Last week's .NET Rocks show with Jeff Richter was a great one. I always find it interesting to hear about the types of things that went (and are still going) into the design/implementation of the CLR. During the show, Jeff mentioned a couple of tips for helping the garbage collector be more efficient.

Keep object lifetimes as short as possible. I think this is essentially the same advice that's usually given for dealing with unmanaged resources (file streams, database connections, etc) -- get it late, release it early. It also tells me that I need to do some more reading up on WHY this is the case in the GC. My assumption is that it has to do with objects getting promoted through various levels of the GC and how often it runs through to free up memory. Definitely need to get a good book on the CLR guts. Suggestions?

Keep the call stack as short as possible. Again, I'm not sure why this is and plan to read up on it in more detail. But it does seem at odds with the common design/implementation goals of loose coupling and short methods. Usually, you want lots of small, cohesive objects that work together to form a larger component. Within those objects, you want relatively short methods that can use one another to perform an operation (do one thing, do it well, and do only that). The side effect of that approach is that the call stack gets fairly deep in short order. It may be that 95% of me experience in .NET  has been in the Winforms world -- wherein applications typically (and as was mentioned on the show) are going to have deeper call stacks than ASP.NET applications.

Anyway, interesting stuff... now off to find some good under-the-hood GC resources.

The more of his "Business of Software" articles I read, the clearer it is that Eric Sink just "gets it". I've read the BoS series on MSDN from the start, as well as his various weblog posts, and it's clear that he's spent a lot of time pondering what makes development really work. I also like that his advice obviously comes from someone who's been "in the trenches", understands real-world commercial development, and lives it each day. The series on the "22 Immutable Laws of Marketing" is a great example of his ability to break down software-business issues for the pocket-protector crowd.

This latest MSDN article is a good summary of things to look for when hiring developers into your team. What I really like is how he refers to "shrinkwrap qualities" -- those qualities that differentiate a good programmer from a good commercial-product developer.

My own experience is that there are lots of developers who pay lip service to OO design, architectural consistency, reuse, current documentation of all kinds, and so on -- but not all developers maintain that discipline day-in and day-out. And an even smaller percentage of those have the "shrinkwrap qualities" -- the ever-present understanding that what they're writing will eventually be in the hands of a paying customer. And while a well-designed, elegantly implemented software product is important (especially for the on-going maintenance and evolution of the product/product line), the end-user just wants an application that helps them get their job done and make their life easier.

Go forth and subscribe.

So I've had a seller's account on Amazon.com for years. Michelle and I often put up books we're done with or CDs we no longer want. You get an email when someone bought something from you (via the "Used & New" links on each product page) and then you have a couple of days to get it in the mail. Sometimes, after we've done some spring cleaning, that seller account can get up to a few hundred dollars.

Every 4-6 weeks or so, they transfer it to your bank account and send you a nice little summary of the transactions. Then you've got some side money with which to get more books, CDs, or movies... right? So where should you go to spend that money?

Well, what they DON'T offer is an option to just credit your regular Amazon.com account with the money in your seller's account. I don't get that... all they need is to provide a "Convert this balance to an Amazon.com Gift Certificate" option and they'd often get that money right back. Doing that leads to potentially three transactions that make money for Amazon -- My initial purchase of an item, their fee for me selling that item on their site later, and then another purchase using the proceeds from that sale.

I've emailed them about this before (have fun finding an email address on their site), but just got a boilerplate "thanks for your suggestion" response... so, what am I missing?

Andy Hunt and Dave Thomas, authors of The Pragmatic Programmer, did an interview with Artima last year and somehow I missed it until this afternoon. Great stuff here, but the part I enjoyed most was right up front when they talk about craftsmanship and how easy it is to fall into a trap of "I work on this piece and only this piece" on large projects. They refer to a quarry worker's creed -- We who cut mere stones must always be envisioning cathedrals.

The idea, of course, is that even those who work on small pieces of a much larger puzzle have to have the big picture in mind. Without that, the result is a finished project that lacks an overall, complete vision. Ok, so your part of the application is the database design, or the exception management, or the communications layer -- all are parts of a larger work that couldn't be built by any one person. Work on the stones but think of the cathedral. Take pride in your gargoyle.

The interview is well worth a read.

On that last post, I started to think about the similarities between my approach to code samples/mini-projects and my approach to organizing favorites/bookmarks. I'm pretty religious about "collecting" bookmarks for cool things I come across. With .NET articles, in particular, I've got about 15 different sub-folders under which I store bookmarks. Those sub-folders are for things like CLR, Exception Mgmt, WinForms, XML, SQL Server, Threading, Unit Testing, and so on.

I've got a pretty good collection of many different articles, from MSDN articles, blog articles, and other sources... the thing is that I'm really bad about going back and referencing them. Instead, when I'm on a project and need some info about a topic, I again go to Google.

Is storing all those favorites in Firefox a waste of time?

I really need to figure out a good way to organize code samples and little "test" projects. On my data drive, I have a folder called \download where Firefox puts all my downloads. Over time, that folder grows pretty large and I have no idea what some of the .ZIP files in there are. Often, I'm downloading code samples and utilities to look at but I need a good way to organize the stuff I want to keep.

I've started setting up a "Code Samples" directory structure, with sub-dirs for "WinForms", "WebServices", "XML", CompactFx", etc... but I'm not sure if that's going to be useful.

And a big part of me thinks I should just delete all but own little "test" projects... for all the little downloaded samples, there's always Google.

I just came across the blog of Alan Cameron Wills and had to subscribe in my feed reader. His first post, back in April, covers a development topic that is near and dear to me -- de-coupling components so that the parts of an application can be viewed independently. If you've done it well, adding/changing components to the overall system is trivial.

In the past, I've used the phrase "build a platform" to describe the approach, but the idea is the same -- rather than try to eat an elephant all at once (tackle a big project), take it in smaller bites (break the big project into small projects). View the app as a platform on which you can build components and capabilities.

Alan focuses his blog topic on the independence of those smaller projects (and says it all with far more clarity than I could). When you view a big project as a set of independent, smaller projects, it's easier to add other small projects (new components) later. If you go in with that thinking up front, your architecture is far more "pluggable" than if you view it as one big application and just start tackling it "a form/function/feature" at a time.

Good reading.

So I started using Mozilla Firefox about a month ago and I think it's official now -- it's my primary browser. It's got so many cool things that IE doesn't have (at least not yet). Things like tabbed browsing, quick searches for links in a page, a much nicer bookmarks/favorites manager, and built-in popup blocking.

The tabbed browsing thing alone is worth the switch, given that I very rarely have only one browser instance open at a time. More often, it's a handful of different articles, google search results, or news stories. I also like that you can save an entire set of tabs as one bookmark and return to them all via that single bookmark.

Another very cool feature is the ability to block images based on the domain in the IMG "src" element. I never see images now that come from the common banner ad servers. 

And the extensions/plugins being built are amazing. I use the GoogleBar (essentially the Google toolbar), a Flash blocker (it replaces Flash with a small logo that you can click if you want to view it), and a bunch of web development and related extensions.

Oh yea, it's also free.

So are there things I miss from IE? Sure... there are still a number of sites that don't work well in Firefox. IE's by far the most popular browser, so some designers don't bother to test their sites in other browsers. When I run across those pages, I use a Firefox extension that puts "View this page in IE" on my right-click menu.

Whoa, I nearly missed this... Mike Schinkel, who runs Xtras.NET is offering a free XDN membership to .NET bloggers during this month! He posted the offer on his personal blog, so get on over there if you're blogging about .NET development.

While you're there, check out Xtras.NET -- I just found out about it through Mike Gunderloy's site. Holy smokes, there's a lot of info there. They carry a ton of .NET components and tools, with lots of information about each -- and the prices look very competitive as well. The thing I really like, though, is the user-reviews. That's the toughest thing about buying components -- you can read all the marketing stuff, even try the evals for a few days... but nothing beats hearing about it from someone who's worked with a tool for months, day in and day out.

And a printed catalog? Sign me up!