Span 2014 retrospective

Posted on 03 Nov 2014 by Matthew Revell

Last week we held London’s first developer conference dedicated to scalable systems: Span.

Over 100 people attended, 11 people gave talks and six companies sponsored. Here’s my take on what went well and what didn’t.

Why a scaling conference in London?

Working as an evangelist/advocate, I’ve been to a lot of developer conferences.

Most are pretty good but there are some things that I, along with friends, had noticed made for a poorer conference experience. Namely:

  • Sponsored talks: attendee happiness and engagement appears to be directly inverse to the number of sponsored talks. Some conferences appear to reject good talks in the hope of encouraging the purchase of a speaking slot.
  • Vendor presentations in disguise: even when the talks aren’t sponsored, direct sales pitches creep into the programme and are usually dull.
  • Drinks: coffee is often horrible, cold drinks are usually unhealthy and, most important of all, they all run out too quickly.
  • Multiple tracks: no doubt, there are good reasons for multi-track conferences but one track of great talks is better than two tracks of reasonably interesting talks.
  • Poorly defined topic/veering from the topic: there has been a creeping tendency for developer conferences to mix things up with non-developer talks and it’s very hard to make these work well.
  • Talks without take-aways: sometimes it’s good to have a talk that deals with the abstract but most people are willing to take a day out for a conference that will give them stuff they can put into action.

So, I had opinions on what made some conferences less appealing to me.

It also seemed that there was a gap, in London at least, for a conference that dealt with building scalable systems.

Scalability is where so much interesting stuff is happening right now. Whether we’re building small web apps in our spare time or working on multi-million dollar applications, dealing with scale is something we either aspire to or face each day.

Each of the many London developer conferences were either narrowly focused on an aspect of something related to scaling – for example, NoSQL databases or microservices – or much broader in scope, giving only one or two slots to scalability topics.

A recipe for a scaling conference that’d make me happy

Towards the beginning of this year I began toying with ideas and came up with a list of what I’d want to see from a scaling conference:

  • No sales pitches.
  • Every talk had to stick to the topic.
  • Shorter talks that got to the point.
  • Practical takeaways, ideally focusing on war stories and lessons learned.
  • A single track on a single day.
  • Good food, good coffee, good opportunities to chat to other attendees.

Pretty quickly I pulled Phil Fehre into it and we started making plans.

Almost the first thing we did was to form a programme committee of people we knew who had professional experience working in distrubuted systems. Although we had experience with the topic, we wanted the programme to be validated by a larger group. There was also the issue of making the event look larger than two blokes who fancied running a conference.

So, we had the topic, we had a formula and we had a programme committee. Next came the scary part.

It’s almost all entirely guesswork

Conferences are expensive to run.

Even if you aim to keep costs down, they’re beyond the level at which a normal person could comfortably cover the costs if things went wrong.

So, you’re taking a personal risk of several thousand pounds based on an instinct that you have a good topic, interesting people will want to speak and that you have the wherewithall to make it all happen.

That leaves a terrifying period where you build something that looks like a conference but without any income. At the very least you need a venue and a date, which means making the following commitment: if someone else enquires about the date you’ve reserved, you have to be ready to pay a sizeable deposit (often 100%) within 24 hours.

So, you reserve a date and hope that you can convince at least one sponsor to support the event before you have to pay for the venue. At that stage you’re selling an idea and yourself: yes, this is a good idea and yes I have both the skills and the contacts to really make this happen.

We were lucky. Within a few minutes of tweeting, we had secured our first sponsor. That only made things more terrifying: now a real company was betting real money on our ability to execute.

We opened the call for papers and spread word of it wherever we could. Our programme committee were great at helping there. Talk submissions trickled in and, within time, we had a good selection. People have interesting things to say and, luckily, most people paid attention to our requirements. Of course, some thinly disguised vendor pitches came our way and we rejected them politely.

This was the first point at which I noticed how much grunt work the conference required. Getting talk submissions required writing a lot of emails hoping to persuade people that Span would be an interesting place for them to speak. If you can’t doggedly persist at repeated tasks, while remaining human and engaging, then you might not want to run a conference.

We ran a voting system where each member of the programme committee would give a +1, neutral or -1 for a talk, along with comments that we hoped would be helpful to rejected submitters.

After a while we had a lot of good talk submissions.

Diversity

We wanted Span to be a conference at which everyone felt comfortable, so we adopted the Ada Initiative’s code of conduct.

It was also important to us that our speakers were a diverse group. After quite a few weeks, we had only one submission from a non-male speaker and that was entirely off-topic for the conference.

Spoiler alert: we didn’t do well with this. I put a lot of effort, worry and time into trying to resolve this. I contacted several groups who were helpful in spreading the word and I directly contacted speakers who had on-topic experience and who would increase the diversity of our programme. For whatever reason, I wasn’t successful in persuading non-male speakers to submit talks.

That’s a matter of disappointment for me and it’s a priority to fix that should Span happen again.

Choosing a ticket price

Honestly, we had no idea how much to charge for tickets.

There were basic costs we couldn’t ignore: catering per head came to around £40. Ticketing and payment provider costs took at least £5 from each ticket.

Sponsorships helped but we had to hit a sizeable number of ticket sales in order to cover fixed costs.

After looking at similarly sized conferences, we came up with:

  • £39 for students (thereby making a loss on each one sold)
  • £149 for the early bird
  • £175 for the standard ticket.

Before the early bird sold out, I panicked a little and changed the standard ticket to £155 as I felt £175 was too high for an unknown conference. I also wanted to make sure as many people could afford to come as possible.

Not everyone paid these prices. We offered discounts to groups of 20% or more and also to certain meet-up groups who helped us with promotion.

We’ve had just one complaint that discounts were made available to certain groups. I think it’s fairly well understood that discounts are made available to groups that help out with promotion and so on.

Now comes the biggest secret of small conference organisers: we gave away some of the tickets for free. Having spoken to other conference organisers, this seems to be common practice for new events. It seems unfair on people who paid, or asked their employer to pay, for their tickets but it’s an inescapable reality of trying out a new conference. Those who paid clearly valued the event at that amount; those who didn’t pay were also able to enjoy it but without going over their budget. Importantly to us, those people helped to make the event a success by giving the speakers and sponsors a larger audience and by adding to the break-time conversations etc.

Ticketing providers

Naturally I looked first at Eventbrite but two things put me off:

  • they hold all the ticket money until after the event
  • their total charge for a £149 ticket would be £9.59 per ticket.

We couldn’t run the conference without having access to at least some of the ticket money before the event and you’re putting a lot of faith in one company’s ability to stay in business. Of course, I didn’t doubt for one minute that Eventbrite would stay around but their holding the money felt wrong and was inconvenient.

Out of a few alternatives, Ti.to seemed like the best choice. Importantly, they had ready-made Stripe integration, meaning we’d get the ticket money one week after each purchase, and their fees were a little more reasonable. The total we paid to Ti.to and Stripe for a £149 ticket was £8.26.

I’m glad we used Ti.to but it is a much more stripped back service than others. There’s no QR code generation, no mobile app to check people in and so on.

If I look at the functionality offered by ticketing services and compare it with other SaaS things I pay for, I’m not convinced that ticketing services have yet found a pricing model that offers good value for money.

The day itself

After a last minute pub meet-up for attendees the night before, the day of Span was long, hard work and fun.

114 people showed up out of 135 registrations. We ran the whole thing with me, Phil and my mate Neil as Span crew, plus four people from the venue and Tony Whitmore taking stills and Max Arnold filming.

The venue, Shoreditch Village Hall, was great. Just the right size and they’re well practised in running tech events. The food and coffee were particularly excellent. If you’re considering running a tech conference in London, speak to them.

I was particularly concerned that the speakers should have a good experience of the conference and I believe they did. Each of them has said that they enjoyed it.

The programme was too long, howewever. In an effort to provide great value for the ticket price, and because we struggled to say no to good talk submissions, we squeezed eleven talks into a ten hour day.

What I’d do differently next time

I’ve not yet thought in detail about what I’d do differently next time but I have some ideas. I’m sure Phil has some thoughts, too.

Off the top of my head:

  • Next time, we must have a more diverse set of speakers.
  • I’d make the early bird a few quid cheaper to make it more compelling to buy early and to make the event more accessible to all.
  • Fewer talks, longer breaks.
  • An official after-party, but we had an impromptu thing this time and it worked out well.

Overall, Span was six months of late nights, lots of emailing, some sleepless nights worrying about money, a sense of growing excitement as things started working out and an amazing day that almost all feedback says was a great first attempt!

Thanks to everyone who sponsored, to Couchbase for being cool with it, to all of the speakers, to everyone who helped out and, of course, to everyone who came. I’m overwhelmed by how positive the feedback has been and excited that all that work seems to have paid off.

There’s more I could’ve covered in this post but it’s long enough already. Maybe Span’ll happen again next year but, for now, I’m off to do something else with those few moments of spare time.


RequestExpired while using Ruby Fog with AWS

Posted on 21 Mar 2014 by Matthew Revell

If you get a RequestExpired => Request has expired error from the Fog library in Ruby, check that your system time is correct. It likely means that your clock is out of sync with AWS.


Introducing the Couchbase Ruby client

Posted on 08 Feb 2014 by Matthew Revell

Playing with Couchbase is easy.

For those first few steps, it’s all about simple CRUD operations on JSON documents: you’re putting JSON in, pulling it out again, making changes and deleting when you need to.

I’m going to write a short series of posts introducing the Couchbase Ruby client. In it, I’ll step through building a small app to keep track of Couchbase swag.

In this post, let’s get acquainted with Couchbase Server and the Ruby client.

Installing Couchbase and the Ruby client

If you haven’t already, get ahold of either the Community or Enterprise edition of Couchbase Server. Installation is straightforward and you can stick with the defaults for now.

For the SDK, we’ll need to install two things. The Ruby SDK is a wrapper around libcouchbase, Couchbase’s C client, so you’ll need to get that first.

Once you have that, install the couchbase gem:

$ sudo gem install couchbase	

Connecting to Couchbase Server

Now we can write some code.

First up, let’s pull in the Ruby client and then connect to Couchbase:

require 'couchbase'
	
db = Couchbase.connect(:hostname => "localhost")

That’s pretty self-explanatory: the database connection is loaded into the db object and the server is running locally. There a couple of other options we could’ve specified, but they’ll wait for another post.

Adding our first document

When we start importing the CSV file, it’ll show that each item in our warehouse has a:

  • product code
  • description
  • quantity.

Before we work the CSV, let’s try it manually.

The product code can act as our key: it is unique and reasonably short.

key = "LAPTOPSLEEVE"	

We’ll take the other two and create a hash:

document = {"Description" => "Red Couchbase-branded laptop sleeve", 
"Quantity" => 91}

Now to write it into Couchbase we pass it to the db object:

db.add(key, document)	

Putting it all together we have:

1 require 'couchbase'
2 	
3 db = Couchbase.connect(:hostname => "localhost")
4 	
5 key = "LAPTOPSLEEVE"
6 document = {"Description" => "Red Couchbase-branded laptop sleeve", 
7 "Quantity" => 91}
8 	
9 db.add(key, document)	

So, here’s what our script does:

  • connects to the Couchbase server
  • specifies a key name
  • creates a hash that the client will convert into the body of our JSON document
  • uses the add method to write both key and document into Couchbase.

Viewing your documents in the Couchbase web console

Open up the Couchbase web console to take a look.

In the top navigation, you’ll see Data Buckets. I’ll cover buckets in a later post but you can think of them as roughly equivalent to a database or collection that you might see in other database systems. For now, it’s just somewhere to put our data.

Click that Data Buckets link and you’ll see that Couchbase created a Default bucket for us at install time.

The Data Buckets page in Couchbases web console

Press the Documents button and you’ll see our LAPTOPSLEEVE document.

The default buckets document listing

It worked!

Adding versus setting

To get our laptop sleeve into Couchbase we used the add method.

Let’s try running our little script again. You’ll get an error from Couchbase that the key already exists.

If we want to write a document into Couchbase regardless of whether there’s already one using that key, we’ll need the set method.

Let’s try that instead:

1 require 'couchbase'
2 	
3 db = Couchbase.connect(:hostname => "localhost")
4 	
5 key = "LAPTOPSLEEVE"
6 document = {"Description" => "Black Couchbase-branded laptop sleeve", 
7 "Quantity" => 349}
8 	
9 db.set(key, document)	

The set method silently overwrites any document already using our chosen key.

Refresh the documents view in the web console and you’ll see that we’ve changed the description and quantity for LAPTOPSLEEVE.

Our updated document

Reading and deleting

Reading the document is just as straightforward:

db.get("LAPTOPSLEEVE")

You can probably guess how to delete a document:

db.delete("LAPTOPSLEEVE")

Next time

We’ll tackle importing the CSV in the next post.


Switching to Jekyll

Posted on 05 Jan 2014 by Matthew Revell

Today I switched this site over to Jekyll.

After close to a decade on Wordpress, I was itching for something lighter-weight. In fact, something a bit more like PyBlosxom, which I used before Wordpress.

Specifically, I wanted:

  • generates flat HTML files
  • posts written in Markdown or similar
  • no complicated theming engine
  • something that was easy to extend
  • ideally written in Ruby
  • community momentum.

Choosing a static site generator

I looked at building something using Jekyll, Octopress, Sinatra or Middleman.

Sinatra was fun to play with but required me to run a Ruby application in production.

Octopress is an on-ramp for Jekyll: it gives you some of things you’d expect from a blogging engine, such as RSS feeds and a default theme. However, I was put off by suggestions that it’s harder to upgrade and some of the choices it made for me.

That left Middleman and Jekyll. Honestly, it came down to nothing more than Jekyll appears to have more community momentum. I could see the advantages of using ERB with Middleman but, right now, I didn’t need to do anything I couldn’t with Liquid templates in Jekyll.

Migrating

Migrating was reasonably straightforward. The only thing I wanted help with was converting the blog posts into Markdown.

For that I chose the ExitWP WordPress plugin. That gave me a zip file of my site’s contents, with a fairly good stab at converting the posts into Markdown. It left a few artefacts, including not converting links with targets and some other chunks of HTML mark-up that got left in the text of the post. It also added a permalink to each post’s front matter, which I removed manually as I didn’t want special case permalinks.

What I needed to add

For design/layout I chose Twitter’s Bootstrap. My pal Joel had mentioned it to me a while back. Along with the Slate theme from Bootswatch and some help from LayoutIt I was able to get a pleasing visual design.

For the RSS feed I used Snaptortoise’s templates, via Drew Inglis. I’ve used an .htaccess redirect for existing subscribers and then this meta tag to point to the feed:

<link rel="alternate" type="application/rss+xml" title="Matthew Revell's blog" href="http://www.understated.co.uk/feed/feed.xml">

The sitemap template came from havvg on GitHub, via Chris Dingli.

Comments were a fairly straightforward choice: Disqus. I’m not yet sure how I’ll migrate the history of comments, if at all.

What’s next

What I have now is good enough but I definitely want to fix some layout issues, pretty some things up and make use of the side-bar on blog posts.

I probably won’t implement categories.


Hiring: Technical Evangelist at Basho

Posted on 15 Jan 2013 by Matthew Revell

I’m looking for a passionate, enthusiastic and opinionated person to join the EMEA community team at Basho.

The job title is Technical Evangelist, but it could just as easily have been Developer Advocate or Community Manager.

The person who’ll suit this role knows the open source world inside-out, can quickly grok technical detail and understand use cases and, most importantly, what solutions are a good fit for them.

If this is starting to spark your interest, do the following items describe you?

  • UK-based.
  • Technical, with the ability to read code and some ability to write code.
  • Excited to travel, for one or two days at a time, two or three times a month within Europe and maybe the Middle East and Africa.
  • Confident speaking to people at meet-ups and giving talks at conferences.
  • Autonomous and full of ideas but able to work to a plan and within a team.
  • You understand that marketing is more than being really good at Twitter.

If you’re interested, drop me a mail (mrevell AT basho DOT com) or take a look at our application form.


Copyright 1999-2014 Matthew Revell.