builderscon 2018 Tokyo に行ってきた
2018/09/06から2018/09/08 の日程で builderscon 2018 Tokyo が開催されました。
家族の体調の都合で 2018/09/08 (最終日) は参加できず、家でベルセルクを見るというギャップがやばすぎましたが、 「ブログを書くまでが builderscon です！」 と運営のお姉さんにもリマインドされましたので、書けるところだけ書こうと思います。
Opening
オーガナイザーである @lestrrat さんによるオープニングトーク。
オープニングトークと言っても、内容は主にイベント過ごし方における注意点でした。 @lestrrat さん曰く「本番でしゃべらなくて済むように」とのことでしたが、あれはあれで準備コストが高そうでした。
参加者もプロフェショナルとして相手と接すること
Openingで個人的に感動したのは、 参加者にもプロフェッショナリズムを意識させた 点です。
「お互いプロフェッショナルなんだから、お互いを尊重しましょう」というあの１シーンがあっただけで、イベントの治安がだいぶ良くなったのではないかと思います。
「知らなかった、を知る」
というイベントテーマのチョイスも良かったです。
加えて、 builderscon 自体に技術的な縛りが無いことも、 知らないことに対する寛容さ みたいなものに寄与しているかもしれません。というかセッションテーマ的に「こんなん知らんし」なモノも多かったですし笑
以前、DevRelCon 2017 Tokyo に参加したとき、外国人がめちゃめちゃ多かったのですが、 知らないことは「ここ教えてくれ」と積極的に質問していたし 、情報のgive&takeが活発だったので、「あー、いいイベントだな」と感じたのを思い出しました。
Envoy internals deep dive
Lyft 社の @mattklein123 さんが Envoy の仕組みについて発表してくれました。
当日の発表資料は見つかりませんでしたが、KubeCon での発表動画が youtube にアップロードされていました。動画を拝見した所、資料も同様でしたので（細部は修正されているかもしれません）、そちらのリンクを掲載しておきます。
メインテーマは Envoy の仕組みの話になるのですが、 予習せずに聞いた身としては、なかなか理解が難しかったです。途中から完全に置いていかれてしまいました。
Lyft は5年前まではモノリスなアーキテクチャ、3年前からマイクロサービスアーキテクチャに移行していったが、課題が様々あったそうです。そして、開発者はマイクロサービスが嫌いになっていた、、、というようなことが説明されます。
トレーサビリティも下がりますし、レイテンシーも気になってくるしで、マイクロサービスであるが故の課題に対する打ち手としての Envoy が爆誕することになります。
残念ながら、私の観測範囲で絶賛マイクロサービス中なプロダクトはほぼ無いので、 Envoy がどれほどイケているかを熱く語ることはできませんが、「次のプロダクトではこっそり入れてみるか」と思わせる誘惑がありました。
一応誤解がないように言っておくと、個人的には 「プロダクトチームが、ちゃんとしたシステムをモノリスでもいいから作れるかどうか」 を重視していますし、マネタイズの過程で肥大化していったモノリスが、自分たちの明日の生活費を稼いでくれていたりもするので、モノリス vs マイクロサービス の構図はあまり好きではありません。
とはいえ確かに、肥大化しすぎたモノリスはいずれ確実にヒデブなので、マイクロサービスへのマイグレーションタイミングの見極めスキルを鍛えつつ、 そのタイミングまでに Envoy は触っておくと良さそうだ、と感じました。
開発現場で役立たせるための設計原則とパターン
次に @shinpei0213 さんの発表を聞きました。
※ 資料は後日公開されるそうです。
このセッションでは、
- プログラム設計の妥当性に関する会話では、きちんと言語化することが大切
- 設計原則やデザインパターンと照らし合わせると言語化しやすくなり、今ある問題にフィットする設計に近づける
という主旨だと理解しました。
新卒の頃はプログラム設計にも力を入れて学習していたのですが、最近では、「ケースバイケースかなぁ」とボヤいたり、「まぁ、どっちでもいいんじゃない？」と言ってしまうことすらあります。
使い捨てのソースコードが増えたと言うのか、フォーカスする矛先が変わったのか、単純に私が老いただけなのか、いずれにせよこの時点で既に言語化できていないので、いよいよマズそうです。
「抽象化」や「責務」をやみくもに分割せずに、先人たちの教えに思い出しながら設計しよう！という点は 新人教育における「教える立場目線」で見た時に、転ばぬ先の杖的な考え方として参考になりました。
Q&Aタイムでは以下のような質疑応答がなされました。
- 設計原則にも適用するフェーズというか、タイミングのようなものがありそうだ
- 問題を再定義することで原則の適用の仕方も変わり、設計も変わりそうだ
ちなみに、発表中に紹介された書籍 マルチパラダイムデザイン はamazonで見たら中古本しかなかったです。高い。
あらゆるデザインパターンでFizzzBuzzを書いた FizzBuzzEnterpriseEdition という 魔改造リポジトリも教えていただきました。
事前知識なしで理解する、静的検査のいろは
@orga_chem さんによるコードの静的解析器の作り方講座です。
発表資料はこちら にあります。サンプルプログラムの処理順もかなり丁寧に説明されており、資料のクオリティも高かったです。視認性大事です。
資料に全てが書かれているため、もはや、ここではセッション概要を書く必要性はありませんが、
特に「素直な実装」を通じて基本概念を学ぶことは、初学者に対する学習過程ではとても効果的であることと、 「あ、自分でも作れるかも」と思わせる題材選びや段取り、まとめ方の工夫を感じました。
JavaCardの世界
SIMカードの大半はJavaで動いているけど、JavaCard用のランタイム（サブセット）で動いていて、いろいろ制約もあって大変だよ！ をユーモア溢れる表現で発表されていました。
当初、このセッションは発表の時間帯に開催されるセッションの中で最も縁遠いだろうと思い選びましたが、 結果として、生で聞けてよかった。会場も笑いが耐えませんでした。
現場で使われている技術を程よい抽象度で説明し、つらみのあった部分はユーモラスに話すというベストスピーカー賞納得の話しぶりでした。
Q&Aでは、JavaCard経験者によるプロトコルの領域の違い関する稀有な質問から、「今後JavaCardで食っていけますか？」みたいなラフな質問まで、質問がめちゃ出ました。
もちろん、質問に対して、発表者が「いやぁ、わかりません」と返しても全然良い雰囲気もとても良かったです。
とはいえ、技術的な話もしっかり説明されているので、JavaでSIMカードの実装をすることが万に一つあれば、資料を再び参考にさせていただきます。（たぶん無い）
lld − 開発ツールの主要コンポーネントの1つをスクラッチから作成した話
最後に @rui314 さんの発表です。
※ 資料は今のところ見当たりません。
ご自身が実装されたリンカ lld に関するセッションです。
lld は LLVM のサブプロジェクトで、 ELF、COEF、MAch-O、WebAssembly（Experimental）をサポートしており、とにかく高速なリンカ （リンカはオブジェクトファイルを１つの実行ファイルやDLLにまとめるプログラム）で、多くのプロダクトで採用されています。
中盤はその開発の経緯や、開発時の経験談を伺うことができました。
リンカを実装するか、コンパイラを実装するかでリンカを選択したこと
リンカを作ると決めてから、バイナリを印刷して読みふけって独学したこと、
一度作成したリンカを「一回書き直したい」と提案し、賛成派と反対派でチームを真っ二つに割ったこと、
それでも自分が開発を推進していく姿勢、
まさにスーパープログラマの人生の断片を覗かせていただきました。
また、うろ覚えですが、以下のようなことも仰っていて、
- 「似たようなコードでも、実際は微妙に違うから、変に共通化しない方がいい」
- 「こだわってもしょうがないところは捨てる」
- 「データ構造が重要。コードはデータ構造が決まれば自然と書ける」
- 「（コードを書き直す所の勘所は）勘」
原理主義に陥るのではなく、シンプルに考えてコードを書き、強い勇気を持ってプロダクトを推進していくのが大切だ 、 というメッセージを受け取りました。
まとめ
builderscon 2018 Tokyo とても良かったです。最終日が参加できなかったのが残念でしたが、 また来年も参加できたらいいなと感じました。
運営の皆様のご尽力もあったので、不便・不都合なく過ごすことができました。ありがとうございました。
というわけで、ブログを書いたので私のbuildersconは終了しました！
