Knowing when to quit

It looks like there is a storm brewing after Charles Nutter posted an interesting piece on making a JRuby "strap-on" for Grails.

Graeme has responded eloquently stating the case for Groovy, the critical point being that we already have a working solution today. Why bother devoting significant resources into the new code to integrate Ruby, all the unit tests, parallel documentation and API compromises to do this?

A fork in the Grails codebase to achieve this would be a big mistake I feel, for several reasons. Forking divides resources. New core features are likely to be added in Groovy using Groovy paradigms, not Ruby. A large part of Grails success is in its dynamic paradigms tailored around Groovy. Documentation, which is a killer requirement for frameworks, would become fragmented and high maintenance if split across multiple languages. I could go on.

Charles says, rather controversially "Grails’ value is not in Groovy". This is partly true however it is hard to see how Ruby would add value to Grails except by allowing Ruby-ites into the Java web-application development space.

Grails gives value far beyond Groovy, but Groovy gives Grails the crucial edge in companies that use Java.

It seems to me that most Ruby/Rails development is for green-field applications, after all who has a legacy Java codebase they can effortlessly plug Ruby into? Even if Grails supported Ruby, you’d still have a new language to learn, and for what?

This is precisely why Groovy is the best choice, and why compromises to Grails powerful dynamic nature using builders etc would be a big mistake to support a language that is much further from the Java used by most people Grails is targetted at.

We have a long-running thread on the Grails user list about us adding support for JSP taglibs to Grails GSP pages. This is not something we are keen to do because there is a lot of work involved to support this legacy code. However it is something we must do to ease adoption of Grails in Java-friendly organisations where JSP is still the norm.

The point here is that this is a relatively minor "join point" in the stack. I think having Ruby as the scripting language for Grails would be very unnattractive to these companies, far more so than not supporting JSP tags.

Grails is seeing huge increases in interest, and the momentum keeps building. I’m due to speak at the first Grails Exchange 2007 conference. It’s a great complement that Charles is indicating that Grails is a solid and productive stack, given its relative immaturity compared to something like Rails which should be a snip to get working on JRuby, considering that a lot of work would be required to add Ruby into the mix.

As all pragmatic programmers like Charles surely know, you should use the best language for the job. How is Groovy deficient for Grails? I can’t think of a single reason. Why use Ruby instead? The only reason I can see is to ease entry by Ruby coders… who already have Rails.

Therefore this question must now come down to "Why is Charles suggesting  Ruby coders use Grails instead of Rails?". We have quite a few reasons, not least cleanly leveraging all the great J2EE stack elements, but we’ll leave the rest to the users of both to argue about

As I touched on in my recent interview on the Grails Podcast, I am proud to have learned when to quit when there is already a good solution for the problem.

Early in 2006 I developed my own application framework (the latest in a number of them) using JDBC, Spring and Groovy. It was simple and successful in commercial sites, but required too much maintenance to add new functionality and too much scripting for back end code. At this time Graeme asked me why I wasn’t trying Grails out. I brushed it aside as I didn’t have time to look into it fully, and considered it to be a little immature, which at that time it was for my needs.

I then researched Ruby on Rails a little, and got excited by what was possible with coding by convention. Simply put, I didn’t  want to learn another language from scratch, and Groovy was so easy to move into from Java. My dialogue with Graeme continued and I started playing with Grails. Come late 2006 and my new commercial sites beckoned, I didn’t hesitate to use Grails. Grails 0.4 added a lot of polish over previous versions, I like to think due in part to the huge number of issues I raised in JIRA, and made development of the sites painless, and even a joy.

Grails’ time has come.

Using JIRA effectively #1

I use on average 3 or more JIRA instances per day on different projects, and have used Atlassian JIRA now for what must be at least four years now. I ask every prospective client I meet whether or not they have issue tracking yet and if not I recommend JIRA. It is a fair observation however that if they do answer no, it is often a clear sign that the project lacks effective project management, which is usually something that a JIRA license can’t solve, although it can make it more bearable.

Anyway I decided to finally put the things that I nag my colleagues about into a set of hopefully useful basic tips for using JIRA effectively. I really am a JIRA obsessive at times…

TIP #1. When creating a new issue, think about the people interested in the issue.

JIRA almost exclusively uses the issue summary when displaying lists of issues, be they reports, portlets, Changelog or Roadmap. Therefore what you write in your Issue Summary is vital. It must be ubambiguous, clear and concise. Here are some real world summaries for issues I’ve been assigned, which do not meet the above criteria:

"Home page – title"
"Documentation"
"punctuation in a search term"

The only rational response to those is "Yeah, what about it?!" until you dig into the issue to view the description. See how they look in a dummy changelog scenario:

Release Notes - PROJECT XXX - Version 1.0

** Bug

    * [XXX-1] - punctuation in a search term

** Improvement

    * [XXX-2] - Home page - title

** Task

    * [XXX-3] - Documentation

Not exactly informative is it? Users/stakeholders will not really understand what has changed in this version.

Issue summaries should be concrete statements of problems or tasks, such that the changes effected in the behaviour of the project resulting from them is pretty obvious to the reader. We might re-write the above issues as:

"Change home page title text"
"Create new developer documentation"
"Punctuation handled incorrectly in search terms"

Much better, and it all looks much more professional too, vital for any public-facing project.

One common reason for vague summaries is creation of high level "macro" issues by an individual who does not understand the underlying tasks required to resolve the issue, which leads us onto the next tip…

TIP #2. Raise high-level requirements as issues, and use sub-tasks to structure the action required

If you are lucky enough to have JIRA Enterprise, you have the fantastic sub-task feature. It is a great shame Atlassian do not offer this in all versions as I think it is pivotal to effective JIRA usage, and the price differential between Standard and Enterprise is far too much if you just want sub-tasks and not the other enterprise features.

Rant-over, here is a typical usage scenario – Manager wants a new feature "Make widgets support Foo".

As a standalone issue this is annoying for developers as they have to edit it to make it apply to the underlying tasks or create new issues and, very clumsily, link them in to the original with issue linking. Still the relationship between the issues is not very visible.

The solution is for the people assigned to the issue to create sub-tasks of the issue breaking it down into the "technical" details of the job at hand.  Everybody can then see the status of the high level task in terms of its underlying tasks. See this example of such an issue

What’s even smarter is that high level tasks and sub-tasks do not need to share fix-for versions… which means you can pencil in your major functionality for release 1.0 but fix portions of it and release them in point releases 0.5, 0.6 and so on and only in final 1.0 release is the entire high-level task complete.

Jira Calendar Plugin and version naming issues

We just discovered the great Atlassian Calendar plugin. We have our calendars exporting to Apple iCal and we’re all very excited about how this allows us to plan our time in relation to all the projects and releases we work on (we do a bunch of websites and there’s always a lot going on).

Anyway we have a couple of gripes about this:

1. Exported iCAL files always include issues even if you set issue count to zero in the portlet. I wonder if there Is a param to add to limit number of issues in the iCAL feed?
2. For the calendar portlet to be useful in the context of a filter handling many projects, you are forced to truncate your project version names to only include the number. This is ok as you can put descriptive text in the Description field of a version… BUT when you see affects/fix-for version list boxes when creating an issue it doesn’t show the description so Joe Bloggs in management says to me "Marc – where have all my version names gone, I don’t know if this issue should be fix for 2.0.2, 2.0.3 or 2.0.5 because I can’t see the info relating to the version any more".

I suppose with the latter, we need a way to either have the version list boxes show description also (maybe via a little ajax/JS panel?), or some kind of config for the calendar plugin to tell it stop parsing the version name property when it meets a certain character. Neither is very nice.

The problem is that the calendar plugin is potentially useful for us to keep abreast of what we have to achieve in the month in terms of version releases, but to do that means making issue creating much more error prone and confusing for those people who can’t remember exactly what each version number relates to on our project roadmaps.