Everyone loves sparklines, and if you want to build them using Groovy, here’s some code that I took from a fabulous example in JRuby, and modified:

package com.stelligent.gsparkyimport org.jfree.chart.JFreeChart
import org.jfree.chart.axis.NumberAxis
import org.jfree.chart.plot.XYPlot
import org.jfree.chart.renderer.xy.StandardXYItemRenderer
import org.jfree.data.general.Dataset
import org.jfree.data.xy.XYSeries
import org.jfree.data.xy.XYSeriesCollection
import org.jfree.chart.ChartUtilities

class GSparky {

    def DEFAULT_HEIGHT = 30
    def DEFAULT_WIDTH  = 150

    boolean build( def data, def imgPath, def height = DEFAULT_HEIGHT, def width = DEFAULT_WIDTH ) {

        def chart = buildChartFromData(data)
        return buildImageFromChart( chart: chart, height: height, width: width, path: imgPath)
    }

    private JFreeChart buildChartFromData( data ) {

        def dataset = generateDataset(data)

        def plot = new XYPlot()
        plot.dataset = dataset

        plot.domainAxis =  minimalAxis()
        plot.rangeAxis = minimalAxis()

        plot.domainGridlinesVisible = false
        plot.domainCrosshairVisible = false
        plot.rangeGridlinesVisible = false
        plot.rangeCrosshairVisible = false
        plot.outlinePaint = null
        plot.renderer = new StandardXYItemRenderer(StandardXYItemRenderer.LINES)
        plot.insets = new RectangleInsets(-1, -1, 0, 0)

        def chart = new JFreeChart(null, JFreeChart.DEFAULT_TITLE_FONT, plot, false)
        chart.borderVisible = false

        return chart
    }

    private boolean buildImageFromChart( args ) {

        ChartUtilities.saveChartAsPNG( new File(args.path), args.chart, args.width, args.height )

        return true
    }

    private Object minimalAxis() {

      def a = new NumberAxis()
      a.tickLabelsVisible = false
      a.tickMarksVisible = false
      a.axisLineVisible = false
      a.negativeArrowVisible = false
      a.positiveArrowVisible = false
      a.visible = false;

      return a
    }

    private Dataset generateDataset(def data) {

        def series = new XYSeries("Sparkline")

        def i = 0
        data.each { y -> series.add(i++, y)  }

        def dataset = new XYSeriesCollection()
        dataset.addSeries(series)

        return dataset

    }
}

And.. a test to demonstrate how it works:

package com.stelligent.gsparky

class GSparklineTest extends GroovyTestCase {

    public void testBuildSparklineImage() {

        def gs = new GSparky()

        def data = [20]

        def r = new Random( new Date().getTime() )

        (0..99).each { x ->
           def y = data.get(x) + (x/2 - r.nextInt(x + 1))
           data << y
        }

        assert gs.build( data, "out/GSparklineTest_test1.png")

    }

}

*Update* - added a line to remove the grey border from around the graph.

InfoQ recently published an interview with Joshua Bloch, who is the author of “Effective Java”– an updated second edition was released, which includes some tips with dealing with Java’s generics, autoboxing, and annotations, to name a few.

“Effective Java” is one of the best books I’ve ever read regarding the Java language and has served me well over the years– the second edition also appears to follow suit. InfoQ also has a sample chapter available, which focuses on Generics and already I’ve found it helpful.

Don’t forget to read the interview as well– the author has some great insights into refactoring and Java in general. My favorite part of the interview was this exchange:

Do you believe that other tools and processes such as unit testing, Test-driven development or pair programming also aid in programming effectively in Java?

Joshua’s response is right on:

Absolutely. Unit testing is key. And writing your tests first is a great thing. Pair programming works very well for some people, as do variants such as “buddy programming” (where you show your code to someone else after you’ve written it, and refactor as necessary together). Writing code in a vacuum is bad thing. Code reviews (which I view as another variant) are essential…

If you don’t have a copy of Joshua’s book, pick one up as soon as possible– your users will thank you!

If you are in Ireland (or close enough to get there easily!) the week of June 9th, then you’ll want to come to the International Conference on Agile Processes and eXtreme Programming in Software Engineering as I’ll be giving a tutorial on Continuous Integration!

The tutorial will walk students through a series of exercises on a project where an automated build system is created that facilitates compilation, testing, inspection, and deployment. This build system will then be plugged into a CI server (Hudson in this case) and students will code a series of features using Agile techniques like developer testing, which will ultimately demonstrate how a Continuous Integration process reduces risk and improves software quality. Students will then toast to CI over a pint of Guinness!

If this sounds like a blast to you, then register today! If you plan on attending, drop me an email and I look forward to meeting you!

For any developer looking to test web services, there are a number of tools out there that seem to fit the bill. When you need one that allows you to interact and create functional and load tests with relative ease, soapUI is bound to be the tool you can’t live without.

To help get you started, Meera Subbarao has authored a how-to series on testing web services using soapUI. Published by JavaLobby and entitled, “Functional Web Services Testing Made Easy with SoapUI,” the series is broken up into three installments; with each article demonstrating an important soapUI feature that will make web services development easier for you.

Part 1 explores soapUI basics including how to write functional tests for your web services and how to add assertions to these tests. In short, soapUI emphasizes a good balance between simplicity and rich features and as Subbarao notes in Part 1,

Once soapUI has been downloaded and installed, you can have functional tests up and running in minutes.

For more elaborate programming tasks, Part 2 examines soapUI’s relationship with Groovy. Groovy is used in soapUI primarily for test setup, test teardown, and to decide which steps to start based on the results of the older ones. If you know Java, writing Groovy scripts with the UI will make your testing even easier.

soapUI also includes command-line utilities for running tests and mocks in a continuous integration environment so you’re able to run the test cases you’ve created within it and above all fail the build just like you would when any other unit test fails. Stayed tuned for the third and final part of this series which will cover integrating tests with your build tool, running these tests as part of your builds, and creating JUnit reports.

I don’t always agree with Mr. Yegge, but this is a great presentation/script on Dynamic Languages with some very interesting ideas and discussion topics.

One point that he never actually got to, but one that I think is worth more discussion - how do you maintain a million-line codebase w/out static types?

My answer is that with a good dynamic language, you have some seriously elegant features and patterns that allow you to keep the size of your codebase small.  Essentially, you don’t maintain a million-line codebase - because it doesn’t take a million lines to write your application.

Which fits in with some of the agile concepts as well - if you are building a project in an agile style, the constant refactoring and removal of technical debt will keep the application smaller and lighter.  The unit tests ensure a clean level of separation of concerns, the DRY and YAGNI principles reduce bloat.

Mastering the art of command line jujitsu is something every developer (regardless of OS) should strive for. While OS UIs are becoming more and more slick and helpful tools are abundant, possessing the ability to drop into a console and efficiently knock something out (find . -iname *.java | xargs egrep -i “todo” anyone?) has come in handy, for me at least, on more than one occasion.

For instance, every modern IDE now has a plug-in that facilitates working with Subversion– in fact, when I made the switch to Subversion from CVS a fews years back, I initially failed to even learn the Subversion commands– my favorite tools did it all for me graphically! Yet, in some cases I found myself distrusting the implementations these tools provided– for instance, one of my favorite CVS commands was cvs -nq update, which effectively tells you what’s changed in your local sandbox as compared to the tip of the CVS repository. This, of course, is handy in figuring out what you plan on committing; hence, I would run this command before a cvs commit so as to filter out unneeded changes.

This developmental cadence of making changes and checking them against the tip (and consequently committing them) is actually common among SCM systems– the cadence has three steps:

• updating a local sandbox to reflect what is in a repository
• understanding what has changed locally
• committing local changes into a repository

With Subversion, these three steps can be achieved via the command line with three commands:

• svn update
• svn diff
• svn commit

The svn update command takes any changes in a Subversion repository and pushes down to a local sandbox. For instance, if more than one person is making changes and committing those changes into a repository, when another person runs the svn update command, those changes will be literally downloaded into that person’s sandbox.

Using the update command is as easy as opening up a console and typing:

tty:~/dev/projects/easyb/ yts$ svn update

If there are changes in the repository, you should see some scrolling text like so:

U    maven-plugins/maven-easyb-plugin/src/main/java/org/easyb/maven/StoryReportMojo.java
U    maven-plugins/maven-easyb-plugin/src/site/apt/usage.apt
U    maven-plugins/maven-easyb-plugin/src/it/story-report-location-test/pom.xml
U    maven-plugins/maven-easyb-plugin/src/it/site-examples-test/pom.xml
U    intellij-plugins/easyb-plugin/easyb-plugin.iws
U    intellij-plugins/easyb-plugin/src/main/java/org/easyb/plugin/ui/EasybPresenter.java
U    intellij-plugins/easyb-plugin/pom.xml
Updated to revision 329.

Note, the U means updated– there are other characters for new files added, merged, in conflict, etc. What’s key here is that by running the update command, your local sandbox is in sync with what’s on the server. Running this command often often means you’ll probably avoid conflicts too!

After you’ve made some local changes, it’s often times helpful to capture what those changes were– if you’ve been working for any length of time or working with more than one file, you’ll most likely find the diff command indispensable.

Like the update command, diff can be run via the command line like so:

tty:~/dev/projects/easyb/ yts$ svn diff

This command will compare what’s in the repository with what’s in a local sandbox; what’s more, it’ll report on the exact changes as follows:

Index: behavior/groovy/org/disco/bdd/prototype/FixtureFeature.story
===================================================================
--- behavior/groovy/org/disco/bdd/prototype/FixtureFeature.story        (revision 322)
+++ behavior/groovy/org/disco/bdd/prototype/FixtureFeature.story        (working copy)
@@ -4,7 +4,7 @@
 description "this story is fleshing out fixture logic for scenarios"

-each "some description" , {
+every "some description" , {
     given "a value", {
         value = 12
     }
Index: src/groovy/org/disco/easyb/StoryBinding.groovy
===================================================================
--- src/groovy/org/disco/easyb/StoryBinding.groovy      (revision 322)
+++ src/groovy/org/disco/easyb/StoryBinding.groovy      (working copy)
@@ -102,7 +102,7 @@
       listener.describeStep(description)
     }

-    binding.each = {  description = "", closure = {} ->
+    binding.every = {  description = "", closure = {} ->
         beforeScenario = closure
     }
     return binding

As you can see in the text above, the local code (labeled as “working copy”) has changed the each call with every, which appears in revision 322 of the repository.

Once you’ve reviewed these changes and are happy with what you’ve got, you can then proceed to push these changes into the repository via the svn commit command– of course, this assumes you’ve run a local build and it passed successfully, right?

tty:~/dev/projects/easyb/ yts$ svn commit -m "updated dsl to use every instead of each"

Note that the commit command can take a flag (-m) that enables you to specify a comment. You should see some text indicating the changes are being pushed into the repository.

Sending        easyb/behavior/groovy/org/disco/bdd/prototype/FixtureFeature.story
Sending        easyb/src/groovy/org/disco/easyb/StoryBinding.groovy
Transmitting file data ..
Committed revision 325.

Note how these changes increment the revision number in Subversion– this is key as all commands allow you to work with various revisions (via flags); hence, by knowing a particular revision, you can logically branch if needed.

These three Subversion commands will come in handy if you aren’t already using them; hence, learn them now! Indeed, for becoming one with the command line is the path to enlightenment.