広告の追加, デッドロックの原因はcall stackを取っても不明, 自動テストに1時間かかるので一部削除, object-fitにはwidth設定が必要
広告の追加
自分のサイトで一番下の広告が唯一有効だったことからシステムにも一番下に広告を配置してみました.
yesodアプリケーションのデッドロック問題の原因はcall stackを取っても相変わらず不明
デッドロック問題は今のrunDB内部でのrunDBを減らしたのを取り込むことにしました.
しかしやはり気になるため,
callStackを見るためにステージング環境でstack build --profileしてみましょう.
プロファイルを有効にしてビルドするとaesonのビルドが全く終わらないことがわかってきました.
topをして見てみようとしたら-bash: fork: Cannot allocate memoryとか出てきました.
こんな表示初めて見ました.
プロファイル付きビルドは物凄いメモリを食うみたいですね.
そう言えばプロファイル付きビルドをすると2回ビルドするんでした, そりゃ重いわけです.
いつまでもビルド終わらないし反応もないので, 仕方がないので一度EC2のインスタンスを終了して, 一時的にインスタンスタイプをアップグレードしてみることにしました.
AWSの課金が秒単位になったので, ビルドするためだけに一時的にt2.2xlargeを使うみたいなことが気軽にできてとても良いですね.
しかし他の作業とマルチタスクになってきて辛くなってきた. やはりデッドロック問題はスルーすべきだったのでしょうか.
callStackの出力には成功しましたが, 量が多すぎて意味不明になっています. stackの物量が多すぎて何もわからない.
call stackを取れれば,
何がrunDBを無駄に呼び出しているのかわかると思ったのですが,
あまりにもstackの量が多すぎますし文字列リストがそのまま帰ってきていて何もわからない.
emacsで整形してみても何もわからない.
defaultYesodMiddlewareがrunDBを呼び出しているらしきトレースになるのですが,
これはrunDBを呼び出さないはずでは…?
もう何もわからない,
調査するのを諦めようと思います.
自動テストに1時間かかるようになっていたのでテストコードを削減
ちょっとしたpull requestを作るたびにtravis CIの自動テストが走るのは良いんですが, テストコードが多くて非常に時間がかかるのが結構なストレスですね. travisがそんなに早くないのはローカルでやっても同じなので仕方ないので, テストコードの削減を提案したくなってきました.
遅い遅いと思っていたけれど実際どれぐらいの遅さなんだと, build historyを見てみたらテストに1時間かかるようになっていて, 流石にこれは自動テストによって生産性が逆に落ちると思うのでテストを削減します.
object-fitにはwidth設定が必要
object-fit - CSS | MDNの動作がfirefoxとchromeで異なる対策をします.
firefoxだとobject-fit: contain;を指定すると意図した感じにうまく収まってくれるのですが,
chromeだと横幅が盛大にはみ出してしまいます.
Can I useを見てもfirefoxとchromeの実装の違いなどは書かれていませんでした.
firefoxは横幅がはみ出さないようにうまく配慮して配置してくれるのですが, chromeは縦幅があっていれば横幅を全く考慮しません.
MDNの解説だとfirefoxに沿ったものしか載ってないだろうなと思ってcsswgの文書を読んでみようと思いましたが英語がきつい.
<img>要素にmax-width: 100%を追加したらchromeでもはみ出さなくなりました.
widthが指定されてなかったら好きに設定して良いという感じになっていたのでしょうか.
hatena-bookmark