What your smartphone's default email signature says about what manufacturers think of you

I would like to think that this is a fake, a joke, someone having a lark. But in the end I know it probably isn't. It got me thinking, though, about these things. I turned off the "Sent from my iPhone" signature on my phone because I have no interest in attaching tiny ads to my emails, but if you compare the two they send rather different messages; let's explore.

Sent from my iPhone
This is technically an ad, yes, but it also sounds somewhat personal. I sent this email to you from my iPhone; implied is a mea culpa for any typos in the message. Perhaps I was walking down the hall, at lunch, whatever I do when I reply to email away from my desk. Taken this way you could almost believe (though not quite) that I actually chose this as an email signature just to convey that message. At the very least, marketing or not, it's short.

Sent via the Samsung Galaxy S™ II Skyrocket™, an AT&T 4G LTE smartphone.
There is nothing technical about this; my default email signature is a blatant advertisement for both my phone and carrier, one of which likely exchanged large sums of money to be included in my every message in the hopes that my not caring or knowing how to change it will hopefully influence you into believing that one and/or the other of these companies offers a product/service worth a damn. I am unlikely to tell you face to face that I ever send anything via anything else. Neither am I likely to remember all 5 segments of my smartphone's full name if ever quizzed about it. Please, the next time we meet in person, tell me what the Menu button in Android does so I might be able to change this. I am more than happy to stand there and let a sales person tell me that Android 2.3.5 is "state-of-the-art" and neither crack a smile nor roll my eyes. I promise you I don't know how to type ™ on this keyboard. I wish I didn't sign a two-year contract for this. Finally, if there are typos I'm sorry, I sent this from my phone because I decided it couldn't wait until I got back to my desk.

I'll briefly drop the same advice here that I give to anyone that asks me in person:
So you want a smartphone? If you ever plan to ask me a question about it, you should get an iPhone. If you're going to ignore that sage wisdom, then the only Android phone worth owning at any time is whichever one has "Nexus" in the name this year. No, I don't know if you can get one at the Verizon/AT&T Store.

Does this mean I think you, gentle reader, have made a terrible error in buying whatever non-Nexus Android phone you might have? Not if you're a tech geek and knew full well ahead of time what you were getting into and decided "I really want this phone even though it will never be improved beyond its current state," or you plan to put CyanogenMod on it yourself. Have a good time with all of that (but don't ask me what's happening when it goes walkabout on you).

Evergreen Receipts Followup

This post is followup to a series.

At some point some of the modifications I wanted to preform on receipts were added as built-in text macros. The benefit of this is that if for some unfortunate reason you have to use text only receipts you can still modify them as you see fit - JavaScript customization only works in the "Mozilla" (browser) print mode. Thomas Berezansky was kind enough to mention them to me (over a month ago now, because I am terrible at following up on personal projects) and you can read how the built in date formatting, whitespace trimming, and substrings work at http://bstcon.com/receipts.txt . The last line - "Doesn't even cover the default set of features that exist without a custom JS file defined in Mozilla print mode. ;)" - is more than a reminder that there is a lot of flexibility available "for free" in the receipt editor; it's also a reminder that nothing is documented except for the placeholders. Currently you can learn what's available by looking through the source code for that part of the Evergreen client or you can do your own thing, possibly duplicating existing functionality (though perhaps with nicer syntax).

He also pointed out an available placeholder that I didn't notice: %shelf_expire_time%. This uses a library setting that you can configure in the client to determine your available hold expiration dates automatically. This is better than adding the date manually, and was either added sometime after I originally changed our receipts in 2008 or I just didn't know about it since I hadn't looked through most of the library settings at the time. Perhaps someone will find another use for mod-DateAdd, but it's not necessary for hold expiration dates.