サービスクラスについては僕も悪かったと思っているけど、それでもCQSは実現したいんだ - Qiita
このエントリは Ruby on Rails Advent Calendar 15 日目です。（遅くなってすいません） 同時に 14 日目のじょーかーさんのエントリへのアンサーエントリでもあります。 （まあ、じょーかーさんがこの Advent Calendar に登録したときに、タイトルから内容を推察してこれを書くことを決めましたが、実際のところ、あまりアンサーにもカウンターにもなってないし、全然関係ない内容と言えないこともないので、まあサービスクラスについては僕も推奨したことがあるし、僕も反省してるんですよ程度に読んでもらえると幸いです。） まずはじめにごめんなさい 3 年くらい前に僕は Rails にサービスクラスというものを導入するといいことがあるよと書いたのだけど、それからいくつもの Rails アプリケーションを見たり、実際に自分で開発したりして、うーんって思うことも増えてきたので
Rubyを勉強する上で有用な情報源まとめてみた - Qiita
Rubyを勉強する上で役立つ情報源をまとめてみました。まだ仕入れていない情報源があれば価値がある記事なんじゃないかと思います。 書籍 Everyday Rails - RSpecによるRailsテスト入門 Rubyでテストコードを書くときは多くの人がRspecを使っていると思いますが、そのRSpecを学ぶ上で実用的な書き方が学べます。実践で頑強なプログラミングを書けるようになり、チームの人たちも安心して仕事を任せてもらえます。 メタプログラミングRuby Ruby力を高める上で必要な知識がメタプログラミングです。コードを読むのにも書くのにも知っているかどうかで大きく影響します。これを読みきった頃には中級者に達していると言っても良いでしょう。 パーフェクトRuby ここまで学んだ知識の穴埋めをしてくれるでしょう。実践力向上に役立ちます。 パーフェクトRubyOnRails Rubyを使う上で
再考: GoF デザインパターン - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 本投稿は私の主観によって書かれています。コメントは大歓迎です。もし長くなるようでしたら別途記事に投稿し、リンクを張っていただけると嬉しいです。 概要 GoFのデザインパターンは適当すぎるから、いい加減、修正されるべき。 参考までに各パターンに対するコメントを書く。 GoFのデザインパターン GoFのデザインパターンは適当であり、教科書通りに学ぶべきものではないように思う。 以下がGoFのデザインパターンの良くない原因だろう。 本が出版されたのは1994年であり、Java(1995)が出てくるよりも前だった オブジェクト指向が未成熟な時代
「これだけ」モデリング - Qiita
これだけモデリングとは **「これだけモデリング」**とは、メソドロジックの山岸さんが提唱されている「軽い」モデリング手法です（山岸さんはリーンモデリングとも呼んでいたがぼくはベタにこれだけモデリング、という日本語が好き）。 デベロッパーでなく情報システム部門目線で見て、どんどん複雑になる企業アプリケーションの要求や設計を見通しよく「共通合意」を作るための、「軽い」モデリングの必要性がテーマです。 そうなんです、従来は、「全部書かなきゃだめ」とか「全部メンテしないといけない」とか、「下流を触ったら上流までさかのぼって修正しなきゃ」とか足かせが多かったので、なかなか実装から遠いモデリングがペイしなかったのですね。だから、「これだけ」モデリングを提案したい、という訳です。 エンタープライズアジャイル時代のリーンモデリング（slideshare） これだけモデリングとは、 誰が？ ー 情報システ
Javaプログラマから見たJavaScriptデザインパターン(導入編) - Qiita
仕事などでJSを書くようになって少々経つが、Java信者で頭が固い僕にとってはどうもJSというのは柔らかすぎてしっくりこない部分が多い。 考え方を整理するにはデザインパターンを知るのが早いと、最近思い立ったので改めて調べてみた。 ということで、Javaは大体分かるし、JSも書くけどそこまで詳しくない人向け（つまり自分主体）にまとめておく。 今のところシリーズ化予定。 ※ JSの知識には自信ないので間違った点に気付いた方がいらしたらコメント等でご指摘いただけると助かります。 ※ デザインパターンとして挙げているコードは、個人的にアレンジしている場合がありますので、ご了承ください。 ０．はじめに 本編案内 内容に入る前に、予備知識をおさらい。要点ではないのでざっくり。 シリーズ案内 Javaプログラマから見たJavaScriptデザインパターン(導入編) Javaプログラマから見たJavaSc
てめえらのRailsはオブジェクト指向じゃねえ！まずはCallbackクラス、Validatorクラスを活用しろ！ - Qiita
ちょっと煽り気味のタイトルにしてみましたが、Railsで開発する時は意識的にOOPに寄せないとオブジェクトの力が活かせなくなるよってことと、Railsが提供しているクラスの責務を分割することを支援してくれる機能について話をします。 ActiveRecordの性質 Rails開発においては、モデル層にロジックを書いてコントローラーは薄くしろ、というのはしつこく言われているので、概ね浸透してきていると思います。 それに加えて、最近私が結構しつこく主張しておきたいのが、モデル = ActiveRecordでは無いよ、ということです。 ActiveRecordは成り立ちから言うと、ロジックとDBへの永続化をまとめてカプセル化するアーキテクチャパターンから来ています。(詳しくはエンタープライズアプリケーションアーキテクチャパターンという書籍を読むと良いです) この方法はロジックが複雑でない場合、つま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
