Dabblings in open source software projects

Sorry to bore you with yet another post designed to remind myself about what I should be mentioning in job interviews.

This post is a breakdown of some of the various participation that I have had in open source projects in the last few years.

• Grails - postings on public newsgroup with gotchas of an upgrade to version 1.1.1 with maven versioning



• Tomcat - following and posting responses to Tomcat users newsgroup; attending presentations by Mark Thomas



• Linux-HA - participation in newsgroup during set up of cluster for Airways project.



• Spring - postings on forums; downloaded source for 3.0 to check use of LinkedHashMap as default type for Map in bean properties.



• Hibernate - postings on forums.



• JBoss 4.2 - checked out source code from subversion repository to apply patch for ajp issue.

VMWare to acquire SpringSource

I found myself doing a double-take as I skimread the Twitter feeds this evening. VMWare to acquire SpringSource - hey, hey what the?

Rod Johnson has blogged about it, and this time it's not April fools day so there may be some truth behind it.

I wonder what this means for other virtualisation and cloud computing providers?

For instance, will this influence the direction of Grails support for Google App Engine? After all, it didn't take long for Grails to do an about turn and support Tomcat instead of Jetty as its default servlet engine after G2One was acquired by SpringSource.

My experience on the London IT job market during economic downturn

After a holiday in Ireland and the UK back in 2007, I decided that if nothing much was happening for me in New Zealand then I should head to the UK where I would have more opportunities to see the rest of the world.

In September 2008 my paperwork came through for my tier 1 visa to live and work in the UK.

I booked my flights so that I would arrive on the same date that the visa became valid, hoping to make a quick start at securing work.

Strange as it may sound, I didn't have any real experience of looking for work. My job in New Zealand had resulted from knowing a bit about a particular technology - CORBA - and a little bit of good luck.

I had initially hoped for some parttime work during my post-graduate study, but got invited to take on a fulltime job - with the option to continue studying parttime. Given that I was only studying to improve my chances of getting a job, this was an opportunity that I could not refuse.

Nearly 10 years later, and on the other side of the planet I had to actually apply for jobs and wear a suit to the interviews - as opposed to the "Pink and The Brain" t-shirt that had been part of my clothing selection back in 1999.

Working in a single company for a long time has some down sides, one of which turned out to be that the choice of technologies used did not match up well with what many job advertisements listed. Spring and Hibernate were the two biggies that I soon identified as being a big deal, so I read some books attended user group meetings etc. and even managed to win a 4 day training course.

After following other people's advice by applying for contracting roles, I started to consider permanent roles. After about the 3rd face to face interview I was lead to believe that an offer of employment was just a formality, so I stopped applying for other roles and considered having a little holiday over Christmas.

In early January the role fell through due to corporate re-structuring that had been followed by a companywide recruitment freeze. It was tough to get myself back into interview mode, so the next couple of companies didn't get a good impression of what I was capable of - 1 even told the recruitment agent who had represented me that I came across as though I wasn't that interested in being there.

After lowering my salary expectations I had more roles to consider, and soon came to the awkward situation of having to choose between two roles.

I chose the role that was located closer to home and the venue of the various technical user groups that I attend during weeknight evenings.

After being hired as a Java developer I accidentally painted myself into a corner that was labelled "Grails/Groovy development" at a time when Grails 1.1 and 1.1.1 were having stability issues.

At the end of my standard 3 month probation period the company shocked me by saying they were "letting me go". Given that I wasn't making much headway with the battle against the Grails issues, and several of their former colleagues had recently become available I can understand their decision.

Second time around on the London job market was a little easier. After six weeks and interviewing for eight different roles, I had two offers to choose from again.

I chose the well-established consultancy that offered greater potential for professional development, over that startup that offered more money.

No regrets.

Grails Bug Fixing Sprint

I was just perusing the Grails User mailing list and came across a post by Graeme Rocher asking for the community to let him know what bugs are "hurting" the most.

As part of the movement towards greater stability outlined as a key objective on the roadmap for Grails 1.2 "Bedivere", Graeme is heading up a bug fixing crusade targeting what is going to produce the greatest value to the active users - that means me, and maybe even you!

If you want to get your 2 cents in on the informal "vote", head over to the Grails Jira to see whether your issue has already been reported. If it hasn't then the best way to see to it that your issue gets attention is to add a Jira entry - make sure you give sufficient details about how to repeat the bug or unexpected behaviour, or risk seeing it drop down in the priority list.

On a slightly unrelated note, I wonder if someone will produce a plugin with a silly title, such as "holy hand grenade of Antioch"? The penny is just tropping for me as to the naming of releases and the Grails product itself.

Grails gotchas / showstoppers effecting uptake

I was somewhat relieved when I came across this blog post which highlights the fact that other developers have also faced a loss of productivity when working with Grails.

The "convention over configuration" approach speeds up development and keeps the learning curve fairly easy for most developers, but the list of open issues on the Jira suggests that there are still some aspects that need tuning - or detuning in some cases (e.g. domain objects not having GORM functionality due to something missing in lazy decoration/injection).

I've been wondering what sort of risks are involved when you use a software product that is essentially just providing a layer of abstraction over several loosely related other products.

For example, what can you do if you want to upgrade to a later version of one of the underlying technologies (for a fixed bug, or to use a new feature), when the layer above that hasn't been tested or made configurable for that new release? At present, I would expect that you would be stuck with whatever version is compatible with your version of Grails. This could change once OSGi becomes a bit more mainstream, allowing for the use of multiple versions of the same libraries within a single application. I wouldn't want to rely on that being the saviour of any application of mine though.

Lag time in layered software

After hearing about the dismay of various users of IntelliJ IDEA when Grails upgraded from 1.0 to 1.1, I got to wondering what sort of cost is involved in developing with technologies that are dependent upon other software.

I see this as an area where open source technologies may have an advantage, as the beta and milestone pre-releases allow developers of related products to update their products in parallel.

I will be curious to see how the developers of Grails and the various plugins cope with the inevitable versioning issues that will arise once Spring 3 is officially released.

In theory it shouldn't be a big deal, but it's inevitable that there will be companies out there with the "If it ain't broke, don't fix it" approach to upgrading.

JDBC Connection pooling

On a development system that I have been working on lately, the MySql database connections have been dropping out due to a lack of activity overnight (> 8 hours - a default timeout).

There doesn't seem to be a suitable corresponding timeout setting for the default connection pooling system for the corresponding Grails datasource (DBCP), so I've gone looking at what the alternative pooling systems have to offer, and how they could be configured to replace the default Grails DataSource.

On the surface of things development for dbcp and c3p0 seem quite inactive. Although dbcp shows a bunch of updates coming in their next release, it has now been over a year since their last release.

The Hibernate guys appear to have stopped supporting use for Hibernate with DBCP

C3P0 seems to use SourceForge to allow downloads, but keeps the documentation elsewhere.

Proxool looks like it could have potential - pity the user mailing lists are full of spam, so the likelihood of getting community involvement is remote.

C3P0 will do for today.

Update: I just attended a SpringSource talk on tcServer in London, during which Mark Thomas mentioned that the Tomcat developers have been working on their own connection pooling implementation, and that he is in the process of contributing some fixes to DBCP. (No mention of c3p0).