Rapids

Don’t Fear the Rapid

by on October 29, 2013 8:03 am

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.

— Rik Scarborough, asktheteam@keyholesoftware.com

  • Share:

Leave a Reply

Things Twitter is Talking About
  • .@NebraskaCC is just 2 weeks away & tickets are still available! #KC developers: Lincoln is just a quick 3-hour drive away. Well worth it!
    March 3, 2015 at 10:59 AM
  • Happy Punday from the Keyhole team! :-) We hope you're having a great day. http://t.co/p0iDzAY9qL
    March 2, 2015 at 2:54 PM
  • There's a new post on the Keyhole dev blog from @joshuarob01 - Agile Team Member Anti-Patterns http://t.co/2nfYQNIkP0 #agile
    March 2, 2015 at 10:57 AM
  • Heard of #GrokOla yet? Q&A with our expert dev team + code-sensitive wiki for tribal knowledge http://t.co/oCITNW9xEf http://t.co/61dIP4Q4jE
    February 27, 2015 at 1:38 PM
  • Rapid appdev has a bad rep, but there are ways to bring development time down the right way. Don't Fear the Rapid - http://t.co/8CKhAzmysb
    February 27, 2015 at 1:05 PM
  • RT @DZoneLinks: Swift 1.2 Arrives: 13 New Features - http://t.co/07q5vavZsT - @DZoneLinks Big Link by mswatcher
    February 26, 2015 at 2:17 PM
  • Our GrokStars are at it again - they've released a free #GrokOla primer. Get to know Java Lambdas: http://t.co/D2iLLj8mph
    February 26, 2015 at 9:13 AM
  • RT @dbgrandi: OH: “Do programmers have any specific superstitions?” “Yeah, but we call them best practices.”
    February 25, 2015 at 6:05 PM
  • New Primer: Introduction to the #Backbonejs MVC Framework - http://t.co/VLRJ4b5fwj Free #GrokOla tutorial available to the public.
    February 25, 2015 at 4:26 PM
  • #RabbitMQ: messaging software built on AMQP protocol. Learn relevant concepts & how to avoid common "gotchas" here: http://t.co/ZwMXlhspJ0
    February 25, 2015 at 3:20 PM
  • #Java is OO but contains non-object primitives. Autoboxing feels more like a band-aid. Do primitives need to go? http://t.co/A8ChCBHXJO
    February 25, 2015 at 1:44 PM
  • We're excited for Tech Night tonight! @bricemciver will present to the team on Leaflet.js in preparation for his @nebraskacc talk. Lucky us!
    February 24, 2015 at 4:15 PM
  • Do Primitives need to go in enterprise apps? - http://t.co/A8ChCBqmle New #Java post on the Keyhole blog.
    February 24, 2015 at 3:31 PM
  • When you pair #JAXB & #JPA, you can expect some "gotchas." Here are techniques to help you overcome the hurdles - http://t.co/J1s5DpcsCp
    February 24, 2015 at 8:15 AM
  • Do Primitives Need To Go? - http://t.co/A8ChCBHXJO New #Java post on the Keyhole blog by @jhoestje
    February 23, 2015 at 10:44 AM
  • New to #JavaScript prototypal inheritance? Here are some notes to help you along the way - http://t.co/NTIDZS6Uhy
    February 20, 2015 at 12:10 PM
  • XML Manipulation With XML Copy Editor: http://t.co/iHHmyAUQqU Good, free tool for when you need to manipulate an #XML document directly.
    February 20, 2015 at 10:35 AM
  • We've been releasing some free #Grokola tutorials. See them all in one spot - http://t.co/WDt5fWa728 #JavaScript #Backbonejs #nodejs #java
    February 19, 2015 at 2:42 PM
  • Code For Maintainability So The Next Developer Doesn't Hate You - http://t.co/iG2wW2rSWj Eight helpful tips to do so.
    February 19, 2015 at 11:20 AM
  • Functional Reactive Programing & #JavaScript offer an elegant way to reduce complexity of time-varying events. Intro: http://t.co/YGSsz5e0xN
    February 18, 2015 at 3:15 PM
Keyhole Software
8900 State Line Road, Suite 455
Leawood, KS 66206
ph: 877-521-7769
© 2015 Keyhole Software, LLC. All rights reserved.