threehv

Well not quite.

Instead, it’s a (biased) look at how using Rails for your next project can give you a better return on investment.

Basically, your major costs are your team and your servers (and you definitely get what you pay for when it comes to your development team).

Everything else tends to zero.

I personally can’t stand the Dock on Apple’s Mac OS X. It doesn’t feel right to me, it doesn’t hold enough information nor does it display the information it does have correctly. And I feel like it is stealing screen space from me (and “auto-hide” is just a crappy hack that feels even worse).

But, ages ago, as a “thought experiment” I decided to design my own “computer user interface” from scratch. Something that non-computer users would understand. You see, to people like me, things like “double-clicking” and “holding the Control key while pressing S” are easy. To some people, it’s not that they’re difficult, it’s just that they’re more difficult than they need to be. Hence so many people single-click when they should be double-click and double-click when they should single-click. Hence so many people use the Caps Lock key, instead of holding down Shift, to type in Capitals.

So, what would an interface for these “non-expert” users look like? A computer is a multi-function device, so I tried to think of a physical multi-function device. The one that came to mind was a stereo. A range of different functions (“tuner, phono, cd, tape” erm I’m showing my age now). So you have a row of buttons. Click a button (once) and the stereo’s function changes.

If you were to model that then the perfect “non-computer” interface would have a row of big, clear, buttons that you click once. When you do that, the computer’s function changes.

And that’s when it hit me. That’s the Dock in OS X (or more correctly NeXTStep). Click an application’s button (once) and all that applications windows are brought to the front. It becomes the computer’s primary function. A simple model with simple interaction, perfect for the user that’s just starting out or lacking in confidence.

Written using the WordPress application for the iPhone.

Quick summary: the 3G is great (especially as EDGE coverage was patchy at best), I’ve not noticed the GPS but the AppStore makes it.

Suddenly Safari is no longer the most used application on my phone.

Should you buy one? It’s both the best and worst phone I’ve ever used. Worst because it has no MMS (essential if you have non-geek friends), it is crippled with regards to ring tones and you can’t use it as a modem for your laptop. But it’s also the only phone I actually WANT to use. In fact it’s rarely in my pocket for more than an hour at a time.

NetNewsWire for the iPhone is great, but has a flaw that spoil it.

The User Experience is all wrong when you read an article.

Your eye starts at the top of the page, you scan down the page to read the preview, then you have to go all the way back to the top to tap the title, in order to view the full article. To make things worse, you then need to scan all the way back down to see the progress indicator. I don’t mind about the “Open in Safari” button in the top right – that’s an exceptional use-case, not the norm. But to have your eyes jumping up and down while in the regular flow of usage is not good.

The fix is simple – add a button, in the footer, for viewing the full article (replacing the “tap the title to read the full article”). So your eyes make a single movement, top to bottom, ending on the progress indicator in the bottom-right.

One of the great advantages of using mock objects to test and specify your objects is that you concentrate solely on the thing you are testing.  

If you weren’t using mocks to tests that a controller re-shows the “new” form if given an invalid object, you would do post :create, :model => { ... } where … is a set of fields that are invalid. This means that, when writing your spec, you have to remember what it is that makes that model invalid. This also means that, every time you change that model, and its rules for validity, you potentially have to amend the controller test as well. In other words, you are not actually testing the controller in isolation, you are also testing the model.

Using mocks lets you write the following:

  @model = mock Model
  Model.should_receive(:new).and_return(@model)
  @model.should_receive(:save).and_return(false)
  post :create, :model => { :some => :fields }
  response.should render_template('/models/new')

In other words, it doesn’t matter what parameters you send to create. The Model (class) will return you a mock instance of model, and the mock instance will return false on save (you can actually get save! to raise an ActiveRecord::RecordInvalid – but I’ve had some difficulties with that). In other words, the real model is no longer part of the test and you are concentrating on the behaviour of the controller alone.

This concentrating on what is important is a vital advantage when using mocks.

But how does this work on testing models?

I wanted to test that a default value was copied from one field to another under certain circumstances. So I set up a method, called set_default_value and wrote some specs to ensure that it was working. Then I wrote the following:

  it "should set the default value before validation" do
    @model = Model.new
    @model.should_receive(:set_default_value)
    @model.valid?
  end

This failed, as it should do. Then I set a before_validation :set_default_value on the model and the spec passed. Each spec concentrates purely on what is important – a couple to show that set_default_value works under different circumstances, and one to show that it is called when it is supposed to be.

What about testing a :dependent => :destroy association?

Unfortunately, that can’t be done without saving at least one of the objects in the association (which means knowing enough about it to make it valid). But, as David Chelimsky (Mister RSpec) points out on the RSpec mailing list, you can do it using mock objects for part of the association. Which was a relief as my “child” object was complex with a whole set of interdependencies of its own.

A very interesting article about how DRY you should be in your specs.  

http://lindsaar.net/2008/6/24/tip-24-being-clever-in-specs-is-for-dummies

Personally I agree with everything said.  Readability comes first, even at the expense of efficiency and DRY; “be nice to those who have to maintain the code”.  The really interesting thing though is the example is actually quite DRY – it’s more about how you organise and order the code, more than repeating yourself.  

I saw the “Your life on your Blackberry” ad the other day.  Obviously designed to promote the Blackberry as a consumer device (because of the iPhone?) my first thought was “that’s the first Microsoft ad I’ve seen in ages”.  My wife’s first thought was “how dated was that?”.  

Let’s hope Microsoft do better with their upcoming promotion for Windows Vista.  

John Gruber finds a great example of iPhone UI design. Sometimes you
have to wonder what goes through people’s heads.

Maybe it’s just me but I think Microsoft’s branding is awful. “Equipt”
means you are getting two unrelated products with names totally unlike
the one on the box you are actually buying.