Monday, February 16, 2009

Documents, Images etc in a database or the file system, and looking after you clients

I've had cause in the past to do a little bit of research into the "right" way to store files that relate to a Windows Application.

Do you embed the whole image, document, spreadsheet...whatever, into a massive binary field and store it away in you database, or do you let the file system do what it does best and manage it?

There are arguments for and against each way - mostly I must say, for letting the file system do it's thing. This is the approach I've used most of the time.

There is one big overriding factor in this decision though. Your users.

It is common knowledge (and shouted loudly by Alan Cooper in the Inmates are running the Asylum) that the file system is one of the most illusive, mystifying and unattainable concepts for "non-technical" computer users to grasp. Locating, moving, copy or creating files in the labyrinth that is c:\, or "My Documents" or "My Computer" or now, Vista's "Computer" or "username" or "Documents" is just beyond the vast majority of computer users in the real world, particularly outside the managed environments of the worlds "Enterprise" environments. Here, network shares are unheard of let alone re-directed user folders and the like...

So how can you impose the responsibility of archiving and maintaining backups of electronically lodged payroll data (for example), and the continued storage and accessibility of said files, required by law, by the Australian Tax Office (in the case of my current example)...how can you impose that responsibility on Ma an Pa business manager, who might bake the best bread, build the best houses or produce the best wine and even run the most efficient business outfit, in the district, when those same people a flat out understanding how they actually save that file to a given folder, and when they manage that, have no comprehension of how to retrieve it again, let alone back it up, archive it, and have it on hand when a contractor that picked fruit for them for 2 weeks, 9 months ago loses his group certificate - you can't!

The most you can insist on is that they backup their database and put it somewhere safe as regularly as possible, and you can give them (or better still build them) some tools to do specifically this. Don't make the learn the file system. I say, in this environment, throwing those files (or at least copies of them) into your database so they are all backed up and immune to the vagrancies of the file system, immune to new lap top purchases, new user accounts and renaming folders en-masse - and are sure to be backed up.

Sacrifice the "best" technical solution, for the sake of your user. Let them achieve the goals without needing to learn what you all know about file systems, or servers, or network shares and so on. They don't care, and they don't have to care.

This rant is not meany to "dis" anyone who holds the common opinion of avoiding storing files in the database - I happen to agree with that, but be sure to only "avoid" it where possible, and where possible means, where you aren't lumping your users - your customers - with the undue responsibility, cognitive friction as Alan Cooper would call it!

Wednesday, February 11, 2009

Streams demystified

I must admit that even though I've been using .Net and C# for about 8 years now "Streams" have never really "jelled". There's all these Streams, StreamWriters, StreamReaders, TextStreams, MemoryStreams, FileStreams. 

I must be honest - it's been pure laziness that has prevented this. This is a bit of a pattern with me. Just getting stuff to work. Hacking it together. Anyway, as I was copying another slab of code today, I had had enough.  I needed to "get" this. So I pressed F1 - called up the MSDN help and read... I stumbled across a page titled "Stream Concepts" - or something like that.

The introduction on "Stream Concepts" explained how all Streams have a Base Store. FileStream - a stream of "stuff" from a file. MemoryStream and stream of stuff from or to "memory". Then it explained how StreamWriters and StreamReaders append themselves to those Stream objects, via the constructor - because when you instatiate a StreamReader, you specify the stream in the Constructor...suddenly, some penny somewhere dropped. Things started to make sense and knew they did, because I was able to whip up some code that was nice and clean, succinct and worked, without converting stuff through about 8 different objects, reader here, writers there and so on, without copying it from somewhere else...and it worked.

Now to the seasoned .Net developer - which I should be, this is trivial and probably makes me look stupid...if so, so be it, i probably am...but I'm a little less stupid that yesterday.

From now on, I am going to force myself to search for this "deeper" knowledge everytime i strike something I don't "get", that I should get...it maybe 20 years to late, but I'll be a decent developer yet...!!

==========

Then, on the way home listening to to Podcast #40 from StackOverflow, the guys (Joel, Jeff and some other dude) were talking about continuous learning, reading and so on - they talked about "deep" learning. That was it. I need far more deep learning. Maybe not as deep as they were talking about, but deeper that cobbling together code that works without really "getting" it... I have to do this...

Tomorrow I'm starting a 4 week, basic (really really really basic) photography course - for people with point and shoot cameras. It maybe simple, and an absolute starting point, but the same principle applies.  I want to learn this stuff properly and if it leads me to spending heaps of money on new cameras, because, as usual, all I learn is how much I need to spend to do things properly, well so be it.