Via Tor.com, Lex Luthor asking the president for a bailout.

In today's New York Times, David Leonhardt writes, of a sixteen-year-old economics paper:

In the paper, they argued that several financial crises in the 1980s, like the Texas real estate bust, had been the result of private investors taking advantage of the government. The investors had borrowed huge amounts of money, made big profits when times were good and then left the government holding the bag for their eventual (and predictable) losses.

In a word, the investors looted. Someone trying to make an honest profit, Professors Akerlof and Romer said, would have operated in a completely different manner. The investors displayed a “total disregard for even the most basic principles of lending,” failing to verify standard information about their borrowers or, in some cases, even to ask for that information.

The investors “acted as if future losses were somebody else’s problem,” the economists wrote. “They were right.”

He goes on to distinguish between classic moral hazard and looting:

With moral hazard, bankers are making real wagers. If those wagers pay off, the government has no role in the transaction. With looting, the government’s involvement is crucial to the whole enterprise.

Ryan Chittum at CJR has a good take on the piece.

It's clear that the system that led to the current economic clusterfuck needs some fundamental reform and regulation. The incentives to loot show up the hollow promise of the markets self regulating.

Title: Perdition House

Author: Kathryn R. Wall

Rating: 3 stars out of 5

Publisher: St. Martin's Minotaur

Copyright: 2003

ISBN: 0312998244

Pages: 295

Keywords: mystery

Reading period: 8–9 March, 2009

Bay Tanner is a young widow and aspiring private investigator from wealthy South Carolina stock. When a hitherto unknown shirt-tail cousin (fifth half cousin, specifically) bursts into Bay's life, she brings havoc in her train.

As one of the characters says, the plot sounds like a made-for-TV movie. Still, Bay is a feisty heroine and the background is not one that has been mined deeply.

We were watching An Engineer's Guide to Cats on YouTube when I looked out the front window and spotted these two looking in. They climbed up the six-foot gooseberry frames to the windowsill.

Meet Whiskey and Guinness, from next door. They think they own the place. When it's hot in the summer, they've been known to stroll in and wander around our living room—while we're in it.

I left the back door open for a few minutes one Saturday morning, while packing the car. I came back in and found Whiskey just inside the back room. He scarpered when I yelled at him and I slammed the door behind him. It was then that I discovered that Guinness was now locked in. He tore past me, to get out the back door. He couldn't, so he tried to climb up and over the venetian blind. He got to the top before he realized that wasn't going to work either. Down he dropped from the ruined blind and back into the living room with him. I opened the door wide and stamped into the living room from the other side to drive him out.

Cheeky buggers. Almost as cheeky as the racoon who climbed up the gooseberry frames one night. We looked out to see a face staring in at us, startling us. We stepped outside with a flashlight and yelled at him, but he was quite reluctant to go.

">

Title: The Seafarer

Author: Conor McPherson

Rating: 4 stars out of 5

We saw The Seafarer at the Seattle Rep this afternoon. Two brothers, Richard and Sharkey, share a house in north Dublin. There's little love lost between them. Richard, recently blinded, is controlling and wheedling. Sharkey is trying to stay off the gargle and it's not easy when Richard and his crony Ivan drink like fishes.

Sharkey's old rival, Nicky, arrives on Christmas Eve, bringing a stranger with him, Mr. Lockhart. They settle down to a game of poker and Sharkey privately learns that he's met the stranger once before. For Mr. Lockhart is the devil and he wants to collect the old debt that Sharkey owes him and take Sharkey's soul.

The brothers fight and fight. Like all squabbling siblings, they know how to get under each other's skin. Ivan and the brothers are wasters, whose lives have been distorted by drink, and Nicky is little better.

The play is grim in places, but it's also very funny, rich with humor between the characters and sometimes at their expense.

The cast do a creditable job of Irish accents, particularly the Harkin brothers. There's a large, apparent difference in ages between the two actors, making them somewhat improbable as brothers.

Runs until March 28th.

Vim has had syntax highlighting since version 5.0 in 1998. It quickly became indispensable. It's hard to go back to looking at monochromatic source code after you've become accustomed to syntax highlighting.

The syntax highlighting is tied into Vim's support for colorschemes, which define colors for the fundamental syntax groups like Number, Comment, and String. The syntax highlighting for a particular language defines custom syntax groups for specific language features, such as cppExceptions or htmlEndTag,

The custom syntax groups are linked to the underlying fundamental syntax groups. Hence, if you change your colorscheme, your syntax highlighting is updated automatically.

The reStructuredText syntax highlighting in Vim 7.2 has some shortcomings, in my opinion. For example, *italic* shows up as italic in gVim, but in the same color as regular text, while **bold** shows up in a different color, but not bolded.

When you declare a syntax group, you can either link it to another gropu and pick up that's one color and fontstyle, or you can give it a concrete fontstyle and color. If you do that, then the syntax group won't change color when you change the colorscheme.

After much poking around, I found a way to set a syntax group's fontstyle and link it to another group's color: see hi def rstItalic and hi def rstBold below.

I also make use of certain Unicode characters in my reStructuredText source, such as endash and emdash, which are very hard to tell apart in a fixed-width font—even though an emdash (—) is twice as wide as an endash (–) in a proportional font. Worse, a non-breaking space is invisible and can't easily be distinguished from a normal space.

I provided custom highlighting for these Unicode characters and the various ‘curly’ “quotes”.

All of this goes into ~/.vim/syntax/rst.vim, which treats $VIMRUNTIME/syntax/rst.vim as a subroutine. I tried putting it into ~/.vim/after/syntax/rst.vim, which gets executed after $VIMRUNTIME/syntax/rst.vim completes, but then I can't provide non-overrideable definitions for rstEmphasis and rstStrongEmphasis.

function! s:SynFgColor(hlgrp)
    return synIDattr(synIDtrans(hlID(a:hlgrp)), 'fg')
endfun

function! s:SynBgColor(hlgrp)
    return synIDattr(synIDtrans(hlID(a:hlgrp)), 'bg')
endfun

syn match rstEnumeratedList /^\s*[0-9#]\{1,3}\.\s/
syn match rstBulletedList /^\s*[+*-]\s/
syn match rstNbsp /[\xA0]/
syn match rstEmDash /[\u2014]/
syn match rstUnicode /[\u2013\u2018\u2019\u201C\u201D]/ " – ‘ ’ “ ”

exec 'hi def rstBold    term=bold cterm=bold gui=bold guifg=' . s:SynFgColor('PreProc')
exec 'hi def rstItalic  term=italic cterm=italic gui=italic guifg=' . s:SynFgColor('Statement')
exec 'hi def rstNbsp    gui=underline guibg=' . s:SynBgColor('ErrorMsg')
exec 'hi def rstEmDash  gui=bold guifg=' . s:SynFgColor('Title') . ' guibg='. s:SynBgColor('Folded')
exec 'hi def rstUnicode guifg=' . s:SynFgColor('Number')

hi link rstEmphasis       rstItalic
hi link rstStrongEmphasis rstBold
hi link rstEnumeratedList Operator
hi link rstBulletedList   Operator

source $VIMRUNTIME/syntax/rst.vim

syn cluster rstCruft                contains=rstEmphasis,rstStrongEmphasis,
      \ rstInterpretedText,rstInlineLiteral,rstSubstitutionReference,
      \ rstInlineInternalTargets,rstFootnoteReference,rstHyperlinkReference,
      \ rstNbsp,rstEmDash,rstUnicode

Title: Watchmen (film)

Director: Zach Snyder

Rating: 4.5 stars out of 5

Copyright: 2009

As promised yesterday, we saw the initial midnight showing of the Watchmen movie at the Pacific Science Center IMAX. And, lo, the geeks came in their numbers and they were greatly pleased. Some were dressed as Rorschach, one came as a smurf; no, I lie, he was Dr. Manhattan.

I summarized the plot in my review of the book. That still holds: the movie was largely faithful to the book. In many scenes, it was clear that the book had served as a storyboard. Too faithful in some ways at 165 minutes long. Some subplots were eliminated; no doubt they will resurface in the director's cut. The Tale of the Black Freighter has been made as a separate animated feature for the DVD. One crucial point about the ending was changed (to Peter's outrage), bringing it closer to The Dark Knight.

I found myself immersed in the movie, though sitting in front of a six-storey screen does tend to draw one in. It's a visual spectacle that couldn't have been made twenty years ago during the early attempts to turn it into a movie. It's violent, more so than the book and more shocking than the book. Unsurprisingly, much of that extra violence centers around Rorschach, the uncompromising sociopath.

The acting is adequate to the task. Nite Owl (Patrick Wilson) and Silk Spectre (Malin Akerman) are the two most normal characters and hold the moral center of the film. Jackie Earle Haley as Rorschach has the most difficult role, hidden behind a face-covering mask most of the time, trying to convey the character's tortured soul. Billy Crudup has little choice but to play Dr Manhattan as a blank cipher, while Jeffrey Dean Morgan hits the right note as the Comedian. Matthew Goode as Ozymandias comes off more as a cartoon villain than in the book.

Fans of the book will certainly enjoy it. I think newcomers will like it too.

Quis custodiet ipsos custodes? (Who Watches the Watchmen?) asked Juvenal.

Answer: we do. The Watchmen movie, that is. Peter, Carol, Raven, Iain, Emma, and I are all going to see the midnight initial showing at the Pacific Science Center IMAX.

I'm not sure that I've ever been geeky enough to watch the midnight opening of a movie before. But it was Peter's idea.

Peter and I shared an apartment in 1990–92 when we were both grad students at Brown, and it was his copy of Watchmen that I first read.

And so the loop closes.

Zits. Somehow all those ads on TV for acne cream never quite tell you that zits continue after your teenage years.

This post was brought to you by the small but annoying pimple that appeared yesterday. Feh!

I knew three of my grandparents; they all died after I reached adulthood. My mother's father, George Victor Clery, died 12 days before I was born, on March 3rd, 1965. I was to be named Vincent after my father, [Charles] Vincent Reilly. Instead, I was christened George Vincent Reilly. I was the first grandchild for both the Clerys and the Reillys. I think I must have been a welcome distraction.

Ironically, my parents had gotten married on his birthday, March 30th, the previous year, and he didn't live to celebrate their first anniversary. The timing was partly in his honor and partly because it was Easter Monday. Catholics were not allowed to marry in Lent then.

I only know the man by repute. He worked, like many in his family, in a bank. His word was law in his household, but my mother adored him. He was very sociable: he'd invite clients to lunch in the bankhouse at the drop of a hat and my grandmother would have to figure out to feed them. His mother was told that he'd not live beyond infancy and his health was poor all of his life, but he was no hypochondriac. I see something of him in my uncles, Dick and Gabriel. Certainly the face and the moustache; also the gruffness.

George Clery, 1900-1965.

At lunch today, I told Eric about Hash Attacks: for many hash functions, it's possible to construct a large set of keys that collide. This can be used to cause a Denial of Service as hashtable operations can be induced to take O(n) time instead of O(1).

Crosby and Wallach successfully demonstrated this against a number of applications.

Andrew has a good writeup of Hash Algorithm Attacks.

There are various mitigations suggested. The one that I used when I first became aware of this problem is to use a salt to the hash function.

In other words, change:

unsigned hash(const char* s)
{
    unsigned h = 0;
    while (*s)
        h = h * 101 + (unsigned char*) *s++;
    return h;
}

to:

unsigned hash(const char* s)
{
    unsigned h = SALT;
    while (*s)
        h = h * 101 + (unsigned char*) *s++;
    return h;
}

where SALT is chosen randomly when the hash table is created or when the process starts. This should be enough to vary the order in which keys are distributed to buckets from run to run.

A few years ago, after watching one too many whodunnit TV mysterys, I coined my

Law of Economy of Characters

The killer is innocuously introduced in the first 20 minutes

In real life, the killer may not be known until late in the investigation—if ever.

In a TV mystery, any non-recurring character who gets more than a few lines has to be a potential suspect—to the audience. The character is not there gratuitously. Their salary is being paid for a reason.

It's not universally true, but it works more often than not. It's less true in books, where throwaway characters are easy to introduce.

Googling around, I found the following, attributed to Roger Ebert:

Ebert's Law of Conservation of Characters

Any main character whose purpose is not readily apparent must be more important than he or she seems

I'm in good company.

I use or participate in a handful of wikis hosted at PBwiki. A year ago, I wrote a PBwiki syntax highlighting plugin for Vim, modeled after the ones that I put together for the FlexWiki and SocialText wikis. Essentially, paste the wikitext into Vim, get syntax highlighting, edit the text, then paste it back into the multiline textbox. I find the WYSIWYG editors annoying.

PBwiki is forcing all wikis to switch over to v2.0 by March 9th. The good news is that the upgrade is painless and reliable. They offer new features, such as an improved editor, better access control, and a new look.

The bad news is that for cranks like me, there's no longer an advanced editor and wikitext. I can use the WYSIWYG editor or I can switch it to HTML source mode. Ick!

One thing that's been bugging me since I started using Opera is that bold and italic text was showing as normal text in my personal blog. Yet other browsers were correctly displaying bold and italic on my blog.

I'm still not entirely sure why Mac Opera had a problem with it, but I fixed it by using the Lucida Hybrid stylesheet tweak.

I adjusted a few other things while I was at it. The most obvious is that the font size is larger.

Most RSS readers won't pick up the stylesheet, so take a look at the actual blog.

I like Stack Overflow, Jeff Atwood's programming Q&A site. It's quickly become a go-to place for all kinds of programming questions. It's certainly easier to find a definitive answer there than trying to wade through a thread in a mailing list archive. The social dynamics seem to be working and a definite community has evolved.

I've been going there more often recently. I browse the hot questions and I often learn something from them.

I'm answering some questions too. I've been doing this for twenty years on Usenet and mailing lists. I might as well get a little credit for it on SO. My reputation is 131 as I write this: I expect it will grow.

Esther Schindler has a post about interviewing your next boss: should a candidate dev manager meet everyone who'll be reporting to them?

Yes. Definitely. If you want a successful, cohesive team, there has to be trust. A manager can make or break a team.

A new manager starts at a disadvantage, relative to a new individual contributor. The new dev is expected to ramp up and have time to build relationships with the team. The new manager has to build the relationships as soon as possible.

If the manager gets to interview with the team before being offered the job, both parties benefit. Why would you want to manage a team that you'd never met? Shouldn't the team have a chance to reject someone who's a bad fit?

I've interviewed “up” twice, once for a dev manager and once for a CTO, at different jobs. But those were the exceptions. Every other time there was a change of manager at any job, I was not consulted.

The two interviews were successful: I'd work for either of them again.

The dev manager went through several hours of interviews with the team, meeting us two or three at a time. We interviewed developer candidates similarly. We asked different questions of the manager, of course. I remember asking him if he had ever laid off or fired someone.

The CTO got to meet the entire engineering team en masse: a dozen or so of us grilled him for an hour and came away impressed.

I think that in either case if the teams had made serious objections, the candidate would not have been hired. Certainly, in both cases, the teams vetoed developer candidates.

It may be traditional, but I think it's a mistake for companies not to have managers be interviewed by their future reports.

Apple launched the public Safari 4 beta today.

It runs beautifully on Vista and it's the fastest browser that I've seen, noticeably faster than Chrome. Everything that I tried worked fairly well; I saw only a few minor glitches.

I installed it on my MacBook at home this evening. It crashes at startup every time that I attempt to run it. Fortunately, it comes with an uninstaller so that I could revert to Safari 3.21.

Back to Opera for now.

Title: Programming Sudoku

Author: Wei-Ming Lee

Rating: 2.5 stars out of 5

Publisher: Apress

Copyright: 2006

ISBN: 1590596625

Pages: 214

Keywords: programming, introductory

Reading period: 22 February, 2009

I was Toastmaster of the Day at this evening's meeting of Freely Speaking Toastmasters. My theme was software development and I wanted to give the non-developer audience a taste for what it's like to write a program. I talked about writing a simple Sudoku game.

Yesterday, I read Programming Sudoku for background. I bought this book for Emma after reading about it on Scott Hanselman's blog. It's targeted at beginning programmers and walks them through building a Sudoku game and solver. I was hoping to get Emma more interested in programming–unsuccessfully. She found it repetitious and a little confusing, and she found some typos in the code.

Pedagogically, the book is good. It starts by creating a simple WinForms application in Visual Basic to play a Sudoku game. Then it builds a solver for simple games and refines the solver to handle harder games. Next, it adds a puzzle generator. It concludes with a brief chapter on a similar game, Kakuro. The explanation of gameplay is clear; the approach seems reasonable.

The code, however, is horrible. It's ugly, it's verbose, and it's repetitive. Consider that the code for doing some operation to a row is almost identical to doing the same operation to a column, but no attempt is made to abstract such operations into helper functions.

Or how about this unexplained fragment to see if a column is complete, which is repeated often, with minor variations:

pattern = "123456789"
For r = 1 To 9
    pattern = pattern.Replace(actual(c,r).ToString(), String.Empty)
Next
If pattern.Length > 0 Then
    Return False
End If

To me, it's obvious that this is a poor man's set difference operation. To a novice programmer, I doubt it.

Examples should be exemplary and held to a higher standard than code that is not intended for public view. All too often, sample code ends up in production. When I wrote samples for classic ASP, I took care to make them good code.

The book is short. The author could have shown some ugly code as an initial solution, then cleaned it up and explained why the new code was better. That would have done his readers a greater service.

I cannot recommend this book to novices: they won't learn good habits from it.