大阪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をよりわかりやすくしただけの物なので割愛します。
ガルパン最終話4話を最速で見てきたけどやっぱりガルパンはいいぞ
ノーネタバレでいきますが、とにかくガルパンはいいぞということを伝えたい。
ガルパンは良い。本当に良い。絶対にこうなる、絶対に誰もがこの展開を見たい、という全てが詰まっていた。3話の終わりで退場したあんこうチームも、決勝で勝ち上がるチームも、全てが「これを待っていた！！！！」となる展開だった。次が公開されるのは何年後かはわからんが、グランドフィナーレを飾るにふさわしい最終話中の最終話となることが期待される。なんなら2時間やってほしいくらいだ。
それはそれとして、最速4話は1話から3話までをぶっ通しで見た後に4話を観るという上映スタイルだった。いややっぱりね、1から3も良いんだわ本当に。何度か観てるけど、連続してもう一回観ると改めて良さに気づく。ガルパンには人生に大切なことが全て詰まっている。
論より突撃。みんな劇場に急げ。
Reject on Rails 2023 に応募するから Kaigi on Rails 2023 でRejectされたCFP置いときます
何
タイトルの通りなんですけど、Kaigi on Rails 2023 のCFPがRejectだったので Reject on Rails 2023 に応募しようと思い、せっかくなんでRejectされたCFPも置いておこう的な奴です。応募するときに楽かなと思ったので。でも応募フォーム開いたら特にどういうCFP送ったか書く場所無かったんで、公開する意味ないやんとか思ったけどもうブログ書いちゃった後だったんで……
CFP
Abstract
Ruby on Rails, Sinatara, Grape, Hanami など、Rubyには多くのWeb Application Framework があります。これらは方法は違えど、全てRackというインターフェイスを満たすフレームワークです。このセッションでは、RubyのWebフレームワーク共通のインターフィスであるRackの仕様を満たす、自分だけののWeb Application Frameworkの作り方を通して、Rackとはなにか、自己流のDSLをどのように作っていくかを学びます。
For Review Committee
Details
Rackのインターフェイスのお話と、主にSinatraで使われているテクニックを解説しながら、独自のDSLで実用的？なWeb Application Frameworkを実装するための知識について話します。
想定する聴講者は、Railsで仕事や趣味の開発はできるけれど、Web Application Frameworkがなんで動いているのかは知らない、という初心者から中級者の間を想定しています。メタプログラミングの話がでてくるので、初学者向けでは無いと思います。
具体的には、最初に「ぼくのかんがえる最強のWAF」のDSLを示し、それを本物のWAFとして実装するためにはどんな知識が必用なのかを順を追って話していく形になると思います。例えば、次のようなDSLが使えるWAFが欲しいです、どうやって作りましょう？ みたいなお話になると思います。
require 'oreno_kangaeta_saikyou_no_waf'
# あくまで今考えてる適当な例なので、どんなDSLになるかはわからんですが
get_root do
'hellow world'
end
post_users do |request|
user = User.new(name: request['body']['name'])
user.save ? user.id : raise
end
このDSLを実現するためには、 / や /users にリクエストが来たときに、反応するブロックをどう定めるか？ 戻り値はどの様に変換してRackに渡すか？ いや、Rackってなに？ エラーのハンドリングをどうするか？ そもそもどうやって起動するのか？ など様々なことを考える必用があります。それらをSinatraやRailsのコードを見ながら、こうやって実装すると動きますと示していく予定です。
あくまで決め打ちのコードのエッセンスを伝える感じにするので、ライブコーディングなどは予定していません。もしかしたら、最後にちょっと動かす程度はあるかも知れませんが。
Pitch
30分で伝えられる量には限りはあると思いますが、RailsでWebアプリを作ることは出来るけど、それ以上のことはできないという方々の好奇心に刺激を与えます。普段使っているツールの動作原理を知ることで、より高い解像度でツールを使えたり、新しい何かを作ったりすることの手助けができれば良いなと思います。