近況
5月
- 結婚式を挙げ、新婚旅行にいった。
6月
- 30歳になった。
- 仕事が忙しくなりはじめる。最近はRailsでサーバーサイドを書いている。
- 結婚式の準備などの忙しさから解放されたため、個人開発を少しずつ始める。ElectronでTodoアプリを作り始め、Webpack, React, Redux, TypeScriptなどモダンなWebフロントエンドの技術スタックについて学んだ。
7月
- 仕事の忙しさがピークに至る。
8月
- 仕事がだいたい落ち着く。
- お盆休みは海いったりバーベキューしたり、ここ10年で最も充実した夏だった。
- 個人開発では、RailsでモダンなWebフロントエンド環境を導入するための知見を学んだ。具体的にはwebpackerについて学んだ。http://naoty.hatenablog.com/entry/2017/08/17/201249
- また、GraphQLにも興味をもちRailsで試してみたりした。引き続き学んでいきたい。
- ある日、思い立ってこのブログのスタイルを書いた。なるべく文章が読みやすいデザインを心がけた。 https://github.com/naoty/focus-theme
Homebrew で自分のためのツールを公開するのが楽しい
Homebrew で自分のためだけの細々としたツール類を公開するのが楽しい。naoty/homebrew-misc という tap を作って、そこにツールのための Formula を置いている。brew tap naoty/misc
を実行すると、インストール可能になる。
自分で作ったソフトウェアを日々自分で使っていると、ジワジワと幸福感が広がってくる。rubygems など、特定の言語、特定のバージョン、特定のライブラリに依存したソフトウェアはずっと使っていくことができなくなるかもしれない。使えなくなった頃には、もうそのソフトウェアを書き直す意欲やモチベーションは失われているかもしれない。
できれば、コンパイル済みの実行ファイルのみを配布できるようにしたい。Go を好んで使ってるのはそういう理由だ。Go 以外の言語を使う場合は 2 パターンある。
- その言語でなければ実現できない機能。macOS の機能を使ったソフトウェアは Swift で書くだろう。naoty/flock もこの理由で Swift で書かれている。
- ソフトウェアの利用者が特定の言語の利用者に偏ってる場合、メンテナンスしやすさを考えて利用者の言語でソフトウェアを書くことになりそう。CocoaPods や Fastlane が Ruby で書かれていることは、この理由で個人的に好きではない。
自分のためのツールを Homebrew で配布するのは、仕事用の PC でもプライベート用の PC でも使えるようにしたかったり、PC を新調しても使えるようにしたいからだ。ポータビリティを高めて、ずっと長く使えるようにしたい。自分は iOS アプリのプログラマーなので、Linux に移ることはしばらくないと思う。なので、Homebrew を使ってる。まだ Homebrew に移せていないツールがたくさんあるので、隙を見て移していきたい。
CHANGELOG.mdを書き始めた
チビチビ開発しているライブラリの1.0.0をリリースしたのを機にCHANGELOGというものを書き始めた。その際にCHANGELOGについて調べていた。
そもそもCHANGELOGは何のために必要なのか考えてみた。CHANGELOGは各バージョンの変更点をざっくり把握するためにあると思う。例えば、Railsの変更点を見たいと思ったとき、まず最初にCHANGELOGを見ると思う。いきなりPull requestやコミットログは見ないだろう。それらは各変更の実装や議論といった詳細を見るのに使われると思う。CHANGELOGは変更の詳細ではなく大まかな変更点の一覧を把握するために使われるんじゃないだろうか。
CHANGELOGを構成する要素はなんだろうか。まず、バージョンとそこに含まれる変更点が挙げられる。そして、変更点の詳細が載ったページへのリンクがあると便利だと思う。変更の種類によってグルーピングするとより見やすくなると思う。よく見かけるのはAdded
, Changed
, Fixed
, Removed
, Deprecated
などといったラベルで変更点をわけている。リリース前の変更点についても書いておくと、今後の変更予定が分かって便利だと思う。
書き方としては、変更点を上から追記していくスタイルと、バージョンごとに書き換えるスタイルがあると思う。歴史の長いソフトウェアの場合、ひとつのファイルにそれらをすべて載せるのは見にくいので、後者のやり方が合うんじゃないかと思う。Railsなんかはこのスタイルだったと思う。
以上のようなことを踏まえて、このようなフォーマットに至った。
# Change Log ## Unreleased ### Added * `changed(year:month:day:hour:minute:second:nanosecond:)`, which creates a `Date` instance by changing receiver's date components. [#77](https://github.com/naoty/Timepiece/pull/77) * `changed(weekday:)`, which creates a `Date` instance by changing receiver's weekday. [#77](https://github.com/naoty/Timepiece/pull/77) ## 1.0.2 Released on 2016-12-20. ### Fixed * Fix testDateInISO8601Format() availability. [#74](https://github.com/naoty/Timepiece/pull/74). * Specify Swift version for the compilation of watchOS target. [#79](https://github.com/naoty/Timepiece/pull/79).
iOSアプリの開発でもCHANGELOGを書くようになった。CHANGELOGの読者としては、開発者自身もそうなんだけど、ベータ版を配信するテスターを主に想定している。ベータ版配信では、fastlaneからFabricを使って配信しているんだけど、その際にCHANGELOG.mdをパースしてリリースノートを自動生成するようにしている。このパーサーはrubygemとして公開している。
エンジニア立ち居振る舞い:生産性を計測する
僕は開発以外の立ち居振る舞いとして、いくつかのツールと習慣によって開発の生産性を計測している。
自分のチームではスクラムを採用していて、各タスクにはストーリーポイントが割り振られている。相対的な作業量のようなものだ。また、個人的にポモドーロテクニックを採用している。25分開発したら5分休憩する周期を1ポモドーロと呼んで、そのリズムを繰り返すヤツです。
毎日、完了したタスクのストーリーポイントと開発に費やしたポモドーロを計測している。Google Spreadsheetに書いている。やっていることはそれだけ。
そうすることで見えてくることがいくつかある。まずは、曜日ごとの開発できる時間だ。会議が多い曜日はせいぜい4ポモドーロだなーとか、リモートワークできる曜日はこれくらいだなーとか。曜日ごとのポモドーロの平均をSpreadsheetで計算して見ている。そして、これは見積もりのときに利用できる。来スプリントに開発できるポモドーロを平均値から見積もれる。
あとは、完了したタスクのストーリーポイントとポモドーロから、1ポモドーロあたりのストーリーポイントが分かる。自分のなかでは、この値を生産性の指標として考えてる。なんとなくグラフにしたりして、生産性を上げるモチベーションにしている。
一番良いことは、上で話した「来スプリントのポモドーロの見積もり」と「1ポモドーロあたりのストーリーポイント」から「来スプリントで完了できるストーリーポイントの見積もり」が計算できることだ。この計算に基づいて、来スプリントでこなすタスク量を決めている。
実績に基づいた見積もりができるようになったおかげで、マネージャー側からは安定したスケジュールが組めるようになるし、開発側からは無理のない仕事ができるようになる。さらに、無理のない仕事ができるようになると、無理のない生活ができるようになる。このことは最近結婚した僕にとって一番重要なことなのだ。
try! Swiftに参加してきた
3/2~3/4の三日間、try! Swiftというカンファレンスに参加してきた。
33セッション * 30分という超濃密な構成で過去参加したカンファレンスの中でも最も充実した内容だった。特に、下のようなトピックが多かったような印象がある。
- Protocol extensionなどのSwiftのパワーを使った、より洗練された実装方法の話
- Swiftを使った関数型プログラミングの話
- デザインやアニメーションなどUIにまつわる話
ちょうどいま直面していた課題に関わるようなトピックもあり、セッション後のQ&Aコーナーでスピーカーに話しかけて、ペアプロまでしてもらった。おかげでその課題はすっきり解決できた。
今回のtry! Swiftで最大の収穫は、英語を本格的に学ぼうと思うきっかけがあったことだった。それは、try! Swift公式アプリで自分のライブラリが使われていたことだった。
公式アプリの開発者の方と直接お話しする機会があった。本当はもっと伝えたいことがあったのだけど、あまりに英語ができなくて、ほとんど伝えられなかった。このライブラリのように海外の開発者に伝えられるコンテンツをもてるようになったものの、肝心の英語ができないばかりに非常にもったいないなーと強く感じた。それがきっかけで先月から英語を勉強しはじめている。