読者です 読者をやめる 読者になる 読者になる

Coderetreat in KIT を開催しました

2014/05/31に金沢工業大学でCoderetreatを開催しました。

みんなで

今回は大学ということもあり、学生さんが多いと見込み、いつものCoderetreatとは異なる形で開催しました。 テーマは「楽しくプログラミング!」

想定していた以上に1,2年生の学生さんが多く、大丈夫か??と思ってたんですが、みなさん優秀でした。プログラミングの本を持ち込んでる子も多く、言語を学び、学んだことを生かしつつ次に行けたんじゃないでしょうか。学生さん、社会人の別け隔てなくプログラミング。みなさんほんとうに楽しそうに過ごせてよかったです。

当日の導入資料

工夫したこと

ライフゲーム以外の課題を用意した

ライフゲームって相当奥深い課題なので、あれはとてもいい課題なのだけど、取っ掛かりが相当大変で、プログラミングと言うのは難しいものだ、と思われてしまうと悲しい。ということで、初心者でも45分で解ける課題としてうるう年の判定を準備しました。また、ライフゲームだと、ルール自体は単純ですが、UIを作る部分が大変に思われがちです。ということで、実際はライフゲームよりも難しいボーリングスコア計算をチャレンジ課題として用意しました。

1年生同士がペアを組んだ時、どうにも解けなさそうであれば、自分が後ろに入り、デモをしてみたりアドバイスをしてみたりしていました。

ペアプログラミングのやり方を軽く解説

プログラミングに不慣れなペアで課題に取り組めばなんとかなるもの、という感じてほしい。ということで、いつもであれば「良いコードとはどんなコードか?」に重点を置いて始めるところを、「ペアプログラミングとはどんな感じでやるものか?」を簡単に紹介し、最初のセッションはペアプロになれるために「うるう年判定」をすべてのペアにやってもらいました。

ペアプロは3人でもできますよ、と言ったところ、3人で2ペア作り、将棋の二人指しみたいな強者もいましたが、最初のセッションがあったお陰でスムーズにプログラミングをやり始められたように思えました。

6セッションのところを5セッションにし、クロージングを最後に書いたコードをふりかえるセッションに。

一日中ペアプログラミングでコードを書き続けるのはなかなかハード。と言うことで、4セッション目以降、だらだらし始めたので、休憩を長めにとったり、6セッション目を諦めて、5セッション目を60分にして、クロージングにみんなにどういうコードを書いたのか、共有する時間にしてみました。

たぶん大学1年生の方たちは、人前で発表する経験はそんなになかったんじゃないかな。そういうことも含め、いい経験になったのではないでしょうか。

発表の様子

クロージングセッションの発表

セッションごとに書いてもらった付箋もこんなに

セッション毎に書いてもらった付箋

開催してみて感じたことをKPT

Keep

  • 大学でのCoderetreat
  • あまり捗っていないペアの間に入り、ファシリテーション
  • 軽く「オブジェクト指向とは、コードを分かりやすくするため、仕事を役割ごとに分離したり、概念を表現できるようにしたもの」と説明してみる。
  • 「犬」や「猫」に「鳴く()」なんてメソッドを定義したり、共通の親に「動物」って定義したりするなんていうオブジェクト指向をいずれ訳の分からない役立たずにしてしまう考え方は一切説明しない。
  • TDDやユニットテストを知らないペアのところでおもむろにやり始める。(ドヤァ)
  • ただドヤァはしたくてしてるわけではない。なんかわけのわからんことをデモされてるぞ?と、若人の好奇心をくすぐることが目的。目を輝かせていた方もいたようで、これはうまく行ったと思う。
  • ただし、「TDD」や「ユニットテスト」という単語は使わずに。昼食や終了後、参加者間での情報交換で話に出てきてくれるといいな。
  • 先生方を巻き込んだこと。講義(今は授業としか言わんのかな…。)にくる学生に声をかけてもらうことで、通常時にはなかなか足を運んでくれなさそうな、プログラミングには興味はあるけど次の一歩を踏み出せない方の背中を押せたと思います。
  • 最後に「俺とCoderetreat in KIT」というタイトルでLTをしてくださった加藤さん。加藤さん、マジ「俺と○○」というタイトルが似合いますね。
  • 大学の先生には面白い方が多いようで。私は大学には行っていないのでわかりませんでしたが、多種多様な経歴の方が集まるのが大学。今回も面白い先生が集まりました。
  • 1人でライフゲームを組みきって「ドヤァ」してくださった、中野先生ありがとうございました。
  • うるう年の判定なんて、「100で割り切れたらうるう年じゃない」とか「400で割り切れたらうるう年」とかは、そういうの組み込み機器に組み込んでも、組み込み機器の製品寿命はせいぜい10数年なので、バグになる可能性があるからいれない、と言い切ってくださった、西川先生ありがとうございました。
  • 河並先生のご尽力があってこそのCoderetreat in K.I.T. でした。本当にありがとうございました。

Problem

  • 申し込みの波が読めない。社会人を主なターゲットにしたCoderetreatを福井で開催した時は、2ヶ月前に募集を始めてやっと集まったくらいだった。今回もGWが明けた段階で12,3人の申し込みだったため、追い込みの意味で学内での募集を強化していただいたところ、それだけで20人集まってしまって、急遽増員することに。
  • 会場ではお菓子が食べられず、少し移動したところなら飲食OKという会場だったため、お菓子があまり気味に。おみやげができたのはいいけれど、この辺りの調整はほんとうに難しい。
  • 昼食中、スポンサーのスライドを連結して流していたけど、繰り返し流す方法がわからず手動で巻き戻す事に。こういう準備はほんと大事。
  • ホワイトボードに書いたハッシュタグがバグってた模様。
  • タスクの分担をうまくできてなかった。というか、タスクを見えるようにしてなかったので、周りに迷惑をかけてしまった。
  • 8:00受付8:30開始は参加者にもスタッフにも負担をかけてしまった模様。でもこればっかりは会場の都合もあるのでしょうがない。

Try

  • 社会人と学生と別々に申し込みを受け付けるようにする。
  • 会場の制約を考え、昼食とお菓子の量を考える。
  • スライドの流し方は前もって準備する
  • Trelloなどでタスク管理

ブログやスライドを書いてくださった方

Coderetreatの開催に興味がある方は、Qiitaにまとめてますので、参照してみてください。

http://qiita.com/search?utf8=%E2%9C%93&sort=&q=coderetreat

今回のスポンサー

スポンサーの皆様にはこんな感じでランチタイム終了後に会社説明をしていただきました。

永和システムマネジメント様発表

永和システムマネジメント様発表

金沢総合研究所様発表

金沢総合研究所様発表

株式会社KCC様発表

株式会社KCC様発表

スポンサー資料

株式会社永和システムマネジメント

永和システムマネジメント

株式会社金沢総合研究所

金沢総合研究所

株式会社KCC

永和システムマネジメント

金沢工業大学

金沢工業大学

株式会社チェンジビジョン

株式会社チェンジビジョン

Tracの変更をIdobataに通知するプラグイン

trac idobata

idobataがいい感じなので、作りました。

TracでのチケットやWikiの操作を行うと、下記のような形でIdobataに通知されます。

f:id:kompiro:20140316192008p:plain

ソースは https://github.com/kompiro/trac-idobata-plugin で公開してます。

デブサミ2014に参加した!(2日目)

デブサミ2014

続いて2日目のレポートです。

Team GeekによるFearless Change

資料: http://www.slideshare.net/kdmsnr/20140214-teamgeekfearlesschange

講演者の角さんは、Team GeekとFearless Changeの翻訳に携われた方。本当に様々な本を翻訳されている方で、リーダブルコードの翻訳もされました。

ちなみにリーダブルコードについても講演されています。

Fearless Changeは組織にアイデアを広める方法を48のパタンを使ってまとめられた本です。パタンを使ってまとめられたもので有名なのは、デザインパターンがあります。

@hyukiさんの定義によるち、大抵のパターンには、下記の4つの要素が含まれるそうです。

  • 文脈
  • 問題
  • 解決
  • 制約

パターンはそれぞれこれらの要素が関連しあっているので、全体象を記述する表記法がほしいです。それらしいものを今度書いてみようと思ってます。

越境する開発~あの日開発していたサービスの名前を僕たちはまだ知らない~

資料: 非公開

講演者の市谷さんこと@papandaはDevLOVE等で非常にお世話になっていたのですが、最後のデブサミと言っていたので、行かずにはおれませんでした。

市谷さんは基本的に資料は公開されるのですが、新たに自分のビジネスを立ち上げる事も含めてお話されたため、今回は非公開にされているようです。

ベースになっている話はこちらです。 http://www.slideshare.net/papanda/ss-28080078

非公開ということで、あんまり詳しく書けないですが良い話でした。

モーションセンサーの現状と2014年の予測

資料: http://www.slideshare.net/kaorun55/devsumi-201414c5

講演者は0日めのセンサー&デバイス祭りのオーガナイザーの @kaorun55 さんでした。裏番組が@kawagutiさんという、よくあるバッティングでした。ざんねん。で、Kinectに代表されるモーションセンサー以外にもOculus RiftというヘッドマウントディスプレーやリコーのTHETAという、360度撮れるカメラの紹介がありました。

このOculus Riftは、0日目のレポートにも書きましたが、ほんと素晴らしい没入感のディスプレーで、首を回す角度に合わせ、ディスプレイの可視領域も変わります。それが全天球全て対象に変わるため、THETAと組み合わせるとあたかもその場にいるかのような印象を受けます。これは正直、体験しないとわからないです。機会があればぜひ体験してください。

Kinect等のモーションセンサーデバイスもPCへの組み込みが始まっています。これまではデジタルサイネージに良く使われたモーションセンサーですが、わざわざアプリを使うためにこれらのデバイスを購入する人は稀ででした。既に組み込まれているのであれば、話は違います。そういったアプリが今後増えていくだろう、というのが2014年の予測でした。

ちなみにですが、こういったデバイスの補助アクセサリは、3Dプリンタで印刷できるデータで配布されることが増えているそうです。

その他面白かったデブサミの資料

デブサミの資料は、 http://codezine.jp/article/detail/7640 にまとめられています。 この中で面白そうな資料をピックアップします。

Play2/Scalaドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所

http://www.slideshare.net/sifue/developers-summit-2014-play2scalaweb

ドワンゴさんのサービス、ニコニコ生放送PHPからScalaに置き換えている際、ドメイン駆動設計をフル活用し、柔軟性、拡張性の高いシステムを構築しているという話です。

ドメイン駆動設計は、数年前から流行してますが、コード側にモデリングを寄せた設計手法ととらえてもいいと思います。1日目の方にちょいちょい書いていましたが、インフラ、テスト、モデリングそれぞれコード側に寄せ、集約するように発展してきたのが2000年代だったんじゃないかな、と思ってます。関連する技術を調べてまとめてみたいところ。

新卒エンジニア研修ですべきことできること

https://speakerdeck.com/ryopeko/devsumi2014-dena-bootcamp2014

DeNAの新卒エンジニア研修の話です。Twitterでとても良かった、と評判だったので、共有します。

最後に

デブサミのオーガナイザー(代表責任者)の@iwakiriさんこと岩切さんは、後継者を育てるため、今年のデブサミを最後にオーガナイザーから退くそうです。デブサミは今年で12回目で、岩切さんはデブサミの立ち上げから一貫してオーガナイザーを続けられていました。

岩切さんがデブサミを始めたのは35歳の時で、35歳定年説なんて嘘だ!と主張されていましたが、今回のデブサミは前夜祭を含め、本当に面白いセッションが多く有意義に過ごすことができました。

岩切さんがデブサミを始める時、会社からデブサミのようなイベントができないか相談され、また仲間から背中を押されていたのですが、一週間ほど悩んで決めたそうです。

僕は今32歳なのですが、35歳になるまでに、そういう風に仲間に背中を押されて新しい事を始められる人になれるよう、頑張ります!

デブサミ2014に参加した!(1日目)

デブサミ2014

ということで、引き続き1日目のレポートです。

サーバプロビジョニングのこれまでとこれから

資料: https://speakerdeck.com/mizzy/future-of-server-provisioning-at-developers-summit-2014

2013年に非常に流行し、発展した技術は、VagrantやPacker、Chef、Docker、serverspec等、数ステップで予め設定したサーバーを立ち上げ、検証できるツールです。このセッションはserverspecを開発しているpaperboy&co.宮下さんのお話でした。

それぞれどんなツールか簡単に紹介すると、

Vagrant

仮想マシンを簡単に作成、管理するツール。各OSをインストールしたイメージを作成しておき、再利用できるツール。プラグイン機構を持ち、VirtualBoxだけでなく、VMWareやEC2、さくらクラウドや後述するDockerに仮想マシンを作成できる。

Packer

仮想マシンのひな形を作成するツール。各OSのインストール、セットアップを自動化するツール。JSONで設定値を書いて実行。VirtualBoxを使って試したところ、キーボード入力なども自動で行ってくれました。過去veeweeというツールもありましたが、Packerの作者はVagrantの作者と同じ方なので、こちらがメインになりつつある。

Docker

Linux上に別のLinux仮想マシンを立ち上げるLXCという技術をベースに、より利用しやすくしたツール。

Chef

ミドルウェアのセットアップをcookbookという形式でセットアップできるツール。cookbookはRubyスクリプトで書く。

serverspec

仮想マシンのテストをできるツール。設定が壊れていないか、テストで繰り返し検証できることや、同一の設定のサーバーを一度に展開した時に、自動的に確認できる。

こんな感じのツールが雨後の竹の子のように生まれ、流行したのが、2013年でした。(間違ってたらコメントを頂けるとうれしいです。)

実際は2013年よりも前からこういったツールがあり、AWSの流行と共により使われるようになり、流行し始めたようです。この流行の流れで、Infrastructure as Codeとか、Immutable Infrastructure とか、 Disposable Component といった言葉が生まれました。インフラを作るのもコードで済むようになり、既存のサーバーの設定をいじくるのではなく、コードを変更して、新たにサーバーを作成し、ロードバランサーの設定を変更することで接続先を変更する、と言った辺りを表現したのがこれらの言葉です。

インフラ周りのセットアップがコードに寄せられると、バージョン管理とかもしやすくなるので、便利ですよね!

テスト自動化を見直そう!自動化への投資が開発チームをクリエイティブにする

資料: 非公開 (代わりにtogetter http://togetter.com/li/628619 )

このセッションはランチセッションでした。いつの間にか、デブサミでも昼ごはんが提供されるようになってました。このセッションは、静的解析ツールベンダーのコベリティさんの中で行われているテスト自動化の取り組みの発表でした。

コベリティさんは、6ヶ月ごとのリリースサイクル、3ヶ月毎に次期リリース計画を練り直し、リリース直前のテストに6週間。スクラムで回しています。サポートするプラットフォームは非常に多く、215の仮想マシンインスタンス上でテストをしています。これだけのサポートプラットフォームを人力でテストすることの方が非効率なため、数年前からテスト自動化に投資し、現在はSelenium(ブラウザテスト自動化ツール)で3000以上のテストケースを自動実行しています。

とはいえ、テスト自動化を行うにもスキルが必要です。一年目は外注した事で失敗したので、現在は社内に専門のチームを設けているそうです。

別のセッションでDeNAのテストチームの話( http://www.slideshare.net/masaki/test-engineering-on-mobage )を聞いたのですが、DeNAも専門のチームがあり、MSやGoogleもそういった部署があります。また、楽天にいる友人は、社内にTDD(ユニットテスト)の文化を根付かせる部隊で仕事をしているそうです。テストの自動化には相応のコストがかかるのですが、大きな会社では自動化に投資を始めています。

スマホアプリのテストも、Seleniumと同一のAPIで実行ができるAppiumというライブラリが出てきています。(Seleniumの開発者がスマホ向けに開発を始めたのがAppiumです。)Seleniumのユーザーグループもできたそうです。

こういった流れを見てみると、2014年は、テストケース自体の管理を、インフラ同様、よりコードの方に寄せていきそうな印象を受けました。

何故クックパッドのサービス開発は日々進化しているのか

資料: https://speakerdeck.com/yoshiori/how-we-cook-cookpad-dot-com

2年ほど前にドワンゴからクックパッドに転職した庄司嘉織(通称@yoshiori)さんの講演です。一言で言うと、クックパッドの文化の話でした。

クックパッドでは、ユーザーに向いた仕事をする事を全社員に課せられており、クックパッドのエンジニアは、社外で講演したり、成果を公開することが義務付けられています。それが人事評価の指標にもなっており、今まで講演してきた資料は、会社サイトにまとめられ、公開されてます。 (これを作成するスクリプトGitHubで公開されています。 https://github.com/cookpad/presentations )

クックパッドでは、ユーザーサポートの管理もGitHubのIssueで行っています。これによりエンジニアとしては、どういう内容が今サポートに来ているのか把握でき、サポートとしては、ユーザーサポートで必要になったコードの変更などの進捗も、コメントで見えるようになったそうです。

そういった取り組みを始めたのがヨシオリさんで、30分程度サポートの人に、GitHubの使い方やMarkdownの書き方(GitHubWiki記法)を伝えたらサポートの人もGitHubを使えるようになったそうです。それができたのも、サポートの人もユーザーに向いた仕事をすることが求められているため、GitHubを使うことでよりエンジニアと密にコミュニケーションが取れ、よりよい仕事ができるのなら新しいツールを覚えることに抵抗がないという、「文化」があればこそできたことだろう、と言う話でした。

その他にも、クックパッドのシステムは1000以上のモデル(テーブル)を持つシステムですが、2ヶ月で50以上新たにモデルが追加されるなど、活発に開発が行われています。基本的にmasterの内容をGitHubにpushするとそのままシステムにデプロイされるため、 日に多い時は10回システムの更新が行われます。システムの更新時には当然CIが走り、壊れていない事を検証します。今、クックパッドのシステムには16000件以上のテストケースがあるので、毎回16000件のテストが実行されます。この16000件を超えるテストケースの実行を10分以内に終えるために専門のチームがあるそうです。デプロイの早さがシステムの更新回数に影響するため、10分以内に終える事を目指しているのだと思います。

1日目の終わりにはアンオフィシャルパーティーがありました。会場の隣はアマゾンジャパンの本社があり、そこの2階で開催されました。アマゾンジャパンの玉川さんにお話を伺う機会がありました。

アマゾンの文化は、Work Hard, Have Fun, Make History というスローガンに現されるとおり、まず「一生懸命働く事」が第一だ、と笑っていらっしゃいましたが、僕は、ユーザーにとって何が一番いいか、ということに向けて一生懸命に働く文化がある、という風に感じました。そのため、特にAWSを利用しているユーザーと共に必要な機能を考え、優先度付けをする会議を設けたりしているそうです。 これから作るツールはどうあるべきか、二日目に考えた事があるので、二日目のレポートにまとめます。

デブサミ2014に参加した!(0日目:センサー&デバイス祭り)

デブサミ2014

デブサミ2014に参加した目的

福井に引っ越してきてそろそろ3年。そして、今年で社会人になり10年が経とうとしてます。福井に引っ越す前に携わっていた翻訳書の出版の話がなくなり、同時期に翻訳を始めていた仲間の翻訳書であるFearless Changeが無事形になるなど、自分のキャリアを考える事がありました。このまま淡々と福井で開発をしていていいのか?と、迷いが出てきてました。そこで Business Model You のワークをやってみたりして、自分の強みが何で、どういう価値があって、それがどう人に役に立つのか、考えてみようと思って、やってみたりしました。こういうワークは独りでやってても効果がないのか、あまり霧が晴れるような効果はなかったんですが。

ビジネスモデルYOU

ビジネスモデルYOU

丁度そんなタイミングでデブサミが開催されるという事を思い出し、開催の大体10日前に急遽デブサミに参加することに決め、上司に休みをもらい、コーヒースポンサーに申し込んで行ってきました。(コーヒースポンサーについては後述します。) 本来ならばデブサミは、予めセッションを申し込む必要があるのですが、コーヒースポンサーのお陰で飛び込みでセッションを聞く事ができるようになりました。コーヒースポンサーは、非常に良い制度だと思います。 @iwakiri さんありがとうございます。

デブサミには東京に住んでいたころの仲間がいます。Fearless Changeの日本語訳の監訳者の@kawaguti さんや、 shibuya.tracとかでよく会っていて、最近はKinectなどセンサーデバイスを使ったアプリ開発の本を書いている @kaorun55 さんに会いたいと思ったのです。

コーヒースポンサーというウルトラな制度

コーヒースポンサーは、スピーカーの皆さんにコーヒーを提供したい、という @iwakiri さんの思いが実現したものですが、スポンサーになった時の特典がすごいです。

こんな感じで超お得!コーヒースポンサーになるには協賛金1万円が必要ですが、それだけの価値が十分にありました。

0日目:センサー&デバイス祭り

今回のデブサミは、@kaorun55 さんの企画で前夜祭、「センサー&デバイス祭り」が開催されました。 @kaorun55 は今年もセッションを持ち込んでたり、精力的に活躍してるからすごいです。「センサー&デバイス祭り」は、体験型のデモが中心だと思い込んでいましたが、セッションもありました。「うげ。申し込んでいない」と思いましたが、会場に行くと、コーヒースポンサーの力なのか、中にいれていただけました。マジごいす。

センサー&デバイス祭りでは、KinectPerCなど、カメラデバイスとセンサーを使ったアプリや、Oculus RiftというVRを追求したヘッドマウントディスプレイなんかがデモされていました。Oculus Riftは頭の動きに合わせて映像も調整してくれたりするんですが、これは体験しないと凄さがわかりません。機会があったらぜひ体験すべきです。そんなに高くないから欲しい。製品版はよ!

で、特に面白かったのは、このレポートにもある、しくみデザインのデザイナー兼社長の中村氏とエンジニア中茂氏の「日本的キモチイイインタラクションは、世界に通じるコンテンツ!テクノロジーに縛られるな!」と題した講演でした。

http://codezine.jp/article/detail/7637

Kagura for PerCのデモ http://www.youtube.com/watch?v=gEt8e701w-c

中茂さんの「プログラマーにとって楽しいのは、美しいコードを書いたり、よいアルゴリズムを書いて高速化したりといった部分だと思うが、それらは大抵ユーザーには伝わらず、さも当然のものとしてその上が求められる。アルゴリズムなどの部分はチャチャッと済ませてしまい、本当にこだわるべき部分にきちんとリソースを費やすことが大事」という言葉に、同じプログラマとして深く共感しました。

しくみデザインさんのビジネスはデジタル広告が主戦場です。お客さんが楽しむ事で、そのコンテンツが記憶に残り、来客効果を上げ、ユーザーのビジネスに貢献するのが仕事です。

「すごいは1度だけ、楽しいは何度でも」ということをスローガンに、

  • とにかく単純に
  • 音をちゃんと作る
  • 失敗自体存在させない
  • 正確さより曖昧さを活かす
  • テクノロジーを感じさせない

広告を作っているそうです。

その他のセッションの中でも面白かったのは、落合陽一さんの、情報の流れの話です。どういうことかというと、20世紀はコンピュータの発展に伴い、情報が「現実→仮想」に流れていたのが、21世紀になると「仮想→現実」に情報が流れている、という話でした。(落合さんが開発されているディスプレイの話は、イマイチよくわからなかったですが、ホリエモンとのインタビュー記事を読むと理解が進みました。)

Tokyo MotionControl Networkすごい

@kaorun55 さんも所属するTokyo MotionControl Networkがセンサー&デバイス祭りの共催でした。このコミュニティの面白いところは、参加者の中にミュージシャンや声優など、モーションコントロールを使って面白い事をしたいユーザーまで巻き込んでいるところです。開発者だけだとニッチな方面に行き過ぎるのですが、実際に「使いたい!」と思うユーザーを巻き込んでいるところが素晴らしいです。

ということで、0日目のレポートはこのへんで。

Global Day of Coderetreat 2013 - Fukui, Japan を開催しました。

2013/12/14にGlobal Day of Coderetreat 2013が世界中で開催されました。今回、福井から初めてGlobal版に参戦しました!

f:id:kompiro:20131224222620j:plain

丁度1年前、 @haradakiro さんからGlobal Day of Coderetreatの開催の報を聞き、福井で開催できないか調整してきました。しかし、2週間の準備期間では間に合わず、今年の2月に福井で初めて開催しました。その時も盛り上がりましたが、今回も大変盛り上がりました!参加者の方がレポートを書いてくださったのでまとめました。

参加者の方のレポートまとめ

id:pobo380さんのレポート
りりぃさんのレポート

こういうレポートを書いてくださると、『やってよかった!』ととても励みになりますね!誠にありがとうございます!

さて、私は主催なので、ファシリテーターとして参加全体の流れの仕切り等をやらせていただきましたが、いくつかのセッションは参加者として取り組みました。最初は見学だけのつもりで途中で帰る若いエンジニアもいたので、主に課題に対しどう取り組むか、実演するためでした。しかし、やってみると他の方とも取り組みたくなり、逆に色々と学ばせていただくことになりました。

1人KPTを記録しておきましょう。

Keep
  • 無事に開催できた
  • 若いエンジニアの方が多数参加された
  • 今回は金沢からの参加者が特に多かった
  • テストコードを書くことの価値を共有できた
  • Java/Ruby/C#/Pythonの書ける開発者が集まったことで、異なるプログラミング言語環境との交流を産む刺激があった
  • サインペンや付箋などを十分に準備できていた
  • テストコードを書く練習場としてとてもうまく機能していた
  • 参加者の意識を「ライフゲームの完成」から「より良い設計」により向けられていた
  • GDCRの事務局本部の連絡が的確で文章化もとても行われていたので、スライド等の準備は非常にスムーズに行えた
    Problem
  • Global版という事で、ハングアウトを準備してみたが、当日のスケジュールの伝達不足であまりやりとりができなかった
  • live.coderetreat.orgの更新をすっかり忘れていた
  • 少人数で運営する事に無理があり、舞台裏では各所に迷惑をかけてしまった。いつもK氏には頭が上がらない
  • 遠方からいらしたシニアエンジニアの方がいらしゃったので、ご飯を食べに行きたかったが家庭の事情で実現できなかった
  • ふりかえりで付箋を貼ってもらっていたが、徐々に張り出す枚数が減っていた。
  • 参加者の負荷が少なかったかもしれない。今回はping-pong(ぶつかり稽古)のみだったが、Baby StepやSCMとの組み合わせなど、もうちょっと負荷をかける取り組みを追加してもいいかも。
  • 東京がGDCRに参加していないなど、会場が神戸、大阪、福井とちょっと寂しい感じになっていた
    Try
  • スタッフ/ファシリテーターを募集する
  • GDCR以外での金沢での開催(2月か3月)
  • 深く知らない言語環境について知る良い機会のため、できるだけたくさんのプログラミング言語が登場する会にしたい(scalaやJavaScriptHaskell等)
  • ぺんてるのサインペンと3Mの付箋の手配を怠らない
  • 休憩も兼ねて、参加者に他のペアのペアプロを促進するようなファシリテーターを勧めてみる
  • ファシリテーターはセッションへの参加は積極的に行わないようにして、ふりかえり等で参加者にもっと考えてもらうようにする
  • 8月くらいから他に参加したい会場がないか呼びかけてみる
  • TDD as you meant it をやってみる。

効率よくデバッグする方法

Eclipseデバッガを活用する31のTipsにたくさんのはてブがつきました。たくさんの方に見ていただけたようで、とてもうれしいです。どうもありがとうございました。
デバッガの使い方のスライドを作ってみたものの、効率良くデバッグする方法については書いていませんでした。例えば、ブレークポイントをどこに貼ると効率が良いのか、教えてほしいという声がありました。デバッガ機能をどう使うとより効率的にデバッグできるのか、考えてみました。

デバッグにおける2つのポイント

突然ですが、僕は、デバッグには下記の2つのポイントがあると考えてます。

  • 障害の再現方法を調査する。
  • ソフトウェアの内部状態を調査する。

みなさんはどうやってデバッグしていますか?僕がデバッグを行う時の流れを書いてみると、

  1. 報告された情報を元に、障害がどうやって起きるのか、再現方法を確認します。
  2. 再現方法が報告されていない場合は、再現方法を調査します。
  3. ソフトウェアの内部状態が障害発生時にどうなっているか把握するため、再現方法の調査中、変数などソフトウェアの内部状態も観察します。
  4. 再現方法と障害発生時の内部状態がわかれば、障害が起きる内部状態にならないよう、ソースコードを修正します。
  5. 再現手順を実施して障害が修正されている事を確認します。
  6. 障害の修正により、デグレードが起きていないかを簡単に確認します。

こんな感じでデバッグを行っています。

「障害の再現方法」と「ソフトウェアの内部状態」をデバッグのポイントとして上げたのは、デバッガとは、これらのポイントの調査を支援するものだからです。それぞれについて、どんな機能があるか、少しTipsをふりかえってみましょう。

障害の再現方法を調査するための機能

僕は、デバッガを知る前は、何度も何度も繰り返し操作し、再現する操作を調査していました。しかし、デバッガの機能を使うと、繰り返し操作しなくてもデバッグできるようにします。

例えば…
変数ビューでの値書き換えられます。
f:id:kompiro:20131013191415p:plainf:id:kompiro:20131013191414p:plain

表示ビューから例外をthrowできます。手元にソースコードがないクラスの中で例外が起きていて、その再現が難しい場合とかに重宝します。
f:id:kompiro:20131013200812p:plain

Drop to Framef:id:kompiro:20131013191339p:plainを使うと実行状態を破棄できるので、何度でも繰り返し実行できます。(※インスタンス変数や
ローカル変数は元に戻りますが、クラス変数など元に戻らないものもあることに注意)
f:id:kompiro:20131013191340p:plain

ソフトウェアの内部状態を調査するための機能

僕がデバッガを知らない頃は、標準出力に変数の値を出力して内部状態を確認してました。
標準出力に変数を出力するなど、デバッグソースコードを書き換えてしまうと、そのままコミットしてしまう事もあるでしょう。
デバッグ情報がコンソールに出力され、意図せずに内部状態が見えてしまう状態は良いものではないですよね。
しかし、デバッガを使えば、ソースコードを書き換えずに内部状態を調査できます。

例えば…
変数ビューでは変数の値が見られます。
f:id:kompiro:20131013191422p:plain

式ビューでは、各オブジェクトのメソッドの実行結果を監視できます。
f:id:kompiro:20131013191343p:plain

コードの上の変数も、実行中であれば選択してInspectできます。
f:id:kompiro:20131013191424p:plain

表示ビューではデバッグ中のプロセスに対し、コードを書くことで状態をInspectできます。
f:id:kompiro:20131013203119p:plain

こうしてみると、デバッガの機能の多くは、これらの2つのポイントを調査するためのものだとわかると思います。

得られている情報による障害の分類と、効率的なデバッグ

さて、報告された障害は、得られている情報によりいくつかの状態に分類できます。

  • 再現手順が報告されていて、その通りに実施すると障害を再現できる
  • 再現手順が報告されているが、その通りに実施しても障害を再現できない
  • 再現手順は不明だが、スタックトレースなどで例外が発生する箇所がわかっている
  • 再現手順は不明だが、再現しそうなコードの箇所を推測できている
  • 再現手順は不明の上、どこでその処理が行われているかよく分からない
  • 障害が報告されているが、再現手順が不明で報告されており、調査してみたが原因が推測できない

それぞれどうやってデバッグするでしょうか。順に見て行きましょう。

再現手順が報告されていて、その通りに実施すると障害を再現できる場合

障害の再現手順が明確にわかっていて、その通りに実施したら障害を再現できる場合、障害が起きているコードの場所がわかればかなりの確率で解決できるでしょう。最近は、障害報告に動画が使われる事もありますが、動画で報告されている場合は、この分類に入るでしょう。
この場合、予めログなどを埋め込み、どの処理が呼び出されているかわかるようにしておけば、呼び出される処理の場所にブレークポイントを貼り付けられるので、障害が発生する箇所の特定にそれほど時間をかけずに済むでしょう。

再現手順が報告されていて、その通りに実施しても障害を再現できない場合

再現手順の通りに実施しても障害を再現できない場合は、

  • 実行環境が違う(OSやブラウザ、バージョン、環境変数など)
  • 再現手順を実施する前処理が足りていない
  • 再現手順が漏れている

など、障害を再現できない要因がいくつか考えられます。例えば、

  • 報告者と実行環境が異なる事が明確な場合、実行環境をできるだけ揃えてみる
  • 前処理として書かれている項目の手順が不明瞭な場合、前処理が足りていない事を疑う
  • 再現手順を実施してみると、実際は操作できない手順があるなど、手順が怪しい場合は手順の漏れを疑う

等々が考えられます。それでも再現できない場合は、現象と再現手順が報告されていることを意識しながら、再現手順を実施した時に呼び出されるソースコードを読んでみましょう。障害の原因を推測できる場合があります。障害の原因が推測できれば、その周辺にブレークポイントを貼り、デバッガを開始します。障害が起きそうな内部状態にならないか、観察しましょう。特に実行環境が異なる場合など、デバッグしづらい場合は、内部状態を書き換えて再現しないか、試してみてください。

再現手順は不明だが、スタックトレースなどで例外が発生する箇所がわかっている

再現手順が不明の場合、本当にその障害があるのか、確認できていません。そういう意味では、修正しないでも良さそうなものです。しかし、スタックトレースなどで例外が発生している事が判明している場合、それは障害が発生した証拠が残っている事なので、速やかに調査を始め、修正を試みましょう。

例外が発生する箇所がわかっている場合、例外が発生した箇所周辺に原因があることを特定できているといえます。そのため、その周辺コードを読み、どういう状態で例外が起こるか推測し、例外が発生する箇所の周辺にブレークポイントを貼るか、例外自体にブレークポイントを貼り、その処理が呼び出される操作を行い、デバッガを使って例外が再現する内部状態をシミュレートしてみます。意図した通り例外が発生するのであれば、そういう内部状態にならないようにガードするなど、コードを修正しましょう。

再現手順は不明だが、再現しそうなコードの箇所を推測できている

再現手順は不明でも、障害の内容から、再現しそうなコードの箇所が推測できている場合があります。この場合も調査してみるべきでしょう。
障害の内容から再現しそうなコードの箇所が推測できてるのであれば、デバッガを使って障害が発生する内部状態を再現してみます。そして、内部状態を再現して障害が発生するのであれば、その内部状態が発生しそうな手順を推測し、再現するか試します。障害が再現するのであれば、その内部状態にならないように修正しましょう。

再現手順が不明の上、どこでその処理が行われているかよく分からない

障害の内容を見て、どこでその処理が行われているか推測できない場合は、その処理が行われている場所がどの辺りなのか、チームの他のメンバーに聞いてみましょう。チームに話してみて、推測できない場合は、再現不能として障害の修正を諦めるべきかもしれません。

障害が報告されているが、再現手順が不明で報告されており、調査してみたが原因が推測できない

障害を調査してみても原因が推測できない場合、チームの他のメンバーに調査を引き継いでもらいましょう。他のメンバーが引き継げるよう、チケットなど障害を管理しているシステムに、調査した内容を追記し、調査を代わってもらいます。
調査した内容をまとめてみると、コードと障害の理解が深まり、原因に気づく事もあります。他のメンバーに引き継いでもらった場合も、自分では気づかなかったことに気づくかもしれません。

忘れてはならない大事な事

障害を修正すると、デグレードを起こすリスクがあることを忘れないでください。障害の影響が軽微なのに修正による影響が広範囲に及びそうな場合は、チームに相談しましょう。場合によっては障害を修正しない、という判断になるかもしれません。
また、修正内容が心配な場合、チームメンバーにレビューを依頼する勇気を持ちましょう。

最後に、そもそも論でデバッガを使ったデバッグを考えてみると・・・

ただ、そもそも論で考えると、デバッガを使ったデバッグは、案外負けパターンなのかもしれません。
と言うのも、最初に書きましたがデバッガでできることは、内部状態の調査と障害の再現の2つです。これらはxUnit等のテスティングフレームワークとテストコードを用意する事で、素早く実施することができます。
テスティングフレームワークを使って十分に検証されていれば、どういう操作が行われた時に状態がどうなるのか、テストコードから内部状態を推測できます。また、デバッガを使ったデバッグよりもテスティングフレームワークを使った方が、短い時間で再現を確認できるでしょう。そして、テストコードで検証しているレベルでデグレードの発生が確認できるのもメリットです。

テスティングフレームワークとテストコードはとても便利なツールです。しかし、テストコードをただ書くだけでは、時間を費やす事が多く、効果を上げられません。テストコードを書くにも、スキルが入ります。このスキルは、上達させる事ができるものです。効果的にテストコードを書くにはどうすればよいでしょうか?それはまた、別の機会に。