主にOSS活動を中心として、自分の今年の活動を簡単に振り返ってみる。
(書き方はバラバラだが)
コミットの継続
良かったこと
毎日コードを書くことと、それにまつわることで書いた活動は、無事に続けられた。
これに関して良かったことは上記エントリの通り。
リポジトリが増えていくと、エンハンス/メンテナンスすべきことも増えていくので、あまりネタに困ることはなくなってきた印象がある。
改善したいこと
継続していることは良いが、内容が単調になっている気がしている。
一因には、作っているものが似ている、という点もあるかもしれない。
特に今年はGradleのプラグインをたくさん作っていたが、どれもほぼ似たような設計になっており、最終的にはGradleプラグインのテンプレートも作ったほど。
なんというか、当然実用性のあるものを作ってはいるつもりだし、テクニカルな点での気づきなどもあったりするのだけれど、ちょっと手応えが足りない。
来年に向けて
来年からはプライベートの時間が限られてくるので、継続するのはちょっと難しいかな・・・
でも何とかやり方を変えて、継続したい。
GitHubリポジトリの成長
良かったこと
Android-ObservableScrollViewは4800スター以上にまで伸びた。
もう少しでClojureにも追いつく！
まあこれは自分の努力の結果、ではないかもしれないけど。
WhatsApp Messengerに採用され、フリルにも採用されたことは個人的に感慨深い。
また、このリポジトリにつられてなのか、他のリポジトリもスターが増えた感じがする。GitHubでフォローしてくれる人が増えたということもあるだろうけど。
やはり、いいものを作ったと思っても、作るだけでなく認知されるようにしないといけないなと思う。
改善したいこと
人に見せた方がいい、知らせた方がいい、というのはわかってはいるのだけれど、今年は「作ったよ」というアピールをどこにもしなかった。
Gradleプラグイン中心で、作っている内容が地味だったのもあるかもしれないが、どこに言えばいいかよくわからなかったというのもある。
来年に向けて
作ったものをグローバルに宣伝できるようなコミュニティやチャネルを探したい。Androidは活発にシェアしているコミュニティがあるけど、他は正直よくわかっていない。
仕事とOSS
もちろん中身について具体的に触れることはできないが・・主に使ってきた技術やOSSに関して簡単に。
良かったこと
昨年はAndroid-ObservableScrollViewを作ったにもかかわらず、
今年は仕事ではスマホアプリ開発と離れてきてしまっていたのが残念だった。
そのせいか、GitHubのスマホライブラリ系のリポジトリも、
メンテナンス中心の控えめな感じになっていたのは否めない。
とはいえ、幸い自分でいろいろ選んだりコントロールする立場にあったことは良かった。Spring Boot を使ったWebアプリ開発をしてきたが、これまでアプリ開発で使っていた Vagrant や Docker も活用し、Android で使ってきた Gradle もかなり理解を深めフル活用してきた。また npm などこれまでやや遠かった分野もわりと多く触れることもできた。
特に Gradle に関しては、いろいろ自動化するためにプラグインを作ってきており、職人的な作業はほぼ無しの状態で開発を運用できているのではないかなと思う。
GitHub での活動に抵抗がなくなったこともあり、Gradle Cobertura Plugin や MariaDB Connector/J に Issue を上げたり Pull Request を送ったりもした。
以前だったら、バグや問題があるとわかっていてもひたすら直るのを待つor使うのをやめる、という消極的な反応しかしなかったと思うので、これは個人的には大きい進歩。
改善したいこと
最近は本当に便利なクラウドサービスが沢山あるが、そういうのを社内的な問題で存分に使えないこともあり、まだ不便なところがいろいろがある(もやっとしか書けないが)。
今後はこれもOSSを活用して何とかしたい。
リリースした作品
毎日コードを書くこと、で書いたようにリリースまでこぎつけることが
必要だと思っているが、そこに到達させることのできた作品を振り返ってみる。
2015年に作り始めたもので、かつ xxx-practice とか練習用のリポジトリではなく作品として成り立っているもの。
ksoichiro/gradle-replacer
初回コミット 2015/1/16。
任意の静的ファイルに変数を埋め込んでテンプレートとして扱い、複数の環境向けに用意したプロパティファイルの値を埋め込んで各環境用のファイルを生成するGradleプラグイン。大部分は同じ形式だが、一部の設定値がリリース先の環境ごとに違っている、といったものを管理しやすくする。
Gradleでわざわざやらなくても・・という気もするだろうが、大半のプロジェクトリソースを扱っていて、その他の少数リソースも同じように扱いたい、とか、メンバーが覚える要素技術を少なくしたい、という場合に有用かも。
ksoichiro/gradle-eclipse-aar-plugin
初回コミット 2015/2/8。
Gradleで扱えるAndroidライブラリの形式(AAR)をEclipseが読める形に変換するGradleプラグイン。
Android Studioの普及を妨げるプラグインでもあるのだが、Eclipseで開発を続けたい人は少なからずいるようで、現時点で70スターくらい付いている。
もともとはAndroid-ObservableScrollViewでEclipseでどう使うの？とうIssueやメールを何度も受け取っていたことがきっかけ。
ksoichiro/ability
初回コミット 2015/5/10。
柔軟なアクセス権制御をするための小さなライブラリ。
Spring Bootで本当のRBAC(?)を実装したかったのだが上手い方法が見つからずに悩んでいたところ、GitLabで使われているSixが良さそうだったので、このAPIを参考にJava用のものを作ってみた。
ksoichiro/ksoichiro/gradle-web-resource-plugin
初回コミット 2015/6/27。
GradleからCoffeeScript、LESS、Bowerライブラリを使えるようにするGradleプラグイン。npmなどを手動でセットアップしておく必要はなく、すべて勝手にやってくれる。
詳細はこちらのエントリにも書いた。
最初はnode/npmを使っていたものを、RhinoとTriremeを使ってJVMで完結するようにした。また最初はGulpでCoffeeScript、LESS、Bowerを扱っていたが上記変更に伴ってGroovyのGParsで並列化して処理するように変更。
処理速度やサイズなどまだ改善の余地はあるのだが、node関連の理解も少し深まり、個人的にはその課題解決の過程もなかなか面白かったプロジェクト。
ksoichiro/gradle-spelling-plugin
初回コミット 2015/11/12。
一覧にNGワードと推奨されるワードを定義しておき、それに違反していないかをチェックするプラグイン。いわゆる表記ゆれを防ぐもの。
業務ではこの手のものを人力のコードレビューで拾っていたが、すべてのチェックは自動化されるべきという考えでプラグイン化。
ksoichiro/gradle-build-info-plugin
初回コミット2015/12/13。
JARファイルに、Gitの情報を含めておくもの。Mavenには既にこういうプラグインはあり、Gradleでもすぐに自作もできそうではあるが、毎回作るのも・・ということでプラグイン化。
プラグインを適用すると、META-INF/Manifest.MFにGitのコミットハッシュ値、コミット日時、ビルド日時などを含めることができる。
また、Spring Boot Actuatorが依存関係に含まれている場合は、自動的にgit.propertiesファイルを出力する。すると、localhost:8080/infoなどでinfoエンドポイントを表示することでこの情報を確認することができる。
ksoichiro/awesome-gradle
初回コミット 2015/12/21。
「これはいい」と思えるGradleプラグインを集めたもの。
今年は本当にGradleを使い込んだ一年で、これないのかなぁといろいろ調べたりする中で知ったプラグインなどを整理しておきたかったのでawesomeとして作った。もう少し育ったらawesomeに入れてもらおうかと思う。
ksoichiro/gradle-commit-checker-plugin
初回コミット 2015/12/23。
すべてのチェックを自動化したい考えから作ったもの。
ブランチを作って開発し、Pull Requestを送る - というフローで開発する場合に、とてつもなく大きいリクエストが送られてくると困ってしまう。
もう少し小さくしてくださいとか言ってもいいのだが、これもよく考えたら自動化できる。
このプラグインを使うと、masterブランチ(設定で別ブランチに変更可能)と現在のブランチを比較して、含まれている差分が大きすぎる場合にビルドを失敗させることができる。
ksoichiro/gradle-plugin-template
初回コミット 2015/12/26。
いろいろGradleプラグインを作っていて、パターン化できる部分が結構あるというのがわかってきたのと、一から作れなくはないが面倒くさい、という点から作ってみた。今後もGradleの発展に合わせてメンテナンスしていくつもり。
なおこのテンプレートは、次のgradle-console-reporterを作るときに使っている。
ksoichiro/gradle-console-reporter
初回コミット 2015/12/27。
Travis CIでビルドした時、なぜかテストが失敗してしまう。
でもJUnitのテストレポートは開けない・・・
そんなとき、コンソール出力にレポートが含まれていれば見られるのに、ということでそれを実現したプラグイン。
クラウドCIではなく社内でJenkinsを運用してる、といったときも役立つ。
あるジョブで次々とPull Requestをビルドしてるが、ワークスペースは保存してないのでテスト結果がなくなってしまう、といったときにコンソール出力に必要な情報を含めておける。
現時点ではテスト失敗時にJUnitのメッセージ、スタックトレース、標準出力、標準エラー出力を出力する機能のみ。
もともとは、gradle-commit-checker-pluginを実装しているときに思いついたもの。ネイティブのGitコマンドに依存しているプラグインのため、ローカルでは成功するんだけど・・・という状態だった。ビルドのアーティファクトを保存したりしても良かったのだけど、一時的なものだし面倒だし、本来のアーティファクトではない。ということでその時はデバッグログを埋めまくってデバッグしていたのだが、まぁ今後も必要になるだろう、ということで作ってみた。
その他気づきなど
作れるものは意外にある
業務で使えるもの、と考えるとお堅い企業では難しいこともあろうが、プロダクション環境で動作するライブラリではなく、「開発用ツール」に限定すれば結構やれることはあると思う。Gradleプラグインはいい例。手軽に作ってリリースできるし、規模も大抵は大きくないからいざとなれば自分でデバッグも十分できる。よりプロダクト本体の開発に集中できるよう、来年もさらに自動化を進めていきたい。
働きすぎは良くない
後半にたくさんプラグインを作れたのは、余裕の時間があったから。
7月から11月までは本当に忙しく、ゆっくり考える暇もなかった。
11月12月はその証拠にたくさん作れているし、それを取り込むことでおそらく業務も改善している。
来年は残業をなるべく抑えつつ、その分の時間でプロダクティビティを上げていきたい。
大事なのは課題を見つけ出せるか
自分の場合、OSSを作るときのネタは、普段の何気ない不満などから生まれていることが多い。OSSとして作るかどうか、公開するかどうか以前に、それを解決可能な課題として考えられるかどうか、が重要と感じる。
課題感がなければ作って解決する発想も当然出ない。
そう考えつつ、自分も視野がまだ狭く、手っ取り早く解決できるものに手をつけているだけなのだろうと思う。来年はもう少し規模が大きくて解決しにくい問題に手をつけていきたい。
まとまらない感じになってしまったが、以上。
来年も頑張ります。
0 件のコメント:
コメントを投稿