exdesign

昨日Rails開発者が集まる場としてRailsDevConが開催されました。

自分の場合、元がプログラマではないため、この手の集まりには消極的でしたが、そろそろ高度な話にも付いて行けるようになったのではないか？と思い参加させていただくことにしました。

それにしてもRails界を代表する皆さんのお話は興味深く濃い内容でした。

特に印象に残ったところをセレクトしておきたいと思います。

「渡米して感じたこと」 増井 雄一郎さん：@masuidrive

• 英語はできなかったが、Rubyができるおかげでいろいろな人に助けられた。
• 家で仕事をしていたので英語をなかなか覚えなかった。
• アメリカはWifiが基本タダなのでカフェで仕事をするようにした。
• カフェにいると向こうの人は気楽に話しかけてきてくれる。
• 結論としては、アメリカに行っても英語は話せるようにならない（笑）。
• 身振り手振り、ホワイトボードを使って説明するスキルは伸びる（笑）。
• アメリカでは、Ruby == Railsと認識されている。 
• Rubyの経験はPHPよりも高く評価される。
• シリコンバレーのRails求人は年収10万～12万5千ドル。
• Facebookアプリ制作、RSec、Cucumberでテスト、NoSQL、Gitの経験が条件になる。
• 働く環境が交渉次第でかなり自由だが、いつクビになるかわからない。
• 日本のエンジニアはスキルがあるのに認められない環境にあるのではないか。

「Rails情報源の歩き方」西村 賢さん：＠IT副編集長

• Railsは情報の宝庫。
  • Ruby on Rails Guides
  • Riding Rails
  • Asakusa.rb
  • The Ruby Toolbox
  • Railscast
  • ASCIIcasts
  • Ruby on Rails Tutorial
  • Rails Wiki
  • Confreaks

• カンファレンスも多い。
  • RubyConf（最大）
  • RailsConf（もっと最大）
• OOSは人がやっているものだから、人との交流が重要。
  • DHH（プレゼンがいい）
  • Matzにっき
  • Yehuda Katz （Railsのコアメンバーだが今後はjQueryに注力するらしい）
  • るびま
  • The Pragmatic Bookshelf
  • StackOverflow
• コミュニティもある。
  
  • RailsBridge
  • Rails勉強会
• 12/22に@ITにRails専用コーナー「Rails Hub」が立ち上がる。

「とあるソーシャルアプリの開発運用」大仲 能史さん：@onk、(株)ドリコム ソーシャルゲーム開発デザイン部

• ソーシャルアプリの開発 --> API利用、人口爆発、短納期。
• API利用の勘所：request と response を見る。困ったらTCPレイヤーまでおりる。
• net-http-spy（NetHTTPにloggerを仕込む）、tcpflowを使う。
• 人口爆発：不可に耐えられるか？ソーシャルではスモールスタートさせてくれない。
• 短納期：二週間に一回何かやらないとユーザーが逃げちゃう。
• 捨てられないデータがあるとすぐにDBが数GBになる。
• 負荷テストは必須（50万ユーザーが３ヶ月で想定）。faker使う
• 超高速でPCDAサイクルを回す必要がある。
• DとAは省略できないので、PとCを最速にする。
• Plan最速 --> 施策は常にストック。
• Check最速 --> ログの自動集約。 facebookのscribe利用。

「Railsプロジェクトを成功させるために現場ができること」赤松 祐希：@ukstudio、フリーランスプログラマ

• 迅速かつ高品質が成功の定義。
• 技術的負債はその場しのぎのコード。利子と負債を増やすことに。
• 開発を加速することでそうなるので、必ずテストを書く。
• テストがないコード＝変更時に困る（負債）。
• テスト駆動＝無駄のない設計。
• リファクタリング（ソースの内部構造コード変更）で返せる負債はすぐ返す。
• 20%のリファクタリングを開発プロセスに組み込む。
• 変更を恐れないためにバージョン管理は必須。
• Gitでブランチを切ってやるのがオススメ。
• Cucumberのテストが通っていればRspec/UnitTestは全部捨てられる。
• Railsの機能をどれだけ使いこなししているかがRailsらしさ。
• 使わない機能にも維持コストがかかる。
• お客さんの要求をほんとうに理解していないため機能が増えてしまうことがある。

「現実の世界で "はじめる！Cucumber"」諸橋 恭介さん：@moro、(株)永和システムマネジメント、Rails勉強会@東京

• 動かないCukeを書く意味 --> 振る舞いを考える時間になる。
• 簡単なテストから書き始める
• テストが動かなくても、自分たちで読むために母国語で書く。
• 「はじめる！ Cucumber」絶賛発売中。

「Rails Add-onsで楽々開発 - youRoomを題材に -」松村 章弘さん：TIS(株) 社内ベンチャーカンパニー SonicGarden

• Cucumberを使っており"rake cucumber"がグリーンだとリリースできる低コストな品質保証体制。
• Tipsは肝心な部分は徹底してテストを書く。バリデーションエラー系も書く。
• 困り事：Ajaxを多様するようになってテストしにくい。
• Twitter, Facebook, OpenID, githubで認証可能なRackベースのフレームワーク「OmniAuth」を活用している。
• Google Docsと連携させてアプリケーション以外のデータをストックしている。データのスナップショットを撮るのにいい。
• Herokuを使っていたが、Amazon EC2に移行した。
• hoptoadでエラーの管理している。 カスタマイズしcronやDelayedJobのエラーもとれるようにしている。
• アジャイル開発向け ITS「Pivotal Tracker」でプロジェクトの管理をしている。チケットのワークフローがシームレスに操作できる。

さっそくスライドを公開してくれています。

「初めてがRuby」松田 明さん, 吉田 裕美さん, ほか

• 新人教育で行われること
  • ペアプログラミング
  • 毎週に振り返り
  • 週１日は業務をやらずにラボ
  • 週１回読書会。今は「Ruby逆引きレシピ」
• どうやって勉強したか
  • 「たのしいRuby」で問題を解き、分からなかったら先輩に聞く。
  • OJTでつくったものを先輩にレビューしてもらう（Github上でコメントをもらう形でやっている）。
• 難しかったこと
  • Rubyは分かるけど、Railsが全然分からず、アプリって何ですか？って感じだった。
  • これはどのオブジェクトが持っているデータなのか？という状態によくなった。
• 上達したきっかけ
  • ruby-debugを使うことでRailsの動きがわかってきた。
  • ActiveRecordのモデルのソースを見たらわかるようになってきた。
• Ruby, Railsがおもしろいところは？
  • ソースが読みやすい。
  • Rubyをやってる方がやさしいので、挫折しにくい。
  • リファクタリングが楽しい。
  • irbでちょっとずつ試せる
  • Railsは最初に全部知らなくても、周辺を後から学べる。

正直まだ付いて行けてないところがありましたが、今後の課題が見えてとても有益な時間を過ごすことができました。

運営に関わった皆様、ありがとうございました！

自分の場合、スピーチとかは無理なので、いいサービスを作り続けることで恩返しをしていければと思っています。