jamesladdcode.com

I saw this on another blog and I liked it a lot. So here it is for you too:

In Jeff Bezos’ 2008 Letter to Amazon Shareholders there is a footnote with the following:

“At a fulfillment center recently, one of our Kaizen experts asked me, “I’m in favor of a clean fulfillment center, but why are you cleaning? Why don’t you eliminate the source of dirt?” I felt like the Karate Kid.”

So why do we refactor rather than eliminate the source of the dirt?

I recently got a copy of the book An Introduction to Seaside so I went for a quick trip to Seaside over the last week and it was refreshing and fun.  Seaside is a Web Application development framework for Smalltalk and the book is a well paced introduction to all you need to know to start writing Web Apps in Smalltalk.

An Introduction to Seaside was not available at Amazon so I ordered it through www.lulu.com, and received it in about 6 working days. The book is reminiscent of the original Smalltalk series of books complete with half tone boxes containing useful code (see image) which brought back lots of memories for me. The flow of the book is well structured and the links and references are very useful, like where to download a copy of Smalltalk for your platform, complete with a working set of Seaside libraries. I chose the Squeak download since most of the examples that detailed what to do in a Smalltalk environment target Squeak.

Some of the grammar in the book was a little wrong and I felt that the book could have been translated from another language into English, but none of the instances detracted from the introduction and instruction.

The book takes you through the development of a ToDo application which is a simple task but one that touches on all the things you may wish to do with a Web App these days, like security, persistence and Ajax support. I would have liked to see more information on testing but there are some solid links to the Smalltalk test frameworks.

Seaside itself is fantastic and I enjoyed working with it more than any other framework I have used so far for Web development, even those like Rails and GWT. The use of a ‘continuations’ approach to the web conversation and the real object oriented focus which you come to expect from Smalltalkers makes it a pleasure and *very* productive. If I had time I’d port it to other languages as a community service, since everyone should be able to develop Web Apps with this simplicity and productivity.

Should you want to know more then I encourage you to read A Quick Trip To ObjectLand to quickly understand Smalltalk and An Introduction to Seaside to understand Seaside. Give it a try, you won’t regret it.

After my post on Cucumber Salad a colleague Tal pointed out a more formal description of the approach I was describing.

A friend is using Cucumber to run his Behavior Driven Development and it isn’t turning out to be the elegance and joy promised on ‘the can’ so we got together to see what the issues were and how to lessen the problems he was having.

In short, the code looked a lot like this:

Given /Some starting state/ do
  lots of code to setup state
end

When /Some condition/ do
  lots of code to exercise condition
end

Then /Some behavior/ do
  lots of code to verify behavior
end

There was a lot of magic going on with variables being defined in one feature file and referenced across multiple feature steps and some steps even introducing more variables. The net effect was code that was tossed together, difficult to keep dry and impossible to refactor, like a cucumber salad where your task was to take the pieces out and reconstitute the whole original ingredients. It was quite a nightmare and it reminded me of the song from The Simpsons where they form a conga line and sing “You Don’t Win Friends With Salad.” So what could he do to clean this up and not lose friends with this salad ?

A simple approach is to create a fixture class that represents the application, web site or service under test and then only delegate to that fixture class in Cucumber related files. This approach keeps logic out of Cucumber files, the code in Classes where it can be reused, kept dry and refactored more easily. It is also easier to understand the code because it is all in one place. You can also use the fixture in other scripts to automate other tasks you might have.

For example, here is some Cucumber that uses the fixture approach:

Given /Signed In User is on their profile page/ do
  @theWebSite.open
             .sign_in('u', 'p')
             .navigate_to_profile_page
end

When /Changing Password/ do
  @theWebSite.select_change_password
end

Then /Change Password Form is Shown/ do
  @theWebSite.has_password_form?
end

Remember, you don’t win friends with salad !

Ok, a snoutbreak or hamthrax is no laughing matter.

In 2000 Australia was buzzing because we had the Olympic games, and I was buzzing too but not because of the games. I was about to fly to Sydney to pitch to Macquarie Bank for venture capital for my new idea. The idea was for a technology to enable two systems to communicate more easily without requiring additional programming. In a nutshell it sent Smalltalk between the client and the server in a similar way to how JSON works now. I even had a demo where you could speak commands into a microphone, they were converted to Smalltalk, sent to the server and the response came back and was spoken to you. I learned an important and expensive lessing during this time, that describing ideas with or without a prototype is hard, and that VC’s are more interested in what technology enables than technology itself. Aside from that I wish I could have described my idea in such a way that the audience just “got” it, and I could have if I had read “The Back Of The Napkin, solving problems and selling ideas with pictures” by Dan Roam before hand.

“The Back of the Napkin” presents a process for breaking down your thoughts, seeing their relationships and a framework for selecting the right diagram to best represent those thoughts when showing them to others. There is even a section on how to give the pitch once the thoughts and diagrams are ready, including a detailed example from start to finish involving a Software company and it’s lagging product. I think this example in itself is worth the cost of the book.

Dan presents ways to better ’see’ problems and discover your ideas, the SQVID process which is a series of five questions that refine our idea and bring out what is important to us and our audience, and  a process for developing and showing those ideas. It is easy to read and entertaining.  I think “The Back of the Napkin” is another one of those books I wish were mandatory reading at school since the process and framework could have served me so many times when I needed the audience to just “get” my idea.