2015/10/31分のコミットです。 CHANGELOGにのったコミットは以下の通りです。 activerecord/CHANGELOG.md Added ActiveRecord::Relation#left_outer_joins. railties/CHANGELOG.md rails/application: allow passing an env to config_for Merge pull request #12071 from Crunch09/outer_joins Active Recordの修正です。 ActiveRecord::Relationにleft_outer_joinsメソッドを追加しています。 User.left_outer_joins(:posts) # => SELECT "users".* FROM "users" LEFT OUTER JOI

エンジニアをどう評価し、どう育てるか。自分自身そんな偉そうなことを言える実力を持ってるわけでもないんですが、最近考えざるを得ない機会が増えてきたので、自分の考えをまとめてみました。 エンジニアスキルの3つのレイヤー エンジニアのスキルは、大きく分けると3つのレイヤーがあると思っています。 1つ目は「業務スキル」。特定のプロダクトや会社に特有のスキルで、プロダクトや会社が変わると役に立たなくなるもの。 2つ目は「言語・フレームワークスキル」。いわゆる「rubyできます」「railsできます」みたいなやつですね。 そして3つ目は「汎用スキル」。会社や言語が変わっても使えるスキルです。 この3つはそれぞれオーバーラップする部分もありますが、汎用スキルが土台になって、その上に言語・フレームワークのスキルを構築し、一番上に業務スキルが乗っかってるイメージです。 じゃあその汎用スキルって何よ？っていう

Railsで中規模なサイトを作っていく上で 避けて通れないのが、増えてきたモデルを適切にキャッシュするしくみのように思えます。 特に変更が少ないマスタ的なテーブルに対して、『多対多』で関連付け(アソシエーション: association)がある場合などは、 それなりのSQLの発行コストになることがあります。そこを適切にキャッシュすることでDBへの負荷が減り、 ユーザーへのレスポンスが改善されると思います。 今回は、最近実装しているキャッシュの方法について、紹介したいと思います。 (というか偉い人、ぜひいい方法教えてください＞＜) 🍣 前提条件： RailsからRedisにキャッシュ今回は前提条件として、Railsのアプリケーションから『redis-store/redis-rails - GitHub』 のGemを使って、Redisにキャッシュをされているとします。 セットアップ方法は『r