2013/08/31関西ruby会議05発表資料

4,471 views
4,341 views

Published on

2013/08/31に行われた関西ruby会議05での私の発表です。
スライドだけでは良く分からないので、しゃべった(と思っている事)を記載しておきました。

Published in: Technology
0 Comments
22 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,471
On SlideShare
0
From Embeds
0
Number of Embeds
314
Actions
Shares
0
Downloads
16
Comments
0
Likes
22
Embeds 0
No embeds

No notes for slide

2013/08/31関西ruby会議05発表資料

  1. 1. No Sugar ~私はどのようにしてRails開発に貢献したか~ 今日はNo Sugar ~私はどのようにしてRails開発に貢献したか ~ というテーマでお話させて頂きます。
  2. 2. 2013 今年2013年は、rubyにとって重要な年です。
  3. 3. Ruby生誕20年 まず何より今年はRuby生誕20年。我らがRuby言語は大人の仲間入りをはたしました。
  4. 4. 2月24日 Ruby2.0 そして大人になった誕生日に、記念すべきRuby2.0がリリースされました。Ruby1.8 , 1.9 , 2.0と利 用してこられていると思いますが、どんどん良くなっていますよね! これからも、どんな進化をしていくのか楽しみです。
  5. 5. 5月30日-6月1日 RubyKaigi 2013 カクタニさんから後でたくさんお話があると思いますが、5/30 – 6/1は、RubyKaigi 2013が開催さ れました。RubyKaigiは昨年実施されませんでした。参加者としては悲しい思いをしましたが、今年見 事に復活しました。復活しただけではなく国際的なカンファレンスとして生まれ変わっており大変楽しい イベントでした。皆さん行かれた方は?
  6. 6. 8月31日 関西Ruby会議05 そして何より今日は、関西ruby会議05が開催されましたが、こちらも去年実施されませんでした。一度 止まってしまったものを復活させる事は、最初っから始めるよりも難しいと思います。だから今日開催出 来たのは、実行委員やスタッフの方々の努力の賜物なので、ぜひ拍手をする事によって謝意をしめしたい です。みなさんも拍手して頂けませんか?
  7. 7. 6月25日 Ruby on Rails 4.0 Ruby界にとってもう一つ重要な事がありました。それはRuby on Rails4.0のリリースです。この事は 私が今日お話をさせて頂けた事と関係があります。今日はその辺りの話をさせて頂こうと思います。 皆さんのお顔を眺めていると「こんにちは」と言える人が少しずつ増えてきたなと感じて嬉しく思ってお りますが、恐らく多くの方にとって今考えているのはこんな感じでは無いでしょうか?...
  8. 8. なので、お約束ですが自己紹介させて下さい。
  9. 9. 梶原寿宣 kennyj 37才 大阪 ㈱日本ビジネス開発 IT屋 管理事多 ~ 子供*2、妻*1、マリオ*1の家庭を営んでいます!
  10. 10. 2005 ここで少し昔話をさせて下さい。2005年、当時私はバリバリのjava屋さんでした。 当時の流行りはDependency Injection。カクタニさんの翻訳を読んでどうやって業務に取り入れるか 考えたりしていました。 そんな折、いつものようにネットで技術情報を調べていると、凄い動画を発見しました。
  11. 11. Ruby on Rails これがRuby on Railsと私の出会いです。 もちろん15分で~とか、javaの10倍の生産性という宣伝文句が誇大広告すぎると思わないほど、分別の 無い年齢ではありませんでしたが、それでも色々調べると心惹かれるポイントが多数ありました。
  12. 12. class Post < ActiveRecord::Base validates_presence_of :title end 例えばActiveRecordのコードを見てみると、なんで動くのか分かりませんでした。 Getter / Setter何処にいってん! 入力チェックなんでこれだけでいけるねん! 本当にミステリアスで興味を持ちました。しかし最も私がRailsに惹かれた点は...
  13. 13. TDD Kent Beck http://upload.wikimedia.org/wikipedia/commons/5/55/Kent_Beck_no_Workshop_Mapping_XP.jpg
  14. 14. PofEAA Martin Fowler http://upload.wikimedia.org/wikipedia/commons/f/f8/Martin_Fowler_%282008%29.jpg
  15. 15. DRY原則 David Thomas http://upload.wikimedia.org/wikipedia/commons/f/fe/Dave_Thomas_speaking_at_the_Pasadena_Rails_Studio.jpg
  16. 16. 先人の知恵の上に立脚している(しようとしている)所が一番惹かれました。 「私の好きな人を好きな人が作ったものだから私も好き」といういささか乙女チックな発想ですが、心惹 かれたのだから仕方ありません。
  17. 17. 使いたい これだけ興味が惹かれるのだから、やはりこう考えました。 私より若い皆様はわかりませんが、少なくとも私の世代は、あまり簡単な事ではありませんでした。色々 と時間がかかります。ただ何もしなければ話は進まないので次のような事を考えました。
  18. 18. 基礎研究 社内システム 繰返し主張 チャンスに 備える 基礎研究: 本を読んだり、コードを書いたり、railsconfのpdfで情報を収集しました。 社内システムを作って実績を作ったりしました。またruby/railsの良さを吹聴し続けて「rubyと言えば 梶原」といった雰囲気を社内で作るように努めました。 私は「チャンスは平等にやってくる」と考えていますが、その来たチャンスを活かせるかどうかは、準備 をしているかどうかだと考えています。その意味では「チャンスは準備している所にやってくる」と言え ると思います。
  19. 19. 時は来た そして理解のある上司のおかげもあり、チャンスがやって来ました。 Ruby on Rails で案件をする事が出来たのです。そして成功させました。 (注 このページは故橋本真也さんの名台詞と共に橋本さんのコスチュームをイメージしたデザインにしま したが、誰にも気づかれていない感じでした。。) そこからは色々な事が有りながらも...
  20. 20. 良き仲間 良い仲間と良いお客様の、たくさんのお仕事ができました。本当にいい仕事が出来たと感じていました。
  21. 21. 幸せな日々 エンジニアとしてはとても満ち足りた日々でした。その理由の一つはrailsのおかげだと信じています。
  22. 22. 2011 日が過ぎ去り2011年、今から2年前の事です。
  23. 23. 仕事が変わってきた 私の仕事がだんだん変わってきました。 管理事や営業支援、査閲などが多くなり、プログラムをゴリゴリ書くことが少なくなってきました。 でもRailsの情報収集は続けており、Rails3のモジュラリティーや、asset pipeline等興味を感じずには いられませんでした。
  24. 24. こんなに仕事にお世話になっており、こんなに好奇心を持たせ続けてくれているのに、私はRailsに何も 出来ていないと感じるようになりました。
  25. 25. 過ぎ去った日々 でも中々動きだそうとせず、ただ日々が過ぎて行きました。 ところがある日私は良く分からない行動をしたのです。
  26. 26. http://portal.nifty.com/cs/hillsPhoto/detail/090711103502/1.htm ある飲み会の後、複雑な気持ちで家に帰り、お風呂に入り、 水を一杯飲みました。普通ならここで寝るのですが...
  27. 27. VPSに繋いだ その日は何故か机に座るとteratermでVPSに繋ぎました。 酔っ払っていたのであまり覚えていませんが、気づいたら...
  28. 28. Rails貢献者になった Rails貢献者になっていたのです。
  29. 29. Pull Request マージされた GithubのPull Request(パッチ)がマージされたのです。これまでただの利用者だったのが、この事で感 じ方が変わってしまいました。割と簡単に採用された事もあり、がぜん面白くなってきました!
  30. 30. 面白くなった
  31. 31. 活動が始まった このようにして私はRailsコントリビュータとしての活動を開始しました。 ここまでが、どのようにしてコントリビュータになったかという話ですが、直接のキッカケは 「酔っ払って」になります。なんとなくカッコ悪いですが、キッカケなんてこんな物かもしれません。
  32. 32. 私の作戦 Railsコントリビュータとして活動するにあって、無作戦で は駄目だと思い進め方を考えました。
  33. 33. バグ対策 対策を主要な活動にしようと考えました。
  34. 34. Issues バグ対の方法の中でも、githubのIssuesに載っているバグのうち「自分で手をつけられそうな物」を直し ていくという方法にしました。そうするのは、ある切実な問題がありました。
  35. 35. 昼間はバグに出会わない 昼間の仕事が、コーディングがゴリゴリでは無くなったので、昼間Railsのバグに 出会う可能性はかなり低くなってしまいました。だからIssuesにのっている他の 人が発見したバグを直すという進め方にしようと考えました。
  36. 36. Railsの構造を学べる 他人が見つけたバグという事もあり、自分で全く読もうとしていなかっ たソースを読む事ができるかもと考えました。そもそもRailsがどのよ うに動いているのかに興味があったので、一石二鳥と思いました。
  37. 37. 問題の切り分けが好き これは趣向の問題ですが、私は現象から根本原因を探るという過程、問題を切り分けていく作業が好きで
  38. 38. バグ修正の基本サイクル All green Pull Request changelog プログラム 修正 テストケース再現 バグ修正の基本サイクルは上記のような感じです。私見では仕事で実施する再現~プログラム修正より、 やや難しいと感じました。なおテストケースはRailsの中ではかなり重要です。
  39. 39. 詳しい情報が 分からない そもそもrailsの バグでは無い 例えば再現。そもそもrails/rubyのバージョンも分からず、何が問題なのかも分からないIssueが上 がってくる事もあります。そういう場合はコメント欄で色々質問し、情報を集める必要があります。また 3rd-partyのgemとの連携で上がる事もあります。スタックトレースから明らかに3rd-partyの問題と 分かっても、「railsの問題では無い」という事を証明してから指摘するようにしていました。
  40. 40. > rails new demo ここまで調べた後はRailsのバグの可能性があるので、普通にnewコマンドを実行し、小さいアプリ ケーションを作成して再現を試みました。恐らく上記のコマンドは数百回は叩いたと思います。
  41. 41. テストケース “何処”に 書くかが難しい テストケースを書くこと自体はあまり難しいと思いませんでした。何故なら既にたくさんのテストケー スがあり、自分の書くべきテストケースを類推する事はあまり難しくなかったからです。それよりも何処 にテストを書くかの方が、雰囲気を理解するまで時間がかかりました。
  42. 42. プログラム修正 単純明快 業務で出会うバグより、根本原因~現象までの距離がやや長いように感じました。 修正時にはサイドエフェクト(副作用)に気をつける必要があります。また修正は単純明快である方が良 いので何度もローカルでコミットを修正していました。
  43. 43. 英語 冗談抜きでやばい たまに質問される事があるので、英語についてお話します。私の英語力はとんでもなく低いです。現在 完了形も最近思い出したぐらいです。それでもRailsが好きで貢献したいので幾つか方法を考えました。
  44. 44. 他の人を観察 他の人のIssueでのやりとりを観察し、コピペや単語を勉強しました。また特有の語彙を覚えました。 例えば彼は自分の開発環境の事を「my box」とか言ったりするので、イキって「my boxでは」みたい な言い回しを多用しました。
  45. 45. Issue上で私は~と思うと意志の表明をする事が多いので、下記のような推測の3兄弟を考え、自分の 信じている度合いで使い分けていました。that以降は割とフリーな感じで。
  46. 46. 寛容 これが一番言いたいことですが、Railsのコミュニティーは本当に寛容だと感じました。私のひどい英語で も何とか意味を拾うように頑張ってくれました。Matz/DHHのおかげ?Railsは国際的なプロジェクトな ので、私以外でも英語も割と怪しい人がいます。そういった事も影響しているかもしれません。 もし英語のせいでRailsコミュニティに飛び込めてないなら勇気を持って進めて下さい!
  47. 47. 思い出のコミット1 初めてのPull Request ここからは少し思い出のコミットについて話をさせて下さい。 まずは私が初めてpull requestしたコミット。
  48. 48. 実はRails本体への影響は1byte、bを足しただけ。しかしこれには深いわけがあります。
  49. 49. 問題 assetのファイル名が 非ASCIIの場合 上手く扱えない 元々の問題は、Rails3.1から追加された機能のasset pipelineの中での問題です。Asset pipelineとは javascriptやcss、imageをそれぞれ一纏めにし、転送回数を減らしたり、apache/nginx等のキャッ シュにのりやすくする機能です。当時日本語のファイルを取り扱おうとすると上手く行きませんでした。 実際私の開発環境、my boxで試してみるといとも簡単に再現します。動きを細かく追っていった所、あ る問題に気付きました。
  50. 50. app /assets /images レイルズ.gif public /assets レイルズ-2cf3622c.gif manifest.yml ファイルは上手くコピーされているが同時に出力されるmanifest.ymlの中を除くと 問題がある事に気付きました。
  51. 51. File.open("manifest.yml", 'w') do |f| YAML.dump(manifest, f) end ファイル出力時に おかしくなる manifest.ymlの出力されている場所を確認すると、モードが”w”になっており、その結果上手く出力さ れていない事に気付きました。今だとエンコーディング指定で上手く行くと思いますが、当時は ruby1.8/1.9両対応が必要と考え、”wb”での提案としました。 教訓は、やはり日本人はunicode等文字コード周りは得意なので、狙い目ではないかと思います。
  52. 52. 思い出のコミット2 事故はおこるさ http://www.thomasandfriends.jp/
  53. 53. 問題 create_tableの id: falseが schema.rb生成時に 無視される Railsの機能にmigrationというDBの移行機能がありますが、その時create_tableメソッドにオプショ ンid: falseを渡すとPKの無いテーブルを作成できます。 しかし、その後自動生成されるschema.rbは、その設定が無視されてしまいます。
  54. 54. mysql> create table bar (baz varchar(255) not null); mysql> alter table bar add unique (baz); mysql> desc bar; +-------+--------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+--------------+------+-----+---------+-------+ | baz | varchar(255)| NO | PRI | NULL | | +-------+--------------+------+-----+---------+-------+ PKが無い時に UKをPKと返してくる。 自分の環境では簡単に再現し、MySQLだけで発生する事が分かりました。調べてみるとRails以前の問題 である事に気付きました。PKの無いテーブルを作り、属性項目にUKをはった状態で、descコマンドで確 認すると、上記のような仕様/バグ?というレスポンスを得ます。結果的にこの問題が発生しました。
  55. 55. 解決策 information_schema 動的カタログ、information_schemaを利用する案を提案し取り入れられました。
  56. 56. Rails 3.1.2 リリース そしてその修正を取り込んだRails 3.1.2がリリースされました。
  57. 57. しかし... しかし問題が発生しました。
  58. 58. リリース数日後上記のようなissueが上がりました。「10倍遅くなった!」 困った事に3.1.1 ~ 3.1.2の間でmysqlのアダプターをいじったのは私だけで このIssue上で色々情報を提供してもらいました。
  59. 59. 大きなデータでは 極端に遅くなる information_schemaは大きなデータセットの場合は、遅くなる事が分かりました。Issueの上でさら に議論し修正方法を考えて行きました。私は大きなデータ・セットを持っていなかったので修正したパッ チをテストしてもらったりしました。
  60. 60. desc ↓ information_schema ↓ show create index ↓ show create table 上記の様な変遷をして行きました。
  61. 61. Rails 3.1.3 リリース そしてバグとスピードの問題を両方をほとんど解決する事ができました。教訓は、私の反省でありCore- teamの反省でもあるのですが、こんなドラスティックな変更をstableリリースにいれてはいけないとい う事です。いくらrailsでも... railsらしい気もするが...
  62. 62. 思い出のコミット3 魔境database.rake
  63. 63. 問題 database.rakeが スパゲッティー化 しており拡張しにくい。
  64. 64. > rake db:migrate database.rakeとは、rake db:***系が実装されているtaskでよく使っているはずです。
  65. 65. database.rakeMySQL PostgreSQLSqlite3 Oracle SqlServerfirebird if-else地獄 恐らく歴史的経緯によるものだと思われました。今だにOracle/SqlServer/firebirdなどのサポートが非常に中途半端に 残っていました。
  66. 66. lib /active_record /railties database.rake ... /tasks database_tasks.rb mysql_database_tasks.rb postgresql_database_tasks.rb sqlite_database_tasks.rb 最初に提案した人は私では無かったのですが、あまり見かけなくなったので私の方で進めていきました。 database.rakeは、当初よりスリムになりDB毎の処理に分離できました。分離した事によって書くアダ プター毎の際、問題が明らかになるなど副次的な効果がありました。
  67. 67. No Oracle No SQLServer No firebird (rails 4.1) Oracle / SqlServer / firebirdのサポートをrails4.0でdeprecatedに4.1で削除する予定です。
  68. 68. 地味なコミット達
  69. 69. PostgreSQLのログを黙らせた。 NOTICE: CREATE TABLEはシリアル列"posts.id"用に暗黙 的なシーケンス"posts_id_seq" を作成します。 NOTICE: CREATE TABLE / PRIMARY KEYはテーブル "posts"に暗黙的なインデックス"posts_pkey"を作成します 色々小物の修正をしていました。Rails3.2.xでは、PostgreSQLを利用してマイグレーションを実行する と上記のようなログが出力されます。ある日、日本人の方がブログでボヤいていました。私も鬱陶しいと 思ってました。Pull Requestを作成し、core-teamに相談するとcore-teamも鬱陶しいと思っていた (?)みたいです。簡単に取り込まれました。
  70. 70. 日本語でルーティング match “こんにちは” => “welcome#index” http://localhost:3000/こんにちは これまではURLエンコーディングしてからルーティングする必要がありましたが、rails4.0は上記のよう に簡単に書く事ができますw
  71. 71. 色々と細かい修正をしていきました。
  72. 72. 予想もしなかった結果
  73. 73. 12th / 2012 258 commits The People Behind Rails 4 2012年のコミット数は世界で12位になる事ができ、今までに通算258のコミットを(数だけは)入れて もらいました。Railsの公式ブログで「The people begind rails4」という記事で紹介されたのは大変 嬉しかったです。
  74. 74. 一つ一つは単純な事 私のやっていた事は、本当に一つ一つは小さい事です。ただそれを積み重ねる事によって意味をもたせら れたのかも知れません。Railsを触った時に感じる質感は、こういったコツコツとした皆の働きの上にあ るのだと思います。「名も無き質」はこういった事から生まれるのでは無いでしょうか。
  75. 75. 皆様も同じく夜遅くまで仕事をしていると思います。だから実際にRailsに利用できる時間はあま り多くありません。そんな中で自分自身の目的を成し遂げていく為には、目的への集中が必要だと 考えて進めていました。私はgit/vim/debugger/英語等は中途半端にしか知りません。それぞれ の習熟をする為に時間をもっとかけても良いですが、それは”直接的”に目的を成し遂げる物ではな いので、ある程度使えるレベルに達せば、目的自身にフォーカスするようにしました。
  76. 76. Railsをより良くする事 その目的は「Railsをより良くする事」の一点です。
  77. 77. 感謝される 社会への貢献 プログラム/英語 世界とつながる 良かった 私はこの活動をしてよかったことは。①バグ対なので皆に感謝される、②広く使われているものなので社 会貢献をしている実感を感じた、③プログラム/英語が少しは上達した、④そして世界と繋がるですが...
  78. 78. http://i.gzn.jp/img/2007/05/18/osaka_shinsekai/osaka_shinsekai18.jpg わが町大阪。日本の一地方都市。恐らく世界では無名。 私だけかもしれませんが、我々関西人は東京にネタミを感じているはずです。 「IT投資が非常に多い。仕事が多い。勉強会とかも沢山ある。カンファレンスも ほとんど東京だ。」 でもインターネットとは凄い物で...
  79. 79. 大阪にいながらRailsのような国際的なプロジェクトに参画する事ができる。 「大阪やから○○出来ない」のような考え方は、自分の中で考えた勝手な言い訳に過ぎない。 一歩前進させれば、ほとんどハンデなしで世界と繋がる事ができる。 そう自信が持てました。
  80. 80. 悪かった いい話ばかりしてもあれなので、悪い話もしましょう。
  81. 81. 。。。
  82. 82. やはり寝不足になりました。仕事から帰っての活動になるのでどうしても遅くなります。また...
  83. 83. タイムゾーン Core-teamは欧米人が多いので、issueの事でチャットで質問しようとすると、どうしても彼らが活発に なる日本時間の2:30 – 3:00頃を待つ必要がありました。
  84. 84. マッド・カッツの 30日間チャレンジ しかし、ここで一つご紹介したい物があります。プレゼンの中でプレゼンを紹介するのはあれですが、 凄く好きなプレゼンなので紹介させて下さい。 TEDの「マッド・カッツの30日間チャレンジ」というプレゼンです。 このプレゼンの趣旨は~(注 観てみて下さい!!)です。
  85. 85. My 30 day challenges Add: Subtract: Bike to work 10,000 steps/day Take a picture a day Write a novel No TV No sugar No Twitter No caffeine そのプレゼンの中でこんなスライドが出てきます。 毎日自転車で仕事場に行く、10000歩/日...等が説明されていますが、 私の好きな所は...
  86. 86. My 30 day challenges Add: Subtract: Bike to work 10,000 steps/day Take a picture a day Write a novel No TV No sugar No Twitter No caffeine Subtract。減らす方です。TVをみない。砂糖をとらない。Twitterしない。カフェインをとらない。 良く~をしましたという話を聞くが、~をしませんでしたという話は聞きません。そういう意味で堂々と 教えてくれた所が凄く気に入りました。
  87. 87. 何かを選ぶという事 何かを捨てる事 使い古された言葉ですが「何かを選ぶ事は、何かを捨てる事」が正にその通りだと思います。 私も睡眠時間が短くなると共に、(大好きな)深夜番組を見る時間はほとんどなくなりました。 周りにいる凄い人の事を「なんか、この人すごいは。自分と全然違うは。」と思ってしまいますが、 きっとその凄い人は、ものすごい集中力で取り組むとともに(意識していないかもしれませんが)何かを 犠牲にしているのだと思います。
  88. 88. 成すべき事への集中 無限の可能性 本気で好きな物を発見して、その事に集中する。そして勇気をもって捨て去る事が何か大きな結果を残す 為の方法なのでは無いかと思いました。
  89. 89. 世界は あなたの貢献を 待っています 世界には、あなたが貢献すべき沢山の事があります。だから是非飛び込んでいって欲しいと思います。
  90. 90. そして願わくばRails~本当に素晴らしいコミュニティーであり、スリリングなwebを知る事ができるの で~の開発に参画してほしいなと思っています。 関西が、Railsコントリビュータの一大生息地になれば面白いですね。
  91. 91. Thank You For Listeningご清聴ありがとうございました。
  92. 92. Twitter: @kennyj_jp github: @kennyj

×