Welcome to the Jungle (Redux)

Previous: Grails, is it really worth it?

I think there is a general misunderstanding of what kind of value can give Grails to a development shop. It seems that there are people out there that believe Grails, RoR and other breeds mean the end of Software Architectures in the web layer. The reasoning is: if the workload to develop a web application is shorter probably it means we need less skilled developers to code our applications.

Wrong.

This is a bizarre way of thinking from my point of view. I have heard of this before. Lowering the workload of development does not mean poorer skills in your development team. The workload is lower because these frameworks follow the Don't Repeat Yourself (DRY) principle. This means that all developers (seniors and juniors) can deliver faster because they don't have to perform repetitive tasks. That's all. But developers still have to face problems, and have to take decisions about their design to fix them. And experienced developers can identify better solutions.

Back to the original question: Do you need a software architect in a project with Grails? Yes, you do. But may be you don't need a full time architect. I have identified several scenarios:

• Cowboy developer: Grails is a great framework if you are cowboy developer. The framework can enhance your productivity if you are a freelance developer working alone. If you don't need to work with colleagues it means you probably don't need to integrate with third parties (services, legacy databases, existing code). In this case, the cowboy developer can play the role of the architect, which makes all the sense. But, I'm not sure if Grails can be successful in this scenario: Ruby on Rails can fit better from my point of view (cheaper hosting, more accepted...).
• Development shop: Your customers accept Grails as a valid option (this is a prerequisite, don't' forget to confirm first if they are happy with Groovy on Grails. Running inside a JVM and an application server is not enough!). You have a trained team of Grails developers. You probably have requirements regarding integration with third parties. In this scenario you need an architect (or a senior developer that can take the role) to take decisions about how to do the things and draft a design. Due to the fact that Grails is a very constrained development environment, you can save time of your architects. They will focus on giving the best solution, but they don't have to care about small details that Grails takes care of (remember, convention over configuration).
• IT Departments: Congratulations, you have persuaded your management about the benefits of Grails. You have now a team in your staff of Grails developers plus some contractors. Normally, development teams inside the companies focus on the core business.The projects are evolution of others, there is a lot of service integration and maintenance. So your architect(s) will focus on smooth integrations with existing legacy code and services. In this scenario a strong architect is a must because you need somebody with good skills to design the bridge between your existing legacy systems and your shiny new Grails applications. This architect has to be a Grails believer: otherwise he will lose the faith when the firsts unexpected problems arrive, something common when starting with new frameworks and technologies (do you remember your first experiences with Struts, Maven or Hibernate ?)

An architect can save time with Grails because it's a constrained development environment and web developers can be very productive, but forget about saving time in the service layer if you have to integrate with a legacy middleware system, a complex database or web services. The best scenario for the service layer can be compared to a classic development using Spring and Hibernate. Still, I have some doubts about how is the development process and the architecture of a Grails application using a rich middle layer with EJBs and Web Services. I feel like a void under my feet when there is no database and the domain classes are not mapped to this database.

Yesterday I was in the event organized by Facebook in Madrid, The Madrid Facebook Developer Garage. The event was organized by FON, the Wifi company owned by Martin Varsavsky. I think Mr. Varsavsky is doing a great job trying to give visibility of the European and specially Spanish companies in Silicon Valley. The event took place in Teatro Lara, a old-fashioned theater in the heart of Madrid. A nice place, nothing to do with a garage.
Just like the content of the event: nothing to do with a developers garage. It was more like an introduction to Facebook. They sold the announcement of Facebook in spanish like an event for developers. Crap. Not a single word about how to develop applications. It was clearly an event focused on entrepreneurs and companies, not on developers. If I read 'garage' and 'developer', it sounds to me like something closer to the bare metal, right? But it wasn't.
A waste of time. I hope Facebook will learn from this mistake and will make things better next time.

There is a very interesting discussion about how good or bad are code reviews in Martín Pérez's Blog (sorry, in Spanish!). Most of us think that the biggest problem of coding convention is the ego of the developers. But here comes something very difficult to manage, specially when adopting code reviews for the first time: what if some developers reject to follow the coding conventions? How can we enforce developers to follow coding conventions? And finally: is the replacement of the rebel developer by a new developer an option?

Previous: How Grails will change my project plan

The results

I wanted to post my impressions and thoughts about Grails before, but you don't know how the events in your life can twist your plans: a delay in the delivery of the HTML designer, a flu followed by a nephritic colic, a laptop dying with all your development environment inside, the wrap up in Amplía, the Christmas holidays and my new start in The Server Labs. All these things made impossible for me to write down my conclusions about Grails applied to a small size project. Well, finally here it is, it's not a broad post-mortem analysis, but probably it will help you to take some decisions about this new technology.

The development environment

You can read in my previous post my development environment. I'm a Eclipse fan, but Eclipse still lacks of a good Grails IDE. So IntelliJ is an excellent option. I used the 30 days trial to develop the Proof of Concept, and I recommend it if you are going to use it for Grails development professionally. Sadly, I will not have the chance to use it in the near future unless in The Server Labs we have the chance to work in a Grails project soon. But if you are one of the lucky ones to work with Grails in an Enterprise environment, go for it. The learning curve of IntelliJ is not flat coming from Eclipse, but it's not hard. I think IntelliJ is more developer-oriented than Eclipse, honestly. The integration of Groovy and Grails is excellent, you can create specific artifacts because it acts as a Visual facade to the Grails commands. It took me just a couple of hours to understand the naming conventions, what artifacts were created from the menus and how to setup a Grails project. A tip: don't add the suffix of the type of the artifact to create; the commands will add the suffix automatically (convention over configuration, remember this my Java brain...). I changed the version of Grails several times, from 0.5.6 to 1.0RC3, with no major issue.
The configuration of a Grails application is simple because it's centralized under the /conf directory. I modified the Datasource.groovy and resources.xml under the /spring directory. I kept unmodified Bootstrap.groovy, Config.groovy and UrlMappings.groovy. Again, convention over configuration shows it pays off.
I started my project in debug mode, and then I modified all the artifacts (Java and Groovy classes, static files, Groovy Server Pages, properties files) without restarting the project. The environment detected the change and then reloaded the modified artifact. In some cases it did not relaunch the application, but in some others did. A change in a groovy or a java class under /src was followed by a reload of the application. The behaviour is similar to Sysdeo Tomcat, for example.

Groovy for an (experienced?) Java developer

I think this is the main concern of all Java developers when starting with Grails: how long will it take to learn Groovy? I cannot say learning Groovy is hard, but it takes time to change your mind to the new syntax, and of course it takes much more time to get full advantage of the features of the language. There are good resources out there to help, but I recommend to buy a book about the language. I started to read Groovy in Action as an ordinary book, but soon I realized it was better to have it by my side while coding as a reference guide.
First thing you realize is how you end all the lines of your code with a semicolon when it's not necessary :-) Not a big deal. Groovy can do more things with less lines of code once you use all the stuff the language provides. But it's not so easy to use them at the beginning. Your first lines of code with look like Java. As rule of thumb I coded first a la Java, and then I refactored the code with the help of the book Groovy in Action. My code was groovier and groovier day after day. Still, I think I did not get full advantage of some features of the language, specially dynamically extending the language and dynamic types. I did not use dynamic types, and my experience with loosely typed languages like Visual Basic made me a supporter of strongly-typed languages.
The excellent integration of Grails with Spring does not help either. Instead of trying to implement something more complex in Groovy, you implement it in Java and use it just adding the variable to inject the dependency in your Controller or Service classes. Obviously this is an advantage, but you have to disciplined if you want to learn Groovy using Grails and follow the approach 'Groovy first'.

Using GORM

GORM (Grails Object Relational Mapping) is the solution to map the Domain model to your database to hold the state of your business and blah, blah, blah... GORM sometimes made me feel like using a Domain Specific Language. The navigation through the object hierarchy of your domain classes is simpler because you avoid the getters and setters. Code is shorter and more expressive. I used dynamic finders for all the queries, I did not need to use Hibernate criterias -I didn't need them-. I don't know if I was doing something wrong, but I tried a dynamic finder with more than two parameters and it didn't work. I should check now with the new 1.0 final. I used constraints to check the input fields and get better scaffolding. It worked except for the email field (again my fault?).
My first version of the domain classes tried to reuse an existing database schema. But this database schema followed a naming convention very common in Entity-Relationship modelling, but an absolute nightmare in a Domain model. The properties and class names killed all the expressiveness of GORM as DSL language. In a real-life project, you should probably map the domain model to the ER model with .hbm.xml files -the old Hibernate way, killing the convention over configuration approach- if you cannot modify your database schema, but I decided to change the naming conventions of the ER model to something that GORM could digest with convention over configuration.
I think this is going to be one of the main problems to implement Grails in Enterprise environments where it's mandatory to follow some strict guidelines regarding naming at database level. It will work with the .hbm.xml Hibernate files workaround, but killing the convention over configuration.

Update: It seems that Grails 1.0 Final allows the direct mapping in the domain classes.

The scaffolding

It does not matter if you are going to use CRUD only operations or not, the scaffolding generates the basic skeleton for the typical cases in a web application. It means you will have code ready to use. I followed an agile approach, refactoring the generated code again and again until I got the functionality I wanted. After several iterations, part of the code was removed because it was unnecessary while the rest of the code was improved until it covered my initial specifications.
I tried to develop something from the scratch, without the scaffolding, but I found myself cutting and copying the code from other parts of the application. Then I decided to generate the CRUD operations with the scaffolding and modify the automatically generated code.

Web development basics

I have used several MVC implementations -basically Struts-, and some Web frameworks like Sitemesh and Tiles. Struts and Tiles configuration is hell: I tried Xdoclet to relief this pain, but I configuration was still and issue. With Grails you don't have to configure anything. Only plain convention over configuration. And I can't say it took me time to understand how it worked, the learning curve was almost non existent. I had already worked before with Sitemesh, and the concepts behind this framework applies 100% in Grails. I think I really save a lot of time with Grails configuring the layouts of the views.
GSP are almost identical to JSP. Just change the scriptlets code from Java to Groovy and use the Grails tag libraries. The number of tag libraries is big, but honestly I have just coded with the basic ones: conditionals, loops, access to form values, errors...). My HTML designer gave me the pages, and I just modified them to insert the dynamic stuff. I did not use any scriptlet, only the tags libraries. The localization of the pages was like in classic web development: modify the messages_*.properties files and use the g:message tab library.
There is a new scope concept called 'Flash' scope. With this scope, the information only is available for the current request and the next request. It's great to render errors text or warnings.
By the way, I tried to implement my test application avoiding the usage of HTTP sessions.

The controllers

All the controllers were created in the beginning with the scaffolding, but I refactored them iteration after iteration until I get functionality I wanted. Again convention over configuration for the name of the actions helps you to save precious time (compared to Struts this is really an advantage). Closures are key in Groovy and Controllers. You can feel intimidated with the code generated if you don't understand closures and don't know very well the Groovy syntax. I needed some time to understand the structure of a Controller and to double check how render, redirect and direct return of model objects worked. Probably this was my hardest time with Grails: fully understand how to extend Controllers and writing good Groovy code.

Spring to rescue

In my test application I wanted to send an email rendering a Velocity template with some basic information (username, password, url, etc...). I have developed this functionality for several projects in the past with Java, and I have already integrated it with Spring. So I took the Java code and pasted in the project. I updated the resources.xml file of Spring and modified a Controller to reference the bean. The integration of Groovy code and Java code using Spring was perfect. Spring wired the bean automatically, injecting the bean into the Controller. I could recycle my Java code like breeze.

Still not very clear...

I think there are several things to polish:

• If you modify a domain class, the application will enter in an endless loop. Every time I modified a domain class I had to restart my project in debug mode. This was really annoying.
  
• I could not force the change of the language adding a parameter in the url, as the documentation said.
• The application created a session for every single element of the web application -static and dynamic-. It was a reported bug that should have been already fixed.
• The problem with the session made me wonder if Grails was really ready for production. I tracked down the issue in the Jira of the project and it seems they knew and was scheduled to be fixed in RC4. Still, I think it was a serious bug that impacts directly on the scalability.
  

Conclusions

I took me about 40 hours of development to implement my test application. I sized the project with the classic Java web stack of Struts+Tiles+XDoclet+Spring+Hibernate in a range of 60-80 hours. So I was quite surprised with the results. I met a Ruby on Rails developer that told me it took him only 25% of the time to develop a simple web application in RoR compared to the classic Java web stack. I think he was exaggerating, but probably he could improve more than 50%. Now that I have more experience with Groovy and Grails I could improve my performance in future Grails projects reducing from 40 to 30 hours. That's one third of the work needed for a classic Java web stack. Of course, stand alone development cannot be compared with team development. A developer can build in 800 hours more than a team of four people in 200, because of code integration issues, knowledge transfer, meetings, etc. But you can really feel that Grails improves your performance. A lot.
Regarding the adoption of Grails in Enterprise environments, I would like to explain why I think it will be adopted broadly instead of Ruby on Rails. But that's a new story for a new post more focused on management and architectural topics.

Next: Do you need a Software Architect?

This week I have visited the ESOC (The European Space Operations Centre) as part of my new job in The Server Labs. It has been a long time since I was in Germany last time, in the Due Diligence for the acquisition of JobPilot by Adecco (I was staff of Adecco). I think things have not change a lot: Germany is a good place to work if you are in technology: there are good companies, cutting edge research and development, multicultural environment, and people are really, really nice at work. This is also something I felt when I was working in Consors , and I have felt the same in the ESOC.
In Spain people the attitude of people is more 'defensive' and it can sometimes hurt the relationship between client and customer from the early beginning. And it's not possible to compare the number of technological companies in Spain and in Germany.
Still, I really missed something: the colours. May be it's because of the weather, or because of the functional mentality of the people, but I missed the colours and the sun of Madrid.