I started 3hv way back in 2006.

I was using this new-fangled Ruby on Rails to build web-based software and Web 2.0 was all the rage.

Now, Ruby is still my favourite programming language, but the world around us has changed.

The best way to build a traditional website, at least for most small to medium sized organisations, is WordPress. I’m amazed at how capable WP is, and how it’s grown from a small toy application into a platform for publishing.

The best way to design a website is to do a rough sketch and then build it directly in HTML and CSS. Photoshop and those other Adobe tools are redundant and it’s a massive waste of everyone’s time to build pixel-perfect designs and expect them to work on the web. There are just too many variables nowadays, not least the huge range of DPIs that you need to deal with (from 72 to 450). Photoshop is great for paper, where you know what the target material will be. With the web, you’ve never really known what the target will be, and today’s proliferation of devices just brings that home.

Rails used to be the first choice of the single freelancer or tiny agency (like 3hv) working for a small company. Agile, nimble, get something up and running quickly and keep it well engineered. But now Rails is used in huge organisations (the NHS and Capita being two with whom I’ve recently spoken) and the price of Rails developers is so high it would be irresponsible to recommend it to small organisations. Likewise, building web-sites and converting designs to HTML is priced so low, it’s not possible to make a living in this country without being able scaling to many jobs at once – which in turn means managing a team of developers, account management and a load of stuff I don’t really want to do.

But most of all, the nature of how we access things has changed. Now you pay the gatekeepers, Apple, Google, Amazon, to get things published. Proprietary tools, controlled platforms. The total opposite of how things were eight years ago.

So it’s time to say goodbye to it and close down the company.

Most of the team here (amongst them Nabin, Mahhek, Vadim and Chandra) are in the process of moving on, or have already started elsewhere.

Personally, I’ll still be Ruby programming, building and designing databases and managing servers on a day-to-day basis. I’ll keep any hosting running (part of my new found enjoyment of systems administration) and I’ll always help out my previous clients where I can.

I also know enough about web-sites, user-experience, site structure, landing pages, on-site SEO and WordPress customisation to be able to advise you if you have a new project.

But I’m not interested in converting people’s designs, building web-sites or coding WordPress plugins. It’s not what I enjoy and it’s not what I do a great job at.

It’s been quite the eight years, but there’s no point looking back.


The Matrix

I spend a lot of my time staring at screens that look like this…

Screen Shot 2014-03-14 at 18.56.48

I had the realisation the other day that to most people I must look like the guy from the Matrix – reading an impenetrable stream of digits and making sense of them.

Surprise of the day…

I’m installing PHP on my computer.

Ultimately, the stuff I’m building has an ever clearer separation between the front and back end.

And I’m finding WordPress is a really easy way of building front-ends, which is easy enough for your clients to amend.

Chatting whilst you work

I’ve mentioned before that I think a chat room is essential if you are working remotely. In fact, I like having one even when working in an office, but I never really understood why.

I think I’ve figured it out now – I like to chat whilst I work. Not all the time; just occasionally. It keeps others informed about what I’m doing and it helps me think.

For example, this little excerpt from today’s room is just an explanation of an investigation I was doing. It’s probably meaningless to most people (and this is the advantage of a chat room over physically talking – those who aren’t interested can just ignore it). But it may have meaning for someone listening, it’s now permanently logged and the act of writing out what I was doing helped me focus in on the problem.

Rahoul B.	fuck and yay!
it's worked
but i don't know why
all i did was add some extra logging into the app to see what it was doing
INFO -- : ... path to file is /Images_Web/7
INFO -- : ... asset management configured: true - Client/Images Images_Web->Images .tif
INFO -- : ... high res file path is Client/Images/Images/7/760955CP.tif
that line in the middle is to prove that it is configured correctly
so maybe for some reason it wasn't loading the "is asset management configured" bit correctly
although i don't understand why not

Tell, don’t ask

Most people, when implementing a controller action, would write something like this:

def index
  @people =


def search_params
  params.require(:search).permit(:last_name, :something_else)

(This is intended to be a Rails controller – so the #index action fills in the @people instance variable, the “index.[whatever].erb” template finds @people and uses it to render the view).

But I would write it like this:

def index
  searcher.fetch(search_params) do | found |
    render action: 'index', locals: { people: found }


def searcher
  @searcher ||= current_user

def search_params
  params.require(:search).permit(:last_name, :something_else)

Three major changes; I’ve added a “searcher” protected method – this is just to make the index action a bit more readable.

I’ve explicitly rendered the “index” template, rather than relying on Rails to implicitly render it – and I’ve passed in the results as a local variable called people instead of as an instance variable called @people. These are exactly to make things clearer, instead of using Rails “magic” – in particular, passing local variables to templates is a great idea as they fail to render if you accidentally miss something out – meaning your dependencies are explicit.

And instead of returning my search results as an answer from the #fetch message, I’ve passed a block as an additional parameter to the #fetch message. Technically, there’s no difference between the two styles; in both cases I need to have some knowledge about the search results (it’s some sort of Enumerable and each item within it will respond to messages like #name and #email). But in the first case, I’m asking the searcher for its results and then doing something with the answer. In the second case, I’m telling the searcher to do something that I specify when it finds those results.

Tell, don’t ask“.

The key is that the searcher, who knows about people, is in control of the interaction – it can do what it needs (presumably finding our results), yields to my block when it is ready and then can do stuff afterwards. It can choose never to yield, if it deems its results irrelevant.

The searcher knows about people so we tell it to deal with those people.

As I say, there’s no technical difference between the two. But semantically there’s a world of difference and it’s always worth remembering who knows what and who is in charge at any point in your application.


I’ve been doing a bit of work with WordPress recently. I have to say I’m really impressed – it’s grown so much from being a basic blogging platform into full-blown CMS. Just a shame I have to work in PHP.

What do you do?

You’re asked for an estimate – of time and costs. As accurate as possible please, we have clients and stake-holders who need to make their own plans based upon this.

You provide that estimate. And then you are told that one of the stake-holders has a deadline well before your estimate’s completion date.

What do you do?


For all the new User Interface patterns that mobile and tablet devices have spawned (Google’s excellent cards, iOS’s mimicry of real world objects, Windows Phone 7′s lovely tiles and the one that changed everything for me; Flipboard), some things remain the same.

When people, at work, are dealing with large amounts of data, your cards and tiles and shelves and layers are useless. What people want is a spreadsheet – a grid of data that they can type in, tab from field to field, row to row, as quickly as possible.