Freelancing Gods 2015

God
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.

25 Sep 2012

Funconf

This could be a story about a mystery. Or it could be an adventure. Or even a tale of learning and sharing. But ultimately, it really comes down to friendship and trust.

Gaelic Badges

Ah, but where to start? Well, if we look back several years, it starts with my good friend James Healy, introducing me to a programming language called Ruby. That led me to the Australian Ruby community and the very first Rails Camp just outside Sydney, where I met Matt Allen. A year later, Matt Allen introduced me to Geoffrey Grosenbach at RailsConf in Portland, Oregon. A few months later, I found myself in Berlin, where through Geoffrey I met Paul Campbell of Dublin.

And then I met Paul again in Las Vegas, London, Amsterdam, Margate (for another Rails Camp), Berlin, and then finally in his home city of Dublin last year. I now consider myself lucky to call Paul a good friend, and have also had the pleasure of occasionally working with him.

Paul is a man with grand ideas, and one of those is an event he and fellow Dubliner Eamon Leonard concocted called Funconf. Every year as Paul put it together, I would consider travelling around the world to attend, but it just didn’t work out. This year, though, Paul told me the third Funconf would also be last – and so I became determined to be there for it. There were other events in in the same corner of the world I have been keen to see as well, thus it became something of a tour – four months travelling around Europe. Let’s be clear: from the beginning, Funconf was always one of the main reasons for the trip.

But what was I travelling over to be a part of? I knew that it was a conference – well, kind of: there would be some talks, close enough. And it’s a tech crowd that attends, so it’s work related at a stretch. But beyond that, Paul & Eamo weren’t talking.

When tickets were finally released, the website, gorgeous though it was, didn’t shed any light. All it asked was one question: “Do you trust us?”

My answer was always going to be yes.

Even after handing over a not inconsiderable amount of Euros to secure my place, few answers were forthcoming. Food and beds would be covered, but there was no clues as to where those beds would be, let alone what food we would be eating.

So I waited patiently, and began upon my travels. I attended conferences, I wandered through beautiful European cities, and I caught up with many friends along the way.

And finally, I arrived in Dublin at the end of August, still clueless as to what was to come. I wasn’t alone though – about a hundred others had come from across the globe. Most had been to previous editions of Funconf, but they were no more enlightened than I.

We met on Friday morning at a hotel in Dublin – some of us sporting a bit more facial hair than normal, after some tweets from Paul & Eamo – and found ourselves in a situation that felt very conference-like. There was a registration desk, hotel-catered breakfast, and a room with lecture-style seating and a PowerPoint presentation ready to go. This wasn’t what we expected! Werner Vogels, CTO of Amazon, was our morning’s speaker, and the talk was, well, just like any run of the mill conference.

We were being trolled. Or, as we’d say in Australia, Paul & Eamo were taking the piss.

Then, things started to get interesting. We grabbed our bags and were herded onto three big, black limousine party buses (a reference to Funconf 1) and with three shiny Deloreans (a reference to Funconf 2), we were escorted by local police to Heuston Train Station.

The mode of transport stakes were quickly raised – because we were then asked to board a train booked just for us, with the destination being Galway, on the other side of Ireland.

Next stop: Galway

Of course, this was just one piece of the puzzle – what was to come once we arrived in Galway had yet to be revealed. That didn’t bother us much: we all revelled in the experience of the train trip, catching up with old friends and making new ones.

Buses – though nothing fancy this time – took us from the station to another hotel. Again, it was quickly clear that this wasn’t out main destination either as we were led into another function room. This time around, there were no PowerPoint slides, for we were the main attraction: an open mic and an invitation to talk for a few minutes on topics of our choosing.

While most got an opportunity to share – in some cases, more than once – others missed out: as the ideas flowed, Paul was taking a token or so people out of the room at regular intervals, and they weren’t returning. Slowly but surely, the numbers thinned until there were fifteen of us left. If I had been keeping an eye on Twitter, I would have known what was happening – but thankfully, I didn’t catch any of the spoilers. The penny dropped when we grabbed our bags and were led through the back streets of Galway to find helicopters waiting.

Helicopters!

Helicopters!

And so, we arrived in grand style at our actual destination, Inis Mór of the Aran Islands (just off the west coast of Ireland).

All this, and it’s just the journey to get us where Funconf was taking place – the support act, if you like. Of course, with Paul & Eamo planning, the journey is as important as every other aspect of the event.

From there, it was a matter of collecting our amazingly crafted badges (thanks Kilian!) and bags (thanks Kilian’s mum!), settling into a bed & breakfast, and then wandering across the island in search of food, drink and friends.

Arriving on Inis Mór marked a change of pace: not only had we reached the event location (if an entire island counts as such), but part of the mystery of Funconf had been revealed. A large question mark still hovered, though: we had no idea what the next day would contain.

But we would have to wait until the morning for that. Friday evening was set aside for dinner and socialising – a fine way indeed to bring to a close such a uniquely wonderful day.

And once Saturday morning arrived, the rest of Funconf was revealed – well, to some extent. We had our venues: the local church, a nearby hall, a pub; and we had a schedule of when to be at each. The specifics of what would happen in each location was only divulged when required.

Those specifics, for the most part, were talks, and very good ones. None were technical, all were interesting, and they were generally stories or ideas. I shan’t recount each at length, as I would not do them justice (and, well, you had to be there), but my two favourites were Michael Lopp and Tom Preston-Werner (known as @rands and @mojombo, respectively). Fittingly, the focus for both was the topic of trust.

But beside the talks? Well, some of us visited the imposing cliff ruins of Dún Aonghasa, some of us got drenched riding bicycles in the rain (and some of us did both), but throughout there was a constant hum of socialising. While the talks were top notch, I can say with some certainty that the main reasons everyone came to Funconf were the people and adventure.

The evening brought with it a clever talk from Derek Sivers, a rocking performance by Kíla, and much partying – but all too soon, it was Sunday morning and time for us to board the ferry back to the mainland. A subdued ferry ride was followed by buses, and then another private train returning us to Dublin in time for the BBQ after-party.

And just like that, Funconf 3 was finished. A grand success indeed, and perhaps it’s for the best that there will not be another one – for I’ve no idea how Paul & Eamo could top that, plus it makes my experience all the more special, shared with such a superb group of fellow adventurers.

Paul, Eamon: thank you ever so much. I have no regrets for putting my trust in both of you, for it was a brilliantly crafted weekend.

16 Jun 2012

Supporting Smart Social Enterprises in Cambodia

About 18 months ago, I posted here about a campaign some friends of mine ran to kick-start some social enterprises in Cambodia through their not-for-profit organisation Kinyei.

These businesses have taken off, and now my friends want to step back and hand them over to their local staff, so they become completely locally owned and run. This push is also in need of some funds though, and so there’s another campaign. The money raised from this will ensure that the necessary training can be given to the staff, so they’re ready to manage the businesses.

There’s only a few days before the fundraising deadline, and much like Kickstarter, if the target is not met, none of the funding gets passed through – and Kinyei haven’t quite got to that target yet. So, if you can chip in, please do!

Kinyei and Friends

I’ve been lucky enough to visit Battambang in Cambodia in the last year, and was able to see the projects in full flight – and it’s quite clear that the local staff have gained a massive amount of knowledge, skills and life experience from being involved. Particularly of note is their cafe baristas, who have become so well regarded that they compete at the country barista championships and train baristas at other cafes and hotels in Cambodia.

So if you can send some money their way, I know it’ll go to a great cause and make a clear difference. Just head on over to their campaign page to donate.

Seyla, Me and Chouert at Kinyei

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.

Open Source Projects

Other Sites

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