Adventures with Scala and Vaadin - Part 2

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] 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"?>

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.

Adventures with Scala and Vaadin - Part 1

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.

If life gives you only lemons... throw them away

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.

A Nice Endorsement of Scala

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

The Pragmatic Bookshelf : Rockin' Good

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!

Pull systems - A metaphor

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.

Missing the mark on an agile principle

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?

Poor Past Performance, Future Pain

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.

An Introduction to Agile, Lean and Kanban

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.

BDD - Not so much

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.

DRM 1984 : A bad idea, even then

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.

How smart is Guy Steele!

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.


Now wash your .... wha?

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.

Godaddy hates me

I've just been on looking for domain names for a side project I'm working on. I hadn't checked in a while, so I popped in 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











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.

Open Source Puppies

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".

Kanban my book pile

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.

Erlang - Putting on the Ritz

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 on Kanban

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.

Why don't I write more Ruby?

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.

I still don't get twitter but .. it is fun .. @roblally