Google +1 Recommendations Rolling Out to All Users Today

According to an email I’ve just received from Google, they are today rolling out Google +1 Recommendations to all users.

When you hover over a +1 button, you may now see a popup showing other pages on the site that your friends have recommended via +1.

My account has been in the beta test for the feature for the last few weeks, but I must admit I hadn’t noticed any recommendations until today. I guess I just hadn’t been using those +1 buttons enough!

Anyway, it’ll be interesting to see if this extra functionality is useful to anyone. If users do find it a useful way to discover new content, perhaps it could encourage a few more people to actually click the +1 button as well. For now, I haven’t found the recommendations particularly interesting, so I remain a bit skeptical about the new functionality. What I think would be useful to users is if the +1 button recommended content on other sites. But that would be a tough sell to the website owners who need to choose to include the +1 button in the first place and who wouldn’t want to lose visitors to their competition.

How about you? Are you seeing any interesting recommendations?


Comparing Payment Gateways and Merchant Accounts

PaymentBrain logo

Working out how to accept payments online is a pain. What do you need, exactly? Which payment gateway should you choose? How much will it cost?

I’ve set up a few online businesses now, so I think I have a pretty good idea of it all, but I remember how confusing all this payments stuff was to begin with.

What’s so Hard about Payment Processing?

When it comes to payment processing, there’s lots of terminology to get your head around (PCI, chargebacks, 3-D Secure, IMA) and dozens of factors to consider (security, shopping cart compatibility, support, retention periods).

Even when you understand it all, it takes ages to dig out relevant information about the different providers. And if you’re getting a merchant account you really need to shop around and play different providers off against each other to get good rates.

Does it Need to be so Hard?

Taking payments really shouldn’t be this hard. But no-one seems to be doing much to help UK merchants figure all this stuff out. The best resources I’ve come across are some excellent blog posts by David Mytton and Daniel Tenner.

So I’ve decided to have a go.

Introducing PaymentBrain

I’ve set up a site called PaymentBrain as a home for resources to help UK merchants choose online payment solutions.

So far, it’s hosting my first stab at a comparison engine to compare payment gateways. I hope to be adding and improving upon it as time goes by.

If you have a friend who’s planning to apply for a UK merchant account in the next few weeks, please put me in touch. I’d love to chat with him or her about it and to share what I know.



How to Speed Up Web Development Using a PSD to HTML Service

PowerBoat 0510 0929

Could you be saving yourself time and money with a PSD to HTML service?

PSD to HTML services allow you to send in the design for a web page as a PSD file (the kind of thing your web designer will create in Photoshop) and give you back a set of HTML and CSS files that can actually be served up as a website or, more usually, integrated into whatever platform you’re using, e.g. a website built in Ruby on Rails. In theory this saves you or your web developer time in doing the conversion work.

From what I’ve seen, PSD to HTML services can save you time and money in your web development process in some cases. They can free you or your web designer from the rather tedious chore of converting PSD design files to HTML and CSS. But they’re not always a good choice.


  • They save you or your team time for other things.
  • They’re fast (turnaround is generally within a few days).
  • They’re good for achieving support across browsers.
  • They’re easy to use.


  • The markup may be harder to maintain as you and your team may not be familiar with all the techniques used.
  • The markup may be more brittle than if developed in-house.
  • The markup may not be as well-labelled as if developed in-house.

In general, I can see PSD to HTML services being particularly useful when you have limited resources in-house for such work and in cases where you’re unlikely to need to make a lot of changes to the design.

I think they’re likely to be less useful in cases where you have a team of in-house designers or developers familiar with the conversion process and you’re going to be iterating frequently on the design. In these cases it’s probably better that your team be as familiar as possible with the HTML and CSS they’re going to be working with.

If you do decide to outsource your PSD to HTML conversion, here are a few simple tips I’d recommend:

  1. Use a reputable service. Consider how much time you are likely to spend working on the HTML and CSS that you get back. It’s generally worth spending extra money to use an established service provider with a good reputation. I’ve used and have been happy with the service.
  2. Include examples of error and alert messages. If you have error or alert messages that can sometimes appear at the top of a page, include one of each within the page designs you submit.
  3. Clarify your site’s requirements before placing your order. Some services allow you to specify whether, for example, you need IE6 compatibility. Take the time to get the specifications right. Extra options will typically bump up the price, but if you need them it’s worth paying as it’ll be harder and more expensive to change things later.
  4. Ask that the use of extra tags be kept to a minimum. Ideally, you don’t want extra tags polluting your nice, clean mark-up as they’ll make it harder to maintain and it’ll be harder to create new content using the same styling. (In practice, limitations of today’s technology mean that extra tags are necessary to achieve some effects, so just ask that they be used as little as possible.)

If you’ve tried one of these services, do share your experiences in the comments. I’d be interested to hear how you’ve found it.

Creative Commons License photo credit: Ross Elliott

How to Choose an E-Commerce Shopping Cart

Urban Shipwreck*

I recently spent some time comparing current e-commerce platforms (a.k.a. shopping carts). It’s a complicated area, so I thought I’d share my findings here in case they can be useful to others.

These are my opinions and analysis based on my own research and experimentation and are biased towards sites targeting a UK market.

First Things First: What is an E-Commerce Shopping Cart?

The name can be deceiving. E-commerce shopping carts are actually complete online shop sites. They allow you to set up various categories of products, set prices, calculate postage, tax and total costs, and send email confirmations to customers. More advanced systems provide features to help with marketing and customer relationship management (CRM).

To actually take payments you also need an account with a payment gateway such as PayPal or SagePay.

Hosted E-Commerce Platforms

Using a software-as-a-service (SaaS) e-commerce platform hosted by someone else is a good idea if you want to avoid the technical nitty-gritty of installing something yourself. A number of companies offer hosted ecommerce services allowing you to get going very quickly.

The downsides of hosted ecommerce solutions are the monthly fees and limited customisation options.

EKM Powershop

  • UK-only
  • Tends to produce rather dated-looking sites with table-based HTML
  • Easy to get up and running
  • Good range of features
  • Has been running for a long time, so should be stable
  • Approx £50 setup + £20 per month

Tiger Commerce

  • UK-only
  • Looks easy to get up and running
  • Approx £20 per month

Internet Retailer

  • Appears to be a fairly small company
  • Looks to provide smart and simple e-commerce sites
  • Recommended for good customer support
  • Approx £20 per month

Install-it-Yourself E-Commerce Platforms

If you want lots of flexibility and don’t mind getting your hands dirty with technical details (or getting someone else to do it on your behalf), installing and customising an open source e-commerce platform can be a good choice.

Bear in mind that if you’re not familiar with them, these do all require a considerable learning curve to get a shop up and running correctly with the various add-on modules you may want. Current shopping cart software tends to be written in php, so it’ll help if you know your way around that.


  • Open source
  • The most popular open source e-commerce platform for many years
  • Much of the community of this classic php shopping cart software has now moved on to other platforms

Zen Cart

  • Open source
  • Originally derived from OSCommerce
  • Now seems to have a greater following than OSCommerce
  • Plenty of add-ons available
  • Keeping core platform and add-ons up to date can be messy

Cube Cart

  • Open source
  • Seems less popular than Zen Cart


  • Open source
  • Based on a more modern architecture than Zen Desk, Cube Cart and OSCommerce
  • Supports multiple stores from a single installation
  • Has become one of the most popular open source ecommerce platforms over the last year
  • Still quite new, so may still have a few issues to iron out

Note: Magento is developed by a company that sells an expensive ‘enterprise’ version, however most users will be fine with the free version.


If you want a simple e-commerce site and don’t want the hassle of dealing with the underlying technology, go far a hosted e-commerce solution with good support.

If you want more control over things, the increasingly popular open source Magento platform looks like a good bet. Although less mature than OSCommerce and Zen Cart, I think Magento’s more up-to-date architecture and sizable, growing community make it a good choice for someone starting out with e-commerce today.

Have you looked into e-commerce solutions yourself? If so, do you agree with my findings? Please share your thoughts in the comments below.

Creative Commons License photo credit: MiiiSH

Best practice RESTful queries in Rails

Creative Commons License photo credit: alexanderdrachmann

I was recently helping a friend out with his Rails project and we were trying to figure out the best way to handle queries in a RESTful Rails app, i.e. returning a subset of items meeting certain conditions. After a bit of poking around, here’s what looks like the most promising convention to follow (please post a comment if you disagree with the conclusion described here).

We had two inter-related questions:

  1. What should a query URI look like in a RESTful environment?
  2. What Rails coding pattern should be used to respond the RESTful query?

What should a query URI look like in a RESTful environment?

The main choices here seemed to be between including the query parameters in the path or placing them after a question mark, e.g.

/items/large or /items?size=large

The answer is: use the latter form: /items?size=large

[Note: the exception would be if you have a resource called LargeItem in your app. In that case you’re really just looking at a standard REST collection GET which should be handled by the index method of your LargeItem controller.]

What Rails coding pattern should be used to respond the RESTful query?

So you’ve now opted for the URIs of the form /items?size=large. What code do you need to respond to these queries?

If you’re using the default Rails 2.0 RESTful resource scheme, queries will now be routed to the index method of your Item controller and your query parameters will be accessible via params, e.g. params[:size].

Your index method needs to return different subsets of your items collection depending on which (if any) query parameters have been passed in. For now I’ll probably put the logic to sort between the different cases in the controller, but it might be better to move it into the model (following the skinny controller, fat model pattern). Any thoughts on this?

How to link to specific queries

You can link to specific queries using something like this:

items_path(:size => ‘large’)


Many thanks to the following sources:

Fix for “Couldn’t find ‘authenticated’ generator”

Here’s another little problem I was just hitting and the solution in case it happens to help someone else out there.

If you’re trying to use a plugin (in this case the restful_authentication plugin) and you’re hitting an error like this when you use ./script/generate:

“Couldn’t find ‘authenticated’ generator”

Check to make sure that you have actually installed the plugin.

In my case, I’d done something like this:

matt@tigger:~/work/rails/streetloop$ script plugin install
Script started, file is plugin

I’d assumed this had installed the plugin, but I don’t think it had.

The correct syntax seemed to be this:

script/plugin install restful_authentication

[Note the use of the name of the plugin instead of the URL as before.]

This resulted in much more promising-looking output:

matt@tigger:~/work/rails/streetloop$ script/plugin install restful_authentication
+ ./Rakefile
+ ./generators/authenticated/USAGE
+ ./generators/authenticated/authenticated_generator.rb
+ ./generators/authenticated/templates/activation.html.erb
+ ./generators/authenticated/templates/authenticated_system.rb

Sure enough, with that installed, ./script/generate worked fine.

Hope that helps you too.

RESTful Rails

Today I decided to get my head around REST and, more specifically, whether and how I should use it in my Rails development projects.

REST (or REpresentational State Transfer – see Wikipedia), is all about resources. As I understand it, in a perfectly RESTful application, every object is resource with a unique identifier (in this case, a Web URL). Any resource can be created, deleted, updated or simply viewed. These operations correspond to the HTTP methods of POST, DELETE, PUT and GET respectively.

Suppose we have an application with a class called User. One instance of that class may have the following URI:

To read this user, we GET
To update the user, we can PUT data to
To create a new user, we POST to
To delete the user, we DELETE

Previously, in a traditional, non-RESTful environment, rather than using these different HTML methods (in particular, PUT and DELETE), you might have something like this:

To read the user, GET
To update the user, we can POST data to
To create a new user, we POST to
To delete the user, we might GET

For GET, PUT, POST and DELETE to work, your Rails application needs to know what to do with them when it receives them (otherwise, for example, how would it know whether you were reading, updating or deleting a user?) To tell Rails that you want to treat Users RESTfully, you specify so in the routes.rb file:

map.resources :users

This has the effect of mapping the GET, POST, PUT and DELETE of the URI to functions show, create, update and destroy in the associated controller. This mapping means that our application will handle such requests appropriately. But how will those requests get generated in the first place? Generally by the user’s browser following links that we’ve offered it. So the question is, how do we generate appropriate links?

We can generate RESTful links by using helper methods that are also (very handily) supplied by the resource declaration.

Named Route Helpers
============ =============================================
account account_url, hash_for_account_url,
account_path, hash_for_account_path

new_account new_account_url, hash_for_new_account_url,
new_account_path, hash_for_new_account_path

edit_account edit_account_url, hash_for_edit_account_url,
edit_account_path, hash_for_edit_account_path

So, for example,

link_to 'See user profile', :controller => 'users', :action => 'show', :id =>

might become

link_to 'See user profile', user_url(@user)

I converted a simple application to be mostly RESTful this afternoon, and switching to these helpers cleaned up the code considerably. I found that I did have a number of operations that couldn’t easily be mapped to a RESTful equivalent. It will be interesting to see whether, with a RESTful mindset, I can find a neater way to accomplish them.

In the meantime, for more details about taking a RESTful approach to Rails, have a look at the Rails API documentation.

How to add nofollow to links in Rails

It’s really very simple, but this one took me a while to figure out, so I thought I’d post it in case it helps someone else.

If you want to add a rel='nofollow' attribute to a link generated with a Rails helper, you just need to specify it in the html_options hash argument to link_to (or whatever link helper you’re using).

For example:

<%= link_to 'Vote', { :action => 'vote' }, { :rel => 'nofollow' } %>

Voila! This should discourage web crawlers (such as the Google search crawler) from following links they shouldn’t and generating false ‘clicks’.

Back online

Right, 67 minutes after I reported that I’d fixed the problem, my sites were back online.
In total my sites were down for 5 hours. Here’s a rough breakdown of where the time went:

  • 2.5 hours before I saw email telling me my site had been taken down
  • 1 hour to be allowed access to server to start troubleshooting (although I was doing some investigation on my test server during this time)
  • 0.5 hours to locate and fix issue on live server and communicate resolution to admins
  • 1 hour for admins to re-enable account

All in all I felt that the response from my hosting company was quite good. I was able to access front-line support through instant messaging and 2nd-line support through email with a 10-15 minute turnaround time once my case reached the front of their queue (which was within an hour of when I started hassling the front-line support guy). The email summary of the problem that I initially received was enough to track down the problem in my code and find a fix, so that was very useful. Even so, a better process might have saved about 90% of the downtime.