volpe’s diary

フリーランスじゃなくなったプログラマ volpe が日々便利だなぁと感じたことを中心に綴るブログです

RailsDM 2019に参加してきた

https://railsdm.github.io/

現在お仕事として Rails に携わっているせいか、どのお話も単なる知的好奇心というだけではなく、自分ごととして明日から役立てようという気持ちで聞くことができた。 2日とも懇親会に参加出来て何人かの方とお話することが出来た。気づいたら20枚ほど持っていった名刺が無くなっていた。自分頑張った。 特にフリーランスの方と何人か知り合えたのは良かった。やはりこういう共通項があると話が弾みやすい。 あと、主催のカルパスさんにも挨拶できて良かった。

3トラックだったのでどのセッションを聞きに行こうか迷いまくったが、見れなかったセッションは今後動画が上がるそうなのでそちらで確認しよう。

以下、自分用メモ。

1日目

DHH

QA形式で松田さんが質問し、ビデオチャットの向こう側でDHHさんが答えるという形式。 ヒヤリング能力が低すぎてほぼ理解できず。。

ラク

  • Oracle cloud
    • AWSより安め
    • OracleDB を使うとメンテナンスコストが下がる

スポンサー

  • Repro
    • joker さん
    • Webサービスの下支え
    • vue vuex
    • フルリモートも応相談
  • STORES
  • Speee
    • @mrkn

アプリケーションを作るときに考える25のこと

  • @onkさん
  • フレームワークの価値
    • 難しいものを簡単にする
    • 価値がなさそうなものの品質を高める
  • 苦手なこと
    • 複雑な form
    • react 使えばいい。APIサーバ。Go使う。複雑化...
  • Slim
    • 閉じタグ不要
    • 1週間くらいで慣れる
  • SPAが当たり前品質になりかけている
  • ページャー
    • kaminari 一択
    • without_count
    • コードが面白い
  • 画像アップロード
    • active_storage
    • carrierwave
    • など
    • vips が人気
    • gem の GitHub の Dependents を読むと勉強になる
  • 削除フラグ
    • いろんなパターン
      • deleted_at
      • 削除テーブルに移動する
      • 削除ログ
        • 別ファイルに移動する
      • 削除済みユーザ
        • 個人情報のみ削除する
  • ランキング
    • boffin
    • 読みやすい
  • マークダウン
    • CommonMark で共通化
    • commonmarker が強くなってきた
  • 編集履歴
    • ActiveModel::Dirty
    • changed?

DevOps, Immutable Infrastructure, microservices そして Chaos Engineering

よしおりさん

  • Immutable infrastructure
    • Chad Fowler
    • サーバに入って手で書いていた時代から、不変にして入れ替える時代へ
  • Microservices
    • マーチンファウラー
    • 組織の構造と一致する
    • 急に流行り始めた
    • やるべきではないとき
      • 高速に構築できない場合
      • モニタリングできない場合
      • 素早くアプリケーションをデプロイできない場合
      • モノリシックなサービスでも必要なこと
  • Docker
    • Application も Immutable であることを強制
      • ファイルとか学習結果とか
  • Container Orchestration
    • アプリケーションの実行を抽象化
      • docker run
      • Docker で抽象化されているから
    • Microservice が70 とか超えてきたあたりで手を出すといい
    • Kubernetes
    • ecs
  • Microservice + Container
    • サービスが小型化
    • ポータビリティ向上
      • Rails runner を動かす環境の構築が楽になる
  • ServiceMesh
    • サービス間通信の抽象化
    • cookpad では Envoy を採用
      • アプリケーションごとに Envoy プロキシを配置
      • アプリケーションは localhost としか通信しない
      • Envoy で通信の流れがわかる
      • タイムアウトとかリトライの設定を Envoy で持てる
      • これまではアプリケーションで持っていた
  • Chaos Engineering
    • サーバを落とすことではない
    • サービスの定常状態を計測できるようにする
    • サービス間通信に異常があった場合にどうなるかを把握しておく
    • unknown - unknown から known - known にする

サーバーサイドエンジニアも知っておくべきフロントエンドの今

タケユー・ウェブ株式会社 板倉 達也さん

  • フロントの話

現在のエコシステム

  • TypeScript
    • vue は導入しにくい?
    • 最強というのはわかったので使うと良さそう
  • 宣言的 View
    • 仮想DOM
    • lit-html 知っておいて損はない
  • Editor
    • vscode + TypeScript + ESLing + Prettier
    • 書きやすすぎる、とのこと
  • Linter
    • ESLint の一強
  • Formatter
    • Prettier
    • prettier-ruby の開発が進んでいる
    • rubocop のスタイルが不要に
  • module bundler
    • webpack でいい
    • ライブラリ開発では Rollup が良さそう
  • Test
    • Jest
    • E2E は Jest + Puppeteer
    • 昔は Mocha, Chai, Karma, Jasmine など使っていた
    • Selenium は使わない方向になってる
  • 非同期処理
    • axios
    • ajax はもう古い
  • Web Components
    • polyfill を入れれば使える技術になっている。
    • 仮想DOM の下位互換でしかないので仮想DOMの代わりは厳しい
    • 外からデータを渡すのがしんどい

最近の注目の話題

  • CDN Worker
    • 正式な名前がないので仮称
    • エッジロケーション?
    • 熱いところ
      • BFF をエッジロケーションに置ける
      • フロントとバックエンドの仲介役
      • 認証とかSSRの交通整理を行う
      • BFFサーバー は node.js で立てることが多い
    • やりたいこと
      • SPA
        • FMP/SEO の最適化にSSRしたい
          • JS環境が必要
          • Rails だとできない、辛い。
      • RTT を高速化したい
        • 通信距離を短距離にしたい
        • エッジロケーションにおきたい
      • CDN Worker なら解決できそう

まとめ

  • モダンな開発手法が入ってきて落ち着いた状況。
    • ツールが選びやすくなっている
  • UXに直結するのでフロントエンド技術は必要

QA

  • MVC1を学ぶと良い。Flux の原型
  • youtubeGoogle のチャンネルを見る
  • webpacker を使うな
    • センスの悪いラッパー
    • フロントエンド知識の遅れに繋がる
  • elm は来るか
    • 来ないだろう

SQLQLは GraphQL にとってなんなのか

@yancya

サービスを成長させる「仮説検証文化」の作り方

@takatoshi-maeda

  • サービス開発は暗中模索
    • 現実と理想のギャップを埋めるには
    • 良い仮説検証
      • 問題の明確さ、期待効果の大きさ
        • 問題の理由まで探る
      • 点と線を用いた検証
        • クリックの絶対数だけでは測りにくい
        • アクセス数の増加などのノイズが乗りやすい
        • 一連のユーザー体験を示すストーリーを見ることでノイズの影響を受けにくくする
      • プロダクトに閉じない視野
        • 直接目で見て定性情報を増やしていく
    • チームでの取り組み方
      • Aglity
        • 細かく試行回数を増やしていく
        • 2週間とかでリリースして確認する
      • 長期中期短期でふりかえる
        • 大きい粒度のふりかえりは大きな仮説に対する検証ができる
        • マネージャだけでなく、チームを巻き込む
        • ユーザの反応、なんのための仕事なのかを考えるきっかけになる
      • 道具を充実させる
        • ふりかえりの情報を収集する
        • 分析ハードルを下げる
        • 中間データの生成
        • 複雑なクエリを必要としなくする
        • jyptyor notebook で可視化、など
        • ユーザのインタビュー,行動調査のデータを取る
        • 良いふりかえりをたくさん積み立てる

Rails な受託の会社で僕がやってること

三村さん

  • ミドルウェアやライブラリの選定
    • 運用や保守を誰がやるか
    • 決定を遅らせる
      • background job をどうする
        • sucker_punch を入れて ActiveJob で実現
        • 必要なら置き換える
  • コードレビュー
    • 考慮漏れのケース
    • パフォーマンス
    • 意図が伝わるコメント
    • コードを受け入れる覚悟ができれば Approve
    • コードレビューで大きな指摘をする必要がないようにする。事前に見るとか
    • コメントが多くなりすぎないようにする。辛い。側で話す。
  • プロジェクトを超えて利用できるようにする
    • 汎用的なものを gem に切り出す
    • 利用率は五分五分
    • esminc github に置いてある
  • 新しい人が入ってきた時
    • コードが書ける以前に、コミュニケーションができてない
    • わからないことを伝える
      • 問題を小さく分解
      • 質問で意識してないかった部分をあぶり出す
      • 使ってる用語の確認
    • 見積もりと計画
      • 見積もれば、どうやればできそうかわかる
      • 計画を立てることでアラームのタイミングなどを意識してもらう
  • 仕事を楽しくやっていく

    • 業務の10%で別のことを
    • 新しいことをやっていく。アップデートのタイミングを考える
  • Dave thomas

雑 almost microservices

ujihisa tatsuhiro

  • Quipper
  • Release の話
    • Modify が重い
    • エッジケースの問題が本番で起きる
    • 意図してない依存関係がある
    • 本番でしか起きない問題
    • テストを書け
      • 実装とテストの両方を間違うこともある
      • コストが掛かる
    • 安心してリリースしたい
      • Pull request ごとに実環境が立ち上がる
      • プロにテストを任せる
      • リリースを分割する
        • 機能で分割する
          • MVP でリリース
          • やりたいことを実現する最低限の機能
        • ユーザで分割する
          • 特定のユーザのみ
          • 特定ユーザをDBに持っておく
          • まずい時にユーザを0にすればいい
          • コードはパターン化しちゃう
      • ロールバックしたい
        • これまではリバートコミット
        • ダークローンチで実現
        • 例外が起きたらダークローンチ自体を打ち消す。自己修復。ブレーカー

Railsアップグレード百景

@r7kamura

  • Rails のアップグレード
    • 社内のすごい人がやるイメージ
    • 誰でもできるということを言いたい
    • 作業前にやること
      • issue のラベルを決めておく
        • Rails 5.0, Rails 5.1
        • 1アップグレードでPRが100件くらいになる
      • 検証環境
      • 開発環境
        • テストが役に立つ
        • PR ごとに検証環境が用意されると便利
        • ダミーデータの拡充
      • CIの整備
        • 高速化しておく。 CircleCI で従量課金するといい
        • migraion のテストが役立った
        • 不要なログの整理。必要な警告が見えなくなる
        • テスト結果の集計。減っていくことが精神的支柱になる
      • Rubocopの整備
        • Gemfile 内の gem をアルファベット順にする
          • 見つけやすい、コンフリクトしにくい
        • Rails カテゴリの Cop を有効化
    • アップデート
      • bundle update で最小限に上げていく rails と必須のもののみとか。
      • master にこまめに取り込んでいく
        • 両方のバージョンで動くコードをプロダクションコードに入れつつデプロイもする
        • 最終的には Gemfile のみを入れれば良いのが理想
        • 暫定対応として Railsのバージョンで分岐を書くこともある
      • パッチバージョンは一気にあげるべき。途中のバグが治っていることがある
      • 他にも色々あるけど、、、大変そう。。

毎日の開発に役立つRailsプラグインづくりの秘訣

@amatsuda

  • なぜ gem を作るのか
    • 現場で解決したい課題があるから
    • とにかく単機能にする hevens_door
      • ドキュメントの代わりにアニメgif を書いた
    • hocus_pocus
      • WikiName っぽい感じ
      • ブラウザ内で rails のモデルを作っていける
      • やる気がなくなった
      • 実際に課題を解決しないと続かないということがわかった
    • 現場の課題: ER図が見たい
      • migration をブラウザ上で出来る
      • erd
      • まだ未完成。誰か助けて
    • 現場の課題: 画面遷移が見たい
      • round_about
      • テストの結果から画面遷移を取得
      • カバレッジの表示にもなる
    • 現場の課題: アップデートが怖い
      • cookpad
      • html差分を前後で比較する
    • 現場の課題: haml が覚えられない
      • himl
  • 現場の問題はいたるところにある
  • gem の名前
    • 一般名詞は危ない

まだ40代後半のプログラマの話、あるいは50代プログラマについて考える

@takahashim

  • 35才プログラマー定年説
    • なんのためにプログラミングをしているのか、という問い
    • 選択肢があってもいいかも
      • プログラミングが好き
      • プロダクトが好き
    • 後進がいない現場に行く
      • Rails が武器になる

2日目

全体がいい感じになるために、私たちRailsをホームにするWeb技術者が出来ること

@moro SMS

  • Rails
    • 単一のRailsアプリで完結しなくなってきた
    • 外部連携するのが日常
      • 要素技術の専門化
      • システムが分断
    • 分割されたものを合流してユーザに届ける
  • いろんな職能の成果をWebアプリに合流させる
    • いい感じに合流できるように
    • ユーザに価値を届ける
  • 全体をいい感じに
    • 管理画面
      • データのCRUDだけじゃ足りないことが多い
      • ちゃんと会話してソフトウェアにする
    • キャリアパス
      • サービス志向エンジニア
      • 技術志向エンジニア
      • 仲良く
    • みんなの仕事を合流させる
      • コミュニケーションの場を作る
      • 楽しくなるインターフェース
      • 価値の総和を大きくするために技術を使う
      • 自分1人でたどり着けない場所に行く
      • 面白がって楽しもう
  • QA
    • 良い感じが自明でない時
      • スモールスタート
      • まずはやってみる
      • 小さく試して振り返る

入門名前

マチマチ藤村さん twitter: ffu github: fujimura

  • プログラマは日々名前を考える
  • 名前は便利
    • 中身をよく知らずに再利用できる
    • Rails の仕組みをよく知らなくても使っている
    • 再利用できると生産性が上がる
  • プログラムに置ける名前の意味は「振る舞い」
  • 名前が悪いと
    • 理解が難しい
    • 誤解する
    • 生産性が落ちる
  • check_login
    • どちらの状態が真なのかわかりにくい。コンテキスト依存
    • check はやばい。
  • 無駄に長い名前

    • シンプルな名前に置き換える
    • check_paid
      • paid? + add_error_if_not_paid
    • user
      • 具体的な名前をつける
  • 辞書.app を使うといい

Roda and Rails

y-yagi

  • フレームワーク Roda
    • Sinatraの仲間
    • controller と routes を混ぜて書くイメージ
    • 速い
    • bench-micro
    • アラカルト
    • プラグインを選択して実装する
  • Rails と組み合わせられないか
    • Rails ほどの router の機能は無いが、graphQL だと十分間に合う
    • graphQL のエンドポイントを Rails に mount
  • ベンチマーク wrk

  • first step Roda. pdfで読める

SmartHRでの最初の1年

risacan

  • IMHO
    • できれば治してね。強制では無い
  • 取り組み
    • KPTの目的がなさそうで提言。別のやり方になった
    • 新人の視点はすぐ消えるので言ったほうがいい
    • 営業さんにGitHubを体験してもらった。開発でやってることを理解してもらう。
    • 営業さんと slack を繋いだ。エンジニアに話していいんだ
  • 技術顧問
    • 解決方法の相談
    • 壁打ち相手。良さそう、無理そう。
    • チームが手が届いていないことをお願いする
    • 先輩に聞きにくいことを聞く
    • 煮詰まった時の相談。命名とか。
    • 新しい文化の導入
      • 他の現場で上手くいったことを導入してくれる
  • モブプロ
    • テストの書き方
    • 障害対応の共有
      • Sentryの見方とか

言わず語りの個人事業主

@yoshuki

  • Saitama.rb
  • なぜ個人事業主
    • 会社がなくなった
    • いずれはやろうと思っていた
  • 営業
    • ブログを書いておいて話のネタになった
    • 懇親会でぼっち。少数のイベントに参加して知り合いを増やしていった
    • 名刺にSNSとアイコン
    • 懇親会では必ず名札
    • 自己紹介ペーパー
      • やってきたこと、やりたいこと
      • A4一枚
      • 読んでもらえる
  • 仕事
    • デスマより0がいい。時間があるので勉強や営業活動を行う
    • 価値を認めてもらえる人がいる
    • 複数同時に仕事を行う。リスクヘッジ
      • 持ってるスキルでできる仕事
        • 動いているシステムの保守など
      • 持っていないスキルでやる仕事
        • 勉強の必要がある
  • 組織
    • 自分で意識しないと何もイベントが起きない
      • 世間との意識がずれてしまう恐れがある
    • 経理などの目が自分しかいない
      • ツールなど使って忘れないように
  • 事務
    • この仕事だと経費が少ない
    • お金の仕組みが詳しくなる
  • 時間
    • お金になることをやってれば労働時間
  • お金
    • 欲しいものが仕事に使えば経費になる
    • お金のことばかり考えて新しいことができなくなるのは避ける
    • 入金が増えるが出金も増えるので気をつける
  • これから

Rails の正体

とても興味深い話だったけど、立ち見だったのでメモ取れなかった。。 Rails の仕組みが改めて良く理解できる内容だった。

  • 速くて綺麗は中規模で崩壊する
  • モデルにバリデーションとコールバックが入っている
    • 速くて綺麗のトリック
    • model層に詰め込みすぎ
      • 小規模だと成り立つ。スタートアップとか
  • 条件付きバリデーションやコールバックが入ってきたら、複数のユースケースからモデルを触っているサイン

    • 2つの解決策
      • ユースケースに依存したモデルを触る層を設ける
      • 規模が大きくなってきたらサービスを分割する
  • hanamiというフレームワークはクリーンアーキテクチャを実現している

    • rails に比べると model の役割を複数の層で分割している

Analyze Rails CI

@mtsmfm Quipper

  • rails/rails のCIを分析してみた
  • なんか落ちてるけど関係ないからマージして
  • TravisCI からデータを取得して BigQuery へ保存するアプリ
    • heroku sheduler で cron 的なことをやる
    • embulk
  • この辺から難しくてメモ取れず。。

巨大なモノリシック Rails アプリケーションのマイクロサービス化戦略

hokaccha

  • クックパッドのコードベース 100万行
    • テストが遅い。解決
    • アップデートが困難
    • などなど
  • 取り組み
    • コード削除
    • コンテナ化
      • WebとAPIを分割
      • Docker で動かす
    • システム分離
      • Microservice化
        • システム境界を間違えると大変
        • コード削除だけでは限界があるので仕方なく進めている
        • 組織で切るのも難しい。変わりやすいから。
        • データの切れ目で分けている
  • 成果
    • 検索システム
      • Solr.
      • 上手く分割できている
      • GRPC に移行している
    • 料理きろく
    • モバれぴ
      • 最新の技術で置き換え
      • 移行
        • いったん新サーバーに全リクエストを受ける
        • 未実装な機能を 503 を返す
        • nginx で旧サーバにリクエストを投げ直す
        • レイテンシーは増えるが誤差レベル
    • Webフロント
      • レガシーな技術
        • coffee
        • zepto
        • 移行はなんとかんなる
      • haml, sass
        • Micro Frontend
        • UIコンポーネントごとにチームを分ける
        • ページ単位(コントローラー)で分ける
      • 課題
        • ページを跨いだ施策
        • cookie,sessin,など
        • UIの統一感
  • サービスの成長のためには目を背けてはいけない