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!

Related posts:

1. Bamboo, Grails and Git for Continuous Integration
2. A Grails App Demoing the StackExchange API
3. Grails-UI DataTable using XML for a model

The slideware plugin provides a framework for creating presentations with a little twist – you can execute code live from the presentation software. If you’ve ever given a presentation about programming you probably are fully aware of the transition from presentation software to your preferred environment for demonstrating code samples. Well, now you can stay entirely within the same application, editing and running code live.

The plugin itself isn’t available from the Griffon repository but source code and a built 0.2 version can be found on github. Considering both the youth of the plugin and the beta status of the framework, it worked impressively well AND had a rich feature set. All of the expected “powerpoint” features are there: themes, layout control, styling, slide transitions and export are all pretty easy to incorporate and configure. The code editor view also works very well. A great variety of additional plugins are harnessed to put all the pieces together and as a result building one of these applications is a great way to tour the platform.

Theming

Applying a theme to the presentation is simply selecting a Java Look and Feel to apply in Initialize.groovy. The Substance jar is included with the plugin so I test drove a few of the nice setups in there and finally settled on the SubstanceMagmaLookAndFeel. There is definitely a wide variety of L&F’s to choose from in that bundle alone and, although I haven’t done it myself, they seem pretty tweakable as well. Plus any old L&F should plug in nicely, I would imagine.

//Initialize.groovy
SwingBuilder.lookAndFeel('org.jvnet.substance.skin.SubstanceMagmaLookAndFeel',
       'mac', 'nimbus', 'gtk', ['metal', [boldFonts: false]])

Layout

Controlling the page composition is a standard Swing Layout or, in the case of the default slide you get with the included “create-slide” script, a MigLayout. Framing the standard variety of slides is very simple. Bulleted pages, title slides, code slides and custom layouts are very easy to accomplish. I don’t have a lot of experience using this particular layout but the presentations Andres has made available on github have a good diversity of examples of how they look in practice.

//the default create-slide generated template
import net.miginfocom.swing.MigLayout

slide(id: "slide0", layout: new MigLayout("fill","[center]","[center]")) {
    label("Insert your text here")
}

Styling

Styling is supplied by the css plugin, on which slideware has a dependency. The default style.css file sets out just some reasonable defaults for the fonts used in different parts of the app, and I didn’t see any real need to fiddle with it. Especially happy to see the nice monospace code font. On a totally related note I recently installed the Inconsolata monospace font to try for development and I’ve been very happy seeing it in my editor, but it’s still nice to see this kind of polish applied to the presentation. The code editor view even includes syntax highlighting! More on that coming right up…

Slide Transitions

Moving between slides with style is the responsibility of the transitions plugin. You can see see all of the animations this plugin enables over here at this page describing Transitions and Transition2Ds. Pretty slick stuff and defined as simply as a parameter to each “slide” node in a script.

slide(id: "slide3", layout: new MigLayout("fill","3%[center]3%","3%[center]3%"),
        title: "Junit3",
        transition: new FlurryTransition2D(Transition2D.OUT)) {
    scrollPane(constraints: "grow") {
        widget(createEditor(text: script))
    }
}

Code Editor

Code slides embed an editable widget and allow for composing and executing Groovy scripts or classes of arbitrary complexity. You can execute the code with a keyboard shortcut and a window will open displaying the console output. The code itself is executed through a GroovyShell, enabling pretty much anything you might want to do. If you have an internet connection and the required repositories configured, Grapes simplifies packaging the dependencies for the application as your code samples can directly Grab the jars they need. Basically, the first time you execute a code slide you’ll have to put up with a small pause while Ivy downloads to your local repository, unless of course the required dependencies are already there. In my case I changed strategies from including jars in the application lib directory to a Grapes approach and I think it’s a better way to go.

I was surprised to find that the editor even included undo functionality. It’s definitely not close to a full blown IDE, and there’s absolutely no reason that it should be. For the task of demoing simple code examples it’s more than up to the task, even to the point of maintaining your edits between slide transitions, allowing you to move back and forth through the slide deck without any state problems.

Export

The application includes a “Print” feature which iterates through the entire slide deck and renders it to a pdf. Distribution of one of these presentations is really very easy, including the ability to create installers for all major platforms simply by adding the packaging plugin.

Test Application

The test app I built while looking into this is pretty simple. It’s got a title slide, a bullet slide and 4 code slides. The code simply demonstrates how you can create test classes and make assertions for Junit 3(with GroovyTestCase), Junit 4 and TestNG. GroovyShell recognizes all 3 of these test files by interface or annotation and executes them appropriately. In each case the console output of the test framework is the result, including the new Spock inspired ascii art assert failure renderings. The Test result files are also written to disk, and that TestNG html output is what I’m used to looking at anyhow. Show me the Green!

The last code slide is just a slightly updated version of an example script on the Grapes page, using the current version of Google Collections and intentionally introducing a failure- mostly just to show off that new assert rendering I mentioned a moment ago. VERY helpful at highlighting the exact nature of a failure. It also encourages me to pay more attention to how I name variables, something I’m sure every developer that has ever worked with me will cheer at. Man, I suck at naming things.

I also developed a brute force test that loads each slide and executes scripts if finds embedded there. Failures are hard to detect since the direct output is simply a text block, but some fairly simple regex’s applied to the output make me at least moderately confident that the code won’t fail at show time.

Overall Impression

It took a couple of afternoons(six hours or so total) to download the source code from github, explore it, create a simple presentation and document the experience. I won’t begin to suggest that I’m fully aware of all the details happening behind the scenes, but the end user experience is pretty fluid: create a slide, tailor the layout, add content and then repeat. The included examples were more than enough documentation on how to hit the ground running. The plugin code itself is a great example of the MVC nature of Griffon, not a whole lot of code, but a great deal of power and expressability. There were a couple of glitches happening in the background, mostly just logging to the console with no visible effect to the application, but overall it functioned as well as (not) advertised. For publicly unreleased software it was an absolute pleasure to work with and I plan on continuing with the development of this particular presentation.

Everything you need to build and run this stuff yourself is publicly available. In my case, Griffon generally has a recent Macport available for both the released(griffon @0.2.1) and development versions(griffon-devel @0.3-BETA-2). Switching versions is relatively painless and, for applications this simple, testing out upgrades is basically just going through the presentation once in a functional test. Versions for other platforms can be downloaded from the Griffon download page.

Deliverables

Source code for the sample application is available on github here. Please just leave a comment on this page if you have any problems running it.

Here’s the pdf produced by the application ‘Print’ feature: Groovy Testing Presentation (252)

And if you don’t feel like downloading anything, here’s how it all looks in pretty pictures.

[Show as slideshow]

[View with PicLens]

Related posts:

1. VIJUG Griffon/Groovy Presentation
2. Achieving Groovy-like Fluency in Java with Google Collections
3. Fun day playing with new Stuff

DISCLAIMER: yes, this is heavily geared towards(but not exclusive to) Groovy-esque sources. What can I say – it’s where I spend most of my time.

Google… in General

If you want to find something – well let’s just say any service that is so pervasive it becomes a verb in the language might be useful.  Learning how to harness the power of the Google architecture can greatly enhance your learning experience. And I can’t see myself Bing’ing anytime soon.

1. Google Search: Knowing and using the Google search syntax properly can be a very powerful tool for finding specific tech-geekie knowledge.
2. Google Reader: Listening to the right content can save you a lot of time when it comes to getting the most out of your code. Even if you don’t read it everyday, combined with Gears and searchability this provides another tool in the fight against techno-ignorance that doesn’t rely on an internet connection.
3. Google Mail: I combine mailing list subscriptions with filters to automatically organize content. Incoming messages from lists are archived and labeled accordingly by filter rules. With Gears installed I’ve got an off-line searchable database of grassroots questions and answers, similar to what an on-line service like MarkMail provides. It’s hard to be the ongoing discussion of community members sharing their best tips, tricks and gotchas.
4. Google code: A great place to find open source projects that can assist you at work and provide valuable  learning materials. And yes, the link targets Groovy .

Aggregators

Some kind people do most of the work for you – taking themed content and putting it all together in one place.

1. DZone: One of my favorite sources of  techie style news.
2. GroovyBlogs: A great example of ‘eating your own dog food’, this is a Grails powered site courtesy of one of the authors of Grails in Action. Most of the Groovy related blog articles I read come from this source.
3. Grails Tutorials: A nice collection of tutorial articles related to Grails and Groovy.
4. GR8Forums: Brand new, this site has the potential to be a great discussion spot.

Community Sharing

There are certain places that encourage community and knowledge sharing more than others.

1. Groovy Console in The Cloud: This is an amazing example of an application exposing a Groovy console on the Google AppEngine, complete with community support for running, saving and commenting example code.  Since the code is freely available, there’s also already a Spock console here in the cloud forked/cloned from it.
2. Github and Gists: More places to share code in project and/or snippet form.
3. StackOverflow: A community effort to put together almost 300,000(and rising) questions and answers related to programming. If you have a question to ask, head over here – chances are someone else has already given an answer. It really is impressive how well this still evolving site functions.
4. Podcasts: JavaPosse and the Grails podcast are on top of my list and usually get listened to during my commute to work.There are hundreds of tech related podcasts out there; pick one or two and give them a listen,  you won’t regret it.
5. mrhaki : OK, this guy gets special mention just for busting out code examples for pretty much every Groovy feature you can possibly imagine. Seriously the guy posts 20+ times a month on average.

Home Pages

These aren’t necessarily up to date at all times, but are great places to start looking for generalized knowledge and additional resource material.

1. Groovy: Pay particular attention to the ‘Cookbook Examples’ and the ‘Modules’ available to quickly add functionality.
2. Grails: A particularly rich and well organized site – with the latest update it’s also very pretty.
3. Griffon: The builder documentation linked from here, combined with the example scripts included with SwingPad, get you up to speed quickly on all of the buildery goodness available in Griffon.

Useful and Inspiring

These are resources I use to step out of the box and to remind myself that it’s not only in elegant code that geekiness lies.

1. Lifehacker: I get into trouble a lot for this one; in my house whenever someone asks me “How do I do {fill in the blank}?” I invariably respond with “Well what does Lifehacker say?” My personal favorite is the bundle wrapping method. With a nice mix of techie and common sense goodness, I love to follow this site.
2. Make magazine: In need of a DIY project to fill up the weekend? From the Minty Boost for a $20 portable USB charger to robots this place takes geeking out entirely to the next level.
3. Jonathon Coulton: With eye-popping geekiness, Jonathon brings us such wonderful classics as “Code Monkey” and “Re Your Brains” – and under a Creatives Commons license as well!

Twitter

Use with caution. More than any other source of data, this one can end up being seriously distracting. I’m careful about who I listen to, while simultaneously trying to remind myself that nobody cares what I had for breakfast or how much I enjoyed it. Have you tried Twitter yet? Not as easy as it sounds buster, believe you me. Just wait and see. If you can keep yourself from jumping every time a new Tweet lands at your desktop, this can be the freshest, fastest way to satisfy your tech cravings.

Books

OK, so these aren’t free, but if you want to jumpstart your knowledge on a particular piece of technology, software or framework, picking up a recent book on the subject can truly help. I try to add a new book to the library every month, but the hard part is really finding the time to read and apply the new knowledge.

I don’t expect that these suggestions are for everyone, but hopefully a few of you out there in the interwebs will find some of them helpful. And feel free to share what works for you if I’ve missed anything.

Related posts:

1. Gource Visualizations of the Groovy/Grails/Griffon Projects
2. A Grails App Demoing the StackExchange API
3. A One Day Griffon Application/Presentation

The venue was great – very nice that the Vancouver Island Tech Park is kind enough to host meetings. Next time I’ll have to come early enough to figure out how to make the projector do better than 800X600 resolution, however. Hard to show much other than a slide deck presentation with that little space. Then again I may be a little spoiled when my usual is 1920X1200.

I love using Keynote for presentations with the Apple infrared remote. Between the presenter view with notes to guide what I wanted to say(and to remind me when to step out and demo some code) and the timer to keep me on track, it went really pretty smooth. That’s my story, and I’m sticking to it. The software, both Griffon and Keynote, worked flawlessly so if things weren’t perfect, there’s only me to blame.

SwingPad seemed to make quite an impression, which is not hard to understand considering how little effort it takes to start showing results on the screen. Put that together with the recent CSSBuilder integration and the rich samples for other builders and I think more than a couple of Java developers will be installing it soon.

The question came up enough that I want to directly reference this blog post from Andres Almiray regarding GSQL in Griffon. Apparently people like to have databases handy at all times

And a big thanks to Andres for sharing two free copies of the upcoming Griffon In Action that he is co-authoring for raffle prizes tonite. Through the magic of Twitter he was very supportive about 20 seconds after the original announcement went out. Now if only they can kill all those nasty spam-bots, etc that are messing with my Twittiness!

I’ve uploaded the demonstration application at github. It shows a simple Griffon app with three tabs. The first is a minor port of Andres’ Trident/GfxBuilder example to show animation. The second is a simple demo of the @Bindable AST transformation along with the SwingBuilder syntax for accesing SwingUtilities; it comes along with an accompanying Fest test. The third requires an internet connection as it parses out the DZone rss feed and delivers it into a GlazedList, demonstrating usage of SwingWorker courtesy of the SwingXBuilder. I showed those samples along with installer plugin built versions of some of the included Griffon sample applications. WeatherWidget is a one fine looking translucent UI example!

Please ping me if you have any problems running this Griffon app, as I did trim out a bunch of the extraneous project files and test reports right before uploading. This was my first time ‘really’ using Git for source control so it’s bound to be a bit messy – nevertheless the Git experience has been great so far. I also tried to get the slides up on SlideShare, but that appears to… not be happening(been uploading now for over 20 minutes this time- about to kill it, again). So here’s the pdf.
Source code download here.

Slidedeck download here.

Related posts:

1. A One Day Griffon Application/Presentation
2. Griffon SwingX Fest testing
3. Presenting a Groovy/Griffon talk

It appeared on the JetBrains blogroll a couple of weeks ago, and indeed may have showed up in an earlier release, but today was the first time I saw it in action. I couldn’t find anything about this new feature mentioned explicitly in the release notes but sure enough, it’s there. Given the similar project structure between Grails and Griffon, and the first class Grails support already available in IntelliJ, it’s really not too hard to see how this platform is in an ideal position to expand Griffon support. Beyond that the general Groovy support seems to get better in every release. The EAP is free to try for any holder of an IntelliJ 8.x license and seems to be pretty stable despite the disclaimers – I highly recommend taking it for a spin, especially if you’re already using this IDE. You get properly configured source directories and dependency paths, access to Griffon’s command line scripts, and even that awesome new Griffon icon shown to mark out the project. What more could you ask for?

JetBrains was beaten to the punch by a NetBeans plugin for Griffon that was released in its initial version before this year’s Java One conference. I’m not a NetBeans user myself, but I am a frequent reader of Geertjan Wielenga’s blog – he’s published some great Groovy examples. Even the Eclipse community has finally gotten around to putting out some real Groovy support, largely due to SpringSource‘s commitment.

Hopefully their recent acquisition by VMWare won’t distract them from developing it too much

Regardless of which development environment you feel most comfortable with, there’s no questioning this is a great time to be a Groovy/Grails/Griffon developer so enjoy!

Related posts:

1. My Favorite IntelliJ Resources, Tips and Tricks
2. Developing Faster with the Atlassian IntelliJ Connector
3. A One Day Griffon Application/Presentation

No sooner had Manfred let loose a message on the Tweetosphere than Andres Almiray very graciously offered up some free copies of the upcoming book Griffon in Action to give away at the meeting. Thanks for that Andres!

The company I work for, Genologics, also gave me permission to publish a presentation that I gave recently at work as a Groovy primer for other members of the development staff. Thanks for that Cliff!

I demonstrated some code in SwingPad and created an application using a GMaven archetype to show off some of the sweetness that Groovy adds to the Java toolbox. It’s worth noting that even though that page doesn’t say it, GMaven recently released a 1.0 final verison(NICE!)

I’ve attached the presentation and some of the source code examples for anyone who might be interested, including the maven project that contains a variety of MOP, builder and GDK extension samples.

GroovyTalk

groovyDemo

SwingPad1

GroovyMailRoute

Prefusebuilder

SwingThreadingExample

Related posts:

1. VIJUG Griffon/Groovy Presentation
2. A One Day Griffon Application/Presentation
3. Achieving Groovy-like Fluency in Java with Google Collections

Since FEST allows you to alter the properties of the widgets directly, I didn’t have to do anything special to trigger actions on the JXColorSelectionButton. At first look, I thought that specifying mouse click point locations would be necessary, but after digging a(very little) bit I discoveregroovyd that FEST exposes the underlying Component its’ Fixture classes wrap as an internal ‘target’. Simply grabbing that Component and settings the background color directly was sufficient.
Here is the new definition of the JXBusyLabel and the 3 buttons which controls its color changes. You can see that two of the three color changes happen automagically due to Groovy binding – setting the background color of the label didn’t appear to work for some reason that I have yet to puzzle out, so it gets a PropertyChangeListener ‘old school style’.

baseColBtn = colorButton(name: 'baseColBtn', background: model.baseColor)
highColBtn = colorButton(name: 'highColBtn', background: model.busyColor)
backColBtn = colorButton(name: 'backColBtn', background: PaintUtils.BLUE_EXPERIENCE.getColor1())
backColBtn.addPropertyChangeListener("background", {PropertyChangeEvent evt ->
      label.setBackground((Color) evt.getNewValue())
      label.setOpaque(true)
} as PropertyChangeListener)

label = jxbusyLabel(name: 'busyLabel',
      preferredSize: new Dimension(model.W / 2 as int, model.H / 2 as int),
      busyPainter: busyPainter(
      highlightColor: bind { highColBtn.background }, baseColor: bind {baseColBtn.background},
      points: bind {slider.value}, trailLength: bind {tSlider.value}),
      opaque: false,
      horizontalAlignment: JLabel.CENTER,
      delay: bind {speedSlider.value},
      background: bind{backColBtn.background})

The three associated tests are essentially using the same recipe, so here’s just one of them to give you the idea.

 /**
 * Test that changing the 'baseColBtn' background color simultaneously
 * changes the busy label's base color.
 */
 @Test void testBaseColorChange() {
       startAnimation()
       def button = window.button('baseColBtn')
       def busyLabel = findBusyLabel()
       Color start = button.target.background
       Color busyStart = busyLabel.busyPainter.baseColor
       Assert.assertEquals(busyStart, start)

       button.target.background = Color.RED

       Assert.assertFalse(button.target.background == start)
       Assert.assertFalse(busyLabel.busyPainter.baseColor == busyStart)
       Assert.assertEquals(busyLabel.busyPainter.baseColor, Color.RED)
 }

Running the test suite takes less than a minute, and most of that time is spend dragging sliders. Those tests are presently going through the entire range of the slider, which is reassuring when actually watching the tests run, but probably overkill in terms of testing. Considering that, running the test suite is pretty painless and quick(the new tests execute in < 1s for instance). And of course the test results are available in the standard, pleasing, and hopefully all green, TestNG output. Which has, by the way, just announced another release thanks very much to its creator Cedric Beust.

I am still having some difficulties in responding to change events on the other sliders in the demo, but I think that I just need to decompose the parts into the MVC structure a little more coherently. In particular, when some sliders are moved, it should trigger some calculations and a repaint of the busy label to reflect the changes(not simple properties that can utilize binding directly). While the original code declares the method inline, I’ve moved it to the controller class and run into some circular dependency problems between the components referenced therein – Component A needs Component B but it hasn’t been instantiated yet in the view, etc. It looks like what is happening is that the change listener is being triggered once when it is assigned to the component, which might be a problem anywhere in Swing/Groovy/Griffon/my implementation. My money is on my own impl, mostly based on the common sense that when you’re writing code in an unfamiliar area you’re bound to meet problems that don’t immediately suggest a solution.

We’ll just have to keep digging and see.

[Show as slideshow]

[View with PicLens]

Related posts:

1. Griffon SwingX Fest testing
2. SwingX busy label demo in Griffon and Groovy
3. A One Day Griffon Application/Presentation

So the SwingX demo has 3 sliders that affect integer values on the JXBusyLabel. Using the Groovy ‘bind’ syntax, responding to changes in these events is simple to say the least.

And as promised in the last post, I’ve written some FEST tests to validate that everything is working as expected. Stay tuned to the end of the post to see a video of the running tests

FEST provides some convenience wrappers for UI elements that allows easy access to common operations. Looking up a JSlider in the UI for instance, returns a JSliderFixture object with a nice little ‘slideTo’ method.
First off, here are the UI components under test. Yes, this is the entire code, including all necessary wiring to trigger updates automagically as the sliders are changed.

speedSlider = slider(
        name: 'speedSlider',
        sliderModel: boundedRangeModel(
                min: 1, max: model.SPEED_MAX - 1, value: model.SPEED_MAX - 1, extent: 0),
        opaque: true)

slider = slider(
        name: 'slider',
        sliderModel: boundedRangeModel(
                min: 1, max: 50, value: 8, extent: 0), opaque: true)

tSlider = slider(
        name: 'tSlider',
        sliderModel: boundedRangeModel(
                min: 1, max: 20, value: 4, extent: 0), opaque: true)

label = jxbusyLabel(name: 'busyLabel',
        preferredSize: new Dimension(model.W / 2 as int, model.H / 2 as int),
        busyPainter: busyPainter(
                highlightColor: bind { model.busyColor }, baseColor: bind {model.baseColor},
                points: bind{slider.value}, trailLength: bind{tSlider.value}),
        opaque: false,
        horizontalAlignment: JLabel.CENTER,
        delay: bind{speedSlider.value})
........
buttons.addLine(button(name: model.START_NAME, action:startAction))

And then the tests run against them. Each test moves a slider sequentially from the minimum to the maximum values and checks at each change to ensure that the same change is reflected on the bound JXBusyLabel property. Because the JXBusyLabel does not have a ready corresponding FEST built in fixture class, we just look it up as a Component by inspecting the UI for the appropriate named Component. The Groovy dynamic type system makes accessing its internal properties trivial after that.

/**
   * Start the animation and then ensure that changing the speed slider changes the delay.
   */
   @Test void testSpeedSlider() {
     def button = window.button(JXBusyLabelDemoModel.START_NAME)
     button.click()
     def JSliderFixture slider = window.slider('speedSlider')
     ComponentFinder finder = BasicComponentFinder.finderWithCurrentAwtHierarchy();
     def busyLabel = finder.findByName(app.appFrames[0], 'busyLabel')
     Assert.assertNotNull(slider)
     Assert.assertNotNull(busyLabel)
     (1..JXBusyLabelDemoModel.SPEED_MAX - 1).each { speed ->
       slider.slideTo(speed)
       Assert.assertEquals(busyLabel.delay, speed)
     }
   }

  /**
   * Start the animation and then ensure that changing the points slider changes the
   * number of points.
   */
   @Test void testPointsSlider() {
     def button = window.button(JXBusyLabelDemoModel.START_NAME)
     button.click()
     def JSliderFixture slider = window.slider('slider')
     ComponentFinder finder = BasicComponentFinder.finderWithCurrentAwtHierarchy();
     def busyLabel = finder.findByName(app.appFrames[0], 'busyLabel')
     Assert.assertNotNull(slider)
     Assert.assertNotNull(busyLabel)
     (1..50).each { points ->
       slider.slideTo(points)
       Assert.assertEquals(busyLabel.busyPainter.points, points)
     }
   }

  /**
   * Start the animation and then ensure that changing the trail slider changes
   * the trailLength.
   */
   @Test void testTrailSlider() {
     def button = window.button(JXBusyLabelDemoModel.START_NAME)
     button.click()
     def JSliderFixture slider = window.slider('tSlider')
     ComponentFinder finder = BasicComponentFinder.finderWithCurrentAwtHierarchy();
     def busyLabel = finder.findByName(app.appFrames[0], 'busyLabel')
     Assert.assertNotNull(slider)
     Assert.assertNotNull(busyLabel)
     (1..20).each { trailLength ->
       slider.slideTo(trailLength)
       Assert.assertEquals(busyLabel.busyPainter.trailLength, trailLength)
     }
   }

It’s particular amusing to note that the test code is more verbose than the Swing component setup. Man, after all of the Swing code I’ve written, WHY WAS NONE OF IT EVER THIS EASY!
Sorry for the shouting, but it’s late and updating this code to use binding instead of change listeners AND writing the tests AND writing this blog post took all of about 45 minutes. So you’ll have to forgive me for getting excited and all.

Here is the promised video showing the FEST test suite being run.. Give it a second as the first round of tests(not shown in the code above) do a bunch of assertions to make sure that all of the expected Components can be found. Not terribly interesting to watch, but a great win for Java GUI testing!

Related posts:

1. More Groovy/Griffon/FEST Testing
2. SwingX busy label demo in Griffon and Groovy
3. SwingSet on Griffon

The SwingX demonstration makes use of an inner ‘DetailsPane’ class that nicely handles a lot of the gridbag layout details, but I didn’t really want to spend the extra time Groovifying a perfectly good and already implemented helper class, so I just threw the java code in the Griffon src directory and that was that. Being able to seamlessly mix Java and Groovy is a definite plus, let me tell you. Below is an example of adding a new DetailsPane using the builder DSL, utilizing a GridBagConstants variable named ‘gbc’ and assigning the foreground color based on a model property.

genPane = jxpanel(constraints: gbc,
                              new DetailsPane("General settings:", model.FOREGROUND))

Here is a side-by-side comparison of Java and then the equivalent Groovy code for creating and initializing a new JXBusyLabel. At first they don’t look a whole lot different, but if you notice, the Groovy version is actually a one-liner, and uses the bind() syntax to set colors based on a model backed property.

 label = new JXBusyLabel(new Dimension((int) (W / 2), (int) (H / 2)));
 label.getBusyPainter().setHighlightColor( new Color(44, 61, 146).darker());
 label.getBusyPainter() .setBaseColor(new Color(168, 204, 241).brighter());
 label.setOpaque(false);
 label.setHorizontalAlignment(JLabel.CENTER);

label = jxbusyLabel(
       preferredSize: new Dimension(model.W / 2 as int,model.H / 2 as int),
       busyPainter: busyPainter(highlightColor: bind{ model.busyColor },
       baseColor: bind{model.baseColor}), opaque: false, horizontalAlignment: JLabel.CENTER)

SwingX contains a specialized button that wraps a color chooser component, and here we can look at the differences between the Java and Groovy syntax for instantiating one. The JXColorSelectionButton class isn’t actually a node made available by the SwingXBuilder, but adding to the builder syntax dynamically is simple to say the least using a call to ‘registerBeanFactory’. Also in the Groovy version, here we’re not directly updating the color on the label, we’re updating the model. While the background color change seems to be correctly updated through the bound ‘baseColor’ model property, it does not repaint automagically. I’m sure there’s a way to do this, it just hasn’t popped up yet.

JXColorSelectionButton baseColBtn = new JXColorSelectionButton();
baseColBtn.setBackground(label.getBusyPainter().getBaseColor());
baseColBtn.addPropertyChangeListener("background", new PropertyChangeListener() {
      public void propertyChange(PropertyChangeEvent evt) {
           label.getBusyPainter().setBaseColor((Color) evt.getNewValue());
           label.repaint();
      }});

registerBeanFactory('colorButton', JXColorSelectionButton.class)
baseColBtn = colorButton(background: model.baseColor)
baseColBtn.addPropertyChangeListener("background",
      {PropertyChangeEvent evt ->
           model.baseColor = (Color) evt.getNewValue()
           label.repaint()     //need to figure out how to remove this call!!!
      } as PropertyChangeListener)

The Java code uses an anonymous inner class to kick off the process.

new JButton(new AbstractAction("Start") {
      public void actionPerformed(ActionEvent e) {
           label.setBusy(!label.isBusy());
           putValue(Action.NAME, label.isBusy() ? "Stop" : "Start");
      }
 })

No anonymous inner classes in Groovy, and with the Griffon framework we can separate the concerns a bit better anyhow. This code is split up between the view and the controller classes. Note that the controller can reference(and update) the action by acting through its injected view component.

/* action and button defined in the view */
actions {
      action(id: "startAction",
      name: model.START_NAME,
      mnemonic: "S",
      accelerator: shortcut("S"),
      closure: controller.start)
 }
button(startAction)
...
/* controller action */
def start =  { ActionEvent evt ->
      view.label.setBusy(!view.label.isBusy())
      view.startAction.putValue(Action.NAME, view.label.isBusy() ? "Stop" : "Start")
 }

Finally, here’s a code sample of how to add a listener to an existing component and bind the action to a method on the controller:

     xSlider.addChangeListener(controller.&fcl as ChangeListener)

In most cases, the sample code here is not trying very hard to shorten the syntax; there’s a lot of room for improvement and further Groovification. I’m sure there’s a better way to add listeners, for instance. Anyhow, aside from a few details, the application is up and running and doing the same thing as the original. Total effort expended: probably about 10 hours, a good portion of it spend Googling and reading. Next step is to write some tests to get better at that side of the equation. I’d be including more links about the excellent SwingX components in this post, but the SwingLabs website has been reporting “Maximum Connections Reached: 4096 — Retry later” all day. Hope everything gets fixed soon guys!

If you’re interested in seeing this demo live and in action, there’s a link to a short Jing video below.

Click here for video of the JXBusyLabel demo running on Griffon.

Related posts:

1. More Groovy/Griffon/FEST Testing
2. Griffon SwingX Fest testing
3. SwingSet on Griffon

# Griffon completion for the bash shell
#
_griffon()
{
   local cmds cur colonprefixes
   cmds="bootstrap clean compile console create-app           \
      create-fest-test create-integration-test create-mvc     \
      create-plugin create-script  create-unit-test           \
      create-fest-test run-fest -cobertura help init          \
      install-plugin list-plugins package package-plugin      \
      plugin-info release-plugin run-app run-applet run-fest  \
      run-webstart set-proxy set-version shell stats test-app \
      test-app-cobertura uninstall-plugin upgrade"
   COMPREPLY=()
   cur=${COMP_WORDS[COMP_CWORD]}
   # Work-around bash_completion issue where bash interprets a colon
   # as a separator.
   # Work-around borrowed from the darcs work-around for the same
   # issue.
   colonprefixes=${cur%"${cur##*:}"}
   COMPREPLY=( $(compgen -W '$cmds'  -- $cur))
   local i=${#COMPREPLY[*]}
   while [ $((--i)) -ge 0 ]; do
      COMPREPLY[$i]=${COMPREPLY[$i]#"$colonprefixes"}
   done

        return 0
} &&
complete -F _griffon griffon

Add this to your .bash_profile file and you’re good to go for saving a whole bunch of keystrokes and calls to ‘griffon help’.

Related posts:

1. Groovy and Bash – can scripting get much easier?
2. SwingSet on Griffon
3. Griffon SwingX Fest testing

The SwingX widgets have been a pleasure to work with in the past, and with the swingX plugin, it takes not a single line of extra code in order to use them.  The underlying SwingXBuilder provides factories which override the standard SwingBuilder syntax to replace the standard widget set with the SwingX equivalents. Simply add the prefix ‘jx’ to the standard SwingBuilder node calls and you’re in business.

Along the way I’m going to incorporate the fest and cobertura plugins to test out the UI. I’ve never used fest before but it seems that the only real requirement is to remember to give your components a uniquely identifiable id. There are additional ways of looking up components with fest, for sure, but unique ids should cover this application’s needs quite nicely. Using both together is a simple exercise on the command line.

griffon run-fest -cobertura

Under the hood, Griffon uses TestNG, so the test class can also take advantage of some nice familiar annotations to assist configuration. Code coverage and testing results are provided by default in an html format, which anyone who likes their test coverage will be infinitely familiar with.  All in all, the experience of setup and execution of the testing framework is pretty painless.

The SwingSet demo is actually laid out pretty nicely for testing in the first place. There’ s a top level MainWindow class, which accepts a DemoPanel parameter. The full demo launches with a SwingXDemo subclass of DemoPanel that aggregates other subclasses of the same into a tabbed pane. Tests are free to call the MainWindow class with any of the individual panels as a parameter, so testing them on their own using fest looks like it would be a cinch.  In Griffon terms this roughly translates to a root MVC group that composes another MVC group that is specified by id. Easier to show than to explain, with an example of a call that would go in the controller:

createMVCGroup(mvcGroupIDParam, uid,   [... param map ...] )

The first thing created in the SwingSet UI is the menu, so that’s what I created first as well. In the view class:

 actions {
    action(id: "quitAction",
            name: model.QUIT_NAME,
            mnemonic: "Q",
            accelerator: shortcut("Q"),
            closure: controller.quit)
  }

  menuBar {
    menu(model.MENU_NAME) {
      menuItem(name: model.QUIT_NAME, action:quitAction)
    }
  }

The component names are defined in the model class so that they can easily be extracted later for testing purposes.
Including the fest plugin with Griffon adds a target which is used to create a new test, which will prompt you for a test name.

create-fest-test

The new test class is created with all of the necessary code to let fest launch the base application frame. This first test is very simple, just making sure that our single menu item is present in the GUI.

  @Test
  void testQuitMenuItemPresent()
  {
    Assert.assertNotNull( window.menuItem(GriffonSwingSet3Model.QUIT_NAME) )
  }

That’s really all it takes to launch a new application using the test harness and verify UI component state. Man, can I think of a couple of times in the past where that might have come in handy

Next, step is cutting over the first SwingSet DemoPanel, a demonstration of JXBusyLabel – 635 lines of the usual Swing inner classes and boilerplate GridBagLayout constraints code. Really looking forward to seeing how it looks in Groovy.

Related posts:

1. Griffon SwingX Fest testing
2. Fun day playing with new Stuff
3. VIJUG Griffon/Groovy Presentation

I got a chance to work with the brand new Griffon framework and must say – the combination of clear MVC architecture, Grails style convention over configuration and already powerful plugin selection make it pretty sexy.

The early support for cobertura code coverage and fest GUI testing are both appealing to any developer that appreciates the need for testing your application.  I’m still undecided on the Grails-like adoption of storing project information in a “.griffon” folder in the user directory and completely outside of the actual project directory structure. With luck, future versions will allow for incorporating maven to handle dependency management and get me past my FUD on that one, something that the latest Grails supports. I haven’t yet tried that new feature out in Grails out so I’m not entirely sure how well it works, but the docs say that there is a provided archetype and that all of the familiar Grails targets are mirrored in the maven goals.

Being able to add additional Groovy style builders as plugins is about as transparent as it gets – install the plugin and you can immediately incorporate that builder anywhere in the application.  The only builder component set that I have had a chance to work with previously is SwingX, but anyone who’s had the opportunity to use a JXTable in place of the vanilla JTable can immediately see the advantage! And the JDirectoryChooser from l2fprod is a powerful alternative to the Swing built-in JFileChooser.

The crown jewel so far however seems to be  the wizard plugin. This addresses what is  a very common scenario in any process related application:

• collect User input in a series of steps
• validate the input at each step
• allow the User  to go back and review or change any inputs
• apply all of the input to an underlying business process
• provide feedback as to the result

The wizard framework worked pretty much as advertised right out of the box and, although the project seems to have stalled (couldn’t seem to  find any updates since mid-2008) , when integrated so well with Griffon it seems a very good candidate for building lightweight applications – installers in particular jump to mind.

Any way you look at it – for a project as newly arrived as Griffon, it’s already promising to be a very powerful enabler. Thanks to Andres Almiray and everyone else involved in the project. I look forward to using Griffon more in the future.

Related posts:

1. A One Day Griffon Application/Presentation
2. Playing with the new Grails :)
3. SwingSet on Griffon