ggdG:wq

技術的な事とか日記とかフワッと書く

Builderscon 2018 に参加した

公式サイト

buildersconは「知らなかった、を聞く」をテーマとした技術を愛する全てのギーク達のお祭りです。

Builderscon 2018に前夜祭から3日間参加してきた。 セッション数が多いので印象に残ったものを中心にメモと感想を...

全体的な感想とか

会場とか部屋サイズの事

  • 去年よりも人が多く、見ようと思ったセッションが人数オーバーで見れないということが多かった
    • 直前のセッションが長かったりすると次の部屋が埋まっていて見れないというのがあった
    • 諦めて他のセッション聞きに行ったらそこも面白いのであまり気にはならなかった
      • 見れなかったものも後日動画配信があるはずだからOKというのもある
    • 最終日のランチセッションに入れなかったのは残念 (お弁当食べたかった)

自作キーボード沼に引きずり込まれた

  • 前夜祭で自作BLEキーボードのその後を聞く → 欲しくなる
  • 最終日に自作キーボードのセッションを聞きに行く → 更に欲しくなる
  • 最終日のLTでも自作キーボードの話を聞く → 我慢できなくなる
  • 帰りの電車でHelix注文した

初日(前夜祭)

IoT・謎ガジェット

この日帰りながら2016年の "Bluetooth キーボードの作りかた" のスライドを見て自作キーボードやりたい熱が上がった

2日目

オープニング

凝ったムービーで注意事項とかの説明があった

"The Stanley Parable"というゲームへのオマージュらしい builderscon tokyo 2018 オープニング作成の裏側

声優さんも同じ人らしいのですごい凝ってる

ランチセッション (サイボウズ株式会社): Kubernetes で実現するインフラ自動構築パイプライン

  • 物理サーバ1000台
  • 自動化の流れ(よくあるパターン)

    • 人が手で手順書に沿ってやる
    • オペレーション辛い
    • Pythonスクリプトにして自動化
    • スクリプト実行の前提条件がが厳しくなってくる
      • 手順そのままの自動化は脆いシステムになる
        • 手順が少しでも異なればそれは正しい処理じゃなくなる
  • どうすれば良いのか

    • 理想状態への収束
      • ゴールとなる状態を与えると、現在の状態との差分を抽出し必要な手順を行うという考え方
        • →実際は複数ホスト間の調停や既存スクリプトと合わせるのが難しく、やりたくてもやれなかった
  • AWS以降に合わせて負債の解消→スケールするように

  • USにkintoneを展開するにあたりAWS上に構築。これまでの技術的負債を解消し、スケールするインフラにしたい

  • k8s上に構築した理由

    • 手順でなく、理想状態を与えてデプロイできる
    • NetworkやDBはCloudFormation、AP serverやLBはk8sでみることにより、フルスタックで理想状態への収束ができる
  • 使われていない自動化は壊れていく
    • ゼロから環境が作れることを保証するためにgit pushするたびにCIで開発環境に適用
    • 一日一回はCIでVPCから削除してフル構築

JavaCardの世界

  • 普段自分が認識しなさそうな範囲の話が聞けたのが面白かった
  • 会場でもJava Cardの存在を知っている人が数人, Java Card触ったことのある人0
  • なるほどーとはなったが、使いどころの無さそうな知識を得られた

lld − 開発ツールの主要コンポーネントの1つをスクラッチから作成した話

  • ゲスト無し Turing Complete FM 生放送(スライド付き)って印象
  • "2回書くことで1回目の経験を活かしてより良いコードを書く"という話はなるほど大事とは思うがなかなか出来ないよなと感じた
  • スライド公開されているか探してみたが見当たらなかった

  • 早くてシンプルなコードを書くために

    • 2回書く(1回目の経験を活かす)
      • 試行錯誤した上でしっくりくるものを試してみる
      • 良さそうなものをいくつか試してみる
      • 最終的には勘
    • 最適化する箇所を最小に留める(大半は読みやすさを重視する)
    • プロジェクトオーナーが責任を持ってコードをきれいに保つ
  • 速いプログラムはコードが速いわけではなくやりたいことがスムーズにできるようになデータ構造は速い

    • データ構造が先、コードが後
    • 良いデータ構造ができれば自ずと速いコードになる

3日目

なぜエンジニアはパフォーマンス計測しないのか

「やる気を出すのではなくやる気が出る状態を作る」いい話

なぜ私はキーボードを作るのか

個人的に今年のBuildersconで最も影響を受けたセッション

このセッションのせいで自作キーボード沼に引きずり込まれたといっても過言ではない

恐らく最も長い時間触っているインターフェイスといっても過言ではないので拘るのは大事

とりあえずHelixを作っているので、完成したらブログ書きます。