Groovy Sydney – September Meeting

Last Wednesday we had our first Groovy user group meeting in Sydney. It was well attended by both external participants and ThoughtWorks developers.

The evening began with a social gathering around pizza and beer. Then we went straight into the presentations. I presented an introduction to Grails. The purpose of my presentation was to raise awareness of a Groovy web application framework, and to become familiar with the command line Grails tool. I was wanting to present a demo as well, but couldn’t for the life of me get my Ubuntu laptop connected to the data projector with a reasonable resolution for a coding demo.

Gianny Damour also gave a presentation after mine on Closures in Groovy. It was quite an advanced presentation on Groovy closures which challenged many people in the room. Gianny introduced us to the concept of builders using Groovy closures, which in term provides the building blocks for developing DSLs in Groovy. More on this topic will no doubt come about in future Groovy meetings.

Gianny did plan to hold a code kata after the presentations so that everyone could get their hands dirty with Groovy, but given it was our first meeting, most people felt uncomfortable with writing code and just wanted to discuss technical topics. This led us to rethink the format of future Groovy meetings. We will still have at least 2 lightning talks, followed by either a third talk or a coding workshop depending on volunteer contributions.

The highlight of the night was having the Groovy meeting hijacked by David Peterson who talked about Buildr, a Ruby build tool for Java projects. Damn Ruby folk are everywhere! :p

The next meeting will be held on 29 October at the ThoughtWorks office in Sydney. The theme of the next meeting will be Groovy for Java developers. If you are interested in presenting on Groovy, Gant, Gradle, EasyB, then please get in contact with me, or post your presentation topics in Groovy Sydney Google group.

Firefox 3 work offline work around on Ubuntu

Found a work around that prevents Firefox 3 from enabling work offline when you are using a USB modem or in my case an iBurst pcmcia modem.

The fix originally posted here requires you to open the Network Manager configuration file.

$ gksudo gedit /etc/dbus-1/system.d/NetworkManager.conf

Then replace <allow send_interface=”org.freedesktop.NetworkManager”/> with <deny send_interface=”org.freedesktop.NetworkManager”/>.

After saving the changes, restart your machine.

Switching from Subversion to Git

I got bored of Subversion and decided to move my subversion repository over to Git. It was actually quite simple if you use git-svn.

The first thing you need to do is set up your git repository on the server. So log into your server and enter the following command to create an empty git repository for your application called “appname” (replace appname with the name of your application).

$ mkdir -p ~/git
$ mkdir -p ~/git/<strong>appname</strong>.git
$ cd ~/git/appname.git
$ git --bare init

Now on your local machine you will need to use the git-svn tool to clone your subversion repository as a local git repository, then push your local repository to the master branch on your server. So on your local machine enter the following on the command line (I’m assuming you are using Ubuntu Linux, naturall). Replace svn_repo_url with the actual url of your svn repository. Replace username with your actual username on the server. Replace local_appname with the name of your application.

$ sudo apt-get install git-svn
$ mkdir projects
$ cd projects
$ git svn clone <strong>svn_repo_url</strong> <strong>local_appname</strong>
$ cd local_appname
$ git remote add origin <strong>username</strong>@<strong>domainname</strong>.com:/home/<strong>username</strong>/git/<strong>appname</strong>.git
$ git push origin master

Switching to Git is as easy as that!

Javascript debugger for Safari

My day to day web browser is Firefox, and the best plugin for developing web applications with Firefox has got to be Firebug. Firebug allows you to inspect the CSS style for any element in the page, navigate the DOM, and debug your javascripts. Firebug is tied to Firefox but you can get some basic Firebug functionality for all browsers with Firebug Lite.

What if you want to debug javascript that just doesn’t seem to work for Safari? Well Safari doesn’t have a javascript debugger just yet, but its open source development shapshot WebKit does. To use it you first need to download WebKit. Then go to Safari -> Preferences -> Advanced, and check the checkbox that says “Show Develop menu in menu bar”.

Next time you run WebKit you will have access to the Web Inspector tool located in the Develop menu.

Dabbling with Groovy

I am currently implementing a Bayesian document classifier in Groovy and I have to say that I am really enjoying the language. As far as dynamic languages go, Groovy has all the bells and whistles, such as closures, meta-programming, and dynamic typing. The language has a familiar feel for Java developers, yet has the features to accommodate developers that know Ruby, Python, or Perl.

Furthermore, Groovy and Grails have excellent tool support with IntelliJ IDEA. I cannot recommend that IDE enough. Auto-completion, code navigation, syntax highlighting, and more importantly refactoring all work as expected. This is something that I have found lacking with IDEs for other dynamic languages like Ruby and Python. Yes, I know there is a Ruby plugin for IntelliJ IDEA, but it still isn’t as good as the Groovy plugin!

Ok, enough of the sales pitch, lets see some code for the document classifier that I am building. The following Feature class contains a method for extracting a set of features from a document. The document is simply a string of text, and the features are all unique words that have three letters or more. So words like [I, a, be, is] will be ignored, and words like [alpha, bravo, charlie] will be identified as features. If we begin with a test, our expectations will look like the following.

class FeatureServiceTests extends GroovyTestCase {

    void testShouldExtractFeatureFromDocument() {
        def sampleDocument = "Groovy is really groovy man."
        def service = new FeatureService()
        def feature = service.getFeature(sampleDocument)
        def expectedFeature = ["groovy", "really", "man"]

        assertEquals(expectedFeature, feature)
    }
}

The test implies that only words that are unique and have more than three characters within a given document will be extracted as a set of lowercase words. This is a utility method for extracting features that can be used to determine their probability of occurring within a document that belongs to a specific category of documents. Since I am implementing this document classifier in Grails, I am using the convention of naming the feature utility class as a service. The implementation of FeatureService is as follows.

class FeatureService {

    boolean transactional = true

    def getFeature(String doc) {
        def feature = []
        def words = doc.split(/\W/)*.toLowerCase().unique()
        words.each {word ->
            if (word.size() >= 3) {
                feature << word
            }
        }
        return feature
    }
}

Walking through the code, line 1 defines the class name. Kind of standard, unless you come from Java, in which case there is no need to define the visibility of the class using public, etc. You can if you want, but the Groovy compiler will just ignore it.

Line 3 was generated by Grails. It contains a property called transactional.

Line 5 contains the method signature for getFeatures(). There is no need to state the return type of the method, but you can if you want.

Line 6 defines an empty list in which we’ll add features to when we find them.

Line 7 uses a regular expression to split the string into a list of words. All of the words are converted to lowercase, and only the unique set of words are kept. This line demonstrates Groovy’s ability to chain methods. The ‘*.” operator means apply the toLowerCase() method to each item in the list that is returned by the split operation.

Lines 8 to 12 show a closure that is being used to filter out words that are less than 3 characters in length. Only words that have 3 or more characters are added to the feature list using the left-shift operator (<<). This is where a Perl “unless” keyword would be useful in the Groovy language, as it would reduce the if statement to a single line. It would also read better, along the lines of “add word to feature list unless size of word is less than 3″. There is demand for this keyword, so we’ll just have to wait and see if it makes it into Groovy.

Finally, line 13 returns the feature list. You don’t need to provide a return statement in Groovy, but in this case it is necessary as the last variable in the method is returned by default. I prefer to explicitly state what the method returns, because doing otherwise could introduce unexpected behaviour into your code.

This code example is quite brief, but it should give you a taste of what Groovy has to offer.

Sydney Groovy Group

Today I decided to start up a special interest group for Groovy and Grails developers in Sydney. If you are interested in Groovy or would like to be a presenter then please join up at Groovy Sydney. You can register your Groovy talk on the Presentation Topics page, and I will organise for you to present at the next meeting. The Groovy Sydney group will meet on a monthly basis at the ThoughtWorks office, followed by drinks at a nearby pub.

Groovy is a dynamic language that I have been ignoring until now for no particular reason. I first heard about it when I was doing consulting work in Brisbane last year. One of the client developers of a large bankasurance company gave a pretty good presentation on Groovy. But back then I was ignorant and caught up in the Ruby on Rails hype.

The thing about Groovy that won me over was that you can start off by writing your code in Java, and then refactor to make your code groovier. It reduces the learning curve required to be productive in a new programming language, which I believe to be quite novel.

Groovy makes sense in the enterprise as it allows you to leverage your existing Java based systems. You can deploy a Groovy application in your expensive J2EE application servers, therefore maximising your return on investment in infrastructure costs. For example, Grails — a Rails-esque web application framework for Groovy — can be deployed as part of a Spring application. Essentially you can implement a lot of your integration business logic in Java, and use Grails to quickly create frontend CRUD functionality, which is tedious to do in Spring alone. Groovy is a tool worth having for any Java developer looking for productivity gains.

iBurst Driver doesn’t compile in Ubuntu Hardy Heron

Bah, just found out that the iBurst driver 1.3.2 doesn’t compile in Ubuntu Hardy Heron. Turns out a macro in the kernel called SET_MODULE_OWNER was deprecated in 2.6.23, and removed in 2.6.24. The iBurst driver currently depends on that macro, so I will have to look at patching it so that it can work for Hardy Heron, which uses the 2.6.24 kernel.

Update
The fix is quite simple. Just remove SET_MODULE_OWNER from ib-net.c, recompile and install.

Ubuntu 8.04 Hardy Heron

Sweet, the latest release of Ubuntu dubbed Hardy Heron is out!

Ubuntu Hardy Heron CD Cover
CD Cover art was created by MadsRH

There are a lot of new changes under the hood. Most notable are:

  • Installation is a breeze.
  • Wubi: one-click installer for Windows.
  • Xorg 7.3 with better defaults and auto-configuration of external screens.
  • Mozilla Firefox 3 Beta 5 in preparation for the official release of Firefox 3 in June.
  • PulseAudio: new audio driver.
  • Brasero: a new CD/DVD burning utility.
  • Transmission: the new default BitTorrent client.
  • New theme.
  • Compiz: Enabled by default for eye-candy.
  • Vinagre: New VNC client. Also uses Avahi to discover VNC enabled clients on the network.
  • PolicyKit: enhanced security.

I am currently in the process of migrating /home to its own partition so that I can go ahead and upgrade to Hardy Heron as soon as possible.

Python Decorators

I found this great post on Python Decorators. Decorators were introduced into the python language since 2.4. The post shows the benefits of using a python decorator to improve the efficiency of a function’s runtime using memoization.

Python decorators are also extensively used in Django for authentication. For example, you can use them to decorate a view function so that only logged in users can view certain parts of your site.

from django.contrib.auth.decorators import login_required

@login_required
def my_view(request):
    # ...

The example code above shows that you only need to add the @login_required decorator above your view function to determine whether or not the current user needs to be authenticated before the view can be displayed.