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.

My son is very keen, as many boys his age are, on video games.

Xbox, Wii, Playstation, Nintendo, flash games, Scratch, Bin Weevels; it goes on and on.
It's what he loves and especially things like scratch.mit.edu are where I try and push him with the hope that it will encourage him to learn more about the world of technology and how games and computers generally work.

Recently, I discovered "Gamestar Mechanic" and interesting site that lets him play a young game player come game game designer who must go through a variety of quests Pokemon style.
Whats nice about the site is that it teaches game design not just game playing. The NPCs in the quests and the levels in the quests teach him about how games work and he gets to design his own games too.

Embedded below is one of his first attempts, a two level affair. Which I must confess I can't beat, give it a go! :-)

So in my $dayjob, I have for the last couple of months been working almost exclusively in Perl development.

I have mainly been doing PHP web stuff for the last couple of years, so it's been interesting looking at Perl again. Coming back to Perl has reminded me how nice a language it is to work in and how many powerful tools it has.

What is interesting coming back to it is noticing how much talk there is about how Perl has lost ground to PHP, Python, Ruby etc. There is the Modern Perl movement and a push currently to up the social media war. For example the "Ironman" challenge trying to get modern articles on Perl online.

What has not changed is Perl 6 is still vapourware prety much.

Anyway...

So Perl Best Practices is great, especially when coupled with PerlCritic.
My tendency is to work like this:

1. Run PerlTidy on whatever code I am working on.
I have some local standards setup to match the style of the team I work with.

2. Hack away
Preferably I "try" to start by writing a t test file or a script that automates testing the script I am working on when the code is not a module. So TDD with unit tests where possible and TDD with regression testing when a script.
I'd love some guidance in this area if anyone wants to comment.

3. Run the code through PerlTidy again

4. Run the code through PerlCritic.
I have this setup at level 3 or 4 currently. Depending on how clever I am feeling or how messy the code is, I tend to run PerlCritic over and over at different levels and try and fix up as many things as I can.

5. Commit the code and get a colleague to review the code.

6. Fix the changes recommended and send it back fro review again until it passes.

7. Merge it into the main codebase.


It's been great to get back into Perl and I shall post more about it over the coming days, weeks, months. :-)

P.s. If you are interested in Learning Perl, you should check out Gabor Szabo's Beginner Perl Maven course on Udemy.