The Worst Journey in the World – by Apsley Cherry-Garrard

It has been just over 100 years now since the discovery of the South Pole. Between 1910 and 1912 two groups, one led by Roald Amundsen and one by Robert Scott, made the attempt at reaching the Pole.  After two years of effort Scott chose four men from the greater team to make the final leg of the polar trip. They made it to the pole to find that Amundsen had preceded him by five weeks. Scott’s five man team began the 800 mile return journey loosing one man to a fall half way back, and loosing a second with about 50 miles remaining. A blizzard halted the last three men 20 miles from their supply cache and over the next nine days their supplies ran out.  Scott wrote:

We took risks, we knew we took them; things have come out against us, and therefore we have no cause for complaint, but bow to the will of Providence, determined still to do our best to the last … Had we lived, I should have had a tale to tell of the hardihood, endurance, and courage of my companions which would have stirred the heart of every Englishman. These rough notes and our dead bodies must tell the tale, but surely, surely, a great rich country like ours will see that those who are dependent on us are properly provided for.

Apsley Cherry-Garrard was one of the members of the expedition that waited at camp six months for Scott’s return and the book is his record of the entire expedition, though the title is in reference to a two week side journey he took early in the over all expedition.

I will not critique the writing, or the point of view, or posit on the issues leading to the failure of the effort. I will say that I enjoyed the writing style which seemed a blend of factual reporting and exuberance. I very much admired the fellowship, tenacity, planning, and work ethic of the expedition team. Cherry-Garrard made me feel like I was a welcome guest in the camp with the team; and I felt an attraction to the effort wondering if I could have endured and enjoyed such a long term endeavor. I was struck by how remote the pole was at that time, how little was know about the terrain, how little was known about the physiology of making the effort. They might as well been attempting to reach the moon. The effort was decades in the making if you count the other expedition journals that Scott studied for all information about the Antarctic; about the dietary needs of men under Antarctic conditions; the same with respect to animals. They were testing new technology, motorized sledges which had been tested under winter conditions in Norway. In the very first segment of the Journey they passed through a gale that near sank their ship – they lost 2 ponies and a dog. One of the three motor sledges broke through the ice while being unloaded and sank 60 fathoms. They spent a year hauling and stashing supplies along a lone of depots headed toward the pole ahead of the anticipated 4 man final race to the pole. They made every effort during the course of the journey to collect useful knowledge for any following journey – and did benefit from that same nobles oblige of previous journey. The collected geologic samples, recorded the weather, mapped the terrain, and many of the men kept journals of Cherry-Garrard took benefit in writing this book. They encountered monsters:

The Killer is scientifically known as the Orca, and, though far smaller than the sperm and other large whales, is a much more dangerous animal. He is armed with a huge iron jaw and great blunt socket teeth. Killers act in concert, too, and, as you may remember, nearly got Ponting when we were unloading the ship, by pressing up the thin ice from beneath and splitting it in all directions.

A great read even knowing the spoiler. A beautiful sketch of stoic English endurance akin to the Birkenhead drill.

I was in the midst of a harder than average software project as I was reading The Worst Journey in the World. But reading that book really made my project feel rather light. There is seldom mortal risk from writing software. The comparison to Death March by Edward Yourdon will wait for another time.

Detection of realtime noteworthy Twitter information in your areas of interest.

My team has been working on a project aimed at extracting realtime, anomalous, relevant information from the Twitter public feed. Part of our engagement is to investigate commercial applications of the technology we develop and to that end we are going through some early alpha tests of a UI for the technology. The technology works, and in many cases seems to beat both local and national media to items of emerging interest; it also sometimes generates false positives. My focus is creating a compelling user product and experience with this technology and I could use some feedback to help direct my efforts. I am asking for a few friends to take an early look and provide any feedback they care to give, especially on the potential value of the product to your daily routine. My team will be iterating on the feedback as quickly as we are able, so initially I’ll just be taking groups of ten or so and seeing how it goes until I can get out a next revision. If you have any interest in participating in one of the early groups please let me know and I will send the full page description of what we have built and put you on the list for one of the test groups. The standard alpha tester caveats apply.

Also any direct connection to a reporter I could talk to at the Bloomberg Speed Desk would be appreciated.

Thanks! – Contact via LinkedIn please.

 

Found Software

Most of the software I write these days makes use of found software. Like the Dada art movement, I turn software I find on the internet into works that please me, and my clients. [ http://en.wikipedia.org/wiki/Found_object ]. This style is different I think than what is taught in CS and CE, where knowledge of algorithms, and BigO, are primary. The spectrum from original algorithm development to consumer product with large embedded software component is broad. In the strictest sense I focus on the need of my client, or my perception of their need and what might best address the gap. Rarely does the need start with a wholly novel algorithm. Thinking about it, the last time I developed such an algorithm may have been in 1992 for a CD-i compression scheme called DYUV where I enabled blits into the compressed data structure.
Recently my team has been working on a route generation package for UAVs. The constraint is it must be open software or developed in-house. People wanted to start in-house using standard A * search techniques. But we looked to see what was available – easy to do with Google. Looking for path finding I came across [ https://code.google.com/p/straightedge/  ]. A terrific place to start, it is in Java, it is BSD licensed, it has some nice visualization capabilities – always helpful for debugging. Now what is my software engineering point here? It is that we can probably save a great deal of effort by looking for found software that meets our needs but the task is not effort free, and in fact we may find that we go well down the path of using this software only to find some showstopper. My point is, I did not have to author an A * search algorithm, at most I need to know about it so I could work my Google search. What I do need is the long term experience of patching together various Java projects into a working cohesive structure that solves my clients’ problems. On a larger scale consider the software we will probably never have to write; an SQL data base (Postgres, MySQL, etc) a no-SQL DB (Couch, Mongo, Neo4j, etc), a fast messaging system (ZeroMQ, RabbitMQ, some other MQ d’ jour), your OS ( Linux, OpenBSD, even Darwin, and if you don’t like how it works the code is there to change :-) ). So being facile with many of these pieces helps, if you get stuck, being familiar with method of debugging is most important, and in making a large project being familiar with SCM and project architecture is most beneficial.

SecondBar is Nice

I have a very nice set up now at work with a Retina 15″, and a Thunderbolt 27″ display. But the single menu on a single monitor is not so nice. SecondBar adds a copy of the menu to the second monitor. I find SecondBar from http://blog.boastr.net/ very handy and recommend it. Thanks! Remind self to drop the fellow some quatloos.

Windowserver Crash on Retina with Lion

I seem to be getting these every couple days to a few times a day with my new Mac Pro Retina. Some claim Mountain Lion fixes the issue, and that the issue has to do with switching graphics drivers from internal to external. I don’t know about that as I did not think the built in Intel driver could run my external monitor, and the issue is happening with the monitor. I also do not want to upgrade to Mountain Lion until the battery usage issues are worked out.

Dashcode Bug – Disappearing widgets

The quick answer is from the terminal run:

$ defaults write com.apple.Dashcode NSQuitAlwaysKeepsWindows -bool false

The issue goes away after doing the changes to defaults and opening and closing Dashcode twice.

Long Version

There is a bug in Dashcode 3.0.5 that seems to cause project corruption on opening a project. In my case elements of my design disappear. What should look like

opens looking like:

The issue goes away after doing the changes to defaults and opening and closing the app two times.

Wipe Nokia 3650

I wanted to recycle my Nokia 3650, but not to give up the memory card with any info. Turns out the Macbook Air has a slot. Let’s see what happens.

Using the System Information App - I get
 Built in SD Card Reader:
Vendor ID:    0x05ac
 Product ID:    0x8404
 Revision:    2.00
 Serial Number:    310
SDSC Card:
Capacity:    16.1 MB (16,089,088 bytes)
 Removable Media:    Yes
 BSD Name:    disk1
 Partition Map Type:    MBR (Master Boot Record)
 S.M.A.R.T. status:    Not Supported
 Volumes:
 NO NAME:
 Available:    10.1 MB (10,133,504 bytes)
 Capacity:    16 MB (16,039,936 bytes)
 Writable:    Yes
 File System:    MS-DOS FAT12
 BSD Name:    disk1s1
 Mount Point:    /Volumes/NO NAME
 Content:    DOS_FAT_12

Cool.
Lets get a dd of what was there.

dd if=/dev/disk1 of=nokiasdcard.dd

That worked to get a mountable version, and then I wiped the card using Disk Utility.
In the end my son wanted the retro phone, no doubt to show his friends the ancient technology.

DARPA META

META is part of the DARPA Adaptive Vehicle Make program. I participated as lead software engineer for BAE Systems Burlington, MA. Our participation in the program lasted about 18 months and was the first time I’d interacted so broadly with academic participants.

Our team put together some pretty interesting ideas and demo’d software every 8 weeks.

The software we wrote for the project was done under a BSD like license per DARPA requirements, and so it is probably the largest amount of software I’ve written that I can not only show to people outside the project, but also reuse on other projects.

Here are the program deliverables, and my team’s specific contributions.

Note that I included MD5sums in the delivery, but DARPA chose not to post them that way.