Code starts in a text editor. Your text editor might be a full IDE, custom built for your language, a vim window with more commands than you can remember, or an emacs with more metakeys than you have fingers. Nowadays, it might even be a window in a browser tab, but that’s always given me flashbacks to deploying software by pasting lines into textareas in Zope, but the lines I type are in a text editor, and currently that’s Sublime Text 3.

I used Eclipse, Netbeans and Aptana and variants on the Java-based juggernaut for years, but partly because my main development languages are PHP and Python, it never really worked that well for me. My primary development OS is OS X, on by beloved Macbook Air, but I don’t want that to matter at all. I use SublimeText because it has plugins to do most of the things I liked about IDEs (SublimeCodeIntel, some VCS plugins, and a small host of other things) and it works the same, and looks the same, across every OS I use day to day. I’ve got my prefs and package lists syncing via dropbox, even, so the plugins stay the same.

I work as a contractor for hire, most of the time, and I’m terminally addicted to new projects. So I’ve generally got upwards of a dozen different development projects active at any one time. Few of them use the same language/framework combination, and all of them need to be kept separate, and talk to each other only in the proscribed ways. Moore’s law has made that a lot easier with the advent of things like Virtualbox being able to run several things at once, but getting those all consistently setup and easy to control was always a bit of an arse. Vagrant is my dev-box wrangler of choice right now. It could do a lot more, but mostly I use it to get up and shut down development VMs as I need them, safe in the knowledge that I can reformat the environment with a single command, and – with most projects, after prep work I’ve already done – anyone can set up a fresh and working dev environment in a few minutes.

(In theory. In practice there’s always some “How up to date is your system” crap)

Plus, the command line history always looks like it’s instructions for some kind of evil gift-giving robot. Vagrant up! Vagrant Provision! Vagrant Reload! VAGRANT DESTROY!

It’s a year or so since I switched almost everything to vagrant environments, but it’s only in the last few months I’ve looked in more depth about using something other than shell-scripts to provision them. I don’t really want to run a separate server for it, I’m not working to that kind of scale, so Ansible is currently my provisioning system of choice.

Ansible technically breaks my rules on development environments being platform agnostic, since it’s fairly militantly anti-windows as a host platform, but with babun (which is a cygwin repackage, complete with a replacement for the awful cygwin interactive shell, zsh, and a full package manager. If you take away nothing else from this, never install cygwin again) it works fine.

I’m fairly lucky in that all my clients have standardized on git as their vcs of choice, as it’s my choice too. Tower absolutely shatters my platform independance rule, but it’s hands-down the best git GUI I’ve used, and its built in git-flow support makes a lot of things easier. In Windows I’m using Atlassian SourceTree for the same job, which does a passable job. I’d still not recommend a git gui unless you know how to drive the command line to some level, if only because the terminology gets weird, but at the same time I’ve really liked being able to work with cli-phobic front-end developers who could still commit directly to the repo and make changes without needing a dev to rebuild.

For that, and not much else, I’ll recommend the Github client (in both Windows and Mac forms). It’s the most easy to use git client out there, but it’s doing that by hiding a lot of complexity rather than only doing simple things. It will work with non-git repos, even, though it’s not terribly happy about the concept. Does have the massive advantage of being free, though.

For the full Rained On By The Cloud experience, current primary deploy stack for Skute backend involves pushes to Github branches automatically triggering CodeShip CI, which runs the test suite before deploying (assuming success, of course) to Heroku. Secondary stack is similar, but deploys with ansible to AWS (for Reasons. At some point in the future I’ll no doubt be doing deeper stuff on how I’ve built the backend for Skute). Leaning heavily on the cloud is, in IT as much as life, not entirely a good idea, but it’s a really good starting point, and redundancy is in place.

Heroku’s mostly been a good experience. We’ve run into some fun issues with their autodetection (They decided our flask-based frontend service should be deployed as node.js, because the asset build system had left a package.json in the root) but the nodes have been rock-solid. Anyway, I’ve drifted into specifics.

Other dev utilities I couldn’t live without? Putty, in windows, for all the normal reasons. Expandrive is a Windows/Mac util for mounting sftp services as logical drives (or, indeed, S3 buckets or a dozen other similar things). LiveReload automatically watches and recompiles CoffeeScript, SASS, LESS etc. when necessary, Sequel Pro is an OS X GUI for MySQL access… and Evernote, where go checklists and almost every other bit of writing that isn’t also code.

There’s probably more, but that’ll be another article now.