As recently as three or four years ago, it was still possible to find the lyrics to songs on the internet with limited hassle. It seems now that all of the lyrics to every song ever written in the history of the world have been hijacked by the browser plugin people. Clever.
I’m not sure what they intend to gain from this magnificent marketing move, especially since most of the sites just crash my browser in XPSP2. I’m sure it doesn’t help that apparently, twelve thousand people had the same idea. In a way, it reminds me of the Underpants Gnomes.
- Collect the lyrics to songs and irritate everybody by not actually letting them see said lyrics.
- ????????
- Profit!!!
Those of you watching the NFL coverage over the weekend may have heard the normally brilliant Chris Berman repeating some gibberish about the Redskins predicting the outcome of the presidential election with astounding accuracy. You can read more about this now-defunct nugget of trivia at Snopes.
Chris, I ask you to please consider the following facts before repeating such nonsense in the future:
- In most election years, the outcome of the race can be predicted with better than 50% accuracy (ie, better than a coin flip). In really close years like this one, it’s never worse than 50/50, Ross Perot notwithstanding.
- The Redskins, or any other sports team winning any particular game over long stretches is probably around 50% too. Other predictors, like the Nickelodeon mock election, have a better chance since they’re actually trying to be predictors.
- There are at least 500 bazillion things you could point to as predictors of the outcome, depending on how far you want to stretch.
Given those odds, it would be really freaking amazing if a few of those predictors did not predict the outcome for long stretches of time. I tried, in a very passionate yet fruitless attempt, to explain this to my boss. “No raise for this guy,” is what I’m sure he was thinking.
One other stat I’d like to point out is the odds that nobody will listen to me and repeat another inane predictor in 2008. I think that this may be infinitesmially close to 100%.
As for me, I voted for Roethlisberger.
There are many articles out there covering the well-known DataSet serialization performance issues. Dino Esposito had a pretty good article in MSDN magazine outlining this, and the ADO 2.0 solution to it.
There is another DataSet serialization problem which I consider to be almost as annoying, that is unfortunately not addressed in ADO 2.0. This program attempts to highlight it:
using System;
using System.Data;
using System.IO;
using System.Diagnostics;
using System.Runtime.Serialization.Formatters.Binary;
// Simple class that holds a reference into the dataset.
[Serializable]
internal class DataSetDescriptor
{
private DataSet _data;
private DataTable _root;
public DataSetDescriptor(DataSet ds)
{
_data = ds; _root = ds.Tables[0];
}
// Ensures that the _root table is really the same
// one that's in the dataset.
public void Assert()
{
DataTable t = _data.Tables[0];
Debug.Assert(object.ReferenceEquals(t, _root));
}
}
class Program
{
static void Main(string[] args)
{
DataSet ds = new DataSet();
ds.Tables.Add();
ds.RemotingFormat = SerializationFormat.Binary;
DataSetDescriptor dsd = new DataSetDescriptor(ds);
// This will (obviously) succeed.
dsd.Assert();
using (MemoryStream stream = new MemoryStream())
{
BinaryFormatter f = new BinaryFormatter();
f.Serialize(stream, dsd);
stream.Position = 0;
dsd = (DataSetDescriptor)f.Deserialize(stream);
}
// This will (curiously) fail.
dsd.Assert();
}
}
The reason the second assert fails is that the _data has serialized the _root into itself, thus breaking our reference to it. The _root is serialized again by the formatter’s algorithm, so we get a copy. This image might help to understand the issue:
I have my own not-for-the-feint-of-heart (but transparent to developers!) solution to this, which involves remoting sinks and a bunch of surrogate classes. It doesn’t look like I will be retiring it anytime soon.
While I’m on the subject, one thing that I find simultaneously funny and depressing is that in the VB.NET version of the famous DataSetSurrogate solution in KB 829740, option strict is off. If you actually run the Visual Basic example, you will find that it is considerably slower than the default DataSet serialization as a result of late binding. It’s slower than the C# version of the program by about a factor of ten.
