Profit on Technical Books

“If you like this presentation, feel free to buy one of my books, they have them up at the bookstore. Or you can just give me five dollars, I’ll make more money that way.”

Luke Hohmann (SD West 2006)

So in case you didn’t already know, writing a technical book isn’t a venture you undertake for profit. I have heard that the average technical book has a press run of about 3000 and that authors end up seeing very little after all the costs are taken into account. Does make you appreciate the effort people will undertake to share knowledge.

Are There Any JSF Best Practices

I attended a talk today at SD West 2006 really hoping to hear some hard earned lessons on better approaches to JSF development. Heck, the talk was entitled:

JavaServer Faces Programming and Best Practices

Unfortunately I got a high level overview of JSF and how great it is will be with JSF 1.2. The whole spiel about the 6 phase event life-cycle and how great it is that you have another XML configuration file and another tag library. It turns out the best practices are part of Sun’s blueprints.

The JSF blueprint stuff is almost laughable. They actually use this statement on how to do templating in JSF:

As we saw, a developer can simply create a layout with

1
<h:panelGrid*>

then copy and paste the same template to each page. This is a quick and easy way to develop web pages.

Creating a Common Look and Feel Using Templating

Great example of code reuse that cut and paste pattern. Isn’t that in the Gang of 4 Book as a classic pattern?

From what we heard the solution to most of our problems with JSF was to use Java Creator Studio 2. We got a quick demo of it. Nice clickity, click interface, you drag and drop a GUI widget and then link it directly to a database table, and you’ve got Enterprise Architecture.

As it turns out the most valuable part of the talk was gathering anecdotal evidence. Despite this being the only talk about JSF at the whole conference with 280+ sessions there were only about 30 people there. When she asked how many of us were using JSF only about 10 of us raised our hands. When she asked if people were using Struts virtually the entire room raised their hands.

The JSF story is still frustratingly incomplete.

Shaking Up JUnit with TestNG

At SD West 2006 today I attended a talk by Cedric Beust on TestNG entitled:

Beyond JUnit: Introducing TestNG, Testing the Next Generation

In 90 minutes he made a compelling argument for TestNG. It obviously has more features than JUnit and you can use the annotation features even if you’re stuck on Java 1.4 since they implemented it with Javadoc comments. I was able to install the IntelliJ IDEA plugin and get it up and running in about 10 minutes so I could play around with it. Some of the features you can do with the annotations include:

  • No need to extend any class.
  • Don’t have to start methods with <div class="codecolorer-container text vibrant overflow-off" style="overflow:auto;white-space:nowrap;">
    1
    test

    </div>

    .</li>

    • You can group tests using annotations like “functional”, or “integration” or “broken”.
    • You can allow parameters to be passed into tests.
    • You can stop running tests without commenting them out, say stick them in a broken group.
    • You can test threads.
    • You can set a <div class="codecolorer-container text vibrant overflow-off" style="overflow:auto;white-space:nowrap;">
      1
      successPercentage

      </div>

      so that a test that might be dependent on a flaky resource won’t just fail.</li>

      • You can specify the order tests execute in.
      • You can specify to use a skip option so dependent tests won’t be run if an earlier test fails.
      • A distributed option for running on multiple machines has been developed and should be added soon.</ul>

      It all sounds great. Why wouldn’t you switch?

      Well Cedric talked about the primary reason I don’t find it compelling to switch or at least not right now. Someone asked him why he hadn’t just asked Beck and Gamma about enhancing JUnit. They said fine until he told them he wanted to add an option to specify the order of the tests. At that point they said on philosophical grounds that they weren’t going to do that, non-negotiable.

      The point is JUnit is a unit testing framework that focuses on true unit tests. The idea that tests can be run in any order is a powerful supporting feature that helps force developers to write tests that test only individual small units of code. Many people still write unit tests that are more functional tests and cross multiple layers of an application or require a lot of setup merely to run. I have to agree that I fall in with Beck and Gamma here.

      My approach for now is to rely on JUnit for all developer unit testing, and do the integration/functional/acceptence tests in Fitnesse. One of my biggest worries is that developers start taking advantage of say labeling a few tests as “broken” in annotations and then not running those unit tests. The point is when a test gets broken it needs to be high priority to fix it or delete it if it’s no longer relevant. Labeling tests broken and just moving on supports negative practices. If we were further down the TDD path, I might be less worried about missteps, but that’s the future.

      Still, TestNG has a compelling set of features and especially nice use of annotations. If one of my developers wants to try it out for a future project, I’ll be completely supportive. It’s always a lot easier to evaluate the difference when you actually use the tool on real world code.

Jolt Award Winners 2006

Software Awards are funny things. At the Jolt awards these were the big soda can winners:

Quick thoughts are that Microsoft and Ruby cleaned up. I actually read the two books that won and I enjoyed both of them.

Behavior Driven Development

Today at SD West 2006 I took a hands-on session with Dave Astels on using rSpec. Dave’s primary message was we shouldn’t be talking about the word test in test driven development, but we should focus on behavior. Really when you’re doing TDD you’re specifying what the code should do not verifying that code works.

It’s an argument that seems to be picking up steam which is partly the idea of changing Test Driven Development to Test First Design or Test Driven Design. rSpec is essentially a replacement for xUnit in Ruby that focuses on nice English syntax for expectations in the form of:

should.have.at.least(5).items

I’ve seen something like this in Java as well with the JBehave project or Agiledox, but rSpec seems to be making some pretty nice progress. The exercise was to implement the game of Deflexion with a full set of expectations. It was a pretty well thought out exercise for a half-day tutorial and Dave was able to spend time wandering around answering questions effectively.

The surprising thing was I paired up with another developer who gets to do a lot of XP in his day job and we really marched our way through the tutorial. We managed to get through 24 tests, I mean expectations, in about 2.5 hours. Not that surprising unless you consider I’m a relative newbie to Ruby and he was a complete newbie, though probably a better pure coder. As a bonus I understand Ruby modules and their syntax a lot better now.

Anyway I’ll be working my way through the complete tutorial tonight, because Ruby and behavior-driven development is just a lot of fun.