Now all we need is polarized contact lenses so you don't look silly.

If you had to destroy hard drives regularly, the Pure Leverage hard drive crusher looks like a nice way to do it:

http://www.youtube.com/watch?v=vY3ZssxkcsQ

But it's a bit expensive for only 10 drives -- $325.

Yes, I've cursed them for more than 25 years because trying to fit desktop application storage into relational models nearly always creates more work than necessary.

Except that the column types are fixed. What happens if keys point to different types of data (images, text, movies, urls, other tables)? Do you create one column for every type of data that may be used into the future? One table per data type? Do you misuse blob columns? One of the nice things about sqlite is that it doesn't force developers into such a restricted world view.

Just because you can haul anything in a semi truck doesn't mean that a semi truck is the optimal vehicle for hauling everything. Sometimes it's better to use 5 minivans. Do you seriously think that Google Maps are implemented in BigTable because the folks at Google were too stupid to use a relational database?

The OOP to Relational mismatch is described at: http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch

Relational databases work well for certain types of data but to assume that tables of rows and columns work for every need is silly.

Relational databases are inherently hard to scale because they mix data together that doesn't necessarily need to be together. If there's no reason why Bob and Alice's records should be in the same table or on the same machine then they shouldn't be. You can avoid all contention by distributing each individual's records on unique or underutilized machines.

Relational databases do not work well for storing hierarchical data like a file system or an object-oriented data store. They do not work well for large blobs like movie files or for unstructured documents like medical records. Because of their rigid structure, they do not version well because copying records to older versions of the schema loses data - if the column doesn't exist there's no place to put the data (imagine if application versions 1 and 2 have to read and write to the same database).

Relational databases have their place and I completely agree that transactions are vital to data integrity, but the fixed column data model is way too limited to store all of the kinds of data used in the real world.

"The bitterness of poor quality is remembered long after the sweetness of meeting a deadline is forgotten." -Charles Kettering

Don't post it to IEEE. That will guarantee that 90% of people interested in your paper won't ever be able to read it. Just put in on your blog with a note here in SlashDot.

Are you trying to monetize it? If so, you need to file for a patent instead. Naturally everyone here would prefer you publish it for free on the internet instead.

http://en.wikipedia.org/wiki/Port_knocking
http://www.portknocking.org/

Ann Arbor's Hands-On Museum has at least two interesting computer displays:

1. Colorful visual effects via a computer projection system which the kids can control by moving in front of a video camera. You really have to see it. Found a photo at: http://farm1.static.flickr.com/57/175283594_e5a67d0221.jpg

2. Green screen chroma key area where kids can fly, swim, deliver the news, etc, while other kids act as TV news directors at a control panel

You want a 32" TV with 720p rather than 1080 resolution.

Run the monitor at 1280x720 (native) and everything will be large and readable.

At 1080, the pixels are still fairly small at 69 dpi, but at 720 they are a large 46 dpi.

This is a great response - making sure that you can't be sued personally is a good first step. Making sure that the company has no assets is another good suggestion - nobody is going to spend hundreds of thousands of dollars suing your company if they can't get at least that much back.

Patenting some of your "inventions" in the software can help you against established software companies. They'll be less likely to sue you if you have a patent that you can sue them over. It's like Mutual Assured Destruction with nuclear weapons.

Lawyers are useful, but don't blindly listen to them. We were hit with a patent infringement threat and instead of spending more money on lawyers that suggested we settle we instead found prior art and sent a response to the company saying that if they didn't go away we'd send the prior art to everyone else they were suing. They went away. Cost us a few days of research, but nothing else.

In short, don't make it worth anyone's time to sue you.

This quote is from a writer, but applies to programmers as well:

"Plumbers don't get plumber's block. Don't be self-indulgent. A page a day is a book a year." -- Howard Fast

I find the best way to avoid programmer's block is to work with someone else and depend on each other's work.