Posts Tagged ‘Coding’

First Look at Vaadin

November 22, 2009 8 comments

I’ve had the chance over a recent weekend to have a first crack at a web framework called Vaadin.

I was originally browsing for news about the latest release of Google’s GWT framework when I stumbled on a reference to Vaadin, and decided to go take a look. What I found intrigued me, and I decided to take it for a test drive, as I was down sick for a couple of days with a laptop nearby…. My back became annoyed with me, but it was worth it, I think.

First Look
First off, the practicalities: Vaadin is open source, and with a reasonable license, the Apache License. The essential bits of Vaadin are contained in a single JAR, and it’s both Ant and Maven friendly right out of the box.

The next thing that struck me about Vaadin was the documentation. The first unusual thing about it’s documentation was the fact of it’s existence, as open source projects are downright notorious for poor documentation. Vaadin is a pleasant exception, with tons of examples, a well-organized API doc, in the usual JavaDoc format, and even the “Book of Vaadin”, an entire PDF book (also available in hardcopy) that takes you through Vaadin in enough detail to be immediately productive.

Given that surprisingly pleasant start, I dug deeper, creating a little app of my own.

Just the Java, Ma’am
The main thing that kept me interested in Vaadin once I started digging further was that it’s pure Java. Many frameworks talk about writing your UI work in Java, such as Wicket, but there’s still a corresponding template and some wiring that happens to put the code and the template together. Not so with Vaadin.

When they say “just Java”, they mean it – your entire UI layer is coded in Java, plain and simple. No templates, no tag libraries, no Javascript, no ‘nuthin. It’s reminiscent of the Echo framework, except in Vaadin’s case the Javascript library that your code automatically produces is Google’s GWT, instead of Echo’s own Core.JS library.

Unlike GWT, though, the Vaadin approach doesn’t bind you to any specific source code though, it’s just a binary jar you put on your classpath.

The only thing in my sample app, other than 2 Java files, was a web.xml and a css stylesheet, both of which were only a few lines long. And this was no “Hello, World”, either, but a rich AJAX webapp with a tree menu, fancy non-modal “fading” notifications, images, complex layouts, and a form with build-in validation. And it took maybe 4 hours of total work to produce – and that was from a standing start, as I’d never heard of Vaadin before last Thursday. Not bad, not bad at all.

I found I was able to get a very capable little webapp up and running with no need to invent my own components, even though I had trees and sliders and menus and other assorted goodies on the page. It worked in every browser I was able to try it in, which is certainly not the case for my own hand-rolled JavaScript most of the time 🙂

I haven’t yet tried creating my own custom components, but it certainly looks straightforward enough.

I did try linking to external resources, and included non-Vaadin pages in my app, with no difficulties, so it appears that Vaadin plays well with others, and can be introduced into an existing project that uses, for instance, a whack of JSP’s that one might want to obsolete.

I think Vaadin warrants more exploration, and I intend to put it further through its paces in the next few weeks. It appears extremely well-suited to web applications, as opposed to websites with a tiny bit of dynamic stuff in them.

It offers an interesting alternative to some of the patterns I’ve seen for advanced dynamic webapp development so far.

One approach I’ve seen a lot is to divide the duties of creating an app into the “back end” services and the “UI”. Generally the UI is written in either JavaScript, or uses Flex or some other semi-proprietary approach. The “back end” stuff is frequently written to expose it’s services as REST, then the two are bolted together. The pain point here happens when the two meet, as it’s common and easy to have minor (or major!) misunderstandings between the two teams. This usually results in a lot of to-and-fro to work out the differences before the app comes all the way to life.

The other approach, more common on smaller or resource-strapped teams, is to have the same group responsible for both UI and back-end services. This reduces the thrash in the joints a bit, but doesn’t eliminate it, because the two technologies on the two sides of the app aren’t the same. You can’t test JavaScript the same way you write Java, for instance, and they’re two different languages – one of which (Java) has far better tooling support than the other. IDE support, for instance, is superb for Java, and spotty at best for JavaScript.

With Vaadin, both of these approaches become unnecessary, as its the same technology all the way through (at least, what you write is – technically it’s still using JavaScript, but because that’s generated, I don’t count it).

You get to use all of the tools you know and love for the back-end services to write the code for the UI, which you can then unit and functional test to your heart’s content.

The temptation to mix concerns between UI code and back-end service code must still be resisted, of course, but at least that code isn’t buried somewhere in the middle of a JSP page, ready to leap out and bite you later.

Because you’re using dynamic layouts, the app always fits properly on the screen without any extra work, addressing a pet peeve of mine, the “skinny” webapp, restraining itself to the least common denominator of screen size, thus rendering impotent my nice wide monitors.

Just because Vaadin is a Java library doesn’t restrict you to using Java to drive it, however. I made another little webapp where the whole UI was defined in Scala, calling the Vaadin APIs, and it worked like a charm. In some ways, Scala is an even better fit for Vaadin than straight Java, I suspect. I haven’t tried any other JVM compatible language, but I see no reason they wouldn’t work equally well.

Deployment and Development Cycle
As I was building the app with Maven, I added a couple of lines to my POM and was able to say “mvn jetty:run” to get my Vaadin app up and running on my local box in a few seconds. My development cycle was only a few seconds between compile and interactive tests, as I was experimenting with the trial-and-error method.

TDD would be not only possible, but easy in this situation.

I successfully deployed my little Vaadin app to ServiceMix, my OSGi container of choice, without a hitch.

Performance appeared excellent overall, although I haven’t formally tested it with a load-testing tool (yet).

So far, I’m impressed with Vaadin. I’m more impressed with any web framework I’ve worked with in a number of years, in fact. I’m sure there are some warts in there somewhere, but for the benefits it brings to the table, I suspect they’re easily worth it. I think the advantages to teams that already speak fluent Java is hard to overstate, and the productivity to produce good-looking and functioning webapps is quite remarkable.

Over the next few weeks I’ll push it a bit harder with a complex example application, and see how it stacks up against other web app technologies I’ve worked with in a more realistic scenario.

By: Mike Nash


Maven Projects In NetBeans 6.5 On OSX / Updating Maven On OSX

May 1, 2009 Comments off

Since my last post, Defaulting To JDK 1.6 In NetBeans 6.5 On OSX, has enjoyed some popularity I decided to keep running with the NetBeans 6.5/OS X theme. NetBeans is a great, free IDE that supports more types of projects than the average developer would likely ever need. One of the most useful project types that NetBeans supports is Maven projects. If you are new to Maven, here is an intro to peak your interest.

For developers who have been using Maven for a while, you likely will be creating your projects (.pom files specifically) from a text editor but this can be a little overwhelming for those new to Maven or those who would rather simply spend their time writing code instead. NetBeans 6.5 makes it incredibly easy to create a Maven project in a matter of seconds.

First, go to the “File” menu and choose “New Project”.
New Project
Under “Categories”, choose “Maven” and in”Projects”, choose “Maven Project” and click “Next”.
Choose Project
The “Archetype” window should open next, select “Maven Quickstart Archetype” and click “Next”.
Project Archetype
The “Name and Location” window will open allowing you to give specifics to your project. You can customize this as you see fit but for the purposes of this example I will leave the default settings. Click “Finish” and your project will start to build.
Project Name & Location
If you are running OS X 10.5.6, as I am, you will likely see the following error:

Error resolving version for 'org.apache.maven.plugins:maven-archetype-plugin': Plugin requires Maven version 2.0.7
For more information, run Maven with the -e switch

The reason for this is that OS X 10.5 shipped with Maven 2.0.6 pre-installed but Apple has never pushed any updates to it. According to the Apache archives, Maven 2.0.6 was released in April 2007 but it is kind of annoying that they didn’t realize that Maven projects would not work by default on OS X before they released NetBeans 6.5. Luckily, it is very easy to update Maven to the latest version if you don’t mind using the terminal and the sudo command.

  1. Download the zip with binaries for whichever Maven version you would like to install. At time of writing, the most recent version is 2.1.0,
  2. Once the file is downloaded, you can extract the archive and you should end up with a directory named something like “apache-maven-2.1.0”. Open a Terminal window and cd /usr/share
  3. Let’s move the current Maven directory to a backup folder in case we ever want to revert. In the terminal you opened in the last step, type sudo mv maven maven-2.0.6. This will ask you for your password and then move the “maven” directory to a new directory called “maven-2.0.6”, assuming your user account has sufficient permissions.
  4. Now let’s put the new version in place so that NetBeans will start using it. To do so, we need to copy the directory we extracted from the zip file. Once again, in the Terminal window you have open, type sudo cp -R /Users/dgabrielson/Desktop/apache-maven-2.1.0 maven. Keep in mind that the path to the extracted “apache-maven-2.1.0” directory will have to be changed to the appropriate path on your system.
  5. Maven should now be upgraded! To confirm, in your Terminal window, type mvn -version and you should see some output like Apache Maven 2.1.0 (r755702; 2009-03-18 13:10:27-0600).

Now if you try to build again, you should get a successful build log ending with:


Enjoy your new Maven build and get coding!

By: Damien Gabrielson

High Ceremony doesn’t have to mean High Cycle Time

April 27, 2009 Comments off

Oftentimes languages such as Java are called “high ceremony” languages compared to languages like Ruby or Python. This refers to the fact that there’s generally a bit more plumbing involved in firing up a Java application – particularly a web application – than there is with the scripting languages.

Of course, Java is compiled (to byte-code at least), so it’s not quite a 1 to 1 comparison with a more interpreted language such as Ruby, but still, even in a “high ceremony” language it’s important not to get too high a “cycle time” for developers, IMO.

By “cycle time” I mean the time between making a change and seeing it working – either in a test, or, ideally, in a running application. Most modern IDEs made the cycle time for tests pretty darn low (and great tools like Inifinitest can take all the manual work out of it, no less), but to see a running application and be able to exercise your changes deployed in a container is a bit more of a grind.

That’s where a tool like Jetty can come in handy. Jetty is a lightweight web app container that can be easily added to your development cycle in place of a heavier-weight solution to allow you a faster cycle time, and, often, greater productivity and interactivity.

Especially in combination with it’s integration with Maven, Jetty can get your app deployed far faster than with other solutions. For most webapps, it’s just a matter of saying:

mvn jetty:run

And you’ve got a container up and running with your app in it within a few seconds.

Jetty can even do a certain amount of “hot update”: modify a JSP (or even some code – although there are limits) and the running webapp is updated, and you’re able to test, edit… cycle away without the painful wait for a deployment any more often than necessary.

You can pass required system properties to your app via maven’s -D mechanism, and they’ll be available to your app:

mvn jetty:run

And even control the port your application binds to on the fly (or via the handy jetty.xml file if you want to set it more permanently).

Jetty and maven also give you the ability to easily script, for example, if you need to run a test utility on your running webapp to ping a series of REST calls, for example, you can:

mvn clean package # Build the webapp
mvn jetty:run & # start jetty, spawning it in the background
java -jar mytestutility.jar # Run my test jar, which pings the URLs for all my rest services, maybe does performance checks, etc
mvn jetty:stop # Stop the jetty instance we fired up in the background

Lightweight containers such as Jetty are just one way to help crank down the “cycle time” for developers, of course. Some other possibilities I’ll leave for a later entry.

By: Mike Nash

Why Pairing is Better

April 4, 2009 Comments off

My wife and I plan our finances each month. We look at how much we spent in the previous month and why, and we project what we will spend in the upcoming month. It’s pretty lo-fi: A 20 column ledger and a spreadsheet. The ledger is always lying out and open so we can write in it as soon as we get home.

The spreadsheet is for calculations and planning. At regular intervals we sit down together, Wendy and I armed with our favorite tools. She relays the numbers from the ledger and I enter them into the spreadsheet. Wendy is focused on reading and relaying the numbers while I am focused on data entry. Once the numbers are in we quickly double-check just to be sure. The process takes less than 5 minutes for 40 – 60 entries.

This time Wendy did the data entry on her own. I asked how last month looked and she said “We spent a lot on groceries”. I happen to like eating so it’s not a big deal that we overspent, but it’s still nice to know why it happened. There is always a reasonable explanation. Meat is a major portion of the bill, and maybe we bought too many bags of frozen peas. Or maybe there is a mistake in the data.

Had we paired during the data entry we would have been assured that the entry was in fact correct and we could begin a meaningful analysis of our overspend. I am now forced to look back through the data in the ledger and ensure that it has been entered correctly. This will take more time because I will be switching tasks many times:

  1. Find the entry in the ledger
  2. Remember the value of the entry
  3. Move eyes from paper to spreadsheet
  4. Scan to find the corresponding entry in the spreadsheet
  5. Recall the value of the entry
  6. Verify the values

Compare these steps with those that I would do when pairing:

  1. Translate what Wendy said
  2. Verify that the value she relayed is correct in the spreadsheet

Yep, only 2 steps. I don’t have to keep switching focus from paper to monitor, nor must I remember any values. I just verify that the value she gave me is the value in the spreadsheet.

When I sat down to verify our numbers, the realization that pairing is much more effective (and arguably more efficient) hit me like a ton of spaghetti code. When you are working on complex tasks you are forced to make switches between contexts – the problem and the solution details. In my example the problem is incorrectly entered data, and the details are moving my eyes from paper to screen, then remembering and verifying values. When writing code the problem is the bug/story you are playing, and the details are language syntax, editor shortcuts, etc.

Now to the point. Imagine that you could offload one of the contexts and fully focus on the other. Wendy can focus on the problem (relaying the numbers) and I can focus on the details (data entry). When writing code the navigator is focused on the problem (satisfying acceptance criteria and design) while the driver is focused on technical details (syntax, shortcuts, stubs, tests…). It stands to reason that pairing prevents mistakes due to context switching, thus solving problems more thoroughly and with fewer mistakes.

P.S. – I asked Wendy to pair with me on the verification. Next time I won’t be so lazy and I’ll help her do the data entry in the first place 🙂

By: Ryan Shuya

Categories: Point2 - Technical Tags: , , ,

Creating a Fitnesse Wiki Widget

April 2, 2009 Comments off


We are using Fitnesse to acceptance test our REST apis.  One of our calls requires that a UUID be created and then used in several places throughout the test.  The syntax we wanted to use was :-

!define myUUID ${!uuid}

This however is not possible, because the !define widget in fitnesse does not support value interpolation.  So, we hit on a revised syntax which looks like this:-


This assigns a randomly generated UUID to the variable myUUID, which is then referencable by the usual fitnesse wiki syntax ${myUUID}.  The implementation looks like this:-

import java.util.UUID;
import java.util.regex.Pattern;
import java.util.regex.Matcher;

import fitnesse.wikitext.widgets.ParentWidget;
import fitnesse.html.HtmlUtil;

public class GuidWidget extends ParentWidget {

public static final String REGEXP = “!uuid\\{[\\w]+\\}”;
private static final Pattern pattern = Pattern.compile(“!uuid\\{([\\w]+)\\}”);

private String varName;

public GuidWidget(ParentWidget parent, String text) throws Exception {
final Matcher matcher = pattern.matcher(text);
varName =;

public String render() throws Exception {
this.parent.addVariable(varName, UUID.randomUUID().toString());
return HtmlUtil.metaText(varName + ” assigned a UUID”);

public String asWikiText() throws Exception {
return “!uuid{” + varName + “}”;

When researching how to implement my own custom widget, I read several posts complaining that !define myVar {!MyWidget(thing)} does not evaluate the custom widget in the define widget.  Well, the ParentWidget class, which you have to extend, allows you to call parent.addVariable(varName, varValue) which does the magic for you.
The one slightly tricky part was that you need to register your widget in the file, and then make sure the new class is in the classpath of fitnesse (not your tests via the !path property).  To do that, all you need to do is add the compiled class to a jar, put the jar in your fitnesse runner lib directory, then amend the run.bat or  Our new run.bat looks like this:-

java -cp fitnesse.jar;lib\guid.jar fitnesse.FitNesse ....

When fitnesse starts, it reads all the widgets in the WikiWidgets property and loads them.  It then outputs a list of the widgets that it has added to the console out.

By: Chris Tarttelin

Focused Practice

March 23, 2009 Comments off

We all want to be better at what we do, right? But how do we go about improving our skills? I think the answer is the same, whether you’re an aspiring software developer, musician, martial artist, or whatever. The key is focused practice. You need to put time into developing your skill. You can’t just put time in either. It has to be focused time. This is time where you’re consciously thinking about your craft, critically analyzing your work, and looking for ways to improve it.

Some of this possible during your day-to-day life; but in my experience, you always get better results by setting aside a special block of time to work on a skill.

Code Katas

The best way I’ve found to apply this to software is through code katas. A code kata is a problem simple enough that developers of any skill-level should be able to solve them. A kata is also small enough to solve in a reasonable period of time. My learning process currently goes something like this.

  1. Pick a skill I want to improve at.
  2. Pick a kata to solve, and a language to solve it in.
  3. Solve the kata while focusing on how to apply that skill to the kata.

For example, let’s say I wanted to work on my TDD-fu. I would pick a kata that I knew reasonably well; in my case that’s the bowling problem. I would pick a language that I knew well, and had a good testing framework; that would be java and junit. I would then implement a solution while thinking about things like…

  • How much code am I writing per test? Should I be writing more? Less?
  • Is my test naming clear?
  • Am I remembering to think about refactoring every time I see a green bar?
  • Am I aware enough of what’s going on to know when I’ve made a mistake and chosen a bad test?

You can use code katas to improve your skills with just about any technique related to software development. Just to name a few, they work well for improving your pairing practices, new languages, writing good OO code, and learning new tools. You just have to pick a focus.

A Coding Dojo

There’s been lots of success stories recently about coding dojos. A dojo gives us a social context in which to work on our katas with other like-minded people. It’s a great mechanism to get feedback on your work, but the downside I’ve found is that a lot of people are intimidated by this. I think the best way to deal with it is just to work on a kata in your own time until you’re comfortable with it, and then bite the bullet and seek some feedback.

You can find more information about code katas and dojos at See the kata catalogue if you just want to get started. There is another list of problems I’ve found useful here.

By: Kevin Baribeau