Freelancing Gods 2014

God
24 Mar 2014

MICF 2014 Recommendations

The Melbourne International Comedy Festival is about to kick off this year – and I can’t wait! It truly is the best time to be in Melbourne.

Because I often see more than my fair share of comedy shows, I’m often asked for recommendations… and while it’s hard to be super sure what’s good this year before any performances have happened, I’ve scanned through the program to put together a list of performers I regularly enjoy. In alphabetical order…

  • Bane Trilogy – I was lucky enough to catch all three parts of this in Edinburgh a couple of years ago, and they’re all excellent. Mobster-style storytelling, with all roles performed by one man, Joe Bone. Start with part one (on Tuesday and Friday nights), and if it takes your fancy, see the other two as well.
  • The Boy with Tape on his Face – silent comedy, but it’s a tonne of fun, even if you do get called up on stage as part of the audience participation. I’ll put money on him being big this year in Melbourne.
  • Celia Pacquola – Regularly hilarious, clever, and with a bit of heart too (perhaps my favourite comedy recipe).
  • David O’Doherty – All his shows feel kinda the same – but that’s not a bad thing at all. Music and comedy that’s both charming and funny.
  • Felicity Ward – her show in 2012 was nominated for the Barry Award (best show of the festival), and would have been a deserving winner. Hilarious even while sometimes being extremely personal.
  • Hannah Gadsby – last year’s show was very brave and very funny and I wish I could see it again. I’ve already got tickets to see this year’s show.
  • Justin Hamilton – he’s a stalwart of the Australian comedy scene, and yet I only saw his show for the first time in 2012, and it was a clever mix of laughs and storytelling. Cue much regret for missing him in previous years. Odds of me making that mistake again this year are slim.
  • Michael Workman – his show last year, Ave Loretta, was one of the most wonderful and beautiful shows I’ve ever seen. Don’t expect comedy, even though you will laugh, because the storytelling is the highlight. I was wiping tears of sadness from my eyes at the end of Ave Loretta, for Michael Workman brings both the laughs and the feels.
  • Sammy J & Randy – the description on the site sums them up perfectly: catchy songs with chaotic tomfoolery and outbursts of filth. Rarely clean, often very, very funny.
  • Tegan Higginbotham – Tegan’s recent solo shows been great narrative stand-up shows, and she doesn’t get the attention she deserves. Given she’s not performing in the duo of chaotically hilarious Watson this year, I’ll be making an extra effort to see this show.
  • Tim Key – some people hate his odd, dry style, but I’ve loved his shows (at least, the two I’ve had the great pleasure of catching). His last show involved him having a bath on stage. Not your average comedy, but all the more enjoyable if it does float your boat.
  • Wil Anderson – I think Wil’s stand-up shows are better than anything he’s done on television… last year’s Goodwil was an excellent mix of intelligence and wit.
  • And for bonus points, my good friend Ben Hopper is performing in The Law Revue – this is Ben’s first festival performing, so there’s no past performances to judge by. Ben’s a funny guy though, so I’m expecting a top show!

These are just a dozen shows that I feel super happy with recommending to all and sundry. There are a few hundred that are part of the festival, so you don’t lack for choices (or excuses) – make sure you catch a show or two before it all wraps up on April 20th.

30 Dec 2013

Melbourne Ruby Retrospective for 2013

The Melbourne Ruby community has grown and evolved a fair bit in this past year, and I’m extremely proud of what it has become.

Mind you, I’ve always thought it was pretty special. I first started to attend the meets back when Rails was young and the community in Australia was pretty new, towards the end of 2005. The meets themselves started in January of that year – almost nine years ago! – and have continued regularly since, in many shapes, sizes and venues, under the guiding hands of many wise Rubyists.

Given I’ve been around so long, it’s a little surprising I’d not had a turn convening the meetings on a regular basis (though I’d certainly helped out when other organisers couldn’t be present). After the excellent, recent guidance of Dave Goodlad and Justin French, Mario Visic and Ivan Vanderbyl stepped up – and then Ivan made plans to move to the USA. I was recently inspired by discussions around growing and improving the community at the latest New Zealand Rails Camp, and so I offered to take Ivan’s place. (As it turns out, Ivan’s yet to switch sides of the Pacific Ocean. Soon, though!)

And so, since February, Mario and I have added our own touches to the regular events. Borrowing from both Sydney and Christchurch, we’ve added monthly hack nights – evenings where there’s no presentations, but people of all different experience levels bring along their laptops and get some coding done. If anyone gets stuck, there’s plenty of friendly and experienced developers around to help.

More recently, reInteractive have helped to bring InstallFests from Sydney to Melbourne. They are events to help beginners interested in Ruby and Rails get the tools they need installed on their machines and then go through the process of setting up a basic blog, with mentors on hand to help deal with any teething problems.

For the bulk of Melbourne Ruby community’s life, the meets have been announced through Google groups – first the Melbourne Ruby User Group, then in the broader Ruby or Rails Oceania group. It’d become a little more clear over the past couple of years that this wasn’t obvious to outsiders who were curious about Ruby – which prompted the detailing of meeting schedules on ruby.org.au – but there was still room for improvement. reInteractive’s assistance with the InstallFest events was linked to their support with setting up a group on Meetup.com – and almost overnight we’ve had a significant increase in newcomers.

Now, many of us Rubyists are quite opinionated, and I know some find Meetup inelegant and, well, noisy. I certainly don’t think it’s as good as it could be – but it’s the major player in the space, and it’s the site upon which many people go searching for communities like ours. The Google group does okay when it comes to discussions, but highlighting upcoming events (especially if you’re not a regular) is not its forte at all.

We’ve not abandoned the Google group, but now we announce events through both tools – and the change has been so dramatic that, as much as I’m wary of supporting big players in any space, I’d argue that you’d be stupid not to use Meetup. We’ve had so many new faces come along to our events – and while we still have a long way to go for equal gender representation (it’s still predominantly white males), it’s slowly improving.

With the new faces appearing, we held a Newbie Night as one of our presentation evenings (something that’s happened a couple of times before, but certainly not frequently enough). Mario and I were lucky enough to have Jeremy Tennant step up to run this and corral several speakers to provide short, introductory presentations on a variety of topics. (Perhaps this should become a yearly event!)

We’re also blessed to have an excellent array of sponsors – Envato, Inspire9, Zendesk, reInteractive and Lookahead Search have all provided a mixture of money, space and experienced minds. We wouldn’t be where we are now without you, your support is appreciated immensely.

Mario and I have also spent some time thinking a bit deeper about some of the longstanding issues with tech events, and tried to push things in a healthier direction:

At many of the last handful of meetings for this year, instead of pizza, we’ve had finger food from the ASRC Catering service, tacos from The Taco Guy, and a few pancakes as well. In each case we’ve ensured there’s vegetarian, gluten-free and lactose-free options. This trend shall certainly continue!

The drinks fridge at Inspire9 (our wonderful hosts for the past couple of years) now have plenty of soft drinks and sparkling mineral water alongside the alcoholic options – and we’ve been pretty good at making sure jugs of tap water are available too. There’s also tea and coffee, though we need to be better at highlighting this.

We’ve also adopted Ruby Australia’s Code of Conduct for all Melbourne Ruby events. This is to both recognise that our community provides value and opportunity to many, and to make it clear we want it to continue to be a safe and welcoming place, offline and online.

We’re by no means perfect, and I’m keen to help this community grow stronger and smarter over the coming year – but we’ve got some great foundations to build on. The Melbourne Ruby community – and indeed, the broader Australian Ruby community – is growing from strength to strength, and a lot of that is due to the vast array of leaders we have, whose shoulders we are standing on.

Alongside the regular city meets, there are Rails Camps twice a year, RailsGirls events becoming a regular appearance on the calendar, and the second RubyConf Australia is in Sydney this coming February. I’m looking forward to seeing what 2014 brings – thanks to all who’ve been part of the ride thus far!

22 Jul 2013

Rewriting Thinking Sphinx: Introducing Realtime Indices

The one other feature in the rewrite of Thinking Sphinx that I wanted to highlight should most certainly be considered in beta, but it’s gradually getting to the point where it can be used reliably: real-time indices.

Real-time indices are built into Sphinx, and are indices that can be dynamically updated on the fly – and are not backed by a database sources. They do have a defined structure with fields and attributes (so they’re not a NoSQL key/value store), but they remove the need for delta indices, because each record in a real-time index can be updated directly. You also get the benefit, within Thinking Sphinx, to refer to Ruby methods instead of tables and columns.

The recent 3.0.4 release of Thinking Sphinx provides support for this, but the workflow’s a little different from the SQL-backed indices:

Define your indices

Presuming a Product model defined just so:

class Product < ActiveRecord::Base
  has_many :categorisations
  has_many :categories, :through => :categorisations
end

You can put together an index like this:

ThinkingSphinx::Index.define :product, :with => :real_time do
  indexes name

  has category_ids, :type => :integer, :multi => true
end

You can see here that it’s very similar to a SQL-backed index, but we’re referring to Ruby methods (such as category_ids, perhaps auto-generated by associations), and we’re specifying the attribute type explicitly – as we can’t be sure what a method returns.

Add Callbacks

Every time a record is updated in your database, you want those changes to be reflected in Sphinx as well. Sometimes you may want associated models to prompt a change – hence, these callbacks aren’t added automatically.

In our example above, we’d want after_save callbacks in our Product model (of course) and also our Categorisation model – as that will impact a product’s category_ids value.

# within product.rb
after_save ThinkingSphinx::RealTime.callback_for(:product)

# within categorisation.rb
after_save ThinkingSphinx::RealTime.callback_for(:product, [:product])

The first argument is the reference to the indices involved – matching the first argument when you define your index. The second argument in the Categorisation example is the method chain required to get to the objects involved in the index.

Generate the configuration

rake ts:configure

We’ve no need for the old ts:index task as that’s preloading index data via the database.

Start Sphinx

rake ts:start

All of our interactions with Sphinx are through the daemon – and so, Sphinx must be running before we can add records into the indices.

Populate the initial data

rake ts:generate

This will go through each index, load each record for the appropriate model and insert (or update, if it exists) the data for that into the real-time indices. If you’ve got a tonne of records or complex index definitions, then this could take a while.

Everything at once

rake ts:regenerate

The regenerate task will stop Sphinx (if it’s running), clear out all Sphinx index files, generate the configuration file again, start Sphinx, and then repopulate all the data.

Essentially, this is the rake task you want to call when you’ve changed the structure of your Sphinx indices.

Handle with care

Once you have everything in place, then searching will work, and as your models are updated, your indices will be too. In theory, it should be pretty smooth sailing indeed!

Of course, there could be glitches, and so if you spot inconsistencies between your database and Sphinx, consider where you may be making changes to your database without firing the after_save callback. You can run the ts:generate task at any point to update your Sphinx dataset.

I don’t yet have Flying Sphinx providing full support for real-time indices – it should work fine, but there’s not yet any automated backup (whereas SQL-backed indices are backed up every time you process the index files). This means if a server fails it’d be up to you to restore your index files. It’s on my list of things to do!

What’s next?

I’m keen to provide hooks to allow the callbacks to fire off background jobs instead of having that Sphinx update part of the main process – though it’s certainly not as bad as the default delta approach (you’re not shelling out to another process, and you’re only updating a single record).

I’m starting to play with this in my own apps, and am keen to see it used in production. It is a different way of using Sphinx, but it’s certainly one worth considering. If you give it a spin, let me know how you go!

11 Jul 2013

Gutentag: Simple Rails Tagging

The last thing the Rails ecosystem needs is another tagging gem. But I went and built one anyway… it’s called Gutentag, and perhaps worth it for the name alone (something I get an inordinate amount of happiness from).

My reasons for building Gutentag are as follows:

A tutorial example

I ran a workshop at RailsConf earlier this year (as a pair to this talk), and wanted a simple example that people could work through to have the experience of building a gem. Almost every Rails app seems to need tags, so I felt this was a great starting point – and a great way to show off how simple it is to write and publish a gem.

You can work through the tutorial yourself if you like – though keep in mind the focus is more on the process of building a gem rather than the implementation of this gem in particular.

A cleaner code example

Many gems aren’t good object-oriented citizens – and this includes most of the ones I’ve written. They’re built with long, complex classes and modules, are structured in ways that Demeter does not like, and aren’t particularly easy to extend cleanly.

I have the beginnings of a talk on how to structure gems (especially those that work with Rails) sensibly – but I’ve not yet had the opportunity to present this at any conferences.

One point that will definitely feature if I ever do get that opportunity: more and more, I like to avoid including modules into ActiveRecord and other parts of Rails – and if you peruse the source you’ll see I’m only adding the absolute minimum to ActiveRecord::Base, plus I’ve pulled out the logic around the tag names collection and resulting persistence into a separate, simple class.

I got a nice little buzz when I had Code Climate scan the source and give it an A rating without me needing to change anything.

Test-driven design

I started with tests, and wrote them in a way that made it clear how I expected the gem to behave – and then wrote the implementation to match. If you’re particularly keen, you can scan through each commit to see how the gem has evolved – I tried to keep them small and focused.

Or, just have a read through of the acceptance test files – there’s only two, so it won’t take you long.

So?

There are a large number of other tagging gems out there – and if you’re using one of those already, there’s no incentive at all to switch. I’ve used acts-as-taggable-on many times without complaints.

But Gutentag certainly works – the README outlines how you can use it – and at least people might smile every time they add it to a Gemfile. But at the end of the day, if it’s just used as an example of a simple gem done well, I’ll consider this a job well done.

09 Jul 2013

Rewriting Thinking Sphinx: Middleware, Glazes and Panes

Time to discuss more changes to Thinking Sphinx with the v3 releases – this time, the much improved extensibility.

There have been a huge number of contributors to Thinking Sphinx over the years, and each of their commits are greatly appreciated. Sometimes, though, the pull requests that come in cover extreme edge cases, or features that are perhaps only useful to the committer. But running your own hacked version of Thinking Sphinx is not cool, and then you’ve got to keep an especially close eye on new commits, and merge them in manually, and… blergh.

So instead, we now have middleware, glazes and panes.

Middleware

The middleware pattern is pretty well-established in the Ruby community, thanks to Rack – but it’s started to crop up in other libraries too (such as Mike Perham’s excellent Sidekiq).

In Thinking Sphinx, middleware classes are used to process search requests. The default set of middleware are as follows:

  • ThinkingSphinx::Middlewares::StaleIdFilter adding an attribute filter to hide search results that are known to not match any ActiveRecord objects.
  • ThinkingSphinx::Middlewares::SphinxQL generates the SphinxQL query to send to Sphinx.
  • ThinkingSphinx::Middlewares::Geographer modifies the SphinxQL query with geographic co-ordinates if they’re provided via the :geo option.
  • ThinkingSphinx::Middlewares::Inquirer sends the constructed SphinxQL query through to Sphinx itself.
  • ThinkingSphinx::Middlewares::UTF8 ensures all string values returned by Sphinx are encoded as UTF-8.
  • ThinkingSphinx::Middlewares::ActiveRecordTranslator translates Sphinx results into their corresponding ActiveRecord objects.
  • ThinkingSphinx::Middlewares::StaleIdChecker notes any Sphinx results that don’t have corresponding ActiveRecord objects, and retries the search if they exist.
  • ThinkingSphinx::Middlewares::Glazier wraps each search result in a glaze if there’s any panes set for the search (read below for an explanation on this).

Each middleware does its thing, and then passes control through to the next one in the chain. If you want to create your own middleware, your class must respond to two instance methods: initialize(app) and call(contexts).

If you subclass from ThinkingSphinx::Middlewares::Middleware you’ll get the first for free. contexts is an array of search context objects, which provide access to each search object along with the raw search results and other pieces of information to note between middleware objects. Middleware are written to handle multiple search requests, hence why contexts is an array.

If you’re looking for inspiration on how to write your own middleware, have a look through the source – and here’s an extra example I put together when considering approaches to multi-tenancy.

Glazes and Panes

Sometimes it’s useful to have pieces of metadata associated with each search result – and it could be argued the cleanest way to do this is to attach methods directly to each ActiveRecord instance that’s returned by the search.

But inserting methods on objects on the fly is, let’s face it, pretty damn ugly. But that’s precisely what older versions of Thinking Sphinx do. I’ve never liked it, but I’d never spent the time to restructure things to work around that… until now.

There are now a few panes available to provide these helper methods:

  • ThinkingSphinx::Panes::AttributesPane provides a method called sphinx_attributes which is a hash of the raw Sphinx attribute values. This is useful when your Sphinx attributes hold complex values that you don’t want to re-calcuate.
  • ThinkingSphinx::Panes::DistancePane provides the identical distance and geodist methods returning the calculated distance between lat/lng geographical points (and is added automatically if the :geo option is present).
  • ThinkingSphinx::Panes::ExcerptsPane provides access to an excerpts method which you can then chain any call to a method on the search result – and get an excerpted value returned.
  • ThinkingSphinx::Panes::WeightPane provides the weight method, returning Sphinx’s calculated relevance score.

None of these panes are loaded by default – and so the search results you’ll get are the actual ActiveRecord objects. You can add specific panes like so:

# For every search
ThinkingSphinx::Configuration::Defaults::PANES << ThinkingSphinx::Panes::WeightPane

# Or for specific searches:
search = ThinkingSphinx.search('pancakes')
search.context[:panes] << ThinkingSphinx::Panes::WeightPane

When you do add at least pane into the mix, though, the search result gets wrapped in a glaze object. These glaze objects direct any methods called upon themselves with the following logic:

  • If the search result responds to the given method, send it to that search result.
  • Else if any pane responds to the given method, send it to the pane.
  • Otherwise, send it to the search result anyway.

This means that your ActiveRecord instances take priority – so pane methods don’t overwrite your own code. It also allows for method_missing metaprogramming in your models (and ActiveRecord itself) – but otherwise, you can get access to the useful metadata Sphinx can provide, without monkeypatching objects on the fly.

If you’re writing your own panes, the only requirement is that the initializer must accept three arguments: the search context, the underlying search result object, and a hash of the raw values from Sphinx. Again, the source code for the panes is not overly complex – so have a read through that for inspiration.

I’m always keen to hear about any middleware or panes other people write – so please, if you do make use of either of these approaches, let me know!

24 Jun 2013

Rewriting Thinking Sphinx: Loading Only When Necessary

I’ve obviously been neglecting this blog – even a complete rewrite of Thinking Sphinx hasn’t garnered a mention yet! Time to remedy this…

There’s plenty to focus on with Thinking Sphinx v3 (released just under six months ago), because a ton has changed – but that’s pretty well covered in the documentation. I’m going to cover one thing per post instead.

First up: index definitions are now located in their own files, located in the app/indices directory. Given they can get quite complex, I think they’re warranted to have their own files – and besides, let’s keep our concerns separate, instead of stuffing everything into the models (yes, I’m a firm proponent of skinny everything, not just skinny controllers).

So, instead of this within your model:

class User < ActiveRecord::Base
  # ...

  define_index do
    indexes first_name, last_name, country
  end

  # ...
end

You now create a file called user_index.rb (or whatever, really, as long it ends with .rb) and place it in app/indices:

ThinkingSphinx::Index.define :user, :with => :active_record do
  indexes first_name, last_name, country
end

You’ll note the model is now specified with a symbol, and we’re providing an index type via the :with option. At the moment, the latter is always :active_record unless you’re using Sphinx’s real-time indices (which are definitely beta-status in Thinking Sphinx). The model name as a symbol, however, represents one of the biggest gains from this shift.

In previous versions of Thinking Sphinx, to discover all of the index definitions that existed within your app, the gem would load all of your models. Initial versions did this every time your app initialised, though that later changed so they the models and index definitions were loaded only when necessary.

Except, it was necessary if a search was being run, or even just if a model was modified (because updates to Sphinx’s index files could be required) – which is the majority of Rails requests, really. And yes, this information was cached between requests like the rest of Rails, except – like the rest of Rails – in your development environment.

Loading all your models is quite a speed hit – so this could be pretty painful for applications with a large number of models.

There were further workarounds added (such as the indexed_models option in config/sphinx.yml), but it became clear that this approach was far from ideal. And of course, there’s separation of concerns and skinny models and so on.

This gives some hint as to why we don’t provide the model class itself when defining indexes – because we don’t want to load our models until we absolutely have to, but we do get a reference to them. The index definition logic is provided in a block, which means it’ll only be evaluated when necessary as well.

This doesn’t get around the issue of knowing when changes to model instances occur though, so this got dealt with in two ways. Firstly: delta index settings are now an argument at the top of the index, not within the logic block:

ThinkingSphinx::Index.define(
  :user, :with => :active_record, :delta => true
) do
  # ...
end

And attribute updating is no longer part of the default set of features.

This means Thinking Sphinx can now know whether deltas are involved before evaluating the index definition logic block – and thus, the callbacks are lighter and smarter.

The end result is thus:

  • Thinking Sphinx only loads the index definitions when they’re needed;
  • They, in turn, only load the models and definition logic when required;
  • Each index now gets its own file;
  • Your models stay cleaner; and
  • Request times are faster.

Overall, a vast improvement.

16 Jun 2013

Pat's Guide to Running Events

I’m lucky enough to attend quite a few conferences (mostly IT-focused), plus I’ve organised a handful as well (Trampoline and the occasional Rails Camp)… so it could be argued that I know a few things in this area. More accurately, it means I can get quite opinionated on the matter, which was quite clear this evening with a few ranting tweets.

Some friends (rightly) encouraged me to write something down in a longer form, so here we have my recommendations for running events generally, but with a focus on conferences.

Before I get stuck into my thoughts, I want to be clear: organising events is a tonne of hard work, is often thankless, and almost never financially rewarding. I have many friends who run events of all sizes, and this post is by no means an attack on them or other organisers of events I’ve attended. It requires no small amount of bravery and risk to put something together.

Single Track

I’m a big fan of single-track conferences – keep everyone together and focused on the same talks. This does reduce the number of speakers (and thus, ideas being shared on the big stage), but generally it leads to a better set of talks, as you’re selecting the absolute best available.

That said, this is not a deal-breaker – multi-track conferences can certainly work well, especially when the tracks have clear themes.

A tangent for those who are keen to give great talks, technical or otherwise: watch Ben Orenstein’s excellent RailsConf talk – and then watch it again when you’re starting to prepare for your next talk.

30 Minutes or Less

I’m pretty sure no talk needs more than 30 minutes. Keynotes are perhaps the one exception – but hey, if you’ve gone with a single track, there’s no keynotes – and I like the idea of all speakers being equal. And to keep the sessions focused, perhaps have a no-questions rule. Encourage attendees to chat to the speakers one-on-one instead.

Emphasise the Socialising

Don’t forget to add plenty of socialising time in-between talks. I know plenty of people attend events not for the talks but to meet people, to connect with their peers – so do what you can to encourage these opportunities. The excellent Nordic Ruby has a rule that there must be at least 30 minutes break between each session.

Curate Lightning Talks

Lightning talks can be a mixed bag – sometimes they’re great: I remember the final lightning talk at the third Trampoline Melbourne, where a high school business teacher taught us all how to beatbox Billy Jean; sometimes they’re awful: product pitches and advertising bullshit that can mar an otherwise excellent event.

These days I probably err towards having no lightning talks, but I’ve seen it done well and curated carefully, and perhaps that’s the best way to approach it. Anyone can put their hand up, but have someone whose job it is to pick a handful that stand out. The RubyConf Australia lightning talks were top notch, and I largely attribute this to the curation.

No Sponsor Talks

Whatever you do, don’t give away speaker slots to sponsors – every speaker should earn their spot on their own merits. Perhaps you can allow sponsors to recommend some speakers (if you handpick some of your talks), and then they can fork out extra to cover that person’s travel expenses, provided you think they should be part of your lineup.

Be Mindful and Seek Equality

It’s well documented that the technology industry is dominated by men, and that there are plenty of situations where women have been treated terribly. Having a clear anti-harrassment policy is a wise idea, as is making the extra effort to seek out women speakers and attendees (something the JSConf EU team do a stellar job at).

We certainly keep an eye on the male-to-female speaker ratio at Trampoline, and have encouraged women in particular to put their hand up to speak – though we also encourage plenty of men too. The later events have certainly been more balanced than earlier ones.

Parties

Most conference parties suck.

I wish it wasn’t the case, but so often, they’ll be held in some crowded bar with loud music. Whether the music’s good or not is beside the point – I don’t go to conferences for the music, I go to socialise. If I need to yell to have a conversation, the odds of me going home rise dramatically. There’s many in the technology industry who aren’t super adept at being social, and these kinds of environments just make it even harder to connect with other people.

The wise Ashe Dryden raised this point recently, and many chimed in with clear support for parties where there’s more of a focus on conversations.

Also: go easy with the alcohol. I attended one Ruby conference recently where there were trays of shots lined up at the official parties (yes, at loud bars) – a particular shame given the rest of the conference experience was excellent.

I know Rails Camp has garned a reputation in Australia of being quite a drunken affair. I think this is a little unfair – yes, sadly some people do get plastered, but the vast majority are pretty smart with their alcohol intake. Perhaps my issue’s more with the wider drinking culture than with the events/conferences scene.

Somewhat related: I love that Travis CI host meets at cafes instead of bars, running up a coffee tab (and I don’t even drink coffee!).

Start Later

I had the pleasure of hearing Alex Koppel speak at Railsberry earlier this year on the topic of sleep – something pretty critical for everyone, and yet often forgotten, especially when it comes to conference schedules.

There’s sessions all day, then dinners and parties all night – and then you get up bright and early the next day to do it all again. Don’t get me wrong, I don’t want conference organisers to become strict parents, but if you have an official party going past midnight, and then talks starting around 9am in the morning, that might leave just enough time for the recommended 8 hours of sleep. And that’s provided you’re not far away from either the conference or party venues, and the conference is providing you a tasty breakfast.

I’d much rather kick things off in the late morning, let people enjoy their evenings, get a proper rest, take it easy in the mornings, and be awake and focused for all the sessions. Indeed, the next event I run (don’t ask me what it is, I don’t know yet) will begin with brunch, a meal that Melbourne excels at.

Seriously: Melbourne’s breakfasts are the best in the world.

Superb Food & Drink or Nothing

And when it comes to meals, do try to provide excellent food and drink at your event (for breakfasts, lunches, dinners and snacks). You’ve got a great opportunity to keep attendees and speakers all in the same place, all socialising and sharing ideas – but if the food’s bad, people will wander off searching for other options. Of course, this will happen to some extent anyway, but good food is noticed and welcomed.

Good coffee too – there’s always a big cheer for the baristas when conference organisers are closing events.

If you can’t afford these things, that’s okay and completely understandable – but instead of providing limited or average options, give people lists of excellent cafes and restaurants nearby. Or perhaps line up a sponsor whose funds will be directed towards food and drink – and be sure to mention this before meals as well.

We generally haven’t bothered with meals at Trampolines – but at the most recent Sydney event, Caroline and Steve organised simple yet excellent catering, and everyone stuck around, had a great meal and could continue conversations without being caught up in the logistics of finding their own food.

Superb Wifi or Nothing

Good conference internet is hard. I can count the events I’ve been to with close-to-faultless wifi on one hand. You need to decide whether it’s critical for your event, but again, don’t be half-arsed about it: put the effort in or drop it completely.

If you aren’t going to bother with internet (or even if you are), a lovely touch is to go out of your way to organise data-capable SIMs for foreign attendees – and make sure they can be used for tethering. I’ve seen some conferences provide 3G/4G dongles to speakers – which is great – but making that offer to all attendees (even if you charge for it) would be brilliant.

For those in Australia looking to have first class internet access available at their event, I recommend speaking to Donal (once of NodeCity) at Podomere, who knows his networking devices and IP traffic back to front. (I did help him out at a few events – but I was just the dumb labour putting access points in place, he’s got all the smarts).

Superb Schwag or Nothing

Your schwag is almost certainly shit. We don’t need more pens, stickers, flyers, magazines, canvas bags, key-rings and stress balls. They’ll almost always end up being thrown out and ignored – which means they’re a waste of time, money, and materials – all limited resources! Stupidity on so many levels!

I can think of only one conference I’ve been to that had schwag worth keeping – Paul & Eamo’s Funconf. Though to be fair, that event was special on so many levels, and calling what we were given ‘schwag’ is demeaning.

As for the rest – occasionally there’s useful things in the mix, but the goal should be no schwag at all. Sponsors may request it, but be polite yet firm and point out that they’ll get much better returns putting their money towards your food or coffee. You could also look at giving people the choice to donate money to worthy causes instead of creating mindless rubbish.

T-shirts

Perhaps I’m wrong to treat t-shirts separately to the rest of the schwag… much of the same applies, though my rules are slightly different: if you can put together an excellent design and offer it in both mens and womens sizes, and perhaps make it optional (those who really want it can pay for it), then consider it.

But seriously: if it’s not a design that someone who doesn’t go to the event and has no interest in the focus of the event wouldn’t consider wearing, I’d opt for no t-shirt. Don’t bother with sponsor logos either.

Badges

Again, almost schwag, but not quite, as badges can be extremely useful for the duration of the event – as helpful reminders of peoples’ names, as a reference for conference schedules, and even as proof of entry for parties.

But almost always, they’ll be thrown out once the conference is over. Which wouldn’t be such a big deal, except they’re mostly plastic and cords, neither which ever get re-used.

Again, the talented Paul Campbell wins points here for providing simple badges on cardboard, with a ribbon to secure it around your neck. Another option is biodegradable plastic badge holders – but keeping things simple is likely the best option.

Over to you

If you disagree with any of this, there’s a comment box below, let me know – or hassle me on Twitter. There’s a decent chance I’ll amend this post over time as more ideas form in my head, but this should provide plenty to consider right now.

RssSubscribe to the RSS feed

Recent Links

Recent Posts

Tag Density

About Freelancing Gods

Freelancing Gods is written by , who works on the web as a web developer in Melbourne, Australia, specialising in Ruby on Rails.

In case you're wondering what the likely content here will be about (besides code), keep in mind that Pat is passionate about the internet, music, politics, comedy, bringing people together, and making a difference. And pancakes.

His ego isn't as bad as you may think. Honest.

Here's more than you ever wanted to know.

Ruby on Rails Projects

Other Sites

Creative Commons Logo All original content on this site is available through a Creative Commons by-nc-sa licence.