Book Report: Lewis Carroll in Numberland

This book is about Lewis Carroll/Charles Dodgson as a mathematician. There were errors in the parts that I understood. So I didn't trust the other parts to help me to understand new stuff. Maybe I could have learned something about math if I'd tried harder. Or maybe I would have wasted time chasing my tail around the author's mistakes.

The book's intro points out some places where math came up in Carroll's kiddie lit. It's nice--but for this you of course want Gardner's annotated Alice books, which have the math-y stuff and the other stuff as well. Once you get past the introduction, the rest of the book is organized in fits, a nice Snarky tribute.

The first chapter fit is about Dodgson's childhood, concentrating on the math-y bits. He learned geometry. Good for him, I guess. The second chapter is about college life. He took exams. He did well at them. Good for him, I guess. In the third chapter, he's still an academic. He tries to teach some young kids math, tries using recreational math to keep them interested. The book seems to be looking up...

And then, there was the cipher. It was around here that I had a crisis of faith with this book.

...two days later, Dodgson recorded that he had devised another [cipher], far better than the last:

It has these advantages.
(1) The system is easily carried in the head.
(2) The key-word is the only thing necessarily kept secret.
(3) Even one knowing the system cannot possibly read the cipher without knowing the key-word.
(4) Even with the English to the cipher given, it is impossible to discover the key-word.

This new one was his matrix cipher, which is based on the following grid:

E K P U/V *

...Following Dodgson, let us suppose that the keyword is GROUND, known only to the sender and receiver, and that the first word of our message is SEND.

  • to encode the letter S we go from G (the first letter of the keyword) to S: this is 2 places to the right and 1 place down, and we encode S as 21;
  • to encode the letter E we go from R (the next letter of the keyword) to E: this is 2 places to the right and 3 places down and we encode E as 23; ...
...and he finishes the example. I'm not a master of cryptography but when I look at this encoding scheme and look at the claim "Even with the English to the cipher given, it is impossible to discover the key-word", I call bullshit. Did Dodgson claim this? Was Dodgson wrong? That would be worth pointing out in the book--but that doesn't happen. Did the book explain the encoding scheme incorrectly, and maybe the real scheme really did have a way to keep folks from learning the key? Maybe.

A short while later, there's a sentence, in the context of Dodgson dispelling a rumor: "No British newspaper reports have been found that support Dodgson's account, so perhaps it was true after all..." This sentence--there were a few ways to interpret it, contradictory ways. Does he mean that British newspapers are unreliable so we should trust Dodgson? Does he mean that British newspapers are more reliable than Dodgson, so perhaps it (the rumor) was true after all? What is the author trying to tell me? Around here, I gave up on the book. I was just moving my eyes over the pages.

Maybe a good book to give to a budding nerd who liked the Alice books. On the other hand, you might do better to give that nerd The Annotated Alice.

Labels: , ,

Tiny Update: finally posted zombie chess puzzle layout photo

Finally posted a photo of the Zombie Chess board layout to the directory of Zombie BANG photos. Why yes, that did take a while.

Labels: ,

Comic Report: The Question: The Five Books of Blood

I picked up this comic book collection "The Five Books of Blood" because it was written by Greg Rucka, who has written some good stuff. So, he's written some good stuff. But he also wrote "The Five Books of Blood". So now I know that not everything he writes is worth picking up.

Maybe if I liked the world of Batman more, this might have appealed. This book is set in the world of Batman. It's pulp-y. Do you like the idea of a group of thugs who worship the idea of crime, who perform crimes because they think they'll gain mysterious powers by doing so? And maybe they do gain mysterious powers by doing so? If so, this comic book is for you. This comic book wasn't for me, though. The idea of crime as a nigh-tangible force is very Batman-ish. But I haven't steeped myself in that tradition, and this book didn't really encourage me to do so.

Labels: ,

Jotting Notes on Red Byer's GC Summit 2009 Talk "Run More Games"

OK, jotting some notes about Red Byer's GC Summit 2009 talk "Run More Games". Yes, the talk was months ago; my notes are not timely. Oh, before I even start, I should link to Red's own notes about the talk--some hindsightish notes and clarifications. Are you back? OK. I'll mostly try to paraphrase here, but I'm injecting some thoughts [in square brackets]

  • Talking about the Bay Area Game only. Which doesn't include Shinteki, BATH. Talking about 1992-present.
  • Defining what counts as a Game. Site + Theme + Clue + Travel
  • Difficult enough: any GC can RSA-128 encrypt a message and give it to a team to slow them down. That's what we're gonna do to the lead teams in Muppet Movie Game, so beware. [hee hee]
  • Typical game is ~20 teams. Run only once. It's like a wedding. [don't scale well; e.g., "this site's parking lot can only handle 20 vans". replay value is there--but GC is probably too exhausted to do it.]
  • Team-based.
  • Community. You have to give back. Give back your time. Playtesting, GCing.
  • The formula. The basic idea: For the game community to survive, folks need to contribute, not just take. It's not enough to contribute just as much as you take. Because lots of teams drop out after just a few games, you need to contribute more than you take or else the community's going to asymptotically go to zero.
  • The formula, ctd. You need to give back one Game every Five Years. You might think, 20 teams play in a game, my team plays 2 games a year, so we'll just run a game in 10 years. But because of attrition, because teams stop playing, you'd better run a game every five years.
  • running games is big effort, expense, stressful
  • Folks worry about inadequacy. Don't do that. you're not gonna do the _______ aspect as well as ________ GC. That's OK. Doesn't have to be the same as everybody else's. My game is going to have my style, my flavor.
  • Running a game: warm fuzzies; giving back to community; try new things, e.g., industrial design; influence community direction; Higher Probability of Future Play
  • History. Captains list, so you knew teams were good--and not too many of them.
  • Feedback loops: a team will "try out" a player. Players they get along with get invited back.
  • Feedback loops: teams want to play, but also trust GC to run good Game. GC needs an audience that can handle 30 hours of Morse code and driving. There's mutual trust.
  • In the past, there was an understanding that teams who were more likely to run games would be invited to more games ??!? [Not sure how this worked. If a team played too much w/out running a game, were they removed from the Captains List?] Number of teams was pretty stable through the 90s. [Oh, maybe teams not-running games has always been a potential problem--but the explosion of # of teams in the aughts exacerbated said problem?]
  • Nowadays, there are still teams and games--but game community is larger. There's been crossover with other communities. No more Captains List.
  • Application process--takes team effort. Doesn't necessarily reward what you want. E.g., first-come first-served just rewards folks who wake up early. [Ideally, application includes a resume of games run, and you'd consider that. (But that requires GC folks to be judgmental, and not everyone is comfy with that.)]
  • Crossover has been good and bad thing. (Here crossover is with things like MSPH, Seattle Game, Shinteki, BATH.) We're more popular now! But we haven't seen a contribution from these folks back to the Game community. [So they should have run Moonraker's in San Jose instead of Seattle? WTF? (...and SBlom touches on this later)]
  • So there's a lot of teams that want to play, but the number of Games hasn't scaled to meet demand. Most games run by repeat GC. Not enough new GCs
    • Linda Holman points out: You don't have to run a BANG before you run a weekend game. Red says: Yeah, firmly believe in rookie GCs; ratrace was messy... but it still worked out. XX-Rated's Paparazzi game was awesome. Goonies was awesome.
  • Possible solutions:
    • close the Game Community 20 teams [reinstate something like the captains list].
    • we can "redefine and branch the community" [???] try to stop the crossover
    • reinvigorate the feedback loops. Even if you don't like a team, if they've run a game, let them play: they've given back to the community.
    • Don't expect to play in every Game.
    • Run More Games
  • Melinda Owens: Gee, if people ran more BANGs instead of more Games, that might help more: BANGs can handle more teams.
    Red: That wouldn't help reduce the demand for Games, though.
    [if your goal is max# of happy players, run a BANG. But if your goal is to get invited to more Games, run a Game]
  • Jennifer Novakoski: Ghost Patrol was team LowKey's first game. It was a full-length game. In hindsight, a few LowKeyers would rather have run a small game first. It's really hard to devote a year of your life to something that you're not even sure it's going to be successful. Just to learn the logistics.
    • Sean Gugler: not a rebuttal, just a contribution to the discussion. I have run full games, I have run half-games. The half-games were not significantly easier to run.
    • Red: Yeah, we spent as much time on overnightmare, a half-game, as on ???
    • Sean Gugler: then again, as I get older and need more sleep, I find the half-games more appealing. [This old fart says, yes, by jiminy.]
  • Brent Holman: As a prospective GC, you should push yourself a little bit. Try doing something that is more than you thought you could do. Try a half-Game instead of a few-hours BANG. Some things... taking the overnight aspect out helps the logistics a lot.
  • Scott Blomquist: I'm in one of those not-in-scope groups [Scott is from Seattle game community, though he lives in Portland as of 2009. It's complicated.] How are we "invaders from the north" perceived by the Bay Area community? You know, it's really hard to run a remote Game. Alaska Air is cheap. If we run a Game in Seattle and you're invited, does that kinda count as "repaying the community"? Or do we need to put a cell membrane around each city and figure out what the equilibrium equation looks like?
    • Someone: I'd love to go to Seattle
    • Greg deBeer: I've never played a Seattle Game, but I think it would be really fun, so do it. But there's also a trend we're seeing more of: simultaneous running a game in multiple cities. No, nobody's tried to "simulcast" a long Game game, just BANG/SNAP/MSPH-like things.
  • Linda Holman: Another barrier to entry [and thus a way to control demand] is money. If you run a game in NYC or Chicago, that will limit your demand down to 20 teams--the 20 teams enthused enough to fly to NYC for a game. But right now, with demand the way it is--you would get 20 teams who are willing to fly to NYC.
    • Red: But do we really want do limit demand for each game? Or do we want to run more games? Most teams don't want to play in 6 games per year.
  • Corey Anderson: If I'm GC figuring who has game-running karma, that's hard if I'm a brand-new team. I might not know. And also--what have you done for me lately? [Is Red disappointed w/Desert Taxi and LowKey because Orange Snood didn't get in to Ghost Patrol? Orange Snood hasn't run a game since those teams have been around. Then again, the Orange-ites and the Snoodites ran more than there share of Games... but years ago. Maybe it was Red's contemplation of all this that led him to wonder how often a team should GC?] So do you tell a new team: well, you have to let this "old guard" in? I don't know what the solution is here.
    • Red: Yeah, been on both sides of that. Been rejected by GCs. As a GC, have rejected teams because I didn't think they'd be a match for our game. "It happens." But we try to favor teams that have bled for the game. As a community, to survive, you have to reward folks who contribute to the community. Otherwise, folks who have run games will disappear. We've seen GCs, where it just obliterated their team. The BioHazard game, the Espionage game, there have been several examples. Anyhow. I'm not saying I have all the answers, I'm just saying this might be a key to get more GCs to step up.
    • Crowd chatter: Hey, if we obliterate more teams, that will reduce the demand :-)
  • Jesse Morris: so we're new GCs. Of the teams that applied [to Ghost Patrol], about 15 were past GCs. We don't know what they did, but we know they did something.
    • David Mendenhall: We were trying to bring in new blood, folks who will maybe contribute more in the future.
      • Red: Yeah. And honestly, the folks on the "old guard" are pretty adept at landing on teams. In Ghost Patrol, I landed on my sister's rookie team and had a great time.
  • Chris Dunphy: If a team is cohesive, a team can go on to run a game. But what if it's a ragtag mob that gets together to play a Game--but not a great group of folks to run a Game? Like, say, RadiKS. I'd like to get advice on how to build a Game-Control centered team to run a game.
    • Red: You know how when you're playing and your team says "Hey we could run something sort of like this but--" that's the spark. [Uhm, and if your team doesn't ever say that?]
    • Teresa Torres: Orange Crush played in 5-7 games with no team dynamic problems. Friends from college, got along really well. Running a game destroyed our team. The reason why: half of our team had no idea what they were getting into. I mean, they knew: we had a plan of building clues and finding sites; and it didn't happen. 2-3 of us bore the brunt of the entire game. Fortunately, at the end we were all still friends--but we will never play in a Game again. Yeah, your Game team is not necessarily your Game Control team. But you might have two teams together like Desert Taxi and and LowKey [and the Snout/Drunken Spider combo springs to mind]
    • Red: Yeah. There's a few Orange Snood folks who are running the Muppet Movie Game. But not all of Orange Snood is running the Muppet Movie Game. I know Snout likes a big "core" GC, but I like a small core. Less effort on updates, reminders, the effort to keep so many people working towards the same vision.
      • Scott Blomquist: quick remark, for some reason in Seattle, 12-person "cores" work really well. Insert your favorite Microsoft joke here :-)
      • Corey Anderson: Huh, so in the Bay Area, part of the reason a lot of "teams" have a tough time GC'ing is that it's basically one serious person and their four "friends of the week". So is the MSPH tradition different?
      • Scott Blomquist: Yeah. Actually, some Seattle non-MSPH have chosen team sizes relatively prime to the MSPH team size, just to force folks to mix a little. I'm affiliated with a 12-person entity, a 6-person entity whose population is made up entirely differently, and when I was a Microsoftie I was on a 4-person MS Puzzle Safari team. Seattle has its own Venn diagram of puzzle communities.
  • Rich Bragg: so why just The Game? I think the community today is the big thing [Bay Area Game + BANG + Seattle + etc] I almost feel--
    • Red: Is it, though? They serve very different expectations. Some people may go between them but I personally only play in Games.
    • Rich Bragg: I think a lot of people would consider a Shinteki a Game. [Yes] So you almost have to make a choice of where to contribute: if I contribute to that circle, am I excluded from that circle?
    • I have no answer for you.
  • Me: The MSPH is coming up. It's not the kind of event I like to play in--too many puzzles, not enough other stuff. So since I don't want to play in it, I volunteered to help run it. Maybe there's enough overlap of interest so that people will remember that I helped do that.


So... how to choose teams? I'm DIY-minded enough to think: Yes, you should consider whether a team has run events lately. If a team's members play a lot but never run events, pass them over for newcomers.

But... you know how Red mentioned "crossover" from other communities into The Game community? I'm one of those "crossover" people. So, as you might guess, I hope when you're tally up events a team has run--I don't think you just count The Game events. I'm biased that way by preference... but of course you should also take what I say with a grain of salt--I'm probably biased that way out of self-interest, too.

And yet... and yet...

Even if The Game were the only thing I cared about, I'd still check for BANGs on a team's resume. Desert Taxi, XX-Rated, coed astronomy: they ran Games; I think they ran BANGs first? (Probably other teams did, too; those were just the first that sprang to mind.) Some folks are happy to just consume. Some folks create. You probably want the creative folks to be "in your neighborhood" even if they're not making exactly what you want.

So what should count? If you're a Bay Area puzzle freak, how much do you care about Mooncurser's? Does Shinteki count, if they're both a Game-like thing and a business that lets in just anybody? What about someone helped run the Microsoft Intern game? What about the guy who lives in Emeryville who runs treasure hunts for his kids for birthday parties? Me, I would count Mooncurser's and Shinteki. I'd probably not count the intern game, not Emeryville... I'm not sure why I wouldn't count those. Maybe because I wasn't invited to those events. But... maybe they'd count for something--because someone who ran such a thing might be tricked into other events later. Oh man, Thomas Snyder wrote a book of sudoku puzzles. How should that count? I mean, I was "invited" to it. I could go buy the book. On the other hand, it's not exactly a hunt. On the other hand, he's obviously of the mindset to make stuff. On the other hand...

There's going to be judgement calls. It's not going to be 100% fair. Not everyone on your GC committee will agree on what the criteria are. It would be easier and more straightforward to make your game first-come-first-served.

But you know? Red is right. Oh, I quibble on details; I would count "karma" from related-but-not-quite-what-I-had-in-mind events. But that's a quibble. It's a good idea to show appreciation for folks who run games, especially if you want to trick more folks into doing it. Slots in Games are darned precious; they're a great way to show appreciation.

When you ask teams to include a resume with their application, you remind them that running a game is important, that you care about it.

Oh yeah, and: Run More Games.


Labels: , ,

Book Report: Notes from a Broad

I bought this book because its author is "Fran Lebowitz". This is not the same Fran Lebowitz who wrote the excellent Metropolitan Life and Social Studies. Rather, this is the "Fran Lebowitz" who usually calls herself Fran Rittman but whose maiden name was nevertheless on the cover of this book. Rittman is from New York, she smokes, she's a literary agent. The real Fran Lebowitz is from New York, smokes. I could kind of convince myself that maybe the real Fran Lebowitz became a literary agent. Rittman is a fitness nut, likes to run. The real Fran Lebowitz said that running was something one does to catch the bus. But she said that years ago, and I could convince myself that she'd changed her mind meanwhile. So I kept reading this book, hoping that it was written by Fran Lebowitz. You know, the real Fran Lebowitz. But the details kept on not fitting...

Fran Rittman wrote a memoir of being an ex-pat in Singapore. It was most interesting when I was interpreting it is the memoir of Fran Lebowitz having gone through many major life changes. That was especially interesting because I kept having to stretch further and further to make things fit. But once I admitted that things weren't fitting--that Rittman and the real Lebowitz were two separate people--this book was kinda dull.

Labels: , ,

Link: How to stop leaking private info each time a FB friend takes a personality quiz

A while back, I started looking at FB app coding, and was thusly creeped out. When someone writes a Facebook app, e.g., one of those What sandwich condiment are you?!? quizzes, they can tell that app to get information about the person who runs it--and about that person's friends. When the person runs the application, a screen comes up asking for permission to look at a bunch of stuff, including their friends' data. I.e., it shows one of those permissions screens that nobody bothers to read anymore. When the program runs, it "sends home" information about your friend--and information about all of your friend's friends. Thus, the personality quiz's writers get to see your FB data, just because your friend ran their app.

Each time you see something in your FB news feed saying "Your friend Joe is Miracle Whip! Take the What sandwich condiment are you?!? quiz." you can cringe a little--your friend Joe just gave away your Facebook information so he could find out what kind of condiment he was.

You don't want to freak out too much about this; for some applications, it's totally worth it to share this kind of information. But I don't want to give out my information to any bozo who throws together a personality quiz.

So I was pretty glad to see this article Quiz: What Do Facebook Quizzes Know About You?, even though it leans towards the privacy-freak end of the spectrum. Mostly, I was glad to find out about FB settings I can use to keep friends' apps from seeing this info even though I have a few friends who are enthusiastic personality testers. I didn't know about those settings before.

I will cringe less often in the future.

Labels: ,

Book Report: Slack

Today I was that guy on the bus who wears too much scent. Not my fault! An automatic air freshener squirted me. Now I know why "fresh" can mean "offensive". I am very fresh right now, in that sense. Not like the "fresh" in "fresh content". That means "recent". Or as the cool kids call it these days, "real time". As of 7:33pm PDT 2009.08.18 I still smell like a stack of urinal mints, which means that this news is in "real time". This news is as fresh as I smell. You might even be reading it sooner than you would expect. Maybe. Depending on how often you check this stuff.

Blogger (the service which runs this here blog and many others) announced pubsubhubbub support. This means that after I post one of these blog posts, lots of services can find out really quickly. (Well, they could do that before, but it would have involved checking my website really often, which would have been silly, because I don't update that often. But now those services that want to check for recent updates can use one "hub" to keep up with many many web sites. So they can be really fast.) But I can keep writing really slow. Though with all of this "real time" stuff going on, I have to remind myself to maintain slack. That's right, I remembered the topic of this blog post. This is a book report, and it is on Slack. Not as in the stark fist of "Bob". I mean the book about managing software projects.

Slack takes a common-sense view, arguing against various software-development snake oil schemes. It was written back in 2001... so I'm reading it kind of late. I'm not keeping up with the literature in "real time," you see. So, I read about old snake oil. Some of that snake oil is still around, but it uses a different vocabulary now. Folks no longer strive for Quality. (That's Quality with a capital Q.) They do still pour effort into optimizing things that don't need optimizing, using this as an excuse to ignore harder problems. But they don't call that Quality anymore. And since they're looking for excuses to ignore common sense, they'll probably ignore the advice of this book. Oh, what? What's the advice? OK.

Don't work too hard all the time--you'll burn out. Besides, if you need to sprint for a while, you won't be able to speed up if you were already sprinting.

Make middle managers talk to each other, not just to their underlings and overlings. The underlings in group A and the underlings in group B might not be so great at talking to each other. It's good if their managers can talk every so often just to exchange ideas and news.

Oh, there's more but you're probably bored. It's all such sensible advice. Not like the snake oil. Snake oil is exciting, in much the same way that it's exciting to get squirted by an automatic air freshener.

Oh man I hope this stuff washes off.

Labels: , ,

Google & OpenID: discovery URL

A while back, I mentioned that Google supported Opendid. There's one important detail that I had a hard time finding amidst the mountains of documentation:

If the user wants to use their Google account to log in via OpenID, the discovery url is

That was hard to find. I think it took me over an hour. It's mentioned on the Federated Login for Google Account Users page... halfway down... under a diagram showing the back-and-forth of redirects which I didn't especially care about because of course my code has to handle those already for all of the other OpenID redirections. And with plenty of mentions of OAuth, just to further convince me that I must be looking at the wrong page, and wander off to look at other places.

It took me just a few minutes to find out Yahoo!'s OpenID discovery URL. Some Yahoo! technical writer deserves a bonus.

(Yeah, yeah, I saw the blog post about webfinger and how it will automagically discover discovery URLs and we'll all be sitting down at lovely unicorn tea parties forever. But maybe instead of waiting for that, I'll just let people log in via their Yahoo or Google account, and that's probably gonna handle all of my users just fine, thank you.)

Labels: , ,

Book Report: Spin Control

This book is a novel. This book is about human evolution. No, wait, this book is about the evolution of society. No, wait, this book is about changes in society post-singularity. No, wait, this book is about the annihilation of society post-human. No, wait, this book is about the futility of consensus-based decision-making. No, wait, this book is a speculation on the paranoia of a eugenics-based society. No, wait, this book is a book about humans partially told from the point of view of an artificial intelligence. No, wait, this book is a spy thriller. No, wait,... this book is science fiction, but it dances around in many areas. It's a fun read, where by "fun" I mean bleak, cynical, yet interesting.

Labels: ,

50 Bands Meme

OK, here are the rules. Test your memory and your love of live music by listing 50 artists or bands (or as many as you can remember) you've seen in concert. List the first 50 acts that come into your head. An act you saw at a festival and opening acts count, but only if you can't think of 50 other artists. Oh, and list the first concert you ever saw (you can remember that, can’t you)?

[Facebook-specific memetic propogation instructions omitted]

  1. Tom Petty & the Heartbreakers (first concert). Oh wait, he was just the opening band... so: Bob Dylan (first concert, ctd). Who came up with the rules to this meme such that Tom Petty doesn't even count? He was kind of a big deal. Anyhow.
  2. Sandpit
  3. Sangano
  4. Tokyo Ska Paradise Orchestra
  5. Dead Milkmen
  6. Billy Bragg et al
  7. Red Hot Chili Peppers
  8. Carmaig De Forest... uhm... more than once... maybe an opening act each time? Uhm... uhm... 少年ナイフ (that's "Shonen Kife", you uncultured swine)
  9. Bush (in St Louis)
  10. Violent Femmes (in San Francisco and later at Hahvahd)
  11. Wesley Willis... oh I'm sure he was an opening band. OK, uhm, Robyn Hitchcock and perhaps the Egyptians?
  12. Primus
  13. Oranj Symphonette
  14. The Wells
  15. Agent Orange. I saw them a couple of times, I think? Were they an opener each time? Uhm, I can tell this "opening bands doesn't count" thing is going to be a problem. Uhm, Explosions in the Sky.
  16. Whipped, I think? Or had the band moved to LA before they ever played a real concert? Erm? Whatever: Veruca Salt.
  17. Flower SF ... except maybe they were opening for another band... but I'm pretty sure I was there to see Flower... Uhm, Yes. I saw the band called "Yes" at the Oakland Colliseum
  18. The Fabulous Hedgehogs
  19. Some band that had Tanya Donnelly in it? Maybe? Like Throwing Muses or Belly maybe? Aw... I don't remember. OK, I'm sure I saw Talkdemonic and they were awesome.
  20. Aggressive Dog (and/or Bandit) (Maybe. Hey, give me a break, it was all in Japanese at some little Tokyo Club (confusingly called "New York Antiknock") with unclear signage)
  21. Quasi
  22. Sleater-Kinney
  23. Blüchunks
  24. The Sugarcubes
  25. The Cure
  26. Spiritualized
  27. The Verve except I think when I saw them they were an opening band, but I think maybe the whole reason I went to the show was for the Verve? Like the Opening Band was some flash-in-the-pan MTV thing? Can I count The Verve? No? OK, uhm, Southern Culture on the Skids.
  28. Radiohead
  29. Black Moth Super Rainbow
  30. TV on the Radio
  31. The Hellbillys... aw, did they headline? Or were they an opening band for... for... Aw... OK, cerntainly a headliner: David Byrne with the Extra Action Marching Mand et al.
  32. Fugazi
  33. Ozric Tentacles (which shouldn't count since they were the opening band, but I didn't stick around for the headliner past a couple of songs)
  34. Voodoo Glow Skulls
  35. Spearhead. When I saw them and Ani DiFranco at that same show, who opened for whom? Uhm... I don't remember. Have I ever seen Spearhead in some other context? Uhm... I don't remember. OK, pretend I never said Spearhead. I said... Holy Fuck.
  36. Ladytron
  37. My Bloody Valentine
  38. L7... were they headliners? I didn't know there was gonna be a test. Uhm, They Might be Giants
  39. Dengue Fever
  40. Frente, I think? Maybe at Justin Herman Plaza? Does that even make sense? Maybe I just dreamed it. OK, I'm sure I saw M.I.R.V.
  41. Cracker, an opening band surely, uhm how about Ween? They headlined a show I'm sure yeah
  42. Man... or Astro-Man?
  43. Ani DiFranco et al. I'm sure I've seen a show where she headlined.
  44. Skankin Pickle... or maybe they opened for Voodoo Glow Skulls? Did I ever see Skankin Pickle headline? uhm, Stereolab.
  45. Charlie Hunter et al
  46. Laurie Anderson. or was it just her? Is Laurie Anderson a "band"? OK, then the House Jacks (yes, NPL freaks, that's an old one of Murdoch's projects before he was Kid Beyond).
  47. The Quails a bunch but maybe they were always an opening band? Maybe? $&#* let's just say Barenaked Ladies but you know I didn't much listen to the music at that show, just mostly lay back and looked at the night sky.
  48. 7 Year Bitch
  49. Sonic Youth
  50. Neko Case and I think maybe Carolyn Marks was there too et al

Well that got messy. If you read to the bottom of this because you were interested, then you can consider yourself "tagged" with this meme. If not, hey, how are you even seeing this?

Labels: ,

Book Report: I Wish there was Something that I Could Quit

It's a novel by Aaron Cometbus! I hadn't heard it had been published until I entered a bunch of book ratings into's recommendation engine recommended the book. Three cheers for recommendation engines. If you like Cometbus, you'll probably like this novel. If you don't know about Cometbus, this would be a difficult beginning.

Maybe I was fooled by the title, but this seems to be a story of people who have given things up. There is a straight-edge bartender. There is Aaron the musician known for touring whose favorite moments are when the band van breaks down. Characters break up relationships carefully, trying to improve themselves (and then thoughtlessly fall into other relationships). This makes for some fun musing, but this isn't really a book in which stuff happens.

There's stuff you do which you'd be better off not doing. Quit doing that for a little while and read this book instead. It will be so very appropriate.

Labels: , ,

Link: Stuart Landsborough's Puzzling World

Puzzling World is a tourist destination in New Zealand. It started out as a big maze for people to wander around in. Then they added some strange attractions. Some of the ad copy worries me, though.

Because [the] Maze had been created using wooden fences, Stuart became the first person in the world to be able to thoroughly understand the psychology of mazes and therefore continue to change and improve the design.

Wow, all of those people who grew hedge mazes must be gnashing their teeth now. "If only I'd used wooden fences, then I would understand the psychology of mazes!"

Labels: ,

Book Report: Alphabet Juice

This book is a sort of lexicon, except that instead of definitions there are riffs. These are some of the author's favorite words, or at least words that he wanted to write about. He likes to pronounce words, and reflects on words whose pronounciation seems to reflect their meaning.

This sounds like a self-indulgent book, but Roy Blount Jr wrote it, and it so happens that I am curious to know what Blount thinks about word sounds because he has a better writer's ear than I do. I care what he has to say about these words. He also writes about letters. He writes convincingly and charmingly about these words. Here's an example:

agenda Why is this a perjorative term? What's wrong with having an agenda? I wish to hell I had more of one. (Is that good English? "More of one?" I think it is, but it doesn't look printworthy.) Politicians play on the word's souding sort of dirty, like ...pudenda?

It comes from the Latin plural for "things to be done," but in English, it's singular.

He has some agendas himself. He just wishes you'd stop misusing just. He wishes you used literally to mean what it literally means. He argues his cases well. He's so convincing that he almost got me putting the hyphen back in e-mail before I realized what was happening. Keep your wits about you.

He cites dictionaries, friends, Yogi Berra, The book, published in 2008, is already dated. He claims he googled [cancan "no panties"] and got no results. Today, there are about 150 though most of them, as you might expect, are not very interesting results, automatically-generated nonsense "dancing girls cancan no panties florida's top ten attractions" yeah whatever. He's aware of this advance of information. In the entry for "Google", he wonders "Has Google rounded up a googol of data bits yet? Depends on when you read this." (But he's exaggerating--there aren't a googol particles in the universe; storing a googol bits is thus technically difficult.) Blount is modern, of course. He outs himself as an UrbanDictionary contributor. (He has a feed, you can subscribe to it.)

(I should also point out: this book can go on for several paragraphs without mentioning pudenda or panties or a lack of panties. The book's not filthy. But it doesn't tiptoe around the dirt, either. That's a good thing--when this book says that the "buck" in "the buck stops here" doesn't refer to filthy bribe money, I believe it.)

So what you have here is a series of short essays in alphabetical order. Belles lettres? Sure. Great words, great words... "mnemonic" "Moebius statement" "monkeys". If you love words, this can be a slow book to read. Swann had his cookie; but words have associations, too. You can get lost in nostalgia. Like the entry for tallywacker. It's not enough to read Blount's opinion. I had to dig through my old comic books until I found issue #3 of "When My Brother Was God" so I could re-experience this quote, this rant by a dorm resident annoyed at what she hears through thin walls: "Mommy raised me a nice girl; I didn't go to twelve years of Catholic school simply to shout Jesus Christ his talleywhacker [sic] must be ripping out her esophagus at random intervals, oh no." The entries for tmesis and zeugma--each left me giddy. He mentions Morse (in the entry for wrought, and has entries for dash and dot.

He's not familiar with software development. He doesn't understand our sense of recursion, though he understands that he has used it to excess. (But, in his defense, who hasn't?) He mentions that weevil comes from the same root as "wave", which might suggest a naming convention to folks working on a certain software project but maybe it's a bit late to point it out. He has an entry for truthiness. I was talking with Matt L. at work about software development, about the demo that looks good, but has rickety underpinnings. Matt coined a term that needed coining, the software-scheduling equivalent of truthiness: done-iness. I guess my point is that we can't expect Blount to take care of everything for us.

But he does plenty. This book is a fun read; check it out.

Labels: , ,

Link: Deny you ever read about Crypto Strikes Back in this blog post

In theory, I'm hobbyishly working on a little programming project. In practice, I make almost no progress on it. I'm almost never home and awake and alert enough to code. The bad news is: not much progress. The good news is: I can make a mental note like "I should find an API for a cryptographically-secure random function in Python" and I don't really need to research it. (Note to self: random.SystemRandom) I just need to keep that in mind and a couple of weeks later, I'll watch a video of a tech talk which mentions the info I want. Normally, you might think that two weeks for "research" of one factlet would be too slow. But it didn't slow me down. It's not like I would have made progress. It was like, no-cost research, anemone-style.

Here's the talk: Crypto Strikes Back, by Nate Lawson.

Oh yeah, and you should totally ignore what I said about crytographically-whatever Python functions and watching that video because in that same video he also says that if someone says they researched crypto by reading a blog post, that's a warning sign of bad crypto. You totally didn't want to read this far. Look, you still have plausible deniability. Go drink gin until you've totally forgot that you read this right now or else your crypto will suffer.

Yeah, if anyone asks, you never read this blog post, and you would never study crypto by reading blog posts. (I, for one, am much too 'leet for that because I study crypto on YouTube.) YOU WERE NEVER HERE! WE NEVER HAD THIS CONVERSATION!

I will now go straight to bed and forget I ever wrote this.

Labels: , ,

Book Report: Knowledge Sharing in Software Development

I was in meetings most of this last week at work. Meanwhile, one of my co-workers was learning a new style of programming--and thus was trying to learn about four big new things at once. She sent me emails, but I was slow to answer; I was in meetings. Days passed; she could read documentation, she was a quick study, she was learning a lot... but wasn't learning the things that would help her, you know, get started doing stuff. Before you know how to get started, you're not sure which things to study to get you started. On Friday afternoon, I sat with this one co-worker. I didn't tell her much--but I steered her at what she needed to get started. Soon afterwards, she was set up with her development environment, had a "hello world" going, was ready to apply some of that stuff she'd read about. Such a difference. Face time speeds things up. Except, of course, that it won't help the next person who wants to learn those four big new things.

How do computer programmers learn? Though it pains this professional tech writer to say it--they don't learn much from documentation. There's gossip, but that only gets you so far. There are so many different kinds of things to learn: general tradecraft, programming languages, project-specific knowledge... The project-specific stuff is especially tough to learn, because you're probably rewriting your project's code all of the time, pulling the rug out from under your own feet. In Knowledge Sharing in Software Development the author, Jan Chong, studied two teams of developers organized in two different styles to watch how job-knowledge flowed within each group.

(Yes, puzzle huntists, that Jan Chong. No, I probably wouldn't have heard about it if she wasn't a puzzle huntist.)

One of the groups followed the Extreme Programming cult, the others were Waterfa-- Hey, come back! This is not a Book on $foo about how $foo is better than the Waterfall strawman.

This book is Jane Goodall among the Geeks. Except that the author is a geek herself, and understands what's going on a lot better than Jane Goodall understands chimps. So when she took notes, she didn't say "Vocalizes technical knowledge, wish I could understand it." She said, "Desire to project technical competence." Oh yeah, how many times have you been stuck in that conversation.

The book doesn't start out seeming useful. It starts out in full-on academic mode. No sentence escapes without citing a couple of sources.

"Work has changed significantly over the past fifty years, moving from a workforce predominantly based on manual labor to one that is increasingly based on knowledge work (Drucker 1993; Elliasson 1996)."
It's not just that, as an academic, one has to cite sources to back up a statement like that. It's that one has to state a statement like that in the first place or risk getting questioned on it by some professor type who doesn't even know what it's like to work for a living these days. Halfway down page 2 of this, I nearly gave up. But I riffled ahead and saw
The Waterfall programmers also invited me to several team-wide social events in the course of observations, including periodic board and card game nights (e.g., playing Robo Rally, Chez Geek, Guillotine)...

Well that was more accessible. And I couldn't help but notice that the list of games didn't say "Robo Rally (Garfield, 1994), Chez Geek (Darbro, 1999), Guillotine (Peterson, 1998)" So, OK, first few pages have plenty of citations to remind the committee that a sufficiency of past reading has gone into the work. But you don't really need to slog through much of that to get to the real work. And there's good stuff in here.

The book describes the behavior of two groups of programmers. One group is a team of Extreme Programmers--they pair-program, forming new pairs each day, all sitting in one big work area where everybody can hear everybody. One group is a team Waterfall programmers, each sitting in an office with a door, where every bit of intra-team communication requires effort. The book looks a lot at the social networks that formed. But that's not what I focused on.

I focused on this snippet about the XP programmers:

...the practice of pair programming made visible the process of reasoning inherent in code construction, a process normally only available through post hoc accounts and code inspection. Through pair programming, the process was made available in situ.

They developed code faster because they all looked at the same code. They rotated between areas of the code. No one was the "datastore expert" or the "security expert" or the whatever expert--they all wrestled with all parts from time to time. They didn't need to comment or document their code so much--because they could talk it over with each other.

They produced code with little documentation. Like most code, it didn't make much sense--but if one of them didn't understand it, they could always ask someone else on the team. Then again, if someone who wasn't on the team didn't understand it... that person would have been out of luck. The XP programmers were happy to be oral, because they didn't need to slow down to explain things. But heaven help you if you wanted to understand their code and you weren't on the team. The XP team checked email once a day; didn't answer their phones. They spent time with the team, no distractions... from, say, the people who were stuck maintaining the code the XP programmers had previously developed.

...on the XP team, specific program code changes were actually quite opaque outside of a given pair.

Yeah, I bet.

So... the good news is that the XP team developed code very quickly by working all day, ignoring the outside world, and not trying to make their code understandable outside of the team. The bad news is that they ended up with some semi-understandable code. By working in pairs, they made sure their knowledge was distributed between their brains but that also made them less likely to capture their knowledge where someone else could read it.

Of course, most of the time that the Waterfall team puts into recording knowledge is wasted. You re-write code so many times over the course of a project, it's a waste of time to explain how any of it works--until you're ready to share it with somebody else. They track so much crap, most of which won't help future maintainers.

What would be the best of both worlds? How do you get the team to work together well, but make sure that they explain their work before they hand it over to the outside world? You almost want to set up an XP team--and then geographically split them up in the last few weeks of the project, force them to clarify things, nudge them to capture the knowledge that they use to clarify the code to each other. Just remember: that explanation you emailed to your co-worker probably also makes a dandy code comment. And the very fact that one co-worker needed that email suggests that patch of code isn't as self-explanatory as you hoped.

(Yes, training-minded co-workers, I have this book at my desk and you can borrow it.)

Labels: , ,

home |