6/27 に「Rubyセミナー 大阪（2025年6月）」というイベントがあったので行ってきた。
関西Ruby会議2025の前日だったのでついでに…じゃなくて、どちらかというとRubyセミナーがメインで関西Ruby会議の方がついで的な気持ち。
目的は忍者式テストの関さんの話。自分が最初に忍者式テストの話を聞いたのはたぶん 2008年のデブサミだったと思うんだけど、当時もすごいと思ったけど今聞いてもやっぱりすごい。 忍者式テストって関さんのチーム以外でも再現可能なんだろうか。
奥本さんの話もよかった。
以下は雑に取ったメモ。ちゃんと書こうと思ったけど、やらなそうなのでメモのまま公開。
『逆アルファシンドロームとAIコーディング』 まつもとさん
- アルファシンドローム
- 飼い犬が自分がリーダーだと思い込む
- 逆アルファシンドローム
- 新技術導入→人間が新技術の配下になってしまう
- 人が自ら配下になってしまう
- matz が考えた概念
- 「AIのための雑用」が増える
- 人間が楽しかった部分が失われる
- AIのためにコーディングを諦める人がいる
- AIのために働く
- 交渉とか営業とか分析とか品質保証とか
- 人間を排除してはいけない
- レトロニム
- 新しい概念により言葉の意味が変わってしまう
- コーディング→ヒューマンコーディング
- 天然コーディング？
- robo dev わりと良い
- たまに落ちる
- 20Mトークン/日
- コーディング能力的には gemini の方が賢い
- ペアプログラミンを彷彿
- 非同期にできるので楽
- 新しいやり方に挑戦するのは楽しい
- そのうち飽きるんじゃないか
- どんどん賢くなってはいる
- これから学ぶ人がどうやって知識を得るか
- 初期学習には有効
- 何回聞いても怒らない
- いい先生
- 中級以降にどうAIを活用するか
- 知識や経験をどう学ぶか
- AIがもっと賢くなったときに人間の関わり方
- 写真と絵画 → 生き残ってる
- 馬車と自動車 → なくなった
- プログラミングはどっち？
『XPとテスト ー 忍者式テスト25年の実践から』 関さん＆美和さん
- XP
- ポストソフトウェア工学
- 極端
- 人はミスをする
- 早くミスがバレるようにする
- 忍者式テスト
- 反復開発のすごくいいやつ
- 実はただのXP
- XPは極端さをさらに上げる仕組みが内在される
- うまくいったテスト→新しい問題を見つけられたテスト
- 失敗したテスト→何も問題を見つけられなかったテスト
- テストは本来手動テスト
- 自動化テスト
- 1000回グリーンになっても1bitもよくならない
- 自動化する過程での実装の洗練の方に価値がある
- 忍者式テスト
- 知らない問題を探すためのテスト
- 手動
- 反復開発に有効なテスト
- 企画・仕様・設計の問題をその工程で見つけるのはむずかしい
- 大規模開発は作る工程と確認する工程が離れてしまう
- 確認工程でよりよい仕様や設計を思いついても対応できない
- 反復開発
- 大きな要求を数日程度の小さな単位にわけて開発する
- 頻繁にシステムテストをしないといけない
- それまでに搭載されたものすべてが問題なく動作することの確認
- そこで忍者式テスト
- TDDを受け入れテストのレベルで行うプラクティス
- 受け入れテストからはじめる開発
- 受け入れテストに導かれてストーリーを実現する
- ストーリーを作るたびにすべてのストーリーの受け入れテストを実施する
- どう試すのか？から考える
- テストを起点として開発全体を考え問い続ける
- ストーリーはチケットで管理
- 毎朝全員で読み合わせる
- 開発中に見つけたバグもストーリーと同様に扱う
- チケット管理システムは Ruby製のお手製
- パッケージ化してひと儲けしたい
- アジャイルがうまくいかないケース
- V字の底あたりをずっとやってるから
- 開発者とテスト担当者が分離
- プログラミングに近い猟奇をイテレーションに区切っただけ
- 忍者式
- 反復ごとにV字のすべてのステップをおこなう
- 全員が開発者
- すべての工程をプログラマーとプログラミング以外の工程を行うテスターで
- 短い周期で出来栄えを見たい→反復ごとの受け入れテスト
- 短い周期で仕様や設計をチューニングしたい
- ぎりぎりまで製品を磨きたい
- システムと結合する難しさを後回しにしない
- 小さな変更でもシステムで結合する
- 難しくてもやる、難しいからやる
- 後回しにすると「じわじわ開発」になりがち
- バグの修正を後回しにしない
- バグを見つけたら原因がわかるまで開発を止める
- 見かけだけの現象で申告さを判断しない
- バグは問題の一部分が見えただけなので本当の問題を探す
- 後回しにすると開発のペースが落ちる
- いまある問題を解決しなければもっと高度な問題を見つけられない
- 規模に向き合う
- 最初はすべてのケースを１日で確かめたい
- →１日ではなくある期間ですべてまわす
- 新しいストーリー、修正したばかりのチケットのテストケースを最優先
- アルゴリズム
- 全員がテストする
- 本日のおすすめテスト
- １日にできそうな量しかおすすめしない
- 難しそうな問題も躊躇せずに修正できるようになった
- 何か起きてても見つけて直せるという安心感
- 理想との差分を積極的に探す
- 全員が良い製品とは何かを問いながら開発
- あとから参加した人にも同様の変化が起きた
- タイムボックス仮説
- 期間があると考えやすい
- １時間、１日、１週間
- 残った文書
- 忘れた頃に読む
- 使い方
- そのとき期待していた製品の動きが書いてあるとうれしい
- チケットは命令書とか伝票じゃない
- 新しい人の役に立ってる
- 先輩と一緒に
- 製品の仕様とか振る舞いとか
- それを繰り返してるのがよい
『Railsアプリケーションとパフォーマンスチューニング ー 秒間5万リクエストのモバイルオーダーシステムを支える事例 ー』 奥本さん
- Railsアプリケーションとパフォーマンス
- kaigionrails.org/2024/talks/falcon8823
- 中学生のときにアプリを作って納品して高専入学金を稼いだ
- パフォーマンスを意識した設計・心構え
- APIベースのRails
- 基礎を積み上げていく
- N+1クエリ・スロークエリを避ける
- 計算量・速いアルゴリズム
- すべてアプリケーションサーバでは解決しない
- Webはアーキテクチャの総合格闘技
- 最初から設計で意識
- N+1が起きないクエリ設計・テーブル設計
- パス・コントローラの設計
- キャッシュ戦略
- CDN/アプリケーションキャッシュ
- N+1
- DBとの通信コストのレイテンシー増加
- Bullet gem で CI でも実行する
- CDNによるキャッシュは特効薬
- あとから入れると大変
- 個人に寄らないAPIはキャッシュを検討
- Railsサーバへの負荷を効果的に減らせる
- キャッシュによる情報漏洩に注意
- Cache-Control / Vary / ETag ヘッダをよく理解する
- プロバイダごとの挙動を理解する
- CDNキャッシュするパスとコントローラを分けておく
- CDN設定で api/private/* はキャッシュしないように設定
- ガードレールを敷きやすいシンプルなルールを運用
- 本気でCDNキャッシュを考え始めると大変
- stale-while-revalidate での逃げがオススメ
- キャッシュが切れても再検証されるまで古いキャッシュを返す
- 短めに設定してもキャッシュミスが頻発しない
- CORSをCDNで応答する
- Preflightリクエストが起きるケース
- 細かいリクエストまでRailsで応答するのは無駄
- CDNでのキャッシュや応答を検討
- ユーザを効果的に待たせる
- ユーザー体験を損なわないように設計
- サーバーエラーだと問い合わせに走ってしまう
- 「現在混み合っております。しばらく時間を開けて再度お試しください」ユーザーが何をすればいいか伝わる
- ユーザーやクライアントの教育も重要
- 負荷試験
- シナリオ試験
- ユーザーの利用シナリオからリクエストをシミュレーション
- ブラウザで実際の
- HARファイル
- Chrome のネットワークタブで保存したものを再現できるツールもある
- 計測
- パス単位での応答時間は最低限集計
- APMはあった方がよい
- 外部APIに負荷を掛けないようにモック化すること
- HTTPSを切って試験
- 負荷を掛ける側のパフォーマンスが出ない
- ロードバランサーの暖気に注意
- 全体のエラー率を確認する
- エンドポイントごとのエラー率を
- チューニング
- コストと事業インパクト
- サービスダウン回避
- ユーザー体験
- インフラコスト
- エンジニアの稼働を減らす
- App/DB/Web/LB/CDNの順にチューニング
- 遅いときはだいたい自分のせい
- 平均よりもレスポンスタイムが遅いエンドポイントから
- 100倍早くできそう > 1000ms
- リクエスト数 x レイテンシが高いエンドポイント
- 2-10倍
- PostgreSQLの実行計画をGPTで解析
- パラメータチューニング
- アプリケーションの性質によるので一概にはいえない
- 目的は計算資源を最大限に使い切ること
- 最後にいじる
- Railsガイドの「デプロイ用パフォーマンスチューニング」
- ゴール設定を見失わないように
- 荒く効果的にできるところから
- ユーザーやクライアントを巻き込んだ体験設計
