10 or so years ago, when one wanted to write a Windows application, you had a choice to make. Does one take the easy way, or the hard way? Were you a real Windows Software Engineer or a wanna be? Did you use Visual Basic, or did you take the time master all the nuances of HWNDs, HDCs, and SendMessage? Was Charles Petzold's seminal Programming Windows book on your bookshelf or not? Did you enjoy the Get a Mac - Gift Exchange ad in which PC gives Mac a copy of the "C++ GUI Programming Guide"?

Today, it seems the web programming world has a evolved into a similar dicotemy. It seems there are lot of ASP.net programmers who are more like the VB programmers of yore, than the C/C++ programmers of eras past.

There are those who avoid getting their hands dirty with Javascript and really don't understand the full power of the browser's DOM. You know the ones that don't even know what byte bloat ASP.net web forms can create, let alone how or why they should avoid it.

Granted, like old Visual Basic, ASP.net web forms is a great tool for writing applications quickly. But the native tongue of Windows is the C/C++ Win32 API, and the best application developers are fluent in it. Likewise, the native tongue of the Web is the Javascript HTML DOM API, and the best application developers exploit every byte of power the web platform can offer application developers and avoid platform abstractions. Like the Windows developers of yore, the best ASP.net applications are written a little closer to the metal than most people are able or willing to go.

I don't know if I really have a point, other than sometimes large frameworks filled with time saving abstractions get in your way, more than they help. Sometimes, you need to get under the hood and get your hands dirty. Sometimes, I wish more developers had the opprotunity to build fast applications, instead of merely developing applications fast.

When, I first heard about Microsoft's $40+ billion (1/2 cash + 1/2 stock) offer to buy Yahoo, my first reaction what similar to Mini Microsoft's. To put that figure into perspective, that's enough to buy over 2,000 Trulias (at $20 million each) or 500 Zillows (at $80 million each). That number is like visiting the Boeing factory in Everett, after seeing it; you just walk away with a sense of awe.

Put another way, it will drain Microsoft of its cash reserves and put the company into debt for the first time in its history. Fortunately, Microsoft earned about nearly $17 billion last year in income, so I suspect Microsoft has an excellent credit rating w/ the banks. Perhaps, the low interest rates and the upcoming recession also factored into Microsoft's decision.

However, during the past week or so, I've come to the conclusion that desperate times call for desperate measures, and great rewards sometimes only come with great risks and regardless of how it turns out, it'll be a great story to be taught in business schools for generations to come… Perhaps, the idea isn't as crazy as it sounds…

Wall Street knows Google is only human – After Google's last quarterly earnings report, the share price plunged by $40 / share. Granted, Microsoft's chart for the past 3 months doesn't look much better. But the fact that Google has shown a marked deceleration in paid click growth and difficulties with moving social network inventory, shows it is still a one trick pony (albeit one with a $150 billion market cap). Furthermore, Google still doesn't have any enterprise street credibility and I'm not the only one who thinks so.

Microsoft knows Google is only human – For years Microsoft has invested heavily in search, and technology wise I think Microsoft is finally starting to catch up. Note: catching up technologically is NOT the same is catching up in market share, traffic, and perception (that takes much longer). For the past year, I've found MS Live & Google to be roughly equivalent, or Google to be slightly better. However, to beat entrenched competitors, you need to deliver superior products, not just equivalents.

Earlier this week, I finally ran into a situation in which the search results Live returned were not only better than Google, but significantly so. I was looking for more information on Content Delivery Networks (CDN as us web geeks call them), and Google gave me a bunch irrelevant information on the Canadian Champions League, and random Canadian food/drug related topics (Canadian Viagra anyone?). Google earned a perfect 0 out of 10 on relevance. Microsoft's results weren't perfect, but 7 of the top 10 results were related to the topic I was interested in and the unrelated topics were less random. I was shocked Google would screw up this badly. Google should know that 1) I'm a software geek 2) 90% of my searches are on geek related topics, and 3) it should have a bias toward geek related things, all things being equal, because Google is at its heart, a company run by software geeks.

BTW – My search on Yahoo, included information on CDs (Compact Discs) & CDNs (Content Delivery Networks) and allowed to me filter my back to my original query. The filtered results were roughly equivalent in relevance to Microsoft's, so I'd give Yahoo a good grade as well. Granted, this was just one obscure search out of billions possible, but the fact Google fumbled something so badly, that usually it nails was a bit, how should I say it, encouraging for those of us who don't want to see Google own the internet.

Google knows Microsoft + Yahoo could beat them (or more likely, force them to start playing defense) – I didn't say Microsoft + Yahoo will beat them. Heck, the Yahoo + Microsoft merger is probably the best thing to happen Larry Ellison in the past 5 years. It might end up being the best thing that ever happened to Google too. One thing is certain, separately, Microsoft & Yahoo will not catch up to Google. Google has a critical mass that Microsoft & Yahoo separately do not.

But if Darth Brin finds the takeover unnerving and Google's head lawyer is publically whining about the deal, perhaps the Microsofties in Redmond & the Yahoos Sunnyvale, should be a little more optimistic about their chances and open minded about the possibilities. Granted, I completely agree with the skeptics that Google is going play the anti-trust poker game to the best of its ability, integrating Yahoo's alien technology w/ Microsoft's is going to be huge challenge, and finding a way to keep Yahoo's best brands and talent (while simultaneously, not destroying Microsoft's) is a marketing & HR nightmare.

Will Google lose? Probably not, but to paraphrase the wise Steve Jobs "Google doesn't have to lose in order for Microsoft to win." I'll put it another way, I'd take the Giants and the points because they are much better team than some people give them credit for. I believe Microsoft (w/ Yahoo's help) can put Google on the defensive, for the first time, and keep them honest. And if this doesn't work, at least Microsoft can go into the locker room knowing they left it all on the field and gave it their best shot.

At any rate, get'cha your popcorn ready. It's going to be one hell of a show, just like SuperBowl XLII was.

Do any of my fair readers have any experience or advice on Safari development tools, plug-ins, or debuggers? Most of my day to day surfing & debugging is with Firefox and IE on Windows, and I know where most of the toys for those browsers are hiding.

My knowledge of Safari plug ins & development begins and ends w/ Pimp My Safari, but I have no idea if the plug-ins are Mac only or run on Windows as well? Furthermore, I have no idea if any of them worth downloading? What are the differences between the Windows & Mac versions of Safari? Is the Mac version of Safari better than its Windows cousin (God, I hope so). How does day to day life as a web developer on Safari compare to that on Firefox or IE? In the Windows world, let's just say Safari, has its share of issues, and is unlikely to win any converts on Windows. I will admit that Safari 3.0.4 for Windows beta was an improvement over their previous beta, but it's still uglier than Opera, and buggier than IE.

However, I suspect that Apple writes code, like the Seahawks play football. They are both much better teams at home, so I suspect Mac Safari is pretty good if you use fruit computers on a daily basis. And if the rumors are to be believed, Safari is going to become much faster, which probably means Safari is going to grow its share of the market. Either way, I'm probably looking at larger browser test matrix and a new set of browser bugs to learn about for my applications.

Perhaps, I should just spelunk on Apple's Safari Developer FAQ, until I find the droids I'm looking for?

It was a long, long time ago… It was a time of a great civil war between the Outlook/Office and the Exchange teams… It was a time of great browser wars and much uncertainty... It was an era in which ancient languages such as C++ ruled the galaxy and web browsers weren't considered application development platforms.

It was during this time, I had the opportunity to work on a product that would help redefine web based e-mail and more importantly define what web applications were capable of. I was one of the first developers on the Outlook Web Access team (or as it was known back then, the Exchange Web Client). During 1996-1998, I worked with Bob Gering (R.I.P.) and Jim Van Eaton, where I created the original appointment / meeting request form, the contact form, and the Java date picker. Needless to say, it was the highlight of my professional career at Microsoft.

Unfortunately, during this great civil war, my career ended up following a different path, than that of my good friends, and I joined "the confederacy". During this period, I ended up working on random Office apps in native code, as I meandered around aimlessly from group to group, either working on products I wasn't passionate about or working for managers who were mediocre. After a few years of my career going nowhere, I left Microsoft.

During this time, my friend Qui-Gon Jim (Van Eaton) became the Jedi Master of the Outlook Web Access team, and under his stewardship OWA became the first web application to use the XMLHTTP technology, which is today referred to as AJAX and continued to grow its proud legacy into the great application you know and love today. Unless of course, you use a browser that doesn't suck, in which case you'll never know how good OWA really is, which brings us to the present day.

You see, Microsoft fumbled the ball during the dot com bust. After building a huge market share & mind share lead in the browser wars, Microsoft disbanded the IE team and essentially walked away from improving its client side internet technologies (fortunately, they invented .net during this time, and improved it's server side software, but IE was essentially trapped in a time capsule from 2001-2005). I suppose at the time it seemed like a smart move since AOL purchased Netscape, and neither AOL, Netscape nor the Mozilla foundation were going anywhere. Furthermore, Steve Jobs second coming at Apple was still in its early stages and Google was merely a good search engine and not yet a verb.

Except, at some point during that era, we hit a strategic inflection point. Firefox got invented, kept improving and kept innovating. All while the majority of the former IE team was trapped in the Vista tar pit. In a few short years, IE 6 went from first to worst in mind share, due to the Firefox team playing the tortoise to Microsoft's hare. Even worse, Google took advantage of Microsoft's internet client myopia and made a web e-mail client that worked great on IE and Firefox (and gave away gigabytes of storage space to sweeten the deal). Shortly afterward Apple released Safari, Google released Google Maps, Microsoft released Virtual earth, and the Web was re-born.

Anyway, the OWA team kept innovating during this era of uncertainty, and ended up with a great AJAX client that only worked on IE because when it was designed 1) there were no other browsers that supported AJAX / DHTML except IE and 2) there were no standards to follow because there were no other browsers that had implemented them yet. I suppose myopia played a role as well, but by the time the other browsers gained mind share, the OWA's development plans were already set in Carbonite.

When I was on the OWA team, we supported IE & Netscape equally well (perhaps equally poorly is a better choice of words, because web browsers and web applications were so much simpler & less complex back then). However, during the past 10 years, we've witnessed the rise and fall of Internet Explorer (and possible redemption) and the World Wide Web is once again a chaotic and exciting area of uncertainty and innovation.

So, with that back story, I am now announcing that this epic tale, is taking a new, if small, unexpected twist. Qui-Gon Jim has asked this former Jedi Knight to return to the Rebel Alliance, where we both hope we can defeat Darth Page and Darth Brin of the Google Empire. For the past few years, I've been peacefully living on Tatooine, but Qui-Gon Jim's call to battle was too compelling to resist.

With a lot of hard work, and a little luck, perhaps I shall become a Jedi Master and re-join the Jedi Council. If nothing else, perhaps I'll merely play Han Solo for a few months and pay off Jabba the Hutt.

One thing is for certain, the light saber fights with the Sith are going to be fun to watch and I'm looking forward to seeing something other than IE 6 bugs for next several months. Wish me luck in my old / new job on Microsoft's Outlook Web Access team!

Last time, I whined about ASP.net byte bloat. As long as I'm bitching about Microsoft's internet platform, I might as well hold nothing back.

Microsoft doesn't care enough about Internet Explorer. It is the red headed step child of Microsoft's internet platform. MS seriously lost a lot of client side credibility and goodwill by disbanding the Windows IE team for 3+ years after Windows XP / IE 6 shipped and letting the Mozilla / Firefox team catch up and surpass it.

I'm sure killing Mac IE & killing Unix IE didn't help matters either (not that anybody ever used them). Shipping a mediocre IE 7 along with a disappointing Vista last year, has further hindered Microsoft's ability to convince people that it does have a great server side web platform and annoyed its supporters. I'm also annoyed that after IE 7 shipped, the IE blog has been less informative during the IE 8 dev cycle than it was during IE 7's. I'm optimistic that after the recent IE 8 Acid Test post, the group is just being quiet instead of dead.

However, barring a Seahawk like comeback by the IE 8 team, my money is on Firefox 3 being the champ in the 2008 browser bowl. Ever since Coach Dave Massy left the IE team, I think they've taken a step backwards. Maybe they need to give IE to Coach Scott Guthrie (GM for all things IIS, ASP.net, Silverlight, and all other MS web technologies that don't suck) or perhaps the GM Windows Live team (Did you know Firefox development is almost completely funded by Google ad revenue?) All I know is that IE is too important to be left in the Windows group. Microsoft needs to show more forward progress and give the season ticket holders reason to be hopeful. Otherwise, IE will be like Shaun Alexander, a browser/back that has a great history and a disappointing present.

OK, I got the big 2 gripes off my chest. Here are some minor ones.

Why does ASP.net AJAX download so many Javascript files? I think there's a new ScriptManager on CodePlex that combines several embedded scripts on a single download. Still, it would've been nice if it was this way by default.

Why is HTTP compression the best kept secret of IIS? Seriously, it seems the vast majority ASP.net programmers don't know about HTTP compression on IIS. Maybe all of my friends read Dilbert instead of Jeff Atwood during their lunch break? OK, it is a pain to configure and providing some UI, like what Port 80 Software's ZipEnable does, would be welcome. People get nervous when I say edit the IIS metabase around them.

Why did I have to wait so long for a real FTP server? Oh well, at least things are better in IIS 7.

As I said, in my first post, on the whole, I'm pretty happy with Microsoft's internet platform. The ASP.net team is adding cool features at a good clip, Silverlight seems like a promising addition to the web developer's tool chest, and IIS 6 has been simple to use & rock solid in deployment. It seems like half of the ASP.net engineering team blogs, so getting that level of transparency is awesome. Visual Studio 2008 & SQL Server 2008 both seem like worthwhile upgrades.

And yet, despite all this coolness, I still have to code work-a-rounds for IE 6 bugs in my day to day life! To be fair to Microsoft, IE 6 was a great browser in 2001. Unfortunately, it's 2008 now and Microsoft fumbled away the web browsing technology dominance it once had. We're all stuck writing apps for a 7 year old web browser, that doesn't compare well to today's best players. Oh well, here's hoping that both IE & 37 will return to All-Pro form next season.

I recently I had a job interview w/ Costco Wholesale in the e-Commerce group. I thought the most interesting question they asked was "If you could change one thing about ASP.net, what would it be". It was a hard question, because on the whole, I'm pretty happy with it. Furthermore, on the whole, I'm pretty happy with the direction that Microsoft is going. However, it got me thinking about what I don't like about Microsoft's internet platform and I figured it would make a great blog post (or two), so here I go.

Viewstate + ClientID = HTML Bloat + Slow. I don't think the ASP.net forms model is bad; it just makes it much more difficult than necessary to produce small HTML markup in the typical case. For example, let's say I have ASP.net code something like this

<form runat="server">
<asp:Repeater ID="rptCards" runat="Server">
<ItemTemplate>
<asp:Image ID="CardFace" runat="server" /><br />
<asp:Label ID="CardName" runat="server" /><br />
</ItemTemplate>
</asp:Repeater>
</form>

And then I data bind a playing card to my repeater in the code behind file, which ASP.net proceeds to render it as this…

<form name="ctl00" method="post" action="form.aspx" id="ctl00">
 <div>
 <input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" 					
 value="/wEPDwULLTEyODIyNzUwMDAPZBYCAgEPZBYCAgEPFgIeC18hSXRlbUNvdW50AgEWAmYPZBYEAgEPDxY
 CHghJbWFnZVVybAUTL2NhcmRzLmFzcHg/Y2FyZD00NmRkAgMPDxYCHgRUZXh0BQ9RdWVlbiBvZiBIZWFydHNkZ
 GQAQrEoOi46tPS8NZ9nekUDim2+Mg=="/> 
 </div>
 <img id="rptCards_ctl00_CardFace" src="/cards.aspx?card=46" style="border-width:0px;" /><br />
 <span id="rptCards_ctl00_CardName">Queen of Hearts</span><br />
</form>

What's with the <div> surrounding the __VIEWSTATE control? Where did that style="border-width:0px;" come from? Why is there so much damn view state? Why do my Image and Label controls render IDs on the client? And why is it named rptCards_ctl00_CardFace instead of something shorter, such as rptCards_0_CardFace?

Sometimes I have nested repeaters, sometimes I don't. Sometimes I use HTML controls instead of Web Controls, but the issue is the same. The elements in question aren't getting changed on the client and only get changed on the server during the initial HTTP GET during data binding. Normally, the __VIEWSTATE just grows & grows as I add more stuff to the page. OK, you can avoid this by a few well placed EnableViewState="false" or disabling it altogether in web.config. Unfortunately, I don't always know when you really need it, so often times I end up disabling it on a control by control basis in a trial and error fashion, until my app works and my markup is small. Unless you truly understand viewstate, you could end up meeting a fatal end with ViewState-ious of Borg. Fortunately, I understand that problem.

What bothers me more is ID bloat, especially when you nest Repeaters, so an innocent looking <asp:Hyperlink> control ends up with an ID like...

rptMerchants_ctl01_rptShippingMethods_ctl00_rptLineItems_ctl00_ProductName,

That's ugly, so I end up using shorter IDs for Repeaters. Unfortunately, that's not good enough at times, so I usually end up replacing many of my server controls with <asp:Literal> controls and controlling my markup directly. Unfortunately, doing that stops you from using the server control you really wanted to use, and makes complex page development a huge pain.

Ideally, what I'd like is a RenderClientIDs="false" attribute for all ASP.net server controls. After all, the ID isn't sent to the server on the postback (just name / value pairs from form controls). You really only need it on the client if you are doing client side DOM/DHTML manipulation. I know you need a Control ID as a parameter to __doPostBack, but I usually don't need it on the client side HTML markup. It also seems odd that ASP.net is missing a RenderClientIDs attribute since they did have the foresight to create an EnableViewState attribute on server controls.

Most of the time, a Hyperlink control is just an <a> HTML tag, a Label control is just a <span> HTML tag, and an Image control is just an <img> HTML tag, so the ID attribute is just byte bloat running up my bandwidth bill. Why is it so hard to just get this instead?

<img src="/cards.aspx?card=46"/><br />
<span>Queen of Hearts</span><br />

Is there a diet control library I don't know about or some magic web.config setting to stop unneeded ClientIDs from rendering? How does one fight ClientID bloat? Should I just wait for an MVC version of ASP.net? I'm kind of lukewarm on the whole MVC thing because of ignorance and the lingering bad taste of classic ASP. I don't mind paying the ASP.net tax, when it adds more value than byte bloat. It just annoys me, that I have resort to <asp:Literal> controls to avoid paying the ASP.net tax in some cases.

So what are the downsides of MVC ASP.net vs Classic ASP.net? Will my favorite 3rd party ASP.net web control product work on it? Do I just need to read Phil Haack's blog and Scott Hanselman's blog more often? Any idea when an MSDN event will cover MVC ASP.net? Oh well, it beats tracking down memory or COM interface leaks in an ISAPI application for a living.

As some of you know, I've been looking for a second monitor for my home workstation for a while now. I finally coerced my spousal unit to let me buy one, and I finally figured out what make / model I wanted, and saved up enough pennies to get something good. I ended up getting Dell's new 2407 WFP-HC 24" Widescreen LCD monitor.

My former primary monitor (and my new secondary monitor) is a Samsung 213T 21" LCD Monitor. Although, the Samsung was the best monitor available that I could afford a few years ago, it doesn't hold a candle to the new Dell. Literally, the Samsung only has a brightness level of 250 cd/m², while the Dell measures at 400 cd/m². It's not night and day, but it's like sunset and mid day (a big difference).

Another difference is the color gamut on this thing is amazing (92% of the NTSC standard). For example, on my Samsung it was hard to tell the difference between the light grey context menu and white window background. On the Dell, the difference is much more noticeable.

Another data point, Hamad Darwish's, A Peek at the Peak Vista wallpaper on the Dell looks very life like. I'm sure with some cold fresh mountain air; I wouldn't be able to distinguish it from reality. On the Samsung, it looks like I'm looking through dark & dirty sunglasses.

Both monitors have horizontal and vertical tilt adjustable stands. Even better, both monitors support portrait mode The Dell goes beyond that standard, by also supporting a height adjustable stand, a USB hub, 9-in-2 card reader, S-Video, composite, and component video inputs.

I also considered the Samsung SyncMaster 245BW, although the picture quality was very good, Samsung cut the portrait mode feature from their new monitor (which was a deal breaker for me, since I've used and liked that feature on my old Samsung 213T). I briefly considered a Gateway FPD2485W, which did have portrait mode and many of the features that the 245BW lacked. Unfortunately, the picture quality wasn't as good as the Samsung. I also looked at the Acer AL2416 the local Computer Stop. The picture quality is good, but the Acer lacks every feature desirable (you can't even tilt it) and frankly why get a Hyundai when you can get a Lexus.

Anyway, I just wanted to let the world know, if you're in the market for a new monitor, I highly recommend the Dell 2407 WFP-HC.

As many of you know, I write real estate web applications for fun and profit. I have to admit it really is an interesting area for innovative web applications. After all, writing a modern IDX solution requires taking advantage of AJAX technologies, mastering a web based mapping platform (like Microsoft Virtual Earth or Google Maps), integration w/ 3^rd party APIs and web sites (such as Zillow or Trulia), pretty dynamic SQL, and handling large amounts of graphical images. Needless to say, it can pose some interesting technical challenges at times.

I'm in the midst of an application architecture upgrade; I'm currently debating how I want store my MLS images. I currently store broker specific images in a database (currently just agent photos and property management photos). My biggest customer (Real Property Associates) has about 70 agent photos and 2000 property images stored in a database, (I currently use ASP.NET HTTP handlers to extract images out of the DB and re-size said image on the fly before I send the response stream to the browser). The NWMLS images are on the file system scattered in one of a thousand subdirectories.

Although this arrangement is more efficient than storing all 474,589 or so NWMLS images in a single directory, it's painful to deal with. Deleting photos for sold or expired listings is like going spelunking instead of doing a DELETE * FROM … WHERE … SQL query. SELECT queries are a lot more flexible that DIR commands. Modifying data only requires one set of DB permissions instead of setting file system permissions on a thousand directories. I don't have to worry about the physical location of my data, since it's just a SELECT query away (regarding of where SQL ends up putting it). Adding meta data is just an ALTER TABLE … ADD COLUMN … SQL command away. In short, even if SQL Server is slower than the file system, the benefits of dealing with it instead are worth the price, so far.

Conventional wisdom is that you don't store images in SQL server. Unfortunately, my good experience with smaller data sets is leading me to believe that conventional wisdom is wrong. Then again, there's a world of difference between 2000 images and a number hovering 25K shy of half a million images. In my case, the images tend to be smaller JPEGs (about 400 x 300 in size) usually hovering around 50K, and I suspect (though I don't know), as long as the size of the images are small-ish, the performance penalty you'll pay appears to be comparatively is minor. My DBA guru friends have told me as long as the image sizes are small, it should be fine. SQL finding a BLOB via a primary key should be pretty quick.

Of course, the only way to find out for sure is to go for it (and see if you regret it later). I suppose, I already know the answer I want to hear. I just want to feel good about it before I go ahead and database-tize my NWMLS image set. Rumor has it that SQL 2008 has a new FileStream datatype, that stores BLOBs in the file system, but yet remain an integral part of the database with transactional consistency, so perhaps I should wait? Ironically, doing nothing (and waiting for Microsoft to fix the problem) is sometimes the smartest design decision you can make.

So does anybody have any good or bad experiences with storing images in their DB / Web applications? How big of a dataset are you storing in the DB? How big of a dataset are you displaying in the web browser window? How do the MLS Vendors deal with this problem?

Although, Dustin has become Joost fan, I just haven't been able to get excited about it. You see, about 6 months ago I purchased a Slingbox and my TV watching universe has been altered forever.

In case you don't know, a Slingbox TV is streaming device that enables consumers to remotely view their cable, satellite, or personal video recorder (PVR) programming from an Internet-enabled computer or phone with a broadband connectivity. It requires a minimum of 512 Kbps upload download speed to be watchable at YouTube quality. If you are blessed to have a very high speed internet connection, the quality approaches that of cable TV.

With Joost, because they are attempting to start a new content distribution model, the amount of interesting content available is limited to content providers who are willing to let Joost redistribute their content. Joost has landed Warner Brothers, CBS & Viacom as content partners, but I don't know what the Joost business model is, so this might just be an experiment on their part instead of wholesale content distribution model change.

However, until I can watch a Seahawks game on Monday Night Football on Joost, I'm not taking it seriously. Of course, with Slingbox you're limited to what your cable or satellite company broadcasts, so if you want to see International programming (say Mexican soccer) and you don't have a Slingbox in Mexico, Joost might be the best opportunity you have to break down international programming barriers. Regardless, the Slingbox is actually useful, and Joost is merely interesting at this point.

One of the many great things about Slingbox is that it enhances your investment in your home media programming and hardware instead of attempting to replace it. For example, I have a TiVo at home, so while I'm on the road, I can watch & control live & pre-recording programming from the airport lounge or hotel room, instead of being force to watch something I don't care about. I also subscribe to DirectTV's NFL Sunday Ticket. So, when I'm at home I have the ability to watch any game being broadcast in the country. Since I've already paid for the privilege of watching NFL games (via my satellite bill), I can watch the game at home or away on any internet connected device that runs the SlingPlayer software.

The SlingPlayer software is currently available for Windows (Vista, XP, 2000), Mac OS X (10.3 & above), Windows Mobile (PocketPC & SmartPhone), and Palm OS. The SlingBox hardware comes with IR blasters, which are placed in front of your cable receiver, DVD player, etc and they allow you to control your device over the internet via an on screen remote control (that is often times a pixel perfect replica of the actual device's remote). This is great touch because you can leverage your remote control visual / muscle memory instead of looking for the play / pause button on your on screen remote. The software also includes the ability to set up channel favorites along the bottom of the video window, so you can channel surf with authority.

Of course not everybody agrees that Slingbox is a good thing. Unfortunately, many content owners appear to want me to pay twice for content (once to DirecTV and again to them for the privilege of watching it over the internet). For example, Major League Baseball has had numerous issues problems with Slingmedia. I think MLB is deploying FUD tactics, and being greedy because it wants me pay twice so I can watch my home team when I'm not watching them from home. Instead, the Slingbox lets fans leverage their existing investment in their cable or satellite TV provider at no additional cost.

MLB has also argued that because the MLB sells transmission rights to specific geographical locations, a cable subscriber in Seattle who watches a Mariners baseball game from his or her laptop during a visit to San Francisco is stealing from the San Francisco cable operator who paid to transmit MLB games in that city. I think that MLB has it backwards; the Slingbox is good for cable operators because it instills loyalty. A fan's home programmer or operator can advertise to subscribers regardless of their geographical location. Besides, the San Francisco cable operator wouldn't be transmitting the Mariners game anyway (they're all Giants & Athletics fans down there) so how can they lose revenue for a game they aren't broadcasting anyway?

To quote Sling Media CEO Blake Krikorian

"All the other leagues understand what business they're in," said Krikorian. "All the other leagues understand that their paying fan is their key asset and crown jewel. (The Slingbox) further tightens the relationship between the league and that consumer, and that is a good thing."

Fortunately, the other sports leagues seem to approve of the device. The commissioner of the National Basketball Association, David Stern, invited Sling to present the product a year ago at its NBA Tech Summit, indicating his approval of the device. Going one step further, the National Hockey League, has announced a new agreement allowing Slingbox owners to use Sling Media's upcoming Clip+Sling technology to share NHL programming online.

The NFL has pretty strict internet video policies, but to date it seems to be silent on their opinion of the Slingbox. Perhaps, this is due to the fact they broke DMCA laws earlier this year, when attempted to remove a video clip of a the standard NFL broadcast disclaimer from YouTube, which was posted by Brooklyn Law School professor and staff attorney for the Electronic Frontier Foundation (EFF), Wendy Seltzer trying to make a point?

Regardless of what content owners, sports leagues and media companies argue, one thing is certain; the Slingbox is not like YouTube or Napster. The Slingbox only unicasts content, not broadcasts it. The Slingbox only allows one person to watch content remotely at time. Not only that, the Slingbox encrypts the video content it streams, so even if someone could tap into your SlingStream they couldn't watch it! Although, the Slingbox hasn't been tested by a legal challenge yet, the smart money is on Slingbox winning due to the precedent set in the Sony vs Universal Studios case (aka the Betamax case).

Anyway, if you're away from home much (or even if you aren't), I can't recommend this product highly enough. And you just might want to get one anyway, in case some judge makes it illegal in a fit of stupidity. Otherwise, you'll be forced to pony up for DIRECTV® SAT-GO which isn't nearly as cheap or flexible as a Slingbox is.

Over at my second home, I talked about how to annoy sploggers w/ a dynamic image. A dynamic image is merely any image generated programmatically at request time. So with a dynamic image, you have total control of the content that will get displayed when the url gets requested.

Typically, when a splogger copies a blog post, they often times leave all the original hyperlinks and images links intact. Sploggers are lazy folks. If they are too lazy to write their own blog post, they are usually too lazy to edit yours. So if they do hotlink to an image on your server, they are now dependent on your server to serve that image request. And this is why we can change the image out from underneath them and have fun with them.

If you're interested in more background on this sort of thing, I'd recommend you check out Scot Hanselman's Computer Zen blog post on HttpHandlers. Anyway, here's how my variation worked…

This first thing I did is write code to generate a text warning message… Nearly all modern web development frameworks have the ability to generate images on the fly, and put the generated bitmap on the request's response stream. So here's some C# code that draws some text in a solid colored rectangle.

OK, now that we have the images we want to use, we need to write code which will generate a different image depending on the circumstance. So, what I did is look at the HTTP_REFERER header from the current request. If a web browser requests an image from a web page, it will usually place the url of the page which is requesting the image in the HTTP_REFERER header. However if a web browser requests the image directly you may not get that header in the request. Also, I've read that Norton Internet Security strips out the header and I'm sure proxy servers that muck with the headers too. In short, you can't count on that header being there.

Also, it's important to note that the value in this header can't be trusted. If the image is being requested by web browser there's a good chance it'll have the value you expect. However, there's nothing preventing a hacker from creating an HTTP request that is identical to the one a page from your domain would create. So, it's is really only effective if they retrieve the image from a sploggers web page.

OK, now that we got our image, we gotta send it across the wire. The only tricky part is that we have to tell the browser not to cache the image, since otherwise; the browser will reuse the image regardless of the domain it's being hosted on. So if somebody visits your blog and then the splog, it's likely the browser would display the same image in both places because the browser cached the original image, and re-uses it if somebody else refers to it.

Anyway, it's not an industrial strength approach but it's enough to stop the causal splogger from stealing content again. For an industrial strength solution, you'd have to combine this approach with IP black/white and IP geo-location and other tricks that products like Port 80 software's LinkDeny employ.

And if Mr. Haack reads this and gets around to creating a world class plug-in model for SubText, I'd be happy to contribute a basic anti-leach / anti-splog plug-in for it. It's not fair that the WordPress kids have all the fun.