Sarah Taraporewalla's Technical Ramblings

This blog has now moved

2008-09-30T13:19:00.002+01:00

This blog has now been moved to:
http://sarahtaraporewalla.com

You can subscribe to the feed:
http://feeds.feedburner.com/sarahtaraporewalla

How many O's in Woolloomooloo*

2008-09-24T07:45:00.003+01:00

I am often asked how to pronounce my surname. It's not too difficult, but for your benefit, I will now attempt at a phonetic guide to my last name.

Essentially, it can be broken down into 3 parts: tara - pore - walla**.

Tara

pronounced ta-ra. Like the girls name; like the house in Gone With The Wind (but without Vivian Leigh's accent please.)

Pore

pronounced like pour or poor. The 'e' is silent.

Walla

pronounced wa-lla. Not wall-a.

Put it all together and you get : ta-ra-pour-wa-la

I hope that helps.

Please feel free to let me know how you thought it was pronounced or spelt.

* The title of this post comes from a riddle by C.J.Dennis:

How many O's in Woolloomooloo?

Two for the W, two for the M

Four for the Ls and thats plenty of them.

(Woolloomoloo is a suburb of Sydney, Australia)

** Oh - and I have one vowel for every consonant (I always lump the double Ls together)

ReSharper - Saint or Sinner

2008-09-11T07:32:00.003+01:00

I love ReSharper. It makes life in Visual Studio such a breeze. You are just so productive in it, with all of its navigation tools, code completion and automatic refactorings. I tried to use Visual Studio without ReSharper the other day - it was so impeded that I swapped computers after about 5 minutes work (mind you - when I swapped, I redid the work in about 30sec).

But, sometimes I think ReSharper makes you, the developer, dumber. Or maybe not so much dumber, but definitely less in control of the code, and therefore makes the code wild and messy.

Before I used ReSharper, I had quite a lot of information about the code base in my head. I knew how classes connected, which files and namespaces they belonged to, what the model looked like. A file rarely got too long, because that would mean I would have to scroll through the file to look for my desired class. If something had changed within a class, like the addition of new methods, I would recognize it quickly regardless of whether it was in the code path I was following.

Now, I only find new features when I actively look for them. I find files that are quite long because I never look at the whole file, only the method that ReSharper brought me to when I used it to navigate a code path. I can't describe how the classes are connected, what namespace or class individual methods are in. And the reason - because I gave ReSharper the power. I stopped being in charge of the code. I stopped inspecting the code base.

Are we too becoming lazy? Are we reverting back into old, bad practices because ReSharper makes it just so darn easy to use? Are we becoming dumber?

Say the right thing - don't just do the right thing.

2008-09-07T10:48:00.005+01:00

Often, I see tests like the following:


public void SuccessulUpdateOfCarDeatilsShouldReturnSuccessResponse()
{
 CarController controller = new CarController()
 
 controller.UpdateCarDetails(0, string.empty, string.empty, string.empty)
 
 Assert.AreEqual(200, controller.Response)
}

This conveys to me two things about the author of the test:

They treat tests as second-class citizens
They have no respect for me, the unknown reader of the test

Let me explain. I could be viewing these tests for a variety of reasons - to add new tests as bugs have appeared, to alter the functionality of the unit-under-test, to understand the unit-under-test ... etc.

Before I can understand what the test is actually testing, I need to look at the signature of the class (ie open the file, navigate to the constructor...) to determine what the string.empty and zeros are representing. This takes extra effort on my part to understand the intent of the test*.


public class CarController
{
 ...
 public void UpdateCarDeatils(int carId, string carRegistration, string colour, string engineIdentificationNumber)
 {
  ...
 }
}

It also makes life difficult, because I am not sure if they are there for a particular purpose (ie the test is testing how the method handles nulls/empty strings) or if they are there because the author thinks they they are unimportant to the test.

I prefer to explicitly call out my unimportant parameters, by passing realistic but dummy values. I would rework the above example into:


public void SuccessulUpdateOfCarDeatilsShouldReturnSuccessResponse()
{
 CarController controller = new CarController()
 
 controller.UpdateCarDetails(42, "car registration", "colour", "engineIdentificationNumber")
 
 Assert.AreEqual(200, controller.Response)
}

This way I can see at a simple glance at the one test file what the method expects to take as parameters. I tend to use 42 as my default dummy id value, so when my team mates see it, they know it is an id value (zero is often an indicator of an object which is not persisted).

By replacing the meaningless empty values, with meaningless values which explain themselves you run into less problems adding the new tests, refactoring or altering functionality as the reader understands the intent of the test. Now, the test not only does the right thing, but also says the right thing.

*Even with Intelli-J or Resharper, there is work involved to understand these values

Test names go wild

2008-08-26T15:41:00.000+01:00

Around Thoughtworks, there is much discussion about test strategies. The arguments range from setup vs inline; named vs anonymous; mocks vs stubs; high level vs unit level, and everyone has their own preferred techniques. While a lot of people talk about the virtues of either side, I wanted to talk about using test names wisely.

I have worked with Jay Fields, a man who is quite passionate about tests. His blog has a whole stream of entries around testing. One post which I believe caused a bit of a stir was his entry on the value of test names.

I understand where he is coming from, and if you are fortunate to be writing in Ruby, then your testing battles are half won already. If you use the gems like mocha and expectations, then testing is so natural, that you do end up with 2 to 3 line tests, one assertion per test and there isn't a need for test names because everything is so neat and understandable, that they become clutter.

However, if you are in a language like C# (which is what my current project is in) then testing becomes that little bit harder, a little more like running through treacle. Mocking is one example of this - compare NMock to mocha... well, actually don't bother because they can't compare. Mocha beats NMock hands down. On my current project, I started to use mocks as I would on another ruby-based project, and quickly switched to stubbed classes because it was lacking in far too many places.

So, sometimes your environments dictate which testing strategy you should use. But here is my plea - if you use test names, please oh please treat them with the same respect as you treat your method names.

My biggest problem with test names is that they may be perfectly fine when you write the code for the first time, but then sometime later someone starts refactoring the code base. Tests start failing (perhaps the requirements have changed, so the test failures are a good thing) and you fix the failing test...but not the test name. And so, a little while later you have a test which is similar to this very trivial example (and yes, I have seen tests like this):

public void ShouldContainOrderedListOfClients()
{
 Event first = new Event("AAA")
 Event second = new Event("ZZZ")
 Event[] result = Order(first, second)
 Assert.AreEqual(first, result[0])
 Assert.AreEqual(second, result[0])
}

Hang on - what the...? That test name has nothing to do with what is being tested. But which is correct - the test name or the test itself. And has there been a test which is now lost? Or has it moved? What is the source of truth?

Sometimes, knowing what the requirements for the unit in question are should be enough to fix up the offending item. Sometimes they are not.

My take home advice - think about what your test is doing before you begin to write the test. Perhaps you even write the names for 4 tests at once, before implementing any of them. That way you can focus on the test at hand, you don't have to be thinking of testing a whole variety of cases in the one test and your tests become small enough that you can easily identify when the test name differs from the test at hand.

Also, treat your test code not as a second class citizen, but as important, if not more important than your code. Tests give you a confidence in the application you are building. To increase your confidence in your tests, you need to increase the time you spend refactoring them and making sure they are testing exactly what they say they are testing, and that there are no holes where your code can fall through and fail.

Lists: Filter, Map and Reduce

2008-08-16T08:56:00.000+01:00

There are 3 very handy list functions which make dealing with lists a breeze: Map, Filter and Reduce. I have come to the belief that not everyone understands their power, so I will attempt to explain it.

Filter

The filter function (fairly aptly named) aims to filter out (remove) items from the list which are not wanted. Typically, the Filter will take a list to be filtered and a condition to be met. Filter will then iterate through the list, and check each item in the list against the condition and form a new list from the items which pass the condition. A practical example would be: you have a list of names, and from that list you want the names that start with "S", so ["Snowy", "Shelly", "Muffin", "Oberon"] would filter to ["Snowy", "Shelly"].


public bool FilterFunction(T item){
 return item.StartsWith("S")
}
public List Filter(List list, FilterFunction condition) {
 List filteredList = new List()
 foreach (T item in list) {
  if (condition(item)){
   filteredList.Add(item)
  }
 }
 return filteredList
}

Map

The map function takes a list and a function and applies the function to every item in the list. A practical example would be: a repository returns a list of Cars, but you need to have a list of the number of seats in the car, so [GWiz, SmartCar, CleverCityCar, PeopleMover] would map to [1, 2, 5, 9].


public R MapFunction(T item){
 return item.NumberOfSeats()
}
public List Map(List list, MapFunction mapFunction) {
 List mappedList = new List()
 foreach (T item in list) {
  mappedList.Add(mapFunction(item))
 }
 return mappedList
}

Reduce

Reduce is the hardest list function to understand (and explain). It is sometimes referred to as accumulate, fold, compress or inject. In effect, it takes the list and folds/compresses/reduces it down to a single value. Reduce takes a list and a function. It iterates over the list; it applies the function to the first item and a 'starting value'. The result of the first function will be used as the 'starting value' in the function of the next iteration. (Some implementations do not require a starting value, but start iterating over the second item in the list, using the first item as the starting value). A practical example would be: finding the total number of seats available in a set of cars, so using the example before of [GWiz, SmartCar, CleverCityCar, PeopleMover], the result would be 17 (1 + 2 + 5 + 9). The common example you will see regarding this function is finding the total of all the numbers in a list, so [1, 2, 5, 9] would yield 17.


public R ReduceFunction(T item, R accumalator){
 return item.NumberOfSeats + accumalator
}
public R Reduce(List list, ReduceFunction reduceFunction, R startingValue) {
 R accumalator = startingValue
 foreach (T item in list) {
  accumalator = reduceFunction(item, accumalator)
 }
 return accumalator
}

Summary

The filter function transforms a set (list) of items into a subset of the items.

The map function transforms a list of items in one type to a list of items in another type.

The reduce function transforms a list of items in one type to an object in another type.

Both Ruby and Python make excellent use of these functions, so if you would like to further your understanding, I would suggest using these.

I am lead to believe that C# has these functions, but only for array implementations (and definitely not on IList). I don't believe Java has these at all, but you could always create reusable methods which provides this behaviour.

Next time you start to write a foreach loop, have a look to see if what you are really doing is a filter, a map or a fold. You may find you save yourself a few lines of code.

Maybe null

2008-08-11T22:15:00.000+01:00

My colleague Andy posted today about Returning null considered Dishonest and while I agree with his sentiments, I disagree with his solution.

Andy's premise is that you should never expect or return a null object as "Returning null is dishonest. It requires others to check that we've upheld our side of the bargain". His solution is to throw meaningful exceptions within the method, so the happy path will return a not-null object, and the unhappy path throws exceptions.

This highlights one practice which I get annoyed with when I see it. Programming by exception is never a good idea. Exceptions should be reserved for exceptional circumstances only and should not contain business logic. If there is a possibility that the system can get into a state which returns null, then it should handle that situation, instead of letting it throw a tantrum and yell at the caller.

A better alternative would be to return an object which may or may not contain the value required. This Maybe object can have two implementations: when it can return the value, it returns a Something which contains the value; and when it cannot return the value (ie value would be null) it returns a Nothing (perhaps with a message detailing why).

To continue Andy's example of the Vending Machine which dispenses a drink only if enough money has been inserted and there is enough stock, we can take a look at how Maybe objects can be used.

public Maybe giveMeADrink()
{
 if (weDontHaveEnoughMoney)
 {
  return new Nothing(notEnoughMoneyMessage)
 }

 if (weDontHaveEnoughStock)
 {
  new Nothing(weDontHaveEnoughStockMessage)
 }

 return new Something(new Drink())
}

// Caller
Maybe[Drink] drink = giveMeADrink()
if (drink.IsPresent)
{
 SlideDownChute(drink.Force())
} else {
 ReportProblem(drink.Force())
}

To me its a much cleaner version, you are coding for the situations that can actually occur, and not relying on try-catch statements around the place.

My advice? Steer clear of exceptions and return Maybes instead of nulls.

JQuery is your friend

2008-08-10T07:56:00.001+01:00

Lately, I have had the opportunity to add some pretty funky usability behaviour on websites thanks to JQuery and some UI Plugins.

If you haven't used JQuery before - start now. It is really simple to add some really cool behaviour. Need to find all the checkboxes on your page? Then $('input[type="checkbox"]') returns the list of them. Methods are also chained, which can often make long unreadable javascript files more concise, and more verbose at the same time.

I have played around with sliders, treeviews, tablesorting, date pickers and ajax forms and they have all been a dream to implement. Typically, we would start estimating stories for one of these functions as a Medium, but then as soon as we found and used the plugin, we realised it was actually a Small.

Of course, not all plugins are easy to use, especially when looking at cross browser issues. My rule now is if it is not on the JQuery plugin list, then I won't even bother looking at it. I also note who has written it - you will notice that a large number of good plugins come from one or two authors - now, I trust any plugin that they write and will use it if there is one there. My other rule is to spend no more than 10 minutes trying to make it work. If after that time I still haven't got it working (on at least all browsers other than IE) then I look for another plugin, or I roll my own.

We have been loving working on the stories which require funky usability controls, so much so that I have introduced a new motto for my current project - jQuery is your friend.

It's not all fun and games however - you do need to be disciplined as to when and how to use jQuery, as testing your app may not be so easy with a lot of javascript obfuscation. I have found browser based testing tools like Selenium have problems interacting with the jQuery functions especially when you bind an element to a click or change event.

All in all, however, you will find it a dream working with jQuery.

Picking the right domain to model

2008-08-09T18:35:00.000+01:00

When designing your code, it is important to model the business domain. However, how do you know you have modeled the right domain? Sometimes you need to look beyond the domain objects, and see what you are actually implementing.

On my latest project, we started modeling what we thought were the correct business objects. Essentially, the project was to build online booking registration. The registration spans many pages (sections), has no session state (see Dan Bodart's blog under heading No Session State just persistent documents) and has a similar usability concept as described in Marc McNeill's blog.

Initially our model had discreet objects, and their complex relationship between them. We soon realised that what we should be representing was not these domain objects but actually the form itself.

So, we turned our model on its head and modeled the form instead. Now, the form consists of a list of sections on the form, and each section consists of a list of fields in the section. A field consists of a label, the value (which the user entered - represented as a string), validators (if this field have a value when submitting the form, or if the value has special qualities like a number between 100 and 1000) and converters (to transform the value from a string to the necessary type like integer). Representing it in this manner has the added benefit that we retain the user entered content, even if it was not of the right type.

We have been using this form based approach for a few months now, and I am sure it has really helped our progress. A new feature was requested the other day - the ability to turn off sections under certain circumstances. This has been quite easy to build with the form model; I don't know how much extra work it would be in the old design, but I'm sure a lot more complex.

What has this taught me? Don't just look at the forest - the tree may prove to be better after all.