特定のRakeタスク内でのみ使うメソッドの定義方法
Rails内で使うRakeタスクに以下のようなものを使おうとしました。 namespace :task1 do task :do_something => :environment do foo end def foo p "task1" end end namespace :task2 do task :do_something => :environment do foo end def foo p "task2" end end namespaceで区切られているためfooメソッドは別のものとして解釈されると思っていたのですがオーバーライドされてしまいました。 特定のRakeタスク内からしか呼び出さないメソッドのスコープを限定するにはどうすればよいのでしょうか？ 特に決まった方法がないのであればtask1_fooなどのような命名規則を適用させようと考えています。
Railsのファットモデル問題に対処する前に読んでほしい記事 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 背景 Skinny Controller, Fat Model Railsではスキニーコントローラー、ファットモデル（Skinny Controller, Fat Model）という方針のもと、 コントローラーのコード量を少なくして、モデルを分厚くするという書き方が推奨されていました。 10 Ruby on Rails Best Practices — SitePoint Rails Best Practices 1: Fat Model – Skinny Controller このような背景から、ファットモデルという設計が目指すべき設
先人達から学ぶRailsのテーブル設計 - Qiita
はじめに Ruby on Rails Advent Calendar 2017 - Qiita の4日目の記事です。 背景 Railsのテーブル設計について、社内で議論することは多いのですが、サービスの要となる部分であるが故、社外にER図を公開するケースは少なく、自分達のサービス開発時以外にテーブル設計を学ぶ機会が少ないです。 目的 OSSで公開されているRailsアプリケーションのソースコードから、テーブル設計に関するデータをまとめることで、テーブル設計時の議論に活かすことを目的とします。 具体的には、「1テーブルが持つ情報量として、どれくらいのカラム数が妥当なんだろう…？」や「テーブル名やカラム名を命名する時にどちらの単語の方が一般的に使われているんだろう…？」といった疑問点の解消を目指します。 方法 OSSで公開されているRailsアプリケーションの見つけ方 AwesomeRails
もしDHHさんがCakePHPのコントローラーを書いたら - コネヒト開発者ブログ
こんにちは！乃木坂46の西野七瀬さんと誕生日が同じサーバーサイドエンジニアの@itoshoです。 僕は元々PHPerなのですが、ここ1〜2年くらいRubyを書く機会が多かったこともあり、最近はRubyでいいな！と思った考え方や技術をPHPに輸入することにハマっています。 そこで今日は少し古い記事になるのですが DHHはどのようにRailsのコントローラを書くのか を参考にして、Ruby on Rails（以下Rails）の産みの親であるDHHさんのコントローラーの書き方をCakePHPに取り入れてみたいと思います。 DHHさんのコントローラーの書き方 そこに至るまでの考えなどの詳細は元記事をご覧いただければと思いますが、要約すると、 RESTの原則に従う場合、コントローラはデフォルトのCRUDアクションだけを使い、その他のアクションは新たに専用のコントローラを作成する。 という考え方になり
Railsで導入してよかったデザインパターンと各クラスの役割について - masato_hiのブログ
3年ほどRailsを書いてきてある程度知見が溜まってきたので、忘れないためのメモとしてKPTと導入例を交えながらダラダラと書いています。 見出しの命名規則は クラス名/ディレクトリ名の単数形をupper camel caseにしたもの + KPT です。 Keepは今後も使うもの、Problemは開発規模によっては問題が発生する(した)もの、Tryは現在使用していないが使用したほうが良いと思っているものです。 これらすべてを導入すれば上手くいくというわけでもないので、開発規模に合わせて適切に採用していくと良いと思います。 DDDやデザインパターン等見聞きはしているものの詳しいわけではないので間違っている部分等あるとは思うのでその辺りはコメントでご指摘お願いします。 はてブコメント欄で頂いた指摘内容等についてはまとめの後でまとめて返答を記載しています。 Asset (Keep) app/as
REST について調べたまとめ - LukeSilvia’s diary
普段仕事でRails を使っている身ですが、Rails 2.x 系を使っているものが1つもない。結構前からRails 3 の話題がでてきている今、そろそろRails 2.x をまともに使っておきたいと思ったので、まずはREST について調べました。最初にREST について調べたのは、REST がRails 2.x (実際には1.2.x から)で導入された最も大きな概念だからです。 REST とは REST とはアーキテクチャスタイルである アーキテクチャスタイルとはデザインパターンのようなもので、システムを設計する上での方針をまとめたものである。 REST は「REpresentational State Transfer」の略である 直訳すると、「(リソースの)表現可能な状態の転送」。あるリソースの状態を表現したものがサーバからクライアントに転送されるのがREST。ここにでてきた「リソー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
