Archive

Archive for June, 2011

You should learn to type (properly)

June 18th, 2011 20 comments

The Typing of the Dead screenshot

As a developer, my job is to make software. To start off with, this software lives only in my head. Programming is the act of extracting the software out of my head and into the computer. The keyboard is the interface between my brain and my computer. There are times when I’m primarily thinking, and my speed on the keyboard doesn’t matter. But when a thought comes to me, I want to get it out of my brain and into the computer as fast as possible, or I might lose it. I need a high-bandwidth connection.

If you write code and you’re not touch-typing, I don’t think you’re taking it seriously. Touch-typing is one of the easiest things you can do to level-up as a developer – the return on investment is massive.

The keyboard is your primary tool as a developer, and you should wield it like a sword.

Also, if you ever end up in a situation where the world has become infested with zombies, and the only way to kill them is by typing at them, you wanna make sure you’re in with a chance.

How do I learn?

By now, I’m really hoping I’ve convinced you to give touch-typing a go. Now, here’s the good news: it’s easy! It takes a bit of time to master, but nothing like the effort that goes into learning a new language, framework, or pretty much anything else.

GNU Typist

The first thing you should do is download GNU Typist. Complete all the lessons in the first course (Series Q – Quick QWERTY course). Make sure you use the fingers it tells you to use for each key. And whatever you do, don’t look at the keyboard. I’ve heard that some people find this so difficult they put a towel or a piece of paper over their hands so they can’t see. If you’re looking at the keyboard, you’re doing it wrong. Even if there’s one key that you keep missing, the only way to learn is to keep on going until you get it right. Next time you get to that problem key, pause, breathe, and press it (use the Force). If it’s wrong, pause again, breathe again, and press it again. Eventually you’ll have spent so much time thinking about the position of that key that you’ll never have to think about it again.

Now, this is the hardest bit. Once you’ve finished those lessons, touch-type everything. Whether you’re writing emails, programming, working at the command line, googling, chatting, or anything, make sure you’re doing it like GNU Typist taught you. This is hard, because at this stage you’ll be slower than you were before. It’ll be so easy to lapse back into your old habits, so you need to be strict on yourself. Any time you start to look down at the keyboard, stop. Any time you start to use your index finger to type a character that your middle finger should be typing, stop. It takes a few days of this before you start to notice that you’re typing faster than you were before. But that point will come, and from then on, you’ll get faster and faster.

Next steps

This is the perfect time to start playing on TypeRacer. TypeRacer pits you against other typists over the world. It’ll only put you up against others of a similar speed, so you definitely won’t be the slowest there. It’s a lot of fun, and great practice.

The Typing of the Dead box

Another good one is The Typing of the Dead, if you can get your hands on a copy. If you’ve ever seen The House of the Dead, it’s like that, except you walk around with a keyboard killing zombies by typing. Seriously. It’s a great game, but beware – you don’t have to backspace over incorrect keypresses, so you’ll need to be careful or it could adversely affect your accuracy.

Once you’ve got your head around touch-typing, you may want to have a play with Vim or Emacs. They’re both well suited to touch-typists, as all the important commands lie under your fingers without having to move your hands, unlike in other editors (e.g. Page Up/Down, arrow keys, and, god forbid, the mouse).

I really hope you do give this a go, because it really will help you to improve as a developer. And if you don’t want to improve, what’s the point? Good luck, and let me know how it goes.

Categories: Miscellaneous Tags:

The Ruby world is nuts

June 8th, 2011 10 comments

Apparently they started out using God, but switched to Bluepill due to its ability to monitor child processes, such as things spawned by Unicorn.

From Episode 166 of The Ruby Show.

Categories: Programming Tags: ,

JavaScript, JSON and modern web MVC

June 2nd, 2011 7 comments

As web developers we’re working through a transitionary period. New technologies are becoming widespread enough to be usable in real web apps – not just toys. After years of stagnation in JavaScript engines, Google Chrome started an arms race in speed, with all the major browser makers competing to make the fastest JavaScript interpreter. These changes are opening up a new world of web app development that hasn’t been fully explored yet, but this means we may have to rethink some of the best practices we’ve been following for the past decade.

MVC today

In a modern web application framework, MVC is well defined: requests get routed to a controller, which requests data from the model (which is probably using an ORM) and instantiates a templated view with this data. This view is sent as HTML to the browser which creates a DOM from the HTML, and renders the DOM (with CSS and images) as a web page.

JavaScript then operates on the DOM, adding a layer of interactivity to the page. As things advance, the JavaScript layer has taken on more importance, reducing the number of page reloads by selectively reloading parts of the page with Ajax.

As the complexity of JavaScript on the client has increased, it’s been easy to end up with unstructured spaghetti code based around the jQuery model of “find something, do something with it”. As more state has moved to the browser, MVC frameworks for JavaScript have stepped in to add structure to the code. The problem is, now we have two MVC stacks:

Current JavaScript solutions suffer from "Double MVC". You need both server and client-side MVC stacks. Conceptual complexity is very high.
@dhh
DHH

MVC of the future

MVCMVC or MMVVCC aren’t just un-catchy, they’re a rubbish idea. If we’re going to make rich apps that rely on JavaScript (and as I said previously, I think we should), we need to lose some redundancy.

The model will usually be accessing some shared database, so in most cases it makes sense for this component to be on the server (authentication usually lives here as well). The view is the DOM, and the controller is the JavaScript. There’ll also need to be model code in the JavaScript – the extent to which the model logic is split between client and server depends on the application.

All the server needs to do is provide JSON responses when the client asks for more data, ideally using simple RESTful resources.

One benefit of the server being a simple JSON store is that it enables us to easily add redundancy to our apps – if server1 fails to deliver a response, fall back to server2.

No more HTML

The DOM is the means by which we display our app to the user. The browser thinks in terms of the DOM. HTML is just a serialisation of the DOM. Modern web app developers shouldn’t be thinking in terms of HTML. HTML is the assembly language of the web, and we should be working at a higher level of abstraction if we want to get stuff done. Most of the time we should be thinking in terms of layouts, widgets and dialogs, like grown-up UI designers.

The problem at the moment is that HTML is being used as a combined data and presentation format, and it should be obvious that this is a Bad ThingTM.

Of course at some point we’ll need to go down to the level of the HTML, and at that point we should be using templates. jQuery.tmpl is one (see my slides and presentation on the subject), but there are many others too. One interesting development (thanks to James Pearce for putting me onto this) is Model-driven Views (MDV).

MDV links JavaScript objects to the DOM in such a way that any changes to the object are automatically reflected in the DOM, and likewise, any user changes to the DOM are automatically reflected in the model objects. Hopefully this will become standard in modern browsers, as it provides a clean and easy way to keep the DOM up-to-date with the model objects without endless wiring, which again helps to insulate us from having to deal with too much HTML.

I’m not suggesting that HTML will go away, or that developers won’t need to learn it – just that most of the time, most developers won’t need to be worrying about it, just like most of the time, most C developers don’t need to worry about assembly code.

Conclusion

Most web-apps are currently halfway there in terms of moving functionality to the client. The problem is that we have ended up in the worst of both worlds as app developers. Our serverside MVC framework provides a nice template-based abstraction over the HTML, which we then break apart on the client. We’re forced to work at too many different levels of abstraction simultaneously, which is never a good thing.

Things were simple when everything happened on the server. Things will be simple again when everything happens on the client. Over time new tools and best practices will emerge to encourage this new way of working. In the meantime, it’s going to take a bit of extra effort, but it’ll be worth it.