Beyond the hammer

I’m a utilitarian software developer, or so I have always thought. For me, being a utilitarian developer has long meant using whatever tools I could wield to “get the job done” as quickly and correctly as possible, and was something I have always taken pride in. In practice, this mindset has translated to writing every project in whatever language I happened to be using at my day-job, and lucky for me, at work, I write Java: the swiss-army-knife of programming languages. Need a chart? Here’s a shitty charting library. Sure, the result isn’t going to be sexy like something made with D3.js, and while the project won’t require much, if any, new learning, it is going to require a LOT more time and/or brainless effort than if I knew how to do it in say,  Python. But hey,  I needed a chart and I made a chart, case closed, great success!. This mode of thinking tends to drive technology choices, for instance why write Objective-C when you can just Java away on Android and leave the iOS work to someone else. You don’t care that an idle Tomcat server suckes down 200mb of RAM, just as long as it serves the JSON when you asked for it.

Of course, the problem with using a hammer for every project is that your faucet leaks because, instead of installing it with a pipe-wrench and some thread-tape, you bashed it on like a neanderthal wielding a river stone. The other issue with this one-tool approach is that while you get really good at beating things with your hammer, you never really learn to use the other tools in the box. When you see a screw, you look over suspiciously at the phillips-head driver in your box, and decide that “no, threads aren’t all that important, any old piece of steel filling the hole will work”, and you instead draw your trusty hammer as you always do, and commence to banging away.

Despite my attention difficulties (the next Docker.io post is in the mail, I promise) I have set my sights on learning some new languages; 8 to be exact. The first 7 will be those covered in The Pragmatic Press’s 7 Languages in 7 weeks, and the eighth will be Apple’s Swift (more on that choice later).

7L7W features languages designed for all programming paradigms. From Ruby’s OOP to Haskell’s pure functional, I really hope to become a utilitarian with a big toolbox, equally comfortable hammering nails as I am cutting wood with a newly sharpened band-saw, and even if I only get a feel for 4 of the 8 languages I have set my sights on, I’m sure I will be the better for it.

Docker.io – part 1

Last night, in an effort to ignore the Patriots’ embarrassing performance against the Kansas City Chiefs, I began to play a bit with Docker.io, an open-source lightweight virtualization solution built on top of LXC containers. Having seen some impressive Docker implementations at the most recent Dealer.com hackathon, I was excited to give it a try as we’re looking for a good turn-key solution for deploying our GreenUp-VT services over at XenonApps.

In the end, I spent about 2 hours and was able to get a Docker container running on an Ubuntu VM running in VirtualBox on my Mac, but not without some struggles.

First, I was quite impressed and encouraged by the Docker documentation. The tutorials, install, and user guides all appeared to be well-written and complete. My only suggestion/complaint, and it’s not a minor one, is that if you find yourself writing a multi-step installation guide, and you’ve got a nifty shell script in your back pocket that preps the environment, downloads the dependencies, and completes the install for you, start your guide with a link to that script. Docker’s Ubuntu install guide, instead, walks you through the entire process of manually verifying your environment, downloading the dependencies, and performing the install, before letting you know that “oh yeah, we’ve got a script for that”:

Before I continue, I should note that I landed on the Ubuntu install only after my first few attempts at getting Docker to run on Debian were unsuccessful. While it may be my own fault for trying to upgrade my Debian install from 7.0 to 8.0 before following the Docker install guide, I was disappointed when I found myself chasing around a startup error only to end up reading a discussion about the problem in Docker’s Github issue-tracker, but then again Docker is an open-source project, so maybe I should just be happy that the problem appears to be a frequently reported issue that is being actively worked on, but I digress.

Once I was able to get Docker running on my Ubuntu VM, I followed the directions, downloaded a standard Ubuntu image, and set out installing Apache and MySQL, all of which just worked as advertised. The container felt like a full VM, and while I haven’t yet dug too far into it, the CLI interface seemed to have all the functionality of any other Bash shell. This week, I’ll move on to configuring an image with a Dockerfile before transferring it to other hosts, all to be included in part 2 of this series.

 

My first post

Over the years, I’ve read a ton of articles and blogs, some of which have been a complete waste of time, and others which have inspired me to be a better person and better software developer. One such blog-post (the link has been unfortunately lost to the sands of time) suggested that to be a better developer one should write about his/her experiences writing and managing software, so today I will take that advice and begin chronicling my experiences.