「〇〇のプラグインを作る」ことのすゝめ / Let's develop plugins

July Tech Festa 2021で発表した発表内容のPDF版です。
この資料はHTMLプレゼンテーションがベースのため、最新ではない可能性があります。
HTML版はこちら

Transcript

1. 「〇〇のプラグインを作る」ことの すゝめ Date: 2021/7/18 Author: Event: Hashtag: Kazuya Takei July Tech Festa 2021 #JTF2021_a
2. 注意事項 このプレゼンテーションは、Revealj.js によって 作成されており、PDF ファイルはdecktape によっ て出⼒されたものです。 原典はHTML 版となっており、 で公 開されています。 なるべく追従していますが、たまに古い場合があ ります。ご了承ください こちらのURL
3. イントロ 🟦 > 🟦 > 🟦 > 🟦
4. 自己紹介 Kazuya Takei NIJIBOX Co., Ltd サーバーサイドエンジニア アーキテクト @attakei as 雑⾷系エンジニア and more Twitter GitHub
5. NIJIBOX について(AD) 株式会社ニジボックスは、UX デザインに特化した、リクル ートグループのWeb 制作会社です。 新規事業の⽴ち上げ⽀援、UX デザイン、UI デザイン、Web 制作、開発、動画制作、イラスト制作、リリース後のグロ ースハックまで、⼀気通貫でサポートしています。
6. NIJIBOX について(AD) 海外のテクノロジー系記事を⽇本語で読むことができ るエンジニア向けのキュレーションメディア 株式会社ニジボックスが運営を引き継ぎ再始動 POSTD
7. トーク内容 ※提出当時のCfP 多くのソフトウェアがコア+ プラグインという構造を取っています。 こ の「プラグイン」は、「コアを⼟台にすることによる軽量な実装」 「機能x 機能というジャンルによるピンポイントな需要の取りやすさ」 などからOSS 活動の実装系はじめの⼀歩として熟れたものとなってい ます。 普段ちょこちょこプラグイン系ライブラリを書いている際にどんなこ とを考えるかを通じて、OSS 活動の⼩さな⼀歩を踏んでみませんか？
8. トーク内容 ※提出当時のCfP 多くのソフトウェアがコア+ プラグインという構造を取っています。 こ の「プラグイン」は、「コアを⼟台にすることによる軽量な実装」 「機能x 機能というジャンルによるピンポイントな需要の取りやすさ」 などから OSS 活動の実装系はじめの⼀歩として熟れたものとなってい ます。 普段ちょこちょこプラグイン系ライブラリを書いている際にどんなこ とを考えるかを通じて、 OSS 活動の⼩さな⼀歩を踏んでみませんか？
9. 主に話すこと プラグインとは何か プラグイン開発がOSS 活動の⼀歩⽬に向いている理由 プラグイン開発時に⾃分が考えていること‧⾒ている こと
10. 「プラグイン」ってなんだ っけ？ ☑ > 🟦 > 🟦 > 🟦
11. プラグインの一般的な位置づけ ※ より引⽤ プラグインとは、差し込む、差込⼝などの意味を持つ英単語。 IT の分野では、ソフトウェアに機能を追加する⼩さなプログラムのこ とを指す場合が多い。 IT ⽤語辞典
12. プラグインの一般的な位置づけ + αの表現として あるソフトウェア‧アプリケーションが存在していて 上記アプリケーションに対して、何かしらの機能追加 を⽬的として提供する ナニカ よく聞く別名： 拡張 , アドオン
13. 本体から見たプラグインの表現例 Google Chrome (Chromium 系ブラウザ) における... Chrome 拡張 Ansible における... Plugins Modules Role(?) Slack に対する... Slack app Slackbot Outgoing Webhook
14. 本体とプラグインの関係性 本体は、それ⾃体で本来の⽬的機能を⼗分提供可能なもの Google Chrome Slack 関係性: 本体 >>>>> プラグイン
15. 本体とプラグインの関係性 本体は必要最低限に近い機能のみを提供し、プラグインの 受け⼝がわかりやすく指定されているもの Sphinx Fluentd Mackerel 関係性: 本体 >>> プラグイン 本体+ 同梱プラグイン >> プラグイン
16. 本体とプラグインの関係性 本体の実質的な役割が、「プラグインが⾏う処理をハンド リングすること」になっているもの Errbot Hubot 関係性: 本体 <-> プラグイン ( 共依存が強い)
17. 本体とプラグインの関係性 本体の機能が⼗分あるほどユーザー向け？ 本体の機能が薄いほどエンジニア向け？
18. 「プラグイン」がOSS活動 に向いている？ ☑ > ☑ > 🟦 > 🟦 > 🟦
19. プラグインの特徴振り返り アプリケーションに機能を追加するナニカ アプリケーションが存在することが前提 機能⾃体の⼤⼩は問わないが、基本的に⼩さな機能で も良い
20. プラグインの特徴から見た、OSS活動 入門との親和性 コンパクトな実装でOSS として成⽴する ⾃分の『不』を⼿軽に解消するトレーニングになりう る 質のいいコード‧ドキュメントのリーディング機会が 増える
21. コンパクトな実装でOSSとして成立す る よくあるプラグインの「振る舞い」
22. コンパクトな実装でOSSとして成立す る よくあるプラグインの「振る舞い」
23. コンパクトな実装でOSSとして成立す る プラグインが持つ最低限の責務 本体とのI/O ルールに基づいた、処理の定義を⾏う ( いつ呼ばれるべきかを指定する) ⾮常にシンプル ( 実際にはもうちょっとあることが多い)
24. コンパクトな実装でOSSとして成立す る sphinxcontrib-gtagjs Sphinx 本体が「HTML を⽣成するタイミング」で呼び 出されて 「Google のグローバルサイトタグを⽣成して」引き渡 す ソースは45 ⾏（本質的な箇所は⾮常に少ない）
25. コンパクトな実装でOSSとして成立す る ... ちなみに コンパクトな実装のためには、適度な分割をする 分割すると、数をこなせるようになる 数をこなすと、OSS 活動のいいトレーニングになる
26. 質のいいコード・ドキュメントのリー ディング機会が増える プラグインを作るには、本来の処理の情報 + プラグインを 呼ぶ本体の情報 が必要。
27. 質のいいコード・ドキュメントのリー ディング機会が増える プラグインを作るには、本来の処理の情報 + プラグインを 呼ぶ本体の情報 が必要。 本体の情報 = ドキュメント+ ソースコードを読む ドキュメントの充実度合いが⾼い（特にエンジニア向 けプロダクト） こういうプロダクトはソースコードも読みやすい ↑リーディング機会が増加する
28. 質のいいコード・ドキュメントのリー ディング機会が増える
29. 質のいいコード・ドキュメントのリー ディング機会が増える
30. 「プラグイン開発」のアプ ローチ ☑ > ☑ > ☑ > 🟦
31. どこから実装の手をつけるか問題 どっちから⼿を付ける？ I/O のほうが本体連動させやすい メイン処理のほうが独⽴して動作確認しやすい
32. どこから実装の手をつけるか問題 どっちから⼿を付ける？ I/O のほうが本体連動させやすい メイン処理のほうが独⽴して動作確認しやすい ←個⼈ 的にはこっち
33. どこから実装の手をつけるか問題 どこから⼿を付ける？ I/O のほうが本体連動させやすい メイン処理のほうが独⽴して動作確認しやすい ←個⼈ 的にはこっち ※いくつか作ると結果的にI/O が先に出来るようになる
34. 何を参考にするか問題 本体ドキュメント(+ ソース) 本体同梱プラグインのソース 「プラグインを作ってみた」系の記事 サードパーティ製プラグインのソース
35. 本体ドキュメントを参考にする プラグインの重要度が⾼いと、専⽤のセクションもあ る プラグイン開発に関するドキュメントの充実度は、千 差万別 「困った時には原典に当たる」精神を忘れずに
36. 本体同梱プラグインを参考にする 主要になりうる機能プラグインは、同梱物を直接参照 できる場所にある リファレンス実装ではないナニカとなっている 同梱 = 本体開発者のお⼿製という傾向が強く、 本体設計を暗黙知として実装している可能性があるの で要注意
37. 「プラグインを作ってみた」系の記事 を参考にする いわゆる、Zenn ‧Qiita ‧ブログにある記事 本体開発元と関係が深い組織が公開しているケースも あり、良いチュートリアルになる UGC 系は⼀般ユーザー視点で、躓きドコロを紹介して くれたりもする
38. サードパーティ製プラグインを参考に する 未来の⾃分と同じく「困り⼿」によって作られている ドキュメントを元に素直な実装をしていることがしば しば GitHub stars の多いプラグインは、それ⾃体がリファ レンス実装とも⾔える
39. ちょっとした小話 ☑ > ☑ > ☑ > 🟦
40. プラグイン開発にはアンテナが必要
41. プラグイン開発にはアンテナが必要 2 ⽅⾯の状況に気を使う必要がある 本体の更新状況 メイン処理のライブラリの更新状況
42. プラグイン開発にはアンテナが必要 sphinx-revealjs の安定的な更新管理のためには Sphinx の更新への追従 Reaveal.js の定期的な最新版取り込み
43. まとめ ☑ > ☑ > ☑ > ☑
44. トーク振り返り プラグイン開発は、 プラグインを前提にしている場合、プラグイン開発を しやすい環境を提供してくれている コンパクトな処理を提供できるため、考える範囲が少 なくて済む メジャーなプロダクトだと、サードパーティのプラグ インという教材が豊富 = OSS 活動のスタートを切るのにちょうどよい
45. トーク振り返り さらに、公開することで…… ⾃分以外の同じ困りごとがある⼈が⾒つかるかも 同じ困りごとでも違う困りごとが⾒つかるかも より良い解決⽅法を知る⼈が降臨してくれるかも と、⾃分以外のリアクションが可視化されていく = 楽しい
46. トーク振り返り 最近あったリアクション ※登壇準備をしてて放置して いたので、これから読みます Rodolfo Campos @camposer Hey @attakei I was playing around with your implementation of the Errbot Slack Bolt Backend. Thanks for implementing it! Here's a simple test that I put together: github.com/camposer/errbo… Check out the manifest, other scopes were required camposer/errbot-slack-bolt-test Errbot Slack Bolt Test. Contribute to camposer/errbot-slack-bolt-test development by creating an account on GitHub. github.com 午後8:25 · 2021年7⽉14⽇ ツイートへのリンクをコピー
47. このセッションを機会 に、自身の中の小さな需 要をOSS活動の一歩目の 題材にしてみませんか？