hirapi's blog

駆け出しwebエンジニアのなんでもないメモ書き

builderscon tokyo 2018で初めて大きな技術系カンファレンスに参加してみた感想

hirapi.hatenablog.jp

hirapi.hatenablog.jp

というわけで、知らなかった、をたくさん聞いてきた!!
初めてのカンファレンス参加で、話ついていけるかなーって不安だったわけだけど、予想通りついていけないことのが多かった(笑
でも自分の知らない話を聞いて、そこをきっかけに勉強するのも私みたいな駆け出しにとって良い刺激だと思う!

読まねば&勉強せねば色々あったけどまず取り掛かろうと思ったのは↓↓
(ほんと「そんなのもまともに知らないのかよ」って言われそうだけど)

  • デザインパターン
    @shinpei0213さんのトークが鮮やかすぎて。結城浩さんの本から読んでみようかな。。。
  • Linuxプログラミングインタフェース』
    目指せP山さん
  • 通信プロトコル
    『マスタリングTCP/IP入門編』を読んでからQUIC調べようかな、そのあと@kazuhoさんのスライドまた読む

不勉強なのを揺さぶられて心が折れそうだけど、今あきらめても何年か後に後悔するの目に見えてる。だからやる。
エンジニア選んでよかったし、もっとエンジニアしたいし、ずっとエンジニアでいたいと素直に思った。

公開されたスライドがまとめられたら全部読む。
素敵なトークをしてくださったスピーカーの皆様、本当にありがとうございました!!

フィードバック?

私てきにうれしかった・楽しかったとこと/困ったとこを並べてみる。いつかどこかで誰かの何かになれば!

  • うれしかった・楽しかった

    • おおよそタイムテーブルどおりにものごとが進んでた
      押しが続いてセッション間の移動が大変になるかと思ったけどそんなことなかった、部屋移動多かった身としてはありがたかった
    • 質疑のとき、スピーカーの方が質問を要約してくれた
      YouTube動画のためらしいけど、わかりやすくて助かった
    • 部屋別にハッシュタグがあった
      セッション別にTLを追えた!
    • 発表がスムーズだった
      接続できなくて開始が遅れる、みたいなの基本的に無かった。これ系って地味にストレスになるから良かったと思う
    • 後日フィードバック書ける
      専用ページから出せるフィードバック、1週間くらい書けるらしい。ゆっくり書きたい派としてはうれしい。
    • Wi-Fi安定してた
      1日目たまにつながりにくかったみたいだけど、私が回った部屋では安定してつながってた
    • 名札にアイコン
      特に誰と話したわけでもないんだけど、オンラインとオフラインがつながってる感じで良かった!
    • 朝採れうまい棒
      メルカリってこんなユーモラスな会社だったのねw
  • 困った
    ほとんど会場の問題説はあるけど一応書くだけ書いてみる。

    • 部屋がちょっとせまかった
      セッションに入るために並ぶとは思わなかった……。でもスタッフの方がうまく誘導されてて混乱は無かった!
    • 飲食禁止
      1つのホール以外は飲食できないの、ちょっと厳しかった。そのホールでフリードリンクだったのはめっちゃ助かったw
    • セッション中の困り事をスタッフさんに知らせる手立てが無い
      どこかで急に部屋の電気ついてスライド見えなくなったことがあった。
      「部屋の電気消して〜」ってツイートがTLに散見されてて私も同意だったんだけど消しに行けず……。
      スタッフさんにメッセージ送る手段があったらありがたかった。(意図があって電気つけたのかもしれないけど……)
      良い手段を発明できたら別のカンファとか、あと大学の授業とかでも使えそう。
    • オープニング・クロージングで前回開催時ネタと前夜祭ネタが目立った(?)
      と言いつつ私が気にしいなのが9割。前夜祭行きたかった……
    • 欲を言えばトーク別のハッシュタグが欲しい
      ブログ書くときに思い出しやすくなるかも。あととぅぎゃりやすそう。
      でも分けすぎるとかえってTL追いにくくなるのかなあ……

て感じかなあ。
こんなたくさんのスピーカーとスポンサーと来場者を数十人のスタッフさんでさばいてたのすごすぎでした、運営の皆様おつかれさまでした……!
(次回とか別のカンファレンス/勉強会とかでぜひスタッフやりたいと思った)

ブログを書くまでがビルコン

とのことだったので拙いメモと共にうおーって書いてみた。
ツイートとかブログ記事とかにリアクションもらえるとどこかつながった感があって良いw

ただ聞いて回ってただけなのにインプットの圧がすごすぎて体力つかった、このエネルギーをしっかり取り込んでエンジニアリングしていく!

builderscon tokyo 2018 2日目に参加してきた

builderscon.io

1日目 に引き続き2日目も行ってきた!
あえて知らないテーマに突っ込んでいった結果、わからない話も多かったけどそのぶん勉強欲もそそられた。

感想記事はまた別に立てるとして、聴いてきたトークは↓↓

トーク

次世代通信プロトコルにおけるセキュリティ・プライバシー保護・パフォーマンス

次世代通信プロトコルにおけるセキュリティ・プライバシー保護・パフォーマンス (Security, privacy, performance of the upcoming transport protocols) - builderscon tokyo 2018
by @kazuho さん
通信プロトコルの仕様を策定してる方のお話、ところどころ「ここは私が提案してて」というのが出てきて異次元だった……!
TLで解説・感想を追いながらわからない単語調べながら、Webエンジニアとしてこれはあかんという強い反省の念。
勉強します……

kazuhoさんがスライドとともに記事をあげていらしたので貼らせていただきます↓↓

blog.kazuhooku.com

高集積コンテナホスティングにおけるボトルネックとその解法

高集積コンテナホスティングにおけるボトルネックとその解法 - builderscon tokyo 2018
by @pyama86 さん
なんかすごいテクニックとかあるのかなあと思って行ったら「測定 → バックトレース → ソース読む」の地道かつ高度なパフォーマンスチューニングだった。
最後におっしゃっていた「基礎的学習が大事」っていうのがすごく響いた。
Linuxプログラミングインタフェース』読まないと……。

hirapi.hatenablog.jp

ブログサービスのHTTPS化を支えたAWSで作るピタゴラスイッチ

ブログサービスのHTTPS化を支えたAWSで作るピタゴラスイッチ - builderscon tokyo 2018
by @aereal さん
なるほど……なるほど……! ってずっと思ってた。
一部のレコード(証明書期限の近いドメイン)を対象にするとき、アプリケーション側が条件付けてDBに検索かけるのではなくて、
対象となるデータが生まれた(証明書の期限が近くなった)ときDB側からシグナルを送ることで、アプリケーション側は「対象のレコードを探す」という処理から解放される、
ていうの目からウロコだった。
1日目のairflowでも思ったけど非同期で処理進めるバッチ処理うまいこと作りたいな、でそれを「ピタゴラスイッチ」て呼ぶの好きだった(笑

hirapi.hatenablog.jp

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
子供心みたいなものをみんなで思い出す良い場だった(笑

hirapi.hatenablog.jp

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

印象的かつスライド見つけられたトークをいくつか↓↓

hirapi.hatenablog.jp

こうして見るとたくさん聞いたな……2日間ものすごいインプットがあった、うまく処理してアウトプットに活かしていかねば。

builderscon tokyo 2018 聴講メモ #8「Lightning Talks」

2日目最後のLT大会もめちゃくちゃ面白かったので、見つけたスライドと感想をちょこっと!

チームでテストを書くために

speakerdeck.com

by Masashi Hirano さん
指示するだけのBossではなく、率先して実行するLeader。すごく勇気と根気が要ることをやって結果が出てるのすごい、見習いたい。
チームメンバーから改善の意見が出るのってすごく嬉しいだろうなあ。
実は昔バイトしてた(大学が忙しくなってフェードアウトしてしまった)会社さんなのでちょっと「おおっ」って思った(笑

cpanfileがRubyでパースできることに気づいた俺たちは

www.slideshare.net

by @onk さん
これはまさかすぎて笑ったw いや確かにそうかもしれないけどやる!?ww
「評価してみます!」からの実演 → 会場「おおー」w
こういうノリ持っていたいなー楽しかった。

Development Tools for Next Generation

speakerdeck.com

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さん

speakerdeck.com

※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライドか、もしくは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
  • 防ぐ

    • CAPTCHA
      テイラー・スウィフトの場合、視聴の度にボタン押させるのは現実的でなかった
    • DOMをランダム化する
    • 変数名を変える
    • リクエストのvalidation
      1分の動画について1分間に1回より多く視聴されることはありえない
    • shadow banning:リクエストの成否をあえて返さない(常に success:true

質疑

  • 余罪は 基本はちゃんとやってますw でも楽しいし、色んなツールをさわってみるのは良いこと

テイラー・スウィフト側から熱烈なファン認定されて、エンジニアとしてインターンのオファー来た(けど仕事あったから断った)。
うまくいったときは「計 画 通 り」(あの顔 アニメver.)← DEATH NOTE好き

感想

ローカルに立てた疑似動画再生サイトで実演しながらの講演、再生数カウントが増えたときにはみんなで「おおー」w
誰もが一度は持ったことのある(と私は思う)ちょっと悪いことをこっそりやってきゃっきゃするあの感じ、すごくチャーミングで楽しかった!w
エンジニアリングが仕事になって義務になって、忘れてた最初のどきどきを思い出させてくれる良いトークだった……!

builderscon tokyo 2018 聴講メモ #6「ブログサービスのHTTPS化を支えたAWSで作るピタゴラスイッチ」by aerealさん

speakerdeck.com

※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライドか、もしくはYouTubeで公開される(?)公式動画をご覧ください。

ブログサービスのHTTPS化を支えたAWSで作るピタゴラスイッチ

@aereal

はてな

テーマ

テイクホームメッセージ

  • バッチシステムについても、ソフトウェア構築一般の原則が使える
    • 状態を持たない
    • 分割統治
  • ↑↑実現するための一例として、
    • ワークフローエンジン:AWS StepFunctions
    • pub/subをサポートするデータストア:DynamoDB

内容めも

  • Let's encrypt
    APIで証明書発行が可能
    はてなから寄付も。これから継続していく
  • 万単位のドメイン。発行・管理を自動化しないと有料プランのサービスとしてきつい

  • 配信の要件

    • 万単位のドメイン → メモリ使用量増加、nginxリロード時間増加
      → リクエスト毎にDBやキャッシュから証明書を取得
    • SAN:1証明書に複数ドメイン はどうか? → LEでSANを利用する場合、DNSの設定に制限
    • ACME:証明書発行の自動化プロトコル ← LEが中心に策定を進めている仕様
      ACMEチャレンジ(所有者確認)
  • 発行の要件

    • 無効なドメインは削除しなければならない
      無効なドメインACMEチャレンジに失敗する。
      かつ、LEのAPIには失敗上限がある
    • 要求は高いが不確実性は高い ← 外部APIと通信する、設定はユーザーに任せている
      → 失敗しても一連のフローが完了する必要がある
    • ドメイン数が増えても、実行時間が伸びたりしない
      複数のドメインを1回のバッチで処理しようとすると、失敗したドメインだけリトライというのが難しい
  • 発行の実装

    • AWS Step Functions:JSONでステップ実行を記述
    • はてな → StepFunctions → Lamda → LE → DB・StepFunctions(戻る)
  • 更新の実装

    • DynamoDBのTTL Trigger → StepFunctions
      TTL Trigger:アイテムが寿命を迎えて自動的に削除されたことが流れるストリーム
      → pub/sub形式。都度見に行って対象データを集めてくる処理がバッチのスコープから外れる。
    • AWS SFnでエラーハンドリング
  • 考察:ピタゴラスイッチ
    巨大なバッチの難しさ

    • 全体でどれだけあって、どこで失敗しうる/したのか把握しにくい
      全体がわからないとどこにどう手を入れていいかわからなくなる
    • 巨大なバッチ、扱うデータ量が巨大 → 処理時間が長くなる。成功/失敗のログが必要
  • さいきょうのピタゴラスイッチ

    • ワークフローエンジンの導入
    • 分割統治
      バッチ処理側がデータの状態を気にしなくていいようにする
      アプリケーション書くときは意識できてるのに、なぜバッチ設計ではできないのか?
      • 合成可能ではない
  • 合成可能なバッチ

    • 直列実行を二項演算ととらえてみる
      • operand:責任範囲が小さいこと(1つの演算子が1つの処理を担当する)
        コンポーネントの責任を小さくする
      • operator:様々な法則を満たす
        ステップの副作用を小さくする
    • → 局所状態を持たない local state
      各ステップが変わりうる状態を持つのではなく、グローバルに状態を持つようにする
      グローバル変数みたいなものなら、悪ではないか?
      → 違う。グローバル変数のように誰でも変更できるものではなく、ワークフローエンジンだけが状態を持ち、バッチ処理はそれを受け取るだけになる

質疑

  • 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山さん

speakerdeck.com

※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライドか、もしくはYouTubeで公開される(?)公式動画をご覧ください。

高集積コンテナホスティングにおけるボトルネックとその解法

@pyama86

GMOペパボ ホスティング事業部
ロリポップ! マネージドクラウド

テーマ

  • 7分であなたもコンテナーマイスター講座
  • はまった問題
  • 展望

テイクホームメッセージ

  • コンテナのボトルネックLinuxコマンドを駆使してあたりをつけて解決する
  • そのシステムコールが何をするのか、基礎的学習が必要(manを読んでわかるように)
    Linuxプログラミングインタフェース』

内容めも

  • ロリポップマネージドクラウド
    haconiwaを採用(mruby製。DSLで定義)

  • コンテナ = プロセス

    • namespace
      unshareによってnamespaceを分離できる。
    • chroot
      プロセスごとに見れるディレクトリを制限
    • cgroup
      プロセスごとにリソースを制限
    • capability
      プロセス・ファイルごとに権限管理
      cap_net_bind_service well-knownポートをlistenすることができる
      dockerで権限付けて起動してるときは、このcapabilityを全付けしてる
  • FastContainerアーキテクチャ

    • FastCGI:リクエストが来た時点でプロセスをフォークして処理、終わったらフォークしたものを殺す
    • nginxがコンテナ起動を確認、してなければ起動、起動したらコンテナで処理 ← リクエスト単位でコンテナを起動させるため
    • → オートスケールもハードウェア障害時対応も「次のリクエストから」実施される
    • → コンテナの高速起動が重要になる
  • 事象:監視コンテナのダウン

    • netns(network namespace)の追加に1分くらいかかっていた
    • ipコマンド:インタフェースの確認以外にもnsの管理にも使える。使っている
    • straceで調査、unshareがボトルネックらしい
    • perf <コマンド>:コマンドの中のどこが遅いのか、システムコールのレベルでわかる
    • deactivate_slab という処理
      Linuxソースコード読んでみた。Slabが12Gと肥大化し、ボトルネックになっているらしい
    • drop_caches:procの機能。キャッシュを開放する
  • 事象:コンテナが起動しない

    • 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

    • 自作のmrubyのAPIクライアントが重い(メモリ9Gくらいとってる)
    • 測定 → バックトレース → システムコール調査
    • mrubyの実装を読んでみて、文字列結合時のメモリのアロケーションを調べる
      c = a + b より a << b のほうがメモリ確保が小さくて済む
  • あるwordpressサイトにabかけたら別のサイトが落ちた
    コンテナなのに……?

    • NFSでファイルを開くとき、毎回ロックをかける
      小さいファイルをたくさん開くPHPと相性が悪い
      → OPcacheを使う

質疑

  • 直感的に、コンテナの起動はI/O等に比べて負荷にはならなさそうだけど
    うちではディスクI/Oは負荷にはなっていなかった
  • コンテナの起動速度(イメージによりそうだけど)
    過負荷状態でなければ1秒以内。起動直前の状態をメモリにのせて、メモリから起動する方法を検証中
  • iproute2入れ方
    makeインストール

感想

「測定 → バックトレース → ソース読む」の流れ、言うは易し行うは難しだ……。インフラ屋さんすごい……。
今まで現職でもうわからんって匙を投げてたところをこういうふうに調べて直していけたらどんなに良いだろう。
ものを言うのは知識と努力だ、がんばろって思わせてくれた。

あと何より面白かった!w
こんな高い技術あってこんな楽しく話す人と働けたらめっちゃ楽しいだろうなーって、こういう人たちと一緒に働けるくらい勉強と経験を積まないとなーって思った。

builderscon tokyo 2018 1日目に参加してきた

builderscon.io

行ってきたーーー!
全部のトーク聞けないのもどかしすぎたけど、選んだどのトークでも「知らなかった、を聞く」を圧倒的な衝撃をもって体験させてもらった。
エンジニアになってよかったって、身体にすとんとくる感覚があった。明日も楽しみ。

トーク

トークはこちら↓↓を拝聴した!
全部メモを取ってたんだけど、ちょっと内容に自信無いものもあるから抜粋で記事にあげた。

産業でガチ利用されるRaspberry Piの話

産業でガチ利用されるRaspberry Piの話 - builderscon tokyo 2018
by @kazuph さん
ラズパイほんとに使われてるんだ……! っていうレベルのガチ無知だったりしたんだけどちゃんと聞けたw
セキュリティとかログとか、webと同じテーマだけど違う制約の問題になっているところが個人的に面白かった!

hirapi.hatenablog.jp

開発現場で役立たせるための設計原則とパターン

開発現場で役立たせるための設計原則とパターン - builderscon tokyo 2018

by @shinpei0213 さん
あるあるすぎる課題を「『デザパタによる構造化』と『設計原則によるレビュー』とのサイクル」で鮮やかに解決しててテンションあがった!

hirapi.hatenablog.jp

事前知識なしで理解する、静的検査のいろは

事前知識なしで理解する、静的検査のいろは - builderscon tokyo 2018

by Kuniwak さん
スライドめちゃくちゃわかりやすかった! 構文解析をひとさらいするとソースコードとかエラーメッセージとかの見方が変わって面白いなーと。
これからRubyやるし、rubocop読もうというきもち。
これはスライドが完璧すぎて足すこと無い……w スピーカーの方がブログ記事上げていらしたので貼らせていただきます↓↓

orgachem.hatenablog.com

機械学習を用いず数学でゲーム内の需要予測をする

機械学習を用いず数学でゲーム内の需要予測をする - builderscon tokyo 2018

by @nessie_sesein さん
数学徒な名言がばんばん出てきて楽しかったw 黒い羊の寓話を体現するようなセッションだった。

hirapi.hatenablog.jp

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 さん
ちょっとこのトークの感動はまだうまく言語化できてない……。 メモだけ↓↓

hirapi.hatenablog.jp