cyber-dojo traffic-lights

My friend Byran who works at the awesome Bluefruit Software in Redruth has hooked up his cyber-dojo web server to an actual traffic-light! Fantastic. Check out the video below :-)

Byran writes
It started out as a joke between myself and Josh (one of the testers at Bluefruit). I had the traffic lights in my office as I was preparing a stand to promote the outreach events (Summer Huddle, Mission to Mars, etc...) Software Cornwall runs. The conversation went on to alternative uses for the traffic lights, I was planning to see if people would pay attention to the traffic lights if I put them in a corridor at the event; we then came up with the idea that we could use them to indicate TDD test status.
Although it started out as a joke I am going to use it at the Summer Huddle, the lights change every time anyone runs a test so it should give an idea of how the entire group are doing without highlighting an individual pair.
The software setup is very simple, there is a Python web server (using the Flask library) running on a Raspberry Pi that controls the traffic lights using GPIO Zero. When the appendTestTrafficLight() function (in run_tests.js.erb) appends the traffic light image to the webpage I made it send an http 'get' request to the Raspberry Pi web server to set the physical traffic lights at the same time. At the moment the IP address of the Raspberry Pi is hard coded in the 'run_tests.js.erb' file so I have to rebuild the web image if anything changes but it was only meant to be a joke/proof of concept. The code is on a branch called traffic_lights on my fork of the cyber-dojo web repository.
The hardware is also relatively simple, there is a converter board on the Pi; this only converts the IO pin output connector of the Raspberry Pi to the cable that attaches to the traffic lights.
The other end of the cable from the converter board attaches to the board in the top left of the inside the traffic lights; this has some optoisolators that drive the relays in the top right which in turn switch on and off the transformers (the red thing in the bottom left) that drive the lights.
I have to give credit to Steve Amor for building the hardware for the traffic lights. They are usually used during events we run to teach coding to children (and sometimes adults). The converter board has LEDs, switches and buzzers on it to show that there isn't a difference between writing software to toggle LEDs vs driving actual real world systems, it's just what's attached to the pin. Having something where they can run the same code to drive LEDs and drive real traffic lights helps to emphasise this point.

cyber-dojo update

Between my recent fishing trips I have been working hard on a new cyber-dojo architecture.
  • pluggable default start-points so you can now use your own language/tests and exercises lists on the setup page
  • a new setup page for your own pluggable custom start-points
  • once I've got the output parse functions inside the start-point volumes I'll be switching the public cyber-dojo server to the new image and updating the running-your-own-server instructions
  • I've switched all development to a new github repo which has instructions if you want to try it now.

River Tone chub/roach

Last week I broke my Daiwa Spectron spliced-tip rod which has served me for 25 years+. After some searching around I replaced it with a Drennan Acolyte Ultra 14ft. I christened it yesterday with my heaviest ever bag on the Tone; 80lb+ of chub and roach with a few skimmer bream, one roach-bream hybrid, and several small perch. All caught on waggler, red/yellow/white maggot, on 1.7lb hooklength, and a size 20 Kamasan B560. Wooohooo.

Verdal salmon

Once a year a spent a glorious week fishing for salmon on the River Verdal in Norway. This year, despite the low water, I caught this cracker. A huge thanks to John Oldren who owns the beat. You will not find a more hospitable host. Also to Gary Scott for being super helpful as always.

Tulchan salmon

One of my favourite salmon beats is Tulchan on the river Spey.
On my most recent trip I caught two, including this beauty from Hunter's Pool.

Wooohooo - River Wye Springer

Woooohoooo. I've caught my first River Wye Springer. Thirty-four inches long, nineteen inches fat, eighteen pounds exactly. I caught it on the Monument pool of the Tunnel beat on a green and yellow devon minnow (a technique I'd never used before). Huge thanks to my friend Steve Roberts for skilfully guiding me.

Before setting off for this fishing trip I'd been stumped on a cyber-dojo fault which eluded me for the best part of a day. After the trip, I cracked it within five minutes. So you see, fishing fixes faults!

nordevcon cyber-dojo presentation

It was a pleasure to speak at the recent norfolk developers conference. My talk was "cyber-dojo: executing your code for fun and not for profit". I spoke about cyber-dojo, demo'd its features, discussed its history, design, difficulties and underlying technology. Videos of the talk are now on the infoq website. The slide-sync is not right at the start of part 2 but it soon gets corrected.

code and test oppose each other

I was reading one of Michael Feathers excellent blog posts on Symbiosis. His writing really resonates with me. As I get older I feel I'm starting to get a handle on thinking about things more dynamically and less statically. Looking back, if I had to pick the one thing that helped me the most on this road I would say its Le Chatelier's Principle, which I paraphrase as "Systems tend to oppose their own proper function". As I recall, Le Chatelier was a chemist and his principle is worded in the context of chemical reactions. The same fundamental "system of opposition" is also described in Walter B. Cannon's classic book The Wisdom of The Body which I first learned about in Jerry Weinberg's book General Principles of Systems Design (p 177). I'd like to try to explain what "systems oppose their own proper function" means using an example from the body. It's called the Glucose Cycle.

If you eat a donut the amount of glucose (sugar) in your blood goes up. If this increase continues unchecked you get hyperglycemia and you die. Fortunately this does not happen because the body is the result of millions of years of destructive testing! Cells in the pancreas detect the glucose increasing and start producing insulin. The liver and muscles detect the insulin increasing and start converting glucose into a stored form (called glycogen). This naturally reduces the amount of glucose and you don't get hyperglycemia.
If the amount of glucose continues decreasing, you get hypoglycemia and you die. Fortunately this does not happen either because other cells in the pancreas detect the glucose decreasing and start producing glucagon. The liver and muscles detect the glucagon increasing and start converting the glycogen back to glucose.

These two effects work in opposition to each other regulating the blood stream glucose.
All this tremendous activity to keep something else constant.
I find it deeply beautiful and deeply paradoxical.

Bradford Keeney writes about this same paradox in his classic book The Aesthetics of Change. An example he uses is evolution. He writes about the battle between a predator and its prey but goes beyond the 'mere' battle for food and territory. He describes a larger cybernetic picture, how the ongoing battle is itself a means or process of generating, maintaining, and stablizing an ecosystem. That evolution is always co-evolution as John Gall said.

This duality suggests that if you want to understand how codebases successfully change you should also understand how codebases successfully stay the same. To quote The Aesthetics of Change again: "Change cannot be found without a roof of stability over its head. Similarly stability will always be rooted to underlying processes of change".

In this light I see test driven development, as much more than simply specifying required behaviour (as important as that is). I see coding and testing working in opposition to each other naturally regulating each other. The ongoing 'battle' between coding and testing, between change and constancy, is itself a primary means of generating, maintaining, and stabilizing the development process.

My instinct tells me good software development is full of processes regulating each other via feedback like this. I'd like to make a collection of them. What's your favourite example? Please tell me. Thanks.