Last year I posted a fairly comprehensive series of articles on the blog (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11) summarizing the content from Gr8 in Copenhagen. This year I opted instead to write an article for the May edition of GroovyMag which is now available. In addition to summarizing the sessions, it also includes interviews with the organizers and any of the speakers I was able to meet up with at the end of the conference.
The issue also includes a piece on contract oriented programming by Andre Steingress, Hamlet D’Arcy continuing his series on Lean development using Groovy, Bjoern Wilmsmann on Natural Language Processing in Groovy, a detailed look at Java Strings in Groovy by Kirsten Schwark and Dave Kleins regular plugin corner reminding us of the power of the Quartz plugin.
Why not check it out? If you’re a subscriber, just download your copy. If not, why not give it a shot for just $5? If you’re really not sure, use the code “peterbell” and you can get one issue for free to try it out. I really like that we have a monthly magazine specifically for the Groovy community that is more timely than books, but better curated and more in-depth than most blog postings. Let’s support it so it continues to grow and become an increasingly valuable resource for the community as we grow.
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!
It’s tough. Keeping up with a framework (Grails) on top of a fairly new, quickly evolving language (Groovy) which in turn is built using evolving frameworks (Hibernate, Spring, SiteMesh and via plugins Quartz, Lucene and many others) in a language – Java – which continues to develop (if only at a glacial pace). I notice on the mailing lists that even the top luminaries in the field are occasionally flummoxed by a question. It’s just not possible to know absolutely everything about Groovy and Grails. The good news is that while an individual may not know everything, as a community we know a lot more. The mailing lists are a good resource, but as the community grows you don’t always get an answer to your questions on the lists. What to do?
The answer for me is to do what I’ve done in every other domain I’ve been involved with – get involved with the community. (I’m relatively new to Groovy and Grails, but I’m pretty involved in the Domain Specific Modeling and ColdFusion communities). Helping out on the mailing lists and contributing to plugins is a great way to get started, but it’s hard to beat the face to face interactions you get at user groups and (especially) at conferences. That’s why I decided to go to gr8 in the US, am presenting on DSLs in Sydney, New York and (hopefully) London this month, and will be attending gr8 in Copenhagen next month (even though I can only manage a day as I’m presenting at the BCS SPA conference on DSL design on the Wednesday).
I was lucky enough to attend Gr8 last year. It was an amazing chance to get to know many of the key developers in the community, to build up a set of resources so that if we do ever get stuck on a technical challenge we can get on IM and often get an answer or idea from someone in minutes instead of hours or days of futzing around. Why do I mention this? Well, Gr8 conference is the only dedicated Groovy and Grails conference in Europe and a great opportunity to learn about a whole range of projects within the Groovy ecosystem – including Grails, Griffon, Spock, Gradle and Gaelyk. More than that, it’s a chance to meet up with other developers dealing with the same adoption, implementation and technical challenges that you work with every time you develop a Groovy based project.
There is still time to register for the conference, so think about how much it costs when you’re stuck on a project for a day trying to figure things out, and I hope you can get a cheap flight, a modest hotel and a ticket to the conference into the budget. It’s not cheap, especially with the market right now, but the only thing more expensive than going to the conference? Working on a project in Groovy/Grails and being stuck *not* having gone to the conference for the amazing technical content and great networking.
Hope to see you there! (If you see me, please say “hi”) – I’ll be the jetlagged one drinking too much Red Bull
Last week I attended the excellent inaugural gr8 in the US in Minneapolis (look for a review in the May edition of GroovyMag). This week I’m back in MN presenting at a ColdFusion conference on agile development and productive work practices.
in May, my Grails world tour begins! First stop, a presentation for the Sydney Groovy group on Tuesday May 4th while I’m down to present at WebDU. The week after I’ll be presenting in New York on Tuesday May 11th, and the week after I’ll hopefully be either attending or presenting at the London Groovy/Grails Usergroup – probably on Monday 17th. I’ll be presenting on DSL design and the Eclipse Modeling Framework that week at the British Computer Society Software Practices Advancement conference, before flying off for a day to the awesome Gr8 conference in Copenhagen (I’d love to attend both days, but am presenting at SPA on the Wednesday in London). Then back to London for another ColdFusion conference presentation (I love *all* dynamic languages on the JVM!) before returning briefly to chillax in New York (my home base) for a while. Back to the UK in June to present on Spring Roo at Code Generation 2010.
I’ve been doing work on domain specific modeling, DSL’s and software product lines for a while, but I’m really excited to finally be porting a lot of my SPL functionality on to the Grails framework. It’s an excellent stack with a really exciting community and I can’t wait to meet more Groovy and Grails developers around the world in the next few weeks. So, if you’re in Sydney, New York or London (or are going to gr8.eu), please say “hi” to the slightly jetlagged guy with a strange English/US accent – I’d love to learn from you all!
As to the preso’s, I’m focusing on practical DSL design. Guillaume Laforge does a great job of presenting on the syntax of DSLs, but there are a bunch of other issues to consider when designing, developing, testing, maintaining and evolving DSLs and I’m looking forward to presenting more information on that as it relates to Groovy and Grails as I continue to get more familiar with the stack.
(Hopefully) see you somewhere!
I’m really looking forward to attending the gr8 conference in Minneapolis this Friday. I have been doing more and more Groovy and Grails projects recently and am looking forward to get to know the broader US community (the Copenhagen conference last year was great – but there weren’t that many US attendees).
I’ll be writing an article for Groovy Mag on the conference, so if you are presenting and would like to be interviewed briefly, I’ll be in the conference hotel Thursday evening and all day Friday (I’m flying back to NYC first thing Saturday) so make yourself known (a tweet to @peterbell is probably the easiest option) and I look forward to meeting you!
On Tuesday of this week I gave a short presentation to the New York Groovy/Grails Meetup, summarizing some of the content from the Gr8 conference earlier this year in Copenhagen. Numan Salati then gave a great presentation looking at various metaprogramming techniques in Groovy and Grails. The slides are now available online.
So, you’ve got git installed, you have created (or cloned someone elses) repository, and you have done an initial commit of a couple of files. What are the day to day commands you’ll need to use on a regular basis? This posting looks through some common tasks and how to accomplish them simply using git. It’s not focused on some of the cooler features in git – just getting you passably productive in as few commands as possible.
Create a Branch
Before you do almost anything to a live project, you’re going to want to start to create a branch. By default you’re on “master” (which is similar to the “trunk” convention in subversion). Unless you’re just doing a quick patch that needs to be tested and deployed immediately (e.g. a quick bug fix for the production server) you’re going to want to create a branch for your work. That way if you *do* need to move to another story, you’ll be able to put aside the code you are working on in a branch and to return it easily. It also means that master will always be deployable. If you ever make changes to master, master then becomes unavailable for deployment until you’ve finished and tested your work, so a 5 minute patch might take a week to deliver if you have a bunch of half finished code in master.
Lets say we want to implement a “user authentication” story for our site. We’d start by creating a branch: “git branch user-authentication”. We’ve now created a branch called “user-authentication”. Type “git branch” and you’ll see there are now two branches – master and user-authentication. You’ll see from the * next to master that while we have created a user-authentication branch, we haven’t switched to it yet (the * denotes which branch you are currently in).
So, the next step is to “git checkout user-authentication” and both a “git branch” and “git status” will show (in their own ways) that you are on the user-authentication branch. Lets add a new file – login.txt that relates to user=authentication, then “git add .” and “git commit -m ‘added login notes’”.
Now we have a branch with an extra file. Imagine you now need to make a quick patch to master and deploy it. All you do is “git checkout master” and you’ll see the login.txt is gone. Now imagine that was a bunch of changes to your core code that would have broken your unit tests/website. Now we can make a tweak to our master branch, deploy from that and then simply “git checkout user-authentication” to get back to the user-authentication story.
You’ve done a little more work on the user-authentication story and you want to capture all of the changes so you can revert to this point. Simply “git add .” and then “git commit -m ‘meaningful commit message’” and you’re done. With git you can afford to commit changes really often as later you’ll be able to use the rebase command to collapse down the number of commit messages (although we’re not going to cover that in this 101 tutorial). If in doubt, commit. Note that if all you are doing is editing existing files, you can just collapse down the two commands to a single “git commit -a -m ‘commit message’” (note the “-a” flag), but that won’t pick up any untracked files, so if in doubt, just do both steps. (Some UI based tools like the git commands in TextMate will automatically handle the git add as part of the commit.)
Ugh. We’re still on the user authentication story. We have done a lot of work and committed regularly, but since the last commit we tried some different things and they weren’t very good. Worse, we can’t remember how to get the code back to the last commit which was working (although not complete). It’s time to roll back to an earlier commit (it’s git and commits are cheap and easy, so you might be a couple of commits into this path). If you “git log” you’ll see a list of previous commits – each of which has a GUID like df9e8fd2a1d3769e42012a29f0ac4b56f6053a62. Lets say we wanted to revert back to the commit with that GUID. All we do is “git reset df9e8″ (note that we just needed a few characters – enough to uniquely identify the element) and it reverts to the status of the branch at that time, allowing you to get back to a known good state and to try something else.
Of course, if you’re doing something experimental, you might just want to create a branch – “git branch user-authentication-experimental-login” and then “git checkout user-authentication-experimental-login” so if it doesn’t work you can just “git checkout user-authentication” and then delete the experimental branch using “git branch -d user-authentication-experimental-login” (if the branch wasn’t a child of the current branch you’ll need -D, not -d).
Merging a Branch to Master
OK, so we’re finally happy with our new user-authentication branch. Let’s merge it into master. From the user-authentication branch we’re going to “git checkout master” to get back to the master and then “git merge user-authentication” to merge the user authentication branch into the master.
Tagging a Release
Often there will be special points you want to tag – such as production releases. When you want to create a tag, just type “git tag release1″ (where release1 is the name you want to give it), and then to revert to that tagged point at any time, you can just “git checkout release1″.
Pushing Your Changes
If this is a shared project, you may want to upload your files to Unfuddkle or github. Depending on exactly how your project is setup this may well be as simple as just typing “git push”, which will update all branches on the remote location with those from your local copy.
There is a lot more you can do with git. The default documentation is at
, although there are also many other tutorials available. Any feedback or questions appreciated!