Introduction
2.5 Years ago, I got my first cup of Grails. It was some time before the Groovy/Grails Exchange 2007, which I visited consecutively. As a result of that visit, I had Graeme Rocher over to our company to give a presentation about Grails (almost 0.4 at that time), and I expected the rest to follow naturally (the rest being: drop all our Java development and take up Grails for all of our web development). I was a little naive in that, I experienced the couple of months after that. Not even did we not drop all our Java development: we dropped none, nor did we picked up any of the cool features Groovy or Grails offered. Instead, people went crazy with frameworks like Wicket, SEAM and other cool stuff, like..ehh…EJB’s…

However, in my spare time I never left Grails and I used it for a lot of prototype applications, especially because the ease of setting up a complete project with Spring/Hibernate integration, etc. And also because it’s just fun to use the power the Grails framework harnesses. Anyway, I never could convince people to seriously use it. I inspired some people to use it, but only for short periods. The lack of IDE support didn’t help in that, and with the thousands of frameworks around, you’ve got to make a choice somewhere. However, I haven’t given up on Grails, and I still try to use it as much as possible. So, when I started for myself in April as an independent (though I do favor certain technologies!) consultant, I thought: this is my chance! I can now focus on Grails technologies. However, even though I’m not quite inexperienced with Grails, I found it hard to find a good (well, any actually) project which was open to Grails, so I found a different project, in which I could focus on other things (like ATDD/TDD, XP, and other quality related things).

However, then, all of a sudden my manager showed some interest in Grails (might not be the best reason to use Grails btw, but it’s great that this is without any resistance!), and we decided to take on a project in Grails. There, the problems started. (Note: I don’t blame anyone in this, except myself: I should have used a different approach. That’s part of reason for writing this blog, to prevent you from making the same mistakes).

What I did first, was tell a little bit about Grails to explain the team how Grails works. That was actually my first mistake. I should have told them lots, lots, a little more, and everything again after that. I thought the transition would be easy, but they were struggling with the framework and the language. I didn’t expect this, to be honest. My expectation (and experience) is that Grails is easy to start with. Get a book, read the documentation, and your ready to go. We built a good prototype, got great feedback on it! However, the old habit kicked in.

Building Grails
First, we tried to build our Grails application with Maven. Bad idea, since it caused some nasty challenges, like getting the code coverage to appear, and getting come quality metrics with tools like CodeNarc. However, you’ll still have to do your (transitive?) dependency management, releasing of software, reports, etc, so there’s something to say for using Maven. It didn’t quite work for us, however, and we spent quite some time into bending it into something which worked for us, which failed. I still haven’t found a viable alternative to Maven. Gradle is nice, Ivy + Ant/Gant seem okay, but that’s not nowhere near the power (I wouldn’t say flexibility) I got with using Maven. I do not, however, make this a Maven vs Whatever Build Tool discussion. I just happen to like Maven for it’s reports, plugin integration, dependency support and modular structure.

Team
Then I also had to overcome the resistance of some of our team members to dynamic languages. Some people prefer the (fake, IMO) safety a statically typed language provides with it’s compilation process. Well, there’s no helping you if you do an Integer.parseInt(“abc”) in your Java code: it will fail just as badly. At runtime. That’s why we write tests, to cover cases like this. This is true for Java, and it’s just as true for Groovy. However, there was still a lot of FUD about Groovy’s usage in bigger projects regarding refactoring, tool support, and even performance. Well, to be honest: I have no idea how easy it is to refactor Groovy code, but, with less code to write, there’s less to refactor. While this might be a bit short sighted, I feel it holds true for a lot of cases.

IDE
The tool support deserves a paragraph on it’s own. Eclipse + Groovy was not a good combination. At all. It was bad, worse, and even a bit worse than that. Even if you are the genius to get it to work (or would I say madmen, since a genius would choose a tool like NetBean or IntelliJ, or, heck, TextMate), you still wouldn’t be able to run a decent unit test in it. Did I mention refactoring? I didn’t, for a good reason: No Support For Refactoring. Let me rephrase that: No Support For Refactoring… in Eclipse. Then why choose Eclipse, and not a great tool like IntelliJ (I’m referring to the 8 release) or NetBeans you might ask. To be honest: I have no idea. I don’t use Eclipse. I’ve used IntelliJ for the last 5 years, and only recently I’m switching to SpringSource Tool Suite because of JetBrains’ ridiculous decision to not show module dependencies in the project view. I hope they get some rest after the release of IntelliJ 9, and see the light to put it back in. Until that period, STS is a really good substitute, and has excellent Groovy and Grails support, which is getting better each day!

The right approach?
So, if I would introduce Groovy or Grails again at my work, I would:
- Pick the right people. People who are not intimidated by a dynamic language, but who have the discipline to use it right.
- Pick the right people. People who are prepared to make a switch. To switch from IDE, switch from build tool, switch from language.
- Pick the right people. People who have the mentality to make it work, overcome challenges and share their findings.

Conclusion
It wasn’t intentional to put ‘Pick the right people’ there, but I think that this is the critical factor to make it work. Make it work from within the team, and make it work from outside of the team (IT operations, Management, etc). I’m looking forward into hearing your responses to this. I hope it doesn’t sound to bitter, cause I’m not. I just made the wrong choices with a partially not-suitable team. It’s my mistake, and I don’t blame anyone but me. I just hope people can learn from my experiences, and the post from Marc Palmer was just the right incentive to finish this post. I hope it helps!

Groovy Power Assert makes assertions quite more powerful. The best way to demonstrate is ofcourse by example. When running the following code in Groovy 1.6:

a = 10
b = 9

assert 91 == a * b

This will be your output:

Exception thrown: Expression: (92 == (a * b)). Values: a = 10, b = 9

java.lang.AssertionError: Expression: (92 == (a * b)). Values: a = 10, b = 9
	at ConsoleScript2.run(ConsoleScript2:4)

While quite helpful, Groovy 1.7 introduced an even better assert, which was initially developed for the Spock framework. The new output of running the above in a Groovy 1.7 console is this:

Exception thrown

Assertion failed: 

assert 91 == a * b
          |  | | |
          |  10| 9
          |    90
          false

	at ConsoleScript2.run(ConsoleScript2:4)

Which gives you much more insight in why the assert fails. You don’t have to use numbers, you can use any type of object to assert on, and the assert statement will call the toString method of that class, as demonstrated below:

def names = [ 'erik', 'marcel', 'sebastien' ]
def reverse = names.reverse()

assert ['sebastien', 'erik', 'marcel'] == reverse

Which will output the following:

assert ['sebastien', 'erik', 'marcel'] == reverse
                                       |  |
                                       |  [sebastien, marcel, erik]
                                       false

Quite funky he? Groovy now gives you some nicely formatted assert information which will help you to tackle your failed tests even faster!

PS: (okay, okay, I added this later….) The same works for special Groovy objects, like GPathResults. For example, check the following code:

def xml = new XmlParser().parseText("<test>x</test>")
assert "y" == xml.text()

The result of this:

assert "y" == xml.text()
           |  |   |
           |  |   x
           |  test[attributes={}; value=[x]]
           false

(Mykola, is this what you meant?)

class Employee {
   def doWork() {  "work!" }
}

class Manager {
   @Delegate Employee employee = new Employee()
}

manager = new Manager()
assert "work!" == manager.doWork()

This works really nice. The Manager now delegates the call for doWork() to the Employee. This is quite powerful, and works really nice and easy.

However, what happens when the Manager has two delegates?

class Cleaner {
   def clean() { "clean" }
   def doWork() { "doWork" }
}

class Employee {
   def doWork() {  "work!" }
}

class Manager {
   @Delegate Cleaner cleaner = new Cleaner()
   @Delegate Employee employee = new Employee()
}

manager = new Manager()

assert "work!" == manager.doWork()
assert "clean" == manager.clean()

This also works really nice. Now the Manager has two delegates, and it can delegate the clean method to the Cleaner, and the doWork method to the Employee. However, since I’m quite curious, and had a small twiscussion with @darthvader42 on this: what happens when the names of the Delegates clash, ie. the Cleaner and Employee both have a method with the same name. This is demonstrated below:

class Cleaner {
   def doWork() { "clean" }
}

class Employee {
   def doWork() {  "work!" }
}

class Manager {
   @Delegate Employee employee = new Employee()
   @Delegate Cleaner cleaner = new Cleaner()
}

manager = new Manager()

assert "work!" == manager.doWork()
assert "clean" == manager.doWork()

This fails! Argh! What happens? The console output is fortunately very clear:


assert "clean" == manager.doWork()
| | |
| | work!
| Manager@2e6a54f9
false


What happened, is that Groovy picked the first Delegate it encountered, and uses those methods. The Cleaner doWork is not called anymore, since all calls to doWork are handled by the Employee.

Conclusion
The @Delegate is a very handy annotation to handle some of the plumbing code for you, but just beware of the results when using more than two @Delegates. Btw, while writing this conclusion, I was also curious what would happen if the Manager itself has a doWork method. As I expected, the doWork method of the Manager takes precedence over that of it’s delegates, so the doWork method of the Manager itself is called!

However, because of some changes in IntelliJ 9 regarding the non-visibility of module dependencies (a feature any IDE has, including IntelliJ 8), I decided to look for alternatives. Not knowing which dependencies a module has is an unworkable situation for me, since I find quite important to know if my UI module depends on a ORM mapper, or not (in most cases, it should not).

Luckily, there are (quite) some alternatives. I’ve decided to check out SpringSource Tool Suite, because:
a) It integrates with technologies like Spring and Hibernate
b) It has support for Maven, which I use for almost every project
c) It has Groovy and Grails support
d) It’s free. This is not a big deal for me, since I also paid for IntelliJ (and it was worth every euro), but this way, it’s easy to try out.

So I downloaded SpringSource Tool Suite here: http://www.springsource.com/products/sts, and after a quick download (and mount, I’m on MacOS), I was ready to go. I imported the Maven project (File -> Import -> Maven) and I was ready to go.

Wait…what’s this error I’m getting??

“The type PostConstruct is not accessible due to restriction on required library /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/classes.jar”

Hmm, it seems my project is using an @PostContruct annotation, and for some reason, this is causing problems. Well, after browsing an little through the options, I found this setting, which is the cause of the problem:

SpringSource Tool Suite - Errors / Warnings

This can be found by going to the preferences screen, and then go to Java -> Compiler -> Errors / Warnings, and there you’ll have to set the Forbidden reference access rule to ‘Ignore’ (or warning, but I don’t like the yellow warnings, not for a reason like this anyway)

After setting the option to ignore and rebuilding the project, I good to go, and my project built without any problems!

In short: first impression: nice! I’ll post more about my experiences with SpringSource Tool Suite here in the near future!

At my current project, we have a simple web frontend which is using Wicket, which needs some changes now and then. Unfortunately, Wicket doesn’t reload pages out of the box, and you need some to make this work.

What is recommended to do (but not required), is to set Wicket in development mode. This can be done in multiple ways, but I’ve set the System property ‘wicket.configuration’ to ‘development’. Then, by changing some code in the WicketApplication (which extends WebApplication), you can enable the hot reloading of resource files. The following code is required for that:

String configurationType = getConfigurationType();
if (DEVELOPMENT.equalsIgnoreCase(configurationType)) {
  log.info("You are in DEVELOPMENT mode");
  getResourceSettings().setResourcePollFrequency(Duration.ONE_SECOND);
}

This way, by recompiling the classes, Wicket detects the changes to HTML and will reload them for you, without having to redeploy the whole application, or needing to restart Jetty. Nice!

References

Wicket FAQ

Normally, when I organize something (be it a motorcycling event, going to the movies, or anything else), of all the people who said ‘yes’, 30% will show up (that is, if I’m lucky). Since 12 people expressed that they would attend the first meetup, I expected a group no bigger than 5 people to show up. You can imagine my surprise when out of 12 people, 18 showed up! That’s 150% more than you might have expected, and 500% more than I expected!

The event was kindly hosted by Lunatech Research BV, a small company in Rotterdam, who wanted to impress us with their office and hospitality. That succeeded greatly in that! The office was great, and the snacks where snacks++ ! Really well done, again: thanks for hosting the event!

The plan was to have 2 small sessions (of around 50 minutes each), drink some beer, get to know each other a little, etc. I think it worked out pretty well. We started with a introduction round, and it became apparent quite quickly that not a lot of people really (that is: in production) something with Groovy and Grails. Out of 18 people, only 2 people had real life experience with Grails. While I certainly hope this will increase, this is a really nice baseline. There were quite some members who had something in the pipeline, but nothing to concrete yet.
After our round of introduction, I had a small talk about how Flex, Grails and JMS could be combined into a small chat application. I thought it was a nice application, but due to time constraints, my presentation could have been better… Well, hopefully I’ll have some more preparation time next time!
The second presentation, which was presented by Michel Vollebregt, was great! The presentation described how to use Groovy DSLs, and was a great combination of combining Java + Groovy to create a very readable (at least: from a user perspective) language to calculate savings over the years. A really nice presentation with live coding, which deserves a lot of extra credits, IMO.

All in all, I think the whole evening was great. I’ve met a lot of new people who were all equally enthousiastic about G&G, and I heard a lot of great feedback about the evening. I think it was a big succes, and I’m looking forward to our next meetup in a month or two, which will be hosted by VX company this time. Great work guys!!!

    private void sendJmsUpdate() {
        this.jmsTemplate.send(this.destination, new MessageCreator() {
            public Message createMessage(Session session) throws JMSException {
                return session.createObjectMessage(new ArrayList<TodoItem>(getList()));
            }
        });
    }

The above code uses the Spring JmsTemplate to created messages and send them to the topic. However, when I tried this, I got this exception:


java.lang.NullPointerException
at org.apache.activemq.ActiveMQMessageTransformation.copyProperties(ActiveMQMessageTransformation.java:188)
at org.apache.activemq.ActiveMQMessageTransformation.transformMessage(ActiveMQMessageTransformation.java:173)
at org.apache.activemq.ActiveMQSession.send(ActiveMQSession.java:1606)
at org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:227)
at org.apache.activemq.ActiveMQMessageProducerSupport.send(ActiveMQMessageProducerSupport.java:241)
at org.springframework.jms.core.JmsTemplate.doSend(JmsTemplate.java:572)
at org.springframework.jms.core.JmsTemplate.doSend(JmsTemplate.java:549)
at org.springframework.jms.core.JmsTemplate$3.doInJms(JmsTemplate.java:516)
at org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:447)
at org.springframework.jms.core.JmsTemplate.send(JmsTemplate.java:514)
at org.epseelon.samples.todolist.business.TodoServiceImpl.sendJmsUpdate(TodoServiceImpl.java:77)
at org.epseelon.samples.todolist.business.TodoServiceImpl.save(TodoServiceImpl.java:39)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)


After a lot of Googling, I found nothing (well, a bug report somewhere, which was totally unrelated to what I had here). Why did I get this error?? I know my remoting was working (String were send), my objects were fine since I could get the list manually by doing a Refresh with the flex client itself (which used ≶mx:RemoteObject>) to call the Spring service…. And then it occured to me that the explanation was already here. I just overlooked it (hate it when that happens): the BlazeDS service apparently doesn’t require the objects (TodoItem) to be Serializable…. JMS ofcourse does! Argh! I forgot to implement Serializable here!

So, if you ever encounter this message, which is hardly descriptive at all, check your objects to see if they are all serializable. It saves a lot of debugging!

I’ve already planned the first event, at (probably) May the 1st, which is viewable here

This evening will be an opportunity for software developers to meet people with different experience levels with the language and the framework. It will also be a good way to identify how to help your and other companies by using Grails. The program isn’t carved in stone yet, but if you have some suggestion, let me know!

Furthermore, I’ve setup an Linkedin group, to get an indication of the interest in Groovy and Grails in the Netherlands. You can join that group here.

So I hope you can help me make this a great succes, and let the Dutch GG community have a voice in the Netherlands!

I’m really dedicated to make this work, but I need your help! It would therefor be great if you could all join, so we can organize some interesting session.

This is the (Groovy) DSL I wrote:

builder.slideshow(filename:'Test.ppt') {
    slide(title: 'Introduction') {
        bullet(text: 'Bullet 1')
        bullet(text: 'Bullet 2')
    }
    slide(title: 'Slide 2') {
        bullet(text: 'Bullet 3')
        bullet(text: 'Bullet 4')
    }
    slide(title: 'Example') {
        textbox("""This is a slide
With a lot of extra lines
Which make no sense
At all""")
    }
    imageslide(src:'background.png')
}

The DSL is pretty straightforward. I didn’t support all features of PowerPoint (nor would I want to, nor is it feasible), but the basics are here. The DSL currently supports all of the above:

• Slides with titles
• Bullets, which can be added to the slides
• Textboxes, which are large text area’s
• Imageslides, which are slides consisting of only images. This is to support all the ‘Beyond Bullet Points’ lovers

While the DSL is far from complete (you could add individual images, position them using X,Y coordinates, add tables, add notes and more), the idea is clear: in a consistent and easy to read structure you can define all those elements you need in a powerpoint presentation. All the missing elements, like stated above, can easily be added by adding it to corresponding domain and exporter.

Domain and exporter you say? Yes! There are ofcourse multiple approaches in creating the DSL, but I’ve kept some parts apart from each other. Under the hood, the DSL is transformed into a very simple domain model, also consisting of slides, bullets, textboxes, etc. This extra layer is introduced to create a separation of concerns. Now, the only responsibility of the Builder is to build the domain model, instead of parsing the DSL and also creating the Powerpoint. The creation of the powerpoint is now delegated to a (also) simple Exporter, which understands the API of the POI library used to create the actual PowerPoint file. So, the model is built by the Groovy Builder, and, once the build phase is complete, the model is given to the exporter, which traverses the model. This makes the code cleaner and also allows easy testing of both the DSL and the Exporter. Ofcourse, I tested none, but instead relied on my excellent programming skills……(The next blog is about TDD, okay??)

This resulted in the following diagram:

Application diagram

I like the approach, but if you don’t, or know a better way, please let me know. I’d really appreciate feedback, since I will probably use a similar approach in the next DSL I create.

The code, and the resulting PowerPoint, can be found in the uploaded zipfile. Like I said: as always, let me know what you think!