Navigation


RSS / Atom



Steal this box

2011-11-29 , , , Comment

What was Amazon thinking by packaging the Kindle Fire in a book-sized box with a distinctive clipped edge and “Kindle Fire” printed on the sides? It screams, “Steal this box!” and that’s exactly what happened to Maria’s kindle. It disappeared between the UPS departure scan of “Out for delivery” and, well, the actual delivery. It never made it our house for scan and signature.

Amazon made good on it and shipped another overnight that we did receive. A slightly belated anniversary gift but she loves her new ebook reader/entertainment device.

Comment


Woolgathering

2011-09-22 , , , Comment

The old Honda scraped its pegs as I gasped on adrenaline, cold tires and wild-eyed speed on an over-cooked turn. Giggle, go slower now. The smell of apples rotting on a fallow orchard mingled with an over-rich idle that I’d meant to do something about but never did because it ran so well up top. I couldn’t tell you why I got up in the dark, slipped out of a warm bed next to my wife, left good friends, to be alone in the pre-dawn wet. I pulled on my boots, zipped the suit, clucked to myself the preride checklist. Fetish against harm. In three hours the house would wake with hot coffee and good conversation. But I’m gone.

Fast forward, a triumphant super-ego and an empty garage bay. Swapping stories of great rides over drinks after work, a bullshit four corners plan for when the kid is grown.

Comment


Advice to software vendors

2011-03-13 , , ,

I am regularly frustrated and annoyed by “Enterprise” software vendors who have never deployed one of these Nimitz-class systems outside a VM running on their salesperson’s laptop. Here are some hints on getting your software into the Proof of Concept instead of running aground:

  • Components go into packages Think of your software in terms of components- core, recommended, optional, client, GUI, docs, etc.- and package that way. I don’t want to manually disentangle a couple of gigs to get the feature set I need. This leads to…
  • Package documentation separate from binaries You get points for having documentation, bonus points if you document your DB schema, double points if the docs bear a passing resemblance to the actual shipping product, but please put the PDF’s, the man pages, the knowledge base and that copy of the website into a separate installation. I really will Read The Fine Manual, I just don’t need to have that whiz-bang local copy of your multi-product infocenter in with binaries. Which leads to the next point…
  • Separate out third-party code If you require a web server and provide Apache, great, put it in its own module. If you require, for example, a JVM, put it in its own module. If you include third-party libraries, put them in all their own module. Don’t shovel at me the entire stack of http server, JDK and out-dated versions of half of the Apache project.
  • Fancy installers must be optional It’s possible that some of your customers’ IT people care barely wipe the drool off their chins, but I should not have to reverse-engineer your installer. Put the GUI in front of simple, standard tools and formats. Better yet, provide a second console-based installer script written in- pick a language- shell, Perl, Python, TCL, REXX, whatever makes you happy. On a deployment of any size, the installation will be done in anger twice- once in the test lab, once for deployment. Your installer will not be run by hand on ten thousand systems. If it does need manual attention, it probably won’t get past the first time. This leads to the next two points.
  • Use a package format accessible with common tools If the platform doesn’t have a native package system (pkg, deb, rpm, msi, etc.) use the standard tar, gzip, bzip2 or zip. 7zip and LZMA is fine. On Windows use zip, cab, msi and sfx. Go old school Unix and use cpio and compress if you like but don’t force me to use the installer to get at the contents.
  • Don’t assume anything about your system privileges, the filesystem or paths One size does not fit all. You may not have rights to scribble in arbitrary directories. You may not be run as root. You may install in a staging area with different paths than those found at runtime. Common binaries may not be found in /usr/local as you expect. Assume that paths will always be the maximum of POSIX, XOPEN or sys/syslimits.h maxpath, UNC max length, etc. Always give me a choice and leave enough space for the locally correct answer.
  • Don’t strip binaries When, not if, your code fails spectacularly I want a useful core dump. So what if the symbols take up room on disk, for any contemporary system there is plenty of space. For Java, also don’t run it through an obfuscator. If necessary, provide a second set of binaries with symbols and let me choose. Don’t tell me after I send you a 3.9GB core that there are no symbols and it will be a few days before your build team can get me an unstripped release.
  • Design with the debugging in mind Leave it in the release. If a flag or environment variable is set, emit debugging. Points for emitting it to STDERR, deduct two points for emitting it to both STDERR and STDOUT. Deduct ten points if it lacks timestamps. And speaking of timestamps, deduct twenty-five points if your run-time log lacks them, deduct fifty points if failed assertions lack them.
  • Include an API I’m sure the dev team thinks the software is perfect- or as close to perfect as the release date permitted- but you can not forsee every possible use of your software. Extra points if it’s in C, deduct a half point for C++ (no change for Java or for Perl or Python as I can make my own bindings if you give me a C API). Bonus points if there are callbacks or hooks exposed in the product, I’ll want to use those to change its behavior or implement something you don’t (ex. security). The API should be the same one the tools you provide use and it should access all of the product functions. If it’s crippled, it’s worse than no API at all because it will waste my time.

Comment


RFC822 Ignorant Sites

2011-03-05 , , ,

Since writing about my pet peeve of non-RFC compliant web forms (http://www.lonsteins.com/blog/2010/11/24/what-s-so-hard-about-rfc-822-addresses) I’ve decided to keep a list of sites that should know better. Sending email doesn’t seem to help, perhaps someone somewhere will be embarrassed if it turns up on a blog post (yeah, good luck).

Comment