builderscon tokyo 2018 2日目に参加してきた
1日目 に引き続き2日目も行ってきた！
あえて知らないテーマに突っ込んでいった結果、わからない話も多かったけどそのぶん勉強欲もそそられた。
感想記事はまた別に立てるとして、聴いてきたトークは↓↓
トーク
次世代通信プロトコルにおけるセキュリティ・プライバシー保護・パフォーマンス
次世代通信プロトコルにおけるセキュリティ・プライバシー保護・パフォーマンス (Security, privacy, performance of the upcoming transport protocols) - builderscon tokyo 2018
by @kazuho さん
通信プロトコルの仕様を策定してる方のお話、ところどころ「ここは私が提案してて」というのが出てきて異次元だった……！
TLで解説・感想を追いながらわからない単語調べながら、Webエンジニアとしてこれはあかんという強い反省の念。
勉強します……
kazuhoさんがスライドとともに記事をあげていらしたので貼らせていただきます↓↓
高集積コンテナホスティングにおけるボトルネックとその解法
高集積コンテナホスティングにおけるボトルネックとその解法 - builderscon tokyo 2018
by @pyama86 さん
なんかすごいテクニックとかあるのかなあと思って行ったら「測定 → バックトレース → ソース読む」の地道かつ高度なパフォーマンスチューニングだった。
最後におっしゃっていた「基礎的学習が大事」っていうのがすごく響いた。
『Linuxプログラミングインタフェース』読まないと……。
ブログサービスのHTTPS化を支えたAWSで作るピタゴラスイッチ
ブログサービスのHTTPS化を支えたAWSで作るピタゴラスイッチ - builderscon tokyo 2018
by @aereal さん
なるほど……なるほど……！ ってずっと思ってた。
一部のレコード（証明書期限の近いドメイン）を対象にするとき、アプリケーション側が条件付けてDBに検索かけるのではなくて、
対象となるデータが生まれた（証明書の期限が近くなった）ときDB側からシグナルを送ることで、アプリケーション側は「対象のレコードを探す」という処理から解放される、
ていうの目からウロコだった。
1日目のairflowでも思ったけど非同期で処理進めるバッチ処理うまいこと作りたいな、でそれを「ピタゴラスイッチ」て呼ぶの好きだった（笑
Using Chrome Developer Tools to hack your way into concerts
Using Chrome Developer Tools to hack your way into concerts - builderscon tokyo 2018
by @amyngyn さん
テイラー・スウィフトのチケットを取るためにMV再生サイトをハックする話。すごくチャーミングで面白いトークだった！w
MVたくさん見たユーザーのチケット当選確率を上げるっていうの、確かにhydeが同じことやったら私も同じチャレンジするかもしれない……w
子供心みたいなものをみんなで思い出す良い場だった（笑
1日約70万ビルド: DockerとNomadが支えるCI/CDプラットフォーム
1日約70万ビルド: DockerとNomadが支えるCI/CDプラットフォーム - builderscon tokyo 2018
by @kimhirokuni さん
CircleCIの中の人！ K8sが世界制覇する中で、1年前に選んだNomadの話。
CircleCI 1.0がたまに落ちる理由もあわせて解説してて、使ってたらもっと面白く聞けただろうなーとちょっと無念。
「K8sは小規模サービスには複雑すぎる」っていうところに自分がぶちあたったらNomadを検討してみようかな。
GirHubから落としてくるだけだから運用が楽っていうの魅力的だった。
スライドあげていらしたので貼らせていただきます↓↓
1日約70万ビルド: DockerとNomadが支えるCI/CDプラットフォーム - Speaker Deck
LT
LTと言いつつそうそうたるメンバーで、どのトークもLTにするにはもったいないくらい面白かった！！
数百人を前にLTとかすごいな……手震えそう……
ハッシュタグTLはここが一番楽しかったw
印象的かつスライド見つけられたトークをいくつか↓↓
こうして見るとたくさん聞いたな……2日間ものすごいインプットがあった、うまく処理してアウトプットに活かしていかねば。
builderscon tokyo 2018 聴講メモ #8「Lightning Talks」
2日目最後のLT大会もめちゃくちゃ面白かったので、見つけたスライドと感想をちょこっと！
チームでテストを書くために
by Masashi Hirano さん
指示するだけのBossではなく、率先して実行するLeader。すごく勇気と根気が要ることをやって結果が出てるのすごい、見習いたい。
チームメンバーから改善の意見が出るのってすごく嬉しいだろうなあ。
実は昔バイトしてた（大学が忙しくなってフェードアウトしてしまった）会社さんなのでちょっと「おおっ」って思った（笑
cpanfileがRubyでパースできることに気づいた俺たちは
www.slideshare.net
by @onk さん
これはまさかすぎて笑ったw いや確かにそうかもしれないけどやる！？ww
「評価してみます！」からの実演 → 会場「おおー」w
こういうノリ持っていたいなー楽しかった。
Development Tools for Next Generation
by @mizchi さん
Chromebookでも開発できるようにエディタを自作↓↓ すごい……
Next Editor
"git for everyone" は壮大な思想だ、デモ見てたらアクセスしやすい位置でぽちぽちしてcommit, pushできるみたいだった。
「エンジニアが転職しやすいのはGitHub Workflowで仕事が標準化されているから」はなるほどだった。
ネットワーク障害を支配したい話
www.slideshare.net
by HIRATA, Satoshiさん
ちょっと福岡disりすぎでは？？？w
擬似的にネットワーク障害を起こして対応の素振りをする、自分でサービス運用するときぜひやりたい……！
おまけ感覚でLT聞くつもりだったけど（すみません）本編レベルでテンション上がった！！
おつかれさまでしたー！
builderscon tokyo 2018 聴講メモ #7「Using Chrome Developer Tools to hack your way into concerts」by amyngynさん
※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライドか、もしくはYouTubeで公開される（？）公式動画をご覧ください。
Using Chrome Developer Tools to hack your way into concerts
@amyngyn
テーマ
テイラー・スウィフトのPVを何度も再生することで、チケットの当選確率を上げる
テイクホームメッセージ
- Tools
- コンソール上でコード実行
- Network
- XHRを再現してみる
- curl
- メンタル
- 忍耐力
- 好奇心
内容めも
再生数の偽装には成功したものの、結局チケットは買わなかった
（炎上しそうなので最初に書いとく↑↑）
- 再生速度を上げて何度も再生する
ブラウザからサーバーへ「動画を見た」と伝えているはず
- 左上の窓からドメインをしぼって、Networkタブで通信内容を見る。
Youtubeからstart, countが送られる。countのレスポンス内容にsuccess:trueがある - 右クリックからXHRリクエストを再度送ると、レスポンスが
success:falseになった（駄目らしい） - Initiateタブからスタックトレース、リクエストを送るときの処理を確認する
id という変数に何か文字列が入っている、値は毎回変わる。ここが大事？ - curlで同じcountリクエストを投げてみる → 失敗
- start → count の流れが必要？
- start 投げてIDを獲得してからcount投げるといけるらしい、自動化できた
→ テイラー・スウィフトのファンとしてNo.1の立場を確立した！！w
- 左上の窓からドメインをしぼって、Networkタブで通信内容を見る。
防ぐ
- CAPTCHA
テイラー・スウィフトの場合、視聴の度にボタン押させるのは現実的でなかった - DOMをランダム化する
- 変数名を変える
- リクエストのvalidation
1分の動画について1分間に1回より多く視聴されることはありえない - shadow banning：リクエストの成否をあえて返さない（常に
success:true）
- CAPTCHA
質疑
- 余罪は 基本はちゃんとやってますw でも楽しいし、色んなツールをさわってみるのは良いこと
テイラー・スウィフト側から熱烈なファン認定されて、エンジニアとしてインターンのオファー来た（けど仕事あったから断った）。
うまくいったときは「計 画 通 り」（あの顔 アニメver.）← DEATH NOTE好き
感想
ローカルに立てた疑似動画再生サイトで実演しながらの講演、再生数カウントが増えたときにはみんなで「おおー」w
誰もが一度は持ったことのある（と私は思う）ちょっと悪いことをこっそりやってきゃっきゃするあの感じ、すごくチャーミングで楽しかった！w
エンジニアリングが仕事になって義務になって、忘れてた最初のどきどきを思い出させてくれる良いトークだった……！
builderscon tokyo 2018 聴講メモ #6「ブログサービスのHTTPS化を支えたAWSで作るピタゴラスイッチ」by aerealさん
※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライドか、もしくはYouTubeで公開される（？）公式動画をご覧ください。
ブログサービスのHTTPS化を支えたAWSで作るピタゴラスイッチ
@aereal
テーマ
テイクホームメッセージ
- バッチシステムについても、ソフトウェア構築一般の原則が使える
- 状態を持たない
- 分割統治
- ↑↑実現するための一例として、
- ワークフローエンジン：AWS StepFunctions
- pub/subをサポートするデータストア：DynamoDB
内容めも
- Let's encrypt
APIで証明書発行が可能
← はてなから寄付も。これから継続していく 万単位のドメイン。発行・管理を自動化しないと有料プランのサービスとしてきつい
配信の要件
発行の要件
発行の実装
更新の実装
考察：ピタゴラスイッチ
巨大なバッチの難しさ- 全体でどれだけあって、どこで失敗しうる／したのか把握しにくい
全体がわからないとどこにどう手を入れていいかわからなくなる - 巨大なバッチ、扱うデータ量が巨大 → 処理時間が長くなる。成功／失敗のログが必要
- 全体でどれだけあって、どこで失敗しうる／したのか把握しにくい
さいきょうのピタゴラスイッチ
- ワークフローエンジンの導入
- 分割統治
バッチ処理側がデータの状態を気にしなくていいようにする
アプリケーション書くときは意識できてるのに、なぜバッチ設計ではできないのか？- 合成可能ではない
合成可能なバッチ
質疑
- SFnのテスト
ダミーのLamdaを呼び出すようにして動かしてみた - TTL Triggerで失敗したとき、DynamoDBから消えているからリトライできてないんでは？
TTLを仕込んだテーブルと仕込んでないテーブルの2つがある。
TTLは証明書の期限より2週間くらい早く設定している。
リトライにも失敗したらMackerelから通知が来るのでログを元に手動対応。 - proxyのリロード、メモリにのっていたもの消えちゃうんでは？
proxyのリロード = nginxのプロセス再起動。memcachedにのっているのでnginxを立ち上げ直しても影響はしない。
memcachedにも無かったらDynamoDBに取りに行くが、そのときの遅延も許容範囲内だった。 - AWS SFnの設定をJSONで書くの、気持ちのいいもの？w
全体でどういう状態があるか、みたいなスキーマが特に無いから今は平気。
だけどミスったときに検知できない。バッチ側から可能的な状態一覧を生成するようにしたい。。。
感想
ソフトウェア設計の考え方をこういうシステム設計に適用するっていうの、ちらちら思ってたけど全然実現できてなくてすごく参考になった。
TTL Triggerみたいなマネージドサービスの機能をきれいに使ってるの見て、自分の思考がアプリケーション（プログラム）の中に閉じてたのに気づいた。
解くべき問題（要件）をまとめた後、何が最短経路かを構成全部から考えられるようになりたい。
こういう設計力、勉強というより実際のサービス設計・運用とかその過程でのディスカッションとかから得られるのかなあ。
日常にディスカッションが足りない……。
builderscon tokyo 2018 聴講メモ #5「高集積コンテナホスティングにおけるボトルネックとその解法」by P山さん
※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライドか、もしくはYouTubeで公開される（？）公式動画をご覧ください。
高集積コンテナホスティングにおけるボトルネックとその解法
@pyama86
GMOペパボ ホスティング事業部
ロリポップ！ マネージドクラウド
テーマ
- 7分であなたもコンテナーマイスター講座
- はまった問題
- 展望
テイクホームメッセージ
- コンテナのボトルネックはLinuxコマンドを駆使してあたりをつけて解決する
- そのシステムコールが何をするのか、基礎的学習が必要（manを読んでわかるように）
『Linuxプログラミングインタフェース』
内容めも
コンテナ = プロセス
FastContainerアーキテクチャ
事象：監視コンテナのダウン
事象：コンテナが起動しない
- bridgeにインタフェース追加するとき：1025になっている。上限ぽいな
- BR_PORT_BITS：10 ← 1つのbridgeに2の10乗がポートの上限
- bridgeを分散させる
事象：CPU・メモリには余裕があるのにLAが高い
- cadviser：google製コンテナリソース管理
- gdb → bt（back trace）
- iproute2でnetlinkを利用したNSID取得 ← 最新のソースでは取得していなかった
もともと、ディストリビューションが配布しているパッケージでインストールしていた - 取得しないようにしたら2秒→0.05秒へ
gdb 便利
ディストリビューション配布、意外と最新のソースと乖離している。詰まったらソース読んで見る4000コンテナ弱でメモリ枯渇 = リソース使い切れた！
システム調査コマンド valfrind
あるwordpressサイトにabかけたら別のサイトが落ちた
コンテナなのに……？
質疑
- 直感的に、コンテナの起動はI/O等に比べて負荷にはならなさそうだけど
うちではディスクI/Oは負荷にはなっていなかった - コンテナの起動速度（イメージによりそうだけど）
過負荷状態でなければ1秒以内。起動直前の状態をメモリにのせて、メモリから起動する方法を検証中 - iproute2入れ方
makeインストール
感想
「測定 → バックトレース → ソース読む」の流れ、言うは易し行うは難しだ……。インフラ屋さんすごい……。
今まで現職でもうわからんって匙を投げてたところをこういうふうに調べて直していけたらどんなに良いだろう。
ものを言うのは知識と努力だ、がんばろって思わせてくれた。
あと何より面白かった！w
こんな高い技術あってこんな楽しく話す人と働けたらめっちゃ楽しいだろうなーって、こういう人たちと一緒に働けるくらい勉強と経験を積まないとなーって思った。
builderscon tokyo 2018 1日目に参加してきた
行ってきたーーー！
全部のトーク聞けないのもどかしすぎたけど、選んだどのトークでも「知らなかった、を聞く」を圧倒的な衝撃をもって体験させてもらった。
エンジニアになってよかったって、身体にすとんとくる感覚があった。明日も楽しみ。
トーク
トークはこちら↓↓を拝聴した！
全部メモを取ってたんだけど、ちょっと内容に自信無いものもあるから抜粋で記事にあげた。
産業でガチ利用されるRaspberry Piの話
産業でガチ利用されるRaspberry Piの話 - builderscon tokyo 2018
by @kazuph さん
ラズパイほんとに使われてるんだ……！ っていうレベルのガチ無知だったりしたんだけどちゃんと聞けたw
セキュリティとかログとか、webと同じテーマだけど違う制約の問題になっているところが個人的に面白かった！
開発現場で役立たせるための設計原則とパターン
開発現場で役立たせるための設計原則とパターン - builderscon tokyo 2018
by @shinpei0213 さん
あるあるすぎる課題を「『デザパタによる構造化』と『設計原則によるレビュー』とのサイクル」で鮮やかに解決しててテンションあがった！
事前知識なしで理解する、静的検査のいろは
事前知識なしで理解する、静的検査のいろは - builderscon tokyo 2018
by Kuniwak さん
スライドめちゃくちゃわかりやすかった！ 構文解析をひとさらいするとソースコードとかエラーメッセージとかの見方が変わって面白いなーと。
これからRubyやるし、rubocop読もうというきもち。
これはスライドが完璧すぎて足すこと無い……w スピーカーの方がブログ記事上げていらしたので貼らせていただきます↓↓
機械学習を用いず数学でゲーム内の需要予測をする
機械学習を用いず数学でゲーム内の需要予測をする - builderscon tokyo 2018
by @nessie_sesein さん
数学徒な名言がばんばん出てきて楽しかったw 黒い羊の寓話を体現するようなセッションだった。
airflowを用いて、複雑大規模なジョブフロー管理に立ち向かう
airflowを用いて、複雑大規模なジョブフロー管理に立ち向かう - builderscon tokyo 2018
by Attsun さん
airflow気になってたから聞けてよかった。Pythonのコードで管理っていうのイメージつかなかったけどふむふむ、てなった。
サーバー大丈夫か……？ てなったけど豊富な余力があるのねブレインパッド……！w
スライド公開されてた！
builderscon2018 airflowを用いて、 複雑大規模なジョブフロー管理 に立ち向かう - Speaker Deck
安全なランダムネスの理論と実践
Safe randomness: theory and practice - builderscon tokyo 2018
by Kenji Rikitake さん
はずかしながら全然考えたことなくて、PCのハード部分（打鍵とか）からランダムネスを生成する発想も知らなかった……！
こちらもスライド公開されてた！
Safe randomness: theory and practice - Speaker Deck
lld − 開発ツールの主要コンポーネントの1つをスクラッチから作成した話
lld − 開発ツールの主要コンポーネントの1つをスクラッチから作成した話 - builderscon tokyo 2018
by Rui Ueyama さん
ちょっとこのトークの感動はまだうまく言語化できてない……。
メモだけ↓↓
builderscon tokyo 2018 聴講メモ #4「lld − 開発ツールの主要コンポーネントの1つをスクラッチから作成した話」by Rui Ueyamaさん
（スライド公開されたら貼らせていただきます）
※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライドか、もしくはYouTubeで公開される（？）公式動画をご覧ください。
lld − 開発ツールの主要コンポーネントの1つをスクラッチから作成した話
@rui314
テーマ
- lldの紹介
- 開発を始めた経緯
- 速くてシンプルなコードを書くためのポイント
- 具体的な高速化のテクニック
テイクホームメッセージ
- 問題についてよく考えて、自分が良いと思うやり方を勇気をもって試してみよう
仮にアンチパターンであっても - 存在しない問題を作り出さない。もともとの問題を直接解決できないのか、をよく考えよう
- 「Unixの開発環境の標準リンカになる」という大きな目標も、誰も挑戦しないだけで意外と実現可能だったりするので、挑戦してみよう
内容
- リンカ：オブジェクトファイルを1つの実行ファイル・DSOにまとめるもの
- 何もしないプログラムのソースコードを、既存のリンカに入れて、出力されたバイナリを印刷して読んだ
→ 1bitだけ変えてみたりして理解していった。 - 当時、Linux, Windows, mac OS すべてファイル形式違うのにひとつのリンカでやっていた
→ スクラッチで書き直し。Windowsだけターゲットとするようにした- 「書き直したくなる気持ちはわかるけど」「リファクタリングでいいのでは」などの意見
→ 無視して書いたら10倍早くなった。 いちいち対応してると 無い問題を解決しようとすることになる - 遅いプログラムを構造によって早くすることはできないが、構造によって自然と早いプログラムが書ける
構造が先、コードは後
- 「書き直したくなる気持ちはわかるけど」「リファクタリングでいいのでは」などの意見
- 他の人が、同じデザインでLinuxのリンカを作った → 4バージョンに対応することに
- OSSとして、オーナーシップを持っておく
- 1回しかコントリビュートしない人が、自分の（狭いスコープで）達成したいことのためにプルリクを出してくる
→ 送ること自体は良いが、それを取り入れるかはオーナーが判断する
きれいなコードはオーナーが保つ
- 1回しかコントリビュートしない人が、自分の（狭いスコープで）達成したいことのためにプルリクを出してくる
- 2回書く ← 1回目から学ぶ。できれば3回書く
質疑
- 「コードを2, 3回書き直してみる」：最初のコードに引きずられそう
1回目書いてるときに思った「ここをこうしてみたら」を次に実践してみる、思いつくものは全部試す感じ。
しっくりくるものを探す。 - 「コードを共有しない」：改修コストがある反面、共通化するとif文が増えたりする。どう選んだ？
勘です。 - 次の目標は
Linuxのディストリビューション全体が10秒でビルドされる、とか？w
カーゴ・カルト・プログラミングはやらない。
80年代に決められたデフォルト値に従う理由は無い。
感想
さいしょわかんないとこ来ちゃったーと思いながら聞いてて、終わったときにはエンジニアとして何かを叩き起こされたような感じで、まだうまく言葉にできない……。
すごく素敵なセッションだった。動画公開されたらまた改めて聴いてみる。それでできれば改めてまとめてみる。
