@kyanny's blog

My thoughts, my life. Views/opinions are my own.

Backbone.Collection

Backbone.Collection を読んだ。ざっと眺めただけ。

http://documentcloud.github.com/backbone/docs/backbone.html

  • toJSON が単に models それぞれの toJSON を map で呼んでるだけ、というのはきれい
  • add のなかで for を使ってるけど _.each とかではダメなんだろうか、 remove も同様
  • get と getByCid も同じロジックでよさそうなものなのに実装が違うのがなんか気になる
  • sort は comparator がないと例外を投げるようだけどデフォルトではなにも設定されないんだろうか
  • https://github.com/rails/rails/commit/a382d60f6abc94b6a965525872f858e48abc00de これみて pluck ってなんじゃらほいと思ってたけどまさかここで見るとは... (で未だにどういうニュアンスの単語なのかわからない)
  • Backbone.Model もそうだったけど通信発生するあたりをぜんぶ (this.sync || Backbone.sync ).call とかに移譲しててよくできてるなーと思う
  • reset と _reset とか、 API として公開するものと内部的なものとのポリシーがはっきりしている感じ、 API として公開するものは実装も自分自身や別クラス?の API を呼び出してるだけだったりして、実際に内部の値をいじるのは _hoge みたいなプライベートメソッドになるべく寄せる、みたいな
  • Backbone.Collection のインスタンス?が直接 .each とかを呼べるように prototype に _.each とかを突っ込んでいて、 JavaScript ではこうやって MixIn するのかーと

Rails の resources ルーティングの URL を collection の base url に指定すると何もかもうまくいくように作ってあって、なるほどねーと思った。 Rails を知ってたらどういうもののフロントエンドを作るときに使えばいいのかすごくイメージしやすいし、関数の命名も ActiveRecord に似せてるから「Model がインスタンスで Collection がクラスなのねはいはい」ととっつきやすい。 Rails の連中が作ったんじゃないのこれという気がしてくる (documentcloud がサーバサイドに何を使ってるのかは知らない)

Backbone.Model

Backbone.Model を読んだ。ざっと眺めただけ。

http://documentcloud.github.com/backbone/docs/backbone.html

  • initialize にデフォルトで何もしない関数を割り当てておくことで呼び出し時に isFunction とかでチェックしなくて済むワザ
  • escape の内容は初回呼び出し時にキャッシュ
  • set は呼び出し時に元の値をとっておいて値が同一でないもの(更新されるべき)だけ更新している。このチェックは変化した属性に対する change:xxx イベントの発火のために必要
  • unset でもバリデーションが走るのは何故だろう。 void 0 は undefined というグローバル変数の値にかかわらず常に undefined を返すんだっけか。 validObj に undefined をセットしてバリデーションを実行、やっぱりよくわからない。 !== undefined 的なバリデーションルールを考慮してるんだろうか
  • clear の for (attr in old) validObj[attr] = void 0; みたいに一行に詰め込むのを多用しているなーという印象がある、ブレース省略スタイルは個人的には採用したくないけどすっきり読めるとは思う
  • url を collection やら何やらからとってくるあたり
  • parse みたいな一段かます設計にしとくと汎用性が高まる

全体的に RubyActiveRecord っぽいなーと思った。メソッド名とか。そしてその思いは Backbone.Collection を読んでさらに強まるのであった。

30days Album はどのようにして画像にアクセス認証をかけているか

30days Album は画像の URL にもアクセス認証を入れています - 刺身☆ブーメランのはてなダイアリー の技術的な解説。基本的に 関西オープンソース 2008 30days Albumの裏側 のとおり。


ミドルウェアはこのスライドのときと比べてけっこう様変わりしている。 Perlbal は相変わらず使ってるけど。

  • リバースプロキシは nginx
  • バックエンドに Apache (Passenger) と Perlbal
  • 静的ファイルは nginx が配信
  • 画像の URL は Perlbal にプロキシ
    • 画像認証用の Perlbal Plugin がセッションストレージの Kyoto Tycoon に認証情報があるか問い合わせ
    • それ以外にも提携している外部サービスのために特定の IP アドレスは素通りさせたりしている
    • 画像ストレージは MogileFS なので X-REPROXY-URL などでよしなに配信
  • それ以外の URL は Passenger (Rails) にプロキシ
    • アルバムを閲覧するときは、
      1. Rails 側でログイン処理時にセッションストレージに認証フラグをたてる
      2. Perlbal はフラグをみてレスポンスを出し分ける

現状把握している問題点

  • ログイン認証なしで閲覧できるアルバムの場合は「最初にアルバムを閲覧したとき内部的にログインと同じ処理をする」のでアルバムの URL を一度も訪問してないと認証かけなくていい画像の URL も直リンクで閲覧できないまま(ブログとか外部サイトに貼り付けられない)
    • いまのところアドホックに「このアルバムは特別に許可」とかやってるけど oEmbed とかでちゃんと解決したい
    • アルバムじゃなくてフォトストレージのほうはインターネット全体に公開することも可能(新しく公開用の画像 URL ができる)

あと、規模的な話。 30days Album にある画像は MogileFS 調べで五億枚くらい (オリジナル画像だけじゃなくてリサイズしたサムネイル画像、あと一括ダウンロード用の ZIP ファイルも含む) なので、 Facebook, Picasa, mixi などと比べるとおそらく二桁か三桁、ひょっとすると四桁くらい少ないと思う(参考: はてなで約 41 億)その規模になっても今のような仕組みで画像へのアクセス認証の仕組みを維持できるかはわからない(このままではスケールしないと思うので)まぁ当然だけどこれをもって Facebook などより優れていると言うつもりはない。

こういう話も機会があればまた紹介したいですね。図を描くのが面倒だけど。

30days Album は画像の URL にもアクセス認証を入れています

Facebook にアップロードした画像の URL に直接アクセスすると非公開設定でも閲覧できるという話題が議論を呼んでいますが、 30days Album は画像の URL にもアクセス制限を入れています。

30days Album で作ったアルバムには、閲覧するための「合言葉」を設定できます。アルバム固有のパスワードみたいなものです。パスワードありのアルバムにはアクセス制限がかかっているので、この「合言葉」でログインしていないとアルバムは閲覧できません。さらに、アルバムにアップロードされた画像の URL にも同じアクセス制限がかかっており、画像に直リンクしても表示されません。

http://30d.jp/img/kyanny/66/469_large.jpg

プライベートな写真の共有には、プライバシーにより配慮した 30days Album をぜひご利用ください。

追記

技術者・専門家の方のために 30days Album はどのようにして画像にアクセス認証をかけているかについても書きました。

tmux: How to turn off paste-buffer keyboard shortcut

これはターミナルマルチプレクサ Advent Calendarのn日目*ではありません*

少し前に .tmux.conf に以下の二行を追記した。コピー/ペースト機能のキーボードショートカットを無効にしている。理由は誤爆によるオペミスの防止。前に「オペミス防止のために mysql> プロンプトではヒストリを無効にしている」という話を見聞きしたことがあり、それにヒントを得てやってみた。

unbind [
unbind ]

デフォルトで [ は copy-mode に、 ] は paste-buffer に割り当てられている。よく押し間違えて copy するつもりで paste してしまうことがあり、 mysql> プロンプトを開いたウィンドウで誤爆したときクリップボードにへんなものが入っていたら目も当てられないなとおそろしくなったので、頻繁に使うものでもないし、いっそ無効にしてしまった。 paste-buffer だけオフにすれば十分なんだけど、なんとなくこわいのでどっちのキーも押さない習慣をつけるように両方切った。上にスクロールするときは :copy-mode を都度入力するのでちょっと手間だけど、万一のときのリスクを考えたら十分見合うコストだと思う。