t_wの輪郭

メモリが90%台のところに来ると落ちている。indexedDBか、localforageがメモリーリークしてる？
保存している量というよりは、読み書きの回数な気がする。要検証。一度ローカルへの保存を止めてみよう

→XMLHttpRequestがメモリリークしていた。XMLHttpRequestの処理をpanel.jsへ移動させて、推奨ページを表示する際に更新がかかるようにすれば、強制的にメモリーを解放させられるはず
　→ダメだった。メモリー消費は変わらず、サイドバーが重たくなっただけだった

→Fetchに置き換えたら治ったっぽい。メモリーの増減が安定している。
　→ダメだった。メモリーの消費は抑えられたが相変わらず落ちる

→気が付かない間にメモリーが消費されていた。動画などの大きいデータを取ってきてしまうと、メモリーに直撃してしまうので、クローラがHTMLだけを取りに行くようにする。
　Acceptにtext/html,application/xhtml xml,application/xml;を設定した。よくわかってないがこれでHTML,XHTML,XMLだけが取られてくるようになるはずだ。
Assertも追加した。取ってきたファイルサイズがAMAZONの欲しいものリストの100倍以上の時にエラーを出してくれる。これでどういったデータで問題が出ているかがわかるようになる。最悪停止するから調査ができる。アンドンだ。

→トイレでうんこしてる間にFirefoxが落ちた。文字通りの>クソ<アドオンである。ログをファイル出力しないと、調査もままならない。Firefoxにログのファイル出力機能が見つからない以上、Web Prowler自身にそういうスクリプトを組むしかない。
　→やめた。ファイル出力したとしても、エラーをハンドルしなければいけないので無理だった。

→pages_register_on_messageに排他制御を入れたらメモリー消費が劇的に減った。同時に実行するとだめらしい。

私の雑な理解

関数の引数と返り値をassert（表明）や型でチェックするプログラミングのスタイル。

assertでチェックするのは当たり前の前提のチェックにとどめると良いらしい。例えば、「ユークリッド距離は負数を返さない」など。

嬉しさ

関数を使うときに、呼び出しのネストが浅いところでassertでエラーになって、どういう間違いをしているか教えてもらえると楽。
さらにいうと、引数が型になっていて、エディターが間違いを教えてくれるともっと楽。実行しなくても間違いに気づけるので。

引数の値が等しいか検査するマクロ
与えられた２つの引数が等しければ通り、等しくなければ失敗する

引数の値が真であることを検査するマクロ
与えられた引数が真であれば通り、偽であれば失敗する

引数の値が等しくないことを検査するマクロ
引数が等しくなければ通り、等しければ失敗する

https://scrapbox.io/lacolaco/JavaScriptにおける表明(assertion)の話

第一引数がfalseだと第二引数をエラーとして出力するやつ。
よくあるassert文と異なり、エラーを出力しても処理は止まらないので注意が必要。
「開発環境では動いて本番環境では処理しない」みたいな機能は提供されていないので、契約プログラミングとして用いる場合はいい感じに頑張る必要がある。