Monthly Hack Day (Part 1)

I have recently employed two senior developers who are involved in developments run as projects within Opencast Software, either on behalf of clients or in partnership.

Up until this point the company has mainly employed staff for consultancy work i.e. traditional PM’s and BA’s. Although we have had the odd developer (in my case very odd!), they have mainly been consulting on how to develop/architecture/design or have been embedded in client teams.

When choosing these new hires the one thing I made a conscious effort to ignore was the acronyms on their CVs!

I looked at projects they’ve worked on, problems they’ve solved (and how), any contributions to Open Source projects, the range of technologies they’ve learned, and particularly, their attitude to working with new technologies and languages they’ve never been exposed to.

One of them was a .NET developer I know by reputation having worked in the same company but has a yearning to learn new languages and techniques, the other a Java developer of 12 years standing who has converted to Rails over the last 2 years and has some experience of Haskell.

Having established the core of my development practice I want them to ‘practice’ their skills and to stretch themselves.

To that end I’ve established a monthly ‘hack day’ during which they can work on whatever pet project they want. This allows the developers room to ‘grow’ and contributes to the company, either directly through a project or indirectly by learning techniques and languages that we might ‘sell’ in the future.

I am also treating this day as a ‘maker day’ i.e. a day when developers concentrate on making things and don’t attend meetings or other distractions.

The first of these days is this coming Friday (23rd May 2014). I’ve asked the developers to pick their own pet project using whatever technology they like. I’m toying with a Raspberry Pi based autonomous robot to fetch the coffee from the Cafe across the yard, possibly using Clojure or Python for the control/AI.

I will blog on the results of this day in part 2…..

I Roo the day…

I am currently starting a fairly simple Java CRUD web application for work and at the same time I’ve been playing with developing a simple web application in Clojure.

In order to develop the app for work I wanted something I could use to drive out a prototype quickly but then enhance and augment further. So I took a quick look at Spring Roo.

I found I could generate the basics of a CRUD app in hours, including security, etc. Great…or was it?

I found myself unsettled by a number of things in Roo.

• Automatically generated integration tests work well in Roo but I found it hard to find good examples of simple extensions to the generated integration tests. For example, how to test a constraint like @DecimalMax on a JPA entity field.
• I always run my integration tests against a different database in the ‘test’ phase of the build than the database configured for the ‘package’ phase. Usually this is to allow tests to run against an in memory database so they can run fast, clean and without a database server running. This is not something Roo helps you with, and although I’ve done this in Spring and could use the same Spring configuration for the Roo project it’s not obvious or easy how to do this. I just expected it to be something the Roo would support out of the box.
• I am a TDD addict…Roo does not support TDD at all well. It’s possible but not natural.
• Although Roo generates nice clean classes with little boilerplate code as it’s still Java it felt unnerving like magic…I didn’t trust it. I kept having to look at the generated AspectJ to check.
• I always set up my continuous integration server (Jenkins) and maven builds to run code coverage and static code analysis tools (I’m using Sonar this time). As the Java code generated by Roo is minimal, with the aspects adding the bulk of the methods you get a lot of static analysis rules failing (due to rules like, “Unused private field”).
• You also get low branch coverage messages that don’t equate to any code in source files. I suspect that this is referencing code that has been aspected onto the class.
• It still felt verbose and heavy weight compared with Clojure code…just look at the number of jars a simple Roo project requires!

Maybe I’m being spoiled by Clojure but it all felt a bit clunky and too much wasn’t apparent or transparent enough. Having said that, Spring Roo cuts out a lot of set up time. Especially for getting a simple CRUD type web application up fast. If, like me, you have to live in the Java world due to skill sets in your organisation/client then it’s a good start.

You can always push the generated Aspect code back into your Java source if the ‘stuff happens by magic’ feeling keeps unnerving you. I did get used to this within a few days though.

So, overall I’m going to use Roo for prototyping and simple CRUD type applications but really I feel that Groovy/Grails, Scala or Clojure give you more, more transparently. You just need to ‘invest’ in learning them.

Seeking Clojure

Over the last three months I’ve been trying to learn Clojure on evenings and weekend. I started this roller coaster ride of joy and frustration  on the recommendation of my close friend and Clojurian @otfrom.

The start of this emotional experience is rooted in a conversation with @otfrom over a glass of wine at the Open Data Institute. The glass of wine may have been a major contributor to my decision to take the plunge into Lisp for the JVM. The conversation went something like this:

• Me: I’m keen to learn functional programming as I think it has advantages over Object Orientation, especially in the brave new world of ‘big data’ and the increasing emphasis on massively concurrent processing. I’ve started reading a book on Scala because as a Java developer I thought it would be a good place to start.
• @otfrom: Sounds like a good idea. Scala is a good language if you want to dip your toe in the world of functional programming.
• Me: Yeah, I thought as it’s like Java I could encourage our other Java developers to start learning and using it.
• @otfrom: OK. Only thing is, do you think that if they’re struggling to learn they might just abandon the functional style and just start writing Java without semi colons?
• Me: ..Oh sh*t, you’re right. The whole point of this is to learn functional programming not write OO in a different language.