builderscon tokyo 2017に参加してきた[day 2]

buildersconに参加してきました。

builderscon.io

前身のYAPC 2015から2年ぶりの参加になります。

以下気になった部分のメモを残しておきます。 ただし聞き間違い等も多くあると思うので、スライドや後日公開される(はずの)ビデオ等を見るほうがよいと思います。

OSS開発を仕事にする技術

builderscon.io

  • 成長が見込めるOSS
    • テーマが明確であること
    • コミュニティが強いこと
      • 具体的にはstackoverflow, reddit, github, 等のコミュニティ
  • ビジョンと基礎があればエンジニアは集まる
  • 複数社からエンジニアが参加していることが重用

  • OSSの開発プロセスに決まった型がない

    • 見つかったものの一つがXDSD
    • XDSD(eXtremely Distributed Software Development)

  • Kubernetes on AWSを採用している企業

  • 自社にあったOSSの選定の仕方
    • ニッチでよい(一番有名なものがよいわけではない)
    • 開発が活発なプロジェクトを選ぶ
      • PRを投げてもmergeされなきゃ意味がない
  • OSS開発のアンチパターン
    • OSS自体で一儲けしようと考えてしまう

ランチセッション A 株式会社VOYAGE GROUP

  • Ajito.fmの公開収録？的な
  • お弁当ごちそうさまでした。 ajito.fm

ランチセッションB Momentum株式会社

  • 広告詐欺や不適切な場所に広告が表示されるのをいかに防ぐかの話

真のコンポーネント粒度を求めて

真のコンポーネント粒度を求めて - builderscon tokyo 2017

  • Atomic Design
    • デザインシステムを作り、ページを作るという流れ
    • 細部から始めて全体を考え、細部を見直せ
  • Enduring CSS(ECSS)
    • コンポーネントの抽象化を避ける
      • 抽象化: OOCSS的なアプローチ
    • いつでも捨てられることを意識する
  • 抽象化を避ける
    • 似たようなUIパーツが登場しても、別の機能の中で使われるのであればそれは別物
    • 同じような見栄えでもそれぞれのコンポーネントであれば
    • コピペで作っておけば、該当部分のコードをすぐに消すことができる
    • コードの捨てやすさが長期運用では実は一番重要
  • 実際の事例の紹介
    • CSS設計はデザインカンプとコードだけ眺めていても解決はしない
    • 前工程、後工程などを考慮し、ワークフローに応じて考える
  • 質疑
    • ECSSを採用してもレスポンシブのためのGridなどは共通になると思う、他に共通化を行ってもいい部分はあるだろうか？
      • Gridは発表者も共通化すると思うとのこと。共通度と変更の可能性を考慮して決める

Goで実装する軽量マークアップ言語パーサー

builderscon.io

  • 軽量マークアップ言語

    • Markdown, Textile, はてな記法
    • HTMLやXMLとプレーンテキストの中間にある

  • はてな記法

    • org-modeとちょっと似た文法
    • 実装が色々ある
      • 実装の数だけ仕様が存在する
      • 仕様を知るにはPerlと正規表現を読み解く必要がある

  • 手頃な実装がない

    • Perl以外で書かれたアプリケーションでも使いたい

  • 軽量マークアップ言語は難しい

    • 人間にとっての読み書きしやすさと、機械にとっての読み書きしやすさは異なる
    • 厳格な文法規則に従わせるパーサーより誤り訂正してくれる方が実用的なのでは？

  • 軽量マークアップ言語のパーサーは個人プロジェクトで取り組むにちょうどいい難度

    • 小さい機能を積み上げられる
    • 使用が厳格
    • 例えば： JSONのパーサーを書いてみる
    • 次に字句解析、構文解析を自作

RDBアンチパターン リファクタリング

builderscon.io

  • DB設計はは積み木のようなもので三角錐の上に球をのせるようなマジカルな設計にしてしまうとニッチもサッチもいかなくなる
  • チーズなのか腐った牛乳なのかを見極める
    • 本当に改修が必要かどうか
    • 腐った牛乳は生死に関わる
    • 時間とともに腐っていく

DBリファクタリングの準備を整える

  • 抽象化: 永続化層を整える
  • モニタリング
    • テストコードではパフォーマンスが監視できない
    • 負荷テストでは人間が想定したテストしか書けない
  • テスト: 品質を担保する
    • テストコードはコード品質の見える化
  • 覚悟
    • サービス停止の壁
    • 0に近づけることはできるが、0には出来ない
    • 政治的な力が必要
    • 自分を守るために自動化（人がアサインされづらいので、だからこそ自動化)
  • これらの大変な作業をする価値があるのか？
    • 腐った牛乳なのか、チーズなのかの判断
  • memo1, memo2がダサい
    • ときには我慢して使ってもらうのでもいいかも
  • 対象を選定し、移行期間を決める
    • 移行期間が必要
    • 移行前と移行後で両方正しく動く必要がある
  • 移行期間についてはコメントに入れておくとエンジニアが気付ける
    • /* 2018/04に削除します */ とか
  • 移行期の戦略
    • Triggerを使う
    • その後Triggerと旧カラムを消す
  • 変更前、変更中、変更後のテストを行う
    • DB変更の手順は多くの手数が必要になる
  • 現場で働くあなたへ
    • 施行前に戻せる事
    • 以降中は過去の状態を保持すること
    • 小さい変更を長いスパンで繰り返す
      • 影響範囲が広いので切り分けをしやすくすることが重用
      • 似た事例Model層
    • 兎にも角にもテストとリファクタリングが必要
    • DBの機能をうまく活用する
      • MySQL: 仮想列
    • コミュニティを上手く使用する
  • まとめ
    • DBの寿命はAppより長い
    • 一度使ったDBは消せない
      • 定期的なメンテナンスが必要
      • DBの肥大化と共に問題も大きくなる
      • Alterが終わらない、小さいときはカラム名変えるのも簡単だったけど、レコード数が大きくなると容易にはできなくなる
    • DBを守ることはサービスやチームを守ることに繋がる
      • 周囲の経験談を学ぶ
      • 積極的にコミュニティを利用する
    • RDBについては、知識が長期的に生きてくる
    • 手を動かした人だけが世界を変える