Atomic Spin :: Elements of Software

Video from my presentation at RubyConf 2007 (Enhancing Embedded Development with Ruby) is now available at the Confreaks website.

See the full video

I’ve just given this presentation at Rubyconf 2007. And now you can enjoy it too:

Keynote file: Enhancing Embedded Keynote

PDF version: Enhancing Embedded PDF

Video: Full Video from Confreaks

Greg and I have been working on an embedded project for one of AO’s longtime clients X-Rite. At the beginning of the project our team (X-Rite + AO) set up a dedicated build server with cruisecontrol.rb and a custom-made build status indicator.

Our build indicator is an upside-down ceiling fan globe with a small microcontroller and super powerful LEDs inside. It goes blue when newly checked-in code triggers a build, and then it displays either green for tests passing or red for tests failing at the conclusion of that build (and all of the engineering department can see it).

Just recently our X-Rite project manager Scott came over and upgraded our build status light for Halloween. We’re pretty sure it’s our automated unit and system tests that will keep evil spirits away, but every little bit helps…

I've just now gotten around to posting the materials I've presented at the OSCON and Agile conferences in the last month. The Agile paper discusses what we learned on our first embedded projects; the OSCON presentation focuses in on the tools and techniques we now apply to embedded development.

OSCON presentation

Agile paper + presentation

Rapid Growth is a very cool, weekly online magazine covering the development and transformation of Grand Rapids. They published a short article about us.

“GR software firm’s growth projections anything but atomic“

Methods & Tools is a quarterly software development e-publication with a distribution list of 45,000. The summer edition of Methods & Tools is now available. It includes an article on our embedded development approach and tools (the PDF version can be found at the preceding link).

Over the last year I’ve been working on a Ruby extension for Measurement Computing’s miniLAB 1008 device; version 1.0.0 is now available on Rubyforge.

miniLAB is a simple analog and digital input and output device we’ve used to help system test our embedded projects. The minilab Ruby extension wraps the miniLAB’s native C library into something addressable by Ruby. I’ve also simplified the interface so that you can refer to the miniLAB’s pins by their labeled name rather than their assigned C constant (for those unfamiliar, the label on the device and the actual value you’d pass to the C library are often wildly different).

Bill Bereza and Matt Fletcher will be presenting 'Improving the Embedded Development Process' at OSCON this summer. The talk will focus on our experience building the Ruby tools that made embedded development effective and fun for us.

Check out the abstract here. If you're interested, consider coming to OSCON. Aside from our presentation, which will surely be the best thing ever, there will be plenty of other interesting talks. A complete OSCON schedule can be found at this link.

Now available: The sample project we distributed on CD to complement our presentation at Embedded Systems Conference Silicon Valley 2007.

Our interest in applying Agile practices to embedded software began in earnest about a year and a half ago. (You can read about our continuing adventures on our Embedded Software page and at this blog’s Embedded Corner.) After several projects under our collective belt, we’re now at the point of working on a very large and complex embedded project with X-Rite, one of our longtime clients. So far things are going quite well. For this project we’ve been using good Agile-style planning and tools like burndown charts. And, we’ve been learning some important things about successfully using Agile planning in embedded projects.

Greg and I are working at X-Rite these days on an extended assignment. We’re part of a team developing a new color measurement device. It’s a complicated embedded system and the first large-scale implementation of our Agile and TDD approaches to embedded system development (incidentally, thanks, X-Rite, for your faith in us). One of our team members, Mark, has some familiarity with the D programming language. I’ve heard of it. It’s been in development for quite some time. Version 1.0 was just released in January of 2007. Because of Mark I just checked it out. It’s nice.

We just recently got a last minute notice that we’ve been accepted to present at the Embedded Systems Conference, Silicon Valley 2007. Greg Williams and myself have the honor of presenting a 90 minute tutorial on the Test Driven Development approach Atomic Object has been developing for embedded software. The presentation will cover AO’s Model Conductor Hardware design pattern and the tools we’ve developed to do unit testing and mocking in C.

Our presentation is entitled Mocking the embedded world: practical TDD , continuous integration, and design patterns. The name plays off both the use of mocks in our approach and the challenge we were once given to make Test Driven Development work in embedded systems.

I have to say thank you to the folks over at James Grenning’s Agile Embedded Forum. Our threads of conversation have been quite helpful in refining the eventual presentation of our concepts and work. The timing of those discussions has truly been serendipitous.

While working in C for an embedded for PIC microprocessor system and at the same time working on a Java & Laszlo project using decent mock libraries, I found myself wishing for auto-mocking for C. We were already writing our embedded code following a Model-View-Presenter design pattern (read more here) for Test Driven Development. If we were to add a mocking mechanism, we needed something small and simple that would fit into a system with 256 bytes of RAM and 32K of ROM. Using Ruby, combined with the Rake build scripts we were already using, we implemented an initial version of a C mock library during a couple slow days at a conference. Using Ruby and rake external to the target system, we generated C code and headers with functionality equivalent to that available in object oriented languages with reflection. The generated C code adds little to no overhead to the actual production system.

Effective pair programming requires a lot more than simply plopping two people down in front of a monitor. Both programmers need to be actively engaged in the task at hand—-something that can prove pretty tricky at times. Lately we’ve been trying out a strategy called ‘ping-pong’ pairing to find out if it can further improve our practices.

We've recently started working on a new board--something to monitor and report the current battery level of an automated vehicle. On the previous board (in charge of controlling speed), we had a hand-driven test fixture that we used for system testing. This time around, we would like to make heavy use of support hardware that we can control programmatically. Our goal is to make the system testing for the board just as automated as our unit tests are.