Flat UI Toolkit...

Yup, yet another web UI toolkit.  This one is for the trendy new “flat UI” – which looks just like the very first UIs I ever saw on a color screen, way back in the early '80s.  Everything old is new again...

Fast Solution for Graph Laplacians...

I first ran across graph Laplacians way back in the '70s when I was trying (and failing!) to build an electronics simulator.  This was long before SPICE was available on microprocessors.  The algorithms I read about back then for solving graph Laplacians were far more complicated than this new algorithm...

Interpolation Tricks...

Some of these are new to me, though I was well aware of the peculiar usefulness of the range 0..1.  I particularly like “smoothstep”...

Passwords Are Not the Bottleneck...

Fascinating paper by a pair of Microsoft researchers, arguing that the poor technical merits of passwords on web-based financial accounts really aren't the problem to tackle.  I learned all sorts of things about the “business” of stealing passwords on reading this paper...

Real World Code Sucks...

Dave Mandl writes (intro):

There’s a kind of cognitive dissonance in most people who’ve moved from the academic study of computer science to a job as a real-world software developer. The conflict lies in the fact that, whereas nearly every sample program in every textbook is a perfect and well-thought-out specimen, virtually no software out in the wild is, and this is rarely acknowledged.

To be precise: a tremendous amount of source code written for real applications is not merely less perfect than the simple examples seen in school — it’s outright terrible by any number of measures.

Due to bad design, sloppy or opaque coding practices, non-scalability, and layers of ugly “temporary” patches, it’s often difficult to maintain, harder still to modify or upgrade, painful or impossible for a new person joining the dev team to understand, or (a different kind of problem) slow and inefficient. In short, a mess.

His experience matches my own, at least for any body of code that wasn't written by a single individual (that's nearly everything these days, as software keeps getting bigger and more complex).

But for the most part, it works anyway – which some might consider to be an inexplicable miracle...

Image Restoration...

A very nice article by Vladimir Yuzhikov about restoring images that are out of focus or blurred through motion, including the underlying mathematics. 

Toom-Cook Multiplication...

Over the years I've written several “math packs” – collections of mathematical functions that can't be performed on the underlying computer's hardware.  Back in the bad old days of 8 bit microcomputers, this even included multiply and divide (the hardware could only add and subtract).  These days most computer hardware can handle 64 bit integer math and double precision IEEE floating point math (including the common transcendentals).  For integer math larger than 64 bits, though, math packs are still the order of the day.

Multiply and divide on integers much larger than the computer's hardware can handle are fairly complex operations.  In all the math packs I've written, the approach taken is the software equivalent of longhand multiplication and division (albeit in binary, not decimal).  This morning I came across an algorithm for multiply that is faster: the Toom-Cook multiplication algorithm.

One of the many fascinating things about the world of software is that new ideas are popping up all the time, even for hoary old algorithms that you might think were so basic they couldn't be improved...

Sparse Fourier Transform, or sFFT...

Many years ago I had a consulting gig that required me to analyze the sound made by ball bearings in (very expensive) rotating machinery.  After a bit of research, it became obvious that an algorithm known as the Fast Fourier Transform (FFT) was the way to go.  On the processors of the day (in the '70s), computing the FFT was a lengthy process – one run of the final firmware I wrote could take almost an hour. 

Recently four researchers at MIT came up with a much, much faster way to compute FFTs when the signal has structure of some kind.  That was certainly true of the signal I was analyzing!  With just a software change, that piece of gear I built could have been much faster.  Dang!

Backup for GMail...

If you're comfortable at the command line, and you have a gmail account, here's something that might interest you: an open source tool (written in Python) that will backup your gmail account to your local computer, and let you restore those messages to any gmail account.  I'm trying it right now (my backup is going to take a while!).

I actually have exactly this program on my list of “Maybe I should write this!” projects.  I'll probably get rid of it now :-)

GIMP 2.8 is Released!

GIMP (Gnu Image Manipulation Program, the free open source image editing software) 2.8 is the long-awaited next major upgrade.  It (finally!) includes “single window” mode, which many people (including me) prefer over the current user interface.  It also includes many improvements to the underlying image manipulation algorithms, including some support for higher color depths (24/32 bits). 

Unfortunately for me, the Mac OS ports aren't yet released, so I haven't been able to actually try it...

Peak.AR...

WIN!  Simon M. passed this little gem along.  I am in awe of this little enhanced-reality app.  All this awesomeness is free, too.

I downloaded the app in a few seconds (from the iTunes store), and fired it up.  There was no configuration required.  When it started up, I aimed my iPhone at the local horizon and got an image (through the iPhone's camera) much like the one at right (click to enlarge).

What you're seeing there is a realtime video display of whatever your smartphone is looking at, but the mountain peaks are overlaid with a little symbol and an annotation giving you the peak's name and altitude. 

I live in a fairly obscure valley (Lawson Valley) in the foothills of the coastal range in San Diego County.  The “peaks” immediately around me are really just the tops of slightly larger-than-average hills; all of them are less than 3,000' high.  Peak.AR knew the names and altitudes of every one of them – even several local peaks whose names I've never been able to find, not even on Geodetic Survey maps.  Peak.AR must have access to an amazingly large database of peaks!

Highly recommended, a 10 on the awesomometer.  Their home page is here.

Bad Code Can Kill...

Most of the time, we software engineers can safely think of our code as not life-threatening.  But the proliferation of computers into devices of almost every kind is changing that. 

The first time I ever ran into an example of code that could kill, it was a very straightforward example: I interviewed a fellow who had just quit his job at a medical device manufacturer here in San Diego.  When I asked him why he had quit, he told me that he had worked on the firmware for an automated insulin pump his company was making.  This pump would be worn by severe diabetics, and it would automatically maintain their blood sugar levels at an appropriate level – no matter what the person ate, or how he exercised.  Firmware that he wrote had a bug in it, one that wasn't detected during normal testing.  One of the patients trialing the device did something to provoke the bug – and the pump flooded his body with insulin, killing him.  My candidate quit his job that afternoon, and vowed to work for a company where that couldn't happen.

At the time, I was working for Stac Electronics.  The team I lead was building Stacker, a disk compression product.  We didn't think of that product as life-threatening – but suppose someone used Stacker in a computer that ran some vital piece of equipment.  If Stacker had failed, causing the computer to crash, then conceivably that could result in harm to a patient.  We had language in our license agreement designed to avoid this situation, but still...

These days, such situations are far more common.  Computers (which necessarily have software or firmware to run them) are embedded in just about anything you can imagine.  Here's a story about computers in a passenger airliner's flight control systems, and a software bug that nearly caused a crash.  In this case, it's obvious that the computer could potentially cause life-threatening malfunctions – but that's not always the case...

Interesting world we live in.  Flight control bug story via reader Doug S.

Flight 447: the Rest of the Story...

Popular Mechanics has a great summary of what really happened in the crash of Air France's flight 447 two years ago off the coast of Brazil.  Bottom line: profound pilot error combined with an apparent lack of understanding of how the automated flight systems on board their Airbus 330.  Some of the pilot errors were apparently caused by the pilots expecting the plane's flight control systems to work like older, less automated systems worked.  Said another way, the pilots appeared to be unprepared to handle the complexities of their automated flight controls.

This is a problem familiar to any modern software developer: users, in general, have little idea how the software they use actually works.  It's common – in fact, normal – for the users' mental model of the software package to be badly flawed.  For most kinds of software, the outcome of this is frustrated users and angry tech support calls.  This is not the case for flight control software, as this article makes very clear...

User Interfaces...

The battle between Graphical User Interfaces (GUIs) and Command Line Interfaces (CLIs) rages on.  Usually these verbal battles are more like a religious argument than anything else.  Vivek Haldar (a Google developer) tries a different approach, and makes several interesting observations along the way...

Writing Unmaintainable Code...

A treatise on how to write programs that are very difficult to maintain.  As any experienced programmer will recognize, the techniques are commonly found in code that wasn't (presumably) intentionally written to be unmaintainable.  Even though it might as well have been.  An example:

Creative Miss-spelling
If you must use descriptive variable and function names, misspell them. By misspelling in some function and variable names, and spelling it correctly in others (such as SetPintleOpening SetPintalClosing) we effectively negate the use of grep or IDE search techniques. It works amazingly well. Add an international flavor by spelling tory or tori in different theatres/theaters.

But do go read the whole thing...

Trello...

Another interesting product from Fog Creek (Joel Spolsky's company)...

TileMill...

Here's a new open source map editing program.  I haven't used it myself (yet!), but it sure looks interesting...

Software State Machines...

I've long been a fan of state machines implemented in software.  Most of my colleagues roll their eyes when I display my enthusiasm for them.  I've generally considered this to be symptomatic of my slightly odd background in digital hardware design, where state machines are the norm.  Most software developers know state machines only from school, if at all.  I use them fairly often, even for very small and simple problems.  Generally I roll my own state machine from scratch, though for more complex state machines I've used libraries like this one.

Alan Skorkin has some ideas about why state machines are infrequently used.  And why they're fluffy bunnies...

The Microsoft Way...

Much of the software engineering world mercilessly mocks Microsoft for their many violations of all that is good and right.  Here's yet another example of what makes them so eminently mockable...

More Obscure Linux Commands...

Several of these look interesting, but especially mytop...