2020.05.13に開催された「オンライン開催!【シューマイ】Tech Lead Engineerから最新技術を学べ!Rails編」で話した「生鮮ECプラットフォームの バックエンドを支えるRails」についてのスライドです。
![Rails for backend of fresh EC platform "Cookpad Mart"](https://cdn-ak-scissors.b.st-hatena.com/image/square/774ab42d063b291cdd401ec45bbd02d863eec531/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F21f0d7233191439eb0e33bbcefdcf0cb%2Fslide_0.jpg%3F15463261)
こんにちは。メドピアのRuby(Rails)化をお手伝いしている@willnetです。最近はエンジニアが増えた影響か、Railsの質問に答えていることが多いです。 以前、Railsの太ったモデルをダイエットさせる方法についてというタイトルでPOROを使っていこうという話を書きました。その際にコード例などもなるべく多く載せるようにしたのですが、このエントリだけを読んだ状態では、いざ「POROを使ってみよう!」としたときにまだ悩む余地がありそうです。 POROはその名の通り普通のRubyオブジェクトなので、いろんな書き方ができてしまいます。それなりに経験がある人でないと、どのように書いたらいいんだろう…と悩んで時間を使ってしまいそうですね。さらに、複数人で開発しているチームだと書き方のバラツキも気になるところです。きっと、POROを書くときのお作法が決まっている方が開発しやすいはず。 そこで、
このエントリで書いた内容は、ほぼ Growing Rails Applications in Practice の内容が元になっています。英語ですが、ここで挙げた内容以外にもコードを綺麗に保つテクニックが書かれており、かつページ数も少なく読みやすいです。コードを綺麗に保つのが好きな方は一読してみることをおすすめします。 はじめに Rails で fat model を避けるための方法は、7 Patterns to Refactor Fat ActiveRecord Models を始めとして、多くのやり方が存在します*1。 validation や callback は ActiveRecord(以下AR) を継承せずとも利用することができます。7 Patterns to Refactor Fat ActiveRecord Models の 「3. Extract Form Objects
ユーザーエンゲージメント部の諸橋 id:moro です。 わたしはずっと、ユーザー登録やログイン周りという、サービス的には基盤的なところ、技術スタック的にはアプリケーション寄りのところに取り組んできました。関連する話を何度かこの開発者ブログにも書いています。 ユーザー基盤を作り直しながらRailsでのサービス層に向き合う 巨大なWEBアプリケーションに巨大な変更を取り入れるためにやったこと この記事で触れている「電話番号による登録」について、チームメンバーが別の側面を紹介してくれています。 今日はそのあたりの開発を通じて考えた、Railsアプリケーションでのフォームオブジェクトやサービス層といったものが何であるか、という問いに対する、現在の自分のスタンスを紹介します。 サービス層、サービスオブジェクト、フォームオブジェクト もともと Railsは Web 画面から DB 構造までをあえて密
Submitting form data is a common feature of web applications – allowing users to submit their information and giving them feedback whether the information is valid or not. ActiveRecord comes with a powerful set of validators for attributes on a persisted data model. When data is not persisted, or used for other non-active record purposes, Active Model Helper Modules reduce the complexity of valida
The latest big ActiveRecord feature to Rails has been polymorphic associations. Not very clear at first, I found out they’re easier to understand with a couple examples. A common one: class Person < ActiveRecord::Base has_one :address, :as => :addressable end class Company < ActiveRecord::Base has_one :address, :as => :addressable end class Address < ActiveRecord::Base belongs_to :addressable, :po
こんにちは。メドピアのRuby(Rails)化をお手伝いしている@willnetです。最近はよくリファクタリングをしています。 今回は、最近僕がリファクタリングしている内容についてまとめようと思います。 メドピアではFat Model/Controllerを避けるために、rubocopの設定を利用しクラスの行数が300行以下になるよう制限しています*1。最近300行を超えるモデルが出てきたので、一部の処理を別のクラスに切り出し始めました。 このとき、Railsが提供している機能であるconcernsを利用すると楽に行数を減らすことができますが、それだとrubocopの指摘を回避できるという意味しかないので、なるべく委譲(composition)を利用して処理を別クラスに移していっています*2。 複数モデルにまたがる処理を切り出す Railsアプリケーションを書いていると、複数のモデルを一度
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く