ユーザー基盤を作り直しながらRailsでのサービス層に向き合う - クックパッド開発者ブログ
こんにちは。パートナーアライアンス部の諸橋 (@moro) です。 突然ですが、わたしはいまクックパッドの「ユーザー基盤」を再構築しようとしています。 一口に「ユーザー基盤の再構築」といっても、そのゴールが何を指すかは(わたし自身にとってもまだ)漠然としており、固定されたゴールは見いだせていません。しかし後述するように、いくつかの問題は明確な形を取っています。言い換えると、それら明確な問題と向き合いながら『柔軟でいい感じのユーザー基盤を目指す』というのがこの再構築プロジェクトの目的です。 その第一歩目として、ユーザー登録部分を現状のクックパッド本体とは別の小さなRailsアプリケーションとして実装を進め、つい先日、一部の限定された利用者の方に向けて公開することができました。 今後も様子を見ながら公開範囲を拡大していく予定です。 再構築の背景 ではその「明確な問題」とはなんでしょうか。 最大
Rails のアーキテクチャ設計を考える - Qiita
はじめに ここ一年くらいずっと Rails の何がダメでどうすれば良くなるのかを考えていました。 Rails を使ってそれなりの規模のアプリケーションを作ったことがある人なら、メンテナンスのしづらさを感じたことがあるのではないでしょうか。 メンテナンスの問題は Rails 以外の開発でも発生することですが、実のところメンテナンスしやすいアプリケーションはどうすれば作れるのでしょうか？ この難問に対して私も答えを持っていませんが、考え続けています。 少なくとも、 Rails Way や Rails Tutorial をベースにしたアプリケーション開発は、業務で用いるには簡単すぎるように思います。 「レールに乗る」という言葉がありますが、私は考え方を変えました。 Rails は規模の大きいフレームワークですが、土台に過ぎません。 Rails Way の設計方針は小規模な開発では有効ですが、規模
Railsでサービスとフォームを導入してみる話 - assertInstanceOf('Engineer', $a_suenami)
この記事はRuby on Rails Advent Calendar 2013の6日目の記事です。 前日は @tkawa さんの「Favoriteの設計実装はパターンとして使える」でした。 Railsで適切に責務を分割するということ RailsはいわゆるMVCと呼ばれるアーキテクチャパターンにのっとったフレームワークであり、プロジェクトを作成するとデフォルトでmodels/、views/、controllers/などのディレクトリが作成されます。 基本的にロジックを記述する場所はモデルであり、ビューには表示処理だけを、コントローラにはアプリケーション上必要な手続きだけを記述するべきであると一般的には言われています。*1 ただ、それを忠実に実践していった結果、モデルが肥大化しメンテナンシビリティやテスタビリティが低下するという問題も多く指摘されています。 これについては4日目に @joker
てめえらのRailsはオブジェクト指向じゃねえ！まずはCallbackクラス、Validatorクラスを活用しろ！ - Qiita
てめえらのRailsはオブジェクト指向じゃねえ！まずはCallbackクラス、Validatorクラスを活用しろ！RubyRails ちょっと煽り気味のタイトルにしてみましたが、Railsで開発する時は意識的にOOPに寄せないとオブジェクトの力が活かせなくなるよってことと、Railsが提供しているクラスの責務を分割することを支援してくれる機能について話をします。 ActiveRecordの性質 Rails開発においては、モデル層にロジックを書いてコントローラーは薄くしろ、というのはしつこく言われているので、概ね浸透してきていると思います。 それに加えて、最近私が結構しつこく主張しておきたいのが、モデル = ActiveRecordでは無いよ、ということです。 ActiveRecordは成り立ちから言うと、ロジックとDBへの永続化をまとめてカプセル化するアーキテクチャパターンから来ています。
肥大化したActiveRecordモデルをリファクタリングする7つの方法（翻訳）
更新情報: 2013/11/19: 初版公開 2021/01/08: 訳文見直し、追記 こんにちは、hachi8833です。今回は、自分が知りたかった、Active Recordモデルのリファクタリングに関する記事を翻訳いたしました。1年前の記事なのでRails 3が前提ですが、Rails 4以降でも基本的には変わらないと思います。リンクは可能なものについては日本語のものに置き換えています。 なお、ここでご紹介したオブジェクトは、app以下にそれぞれ以下のようにフォルダを追加してそこに配置します。 注記: 以下は使われそうなフォルダを列挙しただけであり、実際にはこの一部しか使いません。 Value Object Service Object Form Object Query Object View Object Policy Object Decorator ⚓ 肥大化したActive
(小ネタ)システムコントロールテーブルは必ず用意しましょう
システムを構築すると、必ず「設定値」が必要になります。 ・1ページの表示行数 ・XXした際の遷移先URL ・YY通信のタイムアウト時間 ...etc 上記設定をどこに置くかは結構大きな問題です。 (例) ①propertiesファイル (javaの場合) ②xxx.rbファイル (rubyの場合) ③データベース ... 上記①や②は最速ですが、設定値の反映には「アプリケーションの再デプロイ or 再起動」が必要になります。よって気軽に変更値の変更という訳にはいきません。 ③はデータベースへの問い合わせが必要ですが、アプリケーション実行時に設定値を切り替えられるという利点があります。この手の設定値テーブルを用意しておくと顧客との打合せ時に、無駄な値決めに時間を浪費する事を回避できるというメリットもあります（顧客は情報がそろってから意思決定できるようになるので）。 よって、システムを開発して
Rails-resource-routing-design-bootstrap(ja)
Sendagaya.rb#12での講演資料に口頭のまとめを追記したものです。
Does My Rails App Need a Service Layer?
Does My Rails App Need a Service Layer? Jared Carroll · January 10th, 2012 Sometimes during domain modeling you come across something that isn’t a thing. These operations that don’t quite belong to an object are called services. Services often live in a separate, service layer. The service layer lies between controllers and models, defining an application’s interface, its API. Designing with servi
Railsでコントローラを継承して階層化すると効率よく開発できる - さかなチキンぱん。
ブログを移した為記事を削除しました。 新しいページへどうぞ
RailsでのURL設計を考えてみる(2) follow - ぶろぐ。@はてな
前回の「RailsでのfavoriteのURL設計」が思いがけなくそこそこ見てもらったようなので、いろんなパターンのURL設計を考えてみるシリーズをやってみたいと思います。（続くかどうかは未定） こんどはMioからは離れて、といってもほとんど同じようなものですが、Twitterのfollowのような機能を考えてみます。 Twitterの設計 考える前に、TwitterのWebサイトとAPIではフォロー関係の設計がどうなっているか参考に見てみましょう。*1 Webサイト URL フォローしている ユーザ（ツイート） /:screen_name/following フォローしている ユーザ /:screen_name/following/people フォローされている ユーザ /:screen_name/followers API*2 URL 追加パラメータ フォローしている ユーザ（ID）
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.func09.com/wordpress/archives/577