大学で公演してきた

所属していた学部が10周年ということで、1期生の人たちは今どうなっているかというパネルディスカッションに出演させていただいた。

情報理工学部10周年イベント 「あいちゃれ×みらい塾 次世代グローバルIT人材を生み出す非常識と常識」 | Facebook

基調講演の高須賀さんのお話がたいへんおもしろくて、ハードルが高い状況でトークが開始されたものの、自分はともかくパネラー方々がみなめっちゃ個性的なこともあって、中々おもしろいセッションになった気もする。

聴衆の多くは現在学部に通っている学生さんが多かったので、話題が自然と学生さん達へのメッセージになったのだけど、みんな口をそろえて言ってたのは、何かしら好きなことを見つけてのめり込むと良いということであった。

こう書くと意識高いみたいな話になってつらいものの、自分がめっちゃおもしろいと思っていることをやり続けるのは、モチベーションを維持しながら修行して能力を高めるのに大変効率が良い。その結果として良い成果が出たり、お賃金をいただけたりして、どうにか幸せになれるのであれば、そんなにうれしいことはないという話。

パネラーの人たちはそれぞれ勢いのある成果があって、そういう人たちが一斉に好きを貫け!とか言っていたら、学生さんにとっても、まぁまぁ迫力があったような気もする。

振り返ると、自分も、プログラミングやインターネットおもしろいとか言っていろいろやっているうちに、今の仕事を楽しくやらせてもらっているのがある。わりと雑に選択肢を選んできたこともあるものの、なるべくおもしろさを損なわないようには選んできたつもりで、今のところモチベーションもなんとか運用できてる。なんとか運用しているという風では良くないので、もっと効率良くはしていきたい気はしてる。いい感じの成果を得てモチベーションを高めたいけど、それはがんばるしかない。いい感じの成果についてはひとでくんも何やら書いてた(■ - hitode909の日記)

ともあれ、イベントに呼んでいただいて、おもしろい話も伺えたし、同期ががんばってる様子もわかったし、わかものといろいろ交流することもできて良かったです。ありがとうございました。

わかもの向け情報: 何かしら好きなことを見るけるのに便利なインターンシップがあるのでどうぞ。

「はてなサマーインターン2014」を開催します - Hatena Developer Blog

さっき見た夢

風吹きすさぶ海岸にて:

• かつての生徒: 「先生、僕のこのブランチ。 マージしてくださいませんか...?」
• マスター先生: 「...」
• 刑事: 「先生! もういいでしょう。今が大事なときなんです。どうかこのブランチをマージしてくださいよ。あなただってそうすれば良いことくらい、わかってるんでしょう!?」
• マスター先生: 「...」
• マスター先生: 「刑事さん、わしゃあいつでも言っているでしょう...」
• マスター先生: 「わしのレビューにかなう、最高の品質のコードであれば、いつでもマージすると!!!」
• (マスター先生の気迫に、たじろぐ、かつての生徒と刑事)
• コーディング探偵: 「ふふっ、なるほど、そういうことでしたか。ならばそのブランチ、私が引き受けましょう！」

ピープルウェアを読んだ

この前id:hitode909くんからピープルウェアを貰ったので読んだ。非常に面白くて、興味深い話が多かった。

ピープルウエア 第3版

この本は、作者のトム・デマルコさんとティモシー・リスターさんが10年に及んだ調査と、自身のソフトウェア開発の経験をもとに、ソフトウェア開発における人に関する問題をたくさんのコラムを通じて教えてくれる。冒頭には以下のようにある。

実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである。

いろんなレイヤにおける人の問題についてそれぞれ章がわかれていて、個人からオフィスやチーム、さらには会社組織のはなしへと続く。結構マネージャー視点ぽいコラムが多い気がする。

以下、いくつか記憶にのこった部分をピックアップしてみた。

うまくいっているチーム、うまくいっていないチーム

21章 "全体は部分の和より大なり" によると、チームが結束し同じ目標を向くことできると、大きな力を出すことができるようになるという。チームが結束しはじめると、一体感がでてきて、よく一緒にご飯をたべにいったり、チームにしかわからない冗談を言い合ったりするし、他のチームとは違う選ばれたものだ、という雰囲気を醸し出したりするそうな。

バグを見つける喜びのもとに結束したすばらしいテストチームの例がおもしろかった。ありとあらゆる入力をプログラムに与えてはバグを見つけてはチームで大喜びして、プログラマを泣かしていたらしい。陰険なイメージを強調するためにチームメンバーは、みな黒い服を着てくるようになったそうで、そこからブラックチームと呼ばれていたそうな。彼らは独自の個性により結束した、社会的にうまくいっていたチームだった。最終的には、これまでに見つけられることのできなかった幾つものバグを発見することができたらしい。

自分も、確かにリリース時にクラッカーを鳴らすチームや、折にふれてお寿司の出前をとって慰労会を行うチームを見たことがある。たしかに、それらのチームは結束した良いチームであったように思うので、この話にはなんとなく納得感があっておもしろい。

また、結束したチームを作る簡単な方法はないが、台無しにする方法というのはあるらしく、23章 "チーム殺し、7つの秘訣"という章に書かれている。例えば、製品の品質削減を命じられる(例えば、雑でいいので急げと言われる)と、メンバーは自分たちの仕事に誇りをもてなくなり、結束は失われ、別のチームへの脱出を考え始めるとある。

人がやめないようにするという話

いくつかの章に、人が退職した場合におこる問題について言及されていた。客観的な視点で書かれていて良い。

19章 "ここにいるのが楽しい" では概算でも退職によってかかるコストは人件費の20%にあたるとあって明らかに無駄だと述べてる。また見えないコストとして、退職率の高い企業ではメンバーが長期的な視点を持てなくなるし、雰囲気が悪化して負のスパイラルに陥ってしまうことがあると書かれている。

逆に、退職率の低い企業では、メンバーは長期的な視点ができるようになる。長期的な視点のもとでは、組織をなるべく根本的に良くしようという力がはたらき、共通の方向性のもとで強く結束しやすく、より良い組織になることがあるらしい。

また、35章 "組織の学習能力" では、組織の経験をもとに、組織全体に技術を浸透させたり、組織を再編成したりといった、組織自体の学習能力について述べている。ここでも、"組織の学習能力は、どの程度人を引き止めておけるかで決まる"と書かれている。

さらに、退職率には目を背けがちだが、きちんと分析することで良い組織を目指せるというようなことも書いてあって、なるほどと言う感じ。

電話、電話、また電話

トム・デマルコさんはとりあえず電話がきらいで、電話が最悪だというだけの章(11章 "電話、電話、また電話")がある。電話が存在しないパラレルワールドに、とつぜんにグラハム・ベルがあらわれて電話のプレゼンをするんだけど、そんないつでも作業を中断してくる道具はいらないといって追い返してしまう。電話はたしかに異常で、人間同士が面と向かって会話していた時でも、ベルがなると電話のほうが優先されたりする。

フロー状態のエンジニアの作業を簡単に中断してしまってよくないので、電話をデスクにおかないか、電話をとらなくても良いという制度にすると良いとあった。

自分は、これまで電話のあるオフィスで働いたことがなくて、平和。

まとめ

ソフトウェア開発における人の問題について、漠然と感じていたことが言語化されて整理された良い本だった。具体的な例ものっていて納得感はあるし、読み物としてもおもしろいので、おすすめです。

ピープルウエア 第3版

Peopleware ちょっと読んだところ、1987年に書かれた本にもかかわらず、紹介されてるできごとが現代であるところの2014年でも起こりまくっていて、おもしろい。

— hakobe (@hakobe) 2014, 4月 7

Peopleware 曰く "結束したチームは健康的である。気軽に言葉をかけあい、自信に満ちていて、温かい。"

— hakobe (@hakobe) 2014, 4月 27

参考

• 「ピープルウェア」を読んだ - $shibayu36->blog;
• ピープルウェア - hitode909の日記

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

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

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

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

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

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

• id:kaiteki61 さん Kyoto.なんか(仮) でスピリチュアルっぽい話します - 快適な生活
• id:kiwanami さん MVCの先、状態管理、ジェスチャー
• id:yashigani_w さん Kyoto.なんかでWebKit APIについて話しました #kyotoasterisk - yashigani?.days
• id:iseebi さん Kyoto.なんか でお話ししました #kyotoasterisk - backyard of 伊勢的新常識
• id:stanaka さん mackerelについての発表
• id:hakurai さん Haxe
• id:Sixeight さん Kyoto.なんかで Atom について話しました - ちなみに
• id:yhara さん monolistについての発表
• id:aereal さん Kyoto.なんかで“Introduce browserify”という発表をした - Sexually Knowing
• id:nobuoka さん Java による Web アプリケーションのプロトタイプのために最近使っている構成 - えっちなのはいけないと思います
• id:moznion さん 「Kyoto.なんか」でgithub-commit-comment.vimの話をしました - その手の平は尻もつかめるさ

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

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

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

• Kyoto.なんか - hitode909の日記
• Kyoto.なんかでドラ娘しました - にゃんこにっき 銅鑼ありがとうございました

Kyoto.なんか pic.twitter.com/lFixuduTuL

— nagayama (@nagayama) 2014, 5月 3

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

ワイワイ出社 for Android

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

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

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

ワイワイ退社 http://t.co/L90cwi1XEJ

— hakobe (@hakobe) 2014, 4月 28

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

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

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

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

• 実装: Game.scala
• テスト: GameSpec.scala

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

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

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

意図的にメモリリークしてみたら、けっこうたくさんリークしててやばい。