俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - Qiita
ちなみに、最初に結論だけ言っておくと、まずSandi Metzの「オブジェクト指向設計実践ガイド」を読め、という話です それだけで終わってしまいたい気持ちはあるが、不親切過ぎるしもうちょっとRails向けの話を書こうと思う。 ただ言いたいことは、よく分かってないのに使うのは止めろということ。 自分も本で書いたりした手前、それが参考にされた結果なのかもしれないが、世の中には本当に酷いクラスが存在するもので、雑にサンプルで書くと以下の様な感じのコードが存在したりする。 class HogehogeService # Hogehogeはモデル名まんま def process(hogehoge, option_a: nil, option_b: nil, option_c: false) history = hogehoge.histories.last unless hogehoge.activ
開発しやすいRails on Docker環境の作り方 - Qiita
最近、Rails界隈でDocker使い始めました、という話を聞く機会が増えてきたので、自分が開発環境整備用に構築したDockerの設定をまとめておく。 ちなみに、production運用については以前書いたので適当に探してくださいw 結論から書いておくと、volumeをちゃんと活用すればいい、ってだけの話です。 まず、本番用と開発用のDockerfileは分けた方が良い。一つでやろうとするとどうにも無理がでるので。 自分はDockerfileとDockerfile-devというものを用意している。 docker-composeはほぼ必須です。少なくともrailsプロセスとDBだけでも二つは必要だし、Dockerfileを分けてると事故るので。 Dockerfileはこんな感じ。 FROM mybase:ruby-2.3.1-debian RUN echo "deb http://http.
production環境でRailsアプリをdockerコンテナとしてECSで運用するために考えたこと - Qiita
実際には、まだ本当の本番環境では運用できてなくて開発用のステージングで運用が開始できたぐらいで、他にもやること一杯あるんだけど、ある程度知見が溜まったのでまとめておく。 ちなみに、規模はそんなに大きくないがデータ量は多いアプリケーションで運用環境はAWSのECSを想定しており、現時点で普通のEC2ノードとコンテナで並行稼動している。 docker-swarmなりで自前でコンテナプールを構築してもいいのだが、そうするとサービスディスカバリとか考えなければいけないことが増えるので、後回しにしている。 (注: かなりサービス固有の事情が含まれるため、もし参考にされる方が居たとしても、そのままの形では適用できない可能性が高い) 追記: RailsアプリのためのDockerfileとdocker-compose.ymlのサンプル - Qiita コンテナ化のモチベーション CentOSのお守りからの
Ruby製のシンプルなワークフローエンジンRukawaの紹介 - Qiita
Bigqueryを使ったバッチジョブを色々と実行しているのですが、Rakeで複雑な依存関係を管理したり、並列実行させたりするのが辛くなってきたのでRukawaというワークフローエンジンを自作しました。 自作したのは、RailsプロダクトにAirflowとかLuigiとかAzkabanとか入れるにはちょっと重厚過ぎる感じだったのと、Rubyで書ける方が楽で良いやという理由からです。 RukawaとはRUby KAntan Workflow Assistantの略です(後付け) (本当はミッチーとか水戸の方が好きなんだけど良い名前が浮かばなかった) 実際は、並列実行を可能にして書き方を変えてみたRakeとそんなに大差無い。 Rukawaの機能 ジョブの定義 まず実行したい処理をジョブクラスに記述します。 module ExecuteLog def self.store @store ||= {
Railsと周辺のTimeZone設定を整理する (active_record.default_timezoneの罠) - Qiita
まず、ここまでで一旦整理する。 Time.nowはRubyの組み込みなのでシステムのタイムゾーンしか見ない。OSの時間と常に一致する。Time.localの出力結果もOSのタイムゾーンと一致する。 TimeWithZoneクラスはconfig.time_zoneに左右される。 Ruby組み込みのメソッドで取得したUTCの時間を基準に、設定されているタイムゾーンの時間に変換する。 ActiveRecordのインスタンスに対してアクセサを利用して時間をやり取りする場合はTimeWithZoneで行われる。 仮にTimeクラスを渡しても代入時にTimeWithZoneに変換される。 config.active_record.default_timezoneの設定はDBを読み書きする際に、DBに記録されている時間をTime.utcで読むかTime.localで読むかを設定する。 :utcの場合DB
ActiveRecordの読み込みが実際にトリガーされた場所をログに記録するgem - Qiita
ActiveRecordは必要になるまでDB読み込みをしません。 なのでやたら複雑なビューの中でクエリを弄ったり、コントローラーが肥大化してる状態でひどいSQLがログに流れてくると、パっと見ではどこが原因なのかすぐに分からない。 なので、SQLが実行された時にそれが実際にトリガーされたソースコードの位置も一緒にログに吐いてくれるgemを作りました。 bulletで分からないような、ビューのループの中で直接モデル読んでるみたいなヤバイ箇所を速やかに見つけるためのものです。 joker1007/activerecord-cause 仕組み的にはActiveRecordのロギングの仕組みを丸パクリしてcaller_locationsを足した感じ。 全ての読み込み位置を表示するわけではなく正規表現でマッチするパスを持ったソースコードの位置のみをログに記録します。 Railsで利用する場合は自動的に
てめえらのRailsはオブジェクト指向じゃねえ！まずはCallbackクラス、Validatorクラスを活用しろ！ - Qiita
てめえらのRailsはオブジェクト指向じゃねえ！まずはCallbackクラス、Validatorクラスを活用しろ！RubyRails ちょっと煽り気味のタイトルにしてみましたが、Railsで開発する時は意識的にOOPに寄せないとオブジェクトの力が活かせなくなるよってことと、Railsが提供しているクラスの責務を分割することを支援してくれる機能について話をします。 ActiveRecordの性質 Rails開発においては、モデル層にロジックを書いてコントローラーは薄くしろ、というのはしつこく言われているので、概ね浸透してきていると思います。 それに加えて、最近私が結構しつこく主張しておきたいのが、モデル = ActiveRecordでは無いよ、ということです。 ActiveRecordは成り立ちから言うと、ロジックとDBへの永続化をまとめてカプセル化するアーキテクチャパターンから来ています。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
