社内ハッカソンでカバレッジ率のバッヂ出すサービスを作った話
うちの職場では3か月に一度程度の頻度で1営業日(7.5h)使ってハッカソンを開催しています。
ハッカソンでは各自で作りたいものを考え、一人あるいはチームを組んで1日かけて物を作ります。
1日の最後には各制作物についての発表をし、投票を行って得票数の多かったチームには後日表彰・賞品の贈呈を行います。
今回自分は2人チームでハッカソンに取り組みました。
その成果物についての紹介と当日の振り返りをしたいと思います。
やったこと
カバレッジ率の情報を持ったjsonをAWS lambdaに投げつけたらShields.IOからバッヂのsvgファイルをもってきてS3に配置するサービスを作りました
モチベーション
背景として、社内のリポジトリでサーバサイドとフロントエンドが同居するときにカバレッジの計測・保持・バッヂの出し方をどうしようという話が上がっていました
うちの職場ではcoverallsというサービスにてカバレッジ結果を集計しているのですが、これが1リポジトリに対して1つしか計測結果を保存してくれない。(2つ以上保存する方法あったら教えてほしいです><)
そのため、最近計測できるようになったフロントのカバレッジをどうやって可視化しようかという議題が出ていたわけです。
そんなタイミングでハッカソンが近づいていたので、バッヂ出すだけなら1日あればいけんじゃね?と思ってやってみました
成果物
リポジトリ
(名前は完全にzoiって言いたかっただけ(あと命名は一緒にやった相方氏
ハッカソンの発表資料
*スライド内での「しめにゃん」は自分を、「あきむらさん」はチームの相方を指しています
サービスの詳細
サービスの役割としては、カバレッジ率についての情報を持った指定の形式のjsonを受け取ったらそれを元にバッヂを生成(create or update)してくれるという薄いものになります。
バッヂのURLは[固定URL]+[指定したバッヂ名]という形式で、バッヂを出したい側でその辺は管理してね、というスタンス
薄いがゆえに自由度が高く、例えばmasterブランチとdevelopブランチについてのカバレッジを別々に投げつけてやれば、それぞれ別のバッヂとして出してやることも可能です
アーキテクチャ
(スライドより引用)
実際に適用したサンプルリポジトリ: 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のフォーマットぐらいはドキュメント化する
- クライアント側の導入を楽にするために必要な道具を充実させる
- コードの整理とか
- テスト書いたりデプロイ自動化したりしておきたい
振り返り
良かった
ハッカソン内で問題を解決しようという気持ちが強く働いた
- 目標設定が良かった
- (7h * 2人)でちょうど終わるぐらいの規模感
- 完成した形(=ゴール)がきちんと明確になっていて、それに向かって全力を尽くすことが出来た
- ぎりぎり終わるかどうかなので、きちんとした段取り、作業のリスクや方針決定、コンフリンクトのない(=お互いの作業をブロックしない)協力体制などを相当真剣に考えた
- -> 普段だいぶ甘えて仕事してることが浮き彫りに
- -> 逆に言うと普段からこのぐらいやればもっと効率改善できるなという気付きが得られた
今回のような目標を達成できるかどうか微妙なラインというのは、問題解決に取り組む姿勢にも相当強く影響を与えてくれたと感じられた。
達成のために相当頑張ろうとするので、適切な目標を立てて本気で取り組むという行為は自分にとってめちゃくちゃ良い刺激が得られるのだと分かったのは大きな収穫だったと思う。
反省点
大勢において反省点はなく、細かい点がいくつかぐらい。
- この時間までにこれが終わってないといけないから時間切ってここまでやろう~みたいな、時間ベースでの段取りは出来なかった
- -> 結果的に上手くいったものの、きちんと締め切りからの逆算はするべきだった
- たとえ小さいコードでもきれいなコード書いとかないとリファクタや機能追加で即座に死が見えた
- lambdaのコードは手元ではノーテストでデプロイ後の環境でのみ確認できるという時間が結構長く続いたため修正が結構大変だったりした
- -> 小さい確認サイクルを取るための準備は多少面倒なものでも必ず用意したほうが良い。一日の短い時間でもそれが感じられたので本当に2,3時間で済む作業でなければやるべき。
- 途中の段階で汚いけどいったんマージを決行したのは多分ミスだった
- ->
リリースのためにテストなしや多少のことには目をつぶる
というよくあるメソッドは本当に罪深い
- lambdaのコードは手元ではノーテストでデプロイ後の環境でのみ確認できるという時間が結構長く続いたため修正が結構大変だったりした
その他気付いたこと等
手を普段から動かすことの大事さは本当に実感
- どういう書き方がいいんだろう・・・みたいな立ち止まりを減らしてくれるのはやっぱり手を動かした時間。
ペアプロで得られるものが大きいという実感(問題解決の方向性とか、気付きや見習う点、など)
- 例えば、途中にハマったポイントがあり、二人で一緒に解決しようとしたときの話。
- -> 教訓としてはおそらく環境・文化の温度観を察してどの情報源を取りに行くのが効率良いのかという嗅覚を磨くと問題解決への時間短縮につながりそうという感じ?
- 普段の業務においてはたいていの場合においてあきむら氏の公式のドキュメントを読みに行くのが正しいと思う
成功体験を一つ得られてうれしかった(三度目の社内ハッカソンだけどちゃんとやりきれたのは初めて
おわりに
というわけで大変たのしかったハッカソンでした!
今回良い教訓が得られたのでちゃんと身に付けていきたいですね。
あとはzoiの方もちゃんと面倒見て行ってあげたいところ。
がんばるぞい
SCRUM BOOT CAMP THE BOOK読んだメモ
最近弊社でスクラムを取り入れるという話になり、気付いたら始まっていたので遅ればせながらスクラムについてキャッチアップしていこう運動を始めました。
手始めにSCRUM BOOT CAMP THE BOOKを読み始めたのでそのメモをば。
なお、タイトルが「読んだ」になってるけどまだ途中です。
プロダクトバックログの見積もり
開発メンバー全員で、ポーカーなどを用いて相対見積もりで数字を出していく作業。
この際重視しているのは、話し合いをすることでメンバーが対話を出来る状態になることや、目を多くして見落としをなくすことの模様。
以下、見積もり上でのポイントっぽいところ
- 作業量を相対的に見積もる
- 基準となるユーザーストーリーを一つ決め、その基準を元にストーリーポイントという単位で見積もる
- 見積もりそのものは割りとえいやでやってしまって良くて、誤差を気にするよりも手早く終わらせることを優先
- 詳細にやるのは優先度が高い、直近でやるべきユーザーストーリーに対してのみ。
- 見積もり上で疑問・不明点があり、それが解消できないと見積もれないものについては無理に数字を入れなくとも良い
スプリント計画MTG
2部構成になっており、1部でスプリントで着手するユーザーストーリーを提示、2部で作業の実現方法を話し合う。
一部
- POがプロダクトバックログから今回のスプリントで着手するユーザーストーリーを提示
- その際に要件の説明や、完了定義を説明、開発メンバーと意識合わせをする
二部
- 開発メンバー全員でタスクの洗い出しと詳細な見積もりを行う
- なるべく詳細なタスクに分割し、1タスクにどのぐらい時間がかかりそうかを見積もる
- スクラムでは計測した結果を元にした予測がキモになるので、ここでは詳細で具体的な計画にすることを心がける
デイリースクラム
ここで報告する目的はスプリントにおいての「検査」であり、進捗報告ではない
スプリント目標を達成するために、新たに問題が出ていないかを毎日検査する
- 15分を必ず守るようにする
- スクラムマスターはデイリースクラムの少し前にメンバーに声掛けするなどしてスムーズな進行を心がけると良い
- 問題発見の場であり、問題解決の場ではないので、解決のための案だしなどが始まるのはNG
- 問題が見つかったら、デイリースクラム終了後に必要なメンバーで対策の話し合いをすぐ行う
- 問題発見さえできればいいので、PO/SMはいなくても良い。
スプリントレビュー
POが完了条件を満たしているかを確認する場
- 要は認識合わせの場っぽい
- なので、動くものを見なきゃ認識あってるかわからないよね、という話になる模様
今日のところは一旦ここまで。
Firebaseを使ったので所感と資料をメモ
ここ最近、適当なWebアプリを作るのにバックエンドどうしようかって悩みを持っていたところにこんな記事が目に入ったので、Tutorial触ったり少し調べたりしたことなどメモ。
FirebaseでWebチャットアプリをデプロイするまで(1時間コース) - Qiita
Tutorialについて
- よくあるリアルタイムチャットアプリの実装からデプロイまで簡単にできるという内容
- Tutorial内でざっくり下記の機能に触れる
所感
大雑把にmongodbとsocket.ioを賄ってくれるサービスっぽい
サーバサイドの実装が欲しくなると一気に困るんだけどBaaSは普通そんなもんなのかな。
Twitterの認証もあったけど、API叩くためのトークンを取れないっぽい(クライアント側にトークンを露出させない作りであるゆえにそうなってると解釈してるけど、もし出来る方法あったらどなたかこっそり教えて下さい)
料金
https://firebase.google.com/pricing/
同時接続数100までは無料で使えて、それ以上は月$25 個人で使う文には充分か
その他
フェイルオーバーの仕組みがないとか、割と頻繁に落ちるという話を2016年3月時点の記事でちらほら見かけるのでちょっと怖いかも?
あと、クライアントだけでなくサーバサイドからも利用できるという話もあったので色々使えるっぽいけどそれが適切な道具の使い方なのかはちょっとわからない。
資料
バーデと天然温泉 豊島園 庭の湯に行って来た
またお風呂行って来ました。 www.niwanoyu.jp
アメニティ
無料で利用できるもの
- ハンドタオル
- バスタオル
- 館内着
- クシ
- ドライヤー
有料
- 水着レンタル
所感
立地
池袋から西武池袋線で15分、駅からは歩いてすぐという好立地。
風呂
洗い場が気持ち少なめ。
湯の種類は少ないものの、露天が見栄えするので満足感あります。
夜に行ったのでライトアップされていてそれがまた良い感じ。
一人で入るタイプの小さい露天風呂も用意されていたりしてゆっくりしやすい環境でした。
自販機
瓶の牛乳・コーヒー牛乳・ミックスジュース置いてありました。重要。
施設
充実の館内スペース。
敷地が広いので休憩スペース・食事スペース共に広めでした。
自販機等の館内販売は全てリストバンドでの管理。盤石。
入館料は前払いであとから精算なので手間はあり。
ロッカーが細いのでちょっと注意。といっても、そんなに荷物必要ないので大丈夫だとは思います。
リラクゼーションルーム
充実の席数と種類。
和室・リクライニングチェアがあり、後者に関しては静かに寝られるスペースが別に設けられているので、リラクゼーションエリアでPCおっぴろげてコーディングが出来た。ありがたい。
和室の方は寝る専用っぽい。
食事処
今日も食事は利用してませんのこと。
支払い
クレカOK
また、18時からはナイト料金でお安くなっています
総括
仕事上がりにふらっといけそうでとても良い。
タオル・館内着と用意されているので、下着の替えだけあれば事足りるのもGood.
平日夜ならかなり余裕持って利用できたので活用していきたいですね。
土日にひとっ風呂浴びてコーディングするぞって来た時にどのぐらい混雑しているかもそのうち確かめたいところです。
東京染井温泉 SAKURAに行ってきた
公式サイト
www.sakura-2005.com
下記のブログで紹介されていて、サラッと行ける場所だったのでサラッと行って来ました blog.shoby.jp
所感
風呂
狭くなく、露天もあり、都内にしては充実してる。
平日日中に行ったため、比較的空いてました(それでも割と客は入っていた)
混雑するとちょっと手狭に感じるかも。混みあう時間帯はどのぐらい人が来るのか気になるところ。
自販機
瓶の牛乳・コーヒー牛乳置いてありました。重要。
施設
綺麗な館内でリラクゼーションルーム・和室の休憩室・食事処と一揃いある感じ。
館内着も貸してくれるし、滞在時間に制限はないのでゆっくり過ごす環境は整ってます。
自販機等の館内販売は全てリストバンドで管理されていて大変便利。
退館するときに一括で支払うスタイルでした。
リラクゼーションルーム
椅子に座ってゆっくりノートPCでも弄りたいと思って訪れたけど、かなり静かな部屋だったのでちょっとキーボード叩くのは憚られました。
席も10席しかなく、平日日中でも普通に席が埋まるぐらいだったのでここ目当てで来るのはちょっと危険かも。
和室の休憩室(談話室)
畳の部屋で特に何も置いてなかった。
風呂あがりに横になる以外に出来ることなさそう。
食事処
今回は利用してないので特に。 メニュー見る感じ、お値段はそれなり。ああ、こういうところってこのぐらいするよね、みたいな感じです。
支払い方法
クレカ、交通系ICカードが利用できる。
Good.
ゲーセン
駅近くにあったので行きがけに遊べる。やったぜ。
※施設内にあるわけじゃないです
総括
ゆっくり風呂入りに行くなら◯
ただし土日に行ってどのぐらいゆっくり出来るか次第、のようには感じます。
ひとっ風呂浴びてさあコーディングだ!って環境はなかった。
TypeScript+Browserify+mochaでフロントエンド開発環境
成果物
動機
TypeScriptでフロント開発するときにテストコードもtsで書きたい(という話を聞いた)
使ったもの
- Node v5.1.0
- TypeScript v1.7.5
- gulp
- browserify
- mocha
- power-assert
出来ること
gulp-mochaでtsのプロダクトコード・テストコードをテストしながら開発
browserifyでbundleしてブラウザで実行可能な状態に
他にもやったこと
- gulp-mocha使わずmocha単体で
mocha --compilers ts:espower-typescript/guess test/*.ts
- gulp-typescriptで一時的にファイル吐き出すtaskの定義(トランスパイル後のファイルをテストしたいケースとかで使える?)
やってないこと
- watchfyで差分ビルド