OTCHY.NET

1ミリオンは何万？1ビリオンは何億？

英語で数字を表現する時、当然の事ながら「万」「億」「兆」という単位は使わず、「ミリオン」「ビリオン」などの単位を使いますが、日本語では 4 桁で数字を区切って表現するのに対し、英語では 3 桁で区切って表現します。
会計などで金額を扱う際、カンマを打つ時も 3 桁ごとです。
メモリや HDD の容量でおなじみの SI 単位系も、「キロ」「メガ」「ギガ」と、10³ 区切りです。

これが慣れない。どうしても直感的に変換できない。というかそもそも「直感的」な話ではないですね。
必要になる度に、毎回数字にばらして、桁を数えて…などとしてました。
ですが、いい加減面倒になったので、数値単位変換 っていうツールを作りました。

「1ミリオン→100万」も、「1兆→1トリリオン」も思いのままに変換できます。
同じ悩みのある諸氏は是非ご活用下さい！

技術的な話

とりあえず大きな数を扱うから BigInt だな、という話なんですが、BigInt 同士の演算とか特に不要でしたし、ツールのキモになるのはむしろ「1兆」＝「1,000,000,000,000」というパーサ部分だったので、既存の BigInt ライブラリは特に使わず、独自に実装する事にしました。
効率よりもわかりやすさ重視で、パースしやすいデータ構造を持たせた感じです。

で、肝心のパーサなんですがこれがなかなか大変でした。

「千」だけでも「1,000」ですが、「一千」と書いても「1,000」ですね。
「千百十万」も「1110万」も同じ「11,100,000」です。
さらに、英語の「eleven」はその 1 単語で 2 桁分の「11」を表したりします。

そんなこんなの難問を解決した結果、「1ミリオン」でも「100G」でも「10000000000000000」でも「999億9万9000」でも「壱億弐仟参佰泗拾伍萬陸仟漆佰捌拾玖」でも「fifteen millions and four thousands three hundreds twenty one」でも、正しくパースできるようになりました。

もはや当初の目的を超えて作り込んでしまった感じですが、面白かったので良しとしましょう。

むかーし作って、ずっと放置したままになっていた、Greasemonkey ユーザスクリプトの、GoogleFloatingForm を今の Google にあわせて修正したものを公開しました。
→GoogleFloatingForm

なぜ突然そんな事をする気になったかというと、GoogleFloatingForm改造と、検索結果CSS変更 [javascript][greasemonkey]：みにちゅあがーでん とか、-MB- Google仕様変更 とか、Google の仕様が変わっても、旧版の GoogleFloatingForm を改造しながら使い続けて下さっている方がいると分かったからです。
2ch のスレッドでも時々話題になっているようでした。

自分の作ったスクリプトが、こうして人の手に渡って修正されながらも使い続けられていくって、嬉しいもんですね。

今回、修正といっても今のブラウザの仕様にあわせてほとんどを書き換えた感じです。
今は、querySelector が使えるので、xpath とか使う必要が無くなりましたし、スタイルをちょっといじってフォームが浮いている事が分かりやすい感じにしました。

また、色々と改造して使ってくれる人がいる事も分かったので、スクリプト自体改造されやすさを意識して書いています。

そんなわけで、新生 GoogleFloatingForm をよろしくお願いします。

TwitMgr のバージョンアップを行いました。
OAuth 対応がメインではありますが、地味に日本語の表現を修正して、初見でもやれることが分かりやすくなっているかと思います。

BASIC 認証から、OAuth 認証へ変更するにあたっては、どうしても使い勝手が低下してしまうのは避けようがないところで、そこが残念ではあります。
どうせ OAuth 認証にするならいっそ、サーバサイドをしっかり作り込めばユーザビリティの低下を最小限に抑えられるはずなのですが、元々 JavaScript だけで作られていたものを移植するとなると、ほぼ作り直しになってしまうので、現状で出来る唯一の手段としてはこんなところです。

というのは前置きでして、JavaScript による OAuth 認証について突っ込んで考えたので、以下本論。

TwitterAPI2.js (というか実質は、TwitAPI.js) を使った OAuth 認証では、js ファイルを読み込むたびに、毎回必ず OAuth 認証の確認画面を表示する仕様としています。
プロキシサーバで OAuth 認証を行う構成なので、やろうと思えば、初回アクセス時のみ確認を取る、という事も可能なのですが、そのようにしていないのにはセキュリティ上の理由があります。

TwitAPI.js では、同ライブラリで公式のプロキシサーバを用意していて、公式プロキシサーバに対して許可した OAuth 認証については、その情報がプロキシサーバ側に残ります。
なので、毎回、認証画面を表示するようにしないと、あるアプリ A に対して許可したつもりの OAuth 認証が、他のアプリ B からも簡単に流用できてしまうのです。
毎回許可を得る形であれば、他のアプリ B から無言でいきなり OAuth 認証が悪用されることは避けられます。

クッキーに保存した情報を組み合わせて認証することで、あるアプリ A (ドメイン a) に対して許可した認証を別のアプリ B (ドメイン b) から利用させないようにする実装も検討しましたが、TwitAPI.js の立場から、任意のアプリ A が信用できない以上、アプリ A に XSS があれば同じ事になってしまうので、クッキーを使った実装も見送りました。

Twitter API を JavaScript から利用可能にするための実装は、TwitAPI.js 以外にも見かけますが、そういったセキュリティ上の対応はどうなっているんでしょうかね？調べたことはないですが興味はあります。

JavaScript の場合、そのソースが、設定情報も含めて全て公開されてしまうので、OAuth 認証において本来であれば秘匿すべき情報 (Consumer secret とか最たるもの) を隠すのは困難です。というか、原理的に不可能です。

TwitAPI.js では、プロキシサーバを経由することで、TwitAPI.js 専用のハッシュを発行して Consumer secret を秘匿していますが、専用ハッシュが漏れた場合に備え、前述の「毎回認証画面」でセキュリティを保っているという形です。(専用ハッシュが漏れなくても、TwitAPI.js では共通プロキシを使用している時点で必須です。)
JavaScript で簡単に OAuth を利用したいという要求と、セキュリティを担保するという要求は相反する点が多く、現状で考え得る落としどころはそこであろうという判断です。

JavaScript による OAuth 認証で、初回のみ認証画面が表示されるような実装のアプリがあった場合、原理的にその OAuth 認証は、他のアプリから悪用されうるのではないかと考えています。
この点、もっとスマートに解決するやり方があれば、是非、識者の意見を伺いたいです。

TwitAPI.js については、Ver 0.1.2 を公開したばかりでしたが、TwitterAPI2.js の Ver 2.0.1 に合わせてバージョンがあがりました。

ぶっちゃけていうと、TwitterAPI2.js にいろいろとバグがあって使い物にならないケースがあったので慌ててアップしたという形です。
バグ以外にも、既存の TwitterAPI.js でサポートしていながら、TwitAPI.js でサポートできていなかった機能も追加して、結果的に互換性が向上しています。

これでようやく、TwitMgr の OAuth 対応が完了しそうな感じです。
こちらも近日公開予定。

ずいぶん長い間放置してしまっていましたが、OAuth 認証対応版、Twitter API 用 JS ライブラリ、TwitAPI.js の Ver 0.1.2 を公開しました。

初回認証時に、サーバからのレスポンスが遅いと無反応になってしまう問題に対応するため、レスポンスが返るまでの間、waiting の表示を入れるようにしました。
ローディング画像風の動くテキスト表示なんかも入れたので、ユーザビリティは向上したんじゃないかと思います。

そろそろ Twitter API の BASIC 認証も期限切れなので、このバージョンと TwitterAPI2.js を使って TwitMgr と Splitwit の OAuth 対応もちゃちゃっと済ませたいところですね。