This is a introduction to computer security for programmers. It's subtitled, "What every programmer needs to know." By reading this book I learned... I learned that I'd already learned the foundations of computer security. That doesn't mean that this book is worthless; actually this book is pretty good. I'm just saying that you can learn most of this material in a haphazard fashion by reading comp.risks for 20+ years. What's that you say? You don't want to read something for 20+ years? OK, reading this book would be quicker; you can polish it off in a few hours, longer if you work through the exercises.

If you retain what you've learned, maybe I won't be reading about you in comp.risks. Let's hope that doesn't happen. Why do I learn so much from comp.risks? Because I remember what I read there. Why do I remember? Because it's full of security horror stories. Some poor slob programmer forgot to check this one little thing, and look at how many things fell apart as a result. Scary stories.

Actually, I did get something out of this book. There was some good advice on how to think about escaping & unescaping text for db-backed web apps (i.e., for most of the software that folks write these days) without going nuts keeping track of it all. For that, I'm glad that I read this book. I learned what triple-DES is. For those things and... you know, when you learn something haphazardly, you never really know how well you've learned it? This book was reassuring.

It is Steve Wozniak's autobiography, as told to Gina Smith. It's a fun read. Keep your wits about you as you read--they didn't fact-check all of this material. So when Wozniak tells you what was going on in the industry at this time, you need to remember it was his perception. Probably everyone at Apple was saying that the Apple ][ was the first to sell a million units, so when Wozniak repeats this... Well, maybe that means that Apple was an echo-chamber around 1983, believing their own PR.

But it's worth reading this book. Wozniak has had a fun ride so far, and it's fun to read his reminiscences. Just in case you don't read it, though, I'm going to quote some things from the end of this book, the ideas he was hoping to convey, the lies he hoped to correct:

• He didn't drop out of college
• He wasn't thrown out of the University of Colorado
• He didn't go to high school with Steve Jobs (they went to the same school, but not at the same time).
• He designed the Apple I and Apple ][ machines himself, not with Jobs' help.
• If you are an inventor who works best alone, he advises you to work alone.
• If you are an inventor, please invent. We could use some better inventions.

I'll quote the last paragraph:

I hope you'll be as lucky as I am. The world needs inventors--great ones. You can be one. If you love what you do and are willing to do what it takes, it's within your reach. And it'll be worth every minute you spend alone at night, thinking and thinking about what it is you want to design or build. It'll be worth it, I promise.

Wow, inspirational stuff. I hope more folks are inspired by that than by some of Wozniak's practical jokes, many of which seemed more mean-spirited than funny. (Although I'm sure he would assure you that he didn't mean them in a mean-spirited way.) Check it out.

I'm getting some writing done this weekend, finally putting together notes from the Midnight Madness: Back to Basics game. And I'm listening to some music by Dengue Fever. They perform in the style of 1960s Cambodian rock music. OK, that's gimmicky, but it works. And they've updated the songs, some of whose stylings sound cheesy today. Yes, I've been listening to some of the original Cambodian songs--the internet is a wonderful place, full of pirat-- uhm, archived media. But the story behind the music is sadder than anything you'll hear on VH-1 Where are They Now. "Probably died in a Khmer Rouge labor camp," is not how you want anyone's story to end. But singer Ros Serey-Sothea was a big star in Cambodia in the 1960s, which was an unfortunate time to be in Cambodia; her story is sad, and probably ended in a Khmer Rouge labor camp. Luck is important. Timing is important. It's better to be lucky than talented.

Oh, right, my point. The book Wireless Nation is about lucky people.

This book is about how the USA's FCC apportioned spectrum to early USA cellular telephone companies. There weren't always auctions--the FCC wasn't even allowed to run auctions. So it tried giving the spectrum away based on merit. But that was hard. Then it tried a lottery. Things got really weird as tons of little companies joined the lottery.

It's a strange story full of strange personalities. The USA came late to the world of mobile phones. Its mobile phone industry has been slow to develop. Back when I worked on mobile phone software platforms, those platforms weren't for the USA--they were for Europe and Asia, where people actually used mobile phones.

Why is the USA so backwards? Because its phone providers are a gaggle of randomly-chosen mountebacks. This book tells their story.

One interesting fun bit of history: You know that "fact" that using cell phones in automobiles causes car accidents? The AAA was saying that before there were car phones. It wasn't based on research, it was just a concern, a worry. We should pay more attention to abusive husbands and totalitarians taking over government. We know that these problems recur. They were bad for Ros Serey Sothea. They are bad for us today.

This book's title is misleading: it make sense. This book's preface is misleading: it makes sense, too. It took a while before I realized that the book was noodling all over the place but not actually saying much.

It's tragic. The book is about personal information management. Everyone cares about personal information management: everyone has personal information. TODO lists, emails, schedules, articles, ... I'm a writer. As an information provider, I care about other people's PIM. It's not enough that I keep track of my own info. When I distribute the technical documents I write, I want to make sure that other people can keep track of them--this desire affects my choices in my publishing medium. (I'd love to distribute my documents on Hello Kitty stationery (It smells like bubble-gum!) but my customers couldn't track paper documents easily.) Alas, this book is no help. Or maybe it's some help, but I ran out of patience trying to slog through it.

Early on, it tries to define "information." When it comes to personal information management, spending more than a couple of paragraphs on the definition of information is philosophy. Where by "philosophy", I mean "not useful".

What is information? This question has been a repeated topic of discussion in its own right. Buckland provides an analysis illustrating that the word "information" alternately denotes a process (...), a result (...), or a thing (...). In reaction to the definitional inclusiveness of "information" and the many senses in which the word is used, Buckland concludes "we are unable to say confidently of anything that it could not be information".

I can't believe someone asked me to sit still for a paragraph like that--a paragraph that included the phrase "definitional inclusiveness"--just to tell me that some guy named Buckland pointed out that it's hard to nail down the meaning of a hand-wavy term like "information". But we go on for a chapter rambling on about what can be considered "information".

Let's keep going.

A wiki can be likened to the field in a public park after a snowfall. We can write what we like in the snow but others can too.

This is a pretty image. I appreciate the fact that he didn't compare a wiki to a palimpsest. I am so frickin' tired of people comparing wiki pages to palimpsests. On the other hand, we're already on page 39 and I have been slogging through this book for quite a while without encountering any insights. Why make me sit through a paragraph of simile about a wiki? Why not cut to the chase? Does this book have a chase?

I gave up on this book. There might be some insights buried in here somewhere, but extrapolating from the first 40 pages, I project it's a waste of time.

Maybe I'll just flip ahead. Angry technical writer challenge: choose random paragraphs; reduce each of them to a sentence.

Paragraph

Planning--whether planning a party, a vacation, or even a weekly meeting--can be fun and, anyway, it needs to be done. Chapter 5 considers the possibility that, given the proper tool support, an effective organization of information (based on file system folders, even) can emerge as a natural by-product of the planning we must do in any case. Chapter 9 generalizes by considering various activities that help us to make sense of our information. These activities help us understand and make better use of our information. These activities can alse be a way of managing our information.

Sentence: You can use information that you capture and organize while planning, but I won't say anything concrete about this for a few more chapters because I'm wordy.

Paragraph

It is time to consider a single, unified, and smarter auto-complete facility that can be accessed from all our machines and that works consistently across multiple applications. At the core of this would be a database such as "person" and "budget" and associated properties such as "cell phone number" and "current budget amount." Email applications, word processors, web browsers, and other applications could access this either to store new information or to retrieve information.

Sentence: Omnipresent strong AI would be awesome, but I would still be wordy.

We might hope that somewhere--perhaps at the Library of Congress--legacy applications will be preserved that are capable of rendering and supporting the manipulation of information kept in legacy formats, although support for legacy applications, in turn, may require preservation of legacy operating systems and even legacy computers to run all of the above. Better for most of us might be a web-based service to which we could submit information items in legacy formats--especially photographs and videos--and have them returned in a current format of our choice--in a manner reminiscent of the way we once sent exposed film to a film development lab for processing into prints or slides.

Sentence: It would be awesome if someone figured out legacy formats, but I would still be wordy.

Oh, even the individual paragraphs make me mad in how they waste my time. I need to put this book down. I think the root problem is that this book was written by an academic for other academics. But the title made sense, so I thought it might be written for human beings. That title tricked me into reading forty pages + three paragraphs, but no more.

Myth Adventures is a comic book based on the swords-and-sorcery comedy Another Fine Myth. It's a few years old, but got reprinted recently. I picked up a copy a few weeks ago at Comic Relief. You know, the comic book store whose owner died recently. Another Fine Myth is by Robert Lynn Asprin, who died yesterday. The comic book art is by Phil Foglio who, barring disaster, is still alive.

It is a very funny comic book. A worthwhile legacy, you might say.

It's sad news that Rory Root, owner of Berkeley's Comic Relief comic book store, died today. But no-one reads this blog for news. You're here for book reports. Here is a book report for Defensive Design for the Web:

A quick book of how to deal with those most dangerous parts of designing a web application: when we force people to think. How to write and present a useful error message. How to design a web form. Making online help useful. They point out some examples worth stealing from.

The Shinteki series of games is so awesome that you can remain bitter about a van breakdown for several days afterwards if that van, you know, interfered with... Oh, I'm just going to go sit over here in the corner and be grumpy for a while. To avoid charges of scapegoating, I should admit that there's a non-trivial chance that we would still have come in last place even if the van hadn't broken down. Nevertheless, grr.

Grr.

I enjoyed reading this write-up of a recent Stanford Game. You might, too.

I didn't take any Shinteki photos. That's not quite true. I took a photo of an easel while GC was still setting up. Then Brent put a cover over the easel, like folks weren't supposed to see it so early. So then I erased that photo. Later on, when we were allowed to see the easel, I snapped some photos. But they didn't help. Later on, I didn't think to take photos.

Fortunately, Tobias Lester took some photos. Yay, Tobias! Tobias was on the team. So was Laura! And Emily! They were great! There's a team, photo, yay. Except Tobias isn't in the team photo because he was, you know, holding the camera. the iPhone. the whatever. Anyhow. He took the photo.

And then there's a photo of the lady who towed away our broken-down van. She's pushing that van across the parking lot because (a) the van wouldn't start and (b) she's a tough lady who can push vans across parking lots even if those vans don't start. She was pretty amazing.

Then there's a photo of that view from that lookout point. Chronologically, that came before the van break-down. But these photos are ordered alphabetically and "view.jpg" comes after "singlehanded_van_push.jpg". Hey, if I renamed "view.jpg" to "lookout_point_view.jpg", then it would be in the correct chronological order. Or I could go to bed right now. Yay, bed!

Behold a lovely forum for discussing puzzle hunts, puzzle magazines, and stranger things. It's new, so there's not much there yet.

Scott Blomquist set it up and seeks your frankest feedback. He writes:

Hey, all, I’ve been meaning to start down the road toward building up a community of all you puzzle people out there, whether you call your puzzle addiction Puzzle Hunt, Mystery Hunt, Treasure Hunt, Games Magazine, or The Game, I’ve set up exactly the site for you: http://www.puzzlehunters.com.

Please check it out and give me the frankest feedback you can on what’s missing. I also admit that I’m not 100% sure how to quickly get to critical mass, and, once I’m there, how to sustain it. Your thoughts on that also appreciated.

Some thoughts... I'm guessing that forum activity will be bursty. Like, in the events areas, lots of excitement when a game is announced, a flurry of "Yay, thank you" posts after a game... but not much else. Games Magazine, P&A don't come out super-often, so... bursty again. I bet folks won't get into the habit of swinging by the site once per day. So it's good to get notified when there's activity. The site supports notification, but it seems like I have to sign up for notification in each forum separately. That's a minor hassle, but it's a hassle. So... in terms of getting people to check back when there's new activity I'd suggest:

• Don't go wild adding new forums. While there's still small numbers of people using the site, probably no single forum will get much traffic.
• Does this phpBB support RSS feeds announcing forum activity? There's a non-trivial chance I will overlook email notifications.

To grow the community quickly, you might encourage an event organizer to use a forum as part of a pre-game puzzle. If each team needs to post their answer, that's a few people subscribed right there... A lot of folks who run games think about community, so they might go for it. To keep people coming back, trick your friends into posting content occasionally. Maybe occasionally post some philosophical questions, try to stir up a lively discussion. "Hidden Pre-Game puzzles: Wacky fun times or unhelpful annoyance?"

I don't know anything about the puzzles announced at the Google Australia Blog which is a little frustrating because I'm apparently not supposed to register to look at them.

I made a pretty plain code cheatsheet for puzzlehunts. It doesn't have all the codes you want, but it has the biggies and it's not too crowded. PDF is here: http://lahosken.san-francisco.ca.us/frivolity/hunt/cheatsheet.pdf If you like it, but want to add to it, the source (an OpenOffice spreadsheet document, so help me) is in the same directory. If you improve the cheatsheet, feel free to send the result to me, I can post it.

I used to use an Nth generation photocopy of the code sheet the Burninators provided for BANG 7. But I lost track of that piece of paper a few months back. Yes, I'd made a few copies. I lost track of all of them. Maybe one of them will show up... but if it doesn't show up by Saturday's game.... uhm, yeah. The Shinteki folks had some darned nice schwag at last year's Decathlon event: a pad of paper, each sheet graph-ruled with codes in the margins. Nice, but I also want cheatsheets to pass out. A while back, I'd talked with some folks about the advantages of having multiple mini-sheets with one code on each, but that seemed like it would take more effort, cutting pieces of paper apart. Yes, I am that lazy.

Here I am tending to my blog on the bus. I wasn't really planning on it. I was just checking my email. I get email, among other occasions, when someone or something posts a comment to this blog. My mail this morning suggested that a spambot was posting spam comments to this blog. So here I am, cleaning spam. As long as I'm here, I guess I'll post a Book Report I've had sitting ready for a few months. It's about re-writing software. Like hopefully someone will re-write some of blogger's anti-spammy stuff so that bots can't break CAPTCHA anymore. That would be awesome. Actually, this book isn't about that kind of programming, not about changing how programs behave. It's about changing programs so that they behave the same.

If you're a computer programmer, you've probably heard of this book Refactoring. Everybody talks about it. Everybody talks about Knuth, too, but nobody has read him. (I started to read Knuth, but bogged down when I was reading about his example machine architecture... what was it, 13-bit words? Yeah, yeah, I've heard that the new editions will feature a more modern architecture. I'm sure I'll give them a try eventually. Anyhow.) Reading Knuth wasn't easy. But reading Refactoring is easy.

Parts of it were too easy. I eagerly read the catalog of refactorings. I gobbled them up like popcorn. "Oh, I can see how to apply this refactoring, and now I feel clever," I chuckled to myself. But I was reacting like some silly student who still has a favorite data structure--it was too easy to get swept up by the catalog of refactorings, to forget that each refactoring has a purpose.

I'm doing my best to forget the list of refactorings. Instead, I want to remember the list of "code smells"--things to look for in my code. Symptoms of problems. Often, to recognize one of these suggests the refacto... the edit by which one may purge it.

Alternative classes with different names, Comments, Data class (struct w/few methods), Data clumps, Divergent change, Duplicated code, Feature envy, Inappropriate intimacy, Incomplete library class, Large class, Lazy class (class w/little functionality; perhaps can be absorbed into something else), Long method, Long parameter list, Message chains, Middle man, Parallel inheritance hierarchies, Primitive obsession (reluctance to use objects to represent, say, int values), Refused bequest (subclass overrides most of parent), Shotgun surgery, Speculative generality, Switch statements, Temporary field.

Looking them over, most of these look like problems with poorly-architected OO. There's a temptation to toss out OO--look at the mess it's brought. But then, I do like being able to associate functions with the data they act upon. I like it most of the time. And, as the saying goes, "I can write Java in any language". Don't toss the baby out with the bathwater. Moderation in all things.

Maybe I should turn on moderation for comments on this blog. Hmm.

I posted some notes on the excellent SF Minigame. There's one photo. Usually I have zero photos or many photos. This time, one.

In other news, yesterday The Great Urban Race came to San Francisco. Looking at their website, they seem similar to Urban Challenge. Or maybe I just think that because that photo on their FAQ page looks like it could be the Graham brothers. But it explains some of the strange people I saw on the Embarcadero yesterday. And there was the KGB Puzzle Hunt at CMU, but I didn't see any of that. It turns out that CMU is not in San Francisco.

I didn't plan to spend today filling out an alternative minimum tax form for my friends at the IRS, but they insisted. I thought maybe I'd write something. But I didn't write anything. Except numbers. And now I'm grumpy, so I doubt I'll write anything today. Anyhow, here's a book report I wrote back in a happier time, a book report on The Middle Kingdom:

It's another Andrea Barrett novel in which the main characters are scientists; thus, I am a sucker for this book.

How was the Cultural Revolution like a bad marriage? Why do I blame you for my personal problems? (Here, I mean the general "I" (except in this parenthetical phrase, I guess).) What's the difference between a memory palace and a dream palace? This novel touches on these issues, but it's a fun read in spite of that.

I saw a campaign poster for Obama. It read

Fired Up
And
Ready
To Go

...laid out with those line breaks. I'm so acrostically minded that I found it crudely funny. I blame the puzzle hunts. (I am trying to use the time-delayed publishing feature again. We'll see how that goes.)

[Edited to add: the line breaks, without which this post didn't make much sense]