I couldn’t defer it any longer, so its time I held my annual C.V. update. This year, I’ve been doing more web-agency work with Head London, working on a grocery website, a classroom presentation tool and a celebrity competitions website. I also worked on the redesign of the TouchLocal website and its sister project Wefinda.

Take a look at the latest C.V. on my cv page.

Hubbub is a new deliveries service that rounds up notable local shops and provides a single shop-front for them all, allowing customers to pick from the best grub in their borough. Selected for their repute, their ethical standards and their quality, the Hubbub shops collectively offer an alternative to the homogenised offerings of the cartel supermarkets, bringing their individual flavour to their community over the web.

With a butcher, a baker, a and greengrocer in Hubbub’s first catchment area, it is feasible to get your week’s shopping on Hubbub, yet the up-market range of cakes, wines and chocolates means hosting your fancy dinner party won’t be tarnished by ‘taste the difference’ wrappers.

Currently, the site delivers only to Islington, London, with plans to expand to other London boroughs. The site is scoped entirely around these delivery zones, which determines what products and stores are displayed. One technical challenge of the site is ensuring that customers, stores, products, deliveries, refunds, orders and shopping baskets don’t drift from Islington to Fulham. (If you wish to try-out the website, try putting in the example postcode provided). Rails helps out by using nested routes to allow us to scope resources within an area, so that our URLs are always prefixed ‘in-your-area/:id’.

But this was no straightforward e-commerce shopping site. Partly down to the ambitious nature of the developers at Head London when planning the project, the site is a full-blown delivery management system that runs the entire Hubbub business, which is a genuine on-line company. The site has to be aware of what deliveries the Hubbub drivers are available to make, and track customer’s shopping baskets on the website to the delivery slots. These slots equate to hours in the day of the customer’s choosing, when they would like their goods to be delivered, and each have a capacity. So the checkout process has to be integrated with this system, to ensure that Hubbub can fulfil the orders the website is taking.

Hubbub also has a sophisticated payment mechanism, beyond the scope of most normal payment-processing use cases. Due to the nature of selling locally-sourced produce, some items may fluctuate in price from the point they are ordered to when they are delivered; items sold by weight such as meat and cheese may vary, especially when whole items are needed, such as a 1 kilogram chicken might actually vary depending on the individual bird. This plays havoc when coding a quantity, price and order total system, of which Hubbub has an elaborate variety of options for the administrators populating the database. To support this change in price, we take a nominal amount to verify the card, refund it and then process the order, which may have radically altered afterwards, some time after. Using SecureTrading and XPay, we were able to realise these special use cases, without compromising on security, and without storing sensitive credit card information. We built an open-source rails gem called breadmachine, which is capable of handing 3D-secure redirects and standard authorisations transparently.

Joining an in-progress project of this size was quite daunting. Given a use case or issue ticket, to comb through fifty model classes and determine what to change made for a steep learning curve. The complex object graph of Hubbub meant that making insular changes was difficult; sometimes a feature ran through the entire system meaning that sufficient tests for regression became an immediate need. We ditched the fixtures, which were becoming unmanageable, with NotaHat’s Machinist to mock the objects, trading the relative ease of object instantiation against an increased test suite running time.

Hubbub enters a busy and unproven, yet growing market of on-line groceries. Some have their doubts, but I think that this market has huge potential. When the quality of locally-sourced produce is considered, as well the environmental benefits, its easy to see on-line groceries go the way of the mobile applications market – initially an expensive and questionable area but eventually viable and sustainable.

I today completed a twelve-day stint working with Westfield London in collaboration with Delete London, working on Ruby on Rails development.

The very lovely digital marketing team had some ideas for quick wins to improve the user experience on the London Westfield website, including adding affiliate product data to the retailer pages, and creating an events booking system. I was brought in to help realise these ideas, and turned around two rapid solutions in the allotted time.
Affiliates
The challenge was to find a way to manage the variety of retailer and affiliate partners that Westfield deal with, in an efficient way. I developed an XML parser using REXML’s stream listener to read XML information from an arbitrary affiliate partner, and create product objects from the live stream. These objects then interface with the existing CMS system and generate XML documents ready to be picked-up in the view. Not only does this vastly improve the look of the retailer pages and raise the profile of their clients, but their click-throughs will earn affiliate fees. Win!
Events
Responding to a very tight deadline, I developed an events booking system, designed for the digital marketing team to administer events with minimal effort. The system, implemented in two days, has an administrative back-end that allows the creation of events, with multiple dates attached, composed in an AJAX-form. I used unobtrusive_date_picker to render a user-friendly date picker, as well as restful_authentication to handle the login process. In order to launch within the timeframe, we decided to build the system as a stand-alone webapp, which was supposed to be hosted on a third-party, but after an eleventh-hour issue, I ended up offering my own server as a host, and therefore have my first corporate client! However, the rendered form sits within an IFRAME to hide the URL from the customer.

Meanwhile, hundreds are signing up to Westfield’s events, and the marketing team can download their required CSV data on demand, and the form will deactivate once individual dates become full.

If you’re into fashion, you should sign-up! http://uk.westfield.com/london/offers-events/events/william-baker-booking

The first phase of the Westfield Stratford City website has gone live, designed to attract new leasing business and provide information about the huge shopping complex under construction in Stratford.

I’m pleased to see this site go live, as its easily the most complex Ruby on Rails application that I’ve ever worked on. Building on top an existing rails application is relatively uncommon, and Westfield’s international centres require several infrastructural amendments. Not least, the integration with Teamsite, Westfield’s CMS system. The existing framework already defines plugins and libraries for working with the technology, but the challenge was getting my hands dirty and figuring out what was happening from looking at code.

I was involved in all the new Ruby on Rails requirements of the site (I wasn’t responsible for the design, or any of the snazzy effects, quite a bit of which was done in flash), including some features that are still in the latter stages of testing and user acceptance. I developed new templates and views unique to the Stratford site, and created a blogging/news section that has an administrative back-end, allowing moderators to moderate comments on blog entries and publish press-releases. I also created a contact form that prospective clients can use to e-mail Westfield.

Overall the project has been an insightful experience into enterprise-level Ruby on Rails projects. I’ve learned new technologies too- including the RSpec framework. Its interesting to get a feel for the Ruby on Rails experience going into an existing, large project- rather than whipping up a scaffold and turning out webapps in a week.

Before the new features are launched, check-out the new site, including photographs of the construction and a webcam… http://uk.westfield.com/stratfordcity/

I approached the task of undertaking market research for my new music start-up company in the typical programmer way: I made a website. I wonder how many of life’s problems I would approach in this way; but having a website seems like a good start.

I wanted to canvass the opinion of friends and colleagues on the habits of their on-line music consumption, particularly pertaining to music subscriptions, which is a central idea within my business plan. I knew that I wasn’t an expert in marketing, so I wanted to design a form that would allow users to customise it as they went; so that they could add choices for others to select as they went along. I accomplished this using a standard ruby on rails website, a form, and some AJAX.
Defining my data
First of all, I wrote down a basic entity-relationship diagram on the back of an envelope of what I wanted my models to look like. I knew I was going to ask a load of questions, so I made a box to represent them. I also knew that each question would have a number of choices to select from, such as ‘Agree’ and ‘Disagree’, which is a one-to-many relationship. Next, I hoped that someone would respond to the questionnaire, by associating a subset of choices with the questions I had asked, so I made a box for ‘responses’. There were multiple choices in the questionnaire and hopefully multiple choices so I needed a many-to-many relationship.

I even threw in a user model to store a respondant’s age and location; although it was probably overkill.
Iteration #1 – Make some models
I could then ask rails to do lots of work for me using the generate scripts.
ruby script/generate model Question text:text
ruby script/generate model Choice text:string, question_id:integer
ruby script/generate model Response question_id:integer, choice_id:integer, user_id:integer
ruby script/generate model User age:string, location:string
Normally I’d start with a scaffold, but in this case I didn’t want all of the CRUD features for questions and choices available on-line. Instead, I borrowed a trick I’d learnt from hacking around on the hyperactive CMS project to ‘seed’ the database by loading in data from YML files, rather like the way fixtures work in the unit tests.

Before I started-up webbrick, I wrote down some unit tests to ensure that the relationships were working the way I expected them to, and to ensure that the basic validation on the models were working correctly.
class QuestionTest < ActiveSupport::TestCase

test “required fields” do
question = Question.new
assert_equal false, question.save
question.text = ‘hi’
assert question.save
end

test “question has choices” do
assert_equal false, questions(:one).choices.empty?
assert_equal choices(:emusic), questions(:one).choices.first
end

end
The first test makes sure I can’t save a question without the question’s text being populated. Rather than testing the rails validation framework, this gives me the peace of mind that I remembered to write the validation, and the test will tell me if I accidentally remove the validation in a future re-factor.

The second test ensures that I have my model relationships configured correctly, so that I can access a question’s choices via an attribute.

I could then go away and implement my model:
class Question < ActiveRecord::Base

validates_presence_of :text
has_many :choices, :order => ‘choice_index, text’

end
I approached the remaining models in the same way. Before I could see anything in a browser, I needed to populate the database using the YML files I mentioned before. So I wrote the following rake task to populate the database (lives in lib/tasks).
namespace :db do
desc “Load seed fixtures (from db/seed) into the current environment’s database.”
task :seed => :environment do
require ‘active_record/fixtures’
Dir.glob(RAILS_ROOT + ‘/db/seed/*.yml’).each do |file|
Fixtures.create_fixtures(‘db/seed’, File.basename(file, ‘.*’))
end
end
end
Which allowed me to structure the data of my questionnaire in the following way:

(db/seed/questions.yml)
three:
id: 3
text: ‘What music websites do you currently use?’
(db/seed/choices.yml)
emusic:
question_id: 3
text: ‘E-music’

napster:
question_id: 3
text: ‘Napster’

spotify:
question_id: 3
text: ‘Spotify’
I could then run rake db:seed and my database would be populated with the questionnaire data. I could now fire-up a browser and begin programming the view.
Iteration #2: First form
The next job was to create a form that would allow my respondents to view the questions in my database, along with the choices, and make some responses. I had a bit of plumbing to do here, without the scaffold in place, so I generated a controller, added some views and updated by routes.rb.

Once I had a view, I could create a form. I decided to treat the form as an ordered-list, so I created a partial that would supply the HTML for each question and enclosed it in a OL and LI tag:
<% form_tag ‘/respond’ do -%>

<ol>
<% @questions.each do |q| %>
<%=render :partial => ‘questionnaires/question’, :locals => { :q => q } %>
<% end %>
</ol>

<div id=”submit”>
<p>That’s all for now! Press this button to complete the survey.</p>
<%=submit_tag ‘Submit Questionnaire’%>
</div>
<% end -%>
This approach immediately posed the problem of how to read in the form data, when the view doesn’t know what questions and choices are being visualised in advance. The solution rested in the correct naming convention that allowed rails to convert the form data into a manageable collection. I wanted a collection of responses, that would each contain a collection of those selected choices a user had made, and this is done by naming each input ‘responses, each containing a collection of choices organised by their question_id.

So I could code my question partial (q is the current question):
<% question_name = ‘responses’ %>
<li class=”question” >
<%=label_tag ‘text’ + q.id.to_s, q.text%>
<%=text_field_tag question_name, nil, {:id=> ‘text’ + q.id.to_s} %>
</li>
However, I realised that I couldn’t determine what type of question is was yet; should I display a text-box, a check-box or a radio-box? Back to the drawing-board.
Iteration #3: Multiple-choices
I needed a way of determining what type of question I was asking: would I allow multiple responses to the same question (appropriate when asking ‘which of the following…), or only one (agree, disagree). I accomplished this by adding a allow_multiple flag to my question model, which I could then read in the view to determine whether or not to display a checkbox (for multiple responses) or a radio-box (for one-choice). When there were no choices for a question, I would assume a text-box was reuqired, and that is how the age/location fields work.

Once I had updated my fixtures, model and database, I could return to the view:
<% if q.choices.empty? %>
  <%=label_tag ‘text’ + q.id.to_s, q.text%>
   <%=text_field_tag question_name, nil, {:id=> ‘text’ + q.id.to_s} %>
<% else %>
      <p><%=q.text%></p>
      <% q.choices.each do |c| %>
      <div class=”choice”>
        <%=label_tag ‘choice’ + c.id.to_s, c.text%>
        <% if q.multiple_choice %>
          <%=check_box_tag question_name, c.id, nil, :id=> ‘choice’ + c.id.to_s%>
        <% else %>
          <%=radio_button_tag question_name, c.id, nil, :id=> ‘choice’ + c.id.to_s%>
        <% end %>
      </div>
      <% end %>
I could now view my form and see the correct input fields being displayed, ready for my controller to save the responses.
Iteration #4: Adding new choices
The main reason for developing a new questionnaire in rails was to allow my respondents to add choices which I hadn’t anticipated, in turn allowing others to choose the same response. This is proving useful for the ‘which music services do you use’ question, throwing-up websites I might not have otherwise heard of and I can now benchmark and investigate.

To add a new choice, I needed a way of distinguishing which questions I would allow new choices for and which I would not, so I added another field to question called ‘allow_new’. I updated my model, fixture, database (and unit test of course!) and was ready to up-date my view.
 <% if q.allow_new %>
      <div class=”choice”>
        <label>Other (please specify)</label>
        <div id=”new<%=q.id%>”>
          <%=text_field_tag ‘newchoice’, nil, {:id => ‘newchoice’ + q.id.to_s} %>
          <%=hidden_field_tag ‘question_id’, q.id, {:id => ‘question_id’ + q.id.to_s} %>
          <%=submit_to_remote ‘add_btn’, ‘Add’, :update => (‘q’ + q.id.to_s),
          :url => ‘/addchoice’, :submit => ‘q’ + q.id.to_s%>
        </div>
      </div>
      <% end %>
I added a textfield labelled ‘Other – please specify’ and a button with an AJAX action, so that respondants could add their new choice as they went along, without submitting the entire form. In order to achieve that, I used the submit_to_remote button, which in effect allowed me to nest multiple forms within a single form. Although intuitively, I wanted to create additonal form tags to surround the new text field, this approach didn’t seem to work cross-browser and only the one form is needed. Instead, the :submit option is used to tell javascript to serialise all of the form elements underneath the element with the given ID. The beauty is that this element doesn’t have to be a form element- so here I use the DIV surrounding the question, serialising only the text field for the new choice, along with the existing choices (which I later used to pre-populate the choices that had already been selected). I also pass along the question_id in a hidden field, so that the controller knows which question the new choice belongs to.

IE GOTCHAS: Developers beware! This approach of including multiple AJAX submit buttons in IE is very fickle; unless you play by its rules it wont work and you’ll probably waste time trying to figure it out. Don’t fall into these traps:

Iteration #5: Finishing up
I had a working questionniare, but I wanted to ensure that at least the age and location fields were completed, and that any previously-completed form elements were not lost in the event that validation failed.

The first task here is to ensure that the user model validates for this information:
class User < ActiveRecord::Base

  validates_presence_of :location
  validates_numericality_of :age, :allow_nil => false

  has_many :responses

end
Now if I try to call save! on the User class, I’ll get an error in my controller. Using a begin/rescue block, I could now take appropriate action:
rescue
     @errors = true
     @questions = Question.find(:all, :order => ‘question_order’)

     render :action => ‘index’
   end

  end
I didn’t want my validation to be too sophisticated. Here I used a flag stored in @errors that I check for in my view to display an error message.

To ensure that the form pre-populates with the previous responses, I had to pass the relevant data back out of the params object as the value parameter for the form tag helpers. In the case of the checkboxes, these values would be within a collection that stores the primary key of the choices that had been made, so a little logic was needed to detmermine whether or not to check the box controls:
checked = prevvalue.include?(c.id.to_s) or c.text == params
The second test here checks the new choice created by the AJAX form, determined by whether or not the text in the submitted box matches the newly-created test.

So, an afternoon invested in a new questionnaire and hopefully some intriguing insights into our music consumption habits. If you have any observations about my approach here, or have spotted something that I could have done better or more efficiently, please leave a comment as I’d be glad to know about it.

Of course, don’t forget to complete the questionnaire!

http://mostrated.com/questionnaires/
<% form_tag ‘/respond’ do -%>

<ol>
<% @questions.each do |q| %>

<%=render :partial => ‘questionnaires/question’, :locals => { :q => q } %>

<% end %>
</ol>

<div id=”submit”>
<p>That’s all for now! Press this button to complete the survey.</p>
<%=submit_tag ‘Submit Questionnaire’%>
</div>
<% end -%>