thejavajar

Day three of 2GX was a pretty exciting day. I checked out a presentation aptly titled “Groovier Spring” with Scott Leberknight. Basically, what I took from the presentation was that Groovy is not just another programming language to be compiled and executed in the normal sense. It can used for configuration or even dynamic creation of classes (not objects) and rules or maybe even work-flow. For example, if you wanted to, you can embed Groovy into your Spring configuration files or bean xml files to include logic during bean creation. So, that is cool but why not load some Groovy scripts from your database, use the bean builder and configure some beans when you need them or if you need them? Why not inject what you need when or where you need it? Yeah, I will expand on that at a later date.

I also stopped in at a presentation by Venkat Subramaniam titled “BDD in Java and Groovy”. I am really a big fan of Behavioral Driven Development and even more interested in learning more about Agile Development as a whole. Basically, BDD lets you drop the technical talk and test your software from a more native(like plain Englsh) approach that can be shared and interpreted all the way from conception to implementation. For example if you were writing a inventory system, one test would like this:

Given a customer buys a widget
and there are fifteen widgets left on hand
when a customer returns the widget for a refund
then I should have sixteen widgets on hand

I would like to spend some time in an Agile development environment to see how it all works.

After lunch, Jason Rudolph, author of Getting Started with Grails presented “Refactotum”. Jason was digging into the Groovy and Grails source code and looking at how to improve what has been written. He also encouraged the audience to get involved with Open Source development and his presentation proved how effective the community can be with somewhat little effort. Jason discussed Cobertura and the importance of testing, real testing, effective testing. I took away a great quote that I will definitely use in the future, “comments lie, tests don’t lie”. He is right, comments are sometimes needed but most developers can just interpret the code and comments are rarely updated after a fix. JavaDocs are a key part of documentation and I would rather have well written, meaningful tests rather code drenched in source code comments.

So, it has been another incredible day at 2GX. I sat in on presentations covering Spring and Groovy, Swing Mashups with Groovy and Grails, GORM(Grails Object Relational Mapping), and Groovy with the Google Maps API. Graeme Rocher, Andres Almiray and Scott Davis put together some great presentations and I have a few things I need to check out tomorrow. Again, I am overwhelmingly impressed with what the No Fluff Just Stuff crew has put together for this event. Jay Zimmerman, who runs No Fluff Just Stuff, sat down with a few of us for lunch today and rattled off the number of events(35+) they have going on this year covering everything from Ajax to Spring to Groovy and Grails. Hopefully, we (James Williams, Vladimir Vivien, and myself) can help bring an event of this caliber to the Tampa Bay area in the future.

Again, if you want to be on the edge of what is going on, you need to get out to an event like 2GX. The presenters and attendees are setting the stage for the future of software development. With the style/format of No Fluff Just Stuff, you not only listen to presentations, but interact with the presenters and your peers. I sat and absorbed information while I was thinking of how I am going to implement what I am seeing. In some cases, I was working with my current code while the topic was touching on what I was working on in my IDE. In other instances, I was up until 2am last night working with peers on what I was trying to figure out, doing some demos, and sharing some thoughts and code samples.

As day one of 2GX comes to a close I can honestly say that Groovy with Grails and it’s underlying technologies (Spring, Hibernate, Quartz…) is more impressive than I initially realized. Well, I knew what Spring and Hibernate could do but to see what Grails adds to the equation is incredible. Hearing it from the source is key. I mean it. Attend an event or training!

I sat in on 2 great sessions today; “DSL in Groovy” presented by Venkat Subramaniam and “The Grails Plug-in System: Plug into Productivity” presented by Graeme Rocher. What Groovy can do, blew my mind. Venkat really opened my eyes to the power of Groovy. I also underestimated what Grails is doing under the covers. Basically, if you know/understand how Spring and Hibernate make development easier, well think of Grails as another layer of abstraction that provides that same power in a much simpler format. Now, combine that power with a modular approach to development with plug-ins and a truly dynamic/agile language in Groovy. All I can say is that Groovy/Grails is turning the corner and not looking back, so don’t lose sight of what is out there. Once I get my ISP hosting situated, I will be deploying my first public Groovy/Grails application.

As far as 2GX, it is a great experience so far. I am really impressed with the No Fluff Just Stuff staff and what they have put together. Alright, hopefully I will have some more time to post my thoughts on day two in the evening.

Is there a “right” or “wrong” way to develop Java Web applications?
Short answer, Yes.
Long answer, No, there are many ways to do things “right”.

Is your application built the “right” way?
Well, answering that question might hurt a lot of feelings. I am not an expert and would never claim to be, but a running/working application doesn’t mean things were done “right”, although your manager and stakeholders may disagree.

I would like to mention a few things that I think are important when working with Java and most other object oriented programming languages. I would also like to clear up some misconceptions and lay down some ground rules for developers.

1) Re-usability does not mean copy and paste.
2) Don’t take ownership of your code. Each project should be a learning experience on how to do it better next time. When you are done, move on to the next project.
3) The number of lines in your application is not a benchmark.
4) If learning new technologies is a burden, become a manager or business analyst.
5) Don’t be afraid to leverage something that has already been written.
6) You are going to make mistakes.
7) Re-factor your code at least once during development.

I will add to this list in the future. This may not be helpful to anyone, but each one of these points keeps me in check.