AirBlade Software

What Everybody Needs

2012-05-07T00:00:00+00:00

First, I am really busy. I barely have enough time for the people who rely on me. Honestly, I don’t have any spare time to give away. (On the other hand, I need more time. If you can give me more time, then I’ll almost certainly buy your product.)

Scott Porad, Making Effective Cold Calls

Does Anyone Want To Take Over PaperTrail?

2012-05-03T00:00:00+00:00

I can’t seem to find enough time these days to give PaperTrail the attention it deserves. Does anyone want to take it over?

Here’s what you’d be signing up for:

The domain model has stood the test of time pretty well, but I think it could be a little more intuitive (#115, #124).
The code is clean and well commented.
The test code is harder to read than it should be. It uses an old version of Shoulda and has lots of nested contexts.
There are one or two edge cases to fix (#131, #88).
The big, unsolved problem is handling associations (#12, #44, #121, #148).
The code is tied to Rails 3. It would be nice to generalise it to support, say, Sinatra (#119).

If you’re interested, please let me know here.

Filter Rails Logs

2012-04-13T14:00:00+00:00

Rails logs each request over multiple lines. It’s nice to have so much information but it invariably makes searching the logs a messy process.

Some people are writing drop-in replacements for the Rails logger which log each request on a single line.

In the meantime I use cack to search/filter my Rails logs. Give it a pattern and it will pull out every request block matching the pattern.

$ cack PATTERN LOGFILE

Typical scenario

Sometimes customers phone me with a problem. Each customer has their own subdomain, which I log for every request. cack lets me extract their activity from the log, making it much easier to see what’s going on.

$ cack customer-subdomain production.log
$ vim production.log.out

It’s already helped me solve several customer problems faster.

I’ve also used cack to filter by IP address and controller action.

Caveats

The script has a few limitations:

It writes to a file rather than stdout.
You can’t configure the output filename.
You can only pass it one filename at a time.

GitHub Bottle Opener

2012-04-13T13:00:00+00:00

When in the console, I often want to open GitHub to look at:

my current repo
a particular commit in my current repo
one of my gems
someone else’s gem

You could use Hub for this but that’s like using a Swiss army penknife when all you need is a bottle opener.

Instead I use gh, a trivial little script which is already saving me time.

$ gh                  # open current repo on GitHub
$ gh <commit>         # open current repo @ commit on GitHub
$ gh repo             # open my other repo on GitHub
$ gh username/repo    # open username's repo on GitHub

Deploy The Right Code

2012-04-13T12:00:00+00:00

Every once in a while I used to forget to push my code to GitHub before deploying. It was harmless but annoying.

These days I prevent it with the following Capistrano snippet:

namespace :deploy do
  task :verify_what_to_deploy, :roles => [:app] do
    sha = lambda { |branch|  `git log --pretty=format:%H #{branch} -1` }
    branch = 'master'  # hardcode for now
    local, remote = sha[branch], sha["origin/#{branch}"]
    if local != remote
      srsly = Capistrano::CLI.ui.ask("#{branch} does not match origin/#{branch}.  Deploy anyway? [y/n]")
      exit(1) unless srsly == 'y'
    end
  end
  before 'deploy', 'deploy:verify_what_to_deploy'
end

Problem solved.

Commoditisation Or Not

2012-03-14T12:00:00+00:00

As with many fields, web development looks trivial to the untrained eye. Sooner or later everyone who builds web applications hears, “Why it is so expensive and time-consuming to do this new thing? I have a ten year old nephew who can make web pages. It can’t be that hard.”

There are many good ripostes to this. One of my favourites is Red Adair’s:

You think hiring a professional is expensive? Try hiring an amateur.

Although one could argue that extinguishing blazing oil wells and web development are not in the same league. Moving on…

A modern web application is a system with many moving parts. Any engineer will tell you that complexity rises quickly with the number of moving parts. People expect web sites to be available pretty much all the time, so you need to be good at containing the complexity and simplifying wherever possible.

Recently I saw two pages which reminded me of all this: Netburn and What does it take?.

Netburn’s page simply says, “Are you making a website? You will need to know [daunting list of about 75 things]. Or you could hire someone who knows.” Punchy.

‘What does it take?’ lists the full stack for Sifter, a typical modern day webapp. I thought it was rather good, so here’s my version for Sparkle.

Sparkle’s web stack

Where relevant I’ve included my current technology choice in brackets. Every webapp will have a different blend of components.

User experience

Interaction design
Visual design
Typography
Copywriting
Accessibility

Front end

HTML (HAML)
CSS (SASS)
JavaScript (jQuery, Coffeescript)
Browsers (IE7+, Safari, Chrome)

Server side

Programming languages (Ruby)
Web frameworks (Rails, Sinatra, Rack)
SQL
Version control (Git, GitHub)
Principles of REST / hypermedia APIs
Principles of domain driven design
Testing frameworks (MiniTest, Cucumber, Capybara, etc)
Search (Sphinx, Thinking Sphinx)
Background processing (Delayed Job)
Email delivery (Fastmail)
PDF generation (Prawn)
Barcode generation (Brocade)
Content storage (S3)

Operations

Release management (Capistrano)
DNS (DynDNS)
Monitoring (Pingdom, Scout, Monit)
SMS alerts (Fastmail)
Front-end performance (Page speed, YSlow)
Asset packaging (Jammit, Rails asset pipeline)
Content delivery network (CloudFront)
Web server (Nginx)
Application server (Unicorn)
HTTP especially caching
SSL
Database server (MySQL)
Unix (Bash, cron, etc)
Unix process management (Foreman, Upstart, Monit)
Backups / disaster recovery (mys3ql)
Virtualisation (Vagrant, VirtualBox)
Payment processing (SaaSy)
Invoicing (FreeAgent)

All areas

Text editor (Vim, MacVim)
Common sense!

On the radar

And here’s what I think I need to learn next for Sparkle:

Server provisioning (Chef)
Javascript framework (Backbone.js)
Key-value store (Redis)
Better database (PostgreSQL) — maybe

Comments

Consider Puppet as well as Chef. Don't use Postgres, use Percona. No need for Redis.

Olly Headey • 19 March 2012

True Glory

2012-03-14T00:00:00+00:00

There must be a beginning of any great matter, but the continuing unto the end until it be thoroughly finished yields the true glory.

Sir Francis Drake

Customers Remember

2012-03-07T00:00:00+00:00

People don't remember that a feature was missing once you implement it, but they remember broken features long after you've fixed them.

Joshua Ballanco

The Kano Model

2012-02-22T12:00:00+00:00

In the 1980s Noriaki Kano devised a simple way to model how a person experiences a product or service. The Baymard Institute explains it well; this is their conclusion:

The details don’t matter if you don’t get the fundamentals right, so the basic attributes need to work flawlessly before you focus on anything else.

You don’t need to match every single performance attribute in the market head-on. Align your investments in performance attributes with the target audience of the product – this may of course vary significantly and warrant different variations of the same product.

Delivering unexpected delight attributes is what fuels word-of-mouth. Once you’ve secured the basic attributes and some performance attributes, you should begin brainstorming on what delight attributes you can offer as this is what will truly set you apart from the competition.

Today’s delight attribute is tomorrow’s performance attribute, and six months from now it may very well be a basic attribute. Customer expectations continually increase so you have to continually reiterate and reinvent your offerings.

Having a deep understanding of the true needs of your customers, their context and their behavior, is absolutely crucial when inventing new delight attributes. Looking at what your competitors are doing won’t help much as the delight attribute will no longer be a delight by the time you have imitated it.

The Baymard Institute, UX and the Kano model

After running Sparkle for nearly four years, I’ve ticked the first two off the list. I’m now looking for “unexpected delight attributes”.

Looking around at the moment, a good example is Basecamp Next. 37signals are clearing looking to delight people with its speed and its calendar.

The fourth item provides fuel for one of my favourite software aphorisms:

Your software is only finished when the last user is dead.

So true.

Test Driven Development

2012-02-22T11:00:00+00:00

I developed deck.js off and on over the course of a few months, in lulls between stretches of client work. Yet another advantage to TDD is that it makes picking up development easier after weeks away from a project. Just fire up the tests, see what fails, and get to work.

Caleb Troughton, Deck.js Post-Mortem Quick Hits

TDD is also invaluable when you are chronically sleep-deprived. I built a non-trivial chunk of Sparkle over a month where I didn’t sleep more than 3hr at a time. Although I could barely remember my own name, TDD enabled me to deliver the feature (albeit four times slower than usual) flawlessly into production and it’s worked perfectly ever since.

The biggest perceived “con”, increased development time, is more than erased by the time saved as a result of the pros.

Idem

Unfortunately it didn’t help with remembering my name.