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.

やさしいGemパッチの作り方

203 views

Published on

#omotesandorb発表資料

Published in: Software
  • Be the first to comment

  • Be the first to like this

やさしいGemパッチの作り方

  1. 1. やさしい(※)Gemパッチの作り方 ※個人の感想です Toshio Maki(@Kirika_K2)
  2. 2. Gemのカスタマイズあるある  Gemをカスタマイズしたい  本家に提案したいが、機能がニッチすぎて微妙  仕方がないので、Forkしてソース改変して自社リポジトリに  カスタマイズ案件が1つに留まらず、色んな人によって魔改造が続く  そして時がたつ…  オリジナルのGemのバージョンを上げたい  変更箇所が多すぎて崩壊  Gitのログとチケットと聞き込み調査を元に変更意図を追っていくしかない  担当者は死ぬ
  3. 3. とあるmail gemの話  mailライブラリは便利  最小の労力でメールのテキストが作成できる(複雑なRFCの理解も不要)  が、色々便利に気を回しすぎるため、お節介すぎるところもある  Pull Requestの取り込みが遅い(欲しい機能が半年以上前にPRで出ているとかある)  他に選択肢もないので、mailライブラリに手を入れることにした  独自機能追加&Pull Requestに出ている欲しい機能を先行取り込み  1年後に上がったバージョンに追従(2.6.3 → 2.6.6)  変更点多すぎ😱  先行して取り込んだPull Requestがどう取り込まれたのか、よく分からない
  4. 4. パッチ用のGemを作ることにした lib/ mail_extension/ patches/ awesome_patch/ message.rb body.rb spec/ patches/ awesome_patch/ message_spec.rb body_spec.rb awesome_patch.rb mail_extension.rb mail_extension.gemspec 拡張元のGemをバージョンまで指定 add_dependency “mail”, “= 2.6.6” パッチ単位でディレクトリを作成 変更対象のファイル名と同名にする module MailExtension::Patches::AwesomePatch::Message lib/mail_extension/patches/awesome_patch以下の ファイルをrequireする 後述 パッチ以下のSpecを書く
  5. 5. mail_extension.rbの中身 require ‘lib/mail_extension/patches/awesome_patch’ require ‘lib/mail_extension/patches/great_patch’ require ‘lib/mail_extension/patches/good_patch’ module MailExtension ::Mail::Body.prepend Patches::AwesomePatch::Body ::Mail::Body.prepend Patches::GreatPatch::Body ::Mail::Body.prepend Patches::GoodPatch::Body ::Mail::Message.prepend Patches::AwesomePatch::Message ::Mail::Header.prepend Patches::GoodPatch::Header end 作成したパッチをrequire 拡張するクラス単位で、 prependをまとめる
  6. 6. メリット・デメリット  メリット  gemspecのバージョンを変えてspecを走らせるだけでいいので、VerUpが楽  lib以下にはパッチ単位で変更点が並ぶので、機能の着脱が楽  mail_extension.rbでは拡張されるクラス単位で並ぶので、影響範囲が読みやすい  パッチの数は少ないほどいいので、パッチを減らすモチベーションが働く (Pull Requestを投げて、取り込まれたらExtensionからパッチを外す)  デメリット  すべてprepend/extend/includeで書ききらないといけないので、ちょっと難しい  場合によってはprependの順序も気にする必要がある  元の実装上完全につぶさないといけないメソッドもありうる (NOTEコメントで注意書きを残しておく)  prepend/extend/includeのオーバーヘッドがちょっと気になる
  7. 7. 公式へのPull Requestが一番  パッチを減らすために、なるべく公式へContributeする  明らかにバグなものは報告しやすいので、どんどんやる  ニッチな機能やメリットの伝わりにくいリファクタリング をどう説明するかは結構課題。メリットの伝わりやすい機 能追加ストーリーの中に含められるなら、一緒に提案。

×