2010年6月17日木曜日

オフィスのトイレではどの便器を使うべきか

くだらない話なので、生暖かい気持ちで流してください。トイレだけに。

今の職場の男子トイレは小が4つ並んでいます。
トイレの入り口に近い方をA、一番奥をDとしましょう。

入り口 A  B  C  D


もっとも使用頻度が高いのは入り口に一番近いAです。これはまあ男性諸氏は感覚的にわかると思います。


以下、それぞれのケースであなたが小用でトイレに入ってきた場合、あなたはA~Dのどこを使うのが正しいでしょうか。

※以下の図では、♂は先客、☆はあなた(正解ポジション)です

◆case 1:
入り口 A  B  C  D
    ♂


Ans:
入り口 A  B  C  D
    ♂     ☆


切羽詰っている、先客が仲のよい知り合いだ、人のに興味がある、といった場合以外は、適切な間隔を保ちましょう。Cではダメな理由は、賢明なあなたならもうおわかりですね。3人目が入ってきた場合に、Bだと3人並んでしまい、Dだと先客のAが先に終わった場合に、奥から2人並んでてちょっちイヤンだからです。

では次のケースです。

◆case 2:
入り口 A  B  C  D
    ♂     ♂


Ans:
入り口 A  B  C  D
    ♂ ☆   ♂


B、Cどちらを選らんでも隣合ってしまいます。が、Bが正解です。なぜか。冒頭に書きましたように、一番手前のAを使う人が多い→誰もいない状態でトイレに入ってくるのはA、そう、一番先に入室してきた人はAである可能性がもっとも高いからです。Aが用を足し終われば、Bを陣取ったあなたに落ち着いたひと時が訪れる可能性が高いのです。

さて次のケース。少し複雑なメンタリティが絡んできますよ。

◆case 3:
入り口 A  B  C  D
      ♂   ♂


Ans:
入り口 A  B  C  D
    ☆ ♂   ♂


AとCどちらに並んでも他の人と隣合ってしまいますが、Cを使う場合、BとDどちらが先に終わっても、結局残った方と隣り合ってしまいます。Aを選んだ場合、もしBが先に終われば、あなたには落ち着いたひと時が訪れますし、なにより「一番入り口に近かったからという理由でAを選んだのであって、Bの隣に来たかったからじゃないんだ」という安心感を、Bに与えることもできます。

次も類似ケースです。

◆case 4:
入り口 A  B  C  D
    ♂   ♂


Ans:
入り口 A  B  C  D
    ♂   ♂ ☆


case3とほぼ同じ理論です。ここのトイレにおいて入り口側はもっとも頻度高く使われますが、実は(これは数が6つくらいまでのトイレにたいがい当てはまりますが)"一番奥"というのも、なにかにつけて好まれるポジションですので「Cの隣に来たのではなく俺は"一番奥"というステータスを得に来たんだ」ということで、Cに安心感を与えられると同時に、自分がそこを選んだ申し分ない理由にもできます。ここでの大切なことは「"一番奥"というステータス」です。

最後は珍しいパターンです。

case 5:
入り口 A  B  C  D
      ♂ ♂

Ans:
入り口 A  B  C  D
    ☆ ♂ ♂


ここまできたらもうおわかりですね。このケースではAが正解です。

あとは3人先客がいたら残りを選ぶしかなく、またA、Bに先客、あるいはC、Dに先客といった場合は、ひとつ開けたところが正解になるのは明白です。


これでこのタイプのトイレはもう完璧ですね。
Have a good toilet life!!.

2010年6月11日金曜日

JavaScriptのencodeURIComponentでハマる

珍しくWeb開発系の話。

奇特な動作方式(詳しくは過去エントリ参照)のTwitter
bot「カーチャンbot」のOAuth対応を行っていたとき、何を思ったか、OAuthをライブラリ等使わずに作ってみようと思いまして、あ、HMAC-SHA1とかbase64とかの部分以外は、ですが、んでいろいろやった過程で、ハマったことを書きたいと思います。
…って思ったけれど時間が経って何に悩んだのか忘れてしまったので、一番最近ハマったことを1つ。


JavaScriptの encodeURIComponentでは「-_.!~*'();/?:@&=+$,%#」といった文字のうち、

-_.!~*'()

がencodeされない、ということ。

これらのうち「!*'()」がOAuthを使ったAPIアクセスで問題に。まあTimeline取得やfavをやるにはこんな文字列使わないから問題ないんだけれど、statusの更新、いわゆるつぶやきの投稿時に、Tweet内容にこれらの文字列があった場合に、Signature違いますって言われてしまいます。

ので、Signature生成前に、この変換されないやつらのうち問題になる5文字はさらに個別にencodeしてあげないとダメでした。
-_.~はそのまんまでいいです。

例えばこんな感じのencodeURI拡張版作っておくとよいです。


function encodeURIextend(str){
str = encodeURIComponent(str);
str = str.replace(/\!/g, "%21");
str = str.replace(/\*/g, "%2A");
str = str.replace(/\'/g, "%27");
str = str.replace(/\(/g, "%28");
str = str.replace(/\)/g, "%29");
return str;
}


formのinput or textareaには生文字列でよくて、あくまでpost時のSignature計算に使うメッセージ、POST&https%3A%2F%2Fapi.twitter.com%2F(略)status=ここの値として設定するときに、拡張encodeURIしておく必要があるということです。

まあJavaScriptのOAuthライブラリ使えば、そんなことでハマらずに済みます。Sample*今見たら、まんまこの5文字対策がしてありました。

*下記Twitter developersのOAuth Librariesで紹介されてるもの:
http://dev.twitter.com/pages/oauth_libraries#javascript

稀に、こういう無駄な経験が将来役に立つこともあるんですが、まあ今回のはないかなw