Push Comes To Shove

In many ways the rampant podcasting enthusiasm reminds me of the big "push" furor back in the mid-90s, with everyone racing to incorporate the quickly abandoned channel technology (though it re-emerged as the influential and prolific, simplified RSS years later), all desperately trying to get a piece of the short-lived PointCast-style action.

The essence of podcasting - the most important benefit to many users - is really nothing more than the so-called Long Tail of audio files: Anyone can create an audio file (usually an MP3). From a listener perspective, no longer do you have to sit by the radio at a set time to listen to the talk show produced and distributed by the few elite with the money and the power to run a radio station. Instead, you can now subscribe to a wide array of content from around the world, created by both the aforementioned mega-media firms, but also by a guy in his basement talking into his microphone.

Technically podcasting is the inclusion of file references into the so-called "push" technology RSS, which usability-wise means that instead of endlessly searching around websites looking for audio files, manually downloading and then transferring files to your player, your podcast client software automatically detects when new audio files are available for the feeds you've subscribed to, it usually automatically downloads it (alternately it may provide you with a synopsis of each show, letting you manually select which ones you're interested in), and often even transfers it to your audio player (e.g. mp3 player, iPod) the next time you sync. The definition of podcasting has been expanded to include virtually any sort of media (or even non-media) attachment, expanding the scope to an unusably vague level, so I'm just going to focus on the audio aspect because that's the prevalent context.

As mentioned before regarding usability, small usability improvements can dramatically change the usage of a technology. In the case of podcasting, the theory is that while there have been audio programs available online for years, "push" enabling it would dramatically increase consumption.

Listener's Choice

Personally I don't think usability has ever been the limiting factor for audio files - It's more efficient for me to browse IT Conversations on occasion than it is for me to find a selection of good feeds to subscribe to, and then spend all of that bandwidth and memory space on a bunch of podcasts of uncertain quality and topic (even if I like a particular podcast feed in general, the likelihood that a particular episode is going to interest me is actually low). I don't even subscribe to IT Conversations' feeds - despite it having one of the best content records in the business - because the majority of the interviews aren't of interest to me: For every interview that intrigues me, many more are in a domain or with a personality that I can't allocate the time to focus upon.

I'm not going to eat the gruel just because it's what they happen to be serving today.

Is the content and distribution problem really the reason you don't have more talk radio in your life?

At a more fundamental level, though, podcasting is primarily a creation and distribution expansion of the previously mentioned talk radio. Is the content and distribution problem really the reason you don't have more talk radio in your life? Do you even know what talk radio programs exist in your area, available 24 hours a day from any tuner available?

Probably not.

Difficult to Stomach

Talk radio is something that most people aren't interested in. Talk is something that is difficult to consume without a good amount of your attention (I've found it close to useless - and destructively distracting - playing audio interviews in the background while working), it's difficult to efficiently vet (e.g. I can jump to a blog - or scan a newspaper - and know what interests me or not in seconds. A podcast requires some time to gauge its usefulness in your life), and it's often far less efficient than the alternatives. I can absorb someone's point from their writings enormously more efficiently than I can listening to them ramble on about this and that. It's generally difficult with audio files to jump to the pertinent parts that interest you (there are seldom even indexes or transcripts), so you have to take the chaff with the wheat. It's like that guy who leaves the long, rambling voicemail messages, in which are hidden a tiny nugget of useful info, instead of just sending a concise email.

If it's slow to parse, difficult to scan, and requires a fair degree of one's attention, the reasonable expectation nowadays is that it should have useful, informative video going along with it to increase the utility and value. The .NET Show is a pretty good video feed - with a great transcript that lets me jump where I want with ease to avoid the filler - though of course it's infrequent enough, and covering such a variety of topics, that any sort of automation is useless for it: I just visit the site every month or so and see if the latest outing interests me. While one month might be great, the next might be 90 minutes of someone pushing some questionable vapourware with a delivery promised in 2 years.

Of course sometimes rambling in audio interviews - the filler - is extremely valuable, and people betray information and convey knowledge that they would never have put into words - some of the conversations with industry veterans and superstars on IT Conversations are brilliant for this - but in general talk is not an efficient information medium in an information domain. Highly technical audio podcasts are truly absurd.

Everything Old Is New Again

Remember the excitement about webcams a few years back? Several sites made it easy to find people's webcams, so the presumption was that we would all start consuming. For a short while it was true, and people entertained themselves looking at downtown webcams, goofy people with webcams, and so on. Then the interest faded, and we realized that it really wasn't that interesting.

This has repeated in a variety of technology spheres, where a simple repackaging of content that otherwise had little interest earned short-term euphoria and early adopters, but quickly fizzled out as the buzz and the eliteness subsided.

The novelty quickly wore off, and the utility of the underlying content failed to maintain any level of continuing support.

Tagged: [podcasting], [podcast]

I've come across this question quite a few times.

I have rows with lots of columns, and would like to split it out so that each column is a row

Imagine a scenario where you have a wide table that you'd like to normalize, at least in view or façade (or perhaps in a data transformation layer) - You'd like to un-pivot it, rotating columns into rows.

For a sample, I'll use the questioner's scenario of a Person table with a variety of attributes. Don't get hung-up on the table or whether it's already normalized (the sample came directly from a user who had a rather unique need), the point is simply rotating columns into rows.

You'd like to return a set like the following:

(rows truncated for some brevity)

SQL Server 2005 offers the UNPIVOT operator of the FROM clause, which can made quick (albeit unintuitively and inflexibly) work of this specific need.

SELECT   
  ID, tblPivot.Property, tblPivot.Value 
FROM   
  (SELECT ID,
     CONVERT(sql_variant,FirstName) AS FirstName,
     CONVERT(sql_variant,LastName) AS LastName,
     CONVERT(sql_variant,Age) AS Age
   FROM Person) Person
  UNPIVOT (Value For Property In (FirstName, LastName, Age)) as tblPivot

The use of the derived table in the FROM clause is purely to cast the columns to a common data type, as this is a requirement of the UNPIVOT operator. Otherwise all of the source columns would need to have the same type (precisely the same type).

Note that the IN list has to be a literal, concrete list - you can't pass a table variable or subquery. Always perplexing when they limit these sorts of operators in this way.

With SQL Server 2000 you can do this via simple unions or temporary tables

SELECT 
 ID, 'FirstName' AS [Property], CONVERT(sql_variant, FirstName) AS [Value] 
FROM 
 Person
WHERE
 FirstName IS NOT NULL

UNION ALL

SELECT 
 ID, 'LastName', CONVERT(sql_variant, LastName) 
FROM 
 Person
WHERE
 LastName IS NOT NULL

UNION ALL
SELECT 
 ID, 'Age', CONVERT(sql_variant, Age) 
FROM 
 Person
WHERE
 Age IS NOT NULL

In this case we've made the common type sql_variant, though obviously you should alter according to your data. We've also decided to eliminate null values (so there aren't null property rows), though that depends upon the need.

Another option is to make a programmatically flexible alternative that automatically adapts to the schema of the table (within constraints). For instance consider the following script.

SET NOCOUNT ON

DECLARE @table sysname 
SET @table = 'Person'

DECLARE @id_field sysname 
SET @id_field = 'ID'

DECLARE @sql varchar(8000)

-- create the schema of the resulting table 
SET @sql = 'SELECT TOP 0 CONVERT(int,0) AS [ID], '
 +'CAST(0 AS nvarchar(4000)) AS [Property],'
 +' CONVERT(sql_variant,N'''') AS [Value] WHERE 1=0 '+CHAR(10)

SELECT @sql = @sql + 'UNION ALL SELECT '+@id_field+', N'''
 +COLUMN_NAME+''',CONVERT(sql_variant, '
  +'['+COLUMN_NAME+']) FROM ['+@table+'] WHERE ['+COLUMN_NAME+'] IS NOT NULL '
  +CHAR(10)
FROM 
  INFORMATION_SCHEMA.COLUMNS 
WHERE 
  TABLE_NAME = @table 
  AND COLUMN_NAME <> @id_field 
ORDER BY COLUMN_NAME

IF (LEN(@sql) >0) 
BEGIN 
 EXEC(@sql) 
END

In this case it uses the object schema, though you could alter it to go against a property table or the like.

Standard disclaimers about injection attacks and all of that apply (presumably you won't be calling this with untrusted input), and of course it won't work if you have composite keys, or if you have so many columns that the resulting SQL exceeds 8000 characters. Adapt accordingly. It also does no sorting, so add as you need it.

Tagged: [SQL Server], [SQL-Server]

I've been noticing something interesting with Google lately - While the rankings of this site have been increasing, the number of search engine hits against blog entries has actually been dropping: A week ago several entries in this blog were among the first page results for a number of terms (albeit less common terms), whereas now they've virtually disappeared. Given that other parts of the site are still seeing significant search engine directed traffic (in fact more than ever), it clearly isn't anything site-wide.

What I suspect is that Google has started identifying content as blog/not blog, as has long been anticipated, and if it's perceived to be the former then it is de-valued a degree. Identification could be as simple as checking for a synchronized RSS, or elements like calendar controls and the like. If it looks like a blog, reads like a blog...

There is a legitimate reason for that sort of segregation: The promiscuous linking of bloggers has drowned out `traditional' content, so much so that many searches were going to blog entries that happened to mention something in passing, even in a content-free, largely useless manner, making the use of search engines a frustrating, less-effective exercise. Discussion groups have been flooded with commentary about evil bloggers polluting the Google rankings (blaming bloggers for what is, in essence, a search engine problem).

Naturally Google's first step was to give bloggers a `home' (the Google blog search), and step two, I suspect, is to start cleaning up the search results.

If this is true, on the one hand I'm happy about it - it means that every search result isn't going to return every random MSDN blogger that's highly ranked just for being a part of the conblogation, but on the other hand it punishes those who use a blog format as a content management system of sorts.

Anyways, because I like appearing in the search results, I've created a new category and have started checking off "best of" posts. Through the magic of two XSLT transforms against the RSS of that category, and a bit of customization, it's now being replicated in non-blog-form over at http://www.yafla.com/dennisforbes/index.html. I've SEO'd the path and file names, and of course set appropriate titles on the documents (given that it's a single item per file I can do this), so content will definitely see more seach love over there. The layout is a bit ugly right now, but given that it's just a templated, dynamic transform I'll clean that up when I get the time.

One of the huge stars of the early Internet was e-cards - static, animated-GIF, or Flash alternatives to a standard ink and paper Hallmark card, not to mention that you could save yourself a couple of bucks and the hassle of going out and buying and mailing a traditional card (the biggest boon to men like myself was that you could quickly send one off on the day in question - no event pre-planning necessary).

One of the biggest successes of the e-card phenomena was Blue Mountain. My first experience with Blue Mountain was actually by mistake - I was looking for some ski conditions, and instead of http://www.bluemountain.ca/ I entered http://www.bluemountain.com. Of course I capitalized on my mistake, immediately sending some goofy e-cards to friends and relatives. Of course many of the recipients started using the service as well. I suspect that the tipping point for that company - the contagious source vector - came when winter rolled around in Ontario and the powder was just right, and lots of misdirected Ontarians figured they might as well use the service since they were there.

During those early days e-cards were sent in bulk. It was good times in the e-card business, and marketing was easy: Every recipient was encouraged to send their own e-cards, so growth was exponential.

Excite @ Home bought Blue Mountain for a blistering $780 million dollars in 1999.

Of course, as with most quick-ascent fads, people started to question e-cards: It the sentiment was so cheap, and required so little personal effort, was it really a substitute for a real card? Was it just a thoughtless form of spam, quickly discarded and ignored? It didn't take long for that sort of feeling to pervade the marketplace.

If this were an episode of Behind the Music, dark and disturbing music would be playing. The Dire Straights of e-cards were upon the industry.

Excite @ Home unloaded Blue Mountain for $35 million in 2001. If the business were individually valuated today, I highly doubt it would come anywhere close to even that number.

This thought came to mind given the almost-absence of e-cards I've seen this holiday season. Perhaps it's just me, and my network of contacts is unique in its reliance upon traditional cards, but it is a remarkable contrast. I did receive one e-card - from a web host - and quite honestly it bordered on a bit offensive getting a holiday greetings card that I know was spun off from a mass mailing script.

Project Completion

You just finished a gruelling six-month project to create the Greatest Software Widget Ever Made. Your blood, sweat and tears have been invested into what you believe is a first-rate solution, whether solving a corporate need, or building a better mousetrap to bring untold riches to your ISV.

You email news of your accomplishment to peers and/or clients, proudly sitting back to await the certain accolades.

Amidst the expected congratulations, one reply makes you uneasy. "So it basically does what Project X does?" it asks.

Surely they must be mistaken, you think.

You fumble through the feature sheets for Project X to discover that, sure enough, on paper it does everything that your solution does, and in some ways it is arguably superior: Maybe it supports a richer set of features, is cross platform where yours isn't, or it's a component of a more-complete integrated solution where the whole is greater than the parts.

On paper, at least, it is a better solution.

The Damage

If you're an ISV, you've just discovered that you have more competition than you thought you did. This could impact your market in a wide range of ways.

• Perhaps it's a very expensive product from a company like BEA. You can easily underprice them, and it represents little threat to your product (it might actually help you make sales, giving you a much more expensive product to contrast with in sales pitches). Great stuff!
• Perhaps it's the complex potential use of an existing system that requires such a high level of expensive modules, customizing and programming that it turns out to be much more expensive and risky to actually use.
• Maybe it's an esoteric open-source project with a highly convoluted code-base, few developers behind it, and it requires significant knowledge to configure and use. It represents only a theoretical risk.
• In the worst-case scenario, the alternative is a free, comprehensive, elegant and usable alternative that is quickly becoming widely known. Your market has been devastated, outside of selling in hopes that your customers are blissfully unaware (which is rightfully morally difficult for most people).

If you're a corporate developer, it could simply be a demotivating signal of time wasted (developers are heavily motivated by seeing their solutions doing "good" in the world. Dumping code they invested time and passion into is heart-wrenchingly demotivating. "What have you been working on?" "Well, I spent the last year working on a project that was dumped for Microsoft BizPoint 2009 before delivery"); it could just be ammo for the office Machiavellian (I've was criticized in the past by just such a coworker for not leveraging a "possible solution" that wasn't even invented until two years after my project was deployed, so such Machiavellian Jr's aren't even bound by the constraints of time); or it could be a career killer.

In the corporate space things can get even uglier, as products from the big names like Microsoft will be preferred, however ill-equipped for the task they actually are: If they marginally seem to apply to the problem, there will be those who push for it. Sometimes this strategically makes sense (e.g. if you adopt a new product early, it'll likely evolve quickly if it's developed by a company with the resources that Microsoft has, for instance), but often it's just corporate hubris. Some organizations have a love-hate (mostly hate) relationship with their IT department, so any opportunity to undermine and reduce the dependency on them, even if it involves a more expensive, less-flexible, less-empowering solution, will be pursued. I worked at one shop where a large team of developers worked for years perfecting and expanding in-house solutions, while at the same time the organization continually and openly quested to replace everything they did and were doing with externally sourced solutions. The effect on motivation was profoundly negative, but it was the result of a Better Not Be Invented Here mentality, coupled with a negativity opinion of IT.

The Smaller Scale

Of course such an overlap of functionality or use isn't limited to whole products. It applies to even the smallest component of our projects.

Developers face this sort of issue regularly: From cryptography libraries to database abstraction tools to MVC frameworks to simple coding standards - For virtually every single need, there are solutions that purport to solve all ills and fulfill all needs. Somewhere amidst the 100,000+ version 0.1 projects on sourceforge, the huge catalog of software and feature lists provided by organizations like Microsoft and Oracle, or the millions of projects on the web, and even amongst the libraries and frameworks already included with our platform, there are possible competitors.

From a more optimistic perspective, they are possible allies - code and existing research and knowledge that you can leverage to make your solution better. Why waste time building a dubious non-core cryptography function just to enable security, if you can just use the System.Security.Cryptography collection of classes? Why re-invent the wheel when a lot of standard solutions are crystallized in industry patterns?

The problem is that you have to know about the knowledge, competitors and/or allies that you can leverage.

The Problem

Several months back I wrote that internal code reuse can be dangerous, the premise being that most teams don't spend enough time investigating what is already available (often available in a superior, more widely-known fashion) - be it coding standards, frameworks, or whole projects, a lot of the code base in many organizations is completely redundant, inferior duplications of what already exists, created purely out of lack of awareness. Even when resources are within grasp they're often ignored - A huge number of in-house .NET "utility libraries" duplicate what exists in the .NET Framework. All because no one bothered looking through the admittingly-massive MSDN Library before undertaking a task themselves.

While sometimes this occurs because of the Not Invented Here syndrome, more frequently it's simply ignorance - Either intentional ignorance (such as not bothering doing proper competitor/options research before getting started), or unintentional ignorance (there is such a huge number of projects out there, often with convoluted explanations of what they do, and difficult and time consuming setups to test it out yourself, that it can be impossible to know what already exists. For some small components and projects it can literally be faster to just do it than it is to investigate the alternatives).

Huge code repositories grow larger with second-rate solutions, products are developed that enter the market dead-on-arrival, and developers have the passion beaten out of them.

The Paralysis

As bad as all of this sounds - making solutions to discover that they're second rate or obsolete, or huge internal code repositories filled with duplications of better alternatives - the problem exists even where these problems aren't evident (in fact a secondary-effect occurs because of the prevention of these issues): Many software developers are simply decision-paralyzed. They're unable to proceed with any project because the number of possible standards, components, and frameworks that they need to consider is unending.

This is made worse by the fact that there are tens of thousands of software products and components making claims that they can't back up (especially in realm of nebulous, all-empassing applications. These high level applications often require tremendous configuration and programming to be usable, but the appearance is that they're a drop-in-place solution). Sourceforge, for instance, is full of tens of thousands of version 0.1 applications, where the purported feature list could be be described as a wish list. Other products entail tremendous expense, or bring along undesired dependencies or complexity.

Researching, and then understanding every caveat and issue with every potential solution is a huge undertaking.

The Solution

If only it were so easy to simply rattle off a solution.

Nonetheless, a huge step in the right direction would be simpy allocating adequate time upfront for "competitor research" before committing to a project, or even before undertaking a component. This is a tremendous undertaking these days, yet in timelines it's often forgotten or considered satisfied by a quick 5 minute Google search.

If you're developing a web application to store documents, could it be satisfied by Sharepoint? Community Server? Zope? A derivative of Media Wiki? If you've committed to one of those projects, but you just need to extend some of the functionality (say you want to display the EXIF data of photos), have you committed the time to investigate the alternatives?

For virtually every need, there are a slew of theoretical solutions. The truth, however, is that many of those solutions aren't a good fit - many of them are simply terrible - but you need to be informed and prepared when peers, coworkers and clients ask about them in comparison.

Even if you don't find an appropriate solution already available (in most cases you won't), document all of your findings: If Biztalk looks superficially like it's the right solution, but for some reason it isn't appropriate, be prepared for the inevitable grilling you'll get every single time someone who knows about Biztalk and then hears about your project gets within earshot.

Be prepared!

Tagged: [Software Development], [Programming], [Software-Development]

The Expense of Errors

A widely demanded feature delivered with Visual Studio 2005 is "Edit and Continue"; which is the ability to alter running debug code to incorporate code-changes on the fly: You're debugging and realize that you initialized a variable to the wrong value, or your loop control has a off-by-one error. You pause the run, quickly hash out the changes, it builds it into the running image, and you continue debugging from where you were.

Great feature that can be a tremendous time saver, avoiding having to stop the session, make the changes, rebuild everything, and then begin the developer test session anew.

Is it, coupled with similar tool advances over the years, making programmers generally sloppier, though?

Sloppy Programming Habits

Observing the habits of many peer developers in the field, I would say that it and similar advances absolutely have made us more careless in general: The less expensive errors become, the fewer checks and mental effort we'll expend ensuring that they don't get into the code in the first place. We're continually pushing the onus of catching errors one level higher.

To contrast with a slightly earlier time, there was a time, way back when (circa 1990), when I was plugging away with DJGPP (GCC for MSDOS), editing the source files in a simple DOS text editor, exiting out, building (very time consuming, with few benefits like precompilation), and then running. It was such an onerous, expensive process that I put a significant amount of care and concern into every single line of code. I would follow-up careful coding by going back and auditing every single function and interaction to ensure that it was syntactically accurate, but more importantly that it was logically accurate.

The cost of an error making it to the next level was high enough that I was very motivated to avoid them in the first place.

After such a personal code audit, I was very confident in the code, and it was very rare that an error made it any further: The cost of an error making it to the next level was high enough that I was very motivated to avoid them in the first place. The original level of quality was high enough that few additional checks were actually needed - it simply worked correctly for all scenarios.

Of course I had it incredibly easy in contrast to those who programmed before (I already had the benefit of a significantly easier development process). I'm sure the folks who programmed punch cards redoubled and tripled the effort again, achieving amazingly high at-origin quality levels in their code: You can't just spit something out when you're printing and sorting punch cards, and then feeding it into the mainframe during your tight allotted time window. Nor did programming assembly in the 8-bit days leave much room for errors.

Contrast this with the habits of many developers today (myself included at times): Spit out a bunch of code, occasionally hitting compile/syntax check to automatically detect gross syntax errors. Build and run, and if it blows up then follow the exception back to the error and correct it. Drop into breakpoints and watch what values are to ensure they're what you wanted (a modern variation of printf debugging), and if they aren't then use edit and continue to quickly hash in some changes. Keep debugging. Run the TDD sets to ensure that the superficial, incomplete collection of tests "guarantee" that the code is "perfect". 

Toss the result over the wall to the QA department. They're likely running a macro script that tests a small sub-section of the code, so there are few guarantees there either. In the corporate space, they'll throw it over the wall to the UA testers who again will likely only catch the most obvious of errors.

Deal with the inevitable problem when failures occur in the field, pointing out their inevitability given the numerous layers of quality control you have in place.

Of course some developers will strongly object to even the possibility of such a scenario: Their code is flawless at inception, crafted with the utmost of care and concern, and they need never evaluate their habits or tool usage because they couldn't possibly come closer to perfection. That level of ridiculous denial is destructive on any team or project, and I can offer no advice on how to solve or manage it (though it's the foolishness of the inexperienced, so generally developers grow out of such bravado with time). Instead I choose to deal in the real world, with real developers on real projects in real organizations.

Additional Checks Are No Guarantee

For all of the process (including layers of QA, UA, regression testing, and so on), many errors aren't caught at many shops until the code reaches the field, which is why it's critical that they don't enter into the code in the first place.

the addition of layers can paradoxically increase the probability that errors will be introduced in the first place

Indeed, sometimes the addition of extra layers can paradoxically increase the probability that errors will be introduced in the first place: At one very large organization where I observed development firsthand, developers would hand their obviously flawed code (it was clear that there wasn't even a superficial quality check) over the wall, doing so knowing both that there was a QA department that should catch these things (and if they didn't then it's their fault if it makes it further, exonerating the developers even more), and if that department does find a fault it came as a largely ignored problem report that held few ramifications or negative implications.

Change precisely what was documented as defective, rebuild and resubmit.

Eventually the QA department would pass on the code to the UA department, which was a set of user testers that simply relied upon the comforting idea that the developers and QA surely would have found any possible faults. UA could be relied upon largely to restate long-known system limitations instead of verifying the changes.

All of these layers relieved developers, and each of the other layers, of the real responsibility of defective code. Advanced tools facilitated sloppy coding in the first place, and layer upon layers of ineffective checks ensured that there was little actual responsibility for faults that made it to the field. In the corporate space where developers generally don't have a passion for the software they're creating, the result was often of questionable quality.

False Efficiency

It would be an interesting experiment to have two concurrent mid-sized projects, each completing the same task, with one development team having a modern complement of development tools, and the other with no ability to automatically syntax check, run automated tests, or debug in any way outside of a small number of scheduled debug builds and test sessions. It would be interesting to evaluate both the overall timeline (did the tools save much time?), and the quality levels of the resulting product.

I believe that the results would be very surprizing to many software developers. In real world projects (e.g. not pre-project timelines, but actual post-mortem results), approximately one half of development is dedicated to finding, and fixing, software faults. Making the per-item cost of faults cheaper may reduce the per-fault cost, but it also might increase the frequency of faults to the point of being a net loss.

A comment that I frequently hear relates to the efficiency of development - That modern tools make us so much more efficient. Under the right conditions, and with proper usage, this is certainly the case. Edit and Continue, for example, could be a very useful feature once every blue moon. Yet by the outpouring of demand for that feature, one would think that developers were crippled by the inability to alter running code: The responsibility to craft quality code before hitting build was just too overwhelming. This is a sign that quality code craftsmanship is on the decline.

Tagged: [Software Development], [Programming], [Software-Development]

A St. Olaf Christmas In Norway

Caught this on PBS HDTV tonight and it was spectacular (it'll be on several more times over the next week). The choirs were great, and the setting - Nidaros Cathedral - was extraordinary.

Norway is yet another list of countries that I'd really like to visit and spend a month or so in. As a Canadian, I've always found it odd that nationally we haven't fostered more of a friendship and alliance with the smaller Northern countries (Sweden, Norway, the Baltic States, Finland): We share common political (e.g. smaller countries amongst heavyweights) and environmental conditions (cold!).

Speaking of togetherness - I've been to the Twin Cities (Minneapolis/St. Paul) in Minnesota quite a few times, and I would truthfully say that the classic stereotype of Canadians (many mannerisms, friendliness, and so on) actually applies more aptly to the great folks of Minnesota. That's a beautiful state full of great people, and in many ways it's more Canadian than Canada.

It's the President's Choice

A very large grocer up here in Canada is Loblaw's (which operates under a variety of brands). They generally operate huge supermarkets full of a good selection of fresh, quality products. It most certainly isn't the cheapest grocery store, but I can honestly say that I enjoy grocery shopping when it's mulling around a Loblaw's.

One of the greatest coups of Loblaws, and it's one that has brands and retailers worldwide taking notice, is the President's Choice brands. Originally begun as a rather corny "I'm the president, and this is the stuff I like!" selection of items, it has evolved into a very high quality brand (which is rare given that it's a store brand, which usually indicate a compromise in quality): If I'm looking for a product in a realm where I don't have a favourite, I'll go past all of the well-known brands and pick the PC alternative if one is available. In any given Loblaws visit, probably 30% of the non-produce items I buy now are PC brand items.

Of course Loblaws doesn't actually manufacture the brands themselves - Instead they get outside manufacturers to do it, often the people whose products it will compete against. However it seems evident that they spec out excellent products, and they demand a very high level of quality and ingredients (PC brands eliminated or minimized transfats long before that became a norm, for instance). The result is products that seldom disappoint.

Why do I mention this? I mention it because the PC brand is going so well, and they're earning so much namespace, that a good thing can't continue: Seemingly inevitably some blowhard fly-through executive will decree that if they are making $X, then they should reduce the quality of the ingredients and make $X*1.2! Perhaps I'm a cynic, but this cycle of self-defeat at the hands of short-term sacrificers is legendary when something starts doing well.