Finally catching up with the last couple of DotNetRocks shows and I just listened to last week's DotNetNuke show. I definitely need to check this out. In a past life, I looked at PHPNuke but found it to be (at the time) a bit convoluted to customize or build modules for. It sounds like Shaun (Walker, DotNetNuke's architect and chief developer... sorry, Shaun, I couldn't find a blog!) took a very flexible approach with it and getting a modular, skinnable site up and running quickly could be useful for some internal projects.

Plus, most of my .NET work thus far has been in the Winforms world, so just going through the project code could be a good education all by itself.

Now to find the time...

Dave Donaldson for President! ;)

This is something I struggle with at work. It's frustrating when colleagues doesn't understand "the why," and even more so when you sense that they don't really care to. It's even more fun when you ask why something was done a certain way and are told "I saw it was done that way in XYZ component, so I copied that code here."

Ever since reading Steve McConnell's Cargo Cult Software Engineering, this is an issue that really resonates with me. You can wave sticks around all you like, but if there aren't any planes on the way, then you're just getting exercise. Not knowing "why" something works (or doesn't) means you're just going through the motions. As McConnell quotes in the article, Einstein said the definition of insanity is doing the same thing over and over again, but expecting different results. Shouldn't take Einstein to see that if you're responsible for building something (anything?), the "why" for the choices you make is more important than "how" they're implemented. Especially with software, where there are usually many ways to accomplish a given task -- if you don't know the "why", then how do you know which method is best?

I'm imagining a conversation with the architect designing my house: Architect: "So then, Jeff, we're going to put a beam here through the middle of this room." Me: "Having a beam there would suck... why do we need it?"  Architect: "Well, that's how it's been in other houses I've designed and that's just how I learned to do it." Me: "Hit the bricks."

Which leads to the "adding value" rant... Dave also mentioned those who just want to get the bare minimum done and go home. If that's your goal, you're not adding value to your organization. These days, "writing code" isn't, by itself, enough to add value. There are people on the other side of the world happy to do that for a fraction of what someone here makes. So how do you add value? My opinion is that you do it by working with everyone in the organization to serve the customer, no matter what it takes. Work with the product people as they figure out what the product should be and how it should evolve. Work with the sales people who know what potential customers are looking for. Work with the support people whose phones ring when the product falls short. Work with the management team to understand the overall business' needs and direction. Be flexible. Be proactive. Be innovative. As cliched as it may sounds, work to see the "big picture".

Anyway, Dave, thanks for a good post. I've subscribed!

Just over a week into the Olympics and I'm finding it hard to watch for very long. We get all the channels that NBC is using to broadcast the games... still, there seems to be a lack of in-depth coverage.

First, the coverage is too US-centric. I know that's to be expected to some degree given NBC's audience, but I'd bet that there are some great background stories to be found in non-US delegations as well.

The commentating is really hit-or-miss. With diving, gymnastics, or other "judged" events, I can barely stand to watch it. You have a pair of people, one of whom is the "regular" broadcaster with the booming voice and the other is some ex-contestant (usually whiney-sounding) who's supposed to give us insight. Instead of insight, though, they're nit-picking the performances. Take diving as an example... I'd like the "expert" to tell me about the dive, the things to watch for, how the athlete may have prepared, how its difficulty stacks up to other dives, and so on. Instead, each dive is dissected to the Nth degree - "Oh, Bob, that'll really cost her there. Between the slight twist [requiring .01 slo-mo replay to see] and the knees not being together [by an inch or so, which the judges seated at the side can't see anyway], the judges just can't give her a good score. There's simply no way she can make it to the next round. Her dream is over!" The best part is when the "expert" is horribly wrong and the judges see it differently. In gymnastics, you could go back and watch the individual competitions, both won by US athletes with some big mistakes early in the competition, as an example -- the "experts" wrote them off as non-contenders and they're now wearing gold.

Not enough coverage of "smaller" sports -- last weekend, I happened to catch a couple minutes of highlights from a 10m shooting match. It was great... the commentating was informative, not critical, and I was fascinated by it. I learned a lot about a sport I know nothing of. Unfortunately, there was a US athlete somewhere with a camera pointed at them, so NBC had to cut away.

Medal counts? Who cares? I want to see competition, regardless of who's in the event. And sure, I'll root for US athletes much of the time, but I just want to see great performances from athletes I wouldn't normally get to see. And yes, I'd rather sit and watch the Iraqi mens soccer team than the US men's basketball team. I can watch overpaid, whining primadonnas all through the NBA season. How often can I watch a group of athletes who practice on dirt fields, can't play "home" games in their own country, and have to be airlifted by military planes out of their country. That's a group I can root for.

In my opinion, there are a couple of things that combine in the current .NET Framework to form a void (wait, can two things combine to form a void)? Those two things are the strong preference for .config files over registry storage (a preference I agree with), and the lack of API support for writing config files.

The ConfigurationSettings class is great for reading your app.config or web.config file... but that file is specific to an application and not to a user. So while it's useful for storing things that are typically app-wide (database connection details, logging levels, etc), it's pretty much useless for storing user preferences. These usually include things like remembering a user's window size/positions, preferred file locations, or other user-specific settings.

There are lots of articles and samples online that suggest options for getting around these limitations. My opinion is that most of them fall just short of being complete solutions, though, and the reasons tend to be along these lines:

They don't allow for strongly-typed access to the preferences. To be really useful, reading and writing preferences should be idiot-level simple for the developer. If the dev has to write several lines of code to cast preference values to/from a string for storage, they're gonna skip it. The result is an app that's less flexible for the user than it could be. Another benefit of strongly typing the preferences API is that Intellisense helps the dev access the settings without having to remember key names.

They use INI files or the registry. Since the release of .NET 1.0, MS has steered developers away from using the registry. The registry is generally recognized to be a system that's prone to corruption and using this approach makes XCopy deployment a real pain. INI files are a fairly simple way to go, but they don't allow for a nested hierarchy and you end up dealing with a lot of parsing code. You also can't easily define metadata about each setting. .NET gives us a fairly rich set of APIs for XML, so why not use them?

They provide write-access to app.config. There are some articles that provide a wrapper for the app.config so that the developer can read and write to the file. There are a couple of problems with this -- first is that it's an app-wide file so all the user profiles on a shared machine will have the same settings. Second, app.config is in the application's startup directory, which is usually under \Program Files\. Standard user accounts under Windows don't have the ability to modify program files, so this option only works for Admin or Power User accounts. A better solution is to store preference files under a user's profile (\Document and Settings\[user]\Application Data\) -- even better is IsolatedStorage.

They use lots of files. Many articles and samples use XML serialization as a way to read/write preferences. It works well, but the suggestion is often to have a base Settings class and then many component-specific subclasses. Each component manages its own settings class, reading and writing as needed and then calling inherited members to serialize and deserialize the object. Maybe this isn't much of a problem, but for some reason it seems less elegant to me. The apps I work on tend to be large, modular Winforms apps -- lots of individual components, in which case I'd end up with a lots of files on the user's machine. Also in this scenario, components actually have to be aware of two types of settings -- their own settings and the app-wide settings that the user specifies. It gets worse if you have components that want to share some types of settings.

So do I have a solution for all this? Not yet. But I am reading as many articles and samples as I can find, making lots of notes, and trying to form a clear picture of what I think would be the "mother of all settings APIs". Admittedly, this would be with a bias toward Winforms apps. So far, there are two recent articles that are along the lines of what I'm thinking. These are Building a Better Configuration Settings Class (by Rick Strahl) and Manage Users Settings in Your .NET App with Custom Preferences API (Ray Djajadinata in July's MSDN Mag). Both of them offer good, complete coverage of the issues associated with a settings API.

At work last year, I built a fairly basic XML-based API that stores user preferences but it does suffer from a couple of the problems above -- most notable is that it's not strongly-typed. So... my current plan is to spend some off-hours going through the two articles above, continue to make note of the various ideas that are brewing, and then coming up with a new design that incorporates the pieces and parts that I think are important.

So with all that... am I missing any other key needs from a preferences API?

The Iraqi men's soccer team is playing Costa Rica today, after serving a big upset to Portugal last week. The current FIFA rankings have Iraq ranked 40th in the world, with Portugal at 12th.

Since the US men didn't qualify for the Olympics, I'm hoping the Iraqi team can make a solid run for a medal. These guys have dealth with torture, imprisonment, infrequent training, having to go to another country for "home" games, and being airlifted by the military out of their country. Given all that, and the uncertainty of things in their country, I'm really hoping these guys can make a run at a medal.

And to the players themselves... if you guys could find a way to abuse the Mexican team, that'd be much appreciated!

... that your team's coach is sure to get fired, they come from nowhere with a big win. The fact is, the team's lack of offensive production should mean they don't get into the playoffs. But under the MLS system this year, 4 out of 5 teams in each conference are in -- so as long as one team in the west sucks slightly more than the Rapids, they're in.

Please, Stan, do something.

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.