はてなブックマーク

思いのほか前回のRailsプチ・デザインパターンの紹介に反応があったので、こういう小ネタも出していったほうがいいのかな、ということで第二弾。 ソーシャル系アプリだと、ユーザとユーザを関連付ける多対多のモデルがたくさんでてきます。たとえば、一般的なところではフォローとかブロックとか足あととか。さらにデーティングサイトになると、ウィンクだったり、Secret admirer（こっそりlikeするけど両思いだったらおめでとうって通知がくるってやつ）だったり、いろいろなモデルがこのパターンにあてはまります。 この場合、「AがBをフォローしている」「BがAをフォローしている」「AとBがお互いにフォローしている」という3つの状態があるわけですが、相互フォローの状態は「AがBをフォローし、かつBがAをフォローしている」と読み替えてSQLでも記述可能なので、以下ではシンプルに単方向のグラフで全てを扱うもの

おそらく多くのソーシャル系アプリにあてはまるRailsのプチ・デザインパターン的な話。 ぼくが今やっているEast Meet Eastには、ユーザごとに数多くのプロフィール属性があります。名前、性別、生年月日、郵便番号、職業などなど、カラム数にしてざっと25個。これを、全部ひとつのusersテーブルに詰め込むのは、コードの見通しという観点からも性能の観点からも、あまりよろしくありません。 なぜならば、ユーザ関連の情報を扱う局面としては主に メールアドレスとパスワードなどを使ってログインする（アカウント情報） プロフィール情報で条件を指定してユーザを検索・推薦する（プロフィール情報） という２つの独立性の高いユースケースにわかれるため、ログイン処理をやってるときにはプロフィール情報はいらないし、プロフィールを検索してるときにはメールアドレスやパスワードをロードするのは無駄です。また、開発やデ

年々、ウェブアプリを開発するときにテストを書こうという機運が強くなっていると感じる。 これは、開発パラダイムの成熟を意味することであり、基本的に良いことだと思っている。 しかし同時に「テスト原理主義」とでもいうような極端な考え方もでてきていて、開発スタイルをめぐって摩擦が起こっている。 そして、この議論は「テストは、ないよりあったほうが良いよね」という、微視的には誰も反論できないロジックに押し通されがちで、「地獄への道は善意で舗装されている」の典型的な現象に見えて仕方がない。 テストを書かない、というと背景にどんな深い考えがあっても素人くさく聞こえ、逆にテストを書くというだけで良いプログラマーに見える、という非対称な化粧効果がある。ソフトウェア・コンサルティング会社がテスト好きなのは決して偶然ではない。 ソフトウェアというのは、結局のところ、動いてナンボ、使われてナンボである。 期待するも

はてなブログ、使いやすいので気楽にいろいろ書きたいのだけど、なぜか本腰で書く気になれない。 理想的なブログツールを求めて自分でブログツールを開発してみたり、その途中でGhostを見かけて、やりたいことがほぼ同じだとわかったのでもう自分で作らなくていいやと応援する側に回ってみたり、と右往左往している。 そんな風に逡巡してる理由を自分なりに考えてみたんだけど、一言でいうと「ここにはエクスポート機能がないから」に集約される気がしてきた。実際、Ghostのフォーラムでも同じ質問をしている。 TwitterやFacebookのようなフローで垂れ流しのサービスなら、あまりそういうのは気にならない。そもそも情報を整理する目的で使ってないし、どちらかというとチャットの延長上でS/N比が低いから、再利用性の高い情報をそこに貯めていこうという動機が、ハナからない。 でも、ブログは違う。ブログは、ふわふわと浮い

前回、サンフランシスコからラスベガスへ引っ越しますという報告をしてから1ヶ月が経ちました。実はこの間、怒涛の1ヶ月でした。 まず、あの直後にパンカクの事業がコロプラに譲渡されることが決まりました。そして、7月31日をもってパンカクを正式に退職することが決まり、この4年間の旅は終着点へとたどりつきました。 思い返せば、2009年にインフォテリアUSAを閉鎖することが決まったとき、日本発のiPhoneアプリとして堂々の全米No.1を獲得したLightBikeというゲームを作っている会社から、「このゲームの人気を軸に対戦ゲームのプラットフォームを作って一緒に米国市場を攻めないか？」と、代表のやんくんから声をかけてもらったのが、パンカクとの運命の出会いでした。 その後、Pankiaと名付けられたそのプラットフォームは、iOS / Android / サーバサイドそれぞれ1-3名からなる少数精鋭のチ

明日から、8年間住んだサンフランシスコ・ベイエリアを離れてラスベガスに引っ越します。 びっくりでしょ。いやー自分でもびっくりです。なんせ、そんなことは数ヶ月前までは考えたこともなかったからです。ある日の突然の思いつきで、ラスベガスにコンドミニアム（日本でいうマンション）を購入することを思い立ち、そこから3週間後には現地で契約書にサインしていました。いわゆる衝動買いというやつですかね。。。ともかく、あっという間でした。 で、このことを言うと、色々な人に「なぜ？」と怪訝な顔で聞かれるので、自分自身で整理する意味でもきちんと書いてみようと思いました。 結論をひとことでいうと「経済的な合理性」なのですが、まずは背景から。 高騰する家賃 サンフランシスコは、家賃がどんどん上がっています。どのぐらい高いかというと、2013年の現在、1ベッドルーム、日本でいう1LDK的な間取りの平均家賃が$2,700で

id:stanaka のLTSVがバズってるみたいなので乗ってみた。（Hacker Newsにもポストしたんだけど、瞬時に流れてしまったよ。。） Nginxでの設定を（主にキーの命名で）1時間ぐらい試行錯誤した結果、とりあえず以下に落ち着いた。 log_format ltsv 'ts:$time_iso8601\t' 'ip:$remote_addr\t' 'method:$request_method\t' 'path:$request_uri\t' 'status:$status\t' 'size_req:$request_length\t' 'size_res:$bytes_sent\t' 'size_body:$body_bytes_sent\t' 'time_req:$request_time\t' 'time_app:$upstream_response_time\t' # '

ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー