Raspberry Pi - Getting Started (& ready for hardware hacking)

So, it was all plain sailing getting the Pi up and running with NOOBS following the instructions there, and quickly got it all setup with wifi connectivity and ssh access (which is essential for me, as I don't have a HDMI monitor other than my TV in the living room - so until I could get ssh access from my normal workstation it meant having to take over the living room to configure the Pi on the TV, which my wife was not best pleased about! Also a much cheaper option than buying a new HDMI monitor just for the Pi).

I had been looking around for how to get started with some hardware hacking with the Pi, and must admit the last time I did anything vaguely electronics was when I was in school at 14yrs old (actually I did a robotics module in uni, but that was still mostly programming stuff rather than actual chips/resistors/wires etc).  Some of blogs were writing about how great/essential the Adafruit Pi Cobbler was, and again, I had to go and google and read up exactly what a breakout "cobbler" would be useful for etc but decided that enough people were going for it to invest


(So yeah, that's the Amazon affiliates link - it means I get some money from amazon if you buy this thing from here - it doesn't cost you anything, but is nice for me, so by all means click & buy!)

That lead me on to looking more extensivley at the adafruit site, which has some nice tutorials and all recommend using the Occidentalis OS if you are planning some hardware hacking.

Setting up Occidentalis OS

Occidentalis doesn't come in as nice a package as NOOBS - You basically need to get the image, flash it to an SD card, then boot up your Pi.  I'm on Windows 7 setting up the SD card, so here are the steps/software I used:

• SD Formatter (from the SD association - this is one of the standard tools recommended in normal Pi setup tutorials and is a pretty convenient way to format SD cards) - https://www.sdcard.org/downloads/formatter_4/
• Fedora ARM installer - This can be used to install OS images on to an SD card - you can't just copy & paste downloaded images on to an SD card and this just makes it pretty easy - https://fedoraproject.org/wiki/Fedora_ARM_Installer
• Occidentalis distro image - This is Adafruit's mod of the Raspian Wheezy OS and is modified specifically with hardware hacking in mind - The latest version is currently at v0.2 - http://learn.adafruit.com/adafruit-raspberry-pi-educational-linux-distro/occidentalis-v0-dot-2

Getting the Occidentalis image and flashing it to an SD card is pretty straight forward if you have the above software - the steps are as follows:

1. Format an SD card - it really needs to be 4gb - I am using an 8gb samsung card that is working fine (disclaimer: as with any formatting or writing images to drives - make sure you are targeting the correct drive for your appropriate SD card - as all data will be wiped!)
2. Assuming you have downloaded the Occidentalis image from the above link, extract the zip file locally
3. Right-click and select "Run as administrator" on the Fedora ARM installer executable.  For the source option, select "Browse" and navigate to the .img file you have just extracted from the zip. For the destination triple-check that you have your SD card drive selected (again, this drive will be wiped and all data overwritten when you hit the install button). Then press install. This will correctly setup the SD card with the OS image.
4. Jam your newly setup SD card in your Raspberry Pi and startup as usual. For most of the boiler plate setup, this will work just like Wheezy/NOOBS setup.

Uh.. Wait.. My Pi isn't Booting..

A Brief Update

So, once again I am on paternity leave, and whilst that may seem like a most unlikely time for me to have more spare time on my hands (I really don't.. this parenting stuff is non-stop), it does afford me more time where my job is just watching a sleeping baby to make sure he's ok, which gives me the opportunity for some quieter time.

Last time around I experimented with and wrote up some work with Spring & MongoDB (see previous blog posts here and here) and this time I have a whole host more planned.  Firstly, I am getting back on some Android development and am working on a new app - part of which is using greenDAO ORM for Android (apparently used by Pinterest.com, which is pretty good - although I would think describing themseleves as an ORM might be a little stretch, at first glance it certainly seems to make DB/DAO Android work a lot less of a pain in the arse) - I will write up some notes on using that soon.



The other part is a Raspberry Pi project. I held back from getting a Pi for sometime, as I didn't really have any projects in mind, and as tempting as it was, I didn't want to get one and just have it sitting in a box unused for ages (or alternatively just using it as a mechanism to web-enable my TV) - However, having been inspired by this project I decided that I wanted to build a lego robot powered by the Pi, and long term, having a robot that can do clever things (map out rooms, shortest path algo stuff etc) but also have a code framework that makes it easy for kids to be able to program rules about how the robot behaves in different circumstances etc.

I have a Pi, I have dug out all my old Technic Lego (including motors) and have discovered the joy of buying lots of incredibly low-priced electronics kit (resistors, chips, breadboards, leds, etc) and am almost ready to start - just have to solder a few pieces together and we are off (well, that and learn some basic electronics stuff!)


Expect post on both topics shortly..

Traversing data structures - A Groovy Visitor Implementation

I have been using Groovy for a while now, having come from a solid Java/J2EE/Spring/ORM background where patterns and solid OO is a mainstay.  Although it took me a bit to get in to the swing of the Groovy stuff, I have now really taken to it (in no small part, encouraged having taken the Coursera FP class) - The simplicity and ease to use the built in functional stuff like .each{}, .findAll{}, .collect{} is really neat, and once you get started with them there really is no stopping!

As Groovy is dynamically typed (not weakly typed though!) you do end up using a lot less POJO classes and a lot more Maps, Lists of Maps, etc (also Groovy makes it really easy to work with these guys) and I find myself fairly often needing to traverse complex, dynamically typed data structures to do some kind of data processing.  Normally, in my Java OO background, when frequently processing tree type structures (a nested Map of Lists/Maps/Simple elements can really be thought of taking this form) I would fall back to the Visitor patter (if you aren't familiar with the GoF Visitor pattern, see here, here, etc for details), but if you have a dynamically typed complex data structures, and you don't really want to have each potential node in your structure to have to implement a set interface with a visit() method on it, then I use the following approach.

(disclaimer: yes, it feels as though it is a hacky, dodgy approach of the pattern - but it works well with Groovy and has been working well for me. If you have ideas on how to improve etc I would love to hear thoughts in the comments!  As such, I like to refer to it as "The Unwelcome Visitor Pattern").

First, I create an iterator class - this basically has the code to iterate through a nested, complex structure - I see this as boiler plate code that is a pain to re-write and will be used by all code that wants to traverse a complex data structure (Map with n-level deep nested Lists/Maps)



As you can see, its just a basic re-cursive piece of code to traverse List/Maps - you will note that it expects a visitor class to be passed in to it as an argument on first calling that has a visitMap() and visitList() methods.  In normal Java, this would need to be a class that implements a particular Interface/Abstract class that has implementations of the required methods. However, as Groovy is a little more dynamic we can do some pretty nice on the fly stuff (yes, I know, if you are performing some really common stuff, you may still want to have the traditional Java interface/explicit class approach as well, but that's not why we are here!).  The code below is an example of doing some on-the-fly processing of a dynamically typed complex data structure (in this case, we are just converting all Date objects to Strings, but this is just an example for funsies)



As you can see, in the above we are using Groovy's ability to create Interface implementations as Maps and just defining a simple closure for each of the visitMap() visitList() methods.


It may not be the most graceful solution, but it works simply and allows easy definition of closures that can process Maps/Lists easily (could also be used in the same way fo rtraversing JSON structures etc)