Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Ruby on Rails の楽しみ方

Ruby on Rails の楽しみ方

Avatar for morihirok

morihirok

May 15, 2025
Tweet

More Decks by morihirok

Other Decks in Technology

Transcript

  1. STORES 株式会社 「なぜ今 Rails を学ぶべきなのか」Ruby on Rails から学ぶ Web ア

    プリケーション開発実践 / 技育CAMPアカデミア Ruby on Rails の楽しみ方
  2. 20年続くWebアプリケーションフレームワーク Ruby on Rails • GitHub、Shopify といった大規模なWebアプリケーションが Ruby on Rails

    で開発されている • 日本でもクックパッド、freeeをはじめ、様々な企業が Ruby on Rails を採用 している • STORES は新規プロダクトの開発にも Ruby on Rails を採用している 20年間選ばれ続けるWebフレームワークは 他に例を見ない
  3. そんな課題感から当時読まれていた技術書 • 「Patterns of Enterprise Application Architecture」Martin Fowler (2002) ◦

    Java等のオブジェクト指向言語におけるエンタープライズアプリケーションの設計パターン集 ◦ DHH(Railsの作者)も影響を受けている • 「Domain-Driven Design」Eric Evans (2003) ◦ いわゆるDDDの原祖 ◦ ドメイン(業務知識)をいかにソフトウェア設計に組み込むか、プロセス改善と実際のソフト ウェア設計について書かれている アプリケーションをキレイに作るための アプローチ
  4. DHHはWebアプリケーション開発を大胆に抽象化した • リソースが定まれば、生命線であるユースケースのCRUDは自動生成できる • 例えば Blog というリソースが存在しそれを操作するとして、必要なものはコ マンド一発で自動生成される ◦ blogs

    というテーブルをデータベースに作る ◦ データベースを操作するBlogというモデルクラスを作る ◦ クライアントからのリクエストを受け取り処理するBlogsControllerを作る ◦ blog の一覧、詳細、作成、更新、削除ができるルーティングを作る ▪ 一覧:GET /blogs ▪ 詳細:GET /blogs/:id ▪ 作成:POST /blogs ▪ 更新:PUT /blogs/:id ▪ 削除:DELETE /blogs/:id ◦ 自然と「REST」というWeb APIの設計思想に従うこともできる
  5. アプリケーションにとって必要なリソースを定義できればほぼ完成する • 各種ファイルの関連付けは設定ファイルで行うのではなく規約で決まるため、 設定ファイルを書いて回る必要がない ◦ Blog モデルはなんの設定をしなくても命名から判断してblogsテーブルを参照する ◦ Blog モデルには各レコード・カラムに対してSELECT、UPDATE、INSERTなどのデータベース

    操作を行うメソッドが自動で作られる ▪ 例えば blogs テーブルに author というカラムがあれば、Blog モデルには author とい うメソッドが自動で作られ、それを介してDBを参照できる ◦ BlogsController は何の設定をしなくても、メソッド名に紐づいてファイルを探索し、自動的 にテンプレートエンジンを読み込んでレスポンスを作ってくれる 大事で楽しいビジネスロジックやUIの開発に 集中できる!
  6. DHHがDHHしている例 • https://signalvnoise.com/svn3/the-majestic-monolith-can-become-t he-citadel/ ◦ 2016年に業界の流れが「これからはマイクロサービスだ!」というときに「よくできたモノリ スこそが至高」と叫び炎上 • https://world.hey.com/dhh/why-we-re-leaving-the-cloud-654b47e0 ◦

    2023年ほとんどの企業がクラウドに移行した中「私たちはクラウドをやめてオンプレに移行し ます」と宣言し炎上 • https://world.hey.com/dhh/turbo-8-is-dropping-typescript-70165c0 1 ◦ 2023年TypeScriptがもはやデファクトかという流れの中DHHの好みじゃないという理由で TurboというRailsのフロントエンドライブラリからTypeScriptを消し炎上 25
  7. Railsには良い教材がたくさんあります • Rails チュートリアル ◦ https://railstutorial.jp/ ◦ X(旧Twitter)風のマイクロブログサービスを作りながら学べる ◦ Web

    テキストだと¥1,078(税込) ◦ 無料の過去版でも十分エッセンスを学べる • Rails ガイド ◦ https://railsguides.jp/ ◦ 無料でRailsの機能を網羅的に学べる 28
  8. Railsを学ぶうえでよくある間違い • 場当たり的実装で終わらせる ◦ Railsにはいろんな現実的ユースケースに備えたAPIが用意されている ◦ とにかく書いてみるのも大事だが、結構な確率でそれをやるためのより優れた方法がRailsから 提供されているので、ドキュメントを探ってみよう • 「RailsでDDD的なレイヤードアーキテクチャをやってみよう」

    ◦ Railsは「あえて密結合」にすることを選んだフレームワークで、レイヤードアーキテクチャな ど責務を疎に設計するものとは違う思想を持っている ◦ これに反する設計を持ち込むのはそもそものRailsの思想とは反しており、かなりの覚悟が必要 ◦ もしやりたくなったらまずは「リソース」つまりDB設計に着目するなどいろいろアプローチが ある ◦ まずはRailsの思想をしっかり理解しよう ◦ そのうえで Rails で大規模にスケールしている GitHub、Shopify などの取り組みを参考にし てみよう 32
  9. あえてRailsで学べないことを話すと • Rails のエコシステムに含まれていない技術は学びにくい ◦ 例えばGoであればアプリケーションに必要な様々なライブラリやミドルウェアを各種選定した り自前で作ったりする ◦ その過程でいろんな選択肢を見るきっかけになる ◦

    Railsの場合はあらかじめ内包されていたり定番ライブラリが多くあるので悩むことが少ない が、いろいろ選定して回って知識を得るきっかけがない • 個人的にはRailsのフロントエンドのエコシステムは今のところバックエンドほど「これでいいじゃん!」感はないかも... 33
  10. 参考文献 • 2024年のRailsと自由について考える ◦ https://speakerdeck.com/takahashim/enishitechcconf2024 • Ruby on Railsの正体と向き合い方 ◦

    https://speakerdeck.com/yasaichi/what-is-ruby-on-rails-and-how-to-deal-with-it • Ruby on Rails: DHHのインタビュー ◦ https://kdmsnr.com/translations/interview-with-dhh/ • Ruby on Railsはどのように生まれ、発展してきたのか ◦ https://www.publickey1.jp/blog/24/ruby_on_railsdhhruby_on_rails_the_document ary.html • texta.fm ◦ https://open.spotify.com/show/2BdZHve9cIU6c8OFyz7LeB 40