Today I started my fourth attempt to build and run a simple Hello World Application in Groovy. I failed using Grails 0.4 and 0.5.something because it just did not work and I did not get any help. Because these were premature version I tried using grails 1.0.rc4, but on my new machine. It failed too. But as I know now, because of configuration and windows permission issues.

Now I was successful! But it is very hard if you try to develop grails, while being no local admin. The problem is not Grails itself, but my lack of windows knowledge. I ended up, with nearly all windows runing as admin, except the browser.

I also stumpled upon different problems. I could solve them together with our friend Google, but I think I needed two hours to get my very simple CRUD application working.

My conclusion up to now: Grails has to be easier to start with.

public class MyApplicationContextAwareClass
{

  @Autowired(required = true)
  private ApplicationContext applicationContext;

  // ...
}

Probably not very usable if you like to test your class (or you have to made the property package visible). But if your class is a test it is very nice and quite usefull.

Just a litte note aside: I know many people saying that object oriented software does not perform well. Mostly that is their pretext to do ancient procedural programming or - worse - to mix up both. But every informed developer knows that this is not true. The (performance, architectural, ...) problem of many oo-software is the mashup of procedural/relational on one side and object oriented on the other. A well-known advice is to build the simplest object oriented programm you could and to leave out optimization as far as you could. Optimize only if it is really, really necessary and only if you know very, very well where your performance lack resides.

This week I stumbled over such a situation. Last week - friday afternoon, of course - a customer called us that the result of the actual iteration does not work properly. A component which generates a network plan from a template and does some computations on that structure really killed the test system. A test on our development machine with their test data showed us that this process takes over three minutes of full workload of the hardware. And the plan had only 64 nodes.

So I took Nils over to a pair debugging session and we did some profiling. The bug was found quickly in the gap between some domain objects that evolved from a relational structure. To fix this we added a little cache to one class. The process took about one minute. Another cache and it performed in under one second! Without changing any other part of the system, because of the oo design.

We took this as a proof of the advices above.

Every up-to-date Java developer knows what a ‘plain old java object’ is and its shorthand: POJO. It is a reasonable term from the view of a Java developer and especially of a JEE developer. But there is so much hype around POJOs that other communities are using this term too. So I found articles about ‘plain old CLR/C# objects’ - shortly called POCOs as you may imagin - and a few minutes ago I stumbled upon ‘plain old groovy objects’ or POGOs.

What the hack is old within a ‘POCO’ or a ‘POGO’? Did I miss ‘.Net 2 enterprise edition’ and ‘enterprise groovy beans’? When will there be POROs and POBOs and POPOs and ...?

Perhaps the term ‘simple objects’ does really describe what is meant.