Steal this box
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.
Wordwhiz, a letter tile game
I’ve been learning Clojure and also wanted to learn a bit of the Apache Pivot UI. I am also a long-time fan of the Tivo Wordsmith game by Carl Haynes which I’ve discussed in older posts, so I decided to implement it as a first project.
A compiled snapshot is here. You’ll need Java 1.6 or later. if it doesn’t launch from a browser download it and try
java -jar wordwhiz.clj-0.0.1-SNAPSHOT-standalone.jar
I still have to look into making it run as an applet and I think the interface still needs a bit of work but it’s playable. The source is on github as “Wordwhiz” (git://github.com/rlonstein/wordwhiz.git).
Secret decoder ring
It’s always fun when marketing and branding turns an otherwise matter-of-fact email into a chance to apply my secret decoder ring. Here’s an example from a software vendor:
Thank you for your request for a product enhancement or modification. Enterprise Technologies for Enterprises is continually working to improve its software and services to best meet the needs of its customers. Your input is vital to that effort, and we appreciate your taking the time to provide it.
TRANSLATION: We can’t ignore you, but we’ll make it as difficult as possible to reach someone who knows anything about the product. Our automated system sent you a reply email so you’ll feel satisfied and go away.
Your enhancement request has been reviewed by our Product Management Team. We believe it is worthy of further consideration for potential inclusion in future roadmap planning for Enterprise Technologies for Enterprises Sapience Server (ETE Smart System Galactic Enlightenment Edition).
TRANSLATION: The software is perfect as it is, which is why you gave us money for it. We have added your suggestion to the pile. Sometimes the pile slips off the desk into the trash bin. If it doesn’t go into the trash, we might or might not think about maybe including it at some indefinite future time in one of our products, not necessarily the one you asked about. Or not.
We will forward it on to the broader user community for review. Please join the Pan-Galactic User Community to help prioritize future requirements by visiting www.example.com/porchlight/moth.
TRANSLATION: We appreciate your money and hope to direct you to our moderated forum where we can keep other customers from seeing your complaints. Please don’t vent your spleen on blogs and independent forums because that might get picked up by search engines and get in the way of other customers giving us their money. Don’t ask about your feature, it’s in the pile, we said we’d get back to you.
We look forward to continuing our successful partnership with you. Your success is very important to us.
TRANSLATION: Thanks for the cash. We appreciate it. It lets us buy smaller companies with good ideas and a customer base. Keep using our software because, just because.
Advice to software vendors
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 standardtar,gzip,bzip2orzip. 7zip and LZMA is fine. On Windows usezip,cab,msiandsfx. Go old school Unix and usecpioandcompressif 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/localas you expect. Assume that paths will always be the maximum of POSIX, XOPEN orsys/syslimits.hmaxpath, 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 bothSTDERRandSTDOUT. 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.
Open access to technical papers
Moshe Vardi wrote an editoral about open access in the CACM in 2009. And others have followed up why it can’t, won’t or shouldn’t happen. I myself am skeptical that the organization can let go of the Digital Library cash cow; if even a quarter of the roughly 80,000 ACM members pay the additional $99US per year for access or take the professional membership I figure it would generate about $1.9M per year. Yet Usenix, an organization a magnitude smaller, manages to make its proceedings and papers available. This open access is good for the field.
Professor and cryptographer Matt Blaze weighs in at his blog with Copywrongs.
RFC822 Ignorant Sites
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).
The Association for Computing MachineryWorking.- Emusic
- Nespresso
- Upper Hudson Library System (added 20110711)
Ross Lonstein
