markhneedham/blog huggingface dataset:
Ruby: Hash ordering
Date: 2010-09-07 03:52:32

The application that I'm working on at the moment is deployed into production on JRuby but we also use the C Ruby 1.8.7 interpreter when developing locally since this allows us much quicker feedback.

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:

[source,text]
----

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:

[source,text]
----

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

We found http://www.ruby-forum.com/topic/153146[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!
RSpec: Another newbie mistake
Date: 2010-09-30 07:03:07

We recently had a spec which was checking that we didn't receive a call to a specific method on an object...

[source,ruby]
----

describe "Our Object" do
	it "should not update property if user is not an admin" do
		our_user = Factory("user_with_role_x)
		User.stub!(:find).and_return(our_user)

		user.stub!(:is_admin?).and_return(false)
		user.should_not_receive(:property)
	end
end
----

...where 'property' refers to a field in the users table. In the code 'property' would get set like this:
[source,ruby]
----

class ObjectUnderTest

	def method_under_test
		user = User.find 4

		if user.is_admin?
			user.property = "random value"			
		end
	end
----

That test always passed but when we wrote the test to check that 'property' would be set if the user was an admin we found that it always failed.

The mistake is quite simple - the method that we wanted to check was received is actually called 'property=' rather than 'property'!

Changing the spec to read like this solves the problem:

[source,ruby]
----

describe "Our Object" do
	it "should describe something" do
		our_user = Factory("user_with_role_x)
		User.stub!(:find).and_return(our_user)

		user.stub!(:is_admin?).and_return(false)
		user.should_not_receive(:property=)
	end
end
----

It didn't take that long to figure it out but this is certainly a mistake you wouldn't be able to make in a statically typed language.
jQuery UI Tabs: Changing selected tab
Date: 2010-09-08 18:32:37

We're using the http://jqueryui.com/demos/tabs/[tabs part of the jQuery UI library] on the project I'm currently working on and one thing we wanted to do was change the default tab that was being selected.

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:

[source,javascript]
----

$( ".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 http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.2/jquery-ui.js[1.8.2] of the library  via http://code.google.com/apis/libraries/devguide.html#jqueryUI[Google's CDN] (which seems really cool!) and were able to see that our class was actually intentionally being removed!

[source,javascript]
----

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:

[source,javascript]
----

			// 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.
Ruby: Checking an array contains an item
Date: 2010-09-08 18:54:50

A couple of times in the past few days I've wanted to check if a particular item exists in an array and presumably influenced by working for too long with the .NET/Java APIs I keep expecting there to be a 'contains' method that I can call on the array!

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

Therefore...

[source,ruby]
----

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

[source,ruby]
----

[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:

[source,ruby]
----

response.flash[:error].include?("Some error message").should be_true
----
Ruby: Control flow using 'and'
Date: 2010-09-23 14:33:29

Something I've noticed while reading Ruby code is that quite frequently the flow of a program is controlled by the 'chaining' of different operations through use of the 'and' keyword.

I've noticed that http://www.markhneedham.com/blog/2010/03/28/reading-code-underscore-js/[this pattern is used in Javascript code as well] and it's particularly prevalent when we want to get a status for those operations after they've all been executed.

For example we might have the following code...

[source,ruby]
----

status = user.is_allowed_to_edit_foo? and user.update_foo(params[:foo]) and user.save
----

..where the user's foo would only get updated and the record saved if they were actually allowed to edit their foo.

At the moment it seems quite strange to me because when I see operations chained together like that I assume that they're all 'query' type operations but in Ruby it seems like 'command' type operations are used too.

To an extent the http://martinfowler.com/bliki/CommandQuerySeparation.html[command query separation principle] is being broken but it seems quite common to return a boolean value to indicate whether or not a state changing operation was successful.

I'd be more familiar with that type of code being written like this but I don't think it reads as well:

[source,ruby]
----

status = false
if user.is_allowed_to_edit_foo?
	if user.update_foo(params[:foo])
		status = user.save
	end
end
----

While trying to think of a way of writing that code which I think would be more intention revealing I ended up with the following:

[source,ruby]
----

class User
  def is_allowed_to_edit_foo?(foo, &block)
    yield and return true if can_edit_foo?
    false
  end

  def update_foo(&block)
    #do some awesome stuff
    successful_update = true
    yield and return true if successful_update
    false
  end

  def can_edit_foo?
    true
  end
end
----

[source,ruby]
----

user = User.new
status = user.is_allowed_to_edit_foo?(params[:foo]) do
  user.update_foo do
     user.save
  end
end
----

I'm guessing the original code I posted is more idiomatic Ruby but I still think it's interesting to see the different styles that you can write code in.
Ruby: FactoryGirl & declarative_authorization - Random thoughts
Date: 2010-09-12 14:25:06

Two other gems that we're using on my current project are http://github.com/thoughtbot/factory_girl[FactoryGirl] and http://github.com/stffn/declarative_authorization[declarative_authorization].

We use declarative_authorization for controlling access to various parts of the application and FactoryGirl allows us to build objects for use in our tests.

We wanted to be able to deactivate the authorization when creating test objects because otherwise our test wouldn't have permission to create certain objects.

Our original approach was to create a 'God' role which we could assign to the 'current_user' in our tests therefore allowing us to create whatever objects we wanted.

The problem with this approach is that it means we end up creating this role as part of the production data.

One way to get around this is to put an if statement into the seed data where the role creation happens and only allow that role to be created in test/development environments but that's a bit of a hack.

In any case declarative_authorization provides a function to get around this problem and if we pass a block to that function any code executed within the block will be free of the authorization rules setup:

[source,ruby]
----

require 'declarative_authorization/maintenance'
include Authorization::TestHelper

without_access_control do
	Factory(:foo, :bar => "myBar")
end
----

This works pretty well and there is http://github.com/stffn/declarative_authorization[more documentation on the github page].

Unfortunately we already had 400 or so usages of the Factory throughout the code base which weren't wrapped with 'without_access_control' and had been relying on the 'God' role.

We'd have the same problem if we created a 'create_without_access_control' method on Factory as well so came up with the idea of overriding the 'create' method of FactoryGirl to always be called inside the 'without_access_block':

[source,ruby]
----

require 'declarative_authorization/maintenance'
include Authorization::TestHelper

class Factory
  class << self
    alias_method :original_create, :create

    def create(name, overrides = {})
      without_access_control do
        original_create(name, overrides)
      end
    end
  end
end
----

This helps solve the problem although I guess it could be quite misleading since the 'create' method being called would be a different one than you might expect.

On the other hand FactoryGirl is only being used to create tests objects and we never directly test our authorization functionality using FactoryGirl so it doesn't seem to be too much of a problem to change it in this way.
Ruby: Caught out by no type checking
Date: 2010-09-13 17:44:04

I got caught out for a little while today when comparing a value coming into a controller from 'params' which we were then comparing with a collection of numbers.

The code was roughly like this...

[source,ruby]
----

class SomeController

	def some_action
		some_collection = [1,2,3,4,5]
		selected_item = some_collection.find { |item| item == params[:id] }
	end
end
----

...and since the 'id' being passed in was '1' I was expected that we should have a selected item but we didn't.

The actual code being executed would be...

[source,ruby]
----

[1,2,3,4,5].find { |item| item == "1" }
----

...which of course doesn't match any values since we're comparing a string to an integer.

The fix is relatively simple...

[source,ruby]
----

class SomeController

	def some_action
		some_collection = [1,2,3,4,5]
		selected_item = some_collection.find { |item| item == params[:id].to_i }
	end
end
----

...but I found it interesting that this is the type of thing that would have been caught if we had static type checking but is something you'd aim to cover with a test with a dynamic language.

In this case we had been refactoring the code and having slightly changed the way it worked internally our interaction tests didn't quite cover this scenario properly so we had to go and update those.

So far I've certainly seen that Ruby/Rails can make you more productive and this is the first time I've seen a situation where I wished for C#'s static typing...if just for a little while.
The fear tax
Date: 2010-08-20 14:14:28

Seth Godin recently wrote a post about 'http://sethgodin.typepad.com/seths_blog/2010/08/the-fear-tax.html[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.

image::{{<siteurl>}}/uploads/2010/08/fear-tax.jpg[fear-tax.jpg,502]

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 http://www.markhneedham.com/blog/2008/08/16/null-handling-strategies/[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\...
____
Database configuration: Just like any other change
Date: 2010-08-18 10:07:42

I've been flicking through http://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912/ref=sr_1_1?ie=UTF8&s=books&qid=1282115440&sr=8-1[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 http://blog.m.artins.net/deployment-smoke-tests-is-anyone-being-slack/[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.
Can we always release to production incrementally?
Date: 2010-08-16 04:22:40

http://continuousdelivery.com/2010/08/continuous-delivery-vs-continuous-deployment/[Jez recently linked] to http://timothyfitz.wordpress.com/2009/02/08/continuous-deployment/[a post written by Timothy Fitz about a year ago where he talks about the way his team use continuous delivery] which means that every change made to the code base goes into production immediately as long as it passes their test suite.

I've become fairly convinced recently that it should always be possible to deploy to production frequently but we recently came across a situation where it seemed like doing that wouldn't make much sense.

The project involved replacing an existing website but rebranding it at the same time. One of the key goals of the project was to create a consistent brand across the whole site.

Therefore it seemed that if we chose to incrementally deploy to production then we'd need to spend some time updating the old website so that the look and feel was the same across both versions of the site.

The overall time to finish the project would therefore be higher and the value that we'd get from actually get from putting something into production early probably wouldn't justify the extra effort that it'd take to do so.

In this situation the most effective strategy seems to be to still deploy as frequently as possible to a production like environment internally but only deploy to live when the whole thing is done.

If we're replacing the backend of an old system and the end user won't see anything different then an incremental deployment approach is certainly worthwhile but when brand consistency is the most important thing I'm not sure that it still makes sense.

As always I'd be keen to hear if anyone's done anything similar and if there are any ways around this.
Learning and Situated cognition
Date: 2010-08-10 03:26:23

Sumeet http://www.learninggeneralist.com/2010/08/thoughtworks-university-story-of-our.html[recently blogged about the new style ThoughtWorks University that he and the other trainers have introduced] and although I only got to see it in action for a few days it seemed clear to me that it was an improvement on the original version.

The questions being asked, discussions being had and situations that were coming up were pretty much the same as I've seen on any software project that I've worked on.

One particularly interesting thing which came up a few times was that there was a 'them vs us' feeling between the analysts and developers.

This is certainly an example of a situation which didn't come up on the project when I participated in ThoughtWorks University 4 years ago where we only had a one week simulation.

It is however a situation that does come up and on the projects I've worked on it certainly can feel like you're fighting the analysts. They're trying to balance the wishes of the client as well as those of the developers and to developers it can often seem that the analyst is just being difficult for the sake of it.

The cool thing was that the grads then came up with different potential solutions to this problem and they were pretty much the same solutions that we've used on projects I've worked on.

While discussing a different topic with http://www.intwoplacesatonce.com[Dave Cameron] he pointed me to the Wikipedia entry for 'http://en.wikipedia.org/wiki/Situated_cognition[situated cognition]' which "posits that *knowing is inseparable from doing by arguing that all knowledge is situated in activity bound to social, cultural and physical contexts*".

The following quotes seem to explain why, in my experience at least, I learn way more effectively when working with colleagues on projects than I could ever do on an out of context training course:

____
Knowing emerges as individuals develop intentions through goal-directed activities within cultural contexts which may in turn have larger goals and claims of truth.
____

____
Knowing is expressed in the agent's ability to act as an increasingly competent participant in a community of practice.
____

____
Learning must involve more than the transmission of knowledge but must instead encourage the expression of effectivities and the development of attention and intention that reflect real life learning processes
____

I think this new style TWU gives grads an even better start to their ThoughtWorks lives and I hope to take part as a trainer for one of the terms later in the year.
Ultimate configurability
Date: 2010-08-21 11:04:54

In http://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912/ref=sr_1_1?ie=UTF8&s=books&qid=1282313953&sr=8-1[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'.

image::{{<siteurl>}}/uploads/2010/08/frameworkitis.jpg[frameworkitis.jpg,441]

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.

http://www.udidahan.com/2009/06/07/the-fallacy-of-reuse/[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 http://www.markhneedham.com/blog/2010/02/26/coding-shared-libraries/[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.