The Lincolnshire Poacher by Chris Lloyd

Databases Are for Pussies

— a direct quote from Myles Byrne.

Phil Karlton is quoted as saying: ‘There are only two hard things in Computer Science: cache invalidation and naming things.’ You’d think that because I’m a programmer studying Computer Science (I love the capitals!), that would make me a Computer Scientist. That misconception only occurred to me recently. 99% of programmers out there aren’t Computer Scientists. Therefore, I’d propose the two hardest things in programming are not cache invalidation and naming, but business and interfaces. I’m not going to talk about why I think business is so hard for programmers now: that point, I think, should be fairly obvious. I’m adamant, though, that interfaces are the other most important thing for programmers.

The days where we can sit in dark room with a full-sized console hacking away, are gone. The web has now coupled design to development and you would be foolish to ignore that. You can’t make any technology decisions without considering how they would affect the user interface. Should I use AJAX for this? Should I make that query? These decisions need to be driven by the experience you want to create for your users, not what is easiest for you or what is the most “comp-sciency” solution. I believe that people would find a beautifully crafted site with great content and a 5s load-time more becoming than 0.2s site in Comic Sans (and so does Patrick Lynch). We naturally think about things like processes and data but rarely copy-writing and layouts. I admit, I find these skills hard to practice and I’m not getting taught them as part of a Computer Science education. However, the number of talented people who are taking up design as an essential skill only enforces a trend towards Vitruvian programmers.

Starting new projects always sucks me into making tech decisions. I recently got excited about a new project. ‘I can’t wait to get started, I can use CouchDB! It’s going to be so awesome!!!’ Ok Chris, calm the fuck down and take your finger off SHIFT-1. CouchDB won’t make any difference to whether users will like like your app or use it correctly. CouchDB is shiny and you can’t let yourself get distracted by shiny things until you know what is actually going to be in your site. I know if I start building something using CouchDB I’ll create my own ORM (what can I say, I’m excitable), which will be good but wont quite fit the site, so I’ll end up making decisions based on what is easiest to do with my ORM. I should be making decisions based on what is best for my users and those decisions can’t be influenced by technology. In a recent talk about Google Wave, Cameron Adams said something along the lines of ‘create perfection, then work backwards from there.’ He was referring to user adoption of UI but the same concept applies to technology limiting UI.

Beginning a project with the UI (or “rapid prototyping”) is also an enormous business advantage. Most shops can get simple mockups deployed fairly quickly. Create an index.html and hit upload. However ask a Java shop to do more than static HTML mocks. Ask them to serve some semi-dynamic JSON which you need to show off a feature. Big stumbling block because now they need to worry about more than just hitting “upload”. ‘Ok, talk to the sysadmin, fire up a new project in Eclipse, get Ant running and, oh yeah, do some coding.’ The Agile Nazis could have a holocaust with that one. There should never be an acquisition of power during the life-span of a project, only only the dissolution of self-imposed constraints.

Tyrone

That is where Tyrone comes in. Tyrone is a code generator and library designed to help you get up and running designing UI mockups as quickly as possible. It’s meant to motivate you to start your projects designing interactions rather than pushing code and making ORMs. Also, by using Sinatra, Tyrone can quickly help you create stuff like semi-dynamic JSON and then move onto a larger Rails project when it’s needed. Just use the tyrone command to get started:

{gem,rip} install tyrone
tyrone my-new-app

It works just like the rails command (but better, I’ll come to that later). This creates a new project with a skeleton Sinatra app and a few Javascript files. All bundled up nicely for instant deployment to Heroku. You can then start by adding files to the mockups directory. Easy peasy.

Tyrone is opinionated. It comes with:

1. A nice index page (for easy access)
2. jQuery (as it is faster to code simple things than Prototype)
3. Tim Lucas’ states.js (lovely inline prototyping)
4. An empty features directory (writing stories is a great way to define your app early)
5. A HTML 5 reset stylesheet

You will use HTML 5 for your app. It’s the way of the future and also includes nice input attributes (see autofocus and placeholder) which means you have to code less JS. If you absolutely can’t use it, backporting should be fairly trivial.

Tyrone is only built for initial prototyping: you should eventually switch to a fully fledged Rails app. That process shouldn’t be too difficult as you now have user stories and HAML views all ready to go. The index page purposely limits the usefulness of Tyrone: when you want a custom index page, move to Rails. I worked on a project recently where we started with Sinatra for prototyping and had intended to move to Rails. However, when time started to slip away it seemed like too much hassle. We ended up replicating migrations, form helpers and even had a “controllers” directory. Alot more code was written than was needed (the app, however, was still awesome because we carefully prototyped the UI before implementing it).

Oh, and the name comes from Tyrone’s Dog Babysitting Service . You can be sure that my boy Tyrone loves your UIs more than he loves dogs.

And Now for a Rant

I looked at using Rubigen for Tyrone’s generator. Firstly, and I’m sorry Dr. Nic, but it has shocking documentation. Scroll to the bottom of the README. Where’s the information on how to create a component generator? It’s also so abstracted it expects you to have 5 bazillion generators each with 1 gahundred-thousand templates. The real stinker, however, is the code.

So I made my own. Introducing… (my other coding project this weekend) Pixii! It’s less than 100LOC and the README documents pretty much all functionality. It’s also bloody easy to boot. Go, make generators and be happy. Checkout the README for all the goss. Oh, and the name comes from Hippolyte Pixii.

So, something to try on your next project: design your interface first. Focus on copy-writing. Focus on cutting features. Do 10 different variations of the same thing. Figure out what exactly your user wants, rather than focusing on that interesting, shiny technology. It’ll be hard at first, but remember: “databases are for pussies.”

Myopia

I love this picture. You should go have a look at it large. Millais was one of the founders of the Pre-Raphaelites, a group who believed that taking a classical approach to art was bullshit. Casting aside brilliant colours and chiselled six-packs, they drew women in awkward compositions with dirty dresses truthfully depicting nature. Blind Girl is great because it strikes me as so genuine. The detail of the blind girls hand, gently touching the grass really conveys the warmth of the Sun too. It’s one of those serene moments where nothing else matters except the present.

The parable of the blind girl and the storm can be applied to software engineering. Development practices these days encourage wearing blinkers while programming (BDD, Agile to name a couple). As programmers we naturally abstract problems to the n^th degree, thinking outside of the immediate challenge to a generic solution. The problem with thinking in abstractions is that we tend to think abstractly. A generic solution always answers a different question than what was originally asked. But gosh, I’m a fiend for over-engineering solutions. It’s fucking fun to play with technology. Look at it whirl!

My latest hobby, however, has been knocking that whirling candy right out of my hands. I’ve been walking through crowded places with my eyes closed and headphones blaring. Blind and totally deaf, I can only concentrate on where my feet are going and the sun on my face (unless I’m walking inside, of course). I’ve been calling this “blind walking”. Your Mum will tell you it’s a stupid idea (she told me so last night) but she assumes everybody else is deaf and dumb as well. The reality is that people see you and move out of your way. Largely, this is a confidence thing. You have to be confident if you don’t know where you’re going because that is all you have. I’ve been blind walking every day for the last couple of weeks and I haven’t hit anybody yet.

But back to the regular programming. We constantly create unrealistic scenarios that could happen in the future. Take, for instance, the problem of including a specific version of a library in Ruby. A common Ruby idiom is to do so like this:

{ 'activesupport' => '2.3.2',
  'activerecord'  => '2.3.2',
  'sinatra'       => '0.9.2',
  'fancypath'     => '0.5.12'
}.each{|g,v| gem(g,v); require(g)}

rather than to explicitly requiring each Gem. For the most part this is a good solution to the original problem. However, in the case where the Gem name is different to the library name (like the openrain-action_mailer_tls) this solution doesn’t work. Rather than just requiring each Gem by hand I created an imaginary situation where there would be so many gems I would require a shorthand to require them. By trying to predict the future I missed the edge case of Gem’s with mismatched names. This is a pretty trivial example, but the point I’m trying to distil here is that you cannot predict the future, so don’t bother trying.

Hold on, what is here that isn’t in an article on YAGNI or sleepwalking? I’ve been learning to deliberately ignore a certain future for the benefit of the present. There is no stopping the storm from hitting the blind girl and I knew I would require enough gems that a shortcut was useful (though that could be another topic). You have to act when, and only when an event occurs, not a moment sooner. Everything is a guess until it happens. In the previous example, had I acted once I did have alot of gems, I would have looked at the entire situation and taken the edge case of gems with weird library names into into account. YAGNI is about trying to predict the future to save time in the present whereas I believe you can’t concern yourself with anything that you don’t know for certain.

The two most delightful qualities we (surreptitiously) attribute to good programmers, laziness and cockiness, lend themselves very well to this seeking of immediate happiness and disregard for everything else. Laziness in the sense that it encourages you to only act at the last possible moment. Cockiness is essential as you need to believe that your decisions are correct for them to actualise the desired future. Like Millais, a successful programmer casts aside distracting personal phantasms and seeks out only the truth in their situation.

Lessons In Software Design

I originally wrote Gravtastic, a library for using the Gravatar API, to learn a bit about Ruby and how to publish gems. It was a fun project which I did during my exams in 2007. The project has a few people watching it on Github so it is the best public representation of my abilities (other than my proposed enhancement to Rails). I looked back on it the other day and it struck me just how much I had learnt in the last few years. None of my code was bad, but I’ve been living and breathing binary since late 2008 and my opinion about everything has changed. Hang on, who am I trying to protect? The code was bad and here is what I learnt from re-writing it.

Lesson 1: Results

Firstly, the spec suite was massive. It was disgusting to work with. Sitting down to some refactoring I made one little change and three tests broke (all for unrelated features). The library still functioned correctly, but the specs were too closely coupled to its internals. To fix this, I went through and made specs that only tested the result, not the implementation. To help choose what features to cover with the specs, I singled out methods that were more than 4 lines long. Anything less than that, really, can probably be tested by inspection. In an ideal world, your software should be so simple that you know it works just by looking at it.

Despite the current Cucumber craze, this lesson shouldn’t be confused with writing integration tests: it specifically applies to how you write your unit tests. Each method I was testing was essentially mocking out the execution of the rest of the library. Here are some particularly bad examples:

it "changes .gravatar_source" do
  lambda {
    @klass.is_gravtastic :with => :other_method
  }.should change(@klass, :gravatar_source)
end

it "returns the value of @gravatar_defaults" do
  @klass.instance_variable_set('@gravatar_defaults', :foo)
  @klass.gravatar_source.should == :foo
end

Theoretically doing this meant that one method could be tested in isolation without anything else working. I mean, that’s how tests should be, right? No. In reality, this just resulted in a big mess of interweaving dependencies. There were originally 34 specs and I ended reducing them down to 10, the core functionality.

it "source is :email" do
  @g.gravatar_source.should == :email
end
  
it "options are { ... }" do
  @g.gravatar_defaults.should == { ... }
end

It was actually better just to ignore the perfectness of the tests and go with testing the outcomes that I cared about. This process had the added bonus of also making the specs a readable source of documentation.

Lesson 2: Power

The code had prided itself on being strict: every option passed to the #gravatar_url method was checked and any invalid keys thrown out. This, however is the wrong way to approach software. If you are designing a system to be used by others, it needs to be as open as possible.

Let’s say, for example, that Gravatar brings out some new feature which is activated by the parameter xtra=extreme, so a developer would call it using gravatar_url(:xtra => 'extreme'). Before the Great Refactoring, the library would just filter the xtra parameter because it wasn’t defined in the list of valid parameters. That would mean that every time Gravatar released an update I’d be there, playing catchup. Fixing this was easy: I just don’t give a shit anymore. Users can pass whatever parameters they want. If the user passes an argument which I know a shortcut for (like r for rating) then great, it’ll use that.

I know there will be the people who think “what about developers who don’t test”? Fuck them. If they are not testing the code they write and don’t pick up on a poorly passed parameter, then their app should blow up. I’m not going to sacrifice power and flexibility to fix the mistakes of a minority. I guess this is why I prefer dynamic languages.

Lesson 3: Marketing

As I mentioned before, the last thing I want to be doing is maintaining software like Gravtastic and supporting its users. Yeah, I’m lazy. I spend all day surfing StackOverflow. Until, that is, when I saw a question from somebody who couldn’t use Gravtastic because the README was confusing. I love the ego trip of somebody discussing my library, however they were discussing how they couldn’t use it. Part of me says “screw them, if they can’t figure out the README, then they probably shouldn’t be using the software”. At the same time, I’d like to make software that will actually be used (I don’t want to be absolutist). That’s the reason I released it in the first place and the whole point of open source software. So I decided to help.

When I looked at it, the README was atrocious. I’m the only person who could have understood it. The main problem was that it wasn’t targeted at the correct audience. In the end, I spent more time rewriting the damned README than coding. Version 2.1 of Gravtastic is more an update in it’s marketing than anything else.

Not having practised writing in years I found it very fucking hard. Yes, I’m an “arts” student who has to write essays on things like Tocqué’s interpretation of Maria Leszczyńska or the Japanese avante-garde in the 1920’s and 30’s, but that is hardly writing to entertain someone. If you find shitty painters and pretentious sculptures interesting then you probably won’t understand what I mean by “entertainment”. Most users don’t know what they want, let alone know that they want your product. Getting someone to think that what you offer is fun is the easiest way to get them to want it. And that’s why working very hard on writing good READMEs is the easiest way to get people to like your software.

Of course, the best way of getting people to appreciate whatever you do is by doing a good job. It’s a shame I’m not a good programmer, because then that would be easy. I constantly have to force myself to reflect on what I’ve done wrong. It’s never pretty, but neither is your Mum.

The Third 500

When I used to row in high school, we always talked about the dreaded “third 500”. In a normal 2 km race, we usually split our race plan into 4 parts, each 500m long. When the calmness of the water was broken by the starting gun, our brains got loaded with so much nervous adrenaline that nobody really remembered the first 500m. We would then level out to a comfortable pace in the second section, slowly regaining our composure. For the last 500m we all wanted to die. Hearing the crowd and feeling the pain, we’d fucking hack on the oar until collapsing at the end.

But those weren’t the hardest bit of the race. That was always the third 500. By then, the lactic acid had truly set in and your arms and legs are on fire. Most good crews make their move then, because this is a time when they can be psychologically stronger than everybody else. Rowing was not so much about being strong and fit (of which I was neither), it was about overcoming every instinct telling you to stop tugging on that oar. And the third 500 was the killer.

Software development is much the same. Often the first half of a project will be filled with excitement and interesting problems, and the last bit, actually shipping a polished product, is fun. It’s that third quarter, where the team gets tired and the tough bugs lie, which can make or break the race.

Metalpoint

A tool to help draw and compose vector images in SVG and VML.

Think Illustrator or Inkscape except that it’s purely in the brower. At the moment you can only edit points and move shapes around, but that’s fucking cool in itself. The technology is based on Dmitry’s Raphaël, so it works in all major browsers. My longer term goals (subject to your interest) are:

• Animation. It’ll be really easy doing frame based animation but I want to get the actual editing a little usable first.
• Host it. Perhaps have accounts for save/export features, not sure yet.
• Get the UI working well. This may mean moving to canvas for speed, but I’m going to have to go to HTML5 anyway. This will probably be a bitch.

At the moment there is a small Sinatra app running the code, but all it is doing is processing HAML. There is, however, a static demo in public/demo.html. You can check out the source on GitHub.