One-Button Unread Mail for GMail Redux

It's been 16 months since the last version, and I've since gotten a chance to get a bit wiser (certainly older) with Javascript. So I decided to get around to updating my Greasemonkey script for a one-click "Show/Search Unread" button for GMail.

I believe/hope this version is much more fault-tolerant against GMail's frequent JS recompilations. It's also now rather language independent.

I've only used/tested it on the setup in front of me, so please let me know if it works on yours.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3) Gecko/20090910 Ubuntu/9.04 (jaunty) Shiretoko/3.5.3

Yahoo OAUTH Not Supporting Authorization Header

Hopefully this will help another person running into this issue.

Like a lot of people, I was getting "Signature Invalid" when trying to initiate an OAUTH transaction with Yahoo, e.g., at https://api.login.yahoo.com/oauth/v2/get_request_token. For a while I thought the problem might be with the URL encoding of parameters, as mentioned in many of the discussion. However it turned out that Yahoo's OAUTH does not support the Authorization header, as mentioned here by "David". This is a serious limitation given that this method is the most preferred of the three specified in http://oauth.net/core/1.0a/ .

The solution for this is simple: avoid using the HTTP Authorization header, and pass the OAUTH parameters by URI instead.

---

I'm using the OAUTH PECL library. For this, just change:

$oauth = new OAuth($this->CONSUMER_KEY, $this->CONSUMER_SECRET);

to:

$oauth = new OAuth($this->CONSUMER_KEY, $this->CONSUMER_SECRET, OAUTH_SIG_METHOD_HMACSHA1, OAUTH_AUTH_TYPE_URI);

Mystery solved.

---

Update: Other ficklings with Yahoo OAUTH support:

1. When creating a new app, make sure your "Application URL" ends with a file, or a "/". For example, this won't work: "http://www.example.com".
   
2. If after creating an app, you make any change at all, like adding a short description or an icon, your users will see "Warning: This website has not been verified by Yahoo!. For your security, we recommend that you continue only if you trust this website" when they authenticate with your app.

Mark Twain & Benjamin Disraeli

First, go to http://google.com, type in "Mark Twain & Benjamin Disraeli", click "I'm Feeling Lucky". Do that now. Then come back here.

AdAge has an article out claiming that "the number of people who view their friends and peers as credible sources of information about a company dropped by almost half, from 45% to 25%," between 2008 and 2010. It goes on to surmise that social media is to blame, "social networks themselves may be contributing to the decline in trust." This is all based on quoting an Edelman (a PR firm) 2010 study.

This is all too facile an explanation, I thought. Sure, the definition of "friends" has loosened considerably thanks to the rise of Facebook. But the chart showing huge (20+ point declines) and across-the-board (TV News, Radio, Newspaper, as well as Friends) declines in trust just screamed "systematic change" to me. So I decided to dig by going to the source and compiled my own graphs from Edelman's data.

And here are the errors from source to article:

1. Edelman distinguishes between "Friends/Peers" and "Social Networking Sites", with different numbers for each category. In fact, the numbers for SNS haven't changed at all from 2008 (20% +/- 5%) to 2010 (19% +/- 5%). In further fact, SNS is the only category not showing a decline from 2008 to 2010. For the article to make a direct link from the "Friends/Peers" numbers to Social Media is erroneous.
   
   
2. It turns out Edelman's numbers on "Friends/Peers" show no 2008-2010 change of that magnitude (-20 points). They do show a 12-point decline for "Friends/Peers", but also 11-13 point declines in Newspaper, TV News, Radio News, and Business Magazines. I don't know where the 2010 numbers for AdAge's chart comes from, but speculatively the systematic offsets could be that they looked at, e.g., numbers from the subset Edelman calls "skeptic countries" (UK/France/Germany), or the subset responding "Extremely Credible" (as opposed to "Extremely Credible" or "Very Credible").

Also, consider the responses to Edelman's trust question for Financial Investments. For that, "Friends or Family" score 61%, second only to "Broker/Advisor", at 68%.

Finally, it is true there seems to be a systematic, exogenous change in trust levels across the board from 2008 to 2010. I consider these to be more likely explanations of this change:

1. The 2008 study was completed in Jan 2008, before most people learned the name Madoff and felt personal pain from the economic contraction. It's not unreasonable to link these events to an across-the-board decline in trust. Or,
   
   
2. A systematic offset due to sample error or methodology changes in the studies.

All the same, it's all too facile to blame social-networking for this decline. Edelman's numbers don't show that. At all. And hats off to my new Facebook friend, Shiv Singh, for surfacing this in my activity stream :)

How to deal with goog.inherits() giving "goog.ui is undefined"

Google released the Javascript Closure Tools last week, to my delight. It's the tools behind most of Google's Apps, notably GMail.

I love playing with these great tools that I didn't have time to deal with before.

Being a novice with these tools, I ran into some problems pretty quickly. I'm posting our team's solution to one here, hoping either (a) someone will explain the root of this, and/or (b) others will benefit from the same instant workaround.

Closure provides a convenient Javascript class inheritance method called goog.inherits(), like so:

goog.inherits('ACTG.Ui.ScriptListing', 'goog.ui.tree.TreeControl');

In our HTML file, we have the expected scripts loaded:

<script type="text/javascript" src="path_to_closure/base.js"/>
<script type="text/javascript" src="path_to_our_js_which_has_the_goog.inherits/our.js"/>

This results in "goog.ui is undefined", with Firefox Shiretoko in particular. As some of my former colleagues would say, "How can?"

Turns out this is fixed with:

<script type="text/javascript" src="path_to_closure/base.js"/>
<script type="text/javascript">
goog.require('goog.ui.tree.TreeControl');
</script>
<script type="text/javascript" src="path_to_our_js_which_has_the_goog.inherits/our.js"/>

I think I understand why, but I'm not sure. Still, the workaround works, and there isn't time to explain every mystery in the universe.

And for actual deployment, if you use calcdeps.py to package and minify everything into a single js file, this workaround would be unnecessary.

Google AppEngine Quota Throttling ... Annoyance

Disclaimer: I still have a special place in my heart for the big G. Having said that...

Folks at Bluepulse are ardent fans of Google Apps and Google AppEngine. On the latter, the team recently ran into the quota/throttling issue (described at length by Aral Balkan and others). Aral makes a number of points, not all of which I agree with (e.g., that Quotas are a Bad Idea [in general?]).

But the most valid point is against the rather crazy idea of "intelligent" throttling, where, simply put, your app is cut off at peak demand (in an effort to spread your quota over the entire day).

As others have pointed out, this isn't very intelligent. There is significant benefit loss in not being able to serve your audience when they're most interested. On the cost side, it's not even necessary. Indeed it is arguably desirable to allow apps to consume resources at their own peaks. With the varied and global nature of app distribution, the demand on AppEngine's computing resources will just smooth things out. With a sufficiently global timezone distribution, peak-to-trough demand ratio will be 2:1 at most.

Practically speaking, though, the gap isn't so big. It comes down to the numerical difference between the daily limit and the maximum-rate limit. Right now it's about 8:1 for the free apps, and about 35:1 for the billable apps. Individual apps, especially in their early days, can easily surpass the 8:1 peak-to-trough ratio implicit in these limits.

So, outside of the "it's-free-so-what-do-you-expect" zone, I think the AppEngine team should lift the max limit for the free apps to something closer to 20:1. Let them run out of the daily limit at their own peril.

I suspect there would be a lot of happier developers in the AppEngine community. End users will run into throttling limits much less often. And happier free app owners are probably more likely to convert to happy billable app owners.

Make peace.

Photos (Travel:Asia)

The whole album is here.

A Favorite Background Image

From Desktop Backgrounds