I finished this book on a plane from Boston to Minneapolis. It's a high-level book that's designed to give developers a good perspective on how to find and fix bugs in their code properly.

Frankly, I wish this book would be read by a lot of developers. It's not long - you can devour it in a couple of readings. It's not too detailed on the specifics of a programming language or environment - while Butcher uses some Java code examples it's not a requirement to understand Java to read the book. Butcher focus on how a developer should systematically root out where a bug is and how to remove it effectively. Debugging is not about firing up a debugger - in fact, that has very little to do with debugging. Developers need to ensure they've found the bug and that they have steps in place to ensure it doesn't come back again. I also learned a couple of new tricks as well (the in-memory logger is a nice one).

There's one section of the book, though, that really irked me. Butcher creates a Dispatcher class in Chapter 2 where he demonstrates the basics of logging. However, his catch block catches the general Exception type. Argh!! This is a bad programming practice that no development book should ever repeat, even in code in a book. I've repeatedly run into teams who do this and defend their choice because "they read it in a book". Ultimately we're all responsible for the choices we make in life, and if we write code we're responsible for what we send to the compiler. But having books show this as an example doesn't help. Catching the general exception type causes so many more problems than people think it solves - I hope Butcher fixes this in a future edition.

I should emphasize, though, that even with this irritation, I would not hesitate to recommend this book to other developers. I've been on teams where the developers are severely lacking in debugging analysis skills. This book may not fix that problem in its entirely, but it's a very good starting point.

I finished this book a week or so ago. It's a tale about a man who has become an expert at reinventing himself: he creates new names with complete backgrounds (and paperwork). Part of the reason is that he deals with unexpected debilitating headaches where he ends up overdosing on medication and has to weasel his way out of the psychiatric evaluations. Throughout the book, you learn more about his background and how he has learned to be a "contortionist" with his life.

I enjoyed this book. If you're a fan of "Fight Club" you'll probably like this book too. Clevenger has a similar style to Palahniuk - being very details and viseral at the same time. I'm not sure I liked the ending ... frankly, I'm not really sure what the hell happened (although I think I have a good guess). Clevenger has another book out called "Dermaphobia" which I've already picked up - I'm intrigued enough with "Handbook" to give another of Clevenger's works a go.

I finished all three book a while ago. I'm not going to bother with a synopsis - if you don't know what these books are about (actually, technically it is one book), then you either haven't read them yourself or you didn't see the movies. I read them 20 years ago in high school and I remember liking them, and I wanted to re-read them after the movies were out.

It was hard to read the dialog without imagining Elijah Wood doing Frodo or Ian McKellen doing Gandalf. I actually enjoyed getting that extra visual and I was amazed at how well Jackson brought these characters to life. I don't think all the characters translated well - i.e. Strider/Aragon in the book is different (although not significantly so) from Viggo's Aragon (although I liked his portrayal). Also, while the movies are faithful to the text and general storylines, there are changes. Either timelines are compressed (e.g. in the book Frodo doesn't leave the Shire for many years after Biblo leaves; in the movie he takes off right away), characters trade lines, storylines are deleted (Tom Bombadil and the scouring of the Shire are the big ones), etc. That's fine by me - there's just no way you could have movies faithfully recreate the story without having each one run about 20-30 hours in length (if not more).

Overall it was fun to read the books again. It is a good story, and while some of the dialog ran on a bit for my tastes, it's definitely one that any fan of fantasy should be required to read (as most fantasy books derive/rip off from Tolkien's material).

One of the talks I've been doing in recent months is called, "What Will Pex Do?" It's basically an overview of the Pex toolset - I demonstrate what it does and how you can use other frameworks that come with Pex to do interesting things (i.e. Moles). In the presentation I spend some time on a tool that I've been working on, and I've decided to put the project on CodePlex. It's called AutoPex.

So what is AutoPex? It's a way to automate Pex analysis. While it's interesting to right-click on a method in Visual Studio to see Pex go at it, Pex takes time to do the work it needs to do. So I thought, how could I make Pex do its magic in an offline way that provided meaning to a developer without having to wait for extended periods of time? That's what AutoPex does. It takes two versions of an assembly, and it looks for changes in public methods from the earlier version to the newer one. It does this by using the CCI framework to inspect the assemblies and parse method bodies (if needed). Once that list is obtained, AutoPex just shells out to pex.exe and it lets it take over from there. You can imagine this running on your build server as a special nightly build process. Since the generated method list only contains the "deltas", the resulting report every morning should be fairly easy to peruse - at least it would be smaller than having pex.exe process all of an assembly's public methods every night!

Right now AutoPex is truly a 0.1 version. I have no tests around it, and I know there needs to be a fair amount of tweaking, changes, and clean-up in the source code. Also, I need to play more with pex.exe's command-line options. Currently, once pex.exe is done, it opens the report in a web browser, so running this on a build server would cause a bunch of windows to pop up. It wouldn't freeze the build, but it would create clutter, so I want to see if there's a way to suppress that. Furthermore, I need to create a MSBuild task for this. All that said, if you're already diving into Pex, give AutoPex a drive and let me know what you think - thanks!

I finished both books a couple days ago. At this point, the rifters are living in Atlantis, a secret location at the bottom of the ocean, with some corpses to ride out the chaos and death spreading due to Lenie unleashing βehemoth into the wild. However, it's clear that βehemoth isn't all what it seems, nor is it the end of genetic manipulation in an attempt to either completely destroy or save the world.

The Rifters books are fun to read, but now that I'm done with the them ... I'm not really sure what to make of it. The ending is extremely open-ended, which is fine, but it makes me wonder if this world will ever be revisited b the author. The characters are not 1-dimensional so it's not always easy to determine who you should really be rooting for, if anyone. That's not a bad thing per-se - I actually like it. But that also forced me to keep attention, and while that's not a bad thing either, sometimes the plot lines got a bit confusing and it was hard to figure out who was really who (you'll know what I mean once you start getting into "Seppuku").

Overall the series was well-worth the time to read. It's hard sci-fi to read, both in material and in character development (along with some of the storylines - some things get really brutal).

My next set of books? A trilogy of books I haven't read in 20+ years: "The Lord of the Rings".

Yes, I'm going to Mix this year (thanks Magenic!). For the past 4 months, I've been on a WPF-based app, so I've learned more about XAML, but I haven't spent a lot of time in Silverlight. I really want to change that. I feel that Silverlight as a platform has a lot of potential (especially in the near future), and I need to get my head around that. The fact that the conference is in Las Vegas is just a nice bonus (really :) ).

If you're going to Mix, I hope to see you there!

My employer, Magenic, is putting on an event called Code Mastery. The first (of what might be many) will be in Boston on Feb. 11th. I'm giving two talks, "Writing Better Code" and "What Will Pex Do?". This event is free, but you need to register soon to get in. If you're in the area and you're a .NET developer, I hope to see you there!

I finished this book last night. Basically, Lenie Clarke is on a rampage, out to get ... well, pretty much everyone. Secrets and plans are convoluted and hidden throughout the book, but basically it comes down to one thing: stop βehemoth at all costs.

I didn't like this book as much as "Starfish", but it's still a great read. The secret motivations I felt got a little out of hand, but I've noticed Watts tends to explain stuff that he throws out there later on, so hopefully more will be revealed in the final two books. The hard sci-fi aspect I really like, although some of the technology I felt was a little far-fetched. I like that Watts adds some real-world details behind the concepts and terms he uses, and where he sometimes "places a bet" on something that doesn't quite pan out the way he wanted to (e.g. Ganzfield interrogation, which is based on the quantum mind model). Overall, I had a hard time putting this book down, and while I felt "Starfish" is stronger, I already have "βehemoth: β-Max" on my nightstand.