DevLove関西主催の自動テストの誤解とアンチパターンという勉強会でCoding Kataの紹介をしてきたので、資料を公開します。
以前、暇すぎて実装していたボウリングゲームのKataの実装をLiveCodingして、プログラミングの様子をご紹介しました。どんな感じで、TDDでプログラミングするのかが、なんとなくでも伝わっていればうれしいです。
発表時間の都合で会場では途中までしかできませんでしたが、完成版のソースコードを公開していますので、良ければ参考にしてください。
↑ のコードはわかりやすさ重視という感じですが、よりScalaっぽいものも書いてみたのでよければこちらもどうぞ(インターフェースちょっと違います)。
golangにはpprof用のプロファイルデータを出力できるライブラリが標準でついてくるので、それらを使うことでメモリの使用状況を調べることができる。中でも、net/http/pprofが手軽で便利だった。
net/http/pprofをプログラムに組み込むことでダイナミックなプロファイル情報をWebブラウザで表示してみることができる。使い方は、ライブラリの解説ページにあるとおりなんだけど、プロファイルを取りたいプログラムで
import _ "net/http/pprof"
とimportしたあと、main関数などで
go func() { log.Println(http.ListenAndServe("localhost:6060", nil)) }()
と書いておくと良い。
この状態でプログラムをbuildして実行する。プログラムの実行中に、http://localhost:6060/debug/pprof/heap?debug=1 にアクセスすると、プログラムのメモリの使用状況が表示されるので、下の方にあるruntime.MemStatsを調べたりしましょう。runtime.MemStats以外の部分は、goroutineごとのシンボルテーブルっぽく見えるけどあんまり読み方がわかってない。リロードするとその時々のメモリ状況が見れて面白い。
pprofコマンドの入力にURLがそのまま使えるので、以下のように調査したりもできる。pprofコマンドを使うといろんなビジュアライズができるらしい。コールグラフをsvgで出力したりもできそう。
$ go tool pprof --text http://localhost:6060/debug/pprof/heap | head -n 10
Read http://localhost:6060/debug/pprof/symbol
Fetching /pprof/heap profile from localhost:6060 to
/var/folders/xr/w4h_3ccx43dg7xjc9xj14m_00000gn/T/1KRgavcr87
Wrote profile to /var/folders/xr/w4h_3ccx43dg7xjc9xj14m_00000gn/T/1KRgavcr87
Adjusting heap profiles for 1-in-524288 sampling rate
Total: 453.1 MB
431.6 95.3% 95.3% 431.6 95.3% bytes.makeSlice
5.5 1.2% 96.5% 5.5 1.2% bufio.NewReaderSize
5.5 1.2% 97.7% 5.5 1.2% main.func·002
3.5 0.8% 98.5% 3.5 0.8% bufio.NewWriter
2.5 0.6% 99.0% 2.5 0.6% newdefer
1.5 0.3% 99.3% 11.0 2.4% net/http.(*Transport).dialConn
1.0 0.2% 99.6% 3.5 0.8% net/http.(*persistConn).readLoop
0.5 0.1% 99.7% 0.5 0.1% net.sockaddrToTCP
0.5 0.1% 99.8% 0.5 0.1% net/http.ReadResponse意図的にメモリリークしてみたら、けっこうたくさんリークしててやばい。
ひますぎてボウリングゲーム実装してた。
これはCoding Kataの一種で、ボウリングゲームのスコア計算をするのが目的ではない。Coding Kataというのは、達人プログラマー―システム開発の職人から名匠への道などで有名な
Dave Thomasさんが提唱した、プログラミングの練習法。このボウリングゲームのKataはアジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技などの著者であるRobert C. MartinさんのWebサイトに詳しいやり方が載ってる。2008年くらいの角谷さんの発表にも少しのっていてわかりやすい(当時実演を見せてもらった)。
ボウリングゲーム以外に逆ポーランド記法電卓でやるパターンとかさがせばいろいろある。
Kataといってるのはまさに柔道の形のことで、Wikipediaによると、
形（型）（かた）による形稽古は日本の武道（日本の武術）では普遍的な稽古法であるが、柔道（柔術）では、技を掛ける「取（とり）」と技を受ける「受（うけ）」にわかれ、理合いに従って、決められた手順で技を掛け、受け止め、反撃し、それを反復することによってその理合と技を習得するものである。我が国の修行方法といえる
とある。これと同じで、決められたプログラムを決められた手順で実装することで、リズム感のあるTDDの開発や、テストライブラリの使い方や、効率のよいエディタの操作方法などの練習ができ、実戦でもすばらしいプログラミングができるようになるというものだ。
今回やったボウリングゲームは、なんか資料を見ながらちまちまやってたら一時間くらいかかったのだけど、練習するうちに10分くらいでできるようになってすばらしい生産性が得られる予定。ひまなときにどんどんボウリングゲームしていきたい。
手元の環境でWebアプリケーションを開発するために、複数のプログラムを手動で起動しないといけないのは面倒だ。たとえば、rackupとgruntを同時に起動しておかないと、lessやjsをコンパイルしながらページを表示できないという風だと、いつも両方が起動しているように気をつけないといけないし、そのこと忘れてしまってなぜかデザインが当たらないなどといって悩むはめになる。
RubyのforemanやPerlのProcletなどを使うと、複数のプログラムを同時に起動したり終了したりすることができる。先ほどの例だと、Procfileにrackupとgruntの起動コマンドを書いて、開発環境でWebアプリケーションを起動するときにはforeman startするということにしておけば、必要なプログラムがすべて起動しているという状態に簡単にできて便利だ。
一方最近自分は、Play Frameworkで開発をしてる。Play Framework では sbt から開発用のWebサーバを起動する。sbtの起動は時間がかかるので、sbt自体は起動したままにして、sbtのコンソールから、Webサーバを起動したり停止したりできる仕組みになっている。このような仕組みなので、foremanから直接Webサーバを起動するのは難しい。(できなくはないけど、都度sbtを起動しなおすことになるので遅い)
調べてみたところ、sbtとPlay Frameworkの機能をうまく使うと、Play Frameworkの Webサーバが実行されている間だけ、別のプログラムを起動することができるようだった(参考:Playframework 2.2 Grunt Runner · GitHub)。
Play Frameworkには playRunHooks というsbtのSettingがある。これにPlayRunHookというtraitを実装したobjectを設定しておくと、Webアプリケーションが起動するタイミングや終了するタイミングにhookをかけれる。sbtには別のプロセスを起動する仕組みがあるので組み合わせると以下のようになる。(参考にさせていただいた、Playframework 2.2 Grunt Runner · GitHubをちょっと汎用的にしてる)
// project/RunSubProcess.scala import sbt._ import Process._ import Keys._ import play.PlayRunHook object RunSubProcess { def apply(command: String): PlayRunHook = { object RunSubProcessHook extends PlayRunHook { var process: Option[Process] = None override def beforeStarted(): Unit = { process = Some(Process(command).run) } override def afterStopped(): Unit = { process.map(p => p.destroy()) process = None } } RunSubProcessHook } }
// build.sbt name := "hoge" // ... 中略 ... play.Project.playScalaSettings playRunHooks += RunSubProcess("grunt watch")
これで無事、Play FrameworkのWebサーバを起動するだけで、同時に別のプログラムも起動することができるようになった。余計なことをきにする必要が減って便利になった。
強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」
原著はREMOTEという名前の本。リモートワーク最高という話をBasecamp(元 37 Signals。社名変わってたの知らなかった)の人が教えてくれる。気楽なお話なので、すぐ読める。rebuild.fm#35でも触れられていた本。
本書によると、オフィスに集まって仕事するのは、集中が乱されることが多いし、通勤も大変、住みづらい都会に住む必要もある。リモートで働くことにすれば集中出来る環境で、住む場所や時間にしばられず、効率よく仕事ができるらしい。職種にもよるものの、いろんな工夫をすれば、十分仕事はできるし、Basecamp社やいくつかの企業でも実際うまくやっているそうな。
リモートワークに対してよくあげられる疑問に対して、勢い良く答えている章がおもしろい。みんなが集まってこそ生まれる最高のアイディアがあるんじゃないか、と言う疑問に対しては、リモートでもアイディアは生まれることは、何度もあったし、仮に対面のほうがいいアイディアが山ほど生まれたとしても、企業がそれらをすべて処理できるわけではないと答えてる。リモートだと仕事をサボるのでは、と言う話についてはそもそもそういう人間を雇うのがおかしいというはなしで、勢いがある。
リモートワークすればすべて解決というわけではなくて、オフィスワークとはコミュニケーションのやり方は変えないといけない。コアタイムをきめて、全員がコミュニケーションできる時間を作ったり、チャットツールやビデオ会議ツールをうまく活用したり、いい感じのコラボレーションツール(ここでBasecampをご利用くださいとなる。WikiとかGithubみたいなイメージ)を使ったほうが良いらしい。
Basecampのひとがリモートワークを推進するのはそりゃそうだよな、と思いつつも、確かにずっとオフィスに引きこもって仕事をする必要がないとも思った。今のチームでも、朝に軽く相談したあとは、普段の仕事はだいたいIRCとHipchatとGithubの上で会話するのでなんとかなってる。少なくともコードを書く活動をする分には、家とかカフェとかでも仕事ができる気がする。とはいえ、新しいチームができたときにはじめに信頼関係を築くとか、ブースの真ん中に集まって雑談して、なんとなく問題を整理するとか、帯域の広いコミュニケーションに頼らないといけなかったことは結構あるので、そのへんはなんか工夫しないとダメそう。本書でも、たまには会わないと行けないっと書いてある。
いろんなツールが揃ってきたことで、スムーズにリモートワークできるようになって、自由に働けるなら、そんなにうれしいことはないという感じであった。
毎度おなじみの関西における今期のアニメの放送状況を表にまとめました。今回もしょぼいカレンダーのデータを利用させていただいています。予約設定時の確認などにお役立てください。今回からは、スマートフォンでも見やすいページ も用意しましたので、ご利用ください。
今季の関西最速は以下の5作品でした。
冬アニメの2作品に比べて今期は最速作品が多く、すばらしい期になりそうです。
やはりまずはキャプテンアースに期待です。STAR DRIVER 輝きのタクトのスタッフが再結集して作るロボットアニメということで、同じようにおしゃれな動きのロボットが活躍してくれるのでしょうか。どんなストーリなのかも期待です。
悪魔のリドルはNewTypeで連載中のコミックが原作で、高河ゆんさんの作品です。クラスメイトが全員暗殺者というストーリーの展開や、アクションシーンが楽しみですね。
selector infected WIXOSSはカードゲームを舞台にしたオリジナル作品で、WIXOSSというカードゲームがアニメと同時に実際に展開されるそうです。予告のCMは結構ダークな雰囲気なので、思ったよりシリアスなストーリーが楽しめそうです。
召しませロードス島戦記～それっておいしいの？はロードス島戦記好きの主人公がロードス島戦記を広めるために、ロードス島戦記の劇をする..という内容の三分アニメらしいです。あまり情報がないので、どういったアニメになるか、見てみて知れという感じですね。
それでは、関西の皆さん、今期もがんばりましょう。
この上に番組表が表示されていない場合は、@hakobe にお問い合わせください。
