The Fugue

This is a casual review of the seventh Harry Potter book, and to a lesser extent the entire series. Spoilers herein, so don't follow that "read more..." link unless you've read it.

First I'll say that I have enjoyed reading the books and watching the movies. They're good entertainment. I remember as a kid reading some childrens books about (good) witches and wizards at school—basically the same premise as this series. I don't remember what they were other than the protagonist was a little witch with chronic bad hair or something. (Gee, no matter what I do I can't seem to describe this without implying that Rowling lifted the idea, which even if she had doesn't reduce the originality or legitimacy of the Potter series in my eyes). It was and still is a wonderful premise. I think that I like the premise so much because what I love in a story more than anything else is new and complicated familiarity. Magic school: new. How the magic world and the real world coexist: complicated. School kids with normal school kid problems: familiar. Oh, and I'm a sucker for anything British.

On the other hand, there were a number of things about the Potter series in general that just did not work for me. I found the constant abuse of literary devices tiring, annoying, even insulting. Snape good, Snape bad (but over the entire series the Snape line was excellent). Lupin bad, Lupin good. Sirius bad, Sirius good. Perhaps the most sickening instance of this is the shrieking shack scene where Sirius and Lupin are talking about Pettigrew but Harry thinks they're talking about them. This is not how people do things—even people as distracted as Sirius and Lupin were are not going to say things that sound so blatantly threatening to Harry in front of his face without at least mentioning in passing "Oh by the way, Harry, we're not talking about you. We'll explain later." This came off particularly badly in the movie. I do not like my chain being yanked for emotional effect. I like emotional responses that are earned. That's my biggest beef with the whole series.

That said, I can happily report that chain-yanking has been kept to an absolute minimum in this book. Although there are several reversals, there is very little chain-yanking. Reversal itself is not to be abhored, just its abuse. The one exception is some gratuitous killing. I accept that fighting evil can have casualties, and not every agreeable character can or should survive. But I think the members of the Order would be more likely to survive in an all-out battle situation like we had in this book, yet many die. Disproportionately many, I think. But really, I'm just mad that Fred had to go, probably because the Weasleys, and Fred and George in particular, are my absolute favorite characters, and killing Fred is in essence killing both Fred and George. George goes on alone (and monophonic), but he would have to completely reinvent himself without his twin. Had he died doing something important, or even something characteristically Weasley, it might have been ok. But he just keels over in impersonal crossfire, and you know that it's just Rowling yanking chains again. That's not the kind of emotional response you want—you don't want your readers blaming you for killing off their favorite character; you want them mad at the villains for doing it.

Now you know what I like and don't like about the series in general. I found this book to be a very good read. I missed Hogwarts and the other children and teachers, and seeing them in battle at the end did little to assuage that. But I can't really kid myself into thinking Harry could go to Hogwarts and be safe, so it's fine. Ron leaving was silly, doubly so when the chain was yanked that he'd have come back right away if it hadn't been for those pesky bounty hunters. Harry wasn't as insanely stupid as he has been in the past, though there was a bit of that with the attempted chain yanking about Dumbledore. The whole Dumbledore thing was interesting, in spite of knowing she was trying to yank Harry's chain, if not our own. Character depth and motivation can be very interesting, and it's nice to see some more depth to Dumbledore.

I might be cynical, and of course I recognize this is a children's book, but can we really be expected to believe that Ron and Hermione would be together 24/7 and sleeping in the same tent and never so much as tell the other his or her feelings for several months? I was glad to see them finally figure it out, and I know teenagers can be confusing and confused about that sort of thing, but in my experience if you throw any 2 teenage boys and a girl in a 24/7 alone situation for a few months, someone's going to fall in love (or get a crush, or whatever). Still, I felt it was handled well, with Ron implementing what he learned in the book and Hermione crying and being mad when he returned. Aside from the slow pace it was fully believable and a good culmination of the romance. Harry handled the Ginny situation pretty well, too. At the end of the last book his decision to cut it off felt dumb and pointless, but it made sense in this book (and could have been left for the birthday scene here, but she probably just couldn't resist yanking that chain at the end of book 6). I wish they would have wrapped it up at the end though. 19 years later, "Oh by the way they're married" doesn't have quite the same drama.

I still remember when I first realized that Star Wars was really about Anakin, not Luke (before the prequels). The whole thing instantly took on a new and deeper meaning, and it was thrilling. In a similar vein, this whole series may almost be as much about Snape as it is Harry and Riddle. The reversal in Chamber of Secrets where Snape was supposedly the bad guy but ends up being the good guy was dumb, but otherwise the complexity of Snape and never knowing what his motivations and loyalties were was very interesting. It all comes to a heroic and satisfying end in this book, and all in all I'm more pleased with the Snape storyline than any other. However I do wish we'd had more Snape exposure in this book. He, even more than Hogwarts and the kids, is just a backdrop. So much more could have been done with him, but as so much already had been in previous books, it's not so bad.

So there you have it. A few days after I finished reading it, and the most salient thoughts that come to mind are that I enjoyed it, I plan on reading the series again (probably with my kids), and she really shouldn't have killed Fred off.

Oh, and I almost forgot. I really despise the Americanization of these books. Next time I read them, we will have bought the original British edition.

I love Ruby, and I use it whenever I can for all kinds of tasks. When I was working as a professional system administrator, I put it to good use a few times there too. But using ruby always left me feeling a little guilty, because whoever came after me would probably curse my name for using a "nonstandard" language. It didn't help that Ruby was rarely installed, if even available, by the popular server distributions of the day. But all that has changed in the past two years, and using Ruby is often acceptable even in the conservative world of system administration.

You can imagine my interest then, in a book titled "Practical Ruby for System Administration" by André Ben Hamou. The title is telling; Ruby is known for being recommended by The Pragmatic Programmers because, well, it's a pragmatic language. System administration is all about pragmatism, above all else. Doing things right is important, but doing them now is more important. I knew all along that Ruby was an excellent tool for the enlightened sysadmin; now there's a book to back me up.

The book starts out with why you would want to use Ruby, and nips the counterarguments in the bud. Hamou does a good job on both counts, though as I already know Ruby I can't say whether the language introduction is sufficient of its own accord to get started with actually writing Ruby, or whether you'll need to refer to other sources (which are available online).

In chapter 2 he discusses one-liners. One-liners are the staple of many sysadmins, but I never fell for them. I'd rather write a throwaway script than try to cram it all on one line, or if it can really be done well on one line it can probably be done even more concisely with shell script and UNIX tools. However, the chapter does discuss a lot of fascinating switches that the ruby executable takes. I can see myself using many of these, and I was ignorant of most of them. You might learn the same from a careful study of the man page, but Hamou presents it in an easier-to-digest format. It's not always easy to inject humor into a book while maintaining concise brevity, but Hamou does a decent job of that. I found myself laughing aloud more than once, and yet I feel that the book is concise enough to serve as a reference, and that the jokes won't get annoying after a few readings of a section.

This book is not only a great book for the sysadmin hoping to use Ruby, but also an excellent book for any sysadmin who may not even be interested in Ruby. Although not even pretending to be a book on system administration best practices, there are many gems in here that will leave you saying "Why didn't I think of that?" and "I really need to implement that. It will be so helpful and it's astoundingly simple to do with Ruby!"

Chapter 3 gives you not only a quantitative feel for the speed of Ruby versus other performance-oriented languages (i.e. C), but it teaches you when to be concerned with execution speed, when to be concerned with implementation speed, and makes you think twice about your own feelings about performance. "Ruby is slow" is one of the favorite counterarguments against Ruby, but it's rarely a good one. This is even more true in system administration, where the sysadmin's time is much more important than whether the script runs in 1/10 second or 3 seconds.

Chapter 4 discusses "metaprogramming". I found myself at odds with Hamou most in this chapter, but it was all academic differences in terminology. He's fairly sloppy with the term metaprogramming and other terms (e.g. "macros") in this chapter, but the content is nonetheless a useful and vital part of making the most out of Ruby. I even learned a thing or two. He discusses domain-specific languages (DSLs) in Ruby, but mostly at the level of recognizing one when you see one. I think the world needs a paper or book on rapidly making your own DSLs, something sysadmins could really leverage if it were truly easy to do. I've written a DSL in Ruby, and while easier than I could possibly have imagined it's still not at the level of "easy and completely generic" that I feel DSLs can one day reach.

Chapter 5 is where the fun really begins. With the basics of the language under our belts we can really look at specific examples. This is where the book really shines, both as a tool for applying Ruby and as a minefield of good sysadmin practice. We learn to read and write files, with examples for the most common ones. I don't mean we discuss IO.open and IO.close in detail, I mean we talk about the concepts that apply across all kinds of file reading/parsing and generation, including issues of locking.

In chapter 6 we explore the storage and retreival of data, in a variety of approaches including inspect, marshalling, YAML, and ActiveRecord. Most interesting to me was the section on memcached. I think he ought to also have introduced SQLite (perhaps in the context of ActiveRecord) and DRb.

Chapter 7 is dedicated to dealing with "enterprise data". You know that of which we speak. XML, CSVs, protocols like XML-RPC, SOAP. Most valuable to me in this chapter was a coherent discussion of what REST is (finally!) and how to do it in Ruby.

Chapter 8 discusses network, including writing simple clients and servers. One tendency Hamou has in this book is to use pure Ruby and steer clear of system and backticks. This tendency sticks out in this chapter, where much time is spent discussing that which could be acheived better with a shell script, or at least a Ruby script with judicious use of system or backticks. The general argument for doing things in pure Ruby is portability, and to a lesser extent performance. Neither of these is the first concern of a sysadmin, who is generally not going to write a script that must work on more than one platform (even if it runs on several different Linux/UNIX distributions, which have the same GNU tools).

Chapter 9 deals with that task which we all hate: network and log monitoring. He has some gems of wisdom herein, but all in all we're left feeling about the same as when we went in: we can do it (now we can do it with Ruby) but it's a pain. The gains are not as great here as they are in other areas. This isn't Ruby's fault, nor Hamou's, it's just that nobody's really come up with a good and general way to attack this problem yet.

Chapter 10 discusses RubyGems. I think it's fitting that such a chapter be at the end of the book, and that's all I have to say about that today.

Chapter 11 discusses testing. You should do it in some form and he discusses a few forms. Nothing earth-shattering here, from where I sit. Chapter 12 talks about the future of Ruby, and will probably cause you to salivate.

All in all, an excellent book on using Ruby as a sysadmin. Go ahead, come out of the closet. Ruby is not only OK, it's often the best choice.

I finally got around to watching Elephants Dream. I have to say that I was not impressed.

Ok, I was impressed, very much, by "the machine". I was impressed by some of the surrealism.

But the person animation was basically terrible. The script (if you can call it that) was silly. The plot was nonexistent.

As a demo for "what blender can do", Elephants Dream is a great piece of work. As a completely random set of interesting surreal scenes, it's interesting. As a creative work, it flops.

Sometimes even the best of us can't avoid a chick flick. That's why it's important to pass it on when we find one worth watching.

There was nothing good in the theater (that we could agree on), so we went to the video store. Although I wanted to get Proof, my wife prevailed with Just Like Heaven.

What's to like about Just Like Heaven? Jon Heder, The Cure, Reese Witherspoon, Mark Ruffalo, a story that isn't lame, and Jon Heder.

The story is no Lord of the Rings, but it's fun and not inconsistent. Inconsistency is a plague of the silver screen these days, and it's nice to see an unblemished specimen.

Mark Ruffalo is refreshingly Not Tom Cruise. I was forced to watch 13 Going On 30 once, and he saved my sanity, so I owe him a debt of gratitude.

Reese Witherspoon is delightful as ever. I loved her in The Importance of Being Earnest (an even better chick flick), and I loved her here.

The closing titles roll to The Cure's song of the same name. I wasn't familiar with the song, but it's now on the list of "The Cure songs I really like." Some of the other music was deliciously alternative, too.

The real reason to get this film is Jon Heder (Napoleon Dynamite). This is his first flick since Napoleon Dynamite, and although his role is minor (IDIOTs), he's freakin' awesome.

So next time your S.O. wants to rent a chick flick, be proactive and pick up Just Like Heaven.

By Douglas Mauro, Kevin Schmidt
1st Edition July 2001
ISBN: 0-596-00020-0
326 pages, $39.95 US, $59.95 CA, £28.50 UK

All I knew about SNMP was that SNMP could tell you stuff about your network. That sounded like a cool thing, but every time I had tried to grok SNMP on the web, I had learned that the Simple Network Management Protocol is not Simple at all.

Then the auditor told us that SNMP was a security risk to our network, rattling of strange jibberish like "community strings," "public/private," and "mibs." So I curled up with Essential SNMP over a weekend and promptly became competent. This book will get you up to speed in SNMP in a jiffy. It is exactly what it claims to be—the essentials of SNMP. Those essentials are probably everything you need to know to start making SNMP work for you in your network.

This book is a little aged; it was published in 2001. (I'm writing this in mid-2005) Luckily, SNMP hasn't changed much since then. Most devices you will find in your existing network probably don't even support SNMPv3, and some probably only support SNMPv1. The book does explain all three versions well.

SNMP may not have changed much, but the tools have changed slightly. For example, none of the Net-SNMP examples will work with recent releases. However, the idea of what you can do is still important, and translating from the book's examples to current syntax is simple enough once you learn what has changed in syntax since 2001. (Hint: RTFM) There is a chapter on MRTG, which is useful, but if it were written today they might have chosen Cacti instead. I can only hope that OpenView has become more administrator-friendly since this book was written.

Book Organization

Chapters 1-3 cover the basics of SNMP. They are by far the most valuable chapters. By the time you finish them you should understand what SNMP is good for, what it can do for you, and why you need to be careful with SNMP devices on your network. Graciously, O'Reilly has put chapter 2—the meatiest chapter of this trio—online for all to read.

The remainder of the chapters go into great detail on how to configure your NMSes, agents, and everything else SNMP. The spotlighted NMSes are Net-SNMP, HP OpenView, and Castle Rock's SNMPc. Many other SNMP softwares are covered lightly in appropriate places. More importantly, I think, is that the nooks and crannies of SNMP itself are explored. You can learn how to grok MIBs, build your own MIBs and how to write your own agents or NMSes in Perl (with a spattering of examples). That chapter on MRTG also lies in this section.

The appendices cover various topics in more detail and provide a nice reference for things like which RFCs to read for more information.

You will consume this book quickly, because you will skim over much of the details in the latter portion of the book. Especially if you can't afford OpenView. When you're done, you'll go on a network management rampage, not resting until you've set up all the cool SNMP stuff you can find, e.g. Cacti, Net-SNMP, and whatever cool commercial NMS trial versions you can get your hands on. And you'll have fun doing it.