いつの間にか２年間継続してコードを書いていたので、その振り返りです。上のインコは日々僕を応援してくれる二羽のインコのうちの一羽です。この後本をボロボロに噛みちぎっていきました。
１年目との違い
去年こんなポストを書きました。
このとき、自分はコードを１年継続して書いたわけですが、その後また１年継続してコードを書いていました。
１年目とは「書きたい」と思うものも変わりました。また、習慣を維持する労力も小さくなり、コードを書くことそのもの以外の、登壇などの時間を取れるようになりました。
この１年で新たにやったこと
ツール作成
- markdownをMediumポストにするCLIツール
- AWS SSMで管理されたパラメーターを環境変数にInjectするツール
- Google Cloud Platform API向けに使える、goonと同様のDatastoreクライアント
基盤作成
AWS上にTerraform+AnsibleによるAPI、動画変換基盤+APIの作成
基盤移行
上記基盤をGCP(GAE)に移行するために全てリプレイス
現在エンコーダーをGKEで作ろうと試行錯誤中
API作成
- 動画配信API
- クローラー
- 認証基盤
- etc…
iOSクライアント作成
- RxSwift MVVM
リファクタ
- Goの理想的なpackage構成の模索
- context.Contextの扱い方を意識したAPIの書き換え
- DDDについて試行錯誤しながら構成を変更
- RxSwiftの理想系を周りに聞いて、それに書き換え
コントリビュート
- golang
- 他ツールにちょくちょくコミット
メインでやってたのはAPIです。数が少ないですが、APIの開発を行うと一個でも深く開発ノウハウが得られます。
また、実はiOSアプリなどの実装もしていたりするのですが、周りに聞きつつRxSwift+MVVMをできるだけ在るべき形で実装するように心がけていました。
また、これらの成果によって行った外部発信（登壇）は以下の通りです。
- 実践!Go/GAE+DDDでのクローラー構築
- Contextアンチパターン
- Advanced API Calling in Go
- Challenge to Advanced API Architecture in Go
- Blockchain on Go
- How Go test tests
- Go and on-demand video streaming / Goとオンデマンド動画配信
- How Go cache tests
めっちゃGoばっかですね…
新たに得られた、続けるためのノウハウ
１年目は続けることが目的だった時期もあって、ちょっとした改修をするだけとか、ツールを作ったとしてもそれほど大きくなかったです。
一方、この１年ちょっとは大きなものを深く作るとか、他の人が読まないであろうコアのコードを読んで発信するとか、コントリビュート経験を積むとか、ちょっと方向性が変わりました。
それのおかげで、得られたノウハウも少し実務に活かせるものになってきました。
大きなものを「速く」作る
大きなものをちゃんとタスク管理して作っていく、ということをやっていたのですが、タスク管理するにしても期限を現場レベルで管理する必要があるな、と感じました。
そう感じたかきっかけですが、自分が無駄にアーキテクチャを複雑に追求してしまったり、リファクタリングに時間をかけていくことで、自己満足な実装時間を取ってしまっていると自責の念を抱くことが多くなった、というのがあります。これは本当に無駄なことです。プライベート開発において、コードを書くモチベーションが削れるのが一番天敵ですが、この自責の念はかなり重くのしかかります。
その自己満足な時間を取らないように、スケジュールを厳格に区切ってみようと思い立ちました。
また、タスクの洗い出し粒度は大体エンドポイント単位にしており、もし複雑な実装ならその子要素として要所要所をタスクとして切っておきます。
タスク管理ツールはAsanaを使っていましたが、もっさりしてて使い心地が微妙だったので、Todoistに変えました。これは我ながら英断だったと思います。他のタスク管理ツールはなかなか続かなかったのですが、Todoistは必要十分です。課金もしてます。
コントリビュート経験を増やす
個人的な開発と同時に、ちゃんとコミュニティに対する価値というのも出していきたいと感じる場面が多くなりました。小さくツールやライブラリを作るだけだと、使われるかどうかかなり不安になることが多く、それも目的意識を減退させることが多かったです。
そんなとき、Goにコミットできたことは大きな自信になりました。他にも、marcari/gaurunなどのリポジトリにちょくちょく足跡を残したりしました。
エンジニアとしてプライベート開発もやっていいんだという安心感を得られるので、ただの小さなツール開発者から一歩前に出て、コントリビュート経験を積むというのは大きな精神的支えになりました。
外部発信できないコーディングをしない
登壇の回数が一昨年と比べてはるかに増えました。特にGo界隈ではしょっちゅう表に出る機会を頂いたと思います。
たまに、「登壇ネタとかってどうやって見つけているんですか？」ということを聞かれるのですが、これは１年前のポストにも書きました。中規模以上のAPIなどを書くことで、現場レベルのノウハウを得ることが大事だなと思っています。
また、そもそも登壇しやすいように、ただのREST APIだけではなく、ジョブキューとか検索、Push、認証などの機構の実装に手を出していくことで、外部発信をでき、かつ他の人があまりオープンにしないネタを、プライベート開発だからこそオープンに晒していく、というテクニックを取っています。企業の中で開発してると、そういうセキュアな分野はあまりオープンにできないので、あえてそこを攻めると発信しやすいです。
現状の課題と対応方針
現状の課題は３つあります。
マイルストーンの可視化
理想的なマイルストーンとそれをどれくらい達成しているか、あまり自身でフィードバックできていません。
ガントチャートなどで管理したいのですが、あんまいいツールが見つからないのもあって、気が乗らずにいます。
一個一個のタスクに期限を設定するのも良いのですが、もっと大局的に見たいので、その解決方法を探しています。
集団での成果物
個人的にまあまあいいノウハウ貯めて綺麗に作っていってると思いますが、一人で書いてるとできることというのは限界があります。
みんなで作ってもっと大きいことをやっていきたいですね。
別で発信しやすいテーマを貯める方法
企業だとオープンにしにくいテーマで深掘りしていくことで、発信しやすいテーマを見つけていますが、それ以外にも、テストや速度改善など、コミュニティに共通しているがベストなノウハウを見つけるための時間をみんなが持ちにくいトピックを深掘りしていくといいのかもしれません。で、現状そこらへんの深掘りが足りてないので頑張ります…
まとめ
経験則ですが、継続してコードを書くことは大事です。ですが、月単位や年単位で見ると、やっていることは少し変わっています。
より大きく、実践的なノウハウを得やすいプライベート開発をするためにいいサイクルを築いていきたいです。
追記
できれば1日の平均プライベートコーディング時間教えてよ。他との両立ができていたのかどうかが鍵でしょ。（はてブコメント欄より）
これいい質問ですよね。家庭をお持ちの方とか、勤務体系がアレな方は難しいですよね。
まず、あくまで平日の平均の時間ですが2~3時間くらいでしょうか。あんまり取れてないかなと思います。休日は5、6時間ですね。
かくいう私も前職は勤務体系がちょっとアレな感じでして、11時くらいに帰ったらその後2~3時くらいまでコード書く、みたいな感じでした。
今は18:40くらいに上がって、19時過ぎに家について、その後ご飯や買い出し、洗濯、食器洗いやジムなど諸々あるので実際に作業を始めるのは21:30くらいです。同棲している身なので、両立できないと怒られます。
そこからだいたい1:00、日によって3:00くらいまで作業して、7:30~8:00に起きるという感じです。（ちゃんと寝てますよ！）
