Hi all,
so life on the new team was short lived; I am back in the Perl team and working on a new "Acceptance Test Driven Development (ATDD)" project. This is a relatively new approach for the Scrum team I work on and a new part of the product we are testing.

ATDD for this team is basically automating the running of tests that confirm that the product "does what it says on the tin". In other words, we are creating a barrage of tests that run regularly (hourly) and confirm that the product conforms to a set of formal documents. These documents range from standards from industry to product specific behaviours.

Rather than testing edge cases and behaviours, what we are mainly doing is testing the products output in standard situations. Confirming that as it iterates towards the production version the standard outputs remain constant. In our case we are working on something new, so we are coding tests for things as or in places before the product actually does what it should.

So our test dashboards are turning red now, and slowly turning green as other teams enable the functionality we are testing. It is a interesting and rewarding way of working. You setup a test and see it fail, then some time (days or even weeks) later, it magically turns green when the other teams release the latest version of the product and the test starts passing.

One of the key things we did early on was tie our tests to the specification and standards documents. This has proven to be really key as we have in the test results (specifically in the failures) references to shared documents. So when we say to a member of another team "oph hey, feature x is failing because the widget says bing instead of bong" and the person knee jerks a response like "oh thats how it should be". We are able to say "REALLY???... Thats not what document X says. It says it should be bong, see right here on page 42..."

This is helpful for preventing the very human thing of batting things from one team to another as an immediate reaction to someone on another team saying what you have done is wrong. It's a programmatic way of solving a human problem.
We are using code that refers to documents to prevent people arguing. :-)

Beyond this aspect of $dayjob, the team is continuing to develop it's use of TDD (Test Driven Development) and Pair Programming with mixed results.

So it is February already, wow what happened to Janaury!

Thought I should write something to clear my head. This week I head to Paris with the IJF to work at the Paris Grand Slam judo event. Should be good. I am taking my Raspberry Pi with me and then I'll be sending it with colleagues until I meet up with it again in Samsun Turkey in March. I hope I have it setup correctly!

On the $dayjob side of things, this month marks a small change in my role in the office. Whilst remaining the scrummaster for my old team I become a dev team member of a new (related) team. The change is minor but interesting.

My old team is a primarily Perl team, doing console server applications. In the new team as well as Perl, there is PHP and Javascript involved in an internal web application. So I'll be brushing up on my PHP and getting a daily dose of PHP and JQuery.

It's one of those interesting changes in situation that comes along and if you roll with it you learn a lot along the way. I am fortunate that as the existing scrum master for both teams, this is not a case of meeting new people. Sure I have to learn a new codebase and coding style and standard; but I know the team members and all that good stuff.

Back on the Judo side, but locally. My club(s) are going strong; the Southampton club just regained the third place position in the Hampshire Team Championships and we are preparing for the Hampshire Individual Championships.
I am the competitions organiser so it was great to see a good turn out for the team championships and to be seeing entries for the individual championships coem in steadily already.

Anyway... the only real issue is the old work/life balance.
I'm doing my usual trick of burning the candle at both ends and in the middle. :-) Stay tuned for updates on things.

Lance

P.s. hello, if you are reading this please let me know either in a comment or via email. I am always curious if this cathartic exercise of blogging is purely for me, or if there are people out there reading these words.

So, the title says it all. I am trying writing some code in Node (server side javascript) for my Raspberry Pi. I have done some testing and I actually have a working prototype. I am planning on taking my Pi with me to China and Japan and test it there. Not sure yet if I will as A) it might get broken and B) customs may freak out.

Writing Node has been a bit of a brain twister. All the callbacks, anonymous subroutines. It makes my head spin at times. Fortunately Node has a good body of Google-able information and is pretty good structure wise. That said, being a Perl guy, the temptation to switch to Perl grows as what I am trying to do gets more complex.

Which brings me to why I think node is good. Much like Perl, node has a nice repository of shared modules for doing things. The NPM which is like CPAN. Basically, much like Perl, when you decide you want to do something tricky the first thing you do is go looking for a NPM module that does it already. Which is the way you do things in Perl, search CPAN and find the tool that best fits.
So when I wanted to listen for UDP packets, easy just load the dgram npm. Sent a tweet, load the Twit NPM. Need to write to a couchDB database add in nano. Want growl notifications on my Mac... yup load up the Growl NPM. Easy and Simple.

Having written and tested on my Mac, I have tested on the Raspberry Pi. The Pi is a brilliant little machine, cheap and easy. But for what I am doing I need very little resource. Just a linux box with connectivity. I have added an extra ethernet port via the USB socket which works. That way I can be listening on one network (a private LAN) and use the second port to tweet and write to the database via the internet connected port.

It's been easy to manage via github, the toughest part has been my lack of a windows physical machine. So I have been running teh socreboard in a VM on my mac and that has been a pain in the butt as just getting pings backwards and forwards has been challenging... still working out why.

Anyway, off to China then Japan next week, so lots of time on planes and hotels to work on the project. :-)

Lance

In my $dayjob, I spend a vast majority of my time on a Ubuntu Linux machine writing Perl code in VI/VIM. I, unlike I think all my colleagues like the Unity desktop that now comes with Ubuntu Desktop.

I really like the fullscreen terminal window, it gives me lots of screen real estate for my SSH session (with GNU Screen).

It's good, but it was not quite 100% what I wanted, mainly as that mouse thing kept getting used. My Judo shoulders don't like a mouse much, so I try to limit how much I use a mouse. Unity helped especially with GNU Screen, but something was missing.

So lots of Googling and understanding what I wanted later, I was running the Ratpoison window manager in a VM to test it out. A little more testing and exploring and now I have Xmonad running and making me (and one of my team mates) happy with our almost entirely keyboard driven desktop.

Xmonad ( http://xmonad.org/ ), is a tiling windows manager for Linux. That basically means that rather than the "desktop" metaphor with window panes sitting "on top" and overlapping one another; I have windows that tile automatically on a workspace.

When you first login you are greeted by a blank screen, workspace 1.
I press ALT-SHIFT-RETURN and a terminal opens up fullscreen. And I mean FULLSCREEN. I have the menu bar turned off, no status bar, nothing but a terminal session and a single pixel red border.

For me, I then SSH into my main dev server and type "screen -dR" which connects me back up to my GNU screen sessions. In screen I get multiple sessions that persist even if I get disconnected from the server (handy when working from home or elsewhere). I tend to work in VIM and use Screen to have "tabs" for editing multiple files.

Screen makes this easy CTRL-A then c, creates a new "tab" where I can vi a new file. CTRL-A CTRL-A switches back to the original tab. I can have loads of "tabs" and get to them with CTRL and the number of the "tab". My normal modus operandi is to have tab 0 for running unit tests and doing git checkins. Tab 1 for my unit test script and Tab 2 for the code I am working on.

With Xmonad in the mix, I have the nice new ability to open up a second (or move) terminal session locally with ALT-SHIFT-RETURN. This (by default) splits the screen (workspace) in two down the centre vertical line of the screen. If I repeat the process I get a large tile across the top and below it two smaller sessions below it tiled evenly.

I can move tiles with ALT-J/K or change the tiling pattern with ALT-SPACE. It;s very cool and once you get used to the key sequences, it's super fast and means you don't need to take your hands over to the rodent.

I'll write more on Xmonad in a later post I think as it is "the business".
I've not even started to play with the many many customisations for Xmonad, I have the two most basic ones that bizarrely perhaps are not installed by default on Ubuntu. Those being dmenu and gmrun. They, along with Xmonad itself is a simple apt-get away; give it ago.

So, those who read this blog will have picked up that it has been gathering dust as other projects have soaked up my time and energy. Which is not a good thing as I firmly believe that blogging is a important reflective practice that makes me better at the other things I do.

Anywho...

So the "stuff" I mentioned above is mainly two things, a great gig writing perl code and secondly working for the European Judo Union and International Judo Federation on their IT teams. The EJU and IJF stuff is amazing and awesome and great, but I'll save that for my blog over at http://www.judocoach.com

The perl stuff has been awesome too.
Perl was the first language that "stuck" for me, the first one where I really truely got beyond Hello world and occasional hacking. In Perl I discovered creating stuff. Later PHP took centre stage, but Perl held a special place in my heart.

Recently (ok since about October 2011), I had a chance to write lots of perl code in a corporate environment and damn has it been great.

Perl as a language for some reason reads nicely for me. It has a rhythm that makes sense to me. Beyond that it has flexibility and power. It has CPAN and it has a strong community. So returning to Perl has been really enjoyable and writing code everyday is great, you learn something new all the time and that tangible improvement is addictive.

I'm also lucky as I work on a small agile team using the scrum methodology. I am enjoying scrum alot as it really encourages you to work hard and fast, but in short bursts (sprints, tasks and pomodoros). It is a flexible framework that encourages the team to improve it's own working habits and processes, so during and after each sprint there is lively debate over what we do well, what we do poorly, what we can change, what we should change etc etc. Scrum teams are self-organising, so everyone is encouraged to take responsibility for the team and contribute. It's really enjoyable.

I operate partially as a member of the dev team and partially as the scrum-master for two scrom teams. I am enjoying the technical coding side and the more human oriented helping the teams side.

One of the things that we have done (self-organised) is moved to a Continuous Integration way of working using unit and functional tests powered by Jenkins-CI tool. Being a Perl shop we use Test::More for the unit testing and the TAP plugin and Jenkins to pull our code from Git and test it when changes get merged into the main code base.

The flow-on change from this is our gradual movement towards purely test driven development. I have experimented and tried to work that way in the past and even blogged on this site about it in the past. Working that way again has been great and encouraging others to work that way is great too.
What I find is that at first there is a struggle to make the change, but once you strike gold once or twice and write a chuck of code in the TDD style; you get hooked and realise how much time and pain it saves you. That time saving is real and untill you get it right a couple of times I think people struggle to believe that all the test first effort will actually work for them.

So I am really busy, travelling a lot and working hard writing code plus delivering live video streams for Judo. Add to this my coaching at two Judo clubs and running local kids Judo events and I have been stretched pretty darn thin.

But I am getting the balance right more often now and with the lul in the Judo calendar due to London2012, I hope to recover a bit before launching solidly into the last part of the year!

Stay tuned as I hope to blog more frequently as I get the balancing/juggling right.