think pink

$PATH

Elliott Kember — Fri, 11 Nov 2011 15:26:48 +0000

A few weeks ago I had the great pleasure of speaking at WDC 2011. WDC is a great little conference in Bristol, and I have had the pleasure of speaking a few times now. One of the things I advised in my eclectic, meandering talk was to ask people what frameworks they used, and find out why they chose them. A few people have since asked me to elaborate on how I ended up using Rails, so I thought I’d write up a few thoughts on the frameworks I’ve used in the past, and what I’ve learned.

Way back in the day I was an HTML/CSS developer – cutting and slicing PSDs into workable HTML. I started playing around with PHP when a couple of my friends introduced me to it. include() was the weapon of choice – imagine how much time I could save by including the same tiny templates everywhere! This was a revelation, and like most of the decisions I’ve made, closely linked to being lazy.

I think being lazy is a positive attribute for a developer. The lazier you are, the more likely you are to do work to avoid later work. If you find you have to do the same tasks every time you start a new project, for example, you might automate those tasks into a script, saving you loads of time in the long run.

That was why I moved to CodeIgniter when I discovered it. Here was a small framework, without many dependencies, that was easy to get into and fairly straightforward. And it was great. For simple apps, I knew everything that was going on. CodeIgniter saved me loads of time and frustration doing the boring bits.

One day soon after, I saw a friend using Symfony properly, and the sheer power available blew my mind. When I started working with James Mcglinn at Eventfinder, I discovered that learning Symfony was nothing like learning CodeIgniter. It was hard.

Wherever there’s magic, there’s a lot of work involved in learning the rules. A lot of people have told me that they don’t like the amount of magic that goes on with Rails – and that’s fine. But I think it’s a bit of a silly argument. It’s like saying there’s too much magic involved in using cars, and that’s why you ride a horse. It’s called magic because it’s like a magic trick – it makes something complicated and difficult seem effortless. But a lot of work goes into every magic trick – and you’re bound to get it wrong a few times.

When I moved to the UK, I worked for a company with a Rails application. I’d heard how good Rails was, and how it was swiftly becoming the next big thing, so I wanted to learn it – and here was a great opportunity. For future reference, never try and learn a language and framework when building on a brand-new application that supports an entire company. That was a bit hair-raising.

Learning Rails was a bit like learning Symfony. All the concepts were still valid, but the implementation was different. Everything that should’ve been in a certain place was somewhere else. Ruby is a much nicer language than PHP, though, and that makes quite a difference. PHP is a bit slap-dash and inconsistent, and it continues to soldier on in a haphazard fashion. Ruby and Rails, though, are both built with a final product in mind. This was the key difference for me – Rails seemed to be striving towards a really nice way of doing things, and Ruby provided a really nice language for it. In contrast, Symfony seemed to wrap a framework around the most available language. Both are great, don’t get me wrong – but that’s one thing I prefer about Rails.

The important thing to remember along the way is that you can do it. Other people have learned to do these things, and while they be very smart people they’re certainly not orders-of-magnitude smarter than you. You’re perfectly capable of doing it, but you’re afraid of the unknown. A new language, a new syntax, funny brackets where they shouldn’t be… it’s frightening. You just have to remember that good things take time. You’re not going to be great overnight, but if you work at it for long enough, it’s worth the slog in the end.

Riot and Riot Hack Nights

Elliott Kember — Sun, 09 Jan 2011 18:42:17 +0000

@dizzyup and I are very pleased to be able to announce our new co-operative: Riot. It’s been a long time coming, mostly because we’re equal parts lazy and busy, but we’ve finally put the site live.

Hector’s the designer, and I’m the developer – and together we’ll be building lots of cool stuff in the months to come. Stay tuned!

We’ve also announced the Riot Hack Nights – a monthly meetup of like-minded geeks in the Bath area. If you’d like to come along, RSVP to me on Twitter. There’s going to be beer, pizza, and lots of code. Hot, nasty code. Fun times!

Fun times with RMagick

Elliott Kember — Tue, 04 Jan 2011 10:11:51 +0000

I was bored the other night, so Dan W and Julian and I had a bit of a hack-night session. Dan was working on Doppmaxion, which looks awesome, and Julian and I took the opportunity to do a little bit of Ruby hacking. What did we get up to, you ask?

Well, if you’re in a decent browser such as Safari or Chrome, and using a fairly powerful computer, check out this. It’s an HTML representation of an image, where by “HTML representation” I mean HTML-as-pixels, and by “an image”, I mean “this is such a bad idea it’s not even funny.”

For a long time, I’ve toyed with the idea of representing image data using HTML elements, so it was great to really unwind and see what Ruby can do with something like this. RMagick, it so happens, has an each_pixel method – which you can use to iterate through the pixels of an image. Although we’re not used to doing this sort of thing in Ruby, it’s actually not that slow – I guess it’s using some ImageMagick cleverness behind the scenes. So I iterated through these pixels and threw them in an array – then iterated through the array and spat out some HTML, one div per pixel. The result? Pandemonium.

Your average browser isn’t really designed handle this kind of abuse. So I had to make things more efficient somehow. In reality, nothing could make this efficient, but I had to try. So if you run through each pixel, you eventually find that a lot of images have runs of pixels that are all the same colour. For those, we could do a <div style=“width: Xpx”> and have one element where we’d otherwise have X! This is called Run-length encoding. If I wanted to be extra-smart, I’d make big square areas of colour into single elements, but that’s a bit complicated for a one-night hack.

The original idea was actually to represent a whole website like this – and if you visit elliottkember.com/awesome you’ll see that I was, in fact, successful. This has the advantage of being pixel-perfect in every browser (although I hear Opera doesn’t do it properly, surprise surprise) – but the disadvantage of murdering every browser known to man. I was going to put this as my actual site, but thought better of it.

The source is available on GitHub, on the off-chance that you can think of something useful for this idiocy. Side note: appending to a file every cycle turned out to be much faster than throwing around 11MB strings in Ruby. Take from that what you will.

Anyway, it just goes to show that just because you can do it, and you think it’s a good idea, sometimes you shouldn’t – and sometimes it isn’t.

Your passwords are STILL showing.

Elliott Kember — Sat, 18 Dec 2010 23:41:47 +0000

This article was originally posted on the Carsonified blog on the 6th of August, 2008, by me. However, it’s been two years and this is still a problem.

A lot of geeks and developers out there are using Mozilla Firefox. It’s a fantastic browser, and I highly recommend it. Firefox has been a huge factor in the progress of web development. Where would we be without the Web Developer Toolbar and Firebug?

However, there’s one place you have to be careful using Firefox – password management. You know the little “Remember Password” button you click when you log in? Turns out Firefox doesn’t mind showing you the passwords you’ve saved, in plain text. It’s no secret – others have previously blogged about it – but it does bear repeating. This is the default behaviour, so if you haven’t already spotted this, then chances are it applies to you right now. That means someone unscrupulous can come along and read your passwords. Like this:

First, go into "Preferences in Firefox (on a mac, hit Cmd-,) and head to the Security tab. Then click the Saved Passwords button as shown here:

This will bring up a Passwords window. I’m not showing you mine. But look for this button at the bottom right:

Press this button. Voila! All your passwords are shown, in plain text, on-screen. Please note, my password is not hunter2.

This means that someone can open up Firefox on your computer, and view all your saved passwords. The way to change this is to set a master password for Firefox. Close that passwords window, and go back to the Security preferences pane. There, you’ll see an option for “Use a master password”.

This means that Firefox protects all your saved passwords with a master password which is never shown. However, get used to seeing this prompt…

because it comes up ALL the time when you’re using password-authenticated sites. Personally, I use Webkit nightly builds for everyday browsing: they`re extremely fast and stable.

This has been a part of Firefox since forever. Maybe one day they’ll fix it. For now, it’s still just a giant security nightmare.

Hot Potato!

Elliott Kember — Thu, 14 Oct 2010 12:58:13 +0000

Hector and I have been busy – check out what we made the other day: it’s a game of Hot Potato!

It’s a quick and dirty, one-day fun app.

This uses the refresh code featured in the previous post, Check This Out. It’s very simple, and very crude – but it only took 12 hours to make.

Of course, there are more efficient ways to write interactive, low-latency web apps than by refreshing the whole page every four seconds. But the problem is, efficiency takes more time. The more bandwidth you want to save, the more work you have to do. I’ve got Node.js and socket.io, you’ve got Juggernaut or Socky, I could even just return a JSON feed that only returns the necessary data, and render that. Now that the app’s built, I can use whichever technology I like – when I feel like making it faster.

The app runs on Heroku, though – so an hour’s good performance is only a couple of clicks and a couple of dollars away. For such a trivial app, what’s the point in adding sockets? I’m not paying for traffic, or setting up more servers, or anything. I just want it to be as quick to build as possible.

It’s premature optimisation all over again – if it works the ugly way, go from there. Recently, I built a mobile drawing application for an art installation. For technical reasons, we had to draw into a canvas element, on a Nokia N900 phone. This meant installing browsers, trying plugins, trying javascript, trying sockets, xhr-multipart, polling… the lot. It all worked fine in the office, and it all worked fine in Soho – but none of that shit worked over 3G. What worked? Doing a big poll every 4 seconds. That was robust enough to either make the request properly, or fail and try again later. Sometimes that’s all you need.

I wouldn’t recommend this approach if you expected to get any traffic, or if you had a budget or a timeframe – but sometimes it’s great to just make it work. When it comes down to it, the end-user can’t tell the difference. At an early stage, or with a small product, you’ve got much more important things to think about than performance.

Check this out!

Elliott Kember — Thu, 14 Oct 2010 12:44:13 +0000

Here’s some code I posted on Forrst a while back.

There’s an error with this code. Where it says

    $(this).html()

I meant to write

    $(this).html(html)

Four little characters – but they make the difference between this snippet working, and failing miserably. It was an honest mistake, and it’s fixed now – but nobody picked up on it. That code sat there for weeks. There’s a worse aspect to this, though. Check this out. Here’s a screenshot, in case that disappears:

Someone has taken my code, pasted it into a forum, and asked people to refactor it. This is actually the second version of this that I’ve found – unfortunately the other one was deleted from the original site, and unfortunately the Google Cache too. The original question was worded exactly the same, posted on a different forum, and had an answer that said “The line $(this).html() seems unnecessary.” – which, I guess, is technically correct. Sure enough, someone posted a comment on the original Forrst page shortly after, omitting that line:

That doesn’t work – that’s even worse than my original code! This guy has taken my code, copied it into a forum, asked whether it can be refactored, and then come back with his “refactored” code. That’s awful. I bet this happens all over the show. Have any of you seen this?

However – none of this actually matters. As it turns out, I didn’t look closely enough. There’s another error.

This is one of my problems with sharing code online – you can publish any old shit and people will love it. In this case, the premise is there – but it’s still wrong. If you’re sharing code online, turns out you don’t have to make it work to get a whole bunch of likes. Is that bad? I would certainly make the case that the concept of how this code works is really important – looking at the way it loops. In a sense, reading it as pseudocode is probably a pretty good idea.

Infinitely customizable

Elliott Kember — Sun, 30 May 2010 11:51:44 +0000

As far as I can tell, one of the Apple standpoints is minimizing configuration. Having a single way of doing things is baked-in – you can only resize from one corner, you can only close a window from the red X button, and you can’t customize your system and make it totally different from all the others.

I love this simplicity. Removing the ability to mess with things forces me to get on with the things I should be doing. It takes a lot more work to perfect, but there’s huge value in selling a workflow rather than a workflow platform.

As long as we’re concentrating on details, we might as well be removing unnecessary options. One option that struck me as unnecessary today was in Tweetdeck on the iPad. Perhaps it’s a petty criticism of an otherwise excellent app – but I really don’t feel the need to be able to customize my refresh times down to the second.

What unnecessary options have you seen lately?

Lucida Grande and the Web Inspector

Elliott Kember — Thu, 15 Apr 2010 16:46:43 +0000

I love the new functionality in the WebKit Nightly builds. The nightlies are a great platform – very fast, usually pretty reliable, and super-CSS3-compatible.

However, recently the typeface used in the nightly web inspector has changed from Lucida Grande to Menlo. I understand the change, and that Menlo is a monospace font – but I just can’t help thinking Menlo’s kinda ugly for this.

However, I’ve figured out how to change it back. Now my web inspector looks like this:

Much nicer! If you want to do the same, here’s what you have to do.

Open up the file /Applications/WebKit.app/Contents/Frameworks/10.6/WebCore.framework/Versions/A/Resources/inspector/inspector.css as an administrator, and add this to the end of the file:

Yay!

Edit: Now that Safari 5 has launched, the file to append to is /System/Library/Frameworks/WebKit.framework/Versions/A/Frameworks/WebCore.framework/Versions/A/Resources/inspector/inspector.css

I love the approval process.

Elliott Kember — Sun, 31 Jan 2010 17:42:48 +0000

There’s been a lot of hate for the App store approval process over the past… well, ever since the App Store surfaced. It seems like anybody who has ever touched the SDK has a bad word to say about the draconian Apple iron curtain. The iPad’s recent release has incited similar levels vitriol – it’s closed, Apple is taking over the world, blah blah.

Apple seems to be blocking applications that duplicate native iPhone apps, applications that use Apple imagery, logos or trademarks, and apps that are offensive. I can see how some of this might be frustrating for someone who hasn’t read the documentation properly before they start working. I kid, I kid! I’m sure it comes as a nasty surprise.

This isn’t the only reason behind the approval process. In fact, I don’t think it’s even the main reason behind the approval process. One reason is to protect Apple’s ~~patents~~ trademarks. You can bitch and moan about this one if you want, but it’s fairly standard. If people have your image on their stuff, your brand is vulnerable. You don’t want to go down this route; Apple has a big legal team, and you are not a lawyer.

But I digress; the other reason is that Apple checks every application to make sure it works. By “works”, I mean: it opens, runs, and doesn’t crash too badly. If it’s a game, it doesn’t have to actually be any good – but at least it works and is playable by anybody who owns an iPhone or iPod Touch.

Remember that we are not the average user. Just like the iPad, the iPhone is also targeted at end-users. The end user doesn’t understand bugs, or approval processes. They understand works, and doesn’t-work. If something doesn’t-work, it instantly tarnishes the device. The shine is gone, the thin veneer of novelty wears away, and the dirty, buggy reality is revealed. You can watch it happen. In effect, they’re screening applications for suckiness.

So why do I love the approval process? Because it means that every application is tested and approved by Apple before I can buy it. I like to think of it as though Apple is the Maître d’ of a fancy, expensive restaurant, tasting every dish before allowing it to be sold to his customers. The more picky he is, the better the food will have to be.

Before I spend my hard-earned bling on a game, or an app, I want to know that it works properly. I want to know that somebody at Apple has tried the damn thing. Apple is actually making itself responsible for the user’s experience on the phone, whether on third-, second- or first-party applications. Can you imagine the kind of shit you’d be able to buy if they opened the floodgates and let any old developer release any old crap onto the App Store? There’s a store icon on the homepage of the phone, for heaven’s sake.

I guess the bottom line is that the people who benefit from the process are the ones who know nothing about it – the end-user – and so they never say anything about it. That means that all we hear about are the developers’ stories – and at that, only the negative ones. This selection bias is why the approval process has such a bad reputation. The poor thing needs a friend. Look, I’m sure you’ve had a bad experience with the App Store’s approval process, but try and remember us, the end-users. We love your apps, and we love our iPhones. The process isn’t perfect, I’m sure, but it’s there for a reason.

I am an iPhone end-user, and I love the approval process.

(I was going to write an article about the iPad, but there are way too many already.)

On Failure

Elliott Kember — Sun, 03 Jan 2010 10:50:51 +0000

I’ve recently been playing around with monetizing one of my applications: Filetweet. It’s a fairly simple application, designed to allow you to send files over Twitter. You may have seen it; some of you may have even used it.

It’s the first application I’ve built that I’ve tried to charge for – as an experiment. Using the excellent Spreedly service, and the not-quite-so-excellent PayPal merchant gateway service, it’s really easy to start taking money on a monthly basis. The only problem is, nobody is paying. I don’t think anybody will ever pay. It’s just not that viable a system for people to spend £5 / month on. There are probably even other services that fill the same gap.

But you know what? That’s okay. I don’t really mind if I don’t make any money on Filetweet. It’s supposed to be an experiment, which means that it will most probably fail.

One problem with this ultimatum is that I’ve used the wrong terminology. To “fail” is generally to experience no growth – failing to establish a user base, generating no profit, and not really fixing a problem are good general indicators of failure, and reasonably apt descriptions of Filetweet.

However, I think this terminology is wrong. It’s very depressing to fail, even when you’re expecting it. Every application I build, I secretly hope that it will be the next Basecamp. Can this repeated “failure” be any good for morale? I don’t think so – and I think my own point of view is to blame.

Perhaps on paper the project is a loss – but intangibly it’s a victory. It’s like, the opposite of a Pyrrhic victory, if there’s a name for that. The problem is, everybody tries to get things right the first time. There’s no margin for error. Every time you do something new, you’re trying to do it right – which is absurd.

As developers, in code, we prototype all the time: create a small, off-master experiment branch and try something out. Sometimes it works, but very often it doesn’t, and usually it’s never folded into the main branch, at least without some refactoring.

Why is it, then, that we place so much stigma on “failure” and “success” with individual business ventures, when so little is placed on the success or failure of individual parts of our code? I think the only way to fail from a project is to come away with nothing. If you learn anything, improve at anything, or streamline your development process, you’ve achieved something.

%h3 The Juice and the Squeeze

If the project were to succeed, would the payoff be worth the cost of failure? In ruby:

  def valid?
    return (failure.cost * failure.probability) > (reward - costs)
  end

Of course, it’s not that simple. Knowing the true cost of failure, and the true probability of failure, is a very difficult art. There are, however, several things you can take into consideration:

• Amount of maintenance required
• Any ongoing costs (hosting)
• Possibility of future feature requirements
• Complexity of the application

- all of which will add to the cost of either success or failure.

In Filetweet’s case, the answers are easy: not much maintenance, S3 means very little ongoing cost, feature requests are unlikely, and the application is not very complex at all. In actual fact, if this rings true – if the hard work involved is not very high, you might just be wasting your time trying to achieve success. Why?

Risk == reward

This is where it gets difficult. The more you put into something, and the more you stand to lose, the more you generally stand to gain. Conversely, it’s harder to risk nothing and hope to achieve everything.

But we’ve strayed from the original point of this article – the flawed concept of success. If we’re redefining success, we have to look at that formula again.

  def valid?
    failure = (failure.cost * failure.probability) 
    tangible_success = reward.tangibles - costs.tangibles
    intangible_success = reward.intangibles - costs.intangibles
    success = reward.intangibles + reward.tangibles - costs.tangibles - costs.intangibles
    return success > failure
  end

Even harder – since the intangible rewards are completely subjective. Intangible costs are generally your time, your sanity, and your hard work. The only way to really make this equation easier for ourselves is to do one of two things:

• Reduce the probability of failure, or
• Reduce the cost of failure, or
• Reduce the amount of time and effort you expend

Or,

• Don’t fail, or
• Fail cheaply, or
• Fail quickly

Fail cheaply and quickly

This point is the crux of this article. With today’s range of scalable hosting services – like EC2, and Heroku – and the number of VPS providers around – VPS.NET, Linode – you can really afford to fail cheaply. “Failure” in the commercial sense is immensely valuable – as far as I’m concerned, it’s the real shortcut to success. Any developer will tell you that learning from your mistakes is immensely valuable.

After I finished writing this article, I came across this, entitled “You will fail”. It’s a great article, and I think it expresses what I want to say. I guess what I’m doing is just pre-empting the inevitable.

Prototype rapidly, and fail cheaply and quickly, so when you’re ready to risk everything, you know what not to do.

If you have a good story about any of the failures you’ve been a part of, I’d love to read about them in the comments. You’ll have to log in with Twitter.

You'll never get what you want.

Elliott Kember — Sun, 29 Nov 2009 14:22:14 +0000

People sometimes ask me “How can I get good at programming?” “How can I get really good at Javascript?” The sad thing is, I don’t bother answering these questions any more. What inevitably happens is, I give people a list of things to read and try out, then come back 6 months later to find them in exactly the same spot. So what’s going wrong here? I think they’re after the wrong thing.

The problem here is that they know what they want to be, not what they want to do. The reason this is important is because there’s only one answer to these kinds of questions. Work hard at it. Do lots and lots of it. Do it every day. Do so much of it that it starts to affect you. The funny part is, by really enjoying what you’re doing, you inevitably get good at it. As they say, practice makes perfect. If you want to be a famous guitarist, you have to play and play and play guitar until your fingers bleed. Like Mr Olympia Ronnie Coleman says, “Everybody wanna be a bodybuilder; ain’t nobody wanna lift this heavy-ass weight!” You can’t really disagree with someone who uses 200-pound dumbbells.

At student conferences, people ask what they should do once they’ve finished University. Unfortunately, the best answers I can give are:

Don’t ask for too much money

There are loads of people coming out of Uni expecting a £38k salary. You can get it, but it won’t do you any favours. Either you’ll be unqualified for the job, or you won’t have anyone to learn from. Seriously, take a pay cut, for a year, and work hard under someone who’s way, way better than you. It’s kinda like an internship – you won’t get rich, but you’ll be better off for it. Plus, money is useful, but ultimately it’s bullshit. I’ve been wealthy and miserable, and I’ve been broke and happy. Key words here: “Shared accommodation.”

Take your time

Even when you’re blasting through a prototype, and you can get it done in a day, there’s still time to sit back and just think about it. In a way, rapid prototyping tools fail us here, because they encourage diving straight into development too early – especially when the whole team consists of one developer. Unfortunately, our brains don’t work that way, and you’re destined to forget something. I built a project recently which I nearly put live before I realised it didn’t actually have any navigation. Everything worked, but there were no links to get from place to place. I was rushing. Not only that – you never know where and when your ideas are going to come from. If you proceed slowly, I’ll bet you anything you have more ideas during development that you can then integrate, which is far better than tearing your whole application apart later on. Key words here: “Make haste slowly.”

Your code sucks.

If you think you’re a genius, that’s great. But you’re not. Even if you are, realise that you aren’t. Even if you actually are, keep it to yourself. Key words here: “Show, don’t tell.”

All code sucks.

The corollary to the previous point, this idea is meant to remind you that opening your source code is not the same as showing off your faults. The cool thing about the open-source community is that it’s helpful, not critical. If your code has some bits you don’t get, politely ask for help.

Enjoy it.

There’s no substitute for really enjoying what you do. You’ll be more productive, and people will want to work with you. Don’t complain about what other people are doing wrong, fix it. Try not to be negative about people, or code. If there’s one thing that’s certain in this industry, it’s that you’ll have to fix stuff you don’t like. So get used to it, and learn to enjoy it. Key words here: None. You’re getting paid to fuck around with computers. It’s awesome, and if you don’t like that, then you should do something else for a living.

Fix other people’s problems.

This is a business model in itself. Learn to enjoy solving other people’s problems. Notice how they react when you solve something, or when you give them something they can enjoy using – it’s really, really rewarding. Don’t get into tech support, though. Key words here: I’m trying to spin programming as altruistic.

Like I said, there’s no easy route. If you’re looking for the quick way to be well-known, or to be really good, or whatever – you’re looking for the wrong thing. Look for whatever makes you happy today, and tomorrow und so weiter. That’s what you should do.

Long story short, do what you enjoy. Do it lots and lots. You’ll get better at it. There’s no easy way to success.

Highlights of Buildconf

Elliott Kember — Sat, 07 Nov 2009 14:30:02 +0000

I’ve been at Buildconf for the last two days. It was one of the best conferences I’ve been to. So instead of writing a whole bunch of tweets, which would be annoying, I’ve decided to write a blog post with a list. To make it interesting, count up the number of points you can identify with and leave your score in the comments.

Finding out how to open bananas

Andy Budd getting his kit off to the Flight of the Conchords.

Wilson Miner showing us what Keynote can really do

Tim Van Damme dragging us to the waterfront to collect a Gowalla badge.

On that note, Gowalla. Seriously, I had to delete this shit before it got the better of me.

For the first time in history, the bar closed before the tab ran out

An Ulster Fry

@itsdavidhughes didn’t get kicked out this time

Eric Meyer.

Tim Van Damme is Ballmer insane

“There were some cute girls here, and then we told them what we do for a living.” #webconference #afterparty – #

Belfast museum’s giant deer.

Interesting and in-depth conversations with people who have no idea who you are

Guinness in Ireland is the best

The amazing, gravity-defying, impact-resistant laptop.

Late-night birthday Jager-bombs with @Fehler

A rough sketch of Tim Van Damme

There’s a reason Harp beer is free.

Nicklas’ Moustache Bonus points: Niklas’s Wild Man Moustache Wax.

You need a silly hat

Wanting, and yet not getting, a Build t-shirt.

Politics in the Speakers’ Club

All in all, #buildconf was pretty much the most rewarding conference I’ve been to in a while – buy your ticket for 2010. What other ones were there? 5 extra bonus points if yours gets on the list.

Announcing Chatrbox

Elliott Kember — Sat, 31 Oct 2009 14:04:06 +0000

As you all may have noticed, I’ve been playing around with some cool live-action stuff. At FOWA London, I built a live Twitter feed. The original idea was to build an app to complement HelloApp, a .NET site built by Carsonified for the FOWA conference. I was planning on using standard every-day Twitter polling to get the tweets from attendees, to get a “real-time feed” of the FOWA tweets. Along the way, I discovered two things; One: the Twitter Streaming API, which allows users to pull tweets straight off the Twitter “firehose” live-as-you-can-be, and Two: a way to stream content to the browser.

The secret behind all this is a great Rails plugin called Juggernaut – a push server that sends Javascript to the page using a Flash bridge. Built by Alex MacCaw, it’s a clever way of doing Comet-style long polling, but without the hackiness of long-polling requests. As much as I hate Flash, it’s great for opening sockets and streaming data – something I’m looking forward to with Websockets in HTML5. Long story short, tweets went from your phone to the big screen instantly. No polling, no waiting, just pure Twitter streaming fun. It was absolute madness – turns out it’s crazy to watch 700 people start posting their thoughts onto a massive projector screen. I even got dragged on-stage.

So why this belated post? As you may or may not know, I’ve just launched a new app: Chatrbox. Featuring the stunning design work of @dizzyup, it’s a live-action IM chatroom, featuring Twitter authentication and login. You can create rooms, invite your friends via DM, and talk to people like it’s 1999 and you’re hanging out in a Yahoo! chat room.

On the technical side, there isn’t much to the back-end. Messages are passed in and out using a very simple JSON API, and saved in a DB along with rooms. Messages are passed to the user using Juggernaut, and then rendered into HTML using jQuery. There’s a backup polling system for the iPhone, or browsers without Flash. Twitter is only for authentication, and for inviting others to join in.

The cool part, I think, is the front-end. I’ve been taking advantage of jQuery as usual, and it’s been seriously fun. Before now, most of the Javascript i’ve hacked together has been fairly procedural – except for my Snake plugin, which I rewrote in OO code (I should definitely release that as a plugin some day). This, though, was a lot of fun. Safari and Firefox both have ridiculously fast Javascript engines, which means that you’re free to pretty much do what you want in Javascript. The code behind the app is all-Rails, the code in front is all-Javascript. We don’t need no steenking templates! In fact, there are no HTML templates for messages whatsoever. Everything’s handled by Javascript.

Javascript as a templating language is great for post-render updates. I don’t have to tell the UI where a message should go – it looks at the message’s room_id and inserts it accordingly – which means I can have “unread messages” notifications pop up. Instead of using the HTML as a database, and jQuery as a query system, pulling stuff out by class and ID, I can do it backwards – maintain my data in Javascript objects, and render to HTML.

Unfortunately, this means that the app doesn’t degrade. If you’re not using Javascript, it just plain won’t work. I can’t see myself ever making it degrade, either – it’s not that kind of site. Short of an all-Flash UI, there’s just no feasible way to do chat without it. If you want to disable Javascript, that’s fine – but you’re going to re-enable it if you want my stuff to work. Javascript is just as necessary as CSS.

So there you have it – a fun, interesting, Twitter-based chat room. I’m planning on adding file-uploading, private rooms, and a few other cool features that may or may not be paid-for. For now, though, I’ll be happy if everyone gives it a go. Also, don’t forget to leave a comment below; it makes me happy when people comment :)

Photos by Yaili and Chegs on Flickr, screenshots by Yours Truly.

I forgot to eat lunch yesterday.

Elliott Kember — Fri, 09 Oct 2009 12:03:02 +0000

Writing code for a living can be a bit depressing at times. It has a lot to do with the fact that it’s a sedentary, and often lonely occupation – especially if you work by yourself, for yourself. Lonely hours at a computer screen does wonders for the soul. However, I think it’s important to remember something:

Programming is fucking awesome.

There are a lot of reasons why this is a popular belief. You’re in charge of a system, and you have to make it work. There are elements of problem-solving, challenges, difficult bits, and best of all, new stuff comes out all the time that makes your job easier. What other craft can enjoy those benefits? Not only that: we’re important. We’re put in charge of critical applications. We do things other people can’t. I’ve heard programmers described as tiny gods, which I think is a pretty apt description.

However, to exempt this post from being just another lousy “isn’t programming awesome?” post, I figured I’d explain exactly why I think it’s fun. And when I say why, I mean physiologically. For science!

The best analogy I can give for programming is flying a plane. When you’re flying, you have to concentrate – or else the plane will crash. This means you have to forget about other things, and focus all your attention on keeping the damn thing aloft. You become a part of the process – a symbiosis of man and machine. You have a purpose, and a goal – and everything else is momentarily put aside.

Better yet, playing a musical instrument. If you lose focus, you’ll get something wrong and ruin the performance. It’s very hard to regain your composure after a mistake. I think the same thing happens when you’re building something. If you lose concentration, you’ll lose your train of thought, forget where you are, and have to start all over again. It’s “being in the zone”.

As any Neuropsychology student will tell you, when you concentrate on something, your breathing becomes rhythmic, and your brain’s beta frequencies increase. The funny thing about beta waves? From Wikipedia: “Rhythmic beta with a dominant set of frequencies is associated with various pathologies and drug effects. For instance, beta activity can be accentuated by sedative-hypnotic drugs such as benzodiazepines or barbiturates”. Concentration = hypnosis!

Personally, I think the breathing is behind all of this. Any time you alter your breathing, you mess with your feelings. That’s why you take ten deep breaths when you’re angry. Religion does this; many religions have some form of breath control, be it singing, dancing, chanting, meditation… you name it. Could the entire idea of a “higher power” be caused by misinterpreting the feelings your brain’s activity gives you during measured, controlled breathing? It sounds possible. Funnily enough, the word “spiritual” derives from the latin spiro, which means – you guessed it – to breathe. It’s my favourite theory.

Some evidence suggests that beta waves are good for you, too. This page says “People who have increased their beta Waves have been known to increase their I.Q. and productivity. beta Brain Waves have also been associated as being a natural antidepressant”. Remember, you get paid for this.

The best thing about the trade, as far as I can tell, is that it’s one of the few professions where you get to be “in the zone” for extended periods of time. So much so that we forget to eat, or become oblivious to our surroundings. It’s a little like being in love.

Programming a fairly left-brain exercise – logical and rational, perhaps even robotic. It’s very rare to see creativity and art in programming. _why was an exception, and I miss him dearly. But, in my experience, there’s a real similarity in the feelings between writing some particularly elegant code, and playing a complicated piece of music. Hell, if I didn’t get paid to write code, I’d do it anyway.

When you feel down about what you do for a living, consider this: musicians only get to be “in the zone” for the length of a piece of music. Even pilots don’t get to be “in the zone” every day. I’d be very surprised if business people really get to feel this kind of “in the zone” at all – no matter what they say.

Release open, release awesome.

Elliott Kember — Sun, 06 Sep 2009 10:35:32 +0000

In December last year, I built my own personal site to advertise my new-found employability – www.elliottkember.com. Then, looking at my twitter background, I figured it’d be cool to have a similar image on my own site – a bit of continuity. Then, I was talking to Greg Annandale when a thought occurred to me:

Why not turn that sexy curl into an adjustable feature?

Well, about 20 minutes later I had it working, pending a few tricky bits:

But nonetheless, I had a working curl. You can check it out on my site.

Even Ryan was impressed:

The code wasn’t very elegant, or configurable, and I hadn’t made it very easy to implement, but the thing worked. I went ahead and linked it to everyone I could find to get them to check it out, and I got a little bit of traffic:

At the time, the wonders of relative scale told me that this was a good thing. But as it turns out, it was nothing to write home about. Yet.

My good friend Rey Bango had an idea:

Why not make my fold into a plugin? I sat on the idea for a while, but decided that I didn’t want anyone else having my cool effect. I wanted it all to myself. On one hand, I use many open-source products day-to-day. My job wouldn’t be nearly as fun or as easy as it would if everything were closed-source. The shared contributions of many contribute directly to my own personal gain. On the other hand, I reasoned, why should I let everybody else profit from my hard work, and share my effect?

I agreed with open-source, I decided, but only when other people were releasing things – in other words, I only agreed with open source when I was the one profiting from it.

A bit later, I was cruising around the internets when I found, in a list of javascript effects, a link to this: a page curl jQuery plugin! After checking the source, and discovering that it wasn’t a copy of mine at all, I pondered how he’d made it onto this list. After all, lists are the backbone of the internet. Get on a list, and you’re set for life. #naiveté.

The answer was simple: This dude release the script as a plugin.

Yes, that says 2AM. That’s the last timestamp I’m going to show. Incidentally, I was wrong when I said “copycat” – that URL clearly shows a date of the 15th of December – two days before I made my page curl. Great minds, etc. I reconsidered my stance on a jQuery plugin.

Should I do it, I asked myself? Should I release this into the wild, destined to be my glory or my shame? Am I releasing the next useless gimmicky, showy, tacky Javascript effect for people to complain about?

Hell yes. Let’s do it. First off, though, I had to refactor my code. I wasn’t having my sloppy mess of javascript sitting around cluttering up the web. So I cleaned up my code, and with the help of a few articles, I turned it into a plugin. This is not a difficult task: I can’t remember which I used, but there are 527 Google results for “your first jQuery plugin“. Pick one – it doesn’t matter which. If it sucks, pick another one. Welcome to Google. If you’re actually reading this article, leave a comment with the code words: “rock you like a hurricane“. That way I’ll know.

Now for the important bit: what should I call it? Adam Cooke and I pondered the issue:

Clearly, this name wasn’t awesome enough.

And with a GitHub repository, the Sexy Curls jQuery Plugin was born.

I spewed some of my trademark absurdity into HTML form:

And I passed it on:

Now, Rey tweeted it from @jquery – and here’s that tweet preserved for posterity:

Instantly, some 3,000 hard core jQuery nerds heard the word about my plugin. RT after RT, FWD >> FWD, and so on. Quietly, my plugin propagated around the internets like W32.Blaster. You can watch the tweet stream – it’s still going. I graced the front pages of Ajaxian, YCombinator News, hit #9 on Del.icio.us, and countless other aggregators. Help even came from other GitHub users – Cheeaun was nice enough to give me a hand.
I also surreptitiously included a link to my Twitter page in the first line of the page. As usual, the internet is just my big race for followers.

What did that do to my analytics?

That’s insane. My pageviews were up by about 2,000%. That’s not all Sexy Curls traffic, either – although it pretty much mostly is.

That’s wa-hay above normal – which means people are clicking through. My name is getting out there.

That’s the content for sexy_curls.html – loads of pageviews, a strangely high time-on-page, and somehow I have made 8 cents. I look forward to receiving it.

As usual, a high Firefox/Safari split. I’m proud of my visitors! Somebody also tried to use their PlayStation:

But I haven’t heard back on whether the curl worked. Even the Googlebot is rendering Javascript these days:

So I guess it’s been checking out my curl, too. Hope it liked it.

What did I learn? Open Source isn’t just kernel-hackers in their parents’ basements. Open Source is everywhere. Anything you do can be open-source. So, if you aren’t already, release stuff. Release good code, release bad code, it doesn’t matter. It’ll end up being better than you could ever have intended. Use other people’s code – FIX other peoples’s code.

So far, there haven’t been many reports of sites using the Sexy Curls plugin. But that’s okay – it did what I intended it to do. It sparked ideas, made a few gaze in wonder, touched the corners of the internet far and wide, and maybe – just maybe – it inspired someone to start writing code.

Code is like a magic penny – write it once and you don’t get any. Lend it, send it, give it away, and it comes right back to you.

On Usability

Elliott Kember — Sun, 06 Sep 2009 05:55:53 +0000

I’d appreciate it if you read this entire article before commenting.

So there I was, in a RyanAir Boeing 737-800 coming back from FOWA Dublin. Having just spent three days partying it up I was a little under the weather. It was late, it was raining, and I wanted to sit ~~back~~ bolt upright, read my Jeremy Clarkson book and drink my €5 Coke.

During take-off, the crew turn off all the lights in the cabin. I like to imagine this is because the pilots think it’s more fun taking off in darkness. I was surprised, though, to hear the sound of chimes from all around me, as passengers pressed the “I need a napkin” stewardess button. Were they so frightened of the dark that they wanted a hug and a €3 cookie? I shrugged it off, and reached for the light-switch so I could continue reading.

I was confronted with this:

That’s right – the buttons have no lights on them. So, when the cabin lights are out, you can’t see which button does what.

Now, the 737 is a good plane, built by clever engineers, and even when bought by the lowest bidder and covered with advertisements, it’s still an engineering miracle. It weighs 80,000kg and is capable of carrying 189 people 5,600km at Mach 0.8, which is no mean feat. Clearly the people who made this machine know what they’re doing. So why couldn’t they, at a cost of about €5 per seat, light up the buttons on the ceiling? I don’t know, but I have my own theory:

Usability is difficult.

As with many things, usability comes from a military background. The concept was invented during the course of World War 2, when the Americans realised they were blowing themselves up with grenades a bit too often to be statistically viable. So they streamlined the product, gave their chaps instructions like “throw it toward the enemy”, and then, as far as the film industry would have it, proceeded to stomp all over Europe smoking cigars and shouting at one another. The P-51 Mustang was a miracle of simplicity too – by reducing the number of switches and dials and buttons, they let the pilot concentrate on what he was doing – which is vitally important when you’re whizzing about over France upside-down at 700 miles per hour.

So clearly, removing things is the shortcut to usability. Everybody’s heroes, Apple, Google, and 37Signals do this to great effect. The fewer buttons I have on my page, the more I start to feel like that Mustang pilot. My Macbook Pro is the Cadillac of the Sky.

The problem is, though, sometimes just removing things isn’t the whole answer – as with the 737 and its buttons. Usability is something that you need to study, and practice, and think about. It doesn’t just happen.

This brings me to Balsamiq. Sure, it’s a great tool, if you like post-it notes and Comic Sans. Okay, it lets you build mockups of your websites that look like drawings. But let’s remember one thing: it doesn’t necessarily mean you know what you’re doing.

I understand what the tool is for, and @balsamiq verified this for me: creating 5-minute mock-ups that can be thrown away. But that’s ALL it’s for. It’s really, really not for full-scale wireframes. If you think about this, it’s obvious. You don’t get to re-use components, there’s no layout grid to speak of, and you can’t save files together in a folder-type-arrangement. The tool simply wasn’t designed to do these things, because it’s not meant to.

But the problem is, it’s available to the masses. And that means people are going to start using it. It gives people the illusion that they know what they’re doing. Being a child of the internets, I couldn’t resist but make a funny image of this, complete with Impact writing. Now, if I were really mean, I’d use it. But I won’t. Well, I’ll use it satirically and then apologize, because that seems to be the way of the bloggers these days:

Thankfully, you’re reading this ENTIRE article instead of just looking at the pretty pictures. Right? Good. You won’t be offended, then, because that image is just for satire purposes – a cheap laugh, and a cheap shot. I’m sorry! I should write for TechCrunch.

The problem is, as I was saying, that your clients are about to start doing usability. They’re going to start doing your job. I’m not concerned about the money involved here: FrontPage, Dreamweaver and .NET have been around for years and I’m still making internets. I’m really more concerned about the quality of what you’ll end up producing, in the same way I love finding MM_* functions in websites that I pick apart. When you lower the barrier to entry, people start using simple products for complicated things – and then you end up with crap.

You can’t tell the client that, either, because they’re proud of what they’ve done. They hand you their stack of .bmml files with a big smile, like a 5 year old who’s finished a drawing. The only difference is that instead of just sticking the drawing to the fridge and giving them a chocolate bar from the Treat Drawer, you’re supposed to publish the drawing, put your name next to it, and then accept the criticism. You don’t want to tell them that what they’ve done won’t work, because you’ll break their hearts with the sad truth, and they’ll go off and find some other poor sap who’ll knuckle down and produce it.

If a client comes to you with a mock-up of their website, that’s fine – they’ve thought ahead and given it a shot. Now, when you apply yourself to it, you have something to work from – and even if you go the other way, you still know what you’re avoiding. But if a client comes to you with their own full set of wireframes, what on earth are you supposed to do?

@ balsamiq is a very clever, and friendly chap, and his product is cool. I like where he’s going with it. What I’m trying to say is that the problem doesn’t lie with the tool – it lies with the way it’s used. The bottom line is: be careful. Just because you can do something, doesn’t mean you can do it right.

In fact, there’s a whole talk I’ve got planned based on that very concept – and I’m trying hard to get to speak at a Future of Web Apps event. Shameless plug? Me? Never. Anyway, it doesn’t matter, because you’ll have stopped reading at the last image and proceeded straight to the comment form to rant at me for being nasty. That’s the beauty of the web – everyone can have their say.

Image credits: Usabilitylabrental.com for the cockpit photo, farmerdoodah on Flickr for the upside-down Mustang, and @elliottkember for the satirical internet image.

Speed: The Secret Code of the Baristi

Elliott Kember — Sun, 06 Sep 2009 05:55:35 +0000

The other day I was in the local coffee shop dealing to my addiction. I couldn’t help but notice that the guys behind the counter were speaking in a foreign language. We’ve all heard this language: “Double cap out, no foam”, “Chai mocha skinny half with space”, “Moon unit alpha, tennis elbow”. It sounds like some kind of indecipherable language – the secret code of the Illumilatté, if you will.

I realise, of course, that these contractions are inevitable when you’re performing a task over and over again. To bring it a bit closer to home, they’re like keyboard shortcuts. But really, I’ve never seen any barista actually save any time by leaving off the “-puccino”. So what’s happening here?

The answer, of course, is perceived speed. It doesn’t actually have to save any time, as long as it gives the impression of saved time.

A good example is this: setting your microwave for one minute and eleven seconds actually takes less time than setting it for a minute flat – because you don’t have to move your finger from the 1 button. 1-1-1 is much easier to type than 1-0-0. Of course, the microwave will be running for a good eleven seconds more, but you aren’t sitting there watching it for eleven seconds – you’re off dicing and slicing, or whatever people do when they cook. I cook by phone.

A lot of this stuff has to do with efficiency of data structures. If you keep all your receipts, you put them in chronological order when you store them, right? Each one has to go into its alotted position. Would you design a data structure like that? A lot of expensive writes? You only ever pull all your receipts out of the box once a year, so that read action can afford to be slow compared with the hundreds of writes you might do. You should throw them into specific boxes (heh, sharding) and sort them in one go later on, or once a week or whatever. It’s like a cron job.(00 18 * * sun ./tidy_room.sh).

I was reading a great article the other day at Assert True which says that twice-as-fast isn’t good enough. A speed-up factor of 10 is what’s required to really make any difference. That really only applies to foreground actions – which are high in cognitive interaction. If something locks up my computer, then a 20-second lockup and a 40-second lockup are pretty similar. They both interrupt my computing experience, and generally tempt me to wander over to the coffee machine.

What I’m effectively doing here is backgrounding the process. It’s still happening, it still takes time, but it requires none of my cognitive space. I only notice something’s happening when I’m actively waiting for it – and in this instance, I’m not. So if the application backgrounds the process for me, it’s doing exactly the same thing. If I can use the rest of the computer while it does its thing, then my workflow is pretty much uninterrupted.

This is why background processing is such an awesome tool. If you have to do 10 non-urgent things when an action takes place, put them all in a queue and report back straight away. This is for more than just server-client requests, too. For example, when I was building Twiggy last week, I found that the jQuery remove() function was really slow at removing all the tweets from the results page. That meant that when a new search took place, the whole application would lock up while jQuery cleared the list. Empty() and .html(”) weren’t fast either. Nothing would make this bit of my application run more quickly.

What was fast, though, was adding a ‘hidden’ class to the tweets and hiding them. That was instant. So, the trick was to hide the old tweets and conduct the search. Now, when a search is conducted, the delay is huge. There’s at least a 3-second gap between clicking search and having the results available. The difference is, this dead time is expected. So I told jQuery to remove all old tweets during this searching process. It locked up the phone for the same amount of time, and probably added to the total search time. But when you’re waiting for the results to come back, you know you’re going to be waiting anyway. The really important thing is that hitting the “search” button has an immediate effect. The old results disappear, and the “searching” text comes up. Things are happening. Happy user!

In interaction science, we’re told that the human brain needs less than 50ms response time between an action and its perceived reaction. Any longer, and it feels as though the system is lagging behind. Symbian, buddy – that’s you. That’s why the ubiquitous AJAX loading gif was invented – it doesn’t actually tell you anything. There’s no indication of how long the action might take, but the main communication is there – something is happening. And that’s important. You’ve acknowledged my request straight away, and told me you’re working on it.

In truth, the difference between the tweet-clearing and the asynchronous searching can be huge. On a cellphone, where latency is really high, the searching might take 10 times as long as clearing out all the tweets. But that’s fine – the user knows this. What I can do, therefore, is hide all the other slow interactions inside this searching query, where they pale into insignificance. Better yet, I can spread the invisible functions out during the course of the application’s usage. If I remove a hidden result every half a second, it takes almost no time at all. It’s effectively a process queue.

So if your app does loads of stuff on a request, like emailing 10 people, or processing credit card stuff, or generally doing ANYTHING with the filesystem, run this process in the background. I use BackgroundJob in Rails for its simplicity, but there are others like BackgroundFu and Starling that have other feature-sets. Some can use multiple processes to run the jobs, and some are kept in memory. Pick the one that suits your jobs best. http://wiki.rubyonrails.org/howtos/background-p...

Either way, remember to keep stuff as snappy as you can. This is an optimization, and premature optimization is the root of all evil – so remember to do this reactively once people are using your application. It’s really just intelligent optimization – instead of spending hours speeding up your code, just leave the stuff that doesn’t need to be done straight away until later, when it can be done in the background. Uploading to S3, rotating and cropping images – there’s loads of stuff. If you have a process that generates big ugly graphs, make it run once every six hours, and memcache the result – because there’s nothing worse than a 15-second page load.

All you need to remember is this: perceived speed is the only test of speed.

Photo: Burt Munro (Anthony Hopkins) on an Indian Scout from here