Toy Robots and Linux

My lovely wife purchased a LEGO®* Mindstorms NXT 2.0 kit for Christmas for me!! Yay!!

I've got a Mac Mini driving my TV, so I _could_ plug my new toy into there... But, I don't like to stand uncomfortably for long periods of time, so I'd rather plug the brick into one of my Linux machines (laptop, desktop, or netbook). Ah, but the software that comes with the toy does not support Linux. Happily, there is an active community online which likes to play with these two systems together.

My first stop was Da' Goog, where I came across http://www.krizka.net/2009/12/27/starting-mindstorm-nxt-2-0-development-on-linux/. I started following the directions.

However, I was unable to get the udev rule to create the /dev/ device for me. After much gnashing of teeth, I found that the following worked:

SUBSYSTEM=="usb", SYSFS{idVendor}=="0694", SYSFS{idProduct}=="0002", ACTION=="add" SYMLINK+="legonxt-%k", RUN+="/etc/udev/legonxt.sh"

It differs from the original by the omission of 'group.' prepended to 'SUBSYSTEM', and by the used of 'usb' instead of 'usb_device' as the SUBSYSTEM value.

The only other problem that I ran into was that 'nbc' (the compiler/uploader for the NXC and NBC languages) had to be run as root due to permissions issues. I hope to get those figured out. For whatever reason, the script /etc/udev/legonxt.sh, which changes the permissions of the device file, still does not allow my user to access the brick. However, root can do it just fine. 'sudo' is your best friend and worst enemy.

When I get my system set up better, I will post my step-by-step guide. I've got some robot-making to do right now, though...

*LEGO® is a trademark of the LEGO Group of companies which does not sponsor, authorize or endorse this site. Please see: http://aboutus.lego.com/en-us/corporate/fairplay.aspx

Go And Vim

I love Go in part because they ship with a unit-test system. On the command-line, call 'gotest', and it compiles your stuff and runs your tests. And it's FAST, much faster than any other compiled language I've ever used before.

I also love Vim, for too many reasons to mention here.

I was looking for a way to get continuous testing as part of my development process. And then I remembered :map.



Now, every time I write my file out, I get glorious testing!!

Agile Vs TDD and Pairing

In the past few days, I've seen several people express the idea that Agile => TDD/Pairing (or possibly TDD/Pairing => Agile). I'm guessing that XP (Extreme Programming) is the root of this misconception. I'm going attempt to clear it up here:

Agile is not a programming practice; it is a management attitude.

TDD and Pairing are (distinct) development practices.

But first, let me say that you should not take this as a lesson in any of these topics. Reading this will give you at most a flavor of these topics, and hopefully pique your interest in them.

Let's tackle the simple half first. TDD and Pairing are straight-forward and well served by their names

Pairing is simply two developers sitting at one computer working out a solution together.  I won't get into the cost/benefit analysis here, but I will state that pairing has been wonderful for my productivity and my knowledge.

TDD is slightly more complex. There are three steps: write a test, write some code, and clean up the code. This process is often called 'red, green, refactor', and you end up with a nice cadence of writing short tests, writing small amounts of code, and cleaning up. There are books written about TDD, so clearly there's more than meets the eye here. However, it's still a very simple process once you get the hang of it.

You will notice a distinct lack of any prerequisites in either of the above paragraphs. You don't need anything other than someone to pair with to do pairing, or an test framework to do TDD. Pairing helps you get more work at a higher quality done, but it doesn't fundamentally change how you manage the project. Similarly, TDD helps improve your code quality, and it increases visibility into your code quality. However, TDD doesn't change how you manage your project.

Let's tackle the harder half now: Agile. Agile is not a process, and it's barely a paradigm. Agile is an umbrella which covers (to a greater or lesser extent) several development methodologies (including Extreme Programming, Scrum, etc).

When someone asks if you are Agile, what they should be asking is, "Do you recognize that your clients' needs change, and can you respond to those changes with working software quickly?" This is (according to some of my PMP friends) pretty standard project management stuff, so you wonder why we need to give it a special name. Well, I wonder why we have to give it a special name... That is, in a nutshell, the primary concern of Agile. There are secondary concerns, of course.

The Agile mindset is based around your relationship with your client. But, that relationship informs nearly everything you do as a producer. It pressures you to have greater visibility into your processes, and to abide by shorter release cycles, and a number of other things, too. But, you can increase your visibility and shorten your release cycles and achieve a host of other goals without TDD and without Pairing.

That said, I really think that TDD and Pairing help a bunch.