JsDocにやさしいJSの書き方

最近、比較的真面目にJsDocを書くという機会があったので。

(※この記事の前提はJsDoc 3.2.2です)

JSで適当に名前空間的なものを切ってコードを書いていくと、

/**
 * @class
/*
function Klass() {
}

Klass.prototype.foo = function () {
};

my.name.space.Klass = Klass;

みたいな書き方がいいか、

/**
 * @class
/*
my.name.space.Klass = function() {
};

my.name.space.Klass.prototype.foo = function() {
};

みたいな書き方がいいか、という割とどうでも良い選択（意味的には同じなので）を迫られることがありますが、これは結論的には後者の方がよくて、

• 後者だとJsDocが勝手にKlassがmy.name.spaceに属することを判断してdocumentを作ってくれるが、前者の場合は@memberofとか使わないとその辺を理解してくれない
• 前者だと余計なシンボルがスコープに定義される (Klass)

という二点において、後者を選んだ方がよいです。

ちなみに僕は「メソッド宣言とかを短く書けるから」という理由で前者を選んでいましたが、JsDocを書く段になって後悔しました。

この辺の話は今後JsDocそのものが賢くなると改善されるかもしれませんし、browserifyなどのモダンなモジュールシステム（？）を使っている場合はあまりこういう話題は登場しないかもしれませんね。

JsDocのannotationを真面目に書くのって割と面倒なので、出来るだけannotationなしでJsDocに構造を理解してもらえるようにコード書いたほうが後々ラクですよ、というお話でした。

Googleは内部的には違うものを使っていると思いますが、JsDocの書き方自体はclosure libraryが参考になる気がしています。

google/closure-library · GitHub

色々なライブラリが群雄割拠している昨今のJS業界ですが、closure libraryにはGoogleの伝統と知恵が詰まってると思うんだ。多分。

chrome.identity.getAuthTokenで得たaccess tokenをrevokeする

function revokeToken() {
    var token = gapi.auth.getToken()["access_token"];
    chrome.identity.removeCachedAuthToken({ token: token }, function() {});

    var img = new Image();
    img.src = "https://accounts.google.com/o/oauth2/revoke?token=" + token;
}

やること

• chrome.identityは内部的にaccess tokenをcacheするのでそいつを消さないといけない
• revokeはRevoke Endpointに投げるだけ

メモ

• GoogleのOAuth2では、access tokenのrevokeが「認可の取り消し」を意味する。つまり、revokeした後にユーザは再度認可を行う必要がある。
• 初期起動時に行うGoogle認証・認可のフローをChrome extensionやChrome Apps内でテストしたい場合、上のようなfunctionを用意しておいてUIなりdev consoleなりから叩けるようにしておくと便利

初めて真面目にChrome extension作ったのでチラ裏メモ

まだ公開してないけどね。

• デスクトップ自体のアイドル（ユーザ操作がない）状態やロック状態はchrome.idleで取れる。ユーザ操作がないと判断するまでのtimeoutも自分で決められる。最短15sec。
• Chrome自体からフォーカスが離れたかどうかはchrome.windows使って判定すればオーケー (chrome.app.windowではない)
• 参考: Detect browser focus/out-of-focus via Google Chrome Extension - Stack Overflow (厳密に言うとonFocusChangedのコールバックに渡ってくるのはwindowではなくwindowIdなのでこのコードは間違っている)
• chrome.sendMessageとかmessagePort系とかの機能はchrome.storage.onChangedで代用できないこともないが、storageを使うのは永続化したいデータのみに留めておいた方が無難だろう
• chrome.browserAction.setPopupで右上ボタンにポップアップを設定するとchrome.browserAction.onClickedが効かなくなるが、そこはpopup内のjsからbackground pageに対してchrome.runtime.connectし、chrome.runtime.onConnectedをシグナルにして処理すれば問題ない
• もちろんchrome.runtime.onConnectedはclick eventの代替ではないが、どうせpopupとbackground pageの間でメッセージングするんでしょうと。
• popupのhtmlの中にanchorがあるとChromeが勝手にfocusしてうざい場合はanchor elementにtabindex="-1"を指定する。ってもうちょっとマシな方法ないんかい。(http://stackoverflow.com/questions/16701082/chrome-extension-first-link-is-auto-focused-in-popup)
• Chrome extensionの中でgapi (いわゆるGoogle系APIのJSライブラリ）をOAuth2の認可通した上で使いたい場合は chrome.identity.getAuthTokenしてのち得られたtokenを gapi.auth.setToken({ access_token: token }); すればよい
• 読み込み方はこんな感じで (http://stackoverflow.com/questions/18681803/loading-google-api-javascript-client-library-into-chrome-extension)
• chrome.i18nは普通に使える、それ以上でも以下でもない

総じて、extension開発は、クロスブラウザとか気にせずバリバリ色んな機能を使えるので気持ちがいい。情弱なのでdialog elementとか初めて使った。こういうのがちゃんと使えると、ダイロアグ的なものを出すためだけにUI系のライブラリを入れる必要がなくなるのでうれしい。

あとVue.js割と使いやすかった。小規模なコードだから足りない部分が気にならないだけなのかもだけど。

ChromeのInspect Devicesのページを開くのがダルい時は単にbookmarkしとけばいいって話

最近WebViewとかUIWebViewとかを組みこんだアプリの開発も便利になったもので、4.4以上のAndroidであればAndroid Chromeだけでなくアプリに組み込まれているWebViewすらWeb Inspectorでデバッグできる時代になりました。

Remote Debugging on Android with Chrome - Google Chrome

今更解説を書く気にもならないほどコモディティ化した技術ですが、このremote debug用の画面って開くのが面倒くさいんですよね。Chromeの右上のボタンクリック→その他のツール→デバイスを検証 っていう3ステップあるのが超絶めんどい！下手したらこの動きを一日に20回とか繰り返してる時あるわ！これはあきませんな、これでは消費税も上がりますわ奥さん！

ということで、何とかならないかなー、拡張機能で何とかしてみるか、とか思っていたのですが、よく考えたらChromeではこれ系の機能には普通にchrome://なURLが振られているので、

chrome://inspect/#devices

をbookmarkしておけばよかっただけでした。ちゃんちゃん。

すげーどうでもいい記事。

GoogleもしっかりCanvas Fingerprintingをつこてる風

ちょっと前に、次世代のユーザトラッキング法として有名になったCanvas Fingerprintingですが、かのGoogle社も一部のサービスで利用している様子です。

Google Playのアカウントについては、「一回アカウントをTerminateされたヤツについては、新しいDeveloperアカウント作ろうとしてもクレカ番号とかIPアドレスとかUAとか色々考慮した上で同一個人と判断できたらブロックするけんね」みたいなことを言っているGoogleなので、これもその一環なのでしょう。

ちなみに画像はTor Browserでアクセスした時のものですが、特にやましいことをしようとしていたわけではありません。おーこわ。おーこわ。（ガリガリガリクソン風）