I actually finished reading this in March but have not gotten to writing about it until now. I'm falling a little behind and may have to skip my April reading and merge it into May. Ah well...to the story at hand.

This book was an excellent read and in an ideal format for me. The book is a collection of internally published essays within Microsoft that encompass a vast amount of topics regarding software development processes, management, coding, testing, career development, etc. The essays provided a great way for me to read bits and pieces in between work items and take the book in over the course of the month.

The essays were written by Eric and are not the standard "hooray for Microsoft and how we do things" line that you would expect. The essays tell it how it is and point out what Microsoft is doing / has done wrong and what they should be doing. In addition, the essays provide sane, to the point insights regarding industry tendencies, the good and the bad, and corrections that need to be made both from a practical and a theoretical point of view. They are by no means all encompassing, but do cover a good variety of areas.

I would definitely recommend this book to anyone who is planning on making a career out of software development. By career, I do not mean a tech-head who only cares about coding and nothing else. I also do not mean that you have to aspire for IT management. The book applies to anyone who is or wants to be involved with the software development life cycle as a whole.

Well, I finally finished Debugging Microsoft.NET 2.0 Applications by John Robbins. It took a while for a few reasons. First, I was reading a second book a long with this one that I’ll be finished with shortly. Second, work has been tremendously busy lately. Finally, the WinDbg section of this book is excellent, but can only truly be taken in when doing it in a hands-on manner.

This book is another one of those great desktop references for .NET, alongside of CLR via C#. At first thought, many would probably right off the book based on its title thinking that debugging in .NET is so easy that there is no need to read a book on it. However, this book provides an excellent footing on how to develop in a more debuggable manner, as well as, how to perform more advanced debugging; i.e., WinDbg. Of course, some of the book is the basic information that any seasoned developer is already going to know. Of particular interest to me were the sections on Symbol Servers and Source Servers (not SCMs) and their relation to doing hardcore debugging with WinDbg. Without a guide to get you started in WinDbg, I would think that it would take a very long time to come up to speed with its archaic IDE.

The only thing I did not like/agree with was the author’s obsession with Debug.Assert. Personally, I rarely use Debug.Assert. I prefer to catch my ‘assert’ scenarios and throw a proper exception. His lengthy argument and protesting did nothing to change my mind on the subject.

WinDbg is a great tool once you can get passed some of its archaic syntax. For advanced debugging, I know of no other way to dig deep and solve the problems. For hard core memory or threading issues, WinDbg is a must have. So, that being said, a colleague of mine gave me this listing of common WinDbg commands, which he grabbed from somewhere out there and added to. I then added more to it as I read Debuggin Microsoft.NET 2.0 Applications by John Robbins. So I am putting it out here for further reference.

Mark's WinDbg Common commands.doc (75.00 kb)

I recently obtained a Safari subscription from O'Reilly which has already and will continue to interrupt my planned reading schedule of 1 book a month. The idea behind Safari is to bring as many books from as many different publishers as possible and make them conveniently available for a monthly fee. Safari consists of mostly technical books although a nice selection of business books is available as well, available from multiple big name publishers. This has started to make me a little A-D-D with my reading though as I bounce around from book to book. There are just so many books on there that I want to read that I am having trouble sticking to just one book and reading it all of the way through.

The service is great, but here are a couple of the bad points:

1. Individuals cannot get a subscription to their full business library. The technical library has a limited number of business books in it.

2. Reading everything online is not exactly the most comfortable experience, and Safari does not really go to great lengths to make it easier. They have a print fidelity mode and an html mode, but neither really solves the problem of having to scroll to read.

So I hurried through this book as to immerse oneself in it would take months. Plus, the majority of the patterns mentioned are just formalizations of ideas that I have come across naturally throughout my programming career. At the same time, I wanted to read it to fully familiarize myself with the terminoligy and maybe pick up on some new concepts. Honestly, I have to think that there are better design pattern books out there that explain them in a more concise and obvious manner than this book does. The book is now dated by 13 years which is several generations in software life. This is the grand-daddy of design pattern books and must be given its due respect. I don't own the book, and I am still undecided on whether or not I will purchase it to keep as a reference. As I said, there have to be better design pattern books out there. However, for the time being, I am done reading about design patterns and am moving on to Debugging .NET 2.0 Applications for February.

A little late on finishing this one as I got distracted by quite a few things, but I did finish it. All-in-all this book is an excellent read for anyone wanting a more in-depth understanding of .NET/CLR under the hood. There are several rants that Jeffrey goes into that I wish would have been left out or at least put in comment boxes. He mixes his opinion of coding standards and styles in with the factual information he provides, and I just would rather not see that. I am reading the book for the facts not for his coding style opinions. Regardless, he still provides a great deal of excellent information on the likes of Garbage Collection, Reflection, AppDomains, Threading, etc... It is not a tell-all book about each subject, but it does go into the kind of information that you just will not find in many other places. There was quite a lengthy bit in the middle of the book that seemed like filler material to me where he goes into "Essential Types". There were tid-bits of good information in there, but not enough to warrant the 150 pages he dedicated to it. However, in summary, any serious .NET developer should read this book or have it as a reference. I just hope some of it will sink into my thick skull. I plan on keeping it handy as a reference as well, as there was so much in there that I am certain I will not be able to retain it all.

.NET has two properties to help in determining that things are coming to an end. The IsFinalizingForUnload property off of an AppDomain tells whether the application domain is in the process of unloading. The HasShutdownStarted property off of the System.Environment class tells whether the process is being terminated. These may be useful properties to know about under certain circumstances, although I have not had an opportunity to employ them.

CriticalFinalizerObject is an abstract class in .NET (System.Runtime.ConstrainedExecution) that gives the following to its inherited classes:

1. As part of the class' construction the CLR JIT compiles the finalize methods in the inheritance hierarchy. This helps guarantee that the finalizer will be able to be called, even under low memory conditions when the JIT compile might not be able to function

2. The finalize of method of derived classes happens after the finalize method of classes that do not derive from CriticalFinalizerObject.

3. The finanlize method will be called even under a sudden abort by the application host.

If you are in a catch block that has not specified a catch type variable; therefore you do not have an exception variable, you can use $exception in the watch window to obtain the reference to the exception.

The Power Collections library, original developed by Wintellect at Microsoft's request is freely available on codeplex. The library includes many generic list classes that I wish were available directly in .NET. Here is a sampling:

Bag<T> - Collection of unordered T objects; hashed; duplicates allowed

OrderedBag<T> - Collection of ordered T objects; duplicates allowed

Set<T> - Collection of unordered T objects; duplicates not allowed

OrderedSet<T> - Collection of ordered T objects; duplicates not allowed

Deque<T> - Double-ended queue

OrderedDictionary<TKey, TValue> - Dictionary with ordered keys; one value per key

MutliDictionary<TKey, TValue> - Dictioniary where key can have multiple values; keys are hashed; duplicates allowed; items unordered

OrderedMultiDictionary<TKey, TValue> - Dictionary where key can have multiple values; keys ordered; duplicates allowed