Open source at its best? A review of Spreeconf Europe 2012

The conference I could not miss

Last time I was in Dublin, I swore I’d never go back to the Guinness Storehouse. (I’ll explain why later, for those who are interested.)

But the Spree guys found the one thing that would drag me back: a two day conference on my favourite open-source project! In fact, I would rather have sold my grandmother than miss this. (Fortunately, the tickets were very reasonably priced thanks to the sponsors and my grandmother is safe. For now.)

I’m writing this the day after, sat in a Dublin hotel watching the traditional Irish summer weather (the wet kind). ‘Awesome’ doesn’t quite cover what happened over the past few days. Looking at the selection of tweets generated, this conference was, quite possibly:

print "legen-"; print ->(){ sleep 10; "dary"}[]

There was a great mix of speakers, and I learnt a lot of useful stuff. But two aspects really lifted it beyond just a good conference: interesting chats with great people outside of the talks, and an intangible but strong sense of community. For me, this made it a truly fantastic and unique experience.

What do I mean? At minimum, most of us had worked with the Spree code and had a vested interest in the general continued success of the project, so some (good) shared experiences and a common purpose. Quite a few of us had contributed to the project in various ways, all important and useful, from significant changes in the core code, to bug fixes and feedback, to writing some of the docs, to helping answer queries on the mailing list or IRC channel. Many of us had been helped by such people, and often we in turn had helped others. And for several of us, it was the first time meeting the people behind the email messages or commits (and a bit sad that a few people I had worked with before couldn’t make it this time – even the argumentative ones (-:). There was also a fair bit of pride that our various contributions over the years had built into something quite significant and important – giving many of us some kind of income wth tools we enjoy working with, and making a difference to users of the technology.

Basically, the very best that an open source project can offer!

And it’s such a great experience, I seriously recommend it to anyone who is interested in software: identify some projects which overlap with your interests, track them for a bit, maybe start fiddling with the code and participate in discussions, then maybe start helping out with the bug fixing, new features, and infrastructure. I promise you that you’ll learn a lot, much of which can’t be found in books or courses, and you’ll enjoy it too.

Amongst the various factors that contribute to the success of the Spree project, such as talented, enthusiastic, and helpful people, and tools like Ruby and Rails and their related infrastructures, I believe Sean Schofield (aka schof, uberzealot, …) deserves a huge amount of the credit. His good sense and generosity has been an inspiring model for all of us since the beginning of the project. It is an absolute pleasure to work with him!

Day one: related topics

Chris Mar kicked off with an overview of Spree and some current ideas that SpreeCommerce is investigating. The key points for me (as an old hand…) were:

  • use of the skeleton layout grid for responsive design
  • using jirafe to help collect and analyse interesting stats (looked nice
  • several payment gateway customizations for spree now collected under the “spree-gateway” gem
  • Spreecommerce has partnered with a few of the payment systems and (iirc) might lead to lower charges
  • spree-pinterest gem exists, and can be used to get some interesting numbers

Gregg Pollack gave an introduction to coffeescript. As you probably all know, Gregg is a great communicator of ideas and did a fine job. I particularly liked his technique of going from JS code to CS code to show where and how the improvements are made. It was a good overview of the basics in the time allowed.

There were some interesting questions, especially the usual one about debugging. Sounds like it is still an issue, though some tools are starting to appear which offer some help. Someone quite rightly pointed out that use of TDD will help to avoid many pitfalls.

However, CoffeeScript is not the only game in town – see for a fairly complete list. My current favourite is the ‘Fay’ language ( this is a cut-down compiler for a subset of Haskell into simple JS code. One advantage is that the code is valid Haskell, so can be debugged as a Haskell program, using the stronger type system and various Haskell testing tools, before eventual translation to JS. It also covers more language features than CoffeeScript, particularly the things I miss from CoffeeScript like nicer syntax for list comprehensions and support for more complex data types and pattern matching. Hey: it even allows you to use semicolons and braces if significant white-space isn’t your thing.

M Scott Ford was talking about testing in the context of spree instances, discussing testing of core and testing of integrations of core plus some extensions.

Unfortunately he had the “talk slot of doom” – right after lunch, and when the buffet contained various items made with Guinness. A few of us might have partaken of some liquid refreshment to wash lunch down. A few of us are also not as young as we once were and might have drifted away. (Which fool turned the lights down low? (-:) You’ll have to ask the younger guys for more info about this talk.

Do look out for a recent blog post by @albertovena on TDD-ing a Spree extension for subscriptions –

Nick Gauthier, author of Backbone Recipes, gave a nice intro to the key ideas of Backbone then launched us into a hack-along session, completing an app that he supplied the skeleton for. It’s always fun to have something to play with. Slides are at and the relevant code repo is at

In the evening, we had a few lightning talks during a github-sponsored open bar.

  • Brian Quinn talked a bit about the various ways of using the Deface gem and how the API has changed (you can play with it online too).
  • I talked briefly about the experimental Spree-based site I developed a while back to help coordinate a two-level selling process, where customers order from a trader and the trader orders from the wholesaler. (I must write this up sometime. Please bug me if I don’t do it soon.)
  •  there was a quick demo of a web-based tool to help manage and fill in I18n translations, which looked very useful (apologies: forgotten your names!)
  • The session ended with Nick Gauthier doing some penance involving some random unseen slides and a 20-second timer. I vaguely remember mention of DHH, watches, cars, and cats; but around then my Horlicks started calling…

Day two: About Spree

Quite appropriately, Sean Schofield began the proceedings by talking about his vision and purpose and what it means for Spree.

The vision is “empowering the world’s sellers”, and the purpose is “helping people and solving interesting problems”. Simple statements, but I think is significant how well it captures the motivations behind a lot of us who work with Spree. Perhaps it’s one of the reasons why we have such a strong community around Spree: from the top of the project downwards, we share and genuinely believe in these ideas.

Sean made an interesting comparison between publishing and selling, suggesting that Spree could become the WordPress for (e-)commerce by putting more and better functionality in the hands of smaller traders. One strong step towards this is via the SpreeWorks SaaS product. Sean gave us an overview. SpreeWorks gives people an easy entry into Spree-based selling and a good migration path towards full Spree use for when they need it.

Brian Quinn was up next, talking about his experiments with Backbone for providing more streamlining in tasks like product editing (in admin) and some of the store customization in SpreeWorks, also for improving the performance of the four high-traffic pages in Spree: product index, product show, taxon show, and order edit.

He has a work-in-progress tool (called ‘scribble’) for rendering json templates on the server via V8 with the aim of removing duplication between EJS and ERB templates. (Rich Quick made the sensible point that one could probably achieve this more directly by dynamically creating one set of templates from the other set with a bit of regexp magic. This is worth looking at.) Some references:

  • PJAX (= push-state + Ajax), for mirroring conventional url use
  • RABL gem to help with creation of JSON templates
  • for a demo of Brian’s experiments
  • for the code

Erik Michaels-Ober talked about code coverage tools. His starting point was “how do you become a better programmer”, and invited suggestions from the audience. Someone suggested Haskell (ok, that was me). And no-one suggested going back to school/college! Erik then gave an interesting overview of code coverage tools and gave a demo of some Ruby coverage tools. He also flagged up an article by the late William Thurston on proof & progress in maths which seems worth a look (or see the selected quote pasted in gist 3434943).

Ryan Bigg, who is doing a great job as Spree’s community manager, talked about managing people’s expectations in open source projects, particularly on the side of requesting help on IRC or other public forums. A lot of it boils down to common sense and consideration, of course, though we do occasionally get a few people who leave their common sense at home and make fools of themselves. There was one nice example of a guy who decided to ask the same question repeatedly in a channel until he got an answer…

Today’s holder of the “talk slot of doom” was Daniel Honig, who talked about his company’s experiences of using Spree in large enterprise projects. (I avoided the lunchtime Guinness and so stayed awake this time.) One such project was for the Chipotle Grill chain, with both B2B and B2C stores. He made several interesting points: the need for better reporting tools inside Spree admin (torquebox mentioned as a possible route?); how some customers want product pages to be more brochure-like or to serve as good marketing tools (and his team were experimenting the integration of Alchemy for richer CMS support – the demo looked good); and finally, some points about integrating Spree into various other business support systems like CRM and stock management. His team is working on a platform to help Spree inter-operate with some standard systems.

The best talk IMHO was Adil Wali‘s talk about developing and scaling an online business. He’s been involved in several big projects, and passed on some great insights from both his good and bad experiences of commerce projects. I’m a devout techie, but this guy really got me excited and interested about some of the business issues and how they relate to technical issues. You can see some of this on the sites and I have several pages of notes from this talk. I was going to say watch it online, but sadly the talks weren’t being videoed (apart from @joneslee85’s front-row seat – did he capture anything?). I’d better type up the notes some time.

[Side note: what’s your favourite commerce site? It’d be interesting to collect views on this. My absolute favourite is – completely unique and original, and her team are great on customer service. Free noodles too if you are lucky.]

Paul Campbell, known for his work on Exceptional and Funconf among others, talked about his ticketing site ‘Tito‘ and the various design changes and experiments that it has been through. The key point here is his goal to make it the best experience for buying tickets online. He talked about various design issues, and about experiences with javascript animations and PJAX.

Worth looking up if you haven’t already – the Stripe payment processing gateway, which is much simpler than the standard gateways. There’s some local interest in that it was started by two brothers from Ireland, and it is gradually working its way around the world from its base in the USA. Also worth a look is the Klarna gateway – these guys have partnered with Spreecommerce on a few projects, and were one of the conference sponsors.

Yehuda Katz closed the proceedings with a discussion on handling cruft in open source projects. He also touched on the strengths and weaknesses of the Unix philosophy of composing simple tools into something bigger, and what it meant in the context of larger projects, eg is it tantamount to pushing a problem from one place to another rather than reducing the problem?

Cruft means the ugly bits of code that were needed at some point to support some edge case on some awkward platform, that aren’t essential to the core project. This kind of code is often a source of annoyance and friction for several of the parties involved. The project teams are mostly aware of the cruft, and really do want to get rid of it as soon as they can, though practical details (like life) often get in the way. Newcomers to the project complain about the warts without understanding some of the circumstances and history. Competing projects derive some amusement from the cruft, particularly if they are young enough to have avoided the issues which made the cruft necessary. (Is there a lesson about parenting in here too?) So, Yehuda was reminding us that cruft is a fact of life, and is something we all need to be explicitly aware of and should try to take a balanced approach to. Worth a look: the jQuery roadmap from 28th June, on the jQuery project blog.

So, a great two days, kudos to Brian and crew for organising it, and I look forward to the next one!


Many thanks to my employer, TranscendIT Ltd ( for generously sponsoring my attendance and allowing me the time away. (We’re based in the North East of England, and we handle a variety of bespoke systems from education support to marine fuel testing, but are always interested in Spree projects, from full sites down to helping with technical problems. We’re recently recruited a great designer too!)

Big thanks as well to my better half for holding the fort and entertaining our three young tearaways in my absence. She’s also had to catch a ferocious mouse all by herself whilst I am some 300 miles away. Yes you can go for a spa day or three now (-;

Postscript: why don’t I like the Borehouse

I’ve been on a few brewery tours in my time, and the Storehouse is IMHO a bit of a shallow, anti-septic marketing exercise that leaves a rather bitter aftertaste. Kind of, that’s a few hours of my life that I’ll never get back, only slightly softened by mixing my end-of-tour pint with a good glug of blackcurrant cordial. You also realise how much of an international empire the brewer is, and what it entails. Compare with your favourite over-marketed IT brand now.

Anyway, do try Guiness shandy one time. It’s interesting. But I suggest you leave Ireland first before ordering it: I can’t be held responsible for the consequences. And if you’re in the North East any time soon, do look up Durham Brewery’s White Stout (yes: white) for a refreshing change, or their mighty 10% Imperial Stout.

I remember the time before monads

I’ve been fortunate enough to get some of my ‘essays’ into PragPub magazine, starting with an overview of how functional programmers think and how they use their languages. See Issue 38 for the first installment. Subsequent months should see articles on types and testing, practical programming, refactoring, and dependent types. And yes, eventually something about monads.

When planning these articles, I’ve been reading around some of the recent books and tutorials in Haskell and Ruby – mainly to get a feel for what people might understand and for places where they might run into stumbling blocks. I’m still not entirely satisfied with current material on Haskell, which is one reason I started to write these pieces. The ‘expert’ writing on Haskell is fairly dry, a bit too academic, and I rarely see much of the enjoyment and wonder that keeps me programming in Haskell even after 20+ years. (I love coding, it must be said, and I like to use tools that let me have fun and do great things.)

The other main camp is the people learning Haskell and trying to explain their experiences to others. Though there’s some very useful and interesting accounts out there, they generally also miss some important ideas or put too much emphasis on certain details (and I suspect that the expert camp is partly to blame, for not explaining some ideas as well as they could).

There’s two main culprits: (a) a sense of denial and (b) monads.


By denial, I mean the suggestion that Haskell etc denies itself the use of things like mutable state that everyone else takes for granted, and that a lot of what follows is an attempt to cope with our asceticism. My perspective is different: I see Haskell as starting from a different set of assumptions and arriving at a different place to the mainstream. Instead of us needing higher order functions to cope with not having mutable state, instead, I see HOFs as a useful tool for manipulating the data, and flexibility of HOFs means that we don’t need to rely on things like
mutable state so much. Hell, I’ll stick my neck out and propose a new law:

Callaghan’s 1st Law: the need for mutable state in a language is inversely proportional to its flexibility in manipulating data

Put another way, mutable state is a lower-level idea and becomes less important when your language supports higher-level ways of working.

A similar comment applies to our use of a type system. We’re not doing it to put ourselves in a strait-jacket for any silly or conservative reasons. Experienced Haskell programmers know that the type system is a tool for getting work done, and a great language for playing with designs, and they exploit these aspects to help them get their work done. Plus, if things get in the way, we often find ways to remove the obstacles.

So basically, I think FP and Haskell is more about opportunity than denial. We’re super-liberal!


There’s a view that Haskell is 99% monads (or thereabouts), and that monads are some arcane mystical concept which only a few can master. Bullshit to both!

I remember the time before monads. It _was not_ a barren wasteland, where all we could do is write programs to build trees and not communicate with the outside world. We really could do real world stuff, including file operations, console IO, IPC, though it was a bit clumsy in places. At that time, I was doing PhD work on a large Natural Language Processing system, around 60k lines of Haskell and so one of the largest programs of its time. The program could process and analyze Wall Street Journal articles in a few seconds and build a complex semantic representation of the story, and didn’t use a single monad.

It was however a time of exploration, when researchers explored various ideas to find a good way of both having our cake and eating it. Monads are one of the solutions they found, and essentially gave us a small but flexible API for working with “computations” (like IO operations or state  modifications, or various combinations thereof) as opposed to simple data values, and did so elegantly _within_ the standard langage (ie. no ad hoc extensions needed). It got even better when syntactic sugar was added.

This simple idea provided an excellent structuring pattern to tame a lot of
clumsy code, and even more useful, gave us a solid framework for exploring more powerful ideas.

So monads are highly useful for some aspects of programming work, but they are certainly not an essential or core part. I estimate that 50-80% of most large Haskell programs do not involve monads at all – they are just pure data manipulation. Of the remainder, the monad use is mostly straightforward and follows certain common idioms. Real scary stuff is pretty rare.

Last words

As a new explorer (very warm welcome, by the way!), when you look at Haskell material you may see some very unusual or scary-looking stuff. But do bear in mind that a lot of it is just playing around with abstractions on top of the core language, and probably does translate to something more intelligible. Try to work out what is being said about the data being manipulated, and then it might not look so bad.

Another thing that works is to avoid writing code for things you know how to do, and instead try to write code for other things. For example, try thinking and playing with various tree operations, like leaf counting, traversals, map/foldfilter… Then, you’ll be less tempted to slip into imperative mode.

I also recommend Graham Hutton’s “Programming in Haskell” as the best book introduction to the language. It is a brisk but surprisingly complete introduction to Haskell and related techniques, and parts of it remind me of K&R. However, it is still an academic textbook for an introductory course, and can be thin on the pragmatics and wider picture.

There’s also a thread on the PragPub forums where I’m collecting ideas/requests for future articles. Please feel free to add comments there –