僕はサイボウズで2年ほど前にスクラムを導入し、それ以降スクラムマスターとして活動しています。ありがたいことに最近身の回りで「スクラムマスターに興味がある」という言葉をよく聞くようになりました。同時に「どうすれば良いのか」という声もよく聞きます。人に「こうすると良いですよ」と言えるほど実績も経験もありませんが、スクラムマスターに興味がある、今後やってみたいという方のために、僕はこうしたよという例を紹介したいと思います。あとRSGT2019で話したいと思っていることも少しだけ紹介します。08:12僕がスクラムマスターになった訳Tweet広告を非表示にするもっと読むコメントを書く2018-01-14RSGT2018を終えて、スクラムを始めた時に読んだ本まとめご無沙汰しております。気づいたらブログは丸4年放置していました。2015年にチームリーダーになり、2016〜2017年はスクラムマスターとしてチームにスクラムを導入したり、他チーム・他部署の導入支援などをしていました。2018があり、これまでの活動を発表する機会をいただきました。Amanowww.slideshare.net登壇を聞いてくださった方から「たくさんの本を紹介されてたので、この本をこのタイミングで本を読んでおいて良かった、読んでおいたら良かったと思うものを教えてください。」と質問をいただきました。「○冊選ぶならこれかな〜」といったまとめ方もできますが、ふりかえってみると多数の本を読むことで自分の考え方が徐々に変わり、少しずつ試行錯誤を繰り返しながら自身の一部になっていったという実感があります。今の自分の色眼鏡で結果をフィルタリングするよりも、時系列に読んだ本の列挙+学んだこと要約という形でまとめてみようと思います。巷でAngularJSが盛り上がっているのを横目に、最近は黙々とKarmaを触っていました。Karmaはかなりよくできていて素晴らしいと思うんですが、具体的な使い方はあまり見ないので紹介したいと思います。Karmaについてhttp://karma-runner.github.io/Karmaはいわゆるリモートテストランナーです。リモートテストランナーというと、色んなブラウザでテストを走らせることが目的のように思えますが、そうではありません。主眼が置かれています。コマンドラインでテストを実行するほかにファイルの変更監視CIサーバとの連携デバッグのサポートプラグインによる機能拡張といった機能を持っています。実際に使ってみると、単にテストを実行してくれるだけでなく、ワークフローが劇的に変わることを実感できると思います。個人的にいいなと思うKarmaの特徴について。公式ページのドキュメントが充実しています。ドキュメントをざっと眺めれば使い始めることができますし、CIサーバとの連携方法など使い始めたら気になる所も網羅されていて好感が持てます。あとリポジトリのルートに置いてあるthesis.pdfにはKarmaの設計思想やアーキテクチャがコンパクトにまとまっていて、全体を把握するのに役立ちました。プラグインで拡張できるKarmaはテストフレームワークのサポートやレポーター・プリプロセッサなど機能の多くがプラグインになっています。代表的なものは公式プラグインとして提供されていて、ほかにもユーザーが作成したプラグインが数多く公開されています。おかげで、テストに関する様々な要求に柔軟に対応できます。Growl通知でビルド時はJUnit形式のレポートとカバレッジレポートがほしいなんていう場合にもプラグインの設定をちょいちょい変えるだけでOKです。実績がある実際に現場に投入するとなると、ちゃんと動くかどうかが気がかりです。大規模なプロジェクトはJSファイルが数千になったりするので、安易に乗り換えた結果まともに動かないという事態は絶対に避けないといけません。Karmaはその点GoogleやYoutubeで実際に使われているという実績があり、その安心感はデカイです。KarmaのサンプルプロジェクトそんなKarmaを使うと、「TDDしてCIしてカバレッジを見て...」というワークフローがかなりイケてる感じになります。試しにそのワークフローが体感できるリポジトリを作ってみました。ama-ch/karma-introhttps://github.com/ama-ch/karma-introKarmaのセットアップ方法や基本的な使い方は割愛します。公式ドキュメントや入門エントリを参照してください。karma:devでTDD用の設定でKarmaが起動します。起動した状態でコードを変更すると自動でテストが走って、Growlでポコポコ通知してくれます。Ctrl+Cで終了します。karma:ciでCI用の設定でKarmaが起動します。PhantomJSだけでテストが実行されて、実行後は即終了します。coverageでCoverall用のカバレッジレポートを作成して、Coverallにポストします。手元で直接叩くことはないです。CI設定.travis.ymlはこんなかんじ。coverageするだけです。機能追加ワークフローでは、このリポジトリで何か機能を追加するワークフローを考えてみます。1.フィーチャーブランチを切るまず実装用のブランチを切ります。karma:devでTDDを開始するKarmaが起動してコードの変更を監視します。実装するコードを変更すると自動でテストが走って結果がGrowlで通知されます。デバッグするテストが意図せず失敗したときは、デバッグをします。コンソールを開くとスタックトレースが表示されているので、参考にしましょう。コンソールを見てもよく分からない場合は、Karmaのデバッグ画面(http://localhost:9876/debug.html)を開いてdevtoolsでデバッグします。pushしてプルリクエストを作る実装が一段落したら、ブランチをプッシュしてプルリクエストを作成します。CIのビルドとCoverallsのカバレッジレポートが実行されます。「それKarma使えばWebアプリでもできるよ!」って言いたかっただけです。使ってるプラグインなどgrunt-karma公式のGruntプラグインです。タスクごとにKarmaの設定を書き換えることができるので、これでCI用の設定などを書き分けています。karma-spec-reporterテスト結果をMochaのspecレポーター風に出力してくれるプラグインです。デフォルトのレポーターは通ったテストをほとんど表示してくれないんですよね。一覧で見たい人にはありがたいプラグインです。grunt-karma-coverallsこれはKarmaのプラグインじゃなくてGruntプラグインです。Karmaで作成したカバレッジレポートをCoverallsにポストしてくれます。事前にカバレッジの計測をしておく必要がありますが、Karmaならkarma-coverageで一瞬でできちゃいます。TestemかKarmaかちょっと違う話題になりますが、せっかくなので。提供する機能が大体同じなのでどっちでもいいと思いますが、大規模プロジェクト*1ではKarmaをオススメします。Karmaを触る前はTestemを調べていたんですが、大量のJSを読み込むとファイルディスクリプタの上限に引っかかって動かなかったりwatchでCPUリソースを食い潰して死亡するという現象が発生したため断念しました。いえTestemはレポーターがかっちょいいですし、基本はやっぱり好みで決めて、問題が起きたら他のも検討してみるくらいでちょうど良いんじゃないかと思います。まとめKarmaを使うとテストが自動で動かせるだけじゃなくて、CI連携やカバレッジ計測もできるようになります。ワークフローが変わります。AngularJSも良いけどKarmaもぜひ使ってみてください!*1:読み込むJSのファイル数が数百を超えてくるイメージです。Linterのリポジトリを確認してみたらバージョンが2.3.10に上がっていて、色々と機能が追加されていました。今まではこれができなくて、導入に二の足を踏んでしまう人も多かったんじゃないかと思います。--max_line_lengthと--disableというコマンドラインオプションでそれぞれ指定可能です。以下はヘルプから抜粋。integer)MAX_LINE_LENGTHが設定できない件はディスカッションでも何度か言及されていたんですが、かなりの強硬姿勢で頑として設定可能にはしないという雰囲気で完全に諦めてラッパースクリプトを書いたりしていました。それが一転して設定可能になるという僥倖に鼻息が抑えられません!しかしなぜ急に設定可能になったんだろう?JSHintが歩み寄ってくれたのが関係あったりするんでしょうか。理由はさておき、導入がしやすくなったのは素晴らしいです。JSHintと併用するのも簡単になったので、ますますLintが捗りそうです。Toolsのヒーププロファイラを使った解析方法を書きました。大型本この商品を含むブログを見る近ごろはJavaScriptでもメモリ管理を気にかける機会が増えていると感じます。前まではメモリリークというとIEのJSとDOMの間で循環参照がナントカみたいな話が多かったですが、最近はシングルページのリッチなWebが増えたことで、純粋にオブジェクトのライフサイクルをきちんと管理しないといけなくなりました。連載の内容は、まずオブジェクトのライフサイクルとガベージコレクションの動きを解説して、実際にリークが発生するサンプルコードをヒーププロファイラで解析していくような構成になっています。Viewにも触れています。Backbone.jsをはじめとするMVCフレームワークがJavaScriptに新しいパラダイムを導入してくれましたが、それによってメモリリークが発生するというのは避けたいですね。このような罠にはまらないためにも、オブジェクトのライフサイクルをきちんと把握・管理することが重要です。新人にドヤ顔で「それリークしてるよ」って言うためにも、このあたりはぜひ把握しておきたいですね。逆に新人さんは「それってメモリリークしませんか?」と強力なスタートダッシュを決めるチャンスです。1.1.0がリリースされ、そのリリースノートに気になる記述がありました。LinterってJSDocとかお作法的なとこはチェックしてくれるけど、他のLintツールが当たり前にチェックしてくれるとこはやってくれないんですよね。varの付け忘れとか。Compilerを使ってコンパイル時にチェックすることもできるけど、規模が大きくなってくるとその結果が出るまでに10分とか待たないといけなくっていやな感じー。LinterとJSHintが一緒に使えたらいいんだけどなー。LinterとJSHintが喧嘩してしまい、同時に使うのが難しかったんです。1.1.0で解消したと。Linterが一括でかけられるGruntプロジェクトを作ってみました。gruntデフォルトタスクにjshint:allとgjslint:allが設定してあります。watch変更したファイルのみjshint+gjslintして、結果をGrowlで通知します。解説など以下、中身の解説です。--flagfileを渡したいgjslintを実行するGruntタスクとしてはgrunt-closure-linterがありますが、gjslintコマンドに任意の引数が渡せないっぽかったので練習もかねてタスクを自作しました。gjslintの設定はファイルにして--flagfileオプションで渡せるようにしておくと、.jshintrcと似た設定が書けて後述のエディタ連携でも使えます。Linterを使ってて一番キツイのが一行80文字制限だと思います。これはハードコーディングされていて、設定ができないという。Linterの80文字制限は不要です。この記事を参考にして、ラッパースクリプトを追加して80文字制限を除外しました。あとはこのラッパースクリプトをGruntfile.jsにgjslint.cmdというパラメータで記述して、それを実行するようにしています。watchして変更したファイルだけlintGruntのサンプルを見ていると大体watchで全部のファイルがlintやminifyの対象になっていて、そこそこの規模のプロジェクトで使うのは厳しいです。watchの時は変更したファイルだけタスクの対象にしたいですよね。Gruntが出てきた時にそれができなくて手を出すのをやめて、継続的にウォッチだけしていました。前にgrunt-contrib-watchにnospawnというオプションが入って、これを使うと変更ファイルが取得できるらしい。これで勝つる!と意気込んだものの、ちょっと調べてみたらgrunt-regardeっていうやつの方が良いらしいので結局そっちを使いました。具体的な書き方を一部抜き出すとこんな感じ。'js/**/*.js']});jshintにwatchというターゲットを追加して、srcにgrunt.regarde.changedと指定すると、変更されたファイルだけを対象にしてタスクが実行できます。筋の良いやり方かどうかは分かりませんが。watchでregardeが動くようになりました。やったね!Gruntfile.jsもwatchで書けるようになります。watchしてるときにエラーが出ても落ちないようにするwatchタスクの実行中にlintエラーが出るとタスク自体が終了してしまって、全然watchできない。オプションにforceをつけるとか何種類か回避方法はあるみたいですが。ここのやりとりを参考にして以下のようにしました。{};});watchの結果をGrowl通知Growl通知はgrunt-notifyのnotify_hooksを使うだけでできました。gjslintはstdoutに改行が含まれるせいか、Ubuntuのnotify-sendがうまく通知してくれませんでした。Growlでは問題ないので、ひとまず後回し。IDEAに乗り換えました。Linterに対応していて、設定ファイルを指定するだけでエディタと連携できます。LinterエディタJSHintはちょっとバンドルされているバージョンが古いようで誤判定される部分もありますが、概ね快適に使えています。2とgjslintの--jslint_error=indentationは同時に設定するとswitch文で喧嘩する。Linterおすすめです。Toolsの解説を書きました。見るconsole.log()や簡単なJSのデバッグ、レイアウト調整くらいはやったことがあるけど、それ以上の使い方はよく分からないという方のために、次の一歩を進んでもらいたいと思って書きました。実践的なJSのデバッグ方法を中心に解説し、Timelineパネルを使ったメモリリーク検出方法といった比較的新しい機能も扱いました。Toolsは本当に進化が早くて、執筆中でもお構いなしにバージョンが上がったりUIが変わったりするのが大変でした。この開発スピードのおかげで、僕たちはいち早く便利な機能が使える訳です。このスピードは本当に凄いと思います。個人的に気に入ってる機能は、キーボードショートカットです!特にCtrl+oで「ソースを開く」、SourcesパネルでCtrl+Shift+oで「シンボルを開く」はよく使います。Vol.72は本日発売です。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。