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 othertwo 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 LocalClasstypedef 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.