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テーブルに詰め込むのは、コードの見通しという観点からも性能の観点からも、あまりよろしくありません。 なぜならば、ユーザ関連の情報を扱う局面としては主に メールアドレスとパスワードなどを使ってログインする（アカウント情報） プロフィール情報で条件を指定してユーザを検索・推薦する（プロフィール情報） という２つの独立性の高いユースケースにわかれるため、ログイン処理をやってるときにはプロフィール情報はいらないし、プロフィールを検索してるときにはメールアドレスやパスワードをロードするのは無駄です。また、開発やデ
LTSVをNginxで使ってみる - Hidden in Plain Sight
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' # '
はてなブログへのフィードバック - Hidden in Plain Sight
アンケートがきたのだけど、欄が狭かったので、こちらに書きます。 ひとことでいうなら、「あと一息で完璧」です。 まずシンプルで使いやすい。ベースデザインが見やすくなった。字がでかくてHigh DPIな環境で使いやすい。軽快に動く。テキストエリアがでかい。こういう、「ブログを書きたくなる」要素については、大満足です。 さらに、はてなブログには、（日本国内の）他社にない、決定的に良い点があります。 それは、「はてな記法」の存在です。 はてな記法が使えることには、WYSIWYGエディタにありがちな、モデルにビューが入り込んでるような気持ち悪さのない、「データをデータとして扱える」「exportしたときにゴミがない」「かといってHTMLみたいにpタグで囲む必要なく、改行だけでパラグラフを切れる」「本文を書くことに集中できる」という絶大なメリットがあります。はてな記法は、はてなブログ最強のアドバンテー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
