Project in a week? Not as crazy as you might think…

So after today’s little get-together, I have solidified in my mind what my preferred approach is to the “Project in a Week” problem. Let me preface this with saying that the “Project in a Week” problem to me is the web app – a rich client app might not be so quick to get off the ground. That may take two weeks… (hint: Eclipse RCP)

First of all, let’s look at the development tools:

Eclipse:

I’m not certain that we are ever going to look at another IDE at this point. Eclipse has become that ever-present tool, much like the remote car lock fob, or in my case, the bottle-opener. Eclipse has matured as of 3.2 to be capable of using it and the tools solely from within the Eclipse Project in the majority of our day-to-day development. The Web Tools has rounded out nicely, and even the Visual Editor for SWT/Swing controls is quite extensive.

Subversion:

Subversion is not CVS done the right way. Subversion is a different way of implementing a versioning system. It has support for a database backend, which means transactional commits. It is faster than CVS which, on a larger project such as HWNG, would be quite noticeable. One drawback is that we can’t just go in and hack around with vi in the directory structure as we currently can (and some of us do).

In my mind, Eclipse 3.2 with Subversion (subclipse plug-in) should be our target development environment.

Java 5

Java 5 has several improvements over 1.4.2 for us developers, that I don’t understand why people aren’t yelling and screaming for development to be done under Java 5. Even if the projects are built to <= 1.4.2 specifications, we should be running Java 5 under Eclipse. Many of the newer plug-ins are actually specific to Java 5, which at times can be frustrating when the plug-in has something that would be really handy on a project.

That being said, I cannot think of one good reason that any new development should not be built to Java 5. To be honest, any further development of existing projects should have an upgrade to Java 5 as part of it if the client is not running it. I would really like to understand why a client would think that the upgrade is not possible/feasible, but I don’t think I ever will.

Why Java 5 you may ask? For those of you who have not used it yet:

  • annotations
  • generics
  • auto(un)boxing
  • annotations
  • cleaner loop constructs
  • enums
  • varargs
  • concurrency utilities
  • annotations (did I mention that already?)

I could rant on Java 5 for days, but I will simply wrap this up by saying Java 5 good, Java 1.4/1.3 bad.

So what is the stack I would like to see used? Simple: Tapestry 4+, Hibernate 3+, MySQL 5+, Spring (if needed), and jMock.

Tapestry 4+

Tapestry 4 has several improvements over Tapestry 3 that make the argument for Java 5 all the stronger. Tapestry 3 forced us to have a .html file (the source for the page), a Java class(the behaviour) and a .page file (the bindings between the first 2). Tapestry 4 allows us to drop the .page file and use annotations to bind methods and objects in the Java classes directly to the references in the .html files.

It takes a little bit to get your mind wrapped around Tapestry if you have done alot of work with Struts. I never fully got my head around Struts, but then again, I am a moron. Tapestry is simple enough that even I got into it quite quickly. With Tapestry, the Java class associated with the page is that page’s behaviour. I found Struts often was crazy with actions, jumping through several classes to perform a function. I found Struts terrible to debug, whereas Tapestry degbuggin is phenomenally simpler: you get meaningful errors and actual state (of the session, for example).

Another sweet spot for Tapestry: Components. If we want to get into code re-use, and continue to have building blocks for future projects, re-use is mandatory. Tapestry makes it very simple to encapsulate a chunk of functionality (such as a user/pass and login component) that would most likely be used by every web project we did.

Support for validation and internationlization is built right into the framework. HiveMind is similar to Spring in that it can be used to inject services and objects into the application (hence my “if needed” comment above with respect to Spring).

WARNING: be very, very careful around the rewind concept in Tapestry 4. This is something that H.L. Ship has been wanting to remove from Tapestry, but if you need to fully understand it, get Buckley to give you a better explanation than I can.

Hibernate 3+

Do I really need to convince anyone that Hibernate is currently the sweetest ride as far as persistence goes right now?

Four things that I personally love about Hibernate (apart from it being quick and easy) are:

  1. synthetic fields/values ie. being able to have a field whose value is the result of a query defined within the mapping file
  2. the ability to map objects however you like – we are not restricted by a database schema
  3. unit testing POJOs is soooo much simpler than the hoops we have to jump through to test friggen EJBs
  4. can also take advantage of annotations in Java 5 (the first person to count how many times I have used the word ‘annotations’ gets a candy)

MySQL 5+

Free is always better right? If the case of MySQL I would disagree up to and including version 4. Version 5 has brought along three key things that, as a colleague of mine so aptly put, “almost make MySQL a real database”.

All kidding aside, MySQL is another open source project, and the most significant additions that v5 brought with it are:

  1. stored procedures
  2. triggers
  3. views

This actually brings MySQL much closer to commercial, enterprise-solution databases. There is certainly room for improvement on a few things and some things that are still missing (partitions are in the works for 5.1), but overall a tool that will satisfy 99% of our projects.

jMock

As stated above, unit testing becomes super simple if we are using POJOs. In most cases, we are still going to need to test other things such as services, and will want to be able to mock requests/responses in order to test commands.

jMock should certainly be a tool in everyone’s bag of tricks when it comes to testing.

Spring

I personally have not used Spring extensively, however the little that I have used it, and the more I read up on it I can certainly say that this is another item that is a must have in our toolboxes.

To wrap this up, I think that if we had a properly constructed set of projects that we could check out, have dependencies to, and start using projects to define our building blocks, then the goal of a “Project in a Week” suddenly becomes much less crazy than it first seems. With proper setup, there is no reason why a dozen-page web app could not be done by a team of 4 in one week.

Next time:

Stacking the Deck: How to Set Up Eclipse Projects for a “Project in a Week”

-m

It's only fair to share...
Share on FacebookGoogle+Tweet about this on TwitterShare on LinkedIn

Leave a Reply