RailsDM 2019に参加してきた
現在お仕事として Rails に携わっているせいか、どのお話も単なる知的好奇心というだけではなく、自分ごととして明日から役立てようという気持ちで聞くことができた。 2日とも懇親会に参加出来て何人かの方とお話することが出来た。気づいたら20枚ほど持っていった名刺が無くなっていた。自分頑張った。 特にフリーランスの方と何人か知り合えたのは良かった。やはりこういう共通項があると話が弾みやすい。 あと、主催のカルパスさんにも挨拶できて良かった。
3トラックだったのでどのセッションを聞きに行こうか迷いまくったが、見れなかったセッションは今後動画が上がるそうなのでそちらで確認しよう。
以下、自分用メモ。
1日目
DHH
QA形式で松田さんが質問し、ビデオチャットの向こう側でDHHさんが答えるという形式。 ヒヤリング能力が低すぎてほぼ理解できず。。
オラクル
スポンサー
- 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
- 情熱プログラマー
- サーバに入って手で書いていた時代から、不変にして入れ替える時代へ
- Chad Fowler
- Microservices
- マーチンファウラー
- 組織の構造と一致する
- 急に流行り始めた
- やるべきではないとき
- 高速に構築できない場合
- モニタリングできない場合
- 素早くアプリケーションをデプロイできない場合
- モノリシックなサービスでも必要なこと
- Docker
- Application も Immutable であることを強制
- ファイルとか学習結果とか
- Application も Immutable であることを強制
- Container Orchestration
- アプリケーションの実行を抽象化
- docker run
- Docker で抽象化されているから
- Microservice が70 とか超えてきたあたりで手を出すといい
- Kubernetes
- ecs
- アプリケーションの実行を抽象化
- Microservice + Container
- サービスが小型化
- ポータビリティ向上
- Rails runner を動かす環境の構築が楽になる
- ServiceMesh
- 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
- 非同期処理
- axios
- ajax はもう古い
- Web Components
- polyfill を入れれば使える技術になっている。
- 仮想DOM の下位互換でしかないので仮想DOMの代わりは厳しい
- 外からデータを渡すのがしんどい
最近の注目の話題
- CDN Worker
まとめ
- モダンな開発手法が入ってきて落ち着いた状況。
- ツールが選びやすくなっている
- UXに直結するのでフロントエンド技術は必要
QA
- MVC1を学ぶと良い。Flux の原型
- youtube の Google のチャンネルを見る
- Google IO
- webpacker を使うな
- センスの悪いラッパー
- フロントエンド知識の遅れに繋がる
- elm は来るか
- 来ないだろう
SQLQLは GraphQL にとってなんなのか
@yancya
- SQLQL とは
- https://qiita.com/yancya/items/4b7979d83cbf6af9b819
- サーバに SQL を投げたい
- sqlql の github リポジトリでサンプルアプリケーションを立てられる
- CTE (common table expressions)
- WITH 句であらかじめ見せたくないカラムをフィルタリングできる
- Relation to Object
- JSONAGG
- JSON_TO_RECORD
- 途中わからなすぎてメモ取れなかった。。
サービスを成長させる「仮説検証文化」の作り方
@takatoshi-maeda
- サービス開発は暗中模索
- 現実と理想のギャップを埋めるには
- 良い仮説検証
- 問題の明確さ、期待効果の大きさ
- 問題の理由まで探る
- 点と線を用いた検証
- クリックの絶対数だけでは測りにくい
- アクセス数の増加などのノイズが乗りやすい
- 一連のユーザー体験を示すストーリーを見ることでノイズの影響を受けにくくする
- プロダクトに閉じない視野
- 直接目で見て定性情報を増やしていく
- 問題の明確さ、期待効果の大きさ
- チームでの取り組み方
- Aglity
- 細かく試行回数を増やしていく
- 2週間とかでリリースして確認する
- 長期中期短期でふりかえる
- 大きい粒度のふりかえりは大きな仮説に対する検証ができる
- マネージャだけでなく、チームを巻き込む
- ユーザの反応、なんのための仕事なのかを考えるきっかけになる
- 道具を充実させる
- ふりかえりの情報を収集する
- 分析ハードルを下げる
- 中間データの生成
- 複雑なクエリを必要としなくする
- jyptyor notebook で可視化、など
- ユーザのインタビュー,行動調査のデータを取る
- 良いふりかえりをたくさん積み立てる
- Aglity
Rails な受託の会社で僕がやってること
三村さん
- ミドルウェアやライブラリの選定
- 運用や保守を誰がやるか
- 決定を遅らせる
- background job をどうする
- sucker_punch を入れて ActiveJob で実現
- 必要なら置き換える
- background job をどうする
- コードレビュー
- 考慮漏れのケース
- パフォーマンス
- 意図が伝わるコメント
- コードを受け入れる覚悟ができれば Approve
- コードレビューで大きな指摘をする必要がないようにする。事前に見るとか
- コメントが多くなりすぎないようにする。辛い。側で話す。
- プロジェクトを超えて利用できるようにする
- 汎用的なものを gem に切り出す
- 利用率は五分五分
- esminc github に置いてある
- 新しい人が入ってきた時
- コードが書ける以前に、コミュニケーションができてない
- わからないことを伝える
- 問題を小さく分解
- 質問で意識してないかった部分をあぶり出す
- 使ってる用語の確認
- 見積もりと計画
- 見積もれば、どうやればできそうかわかる
- 計画を立てることでアラームのタイミングなどを意識してもらう
仕事を楽しくやっていく
- 業務の10%で別のことを
- 新しいことをやっていく。アップデートのタイミングを考える
Dave thomas
- oedorubykaigi2012 の話
- 良い行動をしよう
- https://magazine.rubyist.net/articles/0039/0039-MetPragdaveAtAsakusarb.html
雑 almost microservices
ujihisa tatsuhiro
- Quipper
- Release の話
- Modify が重い
- エッジケースの問題が本番で起きる
- 意図してない依存関係がある
- 本番でしか起きない問題
- テストを書け
- 実装とテストの両方を間違うこともある
- コストが掛かる
- 安心してリリースしたい
- Pull request ごとに実環境が立ち上がる
- プロにテストを任せる
- リリースを分割する
- 機能で分割する
- MVP でリリース
- やりたいことを実現する最低限の機能
- ユーザで分割する
- 特定のユーザのみ
- 特定ユーザをDBに持っておく
- まずい時にユーザを0にすればいい
- コードはパターン化しちゃう
- 機能で分割する
- ロールバックしたい
- これまではリバートコミット
- ダークローンチで実現
- 例外が起きたらダークローンチ自体を打ち消す。自己修復。ブレーカー
Railsアップグレード百景
@r7kamura
- Rails のアップグレード
- 社内のすごい人がやるイメージ
- 誰でもできるということを言いたい
- 作業前にやること
- アップデート
毎日の開発に役立つRailsプラグインづくりの秘訣
@amatsuda
- なぜ gem を作るのか
- 現場で解決したい課題があるから
- とにかく単機能にする hevens_door
- ドキュメントの代わりにアニメgif を書いた
- hocus_pocus
- WikiName っぽい感じ
- ブラウザ内で rails のモデルを作っていける
- やる気がなくなった
- 実際に課題を解決しないと続かないということがわかった
- 現場の課題: ER図が見たい
- migration をブラウザ上で出来る
- erd
- まだ未完成。誰か助けて
- 現場の課題: 画面遷移が見たい
- round_about
- テストの結果から画面遷移を取得
- カバレッジの表示にもなる
- 現場の課題: アップデートが怖い
- cookpad
- html差分を前後で比較する
- 現場の課題: haml が覚えられない
- himl
- 現場の問題はいたるところにある
- gem の名前
- 一般名詞は危ない
まだ40代後半のプログラマの話、あるいは50代プログラマについて考える
@takahashim
2日目
全体がいい感じになるために、私たちRailsをホームにするWeb技術者が出来ること
@moro SMS
- Rails
- 単一のRailsアプリで完結しなくなってきた
- 外部連携するのが日常
- 要素技術の専門化
- システムが分断
- 分割されたものを合流してユーザに届ける
- いろんな職能の成果をWebアプリに合流させる
- いい感じに合流できるように
- ユーザに価値を届ける
- 利用者
- 開発者
- 関わる職能の人たち
- フラクタル構造
- 全体をいい感じに
- QA
- 良い感じが自明でない時
- スモールスタート
- まずはやってみる
- 小さく試して振り返る
- 良い感じが自明でない時
入門名前
マチマチ藤村さん twitter: ffu github: fujimura
- プログラマは日々名前を考える
- 名前は便利
- 中身をよく知らずに再利用できる
- Rails の仕組みをよく知らなくても使っている
- 再利用できると生産性が上がる
- プログラムに置ける名前の意味は「振る舞い」
- 名前が悪いと
- 理解が難しい
- 誤解する
- 生産性が落ちる
- check_login
- どちらの状態が真なのかわかりにくい。コンテキスト依存
- check はやばい。
無駄に長い名前
- シンプルな名前に置き換える
例
- check_paid
- paid? + add_error_if_not_paid
- user
- 具体的な名前をつける
- check_paid
- 辞書.app を使うといい
Roda and Rails
y-yagi
SmartHRでの最初の1年
risacan
- IMHO
- できれば治してね。強制では無い
- 取り組み
- 技術顧問
- 解決方法の相談
- 壁打ち相手。良さそう、無理そう。
- チームが手が届いていないことをお願いする
- 先輩に聞きにくいことを聞く
- 煮詰まった時の相談。命名とか。
- 新しい文化の導入
- 他の現場で上手くいったことを導入してくれる
- モブプロ
- テストの書き方
- 障害対応の共有
- Sentryの見方とか
言わず語りの個人事業主
@yoshuki
- Saitama.rb
- もくもく会
- 時々会える場があるのがいい
- なぜ個人事業主
- 会社がなくなった
- いずれはやろうと思っていた
- 営業
- ブログを書いておいて話のネタになった
- 懇親会でぼっち。少数のイベントに参加して知り合いを増やしていった
- 名刺にSNSとアイコン
- 懇親会では必ず名札
- 自己紹介ペーパー
- やってきたこと、やりたいこと
- A4一枚
- 読んでもらえる
- 仕事
- デスマより0がいい。時間があるので勉強や営業活動を行う
- 価値を認めてもらえる人がいる
- 複数同時に仕事を行う。リスクヘッジ
- 持ってるスキルでできる仕事
- 動いているシステムの保守など
- 持っていないスキルでやる仕事
- 勉強の必要がある
- 持ってるスキルでできる仕事
- 組織
- 自分で意識しないと何もイベントが起きない
- 世間との意識がずれてしまう恐れがある
- 経理などの目が自分しかいない
- ツールなど使って忘れないように
- 自分で意識しないと何もイベントが起きない
- 事務
- この仕事だと経費が少ない
- お金の仕組みが詳しくなる
- インボイス制度が怖い
- 時間
- お金になることをやってれば労働時間
- お金
- 欲しいものが仕事に使えば経費になる
- お金のことばかり考えて新しいことができなくなるのは避ける
- 入金が増えるが出金も増えるので気をつける
- これから
Rails の正体
とても興味深い話だったけど、立ち見だったのでメモ取れなかった。。 Rails の仕組みが改めて良く理解できる内容だった。
- 速くて綺麗は中規模で崩壊する
- モデルにバリデーションとコールバックが入っている
- 速くて綺麗のトリック
- model層に詰め込みすぎ
- 小規模だと成り立つ。スタートアップとか
条件付きバリデーションやコールバックが入ってきたら、複数のユースケースからモデルを触っているサイン
- 2つの解決策
- ユースケースに依存したモデルを触る層を設ける
- 規模が大きくなってきたらサービスを分割する
- 2つの解決策
hanamiというフレームワークはクリーンアーキテクチャを実現している
- rails に比べると model の役割を複数の層で分割している
Analyze Rails CI
@mtsmfm Quipper
- rails/rails のCIを分析してみた
- なんか落ちてるけど関係ないからマージして
- TravisCI からデータを取得して BigQuery へ保存するアプリ
- heroku sheduler で cron 的なことをやる
- embulk
- この辺から難しくてメモ取れず。。
巨大なモノリシック Rails アプリケーションのマイクロサービス化戦略
hokaccha
- クックパッドのコードベース 100万行
- テストが遅い。解決
- アップデートが困難
- などなど
- 取り組み
- 成果
- サービスの成長のためには目を背けてはいけない