Much of the IT industry seems to be jumping on the agile software bandwagon (or maybe that should be the Agile software bandwagon). At Black Pepper we recognise the value of most, if not all of the tools in the agilista's kit bag, As you can probably see from our other blogs we're pretty fanatical when it comes to build pipeline, test automation and light management tools, but I guess that's another story.

The point is though that all this agile IT is pretty useless if it doesn't help the business. As a result we should be aiming for Business Agility rather than agile IT. And if agile IT can be a term that is used to mean just about anything you want it to, then business agility is just as easy to spin to whatever message you want.

In fact if you go searching for Business Agility you'll just as likely get stuff on enterprise visibility & streamline provisioning, ESBs, SOA and perversely ERP, plus one company that is called Business Agility, but seems to sell Microsoft software solutions. All of these seem to be somewhat missing the point.

So let's start with a definition, we think ...

Business Agility describes how quickly and cost effectively a business can adapt in response to a changing business environment.

It's probably not perfect but good enough to help us think what it might mean. Speed and change are clearly key components, but cost effectiveness is critical. And how can we be cost effective if we can't guarantee predictability, have our sourcing strategy sorted out and stop wasting money on low value, high cost activities. And that's irrespective of whether we are an HR team or and IT team.

Looking at IT it boils down to a few key areas :
1. being able to handle change, whilst remaining cost effective and predictable
2. by becoming a trusted contributor of ideas and services to the business
3. by giving the business back control of its projects so that it can react best
4. by demonstrating how investment in IT is reducing cost, increasing quality and innovating

Great - so now we have a better vocabulary to describe why things feel broken and "what more for less" really looks like. Fixing this all is a tall order maybe, but all eminently do-able. The answers have something to do with the agile IT buzzwords, but not everything !

Anyway - take a look at our Business Agility with IT white paper if you like or contact us directly and we'd love to start a dialogue.

I wanted to move my /var/lib/mysql directory to /data/mysql (a new partition). So I copied copied them and made the appropriate change in /etc/my.cnf. On restarting mysql with /etc/init.d/mysql start, I got a failure. 

On looking in the /var/log/messages file, I found:

Nov 23 17:48:46 carpenomen kernel: [ 2714.258037] audit(1227462526.718:13): type=1503 operation="inode_create" requested_mask="w::" denied_mask="w::" name="/data/mysql/carpenomen.lower-test" pid=19659 profile="/usr/sbin/mysqld" namespace="default"
Nov 23 17:48:46 carpenomen kernel: [ 2714.310572] audit(1227462526.770:14): type=1503 operation="inode_permission" requested_mask="rw::" denied_mask="rw::" name="/data/mysql/ibdata1" pid=19659 profile="/usr/sbin/mysqld" namespace="default"

I recently upgraded to Ubuntu 8.10, and everything works really well apart from the dual monitor support.

 My laptop has an NVidia graphics chip set. The laptop screen works well, but the attached second monitor was blank and did not show up in the display configuration applet (System > Preferences > Screen Resolution).

After installing the proprietary NVidia driver (required when I selected "Extra" level visual effects from the Appearance applet (System > Preferences > Appearance) the fix is relatively straight forward, a slight tweak to the /etc/X11/xorg.conf file, changing the the "Device" section to look like this:

Section "Device"
    Identifier  "Configured Video Device"
    Driver  "nvidia"
    Option  "NoLogo"    "True"

    ## JohnE added the following options for dual monitor support
    Option  "TwinView" "True"
    Option  "TwinViewOrientation" "RightOf"
    Option  "UseDisplayDevice" "CRT,DFP"
EndSection

I've written in an earlier blog entry about writing acceptance tests in Java for a Flex front ended web app, using Selenium RC. Here I'll describe how we added those tests to our continuous integration build, using a Hudson job as part of our build-and-deploy pipeline.

Our web app comprises two components, a Java server-side component and a Flex client-side component. The Java component is built by a Hudson job as a war file. The Flex component is built by another Hudson job as a zip file. These two Hudson jobs are independent, fairly standard projects built by Ant, each with its own set of unit tests. To run acceptance tests, we need both components to be deployed into the target environment. We created a third Hudson job which aims to deploy the latest artifacts from the Java and Flex jobs, start up Tomcat and Selenium, run the acceptance test suite, and shut down Tomcat and Selenium. This Hudson job depends on the other two jobs and its build is activated when either of those two completes.

As we are already using Ant to control the two component builds, and our acceptance tests are written in Java, we decided to use the Ant build for the Java component as the home for the acceptance test build. Here's the target to run the acceptance tests in the Hudson CI environment:

We have been using agile development methodologies at Black Pepper for a while now and have used Mingle in the past as an online tool for managing stories and iterations.

However, we recently decided on Jira as our feature/bug tracking tool of choice and thought it would be interesting to see if we could use Jira to manage our agile projects rather than have more than one tool.

One of the cornerstones of an agile project is tracking your velocity. This is essentially a measure of how much work you are doing over a period of time. Agile projects are run in iterations, these might be a week, 2 weeks or perhaps a month. The length of the iteration would depend on the project, but 2 week iterations are a good start. Each iteration has a collection of "stories" assigned to it. A story is basically a single feature that has been defined through your analysis of the project before the first iteration. Note that as this is an agile project, you don't have to analyse the project completely up front and have everything mapped out. You just need enough to get you on your way, you will be creating and estimating more stories as you go.

 

We've been pretty busy recently, one of our major pieces of work has been helping Tradefair launch their Hi Lo product, and the trading exchange that supports it.

You can see the product in action here ...

JAOO 2008 was brilliant.
My top three talks, as requested by the conference feedback form:

• Failure comes in flavors by Michael T. Nygard: because the lessons in how to prevent and recover from failure were valuable and the failure stories were funny.
• Software Architects and Testing by Peter Zimmerer: because the message of making testing your responsibility, as software architect, and promoting testing practices to your team, was right.
• The Lively Kernel by Dan Ingalls: because of the mind-boggling demo of rotating stars, clocks and worlds created on a base of JavaScript and SVG.

My other feedback was on water.

“It is about bottled water. This comes at a big environmental cost. I suggest that instead of offering free bottles of water every day, each conferee gets one empty bottle which they fill as required from water fountains or water coolers placed around the conference area.

This morning got off to a slightly shaky start with Lars Bak's presentation about the V8 JavaScript VM that's in Google Chrome not being visible on the screen for about ten minutes while they struggled with the technology. When he eventually got going, it was worth it, and very interesting to hear about some of the challenges in representing JavaScript classes within the VM. They ran some benchmarks - a browser race animating a circling spinner and some more conventional comparisons - between Firefox and Chrome. While I do tend to take these things with a pinch of salt, Chrome was genuinely around ten times faster than Firefox, which is at least enough to make one want to try it out. Now all we need to do is wait for the Linux and OS X ports which, Lars assured us, aren't waiting on V8 - that's done. The graphics is taking a little longer...

The highlight of the day was definitely Michael Nygard's long talk (the JAOO term for two back-to-back sessions) on failure. He presented some great war stories and examples of the kinds of failure that developers can generate with consummate ease when deploying applications to large-scale production environments. He expressed them as anti-patterns in the first session, and then spent the second offering some suggested patterns to be applied to counteract, or rather, prevent them occurring. He's an entertaining speaker, and I'm sure has sold quite a few copies of his book,
Release It!, as a result. I ordered a couple of copies for the office pretty much straight away.

In other news, Jim Coplien didn't shy away from insulting his audience and provoking controversy (as usual, some might say) in taking architecture into an agile world. I'm not sure that he actually ended up talking about architecture as such, but then it's one of those terms that can be used to mean many different things depending on the context. The other sessions of the afternoon were less spectacular - the ones on REST blogged about by Badger covered a lot of the ground that we've been looking at in the office recently, and which will, I'm sure, be covered by other Black Pepper blogs to come.

Tuesday

(Late Monday evening) Chatting with Martin Fowler and ThoughtWorks founder Roy Singham, I was asked to compare JAOO with other conferences that Black Pepper employees attend. The only real comparison for me was with JavaOne because that's the only other conference I've been to in recent years. But the difference is clear and JAOO wins by a Danish Mile.

The quality of the speakers, the material they cover, the ease of access from Europe, the focus on development and developers and the non-partisan context all make JAOO a much more exciting and rewarding conference for me. I still love JavaOne, but JAOO as something special for developers seeking to do better.

Just back at the hotel after a fairly long day and some interesting sessions. There seem to be a few very popular phrases here this year. People are talking about the differences between declarative and imperative programming languages - a great session by Anders Hejlsberg this morning on programming languages and the fact that we should perhaps be focusing more on the 'what' of programming rather than the 'how', with examples from C#, Linq and F#. Since we're reaching the limits of Moore's Law, it'll enable language systems to have more control of the 'how', and perhaps more importantly, the 'where', making systems more easily parallelisable and thus distributable.

Then I found out about Gant. It's Ant, but with build files written in Groovy rather than XML. There we go, the declarative/imperative comparison again. All the usual Ant tasks are available and accessible with syntax that looks very much like the original XML but translated directly to Groovy. If your build files are trivial, then it doesn't really gain you much, but if you're finding that your build.xml isn't very DRY, or you're ending up using a lot, then it's probably worth giving it a try. And if you're finding that you have lots of cause to use ..., then you probably ought to look at gant. If there are tasks that you find you can only achieve by calling out to external scripts (such as the example that we were talking to Martin Fowler about over lunch then there's no question. There's even a nice tool to convert your existing build.xml, ant2gant and a gant ant task so that you can write a 3-line build.xml to integrate it with your favourite CI tool. Nice.

After lunch there were a couple of interesting-looking talks on cloud computing, but one tried to pack waaay too much information in to the available time and so ended up going too fast; the other overran wildly and was a bit too much of a product pitch for VMWare (as I had feared from the abstract) for my liking.