The Groovy Way to Spin the Web

Grails LogoIt’s nice to start a new year off on the right foot, and what better way to do it than by learning and trying out something new? Grails has been on my mind for years and now it seems that the time is ripe to give it a try. It is one in a fairly long list of web frameworks. Like most its competitors, it too touts unique features which make its developers believe it will be the Next Big Thing. While IT history has made it perfectly clear that a magic wand will not be produced any time soon, I thought it worth the effort to get to know and leave an article or two on the subject along the way.

So, why Grails? To begin with, developers who work within the confines of a single paradigm and have never learned about anything else tend to be quite provincial in their way of thinking: every paradigm and tool imposes many constraints on how developers implement a system and how it works, but they don’t realize it because they haven’t seen anything that works differently. It is like asking a veteran CVS user if they like it: sometimes they say that it’s OK (with CVS, it doesn’t get any more positive than that), but they only say it because Continue reading “The Groovy Way to Spin the Web”


Why it is hard not to love Mercurial

Source ControlSoftware is complex. You wouldn’t believe how complex it is. You might think a skyscraper is a complex system, but if buildings got built like software, you would frequently run into fractal cathedrals filled with basketball halls, space ports and zero gravity hair styling salons, reaching into higher orbit and standing upside down on one of their many towers.

Because software is complex, people tend to reduce focus to what they think is most important and polish it as well as they can. However, every once in a while, one stumbles over something which can only be called a diamond because from whichever point of view you look at it, it always looks perfect. One such system is Mercurial, an SCM system.

Continue reading “Why it is hard not to love Mercurial”

Please keep settings in a database

settingsOne of the things people keep reinventing in all kinds of information systems is settings management. There are a number of ways to go about it, which is what probably confuses developers: settings can go into simple property files, XML/YAML files, structured/typed DB tables and general purpose key-value DB tables, among others.

Each of these is best under specific circumstances and it is worth looking at how things are done in really successful software.

Java uses simple property files which get packaged into .jars and are typically used as read-only mappings which are quick and simple to process and easy to understand. Providing GUI element translations in such files is a fairly sensible use of .properties files. Because no assumptions can be made about what the code does at the language level, using a database is out of the question.

Log4j used to be configured using properties files, but property files being basically maps, this was too strict a constraint to represent the richness of concepts the log4j developers wanted people to be able to express. They solved the problem by switching to XML with which they retained the immediate access to the content, sufficient readability (mostly due to limited document size) and reasonably simple processing. Again, there is no such thing as a log4j database to keep settings in so a database table is not an option.

Having said all this, it is very rare that people develop software for the x86 platform without using some kind of database. Continue reading “Please keep settings in a database”

Umbrello pros and cons

Umbrello activity diagram

UML modelling is one of the more under-served aspects or areas of software development within the FOSS ecosystem, so I find myself pushed to frequently re-evaluate less than ideal offerings.

Umbrello is one of the tools I have revisited a few times and, to cut a long story short, it is one of the tools I will not use again until or unless it significantly evolves. To be fair, I appreciate a number of its properties:

  • in certain respects it is quite fast: during start up, initial work on a diagram, saving of diagrams, editing of individual objects…
  • it builds a fairly extensive and sensible underlying concept dictionary
  • it allows me to document the model on every level
  • it is fairly simple to get around
  • it supports a fair number of UML diagram types

However, there is no shortage of issues:
Continue reading “Umbrello pros and cons”