After working creating websites full time at Netsight for a few months, I’ve started to build up a toolkit of apps and sites which I find myself repeatedly using.
The raw tools through which my blood, sweat and tears flow to create websites. The connection between my mind and the text your currently see. These boys are the big guns.
There’s something about vim which sets it aside from other editors. It’s the way vim feels like it was designed to allow you to bash out text as fast as damn well possible. No distractions. No toolbars. No pussy-footing around between you and your characters.
I couldn’t live without vim’s window/split functionality. While tabbed editors let you work with multiple files one-by-one, windows let you work with two at once. Or three. Or ten, if you really must. Often CSS, JS and HTML form interdependent parts when creating dynamic effects on a webpage. With vim, I can have all three visible at the same time, so it’s easy to look up a particular element’s id when creating a CSS or jQuery selector.
Vim also has syntax files for almost every language known to man, and its hyper-efficient editing toolset works perfectly in each. That I can also easily share my configuration using Dropbox seals the deal.
Firefox needs no explanation, and the wealth of tools I have brought into my environment via the brilliance of Firefox extensions will probably get an entire post of its own.
One worth mentioning today, however, is Firebug. I’m truly convinced that most of the great webapps available today owe their existence to Firebug. Creating complex web-based applications is made possible by tools like this. Firebug shortens debug cycles significantly with its suite of web debugging tools. If you are building websites without Firebug—or another browser’s equivalent—well, you probably shouldn’t be building websites.
A few other applications crop up day in, day out, but are not quite so constantly essential.
My work with Zope requires frequent use of the terminal application, and Apple have done a pretty good job implementing this. The Windows terminal, at least in XP, was a
joke piece of crap.
I think programming more than most other professions is affected by the ready information access and, significantly, publication the web allows. Programmers are, in general, quite willing to help each other. The ease of publishing via blogs combined with the fact that it’s remarkably unlikely you’re the first person to hit your particular problem means help is often a web search away.
In addition to the hundreds or thousands of blog posts which have helped me on my way, there are several sites often open somewhere in my tabs.
I’m surprised to see less noise made about this great resource. Most CSS properties are exposed, together with good documentation, examples and compatibility charts. It’s an essential reference work.
Mozilla also have an HTML reference, but it is not nearly so complete.
The jQuery documentation is some of the best around, succinctly and clearly explaining the features of the library. It helps that the library it documents is well thought out, as it provides a good skeleton IA for the documentation to be placed into.
It would be great if this quality documentation extended to the libraries built upon jQuery. Perhaps an area for the jQuery team to look into in future is making it easier for plugin authors to generate documentation, by providing equivalent tools to the JavaDoc toolset.
The best reference to the HTML specification really is the specification (HMTL 4 and XHTML 1) itself, but it’s not the best guide to the implementation support levels and quirks. I’d like to see something like the Mozilla HTML developer site to step in to fill this role.
For this, I turn to Quirks Mode with it’s great big charts full of red and green.
Update: I’ve rediscovered the SitePoint reference pages. Their HTML reference is just the ticket.
And there you have it.