http://railsdevcon.jp/
参加してきた。
まずは一言。こういう素晴らしいカンファレンスが無料で参加できるってのはすごくいいことだと思う（会場も立派でした）。スタッフの方々、おつかれさまでした。
プライベートはプライベートとして、開発（⊇仕事）と全く関係ないことで思いっ切り遊んで息抜きをするけど、それと別に、こういう仕事の枠から離れた開発（⊇仕事）のカンファレンスに参加するのもいい息抜きになるなぁ。
仕事だけだとすごい狭い世界にいるんだなぁと感じさせられる…。
あまりアテにしないでほしいメモを残しておく。
渡米して感じたこと
- 英語は話せるようにならなかったけど、身振り手振りとホワイトボードでなんとかなる。言葉（English）の壁は言語（Ruby）で超えればよい。
- Railsの市場は右肩上がりのよう（でも、PHPの市場はそれよりずっと大きい上に右肩上がり（笑）indeedっていうサイトでそういう情報が見れる）。ただ求人条件（3年以上のRails開発経験、Git, Cucumber,NoSQLなどに精通）とそれに対する評価ってのは日本よりずっといい。10k-17.5k$/年とか。
- アメリカの会社はネゴシエーション次第で色々こちらのわがままがきく。完全フレックスとか、2ヶ月のバケーションとか。日本じゃ、というか今の自分の会社じゃ到底考えられないね…。
- 一度外国に行ってみると、日本に縛られなくなる。
- Rails3の認定試験がはじまる。
- 知らないサイトとかもあり、タメになった。これは見とけ、ってリスト↓
- 公式ブログ
- The Ruby Toolbox
- RailsPlugins.org
- Railscasts（文字だけの場合はASCIIcasts）
- RailsTutorial.org
- RailsWiki
- Confreaks: カンファンレンス情報。言語は縛られないけど、70%くらいがRuby/Railsらしい。
- あと@ITでRailsHubが開始。
とあるソーシャルアプリの開発運用
- 自分の身近なRails案件で大量データ処理があったのでなにかヒントになるかなぁと期待していたトピック。
- デバッグの勘所：困ったらRequest/Responseを確認。更にTCPレイヤまで下りる。
- スモールスタートができないソーシャルアプリの性格上、アクセス数とデータ量の想定が肝。負荷試験と監視。
- 短納期に答えるためにドキュメントはER図とURL図のみ。これらのドキュメントだけで何とか疎通ができる辺りはまさにRailsの恩恵だね。URL図の書き方とか参考になるかなと思った。
- 意思決定速度のUP。
Railsプロジェクトを成功させるために現場ができること
- いわゆる技術的負債（TechnicalDept）をキーワードに、負債をなくしプロジェクトを成功（ここではお客様を満足させることと定義）ためにはどうすればよいか。
- 負債の解決に充てる時間を開発プロセスに習慣として組み込む。
- TDDによりプロダクトコードは必要最小限になる＝余計な機能がなくなる。
- 息を吸うようにリファクタリング。
- TDDを実践して最初にぶつかる壁＝既存テストコードがリファクタリングを妨げる。このためにテストの資産価値を考慮し、捨ててよいテストと捨ててはいけないテストを見極める。
現実の世界で始めるCucumber
- 実際のアプリで一番簡単なページから試していく。XXXのページにアクセスしたらYYYと表示、みたいな簡単なシナリオ。
- 実際のテストとして利用しなくても仕様として利用。
- Ajaxでの扱いにくさには解があるらしい。これは暇な時調べてみよう。
Railsでサービス開発〜youRoomを題材に
- プラグインの紹介とかTipsとか。
- (Plugin) Cucumber
- (Plugin) OmniAuth
- (Plugin) SearchLogic（なんかバージョン関連の不具合で障害が起きてしまったとかなんとか）
- github
- hoptoad
- pivotal tracker（RedMineと違って表の上にあるものほど優先度が高いってルール。だから優先度「高」のチケットが複数あってどっちからやるべきなんだって迷うことがない。他にも色々特徴はあると思うけど。）
- はじめてさわる言語がRubyだった若手エンジニア5名を含めたパネルディスカッション。
- 純粋に新しいことに対して楽しんで学んでいってるなぁと。
- Rubyっていう言語自体の性格と、Rubyを使える人ってまたJavaを使える人とタイプが違うってのが色々とプラス効果になってるんじゃないかなと思った。
