APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
プライマリキーを使った1:1関連でカラム数の多いテーブルを分割する - Hidden in Plain Sight
おそらく多くのソーシャル系アプリにあてはまるRailsのプチ・デザインパターン的な話。 ぼくが今やっているEast Meet Eastには、ユーザごとに数多くのプロフィール属性があります。名前、性別、生年月日、郵便番号、職業などなど、カラム数にしてざっと25個。これを、全部ひとつのusersテーブルに詰め込むのは、コードの見通しという観点からも性能の観点からも、あまりよろしくありません。 なぜならば、ユーザ関連の情報を扱う局面としては主に メールアドレスとパスワードなどを使ってログインする（アカウント情報） プロフィール情報で条件を指定してユーザを検索・推薦する（プロフィール情報） という２つの独立性の高いユースケースにわかれるため、ログイン処理をやってるときにはプロフィール情報はいらないし、プロフィールを検索してるときにはメールアドレスやパスワードをロードするのは無駄です。また、開発やデ
ユーザとユーザを多対多で関連付けるモデルを共通化する - Hidden in Plain Sight
思いのほか前回のRailsプチ・デザインパターンの紹介に反応があったので、こういう小ネタも出していったほうがいいのかな、ということで第二弾。 ソーシャル系アプリだと、ユーザとユーザを関連付ける多対多のモデルがたくさんでてきます。たとえば、一般的なところではフォローとかブロックとか足あととか。さらにデーティングサイトになると、ウィンクだったり、Secret admirer（こっそりlikeするけど両思いだったらおめでとうって通知がくるってやつ）だったり、いろいろなモデルがこのパターンにあてはまります。 この場合、「AがBをフォローしている」「BがAをフォローしている」「AとBがお互いにフォローしている」という3つの状態があるわけですが、相互フォローの状態は「AがBをフォローし、かつBがAをフォローしている」と読み替えてSQLでも記述可能なので、以下ではシンプルに単方向のグラフで全てを扱うもの
テスト考2014 - Hidden in Plain Sight
年々、ウェブアプリを開発するときにテストを書こうという機運が強くなっていると感じる。 これは、開発パラダイムの成熟を意味することであり、基本的に良いことだと思っている。 しかし同時に「テスト原理主義」とでもいうような極端な考え方もでてきていて、開発スタイルをめぐって摩擦が起こっている。 そして、この議論は「テストは、ないよりあったほうが良いよね」という、微視的には誰も反論できないロジックに押し通されがちで、「地獄への道は善意で舗装されている」の典型的な現象に見えて仕方がない。 テストを書かない、というと背景にどんな深い考えがあっても素人くさく聞こえ、逆にテストを書くというだけで良いプログラマーに見える、という非対称な化粧効果がある。ソフトウェア・コンサルティング会社がテスト好きなのは決して偶然ではない。 ソフトウェアというのは、結局のところ、動いてナンボ、使われてナンボである。 期待するも
さよならシリコンバレー - Hidden in Plain Sight
明日から、8年間住んだサンフランシスコ・ベイエリアを離れてラスベガスに引っ越します。 びっくりでしょ。いやー自分でもびっくりです。なんせ、そんなことは数ヶ月前までは考えたこともなかったからです。ある日の突然の思いつきで、ラスベガスにコンドミニアム（日本でいうマンション）を購入することを思い立ち、そこから3週間後には現地で契約書にサインしていました。いわゆる衝動買いというやつですかね。。。ともかく、あっという間でした。 で、このことを言うと、色々な人に「なぜ？」と怪訝な顔で聞かれるので、自分自身で整理する意味でもきちんと書いてみようと思いました。 結論をひとことでいうと「経済的な合理性」なのですが、まずは背景から。 高騰する家賃 サンフランシスコは、家賃がどんどん上がっています。どのぐらい高いかというと、2013年の現在、1ベッドルーム、日本でいう1LDK的な間取りの平均家賃が$2,700で
開発者のマシンを英語環境にしない理由はもはや一つもない - Hidden in Plain Sight
2011年も終りが近づいた昨今、日本の市場が今後どんどんシュリンクしていくことは、もはや子供でも知ってる周知の事実なわけです。 そういう時代にあって、開発者が日本語環境のマシンを使い続けることの意味は、よくよく考えたほうがいいと思うわけです。 個人的には、「世界中で使われるサービスを作りたい」といってる開発者のマシンをみて、キーボードがJISだったりOSが日本語だったりすると、もうその時点でかなりガクッときます。 とくに完全なる国際化が実現されているMacなら、キーボードさえBTOでUS仕様にしてしまえば、アメリカで売ってるMacと100%同じものになります。逆に言うと、アメリカで買ったMacでも、そのまま何の問題もなく日本語が使えるわけです。（実を言うと、現在アメリカのApple Storeでは、日本語JIS配列のキーボードを選ぶことさえできるようになっています） 買ったばかりのMacを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
