ユーザとユーザを多対多で関連付けるモデルを共通化する - Hidden in Plain Sight
思いのほか前回のRailsプチ・デザインパターンの紹介に反応があったので、こういう小ネタも出していったほうがいいのかな、ということで第二弾。 ソーシャル系アプリだと、ユーザとユーザを関連付ける多対多のモデルがたくさんでてきます。たとえば、一般的なところではフォローとかブロックとか足あととか。さらにデーティングサイトになると、ウィンクだったり、Secret admirer（こっそりlikeするけど両思いだったらおめでとうって通知がくるってやつ）だったり、いろいろなモデルがこのパターンにあてはまります。 この場合、「AがBをフォローしている」「BがAをフォローしている」「AとBがお互いにフォローしている」という3つの状態があるわけですが、相互フォローの状態は「AがBをフォローし、かつBがAをフォローしている」と読み替えてSQLでも記述可能なので、以下ではシンプルに単方向のグラフで全てを扱うもの
プライマリキーを使った1:1関連でカラム数の多いテーブルを分割する - Hidden in Plain Sight
おそらく多くのソーシャル系アプリにあてはまるRailsのプチ・デザインパターン的な話。 ぼくが今やっているEast Meet Eastには、ユーザごとに数多くのプロフィール属性があります。名前、性別、生年月日、郵便番号、職業などなど、カラム数にしてざっと25個。これを、全部ひとつのusersテーブルに詰め込むのは、コードの見通しという観点からも性能の観点からも、あまりよろしくありません。 なぜならば、ユーザ関連の情報を扱う局面としては主に メールアドレスとパスワードなどを使ってログインする（アカウント情報） プロフィール情報で条件を指定してユーザを検索・推薦する（プロフィール情報） という２つの独立性の高いユースケースにわかれるため、ログイン処理をやってるときにはプロフィール情報はいらないし、プロフィールを検索してるときにはメールアドレスやパスワードをロードするのは無駄です。また、開発やデ
出口が開いてないと腰を据えられない - Hidden in Plain Sight
はてなブログ、使いやすいので気楽にいろいろ書きたいのだけど、なぜか本腰で書く気になれない。 理想的なブログツールを求めて自分でブログツールを開発してみたり、その途中でGhostを見かけて、やりたいことがほぼ同じだとわかったのでもう自分で作らなくていいやと応援する側に回ってみたり、と右往左往している。 そんな風に逡巡してる理由を自分なりに考えてみたんだけど、一言でいうと「ここにはエクスポート機能がないから」に集約される気がしてきた。実際、Ghostのフォーラムでも同じ質問をしている。 TwitterやFacebookのようなフローで垂れ流しのサービスなら、あまりそういうのは気にならない。そもそも情報を整理する目的で使ってないし、どちらかというとチャットの延長上でS/N比が低いから、再利用性の高い情報をそこに貯めていこうという動機が、ハナからない。 でも、ブログは違う。ブログは、ふわふわと浮い
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
