jamesladdcode.com

I have not written a post for a while as I have been very busy working, developing Redline Smalltalk and looking after my twin boys. Recently I did get some free time and I needed a break from Redline Smalltalk and I picked up a book by Kent Beck from the top of my pile of books to be read. Yes there is a pile and there are about six books in it right now, there is even another Kent Beck book, which should not be a surprise to anyone as Kent is a great mind and his writing is worth your time.

The Kent Beck book I read was “Smalltalk Best Practice Patterns” and while you may think “what the! Isn’t this posts title about Ruby?” what I want to get across is that this book transcends a specific language and is applicable to any Object Oriented language and to anyone wanting to get a good grounding in “Best” practice and patterns of development. Having done Smalltalk, Ruby, Java and C++ I can see how each and every nugget can be applied. So regardless of your language choice you should choose to get this book.

So what does “Smalltalk Best Practice Patterns” have in it?

SBPP is a quick and easy read and it took me about 16 hours to finish it, but of course I am still thinking about the material in the book and how best to apply it. There are 92 specific items covered and a very good real world example and discussion of why. The real world, every day nature of the book makes it a must have, each section has the following elements:

• Title
• Preceding Patterns
• Problem
• Forces
• Solution
• Discussion
• Following Patterns

The appendix having a reference to each point making it great to have near by.  The book contains the following sections and topics:

• Introduction
• Patterns
• Behavior
  Methods
  Message
• State
  Instance Variables
  Temporary Variables
• Collections
  Classes
  Collection Protocol
  Collection Idioms
• Classes
• Formatting
• Development Example
• Appendix A:  Quick Reference

Being a big fan of immutable Objects I especially enjoyed the section on “Getting Method”. If you only adopt one thing from this book I hope it is about private getting methods, sometimes called “getters” or “accessors”. It is hard to stress how much better a large amount of software would be if it adopted this practice. This is how Kent puts it:

“Here’s the real secret of writing good Getting Methods - make them private at first. I cannot stress this enough.” and goes on to say “There are cases where you will publish the existence of Getting Methods for use in the outside world. You should make a conscious decision to do this after considering all the alternatives. It is preferable to give an object more responsibility, rather than have it act like a data structure.”

One comment from a reader, Kyle Brown is “The patterns in this book are absolutely fundamental to good Smalltalk programming. No one who calls himself a Smalltalk programmer should be without the knowledge in this book” and I would go so far as to say that no one who calls themselves an Object Oriented developer should be without the knowledge in this book.

Some friends of mine like to meet up regularly and discuss code and on Friday I caught up with Fredy and we discussed keeping Ruby code clean and dry by orienting it East. Fredy showed me the following Cucumber steps from his project as a starting point for a discussion:

1 Given /the Customer results table is sorted by Address/ do
2   @customer_page.results.header.address.click
3 end
4
5 Given /the Customer results table is sorted by Surname/ do
6   @customer_page.results.header.surname.click
7 end

We both liked the use of the page fixture “@customer_page” as it encapsulated the page being worked with and kept the steps focused on the business logic rather than how to interact with classes that manipulate web pages or swing apps. However, the rest of the lines were not good in my opinion, as they exposed too much information on the ‘how’.

This is how the discussion went:

James: What is line 2 meant to do ?
Fredy: It sorts the customer page results by address by clicking on the address column in the header row.
James: So why not have a method like ’sort_by_address’ and let it take care of the how by getting the results, it would be more readable* ?
Fredy: But what is there (on line 2) is readable.

James: Which of them ‘results.header.address.click’ or ’sort_by_address’ conveys the business intent?
Fredy: I guess ’sort_by_address’ does, but it is only one line and it is done.
James: Sure but it isn’t East Oriented and therefore you are missing opportunities to keep the code clean and dry. See line 6, where you repeat yourself.
Fredy: You and your East thing. (In a sarcastic tone) Ok, tell me how East will help as Im dying to know?

James: For a start you are asking the object with the information for that information rather than telling the object with the information to do the work.
Fredy: But I am using ‘Tell Don’t Ask’, I’m telling the customer_page to give me the results.
James: That isn’t ‘Tell Don’t Ask’ as I understand it, which is also why I call it East and have rules to ensure code is East Oriented. With East you can’t have a public method that returns a value like results, so you would have to ask the customer_page to do something else, maybe ’sort_by_address’ ?
Fredy: Some code has to get the results and sort them !
James: Yes, but it should not be a public method, since this leads to duplicate code like you have (lines 2 & 6) because when you ask for an object then manipulate it the chances that more than one piece of code will do the same manipulation is made higher since most people wont look through the codebase to find the same manipulation and make it common. By going East you greatly reduce this possibility and put the functionality in an Object where it can be refactored to remove duplication.
Fredy: Lets assume line 2 and 6 are East as you suggest, how is that removing duplication and besides now I have an explosion of methods on my page fixture object ?

10 Given /the Customer results table is sorted by Address/ do
11   @customer_page.sort_by_address
12 end
13
14 Given /the Customer results table is sorted by Surname/ do
15   @customer_page.sort_by_surname
16 end

James: Now the methods are all on the same object and not spread across lots of other objects making the opportunity to refactor them into a single method more obvious. For example, ’sort_by_address’ can become ’sort_by’ and take an argument indicating the sort criteria. So your code can now look like this:

20 Given /the Customer results table is sorted by (.*?)/ do |criteria|
21   @customer_page.sort_by criteria
22 end

James: Which is East, reveals the business intent and provides a generic step that can be reused wherever a Customer results table needs sorting without you adding more code. If you follow these changes through the code you should see that going East made the code more DRY and reduced the count of public methods on several objects. As a bonus if the Business decide they want to sort using a keystroke rather than a click you only have to change the code in one spot.

Fredy: I guess I could give the ‘East’ thing a try. Would you help me ?
James: Sure.

*I made a mistake here in the discussion by using a value word like ‘more’ since what is actually more readable to one person may be less readable to another. I need to remind myself not to use ‘value’ words like ‘more’ or ‘better’ in these sorts of discussions.

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 !

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 use Complexian in my Java work and it is simple and fantastic, and now Marty Andrews has released a tool similar to Checkstyle but for Ruby. It is called Roodi. I’m sure this will be another simple and fantastic tool. Check it out here on Marty’s site. Btw - Thats Marty in the pic.