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:

“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.

Programming Tips on CodeJacked.com

The Maxim Software staff runs codejacked.com, a blog with productivity tips for Windows and Linux users. The tips are mostly in “power user” territory, but sometimes we can’t help but cover topics of more interest to programmers. So, for those of you who are programmers, be sure to keep an eye on the CodeJacked programming category (www.codejacked.com/category/programming/), or even easier, just sign up for the whole CodeJacked RSS feed.

Here are just a few of the recent articles in the programming category, to give you and idea of what you’ll find there:
Version Control – A Developer’s Best Friend,
RegEx Pattern Matching on Dates,
Automatic Daily MySQL Backups,
Review: SQuirreL, an Agnostic SQL Client, and
Quick Tip: Searching for Program Source Code.

One Java Tip: “And That’s (not) Final!”

Something to watch out for with initialization code is that “final” has three different meanings depending on where it’s used, and it’s easy to get confused. For example, a common mistake is that setting a Collection to final doesn’t make the contents immutable, only the reference to the collection is immutable.

Announcing JSR 310 – Java Date and Time API

Stephen Colebourne, the guy behind JodaTime, writes in his Weblog that JSR 310 has been opened with the goal of improving the date & time support in Java.