We have arrived at the forth day of the QCon conference. Although today there is an Agile track, I will attend some of the more technical session, too.
Deborah Hartmann introduced the sessions and off we go. I will start with the session on “Grails” by Guillaume Laforge, the Groovy project manager and co-initiator of the framework, that tries to port ideas from Ruby on Rails to the world of the Groovy scripting language. A colleague of mine that is writing a book on Grails has recommended the session, so I will go and see what I get for my money. 😉
Grails = Spring + Hibernate re-invented
Here are the main messages of the presentation:
- Even simple things are quite painful to accomplish with Java frameworks (ORM persistence hard, numerous layers and config files lead to chaos, UI integration messy)
- Grails is an MVC action-based web framework
- Principles: Convention over Configuration (CoC), Don’t repeat yourself (DRY)
- Grails builds on proven components: Spring, Hibernate, Groovy, SiteMesh, AJAX
How Grails addresses pain points:
Pain Point 1: ORM persistence (many XML config files)
- Domain model based on POGO (Plain Old Groovy Objects)
- Relationships between POGO’s based on convention
- Grails generates (called scaffolding) view and controllers for you for a quick start
- By adding constraints to fields an easy way of validation for correct values is provided
- Write only your domain model objects and generate the rest
- Modify some GSP (like JSP) page (view) or some text and reload the page and you are done
Pain Point 2: Numerous config files and layers
- Most things work over conventions (dynamic finder-method construction, based on known fields)
- Reading over relations
- URL’s have easy, consisten mapping like ‘controller/action/id’
- Parameter passing thru easys maps
- Easy job scheduling using Quartz
Pain Point 3: Messy JSP-like pages
- Predefined Taglibs and Components
- Define own Taglibs
Sweet Spot: Enterprise-ready
- Existing Java libraries
- Employee skills & knowledge
- Spring configured beans
- Hibernate mappings for legacy schemas (but still benefit from dynamic finders)
- EJB3 annotated mapped beans
- JSPs, taglibs for the view
- Deploy to your pricey Java app-server & database
- Grails will fit in your J2EE enterprise architecture
Positive impressions about Grails (maybe to incorporate somewere else)
- Conventions over Configuration
- Extend that with metadata where needed
- Dynamic language, so short code-build-run cycle
Questions that remain
- How much logic goes into the GSP-pages?
- Taglibs, huhhh?
- Still generation needed? Why?
All in all an informative talk of Guillaume. Maybe I should try some first steps with Groovy (although its syntax does not appeal very much to me).
The afternoon starts with another scripting language: JRuby. I first wanted to attend the Test-Driven Development session of Steve Freeman, but during his introduction I noted it was too elementary for my knowledge, so I voted with my feet and went for the session about how to integrate Java and JRuby.
In contrast to the Groovy session, the JRuby session seamed quite low-level. No so much the content, but the form of presentation. The presenter (Rob Harrop) just started with the jirb (JRuby interpreter) in commandline manner. He type away quite fast, but after the code moved over the top of the screen, I think, nobody new anymore, what exactly he was doing (actually creating a small Swing application) directly in the interpreter.
So how does JRuby compare to Groovy/Grails. I am basing my lay judgement on few things I saw on the two sessions, so see this not as an expert talking.
Ruby integration into Java is not seamless. Instead you have to use special integration classes to bind it in. Groovy instead makes the use of Java objects a breeze. Java objects and Groovy objects can be used as if they were the same.
Ruby showed a strength in creating new domain specific languages (DSLs). From the point of view of a poor Java programmer JRuby feels very awkward and strange. Many things are not obvious, this is one of my main critique points. Explicitness ist often missing, like when you overload operators, etc.
A issue I find critical with JRuby and Groovy is the dynamic additon of an API (say methods, functionality) to ONE specific instance of a class. While this might be useful in some case, it can actually be nightmarish when it comes to read and understand code. It actually decouples classes from logic making it more difficult track down, where something happens at which point in time (without recurring to debugging).
The next session was “SEAM” presented by Gavin King. He started with the usual rant against Agile and Test-Driven Development (TDD), by saying you need nothing of this “crap”, just use Seam and you are up to a quick start with your web application.
Seam generates a skeleton for a web application inclusive some simple test code. You can modify the code of your application much like in Grails.
“We need no f*cking unit tests. Any one programmer can write those simple POJOs without error. The problems come, when you test a class together with its collaborators.”. So much about a professional attitude to testing.
Seam uses much XML configuration and is in that regard not better than Hibernate or Spring. Gavin admits, that he would prefer doing it in plain Java.
What Seam brings to the table:
- Single component model for JSF, ESB, EJB, etc.
- No actions
- Persistence: No DAOs, instead binds components that access database through JPA/Hibernate directly to the view
- After changing the DB structure, you need to restart the web server.
Seam incorporates the concepts of conversation based transaction. This a very valid approach to transaction handling in web applications. In fact we have incorporated something quite similar in our own framework.
The next session I attended swang back to Agile software development, when Jeff Sutherland, the co-inventor of Scrum, talked about “Agile Project Management: Lessons Learned at Google”. The room was crowded full, which nicely reflected the interest people had in Scrum. The voices I overheard at the conference showed clearly, that many people would like to try Agile, but feel very unsecure, what agile would bring them and how to start with it. Many doubt that it is worth the effort.
At Google the Adwords project is using Scrum, they have begun about a year ago in early 2006 to introduce individual Scrum practices, like a release backlog, into the company. Originally in 2001 Google decided, that they did not need any Managers, because they were not adding value to the company. So they eliminated all managment positions. So from that time on, projects evolved organically. When Google was growing bigger and the software (in case of Adword) increased in size (500’000 LOC and still growing fast), the project manager of that project saw the need for a little bit more structured approach, which would not destroy the organic nature of the current way to do things, as this was seen as a good thing.
Technorati : QCon Conference Agile Report Grails
Del.icio.us : QCon Conference Agile Report Grails
Ice Rocket : QCon Conference Agile Report Grails