The views expressed on this weblog are mine alone and do not necessarily reflect the views of my employer.
 Tuesday, December 03, 2002

Good classic McConnell article pointed to me by JimLittle.  It's called Cargo Cult Software Engineering. It's a fairly short article and worth the read.

In the South Seas there is a cargo cult of people. During the war they saw airplanes with lots of good materials, and they want the same thing to happen now. So they've arranged to make things like runways, to put fires along the sides of the runways, to make a wooden hut for a man to sit in, with two wooden pieces on his head for headphones and bars of bamboo sticking out like antennas—he's the controller—and they wait for the airplanes to land. They're doing everything right. The form is perfect. It looks exactly the way it looked before. But it doesn't work. No airplanes land. So I call these things cargo cult science, because they follow all the apparent precepts and forms of scientific investigation, but they're missing something essential, because the planes don't land.
— Richard Feynman


Updated Link to this post 11:38:57 AM  #    comment []  trackback []

Machine.config versus webconfig.

I've [Gordon Weakliem has] developed some pretty strong opinions on managing configurations, and I've got the scars (and a #12 ranking on Google ;-) ) to prove it.  Someone forwarded me this article by Jonathan Goodyear or ASP Today asking what I thought about storing app settings in machine.config versus web.config.  Off the top of my head, it sounded like a bad idea, but I'm willing to listen.  So I've read the article, and I still think it's a bad idea.  Jonathan's reason for discouraging use of web.config were:

  1. "this approach would require you to change your web.config settings every time you migrated your web application to a different environment"
  2. "Second, it is not a good idea for the development team to know what the QA and production database connection information is, so storing it in the web.config file doesn't make a whole lot of sense from a security perspective"

<snip>
The real headache with configuration comes with managing the configuration.  You need to be sure that as the application changes, the configuration stays up to date, and you need to coordinate use of the <appSettings> section among developers, so that they don't both use the same setting for divergent purposes.  [Gordon Weakliem's Radio Weblog]

I have a couple of thoughts on this...specifically as a retort to the two reasons Jonathan Goodyear had for not using Web.config.  First, yes you have to change some kind of configuration everytime you change environments, but that's easily fixed in a few different ways.

One thing we do is to have the config file during development include multiple configuration sections each named for the stage of dev the system's in and a VERY simple configurationHandler class to manage it.  Kind of an <appSettings environment="test | dev | production"/> kind of thing.  Of course, if Jonathan doesn't want some of the QA secrets known by the Dev team, this is less useful considering that until you strip the dev values at the time of production the config file represents the union of all possible keys.

An alternate way I use to update Config files is via a tool a wrote called ConfigPusher that takes an .config-style XML file that contains the UNION of all keys you'd need in all .config (web.config or otherwise) files - useful for a single logical application like ours that consists of multiple physical Web Apps and Web Services.  You call ConfigPusher from the command line and it updates only the keys that are present in each of the *.config files from the working directory down.  (The master file that represents the union updates only those keys in each config file that intersects with the larger set)  You have multiple configs for debug, test, production and you can update the whole bunch in one swell foop without much trouble.  Each team can have there own configs.  Sure, you're updating Web.config every time you change envionrments, but if this ConfigPusher stage is part of the automated build, so what?  Plus, I don't have to ever look at another config file in notepad again.  (And of course you don't put database connection into in for the production box, it goes in a secure secret location, ssh!) 


Updated Link to this post 10:10:58 AM  #    comment []  trackback []

A picture named ole2cd.jpgCOM was love

This isn't an Enterprise Services crusade. There's a lot of very useful stuff and I am pointing it out. That's all ;)

However, I think I should admit that I did indeed have a very long affair with the entire ES/COM+/MTS/COM family. {Is that a nasty thing to admit?}. The love went away, now we're just good friends.  

October 1992. The first time COM got into customer's hands. I got this CD and I was like "man, that's nuts! Way too complicated!". The first shipment came with docs that dealt in very deep and great detail with IUnknown, structured storage and especially IMoniker. I didn't understand the moniker stuff until two years later. What I understood was AddRef()/Release() and QueryInterface(). An implementation of IUnknown became my default-base class for anything in November 1992. Only about 3 months later I understood how "outer IUnknowns" and aggregation worked. A lot of code-rewriting followed ;). It took about a year to realize that not *everything* should be a COM class. And so it went on and on....

And I just realize... there was no 10th birthday party;) 

[Clemens Vasters: Enterprise Development & Alien Abductions]

Ah, Clemens, you rock!  Thanks for bringing back memories of this CD.  Now I need to go dig up my copy! :)


Updated Link to this post 9:53:54 AM  #    comment []  trackback []