Luke Redpath - Home

iPhone App store: one month on

2008-08-12T13:01:00Z

The iPhone 3G and the app store launched about a month ago now and I think it’s been somewhat of a mixed bag: there is a plethora of shit on there which makes it hard to spot some of the gems.

When Apple announced the $99 fee for the developer program, there was an initial feeling that this would help reduce the number of people with little interest in writing original/interesting/quality apps. Unfortunately it hasn’t; a cursory browse through the app store reveals more tip calculators, fuel/expense trackers, note-taking apps, todo lists, Sudoku, and converters than you could shake a shit-covered stick at. And then there is the really pointless crap: flashlights, novelty apps, fucking candles (and they even have the audacity to charge for this rubbish), not to mention the people who don’t have a clue what user interface guidelines are all about and what makes a good UI (yes, I’m talking about you Stevens Creek Software – you’re apps are an abomination).

That said, there are good apps on there, some of which are of really high quality. Here’s a few that I use regularly:

NetNewsWire

I’ve tried many RSS feed readers on my Mac but I’ve always come back to NetNewsWire. It’s the only feed reader that just feels “right” to me and the syncing between all of my machines courtesy of it’s online NewsGator service is probably it’s killer feature. I’d tried various web-based readers optimised for the iPhone prior to the the app store launch, including NewsGator, but they always seemed slow and clunky so I was quite happy to see NetNewsWire for the iPhone make it out of the door so early.

Downloading feeds over an EDGE or GPRS connection can be painful but since upgrading to the iPhone 3G, it has been a pleasure to use, syncing with my online NewsGator account to retrieve a list of feeds and read/unread data.

A few usability gripes: with a long list of feeds, it can become hard to distinguish between folders and feeds; some kind of visual distinction would be useful. It’s also not immediately obvious that you can view articles with the built-in web view by tapping on the article heading (there is a separate button to view in Safari). Both minor gripes however and if you need your constant RSS fix, NetNewsWire should be at the top of your “to buy” list.

NetNewsWire App Store link

Texas Hold’em Poker (Apple)

OK, if you don’t play poker and your eyes are already glazing over, you might as well skip this one. This app is developed by Apple themselves and it shows. The game is straightforward: compete over a number of venues from your garage though Las Vegas all the way up to Dubai with the stakes and difficulty increasing as you progress.

The AI isn’t exactly brilliant and there will be times where the game is just plain frustrating: you’re heads up and you put your opponent all-in with your KQ suited and he/she calls with 10-2 off-suit, only for the flop to come down 10-10-2. It’s probably a good thing that this isn’t for real money, lest you through your phone out of the nearest window. However, the AI is “good enough” for a fun game of poker and it makes a the daily commute slightly less tedious.

Where this app really shines and makes it so obviously an Apple product is the near-perfect use of the iPhone’s touchscreen gesture support to provide an intuitive and fun user interface; cards can be folded by flicking them into the middle of the table; chips and be pushed into into the pot to go all-in; checking is as simple as tapping the table. You can also switch between a virtual-table mode (where you can see the players as the look at their cards and place their bets) and a more traditional racetrack mode (familiar to anybody who has played online poker) by simply changing the phone’s orientation.

Texas Hold’em App Store link

Vicinity

One of the first apps that I’ve played with that takes real advantage of the location-based services available; after working out your location using triangulation or GPS, it provides you with a list of useful locations in your vicinity (do you see what they’ve done there?): nearby places, cafes, banks, pubs, supermarkets, taxis, hotels and restaurants. Again, this wasn’t very useful on the original iPhone as the cell-tower triangulation was just too slow for it to be usable but on the 3G its incredibly useful. The wikipedia/flickr links are a nice added bonus, especially if you live in a busy area/large city with many points of interest such as London.

Vicinity App Store link

Facebook

This native app is a continuation of the good work that the Facebook team have already done with their web app – for my money one of the best web apps available for the iPhone. The native app doesn’t offer a whole lot more but it does mean a faster, smoother user experience (e.g., swiping a message in your inbox to reveal a delete button ala Mail) and there is also now a built-in chat option. Unfortunately there still doesn’t seem to be a way to edit your profile (other than your status, which I update through twitter anyway).

Facebook App Store link

Twitterific

As well as NetNewsWire, Twitterific was another app that I installed straightaway. It’s not bad but it doesn’t match up to it’s desktop counterpart – I find the dark interface quite ugly on the iPhone (there is a light interface in the paid-for version although I can’t find a screenshot of this anywhere – is it really too much to ask to have this as an option in the free app too?) and scrolling is very slow and clunky. I don’t mind the ads though so I don’t really feel compelled to pay for the premium version (the same goes for the desktop version). Despite it’s lack of polish, I still think it’s the best Twitter client available (at the moment).

Twitterific App Store link

Things

I’ve also grabbed a copy of Things. The interface is very pretty and I’m sure the app will eventually be great but I still need to motivate myself to use it. One thing I’ve found lacking is the ability to set alarms/receive reminders for scheduled events although I suspect that is a limitation of the platform itself. You really need to be checking it every morning to get the most out of it (although I suspect that is the idea if you’re a GTD addict). There is also no syncing with the desktop version which is a deal-breaker for many (not me) but I’d encourage you to snap it up at the introductory price and wait for syncing which will arrive as a free update.

Things App Store link

Speaking of updates

Unfortunately, the worst part of the whole experience is the App store itself and the way iTunes and the iPhone sync with eachother. When you plug your iPhone in, any apps you’ve downloaded via the iPhone app store don’t seem to sync to iTunes automatically – instead you need to manually select “Transfer purchases”. iTunes also seems to be confused about any updates that I need – it frequently tells me that I have “x apps requiring updates” when in fact there aren’t any. The iPhone App store app itself seems slow and buggy and on occasion has caused my phone to freeze altogether, requiring a hard reset – not good.

Writing my own apps

I’ve been meaning to learn how to write Objective-C/Cocoa Mac applications for a while now but haven’t ever gotten around to it. The release of the App store and the iPhone SDK has turned out to be that kick up the backside that I’ve needed – I’ve recently started learning Objective-C/Cocoa and I have a few apps in mind (I’m already working on a native iPhone interface for the SqueezeCenter software that powers Squeezebox music players.

Given that I have very little knowledge of C and absolutely no GUI app programming experience whatsoever, it’s been an interesting experience and a change of mindset (coming from a web development background) that I’m slowing coming to grips with and I’m sure I’ll be blogging about it over the next couple of months (fucking NDA not withstanding). As a Ruby programmer by day, there are certainly times when Objective-C makes me want to cry although it has some own elegances (sic) of it’s own that I’m starting to appreciate. More to follow…

On iPhones and user credentials

2008-08-12T12:31:00Z

Simon Willison argues that the iPhone app, Exposure, behaves “suspiciously” because it uses an embedded web view for users to log into to their Flickr/Yahoo accounts using OAuth.

The crux of his argument is that the embedded web view makes it impossible for users to tell if they are logging into the genuine Yahoo OAuth website or a phishing site. He cites Pownce as a better implementation because it opens the authentication page in Safari, which has lead to complaints/negative reviews from users due to the interruption of having to exit the Pownce app, sign in in Safari, then return to the Pownce app.

Whilst I can see his point about the transparency of using Safari directly, I’m not convinced that it’s worth compromising on the end-user experience to attain some kind of technical compliance with a protocol that most users haven’t heard of nor care about. More to the point, I’m not convinced this is as big a security issue as is being made out.

Ultimately, security often boils down to trust. Do you trust Service X with your credentials and personal information? If the answer is no, then you should not use Service X.

Using an embedded web view in the way that Exposure does isn’t really any different from a native login UI using iPhone interface widgets – without the source code to that application you have absolutely now way of knowing what that app is doing with your credentials. Most of the service-based iPhone apps that I use have a native iPhone login screen – NetNewsWire, Twitter etc. Am I wary of inputting my login details, despite the fact that they could be doing anything with them? No, because I trust the developers of these apps with my credentials (in the same way that I trust them with the same data when I use NewsGator or Twitter.com).

By passing users over to Safari to login – despite the transparency – all they are really doing is shifting the burden of trust on to the login provider and damaging the user experience overall.

Announcing Reevoo Labs

2008-07-03T16:58:00Z

Here at Reevoo, we’ve just (literally) gone live with our new open-source website, Reevoo Labs. Our old open-source site is moribund and now redirects to the new site.

As well as our own personal projects, myself and the others here at Reevoo have developed some useful libraries and Rails plugins many of which we hope to share with the community, including the already well-known Ruby mocking library, Mocha.

The first couple of plugins considered ready for public consumption are already up on the site (sorry about the lack of Subversion repository – all of our code is in a private repository and we’re still working on a mirror – I’ll try and get some of the projects up on my GitHub project page next week).

As well as acting as a place to share our various projects, we’ll also be maintaining a blog which will contains some interesting articles on some of the problems we’ve faced and how we solved them as well as general Ruby/Rails articles. Look out for some interesting architecture/infrastructure pieces from our system admins in the next couple of weeks – don’t forget to subscribe to the Reevoo Labs Atom feed.

Engaged

2008-06-27T16:03:00Z

Once again I find myself blogging after a long period away, sorry about that. But I wanted to make a quick public personal announcement.

On Monday 16th June, after seven and a half years together, Julie accepted my marriage proposal. Thank you Jools.

For Sale: 15" MacBook Pro

2008-02-08T12:44:00Z

Apologies for the long delay between this and the last post—I’ve struggled to find the time to post anything of late although I hope to rectify that in the coming months. In the meantime, you’ll have to make do with a blatant advertisement.

As the title says, I’m selling my two year old MacBook Pro to make way for a more recent, but more portable black MacBook. It was my first Mac and it’s served me well over the years; it’s still a great machine, I’m just in the market for something smaller with a little more oomph. Here are the pertinent details:

Rev. A MacBook Pro (March 2006)
1.83 Ghz Core Duo processor
1.5GB RAM
80GB Hard Drive
SuperDrive
Comes with original box and packaging, accessories and Tiger install CD
I can ship it with Leopard pre-installed if you so wish

It’s well used and has a few battle scars but nothing serious and is otherwise good condition and in perfect working order. The wireless problems that I mentioned in a previous blog post seem to have gone away since the latest Leopard update (so I guess it was a software issue after all) and there are no other issues with the machine.

So if you’re looking to hook yourself up with a great value laptop which is perfect for Ruby/Rails development you can bid on the item on my eBay auction or alternatively, take it straight off of my hands without going through eBay for £650 + shipping costs (£20, Royal Mail special delivery) by dropping me an e-mail – there is a contact link at the top of the page. If you are based in London, I’m also happy for you to collect it. See the eBay auction page for full details and some photos and don’t hesitate to e-mail me with any questions.

Optimising Symbol#to_proc

2007-11-26T10:10:00Z

Whilst pairing with Paul the other day I noticed that he preferred not to use Symbol#to_proc; on asking why, he told me it was because of the unnecessary performance hit that Symbol#to_proc imposed.

Now I’m not one for premature optimisation, but with an idiom like Symbol#to_proc likely to be used throughout a codebase, performance hits like this add up and as things stand, the Rails implementation of Symbol#to_proc is pretty expensive:

require 'benchmark'
require 'rubygems'
require 'active_support'

BIG_ARRAY = ['x'] * 1000000

Benchmark.bm do |bm|
  bm.report("Standard block") do
    BIG_ARRAY.map { |c| c.upcase }
  end

  bm.report("Symbol#to_proc") do
    BIG_ARRAY.map(&:upcase)
  end
end

Output on my 2Ghz quad-core Mac Pro:

                user     system      total        real
Standard block  0.720000   0.060000   0.780000 (  0.772927)
Symbol#to_proc  3.030000   0.010000   3.040000 (  3.040889)

Ouch. That’s roughly four times slower. -Based on my naive understanding of how Symbol#to_proc was implemented, it figured that the bottleneck was the creation of a new Proc object for every iteration; the proc doesn’t need to change for each iteration so surely we could just memoize it-?

Update: It seems that my initial assumption was incorrect; to_proc is in fact only called once. The real issue here is not the instantiation of a new proc, but the Rails implementation. Rails uses this slightly more complicated implementation in order to support passing of multiple arguments with the method call:

Proc.new { |*args| args.shift.__send__(self, *args) }

This allows you to do a few neat things with multiple elements of a collection like [1, 2, 3].inject(&:+) but I consider this supporting an edge case at the expense of performance.

I’ve never found myself in need of the functionality provided by Rails’ implementation (I didn’t even know it was supported) but I do find myself using the obj.map(&:method) idiom a lot so the following simplified implementation suits me just fine:

class Symbol
  def to_proc
    proc { |obj| obj.__send__(self) }
  end
end

The performance gain is significant:

                user     system      total        real
Symbol#to_proc  0.910000   0.010000   0.920000 (  0.916718)

The implementation itself is trivial but I’ve made it available on pastie – just drop it into a file somewhere in your Rails lib folder. If I find the time, I will try and package it up as a basic Rails plugin too. It’s worth bearing in mind that Ruby 1.9’s implementation will probably support the passing of arguments like the Rails implementation but hopefully it should be much faster.

The performance of Symbol#to_proc has also been brought up on Pratik Naik’s blog and this Rails ticket.

Update: Some of my original assumptions about the way Ruby invokes to_proc were incorrect and I have updated my article accordingly.

Some thoughts on Leopard

2007-10-29T11:36:00Z

In case you missed the memo, Apple unleashed Leopard on Friday. I headed down to the Regent Street Apple Store to see if I could snag a copy; unfortunately, by 6pm the queue had reached epic proportions (at least a 45 minute wait) and I promptly left and instead chose to pick up a copy from Brent Cross on Saturday (I feel sorry for anybody who did bother queueing all evening – the Brent Cross store was no more busy than usual come Saturday afternoon).

Rather than spending time discussing Leopard’s much discussed new major features, I thought it would be interesting to point out some of the smaller, minor but useful updates that I have picked up on so far. I will update this list over the next week or two as I discover new things, good and bad:

Installation didn’t go too smoothly for me; there appears to be a bug in the install process affecting some machines that means that my hard drive wasn’t showing up in the “Select a destination” panel. Fortunately I was able to find out from the Apple discussion forums that after waiting 10 to 15 minutes your available drives will appear. One cup of tea later, and the install routine was back on track. I opted to perform an “Erase and Install” on my MacBook Pro to get rid of the sheer amount of crap that I had accumulated over the last 18 months which went as smoothly as I’d expected. I am yet to try the upgrade option on my Mac Mini so YMMV here.

My first impressions were that Leopard seemed faster and given that it was probably hard at work indexing my hard drive for Spotlight this was pretty impressive. My Airport problems in Tiger (the connection would frequently just stop responding or lose packets making it incredibly frustrating to do anything useful) appear to be resolved, at least, when running on mains power. When running on battery I still seem to be suffering from random disconnections although Leopard at least shows that it has lost its connection and reconnects pretty fast. This may be a problem with my router and still requires further investigation on my part.

The new dock is not as bad as everybody has made out and I have left it at the bottom for now even though I’m traditionally a dock-on-the-side person. The new Stacks functionality is useful and looks great although the cool “fan” effect only works when the dock is on the bottom. I imagine the novelty will wear off quite quickly and I will be back to having my dock on the side soon enough.

I’m sure that most Rails developers have been aware for a while now that Leopard will ship with Rails. The new Ruby/Rails stack in Leopard is well thought out and organised and comes with Ruby 1.8.6, Rails 1.2.3 and and a host of other useful gems. Rails itself is simply bundled as a gem and is easily updated. A good overview of the changes to Ruby in Leopard is available.

One utility that anybody who frequently uses SSH and public/private keys would not be without is SSHKeychain which integrates with Apple Keychain and acts as an SSH agent. In my experience SSHKeychain could be flaky and would sometimes silently crash for no apparent reason; good news then because as of Leopard, OSX maintains its own Keychain-integrated ssh-agent making passphrase-protected keys painless to use out of the box.

Speaking of which, the new Leopard Terminal finally supports tabs and is much easier to customize thanks to built-in themes. Despite some niggles (like not being able to jump to a specific tab using Cmd+number) I think that it is finally time to say goodbye to iTerm.

Connecting to your mail server over SSL using a self-signed certificate in Mail.app is no longer a pain in the arse. Before, Mail would prompt you that the server certificate was not from a trusted source every time you tried to connect unless you manually dragged the certificate to the desktop and added it to your keychain. In Leopard, Mail finally has an option to “always trust this certificate” as well as a number of other fine-grained trust options.

The new version of Front Row, based on the Apple TV software, seems like a regression to me. The new interface doesn’t seem as slick and suffers from some annoying bugs like not being able to view album artwork on a shared library and most annoying of all: there doesn’t seem to be any way to get Front Row to open on a second monitor. In Tiger, Front Row would always open on the primary display – this was documented behavior and in Leopard this behavior seems to have disappeared. I like to hook my MBP up to my plasma TV but now Front Row will only open on my MBP screen, even if its not the primary display, severely limiting its usefulness.

On the plus-side, Quicktime now has some useful full-screen options including options to stretch or fill a widescreen display when viewing videos in a 4:3 aspect ratio. Quicktime does work on a second display and allows you to select which screen it will display on in full-screen mode independently of your primary display settings.

Update 1: Airport Woes

When running in battery mode, Airport performance is horrendous, even after installing the latest keychain fix. The signal will go up and down and the transmit rate will jump up and down wildly between 0 and 54 before eventually just disconnecting – it seems to disconnect every couple of minutes.

The question is, is this a) a continuation of the connection stability problems I was having in Tiger but manifesting itself with different symptoms (or simply that Leopard is more responsive to Airport connection status changes than Tiger), b) an entirely new problem created by the latest Airport drivers, c) a hardware issue (dodgy Airport cards?) or d) a problem with my router.

Until I can test out Airport performance on my Mac Mini in Leopard, I can’t rule out D although the fact that many other people are having the same problem seems to suggests this is not the case. Airport performance seems reliable when connected to the mains, so maybe its an issue of power consumption by the Airport card?

Something else that I just noticed: there appears to be a rather nasty looking, if ultimately harmless, rendering bug when scrolling in Finder when in column mode:

More Airport updates

I’m beginning to become more and more convinced that the problem with Airport is a power issue. My Airport connection seems to be very stable with no disconnections when running on mains power but in battery mode the disconnections come very frequently. I’ve also managed to perform the following test with reliable results: plug in the power adapter and wait a few minutes to confirm a stable Airport connection. Now remove the power adapter – in my observations, about 80% of the time the Airport connection will drop within 10 seconds. This would indicate to me that the problem lies in the Airport card not being able to draw enough power to operate in a stable manner whilst running in battery mode.

Yet another update

I mentioned earlier that I was having trouble getting Front Row to display on my TV even though it was set as the primary monitor. Last night I gave it another try and et voila; Front Row was displaying on my TV. Further investigation led me to this post on the Apple discussion forums:

“Not sure if this is related to the bugs you are having, but one I’ve noticed and reported to apple is this: When you first start front row it appears on your primary display, it also remembers which display it first started on. So, if you exit but don’t kill the front row process (in activity manager), front row will always display on that initial primary monitor, even if you swap your primary/secondary in sys pref. I haven’t tried mirroring the displays. ” cmendill, Apple Discussion Board

I haven’t had the change to verify this (yet) but it makes sense – if exiting Front Row doesn’t actually kill the process, then Front Row will not pick up changes to your primary display settings until you do. I still consider this to be a bug but at least it’s an explanation!

Leopard reviews:

Demeter's Revenge

2007-10-18T14:01:00Z

For those who aren’t aware, the Law of Demeter – when applied to object-oriented programs – is a rule that determines which objects another object can send messages to based around the notion of an object knowing as little about the internal structure of the objects it interacts with.

It is commonly summarized as “Only talk to your immediate friends”. Please read the above Wikipedia article for more information and background.

This notion, when applied to Rails applications is equally valid however certain Rails practices seem to encourage demeter violations either through convention or API design and this can cause problems in all layers of your application. I am not the first to voice these concerns.

The issue of Demeter violations in views is a tricky one and not everybody agrees with Jay’s approach to solving violations in the view. Personally, I feel that when it comes to removing Demeter violations in the view, both approaches of adding simple wrapper/delegate methods or larger presenter-based solutions can be useful and choosing which approach to take depends largely on the complexity of the view in question.

Dealing with Demeter violations in Rails

However, my main concern with Rails when it comes to Demeter violations are those found in the controller and model. At Reevoo we try to write as much of our code using TDD or BDD as possible, making use of mocks and stubs to avoid unnecessary database calls (in both model and controller tests). It’s the issue of mocking and stubbing where Demeter violations can be particularly problematic as James and I found on a recent internal greenfield project.

Our new project was written using the Rails 2.0 pre-release and was written in a REST-ful fashion. When dealing with nested resources we would often have code that looked a little bit like this:

class WidgetsController < ApplicationController

  # POST /users/xxx/widgets
  def create
    # where @user was loaded in a before_filter
    @user.widgets.create(params[:widget])
    # and handle the result...
  end

end

We’re using the Rails convention of creating our associated widget object directly off of the User has_many association proxy. No apparent problem here but given that we wrote this test-first, look at the lengths we had to go through to make this work using appropriate mocking/stubbing:

class WidgetsControllerCreateActionTest < Test::Unit::TestCase
  def setup
    # usual rails controller test setup here
    @user = mock('user')
    User.stubs(:find).returns(@user)
  end

  def test_should_create_new_widget_for_parent_user_using_posted_widget_params
    widgets_proxy = mock('association proxy')
    @user.stubs(:widgets).returns(widgets_proxy)
    widgets_proxy.expects(:create).with(:name => 'my funky widget')
    post :create, :widget => {:name => 'my funky widget'}
  end

Because we are violating Demeter by getting a reference to the association proxy and then calling the create method on it all from within our controller, we’ve had to create a mock assocation proxy and stub the association proxy method on user to return it before we can set the expectation that we really care about (the :create call). It might not seem like a big deal, but we also have to make sure we stub @user.widgets to return something in every one of our tests for the create action otherwise we’ll find ourselves having problems with :create calls on a NilObject. Now multiply this issue by every single controller that contains a create action and things start to get very tedious.

The solution

The solution itself is not complicated and simply involves encapsulating the association proxy:

class User
  has_many :widgets

  def create_widget(*args)
    widgets.create(*args)
  end
end

Now our tests become much simpler and the intent clearer:

class WidgetsControllerCreateActionTest < Test::Unit::TestCase
  def setup
    # usual rails controller test setup here
    @user = mock('user')
    User.stubs(:find).returns(@user)
  end

  def test_should_create_new_widget_for_parent_user_using_posted_widget_params
    @user.expects(:create_widget).with(:name => 'my funky widget')
    post :create, :widget => {:name => 'my funky widget'}
  end

For our other tests, we only need to stub one method, the :create_widget method.

Again, whilst this doesn’t seem like a lot of effort, we now find ourselves having to write small delegate methods on all of our ActiveRecord models; and it’s not just create – we also find ourselves writing similar methods for all of our other association proxy methods (delete, update etc…). This too becomes very tedious, which is why my first thought was to try and automate the creation of these methods. This is where Demeter’s Revenge comes in.

“Demeter’s Revenge” is a simple extension to ActiveRecord, written as a Rails plugin that creates a collection of Demeter-friendly methods for your has_many and has_and_belongs_to_many associations. It doesn’t require any special configuration or installation – simply install the plugin as you would any other Rails plugin and your methods will become available to you. Here’s a quick overview of some of the methods you get access to and their standard Rails equivalent:

# given a User that has_many Widgets
user.build_widget(params) # => user.widgets.build(params)
user.create_widget(params) # => user.widgets.create(params)
user.number_of_widgets # => user.widgets.size (or .length)
user.has_widgets? # => user.widgets.any?
user.has_no_widgets? # => user.widgets.empty?
user.find_widgets(params) # => user.widgets.find(params)

For more examples, the plugin comes with a suit of RSpec examples. If you want to take a peek under the hood at the implementation, there is a full suite of specs. You can grab the plugin from my Subversion repository:

svn://lukeredpath.co.uk/var/svn/plugins/demeters_revenge/trunk

If you’re writing Rails apps and mocks and stubs have been causing you pain and/or Demeter violations make you cry, then hopefully this plugin will be of use to you. If you don’t care about Demeter violations and don’t use mock’s and stubs then its probably of less interest to you but I hope you give it a try anyway. If you have any feedback, feel free to drop me an e-mail (see the “correspondence” link in the site header bar) or leave a comment below.

Addendum

One of the things I’m not sure that I made very clear when I first wrote this entry was that this plugin is by no means a silver bullet to end all of your Demeter violation woes, nor are the problems experienced with mocking/stubbing the only reason to avoid violation Demeter violations which I could spend a whole article expounding on.

It just so happens that the pain felt when mocking/stubbing is symptomatic of Demeter violations in your code which should be enough to set alarm bells ringing. In the comments, Neil mentions that this is symptomatic of a problem with the mocking framework; whether or not you believe this to be true, any efforts to allow your mocks to work in such a way that would allow Demeter violating code to be easily mocked/stubbed, I fear that this would simply be a case of sweeping the problem under a rug and hoping nobody notices.

Tumbling

2007-09-23T19:51:00Z

Since I started blogging again a few months ago, I thought it would be a good idea to set up a tumblelog (courtesy of tumblr) to encourage me to post more frequently without having to spend time writing full-length blog entries.

In case you missed new navigation bar along the top of this blog (or you are reading this in your newsreader), then you can access my tumblelog here.

Besides the obligatory tumblelog fare (quotes, chat excerpts and so on) I tend to post any useful, interesting or plain esoteric code snippets that I have written or come across, so please do check it out. You can also subscribe to the feed.

Here are some recent snippets:

On an unrelated note, I did attend RailsConf Europe last week but have yet to finish my write-up. To everybody I got the chance to talk to while I was out in Berlin, it was good catching up and enjoy numerous beers. I have to say thanks to my employers, Reevoo for financing the trip. There were some interesting talks and I enjoyed myself overall but unfortunately were also some disappointments – more on that in my full write-up.

Rimuhosting...singing their praises

2007-09-02T20:51:00Z

I don’t usually post this kind of thing on my blog but when somebody experiences a level of customer service that seems to be so lacking these days, one feels the need to shout about it.

I’ve been hosting this blog on RimuHosting for about a year now – a basic 160MB VPS setup running nginx and one mongrel to power this blog and lighty on my second IP for PHP apps (like Mint Stats and RoundCube Webmail. The VPS also acts as a home to my mail and Subversion repositories.

In all the time I’ve been with RimuHosting I’ve experienced good uptime with problems being sorted out quickly and efficiently. I’ve not had much need to trouble their support team but having just purchased a shiny copy of Warehouse I needed some more RAM to handle a second mongrel instance. I submitted a support ticket asking for a quote, indicating that if it should cost less than an extra $10 a month that they should proceed.

In the time it took me to purchase and download a copy of Warehouse, scp it to my server and untar the thing, my VPS was restarting with its extra memory. All in all, about 5 minutes from the time I submitted my ticket. On a holiday weekend. On a Sunday. That is true customer service.

So, if you are in the market for a personal geek-friendly VPS at a decent price with great support then consider this an obligatory plug for RimuHosting. Tell ‘em Luke sent ya!

Update: Warehouse is now up and running.

Sending SMS messages from your Rails application

2007-08-29T15:46:00Z

Something I’ve seen come up on the Ruby/Rails mailing lists/google groups from time to time is how to send SMS messages from your Rails app. In this article, I’ll introduce you to my Ruby Clickatell library and how to use it to send SMS messages from your Rails application in no time.

When it comes to sending an SMS using Ruby there are two approaches you can take. The first – and more complicated – is to use your own hardware and something like the ruby-sms library to communicate with the hardware. This set-up is time consuming, a pain to maintain and probably not very scalable.

The second option is to take the much easier route and use an existing SMS gateway service. There are many SMS gateways out there that offer APIs (ranging from HTTP/FTP based to email and COM-based); one such provider is Clickatell who are one of the bigger providers out there with a range of services whose customers include Barclays Bank, the BBC and CNN.

Getting started with the Ruby Clickatell gem

Before you can start sending SMS messages from your Rails app, you’ll need a Clickatell account. You can sign up for an account (Clickatell Central API) on their website. Once you have signed up you can log into your account centre and add an HTTP service to your account – this will give you an API key that you will need to use in your code.

Once you’ve signed up, you need to install the Ruby Clickatell gem. I’ve just released version 0.4 and its fast approaching being stable for production use – all it needs is some users to test it out a bit more extensively. So install it and give it a go:

$ sudo gem install clickatell

The gem also comes with a handy command-line utility, “sms”, which can be used to send SMS messages directly from the command line. For more information, simply run:

$ sms --help

More information can be found on the website.

Integrating with Rails

For our basic example application, which will use REST-ful conventions, we will expose a single resource – sms – which we can POST to to send an SMS to a specified recipient. First of all, lets create a simple wrapper around the Clickatell API which will act as our “resource” that takes a hash containing our username/password/api-key and has an ActiveRecord-style create method.

require 'clickatell'

class SMS
  def initialize(config)
    @config = config
  end

  def create(recipient, message_text)
    api.send_message(recipient, message_text)
  end

  private
    def api
      @api ||= Clickatell::API.authenticate(
        @config[:api_key],
        @config[:username],
        @config[:password]
      )
    end
end

The above wrapper isn’t strictly necessary but it helps to keep our controller as skinny as possible.

For convenience, we’ll want to keep our Clickatell credentials in a YAML file in the config folder of our Rails app:

# config/clickatell.yml
api_key: abcdefghi123
username: joebloggs
password: secret

We’ll also want to access this config within our Rails app easily:

# config/environments/production.rb
CLICKATELL_CONFIG = YAML.load(File.open(File.join(RAILS_ROOT, 'config', 'clickatell.yml')))

Bringing it altogether

Now we’ll want to configure our routing to expose our SMS resource:

ActionController::Routing::Routes.draw do |map|
  map.resource :sms
end

Next, we’ll create our form under app/views/sms/new.rhtml:

<% form_tag '/sms', :method => :post do -%>
  <label>Enter the recipients mobile number:</label>
  <%= text_field_tag "recipient" %>
  <label>Enter your message:</label>
  <%= text_area_tag "message_text" %>
  <%= submit_tag "Send SMS" %>
<% end %>

Finally, all we have to do is create our controller’s create method to handle the form submission.

class SmsController < ApplicationController
  def create
    sms = SMS.new(CLICKATELL_CONFIG)
    sms.create(params[:recipient], params[:message_text])
    flash[:notice] = "Message sent succesfully!" 
    redirect_to :back
  rescue Clickatell::API::Error => e
    flash[:error] = "Clickatell API error: #{e.message}" 
    redirect_to :back
  end
end

And thats all there is to it. Of course, in a real application you might want to think about things such as validation of required attributes and message length. I’ll leave that as an exercise to the reader.

For more information:

Breaking the silence

2007-08-02T10:50:00Z

I started my last blog entry with the sentence: “It’s been a while since I blogged”. To use the same sentence to begin this entry would be somewhat of an understatement. Its been six months today since my last post.

There are various reasons for this but the main one would be lack of motivation. Whilst working at Coherent I managed to lose touch with the Ruby/Rails community; I didn’t make it to any LRUG meetings, I wrote precious little code outside of work and my enthusiasm just disappeared. This was partly due to me being the only developer at Coherent and partly down to me just burning out towards the beginning of the year.

However, things have changed somewhat over the past few months. I have left Coherent and I am now a member of the great team at Reevoo. Since starting at Reevoo, I have regained some of my enthusiasm and have now finally found the time to post something here. I even made it to LRUG last month.

Allow me to give you a brief update on some of the projects that I have been involved in:

RSpec article part two: unfortunately this has just been far too long coming. RSpec has changed a fair bit (for the better) since that article and is now quite out of date. There are plenty of other great developers out there writing about RSpec as well now. What I intend to do is revisit my original article and update it to reflect the latest version of RSpec. And while there will not be a “part two” per se, I do intend to write about RSpec more in the future.

UJS – the UJS project has come to a grinding halt over the past six months for several reasons on both mine and Dan’s part. We are still undecided on where to go with the project at this point but it is unlikely that development will continue on the plugin unless somebody else volunteers to take over the project. Read this entry on Dan’s website for more information.

Refactoring REST – the subject of my last blog entry; I still have this code lying around and whilst I haven’t had much of a chance to explore it further I still intend on developing this, time permitting.

Rails Plugin Repository – work on this, too, has unfortunately come to a halt. I still speak to James Adam who just so happens to be joining us here at Reevoo in the coming weeks. So maybe this will be resurrected, or maybe it won’t.

So to the future…things are going great here at Reevoo – we’ve just launched a brand new version of Reevoo. Be sure to check it out. We have some other exicting developments in the works too.

Because I don’t always have the time to post full-length blog posts I set up a tumbelog some time ago which I never got around to using (I didn’t even publicise it). However I plan to start posting to it frequently from now on, so add it to your bookmarks/news reader feeds.

Finally, I will be attending “RailsConf Europe 2007”: along with my Reevoo colleagues Paul and Ben. I look forward to seeing you all in Berlin.

Refactoring REST: searching for an abstraction

2007-02-02T22:12:00Z

It’s been a while since I blogged. Sorry about that. Needless to say, it’s been a hectic couple of months. Birthdays, Christmas, New Year, a new job; all found their way towards keeping me from that big shiny text-box in Mephisto’s admin interface. For those still waiting for part two of my RSpec tutorial – and I know I’ve said this several times already – it will be coming; I’m just not sure when yet. There are some interesting developments afoot in the world of RSpec and I’ll be waiting until these make it into the next major release before tackling the article.

In this article, I’d like to talk about REST. The world of REST and resources has been a part of the Rails edge for a while now, since the last RailsConf in fact and whilst skeptical at first, I’ve really come around to the concept of RESTful resources. Whilst I still feel that it is not always suitable I’ve found that the best approach is combination of RESTful controllers and RPC-style controllers where necessary. One of the great things about the RESTful approach is that it really brings the idea of good object-oriented design – specifically the idea of objects having a clear focus on a particular task – to Rails controllers. The downside is that normalization of REST-style controllers has led to, in my experience, a lot of repetitive code. And as every good programmer knows, duplication should be hunted down and destroyed whenever possible.

The wonderful world of REST

The RESTful resources concept focusses on seven core actions: index, show, new, create, edit, update and destroy. These actions expose four core behaviours of your ActiveRecord objects through some of the various verbs available in the HTTP spec: retrieval (GET), creation (POST), updating (PUT) and deletion (DELETE). If you’ve been working with RESTful resources for any length of time you will find that the code for each of these actions tends to look very similar largely due to the use of convention over configuration that Rails favours heavily.

Whilst looking at refactoring portions of our company intranet, it struck me that such duplication was rife and I set about eliminating it. Ever mindful that the best abstractions are extracted (just like Rails was), all of the ideas and code that follows have been extracted directly from our intranet application.

I’m not the only person who has recognised the duplication that tends to result from taking the RESTful approach and consequently some solutions for making development of RESTful applications exist already in the form of generators and scaffolding.

Existing solutions

The problem with generators is that they don’t actually solve the problem of duplication in the code – they simply make it easier to get up and running by generating boilerplate code for you to modify. But once the code is in place it is still something to be maintained.

The problem with scaffolding is the same problem that plagues the scaffolding that originally came with Rails – it provides a very generic abstraction with little in the way of flex points which means you usually end up overriding the scaffolded methods anyway. You can usually generate scaffolding directly into the source itself but this has all of the same problems as generators.

An alternative approach

My approach was to first attempt some small, fine-grained refactorings on my controllers such as Extract Method to make sure that the REST actions focussed on their core responsibilities and delegated to template methods for specific behaviour. A common example is the create action, which usually looks something like this:

def create
  @user = User.new(params[:user])
  if @user.save
    flash[:notice] = 'User created successfully'
    redirect_to user_url(@user)
  else
    flash[:error] = 'User creation failed'
    # some specific error handling
    render :action => 'new'
  end
rescue SomeException
  # exception handling here
end

After extracting functionality to template methods, I ended up with code like this:

def create
  user = User.new(params[:user])
  if user.save
    handle_successful_create_for user
  else
    handle_failed_create_for user
  end
rescue
  handle_exception_for_user
end

protected
  def handle_succesful_create_for user
    flash[:notice] = 'User creeated successfully'
    redirect_to user_url(user)
  end

  def handle_failed_create_for user
    @user = user
    flash[:error] = 'User creation failed'
    render :action => 'new'
  end

  def handle_exception_for user
    # exception handling here
  end

The same approach is taken for other methods and after making this refactoring I am now left with identical RESTful actions across my application. Some might feel that the next step was to extract a super-class but there was still some variation that hadn’t been eliminated – each controller worked with a different model. I was also somewhat uneasy about using inheritance to eliminate duplication – it is often a good idea to favour composition where possible¹. However a solution that uses composition is awkward because the object model for Rails controllers is abstracted in the framework. Fortunately Ruby provides us with an alternative that allows us to avoid modifying the inheritance tree in the form of mixins. Using include and extend we are able to add functionality to classes and their instances. This is the approach I decided to take but that still left that pesky model variation to deal with.

Refactoring further: extending the DSL

Once again Ruby comes to the rescue with it’s excellent meta-programming functionality. We take advantage of that functionality all of the time in Rails when we use it’s macro-style class methods; filters and ActiveRecord associations and validations are great examples. Using meta-programming, it was relatively easy to come up with a small DSL for exposing resources with a controller. Here is the first part:

class UsersController < ApplicationController
  expose_resource :user
end

As it clearly states, this tells the UsersController that we want to expose our User model. We can use this value throughout whatever code we write to generate each action. The next thing to tackle was how to generate these actions at runtime. I studied the scaffolding code that comes with Rails but wasn’t really comfortable with treating code as a template and running it through an eval statement. I decided to take a more object-oriented approach and created a series of command objects to represent each action. This solution was easy to test and extend where necessary.

Finally, there needed to be some way of specifying what actions RESTful actions you want to expose – you might not want all seven. This lead to the second part of the DSL:

class UsersController < ApplicationController
  expose_resource :user, :except => [:update, :destroy]
end

Of course, you might only want a few of the actions:

class UsersController < ApplicationController
  expose_resource :user, :only => [:index, :show]
end

So where does that leave us? All of the core functionality is in place and all that the developer has to provide is an implementation of the various callback handlers. With some sensible default implementations to these handlers built-in, the developers life is made even easier.

One size does not fit all

It is worth noting that there isn’t a callback handler designed for every situation. Besides the sheer difficulty in guessing all of the flex-points that a developer might need, it would require a lot of bloated unnecessary code just to cater for edge cases. The above abstraction was never designed to cover all cases and I don’t believe any abstraction ever can. However it does make it possible to add functionality quickly at least 80% of the time and it handling the remaining 20% of cases is as simple as the developer providing their own hardcoded action.

All of the code discussed above is available as a Rails plugin that I’ve called restful_exposure. It can be checked out with Subversion at the following URL:

svn://lukeredpath.co.uk/opensource/plugins/restful_exposure/trunk

A README is bundled and all code is released under the MIT license.

Feedback

At present, most of the callback handlers are lacking implementation. This code is only a couple of days old and is not considered production-ready by a long shot. For starters, it is completely lacking any form of test coverage. I used our existing test coverage for our intranet to guide my way during refactoring but it is my plan to add a good suite of RSpec specifications. This isn’t even live on our intranet yet and currently lives on a branch of our intranet code.

In addition to the above functionality there are a few other features that came about as a direct result of extracting this from our intranet application. The first is the introduction of a parameterized index action. It is common to have some alternative collection actions as well as index – archives, search and recent are good examples. They both retrieve a collection of objects but the number of items retrieved, their order and how they are filtered varies. This variation is encapsulated by the index parameter which is passed into ActiveRecord::Base#find as its options hash. This lets you do things like this:

def recent
  index :limit => 5
end

Another thing that it was important to handle was nested resources, representing belongs_to/has_x relationships. One of the impacts this had on the code was in the creation of new objects – the new action had to ensure that the new object created (to be bound to the new form) was linked to its parent object. Getting the parameters for this is made easy by convention and URL parameters made available by nested resource routes so it wasn’t a problem to extract. This lead to the first option for expose_resource:

class FilesController < ApplicationController
  expose_resource :file, :nested_under => :folder
end

The second option came from the need to link new objects to their parent object when working with tree-like nesting of a single model using acts_as_tree. Support for this is built-in using the as_tree option:

class FolderController < ApplicationController
  expose_resource :folder, :as_tree => true
end

I’m well aware that the Rails community is an opionated one (naturally) and that this might not appeal to some people. Some people might perceive this as “too much magic”. Personally I’d disagree – I think this is no more magic here than has_many and acts_as_foo. It has been extracted from a real working application and I think that is important. I have a “3 strikes” rule when it comes to abstractions like this – if I’ve done the same thing three different times or on three different apps then its time to look for that abstraction and reduce the amount of code that needs maintaining. This “3 strikes”/abstract through extraction approach is exactly the same one that lead to my crypted_authentication plugin.

If you are working with RESTful resources and have found yourself typing the same thing over and over again, please do checkout the plugin and give it a try. I repeat, this is not production-ready but I’m really interested in people’s feedback on the approach and any suggestions. Do dig into the source to get an understanding of how I’ve approached the implementation. I’ve tried to avoid Ruby-fu “magic” wherever I can in favour of traditional object-oriented approaches.

Are there any areas such as the nesting/tree-like structures above that you find yourself doing often that would be a good fit for abstraction? What do you think of the API? Comments are open!

Update 05/02/2007: As per Steve’s suggestion in the comments below, I’ve modified the interface so that it uses just the single expose_resource call, with :only and :except options (:all by default) as per the Rails filters API. I’ve updated the code samples above to reflect this. expose_resource_actions has been removed.

¹ It is a generally accepted object-oriented design rule – and one that I agree with and try to adhere to – that composition leads to less coupling and polution of the inheritance tree (which should really only really be used when objects really are of similar type). I also find it leads to more easily testable and elegant solutions.On Google.

Pastures New

2006-12-01T12:53:00Z

Last Thursday was my last day working for Agile Evolved. I enjoyed my time at AE and want to say thanks to Jonathan for employing me in the first place and giving me the opportunity to grow as a programmer, work full-time with Ruby and Rails, contribute to the open-source community and to become an active part of the London Ruby community. Good luck to everybody at Agile Evolved!

The new job

This Monday I started my new job as Head of Software Development for a London-based media company. Unfortunately, at the request of my employers I’m unable to say who I am working for—don’t get excited, it isn’t anybody you would have heard of anyway (probably) but I am really excited about the challenges I will be facing over the coming months.

Obviously there is little I can say about what I will be working on at this moment in time but needless to say we will be fully utilizing the power of Ruby and RubyOnRails and other open source software on several large-scale projects in what could be one of the largest-scale deployments of a Ruby/Rails application. Exciting stuff! I’ll try and post information on how we are using Ruby whenever I possibly can, confidentiality and approval from our PR department pending of course.

Project updates

Some of you may be wondering where this leaves the numerous open-source projects that I am working on. Naturally, I will be very busy over the coming months but I was keen to stress that how important contributing to open-source software was to my new employers and I have their full support so my involvement will continue pretty much as it is, as will my participation in the Ruby community…I’ll have to drag our CTO (aka my boss) down to the next LRUG meeting.

Dan and I will do our best to get a new release of UJS out of the door before the end of the year. It is most likely that we will put back any new features to a 0.5 release and concentrate on bugs and Rails 1.2 compatibility for 0.4. My work on ActiveSpec will most likely be put off until the new year now. Meanwhile, James and I are almost ready with the official Rails plugin repository—it should hopefully be ready in time for the Rails 1.2 final release.

I’m also happy to announce that I have officially joined the RSpec development team. My initial contributions will likely be towards the RSpec TextMate bundle but I hope to get even more involved in the new year.

And finally…

On the subject of moving on, I recently moved my blog from Site5 to a Rimuhosting VPS. Site5 weren’t bad for a shared host but they had no Mongrel support and frankly FastCGI and Rails is just painful.

For those interested in my setup, I have two allocated IP addresses – I’m running Nginx on one IP as a proxy to Mongrel for any Rails apps (currently just this blog) and lighttpd on the second IP address for serving up any static content or PHP apps that I might need (such as Mint Stats and Roundcube Webmail). The setup works well and was easy to get up and running—not having to use Apache 2.2 also saves me plenty of resources which is great because I only have 160MB of RAM to play with on my current plan.

I really recommend a VPS if you are running Rails apps and Rimuhosting are very good value for money. The only pain for me was setting up my mail server with Postfix, Dovecot and SpamAssassin which was a new and painful experience for me. I got there in the end though and I can now have my own Subversion repositories and I will eventually have an instance of Trac up and running for my various open-source projects. Stay tuned!

RJS templates without the R!

2006-11-17T12:02:00Z

In terms of making AJAX applications easier to develop, RJS templates are one of the most significant additions to Rails over the past year. They were far more elegant than adding AJAX callback hooks throughout your main RHTML templates (which was just plain ugly) and it let you get access to your model data in your JavaScript response easily. For many, the killer feature was being able to write your AJAX response behaviour in Ruby—one language to rule them all. The forthcoming Simply Helpful plugin takes this even further. However, not everybody is as keen on RJS templates and a new plugin by Dan Webb seeks to change the way you write your AJAX functionality in Rails.

Dan and I have had several discussions over a few beers about RJS and Dan being the JavaScript wizard that he is was of the opinion that writing JavaScript behaviour in Ruby was an abstraction too far. His reasoning was simple: JavaScript when used correctly can be a powerful language and adding a Ruby API on top was an extra layer of magic that just wasn’t necessary. Whilst he made a fair point, I still felt that RJS was infintely better than the old way of doing things and that its pros outweighed its cons…until now.

The main con with RJS is that you are depending on another layer and if that layer isn’t complete you have to revert to JavaScript anyway—you can do this in RJS by using page.call but this is ugly and really highlights its shortcomings. It would probably be fair to say that RJS as it is currently implemented, is a leaky abstraction. Not only that, but RJS is tightly coupled to the Prototype JS library and Scriptaculous – for fans of one of the many other JS core/effects libraries out there you are left with either the option of trying to port RJS to your library of choice, using page.call commands or resorting to the old callbacks method.

I was somewhat blinded by the “cool” factor of writing my JS behaviours in Ruby—after all I’m a Ruby programmer first and a JavaScript guy second. But when I really think about it, all RJS does is limit me when I want to do anything outside the simple cases that RJS caters for. But the idea of returning a behavioural response from a template is an excellent one and that has always been the overriding factor for me.

As of today, a new option has become available in the form of a new plugin courtesy of Dan – MinusR: RJS templates, without the R! Thats right, RJS templates that let you write your behaviour in JavaScript instead of Ruby. Not only that, but you can still get access to your model data (or other things such as helpers) by embedding ERb—MinusR comes with a js() helper method that encodes the output of your ERb output block in JSON. And finally, you can use whatever JS library you like.

So check it out and start embracing JavaScript. Also check out Dan’s blog post about MinusR.