自分用まとめ
リンク集
ドキュメント
安定の MDN. 本家のはずの Chrome 方面からはなかなか情報が拾えない感じがする。
- 拡張機能の中身 - Mozilla | MDN
- 全体像はこれがいちばん分かりやすかった。
- Native messaging - Mozilla | MDN
- ネイティブマニフェスト - Mozilla | MDN
- はじめての web-ext - Mozilla | MDN
- Chrome との非互換性 - Mozilla | MDN
- Develop Extensions - Google Chrome
- Native Messaging - Google Chrome
ライブラリ
web-ext は指定のディレクトリ以下にある拡張を自動で読み込んだブラウザを起動してくれ、かつ Hot Reloader してくれる。マジで便利。zip の作成も自動化できる。
URL にこだわらなくてよい時は asset bundler は Parcel が便利。
- parcel-bundler/parcel: Blazing fast, zero configuration web application bundler
- kevincharm/parcel-plugin-web-extension: Parcel plugin for WebExtension projects
- qinshixixing/parcel-plugin-clean-dist: This is a package a parcel plugin which delete the last bundled files before compile.
Firefox でも chrome オブジェクトを参照できるのでそっちに寄せる手もあるけど、一応 Polyfill も挙げておく。callback はイヤなので。ただし、一部メソッドのシグニチャチェックがバグってる気がする。
気づいたこと
- ツールバーの button を押したらとりあえず popup を開くのが基本
- ツールバーの button を押したら「ページ」を開くタイプの拡張は存在しない
- OptionPage を開くアクションをボタンクリックに割り当てる必要あり
- そのためにはロード時点で動作する background script が必要
NativeMessaging については続きをどうぞ。 → NativeMessagingの処理とNativeMessagingHostを作るときのTips
超今さらExpress触ってみた - その3 Cloud Functions Emulatorでも動くようにする - の続き。
Request Handlerを直接テストする
今回の目的は express アプリの end-to-end テストじゃないので、Request Handler である以下のコードだけをテストする。
module.exports.hello = (req, res) => {
res.send('Hello Express')
}
さて道具立てはいつもの mocha, power-assert に加えて
howardabrams/node-mocks-http: Mock 'http' objects for testing Express routing functions
を使うことにする。
今回面倒くさいのは、単なる function のテストなのに function は何も return してくれなくて、引数に与えた res が変化するのでそれを見ろ、というところ。基本的に callback 地獄を避けてきたので、この辺のテストの知見がない。素直に function は return してくれとは思うが、そうもいかないので上のライブラリを利用する。
こんな感じ。
test/index.spec.js
const httpMocks = require('node-mocks-http')
const assert = require('power-assert')
const {hello: IndexHandler} = require('../index')
describe('IndexHandler', () => {
it('can handle request', () => {
const req = httpMocks.createRequest({url: '/'})
const res = httpMocks.createResponse()
IndexHandler(req, res)
assert.equal(200, res._getStatusCode())
})
})
httpMocks.createResponse() で得られるオブジェクトは Express の response とは構造はだいぶ違うけれども、status や body など、欲しい情報を取得してテストを書くには十分機能してくれる感じがする。
似た機能を持つライブラリは実はたくさんあるんだけど、あまりダウンロード数がなくて作った本人とごく一部の人しか使っていないのでは？と思われたり、 Sinon に寄せすぎて素直にデータを取り出すことができなかったりするので、これくらいのものでよしとすることにした。
ということで、ここまででやっかいな Request Handler に対してテストを書けるようになった。あとは Google Cloud API を使わない部分に関しては普通の class や function と同じようにやればよいはず。
つまり、テスト書けるようになった！
Googleのユニットテストのドキュメントと比較
テストと CI/CD | Cloud Functions のドキュメント | Google Cloud
これを読むと Google さんは全部 Sinon の Mock で処理しろと書いてるんだけど、Mock って使いすぎると結局中の動作を別な形で書き換えただけになりかねなくて重い1ので、できれば request と response の対応を、インターフェイスをテストする形にしておきたいので、上のような方法を選んだ。（こうしておけば中の処理が変わっても大丈夫。）
参考
Unit testing Express route handlers | Shesh's blog
動作として重いということでなく、だいぶホワイトボックステスト寄りになって変更に弱くなってしまうので、存在として、資産というか負債というか、とにかく重い ↩
ちょっと試してみた時点での感想。ちなみに個人的にはこれまでも、これからも当分ただの feed aggregator として使う予定。
基本的なところ
- friendfeed は様々な feed を取り込むことができるが、対応していないサービスも当然あるので、その場合は Cutsom RSS/Atom ってやつが使える。
- コメントのついたものは上に上がってくる。スレッドフローティング式の掲示板みたい。
- friendfeed も twitter と同じであんまり古い情報はたどれない
例えば friendfeed にはソーシャルブックマークのように使える bookmarklet が用意されているが、あくまである程度の期間しか遡れないので、本格的に使いたければ他のソーシャルブックマークサービスを利用して、その feed を friendfeed 上に引っ張ってくる方がよい。しかもこの bookmarklet は 3rd party cookie を許可していないと使えない。確かに大半のブラウザのデフォルトで許可されているんだけど、拒否していると bookmarklet の動作がなぜ失敗するのかが分からないので注意。
groupについて
- friendfeed の group はユーザーと同じ名前空間を奪い合う。言うなれば仮想のユーザーみたいなもの。
- group 上にも個人のアカウントと同じように様々な feed を import 可能
- group へ参加している者同士は相互に follow している必要がない。group 上の情報は共有できる。逆に follow しあっていなければ個人の feed を個人のメモ書きとして利用可能。
- group は認証制にできる。group の参加者の feed にも認証を掛ければ一応メンバー限定の twitter のような使い方ができる。
- あまり古い情報を掘り起こすことはできないのでストック目的には使えない。つまり Google Group などの代わりにはならない。お手軽感重視。例えば認証を掛けられる Wiki が欲しければ別途探す必要がある。
[2010-02-17 追記] Google Buzz 始まったので、共同「作業」重視なら全部 Google でもよいのかも。あくまで friendfeed は 情報共有程度で使うのがよさげ。
ファイル添付
一時期ファイル添付が騒がれたけれど、試した時点ではそれほど多くの種類には対応していない。基本的には
- Web 向けの画像
- テキスト
くらいしか対応していない模様。mp3 は貼れるみたいだけど試してない。基本的にはソーシャルにやってよ、という感じの方が強いのかな。公開している場合は YouTube や Flickr などと連携させればよいだけで、特に難しい話ではない。group 内で完結させようと考えているとここはちょっとネック。
Twitter でもらったコメント。
2009.09.12:12:30:12 <shinji_kono> @wtnabe OOoもzipも、採用しにくいと思
う。理由はいろいろあるけど。僕的には Friendfeed が、Word サポートした
ら、アカウント削除しよう。
なるほど、確かにそれはそうかも。
※ 手元の zsh を 4.1.1 から 4.2.5 にしたら突然便利になった。今まで ssh の hostname も補完してくれないし、なんか不便だなーくらいに思いながら使っていたのだけれど、これはなんかすごいかもしんない。そして 4.3.2 の環境の zsh は compinit してなかったよ！ バカですか、おれ。補完が強力になるとなんかこう、羽が生えたかのように軽やかな気持ちになりますな。
えー。
先日の svndumpfilter の続き。要するにリポジトリの中から要らないリビジョンを消しちゃえばいいんだろと思ったんだけど、無関係な node だけを削除するのではダメことが分かった。
それは cvs2svn がブランチを切る際に、丸ごと trunk を branches 以下にガバっと copy したあとに不要な node を削除しまくるという作業を一つの revision でやっているため、Node-path だけ見てても必要かどうかを判断できない。Node-path だけ見て拾ったものがいきなり delete アクションに割り当てられててなんじゃこれと思ったら直前に copy されているというわけ。ということはこの copy のアクションが残ってないと dump ファイルを load したときにエラーが出ちゃう。
本当に無関係なら copy も含めて revision まるごと削除すればいいんだけど、その本当に無関係かどうかを機械的に判断するのは結構難しい。例えば必要なパスの中のさらに一部のファイルにだけブランチタグを打っていた場合、cvs2svn では丸ごと copy したあと、その必要なファイル以外を次々 delete していくという履歴を起こしてくれるんだけど、この履歴を見ただけじゃ残るファイルがなんなのか分からない。それこそ svn と同じことをして前から順番にたどってこないとこの時点でそのファイルが必要かどうか分からないのだ。うーん。なんだこれ。履歴を辿りながらすべての Node-path を記録していって、この時点の丸ごと copy ではこれだけのファイルが対象になるってことを確認しないといけない。
って、それまんま svn の仕事やんけ。
Subversion に移行したとき、要るファイルだけを別 branch に copy するのがものすごくやりにくいと思った記憶はあるんだけど、まさかそれがこんな形で効いてくるとは。丸ごとコピーして削除ってそりゃないよ！
copy のアクションがあったらその revision はとりあえず残す方針にして、そのあとの delete アクションで確実に自分の意図したパスが除外されていると分かる場合だけその revision を削除できる…。もっと簡単なパターンマッチで処理できるかと思っていた。甘かった。
※ 最終的には手作業での dump ファイル修正を含めて目的の形にリポジトリを分割することができました。
cf.
そんなに差がつくかぁ？と思っていたけど、やっぱ選挙区制度の改悪が原因だったのか。小選挙区・比例代表並立制になるとき、かなりすったもんだしたけど、結果が出たってことですな。自民党がやりたかったのはこれだと。これが「民意を反映した」ことになるんだから、めちゃくちゃでごじゃりますがな。
票を殺し、民意を殺し、政治を殺してるのは誰だ。
やっと Google がここを拾ってくれたようだ。
inurl:cgi.f50.aaacafe.ne.jp/~wtnabe/ KEYWORD
の形でこのサイト内を検索できる。
が。拾われやすいように用意した静的 HTML の方は拾ってくれてない模様。やっぱリンクテキストが日付だけっつーのはよくないか。ほんとは HTML の中身をなめて title を拾ったり heading を拾ったりしてリンクを生成するといいんだろうなぁ。
まーそれは気が向いたらやってみることにして、Google はあまり使えないのでまだしばらくは tdiarygrep で我慢という話でした。
文庫で650円てなめとんのか？とか思うのはもう時代遅れですか。
Strict & CSS 厨からすっかり XUL ハッカーへと飛躍した piro 氏作。
通常の状態でも選択しただけで色が変わるが、その色を固定するための Extension. リロードしない限り選択を解いても色が変わらないので、Web を参照しながら何かの作業をするときに重宝しそう。
自分は翻訳のときに便利だなと思っている。