More Procrastination

The Objective

A postal service ought to be able to leave a sheet or two of stamps in a mailbox, oughtn't it? Assuming the stamps are bought and paid for, of course. It turns out the United States Postal Service cannot, or will not, if the buyer is overseas, even if the delivery address is in the United States.

Consider the scenario of someone in another country who needs--or just wishes--to send a self-addressed stamped envelope to someone in the United States. How can they do this? They might be able to place an order, send payment to the U.S.P.S. and have the stamps sent to them. If for some reason the U.S.P.S. does not want to ship stamps abroad--but why would they not?--perhaps the stamps could be delivered directly to the intended beneficiary of the stamped envelope, and the envelope sent separately.

The Experiment

The U.S.P.S. does offer postage stamps for sale via an Internet ordering and payment system. The experimental protocol used entailed the following steps.

1. Create a personal U.S.P.S. customer account.
2. Place an order for a sheet of stamps. In this case, stamps of type "Global Forever" were selected as the most appropriate for mailing from the U.S. to anywhere in the world without concern for tariff changes.
3. Pay.
4. See whether the stamps arrive.

The Results

Customer Account Creation

The customer account creation was quite straightforward. In addition to name, one is required to provide an e-mail address, phone number, and physical postal address. Perhaps inappropriately, an address in the United States, that of the intended recipient, was entered. It was tested for authenticity, and a foreign address might (probably) have been rejected. Interestingly, the phone number entry field did allow the possibility of entering an "Int'l" number.
Actually, there was a curious glitch, but which was not insurmountable. The password for the account was to meet certain conditions: at least seven characters, a letter and a number, and allowed --but not required--to contain punctuation marks from a given list. A first password composed of five digits, two letters and an allowed punctuation mark was refused by the system with a message "Must contain one number" or words to that effect. A second password candidate containing only one digit (and one punctuation mark) among the many letters was accepted.

Placing the Order

Once the appropriate article had been identified and put in the shopping cart, order confirmation was attempted. The address as entered during customer account creation was rejected by the system for having an invalid telephone number. An alternate delivery address form was proposed by the system; the only country in the "Pick a Country" list is the "United States" so clearly it would not be possible to have the delivery abroad (other than to various armed forces and similar alternative 'states').

Interruption of Test

Since the order placement could not be completed for either delivery goal, the test was ended at that step.

Interpretation

• The United States Postal Service apparently will not send abroad stamps purchased through their Internet shop; they have made it impossible to enter a foreign delivery address.
• U.S.P.S. may deliver stamps purchased from abroad to the United States, but only if a United States domestic phone number is provided as part of the delivery address parameters.

There may be a rationale for this, but what? Why not ship abroad if the purchaser pays the shipping fees? Are the fees too complicated for the post office to calculate? Perhaps the range of other products available for purchase on their site includes some not easily shipped, but why not then just mark those as not available for overseas delivery? As for domestic deliveries, there was no indication that deliveries would be necessarily registered, which might justify needing to be able to contact the recipient; yet even if they were, one can just leave a delivery notice and expect the recipient to come claim their parcel.
It is not clear whether the problem lies with the order entry system or the lacking service offering. Would the post office mail the stamps to a foreign address if the order entry system allowed capturing a foreign address? Perhaps they would, and it is just the software that is faulty.

Conclusion and Prospects

This is disappointing. The solution appears to be to get a phone number from the intended recipient, if they are willing to divulge that information. But how to ask them and hope for a reply if one cannot send a stamped self-address envelope for their reply along with the request? (This is what is called a bootstrap problem.) It seems one cannot rely on postal methods alone for this use-case, one needs telephones. That's progress?
An alternative may be to purchase printable postage --to print directly on an envelope--rather than physical stamps; it remains to be seen what "delivery parameters" would be required or omitted in that case.

---

Tags: :

Labels: criticism, progress

A piece of writing brought to my attention recently (The Hidden Technology that Makes Twitter Huge) led me to wonder, how does one say "noyer le poisson" in American? "Noyer le poisson" is an expression in French commonly used figuratively; literally translated it is "to drown the fish" (or "drowning the fish"). The figurative use means "to avoid a taboo topic or difficult subject, concealing it under a mound of details." "Beat around the bush" is probably a good approximation, but "snow job" might be better.

The Snow Job

The piece in question is hardly unique in attempting to snow readers, but much of the detail used to snow the reader is actually wrong and misleading, while a real technological innovation of Twitter's is not mentioned at all.  The reader is provided a supposed "look under the hood" at Twitter, the better to marvel at its genius. The originality is possibly overstated, the execution performance is understated, and look under the hood leaves the reader less well informed!

The omitted technology may not matter too much to shareholders as, valuable as it may be, it cannot explain much of Twitter's market value. Twitter uses Scala effectively: "Scala is one of the main application programming languages used at Twitter. Much of our infrastructure is written in Scala and we have several large libraries supporting our use....Our use of Scala is mainly for creating high volume services that form distributed systems...".

The Genius and Genesis of Twitter

There are lots and lots of prior practices and ideas that may have contributed to the Twitter service, including e-mail listserv (for broadcasting messages to subscribers using mail protocol) and pagers (and bippers).  SMS/text messages sent from mobile phones may have a role as a model.  But the real inspiration was people's status messages on IM! From Twitter on Scala (April 2009):

Twitter started as a hack project at a company called ODEO, which was focused on podcasting. As ODEO was having some troubles in its latter days as a company, they started experimenting, to keep engineers involved by letting them play around with ideas they had on the side. One of the engineers, Jack Dorsey, had been really interested in status. He was looking at his AIM buddy list, and seeing that all of these guys were saying, “I’m walking the dog,” “I’m working on this,” “I’m going to that.” He wondered if there was some way to make it easier for people to share that status. So he and a couple other engineers started prototyping what became Twitter on Ruby on Rails, which was the stack that ODEO was built on. And Twitter continues today to be primarily a Rails application, with a bunch of Ruby daemons doing asynchronous processing on the backend.

So, using Twitter might be likened to connecting to a buddy list where nobody ever sent messages, just status updates, and the status updates were logged for later perusal. Or an alphapager system wherein anyone can broadcast short messages to everyone listening on their channel. Or simply, as one of the developers put it, a transport-independent micro-blogging system. But who will be willing to pay for that, and how much?

Message and Content Containers

The BusinessWeek piece notes that a Twitter message has lots of meta-data or header information associated. This is true, but equally true of e-mail. The piece itself, saved as html, is over 200k bytes of stuff, very little of which is the text.
It is also questionable how reliable some of the information provided by senders is, particularly when their anonymity is of the essence. On a message sent via a VPN rather than a geo-tracking device (like a smartphone) the sender's whereabouts are not known any better than those of a mail sender. Some of the fields are optional, as well, and potentially of little analytical value. Among the "special" fields in Twitter messages, a study made by an intern at PARC in 2011 found that Only 66% Use Twitter Profile Location Field as Intended:

34% of Twitter users do not provide a valid geographic location on their Twitter user profiles. Instead, some of these users co-opt the field to make jokes, express their love for a particular celebrity or to shout back at Twitter that their location is "NON YA BUSINESS!" Others, meanwhile, provide no location information at all.

n00b-speak

The factual errors concern the "snow" used to get the reader enthralled: API use and JSON. The use of technical terms was confusing, dazzling; it was not all wrong, really, but may have outstripped the author's understanding.
The first case is the explanation of JSON and its use. JSON is a set of syntax rules for representing labelled data, as is XML, and there are others. It happens that JSON uses a syntax very much like that used in ECMAScript, which (ECMAScript) served as its model. To call it "a simplified version of JavaScript" is not correct; leaving out all the control commands (loops and logic and such) is more than simplification, one does not have a programmable language left.

Similarly, and in the next sentence, "API essentially means “speaks (and reads) JSON.”" is not generally true. API essentially means "accepts requests from application programs and responds as best it can." It is an interface program, which may "speak" XML, html or something else instead of JSON. The flickr.com api, for instance, accepts requests using REST, XML-RPC or SOAP (but not JSON) and replies using REST, XML-RPC, SOAP, JSON, or PHP.

Another instance of confused reference to an API is in "For all the possibilities of APIs, there are also limits." A query result returned by a call to an API has flags set with warning messages, restricting publication; how is that in conflict with "all the possibilities of APIs"? It is not, "API" was worked in gratuitously.

Finally, and this may not bother all readers, stylistically writing of short text messages as if they were animals is inappropriate. "a tweet thrives," "once born, they're alone and must find their own way," is nonsense.

---

Note on the French figure of speech: Ref. (Figuré) Ne pas aborder un thème tabou ou un sujet difficile, le dissimuler sous un monceau de détails. from Wiktionary entry

---

Tags: :

Labels: criticism, debugging, ECMAScript, journalism, technology, translation, Twitter

I've engaged in search engine comparisons in the past, both using sites providing the support framework for the tests and running redundant queries on my own; in fact, when James Fallows wrote a Bing vs. Google note a couple of years ago, I wrote him to recommend Yahoo!, which I'd found very good at filtering out irrelevant results. That was before Yahoo! dropped support for their superior engine (for me, in English) to use Bing for their searches.

Yesterday, ReadWriteWeb described "Bing It On" as "A 'Pepsi Challenge' for Bing and Google," an official effort on Microsoft's part to test the same queries side-by-side with the two search engines. It is a test, presenting only the top (first page) results returned, and one 'plays' five times with the search terms of one's choice. I presume Bing has some way to mine the results to try to figure out why they lose when they do, but I frankly don't know how I would structure that analysis. (But now I'm thinking about it).


For Dave Copeland, the ReadWriteWeb writer, Google won 3-1-1. He includes information about some research findings which may explain the results. The research "found that Google outperforms Bing on simple one-word queries. Bing generally delivered more precise results for simple, multi-word queries and complex multi-word queries." His queries were simple multi-word, not simple one-word, so it does not seem to me that the explanation works.

Nor does this seem to explain the 4-1-0 Google scored with my query set!  None of my queries were one-word, even excluding articles, prepositions and conjunctions. Two were in French, one of which included a spelling ambiguity. My list was not "designed" or planned, it just happened that way, but probably is representative of the queries I submit.

My list:

• stem family joint family
• le module sp\xe9cifi\e9 est introuvable
• Is Zoroastrianism pagan?
• limage populaire
• cooperatives, private equity

The draw was on 'limage populaire', a curious name I spotted on a tombstone recently in a small village churchyard in Belgium. It also contains the spelling ambiguity, as "l'image populaire" is much more common, although "limage populaire" is a possible--not very comprehensible--construction.



The "Bing It On" site also provides a link to learn about the study in which they found "people chose Bing web search results over Google nearly 2:1 in blind comparison tests." The link is on the tally page you'll see after you try five queries, too.

---

Tags: :

Labels: Bing, criticism, Google, search engines

Labels: criticism, debugging, Kubuntu, progress, Thunderbird

Labels: criticism, ecology, kitchen timers, progress