A year ago, I wished for svn blame all. I didn't find anything that could do it, so I wrote my own: blameall.py.

As a fan of type, and a doodler, I am very impressed by Kris Sowersby's type doodles.

Erik Spiekermann has details on secret yellow dots used to track laser printer output. Seems most laser printers print yellow dots in a decodable pattern to track which printer printed the sheet, and when. The Electronic Frontier Foundation has more details (many of the links are broken, but you can fix them by changing the www2 prefix).

This is a fine example of technology used to spy on us in a very subtle way, and for a good cause, to defeat counterfeiters. But the same technology can also be used for ill, and it's for that reason that techniques like this should be explained openly. After all, if the government's reason for this tracking is to prevent counterfeiters, I think everyone would be for it. So why not make the whole technique public?

BTW: EFF has a list of printers which do and do not print tracking dots. I am an employee of Hewlett-Packard, which make a great many models which seem to do this tracking. I am a bit more appalled because I work for HP, but I do not work near enough to the printer group to have any insight into or control over this issue.

If you are the type to become addicted to deceptively simple puzzle games, then whatever you do, don't start playing Jelly Blocks.

Jeff Croft wrote What's not to love about CSS frameworks, asking for debate over CSS frameworks like Blueprint, and got tons of it. Then he followed it up with some summary (and apology).

I don't do a whole lot of CSS work, but I've got some opinions anyway(!):

• Calling them frameworks may be a bit much. "Libraries" seems to fit the scope a bit better.
• Some designers complain of presentational class names. It's true that Blueprint encourages you to use class names like 'span-15'. The problem here is that CSS isn't rich enough to avoid it. It has no indirection capabilities. I'd like to be ables to say "style span-15 like this, and then style big-figure just like span-15", but I can't.
• People are starting to write tools to improve the expressiveness of CSS, like Moonfall, which provides variables and some simple margin math. Christian Montoya has a proof-of-concept of a tool called Semantify that lets you start with presentational Blueprint class names, and then fix them up to be pure semantic names.
• Some designers complain of inflexibility in Blueprint, but again, tools like Blueprint Grid CSS Generator help there too.

In the end, the biggest issues about the CSS frameworks seemed to be that many CSS designers simply prefer to do it all themselves. That's to be expected when sophisticated technologies are made simpler by providing simplifying libraries. The experts have climbed the learning curve, and can do more with the raw technology, they find the framework limiting. Non-experts find the raw technology baffling, and appreciate that the framework simplifies and organizes their work.

When dealing seriously with error handling, an important technique is to be able to manipulate exceptions in ways other than simply throwing and catching them. One of these is to re-throw exceptions.

» Read how to re-throw properly, with examples... (15 paragraphs)

Planet Saturday is a monthly comic about parents and kids. Rather then gags like Calvin and Hobbes, they are more like sweet remembrances with humor, about real moments during parenting or childhood. I love the drawings, which are detailed, expressive, and funny, and the stories are great. Too bad they only appear once a month...

Beautiful Code is a different kind of O'Reilly book. First off, the cover isn't an "O'Reilly cover":

Second, instead of an in-depth examination of a single topic, it's a browsable anthology of essays by a wide range of writers about a wide range of topics, loosely tied together by a single theme: Beautiful Code. Here beauty is widely interpreted, with each author applying the adjective as they see fit.

Some essays work better than others, of course. Andrew Kuchling's piece about how to implement Python dictionaries so that they perform well for all of their varied tasks was very interesting, reviewing all the various optimizations and tradeoffs. Not to turn this into a Python vs. Ruby thing, but Yukihiro Matsumoto's piece, Treating Code as an Essay, was fluffy and inconsequential. That's the price you pay for having an assortment of pieces by different authors.

The other essays cover a wide gamut, from the design of Linux kernels to audio-enabling emacs to the Mars Rover mission to designing software for Stephen Hawking:

"Professor Stephen Hawking can only press one button," was the one-line spec we were given,

begins Arun Mehta's When a Button is All That Connects You to the World. One of the fascinating aspects of these essays is that although they are all about code, they come from such diverse domains, that you can't help but learn new views on topics you already know a lot about.

I haven't read all of the pieces in the book, but the ones I've dipped into have been thought provoking. It's an interesting collection of essays, each by someone who cares a great deal about their code. If you care about yours, Beautiful Code can only deepen your appreciation of it.

Ever since suggesting dunder at work as the pronounciation of two underscores, it has caught on, more than I would have expected. We engineers are also big fans of The Office. So I shouldn't have been surprised to see a new function in the code named:

__mifflin

This was actually suggested by Bob Congdon in the comments on the dunder post eighteen months ago, but I'd forgotten, and got a good laugh when I saw it...

In September, a bug was reported in Excel 2007 which makes 850×77.1 display as 100,000 instead of the correct 65,535. Many people theorized about the cause. Chris Lomont did something different: he analyzed the behavior of the code in depth, and found the problem, producing a 25-page paper with code and diagrams: An Analysis of the Excel 2007 "65535" Bug. This is an impressive piece of work, and is an instructive example of the difference between what problems appear to be, and what they actually are.

It also includes this paragraph in the conclusion:

A final comment to lawyers confused about fair-use issues, reverse-engineering for interoperability, First Amendment and DMCA issues, and the like. Be sure to do your homework before you contact me. It will save us both time and one of us embarrassment.

Chris has a lot more than that, too. His site has tons of math-meets-computers goodness, including graphics code, puzzles, screen savers, floating point tricks, LED hacking, superball pranks, and so on. Good fun.

Philip Greenspun asks "What's the Best Computer Language for a 13-year-old Beginner?" and gets an awful lot of responses. Many of them seem to totally miss the mark about how to introduce kids to programming.

In my experience, you have to keep a number of things in mind besides programming languages.

First you have to find out what fascinates the kid in question. Do they want to make a video game? Do they think expressing themselves in a web page is cool? Do they want to pull data from the web and manipulate it somehow? What sort of application would be interesting to them? Some kids are fascinated by programming itself, but most are only using it as a means to an end, and you need to know what that end is to keep their attention.

Next, there are many things that you and I don't think of as programming that are still programming in the kid's mind. Creating an web page in HTML is programming. Selecting the correct options in a constrained game editor like RPG Maker XP counts as programming.

To a kid who's never told a computer what to do before, any kind of direction that the computer will follow counts as programming. It may not have loops, it may not involve typing, but they still have to:

• decide what they want the computer to do,
• understand the tools at their disposal,
• create the instructions,
• try out what they did,
• and figure out what's wrong when it doesn't come out right.

That right there, that's programming.

The last thing to understand: how much help will you be providing? One way to get kids going is to do most of the work yourself, but then give them a very simple control to play with. I wrote a simple video game once, and then showed Max where the initial number of aliens was set. He could change the value from 10 to 50, and see a dramatic difference in the game play. It was eye-opening for him even though he was too young to be able to make substantive changes.

If you are going to help a lot, then you either have to choose a language you already know, or are willing to learn yourself. If you aren't going to help a lot, then you have to choose a language that won't need a lot of help. This sounds obvious, but your time commitment is often the toughest variable to get right, so think carefully about it.

All that said, I think there are some interesting unconventional choices for where to start kids with programming:

• Flash: the big advantage here is that you can start by simply making key-frame animations, and then graduate up to Actionscript in small doses. Also, kids have probably already been exposed to tons of Flash content, and so have good cultural understanding of the types of thing they can build with it. Downside: expense, though I had good success with buying a copy a few versions old on eBay, and Academic Superstore will sell you an educational license.
• Scratch is a tile-based visual programming environment. The results can be a little crude by Flash standards, but it's a very nicely made environment. Actions are expressed by clicking tiles together, so there's no syntax errors to stumble over. Some of the example projects are quite impressive. One nice detail: the layout of the tile code almost resembles what a textual programming language would look like, so it's a good stepping stone to more mainstream environments. BTW: MIT also has StarLogo TNG which also uses the tile metaphor for building programs, and uses a more ambitious 3D environment, but seems not quite finished.
• RPG Maker XP is a game editor for making tile-based games like the original Legend of Zelda (I think). The graphics are all created from a large set of tiles, so it's easy to make environments that look reasonable, and all of the "coding" is done my making choices in dialog boxes. Enormously complicated dialog boxes, but at least there's no syntax to learn. Max downloaded and figured it out himself when he was 12 or so, and now he's taught Ben (now 9) how to use it, so it's approachable, even though I don't understand it at all. There's no real path up from there, though, so this is only good if the child in question wants to make RPG games.
• HTML. Don't worry that this isn't a programming language, and don't worry about all the CSS form-vs-content stuff. Your kid will probably be thrilled by <font size=7 color=red> and will have his first taste of where the red pill can take you.

In the conventional languages arena, there are good attempts to bridge the gap from kids to code: Hackety Hack is a tutorial and programming environment for Ruby, and RUR-PLE is a robot simulation using Python.

Whichever tool you choose, remember: they're kids. Don't make the mistake of treating them like short adults. They aren't starting a career, or building a resume. It doesn't need to be bullet-proof, it doesn't need the latest theoretical underpinnings. Give them the answers when they are stuck.

Just make it fun.