DrRacket on Raspberry Pi 2


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.

EC2 Instance Unreachable By SSH

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 like in /etc/rc.local:

cat <<EOL >> /etc/ssh/sshd_config
UseDNS no
PermitRootLogin without-password

Everytime the machines startup it is going to append to the file and eventually SSH will stop coming up correctly.  You may want to delete those lines or at least modify them to do something that you want them to do.

Also before you reboot take a look at  /etc/ssh/sshd_config and make sure it looks right. You may need to delete some of the extra entries from the end. You can test it by doing a:

sudo service sshd restart

If the sshd_config is bad, this will fail to restart sshd, but it should still leave you connected so you can change the config and try restarting it again.

If your machine is running but you can’t connect to it, you can disconnect the the volume, mount it on another EC2 instance, change those files and then put it back on the original instance and start it back up.

Kanban Book

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, why is it first in my recipe for success? Put simply, excessive defects are the biggest waste in software development. The numbers on this are staggering and show several orders of magnitude variation.

There seems to be a psychological advantage in asking developers to write the tests first. So-called Test Driven Development (TDD) does seem to provide the advantage that test coverage is more complete.

In trying to organize stuff, you end up with much better results by asking “Where will I look for this when I want to find it?” instead of “Where should I put this?” The same thing is true of development. When you start by asking “How do I test this?” you generally end up with much better code.

The big bang for the buck comes from using professional testers; writing tests first, automating regression testing, and code inspections.

Professional testers understand edge cases. Getting them involved before the code is written can dramatically reduce the number of defects that get committed to the code base. Leveraging their skillset early in the process is one of the best ways to increase the quality of the code.

Longer lead times seem to be associated with significantly poorer quality. In fact, an approximately six-and-a-half times increase in average lead time resulted in a greater than 30-fold increase in initial defects.

Reducing work-in-progress, or shortening the length of an iteration, will have a significant impact on initial quality.

I found this to be insightful. The longer you drag out working on a feature, the more errors you’ll get. Things that shorten the amount of time it takes to finish a unit of work will reduce the amount of errors that slip in. Continue reading “Kanban Book”

Prioritizing Features

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 being used by real users clears a significant hurdle and gives you a much greater chance of success.

Arranging the order of your features so you can quickly get to a usable state with the smallest set of useful capabilities without building anything unnecessary may sound simple. It isn’t.

Continue reading “Prioritizing Features”