komagataのブログ

ハマリポイント

• 古いvagrantを削除する。
• VirtualBoxを新しくし過ぎない。（ちょっと古いやつを使う）
• VirtualBox系でハマったらMacを再起動する。
• ruby2.xではchef-solo動かない。
• chefは公式サイトからcurlで入れる。
• knife-soloはgithubから入れる。
• knife-soloをbundle exec rake installする時ちゃんとruby1.9.3に入るようにする。

古いvagrantのアンインストール

% gem uninstall vagrant
% rm -rf ~/.vagrant.d

vagrantのインストール

http://downloads.vagrantup.com/tags/v1.2.2

debian wheezy64のvm作成

断固debian。

% vagrant box add wheezy64 http://dl.dropbox.com/u/937870/VMs/wheezy64.box
% mkdir wheezy64
% cd wheezy64
% vagrant init wheezy64
% vagrant up

下記でいい感じの設定を履いてくれる。（便利）

% vagrant ssh-config --host wheezy64 >> ~/.ssh/config

% ssh wheezy64

で入れるようになってる。

chef-soloのインストール

% curl -L https://www.opscode.com/chef/install.sh | sudo bash

% chef-solo -v
Chef: 11.4.4

ちゃんと動くか確認。

knife-soloのインストール

gem版は0.2.0だったのでgithubから入れる。

% git clone git@github.com:matschaffer/knife-solo.git
% cd knife-solo
% git submodule init
% git submodule update
% bundle
% bundle exec rake install

rubyが2.xだと動かないので注意！

chef-soloをwheezy64にインストール

% knife solo prepare wheezy64

これで入るChefが0.10.8なのが気になる・・・。

自分のcookbookのリポジトリ作成

% knife solo init chef-cookbook
% cd chef-cookbook
% git init .
% git commit -m'First commit'
% hub create

nginxをインストールするrecipeを書く

% knife cookbook create nginx -o site-cookbooks

% vi site-cookbooks/nginx/recipes/default.rb
package 'nginx' do
  action :install
end

% vi nodes/wheezy64.json 
{
  "run_list":[
    "nginx"
  ]
}

実行。

% knife solo cook wheezy64   
Running Chef on wheezy64...
Checking Chef version...
Uploading the kitchen...
Generating solo config...
Running Chef...
[Wed, 26 Jun 2013 08:35:26 +0200] INFO: *** Chef 0.10.8 ***
[Wed, 26 Jun 2013 08:35:26 +0200] INFO: Setting the run_list to ["nginx"] from JSON
[Wed, 26 Jun 2013 08:35:26 +0200] INFO: Run List is [recipe[nginx]]
[Wed, 26 Jun 2013 08:35:26 +0200] INFO: Run List expands to [nginx]
[Wed, 26 Jun 2013 08:35:26 +0200] INFO: Starting Chef Run for vagrant-debian-wheezy-64.vagrantup.com
[Wed, 26 Jun 2013 08:35:26 +0200] INFO: Running start handlers
[Wed, 26 Jun 2013 08:35:26 +0200] INFO: Start handlers complete.
[Wed, 26 Jun 2013 08:35:26 +0200] FATAL: No cookbook found in ["/home/vagrant/chef-solo/cookbooks-1", "/home/vagrant/chef-solo/cookbooks-2", "/home/vagrant/chef-solo/cookbooks-3"], make sure cookbook_path is set correctly.
[Wed, 26 Jun 2013 08:35:26 +0200] INFO: Processing package[nginx] action install (nginx::default line 9)
[Wed, 26 Jun 2013 08:35:26 +0200] INFO: Chef Run complete in 0.267082 seconds
[Wed, 26 Jun 2013 08:35:26 +0200] INFO: Running report handlers
[Wed, 26 Jun 2013 08:35:26 +0200] INFO: Report handlers complete

一応入ったけどFATALがきになる・・・。

scpとかtestとかちょっと長い処理があるとTwitterを見ちゃって戻ってきてまたちょこっと作業して長い処理があるとまたTwitter見ちゃう。

なのでTerminalで長い処理がある時は終わったら通知を出してすぐに作業に戻りたい。

$ gem install terminal-notifier

$ terminal-notifier-notify -message Finished!

terminal-notifier-notifyというコマンドが入って通知してくれる。

テストが成功でも失敗でも終わったら通知する。

$ rake; terminal-notifier-notify -message Finished!

ちょっと長いのでshellを書く。

~% cat ~/bin/finished 
#!/bin/sh
terminal-notifier-notify -message Finished!

$ rake;finished

testの場合はguard使えばいいけど手元にちょっとあると便利かもしれない。

Herokuでwww.foo.comとかじゃなくfoo.comのようなrootドメインを使うのは面倒です。 （root, naked, bare, zone apex domainなど色んな呼び方があるのもググり辛くて面倒な要因）

以前は「このIPをAレコードに設定してね」と公式ドキュメントにも書いてあったのですが現在は「SimpleDNSなどの仮想Aレコード的なものが使えるサービスを使え、もしくは逆に考えるんだ。rootドメインなんて使わなくってもいいさ・・・と。」と書いてあります。

そんなジョースター卿のような逆転の発送はなかなかできませんし、SimpleDNSは$3/moだったりしてちょっと高い。

ところが12レコードまで無料でHeroku向け設定をポチッとやってくれるDozensというサービスを発見。

DNSを自由に簡単に。Dozens（ダズンズ）

ワーオ！Add Heroku Records?なんていうチェックボックスがあるぞ！

こいつはくせえ、名サービス以上の匂いがプンプンするぜ！

お名前.comのDNSなんて使ってる場合じゃねえ！

最近知ったんですが、

$ ey deploy --no-migrate

こうやってmigrateしなければ無停止でデプロイできる。

migrateアリの時はDBの整合性を保つために開始時にmaintenance.htmlになって終わったら戻る。これは非常に納得感のある挙動。

これの有無でEYC選ぶかどうか変わるレベルなので声高に叫びたい。

おはようございます。高熱を出したまま35歳、アスキーコードで言えば#歳になりましたkomagataです。

間違えてて去年書くはずだったプログラマー35歳定年説について。（その来年がきたよ～、見てる〜？　＞　俺）

パッピーバースデートゥーミーフロム俺 - komagata

「フィジカル、メンタルで衰えてくる」とか「マネジメントへの参加要求が強まり自然にプログラミングから遠ざかる」とか「求められる成果の総量が上昇するのでしかたなく」という面も確かにあると思います。

しかし、

「平均的なキャリアプランなんぞ知ったことか。こっちは大手町辺りに派遣されてスーツで一生デスマ案件でJavaを書き続ける覚悟は完了してるんだよ！」

という我々にとっては関係ありません。にも関わらず我々が長文を書いてしまうのはなぜでしょう？

それは「誰も見てなくても関係ない」「真理鉱山に篭って一生続けられる」はずのプログラミングに35歳ぐらいになると飽きてしまうのではないか？という恐怖のせいです。

アラサーぐらいで社内でもいわば中堅になり、プロジェクトマネジメントやお客さんとの折衝が仕事の中心となっていた時、僕も若干プログラミングに飽きていました。勿論夜中や休日にコードを書いていましたが、仕事ではミドルウェア選定時のプロトタイプ作成とかやばそうな部分をちょこっと書くぐらい。そのころAjaxが流行っていましたがイマイチやる気になれませんでした。

「Webアプリは結局DBだろう、どの言語でも大して変わらない」

みたいなことを思っていました。

そもそもプロジェクトマネジメント自体、体育会系の部活のような一体感があるし商売が上手く行くようになって喜ぶお客さんを見るのも楽しい。プログラミングから離れていくのも自然な流れに見えます。

ちょうどその頃、会社を辞めて毎日新宿のシアトルズベストコーヒーに一人通って朝から晩まで自分のWebサービスのコードを書く生活が始まりました。するとプログラミングに対するモチベーションがどんどん上がっていくのを感じました。

「Javascript超楽しいじゃん。片っ端から全部自分で書きたい。こんな感じだったら他の言語もきっと楽しいはずだ。」

そのあとrubyとか書き始めたりして今に至ります。

その時体感でわかったのが、プログラミングは「やればやるほど飽きる」というモデルではなく「離れれば離れるほどつまらなくなり、近づけば近づくほど面白くなる」というモデルなんだなーということです。身近になればなるほど面白くなる。上達すればするほど夢中になるというのは当たり前な感じもしますが、一定以上ハマれる対象には共通しているモデルなのかもしれないなと思いました。

そんな体験があってからようやく僕は、もし土星の衛星エンケラドゥスへの有人探査ミッションの依頼（多分片道20年ぐらいかかる）がきたとしても、

「ネットが繋がるなら」

と快諾できる心の安定を取り戻したのでした。

EYCでのステージング環境問題ですが、料金シミュレーターで見積もってみたらsmallを一台だけ立ち上げれば6119円だそうなのでEYCにステージング環境を作ってみました。

こんな感じです。

staging環境はRails.envがstagingになります。そんなの大丈夫なのかよとおもいますが、37signalsも色々とenv作ってるようなので予想外のことはそれほど起きないです。

変える必要があるところ

• database.ymlにstagingを追加する。
• if Rails.env.production?となってるところをif Rails.env.production? or Rails.env.staging?に変える。
• s3、CloudFrontにstaging用の設定を追加する（paperclip使ってる場合は要注意）
• Gemfileでgroup :production doとなってるところをgroup :production, :staging doに変える。

ものに応じてproductionだけでやりたいこと、production or stagingでやりたいことがあるので慎重に選ぶ必要があります。

例えば公式Twitterアカウントで通知する部分や本物の広告配信はproductionだけでやりたいでしょうし、S3を使うかどうかというのはproduction or stagingでやりたい。

リリース作業をCIする

デプロイといっても色んな意味が含まれてて、コンパイル・テスト・パッケージング・リリースをひっくるめてデプロイと言えますが、Railsだと大抵テストのみをさしてデプロイと言う。

実際のRailsアプリはリリースで問題が結構起きるのでこれを含めてCIしたい。

EYCはeyコマンドでリリースするので怖話ではこんな感じ。

弊社の場合はpushされるたびに↓のような通知がくるが、まあいい。

受託開発でEYCを使う場合はステージング環境代金もちゃんと見積りに入れると良いと思います。

jenkins, rspec-railsの場合。

# Gemfile:
group :test do
  gem 'ci_reporter'
end

Rakefileの最終行に下記を追加する。

# Rakefile:
require 'ci/reporter/rake/rspec'

rake specの代わりにrake ci:setup:rspec specを実行するとspec/reports/以下にテスト結果のxmlができるので.gitignoreに追加しとく。

spec/reports/

jenkinsの設定

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 spec

Post-build Actions > Publish JUnit test result reportを追加し、spec/reports/*.xmlを入力。JUnitがこういうxml出すみたい。

下記のようなグラフが出るようになる。怖話ではこんな感じ。

画像を直リンできるので目につきやすいところに貼るのがいいかも。

dm-validations-i18nがノルウェーのボークモールに対応しました。

add locale for Norwegian bokmaal (nb-NO) by drtortoise · Pull Request #7 · komagata/dm-validations-i18n

何言ってるかわからんかもしれんが俺もです。

Engine Yard Cloudのstagingをどうするか悩んでます。

1. Engine Yard Cloudにstagingを作る。
2. さくらVPSとかにstagingを作る。
3. Engine Yard LocalをさくらVPSに入れる。

1はstagingへのdeployを含めてCIしたいので立ち上げっぱなしではお金が厳しい。

2はEYCへはeyコマンドでdeployし、さくらVPSでへのcapistranoでのdeployになり、環境もかなり違うのでstagingにならない。同じ理由でherokuも微妙。

3はまだやったこと無いが、さくらVPSにVirtualBoxを入れてEYLは実用的なのかわかってない。またeyコマンドでEYLへデプロイが可能かどうかも気になる。

EYCにかぎらず、stagingの話ってあんまりしない。もっとstagingの話がしたい！

追記：Engine Yard Cloudにステージング環境を作る

tumblr好きのナイスニートの@rono23が自分のtumblrに流れてきたと教えてくれた。

昔の自分に何でブログ（Webで日記）なんて書くのか聞いたら、「面白いから」と即答に違いないけど今だった...

そんなkomagataさんにもぜひTumblrを使ってほしい。

ここに書いても全くもって得なしなので

2007年の俺が2000〜2003年の俺について書いてるエントリー。

2007年の俺よ、2013年はもっと悪化してるよ・・・。