|Ned Batchelder : Blog | Code | Text | Site|
» Home : Blog
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.
I don't do a whole lot of CSS work, but I've got some opinions anyway(!):
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.
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:
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:
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:
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:
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:
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.