The second edition of Programming .NET Components by Juval Löwy was a decent book on .NET techniques, though I found myself unconvinced by much of his advice. In particular, Juval is a big fan of interface-based programming, but doesn’t spend much time explaining the “benefits of interface-based programming” (p. 50). I find myself happy to have left it behind with COM. But perhaps some of this advice works better in “enterprise” situations than it does in client applications?

In any case, most of the value for me with books like this comes from learning things I didn’t know before, so here’s my list of the highlights (and criticisms):

• p. 30: He seems to claim that the “global namespace” is really just a top-level namespace named “global”, but I don’t find that to be the case.
• p. 55: He talks about “programming defensively” by checking to see if an interface is supported by an object. “Never assume an object supports an interface.” This advice may hold well with interface-based programming, but when you’re programming with concrete types, it’s better to throw an exception if you expect an interface that isn’t there.
• p. 56: He doesn’t articulate the “advantages” of using interfaces on structs very well. In particular, he doesn’t mention that casting a struct to an interface causes it to be boxed, in which case you may as well be using a class instead of a struct.
• p. 96: Here’s something I didn’t know: «using (null)» is legal; it simply does nothing at the end of the using block.
• p. 98: He has his own “dispose pattern,” but doesn’t seem to know that there’s a standard dispose pattern (or should explain why he doesn’t use it).
• p. 111: A SolutionInfo.cs file that is shared among all projects of a solution is a great idea that we’re using in our solutions at the office.
• p. 143: “You should always publish [events] inside a try/catch block” that eats the exceptions. I tend to put that responsibility on the client; ignoring exceptions is never healthy in the long run.
• p. 149: System.ComponentModel.EventHandlerList is a handy way to support large numbers of events without storing an individual delegate for each of them.
• p. 181: I didn’t realize that the AsyncWaitHandle of an IAsyncResult may not be released until the handle is garbage collected. I don’t agree with his advice to explicitly close the AsyncWaitHandle, though, because AsyncWaitHandle is often lazy-loaded; if the handle hasn’t been created, you’ll create it just to close it. Better to just leave it alone; some IAsyncResult implementations are smart enough to close the handle automatically when you call EndXxx.
• p. 198: He advises against setting IsBackground to true on a Thread; I agree. “You shouldn’t count on .NET to kill your background threads for you.”
• p. 204: I learned about “synchronization domains” (which are nothing like “synchronization contexts”) and “context-bound objects” – it reminds me a lot of COM apartments. Maybe someday I’ll find a use for them.
• p. 215: He unfortunately encourages the generally discouraged practice of locking “this” for synchronizing instance members and locking “typeof(ThisClass)” for static methods.
• p. 250: He jumps through a lot of hoops to make sure that raising an event can’t throw a null reference exception; I had never considered the problem of possible inlining. A good reason to avoid thread-safe events altogether, but I’d definitely use the do-nothing delegate trick before using a MethodImpl attribute to suppress inlining.
• p. 255: I forget that “managed threads” aren’t guaranteed to be actual individual physical threads.
• p. 263: Events can use ISynchronizeInvoke to raise events on the proper thread for a client with thread affinity.
• p. 268: I had forgotten about the XxxAsync/XxxCompleted/CancelAsync pattern provided by web service proxy classes.

I stopped reading carefully at this point – the rest of the material escaped my interest. To conclude this review, I’ll not discourage you from reading the book, but there are lots of other .NET books that you should read first.

I’ve read many “how to program with WPF” books, and already have a year of programming experience in WPF, so I’m really not able to fairly review books like Programming WPF, by Chris Sells and Ian Griffiths, at least from a beginner’s point of view. This book is actually the second edition; I reviewed the first edition way back in October 17, 2005.

I’ll start with my conclusion – there is enough important material unique to this book that it is a must-have for the shelf of a WPF programmer. Despite its girth (835 pages), it isn’t able to explain every facet of WPF in detail – in particular, I noticed that the Border class was given very little reference. I was worried that I wouldn’t find much of anything I didn’t already know, but I was fortunately wrong on that account, and will close the review by summarizing the most interesting bits:

• p. 59: You can safely use data binding with Settings.
• p. 136: Explains how focus scope affects command routing.
• p. 189: Good information on validation, including custom validation.
• p. 226: Grouping with PropertyGroupDescription.
• p. 298: Handy table of the template parts used by each control.
• p. 336: The ValidateBindings method.
• p. 341: You can navigate a NavigationWindow to a string.
• p. 379: It’s dangerous to use types as resource keys.
• ch. 12: Great information on resources.
• p. 432: Working with bitmaps and bitmap effects.
• p. 484: Low-level text output.
• ch. 15: Outstanding information on printing.
• p. 672: Using attached properties to identify template placeholders.
• p. 730: Screenshots demonstrating airspace issues with interop.

Pro WPF, by Matthew MacDonald, is quite impressive both in its breadth and in its depth. This tome of nearly 1,000 pages describes seemingly every feature of WPF with enough detail to actually get something done. No book of this size is perfect, but the typos were rare enough to not be distracting, and the writing was easy to read and comprehend. Even the succession of chapters is logical enough to allow sequential reading through the book, despite the varied topics.

Even if you’re not of a mind to read the entire book cover to cover as I did, you’ll still want this book as a reference for topics that you won’t find discussed in the other WPF books, including how to build a custom view for a ListView, the many options for implementing printing in your application, how to create and use classes derived directly from Visual, etc. Highly recommended.

Dreaming in Code, by Scott Rosenberg, is an outstanding look at the software development process from the perspective of a well-funded medium-size open source project that has been in development since 2003. This book is compelling from beginning to end, trying to help even the non-technical reader understand why software development is so hard. The many difficulties faced by this development team were surprisingly (and sometimes disturbingly) familiar. Highly recommended for everyone in software, and anyone else who wants to understand our world a little bit better.

The Old New Thing, by Raymond Chen, is an entertaining and enlightening collection of articles about Windows technology. It is a must-read, particularly if you're not already an avid reader of his blog of the same name.

I must confess to skipping the 88 pages that comprise chapter 10, "The Inner Workings of the Dialog Manager." It has been nearly a decade since I assembled a classic Windows dialog box, so the subject simply doesn't hold my interest like it once would have. In fact, a lot of the information in this book would have been invaluable 10 years ago...

The most important chapter in this book is "Taxes," which is a great reminder of the little things that a software application should handle properly (fast user switching, high DPI displays, etc.).

The whole book (aside from chapter 10) is a great read. Even in the brave new world of the .NET Framework, WPF, etc., much of this information is still quite relevant. Highly recommended.

I enjoyed reading (and sometimes skimming) About Face 3: The Essentials of Interaction Design, by Alan Cooper, et al. It is full of “design principles,” all of which are neatly listed in the appendix, and most of which seem right on target. They serve as an excellent reminder of the things to be aiming at when designing a software product.

I must take some issue with the very first guideline, though – “Interaction design is not guesswork.” It is not purely guesswork, of course, but neither is it an exact science. Even with unlimited time, resources, and intelligence, I doubt that we could ever get everything “right,” if there is such a thing. Some of his examples of good interaction design are questionable, in my mind. But it is good to treat design as something that can be done right, if only to keep us from giving up altogether; we should do the best we can.

The content of Professional WPF Programming is too broad and too shallow, giving only a glimpse of various aspects of WPF and related technologies (Expression Blend, WCF, and .NET Security). If you are completely unfamiliar with these technologies, this book might give you a nice overview, but I don’t expect I’ll be picking this book up again.

Yet another excellent WPF book is Essential Windows Presentation Foundation by Chris Anderson. Having read a number of WPF books, and already having considerable experience on the platform, it is hard for me to judge how well the book would fare for beginners, but my instinct is that some concepts are introduced without much explanation, which might make things difficult for a newbie.

Being one of the architects of WPF gives Mr. Anderson’s words more authority than other WPF books; even better, he uses his inside knowledge to help us understand some of the deep concepts of WPF. Of course, I found myself wanting more – more depth on the subjects that he did cover, and more breadth to help with the subjects he didn’t cover. I highly recommend this book, though you might wait to read it until you’ve made it through those of Petzold and Nathan.

Considering how little information there is out there on WPF, it is no surprise that I eagerly read Windows Presentation Foundation Unleashed by Adam Nathan, especially considering how much I appreciated his previous book on .NET/COM interop. I was hoping for more depth and less breadth, but I think I'll have to wait for someone to write "WPF Internals" for that. Otherwise, this book was quite good; I especially enjoyed the full color code samples and screenshots. This book makes a good companion to Petzold's book, since it teaches different things and takes a different approach. I certainly recommend it to all WPF programmers.

It probably isn't really fair for me to review Why Software Sucks... and What You Can Do About It, by David Platt, since he's not writing this book for programmers, but rather for the users of our software. I didn't enjoy the book as much as I had hoped, partially because it's rather more crass than I would like. Still, the book gives good information -- consumers do need to be convinced that bad user interface isn't their fault, and they need to be encouraged to punish the bad and reward the good with their dollars and feedback.

I am eagerly reading everything I can about WPF, the new application framework from Microsoft, so I looked forward to receiving my copy of Foundations of WPF, by Laurence Moroney. Unfortunately, I was very disappointed in this short book of barely 300 pages. It is merely a brief introduction to WPF, especially considering that more than half of the content consists of trivial source code examples and huge grayscale screenshots. Top it off with the fact that the text was written well before WPF shipped and you'll find yourself much better off reading the other two WPF books again.

Just over three years ago, I wrote a review on the first edition of In Search of Stupidity, by Merrill R. Chapman. Fortunately, I remember few specifics from books that I’ve read in the past, so I was able to enjoy reading the second edition without much déjà vu. Like the first edition, this book is an entertaining (and brutal) look at the history of the high-tech industry. I enjoyed the newer material – it isn’t often that you read a printed book with events that occurred only a few months ago. The second edition also includes some explicit analysis near the end of the book. If his analyses don’t help you improve your high-tech business, fear of being featured in the third edition probably will.

Applications = Code + Markup is another outstanding programming book by Charles Petzold. This book is all about WPF (the Microsoft Windows Presentation Foundation), which is Microsoft’s next-generation API for building client applications on Windows.

I was all set to give this book a glowing review, but I was distracted by another project and wasn’t able to finish the book until recently. Fortunately, another reviewer beat me to it and said everything I was going to try to say:

http://blogs.msdn.com/karstenj/archive/2006/08/31/733708.aspx

What can I add to that? Be sure to check out chapter 32, an online chapter about 3-D in WPF. Petzold’s blog has other nuggests of WPF knowledge as well. Most importantly, check out the book’s Web site, which links to sample code, sample applications, and expertly maintained errata, to which I was happy to contribute.

My only complaint about the book would be the lack of section headings, though it certainly forces you to pay attention while you’re reading. Well, I could also complain that WPF could use another thirty chapters – we have a lot more to learn about this cool new technology.

I just finished skimming Pro C# 2005 and the .NET 2.0 Platform, Third Edition, by Andrew Troelsen. Since I didn’t read it properly, I can’t give it a fair review – I guess I’ve read one too many C# books. I didn’t notice anything too surprising, except for the chapter on developing dynamic assemblies with IL, at the end of which he apologizes for not having room to describe the more sane CodeDOM approach.

Overall, the breadth of this book is certainly impressive, but the depth is not there. A number of areas seemed to suffer from small misunderstandings. Furthermore, the attempt to include everything but the kitchen sink only makes more obvious the technologies that didn’t make the cut.

This book might be valuable for an experienced programmer that is approaching the C# world for the first time, but I’m afraid I didn’t find it very interesting.

I made it through the 1,210 pages of Pro ASP.NET 2.0 in C# 2005 (by Matthew MacDonald and Mario Szpuszta) without nearly as much skimming as I thought I’d have to do. This book provides amazing breadth and depth in its description of ASP.NET and related technologies. Not only was it an interesting read from start to finish, but it will also serve as an excellent reference in the future. I highly recommend it to any intermediate ASP.NET developers.

Of course, the book is not without problems. Aside from various errors in the source code, there were other noteworthy confusions:

• There is no static Page.IsPostBack method (page 78) or Page.FindControl method (page 88). The Control class has a Page property that can make it seem so.
• The examples should always HtmlEncode to underscore the importance of escaping HTML markup.
• They have a limited understanding of regular expressions, e.g. [\w| ]* should be [\w ]* (page 699).
• Integrated Windows Authentication can work with Firefox (page 755).

The book does not make the mistake of focusing on Visual Studio to the detriment of understanding the actual technologies, but the authors are sometimes a little too fond of it. I hope they will understand if there are some readers who “still write HTML pages by hand” (page 25) and who “need the HTML view” (page 32).

I took a few notes as I read, so here are a few of the interesting things that I learned:

• XHTML rendering can be disabled. (76)
• The ASP.NET Development Helper looks interesting. (100)
• HTML server controls support limited events (ServerClick, ServerChange) and don’t have to be inside a <form runat='server'>. (113, 119)
• HttpRuntime.UnloadAppDomain restarts the Web app. (153)
• global.asax supports lots of events. (156)
• Custom configuration sections can be defined in App_Code. (174)
• You can trim view state in a list control. (205)
• Static properties are preferred to application state. (225)
• $ expressions bind to app settings and connection strings. (298)
• aspnet_compiler can be used to precompile a Web app. (653)
• There’s a wizard interface for adding membership tables to a SQL database. (714)
• The login user controls can be fully customized with layout templates. (729)
• LoginView is interesting, and works with roles. (793)
• Custom control prefixes can be reused, and can be defined in web.config. (902)
• You can easily write your own templated controls! (930)
• Request validation can be disabled in web.config. (989)
• Web service method results can easily be cached. (1120)
• Exceptions raised from Web services are rethrown as SoapExceptions. (1139)
• Web service methods can be asynchronous “fire-and-forget.” (1185)

Programming Microsoft Windows Forms, by Charles Petzold, is a great book for programmers that want to learn about the cool new stuff in Windows Forms 2.0, but are already familiar with Windows development using the .NET Framework and C#. If you’re a complete newbie, you might want to start with the prequel to this book, the 1,200 page Programming Windows with C#, also by Petzold.

One of the best parts about this book is that it hardly talks about Visual Studio – it really is important to understand these libraries before you can effectively use the leaky abstractions of the Visual Studio designers.

The coolest new features of Windows Forms 2.0 are the dynamic layout features – automatic sizing, auto scaling, anchoring, docking, flow layout, table layout, etc. This book describes them nicely.

The descriptions of the controls were interesting, if brief, and without enough screenshots. I learned something about the LinkLabel control – I always assumed it implemented a label whose entire content had to be a single link, but it actually supports multiple links and text wrapping.

The ControlExplorer application is fun – you can install it via ClickOnce from http://www.charlespetzold.com/winforms/index.html. It allows you to play with all of the controls available with Windows Forms 2.0.

I also enjoyed reading about data binding. It isn’t as well done as the data binding support in WPF, but it looks usable.

In any case, if you are planning on writing a Windows Forms application with C# 2.0 any time soon, I recommend that you pick up this book.

Designing Interfaces, by Jenifer Tidwell, was an enjoyable book that gives names, descriptions, screenshots, and rationale for most of the user interface patterns that you have ever seen. It seems to be good reference material for designing a new user interface, and should help ensure that you aren't forgetting a useful pattern.

Write Portable Code: An Introduction to Developing Software for Multiple Platforms, by Brian Hook, is a short book with 18 short chapters describing the facets of computer hardware and software that can affect the portability of code. As the subtitle indicates, this is an “introduction” to writing portable code, so there are few specifics but lots of general information. This book should be useful if you have no experience in dealing with portable code, or if you are learning a low-level language like C or C++, where portability issues are more common than with high-level languages like C# or Ruby. Knowing about portability issues is important not only for writing portable code but for porting existing code to your platform, so I would recommend this book to anyone that doesn't already have experience in this area.

I didn’t enjoy Write Great Code (Volume II: Thinking Low-Level, Writing High-Level), by Randall Hyde, as much as I enjoyed Volume I. The material was mostly either stuff that I already knew, or more detail than I needed to know, or even things that I thought were incorrect.

Understanding the concepts presented in the book is useful for writing code that won’t be needlessly slow. However, the author spends hardly any time reminding the user that the sorts of optimizations that he’s talking about should only be considered when you have a performance problem, and after you’ve profiled your application and established that the area of code in question is the reason for that performance problem.

I probably should have paid more attention as he talked about the specifics of 80x86 assembly, but it just didn’t draw me in, and it is still rather rare that I find myself staring at assembly code for any reason.

All in all, the book is definitely a “low-level” kind of a book, and thus is less useful to a “high-level” programmer of one of the more modern languages. I can’t really evaluate the book from the perspective of someone who has never done any “low-level” programming (I cut my teeth on C, after all) – this book may be one of the few places where “low-level” information can be found at all these days.

I just finished reading Beautiful Evidence, by Edward Tufte, the fourth in his series on information presentation. I wrote a review of the first three books in the series early last year, but neglected to post it here, so I’ll start with that.

Edward R. Tufte has written three excellent books that describe how to effectively present information using graphical displays: The Visual Display of Quantitative Information, Envisioning Information, and Visual Explanations.
 
The Visual Display of Quantitative Information seeks excellence in statistical graphics. Simple tables can mask interesting qualities of large data sets, so graphics should be used to effectively communicate the ideas represented by the data. In fact, “graphical excellence gives to the viewer the greatest number of ideas in the shortest time with the least ink in the smallest space” – within reason, of course.
 
Is it also important to Tufte that graphics “tell the truth” about the data. It is easy – and common – to manipulate graphics in subtle ways to help prove an idea that the data doesn't necessarily support. He gives a number of guidelines to help maintain graphical integrity.
 
Envisioning Information aims to increase graphical excellence in charts and maps using the theories of his first book. The book consists mostly of examples of graphical excellence and Tufte’s explanations of what makes them so great.
 
Each chapter focuses on a different category of graphic. Micro/macro readings show patterns at a glance, and details when you look closely. Proper layering and separation is important to direct attention to the information. Small multiples show similar images on the same page for easy comparison. Color has great potential when used properly. Finally, combining a map and a time-series is a great way to show a narrative of space and time.
 
Visual Explanations is about using graphics to help explain complex processes. This book has a number of excellent examples of graphical presentations that had great success in communicating an important idea, as well as examples of poor presentations that were unable to do so – such as the recommendation to not launch the Challenger Space Shuttle in extremely cold weather.
 
All three books are fun to read and beautiful to look at. They provide challenging insights into what makes great informational graphics.

I also enjoyed reading Beautiful Evidence, but I didn’t find it as interesting as I had hoped. The material seemed too familiar. The book teaches the same fundamental concepts as his previous three books, and uses some of the same examples. Two of the chapters were adapted from previously published white papers, which I had already read. I also found the end of the book to be rather anticlimactic – the last chapters have to do with sculptures, which I unfortunately found uninteresting.

Still, if you’ve already read his first three books, you can hardly neglect his fourth. I certainly recommend the series as a whole – it is great food for thought.

Professional .NET 2.0 Generics, by Tod Golding, explains why generics are important to the .NET Framework, explains the differences between .NET generics and C++ templates, and describes how generics are used in C# and VB.NET. Unfortunately, after the first few chapters the book is often difficult to understand, provides incomplete explanations, gives some bad advice, and is occasionally incorrect.

Thus I can’t recommend this book, though it may still be helpful for those who need a basic introduction to generics, or to experienced developers that are looking for the occasional nuggets of interest. For example, I wasn’t certain that protected members were accessible among all “closed constructed types” of a generic class. I also hadn’t explored the ways in which ambiguities can arise with generic method overloads; specifically, I didn’t know that potentially ambiguous methods prevent VB.NET from even compiling a class, whereas C# will not fail until code attempts to call the ambiguous method.

I browsed through The Zen of CSS Design, by Dave Shea and Molly E. Holzschlag. It's a beautiful book that describes a number of the designs at http://www.csszengarden.com/. I learned a few things about CSS along the way, but I mostly learned to be glad that I'm not responsible for creating nice designs for multiple browsers using only CSS on semi-structured content. Even if I were a capable designer, it does not look like a fun task. I'm glad that there are people out there that can do it, though; the Web would be an uglier place without them.

CLR via C#, by Jeffrey Richter, provides thorough coverage of the core features of the .NET Framework 2.0. It is a great review of information that you’re already familiar with, and is certain to teach you some useful things that you didn’t already know. The book is very practical, and includes Richter’s often strong opinions on how to properly use the technology, and which parts of the framework to avoid entirely. I highly recommend this book to C# programmers, regardless of experience – I’ve read a number of books on the CLR, and this one held my interest throughout.

Head First Design Patterns, by Eric Freeman et al, was a nice change of pace from most technical books. The basic idea behind “Head First” books is to use lots of pages with pictures and diagrams and crazy fonts and humor and exercises to get the information to actually stick in your brain. This particular book takes that approach with the most important design patterns from the Gang of Four book.

This book was, at the very least, a good review of those patterns; I think it succeeded in helping me remember their names and uses. Specifically, the design patterns described are Strategy, Observer, Decorator, Factory Method, Abstract Factory, Singleton, Command, Adapter, Façade, Template Method, Iterator, Composite, State, Proxy, and Compound. The remaining Gang of Four patterns are each given two pages in the appendix. The many examples throughout the book are all in Java, but a C# developer should be able to follow along easily.

Despite my typographical issues with the book, I highly recommend it to anyone that wants to learn some of the fundamental design patterns in software development.

Professional .NET Framework 2.0, by Joe Duffy, contains 600 pages of mostly interesting information about the latest release of the .NET Framework. For the most part, the book covers topics to an appropriate depth; that is, it generally manages to finish a topic before I get tired of it.

It is difficult to review a book full of information about a technology that you are already experienced in, because you can’t properly evaluate how well the book would have taught you that information had you not already known it. My inclination is that this book would be fairly inaccessible to someone without reasonable experience in a previous release of the .NET Framework and/or the C# language.

The book could have used a bit more editing. I had a strong feeling of déjà vu while reading about anonymous delegates in chapter 14, so I looked back to chapter 2, where I found the pretty much the exact same text.

Still, the writing style is good, and I learned some things I hadn’t already learned from other sources, so I recommend this book to anyone that wants to fill some of the gaps in their knowledge of the .NET framework.

To truly appreciate The Elements of Typographic Style, by Robert Bringhurst, you should probably be a designer – someone who can speak the language of aesthetics and art and feeling, etc. A writer might also appreciate the book, particularly for its many tips on using typography properly on the printed page. Since I am neither designer nor writer, I’m not exactly the book’s primary audience, and thus didn’t end up enjoying it as much as I had hoped.

Even so, I made it through half the book before I began to skim. The author is clearly a man who is madly in love with typography and its impact on the written word. A left-brained brute like me can, to a degree, enjoy a well-styled page of prose. Hopefully, reading this book will have helped me recognize some of the key features of good typography. Like so many critics, I know what I don’t like, so I’m glad that there are people who can use the principles in this book to create designs that I don’t “don’t like”.

Update: Be sure to read Eli's comment, which eloquently explains how I managed to read the first half of the book. :-)

XAML in a Nutshell, by Lori A. MacVittie, is a “Desktop Quick Reference” for XAML, the XML language used by Windows Presentation Foundation. As such, it has minimal explanatory content, consisting primarily of short paragraphs documenting each of the elements and attributes supported by XAML.

The biggest problem with this book is that it is too early for a XAML reference book. The API has changed significantly since the book was written, though it was only released last month. Worse yet, I could find no significant errata or book updates on the Web, leaving me to regularly question the accuracy of the book as I read.

Neither was I impressed by the organization of the book, nor the formatting of the reference items, nor the infrequent and/or unnecessary and/or poorly documented screenshots, nor the lack of online sample code, nor the errors in the text, nor the missing topics (like namespace mapping), nor the lack of information about WPF, the core technology behind XAML.

In short, I cannot recommend this book. You’ll do much better with a copy of Programming Windows Presentation Foundation, the sample code and change notes on that book’s Web site, and the documentation that ships with the WPF beta.

Mastering Regular Expressions: Second Edition, by Jeffery E. F. Friedl, is an outstanding book about one of the most powerful weapons in a programmer’s arsenal. Any time you need to search or manipulate strings of text, regular expressions are the first tool that should come to your mind. Regular expressions are not only “the simplest thing that could possibly work,” but, crafted properly, they will probably be more efficient than any code you would write by hand.

This book teaches you not only the basics of regular expressions, but also their advanced features, how they work, why knowing how they work is important, and how to write regular expressions that will do what you want and exhibit the best performance. The book is very well written, very easy to read (except for some of the difficult material on optimizing expressions), and has a great mechanism for providing useful exercises that I’d love to find in more technical books. (The exercises are rare, but important, so you don’t mind trying to solve them. The question is asked in the main flow of the text, and followed by a special symbol. The answer to the exercise is in a sidebar on the next page, so you can’t easily cheat, and the symbol helps you find your place when you turn back.)

The first six chapters apply to all “flavors” of regular expressions, and thus are required reading for anyone who uses them, from the newest newbie to the most seasoned expert. The next three chapters are specifically about Perl, Java, and .NET, respectively. I must confess to having skipped the first two, since I am not currently using those technologies. The .NET section was good, and has the only reasonable explanation anywhere on how to use the cool “brace-matching” feature of .NET regular expressions. It also discusses the unique way that .NET regular expressions allow you to examine each capture of the same group, a feature that I have found very useful. Still, I wished for C# examples rather than VB.NET, and the chapter would have been better if the author had a more thorough understanding of the .NET framework.

If it isn’t already clear, this is an outstanding book that you must read. Regular expressions are incredibly powerful, and even if you already use them here and there, you need to start using them to their fullest potential.

Professional ASP.NET 2.0 provides a great overview of ASP.NET 2.0, even for someone with minimal ASP.NET programming experience. It is also reasonably well organized for a book written by five people. Here are some of the features I learned about:

• Encrypting Web.config sections (to hide connection strings, etc.)
• Easy support for user login and personalization
• Automatically building code in the App_Code directory
• Cross-page posting (supplies back-reference to previous Page object)
• Precompiling the Web application
• <asp:Literal Mode="Encode"> (for automatic HTML encoding)
• Focus method (sets the default focus for the Web page)
• AutoCompleteType (auto-complete support for edit boxes)
• OnClientClick event (easy support for client-side click handling)
• Lots of ways to do hyperlinks and/or images (Image, ImageButton, ImageMap, Hyperlink, etc.)
• Lots of ways to render simple lists (DropDownList, ListBox, BulletedList, etc.)
• <asp:Xml> (for easy XML transformation)
• Master pages (shared content for different pages on the same Web site)
• New binding syntax, including XPath binding
• HttpContext.Current.Items (for per-request storage)
• Using out-of-proc session state during development (to ensure that you can switch from in-proc if necessary)
• Post-cache substitution (minor additions to otherwise cached pages)
• WebPageTraceListener (sends normal trace messages through ASP.NET tracing)
• Debugger.Launch (to easily attach the debugger)
• System.Net.Mail (for easy e-mail support)
• RegisterClientScriptResource (for including .js files from an assembly)
• Adding information to Web service SOAP headers (e.g., user credentials)
• WebConfigurationManager.AppSettings (easy access to application settings)
• Class properties with public getter and more restricted setter

I really enjoyed reading The Wisdom of Crowds, by James Surowiecki. The premise of the book is that, under many circumstances, large groups of people make better decisions than a few experts. He argues that the group is even smarter than the smartest individual in the group, and provides many good examples. One of the first examples is the counting of jelly beans in a jar; the average of all of the guesses will be closer to the truth than the closest answer of any individual. Of course, everyone can think of examples where crowds (or committees) have made very poor decisions; the book describes the circumstances in which groups of people are smarter than individuals.

To make good decisions, a group needs diversity. A group can know as much as all of the individuals in the group put together. Different perspectives make it most likely that the best solution will be found, because diversity adds new information to the group. (This topic applies directly to hiring practices; by hiring people that are different than the people you already have, you're making the group even smarter, even if the new people aren't as skilled.)

Another requirement is independence. The best decisions are made by groups of people that aren't simply "following the leader." It is important that some members of the group "buck the trend," even if their opinions are wrong, not only because the "errors" can average out in the end, but because reserved people with good opinions are more likely to speak up if they see others doing so.

Decentralization feeds both diversity and independence; when people are spread out, they are more likely to come up with different solutions. The final key component is thus aggregation; you need a way to collect all of the solutions of all of the members of the group to generate the final answer.

How could I avoid reading a book whose title is our favorite mantra at the office? Of course, it’s usually used tongue-in-cheek when that’s exactly what we can’t do…

Ship It! A Practical Guide to Successful Software Projects is a “pragmatic” book by Jared Richardson and William Gwaltney Jr. It is an easy read with lots of great ideas for improving your software development team.

The book starts by describing the infrastructure necessary to do successful software development. Hopefully every programmer out there is using source control by now, but there were some specific ideas that caught my eye; the book does an outstanding job of justifying them:

• Programmers should commit changes to source control at least every few days; if that’s not possible, they should commit changes to a private folder in the source control database.
• Creating a build machine should be as easy as getting files from source control and running a script. The build process should have no machine-level dependencies.
• The build script should run frequently, ideally whenever code is checked in, and should include automated tests to help prevent bug regression.
• Bug reports and feature requests must be tracked in an easy-to-use database.

The book then talks about techniques that help ensure success:

• The List is a prioritized list of measurable tasks that need to be completed. The team has a master list, and each programmer copies items from the team list to their individual list.
• Each item on the list should have a time estimate. When completed, each item is marked as finished, and the actual time is recorded. Time estimates will improve with practice.
• Each team needs a tech lead who maintains The List and monitors the direction of the team.
• The team should have a daily meeting where each person takes a minute or two to describe what they’re working on.
• No code should be committed to source control without a code review, generally by one other developer. Code reviews, like commits, should be frequent.
• The team should be able to easily monitor commits to source control.

The book also describes their process, called “Tracer Bullet Development.” I’m sure I’m missing something, but it doesn’t really seem much like a “process” to me; it basically describes a modular way of architecting a product and dividing the labor among the modules.

Finally, the book reinforces the advice it has given by presenting various common problems in the development process and the techniques that are important to solving those problems. Much of the advice in this section is on how to incorporate and maintain automated testing without too much pain.

I highly recommend this book to all software developers, particularly to those in leadership positions. I’m hoping that our development team will have the opportunity to try out some of these ideas and see improvement as well.

Concurrent Programming in Java, by Doug Lea, was recommended to me by two presenters at the Microsoft PDC 2005 as the best book about concurrent programming for .NET. It is an impressive book, and it seems fairly straightforward to translate the concepts from the Java world to the .NET Framework.

I can’t give this book a completely fair review, because I wasn’t able to finish it. The book is divided into four chapters; my current interest in concurrent programming was only able to get me through the first two. I don’t doubt that I will find additional value in this book the next time I am faced with a difficult concurrency challenge.

I really enjoyed the first two chapters, though, as they provide the language for discussing concurrent programming. For example, section 1.3 describes the “design forces” to consider when designing concurrent software:

• Safety demands that an object is always in a consistent state. Concurrency makes it possible for one thread to interfere with the operation of another thread acting on the same object, possibly resulting in an inconsistent state.
• Liveness demands that operations run to completion. Concurrent programming can permanently halt progress when two threads are waiting for locks held by the other thread, for example.
• Performance wants operations to run in a timely manner. Concurrency support adds overhead that can hurt performance.
• Reusability wants objects and algorithms to be reusable by different parts of the system. Concurrent programming adds a new dimension to the requirements of reusable software; specifically, clients must know to what extent a component is thread-safe.

Chapter 2 is all about keeping objects in a consistent state by ensuring that two threads cannot manipulate the same data at the same time, either by making objects immutable, or preventing objects from being accessed by other threads, or by synchronizing the use of objects with locks. Understanding of these concepts is crucial to writing safely concurrent code.

Section 2.2.7 is particularly interesting if you’re not familiar with the concept of a “memory model.” Basically, modern compilers and processors can rearrange the order in which statements and instructions are executed, as long as the end result is the same. This can cause very surprising behavior when one thread is observing the activity of another thread. The only practical way to ensure that each thread sees what you would expect it to see is to use synchronization; access to shared memory should always be protected by a lock.

I know that the book has more important concepts; perhaps I’ll make another attempt at reading chapter 3 some day. If you’re doing any concurrent programming at all, I highly recommend that you see how far you can get.

I read Effective Java, by Joshua Bloch, not because I ever write Java code (I don’t), but because it surprisingly was recommended as a valuable book for C# programmers. Sure enough, this book has excellent advice for programmers of any Java-like object-oriented framework. My favorites:

• Item 1: Consider providing static factory methods instead of constructors
• Item 6: Avoid finalizers
• Item 12: Minimize the accessibility of classes and members
• Item 13: Favor immutability
• Item 14: Favor composition over inheritance
• Item 15: Design and document for inheritance or else prohibit it
• Item 27: Return zero-length arrays, not nulls
• Item 29: Minimize the scope of local variables
• Item 30: Know and use the libraries
• Item 39: Use exceptions only for exceptional conditions
• Item 46: Strive for failure atomicity

One item that caught my attention was item 16 (“Prefer interfaces to abstract classes”), because it directly conflicts with Cwalina and Abrams’ Framework Design Guidelines (“Do use abstract classes instead of interfaces to decouple the contract from implementations”). Of course, both books are expressing a general preference, not a strict rule, and both books identify the situations where each construct is appropriate.

Some of the items are particular to Java, but they were still interesting as education on some of the differences between Java and C#. I just skimmed the last chapter (“Serialization”), which basically discourages the use of Java’s serialization mechanism anyway. Furthermore, I don’t know how it compares to .NET serialization.

All in all, it was definitely worth reading, and I highly recommend it to seasoned C# programmers.

Programming Windows Presentation Foundation is an outstanding introduction to the latest technology from Microsoft for building user interface for Windows XP and beyond. It is written by two knowledgeable and trustworthy authors, Chris Sells and Ian Griffiths, in a style that’s easy to follow. I’m going to need some actual experience under my belt before I really “get it,” but this book taught me far more than the online information that I’d read thus far.

It’s difficult to introduce so many new concepts in a linear fashion, so there were a few hiccups. I would like to have learned more about “dependency properties” before chapter 9, as they are really fundamental to the entire programming model of WPF. You might consider reading chapter 9 (“Custom Controls”) immediately after reading chapter 3 (“Controls”). I also would have liked to see more code and less XAML, though that may have made the book much longer for little benefit. At the very least, take their advice and skip ahead to Appendix A to help understand what sort of code the XAML is used to generate.

This book was written for WinFX Beta 1, so be sure to read the errata, as there have been important changes in the most recent releases. If that’s too bleeding-edge for you, feel free to wait until they publish the second edition of the book, after WPF actually ships. On the other hand, the fundamentals of WPF won’t be changing, so this book still provides an excellent introduction to the next wave of user interface programming for Windows. I, for one, am ready to get started! Goodbye GDI, hello WPF!

Like its predecessor, the .NET Framework Standard Library Annotated Reference (Volume 2: Networking Library, Reflection Library, and XML Library) is mostly a reference book interspersed with annotations. Unfortunately, the annotations in this volume are less interesting than those in volume 1. If you have the opportunity, do browse through the annotations, but don’t expect a big return on your investment.

C# Precisely, by Peter Sestoft and Henrik I. Hansen, is a concise overview of the C# language. It is clearly intended for programmers that are already somewhat familiar with the language, but want to fill in the details.

I picked it up not because I needed the overview – there was little that I didn’t already know – but because I had read great reviews on the presentation format of the book. The presentation is, in fact, pretty impressive. As you read the book, the left page contains all of the prose, which is information-dense yet quite readable, and the right page contains examples and their descriptions, numbered from the beginning of the book to the end for easy cross-referencing. In only 180 pages or so, this book manages to convey a lot of information very efficiently.

I would definitely recommend this book to anyone that wants to get familiar with the details of C#. Be sure to read the online errata, as some of the information on C# 2.0 is slightly outdated. Also, as mentioned in the preface, this book does not cover a few topics, the most important of which are destructors and finalization; be sure to find another source of information for the missing topics.

Effective C++, Third Edition, by Scott Meyers, contains a number of fundamental C++ guidelines that should be read by all C++ programmers. Having already read a previous edition of Effective C++, my expectation was that I would get a nice reminder of things I already knew. My hope was that I’d learn a few things that I didn’t already know, or had forgotten; here are some of those things:

• You can use the member initialization list of a constructor definition even when you want to default construct a data member (p. 29).
• A classic implementation of the copy assignment operator takes its argument by value (to make a copy of it) and then calls swap on that argument (p. 56).
• Since compilers can reorder operations within a statement, very surprising things can happen in the face of exceptions (p. 76).
• Prefer non-member non-friend functions to member functions (p. 98). I remember this controversial item from the last edition, but it was good to read his rationale again.
• There are very peculiar rules about the swap function. You need to consult item 25 (p. 106) before you attempt to write a non-throwing swap function for your classes. Even calling the swap function is complicated – you must not call std::swap directly, but should instead call it like this: using std::swap; ... swap(obj1, obj2);
• It never occurred to me to use an “interface class” for a single concrete class, merely to reduce compilation dependencies (p. 145).
• Use using declarations to avoid hiding inherited names; you rarely want to hide inherited member functions when you add a new overload, but that’s what happens in C++ (p. 159).
• Include a definition for a pure virtual function if you want to provide a default implementation that must be explicitly requested (p. 167).
• I didn’t realize that “accessing names in templated base classes” was a problem; you’d think I’d have run into that before (item 43, p. 207).
• I also never realized that I’d need to “define non-member functions inside templates when type conversions are desired.” The only way to do that is with a friend function, even if the function doesn’t need special access to your members (item 46, p. 222).

I bought the last copy of Framework Design Guidelines by Krzysztof Cwalina and Brad Abrams at the PDC so that I’d have something interesting to read on the trip home, and I was not disappointed. I find myself in agreement with nearly all of the guidelines; widespread adherence to them even when writing small libraries would improve overall code quality. Of course, it’s much more interesting to highlight the areas that I don’t agree with, so I’ll first make myself clear – I highly recommend this book to anyone writing code that uses the .NET Framework or any similar object-oriented framework.

One classic source of disagreement is in the use of Hungarian notation; I use a mild form of that notation that I feel greatly improves code readability. The guidelines only prohibit the use of these identifier “warts” on the public API, which would be fine, except that method parameter names are shared by the API (which shouldn’t use them) and the implementation (which should, if the rest of the implementation does). So, what to do? Since there’s no easy way to have my cake and eat it too, I just use Hungarian with parameter names, and hope that my clients will forgive me.

I’m not fond of the event pattern where a protected virtual method is defined that raises the event. It’s not clear to me why derived classes should be able to suppress the raising of events; I prefer virtual methods to always be abstract or empty, so that derived classes don’t have to call the base-class implementation at all. I like adding the virtual method, so that derived classes don’t have to add event handlers to their own events, but I tend to call the virtual method and then raise the event.

Speaking of parameter naming, and speaking of events, I really don’t like the convention of calling the EventArgs parameter e. I use args.

Finally, I only agree with about half of the coding style conventions listed in Appendix A:

• They seem to have something against spaces, which are important for readability, particularly if you’re using a proportionally spaced font. (You really should be writing code in Verdana 8pt if you’re not already.)
• I love omitting braces around single statements; I don’t buy the “readability and maintainability” argument, particularly when you put the opening brace on its own line (which they don’t).
• Tabs are way better for indentation than spaces.
• I’ve never understood why private fields should go at the top of a class declaration. All other private members go at the bottom, and for good reason; why not fields? Otherwise, their recommendation to group members is good, though I prefer logical ordering to alphabetical ordering when practical.

I’ll have to publish my own coding style conventions one day. If you’re really curious, just look at code samples elsewhere on this blog…

And in case you skipped down to the bottom, let me reiterate – you should read this book!

C++ Common Knowledge, by Stephen C. Dewhurst, is a short book of 63 items that cover a broad variety of topics targeted at the “intermediate” C++ programmer. It certainly isn’t for a C++ beginner, but I can see how someone with some C++ experience could quickly learn important stuff about C++ by reading this book. None of the information was new to me, but most items were still fun reminders of C++ techniques that I don't get to use every day. Besides, the back cover and introduction make it clear that its primary use for “expert” C++ programmers is to help train “less-experienced colleagues.”

I happily recommend this book to any C++ programmers out there that are ready to move to the “next level,” but don’t stop there. Immediately after item 63 is an excellent bibliography of C++ books that are “must reads” for any C++ programmer, all of which I have read and highly recommend.

If you prefer reading paper to reading a computer screen, you might like The Best Software Writing I: Selected and Introduced by Joel Spolsky. It contains a number of articles by various authors on various aspects of software development. Much of the content is available online – in fact, I’d already read a handful of the articles – but printed books are still a lot easier on the eyes and the brain than reading out of a Web browser.

Here are some of the main points that I want to remember:

• Coding style should be enforced by the compiler.
• Software should be flexible, simple, sloppy, tolerant, and forgiving.
• Strong testing can replace strong typing.
• Great programmers want interesting projects more than anything else.
• You can’t directly measure the performance of programmers or testers.
• Emphasizing rewards for individual merit is dangerous for team morale.
• Writing good social software is really hard.
• Small software companies should “trust the customer.”
• Hiring good people is hard (but still easier than firing).
• Ruby looks even stranger than Perl.

I can’t promise that it’s the “best” software writing, but it’s pretty good, so I recommend this book to anyone in the software industry looking for some interesting ideas.

Imperfect C++, by Matthew Wilson, is an outstanding book that provides “practical solutions for real-life programming” in C++. It presents a wide variety of useful material that I haven’t found in any other book on C++. If you’re an experienced C++ programmer, you’ll have learned much of this material the hard way, but you’ll still find plenty of information that will hopefully come in handy down the road.

As I read, I like to jot down items of interest so that I can come back to them later. There was no shortage of interesting items in this book; here are some highlights.

• 1: Mechanisms for implementing constraints, contracts, and assertions.
• 2.3: Using const to track down uninitialized member variables.
• 2.3.1: Calling private static methods from member initialization lists.
• 10.2.2: Using spin mutexes for synchronization with low contention.
• 10.3.3: Critical sections are as slow as mutexes on multi-processor Windows machines.
• 11.3.2: Using a spin mutex to guard local statics.
• 12.2-12.4: Visual C++ 7.1 optimization. (It supports Return Value Optimization, but not Named RVO. It supports almost every case of Empty Base Optimization, and every case of Empty Derived Optimization.)
• 15.1: Creating a good null pseudo-keyword.
• 18.1: Using the const keyword after the type. (I should really start doing that; old habits are hard to break, e.g. char const * instead of const char *.)
• 18.4: Implementing true_typedef.
• 18.5.3: Using a LocalClass typedef in implementation files to reduce differences between similar class implementations.
• 20. The power of shims.
• 24.6: The best way to implement a safe conversion-to-Boolean for a class.

One of my favorites quotes is in the introduction to chapter 6: “You get all that functionality just by typing a }.”

If it’s not clear already, I highly recommend this book to anyone using C++ to write “real-life” programs.

Emotional Design: Why We Love (Or Hate) Everyday Things, by Donald A. Norman, makes the case that products should be designed with human emotion in mind. That is, a product should not only work well and be as easy to use as possible; it should also evoke positive emotions in the people that use the product.

Taking this idea further, he argues that products – robots in particular – will ultimately need to evoke emotions themselves to maximize our satisfaction with them. His ideas are fascinating, often in the same way that science fiction is fascinating – it may be decades before advances in artificial intelligence can allow us to fully test them.

His opinion of most software is that it is too abstract – too “virtual.” If software is to appeal to our emotions, it needs to be more physical. We need to find ways to stimulate other senses than sight and mind – touch, hearing, smell… Knobs and levers are a good start – I’m not sure where he’d like to see it go from there. Page 83 suggests that there is little hope for existing software products: “Good behavioral design has to be a fundamental part of the design process from the very start; it cannot be adopted once the product has been completed.” To design a good product, you must observe potential users in order to understand their needs. From there, product designs need to be prototyped, tested, and improved iteratively.

In evaluating the effectiveness of product design, he considers three levels. Good visceral design has an appealing appearance. Good behavioral design produces products that work well and are fun to use. Good reflective design is how we feel about the design in the long-term – feelings of pride, good memories, etc.

This book was easy and fun to read; I recommend it to anyone that is interested in designing products that are not only useful, but emotionally appealing. It is not exactly full of practical advice, but it may get you thinking in the right direction.

I’ve had a difficult time getting through what could be considered the first book in this series, so I decided to read the .NET Framework Standard Library Annotated Reference (Volume 1: Base Class Library and Extended Numerics Library) instead. It’s written by Brad Abrams with various other contributors.

This book is mostly a reference book that covers a subset of the .NET Framework Standard Library. Considering the easy availability and detail of the MSDN documentation, you might not find this very useful as a reference. It does provide interesting summaries of the core namespaces, and it is nice to see all of the method signatures supported by a class in just a page or two, but I can’t see myself using it much for reference purposes.

Unsurprisingly, the selling point of the book is the annotations. I wish there had been more of them, but since the annotations are really the only interesting reading, it makes this book very easy to read through. Some highlights:

• Don’t catch, throw, or even derive from ApplicationException.
• ArgumentNullException and ArgumentOutOfRangeException take the parameter name as its first constructor argument, but their base class, ArgumentException, takes the parameter name as the second constructor argument (after the message).
• Array.Copy can be very useful.
• Prefer using SyncRoot to the Synchronized method.
• Seal your custom attribute classes for better performance.
• Expressions within a conditional method are not evaluated when the condition is not met. (So calls to methods within a Debug.Assert wouldn’t be called in Release mode.)
• Delegates are immutable.
• The static Equals method of the Object class deals with null.
• Stream.Null makes a great bit bucket.
• Streams work with bytes; Readers and Writers work with characters.
• A ThreadAbortException is automatically rethrown if caught.

All in all, I really enjoyed the annotations, but considering how much of the book is uninformative reference material, I can’t say that you’ll find it worth the money.

Update: I should also mention that it comes with a CD that contains all of the samples from the book. More notable, however, is the 3,864-page PDF document that replicates the content of the print book, except that it includes documentation for each member of each class. Fascinating, to be sure, but certainly MSDN is more convenient.

I’ve been writing a lot about JavaScript lately, but C++ is my first and best love (in the realm of programming languages, anyway). I finally decided to hunker down and read through The C++ Programming Language (Special Third Edition), written by none other than Bjarne Stroustrup, creator of C++.

I have a decent amount of C++ experience, and have read many of the C++ books written since this one was published, so I didn’t expect to learn a whole lot. Still, it was fun to read – at least until I got to the chapter on streams – and the road to C++ mastery certainly requires it.

I tried to keep a list of interesting items as I read through:

8.2.8: A namespace should express a logically coherent set of features without imposing a significant notational burden. We need a lot more guidance in this area.

8.2.9.3: It is safer to define functions declared in a namespace outside of the corresponding namespace declaration.

// this works
namespace N { void F() {} }

// this is safer
namespace N { void F(); }
void N::F() {}

11.5: Individual member functions of other classes can be made friends.

friend Node * Node::GetNext();

12.4.1.1: Data should be kept in derived classes.

14.4.6.1: Exceptions from member initializers can be caught by enclosing the entire function body in a try block.

15.2.4: I’m finally starting to understand virtual base classes, but experimentation was the key when trying to figure out how they ensure that the shared base class constructor is only called once, particularly when non-default constructors are involved.

15.3.2: Base classes of a struct default to public, just like members.

17.1: Some relational operations can be created implicitly by using namespace std::rel_ops.

18.3.1: Input sequences look interesting.

18.4.2: I forget about many of the algorithms, like mismatch, inplace_merge, and stable_sort.

21+: I couldn’t bring myself to care enough about the Streams and Numerics chapters to read them carefully. I’ve just never had much use for them.

The rest of the book was somewhat interesting, but I enjoyed the first 20 chapters the most. You, too, should be sure to read this book if you’re on the road to C++ mastery.

JavaScript: The Definitive Guide, by David Flanagan, is an outstanding book about the JavaScript language. It has excellent documentation on both the “core” JavaScript language and “client-side” JavaScript as used by a web browser. Best of all, it doesn’t mix the two, which is particularly useful if you find yourself using JavaScript outside of a browser. It also gives the author a chance to dig deep into the core language, which is a far more powerful and expressive language than most people realize.

The second half of the book consists of three references – one for “core” JavaScript, one for “client-side” JavaScript, and one for the W3C DOM. The references aren’t nearly as useful as the first half of the book, since that sort of documentation is more widely available, but it could come in handy.

I have extensive experience using JavaScript both inside and outside of a browser, and have recently been studying the more “advanced” features. I was surprised by some of the details I had overlooked:

• The switch statement uses identity (===), not equality (==), when looking for a matching case statement.
• Each case of a switch statement can use any expression (not just numbers or strings).
• The first expression of a for...in statement is evaluated for each item. (I don’t plan on taking advantage of that obscure feature.)
• You can break or continue to a label.
• FunctionName.length is the declared number of function arguments.
• If a function used as a constructor returns an object, that object becomes the “new” object.
• The push method of an Array can take multiple arguments.
• In client-side JavaScript, “global” variables become properties of the global object, the window.
• SCRIPT elements should use DEFER if they don’t call document.write.
• The Internet Explorer event model has important differences from the standard event model.
• The standard Error object simply takes a string in its constructor (in Internet Explorer, the Error constructor is documented as taking a number followed by the message; I have since discovered that the standard behavior is supported as well).
• The substr method of String is deprecated in favor of substring or slice. (Unfortunately, I find substr far more natural than substring or slice.)
• There are a lot of methods that only work in Internet Explorer (and this book only scratched the surface).

The book also talks some about “Object-Oriented JavaScript,” which I hope to talk more about in a future post.

If you are a JavaScript programmer but realize that you may only be scratching the surface of what is possible, or wonder why the language doesn’t always behave as you’d expect it to, I highly recommend that you read this book.

I don’t use FogBugz for bug tracking, so I read Painless Project Management with FogBugz by Mike Gunderloy more out of curiosity than real need. Since I have little experience with formal bug-tracking systems (I know, shame on me), I found it interesting to read about the various features of this particular bug-tracking system and some of the philosophy behind those features. If you are considering purchasing FogBugz, or are learning how to use it, this book is sure to be useful to you.

(I did end up with one particularly practical nugget of information, though. We’re currently using Visual SourceSafe for source control, and I wondered how a bug-tracking system could easily integrate with VSS – it would need to know which files were most recently checked in, but I know that the History feature of VSS is quite slow. As it turns out, there’s a useful Journal feature that’s available through the Options dialog of the VSS Administrator. It records every change to the database to a log file, which could come in handy for any tools I might write to monitor the database.)

Pattern Hatching: Design Patterns Applied is small book that serves as a follow-up to Design Patterns. It was written by John Vlissides, one of the “Gang of Four,” and published back in 1998.

I enjoyed chapter two of this book, “Designing with Patterns,” as it provided a concrete example of patterns at work. The rest of the book seemed aimed at writers of patterns, so I found it much less interesting. One big problem was that I didn’t heed the warning in the introduction that I needed to be very familiar with all of the classic patterns – I don’t know them as well as I ought, so I sometimes had a little trouble following. It must be time to reread Design Patterns. I also need to brush up on my UML – there can be a lot of meaning hidden behind the style of arrowhead used in a diagram.

In summary, I can’t give the book a formal recommentation, but I did find it interesting, and if you’re really into patterns, then you certainly need to have read this book.

Write Great Code (Volume I: Understanding the Machine), by Randall Hyde, wants to help you write better software by teaching you more about the hardware. I found the book quite fascinating when I didn’t find it uninteresting. I skimmed through his software implementations of floating-point operations, the design of a hypothetical instruction set, and some of the other really deep material, so I ended up really enjoying the book overall.

I enjoyed the refresher on how floating-point works. I’ve never paid much attention to hardware, so I learned a lot about what the data buses are and how they’re used, how memory is accessed, what a wait state is, etc. I thought I knew Boolean logic until I read (and then skimmed) chapter 8. I learned a lot about I/O in the last chapter as well.

The less you understand about the hardware, the more you stand to gain from reading this book. I don’t intend to leverage the material to go out and exercise premature optimization in all of my future code, of course; after all, code should be written for humans, not machines, until it becomes clear that there’s a performance problem.

I’m somewhat tempted to read Hyde’s other book, The Art of Assembly Language. However, from what I can tell, that book teaches you how to write assembly language in HLA (High-Level Assembly). I’d be much better off learning how to read assembly language for x86 processors, since that still comes in handy when debugging high-level languages.

I highly recommend this book to anyone that knows more about software than hardware, and I’m looking forward to Volume II: Thinking Low-Level, Writing High-Level.

C++ Coding Standards, by Herb Sutter and Andrei Alexandrescu, provides “101 rules, guidelines, and best practices” for programmers that aim to write modern, high-quality C++ code. Every C++ programmer needs to read and understand this book.

Relatively inexperienced C++ programmers will have a hard time following some of the items in this book, many of which assume that this isn’t the first, or even the fifth, C++ book or article that you’ve read. Fortunately, each item comes with a handy list of references to follow until you achieve sufficient mastery.

It’s really hard to argue with most of the items in the book. Many of the items are about minimizing dependencies, which I consider to be the most important rule of software development (items 5, 6, 10, 11, 18, 21, 22, 32-44, etc.). I also love item 9, referenced by many of the other items: “Don’t pessimize prematurely.” (Don’t worry; it’s preceded by item 8, “Don’t optimize prematurely.”) There were a few items that were a bit surprising – item 58 seems to suggest defining far more namespaces than I’m accustomed to; I wish it would have given naming guidelines!

The book does an excellent job of bringing all of the little C++ rules that I’ve picked up here and there and putting them all in one short book. The authors did an excellent job of filling 220 pages with 101 items, while always starting each item at the top of a page! There’s also a handy summary of all 101 items in the back, right after the extensive list of references, and before what looks to be a thorough index. Be sure to review this material before any new C++ project to help correct the biggest challenge of C++ programming – it’s hard to remember all of this stuff!

Developer to Designer, by Mike Gunderloy, contains practical advice on how to design a decent Windows application. It’s much more than just throwing some controls onto an interactive designer, writing some event handlers, and sticking a fork in it. You’ve got to pay attention to Windows user interface conventions, both written and unwritten. You’ve got to align controls properly, create predictable menus, ensure that functionality can be accessed by both mouse and keyboard, etc., etc. You’ve got to be consistent within your own application and with the other Windows applications that your users have grown comfortable with. Unless you’re one of a rare breed of developers that has a user interface designer making these decisions for you, it’s up to you to make this happen.

There’s not much in this book that can’t be learned with experience, so if you’re a Windows programming veteran that has taken care to follow the Windows user interface guidelines, you may not learn much from this book. I must admit that I found nothing surprising in the book, and couldn’t escape the feeling that any Windows programmers worth their salt should already know all of this stuff. However, if you’re relatively new to Windows programming, or haven’t really taken the time to make a Windows user interface that’s at least as good as the likes of Microsoft Office, then this book will put you on the right track.

I should mention that Developer to Designer also spends a few chapters on basic Web design. The same idea applies – if you have any experience with Web development, these chapters may seem terribly obvious, but if you’re new to Web development, this book should provide you with a good starting point.

The book also includes an appendix on what we might expect from the new user interface guidelines that will attend the next version of Windows, code-named Longhorn. If you haven’t already done much reading on the subject, this should provide a simple introduction of what is to come.

In summary, this book distills years of Windows UI design experience into one short book of great tips, so if you want to take a shortcut and start writing good user interface for Windows today, reading this book will be a great start.

Now is a great time for a client application programmer like myself to learn how to write Internet applications. I love the .NET Framework, and I’ve heard great things about ASP.NET, so I really wanted to learn more about it. I didn’t want a summary of how to use Visual Studio to create Web sites, nor did I want reference documentation of all of the available Web controls. I don’t yet have much experience with databases, so I didn’t want to get bogged down with that, either. I just wanted to understand the architecture of ASP.NET, and Fritz Onion’s Essential ASP.NET with Examples in C# fit the bill perfectly.

I now have a decent understanding of how ASP.NET works, why it was written that way, and what the possibilities are, so I’m ready to write my first real Internet application. If you’re an “experienced” programmer who wants an intelligent introduction to ASP.NET, this book is highly recommended.

The introduction to Patterns of Enterprise Application Architecture, by Martin Fowler, makes it clear that I am not a developer of enterprise applications. The rest of the book makes me glad that I’m not. (Okay, that’s mostly just a joke.)

Still, there may come a day when I must help develop an enterprise application – and certainly large non-enterprise applications share some traits with your typical enterprise application – so I decided to read this book and hopefully gain some insight.

The fact that I made it through the whole book says a lot, as far as I’m concerned. I did my share of example-skimming and that sort of thing, but I think that I have learned a lot, and hopefully I’ll recognize the need for some of these patterns in my future development and have a good mental framework for dealing with them.

I found the book to be well-organized, easy to read, and generally interesting. I imagine that true enterprise developers will find this book immediately useful.

Code Complete, Second Edition, by Steve McConnell, is a big book. I confess that I didn’t read every last word, but I did look at every page. It’s full of lots of great advice for programmers, and a little not-so-great advice – the advice that I don’t agree with, of course. He said that I wouldn’t agree with all of his conclusions, though, so I guess that means the whole book is right on the money.

I can’t really give it a thorough review, because the book is too comprehensive. I’d be here all day! So, I’ll simply state that every programmer needs to read through this book – more than once, almost certainly. Have fun!

I can’t fairly review Thinking Visually, by Malcolm Craig, because I’m not really his target audience, and I didn’t manage to read the book cover to cover. I did read Part One, though, and it reminded me that I really should take more notes, and that I should do it graphically. It’s a shame when you’re trying to think coherently about a subject, but you can’t remember the things that have already been thought about. Simple notes might help, but drawing diagrams is faster and more useful than linear note taking.

From the summary of chapter two: “The main purpose of diagramming is to help simplify everyday tasks such as problem solving, writing reports, making changes, and coping with information overload.”

The book describes a number of types of diagrams. Browse through a copy if you aren’t familiar with them:

• Algorithm
• Control
• Fishbone
• Flow
• Force-Field
• Influence
• Input-Output
• Mind Map
• Multiple-Cause
• Relationship
• Ring
• Sign
• Tree
• Window

My favorite diagram is the “mind map” – in fact, I use MindManager at work to help me keep a handle on the various projects that we have going on. It’s no more than a glorified outline, but I find it easier to manage the information when it is in “mind map” format.

If you want to write exceptional C++, you must read Herb Sutter’s books, and Exceptional C++ Style is no exception. (Har!) Like its predecessors, Exceptional C++ and More Exceptional C++, the book is organized into items, each of which has a few questions followed by detailed answers that present the most up-to-date ideas for writing good C++ code. I like Herb Sutter’s writing style – and, of course, his expertise – so I had no trouble reading this book from start to finish.

The book can also be skimmed fairly easily, since each item has a nice summary at the end, as well as highlighted guidelines throughout. The most interesting stuff from my perspective:

• I always forget about vector<>::at(). In particular, I forget that it is bounds-checked. Of course, that explains why I never use it – very few STL functions are bounds-checked in any way, so it’s good to get into the habit of realizing that, if you do something wrong, you’re going to crash, not get a nice exception. It’s speed over safety in the STL.
• Avoid template specialization of function templates. (That’s an oversimplification; read item 7 for how to do this the “right way.”)
• Never use protected data members. It’s tempting, but there’s always a better way.
• “The most important thing to get right is the interface. Everything else can be fixed later.” I totally agree.
• “Prefer to make interfaces nonvirtual.” That is, try to avoid public virtual functions. In fact, “prefer to make virtual functions private” unless “derived classes need to invoke the base implementation of a virtual function,” in which case they can be protected. Absolutely.
• “A base class destructor should be either public and virtual, or protected and nonvirtual.” This isn’t instinctive to me yet, but I believe it.
• “There’s often little point in checking for new failure anyway.” It’s about time somebody admitted that allocations never fail – and if they do, you’re not going to be able to recover.
• Nearly useless keywords: inline, auto, register.
• “Remember that floating-point math is weird and deeply strange.” I understand the pitfalls of integer arithmetic, but almost nobody really understands floating-point math.
• “Avoid macros.” Common C++ knowledge for ages, yet I still find them being used when an inline function would do just fine. Stop it!
• “Prefer writing functions as nonmember nonfriends.” The true C++ guru provides only the absolute minimum number of member functions for a class; the rest of the functionality is provided by nonmember functions. Unfortunately, STL fails this guideline, so we don’t have a good example to follow.

I have loved C++ ever since I first started using it. I hope that C++/CLI will enable me to productively use C++ far into the future; C# is cool, but not as cool as C++. If you are a C++ guru, or aspire to be one, this book and its predecessors come highly recommended.

I enjoyed reading Refactoring, by Martin Fowler et al. The book seems to treat refactoring both as a technique and as a philosophy.

As a technique, refactoring is simply “change made to the internal structure of software to make it easier to understand and cheaper to modify without changing the observable behavior of the software.” Most of the book is a reference of refactorings: motivation, mechanics, and examples for things like “Extract Method” and “Replace Conditional with Polymorphism”. I love to write good code, so I actually liked reading the reference material – each refactoring represents a code change that has the potential to make it better.

As a philosophy, the book tries to help the reader know when refactoring should take place, and which refactorings should be used. One practical motivation for refactoring is to improve the design and understandability of code before you add a feature or fix a bug. To determine which refactorings are needed, you’ll notice “bad smells” in the code – one chapter is devoted to some of the more common smells, including duplicated code, long methods, switch statements, etc. One quickly begins to see the author’s idea of what good code looks like; the reader must decide if he agrees.

The trouble with refactoring is the “without changing the observable behavior” part. It’s hard to guarantee that your changes haven’t changed anything. In fact, from page 8: “Before you start refactoring, check that you have a solid suite of tests. These tests must be self-checking.” The process of writing these tests is not described in detail – and rightly so – but the need for a test suite is important to keep in mind. Writing good tests is certainly harder than the process of refactoring itself.

I’m not yet sold on the philosophy behind refactoring, but I want to give it a try. Good refactoring tools are becoming more common – the prospect of avoiding the busy work of refactoring is very attractive, and would be a strong influence to try it out, though there’s still that pesky test suite to create...

Writing this review, I realize that I should read the opening chapters again. In case it isn’t clear, I highly recommend this book.

Test-Driven Development in Microsoft .NET, by James W. Newkirk and Alexei A. Vorontsov, seems primarily intended for programmers that are convinced that TDD is a “good thing” and are writing “enterprise” applications with ASP.NET and ADO.NET in which even one minor defect is one too many. Since only one of those things apply to me (I am a programmer), it should come as no surprise that I did not get much out of this book, and ended up skimming most of it. If you fit the profile better than I do, you will probably like this book a lot more than I did.

I did enjoy the first three chapters, as well as Appendix A, as they teach the basics of TDD by example. TDD seems most logical when developing small, independent components without user interface. Even that looks like an awful lot of work, and it seems to me that the work could increase exponentially with larger, codependent, and/or user interface driven components. Perhaps experience can mitigate some of that, but I don’t think I’m ready to commit the extra time and energy.

Debugging, by David J. Agans, describes “the 9 indispensable rules for finding even the most elusive software and hardware problems,” and they are:

• Understand the System
• Make It Fail
• Quit Thinking and Look
• Divide and Conquer
• Change One Thing at a Time
• Keep an Audit Trail
• Check the Plug
• Get a Fresh View
• If You Didn’t Fix It, It Ain’t Fixed

This book was fun to read. Entertaining “war stories” are used to help illuminate each of the nine rules, and humor – mostly successful – is used throughout to help keep your interest. Experienced debuggers really do follow these rules, but naming the rules makes it even easier. These are the “design patterns” of debugging.

My favorite rule was Quit Thinking and Look. I definitely tend to overanalyze when faced with a bug or otherwise difficult problem. Thinking about a problem is certainly useful, but it can be far more useful to experiment. Why speculate about what part of the software is responsible for an error when you can simply use your debugging tools to figure it out?

This book is short, useful, entertaining, and inexpensive. Read it!

Designing from Both Sides of the Screen, by Ellen Isaacs and Alan Walendowski, is written by an “interaction designer” and a “software engineer,” and is appropriately subtitled “How Designers and Engineers Can Collaborate to Build Cooperative Technology”. This book may be particularly useful for planning software projects that have the luxury of one or more designers and engineers, but I think that it could be helpful even when the same people must serve in both roles.

Many books about the process of software development seem to focus on corporate development for a particular customer with whom the developers have direct access, so I was pleased to see that this book focuses on development from the perspective of writing software for unknown customers out in the real world.

The book is divided into two parts. The first part gives general guidelines for designing software that acts more like a kind butler than an evil robot. The second part (about two-thirds of the book) details a process for designing and implementing a software application. An appendix gives a nice summary of all of the guidelines mentioned throughout the book.

There are three main tenets of “being a butler.”

Respect physical effort by minimizing the number of “clicks” required of users to accomplish common tasks, smoothing out the user’s “flow”, and remembering the explicit and implicit information that the user provides.

Respect mental effort by removing complexity, making common tasks prominent, hiding infrequent tasks, and minimizing the need for “preferences”.

Be helpful by focusing on what works best for the user rather than what is easiest for the engineer.

Their software development process consists of five steps.

Understand the users’ needs by observing how they currently do the activity you want to support and by examining existing products that do similar things. Create a “task list” of the things that users will be able to do with your product, and then create the list of “functional requirements,” which describe what the product will do to support that task list. Finally, ruthlessly prioritize each functional requirement as “Core” (enough to start rudimentary testing), “Important” (required to ship), and “Nice to Have” (not required to ship).

Design the user interface without being overly concerned about what is “technically” possible. Use the prioritized functional requirements to similarly prioritize the task list, and then further organize the task list into four groups that indicate how often the task will be done and how many users will do the task – “Frequent by Many,” “Frequent by Few,” “Occasional by Many,” and “Occasional by Few.” Using this information, organize the functional requirements by “screen,” such that frequently used tasks require fewer “clicks” and popular tasks are more prominent. Make a “task flow diagram” to show the relationship among the various screens. Design the layout of each screen and create a mockup of each of them, making sure that each task is supported appropriately. Create a User Interface Specification that uses text and images to explain how each of the tasks is accomplished.

Design the architecture to support the user interface design, making modifications when necessary to address system constraints, simplicity, ease of maintenance, etc. Once it is clear how the product will work, create a detailed “feature list” from the prioritized functional requirements. Estimate the development time for each feature, and then triple the total time to determine the completion date. (Really!)

Initial development involves (finally!) writing code to implement the “core” features. Resolve issues through discussion between the designers and the engineers. Once the product is to the point where it can be reasonably tested for usability issues, initial development is complete.

Iterative development is the cycle of implementing “important” features, fixing bugs, doing usability testing (by using the product directly and by doing usage studies with potential users), and adjusting the specifications as necessary, until the product is good enough to ship.

This was an easy book to read with plenty of good advice. I hope to return to it when I find myself early in the design phase of my next software project. I may even try to follow their development process, though it’s a bit more elaborate than anything I’ve done in the past. I don’t think that a small software development team needs a complex, formal process for development, but the process in this book might be straightforward enough to help the team stay focused throughout the development of the product.

I enjoyed reading Web Bloopers by Jeff Johnson. The book describes “60 common Web design mistakes and how to avoid them” with lots of helpful screen shots. I don’t do much Web design, but it was entertaining to recognize many of the bloopers in sites that I’ve visited. Being divided into 60 small chapters, it was easy to read a bit at a time over the course of a few days.

I think that this book could be quite profitable as a “checklist” when examining a Web site for usability issues. (In fact, the official Web site for the book has a printable summary of each of the 60 points.) It can be difficult for developers to see the forest for the trees; objectively comparing each blooper to the Web site under development could help find potential problems with usability.

To test that theory, I decided to evaluate the Web site of my employer by the standards in this book. Fortunately, it avoids most of the bloopers, and the ones that are there are generally minor. I’ll send the results to the Web guys; hopefully they’ll find the evaluation useful.

Having already reviewed three other books on Windows Forms, it wasn't likely that I'd find anything too surprising in .NET Windows Forms in a Nutshell, by Ian Griffiths and Matthew Adams.

The first part of the book is an accurate overview of various features of the Windows Forms library. I was particularly glad to see a chapter on property grids, as they look to be a quick-and-dirty way to provide UI for user options. Kudos for mentioning that putting the user-displayed strings (for the property names, etc.) directly in the class attributes is not a good idea; it was nice to see how you could do proper localization of the control.

I was going to complain about the fact that the rest of the book is simply reference material for the many classes, enumerations, etc. provided by the Windows Forms library. Except I actually started reading through them, and found it interesting to read the short summary statements of each type to get a good feel for what is really available in the library.

I'm not actively doing Windows Forms development these days, so my opinion probably isn't very relevant, but I'd say that this could be a useful reference book to have on your shelf when working with Windows Forms.

Coder to Developer, by Mike Gunderloy, is a unique book that should be read by every software developer. In particular, you should read this book if you are working solo or in a small group, if you are working with the .NET Framework, or if you are new to the software industry.

The book is an unusual mix of general and specific advice about project planning, source control, unit testing, bug tracking, etc. Quite a bit of the material is helpful descriptions of currently existing tools, which makes it very useful for the developer of 2004, but will certainly become dated as the months go by. Still, the general advice is solid, and each chapter ends with a bullet list summary of the main points, which would be great to review whenever you are starting a new software project.

Coder to Developer is a short, inexpensive book, and it is a great collection of the “little things” that every developer needs to worry about when they're developing quality software. As such, I highly recommend it.

I can certainly envision a great book on design patterns that uses C#, but I'm afraid that C# Design Patterns: A Tutorial, by James W. Cooper, isn't it.

The first strike against the book is that it starts with a long, half-hearted introduction to C#. Certainly I'm reading this book because I already know C#, not because I need someone to teach it to me. If I didn't know C#, wouldn't I read a book with that target audience?

The second strike against the book is that the C# code all looks like Java code. Thus did I do a search on Amazon, fully expecting to find a book entitled Java Design Patterns: A Tutorial by the same author. I was not disappointed in my search, but I am disappointed that the author didn't bother porting the code examples more intelligently. I mean, the Observer pattern doesn't even mention events...

The third strike against the book is the overly complex examples. I'm all for examples that go beyond the classic Foo and Bar, but using Windows Forms, ADO.NET, etc., to demonstrate the standard design patterns is going too far, and distracts from the message.

Yer out! I do not recommend this book. Stick with the Gang of Four book, and check out this design pattern code library instead – it's got a simple definition, a UML diagram, a “structural” C# code sample, and a “real-world” C# code sample for each of the classic design patterns!

The intersection of the .NET Framework and XML is certainly worthy of its own book, and Applied XML Programming for Microsoft .NET, by Dino Esposito, fits the bill nicely. It was quite refreshing to read a specialized technical book that doesn't teach you the basics, but goes straight into the interesting topics. This book doesn't start by describing the CLR, or how to write C# code, or even what an XML document looks like. Instead it starts with the unique low-level XML parsing technology provided by the .NET Framework, explaining why the standard XML DOM isn't good enough (it requires the entire XML document to live in memory) and why the pull model of XmlReader is more useful than the push model of SAX (which can easily be implemented with XmlReader, but not vice versa).

The XML support of the .NET Framework uses many different technologies (DOM, DTD, XSD, XPath, XSLT, etc.), and I thought that Dino did a good job of representing those technologies without reproducing their specifications. I love XPath, so I took special interest in the XPathDocument class, an alternate representation of an XML document that's optimized for XPath queries. I also enjoyed the chapter on XML serialization, and now have a firm grasp of the difference between the SOAP formatter and the XML serializer, which both convert between objects and XML, but do so in very different ways. I'm not much of an ASP.NET/ADO.NET guy, so the stuff about data sets and Web services wasn't that useful to me, but it was easy to skip/skim.

Every .NET developer should read this book (because every .NET developer is going to have to work with XML sooner or later). I only hope that I can find more specialized technical books like this one that don't spend the first 100 pages telling me what I have already learned from the “broad overview” books.

Programming Microsoft .NET, by Jeff Prosise, is a well-written book about the .NET Framework. It focuses heavily on ASP.NET, which shouldn't be terribly surprising, considering that the .NET framework provides the most immediate productivity for Web development. The book gives only a chapter to client application development through Windows Forms, but it's a long chapter, and other books have been written to fill the gap. I especially enjoyed the chapter on ADO.NET, which gave a good introduction to accessing databases with .NET without going too far over my head.

This book is great for experienced Windows developers that want to understand the .NET Framework. There is very little coverage of Visual Studio .NET, which is a good thing, as it ensures that the reader understands the underlying concepts. Even with some .NET experience, I found that the book discussed topics that weren't covered in other similar books. For example, I wasn't familiar with the concept of background versus foreground threads in .NET until I read that section in the chapter on multithreading. (Background threads will not keep the application alive even if they are still running.) The book certainly can't cover the full breadth and depth of .NET, but it should enable the reader to become quickly productive with C# and .NET.

I've already done lots of reading on the C# programming language, so I must admit that I mostly skimmed The C# Programming Language, by Anders Hejlsberg et al. This book is quite easy to read, and it has anything you'd ever want to know about C#, so if you're writing serious C# code, you'd certainly benefit from having this book available.

Part I is about C# 1.0, and I mainly skimmed the table of contents here. One section that caught my eye was “Atomicity of Variable References,” in which I read that simple reads and writes of integral types of 32 bits or less are guaranteed to be atomic. That's good to know; I'd hate to use a lock around a simple integer if I didn't have to.

Part II is about the eagerly anticipated C# 2.0, and I enjoyed reading about it. I'm greatly looking forward to generics, anonymous methods, and iterators, and enjoyed reading the fine details. It looks like they did a thorough job, and I think the new features will make C# a far better language. Whether it will be good enough to keep me away from C++ remains to be seen...

It feels a bit odd to review a book that's almost 10 years old, but I wanted a quick introduction to SQL, and Lan Times Guide to SQL by James R. Groff and Paul N. Weinberg proved quite useful in that regard. Being a client application developer, I've done a good job of staying away from relational databases and their associated technologies to this point. I've always secretly wanted to learn more, though, and the increasing ease of interacting with databases (e.g., ADO.NET) finally made me cross the line and, at minimum, read a book.

I used SQLite to explore SQL as I read the book, and it worked out great. There's no complex database server to install with SQLite; rather, there's a simple command-line interface for creating/opening a database and executing arbitrary SQL commands against it. Furthermore, the source code is all in the public domain, so it can easily be used even with commercial products. There's even an ADO.NET interface – SQLite.NET, a SourceForge project that uses the BSD license.

The book is not about any particular SQL implementation, so it proved quite useful in getting the basics, and getting a feel for where the syntax might change among implementations. Most of the book was exactly what I was looking for – simple examples of the various commands that are possible with SQL. I'm certainly no SQL expert after reading this introductory book, but I feel like I have a good foundation, and I'm looking forward to incorporating a relational database in a future development project.

Component-Based Development With Visual C#, by Ted Faison, may aspire to be about component-based development, but it is mostly about describing the full breadth of programming possibilities exposed by Visual Studio .NET. To be fair, the first few chapters provide a good introduction to the development process, software components, and component design, including the classic design patterns. Each topic deserves its own book, of course, and many have been written, but it does provide a nice overview.

The rest of the book is about writing components for the .NET Framework in C# using Visual Studio .NET. The book touches on an amazing array of topics, but it is clear that the writer is not an expert on all of them, and, in fact, knows quite little about some of them, as evidenced by frighteningly inaccurate statements about the registry and shortcut files. This book might be useful for programmers that are new to Windows programming with Visual Studio .NET, but, by itself, it will give them just enough rope with which to hang themselves.

(One final note: The Web sites mentioned in the book are no longer valid links. The book is now being sold by Wiley, but I could not find any link to download the source code.)

I enjoyed reading Effective XML: 50 Specific Ways to Improve Your XML, by Elliotte Rusty Harold. Fortunately, I have not been engaging in particularly ineffective XML, but I haven't found practical advise like this anywhere else. Even the introduction was useful, as it clarified often misused terms like “element” and “tag”.

Part 1, on Syntax, encourages us to include an XML declaration and use ASCII for tags, neither of which I can disagree with. I was surprised that he didn't insist that I include the “standalone” attribute in my XML declarations; I seldom create documents that aren't standalone, and feel guilty that I don't include that attribute... His advise to “Stay with XML 1.0” was good to hear, particularly since XML 1.1 was just released; his arguments seem valid to me. I tend to stay away from DTDs – I suppose I just haven't felt that the added complexity would be worth the trouble – so the related items weren't as important to me. I like the concept of using standard entity references (e.g. &Ecaron;) instead of character entities (e.g. &#x011B;), but the subsequent requirement of dealing with DTDs is too much for me. Also, though I've preferred hyphen-delimited element and attribute names in the past – the first XML-related specifications let me down that path – I'm coming around to appreciate the use of “camel case” for names, as they probably are more readable.

Part 2, on Structure, gives good advice on how to decide between attributes and elements, whether a date should be encoded as a single string (“2004-02-23”) or three elements (“<year>2004</year>...”), and even the proper use of processing instructions. He reminds us that mixed content is still important, and suggests using XHTML as the standard for rich text (or “narrative content”). He almost contradicts the advice about character entities in part 1 that I disagreed with, for the purpose of interoperability with parsers that don't read the DTD. I was educated on the finer points of URIs, URNs, and URLs, as used by namespaces. He gives a little help on picking a schema language, and clearly isn't fond of the W3C XML Schema Language. There are also a few guidelines that seemed obvious to me, but must be in response to common abuses of XML.

Part 3, on Semantics, starts with a great summary of the many XML-related technologies that have become available, in each case giving an unapologetic opinion as to the general usefulness of that technology. Needless to say, I'm now less concerned about the fact that I haven't yet learned XLink, XPointer, etc. He touches on the joy of XPath; I certainly can't imagine using XML without it, and the “non-portable” nature of the SelectNodes methods of Microsoft's XML parsers has been worth the productivity gains. He touches on the difference between “push” and “pull” XML parsers; unless performance demands it, I'd certainly recommend sticking with “pull” – the “push” style of SAX simply takes too much development effort in many cases. The book encourages me to validate documents, a lesson that I learned long ago with SGML, but have yet to bring into the world of XML, probably because DTDs just don't seem like a good fit for XML with namespaces, and no clear winner has yet emerged from the battle of the schemas...

Part 4, on Implementation, made me curious to learn more about “native XML databases,” and wisely suggests that XML has not replaced relational databases. Beyond that, part 4 didn't really hold my interest much, probably because my focus is on Microsoft technologies, and I'm basically locked in to using their tools and techniques. For the sake of the first three parts, Effective XML is definitely worth reading, and I recommend it to anyone developing with XML.

After reading the first few chapters of Programming .NET Components, by Juval Löwy, I had hoped that the book would primarily give specific advise about how to best do “Component-Oriented Programming” with .NET. The chapter on interface-based programming was a good reminder that I shouldn't abandon all of the component principles I learned when using COM, but most of the book consists of descriptions of the various features of .NET.

The book does examine some of the more complex aspects of .NET, including versioning, multithreading, and serialization. I skimmed the long chapters on remoting and interception; I understand the basic concepts, and will return when I find a need for those technologies. The chapter on security was especially welcome; it cleared up many of the questions I had about code access security in .NET, though I could still use more information and “best practices” in particular. Speaking of which, I unfortunately noticed a few violations of modern “best practices” for deterministic finalization, asynchronous calls, and synchronization, but that just goes to show that you need to keep up with the latest articles as well as reading the good books.

In summary, though I'd like to have read more about how to write great components in .NET, much of the information in the book was valuable, and my knowledge of the .NET framework is broader having read it.

Applied .NET Attributes, by Jason Bock and Tom Barnaby, is all about attributes in .NET. The book is a bit short at 200 pages, at least relative to most programming books these days. It covers the basic concept of .NET attributes, many of the standard attributes provided by the .NET Framework, and how to write and use custom attributes. I was already fairly comfortable with the concept, and the standard .NET attributes are really best documented in books that describe the features that they implement, so the most interesting sections were on custom attributes, and, more specifically, the use of custom attributes in implementing “aspect-oriented programming,” the programming technique that's all the rage these days, at least in terms of blog conversations.

I enjoyed reading the chapter on AOP, though I was ultimately disappointed by the fact that it is very unlikely that I'll be implementing AOP in my own code. For now, the overhead for making .NET classes AOP-compatible is too high, at least with the techniques described in this book, and I don't see the immediate value in supporting AOP for some classes and not for others.

Also, I wish that the example used in the chapter on custom attributes would have been a little more practical. I don't often find myself creating a custom compiler. My favorite example of custom attributes is how it can be used to parse command-line arguments; that application gives you a good idea as to the cool stuff that can be done.

Unless you're looking for a concrete example of how you could do AOP with .NET attributes, I can't say that I recommend this book; it just doesn't give enough bang for the buck.

User Interfaces in C#: Windows Forms and Custom Controls, by Matthew MacDonald, has the disadvantage of being the third of three books on Windows Forms that I've read recently. There wasn't much in this book that wasn't already covered by the other two. It is similar in content to Erik Brown's book, but doesn't have the overarching application to tie all of the chapters together. Like that book, it doesn't include much on security, localization, deployment, etc. – you'll need to go to Chris Sells' book for that.

The chapter on design was interesting, but I didn't really feel like the concepts were significantly carried through the rest of the book. The information on data binding was great – so much for my presumption that Windows Forms books wouldn't discuss data binding without databases. Hopefully I'll be able to incorporate data binding into a future Windows Forms application and give my newfound knowledge a try. Also, I wasn't familiar with “custom extender providers,” so I enjoyed reading a bit about those, and enjoyed the article on custom layout engines that he references in that chapter.

All in all, I'm glad to have read the book, and it should make a decent reference book as well.

In a way, Windows Forms Programming in C#, by Chris Sells, picks up where Erik Brown's book (of very similar title) leaves off. While Brown's book spends most of its pages describing and using the various controls that are available to Windows Forms developers, Sells' book doesn't talk much about specific controls. It instead focuses on less obvious (and poorly documented) features of Windows Forms and the .NET Framework in general, features that must be mastered to develop and ship a serious Windows Forms application. He does not ignore Visual Studio .NET, but neither is it critical to have a copy to productively read the book.

Unlike Brown's book, each chapter of Sells' book stands on its own. The book doesn't flow as well from cover to cover, but that's okay, because the information is invaluable. As Sells says in the Preface, “this book focuses on the real-world scenarios that aren't covered in detail elsewhere.” True enough; every chapter has stuff that either I didn't know or I had already figured out the hard way. I was particularly enthralled by the chapters on resources, applications and settings, data binding, and multithreaded UI. Most of the data binding material seemed focused on having an SQL database, but there is non-database-driven information in there, and even notice of a critical bug in .NET 1.x that makes data binding to objects more of a chore. Also be sure to read the appendices, which include a colorful essay on the hows and whys of delegates and events.

In summary, if you're doing serious Windows Forms development, you should make sure that you've read this book.

I just read Windows Forms Programming with C#, by Erik Brown. Well, okay, I skimmed some of it; I can't be expected to read every word of these multi-hundred-page programming reference books.

The book is very focused on Visual Studio .NET, which, of course, isn't bad if you do all of your development in that environment, and don't mind certain things being done behind the scenes, but when I'm learning a new technology, I like to stay away from the big tools. To be fair, he frequently shows and explains critical segments of the source code that is generated by VS.NET, so it isn't all that bad.

The chapters of the book follow the development of a “photo album” application, one step at a time. I really liked this approach; the book flows well from beginning to end. If I was less experienced in Windows and .NET programming, and had a bit more time on my hands, I'm sure I would have greatly benefitted from developing the application right along with the book, experimenting along the way. As it stands, many chapters didn't include much that I couldn't figure out from the documentation. That said, I think that the book makes a far more accessible reference guide than the documentation, and when next I work with a Windows Forms control that I'm not familiar with, I'll be sure to read more carefully the chapter in the book that describes it. The “visual index” in one of the appendices (and on the front and back covers) looks like a great way to quickly find the section of the book that describes any given component.

The most interesting chapter to me was the one on data binding. This book is one of the few that doesn't require the installation and use of an SQL database; it was refreshing to see that data binding is possible even with simple .NET objects. I'll think I'd better read that chapter again...

There are many topics missing from the book – security, localization, deployment, etc. – so you'll have to find another source for material that covers the entire software development process for a Windows Forms application. All in all, I think the book does a good job of introducing the reader to Windows Forms development under VS.NET, providing enough detail to figure out what is possible so you can start coding.

Okay, so I didn't read every paragraph of the 1,579 page tome that is .NET and COM: The Complete Interoperability Guide, by Adam Nathan, but what I read was great. Most of the book is full of useful information that helped me understand how .NET/COM interop works and how to most effectively use it. As for the rest of the book, well, I'll never have to go that deep (I hope), but I'm glad that it's there. Dox Box says it best on the cover of the book: “This is the last book that should be written about COM programming. There is nothing left to say.” Amen.

If you plan on doing anything but the most rudimentary P/Invoke and/or .NET/COM interop, you must own this book. It is both a comprehensive reference and a usable guide, and I highly recommend it. It's so good, in fact, that you might have trouble finding it; as of this writing, it is out of stock at Amazon and other online booksellers!

Oops, one more business book review...

Purple Cow, by Seth Godin, is a short, easy read about the failure of traditional marketing in today's business world. Successful marketing is no longer "advertising" -- it's simply too hard to get people to care, because people in the U.S. already have everything they need, most of the things they want, and don't expect significant differences between brands.

Successful marketing must now be about "remarkable" products, products so new and exciting that "early adopters" will buy them and tell their friends. Designing and shipping such products requires creativity and boldness, but hopefully not as much money as a traditional product that has to compete with established competitors. Remarkable products are targeted directly at the people most likely to buy them, and don't attempt to appeal to everyone, so mass media advertising campaigns are unnecessary. In fact, criticism is a good sign that you've got a remarkable product -- as long as the criticism isn't coming from your target market! The book suggests that releasing potentially remarkable products in which few or none may succeed is less risk than releasing unremarkable products that seem safe but are bound to fail.

These remarkable products, or "purple cows", sound much like the "disruptive innovations" that target "non-consumers" as described in The Innovator's Solution, which makes that book a good follow-up to the basic ideas of this book. The Innovator's Solution certainly makes more compelling arguments for these concepts, and provides better strategies for getting them to work for your company. Of course, no book is going to tell you what the next remarkable product will be in your category, so start thinking!

One last business book review...

Another business book review...

Though it could be considered a business book, this book is really about one specific company and their success, not a blueprint for improving your own business. Taking the interesting facts, stories, and values of Krispy Kreme and applying them to your own company is left as an exercise for the reader. That being said, each of the 12 chapters does represent a worthy value for most any company, and we could certainly benefit from looking hard at each "secret ingredient" and figuring out if we could improve our own business by pursuing those values more directly.

Volume 1 of Essential .NET, by Don Box, is a good book to read when you start to feel comfortable with the .NET Framework. You'll be cruising along with the first chapters, reading things that you already know, for the most part, with interesting new details here and there. Then you'll hit some stuff you really don't know much about, and you'll learn some really cool stuff about .NET. After that, you'll start skimming, because you'll arrive at stuff that you just don't care to know that much about yet, and you'll realize that you'll have to read the book again down the road.

At least, that's how it went for me. I cruised through the first six chapters, though there was certainly some new and interesting stuff in there that I didn't know, particularly near the end of the sixth chapter, where I finally learned how I'd do asynchronous programming with delegates. I started to bog down in chapter seven, though, and tread lightly over messages and domains. The stuff on security was interesting, but I'll definitely have to revisit that area a few times before I get cozy.

All in all, I enjoyed the book in much the same way that I enjoyed another of his books, Essential COM. He certainly does have a “terse writing style,” as he puts it, but it is quite readable considering the fountain of information that's being communicated. I quite recommend the book -- at least read it until you learn something new.

My company encourages us to read business books, occasionally giving a bit of incentive, so here's my review of a book that I wouldn't otherwise have read:

Have you read The Lord of the Rings more than once? Have you at least tried to read The Silmarillion? If so, you might enjoy J.R.R. Tolkien: Author of the Century, by Tom Shippey. I thought that the book would be mostly biographical, but it is primarily a discussion of Tolkien's works -- what he wrote, what influenced his writing, where he got his ideas, why he wrote what he did, what themes emerge from his works, how he compares to other authors, what attracts readers to his works, how to respond to his critics, and, ultimately, why he deserves the title "author of the century." The book was a nice reminder of how much I've enjoyed Tolkien, and helped me to better understand why I enjoy his books. In fact, I may be inspired to start reading my Tolkien collection yet again...

I've been a fair-weather fan of the Seattle Mariners ever since their 1995 season, so the late-season success of the Oakland A's these past few years has been a source of some frustration. Moneyball, by Michael Lewis, describes the secret of the A's success. It's a very interesting read that gave me some insight into baseball team management. The differences between the strategies of the Mariners and the A's were quite apparent; I'll never think about "manufactured runs" the same again. The book has a smattering of profanities, likely indicative of the langauge found in the baseball community. I'd recommend this book to anyone who has wondered how the A's do so well with so little money -- or to anyone who simply wants to read a good baseball story.

I've done plenty of Windows programming, but very little Web programming, so I borrowed a copy of Beginning ASP.NET using C# from a coworker. I wanted an introduction to the basics of ASP.NET programming so that I could begin to feel comfortable with the technology. This book fulfilled my three primary requirements for such a book:

• First, it doesn't use Visual Studio .NET, so I never had the nagging feeling that the IDE was doing anything mysterious behind the scenes.
• Second, the samples are written in C#, which I'm quite comfortable with, rather than VB.NET, whose syntax remains a mystery to me.
• Third, it doesn't spend too much time with databases. One of these days I'll get some database development under my belt, but I'm not there yet.

I didn't need the introductions to C# and OOP, but those sections were easy to skim. All in all, the book served as a good introduction to ASP.NET. Of course, if I ever end up needing to write a serious ASP.NET application, I'll be looking for a book with a little more substance. Hopefully, now that I've read this book, I'll be ready.

I just finished In Search of Stupidity, by Merrill R. (Rick) Chapman. I enjoyed the historical nature of the book; I was too young to care about most of the "marketing disasters" mentioned in the book when they occurred, so it was good to read about them and gain a bit more insight into the history of my field. The book uses a very conversational style; in fact, much of it could be converted directly into stand-up comedy for geeks. That style made the book a quick, easy read, though he occasionally crosses the line into unnecessary crudity. He seems to revel overmuch in the disasters he documents; of course, hindsight is 20/20. I'm not sure I gained any lasting insights into how to make a successful company in technology, but if you're looking for a bit of history and a bit of entertainment, this book is a worthy read.

I recently read Code Reading: The Open Source Perspective by Diomidis Spinellis. I can see how it could be of use to someone trying to contribute to a software project if they didn't have much experience in the language or tools that it used, especially if it was an open source project. I've learned "the hard way" more than I need to know about building and using open source projects, and I've got reasonable experience in a good number of languages and tools, so this book didn't have that much new material for me.

If you'd like to skim a condensed version of the book, you're in luck; flip to the back of the book and check out Appendix E: Maxims for Reading Code, which summarizes the main points of the book in a dozen or so pages. Here's a good one from chapter 1:

You can successfully modify large well-structured systems with only a minimum understanding of their complete functionality. I've always resisted this maxim -- it's more fun to rewrite than modify -- but over the years I've learned that it's true, and modifying existing projects almost always gets the job done faster than starting from scratch, even if the latter seems like more fun.

In fact, all of the maxims from chapter 1 are pretty good, so even if you don't read the whole book, chapter 1 is probably worth it. Chapters 2 through 5 read more like An Introduction to C. The rest of the book seemed pretty intuitive to me -- not many surprises there -- but again, you might find them interesting, so don't avoid the book on my account.

The last chapter is A Complete Example, and shows some of his code reading maxims in practice. If you read that chapter and think you could have done better, maybe this book isn't for you. If you read that chapter and aren't sure you would have thought to do what he did, perhaps the book is worth a closer look.