At work, I’m building a module that interfaces with a customer billing system. Writing unit tests for something like this is easy using mocks, but I really wanted to write an integration test the ensured the two systems worked together correctly.

Unfortunately, because the system is a billing system, it is considered sensitive, even the developer instance. This means that, though the Continuous Integration environment (which is hosted in a secure location) is able to access the billing system, the remote office in Denver (where I work) is not.

This can be solved by opening up an SSH tunnel to the CI environment, allowing me to tunnel traffic through HTTP to the remote billing system. But that presents a separate problem.

My integration will work in the CI environment, it will work locally when the tunnel is open, but it will fail any other time. So if I check this code in, every other developer on my team will have to know that, before they run all of the tests locally, they have to open an SSH tunnel, even if they’re working on a component totally unrelated to my work.

Continue reading ‘Conditionally Running Tests With JUnit 4’ »

Paul Dyson has made a blog post entitled “Technical Debt and the Lean Startup” as well as commented on my post about When To Work On Technical Debt, challenging some of my claims. I read through his post and, while it makes a number of good points, I think it ultimately advocates for a risky manner of running a business. I started typing this as a response to his comment, but realized that it was long enough to warrant a separate post, so I’d like to go through his post’s points one by one.

Hit-By-A-Bus Syndrome

Let’s look at his first example: that it’s okay in a lean start-up to have an area of the system only understood by a single person. He basically argues that, in a small start-up, you don’t have enough people to pair-program on everything, so having a single person understand the system is alright. This is a false dichotomy, he is saying that code must be either paired or it must be understood by only one person. Even if you do not have the resources to pair-program every task, you can still have collective code ownership by simply having regular code reviews with your team. It’s not quite as good as pairing, but it’s leaps and bounds better than a single person knowing the system.

Having an area of the system understood by only one person is unbelievably risky, so much so that I’m a bit stunned that someone as experienced as Paul would advocate it publicly. If that one person fell ill, or took an offer at another company, he would have been royally screwed. Development would have to completely stop while the other members of his team came up to speed on that aspect of the system, unable to ask questions of the original developer. This situation would be even worse if he had very few developers; he may have to wait and continue development only after hiring a replacement.

What he’s basically saying is “look, I know people say you need to drive with glasses if you have poor eyesight, but I have poor eyesight and I’ve been driving for years without getting in an accident. If you have poor eyesight, you should consider driving without glasses too.”

Continue reading ‘What Is Technical Debt?’ »

Android is a great mobile OS for people who like to tinker and customize things. Virtually every aspect of Google’s default Android install can be replaced with something else. There are a number of alternative SMS clients if you are unhappy with the default, a plethora of alternative Gallery apps, multiple Email replacements, and many more. You can even replace applications that seem ‘core’ to the OS such as the dialer and even the Home Screen Launcher.

The ability to replace the Launcher opens up a world of possibilites for customization. Launchers like LauncherPro and ADW Launcher have tons of options, giving users a lot of control.

One of the features of some of these launchers combines really well with another type of Android app to allow users to solve the problem of cramming too many shortcuts into homescreens.

Continue reading ‘Boost Android Productivity With LauncherPro + Smart Shortcuts’ »

We’ve got a common library used by a number of projects. This library has it’s own git repository and it’s own job in Jenkins to build it.

One of the tasks of the Jenkins job is to, when the tests pass, copy the jar file artifact into a team-wide Nexus instance, which is added as a repository in our other projects.

Lately I started having a problem where a new project that used this library was unable to run tests correctly – strange failures that seemed unrelated to any actual changes. The culprit wound up being an unlikely source: Clover.

Continue reading ‘Be Careful With Clover in Jenkins’ »

I recently wanted to set up Jenkins on my personal workstation to manage builds for side and personal projects. I was already running Tomcat on the system since I use that to run Subsonic, so I wanted to install Jenkins in the same container.

The process of getting everything working was just short of a nightmare, but I managed to eventually get my Jenkins inside of Tomcat successfully checking out and building projects through Git. While I was dealing with various errors, I was doing a lot of Googling. My searches seemed to indicate that very few people were trying to set things up as I was, because the internet was very little help. When hours of Googling turns up nothing, you know you either have a) a technical problem that nobody else has tried to solve or b) a weird fetish.

So I’ve written this post to explain how to set things up. But rather than a simple tutorial, I’ve written it as a step-by-step account of the various difficulties I had setting it up. I’ve done this partially to draw a little bit of attention to a gap in the error messaging of these tools, but mostly so that the next person who Googles for specific error messages may come across this page and avoid some headaches.

Ultimately, what I wanted was Jenkins installed in Tomcat running as a system service in Ubuntu to be able to check out projects via Git repositories via the SSH protocol. I will assume you already have Git installed because it is awesome, but if not it’s as easy as using your package manager.

Continue reading ‘Ubuntu, Tomcat, Jenkins, Git, and SSH Together’ »