おはようございます。高熱を出したまま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年はもっと悪化してるよ・・・。

第0回に続いて行われました。

今月はメンバーは怖話の@machida, @komagata、来月オープン予定の某サービスの@jishiha, @monoooki、共同ファウンダーを探し中の@yujiymのメンバーで行われました。

他のメンバーはまだ公開できないので怖話の成長率の数字。

PV: 9.15%

収益: -11.79%

一ヶ月30%の成長率には程遠い。収益なんかマイナスだよ!

今回は成長率が手計算だったので来月までには自動化します。週7%成長ほんと厳しいな。我々はクズでございます・・・。


Syntax highlightだけだけど。

" ~/.vimrc:
Bundle 'slim-template/vim-slim'
:BundleInstall

トイレから戻ったら情弱プログラマーの@ko8が

「rbenvの設定が上手くいかない」

とのこと。

見てみるとMacのTerminalが起動しない(起動中にshellが落ちてる?)

本人に話を聞いてみると、.bashrcを設定するという意味がよくわかっていない模様。

どのファイルを触ったのか聞いてみてもよく覚えていない。

最終的に起動時のエラーを追って行き、全ての設定ファイルを削除しても起動しないことから/bin/bash自体が壊れていることが判明。

@komagata「/bin/bashってファイルいじった?」

@KoyaHomma「いじったかもしれないです・・・」

$ sudo vi /bin/bashした上で、書き込み権限が無いという警告を無視して!wを敢行したらしい。

結局、俺のMacから/bin/bashをAirDropでコピーしてきて事無きを得た。

ほっと一息ついて時計を見ると、楽しみにしていたC組のペンドラタイムは終了していた。

今季のインターンもなかなか活きが良いじゃねえか・・・。

「覇王翔吼拳」を使わざるを得ないとは (ハオウショウコウケンヲツカワザルヲエナイとは) [単語記事] - ニコニコ大百科

公式のAMIが公開されてるのでそれを使う。

Cloud/AmazonEC2Image/Wheezy - Debian Wiki

東京リージョン(ap-northeast-1)の64bitはami-dbe16edaってやつだそうです。

SSH username

In line with the security of most Linux distributions on Amazon Web Services, remote root SSH is disabled (as is password authentication). You will need to connect to instances from this AMI as the user admin using your SSH key, and then sudo -i to gain root access.

ユーザーがrootじゃなくてadminなのに注意とのこと。

EC2は高いのであんまり使ってないんですが、検証用やフルタイムで起動しないやつは楽ですね。