Bad Press for Agile

So .. Agile’s been getting some bad press of late. Now, these guys are just quacks, and I probably shouldn’t feed the trolls here, but I never could resist.

Saying “agile doesn’t work” or “agile is only out to sell services(training,certification etc)” is obviously a bogus claim. The same could be said of any software methodology. Many waterfall projects have failed, and many have had the help of process improvement engineers and whatnot. Some projects will always fail. A sound development methodology & culture can help you realise imminent failure earlier, or it can help reduce chances of failure. But no methodology is a guarantee for success. A team of idiots run by idiots will always produce crap. No matter how many buzzwords they fit in their job titles or marketing blurbs.

Agile is many things, but no one has ever claimed it to be a silver bullet. As for for it being “for lazy devs”: all developers are lazy, it’s part of the job description. It’s why we automate shit. It’s why we focus on code and not on hot air.

My recommendation to you: use whatever works for you. And in doing so, you’re already on your way to being Agile :-).

SSH Gateway Shenanigans

I love OpenSSH. Part of its awesomeness is its ability to function as a gateway. I’m going to describe how I (ab)use SSH to connect to my virtual machines. Now, on a basic level, this is pretty easy to do, you can simply port forward different ports to different virtual machines. However, I don’t want to mess about with non-standard ports. SSH runs on port 22, and anyone who says otherwise is wrong. Or you could give each of your virtual machines a seperate IP address, but then, we’re running out of IPv4 addresses and many ISPs stubbornly refuse to use IPv6. Quite the pickle!

ProxyCommand to the rescue!

ProxyCommand in ~/.ssh/config pretty much does what it says on the tin: it proxies … commands!

Host fancyvm
        User foo
        HostName fancyvm
        ProxyCommand ssh foo@physical.box nc %h %p -w 3600 2> /dev/null 

This allows you to connect to fancyvm by first connecting to physical.box. This works like a charm, but it has a couple of very important drawbacks:

  1. If you’re using passwords, you have to enter them twice
  2. If you’re using password protected key files without an agent, you have to enter that one twice as well
  3. If you want to change passwords, you have to do it twice
  4. It requires configuration on each client you connect from

Almighty command

Another option is the “command=” option in ~/.ssh/authorized_keys on the physical box:

command="bash -c 'ssh foo@fancyvm ${SSH_ORIGINAL_COMMAND:-}'" ssh-rsa [your public key goes here]

Prefixing your key with command=”foo” will ensure that “foo” is executed whenever you connect using that key. In this case, it will automagically connect you to fancyvm when you log in to physical.box using your SSH key. This has a small amount of setup overhead on the server side but it’s generally the way I do things. The only real drawback here is that’s impossible to change your public key, which isn’t too bad, as long as you keep it secure.

The Actual Shenanigans

The command option is wonderful, but some users can’t or won’t use SSH key authentication. That’s a bit trickier, and here’s the solution I’ve come up with — but if you have a better one, please do share!

We need three things:

  1. A nasty ForceCommand script on the physical box
  2. A user on the physical box (with a passwordless ssh key pair)
  3. A user on the VM, with the above user’s public key in ~/.ssh/authorized_keys

This will grant us the magic ability to log in to the VM by logging in to the physical box. We only have to log in once (because the second part of the login is done automagically by means of the key files). A bit of trickery will also allow us to change the gateway password, which was impossible with any of our previous approaches.

Let’s start with a change in the sshd_config file:

Match User foo
        ForceCommand /usr/local/bin/vmlogin foo fancyvm "$SSH_ORIGINAL_COMMAND"

This will force the execution of our magic script whenever the user connects. And don’t worry, things like scp will work just fine.

And then there’s the magic script, /usr/local/bin/vmlogin:

#!/bin/bash

user=$1
host=$2
command="${3:-}"

if [ "$command" = "passwd" ] ; then
        bash -c "passwd"
        exit 0
fi
command="'$command'"
bash -c "ssh -e none $user@$host $command"

Update 2016

The above script no longer works with SFTP on CentOS 7 with Debian guests. Not sure why, and I’m too lazy to find out. So here’s a script that works around the problem.

#!/bin/bash

user=$1
host=$2
command="${3:-}"

if [ "$command" = "passwd" ] ; then
        bash -c "passwd"
        exit 0
fi

# SFTP has been fucking up. This ought to fix it.
if [ "$command" = "/usr/libexec/openssh/sftp-server" ] || [ "$command" = "internal-sftp" ] ; then
        bash -c "ssh -s -e none $user@$host sftp"
        exit 0
fi

command="'$command'"
bash -c "ssh -e none $user@$host $command"

And there you have it, that’s all the magic you really need. Everything works exactly as if you were connecting to just another machine. The only tricky bit is changing the gateway password: you have to explicitly provide the passwd command when connecting, like so:

ssh foo@physical.box passwd

Symfony2 and Jenkins

I was a bit surprised to see that Symfony2 doesn’t come with an ant build file for Jenkins by default, so I spent a bit of time whipping one up for you (well, for me, really):you can get it here.

Maybe it’ll work for you, maybe it won’t. The project I’m working on has the complete SF2 distribution in version control and all of our bundles in the src folder. It’s easier to test & ship the code this way. If you want to test a specific bundle or don’t want to have SF2 in version control, then you’re on your own :-).

On donating to open source

Some time ago, Gabriel Weinberg, the guy behind the excellent Duck Duck Go search engine, started a bit of a discussion about open source donations. He set up a website where companies can make a pledge to donate x% of their profits to worthy projects. I donated 15% of my company’s estimated profit this year. Half went towards an individual hacker who will remain nameless and genderless. The other half went to the OpenBSD project, because face it, where would you be without OpenSSH?

FOSS Tithe.org

The Agile Samurai: Mini book review

The Pragmatic Programmers have published quite a few books over the years. My bookshelf contains nearly a dozen of them. The latest addition being The Agile Samurai: How Agile Masters Deliver Great Software.

It’s essentially a high level overview of agile practices, with a focus on the why and the how. Unlike some other books on Agile, this one tries to remain pretty neutral when it comes to methodologies. XP, Scrum, Kanban are all briefly mentioned, but the author managed to boil Agile down to its essentials: common sense, being goal oriented and having a willingness to improve.

The chapter on Agile Planning is a particularly excellent treat. It could have easily been called “the idiot proof guide to agile planning”, because really, it’s that good. Concepts like velocity and burndown are illustrated with pretty graphs. Not only does the book explain how to apply agile planning, but by the end of the chapter you’ll also know why it’s a good idea. The phrase “Why does reality keep messing with my Gantt chart!?!” sums it up pretty nicely.

I have just one problem with the book. The Samurai theme could’ve been explored a bit better. For starters, this here Samurai is wearing his swords on the wrong hip. Second, his name, Master Sensei is a bit silly. Ō-sensei would’ve been much more appropriate. But in all seriousness, the whole Samurai theme could’ve been expanded on. There are many similarities between software development and martial arts in general. Mostly when it comes to drive and focus, a bit less so when it comes to actual sword wielding. Still, it doesn’t detract from the book, so all is well.

All in all, a pretty good book. If you’re an Agile Veteran, you won’t need it, but maybe your pesky manager or team leader could benefit from it …

Automating Maven Releases

Automating maven releases should be pretty straightforward in non-interactive mode. A bug in the release plugin made it impossible in my situation. Every time I would provide the release version(s) as command line arguments, the release plugin would choke on me with the following error message:

Error parsing version, cannot determine next version: Unable to parse the version string

The following shellscript works around this problem, by redirecting input to the maven execution.

Note: I’m releasing a project with a parent and 2 child modules, which is why I have to specify three versions ( + 1 SCM tag). If you’re not using multiple modules, or are using more, you’ll have to adjust the script accordingly.

#!/bin/sh

releaseVersion=AmazingRelease1
nextVersion=AmazingRelease2

mvn \
    release:prepare -P production &>> /tmp/build.log << EOS
$releaseVersion
$releaseVersion
$releaseVersion
$releaseVersion
$nextVersion-SNAPSHOT
$nextVersion-SNAPSHOT
$nextVersion-SNAPSHOT
EOS

mvn release:perform -P production &>> /tmp/build.log

This is an abridged version of our full release script. The full version asks the user to enter the release version once, then releases several versions using different profiles and creates a distribution set with all versions and a bunch of documentation. This works in my situation, but if your release procedure is more complicated then you can just expand on the script :-).

Test design – Equivalence Classes

During a recent job interview, I was asked to write some code — I know, shocking! The idea was that several test cases had been defined, and that I was to implement a relative simple class that would make the tests pass. The problem was pretty simple, so I won’t bore you with it.

What was shocking, however, was how poorly designed the tests were. Boundary cases were largely untested, and it seemed like someone spent an inordinate amount of time writing useless tests. When I brought this up during the interview, the person who wrote the tests seemed surprised that they weren’t very good, because he got nearly 100% code coverage on the implementation he created.

While code coverage is all fine and dandy, it doesn’t actually say anything about the quality of your tests. Maybe his implementation would’ve worked perfectly, even with strange values and edge-cases. Maybe not. We’ll never know.

Equivalence Partitioning is one of the simplest test-design techniques. As the name pretty much implies, the idea is to partition possible input values into equivalent classes. Sounds like a bunch of gibberish? Let me illustrate with a classic example. Liquor laws.

As you can tell from the image, if you’re under 16, you’re not allowed any alcoholic beverages. Once you turn 16, you’re allowed to have beer and other non-spirits. Once you turn 18, you hit the jackpot and can drink whatever tickles your fancy.

The red, yellow and green areas are the three Equivalence Classes for this problem. Whether you’re newborn, 5, 11 or 15, it doesn’t matter, you’re not getting a drink. And once you’re older than 18, your age stops mattering entirely.

Once you have this information, you can design a couple of test cases. In this case, you could start off by designing a test case for each class. The exact age for each test you pick doesn’t matter, as long as it’s in the class you’re testing – or outside of it if that’s what you’re testing.

So that’s three easy tests. Then it’s time to apply a bit of Boundary Value Analysis. After all, it’s so very easy to create off-by-one errors.

Boundaries are the areas where equivalent classes meet. The boundaries in this case are 16 and 18. When you look at the boundaries you’ve defined, you’ll want to look very carefully at your specifications again. Someone’s just turned 16 on this very day. Does that mean they can have a drink? Or not? Once you have the answer, create a test case. Then do the same for all other boundaries.

With five test cases, one for each boundary and one for each equivalence class, you’ll have tested this very thoroughly. Additional test cases can be made to test invalid input. What happens if you try to pass a person with a negative age? What if the age is a million years old?

Two Spring/Hibernate gotchas that got me

Earlier this week I got caught out by two Spring/Hibernate features. One of my service layer methods threw a checked exception after a bit of relatively complex validation, just like I intended. What happened next, however, was not expected. My test failed. Well, it didn’t fail, it died with an error and a horrible stack trace of doom. Hibernate was kind enough to tell me that a batch update failed. This struck me as slightly odd, considering the fact that an exception was thrown long before any saving was meant to occur.

I had, apparently, forgotten about the rather unintuitive automagic dirty checking and subsequent saving. In my rather humble opinion, it’s a feature that should be disabled by default, but that’s not the point here. I had been made aware of the feature in the past, but had somehow completely forgotten about it. Fine, no worries, I can live with it, I’ll just roll back my transaction.

However! My test still shouldn’t have failed, or so I thought. After all, I had Spring transaction support set up for all my service calls, and surely an exception will cause the transaction to roll back? Wrong. By default, transactions are only rolled back for Unchecked exceptions, not for checked exceptions. I can’t for the life of me fathom what the reasoning behind this decision might be, but there you have it. It’s well document in the Spring transaction documentation, but again I had completely forgotten about it.

A simple bit of config fixed the problem:

<tx:method name="*" rollback-for="java.lang.Throwable"/>

So please, don’t be like me. Don’t get caught out by these features! Unless you’re looking for a couple of hours of entertainment, that is :-).

Howto: soapUI integration tests with Maven

Running soapUI tests with maven is surprisingly easy, all it requires is a few simple steps. This howto will walk you through deploying your web project in an embedded container and running the soapUI tests in the integration test phase.

Cargo configuration

With the cargo plugin you can deploy your project to just about any container. For the sake of simplicity I’ll be using an embedded Jetty 6 container.

<!-- Deploy the project WAR to a built-in container during the integration test phase -->
<build>
[...]
<plugin>
	<groupId>org.codehaus.cargo</groupId>
	<artifactId>cargo-maven2-plugin</artifactId>
	<executions>
		<!--Start the container in the pre-integration-test phase -->
		<execution>
			<id>start-container</id>
			<phase>pre-integration-test</phase>
			<goals>
				<goal>start</goal>
			</goals>
		</execution>
		<!-- Stop the container after integration tests are done -->
		<execution>
			<id>stop-container</id>
			<phase>post-integration-test</phase>
			<goals>
				<goal>stop</goal>
			</goals>
		</execution>
	</executions>
	<configuration>
		<wait>false</wait> <!-- We want to deploy, run tests and exit, not wait -->
		<container>
			<containerId>jetty6x</containerId>
			<type>embedded</type>
		</container>
		<configuration>
			<properties>
				<cargo.servlet.port>${my.project.port}</cargo.servlet.port>
			</properties>
		</configuration>
	</configuration>
</plugin>
[...]
</build>

soapUI project configuration

If you haven’t already created a SOAP UI test suite, now’s the time to do so. Once this is done, copy the test suite to your test resources folder (src/test/resources). Set up your project to filter resources.

<build>
[...]
	<testResources>
		<testResource>
			<filtering>true</filtering>
			<directory>src/test/resources</directory>
		</testResource>
	</testResources>
[...]
</build>

With that out of the way, you can now edit the soapUI project file with your favourite XML editor. What you want to do is replace all endpoint references (and possibly WSDL locations) by property keys. So <con:endpoint>http://localhost:8080/MyProject/endpoint</con:endpoint> becomes <con:endpoint>${my.project.endpoint}</con:endpoint>.
Your webapp will be deployed to http://localhost:${my.project.port}/${project.artifactId}-${project.version}, so I suggest using that as a property value.

<project | profile>
[...]
<properties> 
	<my.project.port>8888</my.project.port>
	<my.project.endpoint>http://localhost:${my.project.port}/MyProject/endpoint</my.project.endpoint>
</properties>
[...]
</project | profile>

soapUI plugin configuration

First, add the eviware soapUI maven repository to your list of repositories.

<pluginRepositories>
	<pluginRepository>
		<id>eviwarePluginRepository</id>
		<url>http://www.eviware.com/repository/maven2/</url>
	</pluginRepository>
</pluginRepositories>

Then, add the plugin to your build and let maven know when you want to execute it. Considering the container is starting up before the integration test phase, and is shutting down afterwards, running the tests as integration tests seems like the best option ;-).

<!-- Run SOAP UI tests during the integration phase. -->
<plugin>
	<groupId>eviware</groupId>
	<artifactId>maven-soapui-plugin</artifactId>
	<version>2.5.1</version>
	<configuration>
		<junitReport>yes</junitReport>
		<exportAll>yes</exportAll>
		<projectFile>target/test-classes/soapui-project.xml</projectFile>
		<outputFolder>target/soapui-reports</outputFolder>
	</configuration>
	<executions>
		<execution>
			<id>wsn-server-test</id>
			<phase>integration-test</phase>
			<goals>
				<goal>test</goal>
			</goals>
		</execution>
	</executions>
</plugin>

All done!

Now when you run maven verify (or install, or ..) your SOAP UI tests will automagically be executed and you’ll be informed of any failures.