基本へ帰ろう このページをアンテナに追加 RSSフィード

2011-08-21

いまさら、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 を用いてどのように開発・運用されているのかを話されていました。クックパッドさんのプレゼンは去年も聴きましたが、去年よりパワーアップしているのが印象的でした。メモしたことを箇条書します。※誤字脱字ある可能性あり。

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で写真を撮りました。

f:id:japanrock_pg:20110716110244j:image

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

f:id:japanrock_pg:20110716132106j:image

f:id:japanrock_pg:20110730234739j:image

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

f:id:japanrock_pg:20110716160623j:image

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

f:id:japanrock_pg:20110717172218j:image

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

f:id:japanrock_pg:20110717172225j:image

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

f:id:japanrock_pg:20110717192321j:image

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

f:id:japanrock_pg:20110717172853j:image

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

f:id:japanrock_pg:20110718122537j:image

f:id:japanrock_pg:20110718124943j:image

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

f:id:japanrock_pg:20110718161151j:image

RubyKaigi本当にありがとう。

f:id:japanrock_pg:20110718184515j:image

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