Geo Links

by Mark Shead on April 18, 2017

Some links for testing how different browsers and operating systems handle location links. If you have any suggestions for improvements please post them in the comments.

What is Agile?

by Mark Shead on May 31, 2016

Arduberry for Rasberry Pi

by Mark Shead on March 9, 2015



The Arduberry is an Arduino that sits on top of a Raspberry Pi. It connects to the GPIO pins. You can’t see it in the photo, but there is a MEGA328P chip mounted on the bottom of the board. Functionally it works the same as what would happen if you were to hook an Arduino Uno to a Raspberry Pi using a USB connection. By running software like Firmata on the Arduberry and appropriate libraries on the Raspberry Pi, you can send information between the Arduberry and Raspberry Pi.

So why would you want something like this? There are many shields and sensor libraries available for the Arduino family. Also the Arduino provides analog, digital, and PWM pins while the Pi only has digital pins and a single PWM pin. On the other hand, the Pi has significantly more processing power, audio input and outputs, and allows you to use programming languages that aren’t available for the Arduino. For example you could run Scratch, Java, Python, or Racket on the Pi and use it to control the Arduino.

By default the Arduberry is powered by the Raspberry Pi and since it sits on top of the Pi, it has a nice small form factor. The downside is that if you want to use the Pi to upload programs to the Arduberry, you have to be aware that it uses pins 11 and 13 to accomplish this. So if you have anything plugged into pins 11 or 13, when you try to send a new program to the Arduberry, you’ll get an error like this:

avrdude: The AVR device is not responding
avrdude: initialization failed rc=-1
Double check connections and try again, or use -F to override this check.

So for example if you try to use something like an Arduino Motor Shield that uses pin 13, you’ll have to remove it to upload a different program to the Arduberry. If you have an LED plugged into pin 13, you’ll have the same issue until you remove it.

So the Arduberry can be a good choice when the Arduino code is going to remain fairly static or you don’t need to use pins 11 and 13. If you are needing to make a lot of changes to the Arduino code and have a shield that uses pins 11 and 13, you may be better off with a normal Arduino connected with a USB cable.

DrRacket on Raspberry Pi 2

by Mark Shead on February 23, 2015


The Raspberry Pi has normally been too slow to run DrRacket. The new Raspberry Pi 2 is quite a bit faster, but if install racket from the default repositories, you’ll probably find that you can run racket, but DrRacket fails with a message like:

Seg fault (internal error) at 0xb0f5b0
SIGSEGV SEGV_ACCERR SI_CODE 2 fault on 0xb0f5b0

My guess is that this as something to do with the switch to ARM7 from ARM6. If you try to build Racket from the source, you may get an error like this:

Makefile:155 recipe for target ‘install-3m’ failed
make[1]: *** [install-3m] Error 137
make[1]: Leaving directory ‘/home/pi/Downloads/racket-6.1.1/src'
Makefile:86: recipe for target ‘install’ failed
make: *** [install] Error 2

Best I can tell this is an out of memory error. You can probably get it to work by rebooting and making sure there are no other programs running while you do the build. Also you can start the machine without launching X windows to leave more memory available.

I was on a video conference and chat room today. Someone on the video conference asked what to do about some issue with management. At few minutes before someone had typed into the chat window asking how to delete tasks. I responded with, “You have to kill them.”

My chat popped up on everyone’s screen right after the management question. The person talking on video conference said, “Well, Mark, I suppose that is one option.”

Building A Robot With The Kids

by Mark Shead on December 10, 2014

Building a robot with the kids.

A photo posted by Mark Shead (@mark.shead) on

A sign that said “Park Courageously” inspired me to park like I had never parked before. Turns out it actually said “Park Courteously.”

Mark Shead has worked as a system administrator, network administrator, IT director, and software engineer in variety of industries. Currently, he works with startups and on startup style projects within larger organizations. His focus is on getting better business results by improving software engineering processes–paying particular attention to the human element. This includes helping teams follow Agile principles, using DevOps to drive the delivery of business value, and engineering process improvements.

(Posted here so I can find it again next time I need it.)

Years ago when I was taking a typing class, there were certain tests that were designed to test speed not accuracy. It didn’t take me long to realize that, since there was no detriment to making mistakes, the logical action was to mash on the keys in order to get 700 words per minute for that type of test.

Some IT organizations design their issue system to focus only on the speed of closing issues and not on accuracy. Working with these organizations gives me a lot of empathy for how the typing teacher felt when I turned in a page of random letters and got the highest score.

Agile, Scrum, and Kanban

by Mark Shead on October 23, 2013

Agile is a set of principles for creating software. It doesn’t prescribe a specific methodology. So Agile says, “it is good to reflect on how things are going,” but doesn’t say specifically how to do it. Scrum and Kanban on the other hand are methodologies or frameworks for doing the actual work.

Scrum was created out of Agile, while Kanban comes originally from systems developed by Toyota for managing assembly lines starting back in the 1940s. Scrum is based around iterations while Kanban is based around flow. An iteration in Scrum might be a week long and start with a planning phase where the stories for the iteration are selected followed by development and end with a demo and retrospective. These iterations are typically called sprints. The idea is to get a cadence of a set of features being delivered on a regular basis–typically 1 to 4 weeks. The amount of work that can be in process at one time is limited because the number of stories committed to in an iteration is limited.

Kanban’s focus on flow is more concerned about moving stories through to completion smoothly. There are no iterations and work is limited based on the work in process limit placed on the different types of work. So the development column on a Kanban board might have a work in progress limit of 4 which means the team can’t pull another story into development until something gets pulled out of the development column. This is done to make sure that stories flow through the system and don’t get backed up in front of one resource or one type of work. The people responsible for work in one particular column pull in work from the column to their left when they have capacity. This ripples up stream as columns get an empty slot and can pull from their upstream column. In effect, one story being completed sends a signal up stream than another story can be pulled off the backlog and have work started on it.

Scrum has a Story Board with cards moving across it. Kanban has a Kanban board. Both look very similar, but the way they are used is very different. In Scrum the Story Board is a visual representation of what is being worked on where. In Kanban it is a visual representation, but also a control mechanism to manage the flow of the work. It controls how fast work is released from the backlog. In Kanban, it would be common to create another column to start gathering metrics whenever the team finds some type of impediment. That wouldn’t normally happen with a Scrum Story Board.

For an analogy of the differences between Scrum iterations and Kanban’s flow, you might think of Scrum as being similar to carrying a bucket of water between two points. The water represents work and the bucket represents the iteration. In Scrum you take the bucket to the destination and then talk about how you could do it better, then go back and do it again. Maybe this time you use a slightly different sized bucket, etc. Kanban is more like a gutter running between two points. You pay close attention to any areas that start backing up the water and make sure you don’t pour more water in than is coming out the other end to make sure it doesn’t build up and spill at a curve.

The team I’m currently working with is using Kanban so we have continuous flow for the development. However, we still use iterations for things that can benefit from a cadence–most notably the demos and retrospectives. We also continue to have daily standup meetings. So basically what we’ve done is removed the iteration based work from scrum and replaced it with the continuous flow of Kanban while still keeping the other parts of Scrum.

I’ve heard some people refer to this as Scrum-ban. I’m hesitant to use that term because it sounds silly to me…but I suppose no more silly than Scrum or Kanban.


Outcome vs. Task Focused

August 19, 2013

In Greek mythology, there was a goddess named Eos who fell in love with a Trojan named Tithonus. She asked Zeus to make immortal and Zeus did. In a different myth, the god Cupid pricks himself with one of his own arrows and falls in love with a mortal woman named Psyche. Eventually they work […]

Read the full article →

EC2 Instance Unreachable By SSH

June 27, 2013

If you are using a Redhat 6.4 AMI EC2 instance on Amazon Webservices and after a reboot you can no longer connect to SSH, this might help you. There appears to be a bug in /etc/rc.local that tries to add the same lines over and over again to /etc/ssh/sshd_config. Here is what the problem looks […]

Read the full article →

Kanban Book

May 26, 2013

Here are some highlights and my notes from reading the Kanban: Successful Evolutionary Change for Your Technology Business by David Anderson. The Agile Manifesto doesn’t say anything about quality, although the Principles Behind the Manifesto[1] do talk about craftsmanship, and there is an implied focus on quality. So if quality doesn’t appear in the Manifesto, […]

Read the full article →

Prioritizing Features

February 19, 2013

In building software, the actual coding is rarely the hardest part. Often deciding what features to build is very difficult. There is a huge wasteland full of code that never got to the point where it was actually usable before people gave up on creating it. Getting your code to the point where it is […]

Read the full article →


December 9, 2012

Infinitest lets you automatically run tests in the background in your IDE. Whenever you change something the tests get run automatically.

Read the full article →

Radio Shack Catalog

December 9, 2012

A look at this Radio Shack Catalog from 1983 is a good reminder of how far computers have come.

Read the full article →