2010-08-29

RubyKaigi2010で「本当のアジャイル」を学んだ

Rubykaigi2010参加して本当に良かった。運営の皆様、スポンサーの皆様、参加してくださった皆様、Rubyを普段から支えてくださっている皆様。本当に有難う御座います。私もRubyに大変お世話になっていますので、少しでも私に出来ることはないかと思い、個人スポンサーとなって参加させて頂きました。そしてこのブログを残します。

本当のアジャイル

私がRubyKaigi2010に参加して一番痛感したことは、「今までの私はアジャイルをやっていなかったこと。むしろウォーターフォールに近いことをやっていた」と思い知らされたことです。

ウォーターフォールを御存知ですか？半年や１年の開発見積りを行い、それに従って開発を進めるが、見積りが合わなくなり（大抵は見積が足りない）、しかし見積は変えず、デスマーチと呼ばれる慢性的な長時間残業を行うようになり、自分への投資（技術の学習等）を行う時間を犠牲にする開発体制です。自分への投資がない（もしくは少ない）ものだから、技術力は一向に上がらない。いつまでたっても生産性は上がらないチームになり、成果も少ないままのチームになってしまいます。創造性を失い、ただただ「言われたタスクだけ」を毎日深夜までこなす。このような開発体制です。

そう。リーダー失格ですね。今、私のチームは上記に近い状態になっています。おそらくこのまま続ければ、どんどん悪化していくでしょう。食い止めないといけません。私のチームは「アジャイル」で開発を行っていると歌っています。しかし現実は「ウォーターフォール」になってしまっています。

なぜこのような現象が起こるのでしょう。答えは「RubyKaigi2010」にありました。永和システムマネジメントさんのセッション、COOKPADさんのセッション、Chad Fowlerさんのセッション・・・すべて詰まっていました。私は反省しました。変えなければいけません。そして、今から改革しようと決めました。

さて、どのように変えていけばよいのでしょう。答えは「お客様に”価値のある”成果を定期的に提供する」ということです。え？当たり前？そうですよね。でも、これが出来ていないのが今の開発体制です。毎日１０時間以上机の前にいるのに、成果が少ないのです。

まず、やめようと思ったことがあります。それは「長期的な見積りをやめること」です。

過去何ヶ月振り返っても、１ヶ月以上もの見積が当たったことは１度もありません。断言できます。それを「約束」していたのです。出来ないものを約束してしまうのは良くないことです。そして「まだできません」「まだできません」とお客様に繰り返し話します。これではお客様もうんざりです。ですから、「約束」はやめることにしました。

しかし、これでお客様（私たちの場合は社内にいますが）は納得するでしょうか。しないでしょう。私もそれだけではしません。

では、どうするか。Daily Hit を採用します。１日１つ「成果」を出していくのです。何を「成果」とするかは金曜日に決めようと思っています。例えば、午前中に月〜木の成果を「ふりかえり」ます（「ふりかえり」については別途記述します）。そして、お客様と開発チームで来週の月〜木の「成果」を決めます。お客様と開発チームが納得の行く成果ですのでOKです。月〜木ですので１人４つです。金曜日はふりかえりと来週の成果を決める、コードレビュー・リファクタリングを行ないます。飛び込みタスクがあるって？それも見積もるときの想像してください。あまりに飛び込みが多いようであれば、問題があります。本当にそれは飛び込みですか？今すぐやらないといけないのですか？ほかの日にまとめることはできないのですか？本当にその人がやらないといけないのですか？「ふりかえり」で工夫して、徐々に見積もれる状態に持って行きましょう。

Daily Hit というのは、「１日１つ"納得する成果”を出す」ということです。”納得”がポイントです。だれが納得すればよいのでしょう。もちろんお客様です。しかし、「テストを書く」という成果はお客様にとって納得できるものでしょうか？そうではないですね。しかし、重要なプロセスです。なので、チームリーダーの”納得”もOKにします。しかし１週間に１つ以上は”お客様が納得”する成果を出します。Viewを見せるでも、Viewに計算した数字を出すなど、目に見える成果を出していくのです。お客様に「見せる化」するのです。そうすることで、お客様に「安心感」と「進んでる感」を感じてもらいます。これは非常に重要です。Daily Hitの考え方は、Chad Fowlerさんから頂きました。書籍「情熱プログラマー」にも書いてあります。

”納得する成果”というのは、メンバーの技術力、アプリケーションについてどの程度精通しているかなどによりますので、基本的には１日８時間程度で終わるようなものがよいでしょう。８時間集中するのです。残業が当たり前になると、パーキンソンの法則が間違いなく働きます。８時間で終えるんだと自分で追い込むことが重要なのです。そして、家に帰りましょう。技術力を磨きましょう。生産性をどんどん高めましょう。家庭を大事にしましょう。技術者と交流しましょう。語り合い、本を読み、どんどん自分を成長させましょう。OSSに恩返ししましょう。Chad Fowlerも言っています。

１日で出せる成果を見積もるのは１ヶ月で出来る成果を見積もるより、はるかに楽です。見積もりの精度が自然と高くなり、お客様の”納得する成果”が出せるようになります。そう信じています。

１つの「ストーリー（お客様視点の要望）」を設定して、それに向かって開発します。ストーリーの単位は小さくします。１週間以上かかってしまうストーリーは分割を検討します。長い期間は見積が崩壊します。１日〜１週間が理想です。ストーリーを達成するためには、テスト、ロジック、Viewなどの開発工程があります。その工程は特にチケットを発行するようなことはしません。ホワイトボードに付箋を張る程度で良いと思います。ようするに永和さんが採用している”かんばん”を採用します。「ストーリー」は”お客様視点”でかかれたチケットと思っていただければ良いと思います。ストーリーに関してはこちらを御覧ください。

また、ペアプログラミングを推奨しようと思っています。以前、開発チームでもペアプログラミングをやっていたのですが、途中でやめてしまいました。しかし、今もたまーにやります。そして成果がでます。どういうときに成果がでるのでしょう。それは、「突発的ペアプログラミング」でした。以前は「計画的ペアプログラミング」でした。例えば、「火曜日の14時〜16時はペアプロ」などといった具体です。「計画的ペアプログラミング」の何がよくないかというと、「用意してしまう」ということです。「明日ペアプロだから、スムーズに進むように進行を考えよう」など考えてしまうのです。そうではなくて、「ここわかないのだけど、わかる？」「あぁ、たぶんこうじゃない？」「おお、そうだ。さすが！こやってこうだね。できた！」「こっちもこうやったほうがいいんじゃない？」「そうだね、こうやろう。いいね。」「ちょっとViewやってよ。コントローラにこのインスタンス変数を取得するコード書くから」「OK〜」・・まぁ、こんな感じが理想かなと想像しています。例のようにうまく行けば素晴らしいですね。あとは、「私はテスト書くから、実装お願い」「OK、あ、このパターンはテストしないとだね」「うんそうだね」といった具体に、他人の意見も入るので、バグも減るのではないかと期待しています。一日中やってると疲れそうなので、数十分〜数時間がいいなと思っています。

あと、"お客様ともっと積極的に交流しよう"と思いました。私の場合"お客様"は社内のメンバーです。要するに同じ会社の人です。営業さんだったり運用する人だったりします。その人達とお昼を食べに行ったり、夜飲みに行ったりします。同じ会社の人であれば簡単ですね。そこで「本当に欲しい機能」は何か？を引き出すのです。今は、開発側チームと営業側チームの架け橋をしてくださっている人が１名います。その方はプログラマではありませんので、システムについては分からない部分も多々あると思っています。営業側については非常に詳しく、営業よりの方です。私たち開発チームが寄り添って行き、システムの知識も踏まえた「本当に欲しくて、今すぐ取り掛かれる機能」を判断していく材料にするのです。"お客様の声を聞く"ことも非常に重要なことです。

環境を変えて語り合う

RubyKaigiは同じ会社のメンバー2人と行きました。みんなRuby プログラマです。私を合わせて3人です。RubyKaigiが終わった後、ホテルにお酒を買い込んで、語り合いました。上記に書いてある、アジャイルについてもそうです。意見は一致していました。永和システムマネジメントさんのストーリー開発に感動しました。昼休みに”皆の喜ぶ便利ツール”を作る文化にも感動しました。COOKPADさんの 200ms/request にも感動しました。RubyKaigiで得た知識、経験を元に、今の私達に足りないものを語り合いました。とっても充実していて、とっても成果が高く、そしてとっても楽しいのです。そして、「こんなの作ったら皆喜ぶよ！」って言ってその場でMacBookを取り出して開発してしまいます。そして１つできました。なんという生産性でしょう。このアプリケーションは月曜日から可動するのです。今回の”お客様”は”開発メンバーが喜ぶもの”そう”お客様”=="私たち"だったのでこれは”納得の成果”なのです。しかし、仕事では”お客様”は私たち以外でないといけないですね。

COOKPADさんは言っていました。「今のオフィスに行く前は、開発合宿とか頻繁にやっていました。しかし、今の環境の良いオフィスに来てからは合宿はやってない」

なぜでしょうか。開発するのに非常に優れた環境だからです。成果が出るからです。GoogleやCOOKPAD、はてなやLive Door・・・成果を出している環境をみていると私たちとは異なります。ただ、環境のせいばかりにしていては駄目ですし、環境というのは物や服だけではありません。人間関係や成果を出す開発システム、多くの無駄があるでしょう。そういったものを取り除いてから考えても全然遅くないのです。むしろ考える必要がなくなるかもしれません。

１つ来週から実践してみようと思うことがあります。まずは永和システムマネジメントさんが実践している「昼休みの開発」。お昼を食べながら、便利なツールや機能をわいわい作っていくのです。これには技術的な挑戦も含まれます。新しいRailsを使ってみたいけど、業務ではコストが高いから、昼休みに作るアプリケーションで使ってみようなどです。語り合う中で、「これがあったら便利」「これがあったら皆喜びそう」といったアイデアがたくさんでました。それを１つ１つやっていくことにしました。

あと、あまりに今回のRubykaigの後の語り合いがよかったものですから「また合宿やりたいね」という話がでました。数カ月にいっぺんなどのルーチンになるかもしれません。

「ふりかえり」とアジャイルの弱点

永和システムマネジメントさんのセッションは「永和さんが実際どのような流れで開発しているのか」を教えてくださいました。しかし、時間の関係上「ふりかえり」については飛ばされました。気になった私は、セッションの後、永和システムマネジメントさんの ursm さんに声をかけて質問させて頂きました。

なぜ行うのか
- 成果物をだそうとしているが、計画通りにでないときがある。なぜなのかを振り返る。
- 短いイテレーションの繰り返しで、いろいろな機能を思いつくのは良いが「本当の目的」を忘れている場合がある。それを思い出す。

いつ行うか
- 開発している中で「ふりかえり」が必要と感じたとき
- イテレーションやスプリントが終わりリリースしたとき
- プロジェクトごとによって異なる

だれとやるか
- 基本的にお客様と開発チームを混ぜて行う
- 開発チームの問題では、開発チームのみで行う場合がある

どのように行うのか
- ホワイトボードを使う。成果物をみながらとかはやっていない。
- とくにフレームワークはないが、KPTなどを使うときもある。

議題はどのように出すのか
- 開発中にメモしたことを議題にする
- その場で思いついたことを議題にする

ログはとるか？
- 基本的にとらない。ホワイトボードの写真を取る程度

上記、間違っていたらごめんなさい。訂正しますので、ツッコミお願いしますm(_ _)m

もう一つ、興味深いお話を聞かせてくださいました。「アジャイルの欠点について」です。イテレーションを短くしていると成果を見せているときなどにお客様から「あれもほしい、これもほしい」と言ってきます。それはいいのだけど、「ほんとうに必要なもの」を見失いがちになります。「本当にやりたいこと」の確認が重要です。それを「ふりかえり」で行うことが多い。アジャイルは短くなって成果も見えるけど、短ければ良いものでもないということです。

この視点は非常に重要だと思いました。本当に有難う御座います。

写真集

iPhoneでRubyKaigi2010の様子を少しですが写真を撮りました。

大ホールです。感動的なkeynoteばかりでした。

私の名札です。個人スポンサーです。

好きなメソッドは？好きな言語は？私は好きなメソッドを each と書きました。好きな言語の方は書きませんでしたが、見てみるとさまざまな言語が書かれていました。

書道です。何を書いてもよいのです。

書道２です。楽しい内容ばかりですねｗ

喫茶自由です。ここで喉を潤しました。RubyKaigiのオアシスです。

私もですが、Macを持っている方が非常に多かったです。他の言語のカンファレンスでもそうなのですかね？？

松江ラーメン買いました。まだ食べていません。きっと美味しいですよね。

RubyKaigi2010参加して本当に良かった。運営の皆様、スポンサーの皆様、参加してくださった皆様、Rubyを普段から支えてくださっている皆様。本当に有難う御座います。このブログが少しでもRubyの為になればと願っています

2010-04-21

rails -v で Railsのバージョンが分かる仕組み

ruby コードリーディング rails

rails --help を見てみると、-vでバージョンを表示したり、 rails hoge で hogeアプリケーションを作成したり、rails -h でヘルプを表示したりしているのですが、いったいどのようなロジックになっているのか気になったので見てみました。

% rails -v
Rails 2.3.5
% rails "_1.2.3_" -v 
Rails 1.2.3

railsコマンドの場所を知る

% which rails
/opt/local/bin/rails

/opt/local/bin ディレクトリは「追加アプリケーション」を設置するディレクトリですね。

railsコマンドの内容を知る

railsコマンドはRubyファイルです。

  1 #!/opt/local/bin/ruby
  2 #
  3 # This file was generated by RubyGems.
  4 #
  5 # The application 'rails' is installed as part of a gem, and
  6 # this file is here to facilitate running it.
  7 #
  8
  9 require 'rubygems'
 10
 11 version = ">= 0"
 12
 13 if ARGV.first =~ /^_(.*)_$/ and Gem::Version.correct? $1 then
 14   version = $1
 15   ARGV.shift
 16 end
 17
 18 gem 'rails', version
 19 load Gem.bin_path('rails', 'rails', version)

ポイントは、Gem.bin_path('rails', 'rails', version) です。rails -v と入力したとき、最初は /opt/local/bin/rails で受けるのですが、Gem.bin_path('rails', 'rails', version) で指定のバージョンのRailsをロードして、-v の引数は /opt/local/lib/ruby/gems/1.8/gems/rails-2.3.5/bin/rails に移ります。

詳しく見る

ruby の load は Ruby プログラム file をロードして実行します。Gem.bin_path は以下のような動きをします。

/opt/local/bin% irb
irb(main):001:0> Gem.bin_path('rails')
=> "/opt/local/lib/ruby/gems/1.8/gems/rails-2.3.5/bin/rails"
irb(main):002:0> Gem.bin_path('rails', 'rails')
=> "/opt/local/lib/ruby/gems/1.8/gems/rails-2.3.5/bin/rails"
irb(main):003:0> Gem.bin_path('rails', 'rails', '1.2.3')
=> "/opt/local/lib/ruby/gems/1.8/gems/rails-1.2.3/bin/rails"

つまり、railsファイルの19行目は、

load "/opt/local/lib/ruby/gems/1.8/gems/rails-2.3.5/bin/rails"

とやっていることと同じになります。
load したあと、-v が引数として評価され実行されます。

% ruby /opt/local/lib/ruby/gems/1.8/gems/rails-2.3.5/bin/rails -v
Rails 2.3.5
% ruby /opt/local/lib/ruby/gems/1.8/gems/rails-1.2.3/bin/rails -v
Rails 1.2.3

railsコマンド内で require 'rubygems' していますので、正確に書くと以下になります。

% ruby -rubygems /opt/local/lib/ruby/gems/1.8/gems/rails-2.3.5/bin/rails -v
Rails 2.3.5

/opt/local/lib/ruby/gems/1.8/gems/rails-2.3.5/bin/rails の中身

  1 require File.dirname(__FILE__) + '/../lib/ruby_version_check'                        
  2 Signal.trap("INT") { puts; exit }
  3 
  4 require File.dirname(__FILE__) + '/../lib/rails/version'
  5 if %w(--version -v).include? ARGV.first
  6   puts "Rails #{Rails::VERSION::STRING}"
  7   exit(0)
  8 end
  9 
 10 freeze   = ARGV.any? { |option| %w(--freeze -f).include?(option) }
 11 
 12 app_path = ARGV.first
 13 
 14 require File.dirname(__FILE__) + '/../lib/rails_generator'
 15 
 16 require 'rails_generator/scripts/generate'
 17 Rails::Generator::Base.use_application_sources!
 18 Rails::Generator::Scripts::Generate.new.run(ARGV, :generator => 'app')
 19 
 20 Dir.chdir(app_path) { `rake rails:freeze:gems`; puts "froze" } if freeze

上のファイルを見ると、

puts "Rails #{Rails::VERSION::STRING}"

でバージョンが表示されるのが分かりますね。

実験環境

Mac OS X 10.6.2

RubyGemsの状態は以下です。

/Users/japanrock% gem env
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.6
  - RUBY VERSION: 1.8.7 (2010-01-10 patchlevel 249) [i686-darwin10]
  - INSTALLATION DIRECTORY: /opt/local/lib/ruby/gems/1.8
  - RUBY EXECUTABLE: /opt/local/bin/ruby
  - EXECUTABLE DIRECTORY: /opt/local/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-darwin-10
  - GEM PATHS:
     - /opt/local/lib/ruby/gems/1.8
     - /Users/japanrock/.gem/ruby/1.8
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://rubygems.org/

まとめ

最近、毎日Railsのコードを少しずつ読むようにしています。感じるのはプログラマの成長を支える上で、コードリーディングは非常に有益だと思うことです。
Railsのコードリーディングはrubyのことも知れますし、もちろんrailsのことも知れます。一流の人がどのようにコードを書くのか、どのような設計をするのか、思いつかないようなrubyの使い方など、想像力が膨らみます。
私の場合、時間を決めて（例えば 10:00〜11:00）１日１時間行うようにしています。時間が取れないようであれば、30分になったりします。だらだら伸ばしたりしません。そうして毎日続ける方が私にはあっているようです。最近は何事も習慣化するように心がけています。

2010-04-07

意外とハマる？classやmodule内に書かれたメソッド以外のプログラムの評価について

programming ruby

test.rb という以下の内容のファイルがあります。

puts "Hello!"

class Fuga
  def self.fuga
   "Ruby!"
  end
end

module Foo
  puts "World!"

  def foo
    "Hatena!"
  end
end

class Hoge
  puts Fuga.fuga

  include Foo
end

hoge = Hoge.new
puts hoge.foo
puts "Diary!"

ruby test.rb と実行すると以下のようになります。

% ruby test.rb  
Hello!
World!
Ruby!
Hatena!
Diary!

classやmodule内に書かれたメソッド以外のプログラムは「Ruby インタプリタが読み込んだ時にすぐ評価される」。なので書く場合は読み込む順番を考慮しないといけないので、注意が必要です。以下はエラーです。

class Hoge
  puts Fuga.fuga
end

class Fuga
  def self.fuga
    "Ruby!"
  end
end

実行結果

% ruby test.rb 
test.rb:2: uninitialized constant Hoge::Fuga (NameError)

2010-03-16

Rubyで数値文字参照を文字列に変換

ruby programming

Rubyで数値文字参照を文字列に変換するのってどうやるんだろう・・・と思って調べてみました。

数値文字参照とは

文字参照 - Wikipedia
上記を読んでいただければ分かります。

HTMLなどのSGML文書においては、直接記述できない文字や記号（マークアップで使われる "<" や "]]" など）を表記する際に用いられる方法である。
XMLにおいては、HTMLにおける「数値文字参照」を文字参照と呼ぶ。なおHTMLにおける「文字実体参照」は、XMLでは実体参照（Entity reference）と呼び区別する。

文字列と数値文字参照の変換をやってみる

【みんなの知識ちょっと便利帳】文字列と数値文字参照(文字参照)の変換スクリプト - 機種依存文字文字化け防止でWeb上で変換できます。

文字列 - ♪
10進数数値文字参照 - &#9834;
16進数数値文字参照 - &#x266a;

HTMLで実際に書いてみる

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
<body>

♪
<br>
&#9834;（10進数による指定）
<br>
&#x266a;（16進数による指定）
<br>

</body>
</html>

ブラウザで見ると以下のように表示されます。

Rubyで数値文字参照の変換をやってみる

htmlentitiesというライブラリがありましたので使ってみます。

% wget http://rubyforge.org/frs/download.php/62613/htmlentities-4.2.0.tar.gz
% tar zxvf htmlentities-4.2.0.tar.gz
% irb
> $LOAD_PATH.unshift('/path/to/htmlentities-4.2.0/lib')
> require 'htmlentities'
=> true
> puts HTMLEntities.new.decode("&#9834;")
♪
=> nil
puts HTMLEntities.new.decode("&#x266a;")
♪
=> nil
puts HTMLEntities.new.decode("&#9834;&#x266a;")
♪♪
=> nil

Rubyの実行環境

OS	Mac OS X 10.6.2
ruby	ruby 1.8.7 (2010-01-10 patchlevel 249) [i686-darwin10]
gem	1.3.5

参考

2010-01-24

47都道府県の入力はもう手入力することはない

programming ruby

HTMLのフォームで都道府県を選択するSelect Boxを作成するのですが、「あの県がない！」ということが過去にありまして、４７都道府県を手で入力するのはもう嫌だと思い作成しました。

github URL

GitHub - japanrock/prefecture: prefecture list of japan

利用方法

% git clone git@github.com:japanrock/prefecture.git

ようするにprefectures.csvを使います。

詳しくはwiki

http://wiki.github.com/japanrock/prefecture/

都道府県の一次情報は総務省だろうと思い、都道府県リストの生成は総務省のデータを利用しています。

issue

Issues · japanrock/prefecture · GitHub

どんどん書いていただけると幸いですm(_ _)m

2009-07-21

Rubykaigi2009 3日目高橋征義さんの基調講演: Rubyと私、そして日本Rubyの会

日記 ruby

Ruby会議３日目、最後のキーノート。高橋征義さん。とっても素晴らしい内容でした。
そのメモと感想です。

今回のRubykaigiのテーマ

変化（change）
変わる、変える

テーマの理由

前回は多様性がテーマであった、多様なだけではバラバラなだけ、それではよくないので何かしら変えるべき、変えざるを得ない、何を変えるか、Rubyを変える、私たちを変える、私たちはどう変わるべきなのか、そんな考えで決めたのが今回のテーマ。

Rubyは変化してきた

1997年 Ruby 1.1
- バイナリ配布なし
- 自分でコンパイル
- リファレンスマニュアルはあった
- 最後はソースを読む
- 基本的な部分は安定
Rubyのコミュニティ
- ruby-list
- ruby-dev

一般ユーザが出来ること

書籍の執筆
- 「たのしいRuby」「Ruby | Rails レシピ」
イベントの開催「Rubykaigi」
団体の設立（コミュニティの設立）「日本Rubyの会」

ユーザ視点でのRubyの変化

大きな課題
- みんな同時に幸せになるのは難しい、捨てること、捨てなければ変われない、捨て去る変化を受け入れる
Rubyの経緯
- さまざまな諦めがある
- さまざまなライブラリの取り込み

昔のRuby、まつもとさん一人による開発

問題点２つ
- まつもとさんがかけるものしかかけない、まつもとさんがよく知らない分野のもの、まつもとさんが興味のないもの、まつもとさんんが使っていない環境への対応、それらは実装されないのでほかの人のコードが入る。
- 言語はいろんなものに対応が必要、規格の取り込み、外部ライブラリ、世の中の流れ、流行、一人では追いつかない

変化の方針が必要

コミッタの増加（いい変化）
みんなでメンテ（昔は1人だったが変化してきた）

変化によってうしなったこと

統一性（これはRubyっぽくないということが発生する）
対応の遅延（多くの人との意思共通が大変）
Ruby1.6の時代は海外進出の本格化
Dave & Thomasの書籍の発行が大きかった。Programming Ruby）
Railsへの下地作り、1.6時代に失ったもの
- コミュニティの分裂、異なる自然言語（人間の言語）
- 異なるコミュニティ、英語圏と日本圏（お互いの意見が伝わらない）
Ruby1.8の時代
- 変化があった、一般の普及が一番大きい
- Railsの影響、1.8時代に失ったもの
- 要求水準の高度化、重い開発プロセス
- 批判の声の増大
- 強制的に使わざるを得ない状況が作られると批判が増える
- Rails文化とRuby文化
- 文化の分裂（RubyとRailsのぶつかり合い）

さまざまな喪失

喪失を恐れない
それを超える収穫を得るため、どうすればよいのかを考えることが必要

変化を選別する必要がある

変化をコントロール
Rubyのコントロール
私としては傍観者的立場

私が変えられるもの

それは日本Rubyの会

Rubyの会の変化について、日本Rubyの会の現状

いろいろやってる（Rubykaigi etc）
地域Ruby会議支援
るびま
るりま（日本語のリファレンスマニュアル）
地域コミュニティのハブ（基本的にはメーリングリスト、アナウンスする場）

問題点山積み

活動の多様化できていない
動いてはいる、止まりがち
思い切った改革
手が回らない
情報公開できていない（一部の人が動いている。ほかの活動も同じ）

ボトルネック

私の限界
Rubyの会の限界につながる
Rubyの会の構造
優しい独裁者
Rubyと同じ
それが足かせになってる
自分にはできないことができるようにしたい -> 全然未定、案１、権限の委譲（Rubyの開発を委譲していくように）
会長の集団、あまり解決策ではない
プロジェクト毎の代表、これだけではあまり現状と変わらない
システムによるサポート、MLを捨てる？（今はRubyの会の母体になっている）
プロジェクト管理のシステム化、redmineとか、関心あるプロジェクトに属する
プロジェクトに属する人が会長、私を捨てられる形を作ること、トラックナンバー+=1
私がさほど面白いと思わないことをどんどん積極的にやってほしい
楽しい未来

まとめ

変化には喪失がつき物
喪失を超える良いものを作っていきたい

キーノートの感想

非常に良いキーノートでした。今回のRubykaigiでRubyがもっと好きになりました．
組織が大きくなって良いこと、困ること、様々ある。困ることと言えば、キーノートでも言っている通り、「文化の分裂」だと思う。
組織が大きくなると、いろいろな人が入ってくる、いろいろな考えを持っている。
「文化の分裂」は怖いが、勇気を持ってそれを受け入れつつ進歩して行くか、かたくなに拒否しながら進歩してリーダーの想いを貫くか。選択する必要がある。
大きくなったプロジェクトの隅々まで1人で管理することは難しいが、それにも負けず、世界からの声にこたえ機能を取捨選択し、Rubyの方向性を見失わず、進まなければならない。
まつもとさんも言っていた通り、割れ窓理論もある。どこか１つの「今のRubyらしくないところ」が汚染をはじめるかもしれない。
変化には喪失がつきものだが、喪失によって「今のRubyらしさ」を失って行っていいのか、どうなのか。
私個人的には、失ってほしくない。Rubyの設計思想はとっても好きだ。
また、組織が大きくなり、コミュニティの数も多くなり、「あっちのRubyコミュニティとこっちのRubyコミュニティは違う」とか
「西日本と東日本のRubyが違う」とかこのようなこともあまり望まない。
そこから、派生して、新しい言語の発展は生まれるかもしれないが、「それはそれ、RubyはRuby」であってほしい。
私はRubyコミッタではないが、私にも出来ることがあると思う。Rubyでのソフトウエア開発と、Rubyコミュニティの応援だ。これからも使い続けて行くRuby。
Rubyにかかわるすべての人に感謝しつつ、少しでも恩返し出来ればと思う。

2009-07-18

Rubykaigi2009 まつもとゆきひろさん基調講演

ruby 日記

去年は参加出来ませんでしたが、今年はRubykaigi2009に参加しています。
２日目にまつもとさんの基調講演がありました。そのメモと感想です。
素晴らしい内容で、さらにRubyが好きになりました。

Ruby 羅針盤

われわれはどこにいて、どこに向かっているのか？
2009年、日本
21世紀初頭は、プログラミングの黄金時代。人間の都合で選べる時代。
80年代、90年代のプログラミングはひどい。とにかくＰＣのパワーが弱い。そのせいでひどくプログラミングが捻じ曲げられた。
今は、Rubyなどが議論させるよい時代。

まつもとさんが言うように、私も今の時代（２１世紀初頭）はプログラミング黄金時代だと思っています。

音楽で言うと、１９７０年代だと思っています。どんどん新しい物が生まれる時代です。
１９５０年代までの商業音楽は、クラシック、ブルース、ジャズ、R&B、フォークが中心の時代。まだシンセサイザーがない時代です。ピアノ、オルガン、アコギが中心。レコードでモノラルサウンドです。
１９６０年にビートルズが登場して、世界中に衝撃を与え、１９６９年のビートルズの解散。このころにはステレオサウンドになってます。
ビートルズの実験的な音楽や想像力は後世への影響が大きく、そこを基礎にさまざまものが生まれます。

音楽の１９７０年代は、
プログレ、ハードロック、メタル、（いわゆる）ビジュアル系（私はデヴィッド・ボウイが最初だと思っている）、シンガーソングライター、AOR、シンセサイザーの開発、それらの融合などなど・・・。
ヤードバーズの流れを経てディープパープルが８ビートで爆音ライブをやり驚かされハードロックを築き、ジョンレノンが美しいメロディを歌い上げ、ピンクフロイドなどがプログレを築いた時代です。
シンセサイザーや録音技術の向上など、さらに人間が想像力を膨らませられるようになり、さまざまなものが生まれました。

２１世紀初頭のプログラミングはまさに、音楽の７０年代のように、さまざまなものが生まれる時代なのだと思います。
戦争の影響で生まれたインターネットが発展し、１９９５年のWindows95で爆発的に普及しましたが、まだまだ通信速度が遅く、PCの性能も低い物でした。
あれから１０年以上経ち、PCの性能は飛躍的に向上し、通信速度も飛躍的に向上しました。32kbpsで最速！といっていた時代はとっくに終わっている訳です。
インターネットの普及により生まれた、Linux、同時にHTTPの規格の成長やPerl,Ruby,PHP,Java,C++などのプログラミング言語の発展があり、プログラミング言語やインータネットはいま黄金時代です。情報革命時代のど真ん中です。どんどん新しいソフトウエアが生まれます。あのころは良かったと振り返れる時代に成ると思っています。

まつもとさんのアイデンティティ

Ruby作者
（根本は）言語オタク。言語をすべて愛している。
プログラマ（子供にも教えたいが、自分がやる気にならないと駄目）
文筆家
ブロガー（更新できない）
Twitter( yukihiro_matz )

われわれはどこに向かっているのか

アティチュード
感謝を忘れてはいけない（たくさんの人たちの努力とかかわりで、Rubyはできた）
酸っぱいブドウ（自分には届かないところは、実際は甘いものだけど、酸っぱいものだと思う）
- 言語が嫌いといっても好みの問題が多い。
- 自己正当化
- 真実から目を背ける（フェアではない）
Rubyには欠点があるのを素直に認める
割れ窓理論
- Rubyにはバグがある、それを放置しておくと、Rubyがスラム化（だめになる）
- あまり変化しないソフトウエアは面白くない
- 互換性を考えると変化しないほうがいいという考え方もある。
- 常に変化をし続ける必要がある。割れた窓をほっておくとだめ。
- バグを直すスピードより、バグを発見するスピードが速いので、ばぐがたまっている・・・。

責任

ナイフ。鉛筆を削るためにつかった。人を刺すためではない。
言語はいろんなことができると危ない？
道具の使い方の問題。
強い力（Ruby）を与える（責任を与え）、信頼することによって、人にパワーをあたえ、成功するのが良い。

Rubyは非常に強力だ。使い方によっては、人を傷つける。
まつもとさんは、子供の頃に鉛筆を削るために、ナイフを渡された。親は子供がそのナイフで友人を刺すということはしないだろうと「信頼」したのだ。
Rubyはそのナイフと同じだ。皆さんを信頼している。

原則

フェアである
自己責任
信頼する

まつもとさんはCが一番好き

まつもとさんの作業環境

Emacs
Subversion
StGIT(Stackd GIT)

バージョン管理システムは、ネットにつながないと使えないという欠点がある。Stacked GITで解決。パッチなどをStackd上に積み上げることが出来る。

StGIT
- VCS on top of Git
- Patch Stacking

未公開スタック

27スタック
ほとんどは実験
いくつかを紹介

以下、スタックの例。

exmplex_lliteral

複素数リテラル
1.2+4i
互換性問題なし
Yuguiさんの承諾必要

true_division

1/2 → 有理数 1/2
有利数正規化（2/1→2）には必須
互換性問題代
2.0?

as_conv

明示的な変換（to_a）
暗黙的な変換（to_ary）
明示的な変換は（as_xxx）
暗黙的な変換は（to_xxx）

math_crror_check

Math関数が例外を返す NaNを返さない
Math関数以外は？0.0/0.0とか

ol_bitmap_marking

あとで

nloop

多重ループメソッド

  nloop(3,3,3) {|i,j,k|
   p [i,j,k]
  }

※コードは移し間違えの可能性があります。

str_index_offsset

Bug?

a = "foo"
a[3] = "x"
p s # =>"foox" or exception error

※コードは移し間違えの可能性があります。

sym_gc

シンボルを回収数るGC
GCが遅くなる
シンボルを繰り返しアサインするかも

private_ivar

スーパークラスと共有しないインスタンス変数
@_foo で private
逆のほうがのぞましいか

block_local_vaars_eq

「:=」で代入した変数はブロックローカル
ブロックパラメータでの宣言が不要になる

module_as_trait

module+module
- 新しいモジュールを生成
- メソッド重複でエラー
module - [sym,..]
- メソッドを削除

open_class_overriide

メソッド再定義でオーバーライド
superで呼べちゃう
アスペクト指向のベース
互換性の問題

keyword_args

メソッド定義でキーワード引数
def foo(a, b:4, c:7)
...
end

lvar_propagate

ローカル変数のスコープ
一番外のスコープに更新

  100.times do |x|
     v = x
     ...
   end
   p v  # propagated

※コードは移し間違えの可能性があります。

まとめ

フェアである
自己責任
信頼する（Rubyはみなさんを信じている）
感謝
継続する（不遇の時代から、陽を見た）

Rubyコミュニティはモヒカンである。
Rubyはこれからも良くなり続ける。
みなさんの意見によって言語がかわれる。フレキシブルな言語でありたい。

最後に基調講演を聴いたまとめ

「Rubyは「悪い物は悪い」といえるコミュニティでいたい。まつもとさんがもし悪いことをしたらコミット権を取り上げるようなコミュニティであってほしい」
とまつもとさんは言っていた。

私はRubyを使ってソフトウエアは作るが、言語設計については正直よく分かっていない。
「まつもとゆきひろコードの世界~スーパー・プログラマになる14の思考法」を読み「おー、このような考えで設計されているのか」と思っている程度である。
この本を読んで、Rubyはより好きになったが、今日のまつもとさんの公演を聞いてさらに好きになった。
これからもずっと使い続けたいと思った。

最後に、まつもとさんはじめRubyに関わるすべての人に感謝。

最後に、Rubykaigi2009のバッチを貼ってみました。バッチはこちらにあります。

本当のアジャイル

環境を変えて語り合う

「ふりかえり」とアジャイルの弱点

写真集

railsコマンドの場所を知る

railsコマンドの内容を知る

詳しく見る

/opt/local/lib/ruby/gems/1.8/gems/rails-2.3.5/bin/rails の中身

実験環境

まとめ

数値文字参照とは

文字列と数値文字参照の変換をやってみる

HTMLで実際に書いてみる

Rubyで数値文字参照の変換をやってみる

Rubyの実行環境

参考

github URL

利用方法

詳しくはwiki

issue

今回のRubykaigiのテーマ

テーマの理由

Rubyは変化してきた

一般ユーザが出来ること

ユーザ視点でのRubyの変化

昔のRuby、まつもとさん一人による開発

変化の方針が必要

変化によってうしなったこと

さまざまな喪失

変化を選別する必要がある

私が変えられるもの

Rubyの会の変化について、日本Rubyの会の現状

問題点山積み

まとめ

キーノートの感想

最近のRuby

まつもとさんのアイデンティティ

われわれはどこに向かっているのか

責任

原則

まつもとさんの作業環境

未公開スタック

exmplex_lliteral

true_division

as_conv

math_crror_check

ol_bitmap_marking

nloop

str_index_offsset

sym_gc

private_ivar

block_local_vaars_eq

module_as_trait

open_class_overriide

keyword_args

lvar_propagate

まとめ

最後に基調講演を聴いたまとめ