『事実はなぜ人の意見を変えられないのか』 不都合な真実から目を背ける人たち - HONZ
具体的な数字やデータを示してもダメ。明晰な論理で説いてもムダ。そんなとき、あなたはきっとこう思ってしまうのではないか。「事実はなぜ人の意見を変えられないのか」。 実際問題、日々の生活でそんな思いを抱いてしまう場面は少なくないだろう。失敗例がすでにいくつもあるのに、それでもまだ無理筋を通そうとする社内のプレゼンター。子育てのあり方をめぐって、何を言っても聞く耳を持ってくれないパートナーなど。また不思議なことに、たとえ高学歴の人であっても、「事実に説得されない」という点ではどうやらほかの人と変わらないようだ。 さて本書は、冒頭の問いを切り口としながら、人が他人に対して及ぼす「影響力」について考えようとするものである。心理学と神経科学の知見を織り交ぜつつ、著者は早々に厳しい診断を下す。 多くの人が「こうすれば他人の考えや行動を変えることができる」と信じている方法が、実は間違っていた…。 数字や統
実務で学んだRailsの設計・リファクタリング - Qiita
自分がRailsチュートリアルなどを一通りこなし、実務でRailsを書き始めてようやく学べたRails上でのコーディングのパターンをまとめてみたいと思います。 RailsTutorialを何周かやってみた、これから自分のアプリケーションを書くぞ、という方を想定読者においています。 MVCの責任分割について RailsはMVCにしたがってコーディングをしていく必要があるのですが、何がモデルで、何がコントローラーなのかというのは結構あいまいだったりします。 たとえば以下のような場合は、MVCがきちんと守れていない可能性があります。 コントローラー actionにトランザクションが書かれている ifが３回以上ネストされて書かれている ViewHelperがincludeされている モデル 表示のためにしか使わないようなメソッド（page_title等）がモデルに定義されてしまっている また、MV
Decorator と Presenter を使い分けて、 Rails を ViewModel ですっきりさせよう - KitchHike Tech Blog
はじめに こんにちは。KitchHikeエンジニアの小川です。 Webアプリケーション開発において、コードベースが大きくなってくると、よく問題になるものの一つが表示ロジックの重複ではないでしょうか。知らず知らずのうちにビューに同じようなロジックが増えて、コードの見通しが悪くなってくるのです。 KitchHikeのコードにもその兆候が見られはじめたので、対策として ViewModel パターンを取り入れています。このパターンを適用することで、表示ロジックを集約し、コードのメンテナンス性を向上させることができました。 ViewModel は、そんなに凝ったことをしているわけではないのですが、コードをすっきりさせる上ではかなり強力なパターンです。 今回はこの ViewModel について、実際の使い方を含めご紹介したいと思います。 ViewModelとは? 一言でいえばビューに関連するロジックを
Put chubby models on a diet with concerns
Different models in your Rails application will often share a set of cross-cutting concerns. In Basecamp, we have almost forty such concerns with names like Trashable, Searchable, Visible, Movable, Taggable. These concerns encapsulate both data access and domain logic about a certain slice of responsibility. Here’s a simplified version of the taggable concern: module Taggable extend ActiveSupport:
私はこれで Rails の Fat モデルにおさらばしました
ルビーオンレイルザーの皆さん、 Fat モデル対策やってますか。 Fat モデル対策と言えば Concern ですね。 app/models/concerns/ ディレクトリに module を置いてモデルに include させるというアレです。 しかしただ module を作って Fat モデルのコードを移動し、元のモデル側に include させるだけでは結局モデルのインスタンスに生えるメソッドの数に変わりはないので臭いものに蓋をしてるだけになります。 Rubocop の Metrics/LineLength 警告を逃れるためだけの module 乱立はあんまり意味がないでしょう。間違って別の module で同名のメソッドを定義してしまい意図しない挙動になってしまうことも考えられます。 最近自分がやってるのは、 include される module に定義するメソッドはせいぜい一つ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
