A small toy to explore geohashes

Posted 4 months back at Tom Ward

<article> <header>

A small toy to explore geohashes

</header>

For an app I’ve been building, I’ve been looking into geohashes. For those who don’t know, the geohash format is a simple way to encode latitude and longitude into a single string. As an example, Nelson’s Column in London (51.507794, -0.127952) has the geohash gcpvj0dyds.

Geohashes have a couple of interesting features. First, as you remove characters, you lose precision. gcpvj0dyds fairly accurately points to Nelson’s Column; gcpvj0d represents the South-West of Trafalgar Square and some of the Mall; and gcpvj covers most of Central London, as well as Islington and King’s Cross. A geohash doesn’t really represent a point, but rather a bounding area within which a point may lie. The longer the geohash, the smaller that bounding area.

The other interesting property geohashes have is that nearby locations usually (but not always) share similar prefixes. So much of North London is in gcpv, while much of South London is in gcpu. However, due to the Prime Meridian passing through Greenwhich, South East London has the geohash u10h – wildly different than the other two.

This probably sounds a bit complicated. I was having trouble getting my head around the concept, so to try and get to grips with geohashes I’ve written a toy app that draws them on a map. To try it out, go to http://geohash.gofreerange.com, click the map, zoom and play. If you find it useful, let me know.

Update: This code is now available [on github](https://github.com/tomafro/geohash-explorer).
<footer> 15th September 2011 </footer> </article>

Geohash toy: code released

Posted 4 months back at Tom Ward

<article> <header>

Geohash toy: code released

</header>

A couple of weeks ago I wrote about a small toy app I’d written to explore geohashes. Now I’ve cleaned the code up a little, upgraded it to rails 3.1 and released it here on github. Enjoy.

<footer> 24th September 2011 </footer> </article>

Working inside government

Posted 4 months back at Tom Ward

<article> <header>

Working inside government

</header>

Since September, I and the other Go Free Range guys have been working for the government. We’ve been helping the able and growing Government Digital Service to build whitehall, our code name for the Inside Government section of gov.uk. Yesterday we removed the password and opened our doors to the public.

For those who don’t know, gov.uk is the UK government’s attempt to not only consolidate government websites to a single domain, but also build these sites in the right way. That means public, open source, continual delivery and more.

While the first part of gov.uk focussed on helping citizens, Inside Government is about the business of government. What policies the government has, how it’s implementing them, not to mention the news and speeches, publications, consultations and other things the government does each day.

It’s only the first release of many, a small glimpse into what will one day be. How it ends up will be shaped by feedback from the people who use it.

<footer> 29th February 2012 </footer> </article>

Tip: Bundler with --binstubs

Posted 4 months back at Tom Ward

<article> <header>

Tip: Bundler with --binstubs

</header>

In a previous blog, I wrote how I’d aliased commands such as rake, cap and rspec to run either with or without bundle exec, based on the presence of a Gemfile. I gave up on that a while ago. Instead, I’ve started installing all my bundles like this:

bundle install --path .bundle/gems --binstubs .bundle/bin

I often use features like bundle open <gem> to debug and edit failing gems, so I like to keep each application’s gems isolated. The --path .bundle/gems installs them within an application’s .bundle directory. As well as isolating my gems, it has the added benefit that I can blow away the gemset with rm -rf .bundle

The --binstubs .bundle/bin option installs bundle-aware scripts for each command provided by a bundled gem. For example, a bundle including rake will generate a .bundle/bin/rake script. By adding ./.bundle/bin to the front of my environment PATH, the bundled version of rake will run when I’m in the application folder. I never have to type bundle exec!

Obviously typing that long bundle install command each time is tedious, so I’ve aliased it to bi:

alias bi='bundle install --path .bundle/gems --binstubs .bundle/bin'

I’ve been using these options for a few months, and so far I’m very happy with them.

<footer> 21st June 2012 </footer> </article>

Past, Present and Future

Posted 4 months back at Tom Ward

<article> <header>

Past, Present and Future

</header>

For me and the rest of Go Free Range, the big event this week was the public launch of Inside Government, the government focussed part of GOV.UK. Inside Government aims to replace the majority of government department and agency websites with a single place for all news, policies, publications and consultations. On Wednesday, the first two department websites (for the Department for Transport and the Department for Communities and Local Government) were moved across.

We’ve been working on this project for 14 months, from the initial commit, through the beta launch right up until today. I’ve enjoyed it, but it has been extremely hard work. And although there are hundreds of things I’d still like to change, there are hundreds more I’m proud of.

Harmonia

As well as Inside Government, we’ve also been slowly inviting people to Harmonia, our ‘virtual office manager’. In case you haven’t read the Go Free Range blog, Harmonia is a tool we use to assign all the tasks needed to keep our company running. Rather than use a schedule, each piece of work is assigned in a way designed to be both random and fair.

One variation or another of Harmonia has been helping us for well over a year, but now we’ve built a web app for everyone to use. It’s still a bit rough around the edges, but we’d love it if people signed up and gave us feedback. We’re building this because we want to learn how to build better products, for the future of Go Free Range.

<footer> 16th November 2012 </footer> </article>

Deploying a rails app from scratch using recap

Posted 4 months back at Tom Ward

<article> <header>

Deploying a rails app from scratch using recap

</header>

If you follow our company blog you’ll know that we’re working on Harmonia, our virtual office manager. I thought I’d explain how we use recap to deploy harmonia, to show how easy and fast recap makes application deployment.

Harmonia is a fairly standard rails application. As well as a web front-end, it has two other processes. A queue worker is used to send outgoing emails, whilst the core of the application is the ticker; a process which ‘ticks’ every minute, assigning tasks to team members. We use foreman to declare these processes in the following Procfile:

web: bundle exec unicorn -p $PORT -c unicorn.conf.rb
ticker: bundle exec rails runner script/ticker.rb
worker: bundle exec rake environment resque:work QUEUE=assignments VVERBOSE=1

All of these processes touch application code, so whenever we deploy a new version of the app (which we do frequently) they need to be restarted. Our app also has a database with associated migrations, uses environment variables like DATABASE_URL for configuration, and has a number of gem dependencies managed by bundler.

This is all handled by recap.

Getting started – adding recap to the project

Using recap with a rails project is simple. First add gem 'recap' to the Gemfile and run bundle install. Next run bundle exec recap setup, which will generate a Capfile, guessing values for the git repository and app name. You should check these values and change the server to point to your app server. As an example, the complete Capfile for harmonia is shown below:

require 'recap/recipes/rails'

set :application, 'harmonia'
set :repository, 'git@github.com:freerange/harmonia.git'

server 'bison.harmonia.io', :app

Applications deployed with recap need their own user, owning all files and processes. Assuming we can ssh into our server and are listed as a sudoer, we can create this user automatically running cap bootstrap. This will also add our own ssh user to the application group, allowing it to deploy the application.

Next we can set any environment variables we need for configuration. These are loaded in the application user’s .profile, so are available to all processes started by recap. In harmonia we set our smtp credentials, the server port, some api keys and more, using commands like cap env:set PORT=7000 and cap env:set SMTP_PASSWORD=secret.

The app is now almost ready to deploy. We can prepare it for deployment with cap deploy:setup, which clones the code repository, installs our gem bundle, sets up the database and precompiles our assets.

Finally, running cap deploy will start the app for the first time, launching each process defined in the Procfile with the environment variables we previously set.

Really fast deployments

While recap makes it very easy to get apps up and running the first time, it comes into its doing subsequent deployments. At Go Free Range we like to deploy apps we’re working on very frequently. One thing that helps ensure we do this is making each deployment as fast as it can be.

Using git as recap does is already a very quick way to get code changes onto servers, but recap takes things a step further. By testing to see which files have changed it knows which tasks can be skipped. For example, database migrations won’t be run if db/schema.rb has not changed; the gem bundle won’t be re-installed unless Gemfile.lock has been updated, and foreman process scripts won’t be exported if the Procfile is unchanged. In fact, if these files don’t exist, these tasks will never run at all.

The future

Using recap with Harmonia has made our deployment process very fast and simple. When the main harmonia server became over-burdened and we decided to commission a new machine dedicated to harmonia, recap made that process quick and painless. As well as harmonia, recap is also used to deploy the Go Free Range website, this blog, and a number of other small sites and projects where it has proven itself well. For larger projects, there are some features (such as more control as to what processes run where) that are missing, but I plan to add these in the next release. For all other sites, recap has proven itself a lightweight and capable alternative to the standard Capistrano deployment recipes.

<footer> 27th December 2012 </footer> </article>

Infinite sequences in ruby

Posted 4 months back at Tom Ward

<article> <header>

Infinite sequences in ruby

</header>

One feature of harmonia is tasks that recur on a schedule, e.g. every Thursday, or on the 30th day of each month. For these tasks we need to know not just when they’ll next occur, but also things like the next 4 occurrences, or all occurrences this month.

To do this we’ve used a technique more common in clojure: using an infinite sequence.

Defining simple infinite sequences

Ruby 1.9 and above let us define infinite sequences using the Enumerator class. A simple example is the sequence of integers:

integers = Enumerator.new do |yielder|
  n = 0
  loop do
    yielder.yield n
    n = n + 1
  end
end

>> integers.take(5)
=> [0, 1, 2, 3, 4]
>> integers.take(10)
=> [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

Here’s how this works. The block passed to Enumerator.new defines our sequence. It takes a yielder argument with a special method #yield, used to return elements in the sequence. Whenever #yield is called, execution of the block stops. Execution only restarts if more elements are needed, making the sequence lazy. The Enumerator class handles this stopping and starting execution — we only need to worry about how to generate each element.

Most of the code above is concerned with looping and yielding values, not generating them. We can factor this out, giving us a method that makes it trivial to define new sequences:

def sequence(&generator)
  Enumerator.new do |yielder|
    n = 0
    loop do
      yielder.yield generator.call(n)
      n = n + 1
    end
  end
end

>> integers = sequence {|n| n}
>> integers.take(10)
=> [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

>> squares = sequence {|n| n * n}
>> squares.take(10)
=> [0, 1, 4, 9, 16, 25, 36, 49, 64, 81]

When using infinite sequences laziness is extremely important, as it’s impossible to generate all members of an infinite list in anything less than infinite time. A sequence that outputs whenever a new value is calculated shows this laziness in action:

integers = sequence {|n| puts "Calculating result #{n}"; n}

>> integers.take(3)
Calculating result 0
Calculating result 1
Calculating result 2
=> [1, 2, 3]

Now we can define sequences, how can we use them? We’ve already seen that we can #take any number of elements from our sequence. We can also use #take_while to take elements until a condition is met, such as finding all square numbers under 250:

>> squares.take_while {|n| n < 250}
=> [0, 1, 4, 9, 16, 25, 36, 49, 64, 81, 100, 121, 144, 169, 196, 225]

In fact all Enumerable methods are available, but we have to take care in using them. As our sequences are infinite, any method that iterates over all members has the potential to take an infinite amount of time. For example calling #any? will either return true (if a matching element exists) or never return.

Another big drawback is that when we call Enumerable methods, laziness isn’t preserved. Suppose we want the first 5 odd square numbers. We might try the following:

>> squares.select {|n| n % 2 == 1}.take(5)

Unfortunately this will never return. Even though we only want a finite set of results, the call to #select operates on the full infinite sequence before it returns. #take(5) is never called. The same problem exists with #map, #drop, #reject and more.

Preserving laziness across derived sequences

Without laziness preservation, our sequences seem of limited use. In ruby 2.0 we can use #lazy to make our sequences lazier, but in 1.9 this isn’t available to us. Thankfully we can get around this by generating lazy versions of Enumerable methods ourselves. Let’s take the previous example, finding the first 5 odd square numbers. We hit a roadblock because #select never returned. If instead of using #select we use a new Enumerator to do our selecting, we can work around this:

odd_squares = Enumerator.new do |yielder|
  squares.each do |square|
    yielder.yield square if (square % 2 == 1)
  end
end

>> odd_squares.take(5)
=> [1, 9, 25, 49, 81]
>> odd_squares.take(10)
=> [1, 9, 25, 49, 81, 121, 169, 225, 289, 361]

Our new Enumerator iterates lazily through our original sequence, yielding only odd values. We’ve chained two enumerators together to preserve laziness.

This is all a bit cumbersome as is, but we can turn this into a ‘#select’ method on a new LazyEnumerator class:

class LazyEnumerator < Enumerator
  def select(&block)
    self.class.new do |yielder|
      each do |value|
        yielder.yield value if block.call(value)
      end
    end
  end
end

def lazy_sequence(&generator)
  LazyEnumerator.new do |yielder|
    n = 0
    loop do
      yielder.yield generator.call(n)
      n = n + 1
    end
  end
end

>> lazy_squares = lazy_sequence {|n| n * n}
>> lazy_squares.select {|n| n % 2 == 1}.take(5)
=> [1, 9, 25, 49, 81]

#reject and #map can be chained in a similar way to #select:

class LazyEnumerator < Enumerator
  def reject(&block)
    self.class.new do |yielder|
      each do |value|
        yielder.yield value unless block.call(value)
      end
    end
  end

  def map(&block)
    self.class.new do |yielder|
      each do |value|
        yielder.yield block.call(value)
      end
    end
  end
end

#drop and #drop_while are slightly more complicated, but follow a similar pattern. The main difference being that they need to keep trap of how much to drop:

class LazyEnumerator < Enumerator
  def drop(n)
    self.class.new do |yielder|
      dropped_enough = false
      dropped = 0
      each do |element, index|
        dropped_enough ||= dropped >= n
        yielder.yield element if dropped_enough
        dropped = dropped + 1
      end
    end
  end

  def drop_while(&block)
    self.class.new do |yielder|
      match_found = false
      each do |element|
        match_found ||= !block.call(element)
        yielder.yield element if match_found
      end
    end
  end
end

Together, these methods give us a LazyEnumerator that can be chained in a great number of ways, giving our sequences a lot of power. #take and #drop let us select which members of a sequence we’re interested, while #select, #reject and #map allow us to build new sequences from existing ones:

>> integers = lazy_sequence {|n| n}
>> squares = integers.map {|n| n * n }
>> odd_squares = squares.select {|n| n % 2 == 1}
>> odd_squares.drop(10).take(10)
=> [441, 529, 625, 729, 841, 961, 1089, 1225, 1369, 1521]

Using only a few simple methods, we’ve been able to answer a complicated (though contrived) question, what are the second ten odd square numbers? This particular answer may not be interesting, but the technique of defining and deriving infinite sequences is much more general and useful. This is only a small sample of what you can do with them.

<footer> 31st December 2012 </footer> </article>

How Incidents Affect Infrastructure Priorities

Posted 4 months back at Dan Manges

On Friday night we had an issue at Braintree that took our website offline for a brief period (it was braintreepayments.com, not the payment gateway). After an incident like this, it’s good for the team to get together to review the postmortem. What went wrong? What went right? What can we do better in the future? Inevitably, the discussion generates a list of projects for the team to do to improve reliability and reduce time to recovery.

One important question for the team to ask after generating the list is: where do these projects fit in with other priorities?

Usually, teams have a tendency to want to push the new projects to the top of the queue. It’s understandable: you don’t want the same thing to happen again. It’s worth taking a step back though, and figuring out if the new projects are really the top priority for the team.

Prioritizing Infrastructure Projects

When prioritizing infrastructure projects that are designed to address risk, it’s helpful to think about the chance of something going wrong and the cost to the business if it does. It’s the standard risk management formula:

probability of incident * impact of it happening = cost of risk

Of course, it’s impossible to determine precise values to plug into the formula. I wouldn’t use this dogmatically, but it’s a helpful guideline.

How an Incident Affects the Risk Formula

When deciding if an incident should shift priorities, you need to look at the probability and impact. It’s common for the impact to go up after having an incident: customers or stakeholders may be forgiving of something going wrong once, but if it happens again, they’re likely to be more concerned.

For the probability, start with asking about whether the things that went wrong were known risks or unknown risks. If they were unknown, then the probability is higher than previously thought. Ultimately, you need to figure out whether the previously determined probability of an incident is still correct, or if the value needs to change.

Result

You’re probably not going to go through this exercise and end up with a magical number that tells you exactly what to do. However, following the postmortem discussion, take a methodical approach to changing priorities before you let projects jump to the top of the queue.

Why and how to not use hover styles on touch devices

Posted 4 months back at mir.aculo.us - Home

ipadButtons that show only on hovering over an area with the mouse are a great (if controversial) way to declutter user interfaces on traditional desktops where users have a mouse or trackpad. On mobile devices (phones and tablets), users use their finger instead, and there’s no more way to just hover over an element on a webpage—hovering and “clicking” are invoked by the same action: tapping.

Mobile browsers solve this issue by having the first tap invoking the hover style of an element and, if applicable, the second tap invoking any “click” events. Because of the need to discern swipes and taps, there’s a noticeable delay in browser response time. What this adds up to is that when you have both a :hover style and a onclick event on, say, a contained button in the :hover area, users end up spending the better part of a second trying to invoke the “click” on the button (300ms for the hover tap, 300ms for the click tap, and extra time for lifting the finger in-between).

The easiest way to deal with this is simple: don’t use :hover on touch-enabled devices.

Here’s one way I solved this in Freckle Time Tracking:

  1. I use Zepto’s detect module to see if I’m on a tablet or phone (you can use this module independently of Zepto, it doesn’t have dependencies on it).
  2. If it’s a tablet or phone, I add a “no-hover” CSS class to the BODY element
  3. I disable any :hover styles with selectors that use body.no-hover .... You actually don’t have to redefine the :hover rule, just make sure the normal rule and the :hover rule contain the same CSS property settings (like visibility:visible)

Now, my reason for not feature-testing (sue me!) for support of touch events and instead using browser sniffing is that 1) historically detection of touch events has been unreliable, 2) there are hybrid browsers and devices that support both touch and normal mouse events, and 3) it’s faster.

Vim's :w

Posted 4 months back at The Pug Automatic

I keep discovering neat things you can do in Vim.

Every Vim user knows you can save the current buffer with :w.

But you can also pass a filename: :w ~/my.backup. Then the contents of the current buffer are written to that file. It happens in the background, so to speak – the filename of the current buffer doesn’t change, unlike :saveas.

If you make a visual selection first, only those lines are written to the specified file.

I’ve used this for two things:

To copy and paste between two Vim sessions. I do :w /tmp/x in one Vim, and :r /tmp/x (or :read /tmp/x) in the other.

And just now, I realized I could use it to break one file into two. I had some secret authentication info alongside some experimental code. I wanted to start version controlling that code, so I needed to extract the secrets. I visually selected those lines, did :w ~/.secret.rb and then replaced the lines with require "~/.secret.rb". Reminds me of the useful :Rextract in Rails.vim, but built in.

Something else I discovered in :help :w, but haven’t put to use yet, is :w >> /some/file to append.

Episode #339 - January 25th, 2013

Posted 4 months back at Ruby5

PartyFoul gem opens GitHub issues for Rails exceptions … GitHub code search improvements … Curly template language … Rails path matching with JavaScript … Twitter’s SecureHeaders gems … Custom RSpec example groups … punch and pie.

Listen to this episode on Ruby5

This episode is sponsored by New Relic
New Relic is the all-in-one web performance analytics product. It lets you manage and monitor web application performance, from the browser down to the line of code. With Real User Monitoring, New Relic users can see browser response times by geographical location of the user, or by browser type.

PartyFoul
PartyFoul automatically opens GitHub issues for your app exceptions.

GitHub Code Search Improvements
GitHub just released some big improvements to code search. Your code is live-indexed when you push to GitHub. You can search both public and private repos. There's an advanced search that lets you tweak and filter. Code results now have line numbers and syntax highlighting.

Curly Templates
Curly is a template language that completely separates structure and logic. Instead of interspersing your HTML with snippets of Ruby, all logic is moved to a presenter class, with only simple placeholders in the HTML.

In Browser Path Matching with JavaScript
Richard Schneeman contributed a pull request to Rails recently that allows you to interact with your routes in development mode from your browser. Plus an animated GIF void of cats and tacos.

SecureHeaders
From Twitter, this gem is an easy way to make sure you've got all the right security setting in your HTTP headers.

Custom RSpec example groups
RSpec itself (rspec-rails) uses example groups for the different types of tests for models, controllers, helpers and views. You can do the same for your own spec files.

./bin/setup

Posted 4 months back at GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS - Home

In our protocol guide, we instruct new developers to set up an existing Rails app like this:

git clone git@github.com:organization/app.git
cd app
./bin/setup

The goal of the bin/setup script is quick, reliable, consistent setup. It is placed in the bin directory to match new Rails conventions about executables.

Here’s an example bin/setup:

#!/usr/bin/env sh

# Set up Rails app. Run this script immediately after cloning the codebase.
# https://github.com/thoughtbot/guides/tree/master/protocol

# Set up Ruby dependencies
bundle install --binstubs

# Set up staging and production git remotes
git remote add staging git@heroku.com:app-staging.git
git remote add production git@heroku.com:app-production.git

# Set up database
bundle exec rake db:setup

# Set up configurable environment variables
if [ ! -f .env ]; then
  echo "RACK_ENV=development" > .env
fi

# Set up DNS
if [ ! -d ~/.pow ]; then
  echo "You don't have Pow set up but the team is using it for this project: http://goo.gl/RaDPO"
fi

echo "port: 7000" > .foreman
echo 7000 > ~/.pow/`basename $PWD`

The first section uses Bundler’s binstubs.

The second section sets up git remotes for staging and production commands.

The third section creates the development and test databases, loads the schema, and initializes with the seed data. It does not need to run all the migrations.

The last two sections use Foreman as process manager, Pow as DNS server and HTTP proxy.

This is just an example bin/setup file. Each project will be different. Some might not use Pow. Some might test if Redis or MongoDB is installed and run, install, or print a message if not. Some might want to pull some ENV variables into .env from Heroku.

Regardless of the bin/setup file’s contents, a developer should be able to clone the project and run a single, consistent, reliable command to start contributing.

"A framework for making decisions"

Posted 4 months back at interblah.net - Home

A lot of my time, energy and worry with regards to Free Range over the past year or so has been about trying to establish a direction, a goal, a sense of momentum. A shared and explicit purpose, of what we are trying to achieve and how we think about achieving it.

As we entered the new year, this stuff was very much at the front of my mind, and a serendipity would have it I came across this article by Steven Sinofsky (let’s not hold his Microsoft background against him, at least for now), with some words that felt particularly relevant.

Some quotes:

If you think about a team as a set of folks each coming to work to make difficult choices each and every day (and night!) then the critical element for the team is a shared and detailed sense of the overall plan for a product. Historically software planning has not matured to the degree of planning for most other engineering endeavors (construction, transportation). For the most part this is viewed as a positive—it is the “soft” part of software that makes it fun, agile, and in tune with the moment

But if each perspective on a team is maximizing their creativity and agility, it doesn’t take long for chaos to take over. And worse, if things get chaotic and don’t come together well then fingers start pointing.

It is often amazing how quickly the most well-intentioned folks working together can start to have that so-called natural tension turn into a genuine dysfunction.

For a project of any size that goes beyond a handful of people or involves any complexity, detailing the how and why of a product, not just the what, is a critical first step. The reality is that every member of the team benefits from the context and motivation for the project.

The point of a plan is to build a bridge made up of the how and why, not the what.

A plan for what is being built can sound so heavy or burdensome. It can be. It doesn’t have to be. Another word for a plan is a “framework for making decisions”.

It’s this last sentence that really resonates with me.

I don’t want a plan for Free Range so that we can decide rigidly upfront exactly what we’re going to do, followed by dogmatic excecution.

I want a plan so that we have a framework for making decisions; so that we have a way of evaluating our choices that is based on some commonly agreed goals and principles. Without this, I can only see chaos taking the reigns. And not the good kind either.

Ruby Manor 4 tickets sold out in about 12 hours, and it's great and worrying at the same time

Posted 4 months back at interblah.net - Home

One one hand it’s great that the Ruby Manor tickets this year sold out so quickly - about 12 hours for 250 tickets at £15 each. Our little-conference-that-could must have a good reputation, and people must be excited about it.

On the other hand, I wonder what it else means. I worry when tickets for a conference are selling before there’s any hint of what the content will be, which is almost always the case with Ruby Manor. I know a lot of people will buy tickets for an event based on what they heard about the previous incarnation, but how good a reason is that?

To cheap to pass up?

And when the tickets are only £15, maybe it’s the rational thing to get a ticket without thinking too hard; even if the conference turns out to be rubbish, or you realise you can’t attend, then you’ve only lost the price of quiet night out.

With Ruby Manor, though, it’s not enough to buy a ticket on a whim and then turn up on the day hoping for some fun presentations. We need everyone to get involved to build the schedule. Given that people tend to value things based on how much they paid for them, does that say anything about how people are going to invest in helping build our conference?

How many of you have read the Ruby Manor manifesto? I know some people really to get it, but I haven’t met most of the 250 people who will hopefully be joining us this year, so I really don’t know what most people think. I know that some of the people who helped us sell all our tickets won’t know anything about Ruby Manor except that it’s about Ruby, and it’s in London, and other people liked it. And that might be all they know at the end of the day on the 6th of April, too.

You can lead a horse to water…

In the Free Range weeknotes last week, Chris mentioned a parallel that I drew between things like indieweb and Vendor Relationship Management, but what I was thinking about when we had that conversation was that I am coming to terms with how hard (and maybe impossible) it is to change the way people think about conferences (or software), at all.

Chris wants people to realise that they can have much more control over what software services do with their data, and how they are built. I wanted conference attendees to realise that there was an alternative to expensive conferences with tired content and pointless swag.

What I’ve come to realise, however, is that even when you try and demonstrate that different is possible, and maybe even better, a lot of people will still approach what you’re doing in the same way as any other contemporary example (be that a conference or a software service). Even if something is better, and you can produce a coherent, concise and interesting argument for why it is better, and why someone should care, even with the most perfect meme to implant in their minds… it often still doesn’t make a difference.

It’s really hard to get people to recognise (let alone embrace) philosophical agendas; what I’ve come to accept over the 5+ years I’ve been thinking about Ruby Manor, is that some people just don’t care, and never will.

What I need to get better at is finding that minority who do care – even if they disagree – and build on that.

Anyway, there’s your slice of my brain for today. Do with it what you will.

#402 Better Errors & RailsPanel

Posted 4 months back at Railscasts

Here we take a look at two tools to aid us in development: Better Errors which makes it easier than ever to debug exceptions, and RailsPanel, a Chrome extension to see Rails requests.