Rails8の認証機能と、俺たちのアイデンティティ
かかってこいよ、クリスマス。そうです、私がkinoppydです。
この記事は、SmartHR Advent Calendar 2024 Day1 のエントリーです
Rails8の認証機能
Rails8では、新たにユーザーの認証機能のジェネレーターが追加されています。これは何かというと、これまで多くのユーザーがdeviseやrodauthというGemを使って実現してきたユーザーの認証機能を、Railsの標準機能として生成できるものです。とはいっても、もちろんdeviseやrodauthのようにユーザーの認証に関わる広く高度な機能を提供するわけではありません。提供されるのはユーザー名とパスワードの組み合わせでログインセッションを作成するための一通りの機能のみです。例えば、MFAであったり、データの認可機能、テストヘルパーの提供などはありません。なんなら、ユーザーを新たにサインアップする機能すらありません。デフォルトのままでは、データベースにコンソールから直接ユーザー登録が必要です。
Kaigi on Rails 2024 の感想がようやく書ける
Kaigi on Rails 2024に参加してきました。諸々あってブログを書けるようになるまでめちゃくちゃ時間がかかってしまった。マジで何もできなくなることが世の中にはある。
Kaigi on Rails 2024 と哲学
光の道、導きの星が今年のテーマだった。気がする。それはつまりRails wayと呼ばれるモノでああり、結果として生まれてくるのが概念圧縮であったりThe One Person Frameworkと呼ばれるモノであったりする。
Railsを使っていると、誰もが迷う。0 to 1は特に迷わない。1 to IPOの時に、多くの迷いが生まれてくる。その多くの迷いに立ち向かうための話が、二つの基調講演で違う角度から語られていた。ひとつは、Railsが提供してくれるレールを尊重すること。アプリケーションを拡張したいときは、Railsの流儀を身に着け、自らのコードに応用していくということ。もうひとつは、オプションを手に入れること。常にアプリケーションをシンプルに保ち、変化に追従できるようになっておくこと。これらを光の道、導きの星として解説したのが2024のキーノートであり、深く感銘を受けたポイントだった。そしてRails自身も、メジャーバージョン8を迎えており、自らRails wayの大切さと、変化と柔軟さを体現していると言える。もちろん、ユーザーとしてそれに追従するのはまあ大変なのだけど。
Rails wayという言葉と自分がどこで出会ったのかは覚えていないが、元の本を読んでいないのでおそらく誰かから聞いた話だと思う。人には人のRails way、とまでは言わないが、俺の考えた最強のRailsが世の中にはそれなりに転がっている気がする。なんなら、Railsを書いていない人でさえも俺の考える最強のRailsを持ってインターネットに殴り込みをかけている気すらする。間違った導きの星は、人を迷わせる。だからこそ、ここ数年のRailsは様々な方法で正しい光の道が見えるように誘導しているようにも思えた。Hotwireの導入や、Omakaseの概念、Onceのコード公開、他にも色々。また、今回のセッションの中でも、モデルの育て方、データマイグレーションの標準への疑問など、様々なRails wayへの問いかけがあった。光の道、導きの星は宗教っぽいアンセムでなんか怖いなぁと思いつつも、人々が集まり哲学への問いかけを続けるZENとしてカンファレンス、それがKaigi on Railsだなと実感した。まあお前ら、Rails Guide何度も読み返せってことだ。Rails8ではRails Guideも強くなってるしな。
特に心に食らったセッションの感想
当日直接聞いたセッションと、残念ながら当日聞くことができず後日スライドを見たものがある。
Identifying User Identity
今回一番心に食らったのがこのセッションで、勇気と感動をもらった。 Userテーブルには何も情報を載せず関連テーブルで表現するというスタイル、自分もうっすらとメリットを感じていて個人開発のプロダクトではずっと続けていたのだけど、本当にそのうっすらとした感覚が正しいのかどうかの確信がいまいち持てず（なんせ個人開発なので、あまり派手な問題というモノに遭遇しない）、うまく言語化ができていなかった。そんなところにこのセッションをぶちこまれたので、ああ自分が思っていたうっすらとした感覚の正体はこれだったのかと変に感極まってしまったので一番食らったセッションになった。IdentityとIdentifyされたユーザーの情報は別で成立するんだ、というのがスッと入ってきて、なんだか嬉しい気持ちになった。スライドの中には書かれていなかったけど、Identityとユーザー情報を分割するメリットとして、ペルソナやの切り替えや認証情報の切り替えの実装が楽だというのも自分がうっすらと感じていたメリットで、その考えがさらに補強されるようで励まされた様な気持ちにもなった。 また、最後のユーザーの状態をstatus列無しでリレーションで表現できる、という考え方が凄くクールで、完全に食らってしまった。最高。ベストセッション。
Data Migration on Rails
このセッションが好きな理由は、光の道、導きの星が存在していない領域の話だったから。スキーマのマイグレーションでは無く、データのマイグレーション、もっと一般化すればワンタイムのスクリプトをどのように管理するかという手段をRailsは提供していない。もちろんDHHのお気持ち的なモノはあるみたいだけど、Railsの実装としてそれが示されておらず、Rails guideでも扱われていない。つまり、光の道、導きの星がないものを我々はどう扱えばいいのか、という話だった。実際のところ、多くの話題は光の道、導きの星が無いという話なんだけど、これだけ多くの人が同じ事をやっているにも関わらず、光の道が無いというのはなかなか奇妙な気がしたので、特に気になった。リアルワールドでは同じ目的で山のような数のGemがあり、Gemだけでは無くMakefileやShellスクリプトまで多岐にわたる様々な道しるべが用いられている。黄金律の修復が待たれる。王になれ。
Railsの仕組みを理解してモデルを上手に育てる
このセッションは当日聴いておらず、後日に資料を見て「うわっ、なんて素晴らしいんだ……」と思ったやつ。Railsをやっていると必ず迷う「複雑なフォーム」という問題に対して、光の道を示すためのガイド。Railsをやる人は、みんなこのスライドを胸に刻んでやると良いと思う。フォームオブジェクトの扱い方に関して、ここまできちんとわかりやすく言語化してまとめ上げた資料ってあまり見た覚えがないので、今後のRailsに参加する人たちは必読になると思う。本当に良いスライド。
推し活の ハイトラフィックに立ち向かう Railsとアーキテクチャ
これは完全に感情の問題なんですけど、ハイトラフィックの厳しい環境で手を替え品を替え戦い抜く話、聴いててビリビリするんですよね。勇気が沸いてくる。UPDATE SKIP LOCKEDすごいね。そんなセッションでした。
推し活としてのrails new
これも当日聴いてないんですが、良いんですよスライドが。開発者としての喜びとは本当にこういうモノだな、ものづくりの楽しさってこれだな、って感じられる話本当に大好きなんですよ。自分が作ったモノが誰かに使われて喜ばれるっていう、プリミティブな感情を味わいたいんですよ！！！！ 最高！！！
まとめ
Kaigi on Rails、ホンマに良いカンファレンスやなぁ……来年こそCFP通すぞ。
大阪Ruby会議04に参加＆登壇してきました
大阪Ruby会議04
大阪で2024/08/24に開催された大阪Ruby会議04に参加してきました。
最近はCFP不採択続きだったのですが、すごく久々に採択されたのでHotwireの話をしてきました。
Day0
チーフオーガナイザーの@ydah_さんからお声がけをいただき、クラフトビールのお店でDay0を仕上げていました。
めっちゃビールが美味しかったのでバンバンおかわりを繰り返しながら、@hasumikinさんの「mruby/cの/cって何者なんだ」の話とか、@sanfrecce_osakaさんのハンドルの謎とかを聞いて楽しく過ごしていました。
先日、声優の田中敦子さんが亡くなられてしまったため、非常に悲しい気持ちで少佐の描かれたTシャツを着ていったところ、何人もの方に「それは喪に服しているんですか」と気づいてもらえたり、@joker1007さんに「つらいよね、登壇するときってメンタルの状態も大事だからね、わかる」と励ましてもらったりして、なんて温かいコミュニティだと一人噛み締めていました。
Day1
登壇しました。RubyKaigiのスケジュールアプリのフロントをHotwireで作り直したので、Hotwireがどれだけ便利で、けど気を使うところが多くて、それでいて良いものなのかというのを伝えました。セッションの詳細な解説に関しては、会社の方のブログで書こうかと思います。
今回の大阪Ruby会議04、何故か不思議なことにみんな文字列の処理の話をしていましたね。キーノートのお二人はもちろんのこと、Rubyのソースコードの文字列を短くしたり、変な形にしたり、画面に描写したり、文字列をスキャンしたり、Rustでバインディングを書いたり、ActiveRecordのコールバックがむずかったり、dRubyが良かったり。最後の方は文字列かどうかはさておき、人類は皆文字列を操作することがどれだけ難しいかということを意識していのだなとしみじみ感じました。
今回の感覚として、どのトークもかなりボリュームがあって、一日のカンファレンスとは思えないくらい頭使ったなという感想があった。結構バッキバキに心を刺激されるタイプの地域Ruby会議で、すごく満足度が高かった。一番印象に残ったのはぺん！さんの、コンソールのテキストレンダリングと3Dプログラミングの話だったかなぁ。終始「なるほどなぁ……」と思い続けた。
アフターパーティーもとても楽しくて、@makicamelさんと「小さなツールを作っていくの良いですよね！」と話していたり、@koicさんに「事前にRubocopかけたコードをMinifyした文字列にもう一回Rubocopかけたら、論理的に完全にもとに戻りますか？」とか聞いていた。理論上戻るとのこと。@hasumikinさんのキーノートで折に触れて語られていた「隙間産業」という言葉を、僕はベンチャーだと捉えましたというやや気持ちがキマった感想とかを伝えていました。
最終的に、三件目のお店でたこ焼きと焼きそばを食べながら、謎の電光掲示板の謎をみんなで解き明かしていた。楽しかった。
Day2
中之島には文化的な施設が多く、とりあえずずっと行きたかった中之島美術館と中之島香雪美術館をはしごしていた。特に中之島香雪美術館の方は、大阪Ruby会議の会場であった中之島会館の隣のフロアだったので、前日からめっちゃ気になっていたため、行けてよかった。
あとはLUUPで大阪の街を適度に観光しながら、帰路につく。りくろーおじさんのケーキというのを全く知らなかったが、頼まれていたので買って帰ったら嫁に大変喜んでもらえた。
G.O.A.T
大阪Ruby会議04は、この夏最もアツい地域Ruby会議だと最初に宣言していた通り、アツかったなと思う。そんな最高な会議を開いてくれたチーフオーガナイザーのydahさんとスタッフのみなさん、そしてkyobashi.rbとRuby関西の皆さんに心からありがとうございますの気持ちです。
大阪Ruby会議04のプロポーザルが採択されたので公開します
【重要】
これはあくまでCFPの話であり、大阪Ruby会議のブログはまた別で書きます
何
タイトルの通りですが、大阪Ruby会議のプロポーザルが採択されたので、誰かの参考になればと思い公開します。
落ちたCFPは、いつも不採択がわかった瞬間に公開するのですが、採択されたCFPは実際に登壇するまでに公開してしまうとネタバレになるので、登壇後に公開する感じでやっていきます。
CFP
タイトル
RubyKaigi公式スケジュールアプリ開発で得た、Hotwireの使い方
概要
2021年から提供しているRubyKaigi公式スケジュールアプリを、2024年に全面Hotwireで書き直しました。Hotwireを使った開発体験の良いところと、良くないところ、そして実地で得たモバイル環境でのフィードバックなどをお話しします。主なトピックはTurbo関連で、Stimulusに関しては少なめです。
詳細
RubyKaigi公式のスケジュールアプリを2021年からSmartHR社のスポンサーとして提供しており、今年はReact製だったフロントを全てHotwireで書き直しました。Hotwireで実際にどれほどのモノが作れるのかというベンチマークとして、Hotwireを触ったことがない人、少し触ったけど実際のアプリに組み込むことを躊躇している人などを対象としたトークを予定しています。
以下のURLは、実際のスケジュールアプリのリポジトリです。 https://github.com/kufu/mie
主にTurboFrames、TurboStreamsを使った、SPAライクな挙動をするHotwireアプリケーションの構築について話します。 まず、TurboFramesを用いたDialog系の操作が難しいことに触れます。TurboFramesは、画面の一部を置き換えてページ遷移を避ける技術なので、モーダルなどのDialog系の操作とは相性が良くなく、それをいかにうまく見せるかを話します。また、37SignalsのCampfireがどのようにモーダルを実装しているかにも触れ、実装を比較します。 次に、Tableタグの操作をいかにTurboで変更するかが難しい話をします。Tableは、特定のセルだけでは無く周囲の行列にも影響を及ぼす変更が多いので、単純にTurboFramesで対処することができません。そのため、TurboStreamsで書き換える方法を提案します。 最後に、Turboがいかにサーバー側のレイテンシに影響されるかを話します。実際にモバイル環境では、レイテンシが大きくなるケースが多く、その場合に単純にTuborを使っているとユーザーが操作フィードバックを受ける事ができず、混乱してしまいます。そのため、できるだけ先にHTML要素を用意してTurboを使うか、またTurboのイベントを利用して通信中だということを示すかの重要性を説明します。
前のページでトークの長さが15分と30分両方選べたので両方選んでしまいましたが、どちらでも大丈夫です。
ピッチ
Hotwireはとても良くできた技術で、特にプロトタイプのアプリケーションなどを立ち上げる際に強力なツールとなります。そのため、全てのRails開発者に手段の一つとしてHotwireを選択できるくらいHotwireの良さを伝えたいなというのがプロポーザルの主な動機です。 RubyKaigiでスケジュールアプリを実際に触ってくれた人も多いと思うので、自分が触ったモノがHotwireでできている、ちゃんと動くんだということを実感してもらう事が、このトークの説得力になると考えており、自分がこのトークをするのにふさわしい理由だと思います。
今年も通らなかったので、Kaigi on Rails 2024 でRejectされたプロポーザル置いておきます
何
タイトルの通り、今年のKaigi on Rails 2024 のプロポーザルも採択されなかったので、誰かの役に立てばと思い公開しておきます。
CFP
Abstract
事業に新機能を足していく時、マルチアプリケーションという方法を選択することがあると思います。マルチアプリケーションは、マイクロサービスとは違いアプリケーションごとの独立自治性を高め、コードベースも各自のドメインに関するもののみに関心を向けられる、メリットの多い開発手法です。一方で、マルチアプリケーションではデータベースが分離されており、他のアプリケーションとのやり取りにはAPIを用意して通信する必要があります。このトークでは、事業の急激な変化により十分なデータ通信方法を確立しないまま巨大になってしまったアプリケーション群をつなぐため、GraphQL Federationという技術を選択し運用しているお話をします。加えて、GraphQL Federationだけでは解決できなかった横断的検索に対するDatabase Federationという解決策に関してもお話します。
For Review Committee
Details
大まかなトークの概要として、GraphQLをつかったバックエンドサーバー間のデータ通信に関するお話をします。一般的にGraｐhQLはフロントエンドがバックエンドと通信する際の技術という認識があると思いますが、スキーマによるデータの取捨選択や型の管理などは、バックエンド間での通信でも十分に通用します。マイクロサービスとは違い、完全に独立した別物の複数アプリケーション間で、データの構造や型を守りつつ、相互に安全に通信する手段として、GraphQLとそのオープンな拡張であるGraphQL Federationという技術を選択した話をします。完全なるモノリスではなく、複数のアプリケーションが動いている環境であれば、どこでも応用できるお話です。
SmartHRのアーキテクチャは、祖業である労務管理のRailsアプリに加え、多数のRailsアプリがそれぞれ完全独立で動いています。例えば、労務領域では文書配布や年末調整、書類申請はそれぞれ完全に独立した、Google Cloud上のVPCすら分割されたアプリです。さらに、昨今のタレントマネジメント領域も評価、分析、サーベイなど多数のRailsアプリが動いています。これらはいずれも独立したデータベース、独立したネットワークで動いています。連携のためにOAuth認可によるユーザーの識別、および労務アプリケーションを中心としたREST APIでのスター型ネットワークを構築しています。
労務アプリを中心としたスター型ネットワークは、ある程度の規模まではうまく動いていました。各チームが独自に労務アプリに専用のAPIを作成し、データを取得してくることでそれぞれの機能を十分に動かすことができました。しかし、さらに規模が大きくなってくると、様々な問題が出てきました。その一つが、労務以外のアプリ間でのデータ連携が必要となってきたことです。これまでは独立して機能していれば十分でしたが、現在ではタレントマネジメントアプリに入力したデータを、他のタレントマネジメントアプリから取得したいという要望が多くなりました。短期的に見ると、タレントマネジメントアプリ同士でRESTを作成しあいデータを交換すれば良いように思えますが、ネットワークがフルメッシュに移行してしまい管理が難しくなります。また、データスキーマを適切に管理設定できないと、アプリケーション間で取得しているデータに差異が出てきて、長期的にデータ連携が破綻する可能性も高いです。そのため、SmartHRの従業員情報というエンティティを定義したうえで、適切にデータを共有し合う必要がありました。
技術選定の段階では、API Gatewayを使ったRESTの集合や、GraphQL Federation、Datalakeの作成、データ同期でフルコピーなどの案がありましたが、以下の理由でGraphQL Federationが選択され、その中でも有力だったApollo Fedeartionを採用しました。
- データスキーマが定義されており、それをチームで管理できる
- 社内にGraphQLを使ったバックエンド通信の前例がある
- GraphQLは必要なフィールドのみを指定するので、トラフィックの節約ができる
- データ同期やDatalakeなどに対して、失敗した際にすぐに切り戻しが可能
Apollo Federation自体は公開仕様であり、またRustで実装されたルーターもOSSのため自由に使用ができます。そのため、この構成を作ってみること自体は、かなり簡単に真似ができますし、十分に運用に足るものです。一方で、Apolloはエンタープライズ向け機能として、GraphOSというスキーマやトラフィック、エラー監視を管理するSaaSも提供しています。このSaaSの使い勝手は、OpenAPIなどでRESTのスキーマを管理するよりも良さそうに思えたので、導入をしました。
Apollo Federationを導入した結果、複数のアプリケーション間でデータのやり取りが行われるようになり、連携を前提とした新しいアプリケーションもリリースされています。スキーマの管理も各チームの自治性を保持しつつ、全体のデザインとして違和感のないようガイドラインを整備しながら日々拡張を行っています。現在まで大きなトラブルもなく、非常に安定したデータ連携用のシステムが動いています。
一方で、いくつものアプリケーションが参加するGraphQLのスキーマを作成するうえで、いくつか問題も発生しました。例えば、アプリケーションによってデータの時系列に対する考え方が違うという問題があります。労務アプリケーションは、バイテンポラルモデルを使った厳密な時系列と履歴を管理していますが、それ以外のアプリは大体がその時点でのデータを保持しているにとどまっています。そのため、従業員の履歴をどう表現するかという問題があり、この問題は現在も継続中です。他にも、必ずしもスキーマに落とし込めるデータばかりではないという問題もありました。サーベイなどは、内容をユーザーが独自にカスタマイズできるため、それを汎用的に表現しようとするとPDFみたいなデータ構造になってしまいます。そのため、特定のプリセットを使ったデータのみを現在は提供していますが、今後はユーザーが作ったサーベイの提供なども求められており、苦慮しています。
また他の問題として、アプリケーションをまたいだ検索の構築が非常に難易度が高いこともわかりました。「AかつB」を検索するには、2つのグラフがそれぞれ検索した結果の和を得ればよいですが、「AかつBではない」を2つのグラフの検索結果から得ることは難しいです。なぜならば、アプリケーションごとに同期している従業員の情報に違いがあるので、「Aである」と「Bではない」はそれぞれ違う全集合の演算になってしまい、「Aである」から「Bではない」を単純に除算することができないためです。この話は複雑なので、採択された場合はスライドで詳細に説明します。
この検索の問題を解決するべく、ほぼアトミックに複数のDBをクエリする方針で解決をはかりました。ツールにはTrinoというデータベースフェデレーションツールを使い、すべてのデータベースを検索グラフが直接参照しています。それによって検索は改善されましたが、現在はSQLの生成が複雑になっているという課題が残っています。検索改善のお話も、時間があれば少し話そうと思います。
Pitch
GraphQLは、一般的にはフロントエンド用の技術で、バックエンド間でのデータ連携に使用しているという例は国内では非常に珍しいと思います。またその中でも、GraphQL Federation という選択をした企業は更に少ないと思います。SmartHRでは、NetflixやRippling、国内だとMoney Forwardなどの先行事例を調査し技術選定を行いました。あまり国内で耳馴染みのない技術をそれなりの規模で運用している話を共有することで、マルチプロダクト戦略をとっている会社の選択肢としてGraphQL Federationを増やし、検討できるようになれば良いなと思っています。また、いま成長の真っ只中に居て、アプリケーションをどのように拡張していくかを悩んでいる方々にとっても、マルチプロダクトという選択肢を後押しできる話になると考えています。複数のアプリケーション間の通信方法としての知識の引き出しを増やします。
Speaker Information
kinoppyd SmartHRで働くプログラマ、うどんよりそばがすき。
Rubykaigi2024、沖縄、ステーキ
はいさい。楽しかったよ、RubyKaigi2024。帰りの飛行機の中でこのブログを書いてます。
今年もRubyKaigiのCFP通らなかったので公開します
今年もRubyKaigiのCFP通りませんでした。やっぱり結構へこみますね。送ったプロポーザルの内容を共有しておくので、何かの役に立てばと思います。もしくは誰か添削でもしてください。
Art of metaprogramming
Abstract
Not a Black Magic. Metaprogramming is powerful and useful part of Ruby. This talk describe real world metaprogramming technics with code of famous gems. For example, How RSpec define their DSL, How Rack plugins (e.g. Puma, thin) register itself and how Rack find it, et al. Enjoy white magic metaprogramming world.
For Review Committee
Details
このセッションの目的は、著名Gemで使われるメタプログラミングの妙技を知ることで、聴講者の方々が書くコードの引き出しを増やすことです。そのために、Rubyの強力な武器であるメタプログラミングを、多くのユーザーが利用しているGemのコードを実際に見て挙動を追跡しながら紹介します。多くの人は、メタプログラミングを「メタプログラミングRuby第二版」という名著で学んだと思いますが、Gemを書く人でなければそのテクニックが現実世界でどのように生かされているかを目にする機会はあまり無いと思います。そのため、このセッションではメタプログラミングの力を実例とともに知ることで、聴講者の方々が書くことのできるコードの幅が広がることを期待しています。
まず最も有名な利用例であるDSLは、RSpecとminitestのコードを紹介しようと思います。普段多くのWeb開発者が用いているあの不思議な文法は、どのようにしてメタプログラミングで実現されているのかを紹介します。RSpecはRubyとは思えない構文を実現するためのテクニック、minitestは特定のメソッド名だけをフックする挙動や、autorunの仕組みなどを知ることができます。
次にプラグインの機構を、RackとActiveRecordのコードを見ながら紹介します。Rackのhandlerは、RackのHandlerモジュールを再オープンしてregisterメソッドを呼ぶというワイルドな方法が使われますが、ActiveRecordではActiveSupportの力を借りてロードされたときにフックするというマイルドな方法を使っています。それぞれ、プラグインを本体に登録するときの挙動やそのルックアップ、そして注意すべき点を知ることができます。
最後に、いくつかの光のメタプログラミングをお見せしようと思っています。これはまだProposalを書いている時点ではどのGemのコードを解説するか未定の内容ですが、メタプログラミングを使ってビックリするくらい感心する問題解決を行っているコードをいくつか紹介したいと思っています。例えばですが、ActiveRecordがどのようにカラム名のメソッドを自動生成するかなど、おもわず唸るようなテクニックを探して紹介したいと思っています。現実のメタプログラミングがRubyの便利さをここまで高めてくれるのか、と思えるようなコードを探して共有し、メタプログラミングの素晴らしさを皆で分かち合えたらと思います。
このセッションによって知ったメタプログラミングの奥深さを、実際の業務でも生かせる引き出しとして記憶に残していただけるような内容にしたいと思います。
Pitch
RubyKaigiの参加者層は、コロナによるオンライン期間を経てかなりの入れ替わりがあったと感じています。実際にスポンサー各社が公開しているアンケートや、自分で聞いて回った感覚などから、オフラインのRubyKaigiに初めて参加するという方の数は事実として相当多い様です。新しくRubyKaigiに参加される方々の中には、フィヨルドをはじめとするプログラミングスクールの卒業生であったり、会社の新卒であったり、転職を機にRubyに触れたりなど、しっかりとしたプログラミングの知識と実力を持ちつつもRubyでの実務に携わった時間で見るとまだ若手という方が多く居るように感じました。
まだRubyの経験が浅い方々にとっては、メタプログラミングの便利さや楽しさを感じるよりも、よく知らない怖い何かというイメージの方が強いかもしれません。そんな方々に対して、メタプロの楽しさを伝え、よりRubyを使いこなすための道具を手に入れて欲しいと思い、Proposalを書きました。より多くの人がRubyの深い機能に注目し使いこなすことで、Rubyの世界がさらに広がっていくことにつながれば良いなと思います。
メタプログラミングは、Rubyの素晴らしい特徴の一つではありますが、ここ数年のRubyKaigiではそこにフォーカスしたセッションはそんなに多く採択されていません。事実、メタプログラミングは素晴らしい機能であるものの、毎年そんなに劇的な変化を見せたり新たな発明があるような類いの機能ではなく、常磐木のような機能です。だからこそ、その強力さを改めて伝えたいと思いました。また、RubyKaigiではTracePointやASTを使って黒魔術的な楽しみ方をする方も多く、自分も黒魔術大好きですし、それはそれでとても良いのですが、たまには光の白魔術も見せたいなぁ！ と思ったのが主たるモチベーションです。
Spoken language in your talk
Japanese
Speaker Information
kinoppyd Engineer at SmartHR
さよなら86
ちょうど3年前に86という車を買って、今日売却した。
車を買うまで自分がこんなに運転が好きだと知らなかったので、かなりさみしいお別れになってしまった。手放した理由は子供が産まれたからで、２ドアのスポーツカーでは後部座席に取り付けたチャイルドシートに子供を乗せ入れするのが凄く大変だったからだ。そしてそれを自分でやるならまだしも、後部座席で子供の面倒を見る妻の負担が大きかったので、仕方なく乗り換えることになった。次はKINTOで借りた新型プリウスに乗ることになる。
Springは何をしているのか？
このエントリは、SmartHR Advent Calendar 2023 のシーズン2の3日目です。なんすかシーズン2って。
Spring、使っていますか？ Rails4.1から追加された新しいRailsの起動を早くするやつです。べつに新しくないですね。なんならRails7からは rails new のときにデフォルトで追加されなくなっちゃいました。DHH曰く「最近はコンピュータの性能上がったから別に起動とか大したことないっしょ」らしいですが、本当にそうか？ と思います。Springは大量のGemをロードしたりinitializerとかに大量のコードが書かれている大きなアプリケーションを起動する上で未だに一定の効果を発揮してくれる一方で、なんだかよくわからない謎の機能くらいのイメージしか持っていない方も多いと思います。僕もそうでした。なんとなく別プロセスでRails立ち上げて……みたいな仕組みを耳にしたことはありましたが、えぇなんか怖いとかRailsのリロードとかがうまく動かないのってこいつのせいでは……みたいな印象を持っていて、なんかバグったなと感じたらとりあえず bin/spring stop とかあまり意味のないことをしていました。
素Turbo
このエントリは、SmartHR Advent Calendar 2023 の1日目です。
Turbo、使っていますか？ Rails7から追加された新しいフロント用フレームワークで、思った以上にくすぐったい動きをして僕は結構好きです。今年のKaigi on RailsでもTurboに関するいくつかのセッションが発表され、その注目度が伺えます。しかしその注目度とは裏腹に、あまり周囲に使っている人を見かけません。まあたしかに業務に使うにはちょっと物足りないかなぁという気持ちもわからない事も無いのもありますし、また同時に現代ではReactやVueなどが主流になりすぎて使う気が起きないという理由もわかります。 とはいえ、使ってみないと海の物とも山の物ともつかぬままです。なので、とりあえずTurboを使ってみるのはいかがでしょうか？ なんなら、TurboはRailsなしでも動きますし、とりあえず体験してみるのも良いんじゃないでしょうか。
そうです。Turboは、というよりもHotwireはRailsに一切依存しない独立したフレームワークです。Turbo本体とブラウザのJSエンジン以外に依存する物はありません。僕はTurboに結構良い意味でjQuery感を覚えているのですが、そういう意味でも結構似ています。今日は、Railsから取り外され、何にも依存していない素のTurboを触ってみて、どんな動きをするライブライなのかを見極めてみましょう。
なお、扱うトピックはTurboFrameとTurboStreamです。TurboDriveはわりとわかりやすいというか、TurboLinksをよりわかりやすくしただけの物なので割愛します。