Development Environments for the “Prosumer”

I had a friend, who I would consider a fairly technical guy who programs for fun, but not an engineer by trade, recently ask me how I setup my personal dev environment. I was a little taken aback by the question, because honestly, I employ most of the techniques I use professionally, be it at a much smaller scale and don’t really think about it all that much. So as an homage to him, Below are a few of the tools and methods that I use both personally and professionally in building and maintaining Development Environments.

Tools

Virtualization

I evaluate a lot of software. I would prefer not to install it on my native hardware where it may be difficult to extricate it or may not be compatible with my operating system. So I make use of virtualization for evaluation and various environment setups. I personally use Oracle Virtual Box, but Parallels, VMWare, or Amazon AWS EC2 (if you have stay mobile and don’t lug around a heavy metal MacBook Pro like I do) will work as well.

Editors

This where I may start a holy war. Use whatever editor you want, if you like a nice shiny IDE, go right ahead. If you like something more stripped down like vi or emacs, go right ahead. if you like something in the middle, thats fine too. use something you can feel comfortable in.

Source Control

Always use source control. Period. Even if its a plaything, when you want to make changes to something a week later when you realize its wrong, its 100x easier to rollback to the last working thing and try something else than to try and get rid of the problem code. I use Git and store things up on GitHub or Bitbucket, depending on my mood.

Build System

Use a build system like source control, it will save you a ton of time when you have to walk away and come back to something. I leave some projects for months and come back and the first thing I do is look at the build system. Use the build system that is appropriate for the language you work in( For java use ant/maven, for ruby use rake, etc)

Testing

Write Tests. this will make it easier to verify something still works after you change it. this seems like a no brainer to me, but if you’re just “hacking” something together and don’t write tests, you will kick yourself months later when you go to change something or try and adapt it into something else.

Methods

Keep base VMs, and take snapshots along the way.

I keep a set of base VM images with various operating systems and patch levels. when I need a VM, I clone it( in some VM platforms, this is as simple as recursive copying the VM’s folder and renaming it), install the software I need on it, then use the VM platform to take a snapshot of the VM state so you can go back to a clean state at any time( this is particularly useful for things like databases).

Keep base projects and build systems

This one is from spending may years creating the same thing over and over again when I go to a new job or creating some thing new at home. whether its a ruby gem, a java jar, or a c library, put together a standard directory structure and base build system that will do the basics: clean, compile, package, and save it off in source control. This makes starting new project infinitely easier

Never install a new language your native hardware.

Read this as I don’t trust RVM. If i want to experiment with a new language or build, I stick it on a VM to test it out. I share a folder with my VM that contains the source code I want to test and that way i can use the editor on native hardware and the language in the VM. if it doesn’t work, I roll back the VM to a previous

monday.sh or morning.sh

This is a habit I picked up while working at Apptio. If I am working with a team and there is a lot of daily commits( which in my opinion, there should be) you’ll need to get them, make sure they merge, make sure all the tests still run, and update the generated documentation. Sometimes for really large projects this can take a while. I write a script called monday.sh that will do a full merge, build, test suite pass and documentation update. I fire this up first thing monday, then go check email or get myself a cup of coffee/tea. When I come back, my environment is ready to start the week.

Keep secret scripts and a solution log.

Sometimes, when you need to do a specific thing, whether its unique to your environment, or a particular service, you write script for it. check it in to source control. Also, it you write a nifty function, data transform, or class to do something very specific, keep that in a solution log. I used to use Evernote for this but now I’ve started to migrate to GitHub Gist.

Parting thoughts

You can go as hog-wild on this as you want. I have seen some pretty elaborate setups. I have even gone overboard once or twice. However, don’t let development productivity pr0n keep you from creating awesome things.

Nov 17, 2011