Herokuでwww.foo.comとかじゃなくfoo.comのようなrootドメインを使うのは面倒です。 （root, naked, bare, zone apex domainなど色んな呼び方があるのもググり辛くて面倒な要因）
以前は「このIPをAレコードに設定してね」と公式ドキュメントにも書いてあったのですが現在は「SimpleDNSなどの仮想Aレコード的なものが使えるサービスを使え、もしくは逆に考えるんだ。rootドメインなんて使わなくってもいいさ・・・と。」と書いてあります。
そんなジョースター卿のような逆転の発送はなかなかできませんし、SimpleDNSは$3/moだったりしてちょっと高い。
ところが12レコードまで無料でHeroku向け設定をポチッとやってくれるDozensというサービスを発見。
ワーオ！Add Heroku Records?なんていうチェックボックスがあるぞ！
こいつはくせえ、名サービス以上の匂いがプンプンするぜ！
お名前.comのDNSなんて使ってる場合じゃねえ！
最近知ったんですが、
$ ey deploy --no-migrateこうやってmigrateしなければ無停止でデプロイできる。
migrateアリの時はDBの整合性を保つために開始時にmaintenance.htmlになって終わったら戻る。これは非常に納得感のある挙動。
これの有無でEYC選ぶかどうか変わるレベルなので声高に叫びたい。
おはようございます。高熱を出したまま35歳、アスキーコードで言えば#歳になりましたkomagataです。
間違えてて去年書くはずだったプログラマー35歳定年説について。（その来年がきたよ～、見てる〜？ ＞ 俺）
「フィジカル、メンタルで衰えてくる」とか「マネジメントへの参加要求が強まり自然にプログラミングから遠ざかる」とか「求められる成果の総量が上昇するのでしかたなく」という面も確かにあると思います。
しかし、
「平均的なキャリアプランなんぞ知ったことか。こっちは大手町辺りに派遣されてスーツで一生デスマ案件でJavaを書き続ける覚悟は完了してるんだよ！」
という我々にとっては関係ありません。にも関わらず我々が長文を書いてしまうのはなぜでしょう？
それは「誰も見てなくても関係ない」「真理鉱山に篭って一生続けられる」はずのプログラミングに35歳ぐらいになると飽きてしまうのではないか？という恐怖のせいです。
アラサーぐらいで社内でもいわば中堅になり、プロジェクトマネジメントやお客さんとの折衝が仕事の中心となっていた時、僕も若干プログラミングに飽きていました。勿論夜中や休日にコードを書いていましたが、仕事ではミドルウェア選定時のプロトタイプ作成とかやばそうな部分をちょこっと書くぐらい。そのころAjaxが流行っていましたがイマイチやる気になれませんでした。
「Webアプリは結局DBだろう、どの言語でも大して変わらない」
みたいなことを思っていました。
そもそもプロジェクトマネジメント自体、体育会系の部活のような一体感があるし商売が上手く行くようになって喜ぶお客さんを見るのも楽しい。プログラミングから離れていくのも自然な流れに見えます。
ちょうどその頃、会社を辞めて毎日新宿のシアトルズベストコーヒーに一人通って朝から晩まで自分のWebサービスのコードを書く生活が始まりました。するとプログラミングに対するモチベーションがどんどん上がっていくのを感じました。
「Javascript超楽しいじゃん。片っ端から全部自分で書きたい。こんな感じだったら他の言語もきっと楽しいはずだ。」
そのあとrubyとか書き始めたりして今に至ります。
その時体感でわかったのが、プログラミングは「やればやるほど飽きる」というモデルではなく「離れれば離れるほどつまらなくなり、近づけば近づくほど面白くなる」というモデルなんだなーということです。身近になればなるほど面白くなる。上達すればするほど夢中になるというのは当たり前な感じもしますが、一定以上ハマれる対象には共通しているモデルなのかもしれないなと思いました。
そんな体験があってからようやく僕は、もし土星の衛星エンケラドゥスへの有人探査ミッションの依頼（多分片道20年ぐらいかかる）がきたとしても、
「ネットが繋がるなら」
と快諾できる心の安定を取り戻したのでした。
EYCでのステージング環境問題ですが、料金シミュレーターで見積もってみたらsmallを一台だけ立ち上げれば6119円だそうなのでEYCにステージング環境を作ってみました。
こんな感じです。
staging環境はRails.envがstagingになります。そんなの大丈夫なのかよとおもいますが、37signalsも色々とenv作ってるようなので予想外のことはそれほど起きないです。
変える必要があるところ
if Rails.env.production?となってるところをif Rails.env.production? or Rails.env.staging?に変える。group :production doとなってるところをgroup :production, :staging doに変える。ものに応じてproductionだけでやりたいこと、production or stagingでやりたいことがあるので慎重に選ぶ必要があります。
例えば公式Twitterアカウントで通知する部分や本物の広告配信はproductionだけでやりたいでしょうし、S3を使うかどうかというのはproduction or stagingでやりたい。
デプロイといっても色んな意味が含まれてて、コンパイル・テスト・パッケージング・リリースをひっくるめてデプロイと言えますが、Railsだと大抵テストのみをさしてデプロイと言う。
実際のRailsアプリはリリースで問題が結構起きるのでこれを含めてCIしたい。
EYCはeyコマンドでリリースするので怖話ではこんな感じ。
弊社の場合はpushされるたびに↓のような通知がくるが、まあいい。
受託開発でEYCを使う場合はステージング環境代金もちゃんと見積りに入れると良いと思います。
jenkins, rspec-railsの場合。
# Gemfile:
group :test do
gem 'ci_reporter'
endRakefileの最終行に下記を追加する。
# Rakefile:
require 'ci/reporter/rake/rspec'rake specの代わりにrake ci:setup:rspec specを実行するとspec/reports/以下にテスト結果のxmlができるので.gitignoreに追加しとく。
spec/reports/Build時にrake ci:setup:rspec specでxmlが出力されるようにしておく。怖話ではこんな感じ。
bundle install --binstubs
cp config/database.example.yml config/database.yml
rake db:migrate
rake ci:setup:rspec specPost-build Actions > Publish JUnit test result reportを追加し、spec/reports/*.xmlを入力。JUnitがこういうxml出すみたい。
下記のようなグラフが出るようになる。怖話ではこんな感じ。
画像を直リンできるので目につきやすいところに貼るのがいいかも。
dm-validations-i18nがノルウェーのボークモールに対応しました。
何言ってるかわからんかもしれんが俺もです。
Engine Yard Cloudのstagingをどうするか悩んでます。
1はstagingへのdeployを含めてCIしたいので立ち上げっぱなしではお金が厳しい。
2はEYCへはeyコマンドでdeployし、さくらVPSでへのcapistranoでのdeployになり、環境もかなり違うのでstagingにならない。同じ理由でherokuも微妙。
3はまだやったこと無いが、さくらVPSにVirtualBoxを入れてEYLは実用的なのかわかってない。またeyコマンドでEYLへデプロイが可能かどうかも気になる。
EYCにかぎらず、stagingの話ってあんまりしない。もっとstagingの話がしたい！
tumblr好きのナイスニートの@rono23が自分のtumblrに流れてきたと教えてくれた。
昔の自分に何でブログ（Webで日記）なんて書くのか聞いたら、「面白いから」と即答に違いないけど今だった...そんなkomagataさんにもぜひTumblrを使ってほしい。
ここに書いても全くもって得なしなので
2007年の俺が2000〜2003年の俺について書いてるエントリー。
2007年の俺よ、2013年はもっと悪化してるよ・・・。
第０回に続いて行われました。
今月はメンバーは怖話の@machida, @komagata、来月オープン予定の某サービスの@jishiha, @monoooki、共同ファウンダーを探し中の@yujiymのメンバーで行われました。
他のメンバーはまだ公開できないので怖話の成長率の数字。
PV: 9.15%
収益: -11.79%
一ヶ月30%の成長率には程遠い。収益なんかマイナスだよ！
今回は成長率が手計算だったので来月までには自動化します。週7%成長ほんと厳しいな。我々はクズでございます・・・。
Syntax highlightだけだけど。
" ~/.vimrc:
Bundle 'slim-template/vim-slim':BundleInstall