More as an attempt to help myself remember than anything else, the method we want is actually called 'include?'.

Therefore…

[1,2,3].include?(2)
=> true

[1,2,3,4].include?(5)
=> false

One other quite neat thing is that we can use that in tests when we want to check that an array contains one item that we're expecting.

This is much better than having to specify a specific index which is what we often seem to end up doing in Java/C#.

We therefore end up with (RSpec) tests similar to this:

response.flash[:error].include?("Some error message").should be_true

The documentation suggested that one way to do this was to give the index of the tab we wanted selected when calling the tabs function:

$( ".selector" ).tabs({ selected: 3 });

Since we wanted to select the tab by name based on a value from the query string we thought it would probably be simpler if we could just set the selected tab using a css class.

Our initial thought was that we could put the 'ui-tabs-hide' class on the divs that we wanted to hide and then not put that class on the one that we wanted to show.

Unfortunately that didn't work and the first tab was still being selected…

We downloaded version 1.8.2 of the library via Google's CDN (which seems really cool!) and were able to see that our class was actually intentionally being removed!

10523
10524

if (o.selected >= 0 && this.anchors.length) { // check for length avoids error when initializing empty list
				this.panels.eq(o.selected).removeClass('ui-tabs-hide');

Luckily a little further down the file there is a comment which explains some other ways to manipulate the selected tab:

10749
10750
10751
10752
10753

			// Selected tab
			// use "selected" option or try to retrieve:
			// 1. from fragment identifier in url
			// 2. from cookie
			// 3. from selected class attribute on <li>

We need to put the class 'ui-tabs-selected' on the appropriate <li> and then that will be the one that gets selected.

As a result we sometimes come across interesting differences in the way that the two runtimes work.

One that we noticed yesterday is that if you create a hash, the order of the keys in the hash will be preserved when interpreted on JRuby but not with the C Ruby interpreter.

For example if we create the following hash in Ruby 1.8.7 it will be resorted into alphabetical order:

ruby-1.8.7 > a_hash = { :a => 1, :d => 2, :c => 3 }
 => {:a=>1, :c=>3, :d=>2}

Whereas in JRuby it will maintain its order:

jruby-1.5.1 > a_hash = { :a => 1, :d => 2, :c => 3 }
 => {:a=>1, :d=>2, :c=>3}

We found a post on the Ruby mailing list from a couple of years ago which pointed out that from Ruby 1.9 the order is in fact maintained.

However, Gregory Seidman also pointed out that…

Hashes are inherently unordered. Hashes provide amortized O(1) insertion and retrieval of elements by key, and that's it. If you need an ordered set of pairs, use an array of arrays. Yes, this is a pet peeve of mine.

Since that is indeed what we want we've created an array of arrays in our code instead. The code to retrieve values from the array of arrays is a bit more verbose but at least the order is now guaranteed!

I think the overall point that he makes is very true:

We can switch our attention quickly from one task to another. But … is it good for our brain? Is it good for the work we are doing? Are we really more productive?

I've often found that when I try and switch between multiple different tasks I end up finishing none of them and it's certainly true that twitter, facebook and emails can be amazingly distracting.

Hopefully those types of distractions are less of an issue when working on a software development team, particularly if the team are pair programming.

Project influenced context switching

While I agree with Greg that it's good to try and make sure that we're only working on one task at a time, I think that to an extent there is always going to be some context switching involved if we have a group of people working together.

Greg touches on this briefly in his post:

When we are in a despair and need answers we are not worrying about anyone else. The goal is to ask or tell to achieve whatever we are after. We are not taking into consideration that we might be disturbing someone else Flow.

To me it seems that focusing on the flow of an individual individual/pair is a bit of a local optimisation when we're talking about software teams.

For example if a pair are working on a piece of functionality orthogonal to what another pair are working on then should they interrupt that pair if they need to talk about something?

Interrupting them possible would break their 'flow' but it might give one or both pairs an insight into the problem which they wouldn't have otherwise had.

From my experience pairs interrupting each other often helps reduce the amount of time that we spend building the wrong thing.

An alternative way to still gain this knowledge without interrupting people straight away would be to delay the conversation until a later time but perhaps the best moment for gaining that knowledge has now gone?

Counter productive context switching

The only time when interrupting a pair does seem counter productive is if you're doing so to ask a question whose answer could easily be found out with a quick bit of Googling.

In that case I completely agree with Greg that we should first think about the impact our interruption will have on our colleagues.

Overall

The topic of flow/context switching is an interesting one but I think we need to be careful about having it as our main goal on software delivery teams.

I wrote about pair flow a while ago where I described some ways to achieve more 'flow' within a pair but my current line of thinking is that we'll still have some interruption between pairs and that's not necessarily a bad thing.

An approach to ponder…

Mike Wagg once suggested that pairs should work in 25 minute pomodoros and only be interruptible when they're on a break from one.

This seems like an interesting idea but communication would end up being much more structured/time boxed/weird?!

I've never quite been able to put my finger on exactly what makes a design simple and there is frequently disagreement about what is even considered simple.

On the last project I worked on we had an interesting problem where we wanted to partially update different parts of an object from different pages of the application.

We had access to the id of the object from the URL so my initial thought was that when we submitted each page we could load the full object from the database and update it with the values that had just been submitted from that page.

The problem with that solution was that it meant we needed to make another database call without any real benefit from doing so.

We had already created objects representing the data submitted from these pages so Christian suggested that an alternative approach would be to create NHibernate mappings for those objects instead so that we could just map the updated values straight to the database.

We had bit of duplication in our objects as we had one object representing every bit of data the user had provided so far and then two smaller objects just representing the data provided for each of the pages.

public class TheObject
{
	public string Page1Property { get; set; }
	public string Page2Property { get; set; }
}

public class PartialObject1
{
	public string Page1Property { get; set; }
}

public class PartialObject2
{
	public string Page2Property { get; set; }
}

We then created NHibernate mappings for each of those objects:

public class TheObjectMapping : ClassMap<TheObject>
{
	Map(x => x.Page1Property);
	Map(x => x.Page2Property);
}

public class PartialObject1Mapping : ClassMap<PartialObject1>
{
	Map(x => x.Page1Property);

public class PartialObject2Mapping : ClassMap<PartialObject2>
{
	Map(x => x.Page2Property);

When loading the object from the database onto the page we used 'TheObject' and its associated mappings and when updating the object from the individual pages we could use the partial object mappings.

I think this was quite a neat approach as it allowed us to reduce the complexity of our controller code when updating an object as well as removing the need for one trip to the database.

The trade off was that we ended up writing more mapping code but that seemed to be a reasonable trade off to make.

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.

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.

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…!

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.

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!