Sunday, April 29, 2007

Amazon Unboxed and Media Center

I used Amazon Unboxed to watch Turistas (review here) last night.

It was pretty seamless. It installs a little player, and that player can view the movie at fullscreen.

The movie itself was a bit lower bitrate than DVD (came out to around 2GB, IIRC), so the fidelity doesn't compared to Xbox Live Marketplace's HD videos, the picture still looked really good on my PC. I have a 20" Dell monitor that I run at 1600x1050. I'm going to guess they use MP4 because Mpeg-2 at that bitrate probably wouldn't have looked as good as it did at that resolution.

But I was left wondering, why doesn't this work with Windows Media Center? It would have been nice to download it on the PC and then watch on the Xbox via Media Center Extender. Why aren't vendors like Amazon incorporating their product into Windows Media when that platform can be extended, making a better experience for the customer?

It seems like Media Center is a mess right now, even at a time where Vista has improved the product. And it's shipping with most Vista machines via Home Premium or Ultimate editions to boot, so the software is "free" (kinda, but I doubt you'd want to run Vista Basic). Yet Media Center might be on the ropes more than ever before thanks to the Apple TV device. What good is having Media Center on Vista when:
  • Actual Media Center PCs generally cost over $1000.
  • HDTV Media Center PCs cost $4000-$7000.
  • Devices like the ATI OCUR, which allow Cable Card to be used as an add-in to an existing PC, won't be able to use MC due to Microsoft's draconian position on HD content protection under Vista.
  • Did I mention Vista's draconian DRM stance?

Microsoft is basically screwing the pooch on this one. Media Center is actually pretty good, all I really want it to do is replace my stupid Comcast DVR in an affordable way. I've got the PCs to do it, I just need an HD cable card. Isn't this supposed to be the "commodity PC way" that Microsoft has always talked about? If so, why is Microsoft forcing me to buy a whole new PC that costs thousands?

Sunday, April 15, 2007

XML Databases - SQL Server 2005 v. DB2

I used to laugh at the term "XML Database," because usually that meant a bunch of semi-organized XML documents on a filesystem with no index.

Today, however, there are RDBMSes that have incorporated XML functionality that make this a more viable method of storing data. If there's anything I've learned about tech, it's that a not-so-great solution that people adopt will be optimized and a great solution no one knows about will eventually die. In this case, people adopted XML, so they'll keep hammering away on the storage tech until it's viable. Likewise, this is how we're eventually going to see JITted Javascript -- something I predicted around the time that Web 2.0 was taking hold.

We've been using SQL 2005's XML functionality on a project because the people entering data wanted the luxury of freeform data in XML. This has turned out to be pretty good, although we could have taken it even further. These databases allow you to insert and replace Xml nodes right in the document. Of course, this is nowhere near as fast as using SQL, but the flexibility is pretty great. Anyone who has had to deal with changing schemas on a DB should be familiar with this. If your data is never locked down in the first place, it turns into a nightmare.

I've been reading for a while that DB2 supports Native XML better than SQL 2005, so I decided to give both a try this weekend and see how they compared.


Versions

DB2 Express-C v9.1
SQL Server Express 2005 SP 2


Tests
  • Single row with 6mb of XML, queried via XQuery
  • Same XML file shredded into ~6000 rows in a table with an XML column, queried via XQuery
  • Traditional primary key test.
  • No additional tuning except creating XML indices.
  • All queries done through ADO.NET for consistency.

DB2 Pros:

  • Deployable on Linux, AIX, Solaris, Windows, etc.
  • Consistently the best performance at doing Xquery across shredded XML.
  • XQuery with index across shredded XML better than or equal to typical sql primary key!
  • Consistent query speed even without an XML index.
  • Inserts are very fast.
  • XML indices can be set up for individual XPaths, targeting exactly what you need.
  • XQUERY is a direct command that can be used, rather than querying via SQL functions.
  • Index on 6,000 rows of XML did speed up XQuery across them.
  • Still works well with ADO.NET out of the box.

DB2 Cons:
  • I was able to crash the entire database... yes, I got a C++ runtime error dialog for db2syscs.exe, when I tried to delete a couple columns from an existing table. Nothing fancy, and the DB was completely hosed at that point and I couldn't even stop or restart the thing using their tools. I had to go into Task Mgr and kill all DB2 processes by hand and restart. Obviously, this is inexcusable for a shipping database product.
  • DB2 never ever shuts down gracefully for me. It always complains there are still connections even when there aren't. Back to task manager to kill it!
  • XQuery on 6mb XML blob was never very impressive, speed-wise.
  • Setting up XML index this seemed to have no effect on my 6mb XML file in a single row speed.
  • Documentation is a near-unusuable collection of one page descriptions with no samples.
  • Java-based database management tools suck hard. It's barely usable and has a huge memory footprint to boot. Oracle's Raptor tool is better, though, that too being in Java, it is only slightly better.

SQL Server 2005 Pros:

  • Better command cache and query cache. Doing the same query twice results in queries taking microseconds rather than milliseconds.
  • Fastest at XQuery within one 6 megabyte row of XML data.
  • Far better documentation.
  • Far better tool for database administration (SQL Server Management Studio Express)

SQL Server 2005 Cons:

  • Poor performance at xquery, using exists() across shredded XML.
  • Windows only.

XML/XQuery Pros:

  • Flexibility.
  • Ability to push XML straight from DB to XSLT, if you're into that sort of thing.
  • Did I mention flexibility?

XML/XQuery Cons:

  • Typically slower than traditional primary keys (Except on DB2).
  • Never got SqlParameters feeding into Xqueries for neither Sql Server nor DB2.

So after all that messing around, I decided to do a little control study with MySQL, which has no XQuery or native XML support. In order to weed out the hype of "Native XML", I thought this necessary.

Obviously it's tough to navigate the large 6MB blob of XML on MySql, so I decided to put it up against the shredded XML using "WHERE xmldata LIKE 'lots of percent sighs'. And actually...

  • MySQL outperforms SQL Server when working on shredded XML. (by an order of magnitude)
  • MySQL underperforms DB2 when working with shredded XML. (by an order of magnitude)

Sad, but true. Microsoft's XQuery hype gets killed by using "WHERE ... LIKE" in MySQL on shredded data.

Based on this, here's a guide for while DB to use:

  • Non-shredded, huge XML blobs: SQL Server 2005.
  • Shredded, XML in rows: DB 2.
  • Pure read performance: MySQL.
  • Best in show: DB 2.

I wish I didn't have to write that DB 2 was the best in show here given the crashes and trouble I had with it, but: in general, if you need to use XML in your database, DB2 is probably the best choice.

Wednesday, April 11, 2007

Pavement "Unseen Power of the Picket Fence"

I was just listening to another Rhapsody-picked playlist (most of my music listening choices these days are determined by Rhapsody).

Anyway, came across this song by Pavement that harkens back to the old days of REM albums. Those of you who think "Reckoning" is R.E.M.'s best album will appreciate this. Those of you who learned who R.E.M. was when they came out with "Out of Time" probably will not. I worked in a record store called FlipSide in Wauconda, IL when that came out, and we used to call the CD "Out of Talent."

Anyway, here's Pavement's lyrics for the song...



Some bands I like to name check,
And one of them is REM,
Classic songs with a long history
Southern boys just like you and me.
R - E - M
Flashback to 1983,
Chronic Town was their first EP
Later on came Reckoning
Finster's art, and titles to match:
South Central Rain, Don't Go Back To Rockville,
Harbourcoat, Pretty Persuasion,
You were born to be a camera,
Time After Time was my least favourite song,
Time After Time was my least favourite song.
The singer, he had long hair
And the drummer he knew restrait.
And the bass man he had all the right moves
And the guitar player was no saint.
So lets go way back to the ancient times
When there were no 50 states,

And on a hill there stands Sherman
Sherman and his mates.
And they're marching through Georgia,
we're marching through Georgia,
we're marching through Georgia
G-G-G-G-Georgia
They're marching through Georgia,
we're marching through Georgia,
marching through Georgia
G-G-G-G-Georgia
and there stands REM

Sunday, April 08, 2007

Porting a website from Rails to ASP.Net running on Mono

I've had a website I've been wanting to expand on for a long time (a college basketball site called Hoopd), which I originally implemented in Rails. I meant to do a lot more with it, though it's ended up just faithfully showing an RSS feed for a couple of years. Since that time I'm much more well versed in C# and never really ended up buying into the Ruby/Rails hype anyway.

So today I finally decided to give ASP.NET on Mono the college try. I've been running on a Redhat 9 box that would be tough to upgrade.

I'd like to outline what it entailed to get the small app running on Mono. Obviously, more complex ASP.NET sites will take a lot more work, but I thought I'd record the basics of what it took. For example, it has no database... yet. So there's a lot more learning to be done.


Getting Mono Running

I had attempted previously to get Mono running on this RedHat 9 box. To my delight, Mono 1.2 works right out of the box on RedHat 9 and Apache 2.0.x. However, xsp wasn't showing me any pages when I tried to get it to display a simple ASPX page.

I had to:

  • Get a new glibc (this is par for the course on Linux, right?)
  • Build and install a new APR library
  • Build and install mod_mono from scratch

At that point, xsp2 started to work on port 8080. Mod_mono was looking in the wrong place for mod-mono-server, so I linked it from /usr/local/bin/mod-mono-server to /usr/bin/mod-mono-server2. I didn't want to screw around with Apache configuration to get ASP.NET 2 functionality, so I just linked mod-mono to only use 2.0.

Getting the app to run

The actual coding of the ASP.NET app was very simple, and I won't outline it here. Suffice it to say, you can easily use Visual Studio 2005, precompile your applications, and run them in Mono.

That is, unless you have a bug in Mono itself. Those are painful to debug. I had one of these bugs today.

The first problem I ran into when trying to debug is that Mono has no support for App_Code directories. App_Code is a new structure in ASP.NET 2.0 that allows you to stash all of the business logic, whatever, into a separate directory than the web pages and their related code. As a result, I had to put <@ Assembly Src="App_Code/mydir/blahblahblah.cs" @> directives into my ASPX page to get Mono to compile them. Fortunately, I have only about 8 or 10 C# files right now, so this wasn't that difficult... but it wasn't fun either.

After I accomplished that, it was time to start debugging, right? Well, you can't really debug a running ASP.NET application on Mono on Linux. And, the reason I went through this process of adding Assembly tags is because Mono refuses to print out line numbers in stack traces for my code. It prints them for the System.dll libraries just fine, as well as the webpage, but all of those CS files I painstakingly added to my ASPX file did not get line numbers in the stack trace.

So how do you debug? System.Console.Writeline, of course. Running XSP2 and using strategic writelines narrowed down the problem and I was able to work around it.

The problem is that Microsoft's XPathNodeIterator and Mono's XPathNodeIterator behave a little bit differently, it seems. Microsoft's has "Current" already connected once the iterator has been filled, whereas Mono seems to skip the very first item and have a null in there. It's really odd. I have to debug it more, but since this is just for a silly RSS feed it's not urgent right now. The important part is that to figure this out, it required System.Console.Writeline. Yuck.

To debug stuff in the future, I'm going to see if I can run Mono's standard library from the debugger in Visual Studio. But at least I'll run Mono on my Windows box to speed up the debugging turnaround time a little bit. Though, if I get into hairy CLR problems with Mono, I'm sure I'll reach my breaking point quickly with this and ditch it for a Microsoft hoster.

Performance

Microsoft's debugging server delivers about 2-3x as many requests as Mono's production server. Tracing what Mono was doing, it seemed like it spent a lot of time in Viewstate code, even though I flagged about every possible way that it should ignore Viewstate.

Security

Mod_mono automatically knows to block web.config and C# files. There are a couple holes I found though:

  • A user can load Master pages directly with Mod_mono/Apache, which is automatically blocked by IIS. It's kind of humorous because it just shows you a template, but to some, this might be a security risk.
  • The bin/ directory of precompiled applications is not blocked by default. Use .htaccess to block it if you're using precompiled DLLs.

In conclusion, this was a successful experiment and I'm going to try to build out that site on mono as I had hoped I could. I'm glad to see Mono supporting an older version of Linux so well, and that I was able to get an existing app ported from another framework to ASP.NET running on Mono so quickly!