George V. Reilly's Technical Blog

Command-line Tools for the Clipboard

I mentioned in my post on reStructuredText that I use a little command-line tool, pbcopy, to pipe the output into the clipboard. I finally found a similar tool for Linux, xsel.

• Mac: pbcopy (UTF-8 aware, unlike the built-in version of pbcopy) copies its input to the pasteboard (Mac name for the clipboard); pbpaste writes the pasteboard to stdout.
• Linux: xsel gets and sets the X selection.
• Windows: winclip reads and writes the clipboard in a variety of formats. Use -m for UTF-8 text. The winclip binary is available as part of the outwit package.

Review: Programming Sudoku

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.

The Bowling Game

There's a flamefest going on at the moment between Robert "Uncle Bob" Martin and Joel Spolsky over the value of Test-Driven Design and the SOLID principles. I find TDD valuable and I'm reading Martin's Clean Code at present.

Poking around in the links led me to Uncle Bob's Bowling Game Kata, a Powerpoint deck demonstrating using TDD to score a bowling game.

Ron Jeffries has a very ugly OO implementation and a cleaner procedural version of the Bowling Game. Digging around in the archives of his XP Magazine turns up many other ruminations on the Bowling Game

At Atlas, I was loaned to one group that used the Bowling Game for a pair-programming interview. I found it to be a valuable exercise. It showed us whether the candidate could actually code or not and it gave us a feel for what it would be like to work with them. It gave the candidate a taste of Agile work practices like TDD and pair programming. Of course, in a real pair-programming exercise, I would have been actively making suggestions instead of holding back.

We interviewed four candidates while I was on that team. Two passed, were hired, and worked out. One failed, failed other interviews, and was eliminated. The fourth candidate was very experienced, gave great whiteboard while talking through the exercise at the beginning, and turned out to be completely horrible. He floundered badly and wrote ugly, buggy code. That eliminated him, even though he had done well on the other rounds.