Here’s a list of the component parts:

• an Arduino ATMEGA328
• an Internet Shield
• code to parse the json api output of Hudson and drive the LEDs based on the status (colour) of the builds
• a few high-power LEDs to glow as brightly a possible (might whack some more in there one day to really make it glow)
• a dome (with previous lamp removed) from IKEA

This version is much prettier than the tupperware version I produced previously.  However, I did have to up the LED brightness so they can actually show through the pearlised lamp dome.

The next version will trigger a sound when the build status changes so the team knows that something’s gone wrong sooner (and that normality has been resumed when the build is fixed).

NOTE: The ‘bling bling piggy’ is always nearby to help lighten the pockets of those who break the build.

Update:  David actually blogged on this too: http://blogs.mulesoft.org/presentation-eai-when-tools-can-help/

The big thing for me about this presentation was that it finally tripped a switch in my brain: Enterprise Application Integration patterns don’t have to be about asynchronous queues and such, it’s about all the different ways systems integrate.  That includes simply copying files around, for example.  I honestly wish I’d realised this a few months ago, it would have given me the insight to stop a strange project using rails and leverage an existing EAI engine/framework.  Despite the learning curve we would now have a less custom, and more tested, system.  Better late than never?

I’m also currently on a mild clojure kick.  Having done the Bowling Game Kata in Groovy and then followed it up with a clojure version (thanks to this link for some hints) I thought I’d try to get a simple Apache Camel example up and going in clojure.  The first hit on Google proved very useful for guidance.

Simply trying to get that (and the bowling) example up and running made me have to dig into so many different things:

• leiningen - a clojure wrapper for maven
• Polyglot Maven - a wrapper for maven in several different languages so XML can be shunned
• test-is – a simple unit testing library in clojure-contrib
• AOT – ahead-of-time class creation, amongst other things this allows clojure to run in a binary form (no need for source in production).
• Counterclockwise - an Eclipse plugin that adds support for clojure editing and running (with very pretty, and effective, rainbow bracketing)
• Clojars.org - a maven repo for clojure jar files
• Cloduino can be used to allow clojure to interact with Arduino boards
• Getting started with clojure - this link has a bunch of detail on getting started with clojure.
• labrepl - a learning environment for clojure
• I fired up Idea for the first time in ages and install La Clojure just to try it out.

Obviously, I have only scratched the surface of these things, but at least I know about them now and have a better overall handle on clojure and EAI.

I really do love learning new things and the VanDev meetup triggered more of this than normal.  So I encourage you all to come to VanDev or find a similar meetup near you which covers things that you really enjoy (I’ve got my eye on the local Erlang group next).  

Most of the reasons rung true with me too, especially at the start.  It’s been two years now since we adopted FIT as our acceptance test tool.  We’ve improved greatly since then, but we still have challenges.

1. No Collaboration
   Initially we had developers writing tests and proving the usefulness of the approach.  Unfortunately, the same developers were then tasks with writing a battery of tests against the existing buggy code.  It was a between-project slack period and there wasn’t anything better for them to do.  Unfortunately #2 and #10 came in to play with junior and intermediate devs mirroring the existing system in tests, rather than describing the business requirements.
2. Focusing on how, not on what
   We definitely had a lot of this going on.  We have far more procedural ‘this then this then this’ tests that have a huge amount of setup actions than I like to admit.  We have definitely turned this around somewhat more recently with more abstract ‘business requirement’ tests rather than ‘technical requirements’: the tests don’t change just because the implementation does.
3. Tests unusable as live documentation
   This is my biggest chagrin with the tests, lack of prose around the FIT test tables explaining WHY.  When there are comments they describe what we’re doing with the ‘this then this then this’ style.  Again, we have turned the corner recently but it’s a bugger to retro-fit that kind of knowledge into the tests.
4. Expecting acceptance tests to be a full regression suite
   I think I can own the blame on this one.  I pushed for this to be the case.  In my defense I did push for quick, localized acceptance tests that could run quickly and give the required feedback.  As you may guess, that’s not what we ended up with.  Rather, we got a whole slew of System tests.  They are still very useful tests, they just take longer to run that I want.  In a way it’s a reflection of the system we’re testing: very coupled system begets very coupled tests (maybe).
5. Focusing on tools
   Not really something we struggled with too much.  If anything it was the opposite – few tools in our price range.  We settled on FIT and went forward.  We also use the FitPro Eclipse plugin though it’s limited Mac and Linux capabilities are still a bit of a challenge.  We did look at FitNesse for a while and knowing what I know now I would probably have chosen that as it is more actively developed.  Our biggest perceived challenge was one of integrating with Subversion, in the end it was a non-issue.
6. Not considering acceptance testing as value added activity
   We are doing so much better than before with QA/BA developing the first example FIT tests but we’ve still got a ways to go.
7. “Test code” not maintained with love
   Another sore point for me.  Developers treat our test code as an afterthought and seem to think that good design principles and refactoring don’t apply to test code.  I couldn’t disagree strongly enough.  I am always looking for ways of making my tests simple, robust and expressive.  I often spend a lot longer on my (unit) tests than my production code.  I have hear developers whinge and complain about the test code and how “it’s hard to do such and such”.  I swear that in the time they’ve spent complaining they could have improved the test code ten-fold – but they don’t treat it the same as production code!
8. Objectives of team members not aligned
   We’re actually doing pretty well at this one, we’re a million miles from where we once were.  Our QA guys now sit with the developers and BA’s and there is a true collaborative spirit at times.  I was utterly stunned (shocked, awed, caught-out) recently when a developer said to me “I’ll just commit it and QA can find the bugs”.  I hadn’t realized that that attitude still lived on within our teams.  I guess old habits die hard!
9. No management buy-in
   This one isn’t a problem – I’ve seen too many bugs and mis-understood/implemented features and also seen the benefits of automated acceptance tests to ever go back (so’s my boss).
10. Underestimating the skill required to do this well
    As mentioned above, we definitely struggled with this one initially.  Things are improving as we get better and better with this.  I think the biggest drag was the large amount of tests and fixtures that were written without too much thought that were then copy/pasted or at least aped.

Despite our challenges I think one reason we didn’t fail was that there were several people who held the opinion that ‘failure wasn’t an option’.  We needed to a rigor to our development process: Automated Acceptance Driven Development was a large part of the added rigor.  Yes it takes longer to develop initially, but it pays for itself over and over once you get over the hump.

Disclaimer: I’m no carpenter

Just like software patterns, carpentry joints aren’t a drop in solution.  Joints are a well understood carpentry pattern but they still must be used in context.  The type of wood being joined constrains the joint you can use, the desired appearance constrains which joints can be used, the use of the jointed pieces further constrains the choice of joint.  Further, the thickness of the wood will determine the size of the dovetails for example.  The constraints go on an on.

The difference between carpentry and software development is that the understanding of which joint to choose has been developed and refined by master craftsmen for thousands of years!  You can now buy laminate flooring that just clicks together – but it took the legacy of many, many craftsman hours to make that a possibility.

The take away for me is the re-enforcement of the truth: we’re still the software pioneers.  We’re still lashing bits of code together with rope, we can’t quite get a catalog of time-tested, tried and true joints.  We know enough to know there must be better ways of doing things, we just don’t have a clue of what they are yet.

Software development might just be about pioneer spirit, and anyone who tells you they’ve got it sorted is probably trying to sell snake oil to the prospectors.

[1] Image used under the terms of the Creative Commons Attribution 2.5 Licence – Author: Dumitru Rotari

Anywho, I got to code and I really enjoyed it.  I had written some of this code a while back, but without any tests.  I was allowed to do this because it was just a spike – it wasn’t intended to be production code.  But today I was to turn it into proper code.  Here’s what happened:

1.  Removed extraneuous code I had added as an experiment into component transparency – exposing this as an JMX MBean.
2. Removed other code that wasn’t going to be used in the first cut of this component.
3. Create a JUnit 4 test case.
4. Unit test #1: test that the delegate call works as expected – just what should happen when the circuit breaker is in the Closed state.
5. Unit test #2: test that the circuit breaker trips when a single failure occurs (with the failure threshold set to 1).
6. Refactor the test to make them more concise.
7. Unit test #3 and #4.
8. Refactor the tests, refactor, refactor.
9.  #5, refactor, #6, refactor, #7….. continue testing various aspects of the circuit breaker.
10.  Refactor the test cases and again and again.

I had previously written the code as a spike and tested informally using a browser within the webapp.  But now I wrote the unit tests to prove that I hadn’t coded any amusing bugs.  I wrote each of them so they would fail first, but I was testing existing code – not quite following the word of TDD but living the spirit.

But the thing I brought away from this was the amount of refactoring of the test case I did – I barely changed the existing code which was pair programmed originally.  The amount of test code refactoring reminded me of some work I had done previously about how a specific featureworked.  During my investigation I wrote a set of unit (missing) tests that got refactored and refactored and refactored until it made sense to someone who might care: not just a developer.  This took a good chunk of time to develop, but in the end I was able to publish a literal test as a Javadoc example that would make sense to your Grand Mother!

I did a similar job on the circuit breaker testing – pushing down on the test until it was concise and expressed my intent.  I squished and squashed until I had some really neat assert* statements that made sense for this component:

• assertDelegateExceptionThrown
• assertCircuitBreakerFailsFast
• assertDelegateCallSucceeds

I had previously spent a chunk of time thinking about how this component should function and I reveled in the time I was forced to take in making the tests expressive.

I hope to add the ability to monitor the circuit breaker through JMX tomorrow.  This time it’s going to be TTD.

Mmmmmmm, coding…….

• Bookmark an issue in Jira: http://jira.company.com/browse/PROJ1-53
• Edit the new bookmark
• Give it a sensible name – “browse jira”
• Replace the Jira identifier with “%s”: http://jira.company.com/browse/%s
• Give it a short keyword.  I normally use “j”.

Now you can simply type the following into Firefox’s location bar and jump straight to an issue: “j PROJ2-26″.

You still have to find Firefox and pop open a new tab and such.  I was wondering if I could side-step this and use Quicksilver to jump directly into an issue.  Note that this approach should work just fine with any other browser too.

Following the instructions over at coelomi’s blog I can now jump straight to a Jira issue with very little fuss.  http://coelomic.wordpress.com/2006/01/02/quicksilver-tips/

• Enable the Web Search Quicksilver plugin.
• Copy the Jira url.
• Prepend the url with “qss-”.
• Replace the issue id with three stars “***”.
• Create a new trigger copying the url into the top box.
• Ensure the next box says “Search For” and the next box is empty.
• Assign a hot key for the trigger.

I now have the following triggers:

• Ctrl-Command-j: access any Jira issue – I provide Quicksilver with the full issue id.
• Ctrl-Command-r: access any Jira issue within a specific project – I provide Quicksilver only with the numeric part of the issue id – the project and the hyphen are hardcoded in the url.
• Ctrl-Command-b: same as the one above but for a different project.
• Ctrl-Command-g: A general google search.
• I’ll be adding another to perform a search on our wiki too.

A lot of the content in PTL wasn’t that new to me, as I have previously read several of the books that Andy has read and references from the text.  That said, I definitely learned new things and deepened my understanding about certain areas.

Constant learning is definitely a incredibly valuable thing, I look for it in every potential new hire I interview.  But continually learning in the same habitual way may not be the optimal strategy.  If you apply the agile development approaches to how we learn it suggests that you should retrospect at what works, what doesn’t and that we should be prepared to try different things to see if they work better (rinse and repeat).

Though I’m not a novice at learning, I am a novice at learning using new tools and techniques: when was the last time you learned how to learn in a new way?  So how do I move froward from here?  According to the book, what I need is some novice/advanced beginner handrails to hold whilst I improve.  Different to the other books that I have read around this subject, PTL brings a consolidated set of next-steps in the context of the life of a software developer.

This is the initial list of things I am going to start:

• Read more deliberately using the SQR3 technique, then blog about what I have learned.
  • Read PTL again, this time, read it deliberately.
  • Re-read Domain-Driven Design deliberately.
• Increase my blogging frequency – hopefully doing more often will make me quicker.
• Review my blog posts once in a while – do I still agree? what have I learned since?
• Try mindmaps again having deepened my understanding about how they might help me learn/understand.
  • Redraw mindmaps every now and then – let some mental mushing happen – see what my brain has subconsciously come up with.

Ever more things will come up as I continually learn and continually learn to learn.  I’m still on that journey that started the best part of 33 years ago and one that I hope doesn’t stop for a very long time yet.

I got from it pretty much what I was hoping: an easily digestible introduction into Objective-C.  I had previously read a bunch on the web, but I always find reading books, rather than reading a screen, to be far more effective for myself.  I had many different questions answered from an attempted iPhone coding session a few months ago.

I have been nudging some of the guys at work to start an Objective-C/iPhone/Mac programming study group. This book will be very useful for the novices in the group (myself included) to quickly look up the fundamentals and work through the syntax impedance as they try and push a new language into their Java brains – this was definitely a sticking point with the Erlang study group we had for a while.

In summary, a great, concise reference – just like the title suggests.  It appears that the reviewers on Amazon also agree.

Searching without case-sensitivity – global switch:

:set ignorecase

Searching without case-sensitivity  – for a single pattern:

prefix the pattern with \c

Searching backwards:

? (rather than /)

Search again in the opposite direction:

N (rather than n)

Nothing too thrilling, but it makes using vi that little easier.