The term Rapid Application Development, or RAD, has been around for a few years. From the way it’s avoided in all sensible software development shops, it seems to have gained a bad reputation. There are times when it seems that the idea of rapid development is synonymous with writing throw-away code and simply not doing unit tests.
We are writing more and more complex applications, but the tradeoff seems to be longer programming cycles and more money spent on projects. A great deal of time is often spent on setting up the development environment and configuration for the application.
I would like to take a brief look at a couple of application environments that can jump-start the application process and provide tools that can bring the development time down considerably. I’ll stay in the Java space as I have a great deal of experience there, and a lot of enterprise level programmers share that skill set. Also, the tools we are looking at will allow us to reuse the vast amount of Java third party libraries and code we have put in time and money to develop.
The tools I mention here have some very good documentation online and several tutorials are just a Google search away. So, in this blog, instead of attempting to present you with code that shows how I use these tools and the problems they solve for me, I’ll introduce you to them and urge you to spend some time to work with them to see if they solve your problems.
Web development
Java, and later C#, ushered in an era of relatively quickly built web applications a decade and a half ago. It allowed us to shorten the development life cycle of major systems and deliver them in a new way. As the ability to write more functionally complex code and frameworks have been developed to deliver this complexity, multi-year projects once again have become the norm.
Grails
Grails was developed as the Java VM Rapid Development answer to Ruby on Rails. It has grown beyond being just another Rapid Development environment. In a very high profile case, Netflix has used Grails to develop Asgard, an application to assist development shops in deploying applications to Amazon’s cloud.
Grails’ coding by convention paradigm decreases the amount of time to develop parts of the web application by tying different parts of the application to others by convention instead of forcing the programmer to code those parts. For instance, a class in the model named Employee would have a corresponding table in the database by that same name.
Not giving any care to the look and feel of the website and having no legacy database to contend with, I’ve been able to build a full CRUD, or Create, Read, Update, Delete, application in about 15 minutes. Once you have the basic operations in place, you can modify the application for look and feel.
Grails applications use a combination of Groovy and Java in building the application. Using good programming techniques, a Grails application can be written quickly, but yet remain highly maintainable.
You also do not need to, nor should you, give up testing when using Grails. Grails unit testing supports JUnit 3 and 4 as well as Spock style testing.
Desktop application development
Java is not known as a desktop application language. I think a lot of that is because of the complexity of writing and maintaining a true Rich User Interface in Java, even with Swing. There are some libraries and frameworks for helping with that.
Griffon
Griffon is called a Rich Application Platform and is very Grails-like. Griffon handles much of the framework of a standalone Swing application so the developer can concentrate more on the business logic. Griffon’s reliance on convention, similar to Grails, is both a boost for rapidly developing the application and for maintaining it later. The parts of a Griffon application are very distinctly defined between the Model, View, and Controller (MVC). The framework then injects references to the other layers, so the model is available to the controller and view, and so forth.
Griffon is probably more reliant on Groovy to build the application than Grails is. But it allows you to use the power of Groovy to overcome what I believe are some of the shortcomings of programing in Swing, mainly in providing SwingBuilder that helps, logically, building a Swing interface including help with the different Layouts. I’ve always preferred the GridBagLayout when building Swing applications because of the flexibility it brings, but the amount of information that must be set in each object makes coding the UI slow and harder to maintain. The SwingBuilder, among other things it does, provides a great deal of help with that.
Griffon has a built-in unit test, and the ability to add Spock testing as a plugin. In Griffon, as well as in Grails, Test-Driven Development does not have to take a back door to Rapid Development.
Griffon will then build your application as a standalone jar; an applet that can be deployed via a webpage; a Web Start application which will allow you to deliver the application as well as updates over the Internet; or all three.
Summary
There is no reason to give up good programming practices, such as testing or working to write maintainable code, in order to write rapid code. Sometimes, it might just be how we start the project.
A good builder keeps a well-stocked tool chest and uses the right tool for the job. These two tools should be in every Java shop’s tool box. Take a half a day, or some time over the weekend to download one or both of these environments and work through a tutorial or two. Then you can tell if these environments will be worth spending the time to learn.
