Archive for the ‘Groovy’ Category
GR8 US Postmortem: Be the Outlier
Sunday, April 18th, 2010
The Groovy GR8 conference is a small intimate gathering that is part educational, part commiseration over not being able to fully use Groovy in the day job, and part therapeutic for having to deal with the incessant ribbing from your pretentious Rails coworkers.
The US version of GR8 was held in Bloomington MN this year and was kicked off with Guillaume Laforge giving a sort of “state of the union” of the Groovy language: the past, present, and future. I’m not aware of any other language that has had such consistent releases. It is hard not to contrast the singular vision and momentum of the Groovy language with the languishing JDK 7.
After lunch, Venkat Subramaniam delivered the keynote with the central message “be the outlier” which was as much a sort of “call to arms” as it was a suggested career path. Citing Malcolm Gladwell’s book of the same name: it is the outliers who change the world and are ultimately successful. Of course, statistically we can’t all be outliers, but it’s a good place to strive for, and an appropriate theme for a conference of less than a hundred attendees.
He encouraged being a Polyglot programmer — even if you didn’t have use cases for all of the languages that you learn — citing that the number and types of languages that you know greatly influence how you think and solve problems.
It bears mentioning that while I had heard of the legendary Venkat, I had never actually seen him speak. It is rare for a speaker to be both a powerful orator and also a technical master. I attended both of Venkat’s afternoon sessions and I have to say that his live coding skills are off the hook. Not only did most of his sessions involve live coding, but he answered questions by coding up examples on the fly.
Now that is a master.
If GR8 is a representative sampling of the future of Groovy, then sign me up. There is no other conference that I’ve attended where I felt such immediate kinship with people that I had never met. I look forward to attending next year.
As a quick side-note: it doesn’t seem to matter if I end up going to the shopping mecca of the midwest, The Mall of America, I will still just pick up presents for my kids at the hotel gift shop as I check out.
Five Reasons that Show My Switch to Groovy is Complete
Monday, July 6th, 2009
- I’ve said that I’m “working with Groovy” so much in front of my family and non-programmer friends that they’ve given up making jokes about the 60’s and getting high, and have returned to general nerd-based jokes.
- Not only can I say “GString” with a straight face, I have forgotten its more popular meaning (and I get confused when people talk about getting yeast infections from a data type).
- When I have to dip down into Java, I feel like I’m “coding to the metal”.
- I have forgotten a time before stace traces that run 100 deep and am pleasantly surprised when I happen upon one that fits on one screen.
- My Ruby friend and I have stopped trying to convert each other to our respective language of choice, and instead have settled on a silent, mutual respect (but really contempt) for the other.
Do you have your own? Feel free to comment below…
JavaOne 2009, Prelude: Nerd Migration
Wednesday, May 27th, 2009
It’s that time of year again. Java nerds the world over are packing an extra inhaler and their well-worn copy of “Java Puzzlers”, preparing for the annual trek to California.
In a few short days, I myself will confront my fear of flying and leave the muggy Midwest for the cool, crisp ocean air and azure skies of San Francisco — home of JavaOne.
Every morning I’ll walk from the hotel, down Mission Street, past the impossibly chic Bay Area natives, to the Moscone Conference Center, where I’ll be among my flannel wearing, asthmatic, brethren, safely indoors, sheltered from the harsh northern California sun (or depending on your tolerance for puns: basking in Northern California Sun).
Browsing through the sessions it looks like there is some quality stuff this year. However, outside of a few talks and the odd BoF, there doesn’t seem to be much Groovy representation (which helps to explain why my proposed talk, “Wow, Guys! Look at all the Groovy Talks Here at JavaOne!” was rejected).
It’s nice to see more sessions on Scala this year, and even Clojure makes an appearance in the “Script Bowl” session.
Also, apparently there are a few sessions on a new language called “JavaFX”…I wonder what that’s all about.
A Text Adventure DSL in Groovy
Thursday, May 21st, 2009
Reading Peter Bell’s write-up on Guillaume LaForge’s talk on creating DSLs with Groovy has inspired me to chime in with my own experience with Groovy DSLs. The following is a transcription of sorts of the first part of a talk I’ve given a few times titled “Building DSLs with Grooy: A Real-World Case Study” (slides available here). This section of the talk introduces the idea of DSLs, and how Groovy is well-suited to creating them, by building a small adventure game interpreter. Enjoy.
If you’re like me, you have intense nostalgia for the text adventure games of the early 80s. Games like Zork, or the Sierra line of adventure games like King’s Quest were popular in part because of their natural language interface.
As an homage to these types of games, I thought we could write our own simple one. We’ll use Java as a starting point, since that’s what I know best, and will just be purely text-based. In fact our only interface will be a nice big text area where the player can type in commands, and get responses from the game.
And you know, I don’t really want to go through the trouble of writing a natural language parser, so I think we’ll just have the player enter straight Java code into the text area and we’ll have our game compile it, run it, and then return the result.
Here’s some example output right here:
game.go("north");
> You go North.
game.look();
> You see a dagger on the ground.
game.take("dagger");
> You take the dagger.
Note that the player needs to know that they’re interacting with a “game” object, but that’s OK, we’ll be sure to put that in the Javadoc — or the player’s manual. As long as they preface every command with “game.” they’ll be OK.
We’re immediately, however, faced with the problem of Java’s static compilation. I suppose we could grab each command from the user, wrap it in a Java class file, invoke javac on it, and run it, but clearly that’s no good.
No worries though — this is a Groovy talk, so let’s use Groovy! In fact, we can just rename all our Java files to Groovy files, and we’re where we were with the Java version except now we are able to dynamically execute code via the GroovyShell. Great! Now we can actually implement this contrived example.
Right away too here, let’s just squirrel away the call to “game.” since we know every command needs to operate on this object. This will save the user a bit of hassle.
new GroovyShell().evaluate("game.${playerInput}")
And too, this doesn’t sit quite right as being a very “groovy” thing to do, but make a note of this, and we’ll come back to it later. So now the player can just enter commands without the “game.” preface, like so:
go('north');
look();
take('dagger');
Well, but since we made the switch to Groovy, we might as well take advantage of the syntactic sugar. In Groovy semicolons are completely optional, and parentheses are optional provided the method that you’re calling has at least one argument. So now we have this.
go 'north'
look()
take 'dagger'
And here’s our Game class where just every command is mapped to a method with whatever arguments they take. The player just has to remember to enclose any arguments in quotes so it will be treated as a String.
class Game {
void go(dir) {
println "You go $dir"
}
void look() {
println "You look around and see nothing"
}
void take(it) {
println "You take the $it"
}
...
}
So here’s where things will start to get interesting. Groovy is a dynamic language, and because of that, it allows us to intercept things like method calls and property access. If we leave off the quotes on a String argument, it will assume that we’re referring to a property (or field) by that name and it will try to call get “whatever” on it. Of course things like “north” and “dagger” don’t exist as properties, so a special method called “propertyMissing” will be called to give us a chance to do something before the exceptions start flying.
If we override this method for the Game class then, we can just assume that any missing property was meant to be an argument of that name, so we’ll just return the name, which is a way of faking that the property actually exists.
class Game {
...
def propertyMissing(String name) {
name
} }
Which enables the player to now leave off the parens on command arguments:
go north
look()
take dagger
Good. So that gets around the quote problem. Now the only wart on the player’s experience is having to remember to use parenthesis on any command that doesn’t take arguments, such as “look”.
So let’s fix that now. Remember, if an identifier is standing off by itself like this, then Groovy will assume that it’s a property — so we’ll just go back to our friend “propertyMissing” and add in this little chunk of code.
def propertyMissing(String name) {
if (metaClass.respondsTo(this, name)) {
this."$name"()
}
name
}
This says that if you are missing a property by this name, first see if you have a method by this name, and if so call it, otherwise, just return the property like before. So now we have this:
go north
look
take dagger
Hey, this is basically a Zork level of understanding! But we can do better still…
Remember the contrived “game.” preface?
new GroovyShell().evaluate("game.${playerInput}")
That’s fine for a serial one command after another type thing, but let’s say that we want to open this up for players to write bots against so they can write automated scripts and “level grind” without the hassle of actually playing.
So let’s employ the Groovy keyword “with”, which takes a closure as an argument and basically sets up a little mini-context for us.
new GroovyShell().evaluate("game.with{${playerInput}}")
So what we’re saying here is “use this game object as the context for the following statements”. That is, this closure is within the scope of the game object first and foremost. Now that opens us up to scripting some of our code thusly:
3.times {
go north
}
look
take dagger
I can now use regular Groovy syntax, such as closures, and say “go north three times”.
Depending on how I construct my command interpreter, one could imagine constructing arbitrarily powerful scripts like “keep wandering until you see a monster, and attack it as long as it’s 3 or more levels below me and I’m above half health.” Great, so now we can level grind while at work, and reap the benefits when we log on in the evening without having to resort to Gold Farming.
So let’s look at one more problem that plagues any natural language interface, and especially text adventure games of this era — the Synonym Problem (or as my 5 year old says, “Cinnamons” — so adorable). This problem can be best illustrated via an example.
Here the game only understands “take”, but the player (quite reasonably) doesn’t know this and is having difficulty finding the correct command:
look
> You see a dagger on the ground
get dagger
> I don’t understand that
grab dagger
> I don’t understand that
Just let me have the %$!#@ dagger!
> I don’t understand that
In this example “get”, “grab” and “take” all seem like very reasonable commands that a game should understand. Since we’ve implemented each command as a method, it stands to reason that we could simply try to anticipate all of the terms that a player might come up with and implement each one as a method that calls the main “take” method. But that’s not very Groovy.
In Groovy, if a method is called that doesn’t exist, “methodMissing” is called to give the class a chance to do something about it.
def methodMissing(String name, args) {
if (['grab', 'hold', 'yoink'].contains(name)) {
this.take(args[0])
}
}
Here we override methodMissing and attempt to match the unknown command with a list of known synonyms. For illustrative purposes it’s implemented as a static list, but one could just as easily imagine dynamically looking the command up in a thesaurus – this is happening at runtime after all. This little change makes for a happier player:
look
> You see a dagger on the ground
grab dagger
> You take the dagger
You’re darn right I do!
> I don’t understand that
Better still, if we do find a match, we can graft the synonym onto the Game class as a new dynamic method since it stands to reason that if a player uses “grab” instead of “take” once, they will probably continue to do so, so we might as well make it a method. Incidentally this is how GORM works with finder methods, or so I’ve been told.
def methodMissing(String name, args) {
def funcName = ThesaurusLookup.contains(name)
if (funcName) {
Game.metaClass."$name" = { item ->
this."$funcName"(item)
}
this."$name"(args[0])
}
}
Here all the new found method does is forward to whatever the program-sanctioned method was supposed to be. We can do this through the power of Groovy’s ExpandoMetaClass, which every Groovy class has.
So if we take a step back here, we can see how far some of Groovy’s language features have been able to take us. Here’s the original Java version that we started with:
game.go("north");
game.look();
game.take("dagger");
game.take("fish");
…and here’s the Groovy version that we ended with:
go north
look
take dagger
grab fish
I don’t advocate writing an actual game this way (for example, this way only supports “verb noun” commands), but as an experiment, it’s interesting to see how far we can go without writing any sort of lexer or parser.
Some Great Gr8 Conference Follow-up
Thursday, May 21st, 2009
There have been some great blog posts over at groovyblogs reporting on the sessions at this week’s Gr8 Conference, the Groovy/Grails/Griffon conference held in Denmark.
Among the standouts are an excellent write-up on what’s new in Groovy 1.6 and a summary of a session titled “Groovy Usage Patterns“, both by Peter Bell (the write-ups, not the sessions).
Peter also has a summary on “What’s Changed in Grails 1.1” with a notable section on standalone GORM (something I’ve not been able to get to work yet).
Conspicuously absent though, is significant coverage devoted to Griffon, which is unfortunate since I think this Swing/Grails-like framework has all of the right ideas.
Groovy Map Quiz Redux
Monday, May 11th, 2009
What will the following code fragment print?
def bar = 1
def foo = "a ${bar}"
def map = [:]
map[foo] = "val"
println map.containsKey(foo)
If, like me, you answered “true”, then you may want to read the rest of this post to be spared from spending more time than I care to admit figuring out why, in fact, it prints “false”.
It turns out that the culprit here involves using a GString as the key, which in and of itself it’s a problem, but it does cause some map methods (notably “containsKey” in this case) to behave not-as-expected. The reasoning behind this behavior (including why it won’t be fixed and proposed workarounds) is summed up in this bug report.
One of the proposed workarounds is to force early String conversion of the GString like so:
println map.containsKey(foo.toString())
But rather than having to remember to avoid “containsKey” in the presence of GStrings, I prefer to exploit the fact that Groovy “if” statements will return false if the test expression is null, as in:
if (map[foo])...
Of course this would only be equivalent to “containsKey” if you refrain from mapping to null values.
Property Access with Groovy Maps
Friday, May 8th, 2009
Here’s a quick Groovy quiz. What will the following code fragment print?
def map = [:]
def key = "abc"
map.put(key, "val")
println map.key
If you guessed that it will print “val”, then welcome to the Tripped Up By Groovy Map Property Access Club, members: you and me.
The above will actually print “null”, since the property access notation for maps will treat the “property” as a String, not a variable. So the above is equivalent to:
println map."key"
which, put in that light, clears things up considerably. Given this we can see that
println map."abc"
will indeed give us “val”. If you really, really wanted to use property style access using identifiers, you could do this:
println map."${key}"
but that’s all shades of ugly, so you’re better off just sticking to the “array style” access:
println map[key]
One more quiz. What will this print?
def key = "abc" def map = [key:"val"]
println map[key]
Since I’m no longer using that property style access, you might be tempted to think that it prints “val”. This, however, will also print “null”. The reason is that when maps are initialized like the above, the keys are treated as Strings. So this:
def map = [key:"val"]
is equivalent to:
def map = ["key":"val"]
If you want to store the value of “key” as the key, then you need to enclose it in parenthesis:
def map = [(key):"val"]
With this change the above code fragment will now indeed print “val”.
TDD: It’s Not Just For Zealots
Monday, March 16th, 2009
TDD (Test Driven Design/Development) is the practice of writing tests before writing the thing that will be tested. I’ve been simultaneously interested and suspicious of this way of writing software, trying to decide if the assumed rise in quality of the software could outweigh the dictatorial approach to writing tests (a testocracy)?
A convenient opportunity to try out TDD presented itself recently in the form of helping out on a Grails project. TDD’s autocratic approach to testing seemed like a good fit in this situation since, while I was no stranger to Groovy, this would be my first real foray into Grails.
In an effort to get up to speed in the application, and even Grails to some extent, I ended up writing 20 or so tests in the general area that I would need to be working in just to verify my assumptions of how the application was supposed to work.
When it came time to implement the feature, in true TDD fashion, I first asked myself, “how will I test this?” — that is, I wanted an exit strategy before I even started to think about how to implement the feature. In other words, how would I know when I was done?
So I wrote several more tests, and I was immediately confronted with the overzealousness of TDD: I had failing tests that would remain angry and contemptuous toward me until I implemented the feature sufficiently enough to get them to pass. But once that last test passed, I had a surprisingly satisfying feeling as I pushed away the keyboard and said to myself, “I guess I’m done”.
I have friends who practice TDD full time on a much larger project and it really seems to work for them. While I think TDD worked well for me in the situation, I still remain skeptical of it in larger settings — or for larger amounts of time.
My primary issue with TDD stems from my inability to think about two things at once: am I writing tests, or am I writing software? If I’m constantly thinking “how would I test this?” then I’m not thinking about what I’m even supposed to be doing. Often I need to burst out and write some code, try some experiments, refactor it, experiment some more, throw it away and start again, etc.
It’s not uncommon, during this process, to realize that the tests are now wrong or otherwise obsolete, and now I have to make the internal context switch to nurse them back to health, breaking the flow of what I was otherwise doing.
It makes more sense, I think, as a general rule of development, to test after things have stabilized.
I imagine tests being all these little yipping puppies nipping at the cuff of my pants when I’m trying to walk. Sure they’re cute and all, but sometimes I just want to walk at a brisk pace and these damn puppies are getting in my way!
Groovy Talk at UniForum
Monday, February 23rd, 2009
Tomorrow (Tuesday) I’m going to be giving my “Building DSLs with Groovy” talk at the UniForum group at IIT’s campus out in Wheaton Illinois. I imagine that the talk is only open to UniForum members, but it looks like you can become a member simply by attending a meeting (and paying the fee).
So if you live in the north western outer rim of the Chicagoland area and are curious about Groovy, come and check it out.
Update: The slides from the presentation can be found here for anyone interested.
Why I Like Grails
Thursday, February 19th, 2009
I’ve always been a fan of glass mugs. In addition to being able to see what I’m drinking, I prefer their smooth feel to that of standard ceramic. Recently however, a friend turned me onto grails. On the surface, it would seem that grails are a throwback from an era long past, but there is something to be said about drinking from the satisfying heft of a jewel encrusted grail made of bronze that helps me get in touch with my northern Germanic roots.
I especially like drinking out of grails when working with the Groovy web framework, Grails (no relation). As a side note, here are a few reasons I like Grails (the web framework):
I get to work with Groovy all day
I had been working with Groovy for about a year before coming to Grails (that is, the web framework — I was still drinking out of glass mugs at the time) in the context of a Java desktop application. There was a lot of “split brain” development with about 30% Groovy and the rest Java. It was always a painful context switch back to Java from Groovy, consoled only by the IDE’s superior compiler support (”There, there, look on the bright side: I can look up your methods for you again. By the way, you need to catch this exception and you forgot your semis).
Grails is 100% Groovy though — config files and all. In fact, I wish they would have taken this further with the gsp syntax, but I guess you’re not really web programming unless you have those god forsaken tags somewhere in your application.
It hides scary things from me
I’ve been actively avoiding using Spring in projects due to sheer intimidation, which can be summed up in the following exchange:
Coworker: Are you using Spring on your project?
me: You mean the Dependency Injection framework? We’re just using Google Guice–
Coworker: Oh but Spring is so much more than that — it also handles security and transaction control, and aspects, and it has a small island off the coast of Haiti, and it’s currency is the Spring Buck, and on clear nights if you quiet your mind, you can hear its song…
I’m told that Grails uses Spring behind the scenes, but I don’t have to know about it, which is the way it should be.
Testing is very easy less hard
There is this tension with regard to testing out there where on the one hand there is the Public Face of Software Engineering, which includes every software book I’ve ever read or speaker I’ve ever listened to, that says that testing is very important and that you should unit test all your code.
Then on the other hand there is my primary experience of the dozen or so projects that I’ve been a part of over the last decade plus in which testing was always (at best) an afterthought, and even when we did set out with the best intentions, with our TDD hats on, a project always degenerates to the point where if we achieved 30% coverage we were feeling pretty smug about ourselves.
So the short of it is: regardless of what they tell you, testing is hard.
With Grails though, testing is…less hard. Tests are auto generated, and neatly stubbed out in their “unit” vs “integration” buckets just begging for some love. The great thing though is that, unlike my previous experience with writing tests, I don’t have to pretend that I’m not using a real database, or making a real HttpRequest. All that stuff is mocked out, which I realize you can do for any type of system, but the true gem is that I don’t have to set it up.
The testing is actually so effortless, that it actually encourages me to think about better design in that I will gladly refactor, say controller logic out into a service if it means a cleaner test.
I should also say at this point that while I’ve been drinking out of grails for a few months now, I’ve only been on a Grails project for a week, so these initial impressions may seem naive to the seasoned veteran. Nevertheless, I give grails a thumbs up — just avoid the ones lined with lead.
Recent Posts
Archives
I’m Literate!
'to-read':
Tags
Categories
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « May | ||||||
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | |||