Sooey

2010-10-22 01:10:30 +0900

今月のRubyInsideのスポンサー一覧に、Recurlyという見たことがないサービスが入っていたのでちょっと調べてみたところ、どうやらサブスクリプションサービスの決済代行をやってくれるみたい。料金は1ヶ月200トランザクションまでのBasicプランが一番安くて「基本料金$29とトランザクション毎に$0.20」、上位プランだとトランザクション毎のフィーがどんどん割安になる。実際に使う予定があるわけではないのでそのあたりはどうでもよいのだけど、APIに加えて各種言語のライブラリがちゃんと提供されているところがいい。Rubyの場合はgemも用意されていてGitHubでソースも見れる(Rails3対応!)。コード例はこんな感じ。

# 口座作成
account = Recurly::Account.new(
  :account_code => 'rachael',
  :first_name => 'Rachael',
  :last_name => 'Test',
  :email => '[email protected]',
  :company_name => 'Chicago, Inc'
)

# 支払い情報作成
account.billing_info = Recurly::BillingInfo.new(
  :first_name => account.first_name,
  :last_name => account.last_name,
  :address1 => '123 Test St',
  :city => 'Chicago',
  :state => 'IL',
  :country => 'US',
  :zip => '60654',
  :credit_card => {
    :number => '1',
    :year => Time.now.year + 1,
    :month => Time.now.month,
    :verification_value => '123'
  },
  :ip_address => '127.0.0.1'
)

# サブスクリプションを開始
subscription = Recurly::Subscription.create(
  :account_code => account.account_code,
  :plan_code => PLAN_CODE,
  :quantity => 2, # Defaults to 1
  :account => account
)

# サブスクリプションプランをアップグレード
subscription = Recurly::Subscription.find('rachael')
subscription.change('now', :plan_code => 'platinum', :quantity => 3)

なんと試してみたくなるコードであろうか。こういうのを見ると、とにかくこのAPIを使って何かやってみたくなってきますね。日本の決済代行業者もこれくらい使いやすくしてくれるといいんだけど。

2010-10-21 10:36:00 +0900

Back to The Mac!

The new MacBook Air (2010) | Flickr - Photo Sharing!

新しいMacBook Airに乗り換える時にネックとなるのは「既存マシンのディスクのほうが容量がデカい(ので移行が大変)」じゃないでしょうか。こんなこともあろうかと僕は今年の始めにMacBookローカルディスク内のリストラを行い、数カ月前には320GB HDDから64GB SSDへのダウンサイジングも行いましたので、いつMacBook Airがプレゼントされても大丈夫です。

さて、その際にどのようなことをしたかというと、

  • iTunesとiPhotoのデータを外付けHDD(Drobo)に格納するようにした
    • 曲はiPhone 4に入っているし、出先ではどちらも必要なかった
  • 仮想マシンのファイルを外付けHDD(Drobo)に移動した
    • 僕の場合は出先でWindowsを使うことがなかったので
    • ただし、NASの場合は速度次第で仮想マシンの動作が結構遅くなります
  • リポジトリからチェックアウトしたコードのうち、当面必要ないものは一旦削除
    • Emacsのビルドに使ったソースなんかも削除
  • 不要なファイルをとにかく削除
    • DiskRingなどのユーティリティを使って、サイズの大きいものから着手していくと効果的

といったところです。これで64GBのうち25GBほどが空いた状態になっています。ただし、ちょっとデカいファイルをダウンロードしたりすると空き容量が危なくなってくるので、iStat Menuでディスク使用状況を常に表示するようにしています。ディスクにスワップファイルが作成されないように、メモリを潤沢に積んでおくのも重要かもしれない。

データのダウンサイジングが進むとバックアップも取りやすくなります。僕のいまのバックアップ戦略はこんな感じ。

  • Time Machine + Time Capsule
    • MacBook内の全データをバックアップ
  • MozyHome
    • Time Machineと並行してMacBook内のホームディレクトリ以下をクラウド上にバックアップ
    • 月額$4.95
    • バックグラウンドで自動的にバックアップをとってくれる
    • 使い始めはネットワーク速度が遅いのか2〜3日経ってもバックアップが完了しませんでしたが、1ヶ月くらい放っておいたらいつのまにかフルバックアップされてました(でも、リストアできるか確認していないという)
  • Drobo
    • iTunesとiPhotoのデータ
    • 仮想マシンのイメージ
    • その他、スキャンした書籍PDFなどデジタルコンテンツ一式

Droboは厳密にはバックアップではなくてデータ保護がされるストレージとして使っていますので、Drobo内のデータのうち、消失しては困るもの(書籍PDFとか)は定期的にAmazon S3やDreamHost(激安VPS)にもアップロードしてます。

2010-10-20 22:54:48 +0900

livedoor Readerで購読しているフィードがいつのまにか647件もあった。livedoor Readerはフツーに使っていると未読エントリ数くらいしか意識しないし、更新が止まったものもあろう。昨日読んだDownsize Your Digital Life | Becoming Minimalistには、

I subscribe to less than 10 blogs at any time, and only those that I legitimately care to read on a daily basis.

という話もあったので、フィードの整理をすることにした。

2010-10-19 23:05:04 +0900

アプリケーションやサービスはサインアップ時に必要な処理をとにかく減らすようにして、ユーザーがサービスに馴染んでから詳細な情報を入力してもらうようにしたほうがいい、という話(Gradual Engagement)。

Twitterの場合はサインアップフローの改善によって、登録完了までのコンバージョンレートが29%上昇したとか。

サインアップフローはサービスを作るときはどうしても後回しになりがちだし、いったんサービスが動き出してからはなかなか自分たちが使うこともないので、どの時点で作り込むかの判断は難しいね。おそらくコンバージョンレートをちゃんと計測して定期的な見直しをするような体制が必要なのだろう。