Rubygem開発の流儀

Transcript

1. Rubygem 開発の流儀 @joker1007

2. self.inspect @joker1007 Repro inc. CTO ( 要は色々やる人) Ruby/Rails uentd/embulk Docker/ECS

   Bigquery/EMR/Hive/Presto

3. おそらく地域Ruby 会議で 最も登壇した男です

4. 関西Ruby 会議は登壇3 回目 関西出身として光栄の至りです

5. Repro のサービス モバイルアプリケーションの行動トラッキング 分析結果の提供と、それと連動したマーケティン グの提供 Push メッセージ送ったり、アプリ内でプロモー ション表示 大体Ruby ・Rails

   でほぼAWS 上で稼動している Docker やterraform 等も活用している 会社規模の割にデータ量が多い。 プッシュ送るのマジ大変なので、助けてくれ。

6. Repro inc. は エンジニアを募集しております JS がとくいなフレンズ ( 特に人手不足) テストやQA がとくいなフレンズ

   ( 特に人手不足) Rails がとくいなフレンズ Hadoop やPresto がとくいなフレンズ

7. 本題のRubygem について 私がgem 開発の時に考えてることを話します 個別具体的な話が多いかも

8. Rubygem についておさらい Ruby で利用するパッケージシステム Ruby 本体にバンドルされている ライブラリに限らずアプリケーションの配布にも rubygems.org

9. ライブラリパッケージとしての特徴 作成、リリースが簡単 Gem le を使って必要なものを簡単にインストール Gem le.lock によるバージョン固定も簡単 GitHub にホストされているものも直接利用可

   つまりBundler 凄いし、超便利。

10. Rubygem の作り方の詳細についてはこちら パーフェクトRuby 第二版が絶賛発売中です http://gihyo.jp/book/2017/978-4-7741-8977-2

11. Rubygem 作ってますか？ 実際にリリースしてメンテしてる( いた) 人

12. ちなみに私の場合 Total Gems: 39 Total Downloads: 714460 ( 資料作成時調べ)

13. Rubygem は簡単に作れる -> 本当か？

14. 工程自体は簡単でも gem を作ってリリースするには 別のハードルがある 何を作っていいか分からない ゴールが想像できない 汎用化・抽象化のコツが掴めない

15. 結局難しいのは何か アイデアを生み出す ゴールに向かって工程や解決策を具体化する 多様な環境で使える様に調整する 何か自分で考えて作り上げるという行為自体が難しい しかし、これが出来る様になると仕事に超役立つ

16. とりあえずヒントを求めて gem をもうちょっと深く知る

17. 世の中にはどんなgem があるのか gem をざっくり分類してみる ( 独断と雰囲気による適当な分類です)

18. 開発支援系 ほとんどのgem はこれに含まれる。 また他の系統のものも大半はこのタイプとの複合。 複雑な定型処理をラップする テストコードのためのDSL を提供する ログを取り易くする ベンチマーカー、プロファイラー etc...

    ex. concurrent-ruby, rspec, activerecord-cause

19. クライアント系 自分のアプリケーションの外との通信を支援する。 サービス事業者の公式SDK や、それをラップしたもの が多い。 その他、プロトコルの実装等のパターンも。 DB 等の外部コンポーネントと接続する API クライアントSDK

    SDK をラップした使い易くしたもの 複数のサービスのI/F を統一したクライアント ex. redis, aws-sdk, koala, fog, github-commit-status- updater

20. フレームワーク/ ミドルウェア系 書き方のルールを定めたり、アプリケーション自体を 支える基盤になるもの。大掛かりなものが多い。 個人で書いてそれなりの完成度まで持っていくのは比 較的難しい。 rails, sinatra, hanami, padrino

    ... uentd unicorn, puma ... rack rukawa

21. プラグイン系 プラグイン機構を持つgem を拡張するもの。 書き方のルールがある程度決まっている。 Rails 拡張 RSpec formatter uentd/embulk プラグイン

    Redmine プラグイン etc... ex. kaminari, uent-plugin-bigquery, omniauth-*

22. 既存gem 改造系 明確なプラグイン機構のないgem を改造する。 モンキーパッチや内部実装に踏み込んだ改造等もあ る。 activerecord 拡張 rspec 拡張

    capistrano 拡張 ex. rspec-storage, activemodel-associations

23. 業務特化系 仕事で書くコードの共通処理をまとめたり、ある業種 に特化した便利機能等。 クローズドソースなgem も多い。 社内の認証基盤へのアクセス 社内共通のフレームワーク ゲーム系に特化したテストデータ生成 ex. takarabako

24. 便利ツール系 単体で動作する便利ツールとしてのgem 。 多言語メインの環境でも利用される場合がある。 運用自動化 外部サービスの情報を取得して、整形して表示 Lint ツール bot ex.

    capistrano, rubocop, itamae, ruboty, yaml_vault

25. パフォーマンス向上系 高いパフォーマンスが求められるため、既存の処理を 更に高速な実装に置き換えるもの。 C 拡張によって実装されることが多い。 ハッシュ関数の実装 文字列処理の高速化 通信プロトコルの高速化 ex. hiredis,

    fast_blank, curl_escape

26. 私の場合 既存gem の改造や、プラグイン系が多い 作り易いし、ゴールが分かり易い たまにツールや少し大掛かりな仕組みも書く 大体、新しい環境に移った時の環境の不満から 汎用化の限度を決めるのが難しい ( 後述する) 業務に特化したgem

    は余り作らない 特徴のある業界や大きな会社に余り居たことが ない 入口としてはやり易い

27. 色々なgem を参考にネタを探す 公式のAPI クライアントが使い辛い 良く使う処理をまとめて特化すれば簡単になる かも 秘匿情報の管理が面倒臭い 暗号化と複合化をIAM で管理できれば楽かも Rails

    のビューをもう少し早くしたい プロファイラによるとescape が無駄に時間かか ってるから何とかしたい とにかく日々のイライラや不満を言語化し、 色々なgem のパターンと突き合わせる。

28. Gem を作り始める前にやること 困っていることを正確に把握する 何のせいで不便になっているのか 何が得られれば改善できるのか 解決策のコストを評価する

29. gem 開発のコストとは 開発のコストが低い方が良い 実装難易度が低い 書くコードの量が少ない 調査するコードの量が少ない 外部のミドルウェア等に依存しない 依存するgem が少ない 運用のコストが低い方が良い

    状況が多少変わっても弄らなくて済む 別の方法が見つかったらすぐ止められる

30. activerecord-cause の場合 1. 課題の認識 クソクエリがパフォーマンスを圧迫し ていて辛い 2. 改善阻害要因 AR がどこでクエリを発行しているか

    分かり辛いので、場所を特定するのが面倒 3. 解決策の検討 SQL が実際に発行された場所がログに出ればいい 場所とは？ -> スタック上の自分の書いたコード部 分 自動で判別できる？ -> なんか難しそう、ざっくり 指定できればいい

31. 実装前に調査 コールスタックって簡単に取れたっけ？ 例外の時にやってるんだから取れるだろ caller とかで調べたらcaller_locations があった AR のログってどうやって出してんだっけ？ Rails のコードを読んだら、LogSubscriber

    という ものがあった こいつはAR にどうやって差し込まれてるんだ？ AR はイベントを吐き、各Subscriber はイベント 名にアタッチする

32. これはいけそうだ、作ろう

33. Gem を作る時に考えておくこと 目的を少なく保ち、完璧を目指さない 機能は少ない方が良い 最初から他人を意識しない まず自分を便利に 汎用化は無理のない範囲で Rails の複数バージョン対応とか 記録用ストレージを差し替えられるとか

    しかし可能な限り行儀の良いコードを書くこと

34. 行儀の良さとは gem の外の世界を壊さないこと。 外の世界の変化に追従できること。 プライベートなメソッドを呼ばない モンキーパッチを使わない 組み込みのグローバルな動作を弄らない どうしても必要な場合は最小の利用で済むポイン トを探す メタプロは可読性を損うので局所化する

    黒魔法には代償を伴う。

35. rspec-storage の場合 余計なオプションをRSpec に追加したくない 本体のCLI を弄るのは面倒 元々ファイルパスを指定して保存できる 流石にS3 以外にもGCS ぐらいは対応したい

    自分も将来使う可能性が高い ストア方法の実装を選択可能にする必要がある -> Strategy パターンっぽい URI ならストア先の実装とストア先のパス情報を一度 に表現できる。 URI を解釈して出力方法を差し替えられれば。

36. rspec に必要な拡張機構が無い 行儀の悪さを局所化するためのフック箇所を探す どんなルートでも呼ばれるメソッドを探す I/F 設計がちゃんとしていれば、処理フローの 入口と出口がはっきりしていることが多い IO をラップする系ならopen /

    close とか ネットワーク通信ならconnect / disconnect とか rspec ならFormatter とかReporter の基底クラ スが怪しい ファイルパスからデータを書き込むならパスを 元にIO を作ってるはず

37. 以下の二箇所だけ弄れば可能であるこ とが想像できる IO オブジェクト生成している箇所をフックして別 のオブジェクトに差し替える IO オブジェクトを閉じる箇所をフックして任意の ストレージにフラッシュする この様な思考の順番は前後することも多い。

38. 良くない例 activemodel-associations の場合 モンキーパッチで非公開API 弄りまくり module AssociationScopeExtension if ActiveRecord.version >=

    Gem::Version.new("5.0.0.beta") def add_constraints(scope, owner, association_klass, refl, c if refl.options[:active_model] target_ids = refl.options[:target_ids] return scope.where(id: owner[target_ids]) end super end else # for 4.2.x end end

39. 非公開なAPI 使いまくり def belongs_to(name, scope = nil, options = {})

    reflection = ActiveRecord::Associations::Builder::BelongsTo.bu ActiveRecord::Reflection.add_reflection self, name, reflection end AR のバージョンが上がる度にぶっ壊れる -> メンテ辛い……

40. 汎用化の暗部 多機能化や過剰な汎用化はコードベースの強烈な複雑 化を招く。 例えばdevise やrails_admin のコードが簡単に読めま すか？ メンテに苦労するだけじゃなく、利用者の使い勝手が 良くなっているとも限らない。 コードベースが把握し切れないgem

    を利用するとハマ った時に時間を浪費する。 細かいカスタムが難しくなり結果的に取り回しが悪く なることも。 自分が一般ユーザーとしてそのgem を使う時に簡単に コードが読めるのかを常に考える。

41. 作った後のOSS 活動

42. 機能追加要求について 基本的に「Welcome your PR 」で良いと思ってい る。 ナイスだ、それは俺も便利だと思う、って時は作る。 そうでもない時は以下の点を考慮する。 当初の目的・ユースケースから外れていない コードベースを大きく壊さない実装目処がある

    暇がある 後は、気に食わなければfork してくれー！

43. Welcome PR なんだけど…… 機能追加系の対応にはポリシーが必要 世に出てしまった機能を消すのはとても辛い 外部に公開される名前が適切か？ 今後の変更を圧迫しない実装になってるか? ユースケースを必ず把握すること 簡単な代替手段があるかも ある種のユーザーサポート的なことも必要

    uent-plugin-bigquery には消したい設定項目が色々 と…… 。

44. 実装せずに済ます強い心の例 yaml_vault の場合 ディレクトリ内のファイルをまとめて暗号化できると 嬉しい -> シェルスクリプトで良くね？ uent-plugin-bigquery の場合 レコードの値からテーブル名を動的に指定したい

    -> uentd-0.12 で実装するのが辛過ぎるし、0.14 なら 対応できてるからバージョン上げてくれ。

45. そうは言っても ちゃんとユースケースが妥当で 実装の目処が立つなら作る やっぱり色々と意見もらったり 使ってくれるのは嬉しい

46. まとめ

47. gem 開発において大切なこと

48. 日常の怒りや不満を言語化すること 何が辛いのかを説明できて、初めて それを改善することができる 各々の怒りや不満を大事にしよう

49. できそうと思うには引き出しが必要 Ruby のリファレンスマニュアルだけでも定期的に 復習する価値がある 汎用化、抽象化にはやっぱりデザパタの知識は役 に立つ 日頃から色々なgem のコードを読んで実装テクを把 握しておく 頭のインデックスに引っかかれば検索できる。

50. より良い実装のために 容赦なくパクる ( ライセンスは確認しつつ) 世の中にあるgem は実装パターンの宝庫であり参考 書

51. gem 開発は簡単だけど、何かを自分 で考えて作るのは簡単じゃない でもやってみれば仕事も楽になるし レベルも上がる 無理にでも手を出せばいつの間にか 身についていく そしてOSS とRuby エコシステムの

    世界へ！
52. None