Demystifying Domain-Specific-Languages (DSL)

Groovy supports creating Domain Specific Languages. A DSL is simply a mini programming language tailored to a specific situation or domain. The idea is to hide the characteristics of the underlying programming language as much as possible (in this case, Groovy/Java), and let the vocabulary of the application domain shine through.

DSLs are nothing new. Just by encapsulating the concepts of a domain in classes (”domain objects”) and by defining the methods on those classes that act on them (”actions” and “messages”), you create a DSL of sorts. You see this a lot in unit testing. As a body of unit tests evolves, common SetUp and TearDown code is often extracted to avoid duplication. As the extracted classes and methods grow and evolve, a DSL emerges. For an excellent example of this, see Clean Code: A Handbook of Agile Software Craftsmanship by Robert Martin.

Groovy accomplishes the creation of DSLs in a number of ways:

Scrum and XP Books for Getting Started

For any programmer who wants to learn the particulars of Scrum (short of attending a Scrum training seminar, that is), if you are already somewhat familiar with agile practices like XP, then probably the best place to start is with Ken Schwaber’s second book, Agile Project Management with Scrum.

Schwaber’s first book, Agile Software Development with Scrum, is more of a reference book than a how-to. It describes what Scrum is, but not so much the nuances of how to use it.

“Clean Code” — Crafting On Principles

I’ve been reading “Clean Code: A Handbook of Agile Software Craftsmanship” by Robert Martin. This is no ordinary book on writing better software. It’s not just a rehash of “Code Complete” or “The Pragmatic Programmer.” Those are both fine books, but “Clean Code” is different. So, please don’t think that if you’ve read one, you’ve read them all.

In Clean Code, Martin doesn’t just name the best practices we should all be following. He explains the reasoning behind each one and gives names to the concepts. Just as the idea of software design patterns revolutionized the way we think and talk about software architecture, Martin’s exploration of day-to-day coding habits gives us a smarter way to think and talk about that.

Case in point: Clean Code kicks off with the practice of giving your objects meaningful names. One aspect of this is that good names do not require anyone who might read your code in the future to have to perform any “mental mappings.” Here’s an example of this that I came across just the other day.

Everything’s Groovy

One of the major benefits of using Grails as a web platform is how almost everything can be written in a single language — Groovy.  No more switching gears between language constructs.  Everything’s Groovy.

Configuring a Grails App for Logging

For any standard Grails app, the error log is called stacktrace.log by default. On some servers, it ends up in the config folder (rather than the logs folder) by default, so it’s hard to find. Also, with a fixed name, all apps running on the same server would share the same log. So, for any new Grails app, be sure to open Config.groovy and change

IDE’s for Groovy/Grails

First choice: JetBrains IDEA 7.0 (with 8.0 coming shortly).  Possibly a good second choice: NetBeans 6.5 (new).  Last resort remains: Eclipse.

Doin’ Our Part for Grails

We’ve started contributing back to the Grails open source project.  First up: furthering the cause towards an initial release of a jQuery plugin (http://www.grails.org/jQuery+Plugin).  Also, the next release of the Jasper Reports plugin (http://www.grails.org/Jasper+Plugin) should make life easier.

Grails: Ready for Prime Time

I am currently leading the charge for our clients with Java-based web applications to adopt Grails (i.e. Groovy on Rails). Grails (www.grails.org) has recently achieved its official 1.0 release, just behind the 1.5 release of Groovy. We’re seeing a 10-fold increase in productivity by using GSP (Groovy Server Pages) over JSP (Java Server Pages), and that factor is only going to improve with practice, and as Grails moves beyond 1.0.

What is Extreme Programming (XP)?

The other day, I was asked for the “elevator pitch” on XP, so I dug out this description from an old posting on another of my sites.

It’s taking best practices to the extreme…

• Long iterations become short iterations with early experience
• Long, irregular meetings become frequent stand up meetings
• Back-end testing becomes unit testing
• Specification artifacts become stories and a full-time customer (proxy)
• Enforced deadlines become developer-derived estimates
• Code reviews become pair programming

Top 5 Ways to Keep a Software Development Project On Track

If the three most important attributes in real estate are location, location, location, then the five most important attributes of good project management are communication, communication, communication, communication, communication.

1. Maintain a written glossary of domain terminology. It’s amazing how often the developers and the customers think they’re talking the same language, but they’re not. Misunderstandings like this are a common source of “assumption errors,” which are a leading cause of wasted effort.