Out of a job for the moment, but back into hacking

Ouch, rough week. My position in Adelaide was made redundant just as I started to get some traction. Doh.

This week's focus:

• Go and dust off ruby, and rails skills, with the intent of building a linked data recipe mashup. Turns out in all of the waiting, someone has just gotten all of the data and done the linked data thing with it; the thing which stopped me dead the last time. Coughing up a workable UI for getfridged should be a snap, and gives me a chance to update my knowledge to Rails 3.0.
  Status: We're already sending pull requests on github, I'll hopefully be back up to speed within 2-3 days.
• After the rails bit, make sure I can still hammer out python. Something quick and dirty in python/gtk; talking to tracker over dbus might be the go to display neat statistics or information about your local desktop PC.
• Job applications: I've already put quite a few out there, and a few promising contacts so far.
  
  I've split it into two areas - happily looking at a wide variety of PHP related work; just to get back to something I love and to continue eating. While that's happening, I'm also putting our feelers around the architecture side of things - I was getting pretty darned good at breaking down communication barriers and Getting All of the Enterprise Java Developers to Talk on Friendly Terms.
  While I would certainly need a crash course to go from "intermediate Java" to "highly productive enterprise Java developer"; I can actually work well in a project role with the design of services, diving deeply into a domain and comprehending a data model.

I'm particularly proud of the work I did - building ValEx for 5-6 years from an idea in a back room of a small Adelaide business into a twice acquired, market leading platform.

I really ramped it up when my focus changed from ValEx only to RP Data transitioning to a SOA - I kicked down barriers, established communication between Dev, QA & business teams spread across Adelaide (2 teams), Brisbane (3-4 teams?), Sydney (2-5 teams/projects/etc?) & Offshore (2 teams?), and wore no less than 3 hats at all times (Solution Designer,  Developer, Project Manager, Data Modeller, Architect, Tinker, Tailor, but not yet Candlestick maker)

Some of the projects I did included:

• Rewriting & integrating an existing RP Data product in a SOA fashion, integrating with 3 different legacy platforms.
• Delivering parts of the RP Data consumer strategy - first in New Zealand back in 2011, and a much delayed linking of legacy platforms which I had been championing for some time more recently
• Fixing the address search problems within RP Data by an extra 8% or so, and advocating for a practical implementation of the next steps.
• Providing guidance to LIXI on improvements to the LIXI Valuation Standards, given the updated release of the Property Pro Supporting Memorandum 2012
• Providing detailed technical guidance on how LIXI can meaningfully adopt OWL or Linked Data related standards, continuing the discussion started by NICTA in 2008.
• Establishing stable identifiers on a number of diverse data sets, as initial steps towards linked data in the enterprise; amid a number of legacy ETL processes and other quirky things.
• Providing real world, usable QA controls (assess a transaction against external data sets, route and alert humans to abnormal information) based on linked data in a fairly complex workflow system.
• Finally delivered an incremental business intelligence improvement, plus helped coax some of the operational reporting onto something more like a SDLC, mostly by sending people pictures of Yetis whenever an SQL fragment was emailed, not put under version control. Pro-tip: Don't feed the SQL Yeti.

... and that's just the last twelve months of what I can remember. My biggest fault was not being able to explain it consistently and clearly enough - there barely seemed to be any time!

I miss the ValEx development work more though. I fondly remember making it snow over Christmas (which then promptly nuked the performance of all FF2.0 or lower users, oops); of hacking code all day but finding the really interesting problems to solve only at the union hotel after hours; of putting in the hard yards to get two major and several other important banks integrated, and efficiently working; of being able to walk into any section of the operational business and having friends who I could help by making computers work for them, every day.

I guess that interaction paid off well - there was such a rapid outpouring of support from everyone in Adelaide - from when I found out Thursday morning, and word spread a bit; right up to the last few moments on Friday.

I could not seem to make it ten minutes without someone offering a heartfelt condolence, or pushing a drink into my hand, or offering to help me get my foot in the door somewhere.

Behaviour Driven Development

Behaviour Driven Development swept in like a breathe of fresh air.

Basically, it's unit testing (ala JUnit), but at a higher level - it's also an implementation of capturing user stories.

For example:

Scenario 1: Account is in credit
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned

becomes

public class AccountIsInCredit implements Given {
public void setup(World world) {
   …
}
}

public class CardIsValid implements Given {
public void setup(World world) {
   …
}
}

public class CustomerRequestsCash implements Event {
public void occurIn(World world) {
   …
}
}

... and so forth.

All of your assumptions then get instantiated, and evaluated, before passing off the results to the outcome handling bits.

Doesn't sound like much, does it, but I'm always running into problems like this.

public function testDoesntAllowDatesInThePast() {
     $foo = $this->document;

      try {
         $foo->Date = "1900-01-01";

         $xml = $foo->asXML();

         $this->fail("SanityFailureException expected!");
     } catch (SanityFailureException $sfe) {
       
     }
}

public function testDoesntAllowDatesInTheFuture() {
     //... The same expectations are checked, across 95 other tests as well.
}

With JBehave, I'd be able to piece together several different pieces of setup - make the objects, set values x,y,z; call some other function over there; and then inspect the results I get back at a much higher level of detail.
I could simply have a "does it validate against an XSD" outcome written, as well as two or three other fine grained ones.

Using Agile Documentation, you can make something somewhat comprehensible to business people; as well.

The above example would become

XMLDocument
- Doesnt allow dates in the past
- Doesnt allow dates in the future

Go and have a read of Dan North's blog for more about this

A friendly reminder

Follow style convention or be stabbed.

That is all.