Write down what I learnt. Opinions are my own.
とした。もともと前半の一文だけだったので後半を付け足した。炎上予防。
「学んだことを記録する場所」くらいのつもりで learnt （あえて learned ではなく）という単語を選んだが、 I have learnt という言い方もあるよなと思ったらどっちが適切なのか気になってしまい、調べたらやっぱり同じことを考える人がいたようだった。
この回答がわかりやすく、納得感があった。挙げられている例に照らし合わせると、このブログは「人生で学んだこと」のような内容も含まれはするものの、どちらかというと「今日学んだこと」を記録と頭の整理のために書くことに主眼を置いているので、 I learnt のほうがふさわしいと感じた。
CSS再入門 - できる！中央寄せ 5 | CodeGrid
日本Web技術界隈著名人の残念さ具合 - thinkchangの日々日誌
名前が挙がっている人たちを擁護するつもりはないが、 naoya さん以外のリサーチが甘すぎると思う。「知名度に対して実績が伴ってないじゃん」という批判を展開するなら実績の部分を調べつくして全部けなす、くらいのことはしろよと思う（例えば宮川さんだったらなぜ Vox に触れないのか、ていうか下の名前の漢字すら調べないの？調べられないの？）妬ましさやけまらしさは非常によく理解できるが。
あと、ブログがアイデンティティな人間として、
本当にトップのサービスやヒットサービスをやっているような人ほど、いちいちブログなんか書かずにプロダクトに集中したり、コードを書いている
これには 99% 同意できない。そういう人もいるのは知ってるけど、意見の妥当さよりもイデオロギーとして同意できない。
あとこの↓最初にコメントしている 3 名のはてブアカウントが作りたての捨てアカウントによる自作自演っぽく見えた。
404 Blog Not Found:YAPC::Asia does not welcome Dan Kogai
But they'll never forget Dan Kogai, I believe.
OSS開発の活発さの維持と良いソフトウェア設計の間には緊張関係があるのだろうか? - t-wadaのブログ
ほとんどの会社組織というものが、無限に事業を拡大し永遠に成長し続けることを前提に運営されているように思えることに疑問を感じたことが過去何度かあり、それに似ていると思った。
「良いソフトウェア」を一つ挙げるとしたら qmail （ないし djb のソフトウェアいずれか）だと思っていて、ソフトウェアは（ソフトであるにもかかわらず）付け加えるものも削るものも何もない安定した状態になるのが最高だと思うのだが、しかしそういう静的なソフトウェアだけからなる静的な世界では自分やその他大勢の人たちはソフトウェア開発者として仕事を得ることも、仕事以外でソフトウェアを書いて承認欲求を満たすこともできないだろうから、活発で新陳代謝の激しいオープンソースソフトウェアの世界（それは「良いソフトウェア」だけからなる静的で安定した世界が最高であるという価値観からみれば理想とは程遠い状態だ）といわば共犯関係にあって、理想の実現を阻む活動にコミットして世の中を悪くすることに加担しているとも言えるのではないか、みたいなことを考えて暗い気持ちになった。
最近フリーソフトウェアの本を読んでいるのでオープンソースに対してちょっと態度が硬化しているのかもしれない。ストールマンの実物を見たことがあり、そのときは大変感動したので、 djb も死ぬ前に一度実物をこの目で見てみたい。
Mackerel開発におけるScalaとGo、そしてPerlを聴きそびれた。目覚ましかけておいて止めた覚えもないのに寝坊してしまい、遅れて到着したら案の定部屋が満室で入れなかった。1日目に引き続き7階の部屋に一度も入ることができなかった。狭すぎだと思う。ショックで心が折れてもう帰ろうかとも思ったが心を落ち着けるためにスタバでコーヒーを飲んで踏みとどまった。
Perl 5.22 and You - YAPC::Asia Tokyo 2015
せっかくだから Perl の話でも聴くかということで聴いた。 sub ($a = 0, return $b = 0) みたいなのが悪い意味でやばいと思った。
「Perl5 コアチームにとって、新しい syntax や operator を追加する動機は何か？よりよい言語デザインのためなのか、言語をより実用的にするためなのか。」という質問を（英語で）した。たぶん回答は、 $str &. $str string bitwise operator を例にとると、 $num & $num と似ているが全然違うもの（役割も挙動も）なので、そういうのはコードを読むときはっきり区別できるほうがよい、あと頻出するものは簡潔にかけるほうがよい、みたいな話で、つまりコードが読みやすくなるようにするという意味での良い言語デザインのためという側面もあるし、コードが書きやすくなるようにするという意味での使いやすさを改善するという側面も、両方あるよ、ということだったのだと思う。
身体が冷えたのでコンビニでおにぎりでも買って建物の外で食べようと思ったがものすごい行列で、混んでいる店は苦手だしコンビニで行列に並ぶのはもっと苦手なので諦めて昼飯はりんかい線の駅のドトールで済ませた。
Adventures in Refactoring - YAPC::Asia Tokyo 2015
小さい部屋に入れず難民になることが多すぎて心が折れたのでもうずっとホールにいようと思い、聴いた。各論では同意できない部分もあったが、総論ではいい話だった。分岐をオブジェクトにカプセル化することでテストを書きやすくするとか、抽象化レイヤを消すとか、 Context の話とかは身に覚えがあった。一方で if のネストを return unless $a && $b && $c とかで書き直すのはむしろ読むのを難しくして同意できないと思った。あと deprecated にしたメソッドをテストでは fail させ production では動かしてあげるというのはいいプラクティスだと思った。 scientist もよさそうだった。
「If there is a controversial, debatable point in someone's refactoring, how do you manage it at GitHub?」という質問をしたが英語が通じず、ゆっくり区切って言い直してもダメで、日本語で言い直して同時通訳に翻訳してもらうはめになった。大ホールで大勢の前で恥をかいてかっこ悪かった。質問の意図は「モメたときどう解決してますか」というもので、スタイルガイドがあればクォートがどうとかいうのはモメなくなる、直接話すのは難しいので、リファクタリングの結果を計測する、あとはとにかくコミュニケーションする、みたいな回答だったと思う。まさか大意すら伝わらないとは思ってもみなくて、アメリカは厳しいと思った。
Parallelism, Concurrency, and Asynchrony in Perl 6 - YAPC::Asia Tokyo 2015
ホールが寒くて身体が冷えるとともに目も疲れてきてスライドが見えづらくなり、途中でついていけなくなった。
Profiling & Optimizing in Go - YAPC::Asia Tokyo 2015
ミーハーなので有名人見にきたけど内容にはさっぱり興味が持てなかった。 Emacs 使いっぽいことを発見したことくらいしか印象に残ってない。
Lightning Talks Day 2 - YAPC::Asia Tokyo 2015
MySQL 5.7 の話が良かった。スピード感があり、おもしろく、内容は役に立つ。 LT のお手本のようだと思った。他も全体的にエンターテインメントやフリーダムの点でレベルが高く、昔の YAPC っぽさを感じた。
クロージング 🎉 - YAPC::Asia Tokyo 2015
最後に http://builderscon.io/ というものがアナウンスされたが、 .io ドメインけっこう高くつくのに流行っててみんな金持ちだなと思った。
会期を通じて何人かの知人に声をかけてもらい、近況報告などをしたが、自分のような人間の相手をしてくれてありがたいと思うと同時に自分のような人間が時間や attention を奪ってしまって申し訳ない気持ちでいっぱいになり、自分のような人間がこんなところにいてはいけない気がして始終うつむきながらおどおど過ごしてしまった。視力が悪い上に遠巻きにスライドを見て目を酷使したので周りがよく見えず、ずっと目を細めていたので顔の筋肉もこわばってしまい、精神的にも肉体的にもぼろぼろで悲壮感に打ちひしがれながら帰った。年々こういう大勢の人が楽しげに過ごす場へ参加したときのコミュ障っぷりが悪化しているので、ネットスラングではなく臨床的な意味でコミュ障なんじゃないだろうかと思った。
JavaScript のテストフレームワーク mocha には .only という機能があり、通常 describe とか it とか書くところを describe.only または it.only と書くとそのテストケースのみを実行してくれる。 RSpec の filter_run を利用した :focus と似たようなもので、単体テストを書くときや落ちるテストの調査をするときに便利。
https://mochajs.org/#exclusive-tests
しかし開発者がうっかり .only を消さずにコミットしてしまい、レビュアーも見逃してしまうと、 CI 上でほとんどのテストが実行されないのに結果は Green になってしまい、 CI を回している意味がなくなるばかりかリグレッションバグの発生にも気付けないのでテストを書いてる意味すらなくなる。
実際にそういう事故が何度か起こってしまっていてどうにかしなくては、と思っていたのだが、気をつけてもうっかりは防げないし、レビュアーが見逃すのも防げないし、そもそも「ウォーリーを探せ」みたいなことをするためにレビューしているのではない。
なので .only を検知する mocha-only-detector というツールを gulp タスクに組み込んで、 CI 環境でテストが実行される前に .only が検知されたら即 abort するようにした。
サンプルプロジェクト kyanny/gulpfile-mocha-only-detector · GitHub
詳しくは gulpfile.js 参照。素朴にコマンド実行しているだけ。
実行結果。 npm test のときは test:unit タスクで mocha が実行されてテストもパスしているが、 npm run test-ci のときは test:mocha-only-detector タスクの時点でエラーとなり、 test:unit タスクを実行する前にテストが失敗して終了してくれる。
gulp タスクの書き方がよくわからず、見よう見まねで書いて苦労した。 mocha-only-detector は grep '\.only' test.js みたいな雑なやり方ではなく JavaScript の静的構文解析をする esprima というものを使って構文解析した上で .only を検知しているので信頼できそう。
世界展開する大規模ウェブサービスのデプロイを支える技術 - YAPC::Asia Tokyo 2015
直列な pull 型のデプロイで限界がきたら結局 tarball 配布して展開とかに行き着くんじゃないのかなと思ってたらやっぱりそういうプランのようだった。 Git リポジトリ同期システムを何の言語で実装し、またなぜそれを選び他を選ばなかったのか？と質問して、開発を支える部分なので運用で冒険したくなく、 Node なども考えたが慣れている Perl5 を選んだとの回答で、正しい選択（基準）だなーと思った。
HTTP/2時代のウェブサイト設計 - YAPC::Asia Tokyo 2015
今フロントエンドで何が起こっているのかを聴きたかったけど満室で入れなかったので広くて入れそうな部屋に入った。 HTTP/2 と SPDY の違いが未だにわかってないので勉強しないとなと思った。 asset pipeline みたいな（小手先の）技術が廃れるだろう、というのは良い未来だと思った。
Perlの上にも三年 〜 ずっとイケてるサービスを作り続ける技術 〜 - YAPC::Asia Tokyo 2015
いい話だった。二種類ある似たようなライブラリで delete_if が正反対の意味の実装になってたという苦労話が面白かった。オブジェクト指向入門上下巻もドメイン駆動設計も持ってて少し読んだけど挫折したので再挑戦したい。意識高い本読んでも実務の巨大なコードベース相手だと知識を活かすの難しくないですかと質問して、歯を食いしばって頑張るとの回答で、頑張ろうと思った。あとひとでくん見れてよかった。
うっかりをなくす技術 - YAPC::Asia Tokyo 2015
16:00 からのトークを聴きたかったがその部屋で先にやってたトークは満室で入れなかったのでまた広い部屋に入った。途中で出てしまったので肝心の本題を聴きそびれた気がする。
esa.io - 趣味から育てたWebサービスで生きていく - YAPC::Asia Tokyo 2015
大規模でも小中規模サービスでも捗る microservices な Web サービスのつくりかたを聴きたかったけどやっぱり満室で入れなかったのででかいホールに入った。ちょっと記憶が曖昧だけど GitHub みたいなハートウォーミングなサクセスストーリーで始まってていい話だった。サポート問い合わせメールに五分以内に返事するのめっちゃえらいと思う。あとまだ採用をしないというのもえらいと思う。
Lightning Talks Day 1 - YAPC::Asia Tokyo 2015
まかまかさんの MC （ではないが他に形容しがたい）が一番面白かった。ライトニングトークの新境地を開いたと思う。
懇親会のチケットを本編と別に申し込まなくてはいけなかったことを知らなくて参加できなかったのですごすごと帰った。情報収集が甘すぎた。トークの合間時間とかにちらほらと知人や元同僚に会ったりした。
7階の小さい部屋は相当前から陣取ってないと入れないことがわかったので、明日は事前にどの部屋でやるかチェックして聴き逃したくないトークははやめに部屋に入っておくように気をつけたい。
