はじめに
この記事は M5Stack Advent Calendar 2020 の20日目の記事です。
M5Stackでは製品寄り…そう、市民開発者としてライブラリ開発にかかわることができます。
今回は開発コミュニティへ足を踏み入れ、M5Stackへの関わってきたことと同時に、やらかしたことを総括してみます。
M5Stackの開発に参加する
昔からいろんなOSSの世界にはいろんな活動があることを知っていましたが、昔は、LinuxとかBSDの世界で、知識や技能がふんだんにある限られた人たちが盛り上がっている世界…（まぁ偏見ですが）が多かった気がしています。
でも、ここ最近、ハードウェアもソフトウェアも、オープンソースとして公開されているマイコンがでてきました。GitHubという仕組みもできて、問題提起や修正提案ができるようにもなりました。
ほんとに、様変わりしたなぁ、と感じています。
であれば、その環境に飛び込んでみるしかない！と、飛び込んだ時のことをちょっと書いてみます。
最初の壁はGitHubへのコメント
GitHubで要求を出すには、主に２つの項目があります。
- Issue（問題提起）
- Pull Request (修正提案)
そして、最初は Issue を書く…ことになるわけですが、ここを日本語でやり取りする人って結構少ないのですよね。（OSSプロダクトオーナーが日本人だったとしても。）
でも、いまは、優秀なGoogle翻訳やDeepL翻訳もあるので、それを使って書くことになります。
そして、Issueを書くとして、「それが再現できるように書く」がポイントです。なかなかこれが難しかったりするのですが、環境、バージョン、ライブラリ… まぁ、ここを読んでいる皆さんは既に通過されたところかもしれません。
私も、そのコメントを書いて、改善されていく姿をみながら、「あぁ、何か協力できないかな」と思うようになりました。
プルリクエストは比較的寛容に受け入れてもらえる
M5Stackのリポジトリは、比較的プルリクエストに寛容で、提案したものはある程度受け入れて頂けるような流れです。
このあたりが、「1週間ごとに製品を投入していけるスピード」を発揮できる所以でもあるのでしょうか。そして、ユーザと一緒に製品を育てていける仕組みでもあります。
こういうことから、比較的ライブラリが書き換わっていくペースも速いです。ある程度Issueなどの会話がおちついてくると、ライブラリのバージョンがあがる、といった感じでメンテナンスがされていきます。
ということで、私のゴールデンウイークは、この開発に注力しよう！とスイッチがはいったのでした。
「良い品質のものをUPしておかないと、後々問題になる」
ユーザが多いとは言いつつも、最新のライブラリを確認してIssueを上げてくれる人は、そこまで多いわけじゃないので、機能がうごくかどうか？などは、綿密に確認をしておく必要があります。
さすがにコンパイルが通らない…みたいなものはコードチェックが走っているのでリクエストを出した時点で弾かれますが、細かい機能の実装となると、チェックがもれてそのままリリース…ということもないわけではありません。
Gitでは変更者・提案者のIDは残っていますから、ド派手にやらかすと、すべて記録に残っていきます。
そんな中、着手した電源クラス "M5.Power"
いろいろ触っていく中で、電源ICに着目した会話が広がっていきます。「電源をある程度コントロールで来たらいいけど、分かりづらいなー、ちゃんと機能単位でまとめられないかなー？」というところから、M5.Powerというクラスを作りました。
IP5306という石も、ドキュメントリビジョンも結構種類があって、集まってくる情報次第では、不明なレジスタの中身が分かるようになってたり。
だけど、ここから反省があって、
- 「昨日は自分のワーキングリポジトリでしっかり動かす」
- 製造時期の異なるハード、展開されてる種類を幅広くテストする
- アーキテクチャーは後先を考える
というのがとても大切だという教訓を得ました。
（いや、まぁ、当たり前なんすけどね…）
仕事でPICなどを使っているので、多少の知識はあったにせよ、中国語のマニュアルの解読、ICの動きをちゃんと熟知した「つもり」になっていたので、読み込み用レジスタと書き込み用レジスタを間違えたり、解釈を間違っていたり…
まぁ、これでも「自分のリポジトリで勝手にやっている」分には誰も何も言わない訳です。でも、そのまま勢いをつけてプルリクを出して、取り込まれました。
そして、「うごかねーじゃん」ってIssueがでてきて… というヤラカシにつながります。
（製造時期によってIP5306とI2Cが繋がっていない、なんてこともあってドタバタしました）
それから、Powerクラスは、本来もっと抽象化すべきものでした。というのも、M5シリーズは製品がいっぱいあって、機能とIC依存部分をちゃんと分けていかないと、ソースの互換性が失われてしまいます。現に、別にＩＣは別のクラスがあって、互換が失われてしまいました。
このあたりは、今後ちゃんと作っていく必要があるんだろうと思っています。
ドキュメントの翻訳・加工もオープンソースになっている
プログラムをユーザが作っていけるということは、仕様もちょこちょこ変わるので、マニュアルも書き換えることができます。前までは日本語・中国語・英語のマニュアル構成になっていましたが、最近はどうも中国語・英語の2言語になっています。（整備するにもコストがかかるし。致し方がない）
それはそうと、このあたりも、クラス設計をしたら、しっかりドキュメント化していく必要があります。というのも、作りっぱなしになると制作意図が読めず「似たような関数が乱立する」とか、「使われずに埋もれる関数」になってしまうから。
やっぱり作った以上は整備をしなくちゃ…ということになります。
ここでも、ドキュメントエミュレータを知らなかったので、Markdownを間違えてやたらプルリクしていたり…というようなヤラカシもしています。
これは、「ローカルサーバを立てるといいよ」って教えてもらいました。
npx docsify-cli serve ./docs
start http://localhost:3000
コード規約があるじゃん！それなら…
Arduinoのコード規約をみながら、M5ライブラリにも適用しよう…なんて試みた時もありました。実際の所Arduinoのコード規約ってそんな厳格に決まっているわけでもなく、M5ライブラリのように色んな部品を組み合わせた集合体になっていると、統一感というのもあまりありません。
で、試みたわけです。いわゆる「リファクタリング」ってやつに近い。
でも、これって
- 等価性は担保しないといけない
- コード記法はコード規約に合わせたい
で、触っちゃったわけです。（これは 結構やばかった）。というのも、
- そんなすべての動作の透過性を担保できるハードもってる？
- バージョンアップの時に、そのモジュールどうするのよ？
ってわけです。LCD描画系ライブラリを触った時に一番大変（＆やっぱやめよ？って言われた）のでした。これは経験こそさせていただきましたが、迷惑をかけました…。このあたりも、コミュニティとちゃんと話し合って決めていくべきですね。（Issueで提案してはいましたが、ちゃんと議論はしたほうがいいでしょう）
最終的に
ライブラリのv0.2.7は「全然動かない黒歴史のライブラリ」として葬られました。自由を許してもらっている反面、責任も果たさなければならない…等価交換ですね。
とはいえ、１製品を扱う企業が、これだけの裁量をもってユーザに開発を触らせてくれるってのは、かなり大きい事だと思います。この状況を「うまく活用」して、「双方にメリットがある」ように活動できるか？が大事なのかなとおもいます。
この活動をするにあたっては、かの有名な開発者、らびやん氏に多大なる迷惑と、フォローと、助言をいただきました。あらためてお礼申し上げます。また、M5ライブラリを使っていた皆様、品質不良の際にご迷惑をおかけしました。
今回の教訓
- 企業が自由をあたえてくれるフィールドは大いに活用できれば学びも大きい。
- ただ、迷惑をかける開発手順を踏んではいけない。
- リクエストするまでに、品質はある程度確保しよう。
- 提案するなら、仕組みは後先を考えて。
- 周りに手を差し伸べてくれる開発者がいるなら、謙虚を忘れず前進するべし。
開発コミュニティに参画していくことは、とても意義深いことです。多少ヤラカシても、人生終わるわけじゃありませんので、経験しながらスキルを伸ばして、コミュニティに貢献していきましょう。（でもほんと、人生こそ終わりませんが、他人の時間や仕事を左右するので、そこは丁寧にかかわっていきましょう、自戒を込めて。）
以上、M5Stackを通して得た教訓でした。