Alex Young

Riotjs: A JavaScript Unit Testing Framework

2009-11-04T00:00:00+00:00

I really like Riot, the Ruby unit testing framework, so I decided to port it to JavaScript. You can get it from GitHub at alexyoung/riotjs.

I’ve worked hard to keep the syntax minimal. This is challenging in JavaScript, as you may have gathered from my Fear and Loathing in JavaScript DSLs article.

There’s actually no need for a JavaScript “DSL” in this case — riotjs could work fine by passing around objects. It’s just that riot tests are so terse that I wanted to carry this over to JavaScript. Up until now I’ve been using unittest.js from script.aculo.us and I always felt the tests were too messy.

Here’s a few interesting things to note about it:

Like cucumber the output is verbose
It’ll work with Rhino, I do a lot of work this way because it’s very fast and focused
I colourize the output in the terminal
Your tests will also run in a browser without any modification
There are some aliases: should is aliased to asserts, and given is aliased as context
Those methods are not global because I’m a cunning magician

Here’s an example test:

load('test_helper.js');

Riot.context('Functions', function() {

  given('a function to curry', function() {
    var add  = function(a, b) { return a + b; },
        add1 = Closure.curry(add, 1);
    should('return expected values', add1(10)).equals(11);
  });

  given('a function to memoize', function() {
    var fibo = Closure.memoize([0, 1], function(recur, n) {
      return recur(n - 1) + recur(n - 2);
    });
    should('return fibonacci numbers', fibo(10)).equals(55);
  });
});

Riot.run();

This test is from my closure library, which is a bunch of functional stuff (with lazy evaluation!) for JavaScript. Here’s what the output looks like:

I could also include that script in HTML, because Riot.run will automatically run the tests onload. Additionally, Riot.run can be passed a function containing the tests, rather than having a call to run. The reason I call run here is because I have a set of files I want to run to test the entire libraries.

Don’t be afraid to message me about riotjs on GitHub, it’s a work in progress so I’d appreciate contributions and thoughts.

Running a Web Business in the UK

2009-10-29T00:00:00+00:00

A friend of mine shared this link with me: 37signals has some lessons for European startups. It made me think about 37signals business and marketing approach to web apps — what works and what doesn’t for the rest of us.

I build web applications and I also freelance. My company is called Helicoid. I’ve found that marketing software without a good chunk of capital is like playing the lottery. There’s a chance that your apps might get noticed, but you need to sustain interest over time. You might have noticed how often certain businesses appear on premium advertising services like The Deck — that’s because they invest a serious amount of money into marketing.

Why do some businesses have to pay thousands of dollars to appear on The Deck while 37signals don’t? The secret is community.

History and Community

37signals started as a design agency. They had some great public-facing projects: single page redesigns, a design-oriented blog, and a book called Defensive Design. All of these things conspired to make their blog incredibly popular. Meanwhile, their work became increasing technical, and Basecamp evolved from the desire to better communicate with clients.

Once they hit upon the idea of selling Basecamp as a web application, they had thousands of readers on their blog to sell it to. This is a marketing dream come true. There’s literally no way you can emulate this. You can’t buy thousands of people and make them follow your work and trust you.

With this history in mind, lots of 37signals’ business advice makes sense, within the context of their business. Unless you run a community or have a popular blog, you’re going to need to think for yourself.

If you have access to such a community then you’re in an incredible position: selling to hundreds of people who are genuinely interested in what you do is the best marketing strategy in the world.

Fundamental Business Concepts

If you’re interested in forming a business, it’s worth learning what limited in limited company means. It’s important to understand that the liability is limited to the company itself, not you. That means the risk of failure isn’t as drastic as it sounds, as long as you run your business legally.

Running a business legally is made easier by finding a good accountant. I’m not talking about someone who will find legal loopholes in your country’s tax system, I’m talking about someone who will give you tax and even business advice.

My accountant helped with our company’s formation, and without him I’d never have got started. I found him with Google by searching for accountants in my area.

Networking and Events

Think carefully about the difference between networking, events and marketing.

I go to a lot of web technology events to learn. When I started out, I mistakenly thought these would be good for marketing. They’re terrible for marketing products unless they directly relate to the audience.

Startup events are useless for product marketing. Drinking a few beers with a group of people who are all running web technology companies isn’t going to help you find customers, but it might help you find freelance work.

What Works for Me

Freelance, open source, social media and Alan Sugar.

Freelancing allows me to work on my terms. Sadly the British government has created a climate that is hostile to freelancers and contractors. We’re taxed so much you could probably run NASA off us. To be efficient with the company’s money, I invest in my web applications.

I currently have over 30 GitHub projects. A few of them have corresponding web sites, like JsChat. JsChat has a reference to my company’s name, so my open source efforts get paid back in a small way by people discovering my company.

Social media has given me more marketing exposure than thousands of pounds of web adverts. One of my products gets talked about all over the web on forums, Facebook, Twitter and blogs.

At first I didn’t like to contact blogs about my products because I felt like I was spamming them, but you really need to do this. I launched something last year, fired off a few friendly emails to Mashable, Read Write Web and similar sites, and I had 6000 signups within two weeks. These blogs have a needle/haystack issue, so one trick I used was to offer their readers a code to get a special premium version of my service.

Producing your own content is a good marketing strategy. Aim to write and share useful things with your audience. I write design and technical articles here and on one of Helicoid’s blogs. The secret to social media is rhythm — whenever I let the blogs slide for a few weeks it gets harder and harder to regain interest in them. It takes a while to pay off though, you can blog for months before picking up interest.

I mentioned Alan Sugar for a good reason. I don’t watch The Apprentice and I’ve only seen a few episodes of Dragon’s Den, and I don’t think much of Amstrad. But a few years ago I saw him on TV and he was explaining managing a business to a failed contestant. He said he’d know the exact figures for his potential market, the overheads, the marketing investment, the forecast for the next month or even year.

This was a wake up call for me. I’m a programmer, and business is something I do when I’m not programming. I had to turn this mentality around to have any hope of making money selling software.

Be exacting: detailed monitoring of your web apps can funnel straight back into your marketing investment. I do this my way — I have rake tasks that go off and query my apps to give me figures for various statistics.

Choose Your Own Adventure

All this advice comes down to finding what works for you, and working hard.

If you build it, they won’t come — you need to work to get people interested in your products, and you need to work to support your hard won customers. If you don’t love it you won’t succeed, and if you expect to be successful without marketing you will fail.

Riot: Ruby Unit Testing

2009-10-26T00:00:00+00:00

Riot is a Ruby unit testing framework. It results in terse and expressive unit tests. It strikes the perfect balance between shoulda and rspec-like test frameworks. It’s also very fast.

Riot isn’t based on Test::Unit (unlike Shoulda). It flattens your tests into contexts with sets of assertions. It has a setup block that runs before the assertions in a context.

There’s a movement within the Ruby community to write tests with one assertion per test block. Riot fundamentally works this way because assertions are the test block, so cheating isn’t possible. This makes for incredibly focused unit tests.

Riot is still under active development by its author, Justin Knowlden, but it’s completely usable right now. I was so impressed by it that I’ve created a JavaScript port called riotjs — I’ll cover this in another post soon.

Redundancy

Used as the author intended, Riot removes redundancy even when compared to Shoulda.

Test::Unit:

class UserTest < Test::Unit::TestCase
  def setup
    @user = User.new
  end

  def test_email_address_is_nil
    assert_nil @user.email
  end
end

Shoulda:

class UserTest < Test::Unit::TestCase
  def setup
    @user = User.new
  end

  should "have nil email" { assert_nil @user.email }
end

Riot:

context "a new user" do
  setup { User.new }
  asserts("email address") { topic.email }.nil
end

FAQ and More

Riot’s author has anticipated the typical set of Ruby test tool questions in the README.

Fear and Loathing in JavaScript DSLs

2009-10-22T00:00:00+01:00

I wanted to create an API in JavaScript that behaved like a DSL. The aim was to cut down on unnecessary syntax in the client¹ code. I explored a few techniques which I will present below. In my opinion the best technique is the final one, which my friend Annealer came up with. He intimated that I co-created it, but he was just being nice so don’t believe him.

These examples use a fictional DSL object called DSLRunner that is capable of executing the DSL.

Download the examples here: javascript-dsl-examples

Prefixed Property Names

This technique is similar to how Test::Unit works in Ruby, and it’s also how script.aculo.us unit tests work. Each method is prefixed with a significant name and presented to the DSL object as a list.

In the following example, first and last will be executed before and after the set of the methods prefixed with bake.

if (typeof print === 'undefined') {
  print = alert;
}

var DSLRunner = {
  run: function(methods) {
    this.ingredients = [];
    this.methods     = methods;

    this.executeAndRemove('first');

    for (var key in this.methods) {
      if (key !== 'last' && key.match(/^bake/)) {
        this.executeAndRemove(key);
      }
    }

    this.executeAndRemove('last');
  },

  addIngredient: function(ingredient) {
    this.ingredients.push(ingredient);
  },

  executeAndRemove: function(methodName) {
    var output = this.methods[methodName]();
    delete(this.methods[methodName]);
    return output;
  }
};

DSLRunner.run({
  first: function() {
    print("I happen first");
  },

  bakeCake: function() {
    print("Commencing cake baking");
  },

  bakeBread: function() {
    print("Baking bread");
  }
});

The problem with this example is what we’ve always found with Test::Unit — the method names become unwieldy. It would be nicer to be able to just bake().

DSL Methods as Arguments to Closures

Instead of a property list, a function can be used to store the body of the code. Passing this function methods for the DSL makes the DSL calls more readable. Each of the DSL calls is really a method that adds callbacks to a list then executes them later.

if (typeof print === 'undefined') {
  print = alert;
}

var DSLRunner = {
  methodQueue: [],

  run: function(definition) {
    definition.call(this, this.bake, this.first, this.last);

    if (typeof this.firstMethod !== 'undefined') {
      this.firstMethod();
    }

    for (var i = 0; i < this.methodQueue.length; i++) {
      this.methodQueue[i]();
    }

    if (typeof this.lastMethod !== 'undefined') {
      this.lastMethod();
    }
  },

  bake: function(callback) {
    DSLRunner.methodQueue.push(callback);
  },

  first: function(callback) {
    DSLRunner.firstMethod = callback;
  },

  last: function(callback) {
    DSLRunner.lastMethod = callback;
  }
};

DSLRunner.run(function(bake, first, last) {
  first(function() {
    print("I happen first");
  });

  bake(function() {
    print("Baking bread");
  });

  bake(function() {
    print("Baking a cake");
  });
});

The implementation here can be very simple, and the DSL itself is more expressive than before. The downside, however, is the client code has to comply to the top-level function signature (but not necessarily arity thanks to JavaScript). Connascence of position, as Jim Weirich might say.

DSL Methods Bound Using Closures and with()

This technique binds the body against the DSL library. It’s not enough to wrap the execution of the callback inside a with, metaprogramming is required.

If you’d like to reproduce this trick, remember that:

The function body either needs to be extracted or executed within a closure
You’ll need to eval() the resulting code

if (typeof print === 'undefined') {
  print = alert;
}

var DSLRunner = {
  ingredients: [],

  prepareFunctionBody: function(fn) {
    return '(' + fn.toString().replace(/\s+$/, '') + ')()';
  },

  withThis: function(callback) {
    var body = this.prepareFunctionBody(callback),
        that = this;
    return function() { return eval('with(that) { ' + body + ' } '); };
  },

  run: function(definition) {
    this.withThis(definition)();
    print("Your specified ingredients included: " + this.ingredients.join(', '));
  },

  bake: function(callback) {
    callback.call(this);
  },

  addIngredient: function(ingredient) {
    this.ingredients.push(ingredient);
  },

  last: function(callback) {
    callback.call(this);
  }
};

DSLRunner.run(function() {
  bake(function() {
    addIngredient('flour');
    addIngredient('yeast');
    addIngredient('water');

    print("Baking bread");
  });

  bake(function() {
    print("Baking a cake");
  });
});

The magic here is withThis. It modifies the client’s top-level function to make it automatically execute. Another technique that can be used is to remove the function definition — this requires a more complicated regex.

Next, withThis retains a reference to the executing class using a closure, and uses with to make references to the DSL methods implicit, and calls eval when ready.

The addIngredient method calls could be executed within a Bake class that withThis binds to instead. In my real code I had withThat which takes a parameter instead of using this.

A Closure and Injected DSL Methods

This technique is the one I settled on for my library. It’s a combination of the previous two techniques, without the with().

The function body is prepared and placed in a closure, and then it’s evaluated inside a function with the DSL methods passed as arguments. In my code I call it withDSL:

withDSL: function(fn) {
  var body = this.functionBody(fn);
  body = "(function(bake, addIngredient) { " + body + " })";
  return function() {
    var args = [
      DSLRunner.bake,
      DSLRunner.addIngredient
    ];
    eval(body).apply(DSLRunner, args);
  };
}

My real code uses an optional second parameter which refers to an object that has context-sensitive methods. This could be used to bind addIngredient calls to a Bake object — the top-level bake method would return these objects and they’d include the addIngredient method.

Injected DSL Methods Using Function Constructors

In this case, an alternative to eval is new Function:

  withDSL: function(callback) {
    var body = this.prepareFunctionBody(callback),
        f    = new Function('bake', 'addIngredient', body),
        args = [this.bake, this.addIngredient];
    return function() { f.apply(this, args); };
  }

This ends up relying more on arrays and less on strings, so it uses less code than the previous method.

Phew

Making client-friendly JavaScript DSLs isn’t impossible. You might look at with or eval and decide these techniques aren’t for you, but even meta-programming in Ruby can require a dose of analogous methods.

During the evolution of my library I was constantly benchmarking, and for casual use none of these techniques added overheads (I had 1-3 millisecond drifts).

Here’s a tip: get Rhino set up when you’re exploring JavaScript. Get the Jars and put them in your class path and add a nice alias:

alias js='java org.mozilla.javascript.tools.shell.Main'

¹ The term “client code” is used to refer to code written with the DSL.

BBC Glow: Overview and Example

2009-10-19T00:00:00+01:00

Glow is the BBC’s JavaScript framework. Things to note:

The namespacing makes it play nice with other frameworks (and itself)
It’s split into modules that are mostly self-contained (an exception will alert you to a missing dependency but this is rare)
Modules include: dom manipulation, language extensions, events, animations
Also features UI widgets with bundled images, HTML and CSS
The homepage works with the Konami code

Why does Glow exist?

To read what the developers say, see What is Glow?

To summarise, the BBC have strict browser support guidelines. They also have disparate teams that can work on different parts of the same page. Therefore:

Glow has impressive browser support: support table
Glow can work alongside different versions of itself

DOM and selector support

It’s not as advanced as Prototype or Sizzle, but the selectors provide enough abstraction for most tasks (child and grouping are present but pseudo selectors aren’t). Access the DOM using glow.dom.get("selector"). This will return a nodeList.

When working with Glow it’s best to think in terms of node lists (in a similar fashion to jQuery). NodeList has a lot of convenience methods. Adding a CSS class or iterating over lists of nodes is easy:

glow.dom.get("img").filter(function (i) {
  return this.width > 320;
});

glow.dom.get("#login a").addClass("highlight");

Language and Data

There are a few important methods in glow.lang to be aware of:

extend copies the prototype from one object to another
interpolate provides simple string templates
map is useful if you like iterators and expect them to work in IE

Here’s an interpolate example in which I add it to String’s prototype for convenience:

String.prototype.interpolate = function() { return glow.lang.interpolate(this, arguments[0], arguments[1]); };

var html = '<li><a href="http://twitter.com/{from_user}"><img width="48" height="48" src="{image}" />{from_user}</a> {text}<br clear="both" /></li>';
return html.interpolate({ image: tweet['profile_image_url'], from_user: tweet['from_user'], text: tweet['text'] });

Net (Ajax)

The network (Ajax) API is clean and easy to use. It’s all in glow.net, but there’s not much to it: glow.net.get and glow.net.post work in a similar way to most libraries.

Cross-domain requests are made possible with glow.net.loadScript. This inserts script tags into the document — this works especially well with JSON (pay attention to the use of {callback} in this example):

TwitterSearch.getTrends = function(callback) {
  var url = 'http://search.twitter.com/trends/current.json?callback={callback}';
  glow.net.loadScript(url, {
    onLoad: function(data) {
      var trends = [];
      for (i in data.trends) {
        trends = data.trends[i];
      }
      callback(glow.lang.map(trends.slice(0, 3), function(trend) { return trend.name; }));
    }
  });
}

Animations

The animation API is similar to scriptaculous: it provides a set of faders, sliders, highlight and CSS mutation. These are known as animation helpers.

glow.anim.fadeIn(tweet_html, 1);
glow.anim.css(element, 0.5, { 'bottom': { to: 0 } }).start();

The other major parts of the animation API are glow.anim.Animation, glow.tweens, and glow.anim.Timeline.

The glow.anim.Animation class can be used to build your own animation primitives. Specify a duration and a tween, then add a listener for frame events on the animation object itself.

Tweens are functions for modifying animations — there is a comprehensive set in glow.tweens.

Sets of animations can be orchestrated using glow.anim.Timeline and an array of animations and delays (known as channels). There’s a good Mexican wave example in the documentation.

My Glow example: Twitter search panels

I built a real time, user-configurable, Twitter search app just using Glow:

This demonstrates glow.dom, glow.lang, glow.events, glow.net with cross-domain API calls, and glow.animations.

Gemcutter

2009-10-09T00:00:00+01:00

I’ve put all my gems on gemcutter. They were on GitHub but seeing as GitHub has dropped building gems I thought it’d be useful to move them.

Using gemcutter

The site makes it look easy, because it is:

gem install gemcutter
gem tumble

Now you’ll be able to install gems from gemcutter.

Publishing your own gems

This is easy too. Write a gemspec file and then build a gem, and push it to gemcutter:

gem build yourgem.gemspec
gem push yourgem.gem

Note: It might take a few minutes before the gem is available from gemcutter.

Automation

Jeweler can be used to automate this process — it can use your git and GitHub settings to automatically generate a new project (including GitHub hosting, test directories/helpers).

Deployment: Diffs and Dependencies

2009-09-16T00:00:00+01:00

We moved house recently, so my daily development machine was packed up for a few weeks while I worked off a laptop and a 3G card. It was like being on holiday except I still had to work. Anyway, I found a few deployment-related scripts I was working on for my Agile Deployment series of articles (visit the agiledeployment tag for more).

I’ve packaged these scripts as rubygems, so they’ll be easy to install and try out. They’re essentially snippets that I use to maintain sanity when deploying. They might form part of a bigger deployment system in the future.

Rsyncdiff

rsyncdiff shows the differences between your local and remote code. I’ve been using this to try to visualise what will happen after deploying.

The output contains file creations, deletions and updates. The updates show a diff, and will automatically use colordiff if you’ve got it.

I use it with my Rails projects like this:

rsyncdiff server:/u/apps/project/current/app app/
rsyncdiff server:/u/apps/project/current/lib lib/

I usually just compare app/, lib/ and public/, just to keep the output manageable.

Depwhack

depwhack compares the gems your application loads locally with the gems available on a remote server. I use config.gem in my Rails project which helps mitigate missing gems, but if I’m doing a major deploy for a client I don’t like nasty surprises.

Ruby has a method called at_exit which you can use as a callback at the end of a script. I was using this after running tests on my Rails projects to get a complete list of the gems they use.

It’s pretty easy to do:

at_exit do
  p Gem.loaded_specs.collect { |g| [g.first, g[1].version.to_s] }
end

Installation

I’ve put these scripts as gems on gemcutter:

gem install rsyncdiff
gem install depwhack

The End of Religious Wars

2009-08-21T00:00:00+01:00

Are you tired of rockstar drama queens declaring war on languages, burning all their bridges and filling up Hacker News with boring articles?

Over the last few years Python and Ruby programmers have had a quiet, seething war. It’s equally as ridiculous as Nintendo vs. Sega was back in school. Conventional wisdom in the gaming community is that these wars start because kids can only afford one of the consoles, so they inevitably take sides.

This largely accounts for the programming language and editor wars. After all, time is the greatest currency — it can take months or years to master a programming language. The basics are easy to pick up, but fluency takes real effort, which makes people want to defend their investment.

The Optimist

Reg Braithwaite’s talk entitled Learned Optimism is about a self-improvement technique created by Dr. Martin Seligman. In the talk, he says:

Optimists explain good things as being personal, general, and permanent, and explain away bad things as being impersonal, specific, and temporary.

We need to start thinking about our skills as permanent and general. Learning C++ doesn’t mean you need to take sides, you’re free to learn Ruby, Lisp or anything else. This won’t make you any less of a C++ programmer.

The Superhero’s Cape

I’ve been dabbling with Ruby since around 2000, and working professionally with it since 2006. Ruby is my superhero cape. When I sit down with an editor or irb, I know exactly what’s going on.

The problem with capes is they get caught on things. We either get stuck or simply dragged down into bone-crunching machinery.

And I’d be stuck too if I didn’t have a bizarre fascination with Lisp and Objective-C. Mac and iPhone development dragged me kicking and screaming away from Ruby, and you can put Lisp down to latent British genetic eccentricity.

The Novice

When I was a kid, I loved videogames. According to my dad, it’s what got me into programming in the first place. So when I started out for real, these questions plagued my mind:

What programming language do games use?
How quickly can I learn enough to make games?
What tools do “real” developers use?

I went out and got an Amiga C book and started learning C. This was difficult at a young age, and I kept finding myself messing around in a BASIC environment called Amos (and later Blitz Basic). I could make cool stuff in Amos and Blitz, but I could only make rudimentary Amiga OS applications in C.

Reminiscing about this made me realise that when people are starting out, nobody gives them straightforward answers:

The language books claim to teach their language without previous experience, so they’re marketed to beginners
It’s hard to find good general programming books suited to beginners
It’s hard to find mentors
Online communities can be caustic
Nobody makes it clear that languages are just tools — just because you want to make games doesn’t mean you should learn C++ straight away

Novices are often impatient, but nobody caters for this. Nobody says “you’ll learn a lot of languages in your time, so let’s start with something fun”. There are projects attempting to reach young people using custom environments, but I think people are put off by wanting to learn “the real thing”.

This early struggle to achieve results is perhaps the most interesting part of a programmer’s career. The novice will happily experiment with everything until they gain traction. If this attitude could be fostered at a later stage in a programmer’s career, we’d waste a lot less time being defensive and start to enjoy our jobs again.

The Scientist vs. The Artist

The Sand Traveler: 1,000 traveling particles, each in pursuit of another.

Programmers “build on the shoulders of giants” — it’s essential to what we do. Relativity got us to the moon, C got us to widely available Unix. Programming has a deep relationship with science; it wouldn’t exist without research in information theory and physics.

Certain areas of our work need to be evaluated with valid experiments — benchmarks and optimisation, compiler and interpreter design. However, this doesn’t mean programming is a science. It’s equally an art. Aesthetics are important despite being subjective.

Be wary of people ranting about the right and wrong ways of solving problems. Try to balance established best practices with your own opinions, ideas and take time to experiment. An artist doesn’t use the same techniques throughout their career, they balance the practical and technical aspects of their work with healthy experimentation. They actively seek out influences and inspiration.

Heroes and Villains

Do a Twitter search for dhh and see how many people openly mock David Heinemeier Hansson, and how many people say “wow thanks for Rails DHH!”

How many people talked about how important _why was to the Ruby community before he disappeared?

I’ve worked with enough programmers to know that we’re generally insecure. We’re quick to complain, and rarely give out praise. But it’s difficult to know what good programming is when people don’t talk about who the good programmers and technologists are. We need to properly pay respect to our Jimi Hendrix and Kurt Cobains.

For example, I love my job but probably wouldn’t have it if it wasn’t for Clive Sinclair. It’s OK to have heroes!

The Effect of Inertia

Find some ALGOL online. I actually have an ancient ALGOL manual which talks about punch cards and everything. The reason I collect these old programming books isn’t nostalgia, it’s because we’re still drawing on work from the 50s and 60s. Looking at ALGOL reveals how much things have changed, but at the same time makes us realise the fundamentals haven’t moved on (for imperative languages).

Ruby took a lot of ideas from languages that came before it, and the clarity of its syntax still impresses people today. This perceived evolution creates “inertia” — people are swept along in the wake of change.

Don’t let this sweep you away from other things though. You don’t need to throw away work and switch alliances, just add new languages to your utility belt and enjoy playing with them.

The End of Religious Wars

We could end religious programming wars by learning to teach programming properly. Learning programming isn’t just about covering imperative, functional and object-oriented patterns. It’s about culture, tools, engineering, art and science.

Have you ever seen a programming book that used examples from different languages? It would be completely possible to create such a book in a new and exciting way. Imagine a Why’s Poignant Guide To Programming.

Anything that allows novices to quickly get up to speed will encourage cross-language experimentation and experience.

Free books encourage people to learn: all languages should have a quality free book available
Try ruby allowed people to try out a Ruby interpreter online. This was great for novices or newcomers to the language — all languages need projects like this
Easy installation is key to letting people dabble. How many Windows users downloaded Instant Rails to quickly try out Rails?
Quick results are great for impatient beginners, and all languages should have awesome game examples instead of dull examples about databases and business software
Co-operation between languages might encourage people to work together more — jruby has had positive effects on ruby
Experienced programmers would do well to share their influences and pay respect to truly great programmers. They need to blog about their heroes before they vanish
Experienced programmers should stop fearing what they haven’t yet learned. CSS/regexes/SQL aren’t evil, spend some time learning them properly!

Naysayers will say “jack of all trades, master of none”. The projects and jobs you decide to work on will inevitably lead you to become more experienced in one language. I’m not saying you shouldn’t master a limited subset of things: we should encourage people to experiment and enjoy their work.

What Makes You Happy?

2009-08-20T00:00:00+01:00

Track Your Happiness is an entertaining experiment. It’s a site that periodically sends out links to surveys. The surveys are designed to gather information on your general well-being and happiness. The surveys work fine on iPhones too, so I was able to fill them out wherever I was.

It focuses on a few main areas:

Activity
Focus
Productivity
Social interactions
Sleep time and sleep quality

Before taking the tests I had these preconceptions:

Sleep doesn’t bother me
Productivity and focus are proportional to happiness
I like working alone
I prefer reading and playing to working or watching TV

After taking two or three weeks of tests I finally completed the “course” of surveys. The results were contrary to my assumptions:

Sleep is strongly tied to my happiness
Productivity does not relate to my happiness
I prefer working with at least one person
Reading and watching TV make me more happy than any other activity
I’m happier outside

All of these facts surprised me. When I was a child I’d play outside all the time, but I still had weekend hacking sessions on the ZX Spectrum. Also, as an entrepreneur and freelancer, I thought productivity made me happy. It turns out that my workaholic nature has been compromising my overall well-being.

Try signing up and sticking with Track Your Happiness throughout the course of surveys. They can be annoying and repetitive, but you might be surprised by what you discover.

Agile Deployment: Unified Repository

2009-08-12T00:00:00+01:00

Note: This is part 5 of Agile Deployment.

Source code management is closely tied to deployment. Creating a deployment strategy that truly feels agile requires careful management and preparation of the source repository.

Branched Environments

My first approach worked like this:

I had subversion branches for each server type (pre-production, production)
These branches had their own settings files suited to their environments
We’d merge changes from forks into trunk, then merge into pre-production, then production

This worked relatively well and was easy to understand. The main issue I had with this approach was it added overhead to deploying that I wasn’t prepared to deal with. Having to carefully merge new changes every time was a real chore. I often didn’t feel secure that we’d merged in all the changes, and I’d have to open up Changes to visualise the differences.

Unified Environments

I generally work in very small teams. Most of Helicoid’s design and development is still just me, so I don’t want any overheads at all. I just want to type rake deploy and feel secure that my servers are up to date.

This forced me to unify my deploy environments into one branch. This is how it works for my Rails projects:

database.yml is either 3 files (dev, pre-prod, prod) or 1 file (where production actually refers to the production database settings) — this depends on the project and QA requirements
Most of my projects have their own configuration files. These are handled like database.yml
My deploy.rb allows me to select which environment I’m deploying to

These settings files can then be either symbolically linked or simply copied during deploy. Environment selection can work either using a command line variable or a prompt in the deploy script.

Here’s how I select environments:

rake deploy server=test

Then in deploy.rb:

if ENV['server'] == 'production'
  set :application, 'production_app'
elsif ENV['server'] == 'test'
  set :application, 'test_app'
else
  raise "Please select an environment with 'server=test|production'"
end

Sanity

This unified approach makes every fork deployable to any environment. Although this removes a lot of overhead, this creates a situation where deployment is so easy that people on your team might deploy to production before your QA processes have reviewed changes.

One way to mitigate this is by only allowing certain people to have deploy keys. As with SCM, the software tools can’t replace communication. Don’t rely on the state of the repository alone, talk to your colleagues (and clients if appropriate) to prepare for deployment.

For small projects I find a group email of feature changes is useful to start this process. I gather all my changes from my time sheets (I usually have lots of useful stuff in Tiktrac), and git logs, then I send out a quick message with bullet points detailing the changes. This can be a polite way of reminding clients that they need to review and accept changes on the pre-production server.