Monday, March 30, 2009

The case against the case against everything buckets

Alex Payne writes a good piece about how everything buckets are awful.

He defines everything buckets as applications where you can store every imaginable piece of data and then search over the RTF or PDF documents it generates. Or, in his own words:

These applications claim to be “your outboard brain” or “your digital filing cabinet” or similar. They go by many names: Yojimbo, Together, ShoveBox, Evernote, DEVONthink. There may be differences in their implementation and appearance, but these applications are all of the same sinister ilk. They are Everything Buckets.

He then continues on how these kind of applications suck because they try to do many things at once and fail miserably at most if not all of them. Additionally, he says filesystems already have all the features that allow you to organize all the information you want (you can even have tags via symlinks, he stresses). There's no need to pay for these lousy implemented, do-many-things-wrongly apps.

Computers like structured data and so filesystems are a good way to store hierarchical information without the need for expensive indexing tasks current operating systems usually perform (Spotlight, Beagle, and so on).

This is all good and well, though there are people who think hierarchical filesystems suck.

Anyhow, even if everybody agreed that current filesystems are Sliced Bread 2.0, this well construed argument lacks a pretty important consideration, which is people want the computer to organize their information for them, even if current applications blow. Alex is too quick in dismissing the concept, only because there is no good implementation of it.

All these arguments could have well been used against web search 12 years ago, and I need not mention what happened to it. A good everything bucket would not prevent you to do work with your computer when you want to, nor would it corrupt its data, additionally it would cross reference the data and automatically insert what you throw at it into relevant buckets with little user input.

Alex's advice is right in that, as of now, you are better trying to organize your information manually via the filesystem (YMMV), but he's wrong in that you will never be able to have a good everything bucket application, and even more wrong when he says everything buckets shouldn't exist.

The need certainly exists. The fact that current individual personal computers suck at managing unstructured information and take too much time at creating structure from the chaos is merely accidental.

Let us create a good Everything Bucket soon enough.

UPDATE: As always, I arrive late to the party... and, of course, some people like current everything buckets. I still think they can and should do a lot better.

Monday, March 9, 2009

Excel Interop COMException HRESULT 0x800A03EC via C# (.NET 2.0)

Today I'm writing some code to read Excel files via the interop assemblies. I was reusing working code and it suddenly started failing with a COMException which said the error code was HRESULT 0x800A03EC.

I'm using the following code:

string excelLocation = @"C:\test.xls";
Microsoft.Office.Interop.Excel.Application _app = new Microsoft.Office.Interop.Excel.Application();

Workbook wbook = _app.Workbooks.Open(excelLocation,
Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
Type.Missing, Type.Missing, Type.Missing, Type.Missing);

Worksheet sheet = (Worksheet)wbook.Sheets[1];

/** rest of the code **/

and I get the COMException in the line where I open the workbook.

So, I open the file via regular Excel and I find out it finds the file somewhat corrupt, Excel tells me it had fixed some font and sheet name problems with the file and that if I want to make that fix permanent to save the file. I save the file and then the code works!

But wait, this is not the proper solution if you want a truly automated processing of the files. Given that I don't control the Excel generation process I cannot fix the corruption on the source side of things, so I'll have to fix it on my side.

I started to dig into the Open method parameters and found that the last parameter is suggestively called 'CorruptLoad' so, the solution:

string excelLocation = @"C:\test.xls";
Microsoft.Office.Interop.Excel.Application _app = new Microsoft.Office.Interop.Excel.Application();

Workbook wbook = _app.Workbooks.Open(excelLocation,
Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
Type.Missing, Type.Missing, Type.Missing, true);

Worksheet sheet = (Worksheet)wbook.Sheets[1];

/** rest of the code **/

And that opens it without throwing an exception and gets all the data in the sheets, at least for this particular type of file corruption.