Mark Needham

I've been playing around with Objective C over the last month or so and although my knowledge of the language is still very much limited I thought it'd be interesting to describe some of the things about the language that I think are quite interesting and others that keep catching me out.

Protocols

I touched on protocols a bit in my first post but they seem like an interesting middle ground between interfaces and duck typing.

I like the fact that protocols can define optional methods so that if we're not interested in some parts of the protocol we can just ignore those parts.

From the documentation page:

Protocols free method declarations from dependency on the class hierarchy, so they can be used in ways that classes and categories cannot. Protocols list methods that are (or may be) implemented somewhere, but the identity of the class that implements them is not of interest. What is of interest is whether or not a particular class conforms to the protocol

Smalltalkish style method names

We played with Smalltalk in a coding dojo a bit last year and the first thing that I noticed with Objective C is that the method names are very similar to those in Smalltalk.

I think this influences the way that we define the method name and its parameters as you try and define those in such a way that when you call the method it will read better.

For example I created the following method:

UILabel *aLabel	= [self createLabelFrom:project withXCoordinate:x withYCoordinate:y];

If I didn't have to name the parameters when calling the method I doubt I would have used such descriptive names. I would have just used 'x' and 'y' as the names!

All methods are public/Defining methods in header files

As I understand it all the methods defined on an object are available to any other object to call i.e. all the methods are public

I've read about others using categories to simulate the idea of having non public methods but I haven't tried anything myself yet.

Interestingly we get a compiler warning when trying to call methods on an object if those methods haven't been defined in the appropriate header file although the code still seems to execute fine at run time.

Messages not method calls

One other thing that I sometimes forget is that we're dealing with messages rather than method calls.

We still need to send the message to 'self' even if it's a message being sent to another method on the same object.

Last week we were trying to make use of Rails' 'form_for' helper to populate a dropdown list with the values of a collection that we'd set to an instance variable in our controller.

My colleague pointed out that we'd need to use 'collection_select' in order to do this.

We want to put the values in the 'foos' collection onto the page. 'foos' is a hash which defines some display values and their corresponding values like so:

class FooController < ActionController::Base
	def index
		# @mainFoo defined with some value irrelevant to this example
		@foos = { "value1" => 1, "value2" => 2 }
	end
end

The code we need to do this looks like this:

<%form_for @mainFoo, :html => { :name=> "ourForm", :id=> "ourForm" },:url => {:controller => "foo", :action => :bar} do | mainFoo |%>
 
<%= foo.collection_select :foo_id, {"Please select"=>""}.merge!(@foos), :last, :first, { :selected => "Please select" }, {:name => "foo", :id => "foo"} %>

The method signature that we're passing those parameters to reads like this:

def collection_select(method, collection, value_method, text_method, options = {}, html_options = {})

In this case we want the selected value to always be 'Please select' so we need to specify that in the 'options' hash. If 'selected' wasn't specified in the hash then the code would try to make the selected value @mainFoo.foo_id which in this case has no value anyway.

The other thing which I thought was quite neat is the way that you need to provided the 'value_method' and 'text_method' as parameters so that the dropdown list can be constructed with the appropriate labels and values.

In this case we have the display values as the keys in the hash and the values as the values in the hash so we can retrieve those entries from the collection by using the ':last' and ':first' methods.

We end up in the following method:

      def options_from_collection_for_select(collection, value_method, text_method, selected = nil)
        options = collection.map do |element|
          [element.send(text_method), element.send(value_method)]
        end

This creates an array of arrays which is used later on.

In our case the values passing through this method would read like this:

        collection = { "value1" => 1, "value2" => 2 }
 
        options = collection.map do |element|
          [element.send(text_method), element.send(value_method)]
        end

 => [["value1", 1], ["value2", 2]]

I was initially a bit confused about how we were able to call the 'collection_select' method on 'mainFoo' but a quick browse of the ActionPack code showed that 'mainFoo' actually represents a wrapper around that object rather than the object itself.

One of the earliest rules of thumb that I was taught by my colleagues is the idea that we should try and avoid mutating/changing values passed into a function as a parameter.

The underlying reason as I understand it is that if you're just skimming through the code you wouldn't necessarily expect the values of incoming parameters to be different depending where in the function they're used.

I think the most dangerous example of this is when we completely change the value of a parameter, like so:

public class SomeClass
{
	public BigDecimal doSomeCalculationsOn(BigDecimal value) {   
		value = value.divide(new BigDecimal("3.2"));
		// some other calculation  on value...
		// and we keep on re-assigning value until we return the value
		return value;  
	}
}

In this case the function is really small so maybe it doesn't make that much difference readability wise but I still think it would be better if we didn't reassign the result of the calculation to 'value' but instead used a new variable name.

It wouldn't require a very big change to do that:

public class SomeClass
{
	public BigDecimal doSomeCalculationsOn(BigDecimal value) {   
		BigDecimal newValue = value.divide(new BigDecimal("3.2"));
		// some other calculation  on newValue...
		// and we keep on re-assigning newValue until we return the newValue
		return newValue;  
	}
}

Unless the function in question is the identity function I find it very weird when I read code which seems to return the same value that's been passed into the function.

The other way that function parameters get changed is when we mutate the values directly. The collecting parameter pattern is a good example of this.

That seems to be a more common pattern and since the function names normally reveal intent better it's normally less confusing.

It does become more problematic if we're mutating an object in loads of places based on conditional statements because we can lose track of how many times it's been changed.

Interestingly some of the code for ActionPack makes use of both of these approaches in the same function!

form_options_helper.rb

564
565
566
567
568
569
570
571

      def to_collection_select_tag(collection, value_method, text_method, options, html_options)
        html_options = html_options.stringify_keys
        add_default_name_and_id(html_options)
        ...
        content_tag(
          "select", add_options(options_from_collection_for_select(collection, value_method, text_method, :selected => selected_value, :disabled => disabled_value), options, value), html_options
        )
      end

form_helper.rb

        def add_default_name_and_id(options)
          if options.has_key?("index")
            options["name"] ||= tag_name_with_index(options["index"])
          # and so on
          end
        end

I'm not sure how exactly I'd change that function so that it didn't mutate 'html_options' but I'm thinking perhaps something like this:

	def create_html_options_with_default_name_and_id(html_options)
          options = html_options.stringify_keys
          if options.has_key?("index")
            options["name"] ||= tag_name_with_index(options["index"])
          # and so on
	end

And we could then change the other method to call it like so:

      def to_collection_select_tag(collection, value_method, text_method, options, html_options)
	   html_options_with_defaults = create_html_options_with_default_name_and_id(html_options)
        ...
        content_tag(
          "select", add_options(options_from_collection_for_select(collection, value_method, text_method, :selected => selected_value, :disabled => disabled_value), options, value), html_options_with_defaults
        )
      end

I guess you could argue that the new function is doing more than one thing but I don't think it's too bad.

Looking back on these code examples after writing about them I'm not as confident that mutating parameters is as confusing as I originally thought…!

Another library that we're using on my project is ActionMailer and before reading through the documentation I was confused for quite a while with respect to how it actually worked.

We have something similar to the following piece of code…

Emailer.deliver_some_email

…which when you click its definition in RubyMine takes you to this class definition:

class Emailer < ActionMailer::Base
	def some_email
		recipients "some@email.com"
		from "some_other_email@whatever.com"
		# and so on
	end
end

I initially thought that method was called 'deliver_some_mail' but having realised that it wasn't I was led to the 'magic' that is 'method_missing' on 'ActionMailer::Base' which is defined as follows:

module ActionMailer
...
	class Base
		def method_missing(method_symbol, *parameters) #:nodoc:
        		if match = matches_dynamic_method?(method_symbol)
          		case match[1]
            			when 'create'  then new(match[2], *parameters).mail
            			when 'deliver' then new(match[2], *parameters).deliver!
            			when 'new'     then nil
            			else super
          		end
        		else
				super
        		end
		end
	end
end

The 'matches_dynamic_method?' function allows us to extract 'some_email' from the 'method_symbol'. That value is then passed into the object's initializer method and is eventually called executing all the code inside that method.

        def matches_dynamic_method?(method_name) #:nodoc:
          method_name = method_name.to_s
          /^(create|deliver)_([_a-z]\w*)/.match(method_name) || /^(new)$/.match(method_name)
        end

Reading through the documentation, the author gives the following reasons for having separate 'create' and 'deliver' methods:

ApplicationMailer.create_signed_up("david@loudthinking.com")  # => tmail object for testing
ApplicationMailer.deliver_signed_up("david@loudthinking.com") # sends the email
ApplicationMailer.new.signed_up("david@loudthinking.com")     # won't work!

In C# or Java I think we'd probably use another object to build up the message and then pass that to the 'Emailer' to deliver it so it's quite interesting that both these responsibilities are in the same class.

It also takes care of rendering templates and from what I can tell the trade off for having this much complexity in one class is that it makes it quite easy for the library's clients – we just have to extend 'ActionMailer::Base' and we have access to everything that we need.

One of the reasons I wanted to come and work for ThoughtWorks in India is that I wanted to see how a distributed agile project is run and see the ways in which it differs to one which is done co-located.

I worked on a project which was distributed between Sydney and Melbourne in 2008/2009 and while some of the challenges seem to be quite similar to the ones we faced there, some are completely different.

Emails

Emails become much more prevalent when there are people in different locations and one thing that I learnt from the distributed project in Australia is that we have to be quite careful about the way that we phrase what we write.

It tends to work much better if we write in quite a defensive way using phrases like 'I think that' or 'it seems that' since it's very easy to misinterpret what's being said as we don't have the chance to understand a person's body language or tone.

A colleague pointed out to me that it's equally important to change the way that you read emails to give the other person the benefit of the doubt otherwise everything that you read may come across as being sarcastic and attacking.

Conference calls

As well as emails a lot of the communication between the people in Pune and Chicago is done through conference calls.

We also used this approach on the project I worked on in Australia and while it was still not as effective as face to face communication, the calls were always relatively smooth.

We seem to have more trouble on this project and people's voices often breakup so that you can't understand them at all. This leads to a bit of repetition in conversations and I can easily see how this would become an area of severe frustration.

I also learnt that I need to speak much more slowly on these calls or noone can understand what I'm saying!

Time zones

The time zone difference between Chicago and Pune at the moment is 10.5 hours so there is no overlap in the working days in the two locations which means we need to create an artificial overlap.

A normal working day for projects I've worked on in the UK/Australia would be around 9am – 6pm:

• 9am in Pune is 10.30pm the previous day in Chicago
• 6pm in Pune is 7.30am in Chicago

As a result the people in Chicago are asleep for nearly all of our working day and since the client is there as well the feedback cycle is a bit slower than it would be in the client was in the same building.

There does seem to be more scope to go down the wrong path when building a piece of functionality but as long as the client doesn't change their mind too drastically overnight or have their intent misunderstood then it seems relatively manageable.

A couple of years ago I saw a talk by the former Managing Director of ThoughtWorks India, Sitaraman, in which he outlined some of the challenges of offshore and I wondered whether the concepts of successful delivery both on and offshore were the same.

I'm still of a similar opinion but by being part of a distributed agile team for a few days I can see how much more tricky it is to achieve this than it would be in a co-located environment.

I'm sure there are many more things I will notice that are different as times goes on!

I've spent a little time browsing through some of the libraries used by my project and one thing which I noticed in ActiveSupport is that fields don't seem to be accessed directly but rather are accessed through a method which effectively encapsulates them inside the object.

For example the following function is defined in 'inheritable_attributes.rb'

  def write_inheritable_attribute(key, value)
    if inheritable_attributes.equal?(EMPTY_INHERITABLE_ATTRIBUTES)
      @inheritable_attributes = {}
    end
    inheritable_attributes[key] = value
  end

  def inheritable_attributes
    @inheritable_attributes ||= EMPTY_INHERITABLE_ATTRIBUTES
  end

EMPTY_INHERITABLE_ATTRIBUTES = {}.freeze unless const_defined?(:EMPTY_INHERITABLE_ATTRIBUTES)

If we were using C# we'd have instantiated '@inheritable_attributes' at the field definition with 'EMPTY_INHERITABLE_ATTRIBUTES' like so…

public class SomeClass {
	private Dictionary<string, object> inheritableAttributes = new Dictionary<string, object>();
}

…but we can't do that in Ruby because we don't need to explicitly define all our fields, we just start using them.

I'm assuming this is quite a common pattern in Ruby and in a way it's quite neat because it restricts the number of direct field references which will make it easier to change the underlying implementation. Kerievsky's narrowed change refactoring suddenly becomes less necessary!

For that reason I wonder whether it would be a useful pattern in C#/Java or if it would be overkill.

In Continuous Delivery the authors talk about the danger of ultimate configurability…

Configurable software is not always the cheaper solution it appears to be. It’s almost always better to focus on delivering the high-value functionality with little configuration and then add configuration options later when necessary

…and from my experience when you take this over configurability to its logical conclusion you end up developing a framework that can hopefully just be 'configured' for any number of 'front ends'.

This seems to be quite a common thing to do across organisations and typically the decision about what needs to go into the framework is made before there's been much/any development on the applications which will make use of said framework.

In addition the framework is typically built by a different team to the ones who are going to be working on the applications which make use of it.

As a result it's very difficult for that team to know exactly what they should be building so we'll typically end up with something that is overcomplicated for the situations it's actually required for.

In my mind the problem that we create for ourselves is the same as when we try to write a massive piece of code all in one go instead of driving it out through examples.

We try to imagine how the code might be used rather than knowing how it will actually be used.

Udi Dahan talks about favouring use over reuse and I think this is the ultimate example of not doing that.

A more effective approach would be to develop those websites/front ends individually and then let the shared 'framework' evolve from there.

That way we know that we've extracted some shared ideas because we needed to rather than because we thought we might need to.

Even then we need to be careful about what we share between applications because often it might be best to just accept a bit of duplication to avoid the implicit dependency created between teams.

Seth Godin recently wrote a post about 'the fear tax' which he describes as a 'tax' that we pay when we do something in order to try and calm our fear about something else but don't necessarily end up calming those fears.

We pay the fear tax every time we spend time or money seeking reassurance. We pay it twice when the act of seeking that reassurance actually makes us more anxious, not less.

I think one common example of a time we fall into this trap when developing software is around the security of financial systems.

Due to legal requirements that firms operating in that domain operate under we can often end up with a very complicated security solution which is unnecessary for allowing us to achieve what we want to.

On one system we worked on had a requirement to write some Javascript code to encrypt the data sent from the browser which was then sent securely through SSL to the web server.

Once it reached the web server we then had to send it in a SOAP message to a backend server where it could be unencrypted through the use of a private key.

Since one end point was in Java and one .NET there were slight incompatibilities in the way they handled security so it ended up taking a lot of time to actually get it working properly.

We had this extra security around the messages on the backend to protect against an unauthorised server trying to send messages to that server.

This despite the fact that the backend server was behind a firewall which would not accept any requests that came from servers outside the specified IP addresses of servers known to be in the DMZ.

In other words in order to remain compliant we were paying a significant fear tax in terms of increased complexity of our code base and the time taken to get all the code working in the first place.

Another simpler example of this that is often found in code is checking whether an object being passed around the code is null.

I've worked on code bases where we've ended up checking whether a particular object is null 2 or 3 times.

Alternatively we can use a pattern to take this problem away and then we don't have to worry about it again.

Seth's closing advice is as follows:

Instead of forgetting about the wasted anxiety after the fact, perhaps we ought to keep a log of how often we needlessly pay the fear tax.

Instead of over-staffing, over-planning, over-meeting and over-analyzing, perhaps organizations should take lower-cost steps and actually ship.

Think about how much you could get done if you didn't have to pay a tax to amplify or mollify your fear…

I've been flicking through Continuous Deployment and one section early on about changing configuration information in our applications particularly caught my eye:

In our experience, it is an enduring myth that configuration information is somehow less risky to change than source code. Our bet is that, given access to both, we can stop your system at least as easily by changing the configuration as by changing the source code.

In many organisations where I've worked this is generally adhered to except when it comes to configuration which is controlled from the database!

If there was a change to be made to source code or configuration on the file system then the application would go through a series of regression tests (often manual) to ensure that the application would still work after the change.

If it was a database change then that just be made and there would be no such process.

Making a change to database configuration is pretty much the same as making any other change and if we don't treat it the same way then we can run into all kinds of trouble as the authors point out:

If we change the source code, there are a variety of ways in which we are protected from ourselves; the compiler will rule out nonsense, and automated tests should catch most other errors. On the other hand, most configuration information is free-form and untested.

Alex recently wrote about his use of deployment smoke tests – another suggestion of the authors – to ensure that we don't break our application by making configuration changes.

Organisations often have painful processes for releasing software but I think it makes more sense to try and fix those rather than circumnavigating them and potentially making our application behave unexpectedly in production.

As I've mentioned previously I think the Kindle application on the iPad is the best one for reading books and as a result of that I wanted to be able to read some books which I'd bought from the PragProg store onto it.

The first step is to download the '.mobi' version of the book and use iPhoneExplorer to drag the file into the 'Kindle/Documents/eBook' folder on the iPad.

This works fine but if you add more than one book in this way they all have the same cover image when viewed on the iPad which is quite annoying when trying to work out which book is which.

I went on a yak shaving mission to try and figure out how to solve that problem and came across a post by GRiker where he described how to set a custom cover image.

His instructions were as follows:

For example, let's say you want to sideload WarOfTheWorlds.MOBI with its cover WarOfTheWorlds.JPG into the Kindle for iPad app:

• Modify WarOfTheWorlds.MOBI (using Mobi2Mobi, for example), adding or modifying the ASIN field (in the EXTH block) with the name of the cover jpg, WarOfTheWorlds.JPG. (Since your sideloaded book didn't come from Amazon, you don't need a real ASIN.)
• Copy the modified WarOfTheWorlds.MOBI to Kindle/Documents/eBooks (using iPhone Explorer)
• Copy WarOfTheWorlds.JPG to Kindle/Documents/LibraryCovers (using iPhone Explorer)

I first loaded the mobi files into Calibre so that I could get the cover image by doing the following:

• Click on the icon in the top left hand corner which looks like a book with a + sign on it
• Add books from a single directory
• Find the .mobi file you want to import
• Right click on the book
• Open containing folder

After I'd done that I needed to install 'mobi2mobi' in order to update the 'ASIN' number of the book. The Kindle application looks for a file with the same name as the ASIN number in the 'LibraryCovers' folder and uses that as the cover image for the book.

There are a crazy number of instructions to follow on the mobileread wiki in order to install this.

I followed these but was getting the following error when I tried to run the command:

Can't locate GD.pm in @INC (@INC contains: /Users/mneedham/eBooks/tools /Library/Perl/Updates/5.10.0/darwin-thread-multi-2level /Library/Perl/Updates/5.10.0 /System/Library/Perl/5.10.0/darwin-thread-multi-2level /System/Library/Perl/5.10.0 /Library/Perl/5.10.0/darwin-thread-multi-2level /Library/Perl/5.10.0 /Network/Library/Perl/5.10.0/darwin-thread-multi-2level /Network/Library/Perl/5.10.0 /Network/Library/Perl /System/Library/Perl/Extras/5.10.0/darwin-thread-multi-2level /System/Library/Perl/Extras/5.10.0 .) at /Users/mneedham/eBooks/tools/MobiPerl/Util.pm line 23.
BEGIN failed--compilation aborted at /Users/mneedham/eBooks/tools/MobiPerl/Util.pm line 23.

I came across the following thread where pilotbob described a way to fix this:

I got it working on Snow Leopard. Here is what I did.

1. Install MacPorts… this will make it a whole lot easier. http://www.macports.org

2. Once you get ports installed use macports to install the gd lib stuff:
sudo port install gd2

This will also install perl 5.8.9… perl 5.10 comes with Snow Leopard. Not sure it any mac stuff requires that… but you can always go back, macports puts stuff in a separate location.

I also installed the following macports:

p5-gd
p5-palm
p5-timedate
p5-getopt-mixed
p5-image-size
p5-xml-parser-lite-tree
p5-encode

Then, I use CPAN to install the following… there didn't seem to be any macports for them:

HTML::TreeBuilder
Image::BMP

After that mobi2mobi ran… well it gave me the command line options. I didn't actually try it. But, it doesn't seem to run unless all the dependencies are there.

I tried to install all of those dependencies as he suggests although not all of them worked for me.

After I'd done that I went back to the mobileread wiki and re-ran the following commands:

sudo perl -MCPAN -e shell
 
install Palm::PDB
install XML::Parser::Lite::Tree
install GD
install Image::BMP
install Image::Size
 
install HTML::TreeBuilder
install Getopt::Mixed
install Date::Parse
install Date::Format

And after all that I was finally able to run 'mobi2mobi' to change the 'ASIN' of the file which can be done by executing the following command:

mobi2mobi my.mobi --outfile my.mobi --exthtype asin --exthdata "mycoverimage.jpg"

To get the Kindle application to pick up the new image I needed to be connected to the internet for some reason but all my books are showing with the correct covers now.