YAPC::Asia Tokyo 2014 に参加しました & 発表しました #yapcasia

もう1ヶ月前になりますが、YAPC::Asia Tokyo 2014に参加してきました。 YAPCには去年から参加していますが、今年は思い切ってトークの登壇に応募してみたら採択されたので JSON Shema と API テストというテーマで発表もさせていただきました。

トーク発表「JSON Shema と API テスト」

JSON Schema と API テスト YAPC::Asia Tokyo 2014 from Naoki Shimizu

JSON Schema と API テスト YAPC::Asia Tokyo 2014

トーク概要

業務では JSON Schema で仕様が記述された API の結合テストを書くことが多いのですが、その JSON Shema を使ってテストを楽にできないか？ということで

API の結合テストについて
JSON Shema から API のテストデータを生成する取り組み
作成した json-fuzz-generator について
JSON Schema を使ってできるテスト・できないテスト

についてお話しました。

頂いた質問

JSON Shema で仕様を記述すること自体の普及活動も行なっているのか？

私の周りでは API の仕様を JSON Shema で記述し、サーバサイドのバリデータとして活用することが既に普及していたので、その必要はありませんでした。 JSON Schema を使っていない環境で1から導入・普及させることを考えると、JSON Schema は XML Schema 等に比べるとシンプルに記述できますが、はやり書くには一定の慣れ・スキルが必要なのは事実です。

JSON Schema を簡単に・正確に記述するための仕組みを作る
「JSON Schema を書くと嬉しいこと」を増やす

このあたりが達成されるようになると、JSON Schema の普及は更に進むであろうと思います。 JSON Schema を入力とするバリデータの json-schema や、今回作ったテスト入力データの自動生成ツールである json-fuzz-generator は後者のアプローチですね。

json-fuzz-generator は Hyper Schema には対応しているのか？

対応していませんorz

後述の通り今回はかなりカツカツのスケジュールで作ったものなので、その余裕がありませんでした。しかし実用的な JSON Schema は Hyper Schema を駆使することになるので、json-fuzz-generator でも今後対応させようと思っています。

発表してみて

実は今回が社会人になって初の対外プレゼンだったのですが、めちゃくちゃ大変でした。。。

7月にトーク登壇の申し込みをした時点では今回のトーク内容の構想はあったものの、スライドはおろか json-fuzz-generator も全くの未実装の状態でしたので、完全に LT 駆動開発の状態でした。そんな中、何とか業務外の時間を捻出してコードを書いたりスライドの準備をし、何とか発表の形にもっていくことができたのは「脱・職業エンジニア」を目指している自分にとって大きな自信になりました。(発表の構想やプレゼンのレビューにご協力いただいた @ikasam_a さん、@shyouhei さん、@okitan さん、ありがとうございました！m(__)m)

とは言え突貫工事で作ったライブラリは実用レベルには全く到達していませんし、YAPC の他のスピーカーの方々の発表内容やプレゼン・スライドの完成度には圧倒されっぱなしであったので、

普段から自信をもって LT で話せるようなネタ作り(=開発)をやる
- YAPC前1ヶ月間のような生活を普段からできるようになりたい
プレゼンのスキルもちゃんと磨く
- まずはプレゼンテーションZENを読みます (@ryopeko さんリコメンド)
json-fuzz-generator を実用レベルにもっていく
- このままでは出しっぱなしで終わってしまうので、追加で開発を続けます
- 今は人に見せるの恥ずかしいような状態なので…

このあたりをこの先1年間ぐらいの目標にして生きていこうと思います。

YAPC 参加レポート

普段は Perl をメインで使っているわけではないので、言語に依存しないようなテーマのトークを中心に聞いてきました。その中で個人的に印象深かったトークが以下の2つです。

Git を使ったツール開発

Speaker: @motemen さん

Git を便利に使うツールと、そういった Git ツールを作るにあたっての tips のご紹介でした。

Git 便利ツール: git-pr-release

開発ブランチにリリースする機能の Pull Request を merge しておいて、git-pr-release を実行するとリリースする機能のリスト付きリリース Pull Request を自動生成してくれるというもの。リリースブランチを使うような開発・リリース方針をとっている人/チームにとって非常に便利なツールですね。

これを使えばリリースブランチに意図しないブランチが混じっていてリリース後に気付いて…というトラブルは防げそうです。

Git ツールの作り方

motemen さんが作った Git ツールの共通点は

.git/** 以下を直接いじるような操作はしない
libgit2 を使うのではなく、Git のサブコマンドを使う

の2点だそうです。 git help -a を叩くと Git のサブコマンドの一覧を全て見ることができます。手元でも実行してみたところ、160以上のサブコマンドがありました。普段使っているのはその1割程度ので、便利ツール作成以前にこれらのコマンドの働きを把握するだけでも Git ライフが効率化できそうです…！

git --exec-path コマンドで得られる場所にある Git のサブコマンドを見てみると、実行ビットが立っていないものが多々あります。この実行ビットが立っていない Git サブコマンド達は、シェルスクリプトから実行するための、つまり便利ツールに活用するためのコマンドだということを今回初めて知りました。

Git はチームで開発するにあたって他人に迷惑がかからない程度に使い方を知っている、という完全にペーペー状態なので、今回伺ったお話を活用して社内外で便利な Git ツールを作ってみたいと思います。

コマンドラインツールについて語るときに僕の語ること

Speaker: Taichi Nakashima さん

上記と同様 CLI ツール関係のお話ですが、こちらはもう少しジェネラルな、「イケてる CLI ツールの作り方」的なお話でした。

CLI ツールって普段から利用する機会は非常に多いのですが、いざ自分で作るとなるとお作法が全くわからない状態だったので、とても勉強になりました。詳しくはこちらのスライドを見ていただくと良いのですが、中でもしっかり心に留めておきたいトピックについてメモしておます。

"良い" CLI ツールとは？

1つの CLI ツールは、1つのことに集中している
- UNIX のコマンド群と同じ考え方ですね。ついつい欲張っていろんな機能を盛り込んだものを作ってしまいそうになりますが、2つ以上のことをやろうとすると途端に複雑度が増してしまいます。
直感的に使える
- CLI ツールにも UI/UX が存在し、そのパターンにも慣習があるので、それに則って作ることが大切
他のツールと連携できる
- 上記「1つの CLI ツールは、1つのことに集中している」に通じている部分ですね。2つ以上のことをやるために、1つのことを上手くやるツール同士を連携させるのです。
- exit code の出し分けや、output stream の使い分けをサボるとこういう部分で泣くことになりますね。

いかに"良い" CLI ツールを作り始めるか

こちらのトピックで最も印象的だったのが、「README.md から書き始める」ということでした。(README Driven Development と言うらしいです) その理由としては、

何が作りたいのか整理できる
ユーザ視点でデザインできる
1番テンションが高いときにドキュメントが書ける

といったことが挙げられます。これらは CLI ツールに限った話でもないので、私も YAPC の翌日からさっそく意識して README Driven Development を導入しています。

また、 README に記述する内容の例として、「CI バッジをつける」というのも印象的でした。テスト結果をユーザに見せ続けることで、テストを書くモチベーションを保ち続けることができる、という理由です。テストを書くことがメインの業務に携わりながら[自分が公開したライブラリ[(https://rubygems.org/gems/randexp-multibyte)にはテストが入っていなかったり、といった笑えない状態なので、しっかり見習わなくてはなりません。。。

以上、しれっと書いてしまいましたが実は初ポストの deme0607 でした。