Log in

Gareth Rees Below are the 10 most recent journal entries recorded in the "gareth_rees" journal:

[<< Previous 10 entries]



Blogging elsewhere

I also blog from time to time at CTC Cambridge, Listen With Others, and Otterly. I re-post everything at garethrees.org, so if you want to read all my posts, you should be following my RSS feed.

You can also find me on Google Plus.




Joe sits in the office of his detective agency in Vientiane, drinking and smoking, watching the rain come down, and reading trashy fiction:

The book was a worn paperback with a garish, colourful cover. It showed a multi-story building in the final stages of collapse, a dusty African street, and people running away from the blast. The book was called Assignment: Africa and, in an only slightly smaller subtitle, announced it as the third title in the series Osama Bin-Laden: Vigilante. The unlikely named of the author was Mike Longshott.

A woman comes into in Joe’s office with a job for him:

At last, she said, ‘I want you find him,’ and her fingers caressed the book; he couldn’t put a name to the look she had in her eyes then; he thought she looked lost, and sad, and a little vulnerable.

‘Find who?’

‘Mike Longshott,’ she said.

( What follows is a pastiche of the hard-boiled detective genre... )



The Quantum Thief

Jean le Flambeur, gentleman thief, is sprung from prison by the beautiful Mieli, who persuades him to undertake one last job. Author Hannu Rajaniemi works hard to obscure the familiar outline of this hoariest of heist plots, by layering on the worldbling with a trowel:

The hidden Sobornost tech beneath the Oortian sapphire coral wakes up. The spidership reconfigures itself. The scattered modules pull themselves together along their tethers and fuse together into a tight, hard cone. The q-dot winglets transform from a perfectly reflective material into a diamond-hard firewall. Just in time, before the Archon’s nanomissiles hit.

I do like the experience of being confronted by a complex fictional world and having to make sense of it. ( But I also like to feel that there is in fact some sense to be made, and in this novel I frequently failed to make it. )



Completion colours

In ‘Completion annotations’, I illustrated the interactive completion feature in Emacs with a screenshot showing what happens if you type M-x set-cursor-color RET Dark TAB: you get a *Completions* buffer containing the colour names starting with ‘Dark’. Nick Barnes posted a comment pointing out a potential usability improvement:

It would be nice to have a bit more control still, so that (for instance) when completing on colour names one could see the colours.

To do this, just evaluate the following expression:

(dolist (c (defined-colors)) 
 (put-text-property 0 (length c) 'face `(:foreground ,c) c))

and then run any command that prompts you to pick a colour, for example read-color. At this point, if you are used to the way strings work in most programming languages, you ought to be asking yourself, how does this work? )



Completion annotations

One of the most useful features of Emacs is its interactive completion. Whenever you need to input the name of some item, Emacs allows you to type some parts of the name and then type TAB to see a list of items that match what you have typed so far. But completion is more sophisticated than just prefix-matching. You can use wildcards (for example *green TAB will show colour names containing the substring ‘green’) and when the completion items have multiple words (separated by hyphens or spaces), completion works on each word individually, so that you can type M-x t-d-o-e RET to run the command toggle-debug-on-error. Naturally you can customize the set of completion mechanisms using the completion-styles setting.

The Emacs/Perforce integration that I maintain, p4.el, implements completion for each kind of Perforce item that you might need to name: branches, numbered pending changelists, clients, filespecs, groups, help topics, jobs, labels, and users. However, this works poorly in the case of changelists and jobs, because all you get when you type TAB is a list of opaque identifiers that give you no help in choosing the item you want. )



Five Whys

Toyota’s ‘Five Whys’ process is well known to engineers: it’s one of the basic problem-solving tools in modern engineering management systems like Six Sigma and Total Quality Management. Here’s how Taiichi Ohno introduces the process in Toyota Production System: Beyond Large-Scale Production (1978):

When confronted with a problem, have you ever stopped and asked why five times? It is difficult to do even though it sounds easy. )



The Bug

I have been working on a project recently where there has been a lot of tricky debugging to do. The code I’m working on has to live in the same process as third-party code that is not under my control, and which calls into my code unpredictably, often from multiple threads or signal handlers. This is an application environment that’s particularly prone to rare crashes and deadlocks that somehow elude my own thorough test procedures but crop up nonetheless on the machines of potential customers during product evaluations. I used to find these kind of bugs intimidating and nerve-wracking, but (at least on this project and for the moment) I seem to be a match for them.

The process of debugging is (or ought to be) one of calmly, methodically and steadily gathering data that narrows the location of the problem until it can no longer hide and is forced to reveal itself. In my current project the first step is to acquire the log and (in the case of a crash) the backtrace from the customer and analyze it for the sequence of events leading up to the crash or deadlock. This identifies important features of the environment (which programs were running? are they multi-threaded? do they handle signals?) and usually pinpoints a suspect area of code which can be inspected for race conditions and deadlocks. Inspecting the code usually leads to a hypothesis or two about the cause; but even if it doesn’t I develop a test case that thoroughly exercises the problem area. With some experimentation and a lot of thought I’ve so far always found it possible to reproduce the problem under controlled conditions, whereupon it can be analyzed in the debugger.

Writing this is of course a form of hubris: no doubt I will return to work on Monday to find in my inbox a customer report describing a bug that I lack the skill to track down and fix. This hasn’t yet happened in my career, though there have been a few occasions where I have been in doubt as to the outcome, one of which I described in my post ‘The last lousy bug’. Programmers like to call these accounts “war stories”—joking, of course, but joking seriously. It is stressful to know that something is wrong in your code, but not to know what it is or how to find it, and to have it hanging over your head day after day as you fail to make progress towards solving it.

( This nightmare scenario is the driver behind Ellen Ullman’s 2003 novel The Bug. )



Software inspection and the Heartbleed bug

Since 2005, when a train crashes in the UK, a professional body of investigators—the Rail Accident Investigation Branch—is tasked with determining the cause of the incident and making recommendations to reduce the likelihood, or mitigate the severity, of similar events occurring in the future. There are similar branches tasked with investigating Air and Marine accidents.

There is nothing like this for computer security incidents. )



“Double Dutch” audax

Martin Malins has been organizing the “Double Dutch” 200 km audax for four years now. I rode the first edition back in 2011, when we had the most amazing luck with the weather, and I was looking forward to riding it again. The route is a tour of the Fens: starting at Huntingdon, you head north-east via Ramsey, March, and Nordelph, then north up the River Great Ouse to Kings Lynn for the fourth control and lunch. Then you cross the Ouse and head northwest to an info at Holbeach St Matthew close to The Wash, southwest to the sixth control at the Springfields shopping centre in Spalding, Lincolnshire, and back to Huntingdon for the finish.

I set my alarm for 06:00 )



Password purgatory

Since the Heartbleed bug rendered all our passwords insecure, we’ve all been going through the purgatory of upgrading servers and changing passwords. This isn’t the first time I’ve done a mass-reset of my passwords, but I thought I’d try something new. This time I’m seeing what it’s like to try to follow “best practices.” )

[<< Previous 10 entries]

garethrees.org Powered by LiveJournal.com