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.

Today I used my electric shaver thinking it would be quicker and do the same job as a standard shaver but I was wrong. While it started off quicker since there was no warming the face, shave cream or basin of water to get ready, the net effect is it took longer and I have a bigger shaving burn than when I use a standard shaver. Now I remember why I take the time to shave with the standard shaver and why the electric one sits idle in the bathroom cupboard. Taking a little more time produces a great and comfortable result.

Some BDD specs I see leave me feeling a bit of electric shaver burn as well as a dissatisfaction in the result and I wonder if just a little more time is all that is needed or if the point of BDD is being missed. For example I see this sort of spec (not from actual project):

describe TheClassRoom do
 it ’should not have more than 30 students’ do
  the_class_room.students.size.should_not > 30
 end
end

While this works it appears to me to be testing an implementation and not a behavior of TheClassRoom and it irritates me like shaving burn. It is quick to write this sort of code but I don’t think it helps in the long run. It exposes implementation and it doesn’t tell you much about the behavior of the ‘domain’, for example, why must a class room have no more than 30 students ?

Taking a little more time to craft the behavior can reveal a lot more about the intent of the system, and like the day to day practice of shaving can become quicker and yield a result that burns less, at least to me. For example:

describe TheClassRoom do
 it ’should conform to class room policy’ do
  the_class_room.should have_the_regulation_number_of_students
 end
end

This approach does require the creation of other classes like spec matchers and therefore take longer to write, but in the long run the result should be more readable and manageable. For example in the first approach when the count of allowed students is changed then both the code and the ‘it’ line have to change and with the second approach only a matcher would change.  Given that refactoring tools are not that great at handling comments, I’m keeping code out of them. The matcher is also a more reusable approach.

There are advertisements and continuing sales for electric shavers so I expect they work for some people, but I’m not a fan and prefer to take a little more time. For now the electric shaver is going in the bin.

I have finished reading The Rails Way, by Obie Fernandez and it was an excellent read, covering all the aspects of developing web applications in Ruby with the Rails framework that one could want in an introduction. All the parts are covered in some detail, and I think it would be hard to find something you would need to get a Rails Application done that is not covered. However, a little more detail on Production Web Server tools and deployments would have been nice and maybe that is covered in the Second Edition of the book. The Sections are logical and the examples clear and useful, with lots of sidebars outlining Ruby and Rails idioms and the thinking in the community which adds a realism balance to the theory. I have not been coding in Ruby long enough to comment too critically, but I would say this is a good book to have if you are planning to ride the rails.

I have a dream of a new Smalltalk!

I first read about Smalltalk in the 1981 issue of Byte magazine when I was in high school but it was not until 1986 that I got to use it commercially. I loved it instantly and I know you would too if you gave it a go.  You can get a quick overview of Smalltalk from here: http://www.outbacksoftware.com/smalltalk/smalltalk.html and there are plenty of Smalltalks for you to download and try.

My dream is for Smalltalk to make a comeback and be available on the Java Virtual Machine (which incidentally owes a lot to Smalltalk). This is what I would like in that Smalltalk:

• A file based environment since this is what people are used to.
• A transcript / console you can run interactively from the command line / shell (like Lisp, Ruby and Python etc).
• A Web Development framework based heavily on Rails, since this is a leading framework and one that a lot of people are interested in. Sorry Seaside as you are great but sadly not great enough.
• An ORM framework like ActiveRecord. (EDIT: Apparently this is already available.)
• IDE support for Eclipse, IntelliJ and TextMate.

I want all this on top of the Java Virtual Machine because this is the only approach that appears likely to make it in the Enterprise where things that don’t run on the JVM are shunned. I have had many people say that a Smalltalk on the JVM would be slow but lets face it, there isn’t anything on the JVM that isn’t slow so this isn’t a good excuse to me.

Why not just use JRuby? I am and I like it but Smalltalk has a simplicity and a pedigree that appeals to me more and I think if you tried it you would like it.

Would you support my dream and show support by following my request page on twitter which I hope to show to those at Sun and Cincom who might be able to make this dream a reality ?

http://www.twitter.com/jamesladd