jamesladdcode.com

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