Category Archives: Software Development

Silver bullets


In folklore, a bullet cast from silver is often the only weapon that is effective against a werewolf, witch, or other monsters.

I’m not sure how many of us in tech are hunting werewolves, witches, or monsters, but there are A LOT of us looking for silver bullets. Take one look around at the world of software development and operations today and it’s baffling. A perfect example of what I’m talking about can be found in this CircleCI blog post, which sounds like nonsense but actually sums up the current state of software development and operations quite nicely. Maybe we’re not looking for silver bullets. Maybe we’re looking for the gold bullet, then the platinum bullet, then we move onto missiles, bombs, etc. It never ends.

I’m not talking about the evolution of technology as a whole. We have a desire to always learn and progress. What we have in software development and operations today is a hyper spin cycle of the next shiny object. Very little of it gets mature enough before it’s thrown out in favor of the new-new silver bullet. Unlike the last silver bullet, this one will kill werewolves AND witches. If you’re a software engineer caught up in this never ending hype you can find yourself using all the latest and hottest tech with so much complexity it will melt the minds of mere mortals. This happens rather easily because the hottest tech often comes from companies like Google, Facebook, Netflix, etc. who are solving extremely large and complex problems. They are generously (and often strategically) open sourcing a lot of that work, which turns into the hottest tech of the month club. But most of us are not solving problems at that scale. When we take their tech and apply it to our problem we can easily find ourselves with a lot of moving parts when only a few would likely suffice for our problems. Multiply this problem by the output of the firehose of “innovation” happening. I put innovation in quotes because what comes to us in the guise of innovation is often a company’s hope to ever so slightly improve upon a good enough solution and take away market share in the process. Even when there is legit innovation, the benefits of adopting a brand new stack or even layer in the stack are questionable when weighed against building upon a solid foundation.

Again, to get the best grasp of what I’m referring to, read the CircleCI blog post. It’s short, funny, and maddening all at once. We need to stop the never ending pursuit of the silver bullet and figure out a more sustainable way to build great services people find value in. Otherwise, I’m afraid we’re spending too much of our time porting or, worse, figuring out how to port existing stuff that works well onto something that is now deemed “better”.

Cloning VirtualBox images (or how I save hours a day when testing software)

First things first. If you’re testing software and you’re not using some sort of virtualization solution, stop reading this and go install one. My product of choice is VirtualBox. It’s free (as in no cost and most of it is open source), user friendly, runs on an Ubuntu host computer and I’m familiar with it.

Lately I’ve been doing a lot of testing of the Ubuntu One desktop software and I need to be able to quickly get various versions of Ubuntu up and running. Below I outline how I do that on an Ubuntu host computer. My steps assume that you’re familiar with VirtualBox enough that you know how to setup a virtual machine (VM) already.

Create a master image

The master image is the one we’ll use to clone test images off of. By doing this we can worry about keeping our master image up-to-date and configured the way we need it and then simply clone that image when we have to test.

  1. Create a new VM in VirtualBox and install the OS  (see Lifehacker’s guide if you’re not sure how to do this)
  2. After restarting the VM when the install is done, install all the latest updates on the master image and restart
  3. Install the VirtualBox Guest Additions (allows nice integration with the host computer)
  4. Shutdown the master image

Periodically you’ll want to make sure your master image has all the latest updates, so just boot it up, install the updates and then shut it down.

Clone the master image

Now we’re ready to start testing some software. Instead of using the master image we created above, we’re going to clone that image. This should take less than 5 minutes start to finish.

  1. In a terminal session do the following:
  2. In VirtualBox, create a new VM by clicking the New button
  3. Go through each screen selecting the appropriate values and clicking the Next button until you get to the Virtual Hard Disk part
  4. Select the Use existing hard disk radio button
    VirtualBox Hard Disk Setup screenshot
  5. Click on the folder icon next to the pull down menu listing existing VDI files
  6. Click the Add button
    Add VirtualBox VDI screenshot
  7. Select the image you created (should be in ~/.VirtualBox/HardDisks) to add it to the list of available hard disks
  8. Click on the image you just added and then click the Select button
  9. Click the Next button
  10. Click the Finish button

You now have a brand new VM to use for testing. Once you test with this image and decide its usefulness is over you can delete the virtual disk image (VDI) file in ~/.VirtualBox/HardDisks, repeat step 1 above to create a new cloned image, and then edit your cloned VM in VirtualBox to use the new clone image. In other words, you don’t have to setup a new VM (steps 2-10) every time you want to use another VDI if you don’t want to.

Review The Tests, Then The Code


Last week I was talking with one of the developers at work and he was telling me about improvements his team was making in regards to (informal/desk check) code reviews. I told him that was great and then followed that up with a recommendation on how to improve even more.  Next time there is a code review, start with the tests. This will do two things: 1) Stress the importance of having tests 2) Make the review go quicker, as the tests will either be there and make the intent of the code clear or they won’t be there and the review is postponed until tests are in place.

I know I’m not the first to make this suggestion, but I felt it was worth repeating. Code reviews do have value, even when you pair program. At least, I think they do. Pair programming provides two sets of eyes on the code at the time of creation, but it’s surprising what someone who hasn’t seen the code before will find during a review.

Oh, and if reviewing the tests during a code review doesn’t make the intent of the code any clearer, then I suggest the team investigate behavior driven development (BDD). I’m becoming quite partial to the Cucumber framework for BDD, as I like it’s emphasis on user stories with acceptance tests/examples written in plain text and backed by executable steps.

The Customers Disappear Right Before Our Eyes

Tonight I was foolish enough to think my family and I could waltz into a restaurant on Valentine’s and get a table without much trouble. We were trying a restaurant we hadn’t been to before and I realized as soon as we pulled into the parking lot this probably wasn’t the best night to experiment. We went inside anyway to see how long the wait was. Much to my surprise, the hostess told us it was only about a 15-20 minute wait. I looked around the restaurant and, while it was full, there wasn’t a large number of people waiting on tables. We got on the waiting list and then proceeded to wait.

What I saw during the wait was kind of surprising. I noticed that the staff were diligently doing their jobs, quickly moving from one spot to another. I had to be careful not to step too far away from the waiting area or I was sure to bump into one of the busy bee workers. And while the staff was incredibly focused on the operations of the restaurant, I couldn’t help but notice they were almost oblivious to their customers, whether those customers be waiting for a table, eating their meal, or somewhere in between. I looked around the restaurant of about 40 tables and noticed that at any given moment there were numerous people looking to get the attention of their waitress. Customers coming in through the door were rarely greeted in a timely manner. Those of us waiting for a table were ignored completely, even as our original wait time came and went.

It dawned on me that this situation is not unlike what happens with some software development projects. We get in the groove of producing the software and never take time to make sure we’re satisfying the customer. Yes, those of us practicing agile have the advantage of delivering in short iterations which, at worst, won’t allow a project to go too long before the customer is back in the mix. But, even on agile projects, I’ve seen teams go through an entire iteration without giving much thought to the customer’s needs beyond the initial planning meeting. We think we understand exactly what the customer wants, can’t or simply don’t get continuous feedback from the customer during the iteration, and we develop the functionality. We become like the restaurant’s staff, who are so busy running the restaurant that they forget about the very people who really keep the restaurant running, the customers. Sure, the orders are taken, the food is getting out to people, drinks are refilled, new people are put on the waiting list, etc., but the customers aren’t satisfied, let alone happy. The software gets designed, written, documented, tested, etc. but the customers aren’t satisfied, let alone happy. Sound familiar?

Tonight was a good reminder that technical and operational excellence is critical to delivering a good customer experience, but if we lose sight of the customer in that process then we will fail miserably. We need to be diligent about keeping constant contact with the customer and focusing on the value we’re delivering. We don’t want our customers to walk away from us like my family and others did on the restaurant we attempted to eat dinner at tonight.

One Smart Cucumber

I was messing around with some Ruby stuff tonight and was reading up on the Cucumber project. Cucumber is a behavior driven development (BDD) testing tool.

Anyone who talks to me about user stories knows I’m kind of a stickler on the value statement.  I think I’ve found a kindred soul in Aslak Hellesoy, the creator of Cucumber. The following comes from the Cucumber documentation.

You should discuss the “In order to” part of the feature and pop the why stack max 5 times (ask why recursively) until you end up with one of the following business values:

  • Protect revenue
  • Increase revenue
  • Manage cost

If you’re about to implement a feature that doesn’t support one of those values, chances are you’re about to implement a non-valuable feature. Consider tossing it altogether or pushing it down in your backlog. Focus on implementing the MMFs (Minimum Marketable Features) that will yield the most value.

Here is an example taken from an IRC chat session in #cucumber:

I was impressed to find that section in the documentation. Not only do the docs detail basic usage but they go into the deeper discussion of how to apply agile principles using Cucumber. The balancing act of teaching principles and practices at the same time is no small feat. To find that in software documentation is pretty amazing.

P.S. One of my worst titles ever, I know. I think I was subconsciously inspired by the Hallmark Movie my wife had on a couple nights ago. I now realize I missed my calling as a greeting card writer.

Apache Shindig PHP Setup Problem Solved

First things first. Shindig is an Apache incubator project that serves as an OpenSocial Container and…I’m already falling asleep. Too boring. I’m way behind the curve on all things “social networking” but I have an idea for an app that may scratch an itch I have, and it just happens that some of this social networking stuff might be a good way to jump start the idea. So that means catching up on a couple of years (or more) of stuff that’s been going in the world of web 2.0, which includes OpenSocial. I wanted a local OpenSocial test sandbox and found Shindig to fit that bill.

Now, onto the problem I was running into and the solution. Unless you want the long boring details, I can save you the trouble and tell you to make sure you have mod_rewrite enabled in Apache.

If you haven’t dozed off by now then it probably means you’re running into issues with the Shindig PHP setup and would like some more details. I followed the directions on setting up the PHP Shindig server on my laptop running Kubuntu 08.04 here at home and kept getting a 404 error. I thought that was strange since I could hit other files with my browser that I put in that directory manually for testing but not the Shindig index.php page. Turns out the Shindig index.php page tries to be more “controller/servlet” like by sniffing the URI and passing it along to the appropriate handler. If it can’t find a match, then it gives a custom 404 error. I noticed the test URI (http://shindig/gadgets/ifr?url= didn’t have any reference to index.php. Ah yes, the wonders of Apache mod_rewrite! And guess what I didn’t have enabled? Yep, Apache mod_rewrite. So, below is what I did to get things running on an Ubuntu setup from scratch (meaning no Apache 2, PHP 5 was installed or configured):

Stop laughing, I use the Pico text editor. I’m, as my son would say, “weak sauce”. I know. Anyway, here’s what I have in that virtual host file:

Once we have that in place, we need to edit our host file:

Append the following to the hosts file and save:

Time to restart Apache:

Now you should be able to go to your web browser of choice and run the demo/test app:

If all went well you should see something a little like this:

That’s The Java Way!

A quote from an email I saw come across this evening:

Otherwise, what’s the point? Pile up one xml on top of the other? 

I couldn’t resist.  A cheap shot at Java.  I’m just bitter after being exposed to one too many Java frameworks in the past that seemed to think that “you can never have too much XML” was a mantra to proudly live by.

MSSU Follow Up

On Thursday, October 25th, I spoke to the CIS club at Missouri Southern State University. The presentation won’t win any awards (no presentation of mine ever will.) I put the Powerpoint up on SlideShare. I promised the students and professors in attendance that I would follow up with a post on my blog with links and other info that might be helpful.

If you’re interested in an internship with Gestalt’s Joplin office, please send your resume to my email address: jhoover at I’ll make sure your resume gets to the right people within Gestalt.

Pragmatic Unit Testing in C# with NUnit on

Agile Software Engineering
Some of the agile software engineering best practices I mentioned during the presentation were Test Driven Development (TDD) and Continuous Integration (CI). Since MSSU is focused on .NET, here are some links that might be helpful related to TDD and CI:

YouTube Videos
Coco had asked how Gestalt was using YouTube. I mentioned that we used it as part of a recruiting effort. We had a contest open to the employees to see who could make the coolest recruiting video on YouTube. The results of that contest can be found here. The winner (as voted on by Gestalt employees) was John Moffet’s PatrolNet Woes. In an act of shameless self-promotion, I’m embedding my video below.


My Job Went To IndiaRecommended Read
A book I’m in the process of reading that I think would be extremely beneficial for college students to read is My Job Went To India. I’m about a third of the way through and the advice is practical and especially relevant for those entering the IT workforce these days.

RSS LogoThere were some questions about RSS during the presentation. May I suggest checking out the Gestalt Blogs RSS feed? This feed has all the posts from Gestalt bloggers, with quite a few being out of the Joplin office. My personal favorite combo for subscribing to and reading RSS feeds is Firefox and Google Reader.

Open Source
Below are the links to all our current Open Source projects:

Producing Open Source SoftwareRemember to look into joining an Open Source project. While I don’t have any specific recommendations on projects to join (other than our own!), I can definitely recommend reading the book Producing Open Source Software. You can get a free PDF and HTML version of the book.

The Cathedral and bzr

Horrible title, but I couldn’t resist. Apparently, I need to get in a time machine and catch up on the latest and greatest in version control systems (VCS). Bazaar (bzr for short) is a distributed version control system along the lines of BitKeeper, git, and a number of others. I’d be lying if I told you I completely understand the advantages of a distributed version control system over a centralized one like Subversion. But, the cool guys from Joyent seemed pretty hyped up about Bazaar as their VCS of choice in one of their podcasts I listened to a couple of weeks ago. Oh, and that little Linux distro uses it too. What’s the name again? Ubuntu. That’s it! Ubuntu uses Bazaar to manage the complexity of such a large code base.The Cathedral and The bzr

I started to read a bit more about decentralized VCS; knowing that Linus Torvalds is a HUGE proponent of it I figured I’d see what he had to say. I found this crazy long email reply Linus gives about a month ago to Adam Treat of the KDE dev team, who asked Linus some questions about moving from Subversion to git. It makes my brain hurt trying to think about version control in the way Linus does. I’m not even going to try to summarize his thoughts here because I’m still processing them. I hope to come back and elaborate some more if I get the time to check out Bazaar and further investigate if distributed VCS is something that makes sense for a company like Gestalt to consider using.

P.S. Knowing version control systems, the important functions they serve and how to properly use them in configuration management is key to being an ideal QCer on an agile team in my (rarely) humble opinion.

Twitter Tools WordPress Plugin Fix

Warning Scrum Master CodingAfter getting an hour or so to focus on coding around the Twitter issue I previously posted about, I think I have a fix. For whatever reason the Twitter API is accepting requests from CURL but not from Twitter Tools use of the PHP library Snoopy. Not all PHP installs have the CURL extension installed, so my code uses it if it’s there, otherwise it defaults back to the code Alex King, the author of Twitter Tools, wrote to use the Twitter API.

I’m going to leave a comment on Alex’s site pointing him to this post. I’m putting the code here for download if anyone wants it. I’m also leaving a patch file here for Alex in case he’s interested in using it. I’m not sure it’s worth it or not – not my call. I’m just happy I can spam…errr…inform those at Gestalt using Twitter when I have a new post on this blog. Sure, they can do that even better using RSS, but that’s not as cool as saying you got it off Twitter. Heh.

This is not an issue in Alex’s code, as he points out in a recent blog post. This is an issue with Twitter’s infrastructure, which users are noticing more as the service has grown. Scaling web apps/services is hard. I’ll have a post on that in the not so distant future.