vimgrep（via ハタさんのブログ(復刻版) : vimのgrep(vimgrep)が素晴らしすぎて泣いた。）
:vimgrep /date_format/ **/*.php | cwinRailsというかCapistrano Tipsですが・・・。
リリースの時にタグを打つ & リリースの時にTweetする（ホントはXAuth使いたい・・・）
# config/deploy.rb
set :version, Time.new.strftime('%Y%m%d%H%M%S')
namespace :deploy do
desc "Create release tag"
task :tagging, :roles => :app, :except => {:no_release => true} do
run_locally "git tag v#{version}"
end
namespace :notify do
desc "Tweet release"
task :tweet do
require 'rubygems'
require 'twitter'
require 'pit'
config = Pit.get('twitter', :require => {
'consumer_token_key' => '',
'consumer_secret' => '',
'access_token_key' => '',
'access_secret' => ''
})
oauth = Twitter::OAuth.new(config['consumer_token_key'], config['consumer_secret'])
oauth.authorize_from_access(config['access_token_key'], config['access_secret'])
client = Twitter::Base.new(oauth)
msg = "Version #{version}をリリースしました。 http://help-me-hackers.com #hmh"
client.update(msg)
end
end
end
# config/deploy/production.rb
after 'deploy', 'deploy:tagging'
after 'deploy:tagging', 'deploy:notify:tweet'あとはpushするときpush --tagするようにする。
プログラミングタスクを共有する「Help me, hackers!」というサービスを作りました。（ちなみにこの書きだしはラペコをパクリました。）
一言で言うと「報酬支払いインフラを持った共有公開BTS」です。（報酬はPayPalで払える。もちろん報酬無しの単なるタスクもアリ）
我々プログラマーは趣味や仕事でプログラムを書きまくるわけですが、「何を作ってるのか」とか「何を作りたいのか」などは個人のTODOリストとか、会社のBTSに隠れて見ることが出来ません。それを公開・共有すれば有益なコミュニケーションができるのではないかと考えて作りました。
以前、このエントリーで書いたBTSを使ったリモートでのお仕事。こっちのエントリーで書いたお仕事がスゴく助かったのでこういうのがもっと簡単に行えるインフラとコミュニティーが欲しかったのです。当然極秘のタスクもあると思います。しかし、以前の例からも仕事・趣味に関わらず、公開していた方が結果的にお得なんじゃないかと。両方共良い成果が出たのはお二人ともリモートからオープンソース形式での開発に馴染んでいてスキルがとても高かったのが一番の原因だと思います。なので、そういった人が集まるコミュニティーを作るために、逆に興味無い人をフィルタリングしてしまうようにサイトを作りました。（IE6をわざと非対応にしたり・・・）
利用はTwitter認証を使っていてTwitterアカウント必須です。面倒な登録は無く、編集・削除も後から自由ですので、「今日の自分のタスク」や「おうちで作りたいもの」などを試しに登録していただけると嬉しいです。当初はもちろん僕が全てのタスクに対して全力で解決にあたりますｗ
RailsでProblemクラスをTaskクラスに変えるという感じのリファクタリングをvimでやる時の手順。（なるべく受け入れテストがある状態でやるのがいいと思った。今回は取り敢えずエラーが出ないことを確認するぐらいのテストしか無かったので怖かった・・・。）
% git checkout -b rename_problems_to_tasksとりあえず怖いので・・・。
% script/generate migration rename_problems_to_tasks# db/migrate/20100512071617_rename_problems_to_tasks.rb
class RenameProblemsToTasks < ActiveRecord::Migration
def self.up
rename_table :problems, :tasks
rename_column :comments, :problem_id, :task_id
execute "UPDATE taggings SET taggable_type = 'Task' WHERE taggable_type = 'Problem'"
execute "UPDATE votes SET voteable_type = 'Task' WHERE voteable_type = 'Problem'"
end
def self.down
rename_table :tasks, :problems
rename_column :comments, :task_id, :problem_id
execute "UPDATE taggings SET taggable_type = 'Problem' WHERE taggable_type = 'Task'"
execute "UPDATE votes SET voteable_type = 'Problem' WHERE voteable_type = 'Task'"
end
endMySQLとPostgreSQLには少なくともrename_tableがあるらしい。他は分からないです。belongs_toなテーブルのidも変更が必要。ポリモーフィック関連や単一テーブル継承を使ってる場合はクラス名が値として入ってるのでそれも変更。怖い！
% vim -c "argdo %s/Problem/Task/gce | update" {app,db,test,config}/**/*こうするとY/Nで確認しながら置換出来る。（ということを生放送で教えてもらいました。あざーす！） vendorが含まれるとうざいので除外。
% vim -c "argdo %s/problem/task/gce | update" {app,db,test,config}/**/*小文字で置換（こっちのが大体多い）
% find . -name '*problem*'% git mv app/helpers/{problems,tasks}_helper.rbファイル名もチェックして変更。おお怖い怖い・・・。
このブログを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の周辺でやるとハマる。（俺のことです）