2/18/2006

WHY PODCASTS SUCK

or,

"Don't bother building it, cause I'm not gonna come."

Ah, podcasts.. I’ve tried a sampling of podcasts and have been very disappointed. It seems that learning how to speak clearly, avoid breathing into the microphone, and not saying “um” after every few words are essential skills to producing a quality radio program, and the production landscape for podcasting is severely lacking in this regard. It turns out, quite simply, that owning a microphone and some MP3 recording software doesn’t make you interesting.

We live in a technological era where any Joe Schmoe garage band can burn their own CD and distribute it. That doesn't mean it will be any good.

The real issue I’ve found with the few podcasts I've taken the time to sample is that they’re significantly devoid of substance. Often they spend more time talking about the podcast than the topic, or they are full of off-topic "cutsie" "aren't we kewl" type jokes and the like.

If you are, like me, looking for quality content, this kind of bullshit wears on you pretty fast. It seems that people who are pretty good blog / print authors in their own right just fall to pieces when they start a "podcast".

And the worst thing about podcasts (and even webcasts, like those online Microsoft Multimedia presentations) is the fact that most people with an above-average IQ are going to get bored rather quickly, because you have to either wait until the junk flies by to get to hear the "good part" (if there is any) or you have to skip all over the place trying to find it. In the webcasts, at least there is usually a table of contents and a transcript. Have you ever seen a podcast with these features, indexed by hyperlink to the spot in the audio stream?

At least, with a print article or blog entry, it is pretty easy to quickly scan the whole thing and make a determination if the piece has any real value to you. And finally, pod "Casting" as the suffix implies, is broadcasting -- which is a one-way deal. There's no interaction, no feedback. You can't make a comment, as with somebody's blog.

And finally, before you jump into a new Podcasting career, consider the important fact that the content in your Podcast will never be indexed and searchable via Google or MSN Search as is text content on the web.

So folks, you can podcast until your face turns blue. I really hope you enjoy producing them.

But, Peter Bromberg won't be listening. I might be listening to J.S. Bach, or the Phillip Morris SuperBand, but I won't be listening to your podcast.

2/16/2006

Quality Code Redux, Standards, Dynamic Invocation and Dick Cheney

Bruce Wood, a frequent poster on the MS C# newsgroup, said it all:

"A mediocre standard is better than no standard at all"

Bruce was responding to an OP's desire to "innovate" by using a non-standard implementation of event handlers, and he recalled his experience at university where his professor asked, "What is the purpose of writing code?". After the usual answers (e.g. "To make the computer perform some task") he answered "It's to make it clear to the next guy that reads the code how you solved the problem".


The point is, if the only objective is to make the computer perform some task, why not just use assembly language?

The answer of course is that in a multi-developer environment, or even one where you may someday leave and someone else will take over your code, you want to make it as easy as possible for others to understand not only what you did, but how you did it, and to be able to maintain that code. It is common for the insecure programmer to want to be the deus ex machina of the organization. As developers mature they usually learn that good teamwork and sharing of coding standards is far more important.

Bruce finishes, "Hacking out funky code 'that works' costs your employer extra because it will be more expensive to maintain.... A good programmer will make it work, and make it clear how it works so that it's easy to fix and modify in the future. That's what separates the professionals from the dillettantes".


Often we as developers learn some new technique and become so consumed by "how cool it is" that we forget about Bruce's principle. And, often as not, we don't think through the other implications, such as performance considerations. For example, dynamically compiling custom assemblies based on business rules that come from a database and dynamically executing these using Type.InvokeMember semantics may be very cool, but as Joel Pobar points out in his MSDN article, if that technique is in your application's "fast path" (e.g., it gets called repeatedly) you may end up finding that you have shot yourself in the "Code Monkey Foot", so to speak.

Joel's work, and additional material from Eric Gunnerson before him, show that an Interface - based methodology is approximately 200 times faster, all other things being equal. Not only that, but the whole concept of interfaces makes for better quality programming that is more maintainable. I have found very few situations where it did not make sense to enforce an interface-based approach, even for 100% dynamically - generated code.

You could say, for example "Well, I can't use an interface because all my custom - compiled assemblies / classes require specialized sets of parameters". And I say, "Fine. Then create a public Hashtable called 'Parameters' in your interface, and populate it before calling the business method(s) on the interface." The specific internal representation of that object's "execute" method should know what parameters / types it needs, and simply pick them out of its Parameters collection.

As Bruce so eloquently put it, " 'It works' are the words of a greenhorn".

Of course, we all owe a small debt of gratitude to Dick Cheney. He was the first to implement the "Fire and Forget" pattern!

Finally, just in case you think your data is secure, George Kurtz shows how incredibly easy it is to find confidential information using the Google search engine. Take the time to look at some of this stuff. Absolutely horrifying -- what's out there for the taking!

And, in similar but unrelated news, do you know that AT&T might owe you $21,000?

Something to think about.

2/11/2006

SourceSafe 2005 Internet? NOT!

Let's sort out some of this stuff. My erstwhile eggheadcafe.com partner and chief geek, Robbe Morris, attempted to set this up.

I gotta tell you, this is one dude who doesn't give up easily. He is persistent, dogged, determined. Bottom line? He gave up! Mostly because it wants to hog website "#1" and we aren't gonna mess with the metabase.
He even talked to PSS and they basically said "That's what you have to do". Dudes! WebSite "#1" is not going to get changed to accomodate VSS 2005's quirks, OK?

Now let's do a little research, mostly by Googling "Sourcesafe 2005 Internet":


First big info blog: http://www.hannesschmidt.de/node/35

Prognosis: Not good. Patient might be alive, but we can't communicate with him / her....

Next Victim: http://www.yafla.com/dforbes/categories/softwareDevelopment/2005/11/24.html

Prognosis: Success, but had to workaround "Braindead configuration".

Next: http://jasonf-blog.blogspot.com/2006/01/visual-sourcesafe-2005-webservice.html

Prognosis: Moderate success, after fiddling with permissions (which should be offered during the setup process).

Next Victim: SourceSafe team's own weblog: http://blogs.msdn.com/checkitout/rss.aspx?CategoryID=5890


Prognosis: pretty spare on content! It says "We're hiring". Damn well better be hiring!

Next: Yack's blog: http://blog.davidyack.com/archive/2005/06/22/710.aspx

Link on manually registering a client.

Prognosis: Jury's still out. Yadda yadda, Warden!

Next Victim: Wikipedia entry: http://en.wikipedia.org/wiki/Visual_SourceSafe


Prognosis: Mixed review.

Oh, there is much more. I guess we will wait for the Service pack sometime late this year, or for somebody to write a whole book about it, or TFS, which certainly isn't a cheapo alternative....

2/01/2006

Hacking Internet Explorer 6.0 / 7.0, Feeds Manager, ClickOnce Broken, and a DOS Hole?

Technorati Tag:

Developers who are interested in playing with "add on" concepts in Internet Explorer 7 would be well-advised to take a look at the MSFeeds.dll COM Interfaces. Here are a few screen caps of the COM-Interop generated assembly classes you will get when you set a COM reference to the MSFeeds management COM server DLL. There are three main classes, the first is the FeedManagerClass:

FeedManager provides methods to add, sync and delete feeds from the Feed folder, as well as maintenance items such as IsSubscribed. Next is the FeedFolderWatcher:


FeedFolderWatcher offers management of Downloading and monitoring the Feeds Folder, along with a rich set of events related to same. Finally, you have the FeedWatcherClass:



FeedWatcher handles granular tasks / events such as the status of a downloading feed, the FeedItemCount and error handling.

With a .NET class library wrapping these COM methods/ delegates / interfaces, developers should be able to build neat "Add on" applications that use and work with the same infrastructure that Internet Explorer 7.0 uses.

BTW, you can find the feed management folders here:

C:\Documents and Settings\<username>\Local Settings\Application Data\Microsoft\Feeds\<subfolderName>


Your feeds themselves are actually stored in this folder (and any subfolders you've created, such as "subscriptions") in an "Mostly Text" proprietary format. Updating information is stored as cookies.


UPDATE: This API is documented here, so it's not as "hacky as I originally indicated.


Running Both IE 7.0 and IE 6.0?

There are a lot of hacks, but let me present mine, which is so incredibly easy, you'll wonder why you didn't think of it:

In your Windows folder, there should be an unistall folder for the IE 6.0 you had. It will look something like "C:\WINDOWS\$NtUninstallie7bet2p$"

Make a shortcut to the IExplore.exe executable in that folder, and you are done!



Does IE 7.0 Beta break ClickOnce?

I've noticed after installing IE 7.0 Beta that it cannot handle HTTP ClickOnce deployments. The Publish.htm page loads fine, but both the Launch and the Install options fail miserably. Anybody else notice this?
This is on the local machine of course -- it worked great with IE 6.0.

Blocks AdSense Ads with default Security Settings?

That's another little issue I'm not sure I am happy with. IE 7.0 with the default security settings appears to SILENTLY BLOCK all google adsense ads, until the user puts

pagead2.googlesyndication.com

into their trusted sites list. Hmmm...


Private Researcher Finds DOS Hole in IE 7.0 Beta minutes after Installation

This EWeek article explains all.

IMPORTANT! App Pools and ASP.NET 1.1 Vs 2.0


I was just reminded by Julie Lerman that when you install ASP.NET 2.0 on IIS 6.0, ensure that your 1.1 Apps and your 2.0 apps run in separate App Pools. Not doing so can result in unusual BTH (Bad Thing Happened) behavior that is extremely difficult to diagnose.

FINAL NOTE: 2/8/2006: Bye Bye IE 7.0 Beta 2!


This thing has nice features and all, but there is just too much interference with Visual Studio.NET 2005. So, off it goes. Keep up the good work, IE team. Just let me know when you are done and it is REALLY ready for production. And just to add insult to injury, now that I've uninstalled IE 7.0 and rolled back to IE 6.0, my ClickOnce deployments on this machine ARE STILL BROKEN!