The geekier side of Riff Pie

Do I need continuous integration on a solo project?

I was chatting idly the other day with a colleague, as we often do, about our pet projects. The subject of deployment came up. In our day job, we make quite heavy use of Jenkins to build and test our app, and also to (largely) automate deployment. I asked if he used Jenkins or anything for his own projects, and it turns out he’s just like me and doesn’t bother.  He just runs all his tests before committing.

Which leads me to neatly, and somewhat sooner than I expected, to answer the question in the title of this post: No. As a solo dev, there really isn’t any need to use CI. Clue’s in the name: what are we integrating? Why do we ever bother with CI? It’s because taking the work of more than one dev, on the same codebase, is a difficult and error-prone task, and it turns out that, much like many unpleasant tasks – such as washing up – it’s actually less painful if we do it more often. I write a bit of code, and the tests all pass locally for me. But I can’t be sure that when my code is merged with Bob’s code, they still will. So we automate the integration and testing of our combined efforts. But if it’s just me, then my local working copy, once checked in, is identical to HEAD, so what’s to integrate? Ok, so our CI build is often more extensively testing things than a local build, but on a small one-man project, I doubt the testing overhead is anything a cup of tea won’t take care of.

So back to our chat. My friend said he’d quite like to have a Hudson or something deployed somewhere, anyways, and I know what he means. I used to do it. I’ve had CruiseControl or Hudson boxes running at home, and I’ve had Hudson deployed on a VPS alongside Readonlytwitter. It was quite fun, being able to do a bit of coding at work during a lunch break, commit the code, and then see that the build had passed. Then I realised I was never getting a broken build, and decided the whole thing was a waste of time.

What I recently remembered, though, was that before I dumped personal CI, I was planning to use Hudson to give me single-click deploys. I still want that. But I’m not going to use a CI app to do it. A week or so ago, I started re-writing my company website as a Rails app, just for shits and giggles, and bunged it onto Heroku. I’m unconvinced Heroku is really for me, at least for that particular app, but I really like their Git-based deployment workflow, which seems absolutely perfect for solo projects. So I’ve set about building such an environment for my own apps. How does it work? I have 2 remote Git repos, one which I do dev on, etc, and another that I push deploy-ready code to, upon which that code gets tested, built, and deployed to my live container. So far, it’s proving fairly easy to achieve, with a bit of Bash scripting and some Git hooks. Once I’ve finished it, and made it easily repeatable, I’ll write part 2 of this post, tentatively titled Pushing A Grails App Live Without Any Tedious Manual Steps.

Do we really need to estimate?

So obviously, I haven’t posted anything on here for months, for a variety of reasons. But recently, I discovered, which is quite awesome at forcing you to express your thoughts, even if you don’t think you’ve got any particularly worth expressing. The idea is, you sign up, and write 750 or so words, every day. They’re not published, it’s not a blog, so stream-of-consciousness is the order of the day. And guess what? Today, without even setting out to, despite having no idea what I’d be writing about when I sat down, I wrote what will form the bulk of this post. I wrote about the practice of estimating, as carried out in planning games, planning poker et al.

First off, a quick outline of how my current team runs a planning game. There’s no real need to read this properly, just skim it, or don’t even bother reading it. It doesn’t matter, really. Ours is a relatively typical planning game, probably erring on the side of slightly better than average. It goes like this: The team sits around a table, and our product owner has a bunch of cards he wishes to present to us, each card being a typical user story. “As a user I want to put pictures of lolcats on my website”, that sort of thing. The product owner presents a card, which basically means he reads out the description, and then the QA engineer goes through what acceptance criteria have to be satisfied for the card to be considered ‘done’. Once this is done, the devs have an opportunity to ask questions about the card and the acceptance criteria. We might ask one another how this work should be done, we might question whether it should be done at all, we might adjust, add to or remove acceptance criteria, or decide that the card should be broken down into smaller cards. Often, the card is self-explanatory and clear enough that we don’t bother with this at all, and just move straight to estimating. The underlying question is always “Do we have enough information to estimate this card?” Once we do, we estimate, which involves us simultaneously expressing how long we think the card will take, by holding up cards with some numbers on, or fingers, or smartphones with numbers drawn on the screen in some way. We then decide, based on this, what we as a team are estimating. This might be as simple as taking the majority vote, but if there’s a large discrepancy, such as a really low estimate and a really high estimate, further discussion ensues. When we finally reach a decision, the estimate is written on the card, and we repeat the exercise with the next card. Estimates are made in ideal pair-days, which is a day of typical effort from a pair of developers working on the card, and we can estimate anything from 0, up to 3 pair days, in increments of half-days. Anything above that, and we have to break the card down. This exercise is repeated for each card. It can take hours.

If some of the above sounds a bit tedious, you’re not far wrong. Planning games are tedious, and for me, the entire approach is riddled with assumptions which are just accepted as being right, where they really ought to be challenged. Not least of which is that there’s a need to do them at all. If you skimmed over the description above, good for you, you’re probably already agreeing with me. Estimating how long our work will take, like having a hierarchical management structure, is one of those things we just accept as a fact of life, when of course there’s no real reason for it to exist, unless there is an actual reason, of course. An expressable reason, mind you, not simply a variation on “because that’s how it works.” Sometimes, there can be a good reason for an estimate. It’s not entirely unreasonable for someone to want to know when they’ll get the thing they asked for. But here’s the thing: in our planning games, if estimating a particular card takes a long time, or we seem to be struggling to reach a decision, someone – usually the scrum master – reminds us that it is only an estimate, and we’re not obliged to be exact about it. So what’s the point then? We’re not drawing up any charts of how long things take compared to how long we said they would – we don’t have that sort of information factory running – and nobody gets overly concerned if a card goes over or under its estimate. There isn’t anybody watching us saying “You’ve got half a day left to get that card done.” A feature takes as long as it takes to implement, and that’s that.

Not to mention that we, as a species, are pretty rubbish at estimating anyway.

I’ve worked in places where estimating is abused. Typically, if an organisation starts holding you to your estimates, you start holding them to your estimates too. Say I estimated something at 3 days, and got harrassed when I was still at it 4 days later; I’m not going to get my work done any quicker, I’m just going to over-estimate the next one to give me some leeway. In some circumstances, people will grossly overestimate work, so they can get it done in a fraction of the estimated time, and use the extra time to dawdle, and piss about. I’ve seen it done, I’ve probably even done it. Luckily, where I work now, we don’t foster that. Nobody holds anybody to an estimate, we just do the work, and when it’s done, pick up the next card.

Which makes me wonder yet again, why we bother with the estimates in the first place (are you getting the idea yet?)

Another flawed assumption is that a pair-day is a consistent measure of effort. Sure, we call it an “ideal pair-day” but the underlying assumption is that a task will take any combination of any of our devs the same amount of time to complete. Nonsense. We all have different skillsets, strengths and weaknesses. Of course, the mantra “it’s only an estimate” is repeated again in mitigation of this flaw, where really it should be an alarm bell, a smell, something telling us we’re doing the wrong thing.

As for the limit of 3 days for a card, that is simply bizarre. To pretend that we know, in advance, the maximum amount of time any feature will take to implement, whilst simultaneously claiming to have adopted a working practice that explicitly exists because such things cannot possibly be known in advance, is frankly bizarre. Of course, the counter-argument to this is that anything longer than 3 days should be broken down into shorter cards. Well, maybe. Sometimes, that might make sense, and I’m all in favour of fine-grained stories, but quite often you’ll find that we’ve broken the card down simply because we’re not allowed to estimate it at 7 days, but actually talk about the feature as a whole, and don’t consider it complete until both cards are done. So right there, we’ve put our process before our customers and ourselves. So much for “individuals and interactions over processes and tools”, eh.

As an experiment, in our next planning game, I’m going to suggest that we estimate every card the same, regardless of what we think of it. Say, 1 pair-day per card. Then see if anything’s different at the end of the iteration. My bet is, it won’t be. This gives much more leverage to the argument against estimating. Conversely, if something is different, that gives us something to focus on, a part of our process that is perhaps working better than we thought, and that’s equally a good thing. I’m not married to the “drop estimating” idea, which is exactly how it should be. I’ll post the results, if any, when I get them.

One final thing: if you’re reading this and thinking “But we need to estimate to make sure our devs are actually doing some work!” then I think you’ve got bigger problems to worry about. Trust is a big deal to a dev team – if you trust us to get on and deliver what you’ve asked for, there’s a good chance we’re going to exceed your expectations. Act like we’re a bunch of shirkers, looking for an opportunity to skive, and you’ll see productivity drop through the floor. I’m yet to see an exception to this rule. Srsly.

Unit-testing RESTful Jersey services glued together with Spring

So I’ve recently been playing around with building RESTful web services using Jersey, the production-quality reference implementation of JAX-RS. It’s a neat library, and, to my mind, simpler than other offerings such as Restlet.

However, this post isn’t yet another Jersey tutorial, there are millions of them already. I’ve found the quickest way to develop REST services is top-down, layer-by-layer, feature by feature, and it’s also one of those areas where test-driven development really shines. Luckily, Jersey comes with some good support for unit-testing, in the shape of the JerseyTest class, which leverages a bunch of container adapters to allow you to quickly and easily deploy resources to a container programmatically, and fire real HTTP requests at it. I use the excellent lightweight Grizzly container for this, it’s what works by default.

There’s a problem, though. I like wiring things together with Spring, and although Jersey provide a servlet for configuring your app with Spring, resources and all, it doesn’t actually let you get at the application context, so getting hold of beans from it is a no-no. Using Spring’s JUnit support doesn’t help, because both it, and the Jersey test, create separate, identical contexts. This means, if you need to use something from the context in your actual tests, you can’t. I want to. I like having my resources delegating down to a service layer, and I like mocking this layer out for some tests.

So after a few quickly-dead ideas involving awkward factory methods that let me reach into specific classes in the context, and a singleton servlet for testing – yuck – I had a dig about in the Jersey source code and came up with a little tweak, and subclassed JerseyTest to give trivially easy access to it. If you’ve used JerseyTest, you’ll be right at home, it works exactly the same way. Use the WebappDescriptor.Builder to configure your app, make sure your Spring context allows annotation configuration, and use Spring’s @Autowired in your test class to get any dependencies you need from your context.

Onwards with the obligatory example.

In the following test, I have a RESTful resource which delegates to an some service or other for some work. I want, for unit-testing purposes, to mock out this service. That means, both the RESTful service and the unit test need a reference to the same mocked service. Here’s the test class, with an instance variable declared to hold the service in question, annotated as Spring @Autowired.

public class JerseySpringTestSupportTest extends AbstractSpringAwareJerseyTest {
	public JerseySpringTestSupportTest() {
		super(new WebAppDescriptor.Builder("com.riffpie.common.testing.jersey.resources")
        .contextParam("contextConfigLocation", "classpath:test-spring-jersey-integration-context.xml")
	private ArbitraryService service;
	public void testServiceWorks() throws Exception {
		String input = "this is the input";
		String output = "THIS IS THE OUTPUT";
		String response =
                          .queryParam("input", input)
		assertEquals(output, response);

And here’s the associated Spring config. I use Mockito to mock out a service – which I won’t patronise you by posting here – and inject it into the resource, which I also won’t post here.

<beans xmlns=""
    <context:annotation-config />
   	<bean id="testResource" class="com.riffpie.common.testing.jersey.resources.EchoResource">
   	  <property name="service" ref="delegate"/>
	<bean id="delegate" factory-method="mock" class="org.mockito.Mockito">
	  <constructor-arg value="com.riffpie.common.testing.jersey.ArbitraryService"/>

Your test instances are passed to the application context for auto-wiring, all the necessary dependencies are injected, and you’re away. Simples.

Well, if it’s source code you’re after, release 1.0 of the test class is available here. The source includes the actual classes used, as well as a more complete unit test than the one presented here. If you’re a Maven user, add my Maven repo to your POM, your settings.xml, repo manager or what have you, and use this snippet in your POM to use the library yourself. I’ve even included out-of-the-box support for cookies, which usually takes a bit of buggering about with Jersey clients.


Groovy HTTP with Camel

So I’ve been working on an ActiveMQ load-test harness – written entirely in Groovy, fact fans – on and off for a while, and today started exposing some simple admin tasks over HTTP. I used Groovy dynamic method names to some neat effect, and making it simple to add new functionality to with little effort. Here’s what I did, with specifics left out of course.

First, the camel route and relevant Spring stuff, expressed in Camel’s XML DSL:

   <from uri="jetty:"/>
    <process ref="httpProcessor"/>
  <bean id="httpProcessor" class="com.riffpie.names.changed.protect.guilty.HttpProcessor"/>

Pretty straightforward stuff. If you’re wondering why I chose XML as the DSL, there are a couple of reasons. Largely, I just seem to personally find it more expressive, but of mileage varies enormously on that one. Also, I’m used to using the XML DSL here, as we usually have multiple, country-specific configurations of Camel-based apps, and it’s worked out easier to configuration-manage XML to this end. Lastly, and this may well be something that’s been fixed, but in the version of Groovy we’re using here – 1.6.5, yes, I know – anonymous inner subclasses of actual classes simply didn’t work. Groovy interpreted them as implementations of interfaces. So extending RouteBuilder and such involved writing further top-level classes, and I simply couldn’t be bothered. It seemed a shame that Groovy actually made for more code than the equivalent Java, so I didn’t use it. So there you have it. On with the example. The neat bit is that HttpProcessor class, and how simple it is to extend:

import org.apache.camel.Exchange
import org.apache.camel.Processor
class HttpProcessor implements Processor {
  void process(Exchange exchange) {
    def action ="action")
  def listClients(ex) {
    ex.out.body = "list clients would be implemented here"
  def stopClients(ex) {
    ex.out.body = "stop clients logic goes here"
  def methodMissing(String name, args) {
    args[0].out.body = "couldn't do " + name

So the client end simply sets an action=? header on the request, and this class takes the value, and using some Groovy magic,  invokes that method. If it doesn’t find it, I’ve overridden methodMissing with something that just responds with a “no chance, mate” message, and we’re done. Adding a new action is as simple as adding the appropriately-named method to the class, and let things work themselves out.

As an aside, I started out writing this class with a map of action-name – closures, but that left me with some clumsy old-fashioned conditional code for if there was no action provided, or an unknown one. I felt this alternative made for neater, more compact code, and ran with it.

Of course, this is just the application of the pattern that I happened to be using when I felt like blogging about dynamic method names. There are tons of possibilities for them.

Til next time, cya

Unit tests have all sorts of uses, y’know

Unit tests are marvelous things, I don’t believe it’s even necessary to make a case for them any more. But what is it that they do? Aside from “oh, test units” of course. Well, what they really do is they allow you as a developer, to test certain assumptions you’ve made. You might, for example, assume that certain values passed into a method will cause a certain value to come back, and use unit tests to check that. Or that invalid input will be gracefully handled, rather than bringing the entire app crashing to the ground. That sort of thing. But they can be used to test other assumptions, too. They can be used to test assumptions about, say, the environment in which they’re being run.

Something else unit tests are useful for is a means of communication. Want to know how to use a particular API? A good place to start might well be the documentation, but another good place is often the unit tests for that API. After all, what is a suite of tests, if not a (hopefully) comprehensive example of how to use particular pieces of code? Documentation might well explain that to call method doFoo, you have to construct both a Bar object and a Baz object, and pass them into doFoo, but seeing a unit test actually doing it speaks volumes. But unit tests can also be used to communicate other things. Like what your build environment should be.

See where I’m going with this?

How often have you tried to build some code on your machine, and failed, only to discover later that your box wasn’t set up right for the build? It happens to devs here all the time, and it’s a nuisance. Example: you check out a large project, run the build, and get a whole raft of test failures. The continuous integration build is working fine, no other dev is having similar problems, but you can’t build it. A bit of digging into test failures, and you find that, say, some database tests are dependent on a particular host name being pointed at your local machine. Or a bit of asking around reveals that you need a certain properties file in a certain location, with certain values present, in order to get it working. Now, it’s really questionable that such things need be true at all for a developer build to work, and if you’re in this situation, perhaps your local build is doing too much and it’s time to look at staged builds. However, that’s a different nut to crack.

If you are in a place where these not-really-unit-tests are being run on developer boxes, you can leverage unit tests to ascertain very quickly whether the build environment is correct, and report on what’s missing. Build dependent on a properties file? Write a test that checks for it, early:

public void testStoreIDPropertiesPresent() {
  String filename = "/etc/company/properties/";
  File propertiesFile = new File(filename);
  Assert.assertTrue("You don't seem to have the file '" + filename +" ' on your machine", propertiesFile.exists());

Likewise, if the database tests rely upon a host name, write a test that makes sure it can connect, and catches the appropriate exception. Or anything else you care to think of. Give it a meaningful name, because in a Maven build, you’ll spot that failing a mile off, without having to go trawling through Surefire reports to find the cause of the failure.

Of course, if there are such quirks of your build, you really ought to be documenting them – a README in the root of the project works wonders, but there’s no harm in checking the environment, rather than just assuming it’s been set up correctly. As a build increases in complexity, the likelihood of there being quirks like dependencies on the environment increases. The worst thing you can do is rely on word-of-mouth to communicate them. Documenting them is a good idea, of course. I’ve heard several different ideas floating around regarding exactly how. “Put them on a wiki page”, “create a ‘starter pack’ full of documents about these things”, “provide a README” etc. All well and good, but the thing about such documentation is, it’s used as a sort-of getout clause by the guy writing it. “I’ve put it all on the wiki, it’s not my fault if nobody bothers to read it”. Err, no. That’s a poor attitude to take. Documentation is a passive medium, we shouldn’t just assume everybody’s read it. Human nature being what it is, it’s folly to do so, and worse to hide behind such assumptions in order to absolve ourselves of responsibility. If “documenting things” was such an infallible medium, it’s unlikely we’d need unit testing in the first place.

I’ve talked specifically about leveraging unit tests to check that a build environment is in order, because it’s something I get bitten by frequently, and see others around me being similarly bitten. I’m sure it’s not the only side-usage of unit tests there is. I’d love to hear about how others are using them for things other than merely testing code.