Getting Groovy (and Grails)

Explorations in Groovy and Grails Development

Archive for the ‘DSLs’ Category

London “Practical DSLs” Preso – Deck

leave a comment »

Many thanks to Peter Ledbrook for organizing the London GGUG meeting last night. I got a chance to present on practical DSLs in Groovy and then Peter finished off the evening with a great overview of some of the cool features in 1.3 and even 1.3.1 (which had only launched earlier that same day).

Here is the deck, and the presentation was taped, so as soon as I get the URL I’ll post a link to it.

Advertisements

Written by peterbell

May 18, 2010 at 4:49 am

Posted in DSLs, Groovy, Presentations

Practical DSLs in Groovy Deck from New York Presentation

leave a comment »

Had a great time presenting at last nights Grails meetup in New York. Lots of great feedback! A smart engaged audience made sure that we discussed everything from Software Product Lines to xText to uses for Visual modeling techniques and whether using the term “language” made it harder to sell fluent API’s.

I’ve reworked the deck a lot from the Sydney presentation, with some more examples and a sense of flowing from an API through internal DSLs to various external DSL approaches if and when they make sense. I also briefly covered a wider range of additional considerations – discussing briefly documentation, error handling and IDE support for your DSLs as well as testing and evolution. I also made it clearer that it wasn’t primarily a presentation on the details of getting rid of parentheses and commas to increase semantic density in Groovy as Guillaume Laforge has already nailed that material. This is really a focus on the wider engineering concepts that arise when designing and developing DSLs.

I’m liking the presentation now, although I think I *will* add a couple more slides with examples round the syntax as I found myself talking about things like categories and ExpandoMetaClasses and even the ANTLR preprocessing hooks and a slide or two would probably have helped comprehensibility – especially as I was just shooting through the syntactic materially really quickly.

I just wanted to thank everyone for coming out and in particular Mark Pollack for arranging the location, food and beer and actively participating in a meetup about a technology he doesn’t get to actively develop in!

Here’s the deck.

On another note, we’re looking to put together another meetup next month. If anyone has any ideas on a topic they’d like to see covered or would like to present on, suggest a topic!

Written by peterbell

May 12, 2010 at 12:19 pm

Posted in DSLs, Groovy, NYC, Presentations

London Groovy DSL Presentation Confirmed 17-5

with one comment

I’ve just heard from Peter Ledbrook that I’ll be presenting at the London Groovy/Grails Usergroup on Monday May 17th at 18:30 at Skillsmatter: The Skills Matter eXchange, 116-120 Goswell Road, London, EC1V 7DP.

Peter Ledbrook will also be giving a presentation on the upcoming features in 1.3, so I’m looking forward to catching that!

Looking forward to meeting old friends and new in the Groovy/Grails community in London. And if you’re interested in DSLs even if you don’t do a lot of work in Groovy, come along and check out the preso – it’s relevant for anyone interesting in adding DSLs to the mix of techniques they use when developing apps.

Here’s the summary:

What are some practical uses for Domain Specific Languages? And how do you go about designing DSLs, implementing them in Groovy, creating tests for your models and evolving the structure of the languages over time? In this fast paced session we’ll look at a real world Groovy DSL, how it was designed and implemented, the testing strategies employed and the options for evolving the structure (grammar) of the DSL. If you’ve built DSLs but want to go further, or if you’ve still not figured out how a DSL might help you to build better, more maintainable apps more quickly and easily, come along and learn more about creating practical, maintainable DSLs for your projects.

It is based on a talk I recently gave in Sydney and will be presenting in New York next week. Hopefully I’ll see you in London!

Update: registration now available . . .

Written by peterbell

May 5, 2010 at 9:24 pm

Posted in DSLs, Groovy, Presentations

Practical DSL Design in Groovy – Sydney Slides

with one comment

Here are the slides from last nights presentation to the Sydney Java Users Group. Many thanks to Dushan Hanuska for helping to make the event happen, Brendan Humphreys for organizing the event and to Atlassian for hosting it and providing beer and pizza at their great offices in downtown Sydney!

It was the first time I had given the presentation, but despite rewriting it about 4 hours before the presentation and jetlag (I’d just landed in Sydney from New York that morning) the presentation was well received. The goal of the presentation was to put context around the process of working with internal DSLs by examining the uses for DSLs, approaches to designing of DSLs, the differences between internal and external DSLs and lifecycle concerns such as testing and evolution. I think it provided a good introduction to the material.

For the next presentation, I want to add a little more detail on good language design choices, testing and evolution and I’d also like to add an end to end example I can evolve and a little more coverage of the language features available in Groovy for implementing internal DSLs, but I feel like it was a good first shot at presenting the material. DSLs/DSM is a huge topic and it’s always difficult to figure out exactly what material will help people to do the best job of designing DSLs and to fit it into a one hour slot.

Thanks for everyone who came and supported the event. Particular thanks to Paul King who flew down from Brisbane. He also kindly shared a bunch of ideas based on his DSL Groovy presentations that I look forward to incorporating into the next cut of this preso.  I enjoyed a great evening discussing everything from DSL design through GPars to ideas on new features for 1.8 and beyond – it was great to spend some more time with one of the team that provide us with such a cool language to work with!

Written by peterbell

May 5, 2010 at 3:10 am

Posted in DSLs, Groovy, Presentations

The Gr8 Conference: Practical DSLs with Groovy

with 5 comments

This session by Guillaume LaForge was probably the one I was looking forwards to the most. I do a lot of work with Software Product Lines, Domain Specific Modeling and Domain Specific Languages. I’d seen Neil Ford the other month at No Fluff Just Stuff Boston presenting on using Java, Groovy and Ruby for internal DSLs and I was interested to see what Guillaume would cover. Historically Groovy has been somewhere in the middle of Java and Ruby in terms of support for the kind of syntactic sugar that allows for the creation of business user readable DSLs and I was interested to see both how Guillaume presented the topic and what specific information  he’d include.

He started off by introducing the problems that vertical (business – as opposed to horizontal technology DSLs like SQL or RegEx’s) DSLs are designed to solve. They allow for clean separation of business logic from application code, allow Subject Matter Experts/business analysts to read (not necessarily write) the DSLs and allow for business rules to have their own lifecycle independent of the usual re-build, re-deploy lifecycle required when the business logic is encoded in Java.

He mentioned that there are a range of possible notations for DSLs – from the “e4 – e5” chess notations to the notations used to describe solutions for rubix cubes and sheet music notation. He then also introduced some real world examples of business DSLs such as anti malaria drug resistance simulation, hr employee skill representation, insurance policies risk calculation engine, loan acceptance roles engine for a financial platform, mathematica like lingua for nuclear safety and market data feeds evolution scenarios.

Groovy and DSLs
Groovy has a number of capabilities that make it nicer than Java for implementing business user readable internal DSLs.
– There is no need to write full blown classes – you can use scripts
– Optional typing (def) – cut down on visual noise – in scripts can even omit def
– Native syntax constructs (lists, maps and ranges – can create own custom ranges e.g. monday..friday)
– Optional params (for top level statements) and semicolons so “move(left);” becomes “move left”
– Named arguments: Can mix named and uunnamed – named params are put in a map parameter.
E.g. take 1.pill, of: Chloro after: 6.hours
==     def take(Map m , MedicideQuantity mq)

– Custom control structures: when closures are last they can be put “out” of the parenthesus surrounding parameters
unless (account.balance > 100.euros , {account.debit 100 euros})
== unless (account.balance > 100.euros) {account.debit 100 euros}

Signature “def unless (boolean b , Closure c)”
– Operator overloading: -15.euros + 10.dollars, -10.kilomaters – 10.meters, taskA | taskB & taskC
e.g. a + b – just put a.plus(b) method
e.g. a – b – just put a.minus(b) method
e.g. a * b – just put a.multiply(b) method
etc.

Options for crediting an  account:
account << 10.dollars
account += 10.dollars
account.credit.10.dollars
depends on users which syntax they prefer . . .

Groovy’s dynamic heart: the MOP – The MetaObject Protocol
All accesses to methods, properties, constructuors, operators, etc can be intercepted thanks to the MOP. While Javas behavior is hard wired at compile time in the class, with groovy, behavior is adaptable at runtime through the metaclass.

Different hooks for changing the runtime behavior:

GroovyObject
getProperty() , setProperty , invokeMethod() , getMetaClass() , setMetaClass()
A GO can have “pretend” methods and properties

MetaClass
Core of the Groovy MOP system
– invokeConstructor
– invokeMethpd
– invokeStaticMethod
– invokeMissingMethod
– getProperty
– setProperty
– getAttribute
– setAttribute
– respondsTo
– hasProperty
– Metaclasses can change the behavior of existing third party classes – even java one.

ExpandoMetaClass
– A DSL for metaclasses!
MoneyAbount.metaclass.constructor = { . . }

Note: 10.euros == 10.getEuros()

Class CurrencyAmount {
Number value
String currency
String toString() { “$value $currency”}
}

Number.metaClass.getEuros = { ->
new CurrencyAmount(value: delegate, currency: “EUR”)
}

10.euros
The delegate variable in closure represents the current instance, and “it” the default parameter

The Builder pattern
This is a great pattern for certain classes of DSLs. You’re probably familiar with the markup builder for XML/HTML, but how about having a builder for HR?
softskills {
ideas {
capture 2
formulate 3
}
. . .
}
knowhow {
languages {
java 4
groovy 5
}
. . .
}

Builders are a mechanism, for creating any tree structured graph – a realization of the GoF builder pattern. It uses hooks like GroovyObject#invokeMethod() to catch all non-existing method calls

Adding properties to  Numbers
One of the common approaches when creating a fluent API/DSL in a dynamic language is to add properties to numbers. There are three ways of implementing this in Groovy: create a category, create a custom metaclass or use the ExpandoMetaClass.
– Create a category: A kind of decorator for default MCs. Interesting scope – thread bound and lexical, but doesn’t work across hierarchy of classes (doesn’t work for subclasses).
– Create a custom MetaClass: A full blown MC class to implement and to set on the POGO instance.
– With an expandometaclass: Works for class hierarchy for POJOs and a flag exists to make it work for POGOs too, but the catch is it’s really a global change so beware collisions with other libraries.

Compile time metaprogramming:
Groovy 1.6 now support compile-time metaprogramming via AST transformations. They are compile time, so there is no runtime performance penalty.

There are two kinds of AST transformations available:
– Global – applicable to all compilation units
– Local – applicable to marked (annotated) program elements, using specific market annotations
E.g. added @Singleton and @Delegate

To create a global transformation:
Implement ASTTransformation
Annotate the transformation specifying a compilation phrase

For discovery, create the file META-INF/services/org.codehaus.groovy.transform.ASTTransformation
Add the fully qualified name of the class to that file

Local is same as global, but don’t need to add to meta-inf – just create annotation to specify on which element the transformation should apply.

For example, the Spock framework does this using syntax highjacking with AST transformations to create a BDD framework.

You can pre-compile pogos like pojos in a spring app, but can also load on the fly to decouple the lifecycle of the business rules form that of the application. Also have eval, GroovyShell, or GroovyClassLoaader – most powerful mechanism. Could also visit or change the AST. Scripts and classes can be loaded elsewhere
Groovy DSLs CAN be embedded in groovy classes, but should store elsewhere – database, xml file, etc

Considerations to remember when designing DSL
– Start small with key concepts – beware of over engineering!
– Grow the language progressively, get hands dirty, play with end users
– Let DSL fly – theirs, not yours!
– Tight feedback loop – iterative process
– Stay humble – can’t get it right first time, don’t design alone at your desk – involve the end users from the start!

And if I might add something, check out Eric Evans book on Domain Driven Design. I did an presentation and an interview at ddd.org on using DSM for DDD’ers. I’d also argue that the DSM/DSL community could learn a lot from Erics work on eliciting and developing Ubiquitous Languages – many of which can be executable (making them DSLs).

Maybe play it safe in a sandbox
– Groovy supports usual java security model
– Use metaprogramming tricks to prevent calling or instantiating certain classes
– Create a special GroovyClasLoader AST code visitor to filter only the nodes of the AST you want to keep – e.g. the ArithmeticShell in Groovy’s sample.

– Don’t just test for nominal cases – explicitly test for errors!
– Ensure end users get meaningful error messages

Groovy is often used for mission critical DSLs . . .

That’s the notes I managed to capture from the session. I’d thoroughly recommend catching any of Guillaume’s presentations as in addition to his deep knowledge about Groovy he clearly has a robust understanding of DSM and the practical uses of DSLs. It was a great session both as an intro to DSLs and with lots of detailed information about using Groovy for implementing those languages. I certainly can’t wait to play with Groovy DSLs!

Written by peterbell

May 21, 2009 at 10:31 am

Posted in DSLs, gr8, Groovy