Create project structure on Eclipse for spring/hibernate web application

December 7, 2008
  1. On eclipse create a new repository location that points to the SVN source of the project.
  2. If repository is empty create a new remote folder under trunk.
  3. Checkout the project and create the project structure displayed below and check back into source control.

hibernate-war-structure1

Set the target-eclipse project as the output folder for the project on eclipse.

Advertisements

Exploring Hibernate Series: Introduction

December 7, 2008

This the first post in a series of posts that will look at using hibernate ORM (object-relational mapping). The code for each part in the series can be browsed our checkout through svn. Details on this will exist at http://code.google.com/p/exploring-hibernate-series/

The domain for this web application will be as a defect tracking tool. The application will be developed in an iterative and incremental fashion and test-driven development (TDD) technique will be used to develop it.

The following technologies will be used throughout the series.

ANT 1.7.1
Java 1.5
Spring Framework 2.5
SpingMVC 2.5
Hibernate 3.3.1
HSQLDB 1.8

JUnit 4.4
JMock 2.5.1
WebDriver (latest binaries)

Hibernate 3: org.slf4j.impl.StaticLoggerBinder

December 2, 2008

I have recently downloaded the latest Hibernate 3 binary: [version 3.3.1].

I was writing up a test to verify my DAO + hibernate mapping against an in-memory HSQLDB.

I added the hibernate3.jar and all its dependencies to my classpath yet when i executed the test i got the ClassDefNotFound exception for org.slf4j.impl.StaticLoggerBinder.

Looking into the slf4j-api-1.5.2.jar, I could see that there was no impl package! I decided to download the 1.5.2 version of slf4j myself from http://www.slf4j.org/download.html. I unzipped the distribution and when looking in at the source package of slf4j-api saw that the impl package existed but did not exist in the slf4j-api-1.5.2.jar that is part of the distribution.

So looking inside the slf4j-simple-1.5.2.jar that is also part of slf4j-1.5.2 download, I could see that it had a impl package, so I added this to my classpath along with slf4j-api-1.5.2.jar and that stopped the ClassDefNotFound problem.

Not sure that this is correct thing to do but couldn’t find anything better in my quick qoogle searches.

Day 2: Early Morning

November 27, 2008

The day started with a quick standup meeting in the morning;

It included Shaun (the developer), Pat (the project manager/requirements guy) and Claire (the Development manager). Pat speaks first:

Pat: “..As you know I was on site at the clients yesterday. It was a good day, we captured a lot of general requirements and were able to delve into some specifics in certain areas. I will document this today. I also spoke to them about our approach, let them know that we would need their time also so we can make the best product we can for them. They were a little hesitant about that so I promised to come back and explain more on that matter when we meet next. Basically they want to get moving on this ASAP so they are looking for a quote. As always, i will document everything on the appropriate project wiki page..So today I will continue to document everything and document our approach with the customer etc..”

Shaun: “..I was doing some work on project x yesterday, I had an hour or two left at end of day and seeing that Pat said it was a web-based project, I began setting up the infrastructure for this project. I will continue this today and hook up Hudson to our projects. By the end of the day I should the infrastructure setup finished and if i have time will look at what Pat has written up…”

Claire: “..Great guys, Pat, when is the quote to be in by exactly? It would be great if we could get some time to do some (RAD) rapid application development, flesh out some of the quick wins and discover any possible problems we may encounter with the requirements so far. It would be great to give you a working prototype to show and help you flesh out the requirements further when you got back to them. We really want to impress this customer, we could end up getting alot of work from them…”

Pat: “..At least a week Claire, maybe two, I will be talking with them later in the day on the phone so will flesh that out. I agree, by the sounds of things they have plenty of ideas in the pipeline, it would be great if we could become their preferred supplier of bespoke software..”

So after 10mins of talking they break up and get back to their work for the day.

Day 1: Getting Started

November 26, 2008

The project started with a meeting between our project manager and the customer requiring the software.

They have arranged a meeting whereby they introduce their company and their specific needs. It is explained that they are filthy rich and have decided to reinvent the wheel again and wish to have their own custom bespoke defect tracking tool as they just simply haven’t been able to get to grips with the current products that exist out there…

So the first requirement we have from our customer is very general. We know that we will be developing a web-based defect tracking tool.

Our project manager slash requirements gathering expert (depending on the hat he is wearing) communicates with us (during a tea break) and lets us know that the project is required to be web based. Other than that so far there is no specifics but he says that they couldn’t care less about how we develop it or what tools and technologies we use, that’s your job they say.

We have one developer (Shaun) assigned to this project so far. The rest are putting the finishing touches to another project. It is hoped to ramp up the personnel on this project soon when the requirements/specifications start coming in. Once Shaun the developer heard it was a web based project, he quickly sets about creating the infrastructure that will allow him and others to develop a web based application.

Meanwhile our project manager continues to talk with the customer and gather the requirements for the project.

Its easy for Shaun, he has worked on several web-based projects in the company now and had good knowlege of the setup and the technologies. He also knows work has been done documenting the development environment on the wiki, Shaun opens the wiki page and reads down the checklist of preferred technologies:

  1. Java 1.5.0_xxx (latest update)
  2. Eclipse IDE (Ganymede) JEE version
  3. Subversion SCM for source control
  4. Hudson for continuous integration
  5. ANT for build management
  6. Spring, SpringMVC, Spring webflow
  7. JSP, HTML, CSS, JavaScript, JSF etc
  8. JUnit, TestNG for test automation frameworks
  9. Selenium, WebDriver for web-based in-browser testing (typically end-to-end tests)
  10. Tomcat, JBoss, Glassfish for supported containers/Application servers
  11. PMD, CPD, FindBugs, Checkstyle etc to automate inspections
  12. Cobertura, Emma for Code coverage
  13. and the list goes on…

Shaun has an hour left at work so he quickly creates a spring project and adds the default WAR project structure. He adds an ANT build to the project with support for developing with tomcat container. He quickly adds some basic test dependencies and some files so he can do a quick manual test to verify the ANT build generates a WAR file and can deploy it to the configured location. It works first time but it was easy, he just replicated the way they have did it before. Happy that his build is working, Shaun checks in the code as a new project on Subversion. You can view the code at the following:

svn command line

svn checkout http://iidtrackingsuite.googlecode.com/svn/trunk/ iidtrackingsuite-read-only

svn url: http://iidtrackingsuite.googlecode.com/svn/trunk/

Or

Browse the code online at http://code.google.com/p/iidtrackingsuite/source/browse/

IID Experiment

November 26, 2008

Today I create a new project on google.code called iidtrackingsuite.

The general idea is to use the project as an experiment to investigate the IID approach to developing software.

Exploring Spring Secuirty Series: part 10

November 26, 2008

In part 10, we change from using the configuration to declare users to create a database backend using (hsqldb) and we add the users and authorities to the schema to allow basic authentication.

We add an initializing bean that is responsible for creating the and populating the schema of the in-memory database on startup.

seeĀ https://heraclitusonsoftware.wordpress.com/software-development/spring/simple-web-application-with-spring-security-part-10

Exploring Spring Security Series: part 9

November 23, 2008

In part 9, we use exceptions mappings to control what is displayed when certain exceptions occur within the application.

see https://heraclitusonsoftware.wordpress.com/software-development/spring/simple-web-application-with-spring-security-part-9/

Software Development Observations: #1 Requirements/Specifications

November 23, 2008

The first statement on observations within software development is around requirements/specifications.

While it may be possible to fully specify a piece of software upfront, it is generally undesirable to do because:

  1. As complexity goes up, it becomes less likely that everything can be captured correctly
  2. The interpretation of what the customer wants the system to do can be misaligned between customer and development group even after agreement.
  3. Sometimes the customer can’t express fully upfront what it is they want.

This sentiment has already been documented by:

In [1], Winston Royce, in 1970 said:

For some reason what a software design is going to do is subject to wide interpretation even after previous agreement.

In [2], Fred Brooks, in 1986 said:

Therefore, the most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements. For the truth is, the client does not know what he wants. The client usually does not know what questions must be answered, and he has almost never thought of the problem up the detail necessary for specification.

He also goes on to say:

I would go a step further and assert that it is really impossible for a client, even working with a software engineer, to specify completely, precisely, and correctly the exact requirements of a modern software product before trying some versions of the product.

Does anyone know of other sources?

Some Questions

  1. To what level of detail should we specify then?
  2. Should we try to prioritize our extraction of requirements from the client?
  3. How much time is appropriate to spend on requirements/specifications gathering in relation to the time it takes to turn that specification into working software?
  4. How many times had we to go back and communicate with a customer over gaining understanding on a specific requirement?
  5. How many times was this requirement modified after feedback from the client?

Bibliography

[1] [http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf]
[2] [http://www.virtualschool.edu/mon/SoftwareEngineering/BrooksNoSilverBullet.html]
[2] [http://www.scribd.com/doc/4025086/No-Silver-Bullet-Essence-and-Accidents-of-Software-Engineering]

Software hypothetical question 1: Response

November 23, 2008

In the following post https://heraclitusonsoftware.wordpress.com/2008/11/21/software-hypothetical-question-1-given-a-situation-of-perfect-specificationrequirements-how-should-one-go-about-creating-the-piece-of-software/, I asked a hypothetical question; here is my response (so far):

Customer Involvement

In [1], Winston Royce, in 1970, writes of the importance of customer involvement in the development of software.

For some reason what a software design is going to do is subject to wide interpretation even after previous agreement. It is important to involve the customer in a formal way so that he has committed himself at earlier points before final delivery. To give the contractor free rein between requirement definition and operation is inviting trouble.

Fred Brooks in 1986 goes further in [2] saying:

Therefore, the most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements. For the truth is, the client does not know what he wants. The client usually does not know what questions must be answered, and he has almost never thought of the problem up the detail necessary for specification. Even the simple answer–“Make the new software system work like our old manual information-processing system” –is in far too simple. One never wants exactly that. Complex software systems are, moreover, things that act, that move, that work. The dynamics of that action are hard to imagine. So in planning any software-design activity, it is necessary to allow for an extensive iteration between the client and the designer as part of the system definition.

I would go a step further and assert that it is really impossible for a client, even working with a software engineer, to specify completely, precisely, and correctly the exact requirements of a modern software product before trying some versions of the product.

Our hypothetical situation removes the core need for customer involvement as outlined by Royce and Brooks above. However we must still expect the customer to be involved in the project for the following reasons:

  1. The customer has invested money (and time) in the project and will most likely require visibility on the progress of the development
  2. Even though the specifications were perfect, there is always the possibility that they were implemented incorrectly and somehow this problem has passed through our testing procedures. It is the customer who must finally verify that the implemented behavior is exactly what they required.

It would be extremely risky to not involve the customer and at the start of any project, this should be made clear that customer involvement is so important and an agreement should be made between the customer and development group about what form this involvement will take.

Approach to Analysis/Design

As the specification is perfect, one could argue that it makes sense to perform all the analysis and design up front before considering any implementation. That way we get it all correct in the first go and would be more efficient when it came to the task of writing the code. However there are a few problems with this approach:

  1. This approach assumes we can create a design for the entire system without making mistakes. This is highly unlikely as the complexity and size of systems grow.
  2. Typically we are not producing any working software when we are designing.
  3. Eventually we must implement the design with the technologies that are available. By trying to design the entire system or large majority of it up front, we are not learning anything from creating software with the technologies at hand and feeding that back into our design process.

The truth is that software is complex. And as we progress, we are developing more and more complex systems. The key to being successful at software is to reduce complexity wherever possible. It would make sense then to grow or evolve the system by incrementally developing the system. Thus not all the specification, or analysis or design or implementation or testing needs to be completed, we just need enough specification to get started, enough analysis and design based on what we know, enough implementation to implement this small chunk of the specification and enough testing to verify what we have done so far is correct.

Bibliography

[1] [http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf]
[2] [http://www.virtualschool.edu/mon/SoftwareEngineering/BrooksNoSilverBullet.html]
[2] [http://www.scribd.com/doc/4025086/No-Silver-Bullet-Essence-and-Accidents-of-Software-Engineering]