So You Want to Run a Fairtrade Business?

This is a brief retrospective of what I’ve learned in the 6 years I’ve been running Fair & Bare, a Fairtrade t-shirt company along with my wife.

If you’re a new follower of mine, you heard right – I run a Fairtrade t-shirt company. I’ve not actively been marketing it more recently for a number of reasons, but I still have a strong belief in our original vision. That vision was that Fairtrade shirts at the time weren’t being well received by the world, despite being available. We believed they could be, if we were only to find some that had good designs (and were possibly less ‘preachy’).

So that’s what we set out to do. From 2007-2011 we were running as an online design competition, inspired mainly by Threadless and Emptees, and helped via a great community of designers through a site I built entirely myself (whilst doing a PhD, getting married and buying a house). I’ve since learned that I don’t believe the competition sourced design is the best fit for what we are trying to do, but it constantly excited me that we *could* do it. I still hope some day to be proved wrong though.

Lessons Learned

The Ethical market pales in comparison to the cheaper alternatives. That probably won’t come as news to you. Most people – like it or not, will buy cheap over quality if they’re perceived to be comparable. This has certainly been my experience so far, having touted our wares at student markets, Fairtrade stalls and online. Be prepared to experience it first hand, and to repeatedly go over your story to get people to part with their cash. That is, after all, your unique selling point.

While we’re at it, if you’re selling online, be prepared to experience the same. When so much hard work has gone into creating your goods, you’ll find it heartbreaking to have a couple of people take up an offer from a newsletter of thousands. My advice would be not to get your hopes up….

But don’t entirely despair. When you make those few sales you’ll feel such a strong connection with your customer, even though you may never meet them. Repeat customers will give you a warm glow inside and smile all day long.

The Fairtrade supply chain is slow(er) and (more) fallible. We constantly had trouble with every supplier we used for our shirts over how quickly we could obtain stock and sometimes with the stock itself. Obviously, once our community had selected a design, we wanted it printed and available for sale. We knew we would have to wait for designs to be printed, but what we hadn’t counted on was how long it could take to get hold of shirts we’d ordered. Other businesses might be able to cope better with such delays. 2 months to go from selected to online is not ideal for our business model that relies on constant momentum, especially when we were dealing with a a single product at a time.

Depending on your supplier, you may also experience variations in sizes and colour. Be wary, you’re going to have to deal with all the resulting issues that arise from these problems with your customers or be lumbered with stock you’re unable to shift.

Times are hard for everyone. Since having started, 2 of the 3 suppliers we used have shut up shop and the third has changed it’s supplier. This has drastically reduced the options for us to the point of being unviable, which is one of the reasons we haven’t put out a new design since 2011. (If anyone is able to point me in the direction of other wholesale ethical brands, I’d be keen to hear about them).

Fairtrade cotton, Fairtrade or fair trade? Organic? Soil association certified? You need to be aware of the differences, because competitors will use similar terms. Even though they mean different things to you, most customers don’t know the difference and lump them all in the same good for the producer pot.

First impressions count. Originally, we used to send out our t-shirts in recycled packaging we sourced from envelopes we had kicking around our house. I have to cringe at this now – the idea that old crumply packets were being received with sticky-taped-on labels. That was our first physical impression on our customer. *Sigh*. Our heart was in the right place though, we didn’t (and still don’t) want to be creating more waste. We’ve since moved on to shipping goods out in recycled packets.

Marketing is key. When you’re not marketing your goods, you’re not seen to be active. Just by talking about your business, you’ll get interest in your product and make sales. Our buzz came from regular competitions and launches of new shirts. With every new shirt we’d let our mailing list, community and followers know of its arrival.

Finally, a word on branding. I constantly wrestle with wether we would have been better off branding ourselves first and foremost a t-shirt design company, rather than a Fairtrade one. I think the answer is yes. Our whole ethos was originally based around the lack of well designed Fairtrade shirts. Ultimately, if a design looks good, a customer is going to be happy paying a little more if it’s what they want. The ethical aspect of the cotton is, in their mind, a bonus. But if they’re not even visiting your site or stall because they see you first and foremost as an ethical brand, and that doesn’t entirely float their boat, then you’ve lost a sale.

The whole experience of running Fair & Bare has been a bit of a roller coaster of highs and lows. I’ve learned so much from running it and hope to continue to do so.

It wouldn’t be right of me to post about Fair & Bare here without letting my readers in on a special offer. For this Easter weekend, when you buy two shirts, you’ll get the third free on using the code “EASTEREGG” when checking out.

Breaking up Relationships with CouchDB

[NB: This is an unpublished post I wrote in 2010 on getting started with CouchDB. Therefore, despite all the code and examples being relevant, it may be considered somewhat 'belated']

Beware – there’s a bunch of home wreckers out there intent on removing the love of your life and replacing it with a wicked mistress.

For me, my first experiments working with databases were performed with Oracle, the staple of our computer science course at the time. We were taught how to identify common structures in what we wanted to store (or had already been stored) and how to represent the relationships which existed between them. There was an entire series of lectures dedicated to this fine art, much of which I now can’t remember.

There has been an uptake in the number of developers working with NoSQL, or document oriented databases. These alternatives do not require decisions on subdividing documents into multiple record structures to be made at all, instead allowing the entire document to be recorded as a series of simple variable types. The contents of each document can vary from one document to the next. For the majority of developers who work with relational databases, this might come as a bit of a shock.

There are a number of varieties of NoSQL flavours currently available: CouchDB, Cassandra and MongoDB are a few of the hot ones right now. I’m not going to discuss the pros and cons of each right here (for that I’d refer you to The Changelog’s NoSQL smackdown podcasts), but rather give you a whistle stop tour of CouchDB, which I’ve been working with for a few years now.

If you want to follow along, you’ll need to head to the CouchDB site and read up on installation for your platform. I’m using the CouchDB server app, which is nice and self contained.

Document oriented storage gives me the ability not to have to worry about the structure of my documents prior to storage. From my own point of view this is a huge timesaver as my apps often tend to focus on a single type of document. Think of a blog post stored in a mysql database, we have a table for the post along with all its metadata, a table for the comments and maybe another for recording pingbacks. The same blog post in couch could be represented like so:

   "_id": "83ab09b88836ab714f592293d4e02845",
   "title": "My Blog Post",
   "content": "Lorem ipsum dolor sit amet, consectetur adipiscing elit",
   "comments": [{"ian": "You're a wally"},{"Some user": "This post sucks"}]

A document based db may well not be suitable for the nature of your application. However, I’ve found in lots of cases, it is.

Rest Style Interface

CouchDB works across a REST style interface. To write documents back to couch, you call a HTTP PUT or POST with your JSON structure. To read documents, you call a GET and to delete them you call DELETE. For example, to add a document with “_id=someid” to the database “blog”, you would call the following:

curl -X PUT -d '{"Title":"Another Blog Post", "Content":"Lorem ipsum dolor sit amet, consectetur adipiscing elit"}'

Similarly you can HTTP GET this uri to return the document just added. Saving the document to a couch store will add another field, “_rev” which represents the particular revision of the document you’re storing. Every time you update this document, it will be stored as a new document, along with a new revision number. You have access to all these revisions within couch, or you can choose to cleanup the database by compacting and removing all but the most recent revision of documents. Another blog entry document without any comments would be perfectly valid stored in the same database, as well as a document featuring just an array of pingback items.

You’ll notice that the structures are JSON objects. This is how all objects are exchanged between couch and other languages and over couch’s REST interface. Heading to where we stored the above blog document “” in your browser yields a collection of metadata expressed in a JSON structure about that particular database. Appending “/83ab09b88836ab714f592293d4e02845″ (the id of the document) gives us the original blog document.

This, in turn works wonderfully well with certain frontend frameworks – such as Backbone. If you configure your backbone models to construct URLs the way CouchDB expects them, you can effectively have a frontend app driven by just a CouchDB store. As CouchDB returns JSON objects, it’s able to correctly parse and load them into your backbone app.


To support the extraction of substructures and sorting within these documents, couch has the concept of map/reduce built straight into its core. Futon, couch’s built in administration application, makes creation of these a very simple process. Maps and Reductions are described in Javascript, which is great given most of us are making more and more use of it these days. Head over to and you’ll see your collection of databases right away. Navigate to the blog database and under the view dropdown, select temporary view. Couch automatically populates this with a default temporary view:

function(doc) {
  emit(null, doc);

This basically reads as: for each document emit an object with a null key and the document as the value which is what you’ll see if you go ahead and run it. Not particularly exciting really, but by changing the null key to doc.title, we can emit all those blog posts sorted by title. To do something a little more complicated, such as determining the number of comments for each blog post we can make use of the reduce function too.


function(doc) {
  for(var i=0; i < doc.comments.length; i++){
   emit(doc.title, 1);


function (keys, values){
   return sum(values);

Here, we cycle each of the comments for every blog post and emit a single value 1 for every comment. Our reduce function takes both the entire key and value set which are emitted from the map function for each document and calculates the sum of values sent to it. With these two very basic functions we can support all the queries we might want to make of the database. You can permanently store this entire map/reduce query as a view within couch to be called later. When a document is inserted which effects the result of the query, the map/reduce will be re-evaluated on the next call. It turns out that storing and querying documents in this way can be extremely performant.

I very much enjoy having the ability to write my queries in a language I’m familiar with to retrieve results, rather than having to dip into MySQL voodoo.

So, there you have it, CouchDB – I may well follow this up at a later date with a comparison with Mongo, given I’m now a certified developer.

Growing a Business with Developer APIs

Those of your you who follow me on twitter will might be aware of a single day hack I attempted last week, which takes output from Lovefilm’s customer history and formats it so it can easily be imported into the lovely Letterboxd. It’s named Loveletterd and it seemed entirely appropriate to release it on Valentines day.

After hearing that Letterboxd had created a CSV import tool for it’s community to use and as I’m a Lovefilm developer, I felt like it would be a great use of my time to get to work on Loveletterd.

Originally, I’d thought I’d use Lovefilm’s OAuth sign-on, grab past rentals for a user and create a CSV from it formatting to Letterboxd’s import structure. I’d completely forgotten about a bug I raised on the developer forums; almost 3 years earlier – highlighting that actually this was impossible due to a bug which didn’t read a supplied argument, subsequently limiting the number of rental titles returned as the history. What’s more infuriating is that no one from Lovefilm had replied, even though the problem was reiterated by others in the same and other threads. There’s many different threads which highlight numerous other issues, all of which receive no or very little response from the Lovefilm developer team.

This is an awful way to treat a community excited about building tools with your company data. If you don’t want to cushion the cost of supporting providing such an API yourself, don’t create one, or charge for access to it. Similar sentiment has been said about twitter recently on changing their API rendering it unusable for apps that have based their business models on it. Such is the feeling of discontent that it’s led to a niche for rivals.

Lovefilm’s API “gallery” of developer apps features the message

“We will be placing details of the latest and greatest applications using our API here. Be sure to check this page regularly as new ideas are developed.”

Which is also the same as 3 years ago, shortly after the API’s first release. Good work Lovefilm.

Remembering this, I walked away thinking, “Oh, well”, before going back to my workday. Explaining it to my wife, I realised there was another route to achieve what I wanted, which is what you see on the web now. Ultimately, this is nothing more than a bunch of regular expressions.

Admittedly, I’m aware there’s changes at Lovefilm – they’ve been entirely bought out by Amazon and I can imagine the new owners would want to integrate the company with their brand better. It seems as if they’ve already switched off new developer registrations, so I’d imagine the whole API will be turned off before long.

On the flip, take a look at where I want to take my data to – Letterboxd. A site focused on film lovers and it shows. They’ve taken the route of paid pro accounts, which provide access to the import tools I mentioned earlier. The majority of users won’t make use of this though; they just want to support a site providing a great service which is open and honest. They’re also planning on providing a full API, which I’ll be interested in playing with on release. As a result, I’m sure Letterboxd users will get a bunch of new toys they can use their accounts with that external developers decide to create.

The best thing though? They’re real people who talk to me. After letting them know about my little hack, I got thanks that same day from Matthew of the Letterboxd crew, with a ticket closure shortly thereafter. That beats 3 years of waiting.

Introvert Interfacing

You pay for your ticket, hotels, travel and then spend the rest of the year excitedly awaiting being able to attend the conference everyone is speaking about. Having travelled halfway across the country, braving weather you’d never ordinarily leave the house for, you arrive in the unrecognisable city. You’ve left your family to be here, which is heart wrenching at the best of times and your lonely hotel room is no comfort (especially given the number of beds it has).

You hurredly beaver off to the first fringe event with butterflies in anticipation of the luminaries that are possibly going to be there too. On arrival, the room is bustling with faces from avatars you recognise. How exciting! You know so much about these people from following them day to day; even what they ate for breakfast, the bars they attended, who they hang with.

Yet these cheery personas are only facets of their real life. Chances are, any person you recognise is someone you admire in the industry – but what could you possibly have to talk about? Your lowly 9-5 pales in comparison to the waves these trendsetters are making, they wouldn’t really care what you do would they? Maybe we have something in common? Unfortunately, it’s always far easier to remain silent than waltz up to someone new or that you recognise and drum up a conversation. Inevitably, this more than often happens.

The organisers have done a fantastic job. “Talk with everyone else, make friends”, they prompt – if only you were able to. The conference itself is amazing, inspiring and useful, but others seem to get so much more from it. New friendships are forged, existing ones cemented. Are you the issue here?

Finding food is a problem. Do you venture out in the hope of finding people to talk to, or do you eat out on your own? It becomes easier to ask via twitter, than face to face. At least the conference day provides lunch for you, even if you choose to eat it on your own. You feel like a teenager.

The after-party is much like being back at a school disco. People stare longingly into their empty glasses, whilst propping up walls, longing for company. Why don’t you talk to them? Others circle back into their longstanding groups and attract fresh blood. Those in groups wear similar clothes. Maybe you should buy plaid? You return to the hotel at a reasonable hour, missing out on the later rawkus highjinks.

In the morning, you skulk back onto your bus, wishing you’d coughed up the extra to go via train just to get home sooner.

The Move Towards Static Websites

There’s some discussion on new podcast “The Back to Front Show” on why of late we’re seeing so many static websites cropping up. It seem like now more than ever, we’re seeing both developers and designers jump ship to this way of working, having long been using database backed solutions (such as WordPress/Drupal) to manage their publishing.

When I talk about a static site, I think of it of raw HTML sat on a server and nothing else. However, it seems as if the industry has adopted the term to refer to sites created from tools which are capable of creating/emulating this HTML, whether it be a local, dropbox or a hosted/self-hosted solution. Typically both types of tool are powered through conversion of flat files into the markup which is served publicly. Through using them you can achieve something akin to a typical blog, without the need for a database (or possibly even a server-side language to power it).


Simplicity – Most of the draw toward toward such setups seems to be on the simplicity over flexibility. I can power a site with a minimal setup, but still regularly and simply update and maintain it, using a partial based environment. With a dropbox based solution, I just need to drop my flat files into a folder and everything is updated transparently. Mark Boulton has previously written about his requirements for writing on the web and why he went with Statamic:

“I wanted a way of simply publishing words, rather than getting all wrapped up in php, theming files and database problems.”

Simplicity it seems, rules.

I previously wrote an article on how you could publish using Octopress and Amazon’s S3 service. For anyone who has a relatively low traffic site, such a setup could also work out cheaper than a monthly hosting package.

Development Time – If you’re one for creating custom themes, a static site is also a much simpler solution than wrestling with styling the innerds of a full fledged cms. Typically posts are stored in markdown and can be styled along with assets using a partial templating system (eg. based on YAML or Liquid). Having recently developed a wordpress theme I can testify to the complexity of having to dig through documentation on function usage and to determine which template file should be modified to achieve what I want within a page.

Source Control – As Rick quite rightly points out below in the comments, having all your posts available in flat files makes them perfect for managing/backing up through your revision control tools of choice.


Customisation – For me, the big loss is the lack of flexibility. I hear everyone cry, “Well, duh – it’s static”. Without a server side language handling requests, I’m unable to schedule posts, handle comments, create forms or trigger email. If I intend on continuing to offer them, I have to find third party services to deal with each of these aspects. I’m well aware there’s services like disqus and wufoo that may solve some of these problems, but it seems like a major hassle to integrate each time something like this is required. It may be that this is just me, you may be perfectly happy using these solutions, or may not require them.

Remote publishing – When using a local based solution (e.g. Jekyll), you don’t have the option of blogging remotely, due to the lack of tools to create and push out your content. Gone are the days of being able to log into a site from your phone and add a small update. For me, this is less of an issue as I can’t recall if I’ve ever written a post in this way and try to be more methodical, less spontaneous about what I’m writing from the comfort of my desktop.

Example Systems

If you’re interested in running a static site, then I’ve listed a few that seem pretty popular at the time of writing, along with a brief list of their features.

Jekyll – Locally run, File based, Open source, Powers Github pages.
Octopress – Locally run, Jekyll/File based, but with preconfigured HTML templates, CSS, Javascript, Open Source
Statamic – Self Hosted, File Based, License Required
Kirby – Self Hosted, File based, jQuery inspired API, License Required
Stacey – Self hosted, File based, Open source
Scriptogram – Dropbox/File based

New Year, New Theme

I’ve long made use of the default theme on WordPress, which I’ve always felt wasn’t entirely “me”. The theme now live is one I’ve been tinkering with for a while now based on the lovely preview design used in the document editing tool for github. I really like the focus on simplicity and think it suits me well.

I’ve added some different styling for the navigation elements, given they didn’t already exist on I’ve also added some subtle colour changes when navigating between pages, many of which are based on Laura Kalbag‘s palettes over on colour lovers.

One of the things I hadn’t counted on was consolidating 10 years worth of blog posts into sensible categories as it was becoming a bit of a mess. When I first started blogging, wordpress didn’t exist, let alone tagging and I think I started out using categories in a manner to replicate them.

There’s still a few things I’m not entirely happy with, such as how navigation is represented for single posts. I intend to tidy the theme up and release it back to the WordPress community, but for now I’m enjoying having finally got it out in the open. Feel free to let me know what you think.

Why I Choose Popular Frameworks

I feel compelled to write this post so late in the day after clocking Tyler Renelle’s rant on github about his problems with the popularity of certain JS frameworks (in the main Backbone.js). After having written apps in a variety of JS frameworks (Backbone, Spine and Meteor), I’ve learned that the feature set of a framework is not the only thing I hold dear when making a choice between them.

Documentation, support, learning curve and most importantly community are what also guide me when building anything. If I need to make an app quickly, I’ll of course develop it in my favourite tool (Backbone), because I’ve been using it for years and therefore doesn’t hold a cost. If I have a problem, I know there’s a ton of hackers who’ve probably already worked on solutions already and mechanisms are in place for them to offer advice. There may be better documented more capable tools, but I can’t foot the expense in the short term that might come with investigating something new and run the risk of hitting problems I can’t solve. In the long term, as a framework grows in popularity and garners these other factors then I may make that jump.

The real reason these frameworks are popular right now is in part because they are already popular.


So here we are in a brand new year. 2012 came and went without even the slightest apocalypse. Reflecting on what has been achieved this past year has found favour with others in the web profession so I thought I might try it. More importantly to me, it also seems like a good way to perhaps spur me on to achieve some firm targets this year.

My circumstances have dramatically changed since January last year. I’ve gone from full time employment as a frontend/backend developer for Aardman to being self employed as a frontend developer for the majority of the year. This was (and still is) a scary leap. Finding work, managing finances whilst still trying to be a good father/husband is a sometimes difficult balancing act to perform. So far though (after 9 months and counting), I’m enjoying it.


The amount of conferences/meetups that have been organised this side of the bridge has been fantastic, especially where I’ve not had such a long commute this year. I’ve been able to head along regularly but have had to be fairly choosy about the amount of events I can attend. It’s great to see such a blossoming community round here. I’ve also thought about organising my own event, though I think I have enough on my plate at the moment.


JS has been my bread and butter this year. I’ve enjoyed digging deeper into various frontend frameworks and learning as much as I can about the language. Where I’ve known relatively little about the ins and outs of other backend languages, I feel like I actually have something to contribute here. I’ve continued tinkering with node.js on the backend and have used it as a build tool for much of the year. I spent some time learning a little Cocoa shortly after leaving Aardman and taking the MongoDB developer training course by 10gen. Whilst I found it difficult fitting the course in around everything, I can highly recommend it. I’ve even developed a couple of things myself, which I hope to tidy up and release over the coming year. I’ve not been able to write a great deal about what I’m learning, but hope that will soon change. Some of my most popular posts here relate to use of CouchDB and node.js from many moons ago.


I already had a number of side projects running before the start of last year but I’ve had a number of ideas for tools and a fairly major service I’d like to work on across 2012. I plan on releasing more details soon, but would love to have a recurring revenue stream from one of these coming in at some point this year. I find I can easily stray from this path and get distracted by other less fruitful ideas I have. I’m going to make it a resolution that I remain committed to one thing at a time, whilst putting to bed ideas that haven’t worked out.


As much as I feel like I have adequate design chops, I’ve not had the opportunity to demonstrate them publicly. I’d love to redesign several of my sites to a standard that I feel reflect my skills as a web craftsman. I’m currently working on developing a wordpress theme which I hope to contribute back to the community once I’m done.

So in all, it’s been a good, 2012. I’ve not fitted everything I might like in, but much of the content of my projects and work I had no idea about back at the start of last year. That also means you have something to look forward to from me in 2013.

Happy New Year everyone.

Oh Crap, I’m a Frontend Developer

When I was first tiptoeing in the waters of web development (early 2000′s), getting a grips on job descriptions was simple. There were 2 types of people in our industry: designers or developers. You either drew websites, or you built websites – that was it.

As time went on people seemed to invent new titles: “UX Designers” were the first to appear on the scene to me, and we’re still to this day figuring out what this role really entails. The one that particularly got my hair up though was a “Frontend Developer”. Basically, going from the skills that were listed with these roles (HTML, CSS, JS) it was a designer who could also do a bit of jQuery…. Not a real developer then. Not someone who pokes around with backend scripts and really knows what’s going on, right? Someone who can properly structure apps and create proper object oriented classes. It got my hair up because it seemed like an attempt to poach credentials from us hardworking devs. How dare they. Losers.

Time passed…. I got a real job….. The industry invented more job titles….

My first role was as a PHP/MySQL developer. I also started having to make decisions on frontend design and behaviour without having a formal education in either. I was, in my own projects at least, the only person to do such work. Outside of work during my first job, I decided to play with two hot technologies at the time: CouchDB and node.js. I geeked out about both, using document based stores and Javascript server-side – but hated the steep learning curve that came with having to use JS. It also missed many of the constructs I’d become used to in other languages.

I’d seen a great deal of realtime apps and knew behaviour in my own apps should be keeping up. What I had could be better, much better. It was about here I probably started appreciating how much work was involved in a typical browser based app. I started using backbone.js with a view to better organising the mess of JS that typically sat next to my markup. There wasn’t a great deal of help around, so I read a book as an aide….. I had to properly approach what was going on in the browser as I would do any other software. Hmm, weird. JS in the browser had up until now, been an afterthought to “jazz stuff up”. Developing real, well designed software in the browser however really floated my boat. I prototyped a simple calendar app and it worked fantastically well.

Since then, I’ve been lucky enough to move into a full time contract role as a Javascript Developer – or a Frontend Web Developer, if you like. I probably would have been shocked had someone suggested this 5 or so years ago.

I’m really enjoying being part of the community around JS, the ever increasing list of libraries being posted and patterns for development. Hopefully I’ve learnt to be a little more discerning of job titles than I have been in the past.

Essential Cinema According to Lovefilm

Given there’s a bit of lovefilm bashing going on in Wales at the moment, I thought I’d chime in with the most frustrating thing I found with communications from lovefilm.

Check out the following weekly email I used to receive (I’ve since unsubscribed), along with my annotations.

I really couldn’t care less about who lovefilm are sending into cinema’s to perform reviews and certainly don’t want it to be the first text I see in relation to that image.

Also, the first thing I’m drawn to is the image. Why lead me away from the title of that movie and make work to find the text for the heading? Don’t make the title and preview exactly the same size, or divide them up!

End of rant.