うちの職場では3か月に一度程度の頻度で1営業日(7.5h)使ってハッカソンを開催しています。
ハッカソンでは各自で作りたいものを考え、一人あるいはチームを組んで1日かけて物を作ります。
1日の最後には各制作物についての発表をし、投票を行って得票数の多かったチームには後日表彰・賞品の贈呈を行います。

今回自分は2人チームでハッカソンに取り組みました。
その成果物についての紹介と当日の振り返りをしたいと思います。

やったこと

カバレッジ率の情報を持ったjsonをAWS lambdaに投げつけたらShields.IOからバッヂのsvgファイルをもってきてS3に配置するサービスを作りました

モチベーション

背景として、社内のリポジトリでサーバサイドとフロントエンドが同居するときにカバレッジの計測・保持・バッヂの出し方をどうしようという話が上がっていました
うちの職場ではcoverallsというサービスにてカバレッジ結果を集計しているのですが、これが1リポジトリに対して1つしか計測結果を保存してくれない。（2つ以上保存する方法あったら教えてほしいです＞＜）
そのため、最近計測できるようになったフロントのカバレッジをどうやって可視化しようかという議題が出ていたわけです。

そんなタイミングでハッカソンが近づいていたので、バッヂ出すだけなら1日あればいけんじゃね？と思ってやってみました

成果物

リポジトリ

opt-tech/zoi

（名前は完全にzoiって言いたかっただけ（あと命名は一緒にやった相方氏

ハッカソンの発表資料

speakerdeck.com

*スライド内での「しめにゃん」は自分を、「あきむらさん」はチームの相方を指しています

サービスの詳細

サービスの役割としては、カバレッジ率についての情報を持った指定の形式のjsonを受け取ったらそれを元にバッヂを生成(create or update)してくれるという薄いものになります。
バッヂのURLは[固定URL]+[指定したバッヂ名]という形式で、バッヂを出したい側でその辺は管理してね、というスタンス

薄いがゆえに自由度が高く、例えばmasterブランチとdevelopブランチについてのカバレッジを別々に投げつけてやれば、それぞれ別のバッヂとして出してやることも可能です

アーキテクチャ

(スライドより引用)

f:id:sisisin444:20161224224307j:plain

実際に適用したサンプルリポジトリ： sisisin-sandbox/ngts

今回作成したサンプルではこんな流れでバッヂが作られます

GitHub
-> Circle CI
-> put json to S3(ここから先はzoi)
-> execute lambda function
-> put svg file to public S3

GitHub,CircleCIの部分は、[更新したいタイミング]で、[S3へjsonをputできる]ものであれば何でもよいです。

課題とか今後追加したい機能とか

少なくともjsonのフォーマットぐらいはドキュメント化する
クライアント側の導入を楽にするために必要な道具を充実させる
- 冷静に考えて、CIにaws-cli入れてcredential情報入れてjson組み立ててaws s3 cpするとかめんどくさい
- さすがにエンドポイントはAPI Gateway使うほうがいいかなあ
- lcov形式のファイルを渡せばそれっぽいjson生成してくれるcliをnpmかなにかで提供できると大分楽になりそう
コードの整理とか
- テスト書いたりデプロイ自動化したりしておきたい

振り返り

良かった

ハッカソン内で問題を解決しようという気持ちが強く働いた

目標設定が良かった
- （7h * 2人)でちょうど終わるぐらいの規模感
- 完成した形（=ゴール）がきちんと明確になっていて、それに向かって全力を尽くすことが出来た
ぎりぎり終わるかどうかなので、きちんとした段取り、作業のリスクや方針決定、コンフリンクトのない(=お互いの作業をブロックしない)協力体制などを相当真剣に考えた
- -> 普段だいぶ甘えて仕事してることが浮き彫りに
- -> 逆に言うと普段からこのぐらいやればもっと効率改善できるなという気付きが得られた

今回のような目標を達成できるかどうか微妙なラインというのは、問題解決に取り組む姿勢にも相当強く影響を与えてくれたと感じられた。
達成のために相当頑張ろうとするので、適切な目標を立てて本気で取り組むという行為は自分にとってめちゃくちゃ良い刺激が得られるのだと分かったのは大きな収穫だったと思う。

反省点

大勢において反省点はなく、細かい点がいくつかぐらい。

この時間までにこれが終わってないといけないから時間切ってここまでやろう～みたいな、時間ベースでの段取りは出来なかった
- -> 結果的に上手くいったものの、きちんと締め切りからの逆算はするべきだった
たとえ小さいコードでもきれいなコード書いとかないとリファクタや機能追加で即座に死が見えた
- lambdaのコードは手元ではノーテストでデプロイ後の環境でのみ確認できるという時間が結構長く続いたため修正が結構大変だったりした
  - -> 小さい確認サイクルを取るための準備は多少面倒なものでも必ず用意したほうが良い。一日の短い時間でもそれが感じられたので本当に2，3時間で済む作業でなければやるべき。
- 途中の段階で汚いけどいったんマージを決行したのは多分ミスだった
- -> リリースのためにテストなしや多少のことには目をつぶるというよくあるメソッドは本当に罪深い

その他気付いたこと等

手を普段から動かすことの大事さは本当に実感
- どういう書き方がいいんだろう・・・みたいな立ち止まりを減らしてくれるのはやっぱり手を動かした時間。
ペアプロで得られるものが大きいという実感（問題解決の方向性とか、気付きや見習う点、など)
- 例えば、途中にハマったポイントがあり、二人で一緒に解決しようとしたときの話。
  - 相方は知らないAPIを使う時まず公式Docを読む人だったが、自分は今回の状況(aws sdkという恐らく変わりづらいAPI、問題設定への解決方法がありふれたものなので日本語情報が割とありそうという雰囲気)から、先に日本語情報を拾いに行った結果サクッと解決できた問題があった。
- -> 教訓としてはおそらく環境・文化の温度観を察してどの情報源を取りに行くのが効率良いのかという嗅覚を磨くと問題解決への時間短縮につながりそうという感じ？
- 普段の業務においてはたいていの場合においてあきむら氏の公式のドキュメントを読みに行くのが正しいと思う
成功体験を一つ得られてうれしかった（三度目の社内ハッカソンだけどちゃんとやりきれたのは初めて

おわりに

というわけで大変たのしかったハッカソンでした！
今回良い教訓が得られたのでちゃんと身に付けていきたいですね。

あとはzoiの方もちゃんと面倒見て行ってあげたいところ。
がんばるぞい

sisisinのブログ

社内ハッカソンでカバレッジ率のバッヂ出すサービスを作った話