Gource

Gource is a software version control visualization program with support for Git, Mercurial, and with a tiny bit of extra effort, CVS and Subversion. It’s available as a macport install, as is the ffmpeg program used to stitch together a series of screenshots into the final video.  All of these visualizations were created with Git or Git-svn. When the Gource program is running it brings up an interactive window so you can interact with it to a degree, affecting the camera, zoom, etc.  The default resolution is 1024×768 but I tried to bump it up to 1920×1080. I’m assuming that stretched the limits of the rendering, as there’s quite a bit of pixellation in the final product; either that or the ffmpeg params need to be tweaked. The three visualizations on this page were all created using this one-liner command line invocation (broken down here over several lines for readability).

gource -1920x1080 --highlight-all-users --bloom-intensity .3 -a 1 -s .01
     --hide-dirnames --hide-filenames --stop-at-end --output-ppm-stream -
     | ffmpeg -y -b 3000K -r 60 -f image2pipe -vcodec ppm -i -
     -vcodec libx264 -vpre default  gource.mp4

Groovy

From the initial commit on August 28, 2003, Groovy has come a long way. I tried the Gource provided python script to translate an svn log file into the required format the first time, but cloning the repository with git-svn seemed to produce better results. It’s interesting to see that the overall structure of the Groovy project doesn’t look like is has changed very much over the years. I recognized a lot of the names you see on the screen. Be sure to watch the 1080p version if you’re having trouble reading the text and see if you can’t find some recognizable committers.

Click here to view the embedded video.

Grails

Starting on Sunday March 14, 2004 here’s how it all unfolded, at least from the perspective of the public Git repository. Grails looks like it grew a little more spontaneously than Groovy; there are more frequent restructurings and some transitions that seem to cover a whole lot of ground in very little time. In particular watch out for the burst of activity in the summer of 2009.

Click here to view the embedded video.

Griffon

September 17, 2008 marks the first commit for Griffon and this short but sweet video explodes right from the start. Benefiting greatly from the Grails model this project shows a lot of progress in a very short time indeed. Most, if not all, of the names you see here you probably caught in the previous two videos as well.

Click here to view the embedded video.

What’s the Point?

Watching these gives me (and maybe you) some appreciation for how much effort over time it takes to bring a new language/framework/technology to maturity and all of the individual contributions that go into it. Gource provides a lot more detail into the actual structure if you want to dig in. For purposes of keeping these images fairly uncluttered I removed file and directory names and just focused on the committers and the general structure. I think I gained a git of insight into how a codebase can evolve, and properly appreciate that organizing the increasing complexity of an ever-growing system over time is not a simple job. Plus they look cool. Enjoy!

Tweet This Post

Related posts:

1. Bamboo, Grails and Git for Continuous Integration
2. A Grails App Demoing the StackExchange API
3. VIJUG Griffon/Groovy Presentation

Since neither Grails nor Git are by default supported by Bamboo, I grabbed a couple of plugins to enable my home continuous integration system. Bamboo has a very sensible plugin model that allows for adding new capabilites with only a jar file in the right place and a server restart, and a fairly rich library of plugins. It’s also encouraging to see a company that is committed to eating their own dog food – recently they’ve moved their plugin resources to Jira studio as you can see on the Grails plugin home page. This gives you as the consumer of the software access to the wiki’d documentation, any open issues, and even visibility into when source code changes are committed. I’m assuming that last is subject to whether or not the plugin source code is open source or not, but still – pretty nifty.

The Grails plugin instructions speak for themselves in the 3 screen-shots on the one and only wiki page. Anything else you need to know is summarized in a one liner on the “Builder” tab when you select the Grails builder: “Use a new line to seperate Grails commands.” Gotta love clear, simple instructions. Drop the plugin jar into $BAMBOO_INSTALL_DIR/webapp/WEB-INF/lib, restart Bamboo and configure a new builder for Grails. Took a couple of minutes and knowing where my Grails install was located.

A quick Google for “Bamboo git plugin” led to a bit of a hypertext chase that eventually ended up here. Looks like this particular plugin has passed through the hands of at least a couple of maintainers, but so far it’s worked exactly as advertised. And again, loving the dog food analogy, it’s nice to see a project enabling Git hosted on github. Thanks very much to Kristian Rosenvold for running with the ball on this one! Again, drop the jar into $BAMBOO_INSTALL_DIR/webapp/WEB-INF/lib and restart Bamboo. When creating a plan you will now have Git as a choice for a Source Repository. In my case I’m just using a plain file repository that resides on the build box, but it should work just as well with a remote repository.

Setting up the Grails targets is similarly straightforward. Thanks to this article, which describes the Grails setup on Hudson, and reminded me about the –non-interactive flag since obviously the build server isn’t going to be able to interact with the console. I’m also using a couple of Grails plugins to provide static source code analysis so my parameters also include -coverage and a call to the codenarc script.

I had a little trepidation about how this would all turn out after reading this blog post, but I’ve had much better results so far in my personal experience. It’s entirely possible that the key differentiator is wrapping Grails with Maven. It’s definitely not perfect, but it is getting better all the time. Hopefully you have better luck in the future Neil!

[Show as slideshow]

[View with PicLens]

Tweet This Post

Related posts:

1. Gource Visualizations of the Groovy/Grails/Griffon Projects
2. Jira Grails Plugin
3. Developing Faster with the Atlassian IntelliJ Connector

A DataProvider method in TestNG can return either a two dimensional Object array or an Iterator over each of the test parameters. A consumer of that method will be triggered once time for each set of parameters from the provider. Parameters are injected into the consumer method at execution time.
This greatly eases testing various expectations that run through essentially the same path of execution.

Here’s the simple method under test, courtesy of this example on Groovy Almanac

    /**
     * Use the Groovy added List.inject() method to sum a list of numbers.
     */
    def sum(list)
    {
        def sum = list.inject(0) { sum, item -> sum + item }
    }

And here’s the corresponding DataProvider test harness. The test is injected with a List of numbers to sum and the associated total expected for each case.

    @DataProvider (name = "test1")
    public Object[][] createListInjectSumData() {
        def array = new Object[3][]
        array[0] = [[1, 2, 3], 6] as Object[]
        array[1] = [[2, 4, 6], 12] as Object[]
        array[2] = [[3, 6, 9], 18] as Object[]
        return array
    }

    @Test (dataProvider = "test1")
    void testListInjectSummation(list, expectedSum) {
        Assert.assertEquals(new ListInjectExample().sum(list), expectedSum)
    }

I’ve put the maven project I used to demo this up on github here. Mostly just because I’m having a great time using Git lately.

Tweet This Post

Related posts:

1. Achieving Groovy-like Fluency in Java with Google Collections
2. Different Flavors of Embedded Groovy in Java Apps or “How To Make your Java Groovier!”
3. Breaking Weak CAPTCHA in… slightly more than 26 Lines of Groovy Code