Swiftのオブジェクトグラフを生成する flock を作った

Objective-C/Swift/iOS

Swift で定義されたオブジェクト間の依存関係を可視化する flock というツールを作った。これによって、 Swift で書かれたコードベース全体を把握しやすくなったり、リファクタリング時に影響範囲を把握しやすくなる。

Usage

Homebrew からインストールできる。

$ brew tap naoty/misc
$ brew install flock

flock は指定したディレクトリ（何も指定しなければカレントディレクトリ）以下の Swift のソースコードを解析して dot 形式のソースコードを出力する。これを Graphviz 等を用いて画像に出力して使う。

$ flock <directory>

試しに Alamofire で flock を試してみた。

f:id:naoty_k:20170313230437p:plain

横長になってしまうので、一部を切り取った。

f:id:naoty_k:20170313231019p:plain

コードの依存関係がハッキリと把握できるようになった。

How it works

Objective-C では nst/objc_dep というツールがあった。これはシンプルな Python によるスクリプトでありながら、コードベースを把握する上で強力なツールだった。しかし、 Swift は Objective-C よりも文法がはるかに複雑なため、正規表現で依存関係を抽出するのは困難だ。

幸いにも、 Apple は SourceKit という IDE のためのフレームワークを OSS として公開している。これを使うことで、正規表現によるパースなしに Swift のソースコードの AST を抽出することができる。 SourceKit を使った有名なツールに realm/SwiftLint がある。

flock では、間接的に SourceKit を使っている。間接的に、というのは SourceKit を Swift から扱いやすくする jpsim/SourceKitten を使っているからだ。 flock は SourceKitten が提供する情報をもとに dot ファイルのソースコードを生成している。

課題

現状では、 [String], String?, Set<String> といった Compound Type を扱えていないため、依存関係の一部分しかグラフにできていない。 SourceKitten がこうした型を扱えていないため、 SourceKit を直接扱うか、こちら側でなんとかパースするかすることになりそう。

Homebrew にコントリビュートした

Homebrew Ruby/Rails

あらすじ

前回、 naoty/todo というツールを Homebrew で配布しようとしたときにとある問題にハマった。 todo という名前を持つファイルが README.md や LICENSE のようなメタファイルとして判断されエラーが起きてしまうという問題だった。

Homebrew に Pull request を送った

前回は、メタファイルではない適当な名前の空ファイルを置いてこの問題を回避していたが、なんというか負けな気がしてきたので、 Homebrew に Pull request を送った。前回、コードを読んで何が原因なのかは把握していたので、修正すべきポイントもおおよそ見当がついていた。

当初は実行ファイルであればメタファイルではないという方針で Pull request を送ってみたが、パーミッションが正しく付与されていないものも稀にあるらしかった。そこで、コミッターのアドバイスを基にメタファイルは keg のルートディレクトリにしか存在しないだろうという前提で修正し、無事に merge された。

この修正によって、 todo, changelog, license といったメタファイルっぽい実行ファイルを配布したいときに Empty installation エラーによって失敗することはなくなった。また一つ、世界が便利になった。

Homebrewで自作Formulaを作るときの落とし穴

Homebrew Ruby/Rails

naoty/todo という CLI ツールを Homebrew で配布しようとしたときにハマったことを書く。

naoty/todo は Go で書かれており、コンパイル済みのバイナリを GitHub Releases にアップロードしてそこから配信したいと思っていた。ドキュメント等を調べると以下のように formula を書くことでインストールが完了するものと思っていた。

class Todo < Formula
  desc "A todo management tool just for myself"
  homepage "https://github.com/naoty/todo"
  url "https://github.com/naoty/todo/releases/download/0.2.0/todo.tar.gz"
  sha256 "be20e4069c0ae49998dfc00a010ca8f5d49d26193bd0c3e8611a4bf53cac469d"

  def install
    bin.install "todo"
  end
end

しかし、実際には Empty installation というエラーが発生してインストールができない現象に遭遇した。ドキュメントを調べてみるも、なぜこれが失敗するのか突き止めることはできなかった。そこで、エラーメッセージを頼りに Homebrew のソースコードを読むことにした。

まず、 Homebrew のソースコードは /usr/local/Homebrew/Library/Homebrew にある。そこで ag で Empty installation というエラーメッセージを検索してみると、以下のようなコードを見つけることができた。

if !formula.prefix.directory? || Keg.new(formula.prefix).empty_installation?
  raise "Empty installation"
end

ここからは pry を使ってブレークポイントを貼りながら進めようと思った。 Homebrew はシステムの Ruby を使っているようなので、 システムの rubygems で pry をインストールし調査を続けた。

binding.pry で調べたところ、 empty_installation? が true を返しているようだった。このメソッドの中身は以下のようになっていた。

def empty_installation?
  Pathname.glob("#{path}/**/*") do |file|
    next if file.directory?
    basename = file.basename.to_s
    next if Metafiles.copy?(basename)
    next if %w[.DS_Store INSTALL_RECEIPT.json].include?(basename)
    return false
  end

  true
end

さらにここでイテレーションされている file を調べると formula でインストールした todo と README 等のファイルが含まれていた。ここで何が原因か調べてみると、どうやら以下のように todo が README や LICENSE といったメタファイルのひとつとして扱われていて、ここで true が返っているようだった。

BASENAMES = Set.new %w[
  about authors changelog changes copying copyright history license licence
  news notes notice readme todo
].freeze

ということは、メタファイルではないものがひとつでも存在すれば true が返るということなので、以下のような formula を定義して適当なファイルを置くことで、この問題を回避することができた。

def install
  bin.install "todo"

  # Avoid "Empty installation" error which will be caused when the only
  # "todo" file is installed.
  bin.install "empty"
end

この問題は license や changelog といった名前のパッケージを配布する場合でも起こる。ソースコードを読まないと原因が分からないので、同じ問題に直面した人は不運という感じがする。

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として公開している。

2016年振り返り

今年書いたコード

  • 仕事のiOSアプリを0からSwiftで書いた。
  • Timepiece: Swift 3に対応し、1.0.0をリリースした。
  • cocoapodsにcontributeした。
  • AnyQuery: Swiftでのリポジトリパターンを設計していた。
  • clr: Swiftのアプリ開発以外のユースケースを見つけた。
  • ABKit: なんとなくA/Bテストツールを作ってみた。

感想

今年はiOSの一年だった。新卒以来、久々に仕事でiOSアプリをフルスクラッチで書いてリリースした。SwiftとiOSを勉強し、コードをたくさん書いた。

プライベートでは、ずっと続いてるTimepieceをメンテナンスしていた。try! SwiftでTimepieceを使ってくれている海外の開発者と会い、自信がついた。

来年は、Timepieceのメンテナンスを粛々と続けつつ、仕事で関わっているプロジェクトの成功を第一に考えていきたい。

コード署名・証明書

Objective-C/Swift/iOS

iOS開発で頭を悩ます問題のひとつに、コード署名や証明書の問題がある。Code Signing Errorなどのような単語で検索すると、どのように問題を解決するのか、どのような手順で証明書を発行しXcodeに設定するのか、といった情報がたくさん返ってくる。しかし、コード署名とは何か、証明書とは何か、といった根本的な疑問に答えているサイトは少ないように思える。コード署名や証明書はチーム開発において致命的な問題につながることもあり、十分な理解の上で慎重に運用すべきものであると思う。

そこで、僕はこちらの本を読み、署名や証明書といったものを理解した。

暗号技術入門 第3版 秘密の国のアリス

暗号技術入門 第3版 秘密の国のアリス

本書ではiOS開発における署名や証明書についての記述はないが、自分の中でiOS開発におきかえて読んでいた。そこで得られた理解をここに書いておこうと思う。

まずコード署名とは、証明書を使ってアプリケーションにデジタル署名を施すことを指している。デジタル署名とは秘密鍵を使ってメッセージに施された署名のことで、署名は秘密鍵の対となる公開鍵を使って検証することができる。デジタル署名によって、メッセージが署名を施した人物のものであること、またメッセージが改ざんされていないことを保証することができる。

iOSアプリケーション開発の文脈では、開発したアプリケーションがAppleによって認証された開発者によるものであること、そして開発したアプリケーションが改ざんされていないことをコード署名によって保証していることになる。

一方、証明書とは認証局によってデジタル署名が施された公開鍵のことである。証明書を使わずに公開鍵の受け渡しを行う場合、man-in-the-middle攻撃という手法でなりすましされる危険性がある。攻撃者が公開鍵の受け渡しの間に入り、攻撃者の公開鍵を代わりに受け渡すという手口だ。こうした危険性を排除するため、公開鍵自体に認証情報が必要となる。そこで、認証局が電話番号などさまざまな情報を使って公開鍵を発行した主体を認証し、証明書を発行する。

iOSアプリケーション開発の文脈では、キーチェーンアクセス.appでCSRファイルというものを作成している。このファイルはコード署名の検証に利用する公開鍵と公開鍵を発行する主体の認証情報を含んでいる。このファイルをMember CenterにアップロードすることでAppleから証明書をダウンロードすることができる。

アプリケーションをApp Storeにアップロードする際、開発者は自身の秘密鍵を使ってコード署名を行い、Appleはアップロードされたアプリケーションを証明書に含まれる公開鍵で検証する。

エンジニア立ち居振る舞い：生産性を計測する

雑記

お題「エンジニア立ち居振舞い」

僕は開発以外の立ち居振る舞いとして、いくつかのツールと習慣によって開発の生産性を計測している。

自分のチームではスクラムを採用していて、各タスクにはストーリーポイントが割り振られている。相対的な作業量のようなものだ。また、個人的にポモドーロテクニックを採用している。25分開発したら5分休憩する周期を1ポモドーロと呼んで、そのリズムを繰り返すヤツです。

毎日、完了したタスクのストーリーポイントと開発に費やしたポモドーロを計測している。Google Spreadsheetに書いている。やっていることはそれだけ。

そうすることで見えてくることがいくつかある。まずは、曜日ごとの開発できる時間だ。会議が多い曜日はせいぜい4ポモドーロだなーとか、リモートワークできる曜日はこれくらいだなーとか。曜日ごとのポモドーロの平均をSpreadsheetで計算して見ている。そして、これは見積もりのときに利用できる。来スプリントに開発できるポモドーロを平均値から見積もれる。

あとは、完了したタスクのストーリーポイントとポモドーロから、1ポモドーロあたりのストーリーポイントが分かる。自分のなかでは、この値を生産性の指標として考えてる。なんとなくグラフにしたりして、生産性を上げるモチベーションにしている。

一番良いことは、上で話した「来スプリントのポモドーロの見積もり」と「1ポモドーロあたりのストーリーポイント」から「来スプリントで完了できるストーリーポイントの見積もり」が計算できることだ。この計算に基づいて、来スプリントでこなすタスク量を決めている。

実績に基づいた見積もりができるようになったおかげで、マネージャー側からは安定したスケジュールが組めるようになるし、開発側からは無理のない仕事ができるようになる。さらに、無理のない仕事ができるようになると、無理のない生活ができるようになる。このことは最近結婚した僕にとって一番重要なことなのだ。