confessions of a ruby programmer

Online accounting for freelancers

2009-03-16T00:00:00Z

When I decided to go freelance, I spent a lot of time researching the different options available when it comes to running my own business. The simplest route is to register as a sole trader but this increases your liability and isn’t the most tax-efficient route (all profit is treated as taxable income). I briefly considered operating through an umbrella company but after some troubles getting up and running with one I decided to bite the bullet and form my own limited company.

Of course, with this option comes a whole host of administration and responsibilities; you’re going to need an accountant. You can either find a good accountant and pay them for advice and preparing your end of year returns as and when you need them to or you can pay for a monthly service and have them take care of almost everything for you. Whichever option you choose, it is well worth learning some basic accounting principles and even if you’re accountants are doing everything for you, I highly recommend keeping your own books too because ultimately as the company director you are liable for any mistakes.

Accounting software, the options

If you’re going to do your own books, you’re probably going to need some kind of software to keep track of everything. You could use a spreadsheet but there are slicker options available. There are a variety of desktop software packages but there isn’t much available for the Mac (and don’t want to boot up Windows in a virtual machine just to do my accounts). After some research I came across two online services that cater for the UK: FreeAgent and Xero. I have used Xero for the past couple of months and have now moved over to FreeAgent for reasons I’ll outline towards the end of this article.

Xero, “the worlds easiest accounting system”

Xero was the first service I came across; a New Zealand-based company who have recently branched out into the UK. They offer a full accounting solution for £19 + VAT per month.

Xero has an attractive and intuitive interface and it presents an overview of your company finances in a clear and concise manner. It will allow you to set up your various bank accounts (including any credit card or Paypal accounts) and import statements directly from your bank (it supports the standard OFX and QIF formats). It will generate attractive looking invoices for you and makes it really simple to track and manage your outstanding debtors including the ability to generate PDF statements and email reminders.

Dealing with expense claims can be a bit convoluted if you’re a one-man company. Xero’s expense claims features seem to be aimed more at larger companies that deal with multiple claims from multiple employees, requiring each claim to be itemized and approved which makes the process a bit long-winded.

Xero’s killer feature is it’s transaction reconciliation interface. Xero maintains a strict separation between your “Xero balance” and your various bank account balances, which are reconciled when you import a statement. This is all done using a combination of clever transaction matching and an intuitive interface that makes bank reconciliation a piece of cake.

FreeAgent, “online accounting nirvana”

FreeAgent offers an online accountancy solution for a range of different setups, starting from £15 + VAT per month for sole traders up to £25 + VAT per month for limited companies. They also offer a great referral scheme where you receive a permanent 10% discount for each person you refer (and who signs up to a paying account) meaning you can actually get the service for nothing if you refer 10 people. Each person you refer also receives a 10% discount on the monthly subscription.

FreeAgent is aimed squarely at freelancers and small businesses. Whilst Xero can be a bit intimidating for a newcomer to the world of accountancy, FreeAgent keeps things simple; instead of Accounts Receivable and Accounts Payable, you simply deal with Invoices and Bills. Reports are accessible and clear and concise and like Xero, the user dashboard prevents a great overview of your accounts. It even has an iCal feed of important dates (such as when PAYE, VAT and company returns are due).

FreeAgent’s focus on freelancers who operate their own limited companies is one of its strongest selling points; out-of-pocket expenses are dealt with easily, it has basic project management and time-tracking functionality and it does basic payroll for company directors. It even does the calculations for your personal self-assessment tax return.

Xero vs FreeAgent, a conclusion

Having used Xero for a few months (and finding it a pleasure to use), I ultimately decided to move to FreeAgent for several reasons.

Firstly, and most importantly, was it’s support for the flat-rate VAT scheme which Xero doesn’t currently support. This effectively made Xero’s reporting functionality useless to me as it wasn’t able to deal with my VAT and turnover figures correctly. FreeAgent deals with this perfectly, even remembering to exclude revenue outside of the scope of VAT (i.e. for US-based clients).

Secondly, the features aimed at small, one-man companies such as mine like the directors payroll, self-assessment calculations and simplified expense tracking means my life is made all the more easier, to the point where I’m actually considering canceling my monthly accountancy service and getting advice on an ad-hoc basis instead (at around a third of the cost).

One thing missing from both Xero and FreeAgent is multi-currency support although both of them are apparently working on this. However, its not impossible to manage your foreign-currency invoices in either system although it requires doing the currency conversion and handling of exchange rate fluctuations manually.

Despite having moved away from Xero, my overall experience with it was positive and they were very receptive to my feedback (several members of the Xero team can be found on Twitter). To get the most out of Xero it can be useful to learn about double-entry bookkeeping and some basic accountancy terminology but this isn’t necessarily a bad thing; in fact I’d recommend doing this whichever system you use.

Both offer free 30-day trials and neither lock you into contracts so if you’re looking for a great, intuitive online accountancy system I’d recommend giving them both a try. Overall I feel that right now, FreeAgent offers the best combination of features and simplicity for freelancers. If you want to grab that 10% discount, you’re welcome to use my referral code.

Automating iPhone releases with Rake

2009-03-03T00:00:00Z

So far for me the release process for Squeemote has been fairly manual. After checking the final release several times using a development build, then an ad-hoc build, the time would come to create a distribution build. I’ve done this several times now and each time I’ve gone through the same tedious steps so I thought it’s time I wrote myself a Rake task to automate the process somewhat.

If you’re a Ruby/Rails developer you will no doubt have Rake installed. Otherwise, with Ruby installed (which you should have as it ships with Leopard) then you can install the latest version of Rake using the command gem install rake. If you’re not familiar with Rake, to use this task, create a file named Rakefile in the root of your project and add the code below. To run it, simply execute rake release from a Terminal.

The Rake task is still in it’s infancy but I will continue to update the gist as I make further improvements. It performs the following steps:

Bumps the build number using agvtool (see this article on using agvtool)
Builds the release using my main target and by default the Development distribution
Creates a folder in my saved releases folder and copies the built package (and the dsym file) to the release folder.
Compresses the package into a zip file ready for uploading to Apple.

Feel free to modify this to your needs; I encourage you to fork the gist and make your changes available for everybody else.

The configuration and SDK can be overridden using environment variables so its possible to use this task to build ad-hoc releases too. The main feature currently missing is checking whether or not the build was successful or not before continuing, something I’ll fix shortly. It also doesn’t set the agvtool “marketing version” (e.g. 1.2), which I generally do manually on my repository master branch when starting work on the next version of my app.

If anybody else has any nice tips for automating their iPhone development workflow, I’d like to hear them.

Bringing device sync to Squeemote

2009-02-17T16:00:00Z

Since the first release of Squeemote arrived in the app store in mid-December, over 500 people have bought a copy, which is more than I’d ever imagined considering it was only originally built to fulfill my own needs (I’ve wanted to be able to control my Squeezebox like this for years).

It’s been a busy couple of months for me, ever since I decided to go it alone and especially since starting a new client project a few weeks ago, I’ve not had a lot of time to focus on Squeemote. I’m starting to pick it up again and I thought I’d give a small insight into one of the forthcoming and oft-requested features, device synchronization.

Getting the interface right

Device synching isn’t something I’ve used much in the past being the owner of just a single Squeezebox but now I also own a Squeezebox boom its something that has become more interesting to me. I’m also very aware that a lot of Squeemote owners own numerous devices and use synching frequently.

I’ve always intended to support device synching but I omitted from the first release due to the complexity involved; I believe in releasing early and frequently and I didn’t want this to hold back the initial release. When I say complexity, I don’t mean so much on a technical level (the SqueezeCenter API makes it reasonably simple to sync devices) but more in terms of how to create an effective interface for synching devices.

Having spent some time pondering the issue, I think I’ve come up with a good first draft of the interface and I want to get it out there for existing Squeemote owners to leave feedback.

I’ve reworked the now playing interface slightly to accommodate some extra controls. On the left is the as-yet unimplemented mute control. The Squeemote icon on the right brings up the new Device Selector screen.

It’s still in it’s early stages but here’s how I see it working:

In it’s default mode (with sync disabled), it acts much like the existing devices screen. You can choose the active device and hit done, and you’ll be taken back to the now playing screen for that device. In this mode, you only ever control a single device at a time.
With sync mode enabled, one device is marked as active (the device that was active when sync mode was enabled); for the other devices, the INACTIVE button becomes a SYNC button which when pressed, will sync that device with the active device. Control is always done through the active device.

I’m still not sure how this will take into account sync groups but I have a feeling that this might be enough, certainly for an initial release. Other little bonus features from this interface are:

Quickly change device from the now playing screen instead of having go back to library mode and finding the devices tab.
See instantly what is playing on each device.
Power control for each device! (another much requested feature and a feature I curse myself for not having implemented sooner)

This will be the focus for the next release (1.2) but there will be a few other extra features thrown in such as browse by Genre.

Finally, in case you missed it, Squeemote now has an official home.

Importing comments from Mephisto into Disqus

2009-02-16T16:00:00Z

As part of my continuing effort to strip Marley down to the bare-essentials and make it as simple as possible, I’ve moved my comments over to Disqus. This means I don’t have to worry about having a database for comments, building tools to moderate those comments or handle spam. I simply drop the comments directly into the page using a snippet of Javascript (I’m actually using Norman Clarke’s Ruby disqus library to make this even easier).

To import my old Marley comments into Disqus, I used Locomotivation’s handy Sinatra Disqus Importer. It’s a super-simple Sinatra app that takes an RSS feed of your existing blog posts and comments and uses that to feed the comments into Disqus using it’s API.

I wanted to do the same for all of my old Mephisto-powered blog comments. Doing this was fairly trivial, it just required a script to take the content from the Mephisto database and spit out an RSS feed that I could use with the Sinatra importer. Having imported a mysql dump from my server into my local MySQL database, I was able to use ActiveRecord and Builder to generate the RSS feed; here’s the code in case it’s of any use to anybody. It’s a bit rough and you might need to tweak it a bit but it does the job.

Remote pair-programming using iChat

2009-02-03T15:40:17Z

When I worked at Reevoo we tried to live by a mantra of “pair on all production code”. Sometimes this wasn’t practical (there would often be times when there was an odd number of us available) but its a rule we tried to stick to wherever possible.

Obviously, now I have gone freelance, pairing isn’t always a luxury I’ll have – that’s fine, I’m comfortable working on my own – but I’ve always felt that some of the best code I’ve ever written has been code that I have written in a pair. Fortunately, for my latest client, I am able to work with my former Reevoo colleague James Adam who some of you may know as the author of the Rails Engines plugin and one of the co-organisers of the London Ruby User Group and the awesome RubyManor conference (don’t forget to check out some of the videos).

Coding remotely

From the outset, we were both agreed that we would prefer to pair on as much code as possible. The problem would be that we wouldn’t always be in the same location. We’ve both taken up membership at The Hub which gives us a shared space to work once a week or so but the rest of the time we would both be working from home.

This isn’t a new problem; in fact it was one that some of us at Reevoo have experience with using a combination of screen and vim. However, vim isn’t really my bag and I’m far more productive using my editor of choice, Textmate.

VNC was an obvious solution but if you’re both Mac users, iChat offers a far more integrated solution, offering instant-messaging, voice chat and most importantly, seamless screen-sharing. iChat’s built-in screen-sharing solution is fast enough to work on one person’s machine whilst making it easy to switch back to your own machine when necessary. Even better is if you have a dual-screen setup (I run my MacBook connected to a Dell 20" monitor). Using this setup, I can run James’ screen on my Dell, leaving my MacBook free for background tasks like email, twitter etc. It’s not perfect, there are a few technical niggles; but it has worked well for us so far.

Remote pairing tips

What has surprised me the most is just how effective this approach has been. I feel like we have been working just as effectively as if we had been sat in the same room together. We get from all of the usual benefits of pairing; the ability to bounce ideas off each-other, catch minor mistakes that the other person has missed, discuss alternative approaches to a problem and tempering another person’s enthusiasm with some caution (e.g. “maybe we could do [some cool idea]…yes that would be good but do we really need to do it now?”). If I would offer some tips when using this approach, they would be:

Make sure you’re both ready to start before you get going. Nobody likes to feel like they are being pressured into doing something. Pair-programming all day can be really draining so make sure you’re both happy to begin.
Don’t hesitate to suggest to your pair that it’s time for a break. It can be good to stop for 5 minutes every now and again to make a cup of tea, catch up on some emails.
Try to avoid unnecessary distractions whilst in full-flow. Try to turn off other IM clients or at least set your status so people know you shouldn’t be disturbed. Disable growl notifications or other annoying popups (e.g. Twitter clients). There will always be a few minutes downtime here and there which you can use to check these. Trying to do it whilst in the middle of pairing may lead to errors or missing important information and its unfair on your pair if you’re not paying attention.
Agree on who is driving at any given time, and take it in turns, swapping periodically. James and I tend to work using the “driver writes a test, pair implements test” approach. We’ll swap roles frequently but its important to know who is the main driver so you aren’t always trying to type at the same time or grabbing the mouse when somebody is trying to move in the other direction. This is probably more of an issue with remote pairing than normal pairing (unless you’re using multiple keyboards/mice!).
Don’t forget that when you are connected to your pair’s machine (and it’s in the foreground), all of your keystrokes will be sent to the remote machine. def my_methodhello mum probably won’t pass any tests.
Bonus Tip: Quicksilver can be useful for leaving the equivalent of little notes to eachother whilst the other person is away; if you’re pair has gone to make a tea/popped to the toilet and you need to leave too, just leave them a nice big message on their screen – bring up Quicksilver, hit Cmd+Period to enter text mode, write your message then hit tab and select “Large Type”. They can’t miss it.

If you’ve never paired before, or have been put off of pairing because you work remotely, give it a try; you may find you write better code than you ever did before. Does anybody else pair remotely? If so, I’d love to hear your tips.

Squeemote 1.1 now available in the iTunes store

2009-01-23T00:00:00Z

Squeemote 1.1 was finally approved by Apple this morning and is now available in the iTunes store. This is quite a hefty update with a number of new features, improvements to existing ones and numerous bug and performance fixes. Here’s the run down of changes:

Added support for browsing Music Services and Internet Radio stations.
Improved handling of music service and internet radio streams on the now playing screen, including displaying the correct artist/album/title/artwork for music service tracks.
Squeemote will now automatically discover your server.
Added support for server authentication and improved the layout of the initial setup screen.
Reduced initial startup time.
Improved display of album tracks when browsing music library.
Artists list now respects “ignored articles” server setting when sorting.
Added “clear playlist” button to current playlist screen.
Improved responsiveness of volume slider control.
Added “disable auto-lock” setting to prevent device from going into standby.
Numerous bug-fixes and performance/reliability improvements.

There are a few outstanding known issues mainly relating to Squeemote no longer picking up changes from the server after coming out of standby. These will be resolved in 1.2 which is progressing nicely and will hopefully be submitted to Apple in the next week or so.

I’m also pleased to announce that Squeemote now has it’s own website. It’s not quite finished yet but I believe in releasing as soon as possible. Look out for a Help/FAQ page over the weekend.

On a technical note, I did a fairly significant piece of refactoring to the underlying code that retrieves the remote data and displays a “Loading…” view whilst this is happening. I hope to write a blog post about the methods I used to accomplish this and will be releasing the generic code behind this under the MIT license.

Squeemote, the Squeezebox iPhone remote, ready for sale

2008-12-19T21:47:07Z

Update: You can find out more information about Squeemote on the official website

After some wrangling back and forth, I’m happy to announce that my first iPhone application, Squeemote (formerly iSqueeze) is now available on the iTunes application store.

Squeemote for iPhone and iPod Touch is a remote control application for the SlimDevices Squeezebox™ and similar devices such as the Duet and Boom. This first release is aimed at people who mainly use their own music library rather than streaming services (support of which is currently limited). I intend to add browsing support for streaming services in a later release but my main focus for this initial release was on quality over quantity: I didn’t (and do not) want to cram it with features. I focussed on making this the best possible experience for browsing your SqueezeCentre library and controlling your device.

I already have some ideas on further improving the user experience for music browsing and playlist management that will appear in a future release. Another area which is currently quite basic is device management; Squeemote supports multiple devices and allows you to choose which device to use and set a default device but there is currently no support for grouping devices for synchronous playback. This, plus browsing support for streaming services will be my priority in the next major release.

It’s been an interesting experience writing my first ever iPhone (or Cocoa) application and getting it submitted to the iTunes store but I’ll save the technical notes for a separate post.

If you have any questions or problems, feel free to leave a comment or drop me an email. I have also set up a support page on GetSatisfaction.

Quick and easy hosted websites with GitHub

2008-12-18T21:47:07Z

Chris Wanstrath from GitHub recently tweeted about his new website. Whilst trying to load it earlier today I accidentally misspelt his username, revealing a GitHub feature that I hadn’t come across – GitHub pages.

Simply go to yourusername.github.com and you’ll be presented with a friendly error page explaining how to set up your own github.com sub-domain website. It’s fairly straightforward – create a repository named yourusername.github.com, create a local master branch and push it to GitHub. Within ten minutes or so, your new site will be up and running. Very cool. Here’s mine (yes, fairly pointless I know). And here is another.

Update: It seems that I just beat the guys at GitHub to it with their official announcement.

A Brave New World

2008-12-04T15:10:53Z

I’m writing this from the depths of the London Underground system, on a Northern Line train out of the city. I’ve just come from several meetings regarding some forthcoming opportunities. This is the beginning of the next step of my career as a Ruby programmer.

Last Friday was my last day at Reevoo. I had been contemplating leaving for about a month when some unexpected changes at Reevoo forced my hand. In many ways I had become tired of working on the same thing week in, week out and I craved new challenges. It is with some regret however that I leave what is in my opinion (and others) the best Ruby/Rails team in the UK. I have learnt a lot over the last 18 months and much of that is due to the sheer breadth and diversity of knowledge across that team as well as everybody else at Reevoo. I have learnt how to be a better team player, I have come to appreciate pair-programming more than I ever did and I have faced the real day to day challenges of being part of an “agile” team.

As of this week, I officially enter the world of Ruby contracting. Inspired by the likes of Obie Fernandez (I’m a big fan of his blog and I love what the guys over at Hashrocket are doing), Jay Fields (the linked article is what really got me thinking in the first place ) and James Adam, (my former Reevoo colleague, who has recently gone “free-range”), I have decided to take the plunge and fully invest in building my “brand” and jumping head first into the contracting world. I have been working with Rails since almost the beginning and it has taken me nearly four years to get to this point. It’s a scary prospect, leaving the comfort and safety of a regular monthly income but with hard work there is the prospect of great rewards. I look forward to working with other members of the Ruby and Rails community across a wide range of projects.

if you’re looking for a Ruby/Rails expert to help out with your project.

Blogging, Git style

You may have noticed the new design. The main objective of the new design was to move towards a traditional blog-style format; I liked my old design but it certainly placed an emphasis on individual articles, something that I’ve had less and less time to write, hence the scarcity of posts in the last year. The idea is that with the new design, I feel less pressure to write long article-style entries and therefore blog more frequently. I also feel that now more than ever is an appropriate time for a refresh.

I’m no longer running Mephisto but am instead using a heavily modified version of Marley, a lightweight Sinatra app that comes with no admin interface but instead pulls blog entries from a git repository. This means I can write all of my posts offline in my favorite text editor in an iterative fashion, stored in a local git repository and pushed to github when I’m ready to publish (Marley pulls from GitHub by way of a post-receive hook). Marley is relatively new and was a bit rough around the edges but I found it a great base platform to start hacking away on (as you can see by the frequency of commits to my github fork over recent days).

I’ve also abandoned my old nginx/mongrel deployment setup and moved back to Apache running Passenger – the ease with which you can configure and deploy a simple Rack-powered app like Marley (or any Sinatra based app) is astounding. No more messing around with monit configs and restarting of mongrels for me. I’ve set up some mod_rewrite rules so all of the old blog URLs should 301 redirect to the new URLs.

There’s probably a few bugs here and there, and some of the images might be broken until I’ve had a chance to reupload them. There is currently no syntax highlighting on code samples; this is on my todo list. I’ll hopefully iron these issues out over the coming days. People who have subscribed to my feed using the FeedBurner URL should not need to change anything; those who were using the direct URL should subscribe to the FeedBurner URL instead.

Are you a Ruby and/or Rails contractor? How’s it working out for you?

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

* Timeout on any Ruby method * More sneaky #to_proc tricks

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')))

h3. 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:

* Ruby Clickatell API Website * Ruby Clickatell Documentation * Rubyforge project page * Clickatell Gateway 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.

Exploring TextMate...a Ruby perspective

2006-10-30T16:14:00Z

Marshall Vandegrift has posted an interesting screencast showing off Emacs as a tool for Ruby/Rails development. I enjoyed the screencast, and Emacs certainly has cool features but all I could think whilst watching it was (WARNING: FLAMEBAIT ALERT!)…“urgh, its soooo ugly, how could anybody work with that all day. And TextMate does all of this and in a much nicer way…”.

It got me thinking about how I use TextMate every day and whether I really take full advantage of its built-in commands and snippets for Ruby and Rails development. I wondered how many of the features in the above Emacs screencast were already in TextMate and the answer was…most of them! This inspired write a post about some of my favorite TextMate snippets and hopefully you’ll find out about a few you didn’t know about.

Whether you are a new or seasoned TextMate user, its really worth spending some time to learn some of the more useful snippets in the bundles for the languages that you are using. I’m sure most Ruby and Rails developers are aware of the basics such as do..end completion and the various snippets for creating classes, modules and methods. What follows is an overview of some of the cooler functionality built into the Ruby/Rails bundles that you might not have come across. There is a certain amount of mental overhead in learning these snippets but if you can you will find yourself being even more productive.

But first…

If you are running a stock TextMate install, you’ll only have the default set of bundles. There is a wealth of bundles in the Macromates Subversion repository. I won’t repeat the installation instructions here, but I will mention a small tip for managing your bundles.

The Macromates repository has a lot of bundles and the chances are you will only need a small selection of them. Installing all the bundles slows down TextMate’s opening times and adds a lot of noise to the Bundles/Snippets menus. Instead of simply checking out all of the bundles into your /Library/Application Support/TextMate folder, create a folder in a Subversion repository of your own, and check the empty folder out to /Library/Application Support/TextMate. Now, add all the folders in the Macromates repository except the Bundles folder to your repository as an svn:externals entry. Next, create a Bundles folder and check this in. Finally, add all of the Bundles that you want as svn:externals entries in the Bundles folder.

If the above sounds too complicated or time-consuming, you can use my own setup as a starting point.

Syntax constructs

Note: for the rest of this article, I will put any relevant tab-triggers in square brackets.

The TextMate Ruby bundle has snippets for most of the common declarations that you are likely to use…there are definitions for classes [cla], modules [mod] and methods [def] and other common blocks such as conditional statements [if, ife, elsif], loops [until, while], exception handling [begin] and generic blocks [do].

The class and module snippets, like a lot of newer snippets, use a single tab expansion for multiple snippets, with the different options appearing as a contextual menu. This reduces the overhead of learning lots of obscure triggers and gives you a good overview of what you can do with a particular trigger. The class snippets, for example, have variations for creating standard classes, classes with inheritance, classes with a generated initialize template and more. You can even create a new Test::Unit testcase, complete with the necessary requires, Test::Unit::TestCase inheritance and a default test method with a single trigger [tc].

Finally, there are snippets for many of the common tasks performed when writing a Ruby script, such as entering the shebang line [rb], requiring files [req], generating symbol => value key/value pairs for hashes [:], lambda blocks [lam], and one of my favorites, path-from-here [patfh] which is used for getting the path relative to the current script and generates:

File.join(File.dirname(__FILE__), *%w<strong>[rel path here]</strong>)

h3. Writing classes/modules

In addition to the snippets for defining classes and modules, there are some other goodies too.

If you want to add Enumerable support to your class, you need to include the Enumerable module and define an each method. To do this in Textmate, simply create a new class then inside your class definition, use the Enumerable snippet [Enum]. This will generate something like this for you:

class Foo
  include Enumerable

  def each(&block)

  end
end

In a similar fashion, the Comparable snippet [Comp] will include the Comparable module and create a stub <=> method for you to fill in.

Defining attributes for your class is a breeze – TextMate contains snippets for attr_reader ®, attr_writer [w] and attr_accessor [rw]. You can define class methods just as easily as you define instance methods [defs], alias methods [am] and overwrite method_missing [mm]. Don’t forget the singleton class for helping out with that meta-programming goodness [sin].

Other cool snippets

There are plenty of snippets for all of your favorite iterators including each [ea], each_pair [eap], collect/map [col/map] and everybody’s favorite, inject [inj]. There are too many to mention here – there are snippets for all of the common iterators and block methods defined in Enumerable and other collection classes, as well as snippets for iterating over files.

How often do you fire up IRB just to run a simple snippet of code? I do…but why waste time loading up IRB when you can execute lines of Ruby directly in TextMate? Simply write a line of Ruby code, then run the “Execute line as Ruby” command [Ctrl + Shift + E]. The result of the expression will be inserted directly on the next line.

Finally, some personal favorites. Trying to convert all those string keys to symbols in your Rails app to make things much easier to read? TextMate makes it easy to switch between strings and symbols – simply move the cursor onto the string/symbol you want to switch and hit [Ctrl + :].

Interested to know whats going on under the hood of the library that you’ve required in your script? Put the cursor over the require line, and hit [Cmd + Shift + D]. If TextMate can find the required file, it will open it for you. How cool is that?

A final, Rails-related mention goes to the Rails migration snippets. There are only three commands you need to know: columns, tables and indexes [mcol, mtab, mind]. All of the common migration commands are supported and where possible, the snippets will generate your self.down method for you, whilst you are writing the self.up method! A particularly good example of this is “Drop and Create table” – type in the name of the table you want to drop, hit tab twice and it will populate self.down using the relevant section of your schema.rb. Clever stuff.

Writing your own bundles

Of course, the real power behind TextMate lies not only in its pretty good set of existing bundles, but the ability to write your own. Writing snippets is the easiest of the lot and I really advise you to create your own “personal” bundle to store all of the little snippets tailor-made for you. The next step up is writing commands and here is the killer feature – you can write your commands in whatever language you know best, as long as TextMate can find the interpreter (it uses a shebang line at the top of your command). A lot of the built-in commands are written in Bash, but many of the Ruby commands are written in, unsurprisingly, Ruby. Take a look at some of the built-in commands to give you an idea of what you can do.

Here are some of the bundles that I’ve written that are available for all:

* RSpec TextMate Bundle * RESTful Rails – snippets for RESTful Rails development * UJS4Rails Bundle – snippets for the UJS Rails plugin

The last two are still very much under development but the RSpec bundle is pretty comprehensive and covers all of the built-in expectations, as well as the mocking API, Rails integration and spec runners.

Feedback

Have you got any favorite snippets that you want to share with the world? Let me know. You can use the comments below, although I advise for anything but short snippets that you pastie them and post the link.

Blogging for Britain

2006-10-17T09:16:00Z

An interesting article dropped into my newsreader this morning. The National Trust are organising what they hope to be “Britain’s biggest blog” by encouraging people to blog about a normal day living in Britain. The blog entries will then be archived and stored in the British Library amongst other places.

As a relatively new blogger (this blog is my fourth attempt at getting a blog going and has been up and running since May this year), I’ve tried to avoid blogging about the mundane day-to-day aspects of life but I have to admit that this sounds like an intriguing idea that I’d really like to have a go at.

If you live in the UK and you’d like to take part yourself, entries can be uploaded between 17 – 31 October on the History Matters website. It doesn’t have to be more than 650 words long. I’ll be picking a day in the coming fortnight to give it a go (hopefully an interesting day!) and I’ll post my entry up on here too.

Go on, blog for Britain!

Introduction to ActiveSpec

2006-09-28T11:39:00Z

As I mentioned in a previous article, during my downtime last week I have been working on a Ruby library called ActiveSpec. Other than a quiet announcement on the Rails mailing list (and an accidental one on the Rails core list) little has been said about it, until now.

Specifications

Not to be confused with the kind of specifications we talk about when using the RSpec BDD framework, the Specification design and analysis pattern can form a part of your core domain model. The easiest way of describing a specification is a collection of rules. Objects can be evaluated against the rules of a specification and should all of those rules be met, the specification is satisfied. The Specification pattern can be used to decouple those rules from your core domain objects. This can be especially useful when the evaluation of a series of business rules depends on several domain objects at one time.

The Specification pattern borrows from logic-programming and the concept of predicates – a specification object is a an object that essentially evaluates to a boolean. Different specification objects can then be combined to create more complex specifications (a composite). Domain Driven Design, by Eric Evans, concisely summarizes this as follows:

“Create explicit predicate-like VALUE OBJECTS for specialised purposes. A SPECIFICATION IS A PREDICATE that determines if an object does or does not satisfy some criteria.”

There are three main uses of the Specification pattern:

Validation
Selection
Creation (build-to-order)

The simplest of these is validation and that is what the initial release of ActiveSpec focuses on.

What is ActiveSpec?

ActiveSpec is a Ruby implementation of the Specification pattern. At the lowest level, it provides a series of generic Specifications that will be familiar to anybody who has used Rails validation macros. It also provides a way of creating composite specifications in a more declarative manager and on top of that, a simple DSL that can be used for easily defining specifications. Finally, it makes it easy to declaratively link your own classes to specifications depending on context.

Where would you use it?

As I mentioned before, one of the main uses of the Specification is for validation. More specifically, it can be used for evaluating objects, or a combination of objects against a series of complex business rules. Validation was the initial motivation for creating ActiveSpec and it was designed as an accompaniment – not a replacement – for ActiveRecord’s built-in validation macros. Furthermore, ActiveSpec is not limited to use with ActiveRecord or indeed, Rails. It can be used with any Ruby object.

ActiveRecord’s validation macros make it easy to declaratively add data validation to your model objects. A lot of the time these are enough and for basic validation (such as size constraints) they work well. On a recent project, with a particularly complex domain model, there was the need to validate objects in different ways, depending on its state and relationship with other objects. We found there was a lot of pushback as we tried to bend ActiveRecord validations to apply the complex business rules needed. We managed it, but the resulting code wasn’t pretty and certainly not the elegant, clear code you would come to expect from a Ruby or Rails application. In retrospect, the Specification pattern would have been an ideal solution.

Getting started with ActiveSpec

Before we can do anything, we need to install ActiveSpec. This can be done easily using RubyGems.

$ gem install activespec

We’ll start by taking a look at the ActiveSpec::Specifications module. This module contains low-level, generic Specifications, that match a lot of the functionality provided by ActiveRecord’s validation macros. These include:

CollectionSpecification (validates_inclusion_of and validates_exclusion_of)
ConfirmationSpecification (validates_confirmation_of)
PresenceSpecification (validates_presence_of)
SizeSpecification (validates_size_of)

All specifications in ActiveSpec conform to the same, simple one-method interface, satisfied_by? In addition, all of the above Specifications can be used against multiple attributes of an object, in a similar way to the ActiveRecord validations macros. Here’s SizeSpecification in action:

user = User.new(:username => 'luke')
spec = SizeSpecification.new(6, :username)
spec.satisfied_by? user
#=> false

On the face of it, this offers nothing different to using validates_size_of :user, :is => 6 On their own, these low-level Specifications offer little, except for an alternative implementation of the built-in ActiveRecord validations. Its when you start combining them with other low-level specifications, as well as your own custom specification objects, to create more complex specifications that their power becomes more obvious.

Composite specifications

To aid in the creation of composite specifications (a collection of specifications that can be treated as an individual specification due to a matching interface), ActiveSpec provides a CompositeSpecification class:

spec = CompositeSpecification.new
spec.add_specification(SizeSpecification.new(6, :username))
spec.add_specification(CollectionSpecification.new(18..30, :age))
spec.add_specification(ConfirmationSpecification.new(:password))
spec.satisfied_by?(User.new)
#=> false

Of course, because a CompositeSpecification and a single Specification share the same interface, there is no reason why you can’t add composite specifications to other composite specifications.

Finally, ActiveSpec provides two low-level convenience classes. The first is a decorator called NotSpecification. You can use this to reverse the result of a specification (i.e. if a specification returns true, then it will return false when wrapped in a NotSpecification decorator). One potential application of this is in the implementation of both validates_exclusion_of using the CollectionSpecification:

spec = CollectionSpecification.new(1..10, :age)
# or validates_inclusion_of :age, :in => 1..10

spec_two = NotSpecification.new(CollectionSpecification.new(1..10, :age))
# or validates_exclusion_of :age, :in => 1..10

The second convenience is a simple adapter that can be used to wrap around Proc objects to make them conform to the specification interface. This makes it possible to use Procs as ad-hoc specifications:

spec = ProcSpecification.new(proc{ |object|
	# do something with object
	# and return true or false
})
spec.satisfied_by? some_object

Taking things further with ActiveSpec::Base

So far we’ve demonstrated some of the built-in ActiveSpec generic specifications can be used in place of ActiveRecord validations and how they can be combined to create more complicated specifications. Whilst this forms the core of ActiveSpec’s functionality, using these low-level specifications directly isn’t very elegant. ActiveSpec::Base allows you to construct composite specifications in a much more declarative manner that will feel a lot more comfortable for those used to ActiveRecord validations. All you need to do is inherit from ActiveSpec::Base.

class UserSpecification < ActiveSpec::Base
	requires_presence_of :username, :password
	requires_size 6, :password
	requires_confirmation_of :password
	requires_inclusion_in 18..30, :age
end

UserSpecification.satisfied_by?(some_user)

For every built-in low-level specification, there is an equivalent must_satisfy You can also pass in a block to must_satisfy and it will automatically be converted into a ProcSpecification.

bc(ruby). class AdvancedUserSpecification < ActiveSpec::Base
must_satisfy :valid_user_specification
must_satisfy do |user|
# do something with user
end
end

Finally, the ActiveSpec::Context module defines a specification method will be made available in the global namespace. Using it couldn’t be simpler:

specification :valid_user do
  requires_presence_of :username, :password
  requires_confirmation_of :password
  must_satisfy :another_specification
end

ValidUserSpecification.satisfied_by?(some_user)

As you can see from the above example, all of the macros available in ActiveSpec::Base are available to the DSL. The DSL will automatically create a specification class that inherits from ActiveSpec::Base which can then be used in the same way as your other specifications.

Using the Satisfies mixin for easy integration

The final piece of the ActiveSpec puzzle is the ActiveSpec::Satisfies mixin which makes it possible to attach specifications directly to a class. Whilst this increases coupling, there are times when you always want a class to pass one or more specifications and manually passing objects into specification objects can get quite tedious. The ActiveSpec::Satisfies mixin adds two new methods to your class – a class method called satisfies_specs? If the use isn’t obvious, allow me to demonstrate:

class User
  must_satisfy :valid_user_specification

  # optional :if argument takes a symbol or a block
  # and can be used for conditional evaluation of
  # specifications
  must_satisfy :activated_user_specification, :if => :activated?
end

user = User.new
user.satisfies_specs?
# evaluates ValidUserSpecification
user.activated = true
user.satisfies_specs?
# evaluates both specifications

If you want to use this functionality in your Rails models, add this to your environment.rb file:

require 'active_spec'
ActiveRecord::Base.send(:include, ActiveSpec::Satisfies)

There are plans to make ActiveRecord integration easier in the future with the use of a Rails plugin.

Give it a try!

ActiveSpec is still in its early stages – its only at version 0.1. The next release will focus on improvements to the existing code and tackling the second use of specifications for selection. Work on this is still in its early stages, but here is a small teaser:

# pure ruby selection
User.find_by_specification(SomeAdvancedUserSpecification)

# specifications for SQL queries?
User.find(:all, :conditions => SomeAdvancedUserSpecification.to_sql)

If you have some cool ideas for ActiveSpec, or feedback on any of the above, please let me know.

Further information

RailsConf Europe 2006: In Review

2006-09-27T16:45:00Z

RailsConf Europe was really great for the most part. There were some awesome keynote talks (sorry, “plenary”) with particular highlights being Dave Thomas’ excellent closing talk (which fully deserved the standing-ovation it deserved. Kathy Sierra also gave an awesome talk on creating passionate users. Both were the most confident and professional speakers of the two days but there were many other great talks as well, especially on the Thursday.

A personal highlight was seeing how popular Dan’s UJS talk was. I’ve already spoke about the talk but I must restate how cool it was to see the main hall fill out during Friday lunchtime after Dan was asked to repeat his talk due to so many people being disappointed on the Thursday morning. Speaking of UJS, we hope to have 0.4 out soon but a combination of my lack of net access last week and the both of us being really busy means that it might be a few more weeks yet. We have fixed a good few bugs however so we might push a point release in the meantime; I haven’t decided yet.

Gavin Bell and Tom Armitage (who I’d seen give an excellent talk at LRUG) gave an interesting talk on polymorphism as a pattern in social software. I felt that perhaps their overall point got lost a little but it was interesting nonetheless. It was cool to see testing with Javascript getting a good airing by Thomas Fuchs (see my live notes on his talk) and Marcel Molina Jr. showed some useful tips and tricks for sharing and reusing RJS code. An unexpected highlight of Marcel’s talk came towards the end when DHH and Piers Cawley got into a small disagreement over the separation of concerns between models and views – for the record I think DHH was spot on and I was somewhat confused at Piers’ ranting. It was entertaining though.

Apart from DHH’s opening address, which I’ll come to shortly, the other talk that sticks in mind was Jim Weirich’s talk. He gave a great overview on “playing safe with others” and how to write good Ruby code without unintended side-effects. I’m too lazy to write up my notes, but you can click on the image above for a larger view of my Moleskine scribblings – sorry about the dodgy handwriting!

David Heinemeier Hansson gave a great talk to kick the conference off, which was mostly about code (with all of his slides in Textmate as he didn’t have Keynote on his laptop…cool!) and I have to say that I’m finally convinced about ActiveResource and REST. Simply Helpful looked really neat as well. The one part of David’s talk that I didn’t get to see was the part he had to postpone until the core team chat later in the day (I was already on the way home for an early night by that point). I didn’t see it, but its hard not to know all about it. I’m sure you’ve all seen the photo. So what was my reaction? To be honest, disappointment.

I know David likes to make controversial statements in this way (we all remember “Fuck You”). He’s one strongly opinionated guy and in many ways it can be a positive quality (one that comes across heavily in Rails). And in some ways I agree with him – just because you download a piece of open source software it doesn’t mean you are entitled to anything. You aren’t entitled to support, developers aren’t obliged to listen to your feature requests and ideas and they certainly don’t have to listen to (or deserve) unconstructive criticism and bitching. However well you thought the recent Rails security hole was handled there was no call for some of the petty bitching, moaning and whining that some people felt the need to do. Constructive criticism is fine and should be encouraged but whining helps nobody.

What I don’t agree with is David’s black and white attitude towards people. I don’t like the notion of “if you haven’t contributed back to the community then I don’t care what you have to say”. Just because somebody might be new to the community or hasn’t had the time to contribute much to the community be it in the form of patches, plugins, or help on the mailing list it shouldn’t meant that they should just be ignored by default. David may well have no legal responsibility towards anybody who downloads and uses Rails – a point he has been quite clear about. But in my most humblest of opinions, when you put out a piece of open source software like Rails, promote its use and see it grow into what it has become today, with many developers and companies livelihoods depending on Rails you carry a certain degree of moral responsibility to those developers. Giving a big “fuck you” to people just because they haven’t yet made some kind of contribution back to the community is short-sighted and somewhat immature and I was disappointed not so much by the point David had to make, but the way in which he made it and had I been around for the core panel talk I’m sure I would have left with a somewhat bitter taste in the mouth.

After that last sentence it would be somewhat ironic for me to end my RailsConf thoughts on that note so let me get back to being positive. The conference was well organised (except for those shitty passes) and most of the talks were interesting. Above all else, I had a great two days and got to meet some great people. Damien, Max, Robby, David, Jarkko, James, all the guys at Aegis Media and everybody else I met over those two crazy days. It was great to meet you guys and share some beers! Here’s to RailsConf Europe 2007 – see you in Berlin!

Give me my Internet back!

2006-09-27T16:30:00Z

Just in case you’ve been wondering where I’ve been…allow me to explain. Warning: ranting ahead!

Last week mostly sucked, no thanks to the two companies above. Last month Sky announced that they were launching a new ADSL service called Sky Broadband. They were offering up to 16Mb with no caps for only Â£10 per month for Sky TV subscribers. My previous ISP, Zen Internet were good with decent support, but they were not cheap: Â£25 per month for up to 8Mb (I never got more than 3Mb) and a 20GB cap is not what I call good value for money. How could I not jump at the offer?

It turns out that it was the worst decision I’ve made in a while. Through a combination of Sky’s complete and utter incompetence and lack of communication and what I can only assume is laziness and more incompetence on BT’s part, I have been without broadband net access at home since September 15th, which is when my Zen connection was cancelled. To make matters worse, we just moved offices here at Agile Evolved and we didn’t get broadband installed until September 21st – nearly a week without any net access! My Sky connection should have been activated on the 11th but it wasn’t. With RailsConf coming up I decided to wait until the following Monday to chase things up, and so began a week of constantly calling Sky (with up to half hour hold times) trying to find out what on earth was going on, only to be told that “there was a delay at BT’s end”. You see, because Sky is a LLU (local loop unbundled) service, BT, who run the phone exchange have to physically connect you to Sky’s hardware. It never happened. At one point I was told there would be up to a 30 day delay. That’s just not acceptable.

Sky must have known that demand would be massive so I don’t buy any excuses of “underestimating the demand”. Nor do I buy the complete passing of the buck to BT – Sky have to take responsibility too as they are the ones selling the services whilst BT struggle to cope.

Things can’t get any worse you might assume, but after cancelling my order yesterday, I rang up to confirm with Sky that it had been cancelled. I was told that it has and that the cancellation had been sent through to BT. Unfortunately the order has left what is known as a “marker” on my line which prevents me from ordering broadband from anybody else until it is removed. I rang up BT’s wholesale division to have it removed and even though the lady was very helpful she told me that it my line was showing up as having an “incompatible product” and that it could take up to two weeks to have the marker removed. She promised to put it through as urgent and said that it could be done by next Monday, even tomorrow but the possibility remains that I will be without net access at home for another two weeks.

The bottom line…if you are in the UK and were thinking about getting Sky Broadband – don’t bother. At least, not for now. Wait until things are settled down a bit – I might be willing to give them another chance in 3 to 6 months but I seriously advice people to give them a miss for now unless you have some kind of backup, like a cable broadband connection that you can leave active until your Sky Broadband connection is up and running. If only I could get cable where I live, as I used Telewest cable when I lived in Wolverhampton and I never had a problem.

And breathe…

If there was one good thing that came out of my downtime last week it was that I was able to spend some time developing my Ruby Specifications library, ActiveSpec. More on that soon…

UJS @ RailsConf Europe 2006

2006-09-15T13:35:00Z

Update 15 Feb 2009: The UJS plugin for Rails is no longer actively maintained but you can find the the source on github.

There has been a tremendous amount of interest at RailsConf Europe in the UJS Rails Plugin. Dan gave his talk on Thursday morning and it was a struggle to get in; it was completely oversubscribed (I had to use the old ‘but I’m the co-author!’ line just to get in). It was great to see the interest it had generated. The talk proved so popular that a second presentation was scheduled on the Friday in the main congress hall which again proved really popular; we managed to fill up most of the room despite it being lunch – not a bad achievement.

Dan gave a great presentation that went into the full details of the whys and wheres of unobtrusive scripting before giving a run down of the core UJS features, wrapping up with a small case study: building an AJAX-powered shopping cart using UJS. He showed how to build the shopping cart so it works in a traditional manner without JavaScript and then he used UJS to layer the additional behaviour on top of that.

Some people brought up some interesting questions at the end of the talk, some of which I’d like to address.

One person asked if there were any major drawbacks to working this way. In general, I think you’ll find that once you have got into the right mindset, you will find yourself always thinking about how things will work with and without JavaScript. Its important to stress that it is a mindset change, as Dan pointed out in his presentation. It took some time to convince people of the advantages of CSS-powered layouts and I have a feeling that it might take some time with unobtrusive scripting but I think we’ll get there eventually.

Somebody questioned whether or not this approach will work when you trying to create a web-based application that mimcs a desktop application; he cited something like Google Spreadsheets or Google Maps. I think in situations like this it could be difficult to use UJS, simply because creating a fallback would be difficult. You’d also have to question the usefulness of an application like a spreadsheet that didn’t work without JavaScript – how usable would it be? Campfire is another example of where the AJAX functionality is integral to the way in which it works.

Google Maps on the other hand could easily be made unobtrusive. Think about it: how did web-based mapping apps work before AJAX came along? They presented a static map with arrows on each side for moving across the map. It is slow, but it works. There is no reason why Google Maps can’t fall back on this behaviour in the absence of JavaScript.

On a related note, it was great to hear from the guys at Odeo and that they really liked the UJS plugin. They mentioned that most of Odeo is unobtrusive and they had to roll a lot of their own JavaScript helpers and raw JavaScript to achieve this. If Odeo start using UJS, that would just be awesome.

There was one other concern relating to the use of links for GET requests only (with no side-effects) and buttons for everything else (POST, PUT and DELETE in REST terms). The concern revolved around the ability to style buttons. Styling buttons can be tricky in some browsers (such as Camino) but this is easily worked around with a bit of clever CSS or use of an image button.

One thing Dan didn’t mention in his presentation, which is worth pointing out, is that the UJS plugin upgrades the built-in Rails helpers (link_to_remote are given the appropriate values.

However, I still want to stress that if you can use the link_to_remote can make things a bit funky:

<% @products.each do |p| %>
  <p><%= link_to_remote product.description, :controller => 'products', 
                                                :action => 'description', 
                                                :id => p.id %></p>
<% end %>

The above will work, but very slowly. That’s one behaviour rule for every div

<div id="products">
<% @products.each do |p| %>
  <p><%= link_to product.description,
           :controller => 'products',
           :action => 'description', 
           :id => p.id %></p>
<% end %>
</div>

<% apply_behaviour "#products a", make_remote_link %>

One behaviour for any number of products.

If you haven’t tried UJS yet, do give it a go. www.ujs4rails.com is the official website, and it contains documentation, tips, tricks, a quick start guide and things such as rdocs and a Trac for filing tickets.

If you like to live on the edge, feel free to try running on the trunk – we have some cool new ideas on the way for 0.4 and 0.5, including custom assertions for Test::Unit for asserting behaviour (and some extensions for RSpec too!) and a cool in-browser debugger that will let you do things such as view elements with behaviour applied and what behaviours are applied to those elements. Combined with FireBug and Thomas Fuchs’ unittest.js library (see my article on his RailsConf talk), that should make a pretty awesome testing environment for your AJAX apps.

Have fun with UJS. All feedback is welcome, especially if you have some ideas that you think would make UJS even cooler.

RailsConf: Adventures in JavaScript testing by Thomas Fuchs

2006-09-14T15:58:00Z

I’m currently sitting in the main congress hall awaiting the start of Thomas Fuch’s presentation. As I’m sure many readers of my blog are aware, I’m a huge advocate of testing, or to be specific, good testing. However, one thing that I’ve never managed to get into is unit testing with JavaScript. I’ve never really been aware of the tools available or how well it works.

I’m going to write this post live; hopefully it won’t just come across as a mish-mash of incoherent ramblings.

Traditional JavaScript “testing” generally revolves around alert. it can be useful sometimes but it generally doesn’t offer anything interesting. Use it sparingly.

There are many common misconceptions or attitudes towards JavaScript: “we don’t need tests for 10 lines of code”; “but you can’t debug JavaScript”. Wrong and wrong again. Enter unit testing for JavaScript.

Some options exist already, such as jsunit. These have their problems, such as awkward syntax or problems with Prototype.

Scriptaculous has its own unittest.js library. All you need to do is include the unittest.js file and an empty div with a “testlog” HTML ID (defaults). Now you’re ready to roll with Test.Unit.Runner.

Test.Unit.Runner looks quite similar to the standard xUnit family of testing libraries. It has the standard setup and teardown methods and a suite of assertions.

It has some good testing functionality for dealing with effects, and time-sensitive behaviour (wait function).

It has a basic benchmarking system too!

Rake integration is provided through a the javascript_test plugin – it allows you to launch browsers and run your javascript unit tests through a single command: rake test:javascripts. It uses a WEBrick server and supports multiple browsers, including Camino, Firefox, Safari and Internet Explorer. It’s fairly trivial to add support for other browsers too. It seems to be missing the functionality to close the browser after the rake test run. Perhaps the browser definition classes could be extended to support a “close” method that is called after the test run?

The plugin also provides a generator for generating test stub files (HTML format) in test/javascript.

Did I mention the browser-based test runner looks pretty sweet?

OK, here’s the killer feature so far: RSpec-style syntax, including should* style expectations and context/spec format. I’m convinced, sign me up!

Some other hints and tips: If you aren’t using Firebug already, then start using it! It is awesome and makes debugging AJAX and general JavaScript problems a lot easier. (as an aside, its also great for debugging your behaviours when you are using UJS). There is also a tool for Safari called Drosera.

Don’t forget your RJS templates either. RJS has some basic debugging support built-in (although this could really do with being expanded upon).

During the question and answer session, Simon Willison mentioned a tool that was part of the Dojo Toolkit that uses a command-line JavaScript interpreter to run its unit tests. It sounds interesting although I feel its a lot more useful to run the tests in the actual environment they are going to run in (i.e. the browsers). By introducing something like a separate interpreter that end-users aren’t going to be using, you are relying on that interpreter being correct.

All in all, it was a good talk and has really got me interested in unit testing with JavaScript. It’s definately something I should be doing, especially as I am so strict about testing with the rest of my code.

Finally, a word of warning for those who want to try a bit of live blogging: IRC is evil and distracting. Use with caution!

Links and useful information:

Scriptaculous
#prototype IRC on Freenode.
Rails Spinoffs Google Group

New business cards

2006-09-08T12:15:00Z

Check out our new Agile Evolved business cards which arrived today, just in time for RailsConf.

They look really cool. They were printed by Aubergine Print. Our new logo was designed by Tokyo Cube. Mine haven’t arrived yet, but when they do I’ll update the above photo with something a bit more high-quality (theres only so much you can do in Photoshop to improve a camera phone picture).

There will hopefully be many of these being handed out at next week’s European RailsConf.

Decorator Pattern with Ruby in 8 lines

2006-09-06T19:30:00Z

The Decorator Pattern is a design pattern that enables you to dynamically wrap behaviour around an existing object at runtime. It is especially useful when an object can have many variables that can be combined in different ways, which in turn affect it’s behaviour.

This small, simple implementation of the decorator pattern in Ruby sums up what I love about the hottest dynamic language on the planet.

I’ll borrow a simple example from the excellent Head First Design Patterns book by Eric Freeman, Elisabeth Freeman, Kathy Sierra, and Bert Bates.

Let’s say you want to calculate the cost of a cup of coffee. You have Coffee class, which implements a cost() method. For the purposes of this example, let’s just hardcode a value:

class Coffee
  def cost
    2
  end
end

Great. But what if we want the cost of a coffee with milk? We could have a new class:

class WhiteCoffee
  def cost
    2.4
  end
end

OK. But now we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee. It just isn’t going to work. Enter the decorator pattern. Here’s the the 8 lines of Ruby mentioned in this entry’s title:

module Decorator
  def initialize(decorated)
    @decorated = decorated
  end

  def method_missing(method, *args)
    args.empty? ? @decorated.send(method) : @decorated.send(method, args)
  end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
  include Decorator

  def cost
    @decorated.cost + 0.4
  end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
  include Decorator

  def cost 
    @decorated.cost + 0.2
  end
end

class Sprinkles
  include Decorator

  def cost
    @decorated.cost + 0.3
  end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

Of course, there’s nothing stopping us from making life easier with a few factory methods:

class CoffeeFactory
  def self.latte
    SteamedMilk.new(Espresso.new)
  end
  
  def self.cappuccino
    Sprinkles.new(Cream.new(Milk.new(Coffee.new)))
  end
end

order = Order.new
order.add(Coffee.new)
order.add(CoffeeFactory.cappuccino)
puts order.total

Due to Ruby’s highly dynamic nature, the Decorator pattern isn’t the only way of extending class functionality at runtime, however I just love how simple it is to implement the pattern in Ruby. For more information on implementing decorators in Ruby, including generic decorators and alternatives to the traditional decorator pattern, see the DecoratorPattern page at the RubyGarden.

Finally, it would be nice to maintain some kind of identity when using decorators. The RubyGarden page above has one approach. Whilst we aren’t using inheritance, it would be nice to retain one of its features:

CoffeeFactory.cappucino.kind_of? Coffee
#=> true

I can think of a few ways of extending my Decorator class to retain this functionality, but I’m gonna leave this one to the reader. Over to you.

Update: In typical Ruby-fashion, my 8 lines of code has been beaten by, well, zero lines of code by Trevor Squires. Using modules, super and extend, Trevor came up with this alternative solution, which maintains identity as well. Bow down to his Ruby-fu.

Update 2: Never one to step back from a challenge, I see Trevor’s Ruby-fu and raise him with a bit of my own. I still feel my decorator implementation carries some weight, with a nice bit of syntatic sugar:

class Milk
  include Decorator
end

class Whip
  include Decorator
end

class Sprinkles
  include Decorator
end

# normal coffee
Coffee.new

# coffee with milk, whip and sprinkles
Coffee.with :milk, :whip, :sprinkles

The self.with method could do with being extracted into a Decoratable module but here’s a concrete implementation. Trevor’s method still has an advantage in that it maintains object identity, but I have some ideas to solve that. But alas, it is past 1am and bed beckons.

Update 3: Trevor fights back with his own self.with() implementation. Personally I prefer the extend implementation, it eliminates the symbol to class trickery, and still maintains identity. His ’fu is still strong.

However, there is one downside to Trevor’s method: you can only apply a decorator to an object using extend once. But what if you wanted double sprinkles?

Sprinkles.new(Sprinkles.new(Coffee.new))

# or with a bit of sugar (no pun intended)
Coffee.with :sprinkles, :sprinkles
</code></pre>

The first rule of Barcamp...

2006-09-02T14:55:00Z

Ongoing updates live (or when I get round to it) from Barcamp London. I’ll be posting notes on the presentations I attend as the weekend goes on.

4pm: Above is my current view as I sit in the reception of Yahoo’s swanky West End offices, trying to polish off the second part of my BDD/Rails tutorial, whilst panicking about my UJS presentation tomorrow (AKA my first ever presentation).

After arriving fashionably late (ok, 4 hours late) I dropped into Jonathan’s Comet talk, which was followed up by a talk on the Low Pro extension to the Prototype Javascript library by Dan Web.

Jonathan’s talk on Comet gave me some ideas about a forthcoming project we’re gonna be working on here at Agile Evolved. There do seem to be a few implementation issues to resolve first however.

Surprisingly, Dan’s Low Pro talk was a revelation to me. I say surprsing, because you think I’d know all about Low Pro, what with it being the core behind the UJS For Rails plugin however I was only really aware of its improved event handling capabilities. Even cooler was its improved DOM support and the real killer for me, Behaviour classes. Behaviour classes let you build self-contained classes that contain behaviour for a collection of events, which can then be applied to elements in one goal. Dan is going to be blogging about this in full, but here is a small snippet:

var Sortable = Behaviour.create({
  initialize : function() { },
  onclick: function() { },
  onmouseup: function() { }
});

Event.addBehaviour("#todolist li", Sortable);

How awesome is that? It would be a great to see a re-implementation of script.aculo.us behaviours using Behaviour classes. Its also a great way of building and packaing up your own unique behaviours.

6:14pm: Award for most bizarre use of the English language goes to Simon Willison.

“I’m still upset on a theoretical level.”

Sunday, 3pm: OK, here’s some advice. If you are going to do a presentation, don’t leave it until the last minute to put together. I managed to get my slides finished by about half past 1 and was on the train into central London by 2. In the end my presentation seemed to go ok, though I’m still not a fan of public speaking.

Despite arriving so late, I did manage to couple catch a couple of interesting talks. Nick Fitzsimons gave an interesting talk on the correct use of HTTP, which extended nicely from a talk on Saturday regarding REST and Rails (and whether or not to use it). We generally agreed that in an ideal world, content negotiation and a single URL for a resource (with the accept header determining how you want that resource to be presented) is a good thing. However, there were concerns voiced about misconfigured proxy servers that could end up munging with accept headers which would result in some very strange behaviour.

People were more positive about using HTTP verbs to perform different actions on a resource. The issue surrounding proxy servers (which may not allow certain verbs) remained but it was less severe as a proxy server that did not support a particular verb would simply fail, rather than appear to work but actually do something strange.

Thanks to those who did attend my talk on Unobtrusive Javascript with Ruby on Rails. If you weren’t able to attend Barcamp, you can download the slides.

All in all it was a good weekend. It was good to meet some interesting and friendly people. If you haven’t attended a Barcamp before, I suggest you keep an eye out for one in your area, as they are great fun.

Developing a Rails model using BDD and RSpec, Part 1

2006-08-29T13:15:00Z

Writing Rails testing articles seems to be quite popular at the moment; seeing as I’m often quite vocal about testing on the #caboose and #rubyonrails IRC rooms I felt it was about time I posted one of my own. I have a large series of articles on testing with Rails in the pipeline, but until that is done, here is a nice and simple tutorial for newcomers to BDD and RSpec – the first in a two-part article exploring the development of a typical Rails model, using BDD techniques and the RSpec framework. If you are interested in BDD and RSpec, or new to testing in general and want to learn how to iteratively develop a model test/spec-first, this is the article for you.

Anatomy of a typical Rails-style test

Will Rails developers please raise their hands: how many times have you written a test that looks like this:

class UserTest < Test::Unit::TestCase
  def test_create
    user = User.create(:some => 'params')
    assert user.save
  end
end

Now ask yourself how many times have you sat back and asked yourself why you are writing the above test?

If the concept of unit testing is new to you, then writing tests at all is a great first step. But its also important to have useful tests. Are your tests valuable? Are your tests acceptable?

Avoid meaningless tests

The above test is a good example of a meaningless test. Why is it meaningless? Because you aren’t testing your own code; you are testing the ActiveRecord library, which is pretty well tested already. Let’s take a look at a default Rails model:

class User < ActiveRecord::Base
end

Just those two lines of code give us a whole load of functionality, all of which is provided by the ActiveRecord library. Its fair to assume that the functionality given by those two lines of code will work. If it doesn’t then there is either something wrong with your local setup or something fundamentally wrong with ActiveRecord; in either case, your own tests are the last of your problems.

Test your own code

So if we can safely assume that the built-in ActiveRecord functionality works as advertised, what should you be testing? The simple answer: test any code that you write. Anything that gets added to your model needs test coverage. The aim of this tutorial is to place an emphasis on testing the behaviour of your code in different situations (or contexts). This is the basis of Behaviour Driven Development, the methodology that I will use in this tutorial to iteratively develop a Rails model, ~~test-first~~ spec-first.

For this tutorial, I will be using the excellent RSpec framework, but you could easily apply these principles to TDD using Test::Unit. Before we get started, you’ll need to install RSpec and the RSpec On Rails plugin for your current app:

~/mygreatapp/ $ sudo gem install rspec
~/mygreatapp/ $ ./script/plugin install svn://rubyforge.org/var/svn/rspec/tags/REL_X_Y_Z/vendor/rspec_on_rails/vendor/plugins/rspec
~/mygreatapp/ $ ./script/generate rspec

Replace X, Y and Z in the above with the version of RSpec that you are using. If you have any problems, refer to the full instructions.

Going into RSpec in full detail is outside of the scope of this article, but it should be pretty clear what is going on – this is one of RSpec’s strengths. If you would like to read a more generic RSpec tutorial, the RSpec website has a great tutorial to get you started.

The problem

We’re in the process of writing our fantastic new Web 2.0 application, and we’ve decided that we need people to be able to create accounts and log in to the application. We don’t want to use any of the available Rails authentication plugins; we want to develop our own User model. After a quick whiteboard/CRC session, we come up with a few basic specs for our User model:

A user should have a username that they can log in with
A user should have a password between 6 and 12 characters in length
A user’s password should always be encrypted in the database
A user should have an email address
A user can optionally have a first name, surname and profile/description

With this in mind, we fire up our favourite text editor and start work on a new Specification. We use the generator that comes with RSpec on Rails to generate a new model, with an accompanying spec file.

$ ./script/generate rspec_model User

This will create a new user.rb file for our model, just like the normal Rails script/generate model command, but it will also create an accompanying spec file in the spec/ directory. If you open up the created user_spec.rb file, you will see a stub context ready and waiting.

Behaviour Driven Development favours the breaking up of specifications into individual “contexts”. A context is an object (or collection of objects, but generally object being specced) in a certain state. As we are going to start our specs from scratch, you can safely remove the stub context in the user_spec.rb file (don’t remove the require line at the top though!).

So what is a good starting point? I tend to favour a more generic starting context: “A user”. We can use this to specify the behaviour of a user in general.

Specifying your model in code

Let start with our first specification: a user should have a username that they can log in with. Its fair to assume that the username is required (otherwise they won’t be able to log in). So what could we specify? How about this:

context "A user (in general)" do
  setup do
    @user = User.new
  end

  specify "must have a username" do

  end
end

That’s not bad, but it could be better. We’ve expressed a requirement in our code but we haven’t said anything about the behaviour of a User object. What about this instead:

context "A user (in general)" do
  setup do
    @user = User.new
  end

  specify "should be invalid without a username" do

  end
end

That’s better. Not only have we expressed that our user must have a username, but we’ve also expressed what behaviour should be expected from the User model if it doesn’t have one; it should be invalid. Let’s fill this spec in, so we have a failing spec:

context "A user (in general)" do
  setup do
    @user = User.new
  end

  specify "should be invalid without a username" do
    @user.should_not_be_valid
    @user.username = 'someusername'
    @user.should_be_valid
  end
end

Now we need to make this pass. The first things we need is our actual User model, and a table in our database. BDD (and TDD) emphasise taking small steps, following the red, green, refactor mantra. However, due to our coupling to the database as a result of using the ActiveRecord pattern, we are going to have to make a slightly larger leap: our users table schema.

We need to write a migration for our users table, but at this stage we aren’t certain exactly what columns we need. We could write a migration every time we want to add a column but that would quickly become tedious. Instead, we’ll make a reasonable guess at our schema based on our written specs – if we get it wrong at this stage it doesn’t matter. Migrations make it easy to modify our schema in the future. Something like this should do the trick:

class AddUsersTable < ActiveRecord::Migration
  def self.up
    create_table :users do |t|
      t.column :first_name, :string
      t.column :last_name, :string
      t.column :email, :string
      t.column :description, :string
      t.column :username, :string
      t.column :encrypted_password, :string
      t.column :salt, :string
    end
  end

  def self.down
    drop_table :users
  end
end

You’ll note that we’ve made a few assumptions regarding our password columns. We already have an idea in mind about how we want to store the password – as a salted hash – so we’ve created columns for the encrypted password and salt. Now we’ve written and run our migration, and created our User model, its time to get the spec to pass:

class User < ActiveRecord::Base
  validates_presence_of :username
end

You’ll notice that we’ve not added a should statement for the error message itself. That is because we know Rails will happily provide us with the default “can’t be blank” message. Remember: only test the code that you write. In this case, we decide we do want a custom message, so lets add a spec and make it pass:

context "A user (in general)" do
  setup do
    @user = User.new
  end

  specify "should be invalid without a username" do
    @user.should_not_be_valid
    @user.errors.on(:username).should_equal "is required"
    @user.username = 'someusername'
    @user.should_be_valid
  end
end

class User < ActiveRecord::Base
  validates_presence_of :username, :message => 'is required'
end

We’ve also specified that our user must have an email address, so lets add a spec for that:

context "A user (in general)" do
  setup do
    @user = User.new
  end

  specify "should be invalid without a username" do
    @user.should_not_be_valid
    @user.errors.on(:username).should_equal "is required"
    @user.username = 'someusername'
    @user.should_be_valid
  end

  specify "should be invalid without an email" do
    @user.should_not_be_valid
    @user.errors.on(:email).should_equal "is required"
    @user.email = 'joe@bloggs.com'
    @user.should_be_valid
  end
end

That’s simple enough to implement:

class User < ActiveRecord::Base
  validates_presence_of :username, :message => 'is required'
  validates_presence_of :email, :message => 'is required'
end

Great, we’re on a roll. But wait a minute, both of our specs are now failing. What gives? Of course, because we’ve now added two validation requirements, we need to add an email address in the first spec to make it pass and a username in the second spec to make that one pass. Hmm, it doesn’t sound very DRY, but lets go with it for now – we want our specs to pass after all!

context "A user (in general)" do
  setup do
    @user = User.new
  end

  specify "should be invalid without a username" do
    @user.email = 'joe@bloggs.com'
    @user.should_not_be_valid
    @user.errors.on(:username).should_equal "is required"
    @user.username = 'someusername'
    @user.should_be_valid
  end

  specify "should be invalid without an email" do
    @user.username = 'joebloggs'
    @user.should_not_be_valid
    @user.errors.on(:email).should_equal "is required"
    @user.email = 'joe@bloggs.com'
    @user.should_be_valid
  end
end

Phew, that was a close one. Finally, lets add the specs for the password. We know a password is required and that it has to be between 6 and 12 characters in length. Because that is actually two specifications, we’ll write two separate specs in our code. Lets start with the required field specification, as that will look similar to our above specs:

context "A user (in general)" do
  setup do
    @user = User.new
  end

  specify "should be invalid without a username" do
    @user.email = 'joe@bloggs.com'
    @user.password = 'abcdefg'
    @user.should_not_be_valid
    @user.errors.on(:username).should_equal "is required"
    @user.username = 'someusername'
    @user.should_be_valid
  end

  specify "should be invalid without an email" do
    @user.username = 'joebloggs'
    @user.password = 'abcdefg'
    @user.should_not_be_valid
    @user.errors.on(:email).should_equal "is required"
    @user.email = 'joe@bloggs.com'
    @user.should_be_valid
  end

  specify "should be invalid without a password" do
    @user.email = 'joe@bloggs.com'
    @user.username = 'joebloggs'
    @user.should_not_be_valid
    @user.password = 'abcdefg'
    @user.should_be_valid
  end
end

Now, we don’t actually have a password column in our users table, but we need somewhere to store the cleartext password before it gets encrypted. A standard Ruby instance variable will do. Here’s the code to make it pass:

class User < ActiveRecord::Base
  attr_accessor :password

  validates_presence_of :username, :message => 'is required'
  validates_presence_of :email, :message => 'is required'
  validates_presence_of :password
end

h3. Refactoring towards cleaner, clearer specifications

Before moving on to the password length specification, lets address our duplication issue here. Its already getting tedious adding all the other required fields in each spec in order to make them pass. It is making our specs bloated, ugly and it will be a nightmare to maintain in the future if our specification changes. Let’s solve this by introducing a small helper module and a neat Hash extension:

module UserSpecHelper
  def valid_user_attributes
    { :email => 'joe@bloggs.com',
      :username => 'joebloggs',
      :password => 'abcdefg' }
  end
end

context "A user (in general)" do
  include UserSpecHelper

  setup do
    @user = User.new
  end

  specify "should be invalid without a username" do
    @user.attributes = valid_user_attributes.except(:username)
    @user.should_not_be_valid
    @user.errors.on(:username).should_equal "is required"
    @user.username = 'someusername'
    @user.should_be_valid
  end

  specify "should be invalid without an email" do
    @user.attributes = valid_user_attributes.except(:email)
    @user.should_not_be_valid
    @user.errors.on(:email).should_equal "is required"
    @user.email = 'joe@bloggs.com'
    @user.should_be_valid
  end

  specify "should be invalid without a password" do
    @user.attributes = valid_user_attributes.except(:password)
    @user.should_not_be_valid
    @user.password = 'abcdefg'
    @user.should_be_valid
  end
end

There, thats much DRYer, more expressive and easier to maintain. If our valid attributes ever change, we only need to change them in one place. However, we haven’t sacrificed readability in the name of DRY, which is very important with any tests/specs.

Finally, lets add a spec for our password length:

specify "should be invalid if password is not between 6 and 12 characters in length" do
  @user.attributes = valid_user_attributes.except(:password)
  @user.password = 'abcdefghijklm'
  @user.should_not_be_valid
  @user.password = 'abcde'
  @user.should_not_be_valid
  @user.password = 'abcdefg'
  @user.should_be_valid
end

And to make it pass:

class User < ActiveRecord::Base
  attr_accessor :password

  validates_presence_of :username, :message => 'is required'
  validates_presence_of :email, :message => 'is required'
  validates_presence_of :password
  validates_length_of :password, :in => 6..12, :allow_nil => :true
end

You’ll notice we’ve added the :allow_nil option to the length validation. This is to avoid a double validation error if we haven’t set a password – the validates_presence_of validation will already handle this and we don’t want an extra error message complaining about the length of the password as well.

There is one last refactoring that we can do at this stage. In each of our validation specs, we’ve checked that the model is invalid, then set the required value and checked that it is now valid, to ensure that the validation is working end to end. We can extract all of these checks into a single specification:

specify "should be valid with a full set of valid attributes" do
    @user.attributes = valid_user_attributes
    @user.should_be_valid
  end
</code></pre>

"Download the full specification.":http://pastie.caboo.se/10720/text

Whats next?

So far we’ve written a basic User model, with an initial schema and a validation of required attributes. We’ve covered the basics of RSpec syntax and we’ve learnt how to DRY up our specs by extracting common code into a helper module.

In the second part of this tutorial, we’ll look at password encryption and authentication. If you have any questions or feedback, do not hesitate to leave a comment; I’ll be happy to answer any queries you may have.

SoundBytes: geddit?

2006-08-21T18:16:00Z

In the style of 37Signals “SunSpots” articles – a small collection of odds and ends not big enough to warrant an entire entry to themselves – I present to you SoundBytes; little bites of information (but bytes, because we are geeks, right?) that are, as any of my Northern friends would say, sound.

Just two small little bite-sized nuggets for this edition…

Automatic stylesheet inclusion with stylesheet_include_tag

First up, stylesheet_include_tag is a small Rails helper that I wrote to help me organise my application stylesheets. I named it _include_tag to distinguish it from Rails’ own stylesheet_link_tag.

First of all, here’s the code:

def stylesheet_include_tag(*sources)
  if sources.include?(:controller)
    sources.delete(:controller)
    sources.push(controller_stylesheet_source) if stylesheet_exists(controller_stylesheet_source)
  end
  if sources.include?(:action)
    sources.delete(:action)
    sources.push(action_stylesheet_source) if stylesheet_exists(action_stylesheet_source)
  end
  if sources.include?(:defaults)
    sources.delete(:defaults)
    sources.unshift('application')
    sources.push(controller_stylesheet_source) if stylesheet_exists(controller_stylesheet_source)
    sources.push(action_stylesheet_source) if stylesheet_exists(action_stylesheet_source)
  end
  sources.collect { |source|
    path = "/stylesheets/#{source}.css"
    tag('link', { 'type' => 'text/css', 'rel' => 'stylesheet', 'href' => path})
  }.join("\n")
end

protected
  def controller_stylesheet_source
    params[:controller]
  end
  
  def action_stylesheet_source
    [ params[:controller], params[:action] ].join("_")
  end
  
  def stylesheet_path(source)
    "#{RAILS_ROOT}/public/stylesheets/#{source}.css"
  end
  
  def stylesheet_exists(source)
    File.exists?(stylesheet_path(source))
  end

So how do you use this little helper? It’s quite simple really – it takes three options:

:controller – looks for a stylesheet under /public/stylesheets called controllername.css – if it finds one, it will automatically include it.
:action – as above, except it looks for a stylesheet called controllername_actionname.css
:defaults – a combination of the two above options, plus it also looks for a stylesheet called application.css – this is the one that I usually use.

So what do you gain? Simply, the ability to break apart your stylesheets into sensible chunks (with global styles in application.css) and not having to worry about adding a link tag for every stylesheet you want to use. Simply drop in a stylesheet under /public/stylesheets using the naming conventions above and it will automatically detect it and add a link tag for you.

Just drop the above code into your ApplicationHelper (or a separate file, and include it) and that is all there is to it. This is one of the many helpers that I’ve written that I just couldn’t live without.

Comment notification for Mephisto

As you might have read, I recently moved my blog over to Mephisto from Wordpress. I’m loving Mephisto, but one of the features I miss is email notification of new comments. You could just use the RSS feed but some people, including myself, prefer email notifications. Implementing email notifications was pretty trivial – it was just a case of hooking up an observer to the Comment class. I’ve packaged up the extension as a normal Rails plugin. As I’m using trunk/tags you probably won’t have much luck installing it with script/plugin, so use svn co instead:

$ svn co http://opensource.agileevolved.com/svn/root/rails_plugins/mephisto_comment_notification/trunk \
  vendor/plugins/mephisto_comment_notification

Please report any problems with the above plugin on the Agile Evolved Open Source Trac.

UJS Rails Plugin 0.3: new name, new website

2006-08-21T13:05:00Z

Update 15 Feb 2009: The UJS plugin for Rails is no longer actively maintained but you can find the the source on github.

Dan and I are please to announce the biggest release of the Unobtrusive Javascript for Rails plugin – now simply known as UJS. This is a big release in many ways – we’ve got some important bug fixes in here, some great new helper functionality and most importantly: caching. The other big news is that the UJS plugin now has its very own website.

The website is the place to go for news, information, release announcements (although I will still announce releases on this blog) and tips and tricks – everything you need to get started with the UJS plugin.

Before you rush off to check out the new site, here is a quick overview of some of new features:

Added out-of-the box caching using HTTP ETags and advanced behaviour caching
Added new apply_behaviours functionality for applying multiple behaviours at once.
Added a series of behaviour helpers to make applying Scriptaculous effects unobtrusively easy.

There are also some bug fixes, some refactorings and significantly improved test coverage. For full details, see the announcement on the UJS website.

Finally, the other big change is that the Subversion repository has changed location, as has the place to report issues with the plugin: the plugin now has its own dedicated Trac.

The plugin repository is now located at:

http://source.ujs4rails.com

The latest version of the plugin now has its own tag, which should make it work with Rails’ built-in script/plugin script:

http://source.ujs4rails.com/current/unobtrusive_javascript

Finally, you can report issues on the UJS Rails Plugin Trac:

http://trac.ujs4rails.com

Rails plugin repository is on the way

2006-08-18T13:06:00Z

Ryan Daigle speculated on his blog that an official Rails plugin repository was in the works. He referred to an app checked into the Rails subversion repository recently.

I can announce that a Rails plugin repository is on the way, although not the one currently in the Rails repository. That particular app was a repository started by Rick Olson. The repository that is on the way is actually being worked on by myself and James Adam of Rails Engines fame.

Background and motivation

To give a bit of background to this; the idea of an official plugin repository was born out of a conversation between Rick Olson, James and Geoffrey Grosenbach at RailsConf. Work had already begun on improving the Rails plugin mechanism with RaPT, a project run by Geoffrey, James and Ben Curtis. I recently joined the RaPT team and after some discussion with the rest of the team, James and I started development on the project.

Some people may ask why an official repository is needed. Ben Curtis currently maintains a good repository of his own however it is unfair to rely on one person to keep the repository running. As more and more people use, develop and rely on plugins, the existing setup – a wiki page – is simply not scalable or maintainable. Plugins are the number one way of adding/changing Rails functionality without having to submit patches to the core – something that DHH actively encourages and something I fully support. I believe the core should be as lean as possible with additional functionality being provided by plugins.

Our original idea was to develop a plugin repository that sat somewhere between Rubyforge and the Mozilla Firefox extensions website – this included tagging, comments and ratings – the usual Web 2.0 suspects. However, after some discussion with the Rails core team we decided to drop those features in favour of making adding plugins as easy as possible and developing a way of detecting plugin health by gathering test run statistics to both encourage testing of plugins and make it clear how likely it is that a plugin will work with a particular Ruby/Rails version. The other downside to having ratings/comments etc. was the need to make users sign up for an account, something that is best avoided.

The other major feature that James and I felt was really important was the correct (and mostly automatic) handling of plugin releases and metadata. This includes reading plugin metadata from an about.yml file and handling plugin releases through either updates to the release number in the about.yml file or repository tags. One of the major failings of the current script/plugin tool is its inability to handle plugins that use the traditional trunk/tags/branches structure – something I feel is essential for anything but trivial plugins.

To sum up, the core functionality of the repository will be:

Make it easy to browse plugins and view plugin/release health/compatibility
Correctly and automatically handle plugin releases/versions and metadata
Make adding of plugins – either single plugins or entire repositories of plugins – as easy and foolproof as possible
Provide some Rake tasks to make it possible to announce new plugins/releases without having to go to the repository website
Improve the script/plugin tool and make it use the plugin repository as its main source, making it possible to install plugins by simply specifying the plugin name

Current status of the project.

James and I have made good progress on the project so far. You can view where we are up to here – do bear in mind that this is still under development and cannot be considered reliable at this point. We are aiming to move the project over to the Rails subversion repository in the next few days.

I cannot give an accurate ETA on when the project will be ready to go live, but we really want to have this up and running in time for the European RailsConf. In the meantime, have a play with what we’ve done so far and get a feel for it. If you have any suggestions please do speak up as it is the community as a whole that this is aimed at.

Update: James has also put up a post on his blog about the project.

New blogging engine and template

2006-08-18T11:35:00Z

Like many other people, I’ve moved my blog over to Mephisto by Olson and Palmer (doesn’t that sound like a 70s prog band?). I’d become very sick of Hemmingway though, even if I was using the less common white version, and with Mephisto coming with Hemmingway as its default theme its now even less unique, so it was time for a change. So I present to you…Sydney.

Why Sydney? Absolutely no reason whatsoever. It was the first thing that came into my head. The template itself wasn’t actually designed for my blog; it was designed for the new, forthcoming Unobtrusive Javascript plugin website, with a different color scheme. A bit of reworking later I now have it as a full-on blogging template for Mephisto and it supports multiple color schemes. The UJS website will be using “neopolitan”. I call this one “mintchoc”. I’m not 100% certain if I will stick with this color scheme but I’m very happy with the overall layout.

Unfortunately I will not be releasing this template for others to use…to begin with anyway. Its nice to have your own unique theme so I’d like to keep it that way for the time being. I have no doubt that I will release the template to the community in the future though.

Backwards compatibility

I’ve added a custom route to make sure all Wordpress URLs load the correct article – the only difference was the /index.php/ part of the Wordpress URL and a few of the article slugs needed tweaking. If you have any pages bookmarked, I’d recommend updating your bookmarks to the new URL. Archive pages will probably not work any more. I’m also yet to import the comments but I will do this over the coming days. Thanks to Chris McGrath for his article on converting typo URLs to mephisto URLs which was a great help in getting this running properly.

Awesome syntax highlighting

It’s also worth mentioning that code syntax highlighting is provided by Dan Webb’s awesome Javascript CodeHighlighter library, and a small Rails plugin that adds some Mephisto filters to use it. Dan hasn’t set up a permanent home for the library yet and some of the language definition files could do with a bit of fleshing out, but its very easy to extend and its very fast. Naturally, its completely unobtrusive – your code will still be displayed sans-highlighting if Javascript is disabled and there’s no more littering of your code with loads of span tags. Best of all, its completely language agnostic – use it with your Rails apps, your PHP apps, or with completely static HTML pages. Grab CodeHighlighter for your own website.

And finally…

On the subject of the UJS website, Dan and I hope to have this, along with a 0.3 release out on Monday. The new feature contains some neat new features, some bug fixes, improved test coverage and most importantly…caching. Keep an eye out on Monday for more information and the new UJS Rails Plugin website.

Unobtrusive JS 0.2.2 - "the two in one day!" release

2006-08-10T17:55:00Z

Update 15 Feb 2009: The UJS plugin for Rails is no longer actively maintained but you can find the the source on github.

I’m sure many people are aware of the risks in running pre-1.0 software/plugins and that there are likely to be many bugs discovered until that 1.0 release finally hits (and beyond).

Unfortunately, it takes really working with a Rails plugin to find problems and I have been doing so today. I encountered a strange error where the plugin was generating IDs for elements that shouldn’t have any javascript events attached.

Update 21/08/2006: The latest version of this plugin is 0.3 – please see [this post](http://www.lukeredpath.co.uk/2006/8/21/ujs-rails-plugin-0-3-new-name-new-website) and the [official UJS website](http://www.ujs4rails.com) for more information.

def tag_options(opts)
  unless opts[:inline]
    JAVASCRIPT_EVENTS.each do |event|
      if opts.include?("on#{event}") # this was the culprit!
        opts['id'] = generate_html_id unless opts['id']
        register_js_behaviour("##{opts['id']}:#{event}",
                  opts["on#{event}"]) unless opts["on#{event}"].nil?
        opts.delete("on#{event}")
      end
    end
  end
  rails_tag_options(opts)
end

What it turned out that was happening was that some Rails helpers were adding empty onclick handlers to some tags so they were being picked up by the above code. All that was required was a simple fix:

# get rid of this
# if opts.include?("on#{event}") 
# and use this:
unless opts["on#{event}"].blank?

So [grab Unobtrusive Javascript for Rails 0.2.2](http://opensource.agileevolved.com/svn/root/rails_plugins/unobtrusive_javascript/tags/rel-0.2.2/) while its hot!

Unobtrusive Javascript broken in Edge Rails, small fix release

2006-08-10T12:26:00Z

Update 15 Feb 2009: The UJS plugin for Rails is no longer actively maintained but you can find the the source on github.

We're currently using Edge Rails and the Unobtrusive Javascript for Rails plugin in the forthcoming Rails Plugin Repository and after a Subversion update today, something seems to have broken the Unobtrusive Javascript plugin.

I'm not sure what caused the breakage but the problem was a minor one; after some investigation it turned out that the unobtrusive javascript controller was not being automatically being required by Rails even though its parent folder had been added to the Rails load path. The fix was as simple as explicitly requiring the controller file and everything is now fine. ~~Release 0.2.1~~ addresses this issue and also adds an about.yml file containing plugin meta-data.

Update: Please grab Release 0.2.2 instead.

If you are running on Edge Rails you will need to upgrade to this release. The plugin (version 0.2) continues to work just fine if you are running the new Rails 1.1.5 security fix so whatever caused this breakage doesn't appear to be related to the security fix.

The RailsConf Europe HooHa

2006-08-04T10:37:00Z

David posted an entry on the RubyOnRails weblog pushing people to go to RailsConf EU and a lot of people reacted negatively to it.

The thing that most people reacted badly about was the price. Â£575 is a lot of money to spend for most people, especially freelancers and enthusiasts and the early bird price of Â£475 is still not cheap.

The more cynical would think that the real reason David wants to encourage people to come along is because the organisers can make money from it. I doubt this is the case. However there has been a surprising lack of enthusiasm and hype surrounding the conference compared to the US conference which was hyped to the roof and I suspect the number one reason for this is the cost.

That being said, there is really little excuse for much of the whining and moaning that has been going in the comments for the above post and elsewhere. Ultimately, its not about whether or not the conference is expensive (and I do think it is overpriced and yes, I am going) but whether or not you can justify the cost.

If you can justify the cost, please, get a ticket and come along - I do feel it will be a worthwhile experience. You'll get to meet some interesting and clever people, talk Ruby and Rails for two days without people looking at you funny and its a great networking opportunity.

If you can't justify the cost - fair enough. But don't go on about it - get over it; move on. The world is not going to end because you could not attend the conference. Your RubyOnRails skills are not going to suffer. I'd consider myself a good Ruby and Rails programmer and I didn't get to the level I'm at today with a full time, well-paid Rails job by going to conferences. Even if I could have afforded the flight and tickets to the US RailsConf (and I would have loved to go) there was no way I'd be able to justify that expense.

Many people mentioned that the money they could spend on the conference would be better spent on books. Thats a fair point. If you have the money available do go and buy some books, you'll definitely benefit. I strongly recommend Rails Recipes by Chad Fowler and Domain Driven Design by Eric Evans.

As I said I do believe the conference is far too expensive; but some of the bile being aimed at the organisers is ridiculous. Yes it would be nice to go but going to a conference is a privilege, not a necessity. Nobody is pointing a gun at your head and making you go. If you are in the UK, you could always try visiting a local Ruby Users Group, or starting your own if there isn't one.

Regarding the price, if the main reason that it is so expensive is because it is being held in London - one of the most expensive cities in the world (I know, I live there!) then my advice to the organisers would be: hold it somewhere else. There are much cheaper venues with great air, road and rail transport links - Birmingham springs to mind. With the wealth of cheap flights out there, I'd even be happy to fly to somewhere on the continent for the conference - it would still probably work out cheaper.

Finally, a lot of people were bitching about such and such feature not being in Rails (il8n mainly) and how Rails was making a fatal mistake by not having it in the core. If people haven't really picked up on this yet, let me re-iterate - Rails is opinionated software and I hope it stays that way. Yes there are times when I've wished for a feature but with Rails' plugin system there is no longer any excuse for bugging the core team for a particular feature - if you need it that badly, implement it as a plugin and share it with the world. There are already efforts going into internationalisation and legacy database support.

The core should only ever have the key features that are essential to the majority of people - adding minority features (even if they are important minority features) will only lead to a bloated framework which is a contradiction to everything Rails is supposed to stand for. ActionWebService is already being stripped from the core into a plugin and there are other things I'd like to see extracted from the core into plugins as well - the Prototype/Scriptaculous helpers and most importantly the most useless Rails feature of all, scaffolding - a feature that anybody with an ounce of Rails experience has a need for other than for the occasional spike/prototype.

I'm well aware that the current Rails plugin system is far from perfect - installing plugins could be made easier and its a pain to install plugins that make use of the standard Subversion trunk/tags/branches structure. But there are efforts going on to improve this. If theres one thing you can do today to improve Rails and make yourself a more experienced Rails programmer - write a plugin!

Release: Unobtrusive Javascript For Rails 0.2

2006-08-01T03:17:00Z

Update 15 Feb 2009: The UJS plugin for Rails is no longer actively maintained but you can find the the source on github.

Dan Webb and I are happy to announce the latest release of the Unobtrusive Javascript plugin for Rails. This release packs in lots of cool new features, a few changes to old ones and some performance enhancements.

Update 21/08/2006: The latest version of this plugin is 0.3 - please see this post and the official UJS website for more information.

As I mentioned in my previous article, Dan had been working on his own plugin and we've now pooled our efforts and are working on the single plugin together, with much of Dan's JavascriptProxy functionality from his own plugin now rolled into Unobtrusive Javascript for Rails 0.2.

Here's a full list of changes and additions:

UPDATED: register_js_behaviour remains as an alias for backwards compatibility but is officially deprecated; it will probably be removed in the next release. There are also aliases for the American spelling of behaviour for our friends on the other side of the pond.
NEW: You can now attach behaviours directly to elements using @tag@ by passing in javascript event handlers in the HTML options hash (:onclick, :onmousedown etc.); they'll be extracted to the external behaviours file automatically.
UPDATED: The core Rails AJAX/Javascript helpers (link_to_remote, button_to_function, link_to_function, form_remote_tag etc.) now work out of the box.
NEW: There is no need to explicitly specify an HTML ID for the elements you want to attach behaviour to - if you don't, one will be generated automatically for you.
NEW: Options to render behaviour rules directly in your page inside script blocks instead of in the external behaviour file.
FIXED: Behaviours inside AJAX-loaded partials will now work.
UPDATED: event:Selectors and domReady javascript libraries are replaced with the lowPro.js library by Dan Webb
UPDATED: Javascript behaviours now have access to a single variable - @this@
UPDATED: Behaviours can now cancel the default action by returning false as well as using Event.stop(event). This also works properly in Safari.
FIXED: The required javascript files will be copied to your public folder automatically on installation. There is also a rake task for copying files across when upgrading the plugin.
NEW: Documentation!

There is currently only one known issue:

Behaviours are not being reapplied after an AJAX request in Opera 9

Here's a look at some of the new features, starting with writing behaviours using pure Ruby:

<% apply_behaviour "#mylink:click" do |page, element|
  page.alert "You clicked me! Now watch me fade..."
  element.visual_effect :fade
end %>

Attaching behaviours directly to elements with content_tag

<%= content_tag "div", "My funky box", :onclick => "alert('Hello World!')" %>

We want you to really put this release through its paces - does it conflict with other plugins? Does it cause unexpected problems with Rails itself? Are there any other features you'd like to see? The place to report these feature requests and bugs is of course the Agile Evolved Open Source Trac.

Further Information

Installation note: some people have reported that the plugin fails because the Rails plugin installation script installs the plugin to rel-0.2 instead of unobtrusive_javascript. This is a failing of Rails' plugin installation system in that it doesn't correctly handle the typical tags/trunk/branches Suvbersion repository layout. If you install the plugin using script/plugin, make sure you rename the rel-0.2 folder to unobtrusive_javascript. If you are using svn:externals, you can edit your externals file manually:

$ svn propedit svn:externals vendor/plugins

Then add the following line to it:

unobtrusive_javascript http://opensource.agileevolved.com/svn/root/rails_plugins/unobtrusive_javascript/tags/rel-0.2

Future Plans

So what do we have planned for 0.3? More patches to Rails' more complicated built-in helpers, such as apply_behaviour how about some of this:

<% apply_behaviour "div.draggable", make_draggable %>
<% apply_behaviour "li.sortable", make_sortable %>
<% apply_behaviour "#searchbox", make_autocomplete %>

Comments open!

Rails Plugin Packs™ coming to RaPT

2006-07-28T17:00:00Z

Good news - Geoffrey has agreed to roll Rails Plugin Packs into RaPT. I've already integrated it into the RaPT source code and a patch is winging its way to Geoffrey's inbox as I write this.

For the adventurous who want to give it a try in the meantime (with all the usual caveats), you need to first check out the RaPT source:

$ svn co svn://rubyforge.org/var/svn/rapt/trunk rapt

~~Next, download the pluginpack integration patch. Change to the rapt directory you just checked the source out to and apply the patch.~~

Update: I've been added to the RaPT committers list; this patch has now been applied to the trunk. Once you've checked it out, you simply need to build and install the gem.

$ rake package
$ gem install pkg/rapt-0.1.0.gem

You'll find RaPT will now have three new commands: pack:install, pack:uninstall and pack:about. All three commands take one argument, the system path or URL to your pack file. Run rapt -h for more information.

Install your favorite rails plugins easily with Rails Plugin Packs™

2006-07-27T12:21:00Z

After a brief brainwave on the way home from work, I came up with a simple solution to the problem, which I now present to you simply as: Rails Plugin Packsâ„¢.

The concept is incredibly simple; you write your own plugin pack - nothing more than a simple specification written in YAML - and publish it somewhere, either storing it somewhere on your harddrive, on your network or hosted on your website. You then use a series of simple Rake tasks to install/uninstall these packs by simply specifying the URL/path to the pack file.

I've initially implemented this as a Rails plugin, so install it to get going:

$ ./script/plugin install http://opensource.agileevolved.com/svn/root/rails_plugin_pack

This will give you three new Rake tasks - pluginpack:install, pluginpack:uninstall and pluginpack:about. What they do should be pretty self-explanatory. They all take a pack url/path as an argument, in the form PACK=url_or_path, for example:

$ rake pluginpack:install PACK=http://www.lukeredpath.co.uk/mygreatpack.pluginpack

Currently, Subversion is required to use the plugin as it installs each plugin by doing an svn co of each plugin. I plan to expand on the ways of installing the plugins soon, including support for svn export and svn:externals.

Writing your own pluginpacks is simple - the file extension can be whatever you like although I prefer to use the standard .pluginpack suffix. The files themselves are very simple and are written in YAML. Here's an example plugin pack file (which comes bundled with the rails_plugin_pack plugin itself):

about:
  name: Example Pack
  description: An example plugin pack
  author: Luke Redpath
  email: contact@lukeredpath.co.uk
  website: http://www.lukeredpath.co.uk
plugins:
  unobtrusive_javascript: http://opensource.agileevolved.com/..[truncated]
  navigation_mappings: http://opensource.agileevolved.com/..[truncated]

All of the meta-data is optional, although if you omit a name it will result in your plugin being called "Untitled Plugin" so I recommend giving every one of your packs a name, at least.

So what possible uses could this have? I've already discussed facilitating the installation of the same group of plugins on each new project - you could have your own personal or company-wide "standard" plugin pack that you use on each new project. You could write a blog post about your favorite Rails plugins and offer a plugin pack containing each plugin discussed in your article. You could use it to group related plugins. You could even use it as a basic dependency mechanism, by offering packs of plugins that depend on each other (although this is no substitute for a proper dependency mechanism).

The only downside to this at the moment of course, is that Rails Plugin Packs is implemented as a Rails plugin itself, meaning you still need to install at least one plugin manually before you can do anything else on a new project. This isn't ideal and I'm waiting to hear back from Geoffrey Grosenbach about the possibility of submitting a patch to RaPT and rolling plugin-pack functionality into the RaPT core.

Comments are open so as usual, all feedback welcome and appreciated; please file any bugs/issues in the Agile Evolved Trac.

Update: I've made a small change to the plugin pack format so if you've already checked out the plugin you'll need to run an update. I've updated the example above and you can view the actual changes with the trac changeset viewer.

Using Ruby hashes as keyword arguments, with easy defaults

2006-07-27T10:36:00Z

Similar to many Rails helpers/methods, a lot of the methods I write often use an optional hash of options, or sometimes just a hash only, to simulate keyword arguments (often using symbols).

The only downside to doing this is you lose out on easily setting default values using Ruby's default method argument values. You might use code something similar to the following to make up for this:

def some_method(opts={})
  my_foo =  opts[:foo] || 'mydefaultfoo'
end

However, as you have more and more keyword options, setting defaults in this way gets rather tedious. Fortunately, Ruby's Hash#merge comes to our rescue (almost) - it allows you to merge the contents of one hash with another. The only problem - any duplicate keys in the hash you are merging will overwrite your original hash values - when it comes to setting default values, we want this to work the other way around; we only want values in the defaults hash to be merged if they do not exist in the original hash. Again, Ruby comes to our rescue - Hash#merge takes a block as an argument and will pass any duplicate values that crop up into the block - we can use this block to decide which value to keep.

Using the simple monkey patch to the Hash class below, you will no longer have to set each default individually:

class Hash
  def with_defaults(defaults)
    self.merge(defaults) { |key, old, new| old.nil? ? new : old } 
  end

  def with_defaults!(defaults)
    self.merge!(defaults) { |key, old, new| old.nil? ? new : old }
  end
end

Of course, sticking with Ruby naming conventions, with_defaults() will return a new hash whilst with_defaults!() will change the original hash directly. Now all you have to do is something like this:

def my_funky_method(opts={})
  opts.with_defaults! {
    :arg_one => 'foo',
    :arg_two => 'bar',
    :arg_three => 'baz'
  }
end

Update: Dan Web just informed me of another way of doing this - instead of merging your defaults into your options, simply merge your options into your defaults et voila!

def my_method(opts={})
  {:arg_one => 'foo', :arg_two => 'two'}.merge!(opts)
end

If there is one thing that is annoying about Ruby, it's that just when you think you've come up with a cool little code snippet, somebody inevitably comes up with an even easier way of doing the same thing.

That said, I do still think there is something nice about the with_defaults() method - it's slightly more intention-revealing. Weigh that up with the need to monkey-patch. Choose what works best for you.

Update 2: Josh Susser now informs me (see comments) that this functionality is built-right into Rails courtesy of ReverseMerge. I still think with_defaults sounds better but I guess that pretty much makes this post redundant!

We're hiring: Rails developers needed

2006-07-24T16:29:00Z

Things are getting busy here at Agile Evolved and we are looking for UK-based RubyOnRails developers to join our team.

We'e looking at two junior-level development positions. You donâ€™t necessarily need to have RubyOnRails experience but if you do not you will need to be a fast learner and have excellent skills in another language.

You must fulfill the following requirements:

Should be able to learn very very quickly.
Should have excellent OO knowledge (be prepared to be tested on this).
Experience with a scripting language such as either Ruby (preferred), Python, PHP 5 or similar.
You must already have the the relevant UK work permits or be an EU resident.
Good knowledge of HTML/XHTML and CSS.
Basic knowledge of Javascript (Youâ€™ll be an expert by the time we'e through with you).
You must like or at least smile when using a Mac.

In addition, we'e also looking for a full-time Web Designer. Skills for this position are:

Excellent HTML/XHTML and CSS skills.
Good design skills.
Knowledge of Photoshop and Illustrator.
Good Javascript skills.

Of course if you'e one of those few people that can code and do design as well weâ€™d love to hear from you too.

Salaries for these positions are in the Â£18k to Â£25k range. Please send your CV/Resume as a PDF (preferred), MS Word or text file to enquiries@agileevolved.com. Please also include a cover letter. No agencies please.

Testing your Rails views with Hpricot

2006-07-07T13:22:00Z

Update: This extension is now available as a Rails plugin. See below for more details.

_why released his great little Hpricot HTML parser the other day and the first thing that struck me would be that it would be a great tool for testing the output of Rails views. Rails comes with the built-in assert_tag method but I've always found it clunky and a pain in the arse to use.

By combining the Hpricot library and a few useful helper functions, you can now test the output of your Rails views in Test::Unit::TestCase easily using Hpricot's support for CSS selector searches.

First of all, install Hpricot if you don't have it already:

$ gem install hpricot --source code.whytheluckystiff.net

Next, download the Hpricot Test Extensions file and copy it to the lib folder of your Rails app.

Finally, require the file at the top of your test_helper.rb file:

# test_helper.rb
require 'hpricot_test_extension'

Alternatively, you can also install as a Rails plugin. The plugin is located in the Agile Evolved Open Source repository.

And thats it. You'll now have access to four new methods - tag, tags, element and elements. All four methods take a CSS selector as an argument. The pluralised methods return an array of search results for the CSS query, the singular methods just return the first (handy if you know you'll only have one of a particular element, say, "title"). The tag methods return the inner contents of the returned elements, whereas the element methods return the raw Hpricot::Elem objects for you to work with. Here's a few examples:

assert_equal "My Funky Website", tag('title')
assert_equal 20, tags('div.boxout').size
assert_equal 'visible', element('div#site_container').attributes['class']

Finally, there is a small extension to the Hpricot::Elem object itself which lets you assert the presence of text within an element using an alternative syntax:

assert element('body').should_contain('My Funky Website')

I plan to integrate these helpers into rSpec as well using a more rSpec-style syntax. Any comments and suggestions are welcome.

Annoying IE bug with the script.aculo.us in-place editor

2006-07-03T13:34:00Z

I came across a rather annoying bug with the script.aculo.us effects library the other day. If you use pass in a loadTextUrl parameter to make the inline editor grab the value from the server, Internet Explorer would throw up the error 'Can't move focus to the control because it's invisible not enabled or of a type that does not accept focus.'.

After digging around in the inplace-editor code, it seems that it was disabling the inplace form field while it sent off an AJAX request to the server to grab the value, then re-enabling it once it the data was returned. The problem seemed to be down to the difference in the way IE and other browsers place focus on the field once it was inserted. Safari and Firefox were both placing focus on the field before it was disabled, whilst IE was trying to focus it after it had been disabled. This is what was causing IE to barf.

The solution? Instead of simply calling the function that retrieves the remote text from the server (which does both the disabling/reenabling and AJAX request) directly, attach it to the field's onfocus event handler. This ensures that it will always get executed after the field has focus.

I've submitted a patch for this which fixes this problem which will hopefully be accepted, so if you've ever had problems with this in IE, this should help you out.

RubySlim - Ruby API for SlimServer

2006-07-03T11:15:00Z

Just a small announcement for any other Squeezebox/Soundbridge owners out there who use the SlimServer music server. I've started work on a Ruby API for it and you can view the latest source on the Agile Evolved Open Source Trac.

You can also check out the latest source code from Subversion.

Here's a small code example:

slimserver = RubySlim::SlimServer.open('localhost')
slimserver.connect('myusername', 'mypassword')
puts slimserver.version

squeezebox = slimserver.players.first
squeezebox.turn_on
squeezebox.current_playlist.play

And in the future...a full RubyOnRails, AJAX-enabled front-end to the SlimServer for browsing your music collection, creating playlists, controlling your SqueezeBox and more. I've not checked anything in on this but I've already been experimenting with creating ActiveRecord models that interact with the SlimServer database. You could do something like this (this is actual code that I have got working):

my_favorite_album = Album.find_by_title('The Number Of The Beast')
squeezebox.current_playlist.load :album => my_favorite_album.id

Finally, if you have access to the SlimServer CLI API (click on technical information on your SlimServer web interface menu) you can play with any parts of the CLI API that I'm yet to add to the Ruby API by using the raw connection and API object:

# make sure you are using the CLI port, not the web interface port
connection = RubySlim::SlimServer.raw_connection('localhost', 9090)
slimapi = RubySlim::SlimAPI.new(connection)

# invoke any api commands
slimapi.invoke("version")
slimapi.invoke("myplayerid player status")

For those interested in the concept of behaviour-driven development, the whole thing is specced using rSpec. Admittedly its not the greatest exercise in BDD because I'm simply wrapping an existing API in a Ruby API so there wasn't more than 1 context for most classes, but it was still great to use and the built-in mock objects API -- which seems very similar to FlexMock -- was very easy to get to grips with - great for mocking out those telnet connections to the SlimServer CLI.

Update: RubySlim is now hosted as a RubyForge project. The 0.1 release is available as a gem.

$ gem install rubyslim

Updating a single record attribute with ActiveRecord

2006-06-28T11:15:00Z

On a Rails project I'm working on at the moment, the Rails app had to make calls to a third-party application using web services - we would then update certain attributes on a particular model instance with data returned by the web service. The only problem was that the third-party app had to update (different) attributes on the same record. Whilst the web service would always respond in a timely fashion, there was no way of predicting when the third-party app would run its update (it could be delayed if the server the server was under heavy load).

This resulted in a race condition that could potentially result in a loss of data. Because Rails already had a loaded instance of the object in memory before the web service call was made, if the third-party app saved its changes before Rails saved the record with its own changes, the values already loaded in the Rails object would overwrite the new values written by the third-party ap

The solution seemed obvious at first - instead of doing:

obj.some_attribute = 'foo'
obj.save

We could simply do:

obj.update_attribute('some_attribute', 'foo')

But we were mistaken. Whilst the method's name would seem to imply that ONLY a single attribute would be updated, this is in fact not the case. All update_attribute() does is exactly the same thing as the first code snippet. From the Rails source:

def update_attribute(name, value)
  send(name.to_s + '=', value)
  save
end

As it turns out, there isn't a built-in way of updating just a single attribute that we could see. So we wrote our own, simple solution:

def update_single_attribute(attribute, value)
  connection.update(
    "UPDATE #{self.class.table_name} " +
    "SET #{attribute.to_s} = #{quote(value)} " +
    "WHERE #{self.class.primary_key} = #{quote(id)}",
    "#{self.class.name} Attribute Update"
  )
end

Feel free to use this in your own apps if needed - the easiest way to use is it is as a monkey patch to ActiveRecord - simply paste the following code into a file called active_record_patches.rb in your app's lib folder and require it at the bottom of your environment.rb file. Alternatively, you could patch the Rails source directly or convert this to a Rails plugin.

Update to Unobtrusive Javascript Plugin

2006-06-07T14:33:00Z

Update 15 Feb 2009: The UJS plugin for Rails is no longer actively maintained but you can find the the source on github.

Some small changes and one major bug fix have been checked into Subversion today:

The controller action that serves up event-selector.js, eliminating the need to manually copy it to your public/javascripts folder, was looking for the js file in the wrong place, stopping the whole plugin from working. If you've already discovered this, please run an update.
There is now an unobtrusive version of the link_to_remote function - this also dynamically appends a return false to the onclick event to ensure it works in Safari (see this blog post)
The rules are now assigned using an addLoadEvent function instead of window.onload - this is more of a quick fix and will be improved in the future (I plan to use Prototype's onReady extension) but in the meantime this makes sure it doesn't mess up any other onload events you might have.
The rules are re-applied automatically on completion of any AJAX request

Please post any bugs to the Agile Evolved Open Source Trac.

Introducing Unobtrusive Javascript for Rails

2006-06-06T22:23:00Z

Update 15 Feb 2009: The UJS plugin for Rails is no longer actively maintained but you can find the the source on github.

Rails makes a lot of things easier for a developer. One of those things is AJAX. The built-in Javascript and AJAX helpers, such as form_remote_tag and link_to_remote, make developing AJAX apps a breeze. But if there has every been one major bone of contention with these helpers, it's the markup they produce. Developers have been well aware of the need to separate content from presentation with CSS for a while now - less prevalent is the recognition of the benefits in separating behaviour from content.

Update 21/08/2006: The latest version of this plugin is 0.3 - please see this post and the official UJS website for more information.

I'm not going to cover the ins and outs of why you should separate behaviour from content here, but or those unfamiliar with the reasons and benefits, Peter-Paul Koch of QuirksMode published a great article in 2004 highlighting the benefits of separating behaviour from content. More recently, Dan Webb from Vivabit published an article about the problem with Rails AJAX helpers.

As Dan points out in his article, the subject has been mentioned on several occasions on the RubyOnRails mailing list but has often been shot down for a multitude of reasons ranging from "its not worth it" to "it would be too awkward". Invitations to submit patches were made but nothing came about.

So I'd like to present to you something I've been working on here at Agile Evolved - Unobtrusive Javascript for Rails. The plugin makes use of a Javascript library called event:Selectors by Justin Palmer at EncyteMedia. Similar to Ben Nolan's behaviour.js library but making full use of Prototype, it allows you to use CSS selectors to attach Javascript events to your page. This plugin allows you to make use of the event:Selectors library, but in Ruby, directly from your controller or view and have the resulting behaviour rules dynamically generated at runtime in an external javascript file. Let me demonstrate:

First of all, you'll need to grab the plugin from the Subversion repository. Please note - the plugin is in its early stages at the moment and is likely to be updated quite a bit over the coming weeks - I do not recommend using this in a production site just yet. In the meantime, if you want to have a play I recommend using svn:externals to make sure you keep your copy of the plugin up-to-date.

$ ./script/plugin install -x http://source.ujs4rails.com/current/unobtrusive_javascript

Next, you'll need to load in the Prototype javascript and the Unobtrusive Javascript scripts. Somewhere between your layout's head tags, add the following:

<%= javascript_include_tag :defaults %>
<%= unobtrusive_javascript_files %>

You can now attach events to elements in your page from either your controller or your view, using the register_js_behaviour() function. The function takes two parameters; the first is the CSS selector and event (for more details see the event:Selectors documentation) to attach your behaviour to and the second is a string of Javascript that you want to execute. Here's a small example:

<% register_js_behaviour "#my_funky_link:click", "alert('Hello World')" %&gt;

Of course, writing out large strings of javascript could become cumbersome. The first solution is use the built-in Rails helpers to generate your Javascript strings. For instance, if we want to highlight a div when we hover over it with the mouse, you could do the following:

<% register_js_behaviour "#my_funky_div:mouseover",
        visual_effect(:highlight, "my_other_div", :duration =&gt; 0.5) %>

Now, if you load up a page with one of the above calls and View Source, you might expect to see a whole load of generated Javascript. Except you won't - thats because the unobtrusive_javascript plugin makes use of a special controller and view to dynamically generate your behaviour rules at runtime, which are then linked to using a normal script tag. That means you can attach as many behaviours to your page as you like, from anywhere in your view or controller, without clogging up your rendered HTML with Javascript.

Next, there is the issue of graceful degradation. The two primary candidates for graceful degradation are the link_to_remote and form_remote_tag helpers - links and forms both have natural fallbacks - the HREF and ACTION respectively, and by using some unobtrusive Javascript we can make sure those fallbacks are used when somebody has Javascript disabled.

This initial release contains an updated version of the form_remote_tag helper - by default it does exactly the same thing as the built-in Rails helper but making it use unobtrusive Javascript is a case of one small addition to your code:

<%= form_remote_tag :url => { :action => 'foo' }, :unobtrusive => true %

Because the event:Selector library depends on an HTML ID to attach an event, your forms will need an ID but worry not - another modification to the form_remote_tag helper will mean that if you do not specify your own HTML ID, one will be automatically generated for you.

Finally, some of you may be aware that Dan Webb, who I mentioned earlier in this article, has been working on his own unobtrusive javascript plugin. I have been in touch with Dan and he preferred the simpler syntax that my plugin uses. That said, he's plugin contains some very cool stuff and we've agreed to merge the best of both of our plugins together over the coming weeks, including the ability to supply the register_\javascript_behaviour() function with a block which will let you write the Javascript functionality you want to attach using Dan's RJS-style JavascriptProxy classes.

Please do download the plugin and have a play around. You can report any bugs on the Agile Evolved Open Source Software website and any opinions and ideas are welcomed.

Unobtrusive Javascript in Rails...what if?

2006-06-06T00:22:00Z

Update 15 Feb 2009: The UJS plugin for Rails is no longer actively maintained but you can find the the source on github.

What if...you could produce accessible, unobtrusive javascript, using Rails built-in javascript/prototype helpers, with just one extra line of code in your layout, a plugin, and one small enhancement to the helpers? Something like this:

<% form_remote_tag :controller => 'foo', :action => 'bar', :unobtrusive => true %>

Which produces:

<form id="form_foo_bar" action="/foo/bar" method="post">

But which still acts as an ajax form? You would simply handle the response for ajax and non ajax requests using Rails' responds_to function.

In addition, what if you could attach javascript functionality to your page elements in a Behaviour-like fashion, but using pure Ruby, anywhere in your view, but loaded from an external Javascript file?

Sorry to tease. Stay tuned, we have something very cool to show off in the next day or two.

http://opensource.agileevolved.com

A Brief Introduction

2006-04-05T13:24:00Z

I'm not great at introductions so I'll try and keep this short and sweet. My name's Luke Redpath and I'm a developer from London, UK. I'm the Senior Software Engineer at Agile Evolved

As part of my job I get to work almost exclusively with RubyOnRails, something I will post about frequently on my blog. I'll be sharing Rails tips and opinions and we have some interesting Rails plugins under development - more about that soon.

I'm also a SitePoint mentor and you can find me posting frequently in the Ruby, PHP Application Design and General Development forums.