Marc Palmer

Don’t statically type your services when injecting them. It hampers reloading during development, because there are possibly insurmountable problems related to classpath and dependencies.

Nobody seems to be good at it, least of all our utility companies. Where we live, not far from Gloucester, the water company seems to be without a clue.

I don’t know the details but Severn Trent Water run the water plant that supplies what would seem to be most of Gloucester and surrounding areas. A single plant, that is under water and hence shut down. Redundancy anyone?

They are now saying that people are unlikely to have the water back for 7-14 days. That’s an impossibly long time for an area that is quite densely populated at least in the cities of Gloucester and Cheltenham.

What do they do about it? Send out trucks (bowsers) with water. You can get the list of them from their website which is just a plain text dump of abbreviated and sometimes split locations. They kindly tell you to use Google Maps to find these places. I mean COME ON. Look them up once at your HQ and put LINKS in or a map like this one I started doing in a couple of minutes having never used Google Maps to make a custom dataset before.

Large companies seem to have no clue how to communicate with the public in emergency situations. We’re only going to have more and more emergencies as the climate becomes more unpredictable.

At least, that’s what Apple seems to think.

Got my new ADC membership pack in the post and got the customary nerdy black t-shirt that is so big I can hide my entire upper body behind it. I’m hardly a waif, pushing the safe BMI to be honest.

Completely unwearable and a total waste of resources. I don’t want ADC to mail me this black box with a crap t-shirt and a DVD in it. I can download all I need thanks!

As is usually the case with anything "new" there’s a lot of FUD and confusion out there with people who have not used Grails yet, that may be stopping them using it. Here’s a quick list of some of the more common falsehoods being bandied about:

1. "Grails is just a clone of Rails". Ruby On Rails introduced and unified some great ideas. Grails applies some of them to the Groovy/Java world but adds many features and concepts that don’texist in Ruby, all in a way that makes sense to Groovy/Java programmers.
2. "Grails is not mature enough for me". The increasing number of live commercial sites is the best answer to that. Its also built on Hibernate, Spring and SiteMesh which are well-established technologies, not to mention the Java JDK which is as old as the hills. Groovy is over three years old.
3. "Grails uses an interpreted language (Groovy)". Groovy compiles to Java VM bytecode at runtime. It is never, ever, ever interpreted. Period. Never. Did I say never ever? Really.
4. "Grails needs its own runtime environment". Nope, you produce good old WAR files with "grails war" and deploy on your favourite app container. During development Grails uses the bundled Jetty just so you have zero configuration and dynamic reloading without container restarts.
5. "My manager won’t let me use Grails because it isn’t Java". Smack him/her upside the head then!** Grails code is approximately 85% Java. It runs on the Java VM. It runs in your existing servlet container. Groovy is the greatest complement to Java, and many times more productive. You can also write POJOs for persistence to databases in Java and include Java src and any JARs you like in a Grails application, including EJBs, Spring beans etc. Any new tech can be a hard sell in a cold grey institution, but there’s rarely a more convincing argument than "Hey Jim, I knocked up our new application prototype in 1hr in my lunch break with Grails – here’s the URL". [** comedy violence kids, not the real kind]
6. "Grails is only for CRUD applications". Many demos focus on CRUD scaffolding, but that is purely because of the instant gratification factor. Grails is an all purpose web framework.
7. "Scaffolding needs to be regenerated after every change". Scaffolding is what we call the automatically generated boilerplate controller and view code for CRUD operations. Explicit regeneration is never required unless you are not using dynamic scaffolding. "def scaffold = Classname" is all you need in a controller and Grails will magic everything else and handle reloads during development. You can then, if you want, generate the controller and view code prior to release for full customisation.
8. "Grails is like other frameworks, ultimately limiting". All Grails applications have a Spring bean context to which you can add absolutely any Java beans you like and access them from your application. Grails also has a sophisticated plugin architecture, and eminently flexible custom taglibs that are a refreshing change from JSP taglib.
9. "I can’t find Grails programmers". Any Java developer is easily a Grails developer. Plus there are far fewer lines of code in a Grails application than a standard Java web application, so getting up to speed will be much quicker.
10. "Grails will make you popular with women". Sorry quite the opposite, you will be enjoying coding so much you won’t be chasing any women for a while. We should put this as a warning in the README actually, along with a disclaimer about any potential divorce that might result from hours spent playing with your Grails webapps.

Why not come and hear other people talk non-FUD about how they are building web applications in double quick time at Grails Exchange 2007, tickets available now.