表題の通りRailsにおけるdata migrationの手法や現在地についてKaigi on Rails 2024で発表してまいりました。
4年連続でスピーカーとして参加*1することができ大変光栄でした。また、後述するようにオフラインならではの稀有な体験ができ、楽しかったです。
今回の発表について
発表に用いたスライドは以下です。
今回はこれまでの発表とは違ったアプローチに挑戦してみました。これまでの発表が1つの課題やプロトコルについて深掘るスタイル(まぁ、発表って普通はこっち)だったのに対し、今回は収集する情報の幅を広くとりつつ特定テーマの現在地を半網羅的に示すというsurvery report風味な内容という感じ。
意図したアプローチではありつつも、スライドを作りながら「ちょっと浅すぎないか」「広く薄いこの内容は誰にとって面白いのか」とけっこう直前まで悩んでいた。特に一番伝えたい芯をどこ置くかは迷いどころだったものの「今回のスライドを今後の議論の土台としたい」という落とし所で突き進むことにした。
聞いてくださった方が1つでも知らなかったことを持ち帰れたり、今後data migrationを考える際に立ち返る道標的なものになれたりしたら幸いです。
発表時にXで実況的に感想をくださった方、発表後に話しかけていただいた白土さん、corocnさんありがとうございました。大変励みになります。
スポンサー
所属しているSmartBankは2年連続でスポンサーブースを出しており、僕も時折そちらで会社紹介をしたりしてました。
会社として初めてのテックイベントスポンサーが去年のKaigi on Railsであり、当時は「会社名もプロダクトも聞いたことないっすねぇ...」という感じだったのが、今年は「B/43使ってます、ユーザーです!」「RubyKaigiでもSmartBank見ました!」のような方がたくさん訪れてくれ、認知の広まりを感じました。Kaigi on Rails、YAPC、RubyKaigiと続けてスポンサーしたり毎回登壇者を送り込んだことの効果をひしひしと感じます。
一方、実態以上に良く思われてないか、人が足りてて課題が少ないと思われてないか、キラキラしてないかといった認知形成も社内で話題に上るようになり、次のステージって感じですね。
実際には登壇やブースで見えるような"輝き"以外の泥臭い課題に取り組んでいたり、そもそもRailsエンジニアは10名ちょっとの少人数で採用強化中だったりするので、認知補正をひたすらやっていました。
今回のKaigi on Railsでは会う人それぞれにSmartBankの認知補正を頑張ったので伝わってたら嬉しい
— ohbarye (@ohbarye) 2024年10月28日
「エンジニア既に沢山いますよね」→「まだ12人だけでめちゃ募集中です」
「Fintech好き熟練Railsエンジニアしかいなさそう」→「20/30/40代が約3割ずつ、Rails未経験約3割、Fintech経験者は1割以下」
ひっそりとできたらかっこいいのかもしれないけど、こういうのはストレートに伝えたほうがわかりやすいだろうと思って、会う人会う人に言いまくってました。本当に採用強化中であるのと同時に、もっと実態を知ってもらうためのカジュアル面談もオープンしています。
転職意欲を問わず「Kaigi on Railsで配布していたアーキテクチャ図の解説をしてほしい!」「rails stats
どんな感じなの?」「えっ!! Railsでカード決済システムを!?」といった純粋にテクニカルな話題のみにも対応していますので、お気軽にお声がけください。
印象に残った発表
登壇者としての参加だったのであまり落ち着いて聞けた発表はなかったのですが、中でも面白かったのはがーしーさんのcXML という電子商取引の トランザクションを支える プロトコルと向きあっている話でした。世の中に存在するニッチで渋〜いプロトコルと戦う話、大好きです。懇親会でがーしーさんを捕まえてお話ししたところ、SmartBankのメンバーの去年の発表を見てこういうニッチな枠を狙ったりスライドを参考にしていただいたとのこと。これは嬉しい。いろいろ話した結果cXMLプロトコルの存在意義やメリットを受け売りで他の方に伝導できるようになった。
また、moroさんのIdentifying User Idenityもとても良かったです。昨年のSimplicity on Railsと同じく、「そうそう、そうやっている / やりたかったんです」と言いたくなる内容で、自分たちのコードベースが追認されるような心持ちになりました。
発表を見られなかったもののすごく面白そうなスライドもたくさんありました。カラム追加で増えるActiveRecordのメモリサイズ イメージできますか?、デプロイを任されたので、教わった通りにデプロイしたら障害になった件 ~俺のやらかしを越えてゆけ~、約9000個の自動テストの 時間を50分->10分に短縮 Flakyテストを1%以下に抑えた話はスライドだけでも興味深かったのでアーカイブも楽しみにしてます。
交流
今回は"インターネットで一方的に見知っているけど初めてお会いする方"とオフ会できて良かった。
廊下
一方的に見知っている方の筆頭がpalkanさんで、なんとDay 1の本プレゼントクイズに当選して"Layered Design for Ruby on Rails Applications"の物理本をいただいた。
One of my best memories at #kaigionrails was winning palkan san's raffle and getting a copy of his book with a fancy message "Think as a framework author" in Japanese (フレームワークの作者のように考えましょう) !
— ohbarye (@ohbarye) 2024年10月27日
I wish we had taken a photo as #rubyfriends . https://t.co/Bw55ymU6YC pic.twitter.com/4WnCqsFAqt
緊張しながら話しかけたところにsylph01さんもいて、クイズの答えあわせしたり講演内容について質問したりした。たぶんもうネタバレ大丈夫だと思うので書くと以下が答えだった。僕がQ1正解でsylph01さんがQ2正解でどちらもhalf correctだった...。
Q1. Rails Way, or the Highwayのインスパイア元は?
A1. My Way (Limp Bizkit)
Q2. 最近見た世界最大のモノリスは?
A2. Shinjuku
講演に関するQ&A
せっかくなので講演について聞いたのは「Formレイヤーを追加するときに抽象化って必要なのか?」ということ。
Formクラスの導入はigaigaさんのRailsの仕組みを理解してモデルを上手に育てる - モデルを見つける、モデルを分割する良いタイミングや、過去のmoroさんのフォームオブジェクトとの向き合い方などで出てきているように、パターンとして日本のコミュニティでも広く知られている。けどいずれも抽象化を施すまでは至っていない(と思う)ので、その必要性が気になった。
palkanさんの回答(disclaimer: 乏しいリスニング力のため聞き間違いの可能性おおいにあり)は「規律を課さないレイヤー追加はいつか破綻するから抽象化が必要なのだ」というものだった。
POROのFormクラスやActiveMode::Model
をincludeしたときだけのFormはいわばレイヤーになりきれていない"intermediate state" (中間的な状態) であり、チームで統一した書き方を強制できない。モデルの操作や例外のハンドリングなどがまちまちになり、新人は思い思いに実装されたFormクラスのうち任意のコードを真似するようになる。フレームワークの作者のように考えるなら、新たなレイヤーを追加するなら抽象化による規律・規約を持ち込み、長期にわたってそれらが守られるようにすべきなのだ。
ということを言っていた気がします(9割意訳)
懇親会
そんな話をしてくれたpalkanさんが同著の「日本語版を出したいけどどうしたものか」とこぼしていたのを聞き、突然なんらかの使命感に目覚め、Day 1懇親会ではいろんな方にその意図を広めたりしていました。このことを口実にinaoさん、snoozer05さん、okuramasafumiさんたちと話す機会を持てたりもしました。しかし、翻訳書やRails本の出版事情も聞くほどになかなか大変ですねぇ...
Day 2の懇親会ではsinsokuさんハマちゃんさんらと学生さんと同じテーブルになりました。弊社は新卒採用やインターンをやっていないので学生と話す機会が非常に乏しい、実際話してみるとものすごく優秀なだけでなく、我々にはない視点での質問や話題を提供してくれて大変楽しかった。
インターネットで見知っていた桐生あんずさんも発表前の廊下で忘れられない遭遇をしただけでなく、懇親会でarimoさんakiさん交えていろいろ話せました。僕の https://scrapbox.io/ohbarye/ をちょいちょい見てくれていたことがわかり、大変嬉しかったです。
さっき廊下で後ろから
— ohbarye (@ohbarye) 2024年10月26日
「これからohbaさんの発表ききます」って話してる声が聞こえて
「えっ?もう出番だったっけ!?タイムテーブル見間違えた!?」とめちゃくちゃ焦ったのですが @nay3 の発表を見に行く @anzu_mmm さんの発言で私は無関係でした
ヨカッタ〜#kaigionrails
再会で言うとRubyKaigiでちゃんと話せなかったmorihiroさんともちゃんと話せて良かった。お互い瞳孔が開いてたような気もしますが個人技やマネジメントなどについて久々に熱い語りができたように思います。
Quipper時代の同僚のtricknotesさん、indigolainさんと同窓会できたのも良かった。tricknotesさんは開発以外にも挑戦しつつプライベートでコードをゴリゴリ書いていたり、indigolainさんは https://github.com/kaigionrails/conference-app にもコミットしててかっこいいですね。願わくばQuipper時代の同僚ともっとコミュニティでオフ会したいですねぇ。
振り返るとここ数年で最大級に色んな方と会話でき、オフラインイベントの良さを最も堪能できたイベントだったように思います。もっとたくさんの人と会話したのだけど名札を見る余裕がないために失礼があったらすみません。
登壇お役立ち情報
懇親会だったと思うのですが「X見てたんですが発表以外の工夫をなんか色々"やって"ますよね?参考にしたいので教えてください」と言われました。
そうですね...どれも本質じゃない小技ではありますが、いくつか"やって"はいるとは思ったので、会期中にポストしたものを並べておきます。登壇にこれから挑戦する方などに参考になれば幸いです。
マイクの持ち方
今日もこれ意識していきたいhttps://t.co/qP8xo2ARD5#kaigionrails
— ohbarye (@ohbarye) 2024年10月26日
登壇日の朝の告知
[告知] 本日15:05~に #kaigionrails_red にて「Data Migration on Rails」という題で発表します。
— ohbarye (@ohbarye) 2024年10月25日
"database migration" (データベースの移行) ではなく "data migration" (本番環境のデータ修正等) の話で、運用経験を通じて一度は触れた身近な題材かと思います。興味あればぜひ!#kaigionrails pic.twitter.com/Z58xIODU6i
発表前の資料放流
このあと15:05~15:35にHall Redで発表する「Data Migration on Rails」の資料です。
— ohbarye (@ohbarye) 2024年10月26日
画面が見にくい時、口頭だと飛ばされる箇所をじっくり見たい時はこちらをご覧ください。
ハッシュタグ付きでの感想・フィードバックお待ちしております!!https://t.co/vZBQCYLohy#kaigionrails #kaigionrails_red
登壇で使用していたポインターに言及いただいた方へ @xi_kax @GhostBrain @arimo
— ohbarye (@ohbarye) 2024年10月26日
こちらのロジクールの製品を使っております。まぁまぁ高いけど5年以上使えており大変便利です!#kaigionrails #kaigionrails_red https://t.co/1PbKpunFf7
今後
改めて30分の登壇は準備も練習も大変で、何年やっても慣れないことばかりです。とはいえ終わった後に得られるものは多いので継続可能なペースでやっていきたいものです。
宣伝
来週11/5 (火)のアフターイベントにも登壇することになりました。Kaigi on Railsではテックトークをしたので、次は「登壇のネタ探し・プロポーザルの書き方・登壇内容を磨く工夫」あたりについて話そうかなと思っています。一般的な登壇のメリットとか工夫はけっこう知られてきたと感じており、今回はあくまでohbarye個人としての体験・経験・工夫をまとめてみようかなと。
さっきまで満席でしたが増枠されたようなので未申し込みの方もぜひ以下からどうぞ。現地でお会いできること、再会できることを楽しみにしております。
感謝
最後になりましたが、Kaigi on Rails 2024を開催してくれたオーガナイザーの皆様、最高のイベントをありがとうございました!
*1:オーガナイザーチームの寺井さんとも話したけど、他にはいない?