Rob Lally : Robert Lally

The next few examples in the book cover adding event handlers in more detail. I think we’ve beaten the ‘closures are definitely the best way to do this’ horse until it’d like us to stop so… I’ll move farther on.

When we get to Chapter 5 we come across an interesting section on resizing components. All components implement the Sizeable interface. The sizeable interface has methods for setting the height and width of the component. There are two choices for each of these methods - set the value as a float along with a unit of measurement, or set the value using a String with the value and the unit.

component.setWidth(12.5, Sizeable.UNITS_EM);
component.setHeight("23%");

I don’t find either of these choices to be that inspiring. Not bad, each is just a little sub-optimal, for my particular sensibilities. I’d rather type something that looks like

component.setWidth(7 pixels)

It is a small change, but one that I think makes the code look a little bit clearer, a little bit more expressive. So how do we make it work? Implicit conversions to the rescue. So what’s an implicit conversion? In short, by explicitly importing an implicit conversion into a scope, you give the compiler the ability to transform one specific type into another specific type if it needs to. That’s a hard sentence to understand, and it probably isn’t even correct ( any Scala boffins that want to correct me, feel free ). In practice it is easier to understand. Here’s the code that I’ve added to VaadinUtils.scala:

class Dimension(private val value: Number) {
    def pixels : String = value + "px"

    def percent : String = value + "%"
}

object Dimension {
    implicit def intToDimension(value: Int): Dimension = new Dimension(value)    

    implicit def doubleToDimension(value: Double): Dimension = new Dimension(value)
}

And then in the imports at the top of my class I import Dimension._ and, presto, I can now use 21 pixels or 34.5 percent ( or 21.pixels or 21.pixels() ) in my code.

What’s really going on? Well, as I understand it, when Scala sees an int with a pixels() method being called on it, it scouts around for an implicit conversion that it could apply that would make the code compile. Now, I’m sure that this sounds scary and dangerous, that’s why Scala is very conservative about conversions.

You’ll notice that I’ve had to define an implicit conversion for both Int and Double because Scala won’t even perform that conversion automatically. One of the things I like about Scala is that it gives you power whilst trying to minimise risk. Neat.

Kent Beck asked some interesting questions around the behaviour of the software community with respect to ‘getting paid’.

I’ve been irked by the behaviour of the community on this subject for quite a while. Personally I blame paranoid ass-hats like this. Harsh but…

It has come to my attention that people have misinterpreted my last story.

When they told me they wanted me to spend hours in focus group meetings, I laughed at them and walked away. Anyone who didn’t would be in the low-wattage light-bulb category.

End of message.

A few weeks ago I was on holiday in Las Vegas. In one section of the casino I was staying at, there was an area run by one of the big US TV networks where they were testing out TV pilots and newly shot episodes of TV shows.

As you passed by, they would stop you and ask you if you’d like to help them choose the future of TV. I thought it might be amusing, so I took a leaflet and listened to a thirty second pitch. Spending an hour watching a show and giving feedback might be fun - it was near the end of the day and I was tired and footsore from sightseeing.

They started out with “we’ll give you $75 to go through our process”.. hmm, that made it even more attractive. I can have a seat and a beer and pay for dinner with the proceeds. Then came the kicker. After watching the show, you have to participate in FIVE focus groups, each lasting an hour or so.

It turns out that the reason most TV shows suck is because the people who review them are morons. You’re staying in a casino, paying two or three hundred dollars a night for a room, and you’re going to give up a whole day to review a TV show for seventy five dollars. Anyone who’s not a moron would conclude that this is a pretty bad deal.

Strangely, there were people queueing up to watch the shows… I looked at them, and judged them in the light of the information I had. I stand by my moron theory.

Firstly, I’d like to thank all the people who’ve said nice things about the first three parts - here, on twitter and on various news-groups. Of special note is Mark Harrah, the creator of SBT. Not only did he drop me a nice note, he made a change to SBT so that the issue whereby you couldn’t usefully run jetty in batch mode is solved. Now that’s service!

I’d also like to apologise to the people who’ve been reading my blog on the web. I realise that I need to change to a variable width column layout so that you can actually see all of the code. I’ll get to it soon… honest.

Last time I promised I’d talk about continuous compilation and deployment. This is pretty complex, so try to keep up.

Normally to compile all the code and run jetty you’d type:

~/code/spike : sbt
> jetty-restart

Or some such. To get continuous compilation and deployment going you need to do this:

~/code/spike : sbt
> ~ jetty-restart

See the tilde on the second line? That’s it. That sets up file watchers to watch for changed files/resources and executes the specified action when it detects them

Want to run your tests every time the code changes?

~/code/spike : sbt
> ~ test

I’m sorry if you’d like an XML configuration file or something similar. We’re all out of complexity this evening, try again tomorrow.

Back to the Scala & Vaadin.

The next example, from page 40 of the Book of Vaadin is slightly more substantial. I’m hoping that Scala will let us make even bigger improvements to the code because we’ve more to work with.

The Java code:

public class WindowOpener extends CustomComponent implements Window.CloseListener {
    Window mainwindow;
    Window mywindow;
    Button openbutton;
    Button closebutton;
    Label  explanation;  

    public WindowOpener(String label, Window main) {
        mainwindow = main;
        final VerticalLayout layout = new VerticalLayout();
        openbutton = new Button("Open Window", this, "openButtonClick");
        explanation = new Label("Explanation");
        layout.addComponent(openbutton);
        layout.addComponent(explanation);
        setCompositionRoot(layout);
    } 

    public void openButtonClick(Button.ClickEvent event) {
        mywindow = new Window("My Dialog");
        mywindow.setPositionX(200);
        mywindow.setPositionY(100);
        mainwindow.addWindow(mywindow); 

        mywindow.addListener(this); 

        mywindow.addComponent(new Label("A text label in the window."));
        closebutton = new Button("Close", this, "closeButtonClick");
        mywindow.addComponent(closebutton);
        openbutton.setEnabled(false);
        explanation.setValue("Window opened");
    } 

    public void closeButtonClick(Button.ClickEvent event) {
        mainwindow.removeWindow(mywindow);
        openbutton.setEnabled(true);
        explanation.setValue("Closed with button");
    } 

    public void windowClose(CloseEvent e) {
        openbutton.setEnabled(true);
        explanation.setValue("Closed with window controls");
    }
} 

public void init() {
    Window main = new Window("The Main Window");
    setMainWindow(main);
    main.addComponent(new WindowOpener("Window Opener", main));
}

The free floating init() method is supposed to be placed into the Application class.

I’ve removed the comments and done a little tidying up of the structure: people have suggested that by not tidying the Java code in the earlier examples I was doing Java a disservice. I also removed the comments because I believe that comments are, for the most part, an abomination, a crutch that has removed the need for programmers to support their own weight and write clean code. As with most things, I could be wrong. I doubt it, but it is possible. I’m not egotistical enough to believe I’m never wrong. Just very, very rarely. Honest.

Transliteration:

package spike

import com.vaadin.Application
import com.vaadin.ui._

class WindowOpener(abel: String, main: Window) extends CustomComponent with Window.CloseListener {
    var mainwindow: Window = null
    var mywindow: Window = null
	var openbutton: Button = null
    var closebutton: Button = null
    var explanation: Label = null
    mainwindow = main
    val layout = new VerticalLayout()
    openbutton = new Button("Open Window", this, "openButtonClick")
    explanation = new Label("Explanation")
    layout.addComponent(openbutton)
    layout.addComponent(explanation)
    setCompositionRoot(layout)

    def openButtonClick(event: Button#ClickEvent): Unit = {
        mywindow = new Window("My Dialog")
        mywindow.setPositionX(200)
        mywindow.setPositionY(100)
        mainwindow.addWindow(mywindow)

        mywindow.addListener(this)

        mywindow.addComponent(new Label("A text label in the window."))
        closebutton = new Button("Close", this, "closeButtonClick")
        mywindow.addComponent(closebutton)
        openbutton.setEnabled(false)
        explanation.setValue("Window opened")
    } 

    def closeButtonClick(event: Button#ClickEvent): Unit = {
        mainwindow.removeWindow(mywindow)
        openbutton.setEnabled(true)
        explanation.setValue("Closed with button")
    }

    def windowClose(e: Window#CloseEvent): Unit = {
        openbutton.setEnabled(true)
        explanation.setValue("Closed with window controls")
    }
} 

class SpikeApplication2 extends Application {
    override def init: Unit = {
        val main = new Window("The Main Window")
        setMainWindow(main)
        main.addComponent(new WindowOpener("Window Opener", main))
   }
}

I’ve dropped this into a new file on my system src/main/scala/spike/Application2.scala.

To get it to run, you need to change the web.xml. Change the line:

<param-value>spike.SpikeApplication</param-value>

to:

<param-value>spike.SpikeApplicatio2n</param-value>

Yup, there’s a 2 on the end of the class name now. Fire up the app and have a look - we’re going to get pimping!

So, what do I want to change first? Well, if you look where the Buttons are instantiated you’ll see something that made my skin crawl. In an earlier episode I talked about the ugly anonymous inner class usage, but mentioned that it was probably the best choice. Best of a bad lot in Java as it were. This is one of the other choices. The button is being instantiated with a target object and a method name so that the button can call the method when clicked. I know why people do this, I’ve done it myself and in Ruby or Smalltalk it’d be idiomatic, people would be prepared for it, and it wouldn’t get messed up. In Java having method names as strings is always a bad idea. Amusingly, as if my sub-consience was trying to prove me right, I misspelled one of the method names not once, but twice. And when I ran the app.. it didn’t work.

Using method names as Strings and calling them by reflection isn’t a good idea. There are so many things that can go wrong - signature changes, misspellings, changes in visibility level, return type changes, exceptions etc. In Java, the belief that static typing protects you from these sort of problems means that developers just aren’t prepared for it. Thankfully, the SButton class we created earlier solves this problem in a nice type-safe, statically defined way. Goodbye reflection invocation.

One of the ugly parts about using reflection is that the methods you’re calling back to have to be public so that the reflector can see them. This leads to classes with odd “don’t call me I’m not what you think” methods.

This class also implements the WindowListener interface because it needs to respond somehow, and some of the class’ state is modified as a result of the callback. Implementing this interface here was the expedient thing to do, but it does mean that the class has a broader interface, implements an interface so that it can comply with the demands of its own internal workings and, if it wanted to listen to multiple child windows would need to jump through hoops to figure out which child window it was that was being close. I’m gonna get my closure tools out again.

package spike

import com.vaadin.Application
import com.vaadin.ui._

class SWindowCloseListener(action: Window#CloseEvent => Unit) extends Window.CloseListener {
    def windowClose(event: Window#CloseEvent) = {
        action(event)
    }
}

class WindowOpener(private val mainWindow: Window) extends CustomComponent  {
    private val openbutton = new SButton("Open Window", _ => createSubWindow)
    private val explanation = new Label("Explanation")

    private val layout = new VerticalLayout()
    layout.addComponent(openbutton)
    layout.addComponent(explanation)
    setCompositionRoot(layout)

    private var subWindow: Window = null

    private def createSubWindow: Unit = {
        subWindow = new Window("My Dialog")
        subWindow.setPositionX(200)
        subWindow.setPositionY(100)
        subWindow.addComponent(new Label("A text label in the window."))
        subWindow.addComponent(new SButton("Close", _ => closeSubWindow))
        subWindow.addListener(new SWindowCloseListener(_ => onSubWindowClose))
        mainWindow.addWindow(subWindow)

        openbutton.setEnabled(false)
        explanation.setValue("Window opened")
    } 

    private def closeSubWindow = {
        mainWindow.removeWindow(subWindow)
        openbutton.setEnabled(true)
        explanation.setValue("Closed with button")
    }

    private def onSubWindowClose = {
        openbutton.setEnabled(true)
        explanation.setValue("Closed with window controls")
    }
} 

class SpikeApplication2 extends Application {
    override def init = {
        val main = new Window("The Main Window")
        main.addComponent(new WindowOpener(main))
        setMainWindow(main)
   }
}

In the tidy up, we’ve gone from five instance variables down to four ( three of them immutable values), lost a constructor parameter that didn’t do anything, created a nice little reusable listener class, removed risky reflection invocation and removed ALL of the new public methods and properties. The interface of our class is now identical to the interface of our super class.

Some Vaadin at last.

Download Vaadin from here and unpack it. You only really need the minimal one jar download, but with documentation this well written it’d be a shame not to grab it all.

They have platform specific downloads because some pieces of the underlying GWT toolset use SWT. As far as I can tell, there’s no runtime platform specificity and I’m not going to be touching the GWT tools in this series, so don’t worry about it.

From the download copy the vaadin-6.0.0.jar file ( hidden inside the WebContent directory if you downloaded the full installation ) into your spike/lib directory.

SBT adds any jars it finds in the lib directory to the classpath. Old-school styling baby!

And now some code.

The first “why don’t you follow along at home” example from the Book of Vaadin is on page 24.

You need to configure the Vaadin servlet in the web.xml file. Sorry, back to the XML grindstone.

Insert this into the web-app element:

<display-name>myproject</display-name>
<context-param>
	<description>Vaadin production mode</description>
	<param-name>productionMode</param-name>
	<param-value>false</param-value>
</context-param>
<servlet>
	<servlet-name>Spike Application</servlet-name>
	<servlet-class>com.vaadin.terminal.gwt.server.ApplicationServlet</servlet-class>
	<init-param>
		<description>Vaadin application class to start</description>
		<param-name>application</param-name>
		<param-value>spike.SpikeApplication</param-value>
	</init-param>
</servlet>
<servlet-mapping>
	<servlet-name>Spike Application</servlet-name>
	<url-pattern>/*</url-pattern>
</servlet-mapping>

The web.xml will now route all requests through the Spike Application servlet that’s will look for the spike.Application class. I’ve changed the class and package name from the example to match the project and to keep package hierarchies short-ish.

The original Java code on the first example looks like this:

package com.example.myproject;

import com.vaadin.Application;
import com.vaadin.ui.*;

public class MyprojectApplication extends Application
{
    @Override public void init() {
        final Window mainWindow = new Window("Myproject Application");
        Label label = new Label("Hello Vaadin user");
        mainWindow.addComponent(label);
        mainWindow.addComponent(
            new Button("What is the time?",
                new Button.ClickListener() {
                    public void buttonClick(ClickEvent event) {
                        mainWindow.showNotification("The time is " + new Date());
                    }
                }));
        setMainWindow(mainWindow);
   }
}

Not too bad. Particularly when you consider what it generates - a full page of HTML with a button with a server-side call back that displays the server time on screen in an area that fades out after a few seconds.

Not too bad, but I think Scala can do better. Stage 1 - Transliteration.

Create the application class:

~/code/spike : mkdir src/main/scala/spike
~/code/spike : touch src/main/scala/spike/Application.scala

Then edit the class so that it looks like so:

package spike 

import com.vaadin.Application
import com.vaadin.ui._
import java.util.Date 

class SpikeApplication extends Application {
    override def init(): Unit = {
        val mainWindow = new Window("Spike Application")
        val label = new Label("Hello Spike Application User!")
        mainWindow.addComponent(label)
        mainWindow.addComponent(
        new Button("What is the time?",
            new Button.ClickListener() {
                def buttonClick(event: Button#ClickEvent) {
                    mainWindow.showNotification("The time is " + new Date())
            }}))
	    setMainWindow(mainWindow)
   }
}

Start Jetty:

~/code/spike : sbt
>jetty-run

Then navigate to http://localhost:8080

Exciting - not so much. Still, the Scala here is pretty much identical to the Java code. It is nice to know that you can take a piece of Vaadin code and translate it without too much trouble. But if the Scala isn’t any better - then Java would be a ’safer’ choice.

Let’s see if we can pimp this code.

Hmm, I don’t like the inner class listener. In Java this is the best choice, in Scala we have more choices. Closures/Blocks/BlockClosures/Anonymous Functions/Lambdas/Anonymous Delegates/whatever you want to call them. to the rescue. We can create a button that takes a closure and never have to write one of those ugly little inner classes again.

Another thing that bothers me is that call to setMainWindow. Inheritance like this makes testing and TDD harder because I’m tied into the way the Application class works. I don’t like that. That’s not a game I’m going to play. I’ve an idea of how to extract us from that hole using abstract traits. But that can wait until I try writing tests.

After removing the inner class, slight blemishes in the rest of the code became more obvious so I’ve done a spot of in-lining and removed a few extraneous braces. I often find that once you can’t see the little pimples until you’ve removed the massive warts. Anyway, the code now looks like this:

package spike 

import com.vaadin.Application
import com.vaadin.ui._
import java.util.Date 

class SButtonClickListener(action: Button#ClickEvent => Unit) extends Button.ClickListener {
    def buttonClick(event: Button#ClickEvent): Unit = {
        action(event)
    }
}

class SButton(text: String, action: Button#ClickEvent => Unit) extends Button(text, new SButtonClickListener(action))

class SpikeApplication extends Application {
    override def init: Unit = {
        val mainWindow = new Window("Spike Application")
        mainWindow.addComponent(new Label("Hello Spike Application User!"))
        mainWindow.addComponent(
            new SButton("What is the time?", _ => mainWindow.showNotification("The time is " + new Date)))
	   setMainWindow(mainWindow)
   }
}

But, but, but, that’s longer I hear you cry. Yes it is. But the first two classes can be pulled out and stored away somewhere and you’re free of inner class event handlers for every button hence-forth.

The important part is the init method, isn’t that much cleaner than before? You create a window, add a couple of components and pass it on.

For my money, this is a win.

Swap this code into place, execute a:

>jetty-restart

and take a look to make sure it hasn’t changed.

Next time - continuous build and deploy and on to the next example.

So, where to start? At the beginning I suppose. I’ve decided to take the Book of Vaadin and, as I’m reading it, I’ll convert each of the examples from Java to Scala. Stage one will be transliteration, stage two will be ‘pimping’ and Scala-fying the code.

My Scala chops are still developing, and my Vaadin chops are non-existant, so if anyone wants to point out stoopid-noob-mistakes or ways to improve my pimping skills please feel free. Either drop me a line here or twitter me @roblally and I’ll try to rectify my mistakes.

As I talk through the process I’ve followed, I’m not going to mention IDE integration. I use the most excellent IntelliJ IDEA and the mostly excellent Scala plugin for it. Configuring the IDE is really outside the scope of this post, you’ll have to figure that out for yourself. Anyway, time to get going.

Stage One : SBT

SBT (Simple Built Tool) is a minimalist (well, it is minimalist now, and more features are arriving all the time) build tool for Scala. It isn’t the answer for every problem, but if things pan out the way I hope they will, it should be good for this little project.

Start off by downloading the SBT launcher : the installation instructions are simple enough.

Stage Zero : Java (preferably Java 6)

Yeah, I know, zero comes before one, but since I’m only going to say “Java - you should have some”, it doesn’t really matter where I put it.

Stage Two : Create a project

Create a directory to hold the project. I’ve used ~/code/spike - using spike in the XP sense rather than the Buffy villain fan-boy sense.

~/code/spike (3504) : sbt
Project does not exist, create new project? (y/N/s) : y
Name: spike
Organization []:
Version [1.0]:
Scala version [2.7.5]:
sbt version [0.5]:
...lots of output...
>

When I ran SBT in the empty directory it told me that there was no project found (anyone who’s surprised should stop reading now.. nothing to see here, move along) and helpfully offered to create it.

I entered the name of the project ’spike’ and hit return to accept the defaults for everything else.

SBT will now download everything I need to get my project going, including the correct version of Scala and SBT itself. Yes, all you downloaded was the SBT launcher, the full version is tied to the specific version of Scala you’re using so it helpfully has a neat layer of indirection.

You’ll notice that SBT has left you with an endearing little ‘>’ prompt. SBT can execute a command, or it can enter an ‘interactive’ mode where it will execute a command and then stay running, waiting to fulfil your next desire. Like a very limited genie, only capable of granting pretty crappy wishes. The scala compiler can take a few seconds to get warmed up, so this isn’t a bad idea. You can also tell it to execute commands whenever it detected file changes - very nice for those TDD aficionados, on every file save you can have all your tests run so you never have to manually poke the run button. When using two monitors I like to have a console with SBT running in file watcher mode running my tests on one monitor with my IDE on the other.

OK, OK, very nice auto test runner… neat but hardly revolutionary. Well, another neat but not revolutionary feature is the ability to run a hosted Jetty instance and restart that whenever files change. I’m hoping that will be a real win when we get to the point of actually having something on the screen.

We don’t want SBT running just now, though so:

> exit
[info]
[info] Total session time: 781 s
~/code/spike :

The default SBT project isn’t a web app, and doesn’t really know anything about them. Let’s fix that.

~/code/spike : mkdir src/main/webapp/
~/code/spike : mkdir src/main/webapp/WEB-INF
~/code/spike : touch src/main/webapp/WEB-INF/web.xml

Open the web.xml file in your favourite editor and pop in:

<?xml version="1.0" encoding="UTF-8"?>
<web-app
	xmlns="http://java.sun.com/xml/ns/javaee"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
	version="2.5">
</web-app>

My word, I’d forgotten what a pain in the ass it is to try to put sample XML into a blog posting. For that reason, if for no other, I’ll try to keep the XML to a minimum. I think we’ll have to define a single servlet, after that we can stay away from angle-bracket land for a good while.. maybe forever.

SBT is configured using Scala. Adhering to the convention over configuration mantra it has pretty sensible defaults. But since this is a web app, the defaults won’t cut it. We need to create a project configuration class.

~/code/spike : mkdir project/build
~/code/spike : touch project/build/SpikeProject.scala

And pop open SpikeProject.scala file in the editor/IDE of your choice. (We’re almost there.. honest).

import sbt._

class SpikeProject(info: ProjectInfo) extends DefaultWebProject(info)
{
  val jetty = "org.mortbay.jetty" % "jetty" % "6.1.18" % "test->default"
}

And our configuration is done. GENTLEMEN, START YOUR ENGINES! Or, developers of any gender, please start your web-server.

Run the following command once.

~/code/spike : sbt update

You need to do this every time you change your configuration. SBT will download your dependencies, but only when you ask it to. With everything in place

~/code/spike : sbt
> jetty-run

And there you have it! A web application that does nothing at al on http://localhost:8080!!!

Please note that I started sbt in interactive mode and then started Jetty. If you just run sbt jetty-run then jetty starts and promptly stops. Not as useful as you might imagine.

I know, I know, a second part has gone by without any Vaadin and hardly any Scala. Next time, I promise.

Over time I’ve been becoming increasingly enamoured of Scala. Like many technologies that I come to love, the first two or three times I try them I come away unsatisfied. I don’t know what it is, but some technologies keep me coming back until they click. Scala’s been like that. The first time I was put off by the apparent complexity of the syntax, the second time I was put off when I was stymied by the lack of a useable reflection mechanism. This time round… I’m happy and I feel at home.

So, I’ve been looking round at web frameworks in the Scala world, and there wasn’t a lot that pleased me. I can see why some people would like Lift - if it was 1998 and we hadn’t figured out that the only thing worse than having code in your markup, is having markup in your code. Maybe this is another one of those things I’ll come back to and have a click moment on. But, for now Lift goes in the “bad idea that works only because of the brain power behind it” pile.

So I started looking round for something that lined up better with my personal sensibilities. I’ve often been attracted to Echo, and it looked like it might be what I was looking for - a component framework that would let me write only in Java - or in this case Scala. Development of Echo 2 seems to be mostly at an end and Echo 3 is closing in on a production release.

I want to develop now, the “keeping up with Jones’” part of me doesn’t want to use Echo 2 and the “oh, god, the pain” part of me doesn’t want to use a beta release of a framework in an untested configuration.

Poking around the Echo home page, I came across this post mentioning Vaadin. From a development perspective Vaadin looked very similar to Echo - application centric, everything is written in Java, component based. And they’ve just released a new version (6.0) with some outstanding documentation including the very nifty Book of Vaadin.

I’m a sucker for a well documented open source project, so I’m trying it with Scala rather than Java, and I’ll document my experiments here.

Joonas Lehtinen, who I believe has a connection to Vaadin asked me to report to the Scala or Vaadin mailing lists - once I’ve got a couple of these posts up I’ll drop a link into the Vaadin forums.

PS I’m not picking a fight with the Lift people, I respect them and I wish them every success. I’ve bought the Lift Book and David Pollack’s excellent Scala book, so I’m doing what I can to support the community. Even though I think they’re off in the weeds. Dammit, I didn’t mean to type that out loud.

I’ve just finished listening to The Art of Teaching Entrepreneurship and Innovation by Tina Seelig, a podcast from Stanford’s excellent Technology Ventures Program.

One of the key points I took from the podcast came from a story where Tina had given a group of students $5 and challenged them to create as much value as possible in a set period. Those who did best were those who realised that the $5 was a constraint, not an asset and worked around it. Those who limited themselves to the question, “what can I do with $5?” didn’t do as well as the people who asked themselves “how can I generate value”.

My favourite response was the group of students who, instead of using their $5, sold the presentation slot, where they were supposed to present their results to the university, to a local company who came in and did an advertising pitch. This group realised that the assets they had transcended the obvious raw materials in front of them.

To make the point clearer, in future years Tina substituted the $5 for post-it notes or rubber bands. Whilst the results of people trying to generate value with only a handful of rubber bands was more amusing, I personally think the lesson about looking beyond the obvious was more important. But, Tina Seelig is obviously a smart lady, I’ll trust her vision.

Électricité de France - Alex McGuire hat-tip to Barry Carr for pointing it out.

I’ve bought a few books in PDF format from the Pragmatic Bookshelf (to go with the massive pile of dead-tree books I purchased from them) and I have to admit that I started off purchasing items only because I wanted early access rather than because I thought that PDF books were a good idea. That’s changed.

As the books have been updated over time, new versions have been made available to me and that’s something I really like. Today I got a notification that a new version of Travis Swicegood’s excellent Pragmatic Version Control using Git has been made available to me. I love these little presents, they’re wonderful little presents that cheer me up every time.

The thing that’s important and different about what the Prag Prog peeps do is that this isn’t just a final version of a Beta Book, it is a new version of a book that’s already in print. I purchased a book from Manning’s early access programme and as soon as the book went to print I lost the ability to download the PDF. I’m never buying another book like that from Manning.

With Manning I felt screwed, with the Pragmatic Programmers I feel like I’ve got more than I’m due.

Good job guys!

I was talking with my friend Clarke Ching today about Kanban and pull systems in general. I came up with a metaphor that we both liked and thought I would share it.

Problem : Imagine you want to get a ball of string ( your features ) through to the other side of a funnel ( your development team ).

Traditional methods involved pushing REALLY, REALLY HARD until it goes through.

Agile and other iterative methods realise that trying to force a whole ball of string through a funnel at once is madness, so they chop the string up into smaller pieces which are easier to push through.

Pull systems, such as Kanban, change the dynamic, rather than pushing the string through, they feed the tip of the string through and then pull it as fast as they can.

Which of these is best?

Well, traditional methods often cheat by mashing some subset of the string through and declaring victory. Or by making the team ( the funnel ) enormous so that you can fit a fairly large ball of string through the hole without effort. Or by minimising the features so that they’re dealing with a tiny ball of string. Or some combination of the above. I’m not sure this is ever a good idea.

Agile works pretty well, but the chopping takes effort ( iteration planning ) and consumes time. But it does break down into nice, neat iterations which provide clear points for releases, milestones, measurement and feedback.

Kanban works pretty well too, it might be slightly more efficient than an iterative Agile approach, but the milestone and release points need to be superimposed onto it since there are no natural break points.

Lean and ToC have their place here too - tools, techniques and strategies to make the hole in the funnel wider and to make sure that the string that gets through is the right string, used as efficiently as possible. Stretching the funnel as far as possible, just as I have stretched this metaphor.

I was reading through the principles page on the Agile Manifesto site today and I realised that I’ve never really been very good at one of the items.

The best architectures, requirements, and designs emerge from self-organizing teams.

I’ve managed a lot of teams, and for the most part, I’ve been deemed pretty successful. My management style was always to try to blend in with the team, to be one of them, to get people to move forwards by setting an example or by encouraging them. I never introduce or describe anyone as working for me, I always say I’m working with them or we’re on the same team. Of course, there are management activities that need to be performed (reviews, promotions, demotions, bonus awards etc), and I’m happy doing those things. I’ve never felt that knowing people, or treating them as the equals (which, of course, they are) hampered me in any way. The more closely you work with someone, the more of the real them you see. You get a better idea of their potential, their skills, their interests, ways in which they could contribute more to the organisation.

I’m actually lying when I say I’ve never introduced anyone who worked for me as a subordinate. My friend and mentor, Gerry Martin, who was instrumental in my decision to return to college and retrain in software, eventually came to work for me. Every time I got to introduce him as my minion, I got a kick out of it. But, hey, if you can’t poke fun at your best-friend, who can you poke fun at. (Sorry Gerry, you know I love you.)

My attempt at egalitarian leadership didn’t always work out as I intended. One of the things I didn’t consider, is that because I could ignore differences in organisational authority, it didn’t mean that others felt the same. This led to one incident where I upset someone through an ill-considered joke that left them feeling angry, impotent and embarrassed.

I feel that, for the most part, the people on my teams were given authority and autonomy, everyone was given the opportunity to contribute as much as they wanted or were able to. There was opportunity for decision making, direction setting, personal contribution, group collaboration and individual growth. But, were my teams self-organising? Not really. I was always there trying to guide people in the direction I felt we should be moving. Not by edict, decree or demand, but by persuasion, example and leadership. But, in the end, however gently the boss tries to guide you, you’re still aware that he’s the boss and his opinion carries more weight than merit alone. It wasn’t a democracy or a meritocracy: even if everyone disagreed with me silently or publicly, it wouldn’t have led to my replacement.

Is this a problem? Perhaps. I’m not sure what the alternative is. I firmly believe, that leadership is vital to the success of any organisation. By leadership, I don’t just mean “somebody has to be in charge”, I mean that someone has to accept responsibility and authority in equal measure and then use that authority judiciously, sparingly and only for the good of the organisation and all of its stakeholders.

Is a truly self-organising team possible in a commercial organisation?

I finished off Almost Perfect this morning and I must admit I was a little disappointed by the ending. All the way through the book I’d interpreted Peterson’s actions one way, and then, in the last fifty pages he started to spout his personal philosophy and I realised that I had been interpreting things in a more charitable way than I now feel he deserved.

One of the things that irked me the most was the section where he described how the employees had been asked to work long hours, six days a week for over a year and they’d done it because they were trying to help the company. Then he follows on with complaints about people being unprofessional and visiting the doctors or the dentists during the day. He complains extensively about anyone doing anything not directly work related during business hours - down to being angry at people for showing new baby pictures to colleagues - and then spends long paragraphs describing how productive he was during his afternoon tennis games, or how much he accomplished just by sitting on the beach relaxing and thinking.

“Hi, my name’s Pete. I’m inconsistent and unreasonable.”

I think he must have taken criticism about some of this in the past because the on-line version has a number of the later pages missing. The second-hand copy I got from Amazon was the complete text and the extra light it shone was, as is the nature of light, illuminating.

I’d still recommend the book to anyone who wants to read it. One particular section near the end of the book contained a valuable lesson.

Peterson had described their problems shipping enough copies of a new version of WordPerfect. A few years later, their next major release was due to ship, in the months leading up to their IPO. The launch went off without a hitch and first month sales were at a record level. Then they died off. The next month wasn’t much better. This unexpected, and un-predicted, drop off in sales hit their IPO hard.

During analysis of the slump, they discovered that because their distributors hadn’t been able to get enough product to supply demand after the last major release, they’d over-ordered for the release of the new product. Since they’d over-ordered, they were carrying extra stock and they didn’t need to re-order. This created a month one with unrepeatable sales, making all subsequent months look bad, and months two and three were bad by any standards.

Apart from all the usual lessons about judging sales based on fulfilment of only part of the supply chain rather than completed end-to-end transactions we’re left with a crystal clear example of human behaviour.

People will guess your future performance based on your past performance. It doesn’t matter what you say or do, a man, or a company, is judged by their actions.

Next Friday, the 29th May, Clarke Ching and I are teaching a one day workshop in Edinburgh entitled ‘An Introduction to Agile, Lean and Kanban’.

We’re charging a small fee (£30) to those who’re in full time employment: really, just enough to recoup the costs of renting the room. Entry is free to those who’re currently an ‘under-utilised resource’ (HR speak for unemployed).

If anyone is interested, please contact me at rob@ and I can provide you with details.

I’ve been mulling over my dissatisfaction with BDD, and I’m finally in a position to write down my thoughts.

In short, BDD doesn’t actually seem to be a coherent thing. There are many different perspectives on it, and many different tools with slightly different focusses. The only consistent thing is that the word ’should’ is required to be used anywhere that you would traditionally have used ‘assert’.

To be clear, my argument isn’t with the tools that have been developed: I’m not sure I have a need for ScalaTest or easyb or RSpec or Cucumber, but I think they’re interesting and I hope that future development will lead to something I find compelling. My problem is with the definition of BDD itself.

BDD started off being touted as a replacement for TDD. TDD was too hard, people confused TDD with a testing methodology, people didn’t understand TDD was about design, tests were too hard to read: so the BDD inventors and proponents suggested. Some of this may have been true, there are many people who fail to grasp that TDD was primarily, but not exclusively, about design. Dan North, Dave Astels and others decided that the way to reduce confusion was to change the name; which always reminded me of the way Borland decided to improve sales by changing their name to Inprise.

So here we have it, BDD is a replacement for TDD, now it uses specs and the word ’should’ rather than tests and the word ‘assert’. I thought it was a bad idea at the time because you don’t make things easier for people to understand by having more than one way to say things.

	assertEquals(oneWayToDoThings(), "good");
	many_ways_to_do_something shouldBe 'bad'

I have no doubt that the creators of BDD and RSpec had good intentions. I have no desire to challenge their integrity or their creativity.

As time has gone on, BDD has morphed into a creature that is neither fish nor fowl. BDD specs have morphed, in many cases, to be ‘executable requirements specifications’ which is a laudable goal, but leaves a number of holes.

If a spec is an executable requirement then it is written in customer language. If it is written in customer language then it is of no use as a tool for driving design of classes, methods, objects and functions. So, if this is the home of BDD then it isn’t a replacement for TDD it is something that lives alongside TDD. Mention this to a BDD proponent, though, and you get an argument. You can write specs that cover the same ground as unit tests. Yes you can, but what are the advantages of doing so? You’ll have wordy, obfuscated tests carrying the baggage added to make BDD more palatable for customers and, you still miss out on many of the benefits of TDD.

TDD, as a design methodology, forces you to write code that is used by two different clients: the tests and the final application. This is one of the ways that it helps promote flexibility. It gives you an early look at ‘how exactly am I going to use this class/object’. DBB frameworks don’t look or work like the code that will be calling the final code, so there really is no benefit here. Take easyb as an example, it doesn’t even use the same language as the code you’re writing (assuming the common use case of using easyb as a BDD framework for Java development).

TDD highlights pain points when writing tests, if it is hard to write a test for, your code probably needs a little work. BDD frameworks such as Cucumber, can quite happily support specs written in terms of ‘the system’ or ‘the application’ and you have to write grotesque code to make it work under the covers. This doesn’t make Cucumber a bad tool, just the wrong tool for the job of designing code.

So what is the output of BDD: User Acceptance Tests? Functional Tests? Unit Tests? System Tests? A system design? The design of individual units? It depends on who you talk to.

I’ve seen specs that are written from a customer point of view, useful as user acceptance tests. I’ve seen these mashed until they talk about an application in terms of controllers and pages and objects, making them useless as user acceptance tests because they’re not what the user agreed to and they no longer understand them well enough to re-agree to them. They’re also sub-optimal as drivers for design because they’re based on the implementation assumptions of the end user and they’re constrained to be about the subject matter that the user was originally talking about. This leaves lots of areas undefined where you need design but don’t have explicit user requirements because they just want it to work. The users will not tell you that they want to ensure that you have properly nested resource de-allocation blocks in your JDBC code because that’s not their domain. Do you need to have it? Yes, absolutely. Do you want it to work every time. Yes, absolutely. Will a badly designed solution make your code a pain to work with forever, yes absolutely.

So what happens? Developers have to write more specs, for things that users actively don’t want to know about.

I’m not convinced by BDD as a means of writing functional specifications either ( this doesn’t include User Acceptance Tests ). The best functional specs I’ve seen were elegant documents that used text, screenshots, charts, tables, diagrams, flowcharts and even embedded sound files to describe as concisely and accurately as possible the users expectations. Constraining these documents to a structured textual format is, at the moment, a bad idea. We’re reinventing Knuth’s Literate Programming ideas of the seventies, only we’re trying to impose it on clients and analysts too. There may be a future here, but I don’t think we’re here yet.

Particularly egregious offenders here are those cases where the functional specification is written in embedded strings in a document that is otherwise code. Conflating two completely different documents, and levels of abstraction into a single chimera-like whole that serves nobody well.

Ten years ago, I worked for a company where all development was done in UML and we forward generated the code from our diagrams. This didn’t work well, it was slow and painful but ‘technically’ it was possible so those in charge kept pushing the idea. Writing functional specifications using BDD frameworks is ‘technically’ possible but that doesn’t make it a good idea. Not here, not now.

We’ve learned new ways of building tools, and we’re looking for ways to leverage them. BDD isn’t AN answer, so it certainly can’t be THE answer.

I’ve been reading W.E. Pete Peterson’s excellent book Almost Perfect (available to read on line here) and he has some interesting things to say about his attempts to add copy protection to WordPerfect. At the time he was running WordPerfect Corporation and was one of only three shareholders, so his perspective isn’t an academic one:

“It was simply not fair to make the honest, paying customers put up with an inconvenience that had been made necessary by the dishonest ones. In the end, what was good for the legal customers was also good for our bottom line.”

The book has been a most entertaining and educational read. It’s great to read the story of an ethical, decent man who built by success without sacrificing his principles. Particularly heartening from a technologists perspective is that he attributes the companies early success to the quality of their engineering staff and their ability to hang on to smart individuals and focussed teams.

Sadly the book has been out of print for a very long time, but second hand copies are available on Amazon, that’s where I picked up my copy.

I just followed a link from Ralph Johnson’s blog to a presentation buy Guy Steele called Growing a Language. I’ve seen links to it for years but never taken the time to watch it. I wish I had.

Everywhere I go, I see the same thing. “The best way to avoid swine flu is to wash your hands after you go to the bathroom.”

So, if this advice were to be believed, the source of swine flu is one’s own genitals. This does not seem likely. I don’t understand why seemingly rational, intelligent people keep stating this again and again as if it made sense.

My penis is not the source of swine flu. If my penis had swine flu, then I’d have swine flu. I cannot catch a disease from myself.

When I say I can’t understand why smart people would relay this same, obviously bad, advice again and again I’m really lying. I can understand it. There’s a whole host of reasons but mostly it is people attempting arithmetic with small numbers and failing.

1. I should wash my hands after I use the small room
2. I touch lots of things with my hands and so they are a significant vector of infection

Washing your hands may be able to help reduce your chances of catching certain ailments. Or it might not. But it has nothing to do with making use of the WC.

Sadly this sort of conflation of ideas happens all the time in the programming world. People take some idea that seems reasonable, toss in a dash of something else reasonable, shake and concoct a third thing of ‘limited utility’.

Looking for an example: well, take much of BDD for a start.

BDD = Penile swine flu.

I’m just going to leave that hanging there for a day or so whilst I write up my thoughts properly.

I’ve just been on godaddy.com looking for domain names for a side project I’m working on. I hadn’t checked in a while, so I popped in roblally.com to see the status of it (please give it to me Irish Rob Lally… you don’t really use it). It still isn’t available but godaddy had some alternative choices for me, apparently Godaddy wants only bad things for me. Here are the choices it suggested

• DEPRIVELALLYLIVE.COM
• YOURDEPRIVELALLY.COM
• DEPRIVELALLYPRO.COM
• DEPRIVELALLYONLINE.COM
• BESTDEPRIVELALLY.COM
• EASYDEPRIVELALLY.COM
• DEPRIVELALLYSTORE.COM
• MYPILLAGELALLY.COM
• PILLAGELALLYLIVE.COM
• YOURPILLAGELALLY.COM

Why does Godaddy think I need to be pillaged and/or deprived so badly? What do they think I need deprived of? I guess I’ll never know, but if anyone comes near me at tonight’s techmeetup in a godaddy shirt I’m going to punch first and ask questions later.

I’ve written here, in the past, about my belief that, by starting an Open Source project, you’re making a commitment to the world. It seems that Rod Johnson of Spring fame and owner of successful Open Source company Springsource agrees with me.

Whilst being interviewed during episode 238 of The Java Posse Rod commented that he felt “Open Source projects, like puppies, are for life not just Christmas”.

One of the notions central to Lean and ToC, is that you can increase productivity by limiting the release of materials into the system.

This is quite a difficult concept to get to grips with. Intuitively, it just doesn’t seem right. Emotionally, it feels that this is exactly the opposite of what the truth should be. One of the reasons I’ve always found it so hard to keep this ideal at the forefront of my mind is because I’ve never found a way to apply it to every-day life. I’ve lived it in the business world, I’ve not lived it in my personal life. Until now …

I’m a spree shopper. I rarely buy just one of anything. If I’m going shopping for CDs, I’ll come back with three. If I go for a wander in a book shop, I’ll buy four books. DVDs .. yup, I’ll come home with a pile. But here’s the funny thing I’ve noticed. If I buy three CDs, I’ll rarely listen to them all enough to enjoy them. If I buy four films on DVD, one or two will never get watched. Being overwhelmed with choice, my mind rejects several of the options. And once I’ve rejected them .. I rarely look back. The extra CDs and DVDs I buy are, in the purest sense, waste. Worst of all, though, is my book pile.

At the moment, I have about ten or twelve books in my ‘to read’ pile. The, fascinating thing though, is that, the bigger the pile gets the less energy I have for reading. To start reading, I need to make a choice. That choice gets harder, the more options there are. And, since I’ve already read some of these books, I’ve had to reject most of the books in this pile more than once. What if I pick the wrong one? Why did I decide not to read this book last time .. I must have had a reason?

Then, when I do pick a book and start reading, my doubts start. Would one of the other books be more interesting? More informative? More fun? Better written? More up-to-date? The list of doubts piles up.

Then I start to read more than one book simultaneously and things get worse.

So, what’s the solution? Well, I’m going to control the flow of materials into the system. I’ve now got a bag, and a pile. The pile is something of a misnomer since it is a pile of one. I’ve tossed all the books I was going to read, except the one I’m currently reading and one book that I’m going to read next into a bag. The bag is not a pile, it is unordered. There is no weighting or relative importance that can be implied by position in the bag.

My new reading workflow:

• I’m reading the book I’m reading.
• I know what I’m going to read next.
• When I finish a book, I take my next book from the pile-of-one next to my bed and I can then pull/replenish the pile-of-one by choosing a new book from the bag.
• At any time before finishing the book I’m on, I can swap out the-pile-of-one.

I can’t explain exactly why this makes me feel better, but it does. There’s no longer this daunting meter high pile of books I’ve “got to get through”. I’ve got the book I’m reading, the book I’m reading next, and an opportunity to choose, not an obligation.

The overlap between GTD, ToC and Lean feels very strong here. I’ve always thought of GTD as Lean/Agile for one.

This feels good now, I hope it works out. I shall report back on my experiences.

Over the last couple of weeks I’ve been exploring and programming in Erlang. It has been an interesting, informative but challenging and frustrating experience.

Do you remember the scene in Young Frankenstein where Gene Wilder, playing Frankenstein and … whoever it was, playing the monster do the soft-shoe-shuffle and sing ‘Putting On The Ritz’? Well, the gag is that the monster, despite his grotesque, clumsy, clumsily-assembled form carries out the dance immaculately until, right at the end he sings his one line of the song. When he howls, “Puttin’ on a riiiitz’ I nearly wet myself laughing. Erlang’s like that.

Erlang is a horrid language, Damien Katz recently pointed out what he considered to be the flaws of the language, and I’d largely agree with his take on things. Actually things are worse than he makes out, he doesn’t critique the documentation which is poor and he doesn’t point out the problems of cruft and half-implemented abandoned features in the implementation. In response to his posting, someone in the comments points out that Erlang does have a package/namespace mechanism which is true. The topic of packages came up last week on the mailing list - someone pointed out that it didn’t seem to work properly. The answer they got was that that was put in as an experiment at the start of the decade, it didn’t work properly and that the implementers might take it back out at some point .. if they got around to it. Other features like module attributes have a similar story.

Katz chops away at some of, what he considers to be, the more egregious ugliness of the language, he doesn’t bother with the minor warts. But I find that there are enough of these warts that they become irksome. For example, macros have to start with a ? which leaves you code looking confused and ugly - why are there so many questions and so few answers? Lisp macros fit in with the language, they are indistinguishable from normal forms and so they create an extensible, grow-able language. Erlang macros stand out, they feel like something you should avoid because they are strange and ugly.

But, all these things said, I still find that Erlang and OTP - like the monster’s dance - has moments of grace, beauty and style. There are things in there to love. Erlang does processes and monitoring better than anything I’ve ever seen, it truly is remarkable in this aspect. If I needed to write an application where concurrency was more important than anything else, I might well look to Erlang.

So, Erlang, I’ve learned from you - I’m a better programmer for having spent a couple of weeks with you. But, for now, all I see is a monster capable of some clever tricks … and you’re going back in the box, until I need you.

David Anderson’s InfoQ talk on Kanban and software development is fascinating. In particular I liked the clarity of the numbers he produced to prove the successes of his methods. I also liked the photographs of the tracking boards that different groups were using, David’s analysis of them and the way they changed over time as groups came into contact with each other.

All in all, a thought provoking presentation that backs ideas up with concrete numbers.

I’ve been a fan of Ruby for a long, long time. If I had a real world problem to solve, and language was no barrier .. I’d probably choose Ruby, unless there was a solid reason not to.

Why then do I spend so few of my hacking hours poking at Ruby code?

I think it is because my hacking hours are spent twiddling with new shiny things or working through the same old exercises[1] in different ways, rather than trying to achieve something. As I mentioned a few days ago, I think it is irresponsible and unfair to release an app or library to the OS community unless you’re willing to support it, and I’m not, so I rarely build big projects. For the most part, how I solve the problem is more interesting to me than the problem.

I suppose it comes down to - I rarely use Ruby because I’m rarely trying to solve a problem as efficiently as I can.

[1] Uncle Bob Martin’s “Agile Software Development : Principles Patterns and Practices” contains an interesting little console programming problem that I’ve worked through in half a dozen different languages.

https://twitter.com/roblally

Does anyone remember the final episode of Blackadder Goes Forth? It is the one where Blackadder attempts to avoid being send to certain death by pretending to be mad. He puts his pants on his head and sticks pencils up his nose because .. well, people who do that are obviously insane.

I think that Richard Stallman is trying to pull a similar trick with this posting. I appreciate everything the man has done for the software community, but he seems to have transcended reality at this point. Maybe he’s frightened that with the current economic downturn that wold war is inevitable and that he’s going to be conscripted - he’s smarter than us all, and he’s putting his insanity defence in place right now.

I went indoor-climbing last night for the first time in over a year. Right now my arms hurt so much that I’d rather not have them. It’s not like they’re doing me much good just now anyway - my hands are largely incapable of closing and the opposable thumb seems like a dim and distant dream.

I did learn a few lessons last night, about climbing and about the way my mind works. When I arrived at the centre and approached the first wall, I realised that I had no idea how the equipment worked. I couldn’t remember how to tie myself on, and I couldn’t remember how to set up the belay end of the rope. That information had completely fallen out of my head. I’ve done it a thousand time but … I still couldn’t quite recall how to do it.

The bit I found most surprising is that I was sure I knew how, I was sure I’d forgotten nothing at all; right up until the point when I tried to do it. There’s a lesson there for all software architects (me included) - if you don’t write software regularly you will forget things about the process. Not only that, but you won’t know what you’ve forgotten. If you forget enough about the process you’re no longer an asset to your company. You’re just a guy who’s telling people how to belay, and keep other people alive, who can’t actually belay. Don’t be that guy.

My second lesson is about trust. I climb with my wife and my best friend. These are people I trust implicitly. I’d also given my equipment a thorough check over before I went out, so I was sure it was working fine. Even with that, I was terrified on my first few assents. Now, I don’t like heights, I hate them in fact. In the dictionary, under acrophobia it has a picture of me .. screaming whilst standing on a shoe-box. But I’d got over it whilst climbing, a year ago I could climb freely without fear. Now I was sweating and panting and wearing out my arms clinging onto the wall for dear, sweet life. Why?

To me, it seems that there are things that come naturally to us, and things that don’t. For me, being off the ground is not natural. By working at it, I got to a point where I was no longer afraid, then I began to enjoy it. At the same time it was good exercise that was helping me get a little bit fitter each time I went. When I stopped going, my confidence and trust in what I had learned started to erode and my natural fears and distrust started to come to the surface again. When we don’t practice something, we not only loose our understanding of it, we can start to believe things that are actively not true. Yes, brother architect, I’m talking to you again. Ever wondered why so many companies are lumbered with crappy products that the group architect purchased? Because they were out of touch, and began to believe the easy lies of silver-bullet vendors. They believed in the things that appealed to their core nature rather than the hard-won truths they’d struggled so hard to find.

When we don’t keep our skills sharp, we forget things. When we don’t practice our craft, we believe things that aren’t true.

In this week’s episode of ‘Rob Shows His Ignorance’, I’ve a couple of questions regarding power consumption and computers.

1. If I’m watching a video at native resolution - so if the picture is 640×480 I have it consuming that many pixels on my screen, will that consume less power than if it has to transform it to a different size/resolution? I imagine that there’s extra processing required to map it onto a bigger image, but I don’t know if modern hardware is sensitive enough to this level of work for it to be a noticeable difference. Will the GPU be able to work at a lower level? Is my basic premise reasonable? Since most video is compressed in some way, is there in fact an extra step required to transpose the picture onto a higher resolution or is that all taken care of within the decompression process? I ask, because I always have the impression that my laptop battery doesn’t last as long when I watch video in full screen mode as it does if I watch it in a window.

2. If I turn the volume up on my laptop, as I understand it, more power is being used to create bigger vibrations in the speaker. Now, I was watching a video (Bill Buxton’s Mix09 Keynote) and I noticed that there was a volume control on it. If I turn the volume up from within the flash application, I’d be surprised if it changed the amount of power running to my speaker so … it gets louder for the same amount of energy. Since even my twenty year old physics tells me that you can’t make energy for free .. this doesn’t seem right. What’s going on? Am I just deluded that my laptop controls volume by a variable resistor just like my great-grandfather’s crystal set?

It is at times like these, that I wish I had a background in EE so that I didn’t have to expose my vulnerable, underbelly of ignorance

After watching Dan Roam’s presentation, I decided to see what else looked good from Mix09. The day 1 keynote from Bill Buxton - available right now on the front page of the site gave me an insight into the mind of a designer that I didn’t have before.

Bill talks extensively about the history of industrial design and its rise during the great depression and that we can take the opportunities of the current financial crisis and use them to make usability design a priority.

I’m not sure if his logic, that crisis periods are inherently periods where design can prosper, is well founded but .. let’s hope it is. When you’re stuck in a financial hole, digging may not help but just sitting there doing nothing certainly won’t work. If innovative design and engineering can give us hope - let’s get to it.

Some of the ideas that Bill pushed strongly on were the notions that design has to be fast, has to be iterative and that only trying one approach to solving a problem leads to sub-optimal solutions. I’ve tried the first two of those ideas in development and they work like a charm. I wonder what it would be like to try to get several different solutions to the same problem in parallel? Perhaps that’s really what’s going on in the Java web framework world, or the .NET DI container world. Perhaps, rather than being frustrated by the problem of trying to learn and decide amongst multiple choices we should rejoice that we have options; we should be pleased that we get to choose the design that we believe in most.

The other big take-away that I got from Bill’s presentation was that in selling something you shouldn’t try to sell the item itself. You should sell the experience of using/owning the item. I can see this as a useful tool when trying to build software and also to make engineering decisions. Build software that will lead to a positive user experience and you’ll be a success. When considering two engineering alternatives, ask people to imagine the experience of living with that decision. Ask the technologist to put on his negative/remember-all-the-times-things-didn’t-work-the-way-they-should hat on and ask him to imagine what life would be like.

I’ve said it before, and I’l say it again. I love watching smart, passionate individuals talking passionately about their passions.

Mixing it up in Vegas: In this engrossing and entertaining presentation Dan Roam talks about his theories on sketches and how they unlock creativity and help communication and consensus gathering amongst groups.

I really enjoyed it, I’ll certainly try some of these ideas out, and I will probably buy the book. All those positives aside, three things do bother me about his presentation.

1. He starts off by saying that you don’t have to be able to draw at all to use his methods. That his ideas revolve around using simple shapes to communicate. Then he uses slide after slide filled with drawings that, whilst simple, are of a much higher standard than I could ever produce. (Yes I am that artistically challenged.) If simple diagrams are what you need to communicate .. why doesn’t he use any?

2. I’m willing to accept that using drawings as a means of communication engages parts of our brains that would otherwise lie dormant. What are the trade-offs? What are we sacrificing? Trading in my ability to logically critique something for my ability to create new ideas is something I’d want to do sometimes. When is it good, when is it not? Give me the down as well as the up.

3. I became suspicious when the Dan claimed that we can use pictures to solve any problem. That’s obviously nonsense. At best we might be able to describe any problem using pictures. Describing and solving are two different things. Don’t believe me? OK, well, all of my grandparents are dead. I love them, even those I never met. I’d like them back. Please provide me with the drawing that solves that problem.

Before I go any farther, I’d like to be clear that I’m a Black Pen Guy, When I talk, I like to stand in front of a white-board and scribble. I love to throw a marker to people and say, “show me what you mean”. Giving me a tool to make me better at design, communication and problem analysis is wonderful. That’s all you need to do to sell it to me.

Anyway, rants aside, this is a really interesting presentation with oodles of interesting ideas and anecdotes.

(Via Clarke Ching.)

I like the teams I run to use pair programming, because the end product is better. I’ve also heard lots of people say that they don’t want to do it.

I have a theory that pair programming is the brussels sprout of the technology world. Lots of people don’t eat them because, not because they think they’re bad for you, but just because they don’t like them

I have no children. When I do, they’ll eat brussels sprouts. I won’t do it because I want them to be sad, or to make those little sicky faces that children pull when they put something unfamiliar in their mouth. I’ll do it because I want them to be healthy, productive and to live a long time.

When I go to work I like to wear a suit. I also like to wear a tie. I like to wear thick, starched, stiff collared shirts with thick double cuffs. I like hard soled, thick leather shoes. I like to be aware of how I’m dressed, without being uncomfortable.

Why? It’s my war paint. In the same way that a Native American or a Massai tribesman or an ancient Celtic warrior put on face paint as a symbol that they were no longer at rest, they were now at war, and wholly committed to the task at hand. That’s how I want to feel when I go to work. I’m there, I want to get a job done. I’m committed. I’m not in the same frame of mind as when I’m at home with my wife watching TV.

Is it really necessary? Yes, for me it is. I like to make friends with the people I work with, the people I work for and the people that work for me. But friendship holds a trap. I’m not at work just to hang out and shoot-the-breeze. I’m there to create, to achieve and to add value. My war paint keeps me focussed.

I’ve just watched Zed Shaw’s THERE WILL BE PORN: 10 Dangerous Ideas Nobody Should Implement which thankfully contains neither porn, nor ten ideas. He sings, he plays music, he insults people he likes, he has some number of ideas that people should never implement which is less than ten that he talks about and he swears a great deal.

You know the old chestnut whereby both art and porn are hard to describe but “I’ll know it when I see it”. Well, this is neither. But for some reason I enjoyed watching it.

There’s a lot of history you have to have lived through to really understand it; you’ll know if you know. If you do, give his farewell speech a listen. If you don’t … he plays a mean guitar.

I’ve been working on my CV recently and finding it hard to quantify what I do and am. I’ve worked in almost every capacity in technology:

• Developer
• Process Engineer
• Architect
• Team Leader
• Project Manager
• Analyst
• Product Manager
• Programme Manager
• Service Delivery Manager
• Support Engineer
• Agile Coach
• RUP Mentor
• Technology Evangelist and Trainer
• Trouble-shooter

And a whole bunch of other roles that don’t even have good names. I’ve loved every one of these roles, I’m fascinated with every aspect of technology. Beyond that, I like to flatter myself that I’ve acquitted myself well in all of these roles. I love technology, I love managing people. I love guiding and participation of the creation of something out of nothing. Well, nothing more than sweat, tears, inspiration and a compiler.

I’ve always loved the idea of being a polymath, a renaissance man - but sadly my interests have always been restricted to one field. Luckily it is a pretty big field and there are few people that have become masters of it all. I’m not there. Not even close. But I’d like to be.

Everyone needs a goal in life. “Be the best you can be at the thing you love” works for me.

Here’s a rule of thumb I like to use.

Q. How do you know when a document is too long to be useful?

A. Print it out and try to slip it under the door of the person you wrote it for. If it doesn’t fit … it’s too big.

As a an addendum to my test; whilst you’re at the door, open it, go inside, and say hello. Nine times out of ten, that’ll do more good than the document.

In a post entitled, simply, Software, Rafael de F. Ferreira juxtaposes quotes from James Bach, Erik Meijer and an Alan Kay/Phil Windley amalgam to put together an intriguing argument that quality software doesn’t exist, people no longer care that quality software doesn’t exist, computing is in its infancy and we don’t know much yet, but we’re also not really learning so things aren’t getting better.

I’m not sure I buy it. In fact I’m sure it is bunk. I’ve said for a long time that The Software Crisis doesn’t exist. As an industry we create more, better software cheaper than ever before. WTF is the crisis?

Can we do better? Yes.

So why do people talk about a crisis? Because programming attracts smart, dedicated, attention-to-detail-oriented, meticulous, perfectionists who’re never going to be happy. People who’re always going to want to do better. For many people - including me - software is my art, my hobby, my career, my passion. I want it to be great. I won’t accept second best. I won’t accept shoddy or badly done or half-hearted. I want to build the best .. whatever the hell it is I’m working on.

Equally, I won’t accept people telling me what a bad job the software industry does any more. We don’t do a bad job, we do the best job of writing software that anyone ever has in the history of the world. Possibly the universe.

Can we do better? Yes. Can you beat me with the crisis stick? No, sir, you may not.

My good friend, Clarke Ching, today proposed that we reach out to universities and colleges to help them teach students the things we’d like them to know when they graduate. I’ve done some of this in the past working with universities and colleges in the US and the UK, it was very rewarding. I’d love to do more.

This trickle down from Reuters looks and sounds legit.

I’m not sure how I feel about this. Mostly positive I think. Sun has been chasing the client-side dream for the last couple of years ( well forever really, but with renewed vigour of late ) with twaddle such as JavaFX. Personally, I’ve written mostly server side Java. That’s what I expect to continue to do. If I was going to write client side code, I wouldn’t use JavaFX. I can’t think of a single reason why I would choose JavaFX over Flash or Swing or GWT or SWT or … anything.

Sun, who’ve been financially constrained for a long time, have been focussing resources on client side development and that has led to stagnation and lack of drive on the core Java language. Take the complete failure to deliver on closures for example - Sun had other priorities, so nothing happened. IBM sells hardware, lots of back end hardware. They make money out of said hardware and want people to write as many apps as possible for them. I have hope that they can deliver on the sort of roadmap that will make me happy.

I had a conversation with the head of Sun’s R&D department about three years ago. We talked about their hardware platform and the fact that they were producing hardware with massive numbers of processors and cores, and that each of the cores were comparatively slow. This sort of architecture seems ideal for hosting PHP/RoR/CGI/share-nothing apps and kind of poor for hosting Java apps. I asked him if he felt that was true, and what they were planning to do about it. He said, yes their hardware and software sweet-spots had diverged and that they had some ideas about how to realign their offerings. As far as I can tell, things are still the same today.

Don’t get me wrong. I like Sun. They’ve given me lots of free stuff, for a long time, and in return I’ve given them … nothing. That’s not quite true, I’ve had Solaris boxes ripped out and replaced with IBM Blades running Linux. So, I’ve given them less than nothing. Sheesh, no wonder their stock price has gone down the drain.

I’m writing this post because a lot of my friends are dyed-in-the-wool Java and Ruby developers who believe that nothing good ever came out of Redmond. I’d like them to think again.

Over the last few weeks I’ve been listening to podcasts that have come out of the .NET community: Elegant Code’s Code Cast, Scott Hanselman’s Hanselminutes and Herding Code and overall my reaction has been, “Wow, the Microsoft/.NET community is really starting to get to grips with Lean and Agile”. This wasn’t the case the last time I worked intensively with .NET about three years ago, back then it seemed that MS and .NET developers were living in the dark ages.

Listening to people working from within Microsoft talking about using Scrum and XP and Lean and how it is making their development better is heart-warming to someone who’s been pushing this message for the last ten years.

That Microsoft are dogfooding their own applications, and changing them to make them work better in support of Agile methods is fantastic news. Microsoft can do a lot of good if they support these ideas openly, and that seems to be their intention.

Microsoft isn’t just making strides in the process department though, the advances they’ve made in the CLR and the languages that run on it are really starting to pay dividends. As this post from Matthew Podwysocki shows, the generative effects of advancing the language and the platform.

That the .NET platform has been pulling ahead of Java in the feature department for a while now hasn’t been a secret. But now, for the first time, I’m starting to see people using these features and talking about these features to solve significant problems rather than brandishing them as ‘the new hotness’.

If only it wasn’t tied to Windows, I’d buy some.

Bob Martin has a presentation he gave at a JAOO conference up on InfoQ. The title of the presentation is Craftsmanship and Ethics, which is somewhat misleading since the presentation is basically on Software Craftsmanship prefixed with “we should be craftsmen, craftsmen should have ethics, it’d be unethical not to”. I was a little disappointed by that - I was interested in his thoughts on ethics and how they relate to the development.

Overall it is an entertaining presentation that will leave the Agile and SC groups nodding and leave those with a different mind-set shaking their heads as normal. I enjoy watching passionate people talking passionately about their passions… so this was fun; but I don’t think it changed any minds or taught anybody anything they didn’t know.

I’m assuming that the crowd at a JAOO event is composed of experienced professionals who care about and investigate their industry. To effect change it isn’t enough to speak passionately. It isn’t enough to tell experienced professionals what you think or feel - they have their own thoughts and feelings and there’s no reason they should supplant their own with yours. People need compelling reasons to change, they need people to provide compelling solutions to immediate problems, they need to believe that by changing they are shedding risk rather than increasing their risk profile. Passion isn’t enough.

Uncle Bob, and the other leading figures in our profession have the opportunity to speak directly to thousands, indeed millions of developers each year, and I don’t think that what they’re doing is working. The Tony Robbins style pitch is enough to get people fired up at the conference, it doesn’t carry enough momentum to provide a solid take-home.

I’m reminded of Geoffrey Moore’s Crossing The Chasm: Agile, Lean, Craftsmanship, all these ideas have been sold to the innovators and perhaps even the early adopters, we need to cross the chasm to get to the next group of technologists - the early majority. Even this isn’t enough, though. We haven’t got the message through to project mangers, business analysts or customers, let alone C*O types. We can present compelling cases when we talk to people one-to-one, but the ideas haven’t taken root in these communities; in Chasm terms we still don’t have a hook in the innovators there.

If we advanced the management and technology communities in parallel we’d have a much better chance of improving the way software development is done.

How do we do it? Well, first off, I think we need to stop talking about quality, top talking about Agile and Lean and Craftsmanship and start talking about value. Value is what everyone wants. Developers want to create value, managers want value created, customers want to buy valuable software.

I firmly believe quality leads to value, but telling people they should want quality leads nowhere. Tell someone they want value and they retort, “Of course I do, how do I get it?”. NOW you can say, “Well, every industry in the world has come to accept that building in quality leads to higher value.” At this point, I’ve never heard anyone say, “Hmm, that sounds hokey. Go build me some shit. I’m sure that my best path to value is by heading through latrine-town.”

When technologists, managers and customers talk about value, they may not all understand it in the same terms. At least not at first. But until they agree on what value is, there’s no way to build successful products or relationships.

The idea that people might not have the same understanding of value is something that many technologists don’t get right off the bat. To explain it, I need to take back something I said a few lines ago. I don’t believe that quality always leads to value. This also brings me back to Uncle Bob’s talk.

I have worked in environments where financial opportunities would arise out of nowhere, last for a few days or a couple of weeks and disappear. In these cases, the opportunity to make millions of dollars a day can exist if you can(in abstract terms) get information in, process it and send it back out within a specified time period. Oh, and the countdown on how long you can do this for has already started. Every moment between now and shipping costs a non-trivial sum of money. In these cases, value comes from shipping. The software might have problems - if it crashes every fifteen minutes night and day, that’s OK .. we’ll run ten copies on ten machines and have ten interns sit and watch them clicking the icon every time it falls over. The software doesn’t have passwords or security, that’s OK we can hire a rent-a-cop with a gun to keep people away from the computers.

Overall, doing this makes money. Sure, over the first few days the team try to improve the quality so that half the interns can go home - but the software is going in the bin in a week .. improvements beyond basic stability are a drain on assets nothing more.

I’ve heard developers shout about this being a terrible, shoddy way to do software and insult the developers who build it. I may even have been one of them. That’s because I wasn’t thinking about generating value with my software, I was only thinking about software for the sake of software.

Now I think about value, I can understand why people build software like that. I can also understand that we can get that software out of the door faster by looking at what we build in each case and trying to pull together some pieces that they can glue together the next time an opportunity arises. Pieces that’ll let us be EVEN faster to market next time. That’s value.

My point, value isn’t a universal truth. Value is relative to the situation. If everyone talks about value at the start, and forms a common understanding we can fit everything else into the framework this gives us.

Uncle Bob, luminaries of the development world, talk about value. Please.

This morning I opened up a copy of Dave Hitz ‘How To Castrate A Bull’ and I’ve been totally blown away. I read it cover-to-cover without standing up. This was unfortunate because I was in the bath. I filled the tub over and over with hot water until I was done because I couldn’t bear to stop to dry myself until I had got to the end.

Dave (someone else I’m on first name terms with by dint of having read his writings) tells of his experiences as a founder of NetApp. The book is filled with amusing stories and side-bars, coupled with sage and hard-won advice, recounting of failures and successes with equal honesty, passing on of lessons learned from others and a thousand tiny observations each a gem in of itself.

I only wish Dave had a second, parallel company at the same time so he’d have a sequel.

Damien Katz, and his family, sold their house and lived off their savings so that he could write free software.

His honesty and his story left me, literally, in tears. But truly inspired.

Please watch it.

Trying to get CouchDB set up, I’ve had to install macports. Macports is a neat tool that makes a lot of apps and libraries available for the Mac. Many of these are old-school Unix libraries and it seems that it isn’t just the code that the Macport team wanted to bring to the Mac - they wanted to bring the Unix user experience too.

I downloaded the installer and ran it. It gave me a lovely progress bar that pottered from zero to about seventy percent in 2 mins or so. Then it just sat there. After about twenty five minutes I tried to stop it .. and it said “No, I’m not going to stop”. Before killing it I decided to see if it was doing anything. I opened a terminal and ran top. It seemed that there were multiple rsync processes consuming CPU. Digging around I found that the installer was actually doing something - downloading files from the mother-ship. I decided not to kill it and another 20 minutes later it finished.

Why do people do this sort of thing? If they’d written an installed that flashed up a message saying “This could take a while” I’d be content to wait. Giving me a progress bar that just stops for most of an hour is madness, the worst possible UI decision. Showing me nothing would have been better because then, at least, it wouldn’t have looked broken.

I’m now all stressed because I have code on my system written by people who thought that UI was a good idea. What other insanity do they have in store?

I’ve now watched all eight episodes of Erlang in Practice a series of screencasts by Kevin Smith[1] and it was money well spent.

Having watched a expert write in Erlang for six hours, I feel I have a much better understanding of the flow of Erlang development. It isn’t as good as sitting down with someone and pair-programming, but it is as close as I can get. Watching someone write code is a very different experience from reading a book on the subject: each has something unique to offer. A book can teach you syntax and tricks and libraries and all of the static parts of a language, it can’t show you the way an expert thinks. The way an expert gets from A to B, the mistakes they make, the paths they go down before refactoring; things that even experts can’t tell you, but they can show you.

The only thing I didn’t like about the ‘casts were that on a number of occasions Kevin ( I feel like we’re best buds after spending the day together ) would make a mistake that I spotted and, no matter how much I yelled at the screen, I couldn’t get him to fix it. It felt like I was at the theatre shouting “look behind you” and the actors stubbornly refused to comply. That’s a minor thing, though. Informative, entertaining and (if you’re geek enough) fun.

I hope he does more.

[1] Sadly not that Kevin Smith, seeing Erlang written by Silent Bob would be great.

My foray into the World of Erlang continues. I’m excited and energised by the new and interesting things I’m discovering. Learning to think in terms of messages passed between processes isn’t easy, or natural yet; but I’m getting there.

I do have some concerns though. Erlang has been around for a very long time ( in computer years ) and has a few people who date back to the beginning still involved. Many members of the Erlang community are, however, quite new to the language and are working at trying lots of different ideas - some of them new, some of them translations of ideas from other languages.

What this means, for me, is that when I look around for a library to perform a certain task I’ll find a bunch of different options, each with a different approach, none of them are stable and none of them have any strong hints about their future. It seems that Erlang is such a fertile place for experimentation, and the community is so young, that projects spring up, are used briefly and are abandoned before they reach their potential.

Take web-frameworks for example. I want a UI for an app I’m considering and a web-ui would be just-the-thing. I looked around and there are loads of different web frameworks and web servers. I don’t have any trust that any of them will be actively maintained three years from now. I can’t create a critical dependency between my work and a project that may or may not have a future.

I’m not criticising people for their efforts (I will in a moment though) people are entitled to spend their time and efforts in whatever way they want. Erlang has drawn innovators, early adopters and those dissatisfied with the tools and options they had elsewhere. The relatively blank canvas is, I’m sure, what attracted many people to the language. There’s new ground to be broken, clean slates to be drawn on and blank sheets to be filled with ideas. All wonderful stuff.

The problem I have isn’t with innovation and creativity. The problem I have is with people who innovate, create, persuade other people to use what they are creating and then get bored and forget it. If you write up some code, dump it on git-hub and say “world, it is there if you want it” that’s one thing. If you create a project, put together a pretty project page telling people why it is cool and why they should use it then you’ve created a social contract you’re obliged to support your work. If you don’t want to make the commitment then don’t act like you are.

People who create, advertise and evangelise, then abandon open source projects are doing the world an active dis-service. Why?

• There’s only so much time and attention to go round. Many/most projects are not original - they’re similar to other existing projects. By creating an only slightly divergent copy of something you dilute the market of the original, reducing their chances of success.
• Open Source has, in most fields, killed off the market for commercial products. I don’t have the choice to pay someone for a quality product because the market has been devalued. Killing off the commercial market and replacing it with nothing is a distressing scenario.
• It provides an impediment to those who might follow through on an idea. Many in the Open Source community dislike the idea of forking or creating copy-cat projects. If you create an abandon-ware project you’ve added an extra barrier for others to cross.

Just to be clear here. I don’t have a problem with Open Source. I’ve used it for many years. I’ve spent some of the last few years providing technical support for Open Source applications and libraries. I’ve found good Open Source projects to be, without question, the equal of their commercial counterparts. I’ve watched innovation and change come from the Open Source community, positively affecting the entire industry. I like Open Source. I get annoyed by Open Source dilettantes and their here today/gone tomorrow behaviour.

I have an Open Source project of my own. I’m not going to point to it, because I don’t want you to use it. I made the code available for myself and a couple of other people. I have a disclaimer on it saying “there’s no good reason for you to use this” because it is treading old ground and I’m not going to maintain it. If someone finds it and uses it .. that’s fine, if nobody ever does that’s fine too. But nobody will ever believe that it is a project they can depend on.

So what’s my point?

The Erlang community right now has many smart people in it. They have lots of ideas and they want to try them out. There’s almost as many ideas as people, so there are mostly small communities and unstable projects. There’s certainly exceptions to this rule such as CouchDB and RabbitMQ, but in general I don’t see many significant communities building significant projects. For my benefit, and that of everyone else, I’d like that to change.

If you’re about to create a project or release some code you have as an Open Source project, please consider these question:

• If you have an idea that you’d like to try out, could you do it under the banner of an existing project?
• If you want to build a product, just like X. Could you contact the people who build X and help them out? You’d probably end up with something better than either of you could on your own.
• If you just want a creative outlet, do you have to start from a blank slate or would working with a community on something in existence be fulfilling?
• Would picking up someone else’s abandon-ware and carrying that forward be viable?
• Are you really going to devote the time necessary to maintain this for the next n years? Where n is a number that at least twice as big as you’d expect.
• Do you just want to show people something cool that you bashed together? If so, have you made it clear that this was just a one-off that you’ve made available to that people can learn from it or carry on if they’re interested?

Whatever else people may tell you, Java has been a success because of the communities associated with it. In particular the Apache Jakarta community was instrumental in making Java the phenomenon that it became. They had rules, they had standards, they had ethics and lots of smart people talking and building great things. Companies and individuals would adopt projects because they were Apache products - it was a name you could trust. The name and the community had respect and trust. Smart individuals looking to work on interesting problems gravitated there. Those with interesting ideas would go there and find other like-minded people to help them.

Erlang doesn’t seem to have that community, not yet anyway. But it does have enough people to create that community. At the moment they’re consumed by experimentation, and there is no central place or group that seems to be a likely candidate. Some languages never coalesce around a community and are forever fragmented and experimental e.g. Smalltalk. This isn’t necessarily bad, things are what they are.

Right now, I’m enthusiastic and energised, but I’m also cautious and concerned. Erlang looks like it could be ideal for the problem I want to solve; I just don’t think I trust the basket enough to put all my eggs in it.

Looks like I jumped aboard the Erlang train just in time. If I’d waited any longer I might have missed the chance to be Munctional.

I’ve changed. I’m surprised how much. A couple of years ago when I was playing with Erlang I thought it was OK, it had some interesting features .. but nothing special. I don’t know what has changed since then, I think perhaps it is all the time I’ve spent with Clojure, but I have a new appreciation for the beauty of functional languages. I am excited.

I’ve spent a few hours bashing away with Erlang now, and things have certainly come a long way since 2007 when I last devoted any time to Erlang.

Actually, not everything has come a long way. The only platform that you can get binaries for on erlang.org is Windows. I was working on Windows the last time I poked at Erlang so I probably didn’t notice this last time round. Compiling from source isn’t a huge deal but … this is 2009, if you want people to try something, forcing them to compile from source before they can try it out doesn’t seem like the path of least resistance.

After compiling I looked around for an editor and many fingers pointed to Erlide. I must admit, I wasn’t expecting much - I haven’t been pleasantly surprised by Eclipse plugins for off-the-beaten-path languages in the pase. I must admit, I’ve been pleasantly surprised by Erlide. It has all of the basic functionality I’d want and a little extra that I wasn’t expecting with some refactoring functionality that was released today. The one piece that doesn’t seem to be there is a code formatter, which surprises me as that’s normally one of the first things to get done. There may even be one in there somewhere and I just haven’t found out the incantation to get it going.

So, I have Erlang installed, and I have an editor/IDE. Next stop, some educational materials. I have Joe Armstrong’s book Programming Erlang which is a pretty good text, but I’d like to warm up with some shorter pieces, whet my appetite going and get me back into the flow of things. The main Erlang site has some pretty good tutorials here.

After getting back up to speed on language basics I need look through the libraries that are available. In 2007 there wasn’t much beyond the OTP stuff that ships as part of the Erlang distribution. That’s changed, there is now a plethora of libraries and frameworks, in various stages of maturity, that I’ll need to look into before I really have any sort of handle on Erlang development.

I watched The Watchmen on Friday, and it was truly splendid. I was going to write more but … I think I’ve covered it.

I got involved in a discussion a few days ago in the Scala mailing list. I made a statement based on an experience that was related to me, rather than something I’d tested for myself. Alexis Richardson disagreed with me and the commends I’d made about Erlang and RabbitMQ strongly, and said so.

None of the above is noteworthy, people disagree about things all the time. What is noteworthy is that Alexis remained calm, measured, polite and considered all through the discussion. This is such a pleasant change from the usual mailing list pattern that I thought it was worth mentioning.

As a tribute/thankyou to Mr Richardson and his well-mannered ways, I’ve decided that I’m going to give Erlang - a language that wasn’t on my list - a second chance, and try it for the personal project I mentioned a few days ago.