Kyoto.なんかというイベントを開催しました

GWの真ん中の5月3日(土)にKyoto.なんかというイベントを開催しました。

Kyoto.なんかは"京都に集まってプログラミング等の発表をしあってわいわい語らう"という趣旨の勉強会で、このような、ふわっとした趣旨にも関わらず、11人の発表者の方々と40人を超える参加者の方々に集まっていいただき、たいへん盛り上がる会になりました。懇親会でも今までにお話したことの無い方同士がわいわい交流できていた風で、なかなかうまくいったんじゃないかと思っています。ご参加のみなさまありがとうございました!

もともとはKyoto.jsを開催する予定だったところ、GWにいろんな分野の方が京都周辺にいらっしゃるということで、もう少し間口の広い会を企画することにしました。プログラミングに関係するなんかを発表すれば良いということで、Kyoto.なんかと仮で名づけたのですが、そのまま開催されたという趣きです。

いろいろお願いするうちに11人もの方に発表していただくことになったため、当日は一人持ち時間15分でつぎつぎとおもしろ発表していただくという形式になりました。時間になったら銅鑼がなるというルールで、発表者の方々はたいへんだったと思うのですが、勢いがあって良かったです。

Kyoto.なんかでの発表の資料を見つけた限りまとめました。発表者のみなさま、ありがとうございました!

どの発表も聴き応えがあってとても良かったので、ぜひチェックしてくださいませ。

今回は、GWに京都に人が集まってきそうだということでイベントを開催してみたのですが、思いの外たくさんの人に参加いただいて、すごくおもしろかったので、気が向いたらまたやりたいです。たぶん多少レア感があったのが良かったので、たまに開催することにしたいと思います。(Kyoto.jsでは二週間に一回開催しようとして息切れして一年くらい何もしてなかった)

Kyoto.なんか の次回開催のモチベーションのためにブログやTwitterなどでの感想をいただけますと、よろこびますのでよろしくおねがいします!

この写真では真面目な様子ですが、発表の後、数時間ピザをたべつづけながら楽しく交流しました。

ワイワイ出社 for Android

参考: ワイワイ出社 - hitode909の日記

ifttt の Android アプリがリリースされたので、Androidをご利用のみなさまもワイワイ出社/ワイワイ退社ができるようになりました。どうぞご利用ください。

IFTTT Recipe: ワイワイ出社 connects android-location to twitter

IFTTT Recipe: ワイワイ退社 connects android-location to twitter

さっきちょっと会社に寄ってみたところ、ワイワイ出社されなかったけど、ワイワイ退社には成功した。

DevLove関西でCoding Kataの紹介をしました

DevLove関西主催の自動テストの誤解とアンチパターンという勉強会でCoding Kataの紹介をしてきたので、資料を公開します。

以前、暇すぎて実装していたボウリングゲームのKataの実装をLiveCodingして、プログラミングの様子をご紹介しました。どんな感じで、TDDでプログラミングするのかが、なんとなくでも伝わっていればうれしいです。



発表時間の都合で会場では途中までしかできませんでしたが、完成版のソースコードを公開していますので、良ければ参考にしてください。

↑ のコードはわかりやすさ重視という感じですが、よりScalaっぽいものも書いてみたのでよければこちらもどうぞ(インターフェースちょっと違います)。

golangで書かれたプログラムのメモリ使用状況を見る

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ごとのシンボルテーブルっぽく見えるけどあんまり読み方がわかってない。リロードするとその時々のメモリ状況が見れて面白い。

f:id:hakobe932:20140410010531p:plain

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分くらいでできるようになってすばらしい生産性が得られる予定。ひまなときにどんどんボウリングゲームしていきたい。

Play Framework で開発用Webサーバと同時に grunt/gulp を起動する

手元の環境で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サーバを起動するだけで、同時に別のプログラムも起動することができるようになった。余計なことをきにする必要が減って便利になった。