エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
Rails で RESTful な URL にこだわらないと... - 杉風呂2.0 - A Lifelog -
記事へのコメント0件
- 注目コメント
- 新着コメント
このエントリーにコメントしてみましょう。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
Rails で RESTful な URL にこだわらないと... - 杉風呂2.0 - A Lifelog -
備忘録。 ダメなルーティングの臭い 名詞ではなく動詞が使われている resources/resourceよりもget/post... 備忘録。 ダメなルーティングの臭い 名詞ではなく動詞が使われている resources/resourceよりもget/post/put/patch/deleteが使われている コントローラ内にscaffoldで生成される7つのアクション以外のアクション定義が多い resources/resourceのonlyオプションで本来使われるべき7つのアクションがcollection/memberブロック中に登場する ダメなルーティングだと起こりえる問題 リソースの発見を逃す モデルとテーブルの発見を逃す 機能追加の際に、テーブルにNULL可なカラムを追加し、レコードをUPDATEする処理を書くようになる 1つのテーブルに複数の要件が盛り込まれ、モデルのコールバックなどで「関心事の分離」ができない状態になる しばしば正規化が崩れ、状態管理が複雑になる/過去の状態が追跡不可能になる コントローラにアク