The leftovers

[elfs]

The leftovers.

And this is what I recovered from my office space today. Three stacks of books: the one with The Humane Interface is heading over to Half-Price. (It also contains A UML A Pattern Language, which was basically buzzword-compliant bullshit once upon a time, Java Swing from O'Reilly, and Eric Meyer's On CSS (a great book for it's time, but nowadays most of what Eric taught me I know or can look up on A List Apart). I'm still keeping much of my older, harder books, the Nutshells and so forth.

Other than that, a few notebooks, the 2008 planner, a bottle of aspirin and one of naproxin, a box of emergen-C's mostly unused, my Kanji-a-Day calendar, photos of my kids, two coffee mugs, a pair of headphones, a calculator, a CHIMP, a couple of plastic toy insects from the recession-killed Science Art and More (a great store, but now gone, just like the Discovery Store and now Learning Quest at Southcenter... science-based toystores just can't seem to stay open), and my ancient Beanie-baby skunk mascot.

Bleah. Detritus, all of it. I was glad to get my New Riders Python book back (it's for python 2.1, and yet it's still the best damn python reference ever made), as well as the O'Reilly Dynamic HTML, (which includes great ECMA-262 guidelines and solid CSS advice, as well as DOM programming).

I'm still keeping Managing Gigabytes. It's still a fascinating read, and since compressing and repeatedly reading and decompressing the data soon requires less electricity than reading it directly; decompression, especially with super-cheap specialized chipware, soon becomes cheaper than leaving the data uncompressed, especially if you know your dataset's decompression blocksize fits within your server's RAM for queries and you can keep the index hot. I had an idea a few years back for adding a second, structural index for XPATH queries, and then trying to simplify the old MG package (which is in Java, and unbelievably hard to grok), but I've never had time and Isilon wasn't interested. Indexing their huge pools is someone else's problem. I also kept my Knuth's Literate Programming. Yes, LP can be taken too far. But the discipline of LP is wonderful stuff, and good practice. Every time something became sprawlingly complex, I'd put a comment in the text:

/* Going Literate.  See Knuth, Literate Programming, pg 99. */

And would then follow with a lot more "intent and flow" commentary than most people could ever want.

I had three standards at work: whatever we must do must maximize customer understanding and minimize service calls, because service time is money; it must help, and not hinder, sales, as we were the UI, and the UI is what sales people use for demonstratin purposes; it must not become a maintenance nightmare. The last became harder in the era of Ajax, with half our program written in Javascript, and half in Python, but we tried hard to get it right.

I only hope my next employer appreciates that. I'd hate to leave these books here forever.

Comments

[resonant.livejournal.com]

Can you expand on how storing frequently-accessed data in a compressed format is more efficient? Not that I don't believe it, it's that I don't understand the mechanism.

[elfs.livejournal.com]

It's actually quite simple. If you choose a method of compression where compression and disk access are expensive, and decompression and memory are cheap, then the time and electricity costs of reading the information off the drive and decompressing it is less than the cost of reading the larger, decompressed block off the drive in its entirety after the 'nth' access.

This was true fifteen years ago when I was doing the work; it may be different now, but I doubt it: drive size makes accessing even more expensive, while customized hardware can make the decompression even less so. (Witness the popularity of MP3 decoding chips, although that may be a bad example.)

Flash drives will definitely change the numbers, but I suspect the cost and difficulty of manufacturing them may make them a less palatable option for cost-conscious institutions for a while.

[resonant.livejournal.com]

Ah. Thank you.

[lovingboth]

For a web design site, A List Apart looks awful - those columns are far too narrow and also don't resize if you zoom the text.

I once did the compression stuff for a project on 'every mA of power is sacred' handhelds. Seeding LZ77 tables with text I knew would often appear meant the compression ratios were much better than a general purpose routine and LZ77 decompresses very quickly.