Sooey

2010-11-17 01:37:59 +0900

Redisのサーバ側コードを読んでみるよ、という試み。

武器はTAGSファイルと$EDITOR、それにGDBだけというのがいい。とりあえず起動時の処理とリクエスト＆レスポンスの流れまでが解説済みで、次はSETとGETコマンドを追ってみるようです。

こちらも、Redisの歴史から特長、使い方なんかをチュートリアル風にまとめたサイト。

フォントやらデザインやらがなかなかポップでよい。

2010-11-17 01:18:50 +0900

アメリカのほうで新しいPathという写真共有用のソーシャルネットワークがスタートした。まずはiPhoneアプリからスタートということなんだけど日本のiTunes Storeでは販売されていないみたいなので、サイトのIntroducing The Personal Networkを読んで概要をわかった気になってみる。

  • Pathはパーソナルなネットワーク
    • 写真を家族や友人と共有することが目的
    • 自分がもっとも大切だと考える近しい人（家族や友人）50人までとの共有が可能
    • フレンドに設定できる上限が50人に制限されているため、写真をポストする際にあまりよく知らない人に写真が見られてしまうといったことを気にせずに済む
  • 写真にはPeople、Place、Thingという3つのタグでコンテキストを設定できる
    • このあたりはiPhoneアプリのスクリーンショットだけでは挙動がよくわからない…

とにかく「信頼できるネットワーク内だけでのpersonal momentsの共有」ということにフォーカスしたサービスみたい。

あと、Oxford教授の研究結果としてこんな話も引き合いに出されてる。

We chose 50 based on the research of Oxford Professor of Evolutionary Psychology Robin Dunbar, who has long suggested that 150 is the maximum number of social relationships that the human brain can sustain at any given time. Dunbar’s research also shows that personal relationships tend to expand in factors of roughly 3. So while we may have 5 people whom we consider to be our closest friends, and 20 whom we maintain regular contact with, 50 is roughly the outer boundary of our personal networks. These are the people we trust, whom we are building trust with, and whom we consider to be the most important and valued people in our lives.

5人まではとても親しい友人と思えて、20人まではよく連絡を取り合う間柄、50人になると個人的な繋がりの範疇を超える、といった感じかな。

Pathが受け入れられるかどうかはともかく、Flickrの共有範囲設定はもうちょっと細かくしたいなあと思うことも多いので、こういうアプローチもありなのでしょう。ただ、写真共有サービスの場合、とくに日本では「一緒に写真に収まる間柄」というのが「オンラインのつきあい」とはぜんぜん重ならず、写真を共有したい相手がそのネットワークに参加していないケースが大半だと思うので、そのあたりをうまいアプローチで解決して欲しいですね。

2010-11-16 12:54:47 +0900

HerokuにPG Backupsというアドオンが加わり、Heroku上のPostgreSQLからダンプ取得・リストアが簡単にできるようになった。詳細はPG Backupsのページに書かれているのでそちらを見たほうが早いでしょう。

手元で試してみたところ、当然ながら問題なく使えました。この簡単さはすごい。

heroku gemパッケージが更新されているのでアップデート。

$ gem update heroku

pgbackups関係のタスク一覧。

$ heroku help | grep pgbackups
=== pgbackups
pgbackups                                  # list captured backups
pgbackups:capture [<DB_ID>]                # capture a backup from database ID (default: DATABASE_URL)
pgbackups:url [<BACKUP_ID>]                # get a temporary URL for a backup
pgbackups:destroy <BACKUP_ID>              # destroy a backup
pgbackups:restore <BACKUP_ID> --db <DB_ID> # restore the database ID (default: DATABASE_URL) from a backup
pgbackups:restore <url> --db <DB_ID>       # restore the database ID (default: DATABASE_URL) from a URL

captureでダンプを取得、urlでダウンロード用のテンポラリURLを取得、restoreでダンプのリストア、destroyでダンプの削除という感じ。

アプリケーションにpgbackupsアドオンを追加する。

$ heroku addons:add pgbackups:basic --app sooey-journal
Adding pgbackups:basic to sooey-journal... done

ダンプを取得してみる。

$ heroku pgbackups:capture --app sooey-journal

DATABASE_URL  ----backup--->  b001

Capturing... done
Storing... done

これで、バックアップIDがb001のダンプが取得された。この時点ではダンプされたデータはHeroku側にあり、そのままリストアもできる。データを手元に持ってきたい場合はpgbackups:urlタスクにバックアップIDを渡すと、ダウンロード用のテンポラリなURLが返される。

$ heroku pgbackups:url b001 --app sooey-journal
http://s3.amazonaws.com/hkpgbackups/...
$ curl "http://s3.amazonaws.com/hkpgbackups/..." -o b001.dump
$ ls -l b001.dump
-rw-r--r--  1 juno  staff  44594 11 16 12:43 b001.dump