このブログをDreamHostからHerokuに移しました。
% cd ~/Sites/cloister
% heroku create
% heroku git push heroku master
% heroku rake db:migrate
% heroku rake db:seed
その後docs.komagata.orgをproxy.heroku.org（proxy.heroku.comの間違い！別アプリで糞ハマった！）のCNAMEに設定しただけ。DBがポスグレって聞いてたからポスグレ用の設定にしなきゃいけないのかと思ったら何もしなくていいのね。糞思いDreamHostと違って速くなった！簡単だなぁ。
追記：ドメイン全部をherokuに向けたい場合はproxy.heroku.comのアドレスを全部@のAレコードに設定すればいい。
via 怒らないでいられる19の方法 - チョコっとラブ的なにか
俺が頭にくることといったらこの二つに尽きる。
２年ぐらい前、アパートの湯沸かし器が壊れて風呂に入れなくなったことがあった。アパートの備品なので管理会社を通して会社を半日欠勤してボイラー屋？に来てもらった。（仕事なんぞ風呂の前では小事）
ところが、新しい湯沸かし器を取り付けるには不動産屋の許可が入り、何故か連絡が取れないので土日挟んで３日後の月曜日まで何も出来ないと言う。
俺はこの時、自分は本当に頭にきた時は、カッとなるのではなく、逆に血の気が引いて冷静な嫌な奴になるタイプなのだということがわかりました。
を逆に質問した。
そうしたら、「一時的なテンポラリ湯沸かし器を今取り付け、月曜日に改めてパーマネント湯沸かし器を取り付け直す」というソリューションを提案してくれました。
風呂入れない如きで職業人生を全て否定されるぐらいだったらとりあえず取り付けとけという感じでしょうな・・・。
風呂入れない場合はどうやっても怒らないでいることは無理ですが、それ以外に関して怒らないでいるために心がけていること。
via システムエンジニア 生き残りの極意: 実はオブジェクト指向ってしっくりこないんです！
全ての最上位がObject（物）ってのがしっくりこない。OWLのowl:ThingみたいにObject（物）とThing（事）じゃない？その２つの上位に何かのクラスって感じで。オブジェクト指向分析が得意な人だと「事」を「物」で表現するのに慣れてるんだと思うんですが、最初違和感なかったですか？
その上位クラスが何なのかが分かりません。色んな言語のObjectの上位クラスが知りたい！ググり辛いんですよねコレ。絶対俺の知らないとこでぴったりの名前採用してる気がするんだけどな〜。
@jishihaさんに目の前でお手軽なデプロイ作業を見せてもらって、しかもLibreqのページ表示のサクサク具合に感動して試してみました。
Heroku Guickstart Guide見れば迷うところはありませんでした。
% sudo gem install heroku
% heroku keys:add
Uploading ssh public key /Users/komagata/.ssh/id_rsa.pub
Enter your Heroku credentials.
Email: komagata@gmail.com
Password:
Uploading ssh public key /Users/komagata/.ssh/id_rsa.pub
% rails foo
% cd foo
% script/generate controller top index
% rm -f public/index.html
% git init
% git add .
% git commit -m "first added"
% heroku create
% heroku rename foo1111
% git push heroku master
（首領への道風に）「え、えらい簡単やないか、兄弟・・・」
どこぞのサービス（DreamHost）のせいで「海外のサーバー ＝ 糞思い」というトラウマを植え付けられていました。更にVarnishのキャッシュサーバーも使えるとか。git pushがイコールデプロイになってるのが便利＋面白い＋怖いですが、herokuにもう一つ作って置くとか、githubとかpush先を複数用意しておけばグループ作業でも安心ですね。
 |
|
ゾンビ戦争。
いわゆるゾンビがアウトブレイクして世界中に蔓延したらどうなっちゃうのか？というのをゾンビ戦争後１０年たった各国の人へのインタビューをまとめた形式で語られる。
各国がパニックを経てどういう状態になるのかも面白いけど、ゾンビの原則（頭悪い・足遅い・脳を破壊しないと死なない）を踏まえた上で各地でこういうことが起こりましたよというシュミレーションが面白い。
ゾンビ映画は通してみた記憶が無いし、バイオハザードも２の途中で挫折したのでゾンビ好きな部類ではないんですが、著者の前作、The Zombie Survival Guilde: Complete Protection from the Living Dead(2003)とか他のゾンビ物映画もちょっと見てみたくなりました。
Capistranoでリポジトリには入れたくない設定ファイルはsharedなどに置いといて、deploy時にシンボリックリンクを張るといい。
ただし、deploy:migrateタスクより先にやらないとdatabase.ymlが見つからなくてエラー。currentが出来るのはdeploy:migrateの後（deploy:symlink）なので、下記のようにcurrent_pathではなくrelease_path（/var/www/foo/20100501062159みたいなヤツ）を使いつつdeploy:migrateより前に実行する必要がある。（deploy:finalize_updateはdeploy:migrateより前にある）
# config/deploy.rb
namespace :deploy do
desc "make symlink to config file"
task :symlink_config, :roles => :app, :except => {:no_release => true} do
run "ln -s #{deploy_to}/shared/database.yml #{release_path}/config/database.yml"
run "ln -s #{deploy_to}/shared/twitter_auth.yml #{release_path}/config/twitter_auth.yml"
run "ln -s #{deploy_to}/shared/newrelic.yml #{release_path}/config/newrelic.yml"
end
after 'deploy:finalize_update', 'deploy:symlink_config'
end同じシンボリックリンクを張るタスクだからっつってdeploy:symlinkの周辺でやるとハマる。（俺のことです）
今日のハマリ。
TwitterAuth::Dispatcher::Error (Status is a duplicate.):
oauth (0.3.5) lib/oauth/tokens/access_token.rb:44:in `post'
app/controllers/votes_controller.rb:25:in `tweet'
Tweet部分でエラーが返る。自分のアプリのせいだと思い込んでいたんですが、statusって何だ？ステータスってものは人に一つじゃないの？何でステータスがduplicateするんだ？
冷静に考えたらTweetは元々、メッセンジャーなどで使う「komagata@仕事中」の右の部分。それの遷移を時間軸で蓄積したものがタイムラインなのでつぶやきの公式な名前はpostでもtweetでも無くstatusだ。
同じ時間帯に全く同じstatusを送ったので「Status is a duplicate.」という訳でした。
もうGoogle日本語入力で補完して欲しい・・・。
railsのproductionでhamlのインデントが効いてない？
2.2.0
New Options
:ugly
The :ugly option is not technically new; it was introduced in Haml 2.0 to make rendering deeply nested templates less painful. However, it’s been greatly empowered in Haml 2.2. It now does all sorts of performance optimizations that couldn’t be done before, and its use increases Haml’s performance dramatically. It’s enabled by default in production in Rails, and it’s highly recommended for production environments in other frameworks.
新しいSyntaxが加わった2.2.0から深いネストが遅くなったのでproductionではデフォルトで:uglyオプション有効でインデント無しだそうです。
・・・・・・・・・。
こんな多数派の迫害にもう我慢ならないっ！
少数派の諸君！今すぐ下記のように:uglyオプションをぶち壊して政府転覆の恐ろしい計画を練ろうじゃないか！
# config/initializers/haml.rb
Haml::Template::options[:ugly] = false何だかんだ言ってもdevelopmentとproductionで挙動の違いの問題は出る。
# /etc/hosts
127.0.0.1 foo foo-production<VirtualHost *:80>
ServerName foo
DocumentRoot "/Users/komagata/Sites/foo/public"
RailsEnv development
</VirtualHost>
<VirtualHost *:80>
ServerName foo-production
DocumentRoot "/Users/komagata/Sites/foo/public"
</VirtualHost>こうしておくと便利。