Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

パッチを書いてみよう(第17回Nseg勉強会LT)

2,594 views

Published on

Published in: Technology
  • Login to see the comments

パッチを書いてみよう(第17回Nseg勉強会LT)

  1. 1.  パッチを書いてみよう masa 2011-07-23 Nseg 第 17 回勉強会
  2. 2. 自己紹介 はてな:http://d.hatena.ne.jp/masa141421356 (id:masa141421356) Twitter : @masa141421356 ほぼプログラマ。仕様の打ち合わせから実装まで全部やります。
  3. 3. Firefox のパッチってどう書くの?
  4. 4. 第1部:パッチを書くのに必要なもの・Firefox のバイナリをビルドできる開発環境・bugzill.mozilla.org のアカウント・ Firefox で使用している技術(C++, JavaScript, HTML, CSS, XUL, HTTP, etc.)の知識・ 「ある程度」の英語力
  5. 5. ・作業時間(これ重要)・ 自分が気になったバグを追いかける根気1. 開発環境 MDN 開発者ガイド    https://developer.mozilla.org/ja/Developer_Guid e
  6. 6. 殆どのツールは OS 付属か無料ダウンロードで揃う。SDK 揃えるのが面倒?ま、ビンゴ揃えるつもりで (By Benjamin Smedberg)http://benjamin.smedbergs.us/blog/2008-04-16/microsoft-header-bingo/
  7. 7. 2. bugzilla.mozilla.org アカウント メールアドレスがあれば OK ログインしている人にはメールアドレスが見 えるので、英語 SPAM が嫌いな人は迷惑メー ル対策の出来るアカウントでやるのがお勧め
  8. 8. 3. 技術の知識Firefox のソースはコアの部分は C++UI は XML/HTML + JavaScript + CSS など。UI 系だと画像を作るだけでよいバグもある
  9. 9. (bug 414243 誰かやりませんか?)
  10. 10. そのほかには Web に 関 わ る 各 種 の 標 準 (HTTP, HTML, XML, ECMAScript, CSS 等) OS の標準的なアプリケーションのガイドラ インや API の知識
  11. 11. あと、Mozilla のコーディングスタイルガイドライン。大体周辺のコードのスタイルに合わせれば OK。技術を全部知っていなくてもパッチは書ける。
  12. 12. 4. 「ある程度」の英語力  bugzilla.mozilla.org のディスカッションは 基本的に英語
  13. 13. 技術的な話だけのディスカッションの場合はそれほど難しい言葉は出てこない(専門用語は別)。簡単に直せるバグは説明や議論に使われる単語や言い回しも簡単なことが多い。
  14. 14. 仕様や設計思想に関わるディスカッション  ↓難しい話や慎重な議論が必要なものは、必然的に使われる言葉が難しくなる
  15. 15. 結論が明らか(直したほうが良いことが明らかなバグ)   ↓大体使われている単語も簡単
  16. 16. Typo は? あっても大丈夫。でも、スペルチェッカーは有 効にしておくことは推奨。それだけでかなりミ スが減る。 誤解を生むような typo はすぐに訂正を入れれ ばよい(コメントを取り消せないことはみん な知っているので)。
  17. 17. 今の自分の目標 1つも typo をせずにバグ登録か ら修正完了までの処理を完了する こと
  18. 18. 5. 作業時間 自分の場合は夜と休日の空き時間。 家庭も大事。休みの日全部をつぎ込むと理解が 得られなくなる。 実質的には土日で合計半日が限界。
  19. 19. でも、何もしないのと少しでも手を動かすのは全然違う。
  20. 20. 6. 気になったバグを追いかける根気興味を持った分野のバグか自分の見つけたバグが追いやすい。
  21. 21. 興味のある分野・主力分野を突付く。・Windows の High Contrast で UI 部品の色が周囲と同じ になって見えないバグ・URL に変な文字を突っ込むとブラウザが誤動作する・実質的に Web アプリと見なせるもののセキュリティ
  22. 22. 第 2 部:実際に直してみよう 実例(bug 660612)を参考に
  23. 23. 1.直すべき場所の見当をつける・ 機能から想像される変数名でソース検索 MXR で検索できる( http://mxr.mozilla.org/ )  例:フォントの高さがウィンドウサイズより高い場合にページ スクロールの量が極端に少ない(bug 383267)    → fontHeight でソース検索
  24. 24. ・ 問題となる箇所に固定文字列があればそれでソースを検索する。・ UI 系は DOM Inspector で見当をつけて、userChrome.css で試 してみる。・ 国際化された文字列なら、リソースを検索してリソース名からあ たりをつける・ 自分が過去にパッチを書いたことがある部分は想像がつく・ ディスカッション中にヒントが見つかることも
  25. 25. ・ bug660612 の場合 bug660612 : Utf8ToOneUcs4Char passes invalid UTF-8 octets %ED%A0%80, so decodeURIComponent(%ED%A0%80) doesnt throw 知ったきっかけは @Constellation さんのつぶやき
  26. 26. 後日バグの詳細がはてなへhttp://d.hatena.ne.jp/Constellation/20110530/1306759498
  27. 27. 問題のコード http://hg.mozilla.org/mozilla-central/file/e0ca895fde7e/js/src/jsstr.cpp#l5977
  28. 28. 何故特定できたか? →以前パッチを書いた場所
  29. 29. http://hg.mozilla.org/mozilla-central/annotate/e0ca895fde7e/js/src/jsstr.cpp#l5977
  30. 30. 2. 直してビルド  手元のソースを修正してビルドする。   元の改行コードと文字コードを維持できる エディタが必要(LF 改行対応必須)
  31. 31. 3.意図どおりに直ったかテスト どうやってテストする? ↓ バグに添付されたテストケースで試す。   ↓ 良質なテストケースが無いと検証不能   ↓ 良いテストケースを書ける人は高評価
  32. 32. 4.リグレッションのチェック他の機能へ影響が大きそうな場合は慎重に。 自動テストがある機能はテストを走らせて見る
  33. 33. 5.可能なら自動テストも書く・自動テストが書いてあると話が早い ・リグレッションがあった時に Tinderbox が 炎上してすぐにわかる    ↓  テストを書いて通るのを確認!!
  34. 34. 6.パッチをアップロード・自動テストの配置するべき場所に自身が無い・なぜか hg diff で追加ファイルのパッチが出 ない    ↓ jsstr.cpp は修正パッチとして登録
  35. 35. テストは単独ファイルで添付
  36. 36. テストは長いので省略
  37. 37. 7.レビューレビュワーは誰にするか・ガイドラインは MDN に書いてある・ CVS Blame や Hg Blame で自分が直した 場所にその前に手を入れたバグを探して、パ
  38. 38. ッチのレビュワーを探す
  39. 39.  今回は、前にパッチを書いたときと同じ Jeff Walden さんにした
  40. 40. 8.指摘事項のある r+とコメント
  41. 41. 9.指摘対応その1指摘事項・自分なら2つの if を1つにまとめるね・テストは decodeURIComponent("%ED%A0%80") がURIError を投げることのチェックだけにして、余計なものを削って、js/src/tests/ecma_5/Global に置いてください。
  42. 42.  相変わらず hg diff で追加ファイルがパッチに 出ないので、仕方なくテストは手作業でパッチ に変換。 パッチは変換ミスがあったので後で差異アッ プロード
  43. 43. 10.指摘対応その2と 3 だいたいそのままなので日本語訳省略
  44. 44. ここでようやく hg add ファイル名をしないとパッチに新規ファイルが乗らないことに気づく(MDN に書いて欲しい)
  45. 45. 書き直した部分
  46. 46. ここで 1 つミスをした。指摘内容と比べてみよう
  47. 47. ( )の数がコメント内容と違ってます…orzこの指摘と修正を経てようやくコメントなし
  48. 48. r+がつきました。
  49. 49. 11.チェックインへコミッタじゃない人はチェックインできないので誰かにチェックインしてもらう
  50. 50. このコメントと一緒に checkin? をセットこの間で checkin+ になった
  51. 51. 12.フォロー・セキュリティホールなど、現行バージョンの 修正を検討するべきバグだった場合     ↓ フラグやコメントで現行バージョンへの投入 が必要かどうか相談する同じパッチが使えない場合は、各ブランチ用にパッチを書く。
  52. 52. ・Seamonkey も気にする。 ブラウザ固有機能のバグなどでは、Firefox と ほぼ同じコードが Seamonkey にも存在す ることも多いので、そちらのケアもする。   ・Rhino も気にする
  53. 53. JavaScript エンジンの場合は Rhino もチェ ックしておく  Question?

×