ES6で書かれたUserscriptでchaiとmochaを使ったテストを走らせるための小技
github.comのcommit一覧ページで、2点のcommit hashからcompareページに簡単に遷移できる Userscript を3年ほど前に開発し、最近ES6を使ってほぼフルスクラッチで書き換えた。
その際に chai と mocha を使ったユニットテストを書けるように整備した。通常のjsファイルとは異なり、気をつけないと「Userscriptは動くがテストは動かない」、「Userscriptは動かないがテストは動く」といった事態に陥る。
このエントリでは、Userscriptをtestableにするために実装上気をつけた点を紹介する。
Userscript側
テストしたい関数を1つのclassに集約する
Userscriptは、ブラウザに組み込むことで何らかの補助的動作を可能にするツールである。この「補助的動作」の根幹に当たる部分を class に切り出し、それをテストケースの対象としておくと見通しが良くなる。
冒頭に上げた github-commitdiff-viewer では、
などといったロジックを CommitDiffUIManager というclassに集約させ、このclassをテスト対象とした。
Userscriptだけで動かしたい処理とテストだけで動かしたい処理を分岐させる
Userscriptとして動かしつつ、テストも実行可能なように記述するために下記のような実装を行った。
class TestTargetClass { // Userscriptの機能の根幹部分を実装 } if (typeof window === 'object') { let testTargetClass = new TestTargetClass(...); testTargetClass.executeSomething(); } else { module.exports = TestTargetClass; }
module.exports はテストだけで動かしたい部分で、ここをUserscript上で実行してしまうとエラーが発生してしまう。
テスト側で global.window オブジェクトをUserscriptのrequire後にmockすることで、「Userscriptをテスト側でrequireしたときにはwindowオブジェクトがない」という状況を作り出すことが出来る。
let TestTargetClass = require(path.join(__dirname, '..', 'someuserscript.user.js')); // この時点ではwindowは未定義 global.window = ...
この挙動の差を利用して、 if (typeof window === 'object') が true のときはUserscriptのみで動かしたい実装を記述し、 false のときはテストのみで動かしたい実装を記述することが出来る。
テスト側
jsdomを使ってUserscriptが読み込まれるページのdocumentをmockする
let jsdom = require('jsdom'); const dom = new JSDOM(` // Userscriptが読み込まれるページのdocumentのHTMLのうち、 // テストに必要な部分をべた書きする `); global.window = dom.window; global.$ = require('jquery');
前の項目で global.window をUserscriptのrequire後に記述するとUserscriptとテストで挙動を分けることが出来る点を紹介した。
global.window にjsdomを活用することで、Userscriptが読み込まれるページをモックでき、「DOMを探索して何かする」といった挙動の関数についてもテストが可能になる。
無料で使えるGCEのf1-microインスタンスで、Grafana+Prometheusのモニタリング環境を構築する
2018年、あけましておめでとうございます。拙い内容ではあるものの、本年も頑張って技術的な試みについて発信していけたらと。
年末年始でGrafanaとPrometheusを個人VPSのモニタリング環境として構築したので、その作業ログをまとめておく。
今回構築した雑な構成図
私は個人の開発環境としてさくらのVPSを所有しており、
をまとめて動かしている。
GCEにおいて、USリージョンのf1-microインスタンスが無料枠(Always Free Products)として利用可能であることを昨年末に知り、せっかくまとまった時間があるのでこの機会を活用してVPSのモニタリング環境を構築しようと考えた。
アプリケーションは、昨年業務で携わった新規プロダクトでお世話になっているGrafana + Prometheusを利用することにした。
なお、このエントリで紹介する環境ではVPS側にUbuntu14.04を、GCE側にUbuntu17.10をOSとして利用している。
続きを読むiPhoneをバッテリ交換に出したらiOSのバグに遭遇した
譲ってもらった中古のiPhone5sがバッテリの持ちが酷く、更にLightningケーブルを抜き差しすると極端にバッテリ残量の増減が変わってだいぶヘタっていたので今日バッテリ交換をお願いしてきた。このiPhoneはサブ機として運用している。
お願いした業者さんは あいさぽ というiPhone修理を専門に行っている所。バッテリ交換だけなら5000円ほどで済むのでかなり良心的なお値段設定。
夕方に修理を依頼し、その後ジムに寄って一汗かいたあと受取に戻り、動作確認をするとなぜか電源ボタンとボリュームボタンが効かないという始末。修理に出す前は正常に動いていたので何かがおかしい…
ちなみにiPhoneのスペックは下記。
試行錯誤していると、他の電源ボタンを使う操作として強制再起動はかかるという不思議な感じ。このことから、ハードウェアの問題ではなくソフトウェアの問題ではないかと考え始めた。
画面をよく見ると、電池交換をして再起動をしているので時計の設定時刻が初期化されていた。これが怪しいと思ったので、手元のSIMが入った別のiPhoneをテザリングさせてWi-Fiに接続した状態にし、時刻合わせを行ったところビンゴ。時刻合わせを行ってからは電源ボタンとボリュームボタンが効くようになったのだ。
iOSのバージョンが 11.0.2 と11系リリース直後のままで不安定なバージョンを使用していた自分にも原因の一端があるが、かなり焦った。。
このあたりの勘が効くのは、普段不具合の調査を行ったりしている職業病なのかもしれない…
初めてOSSにコミットした話
mariaex というElixirのMySQLライブラリにPull Requestを送って、無事に3日前にmergeされた。初めてのOSS貢献で感慨深かったので記事に書いておこうと思う。
きっかけ
今年の2月頃、業務中にとあるDBのテーブルを設計していて、業務ロジックから生まれる複雑なfieldをどう保存するか悩んでいた。関わっていたのはリリース前のとあるElixir製プロダクト。そのタイミングで保存すべきfieldを絞り込み、テーブルを設計してPull Requestを出した。schemaの中にカラム数は結構あった。
設計したテーブルをレビューしてもらったところ、「それ、まとめてJSONカラム使ったら良いんじゃない？」とベテランの同僚エンジニアから指摘を受けた。確かに、今後カジュアルにカラムを追加したり削除する上で都合が良いので、指摘に沿ってJSONカラムを利用することに。
そのプロダクトではMySQLのライブラリに mariaex を利用していたが、実装当初はJSONカラムがunsupportedだった。
関連するissueが立っており、repositoryのmaintainerが実装した commit が残っていた(Pull Requestは出ておらず)ため、これを元にmasterからブランチを切って差分を作ってみることに。
試行錯誤を重ねた上でPull Requestを出したが、mergeされるまですんなりとはいかなかった。
続きを読むさくらのVPS@Ubuntu14.04でmysqlが起動できなかった
ansibleを利用してmysqlをインストールしていたが、どうもmysqlの起動でコケてしまっていた。
直接ログインして sudo service mysql start を実行してもうんともすんともいわず、困っていた。
mysql.err を見てみると1つWARNINGが出ていたが特に関係のあるものではない。
% sudo tail -n 20 /var/log/mysql.err 171001 22:47:14 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 2017-10-01 22:47:14 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details). 2017-10-01 22:47:14 0 [Note] /usr/sbin/mysqld (mysqld 5.6.37-log) starting as process 24154 ... 171001 22:47:16 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
my.cnf に下記のオプションを追加したことでWARNINGは解消されたが、依然として起動ができなかった。
explicit_defaults_for_timestamp: 1
困ったなと思って syslog を見てみると気になる内容が。
% sudo tail -n 20 /var/log/syslog Oct 9 14:34:38 www4184uf kernel: [665121.153306] type=1400 audit(1507527278.123:68): apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/var/log/mysql.err" pid=25878 comm="mysqld" requested_mask="c" denied_mask="c" fsuid=105 ouid=105 Oct 9 14:34:38 www4184uf kernel: [665121.153318] type=1400 audit(1507527278.123:69): apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/var/log/mysql.err" pid=25878 comm="mysqld" requested_mask="c" denied_mask="c" fsuid=105 ouid=105 Oct 9 14:34:38 www4184uf kernel: [665121.153325] type=1400 audit(1507527278.123:70): apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/var/log/mysql.err" pid=25878 comm="mysqld" requested_mask="c" denied_mask="c" fsuid=105 ouid=105
apparmorというプロセスに起動を止められている…？WikiPediaによれば、このプロセスはセキュリティを向上させるプログラムとのこと。
AppArmor (Application Armor) とは、Linux Security Modulesの一種であり、各プログラムにセキュリティプロファイルを結びつけ、プログラムのできることに制限をかけるプログラムである。プロファイルは、ネットワークアクセス、Raw socket アクセス、ファイルへの読み書き実行などの機能を制限することができる。
ref. https://ja.wikipedia.org/wiki/AppArmor
とりあえずmysqldに関してapparmorの制限を止める。
sudo ln -s /etc/apparmor.d/usr.sbin.mysqld /etc/apparmor.d/disable/ sudo apparmor_parser -R /etc/apparmor.d/usr.sbin.mysqld
再度mysqlを立ち上げようとすると再び止まってしまっていたので mysql.err を見る。
% sudo tail -n 20 /var/log/mysql.err /usr/sbin/mysqld: Table 'mysql.plugin' doesn't exist 2017-10-09 15:21:34 15344 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it. 2017-10-09 15:21:34 15344 [Note] InnoDB: Using atomics to ref count buffer pool pages 2017-10-09 15:21:34 15344 [Note] InnoDB: The InnoDB memory heap is disabled 2017-10-09 15:21:34 15344 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2017-10-09 15:21:34 15344 [Note] InnoDB: Memory barrier is not used 2017-10-09 15:21:34 15344 [Note] InnoDB: Compressed tables use zlib 1.2.3 2017-10-09 15:21:34 15344 [Note] InnoDB: Using Linux native AIO 2017-10-09 15:21:34 15344 [Note] InnoDB: Using CPU crc32 instructions 2017-10-09 15:21:34 15344 [Note] InnoDB: Initializing buffer pool, size = 256.0M 2017-10-09 15:21:34 15344 [Note] InnoDB: Completed initialization of buffer pool 2017-10-09 15:21:34 15344 [Note] InnoDB: Highest supported file format is Barracuda. 2017-10-09 15:21:34 15344 [Note] InnoDB: 128 rollback segment(s) are active. 2017-10-09 15:21:34 15344 [Note] InnoDB: Waiting for purge to start 2017-10-09 15:21:34 15344 [Note] InnoDB: 5.6.37 started; log sequence number 1601046 2017-10-09 15:21:34 15344 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306 2017-10-09 15:21:34 15344 [Note] - '0.0.0.0' resolves to '0.0.0.0'; 2017-10-09 15:21:34 15344 [Note] Server socket created on IP: '0.0.0.0'. 2017-10-09 15:21:34 15344 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.user' doesn't exist 171009 15:21:34 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
/var/lib/mysql 配下の内容を見てみると、古いplaybookの適用時の残骸が残っていたようで、ファイルの作成日時がばらばらになっていた。
% ls -la /var/lib/mysql total 143380 drwxr-xr-x 4 mysql mysql 4096 10月 9 15:21 . drwxr-xr-x 50 root root 4096 10月 1 22:12 .. -rw-rw---- 1 mysql mysql 56 10月 1 21:37 auto.cnf -rw-rw---- 1 mysql mysql 67108864 10月 9 15:21 ib_logfile0 -rw-rw---- 1 mysql mysql 67108864 10月 1 22:47 ib_logfile1 -rw-rw---- 1 mysql mysql 12582912 10月 1 23:09 ibdata1 drwx------ 2 mysql mysql 4096 10月 1 21:30 mysql drwx------ 2 mysql mysql 4096 10月 1 21:30 test
一旦きれいな状態からインストール作業を試みるためディレクトリごと削除し、mysql-common, mysql-serverのpackageを削除し、再度ansibleを実行してみた。するとmysqlのplaybookは正常に最後まで適用できた。
色々とハマりどころがあったのでなかなか厄介だった。。
