Rob Howard's company, Telligent Systems, is looking for a professional services automation solution.

Scratch one vendor from the list.

Darwin in the business world... the response from the vendor is condescending, spelling/grammar errors, and vehemently anti-Microsoft. The latter point may not be a big deal by itself, but you'd think a Director of Sales would look up a prospect's web site... and maybe look at the "About" page. The first sentence:

Telligent is a solutions company with unique expertise and knowledge of the Microsoft Platform.

I've been subscribed to some Netflix RSS feeds for about a week now. Overall, it's not bad but I had to scale back what I was pulling into FeedDemon. I started with my queue, my recommendations, the Top 100, and the New Releases. The latter two are public feeds for everyone, while the two former feeds are specific to my account. My feelings on them have been:

Queue -- I've found this to be pointless and removed it from FD. RSS is great when I want to be notified that some content somewhere has changed. But when Michelle and I are the only ones changing that content (the queue itself), I don't see much point. Ditto for the "Recent Rental Activity" feed.

Recommendations -- This one is useful in that it puts some titles in front of me that I might no otherwise find. Overall, I find Netflix's recommendations engine to not be as accurate for me as Amazon's or the Suggestions engine in Tivo. I'm not sure why that is, but it seems that Netflix often recommends films that simply have the same actors/actresses as movies I've recently rated. If I'm a DeNiro or Coppola fan, chances are pretty good I already know about their movies...

Top 100 -- This one isn't bad either. It hasn't changed much and I'm not sure how often they recalculate their Top 100, but it's interesting to know what's getting a lot of requests.

New Releases -- I had to unsubscribe from this feed. Amazon's "New Releases" for DVDs (and Music, for that matter) highlights the new stuff that's likely to be of interest to many people. You can then drill down further to see the more obscure releases. The problem with this feed is that it's just a firehose of new releases. Bizarre documentaries, how-to and self-improvement titles, etc. Don't get me wrong, I like independent movies and some of the non-mainstream stuff... but when I'm reading my news in FD, I don't want to sift through 50-60 new titles every day on the off chance that I'll find one or two that seem interesting.

I've listened in on parts of the new Windows Forms series of webcasts, called "Soup to Nuts". They're well presented and the whole webcast deliver They've been fairly basic so far, but the sessions are organized to get more advanced as the series progresses. It seems that the .NET world was initially so focused on ASP.NET and web services, while good Winforms resources were relatively scarce. That's definitely changed, but a strong tutorial series like this is a welcome addition to the resource pool.

As an aside, the whole "webcast" experience has really improved over the last year or two. With the current MSFT webcasts, the streaming seems very stable and it's becoming less of a one-way experience -- you can respond to questions/polls from the presenter, submit questions for the presenter, send requests to speed up/slow down, and so on. Pretty cool.

I've had XM Radio for nearly a year and a half... and have been hooked since Day 1. Rarely do I hear a commercial and there's always something interesting. They've announced a bunch of changes recently, one of which is a new online music service. They're going to charge $8/mo for the service, or $4/mo if you already have an XM subscription for a hardware radio. It's a cool idea, but the press releases makes it sound like you're only going to get a subset of the full channel lineup. I suppose if you've got XM in your car already, this is a good way to pay just a few dollars more and get it at home/work. I went with the Delphi radio, though, which I like because I use it in the car, at home, and in the office.

They also added XPR - XM Public Radio. I listened briefly to it earlier and can't quite tell what (if any) relationship it has to NPR (aside from a few familiar names).

Now if they'd add a weather/traffic channel for Denver/Boulder, I'd be shouting from the rooftops.

I've decided that Justin Rogers is a .NET rock star. His blog posts are math-intensive, but he gets the fact that not all developers interested in math and physics are already proficient at a PhD level. He explains things so well and demonstrates the points with code. Highlights for me were the first "physics installment" (covering collisions) and first "math installment" (on image layouts)... but the poker series is what first got me turned on to his blog.

I had originally started bookmarking the poker entries under a .NET->Poker folder... but when the math/physics started coming, I just renamed the Poker folder to "Justin Rogers" - making him the first blogger to qualify as a category of his own in my bookmarks.

Thanks, Justin, for the time you spend on those articles.

All the troops must be set... I posted some invites to http://gmailforthetroops.com/ and never heard back. C'est la vie... first five to send a request to jdonnici -at- gmail dot com get them. I'll still put a request coming from a .mil address to the top first.

I took Friday and today off to make the Labor Day weekend even longer. After some chaotic times at work, I figure five days at home just hanging out with my family would be great... and it has been. But I'm now halfway through day five and can't believe how quickly it's gone by. But... but... I'm not ready to go back...

So Microsoft announced yesterday that some pieces associated with Longhorn (Indigo and Avalon) would be made available to Windows XP prior to Longhorn shipping. Also that WinFS would show up after the initial release of Longhorn.

Within 24 hours, the Channel 9 crew get Jim Allchin to sit down for a video interview. Ok, so it shouldn't be rocket science to get a Microsoft exec to sit for Channel 9... but the thing that I appreciate is that you wouldn't have seen this a year or two ago. There'd have been the announcement, a few spokesperson quotes in the trade press, and then a whole lot of speculation and whining. I much prefer the new transparency.

As for developer reaction on the delay itself... I don't see cause for concern. Had anyone in their right mind been working on any sort of production system that relied on Longhorn? I'd question that judgment. I think getting Indigo for WinXP (which has been planned and announced) will be great. Ditto for Avalon. But as nice as all that is, it's a ways off... and if you're delivering any sort of meaningful application any time soon, and you're a Microsoft shop, you're working with .NET 1.1. Even if you we knew exactly when these new subsystems would ship, it's worth being cautious before jumping in with both feet on a major new system.

I do think that knowing about this stuff sooner rather than later is a big plus, though I'm sure it means heartburn and tough questions for the evangelist types.

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.