今年に入ってOSSコントリビュートを再開している。
「再開している」と書くと以前からバリバリやっていたように聞こえるが、ほどほどだ。以前はLaravelのキャッチアップとEC自体の機能を実装してみたいと思い、Laracomばかり見て(機能を追加して)いた。
その過程でLaravel本体やLaravel Breezeなどの実装がどうなってるかが気になり始め、ソースを読んだりissueやテストコードの追加をしたり、バグを修正したりというのが初めてのOSS活動*1だった。あとは自分で作ったツールなどを公開したりしていた。
その後結婚したり、副業を始めたり、カンファレンス・勉強会登壇に時間を割いたこともあってしばらくOSS活動はお休みしていた。
が、今年に入ってから新生活にも慣れ、何よりコードを書くことに時間を費やすためカンファレンス・勉強会登壇を縮小したことで再びOSSコントリビュートに時間を割けるようになった。
そして久しぶりにコントリビュート活動取り組むにあたっていろいろとissueやソースを見ていて気づいたことがある。
それは、普段業務でコードを書くときとOSSコントリビュートで求められる知識や技術が違うということだ。
ここ1年はいろんなことを経験できたり、知識が深まったりしたおかげで、以前とはOSSの見え方が変わったように思う。例えば普段のコードは業務や運用のことを理解していれば最適なコードや設計をイメージすることができる。どちらかというと、現実の運用なんかをいかに適切にコードに落とし込めるか？ということが求められる場面が多い。
だが、フレームワークやライブラリにコントリビュートしようとする場合はプロトコルや低レイヤーレベルの最適化やDBなどミドルウェア、あるいはブラウザなどとどう連携するか？いかにうまく使うか？に関する知識が求められることが多い。実際issueを見ているとHTTPなどのプロトコルそのものの扱いであったり、ミドルウェアとの連携や、処理の効率化(アルゴリズム)に関するものが多い。
つまり、そこへコントリビュートするには例えばKotlinやTypeScriptなど言語や、KtorやHonoなどフレームワークそのものの知識は前提であって、それ以上のコミットをするにはそこ以外の知識が必要になるという当たり前のことに今更気づいたのである。
そんなわけで、いざコントリビュートを再開してできたことはバグ修正にとどまっている。これは問題箇所のソースが読めれば修正できる場合が多いからだ。逆にそれ以上のことができないのは、先に言った箇所の知識の解像度が低いからだと考えている。
この辺りの知識は新卒の頃に基礎として応用情報やOracle Master Silver、LPIC Lv.2、Google Cloud Proffessional Cloud Developerくらいまでで一通り見てきた。おかげで最低限の知識としてはついてるけど、応用させていくにはもうすこし解像度を上げないとダメだなと思う。し、これはサービスを作ったり、チューニングするなかで選択肢や選択の根拠をより適切に考えるうえでも重要だと思う。
なので年始のタイミングでは技術領域を絞っていくとか言っていた*2が、それ以前(以上)にインフラと数学の方を中心にやっていく必要があると考えている。
HTTPをはじめプロトコルそのものや、TCP/IP、DB、暗号技術や数学といった部分の方を重点的に勉強していくつもり。インプット中心になっていく予定。よって、テクブのアウトプットも減りそう*3。ただこれも良い機会だと思っている。テクブを出してバズらせることが目的になってしまいつつあったからだ*4。
勉強をする傍らでやりたいこともある。これは 
id:sfujiwara さんが最近公開されていたスライドに影響を受けている。
これまで通り他のOSSにコントリビュートしていくこともそうだが、まさに"隙間家具"的なOSSを作りたいと思っている。KtorやExposedを使っていて「こういうのがあればいいのにな〜」と思っていたものを自分で作ればよいのだと気付かされた。今から「JotaiやHonoを作れ」と言われても良いものが作れるイメージが全然湧かない。けど、"隙間家具"は現在進行形で自分が困っているので解像度高く解決できそうだ。
そんなわけでしばらくはSNSやブログ、カンファレンスや勉強会から離れて武者修行の旅に出ます。探さないでください。
