最近観た映画

フューリー

フューリー [SPE BEST] [Blu-ray]

砲弾の軌跡がひたすらかっこよかった。あと発射と着弾の音。

第二次大戦の頃とくらべて現代の兵器は砲弾の速度は速くなっているものなのかなぁ、限界がありそうだけど、などと思ったが、 Hulu にあった「ガニー軍曹のミリタリー大百科」によると、やっぱりだいぶ改善されてきているようだった。

「ガニー軍曹のミリタリー大百科」は、「フルメタル・ジャケット」のハートマン軍曹役で有名な R・リー・アーメイ氏がひたすら楽しそうに古今東西の名兵器を紹介する番組で、口の悪さとかやってることのバカバカしさが良かった。戦車の主砲でガソリンの入ったドラム缶を撃って爆発炎上したら「ハッハー！これだ、これがやりたかったんだ！！」と高笑いしたり、機関銃で自動車を蜂の巣にして「あの車に乗っていなくて良かっただろう！」とドヤ顔で言い放ったりする。

ネイビーシールズ：チーム6

ネイビーシールズ：チーム6 (字幕版)

全然印象に残らなかった。もうどんな話だったかも忘れた。

グリーン・ゾーン

グリーン・ゾーン 【ブルーレイ&DVDセット・2枚組】 [Blu-ray]

なんか無茶苦茶な話だなぁ、という感じ。義足の現地人が振り回されて哀れだったけどオチもやっぱりなという感じだった。

ローン・サバイバー

ローン・サバイバー Blu-ray

これもあんまり印象に残らなかった。

13時間 ベンガジの秘密の兵士

13時間ベンガジの秘密の兵士 (字幕版)

これはまぁまぁ見ごたえがあった。迫撃砲ってこういうシチュエーションで威力を発揮するのだな、ということがよくわかった。

マネーモンスター

マネーモンスター (字幕版)

まぁまぁだった。すごく面白いわけではないけど、暇つぶしするには飽きないくらい。遺産を全部株（しかも単一銘柄）に突っ込むとか無謀すぎるだろと思った。

最近思ったこと

日本経済新聞

特定疾患の自己負担額がまた上がり、月ごとに一回の診察・治療につき二万円になった。レミケードを八週感覚でやっているので、ならすと月一万くらいになる。

自己負担額は所得に応じて決まるものだから負担が重すぎるということはないし、補助なしではもっと高額になるところを免じてもらっているのだから有り難がりこそすれ不満など言えた立場ではない。

元アナウンサーが人工透析の患者を誹謗するようなことをいって炎上した一連の記事などを少し読んだ。正論だと思うし、自分が病気一つしない健康な身体の持ち主だったら賛同していたかもしれない。

けれども、人工透析ほどではないにせよ高額な医療に依存して生きている身からすると、医療を「足切り」すべきだという風潮は受け入れがたい。だって金払えなくなったら死ぬ、死ねってことだもの。それは過酷すぎる。人並み以上に働いて稼ぐことが難しい病人には、なおさら。

1 on 1 evaluation - @kyanny's blog

先月下半期の評価面談をした。制度の開始時期の関係で上半期のぶんが通常のスケジュールより遅れたため間隔が短いが、今回から正規のフローということになる。

前回話にあがったのは Software Engineer in Test とかそういうキャリアのことで、しかし Quality Assurance を専門にしたいわけでもないんだよなぁ、というあたりがネックだったのだが、三ヶ月で状況が変わった。

アプリケーションをまたぐ機能テストの負担が急激に増し、リリース作業に多くの時間と人手がかかるようになってしまい、このままでは破綻してしまうので何か手を打たねば、ということになって、機能テストを自動化してテスト作業の負担を減らすプロジェクトを立ち上げて夏頃から掛け持ちでやっている。

単体テストはけっこうしっかりやっていると思っていて、 Rails で書いているサーバサイドはもちろん、 CoffeeScript と Marionette.js で書いている クライアントサイドのシングルページアプリケーションも、カバレッジは 60% から 80% はあると思う。

しかし複数のアプリケーションが非同期に連動する機能は単体テストでカバーするのが難しく、自動化したテストを書く試みは社内で何度も行われてきたが、テストのメンテナンスが追いつかず頓挫を繰り返してきた。

今回は社内の「プロジェクト制」のフローにのっとり、目的や期間を明示したうえでちゃんとプロジェクトとして承認され、この作業にリソースを使ってもよいとお墨付きをもらったうえで取り組んでいる。過去の失敗例はエンジニアが「片手間」でやっていたため、継続的な取り組みができないことが原因だったと考えたのだ。

残念ながらまだ結果は出せておらず、何度もスケジュールを延期している。他の開発プロジェクトと二足のわらじで取り組むのは思っていたよりも大変で、まとまった時間を確保できない。見積もりが甘かった。 Selenium WebDriver のブラウザ毎の細かい振る舞いの差にも苦しめられた。幸い、難易度の高さや重要性には理解を示してもらっているので、実運用にのせるまでしっかりやりきりたい。

それ以外では、評価面談だから当たり前だけどやっぱりキャリアの話になって、「プロダクトコードを書くことに強いこだわりがあるのは理解できるけど、どちらかといえば技術のスペシャリストよりも人・組織・プロセスとかのマネジメントが向いてるタイプだよね」と鋭い指摘を受けた。

好き嫌いが激しいし気分にムラがあるから向かないんじゃないですかね、と反論したら「（もしそういうキャリアに進むなら）そういうところは直したほうがいいね」と切り返されてしまい、ぐうの音もでなかった。

自分でも、技術のスペシャリストにはついぞなれなかったな、という事実は受け入れている。組織が成長するにつれ、そういう人間がハブ・パイプ役の仕事をするようになる、というのもわかる。そういう仕事も大事で、こういう変化はどこの会社でも起きているというのも知っている。

でもまだひっかかる。仮に数年後、自分が四十歳になったときマネジメント中心に仕事内容がシフトしていくとして、そこに「肩たたき」的な要素が全くないのか？といえば、そりゃ当然あるだろう。

スポーツ選手と違い、ソフトウェア開発者には肉体的な限界で現役を引退するということがない。であれば例えば逆に、スポーツ選手にも肉体的な限界が無く、実力と実績と年俸とニーズのバランスで現役を続けられるか否か決まるとしたら、トップ選手が死ぬまで競技をして巨額の報酬を得られる一方で、選手生命十五年くらいになると指導者とかチームスタッフとかへの転身を打診される人は、選手としての価値がもはやコストに見合わないと判断されたということだ。トップ選手はもちろん、自分より実力と実績で劣るが年俸の安い若手にも負けるということだ。

そういうことを、易々と受け入れてしまっていいのか？いやむしろ、その日が来たときのために今から備えておくべきなのか？と考えているうちに、プロスポーツ選手が明らかに全盛期より見劣りするパフォーマンスしか出せなくなったのに現役続行にこだわる理由がわかった気がした。

まぁ、「コストに見合わないんで、首切りますわ。それか年俸大幅カットね」とならないだけ、サラリーマンはマシではある。

インフルエンザ

数年ぶりにインフルエンザに罹った。けっこう熱が出て、関節痛などもあり、喉もやられて、大変だ（現在進行系）

火曜日くらい: 喉の痛みがあり、風邪のひきはじめのような感じだったが三年もののイソジンでうがいをしたら治った。思えばここで油断した。

木曜日: 夜に会社の飲み会。おそらくここで感染した疑いがある。たぶん関係ないけど去年予防接種をしなかったことが悔やまれる。

金曜日: 体調は全く問題なし。飲み会に同席した隣席の同僚がインフルエンザで会社を休んだのでやや不穏な感じだったが、自分は大丈夫だろうと思っていた。

土曜日: 夕方くらいからなんとなく変調の兆しのようなものを感じ、夜になるとだんだん具合が悪くなっていき、夕食もとらずに寝込む。発熱もはじまり、 37.6 度くらい出る。寒気や関節痛がひどく、眠ることもできない。

日曜日: 午前中に緊急外来を受診する。発熱と頭痛がひどく、二時間待たされてインフルエンザA型という結果が出た。帰宅後薬を飲んでひたすら横になる。熱は最高 38.9 度まで上がった。

月曜日: 依然として食欲も湧かず、身体が痛くて横になってじっとしているのもつらい。熱の下がり方もおそく、 37.9 度くらい。この時期にしっかり食べておかなかったのがまた失敗だった。

火曜日: 仕事を休み、ひたすら自宅で布団とソファーを行ったり来たりする。数日ろくに食べていなかったせいで体力の衰えがひどく、腹痛や咳が悪化しはじめる。熱は 37 土台前半に下がりはじめる。

水曜日: 熱はほぼ下がったが、咳がひどく、仕事ができる状態ではないのでもう一日仕事を休む。身体の痛みも収まってきたので比較的よく眠れた。このままだと社会復帰できなくなるので無理にでも身体を動かそうと夜は家事に精を出す。

木曜日: まだ出社はできないので自宅作業。咳は落ち着きつつあるが熱がぶり返してしまい一時は 37.5 度まであがってしまう。

小説 言の葉の庭

よかった。映画を先になんども観ていて、それが大好きで、その映像とか音とかの記憶があってこそのひいき目が多分にあるだろうことは承知の上で、でもめちゃくちゃよかった。

小説を読んでる最中に、読み終える前から、もう一回頭から読みたいと思ったのは初めてだったかもしれない。

小説　言の葉の庭<小説　言の葉の庭> (角川文庫)

ChromeDriver でウィンドウサイズを指定しなかったらレスポンシブ・ウェブデザインなサイトのテストでハマった話

前提

Selenium WebDriver と ChromeDriver を使うと、 Chrome の新規ウィンドウが適当なサイズで立ち上がるが、 width が微妙に狭い。さらにディスプレイのサイズとの兼ね合いで、 CSS のメディアクエリのブレークポイントをこえてしまうことがある。そのせいでハマった話。

結論

Chrome の起動オプションを指定してウィンドウサイズを固定すべし。

解説

Capybara から Selenium WebDriver を使って、とあるウェブアプリケーションに対するブラウザ自動化テストを書いていた。このウェブアプリケーションはレスポンシブ・ウェブデザインを採用しており、 Bootstrap v4 の hidden-*-up や hidden-*-down を利用している。

これらのユーティリティ・クラスを使って、画面サイズに応じてヘッダー部分のメニュー項目をハンバーガーメニューの中にしまいこむようになっている。ものすごく簡略化すると↓のようなマークアップになる。

codepen.io

自分の作業環境は Retina ディスプレイの MacBook Pro に DELL の U2212HW という外部ディスプレイを接続している。解像度はそれぞれこうなっている。

ChromeDriver によって立ち上げられる Chrome ウィンドウのサイズは、アクティブなディスプレイのサイズを元に決定されるらしく、 Retina ディスプレイ側で起動したときと外部ディスプレイ側で起動したときでサイズが異なる。

このサイズの違いがちょうど、ウェブアプリケーションの CSS メディアクエリのブレークポイントを超えてしまう数字だった。書いていたテストスクリプトの中で、ヘッダーメニューの要素の属性値をチェックする箇所があり、小さいウィンドウサイズの Chrome で実行したときだけ、対象の要素がハンバーガーメニューの中に隠れているのでテストが落ちてしまった。

Firefox はウィンドウサイズを指定せずとも十分大きなウィンドウサイズで起動し、 Chrome も Retina ディスプレイ側で起動されたときは問題ないため、一見すると「Chrome でだけランダムに落ちる」という状況で、原因の特定に苦労した。テストが落ちてもブラウザのウィンドウを閉じないようにした上で、開きっぱなしのウィンドウで Developer Tools のコンソールを起動して要素を探したりしているうちに、ヘッダーの見た目が違うことに気づき、解決に至った。

以下、アクティブなディスプレイの違いによって起動した Chrome のウィンドウサイズが異なる例。

ウィンドウサイズ指定無し・Retina ディスプレイ側で起動

テストスクリプト

capybara-chromedriver-change-window-size/test.rb at master · kyanny/capybara-chromedriver-change-window-size · GitHub

Chrome のウィンドウサイズは 2100 ピクセル。 width が十分大きいので、 hidden-md-down の要素が表示される。

ウィンドウサイズ指定無し・外部ディスプレイ側で起動

テストスクリプト

capybara-chromedriver-change-window-size/test.rb at master · kyanny/capybara-chromedriver-change-window-size · GitHub

Chrome のウィンドウサイズは 927 ピクセル。 width がやや小さいので、 hidden-lg-up の要素が表示される。

ウィンドウサイズ指定あり・Retina ディスプレイ側で起動

テストスクリプト

capybara-chromedriver-change-window-size/test2.rb at master · kyanny/capybara-chromedriver-change-window-size · GitHub

Chrome のウィンドウサイズは 2560 ピクセル（1280*2）。 hidden-md-down の要素が表示される。

ウィンドウサイズ指定あり・外部ディスプレイ側で起動

テストスクリプト

capybara-chromedriver-change-window-size/test2.rb at master · kyanny/capybara-chromedriver-change-window-size · GitHub

Chrome のウィンドウサイズは 1280 ピクセル。 hidden-md-down の要素が表示される。

教訓

• エラーメッセージを読んで意味を考えること。「要素がクリックできない」といっているのであれば、ブラウザからは本当に要素が見つけられていないということだ
• ブラウザの画面をよく見ること。超よく見ること。 sleep でもなんでも挟んで開きっぱなしにしたり、スクリーンショットを撮ったり、じっくり見るためにできることはある
• 要素が DOM 上に存在するかチェックするときコンソールから jQuery などで探す場合、 :visible をつけること。これなしで要素にヒットしたとしても、それはブラウザから「見えている」とは限らない
• 特別な理由がない限り、おとなしく Selenium WebDriver のデフォルトである Firefox を使っておくのが無難
  • ただし、今回のケースではどうしても Chrome を使いたい事情があった。 Chrome でのテストカバレッジをあげるために Firefox ではパスするが Chrome で落ちる要素クリック処理まわりのテストをローカル環境でデバッグしていたのだ...