script/generate mailerでgenerateされるテストコードの@expectedはTMailのインスタンスらしく、生すぎなことがあります。
というわけで、お手軽にテストする方法をぐぐりました。

via http://sablog.com/archives/2006/03/14/how-to-test-actionmailer-in-ruby-on-rails

   1  class SampleMailerTest < ActionMailer::TestCase
   2    tests SampleMailer
   3  
   4    def setup
   5      # テスト時に配送したメールの配列を保存する。
   6      ActionMailer::Base.deliveries = []
   7    end
   8  
   9    def test_welcome
  10      to = "satoko@s21g.com"
  11      sender = to
  12      sender_name = "satoko"
  13  
  14      SampleMailer.deliver_welcome(to, sender, sender_name)
  15      assert !ActionMailer::Base.deliveries.empty?
  16  
  17      sent = ActionMailer::Base.deliveries.first
  18      assert_equal [to], sent.to
  19      assert_equal "expected title", sent.subject
  20      assert sent.body =~ /^Recommended by #{sender_name}. Enjoy!$/
  21    end
  22  end

Refs

http://wota.jp/ac/?date=20050731

近々使うかもしれないので。

http://www.amazon.com/gp/browse.html?node=201590011

用語

• Amazon Elastic Compute Cloud (Amazon EC2)
• Amazon Machine Image (AMI)
• Amazon S3 (Amazon Simple Storage Service)

まずはGettingStartedから

http://docs.amazonwebservices.com/AWSEC2/2008-02-01/GettingStartedGuide/
(注)下記は2006年10月12日時点での記事ですが、内容がGettingStartedと今も大体同じ感じです(コマンドもそのままぽい)。
ここギコ！さん乙！
http://kokogiko.net/m/archives/001772.html

必要なもの

• SSHクライアント
• JRE：version 5

何ができるのか

defaltで用意されているイメージに自由にツールインストールできる。
ただし、インスタンスを止めてしまうと加えた変更は全て破棄されてしまう。加えた変更も併せ再現可能な状況にしようと思えば、現在のインスタンスの状況をイメージ化して登録すればよい。

Refs

• 大量の計算をやってもらう

  • http://blog.lilyx.net/2007/07/05/amazon-ec2-introduction/
    インスタンス上のサービスにデータをアップロードするとお金がかかるので、計算だけに使うと、インスタンス数x稼働時間分のお金しかかからない。

• Railsアプリケーション開発向けのAmazon EC2イメージ

  • http://www.moongift.jp/2008/03/ec2_on_rails/
    ベースはUbuntu 7.10。MySQL（Amazon S3に自動バックアップしてくれる）、Apache、Mongrel、memcachedなどがインストール、Capistranoを使っての複数運用もOK.

• http://www.moongift.jp/2007/12/firefox_extension_for_amazon_ec2/

疑問

AMIインスタンスの再起動とOSの再起動って違うんだろうか。後で調べる。

Amazon EC2を人に勧めると必ず言われるのが、「インスタンスを再起動したらディスクが消えるのが怖い」。

これは「インスタンス」を再起動であって、OSを再起動してもディスクは消えないのだが、確かに起動に必要なファイルを消してしまって、OSが起動できなくなってしまうと、確かに取り出せなくなってしまいます。
http://blog.masuidrive.jp/index.php/2008/04/14/ec2-ersistent-storage/

ここのレビューがためになりました。ので抜粋。
http://highscalability.com/google-appengine-second-look

Developer Forum抜粋訳

• データベースのエクスポート機能はなし。自前で用意する必要あり。
• limitに気をつけろ
  • 1MB upload limit
  • 1000 database return limit
  • Google limits your CPU usage
• フルテキスト検索はサポート対象外
• SessionはGoogleのを使え：djangoのauth, sessionは使えない
• 遅い：It takes GAE almost 3 seconds to save 50 of dummy records (consisting of just 2 text fields).

以下、自分用メモ。

GAEでの注意

• MySQLとBigTableは全然違う観点で作られている
  ちょっとのデータをめっちゃくちゃ早くするというものがゴールでなくて、多くのデータを処理し、分散させるというゴールにもとづいてデザインされている。
• web appの開発ノウハウは全然役に立たない(Sessionがないとか、JOINがないとかが大きい理由？)
• AWSのノウハウはGAEでは全然役に立たない(GAEはvm。モデルが違う)

早くするコツみたいなもの：遅いのは使い方が良くないから

例えばavg()、データをInsertする時に計算しておいて、表示するだけのほうがよい。
MYSQLだとアクセスがあったときにJOINして計算するのが普通だろうが、GAEではデータは分散されて保存されるので(+JOINがない)、そのたび計算するのだと遅くなる。
Insert時に計算はすべて終わらせて、あとはSelectだけということか。

Refs

http://hiroshiykw.blogspot.com/2008/04/google-app-engine_10.html