いまさら、RubyKaigi2011を振り返る

2011年7月16日(土) 〜 18日(月) に開催された、RubyKaigi 2011から、もう一ヵ月以上経つのですね。いまさらですが、RubyKaigi2011をつらつらと振り返り、感じたこととメモを残します。

私はRubyKaigiに過去2回参加(2010年筑波2009年東京)していて、今年で3回目です。去年に引き続き個人スポンサーとして参加致しました。今年もとても楽しく、学ぶことが多く、たくさんの人とお話できました。RubyKaigi2011を運営してくださった皆様、スポンサーの皆様、有難う御座いました。

RubyKaigiは1年に1度、日本にRubyist達が全世界から集まる場所です。RubyKaigiの開催により再会できた人、憧れの人に会えた人、インターネットごしでしか知らなかったのにリアルになった人・・・こうした機会というのは多くないです。RubyKaigiはこうした機会を設けてくれています。Rubyコミッタがこんなに集まる会議はなかなかありません。海外のスターエンジニアと出会えることもなかなかありません。たこ焼き仮面さんの日本語キーノートはなかなか見れません。Ruby2.0の開発はtrunkでやろうなどといった話もなかなか聴けません。角谷さんの価値とは何か?多様性は善であるという主張もなかなか聴けません。全世界からキーノートが集まり、選ばれたものだけが発表できるという、全世界レベルのキーノートが聴けるわけです。地域RubyKaigiにはないものがRubyKaigiにはあるのですよね。とても貴重です。ぜひとも来年も開催して欲しいと願っています。

Next version of Ruby 1.8 and 1.9のセッション

Next version of Ruby 1.8 and 1.9のセッションでは、「Ruby 1.8 has no future. We gonna use 1.9.」という言葉があって、もう1.8ではなく、1.9を使おうという話がありました。私はまだ1.8.6をメインにつかっており、そろそろ1.8.7をメインにしたいと思っていて、かなり遅れております。Railsでは、1.8.6 はサポート対象外となっていますし、そろそろ1.8.6 を卒業しなければと感じました。

クックパッドさんのセッション

Ruby を利用した大規模ウェブサービスの開発・運用では、クックパッドさんがRuby を用いてどのように開発・運用されているのかを話されていました。クックパッドさんのプレゼンは去年も聴きましたが、去年よりパワーアップしているのが印象的でした。メモしたことを箇条書します。※誤字脱字ある可能性あり。

  • Ruby 1.8.7
  • Rails 2.3
  • haml
  • sass
  • JQuery(Protope を jQuery に 変えた。ブログで検索すれば出てくる)
  • Passenger 2.2
  • MySQL 5.0
  • memcached
  • サーバ構成は定石(サーバ/インフラを支える技術)
  • キャッシュ / バーニッシュ 2.1.5
  • イメージサーバ EC2 に設置
  • Image serve => Tofu(Rails3で処理は書いている)
  • Upload Server on EC2
  • Rails3 => S3
  • URLの中で画像サイズ等を決めている。
  • Searcher
  • MySQL + Tritonnから変わった。
  • Solr に変えた理由。柔軟な検索が可能。早くなったわけではない。柔軟で開発がしやすくなった。
    • Facet(like group by)
      • 集合扱う
    • Boost Search
      • 重み付け検索
    • Dynamicfields
      • 動的なフィールド追加
  • Log Analytics
  • Speed
    • Ruby / Rails 遅い? Slow? 実際に遅い?実際には遅くないかも。No.
    • Cookpad は 200ms 以下を実現。定石をきちんと行うことで、スピードを維持している。
  • 早くする工夫
    • "Good はやらない。Bestのみ集中"
    • シンプルさを保つ
    • Keep it Simple
    • ほんとうに必要な機能のみに絞る
    • 無駄に複雑なことをやらない
    • キャッシュに乗りやすくなる
    • シンプルなクエリ
    • あとでやる(Async Loading)。非同期レンダリング
    • 36ms、195ms(第一レスポンスは 36ms、他の非同期の部分は 195ms )
    • Ruby Rails not slow.
    • ウェブオペレーション(日本の料理のインフラ)
  • クックパッドは 30人のエンジニア。
  • Railsアプリの多人数開発
    • 開発 Dev → デプロイ → フィードバック →(戻る)
    • これをどれだけ早く回すのかが大切。
    • Tests
    • Rspec 1.x
      • unit
      • functional
      • integration
  • 最近はUnit と integration を沢山書き、functional は少なくなってきた。
  • Integration のテストが大切。javascript のテストがかける。
  • テストの処理速度が遅い。20分かかる。ティータイムになる。
  • テストをリモート上で行った。
  • テスト用のサーバをアップして、remote spec ×4 server。テストの話は大江戸Ruby会議で話したよ
  • Deploy Rule
  • CIが通るか?
  • 皆テストを書く・実行するように
  • CIで動かないテスト = 将来的に価値がないテスト
  • 継続することの重要性
  • 新しい技術を導入する = CIで動くテストが書けるを認識
  • RubyStudy@Sapporo#18
    • カピトラーノ
      • デプロイ時にメッセージを記入
      • 新機能の追加・大きな変更
      • Skype による通知
  • Error のモニタリング
    • インフラモニターがあって、それで見てる。何があると、画面が真っ赤になる。
  • エラーログの監視システム
  • フィードバック
    • Extensionsを使っている
    • Rails拡張
      • 条件指定で有効化
      • 一部ユーザのみ限定公開
    • プロトタイプ開発向き
    • Spec を書かなくても良いルール(まずは作る)
        • 例外発生時”自動で無効化”(extensionが落ちても今の機能に切り替わるので安心)
  • 新機能の利用率を知れる。
  • 配置ディレクト
  • リリースしない決断したら、rm app/extensions/foo_bar
  • 近いうちに、クックパッドのブログで公開

2008年に聞いたクックパッドさんのセミナーでは、Rubyは1.8.6、Railsも2.0でした。バージョンアップを意識的に行っていることが伺えます。クックパッドさんはColdFusionからRuby on Railsへ移行するなど、開発の改善を常に考え進化しています。

私のところは、やっとこ基幹システムがRails2.3 になろうとしていますが、これはクックパッドさんの影響を受けていると感じています。数年前に作られたシステムをバージョンアップするというのは、簡単ではありません。バージョンアップするだけで、何ヶ月もかかる場合もあります。私のところはRailsMySQLとライブラリのバージョンアップを行うのに半年近くかかりました。表向きは何も変わらず、裏で変わるだけですので、ユーザからすると「半年もかけて何がよくなったの?」となります。クックパッドさんが以前言っていたことで、「クックパッドはこれから100年以上生き続けるサイトである。だから、バージョンアップにも対応し続ける。新しい機能は魅力だし、他の新しいサービスと勝負できなくなってしまう」。私はこの言葉を聞いて、バージョンアップの重要性を知りました。たしかに、開発をしていると「あの機能があれば、1行で終わるのになぁ」とか「ちょ、gem install xxx できないんですけど。。」みたいなことがたくさんありました。スピードはとても大切ですので、適切なペースを保つためにも、寿命の長いアプリは、定期的なバージョンアップは必要だと感じます。これからも、バージョンアップしてきます。

githubのセッション

こんどはgithubのセッションです。英語でしたので、メモしたこともかなり怪しいですが・・・メモを箇条書きで残します。※誤字脱字ある可能性あり。

  • BrowserMob
  • Pingdom
  • akamaiを検討
  • Measure backend Behavior
  • Capacity plan
  • Collented
    • Time Series Information
  • Nagios
    • Monitoring & Alerting
  • Custom
    • Redis Counters
  • Communicate
  • Propane
    • extendable JS
  • Campfire
    • searchble logs
    • streaing API
  • Hubot
    • door me, image me
    • distributed execution
  • Day to Day
    • how tools work togers
  • User Interaction
  • Error
    • Unavoidable
    • cotweet
  • Haystack
    • exception loggin
    • like Hap Toad
    • 例外頻度が見れる
    • stream in realtime
    • fwe users impacted
    • many users impacted
  • Respond
    • failures we may miss
  • continuous integration
  • Branch status
    • any branch, any time
  • Jenkins CI
    • Solid Backend
    • ブランチの状態も常にCIでチェックしている
  • Webhooks
    • janky
  • Trigger Build

たのしいRailsのセッション

たのしいRailsのセッションでは、Railsそのものを開発するためのTips等が紹介されていました。私もOSSに貢献しようと思っているものの、なかなか足が踏み出させていない分野です。自然と貢献できるようになっているのが良いと思っていますが、OSS開発の道には努力しないと乗れないなという感じもしています・・・。セッションを聞いた時のメモを箇条書きしていきます。※誤字脱字の可能性あり。

たのしいRails
  • Ride on someone else's "rails"
  • "rails" for yourself
  • "rails" for everyone => "rails" に乗って開発するのではなく、"rails" そのものを開発することが楽しい。
  • プラグイン開発(Development Rails plugins)
  • Rails本体開発(Development Rails
  • 自分以外のためにコードを書く場合、コミュニケーションが必要。That's called "social coding"
  • Social Coding は 人と直接コミュニケーションすること。つまり、The community につながる。
  • a Community
    • 日本Rubyの会
    • asakura.rb
    • => The Community ではない
  • The Community == The World
  • Code Ruby, and be a member of "The community"
10 Pro Tips

1. Read Rails
  read "git log" every morning

  git pull
  git log

  将来のRailsが分かる
  だれが作っているか分かる

  良いコード、悪いコードが分かるようになる
  良いコミットコメントが書けるようになる

2. Know the people

 だれに注目すれば良いかわかる

 Stalk them online
 github
 Twitter
 blog

 BTW
  @tenderlov

3. Imitate good commites

 良いコミットが見えてくる

 A Good commit
 ・Atomic
 ・With tests
 ・with a short commit comment telling
 ・what

 in English, of course
 将来のソーシャルコーディングで避けて通れない道、英語。

4. English

 Know these 26 letters
 Aware of the accents
 表音文字、アクセントの位置が重要(アクセントの位置を間違えると通じない)

 Watch Railscasts

5. Live on the edge

 Railsのコミットを見ていると、新機能をどんどん使いたい

 Bundler素晴らしい

6. Contribute to the documentation
 ドキュメントを書いて、コミットする。
 だれでも、コミットできる

 git clone Info/docrails

 一番被害が少なくて良い

7. Share your monkey patches

 自分で作ったモンキーパッチを世界にだそう

 ブログなどに書くのではなく、パッチを書いてpushしましょう

 fork rails, push ,and send a pull request
 普通の pull request でパッチを送れる

8. Start from a gem

9. write a good README

 自分のgemを作る

10. Attend RailsConf
 Railsはたのしい
 RubyConfより全然楽しい

11. write a book

 BDD
  Book
  Driven
  Development

Rubyマスターへの道

◯準備

1. いろんな分野があること
 これを理解しましょう。
 プログラミングは色々な分野がある
 Rubyならだいたいなんでも作れる

2. 時間がかかること
 とりあえず、10年くらいあれば、だいたい何でもうまくなる。
 継続しましょう。
 料理に似ている。
 実践しないとうまくならないこと
 わりと早い段階から(それなりのものが)手にはいる

3. 何でもできること
 コンピュータの中ではプログラにできないことは何も無い。
 Rubyがだめなら、Cで、cがだめならアセンブラで。

4. 何でも作れること
 何でも作れるプログラマ
 増え続ける分野?

 何でも作れる= 「勉強すればなんでも作れる」という自信のこと

◯初級編

5. ライブラリを知ろう
 ・組み込みライブラリ
  Array, String, etc.
 ・標準添付ライブラリ
  open-uri, tempfile, find, etc.

6. 身近な問題を解決しよう
 テキスト処理
 ファイル名の一括リネーム
 Excel(*.csv)の処理。 require 'csv'

◯中級編

7. 良いコードをかこう
 「美しさ」は宗教やオカルトではない
 美しさ = 圧縮された「良さ」

 Rubyらいしコードを書く
  「初めてのRuby」がおすすめ

 each より map を使う
  短くなる
  意図が分かりやすい
  デバックしやすい、保守しやすい

 読みやすいコード
  Rubyの特徴 = 読みやすい(脳にやさしい)

8. ブログをかこう
  最初は反応がなくてつまらない
  検索エンジンごしの誰かに向けて
  メモをまとめることは自分にとっても役立つ(考えをまとめる、あとで見直す)

 発表しよう
  小さなイベントから少しずつ大きく 
  他人の作ったものの話でも良い

 githubに置こう
  英語だとなお良い
  置いて損することはない

◯上級編

9. 中を開けてみよう

 gem のソースを読む
 gemを書き換える
  gem pristine rails
   もとに戻せる
 Rubyのソース

10. 他の言語を知ろう

 Rubyしかしらない = Rubyの特徴を知らない

◯マスター編

11. 人と違うことをしよう

 Rubyはまだまだいろんなことができる
 手分けをする

12. 生産的であるために
 やる気の問題
  諦める(やりたくなるまで待つ)
  とりあえず始めるとやる気がでる
  嬉しいことがあるとやる気が保たれる
   チケット駆動
   テスト駆動
  やらざるを得ない環境(喫茶店とか)

 生産力の問題

◯終りに
 Rubyマスターになるとなにか良いことがある?

 プログラミングの楽しみとは「動いた!!」ということ。

 「あんなに上手くできたら楽しいだろうな」?
   幸せは現在にしかない
   目の前のコードを楽しもう

  気づいたら、Rubyマスターになっていたというのが良い

Ruby遺産とレガシーコード修理技術

Ruby遺産とレガシーコード修理技術のセッションを聞いた時のメモを箇条書します。※誤字脱字の可能性あり。

  • 25年使われるソフトをメンテする方法
  • tDiary = 日記のソフト
  • 書籍:レガシーコード改善ガイドを使って、開発者の負担を減らしましょう。基本Javaの本なので、考え方をもらった。

1. 変更できるほど十分にコードを理解していない場合
 =>削除する
  ・昨日の追加は慎重に、削除は大胆に
  ・ユーザに求められていてもNoと言えることが重要 ・仕様の却下業

2. 変更する必要が、ありますが、どんなテストを書けばよいかわまりません
 =>仕様化テスト
  ・テストで壊してはいけない骨格を作る
  ・ユニットテスト
  ・エンドツーエンド 
  ・インテグレーションテスト
  ・capybara

3. どうすれば何も壊していないことを確認するのか
 ・沢山のRubyのバージョン(1.8.6, 1.8.7, 1.9.1, 1.9.2, 1.9.3, 2.0.0)
  ・コンパイラ任せ
 ・CI
  ・travis-ci
  ・githubにあれば使える

  • ユーザが開発者
  • 開発者の負担を減らして、新しいことに挑戦してもらう
  • 継続するためには、開発を楽しむことが重要「たのしいRuby」(スライドの背景)

まとめ、書籍:レガシーコード改善ガイドを使って、開発者の負担を減らしましょう。基本Javaの本なので、考え方をもらった。負担を減らし多分、新しいことに挑戦してもらいましょう(燃料投下)

テスティングフレームワークの作り方

テスティングフレームワークの作り方を聞いてメモしたことを箇条書きしていきます。※誤字脱字の可能性あり。
Ket Beck曰く、著者は新しいプログラミング言語に直面すると、xUnitを実装する。TF = テスティングフレームワーク

  • Rabbit(うさぎとかめのタイマーのあれ)
  • test-unit 2
  • Cutter
  • GaUnit
  • Pikzie

判断基準について
 判断基準があるとずいぶん楽
 判断基準を伝える人が少ない
  「盗む」は大変
  盗んでないでもっと先へ行け

大事なこと
 何でもできるものは目指さない
 ターゲットを考える
  誰が使うTF?
  なんのためのTF?

自然であれ
 気づいたらできていた
  AをしたらBになっていた
 思いついたことが正解
  BをするにはAでいい?

自然か考える
 一貫性がある?
 身近なものと同じ手順?
 身近なものと同じルール?

まとめ
 判断基準を決めること
 ターゲットを絞ること

写真集

今回はiPhoneではなく、Mediasで写真を撮りました。


今回のテーマである「最後のRubyKaigi」を示したうちわです。来年も開催されることを願っています。



ステッカーを沢山頂きました。


個人スポンサーでしたので、Tシャツもらえました。


日本全国から来ていますね!


アメリカ、南アメリカ、ヨーロッパ、オーストラリア、アジアから来ていますね!


懇親会は「サンシャイン60 58階 サンシャイン・クルーズ・クルーズ」で行われました。景色がよく料理も美味しく、楽しいひとときでした。


大ホールです。たくさんの素晴らしいセッションがおこなわれました。



アジャイルサムライの本にサインをいただきました!価値ある開発とは何か?と問い続けます。


RubyKaigi本当にありがとう。


クロージングでのシーン。スタッフに向けて、スタンディングオーベーションです。とても感動的でした。スタッフの方々、発表者の方々、参加者の皆様、本当に有難う御座いました!