アプリケーションを作るときに考える25のこと
This document contains code snippets and technical details from various programming languages and frameworks. It includes examples of database queries, model associations, HTTP requests, pagination, and tracking model changes in Ruby on Rails. Thread-local storage is demonstrated using RequestStore to make request information available across different parts of a Rails application.Read less
Railsの太ったモデルをダイエットさせる方法について - メドピア開発者ブログ
こんにちは。メドピアのRuby(Rails)化をお手伝いしている@willnetです。最近はよくリファクタリングをしています。 今回は、最近僕がリファクタリングしている内容についてまとめようと思います。 メドピアではFat Model/Controllerを避けるために、rubocopの設定を利用しクラスの行数が300行以下になるよう制限しています*1。最近300行を超えるモデルが出てきたので、一部の処理を別のクラスに切り出し始めました。 このとき、Railsが提供している機能であるconcernsを利用すると楽に行数を減らすことができますが、それだとrubocopの指摘を回避できるという意味しかないので、なるべく委譲(composition)を利用して処理を別クラスに移していっています*2。 複数モデルにまたがる処理を切り出す Railsアプリケーションを書いていると、複数のモデルを一度
新規プロジェクトがいつまでも良いコードであり続けるための、僕なりの5つのルール | FiNC Developers Blog
新規プロジェクトがいつまでも良いコードであり続けるための、僕なりの5つのルール はじめまして。FiNCでWeb Application Engineerをしている清水です。サーバーサイドからフロントエンドまで、アプリケーション全般の設計と実装を担当しています。 ウェルネスサーベイというプロジェクトをここ一年半やってきました。過去の新規プロジェクトをゼロからやることは何度かありましたが、やはりやる度にこうしておけばよかったという反省・学びがあるので一度まとめようと思います。ちなみに言語はRubyでRailsを使って開発しています。 新規プロジェクトの初期の一年で起こること新規プロジェクトの初期の一年は、エンジニアの視点で見れば度々来る 仕様変更 との戦いでした。 実際、今回の我々のプロジェクトにかぎらず、一定の仮説の上で始まるどんな新規サービスも、一年後にまったく同じ仕様というとは逆に稀で、
Railsで導入してよかったデザインパターンと各クラスの役割について - masato_hiのブログ
3年ほどRailsを書いてきてある程度知見が溜まってきたので、忘れないためのメモとしてKPTと導入例を交えながらダラダラと書いています。 見出しの命名規則は クラス名/ディレクトリ名の単数形をupper camel caseにしたもの + KPT です。 Keepは今後も使うもの、Problemは開発規模によっては問題が発生する(した)もの、Tryは現在使用していないが使用したほうが良いと思っているものです。 これらすべてを導入すれば上手くいくというわけでもないので、開発規模に合わせて適切に採用していくと良いと思います。 DDDやデザインパターン等見聞きはしているものの詳しいわけではないので間違っている部分等あるとは思うのでその辺りはコメントでご指摘お願いします。 はてブコメント欄で頂いた指摘内容等についてはまとめの後でまとめて返答を記載しています。 Asset (Keep) app/as
ソースコードの減らし方 - 基本的な考え方と10個の方法 - クラウドワークス エンジニアブログ
ステップ数で評価が決まる現場では全く役に立たないテクニックではありますが、ソースコードの減らし方について紹介したいと思います。 開発Div. エンジニアのayasudaです。 2014年の夏にジョインし、会社名と同じサービス、クラウドワークス の開発に携わっています。 ご覧の通り、消したソースコードの方が多いので、ステップ数換算だとマイナスの働きしかしてませんね！ 本記事では、特に Ruby on Rails の運用されているプロダクトコードにおける、ソースコードの減らし方について紹介していこうと思います。 基本的な考え方 ソースコードを減らすときの大原則は「ボーイスカウト・ルール - プログラマが知るべき97のこと」です。 普段、ソースコードを触るときに、一つでも良いので簡単な改善を入れる。これを積み重ねるのが大事です。 一度に一気に直そうとするのはあまり良くありません。大抵の場合、デグ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
railsのdefaultでは用意されていない考え方や設計、リファクタリングについてのリンク集 - Qiita
http://post.simplie.jp/posts/19