andyhume.net

This is a short comment on Ted Dziuba’s version of why MacOS X is an Unsuitable Platform for Web Development. Ted is right and wrong at the same time.

Unless you’re building the simplest of web sites with static pages or just PHP you shouldn’t develop on OS X. I used to. I used to compile MySQL and Apache from source, upgrade Python, install Django and a bunch of other Python tools, and leave myself in a hell of a mess, because yes, package management on OS X is a pain in the proverbial. And I hated doing this on the same machine that was my primary machine for email, web browsing, and other ‘desktop’ type tasks.

The obvious solution to this is virtualisation. Using Parallels, VMWare, or VirtualBox (my current choice) you can spin up as many sand-boxed environments as you like (which is why I don’t find much value in virtualenv). Using the same mechanisms you use to create production machines will get you most of the way to a development machine. Take a snapshot of that (or better still, use something like Vagrant) and you’ve got re-usable and shareable development images.

Why is this good?

You’ll catch bugs early. By developing code in an environment that closely matches production you’ll develop code that is more likely to work in that environment. You’ll get less bugs reported to you when your code moves into staging, or worse still production.

You’re sandboxed. You can feel free to install whatever dev tools you want on that machine, with no danger of screwing up your main desktop machine, or bloating it with crap you don’t need. Secondly, if you need a different environment for different projects you don’t have to manage them within one OS. I can’t imagine the hell on earth I’d go through to setup Apache with one lot of virtual hosts pointing at Python and Django, others pointing at Ruby on Rails, etc… all on OS X, where I write my email and sometimes open things like Photoshop and Fireworks.

You can still use OS X editors. I normally use Macfusion to mount appropriate directories of my VMs on OS X, so that I can use Textmate and other OS X tools to edit and manage code. I’m sure there is a better more fashionable approach than Macfusion, but I’m a creature of habit and it works for me.

The best thing about this is, despite OS X being an unsuitable platform for web development, you can still use it as your primary OS. It is a better, more stable, more pleasing and usable platform than any version of Windows or Ubuntu Desktop.

When we had new people joining at Multimap (or ‘onboarding’ at Microsoft) one of the initial big hurdles for them was learning the ins and outs of the approximately 30,000 lines of JavaScript that powered the site.

One thing I used to recommend people do was to turn on a little event logging switch we had in the code that logged to the console every event fired. The application made heavy use of custom events, so by watching these events occur in real time as you navigate and use the application, you can get a pretty good insight into what is going on in the guts of it. For example, a typical output might look like:

dragStart
dragEnd
mapMove
locationUpdate
geocodeSend
geocodeReceive
adUpdate
searchSend
searchReceive
panelOpen

Not only does this give you a broad overview of what might be going on, but knowing the names of the events gives you a starting point for jumping into the code. You can now search and find the module that triggers that event, as well as every piece of code that is listening for it and waiting to do stuff.

Recently I wanted to do the same thing in another JavaScript application which is using jQuery to do its custom events.

The above code monkey patches jQuery’s trigger event and logs the name of the event to the console. It doesn’t work for the browser’s built in events, (which is probably fine as you generally know what browser events are occurring), but it does work for all of jQuery’s built in events and any custom events that you trigger yourself.

I think this is a helpful way of starting to learn a codebase. In this case, it’s not so much new people joining that might benefit, but a client’s development team who’ll be taking this over eventually.

I’ve heard a lot of people recently describing HTML5 localStorage as being a replacement for cookies, or cookies on steroids. Even the masterful Bruce Lawson said pretty much this in his fantastic Web Anywhere talk at SxSW last month. I cringe every time I hear someone say this as it’s such an obviously dumbed down version of reality.

So, to state the obvious…

Cookies are small pieces (about 4 KB max) of data stored on the client which are sent in the headers of an HTTP request to the server, typically to allow for sessions or some other kind of state to be handled across requests. They contain expiry information and are typically created by the server using HTTP headers. There is also a JavaScript API that lets you access and edit cookies, although the less said about that the better. Cookies will continue to be a critical part of your web applications despite the introduction of localStorage.

localStorage is a persistent key-value store in the browser with a full JavaScript API to set/get/remove values and events to track changes programatically. It typically allows for up to 5MB of storage, although this can be increased at the user’s discretion. Data in localStorage isn’t sent to the server as it is with cookies.

localStorage allows for a whole range of uses that cookies do not, and cookies allow for a whole range of uses that localStorage does not. There is admittedly a small area of cross-over, but explaining it in those terms is backwards, hugely undervaluing the scope and importance of localStorage, and frankly condescending to the people you are explaining it to. Please stop doing it.

The next time you’re called to simply explain localStorage or sessionStorage in HTML5, don’t mention cookies. Just simply say, “localStorage is a powerful key-value store in the browser which you can access through a JavaScript API.”