似ているようで全然違う!?Activerecordにおけるincludesとjoinsの振る舞いまとめ - Qiita
似ているようで全然違う!?Activerecordにおけるincludesとjoinsの振る舞いまとめRubyRailsActiveRecord Activerecordを使ってるとき、関連(Association)のあるmodel同士をまとめて取得したい時がけっこうある。そんな時、includesやjoinsを使えば効率良くデータを取得出来るんだけど、実はこの二つは振る舞いや特徴が全然違ってたりする。ややこしい気がしたので、ここでちょっとまとめておく。 先に結論を書いておくと、基本的には includesは先読みしてキャッシュしておく。 joinsはただINNER JOINしてくれる。 と思っておけばOK。 ちなみに、railsのversionは4.1.0。Web上に落ちてる情報は古いせいか若干現状の挙動とは違ってたりしたので、気をつけた方が良さそう。
Railsを作った男たち - Qiita
あいさつ Railsアドベントカレンダー16日目です. いい感じに中だるみして来たのでトンズラここと思いましたが筆、執りましたよ. Railsに限らずOSSのすごいエンジニア（小並感）に感化されるのは良い事だと思います. （画像の使用許可等はちゃんと取りました. 画像無い方は許可取れませんでした.） Railsは本当に多くの方々のお力によって作られているとは思いますが、 今回は僕の恣意的な選択によって数人の方を挙げさせて頂きました.（基本的にはコミット数） David Heinemeier Hansson(DHH) Github: dhh Blog: DAVID HEINEMEIER HANSSON Twitter: @dhh Railsの生みの親. 2004年7月にオープンソースとして公開するも、2005年の2月までコミット権を誰も渡さなかったとか. デンマーク生まれで写真家で尚かつカー
Sinatra frameworkに関する私見 - ローファイ日記
エクスキューズとか 正直な話をすると、Webフレームワーク自体に関する興味は以前に比べて失われてきているので、最新のSinatraの細かいコミットまでは追っていない。 だが、2年強ほど Sinatra/Padrino 界隈を追いかけてきて得た知見と言うか考えについてまとめるのは一定の価値がある、少なくとも自分に取っての価値は非常に大きいと思うのでここに書いていきたい。 副次的には、ミスコンセプトによってSinatraを利用して、結果必要の無いイメージの悪化を招く事態を一件でも減らせればと思う。 Sinatraはmicroframework、あるいは「フレームワークではない」 公式の説明にある通りである。 具体的にどういうことかと言うと、Sinatra単体ではウェブサービスに必要な要件を満たさないかもしれないと言う話である。Sinatraが持っていないものについては、Sinatra以外の場所
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
