Sooey

2010-10-23 00:21:25 +0900

MailChimpというEメールマーケティング向けサービスがある。

ここはAPIをちゃんと用意していて、WordPressやMovableTypeをはじめとしたソフトウェアや外部サービスとの繋ぎこみも積極的にやってる、わりとわかってるところだと思う。そんなMailChimpのブログに書かれたEwww, You Use PHP?というエントリが盛り上がっていたので読んでみた。

Lately here at MailChimp we’ve been trying to bring in more developers to help us keep the innovation coming fast and furious as the application grows in scope and scale. It’s always been difficult for us to hire really good developers, just because of where we are. Our office is here in Atlanta GA, not exactly a hotbed of cool startups in the last few years. On top of that we’re fundamentally an email company, which is far from a sexy problem for geeks to sink their teeth into. But the biggest negative reaction we get when hiring new developers is when we mention the programming language we use.

Ewww, you use PHP? I though you were cool!

要は、MailChimpのシステムはほとんどPHPで書かれているのだけど、いいプログラマーを雇おうとする時にはいつもその点でネガティブな反応を受けてしまうという話。

PHP is considered by the programming elite, almost without exception, as one of the worst languages currently in use today. The term “good PHP programmer” is considered an oxymoron.

PHPはほぼ例外なく、プログラミングのエリートから「今日使われている最悪な言語のひとつ」と考えられている。「よいPHPプログラマ」という言葉は、矛盾した表現だとみなされる。

We’ve built a framework for developing applications in PHP specifically designed to allow for fast innovation the high-load, high-performance environment we live in every day while still keeping the API extremely simple to deal with. This isn’t your grandfather’s PHP, or even your slightly older brother’s. I can say without doubt that it is the most sophisticated framework for this environment that I’ve heard of except for perhaps what Facebook uses. Our architecture is heavily sharded, fast, and scalable to handle the absurd amount of growth we’ve had in the last few years.

MailChimpではクールで興味深い課題(彼らは自社の取り組む問題領域をそのように捉えている)を解決するために、PHPによるアプリケーション開発用フレームワークを開発した。彼らの環境にとってはこれ以上に洗練されたフレームワークはないとまで言っている。例外はFacebookのそれくらいだろうと。

So before you jump on that bandwagon thinking nothing interesting could possibly be done with PHP, think of us (or Facebook). You might be missing out on something great.

主張はわからなくもないけど、FacebookもYahoo!もMailChimpも「PHPを採用している」とは呼べないくらいの高度なレベルで利用しているような気がするので、それをあえてPHPでやる意味はないような気がする。多分、こういったプレイヤーがPHPを採用する理由は言語仕様以外の部分にあるんじゃないだろうか。少なくとも、FacebookもYahoo!もPHPの言語仕様を称賛したことは無い気がする。

そして、PHPを嫌う人たちの主張はその言語仕様に対するものが多い(ので、議論は結局のところ平行線)。

2010-10-22 01:34:38 +0900

37signalsのPodcastに寄せられた「どうやってプロジェクトやプロダクトに興味を持ち続けるようにしていますか?私は数ヶ月もするとプロジェクトに飽きてしまって…」という質問に対して。

  • Jamis
    • 2ヶ月以上も1つのプロジェクトに付きっきりにならないようなチーム体制になっている
    • 1つの機能にだいたい2〜3週間くらいの短いイテレーションで取り組むようにしている
    • それが片付いたら別プロジェクトで同じように作業にとりかかるので、取り組んでいる物事について飽きてしまうようなことはない
  • Jeff
    • プロジェクトに飽きてしまうということは、モチベーションが維持できない、いい仕事ができない、ということ
    • 我々は、物事を達成可能な小ささにしておくことを心がけている
    • 自分が飽きてきていることに気づいたときは、手を止めてこう考える:「今、自分が完成させられるものは何なのか?新しいと思える次の事に取り組むにはどうすればよいのか?」

Jeremyもいいこと言ってるっぽいけど抽象的なので訳さないでおく。

で、Jamisの言うチーム体制についてはA New Way of Working: A Two-Month Recapで触れられているみたいなんだけど、時間切れなのでまた今度。

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 => 'rachael@test.com',
  :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)にもアップロードしてます。