legoboku.jp

「4時間で学ぶ、効率的な自動テストスクリプトのメンテナンス」は実践的で良い教材ですね

2014-05-03T14:01:00.004+09:00

STAR（Software Testing Automation Reserch; テスト自動化研究会）の方々が作成・公開されている「4時間で学ぶ、効率的な自動テストスクリプトのメンテナンス」をやってみました。確かに4時間くらいでできます。

この教材の内容はサイトに書いてある通りです。

オープンソースのブラウザテストツール「Selenium WebDriver」の使い方と、テストスクリプトを効率よくメンテナンスする方法について、実際にプログラムを書きながら学べるチュートリアル形式教材です。

日本語かつ無料で提供されているSelenium WebDriverのチュートリアルとしては一番実践的かつ分かりやすいと思います。

ひと通りやってみて感じた良い点は以下の通り。

演習で必要な環境はひと通り提供されます。自分で用意するのはJava、Eclipse、Chromeです。
演習で必要になるSeleniumの機能はひと通り最初の解説で説明されています。他のドキュメントなどは参照する必要がありません。
例（ホテルの予約）が具体的です。
タイトルにメンテナンスとある通り、メンテナンス性を向上するため、ページオブジェクトパターンが解説されています。実際にテスト対象が変更された場合にテストコードを修正する例もついてきます。

これはこれで十分だと思いますが、さらに追加して欲しい点としては、複数ブラウザ対応の実現方法を盛り込むことでしょうか。

Stanform大学のDBコース、半分くらい終わりました

2014-02-17T15:18:00.004+09:00

Stanford大学のオンラインコースを使って主にRDBを勉強しています。慣れてきたので、だいたいどういうものか紹介をしておきます。コースが修了できたら、また報告しますね。

DBコースを受講したわけ

最近まで、仕事では直接DBを触る機会が少なかったのですが、昨年の10月から海外勤務になり、業務内容が全面的にDBを扱う仕事に大きく変わったため、Stanford大学のオンラインコースを使って主にRDBを勉強しています。

元々は、何かオンラインのコースを取りたいなと思っていて、分野として候補がいくつかある中、丁度良いタイミングで始まったのがDBだったので、コレを選んだ次第です。

DBコースの内容

内容は以下の様な感じ。

Relational Database Overview
XML Data
JSON Data
Relational Algebra
SQL
Relational Design Theory
Querying XML
Unified Modeling Language
Indexes
Transactions
Constraints and Triggers
Views
Authorization
Recursion
Online Analytical Programming
NoSQL Systems

期待通り、SQLやテーブル設計などRDBの内容が中心ですが、XMLやJSONなども含まれています。

受講の仕方

基本的に開講と同時に全教材が開放されて、どこから進めても良い形式になっているようです。ただし、提出期限は上から順番になっているので、上からやった方が良いと思います。

各項目に対して進め方は各項目に対して以下を繰り返す感じです。

講師の説明ビデオを聞く
簡単な4択のクイズに答える（得点なし）
基本問題

選択問題（小得点）
実際にクエリを書く問題（中得点）

チャレンジ問題

実際にクエリを書く問題（高得点）

コースの修了について

基本的には回答を提出して自動採点する仕組みになっています。そして、回答を提出するたびに現在の修了状況が採点されます。基本問題をひと通り解けば、50%は完了し、コースは修了できるようです。もし良い成績を残したければ、チャレンジ問題にも挑戦した方が良いです。

教材が英語だけど大丈夫？

私の場合、今、日本人がいない職場にいて、英語で仕事しているので、英語のコースを受講する分は特に問題はありません。

ただし、まだ知識が浅い内容に対して、若干、早口で講義が行われると、ちょっとつらくなって何度も聞き直す必要があったりします。結局は、基本問題を解きながら、具体的な物を見つつ、教材を読み直して理解するという流れになりがちです＾＾；　また、それでもよく分からない場合は、今回は日本語の教材がネット上に転がっているので、必要に応じてGoogleで調べながらやっています。

英語のヒアリングが苦手な人にはちょっときついかもしれません。

負荷について

内容や自分の知識レベルにもよるのでしょうが、コースを修了したい人は週3〜4時間、良い成績を残したい人は週7〜8時間くらいかけないとダメなようで、フルタイムの人なら同時期に1コースが限度だと思います。

進め方の工夫について

開講と同時に全教材と締め切りが公開されますので、それに合わせてプライベートの予定を含めて、スケジュールを組んでおくことをおすすめします。難しい問題で手こずる可能性がありますので、常に締め切りより1週間程度は前倒しで進めましょう。

また、チャレンジ問題は締め切りが後になっているので、ついつい後回しにしてしまいがちですが、スケジュールの余裕があるかぎりは、基本問題をやった後に、早めに手を付けた方が良いと思います。

ということで、今回は中間報告です。無事に修了できたら、再度ブログ上でレポートを書きますね。

CodezineのSeleniumチュートリアルをやっています

2014-02-17T14:51:00.003+09:00

今の勤務先の業務に、Seleniumを使ったテストが予定されているので、実務でやる前に、自分でもSeleniumによるテスト自動化を体験しておこうと思ってチュートリアルで学習しています。

やっているのは以下の連載の第2回。

WebDriverの採用で生まれ変わったOSSのブラウザテストツール「Selenium2」入門第2回：「Selenium2」のインストール手順と初めの一歩

内容は以下の通り、簡単なサンプルを使って、Selenium IDEとSelenium Web Driverの基礎の基礎を学べる良記事です。

環境設定

Selenium IDEのインストール
Selenium Web Driverのインストール（Javaライブラリ、ドライバの両方）

Selenium IDEでブラウザ操作の記録、JUnitテストコードのエキスポート
Selenium Web Driverでテストコードの実行

これの次は以下を試す予定です。

WebDriverの採用で生まれ変わったOSSのブラウザテストツール「Selenium2」入門第4回：実践！ PageObjectパターンによる「Selenium2」テストケース改善チュートリアル

PageObjectパターンは、Selenium開発者の間で推奨されているデザインパターンです。テスト対象のWebページに対して、直接、Selenium Web Driver APIを使った低レベルなコードを書くのではなく、テスト対象のWebページの外部仕様を表現するクラスを用意し、そのクラスに対してテストコードを書くやり方です。コレをやるとテストコードがすっきりして、良いテストが書けるようになります。

このチュートリアルのあとは、一旦、所属チームの方針で決められているテスティングフレームワーク TestNG の勉強を「TestNG Beginner's Guide 」でやって、本格的なSeleniumの勉強を「Selenium Testing Tools Cookbook 」でやろうと思います。

【読書】海賊と呼ばれた男

2014-01-23T13:52:00.003+09:00

2013年の本屋大賞というポップが目立っていて気になっていた「海賊とよばれた男上」「海賊とよばれた男下」を読みました。どうも文庫も出ていないそうで、やや高いので、サンフランシスコのジャパンタウンにて会員割引10％で購入！

著者は百田直樹さん、最近ヒットしているらしい映画「永遠の0」の原作者の方です。内容は出光興産の創業者・出光佐三をモデルにした歴史・経済・成り上がり・青春小説です。上下巻あり、かなり長いですが、非常に読みやすく、テンポも良い小説であっという間に読んでしまいました。

いちおうフィクションらしいのですが、かなり史実に忠実に書かれているとのこと。祖父母の世代は日章丸事件というとかなり有名だそうですが、ちょっと世代的にあまりよく知りません＾＾；

出光佐三氏は太平洋戦争前に生まれ、大八車で小麦を運び、手売りする商売から始め、アメリカで需要が出始めた石油に着目し、戦後の復興期に国内への石油の供給で貢献した方のようです。

戦前・戦中・戦後と、業界のルールを無視したとしても、石油事業を通じて日本の繁栄を常に目指してきたことで、戦中までは同業他社にいじめぬかれ、戦後は石油メジャーにやられほうだいだったようです。

しかし、戦後、石油メジャーによる日本市場の支配に対抗するため、当時、元宗主国である英国と石油利権で抗争中であったイランの国有会社と石油販売の契約を結んだことで、石油メジャーとは敵対関係になったものの、日本のエネルギー安全保証と会社の業績の面で大変な功績を上げ、世界的に名を轟かせたそうです。

小説を通して感じるのは、出光佐三（小説中は国岡鋳造）の一本スジの通った人生哲学、目先の商売ではなく日本の繁栄を常に考えた行動、そして戦後の反映を支えた当日の日本人達の謙虚さ・ひたむきさ・辛抱強さでしょうか。私自身は戦後40年近く立って生まれた人間であり、彼らのような強さは微塵もないですが。。記憶の中にある大正生まれの祖父母の人間性を小説の中に見た思いでした。

そのうち、この小説も映像化されるのかな〜。そしたら見てみたいです。

【読書】SONYとマッキンゼーとDeNAとシリコンバレーで学んだグローバル・リーダーの流儀

2014-01-05T16:30:00.001+09:00

日本のベンチャー企業がシリコンバレーの企業を買収し、米国市場、ならびに世界での成功を目指す過程が物語形式と客観的な解説の組み合わせで進行します。章ごとに、日本と欧米企業の労働観や組織観の違いから発生する具体的な軋轢を紹介し、両者の違いを分かりやすく解説した上で、それを乗り越えていく過程を示しています。

著者の考えとして、欧米企業のやり方を過度に礼賛するわけでもなく、我々日本人の特性を活かしながら海外企業とうまくやっていく方法を考えることを提案している点は好感が持てます。著者によるとソニーの創業者盛田氏が著者の理想とするグローバル・リーダーのようです。

近年、海外企業を買収して、海外事業を発展させようとするケースは多いと思います。その際に本書に出てくるような日本の本社と現地子会社の間での軋轢のような話は往々にして見られる現象だと思います。日本から現地に赴任して海外子会社のオペレーションを担当する駐在員、あるいは海外企業と頻繁に仕事する機会のある人にも良い書籍かもしれません。

ちなみに、グローバルと言ってもシリコンバレーの話だけですし、タイトルにあるマッキンゼーとDeNAはほぼ関係ありません。これはマーケティング上の都合でしょう^^;

【読書】10年後の仕事のカタチ10のヒント　シリコンバレーと、アジア新興国から考える

2014-01-05T14:24:00.003+09:00

いわゆるグローバル企業で働き、海外で生活しているお二人の対談を元にした書籍です。

昨今のグローバル化で、単純労働だけでなく知識労働さえも簡単に海外にアウトソースされていく時代にあって、今後10年間のキャリアをどう考えるかヒントとなる内容です。グローバルグローバルと恐怖心を煽る内容でもなく、ノマドノマドと礼賛する内容でもないです。

あくまでも中立な立場で、現在の世界中の仕事のあり方、今後不利になる働き方・有利な働き方を解説しています。時代の流れを味方に付け、能力を活かしていきいきと生きていくかはあなた自身。そういうやる気をもらえる書籍です。

今後のキャリア、海外での仕事に興味ある人にオススメ。

Java + Selenium Web Driver 2.x の入門書 or 記事

2013-12-26T14:52:00.001+09:00

仕事で Selenium Web Driver 2.x（言語は Java ）を使う予定なので書籍や入門記事を読んでいます。参考になりそうな書籍や記事を以下に挙げておきます。

書籍

Selenium 2 Testing Tools: Beginner's Guide

入門者はこれくらいでしょうか。残念ながらAmazonの評判よくありませんね。買って読んでいますが、少し解説が親切ではない印象です。

また、Web Driver の解説が少ないようです。良い点は intelliJ と JUnit 4 を使った例が解説されている点、きれいなテストコードを書くためのデザインパターン（PageObject Patternなど）が解説されている点です。

記事

Selenium Documentation

公式のチュートリアルです。Web上では最も情報が多い印象です。

The 5 Minute Getting Started Guide

リポジトリを置いている Google Code 側にもチュートリアルがあります。本家との住み分けは分かりません。こちらはものすごい初歩的な内容とデザインパターンの解説があり、その間のドキュメントに乏しい点が残念です。

WebDriverの採用で生まれ変わったOSSのブラウザテストツール「Selenium 2」入門

解説が分かりやすく、例が具体的で参考になります。JenkinsやSelenium Grid とのからみが解説されている点も良いと思います。日本語の解説では一番良い印象です。

Selenium WebDriverでWebアプリのテストが変わる

解説は短いですが、例が具体的で良いです。冒頭の『Webのテストに超絶便利な「Selenium WebDriver」とは』という箇所で Selenium WebDriver を使うテストの登場人物（テストコード、driver、server、Webブラウザ）が図つきで解説されている点は初心者にとってありがたいですね。

--

とりあえず最初に読むと良さそうなのは以上。新たに良い記事が投下されることはなさそうな気がしますが、見つけたらブログで紹介しますね。

BIの使い勝手が悪いとBIからExcelファイルにエクスポートして、そのExcelを加工する業務が増えて生産性が落ちるのだそうな

2013-12-16T05:53:00.002+09:00

日経コンピュータの記事で「超Excel」というのが紹介されていました。いったい何だろうと思って、読んでみました。いわゆる「オペレーショナルBI」とか「セルフサービスBI」と呼ばれている分野の製品の導入を推進する記事のようです。

（※ドラッグ・アンド・ドロップでBIのダッシュボードやレポートが作成出来る操作性の高いBI製品のことです。最近の主要なBI製品には入っているようです。）

日経コンピュータ - 人間BI脱出の切り札、超「Excel」

ここで書かれているBI導入の現実が生々しいです。現実を無視して、BIを導入して、あまりに使いづらいので、それを迂回するような運用が現場で取られ、結局、生産性は落ちてしまうという展開。

そこでエクシングの社内では、複数の営業担当者を束ねるマネージャーがBIソフトから必要なデータを抜き出し、Excelで集計・加工する方法が普及していった。外出が多い営業担当者は、自らExcelを操作してデータを集計・加工する時間はないため、マネージャーが作成したExcelのデータを参考に営業活動を進めていた。

（「人間BI脱出の切り札、超「Excel」記事より引用）

それに対して、最近のBI製品ではドラッグ・アンド・ドロップで現場の人が作りたいレポート・ダッシュボードが比較的に簡単に作れるようになっているので、そういうのを使いましょうという紹介でした。

記事中では QlickView と Tableau が紹介されています。これの他に Jaspersoft も同様のことができます。

文字コード変換を簡単に行う Eclipse プラグイン = CharsetConvプラグイン

2013-12-16T05:41:00.001+09:00

Windows向けに書かれた書籍のサンプルコードをMaxのEclipse上でビルドなどしている際に、ファイルの文字コードを変更したいケースがありました。

便利なプラグインがないか探していたところ、CharsetConvプラグインがちょうど良さそうでした。これを使うとEclipseのウインドウ上でファイルを指定して文字コード変換を行うことができます。

インストール方法や利用方法はこちらのブログで確認できます。

CharsetConv Eclipse Plugin

よく使うサービスに2段階認証を導入

2013-12-15T05:55:00.002+09:00

アカウント乗っ取りの類、、、恐ろしいですね。いまさらですが、最近使っているサービスにひと通り2段階認証を導入して、アカウント乗っ取り対抗策を取りました。

導入方法は以下を参考にしました。

もしみなさんもまだやってなかったら導入を検討してみてください。

Jaspersoft Studioの翻訳マニュアルの一部を翻訳しました

2013-12-02T14:22:00.002+09:00

BIソフトウェアベンダーであるJaspersoft（本社はSan Francisco）のユーザ会の間でJaspersoft Studio（レポートのデザインツール）の翻訳を進めようという話が進んでいます。

私も3つある翻訳マニュアルのうち以下の2つを翻訳してみました。

このドキュメントによると、利用者が翻訳をベンダに提案出来る仕組みができているようです。

利用者がキリの良い単位で翻訳
その国際化バンドル（メッセージの翻訳部分をファイルに切り出したもの）をJaspersoftに送付
Jaspersoftのリリース担当者が翻訳をチェックし、次のリリースに取り込む

他の商用オープンソース製品の翻訳がどのように運営されているのか知らないので、今回こういう仕組みを知って大変興味深いです。翻訳がどのように行われているのかも随時エントリを書いてみたいと思います。

Jaspersoft 製品のユーザコミュニティに興味ある方はこちらから参加ください。

（追記）ユーザ会の荒川さんがJaspersoft Studioの翻訳について書いています。

小林雅一著「クラウドからAIへ〜アップル、グーグル、フェイスブックの次なる主戦場〜」

2013-09-29T13:21:00.002+09:00

「クラウドからAIへアップル、グーグル、フェイスブックの次なる主戦場 (朝日新書) 」はGoogle、Apple、Facebookといったシリコンバレーの有名IT企業によるAI（人工知能」の研究成果、および製品開発の動向を一般向けに解説した書籍です。

Google、Apple。彼らは最近ウェアラブルコンピューティングの開発競争を加速化しているのは報道の通りです。その意図は「ユーザのネットアクセスの大本を牛耳る」ことだそうです。大本を牛耳ることができれば、そこからユーザ操作に関する膨大なデータを収集し、ユーザの意図を解釈し、自社のサービスへの誘導したり、適切な広告を配信することで莫大な利益を上げることができます。

その次なる主戦場で重要だと考えられているのが人間の意図を解釈できることだそうです。スマートフォンを開き、スクリーンを覗き込みながら、煩雑なボタンを操作するのではなく、人間の視線、人間の発話、ジェスチャーからその人の意図を解釈し、適切なフィードバックを返すことに力を注いでいます。

その人の意図を解釈する際に活躍するのがタイトルにもある、AI（いわゆる人工知能）の技術です。AIは今から40年以上も前に登場し、知識表現、数理論理の面で研究成果は挙がりましたが、当初期待されていた「人と同じように考えるコンピュータ」の実現は至難の業であるとされてきました。古典的な方法（ルールを記述することで人と同じような解釈ができる）では思い描いた成果が得られなかったのです。

そこでGoogleのサイエンティストが着目したのが統計・確率的な手法で、人工知能を実現することでした。人間の作成したデータを統計解析することで、意味解釈はせずに人の意図を解釈することが部分的に可能になってきました。（例えば、I love youという文章についてI の後にloveが続くと、90%の確率でyouが続くといった風に）古典的な研究者からはそこには知性のかけらもないし、展望もないと批判されているそうですが、古典的な研究では得られなかった実用的な成果を挙げているのは確かです。

さらに今流行りが古典的なニューラルネットワークを進化させたディープラーニングという手法が取り入れられ始めているそうです。（説明が難しいので割愛しますが、人間の脳の知覚メカニズムを模倣したモデルです）近年の成果だと自動車の自動制御などにも応用されているそうで、自動車の運転などは10年以内に商業ベースに乗るとの観測もあります。事故が起きた場合の責務は誰にあるのかといった法的な課題はあるそうですが、期待される技術ではあります。

わーすごいと読み進めていくと、最後の最後で、これらの人工知能の技術がもたらす未来はどうなるかに視点が移ります。今まで機械ではできず、人間でないとできなかったことが次から次へと機械に置き換わっていく可能性があるのです。

製造機械など単純な手順の繰り返し作業は昔から自動化されていますが、今後は人でしかできなかった知的な判断を伴う作業が機械に置き換わる可能性があります。機械に置き換わると当然、失業が発生します。失業が増えると情勢不安につながります。産業革命が起きたイギリスでは仕事が機械に置き換わるとして、機械を打ち壊す大規模な運動が起きました。その現代版がそのうち起きるのでは？

人工知能の発達で恩恵を受けることは非常に多いことは確かですが（例えば、自動運転で交通事故は減らせるなど）、一方で急速に人工知能が発達する中であなたの仕事が果たして機械に奪われない保証はあるでしょうか？産業の発展と共により高度な仕事に移行する準備はしていますか？考えさせられる本です。

マーク・ピーターセン著「実践日本人の英語」

2013-09-29T12:47:00.002+09:00

「実践日本人の英語 (岩波新書)」は、英語学習者の間では有名な「日本人の英語 (岩波新書) 」（1988年出版）の続編です。著者マーク・ピーターセン氏は明治大学の教授で、専門分野の講義の他、英語の講義も担当されているようです。この日本人の英語シリーズは、著者が日本人学生の英作文を添削する過程で気づいた日本人が間違いやすい英語のパターンが分かりやすく整理されています。

おそらく本書は中級者レベル向けだと思います。初級者の場合、この本に書かれているようなニュアンスの違いを気にする前にまずは英語の運用能力を鍛えるべきです。そして、ある程度、英語で意思疎通できるようになってから、上級を目指す前に自分の足元を見直す上で役立つ内容になっています。（確か私も「日本人の英語 (岩波新書) 」を学生の時に読んだ記憶がありますが、その時は英語レベルがいまいちだったので難しく感じた印象がります。）

肝心の内容はというと、著者曰く日本人の英語学習初学者が英文を作成する時は、日本語の文法に引きづられたままで、原文の日本語を英語に直訳する傾向にあるそうです。日本語と英語は文法がかなり違うので、日本語に引きづられてそのまま直訳するとおかしな英語になったり、意味不明になったり、最悪の場合、誤解を与えるケースがあると指摘しています。

もし誤解を与える表現になっている場合、読み手が英語の文法間違いに気づかないと、誤解を与えることに書き手が気づかずにコミュニケーションを継続してしまうケースもあります。これは友達通しの雑談であれば、後で誤解が分かっても笑ってすみますが、ビジネスや研究発表の場合、実害が発生したりするので、注意する必要があります。

例えば、p36の冠詞の例を紹介します。以下の2つの文の意味の違いは分かりますか？

The government plans to phase out nuclear power plants in Japan.
The government plans to phase out the nuclear power plants in Japan.

the がついているかいないかの違いです。著者によると1の冠詞がない複数形の場合、「some nuclear power plants」と同じ意味になるそうです。一方、theがつくとすべての原子力発電所が対象になってしまいます。日本語に訳すと以下になります。

政府は日本にある2つ以上の原子力発電所の廃止を予定している。
政府は日本にあるすべての原子力発電所の廃止を予定している。

ただ、the がつくかどうかで全く意味が異なっています。前述したように友達通しで雑談する分には全く問題ありませんが、政府の官僚だったり、ニュース記者がこの文法間違いに気づかずに報道すると世界中に誤解を与えてしまいます。これと同じ問題が自分のビジネスにおいても起こる可能性はあるのです。

このような細かいニュアンスは文法学習だけて身につくとは思えないので、お金を払って英文添削のトレニーニングを継続的に受けないといけないんでしょうね。

Mac OS Xでテキストファイルの改行コード・文字コード一括置換は「MultiTextConverter 」が便利

2013-09-07T14:48:00.001+09:00

http://www.rk-k.com/software/mtc

パパっと検索して出てきたのがこれです。
インタフェースもシンプルだし、なかなか便利そうです。

Mac OS XにHomebrewでApache Antをインストールする

2013-09-07T13:28:00.003+09:00

How do I install ant on OS X Mavericks?
http://superuser.com/questions/610157/how-do-i-install-ant-on-os-x-mavericks

上記の質問サイトでやり方を見つけました。

http://superuser.com/a/611510

It looks like the alternate repository was migrated. You can either enable the homebrew alternate repository or install directly:

brew install https://raw.github.com/Homebrew/homebrew-dupes/master/ant.rb

実際にやってみるとうまくいきました。

$brew install https://raw.github.com/Homebrew/homebrew-dupes/master/ant.rb
#################################################################100.0%
==> Downloading http://www.apache.org/dyn/closer.cgi?path=ant/binaries/apache-an
==> Best Mirror http://ftp.kddilabs.jp/infosystems/apache/ant/binaries/apache-an
#################################################################100.0%
/usr/local/Cellar/ant/1.9.2: 1590 files, 39M, built in 7 seconds

$ant -version
Apache Ant(TM) version 1.8.2 compiled on June 16 2012

ただし、2013年9月7日現在の最新版は1.9.2なので、若干古いバージョンが入っています。

テスト駆動開発による組み込みプログラミングの集い＠関西で講師をやりました #tdd4ec

2013-09-01T16:58:00.003+09:00

（もう開催してから1ヶ月以上経っていますが、ブログにも記録しておきますね^^;）

7/20 (土)に関西で「テスト駆動開発による組み込みプログラミングの集い＠関西」という組み込みソフトウェア開発者向けTDDのワークショップをやりました。

開催のきっかけ

そもそものきっかけは、東京で原著の読書会をやってる時に、Twitter経由で本イベントの主催者である@HappyLuckyAkiraさんから「関西でも開催しませんか？」と声かけいただいたことです。「実家が徳島なので、帰省ついでに開催できるなら！」と返事して、いろいろな方のサポートをいただいて無事開催できました。

まずは一歩踏み出す、他者とつながる

私が東京で原著の読書会を開催してから、Twitterを使ってたおかげで色んな人が我々のことを見つけてくれて、色々な人と協力しながら、翻訳レビュー、Agile Japan 2013でのワークショップ通訳、トレーニング開催、東京や関西でのワークショップイベントへ繋がったのはとても刺激的で素晴らしい体験でした。その辺の経緯はLTでお話しました。

まずは一足を踏み出すこと。他者とつながる場所で活動することは大事ですな。

LTをやりました

怒涛の勢いでここまできたので、整理の意味あいで。あと、活動をしてもらう目的でコレまでの経緯を紹介しました。

誰かが言ってたけど人生はRPGのようだ from Yohei Onishi

ワークショップをやりました

そして本題のワークショップでは、以下の資料を使いました。

テスト駆動開発による組み込みプログラミングの集い@DevLOVE関西 from Yohei Onishi

ワークショップの流れ

流れは以下のとおり。
あとで書籍見た時にすんなり理解できるように動機づけ、重要なテクニックなどは紹介しました。
ただし、口で説明しても伝わりづらいかと思い、ワークショップをやりながら詰まったところを助言したり、途中でTIPSを紹介したりしました。

概要説明

TDDとは何か？
なぜTDDをやるのか？

ペアプロで演習

書籍のサンプル「プロダクトコードをスパイする」をテスト駆動で実装

振り返り

ペアプロの組で振り返り
全体の振り返り（ペアプロの組×2）

良かったこと

途中、人が集まらなかったそうなので、ひとまずは開催できて安心しました。
未体験の人がTDDに取り組無きっかけを与えることができてよかったと思います。

最初の講師が私で良かったのかという疑問はありますが^^;

他の関西コミュニティで活動されている方も参加されており、うちでもTDDのワークショップやりませんか？という意見が挙がってました。関西の交流の活発さが伺えました。

反省点

Windowsでサンプルがコンパイルできなかった

Windowsでの動作確認をちゃんとできていなかったせいで、当日、Windows組がコンパイルできない騒動が発生^^; エンコーディングがUTF-8だとWindowsでうまく動かないようで^^; すんません。

サンプルの題材が参加者に上手く伝わっていなかった

題材自体がよく理解できなかったという意見もありました。あまり分かりやすい説明ではなかったところ反省してます。ただ、Q&Aの時間を設けてもなかなか手があがらないのが難しいところです。

次の機会でトライ！

昔、TDDBCに参加した時は、「簡単な問題を徐々に出してく」「本人にフルスクラッチで作ってもらう」というやり方をしていました。時間を1日とか半日とか取れるなら、そういうやり方の方が参加者にとって題材を理解する負荷、サンプルを理解する負荷は下がるのかなと思いました。

ただし、皆の設計・実装が異なるのでサポート陣が大変そうですね。

せっかく組み込みなので最後にarduinoで実機テスト出来る題材にするとか。すでに@haradakiroさんがやってましたが。。。

おまけ

このイベントの声かけいただいたのが5月上旬だったんで、5月末開催のAgile Japan 2013で原著者のJamesさんとお会いした時に、主催者の @HappyLuckyAkira さん向けのサイン本をもらっておきました。やはり頑張った人にはご褒美がないと。。

今日いただいた、サプライズプレゼント。家宝です！ #DevKan #tdd4ec http://t.co/zQbrQUmcF1
— Akira kubo (@HappyLuckyAkira) July 20, 2013

HomebrewでMac OS X Montain Lion (10.8.4) にMySQLをインストールする

2013-09-01T16:02:00.006+09:00

自宅のMac OSにMySQLをインストールする機会があったので、ついでにその流れをメモしておきます。

以下のブログエントリを参考にしました。

HomebrewでMySQLをインストールする時に知っておきたいこと
http://tukaikta.blog135.fc2.com/blog-entry-197.html

1. MySQL をbrewでインストールする

brewコマンでインストールを実行します。

$ brew install mysql

私の環境では以下の実行結果が出ました。インストールに問題はないようです。

To connect:
mysql -uroot
To have launchd start mysql at login:
ln -sfv /usr/local/opt/mysql/*.plist ~/Library/LaunchAgents
Then to load mysql now:
launchctl load ~/Library/LaunchAgents/homebrew.mxcl.mysql.plist
Or, if you don't want/need launchctl, you can just run:
mysql.server start

なお、実行結果は以下のコマンドで後から確認できるそうです。

brew info mysql

2. MySQL を起動する

実行結果のログに出ていた以下のコマンドを入力すると無事に起動します。

mysql.server start

以下のコマンドで起動を確認します。なお、私の環境ではパスワードが設定されていないためpオプションは不要でした。

mysqladmin -u root ping

以下の出力であればOKです。

mysqld is alive

3. rootユーザにパスワードを設定する

こちらをやるかどうかは任意ですが、パスワードを設定しておくと良いでしょう。

mysqladmin -u root password 'new-password'

これで完了です。

Mac OS X LionへPostgresSQLを導入する

2013-08-14T21:57:00.004+09:00

これまで仕事でDBを扱うことはなかったのですが、最近、DBを使う仕事をやることになったので、あわててSQLを勉強中です。

今回は個人PCのMac OS X Lion（バージョン10.8.4）にPostgreSQLを導入しました。本エントリでは導入手順を紹介します。

(1) インストール

Mac OS Xにインストールする場合、GUIのインストーラを使うのが簡単そうです。以下でダウンロードできます。

http://www.postgresql.org/download/macosx/

Homebrewでインストールすることもできます。

> brew install postgresql

(2) データベースの初期化

データベースサーバのプロセスを起動する前にデータベースを初期化する必要があります。

まずデータベースの置き場所を用意しましょう。お試しであれば場所は好きなところで良いでしょう。

> su postgers
> mkdir -p ~/psql/data

（注意）データベースの置き場所はPsotgreSQLを起動するプロセスから書き込みできるパスが良いです。パーミッションの関係でデータベースに書き込みできないとプロセスが起動しない場合があります。データベースを起動するユーザでデータを配置するディレクトリを作成したほうが間違いが無いと思います。

次に先ほど作成したパスにデータベースを初期化します。

> initdb -D /usr/local/pgsql/data

以下の出力が出ればOKです。

Success. You can now start the database server using:
postgres -D psql/data
or
pg_ctl -D psql/data -l logfile start

(3) サーバプロセスの起動

出力にある通り、起動の仕方は2通りあるようです。後者の方はログファイルを作成してくれるので、後者の方が良いのではないかと思います。

> pg_ctl -D /usr/local/pgsql/data -l logfile start

起動プロセスをアカウント名でgrepしてみるとサーバプロセスが起動していることが分かります。

> ps ax | grep postgres
389 ?? Ss 0:00.00 postgres: checkpointer process
390 ?? Ss 0:00.00 postgres: writer process
391 ?? Ss 0:00.00 postgres: wal writer process
392 ?? Ss 0:00.00 postgres: autovacuum launcher process
393 ?? Ss 0:00.00 postgres: stats collector process

(4) サーバへのアクセス

psqlというPostgreSQLのターミナルにホスト名「localhost」を指定して接続してみます。

> psql -h localhost

以下が出力されればOKです。

WARNING: psql version 9.1, server version 9.2.
Some psql features might not work.
Type "help" for help.
postgres=#

「テスト駆動開発による組み込みプログラミングの集い」用サンプルの動作確認方法

2013-07-13T11:58:00.000+09:00

7月20日に大阪で開催する「テスト駆動開発による組み込みプログラミングの集い」では、以下の手順でCppUTestを使った単体テスト環境を用意していただきます。

1. ビルド環境を用意する。

CppUTestをビルドする環境が必要です。OSによってやり方は異なりますので、自分の環境に合わせて用意してください。各環境のインストール方法は割愛します。

Windows

gcc（cygwin）
Visual Studio（2010以上）※注意参照

gcc（XCodeに付属）

Unix/Linux

（注意）CppUTestはVisual Studio 2008に対応していますが、準備の都合で2010以上とさせていただきました。

2. サンプルをダウンロードする。

以下のURLからダウンロードできます。適当なディレクトリに解凍してください。パスに空白を含まないディレクトリが良いかと思います。

https://github.com/yohei1126/tdd4ecisback/archive/master.zip

3. サンプルをビルドし、テストを実行する。

以下の手順で、CppUTestおよびサンプルコードをビルドして、実行ファイルを作成し、その実行ファイルを実行するとテスト結果が表示されます。ビルドの仕方はツールによって異なるので注意してください。

(a) gccでビルドする場合 (Windows上でcygwinを使う場合も含む)

> cd (トップディレクトリ)
> make

(b) Visual Studio 2010でビルドする場合

<サンプルのルートディレクトリ>msvc/tdd4ec/tdd4ec.sln を開いて、ソリューションファイルをビルドしてください。ビルドが完了したら「デバッグなしで実行」してください。

4. テスト実行結果を確認する。

以下のような結果が出ればOKです。

$make
make -i -f Makefile_tdd4ecRunning tdd4ec_tests...........OK (11 tests, 11 ran, 24 checks, 0 ignored, 0 filtered out, 0 ms)

プロ通訳じゃないソフトウェアエンジニアが #agilejapan 2013 のTDDワークショップで通訳した時に気をつけたこと

2013-05-26T14:51:00.001+09:00

5/24（金）に開催されたAgile Japaan 2013の『Test-Driven Development for [Embedded] C』というワークショップ（講師：James Grenning 氏）で通訳をやりました。以前、Agile Samurai Dojo GatherningでJonathanさんと参加者の通訳をやったことはありますが、ちゃんとしたワークショップで通訳をやったのは初めてです。

Test-Driven Development for [Embedded] C by James Grenning at Agile Japan 2013 from Yohei Onishi

今回、個人的に非常に勉強になったので、自分の勉強の整理のため今回の体験をまとめておきました。もし同じようなことをやるどなたかの役に立てば幸いです。

※なお、このエントリは講師が外国人、受講者が日本人、日本語と英語の逐次通訳（通訳元の人が話し終わってから通訳をやるスタイル）を想定しています。

なぜ通訳をやることになったの？

最初にそもそも通訳をやることになった経緯を先に説明しておきます。

私は講師であるJames Grenningさんの著書「Test Driven Development for Embedded C」の読書会を東京で開催しており、その翻訳書である「テスト駆動開発による組み込みプログラミング ― C言語とオブジェクト指向で学ぶアジャイルな設計」の翻訳レビューにも参加していました。ちょうど翻訳が落ち着き始めた去年の年末、監修者の蛸島さんに、レビュアーの私が「本の販促でJamesさんを日本に呼べませんかね？出版後だとAgile Japanですかね」と提案しました。Agile Japanでは海外スピーカーをゲストに呼んでいることは知っていたので、もしかしたら実現できるかなと思ってい方からですね。そこから、2人でAgile Japan運営委員の方にJamesさんをキーノートスピーカーとして呼べないか交渉しにいきました。

当初は、何か難しい交渉になるのかと想定していましたが、運営委員の平鍋さんも「いいですね！Jamesさんは前から呼びたかったですよ！」といきなり快諾。意外と話が早く進みました。実際の来日の交渉はAgile Japan運営委員の方が担当され、私は蛸島さんとTDDのワークショップの通訳および補助として準備をやらせていただくことになりました。

技術的な通訳の基本

通訳と言えば、日本語を英語に、あるいはその逆に置き換えたらいいんでしょう？と連想されるかもしれませんが、実際の通訳は少し奥が深いと思います。私が頭に思い描いている通訳の作業は以下の通りです。

※実際には以下の作業は日常の英会話で常に意識していることですが・・・

通訳元となる言語を聞いて理解する。
1で話している内容の意図を把握する。通訳する内容を整理する。

元の直訳すると伝わりづらい場合、頭の中でもっとシンプルな表現に置き換えます。また、意図が分からない場合質問して確認したりします。

通訳先となる言語に単純に置き換える。
3の内容をより自然な表現にして発話する。

実際には3→4は一瞬で行われます。

この時、純粋に通訳と言われて想い描くのは3（機械的な言語の置き換え）だと思われますが、実際には通訳の元の意図を損なわず、かつ通訳の先に意図が伝わるようにするために工夫が必要になるのです。これは通訳する両言語の言語能力が必要になる他、通訳対象の専門知識が必要になります。なぜかというと対象分野によって適切な語彙が違うため、対象分野の専門知識がないと適切な語彙が選べないからです。聴講者は何を言っているのか分からない状態になってしまいます。

例えば、翻訳の例になりますが、Amazonで「翻訳がひどい」というレビューを付けられている翻訳書は前述の作業が適切にできなかった例だと考えられます。これは2の原文の意図を把握する作業ができていなかったり、対象分野の知識がないため3の狭義の通訳ができていなかったり、4として翻訳先の日本語が推敲されていなかったりして起きているのだと思います。

ワークショップの通訳って何をやるのか？

では、技術通訳が分かったとして、ワークショップでの通訳は何をやるのでしょうか？それはワークショップによって内容が違うと思いますが、基本的には2つだと思います。

講師の説明を受講者に通訳する
受講者と講師の質疑応答を通訳する

前者については講師がキリがいいところまで話をして、そろそろいいかなと頃合いを見計らって、通訳した内容を受講者に伝えます。明確に講師から通訳してくれと指示がある場合もあるでしょう。ただし、今回は講師が説明内容や受講者の様子に集中している雰囲気で、通訳側が通訳を差し込んでいいタイミングを見計らって通訳する感じでした。

後者の質疑応答に関しては、質問内容を聞いて、質問者に「質問は○○ですね？」と意図を確認して、講師に通訳します。講師が解答をしたら、その逆をやります。

通訳の準備として何をしたらいいのか？

(1) 専門知識の習得

前述のとおり、通訳する上では対象領域の専門知識が必要です。対象領域の知識を習得する他、ワークショップの資料を必ず隅々まで読んでおくのは必須です。そして、可能な限り、講師の著書、ブログ記事、インタビュー記事を読み、インタビュー動画も見ておきます。これでワークショップの内容を理解し、さらに講師の話し方、発音の仕方、よく使う語彙、説明のパターンなどを把握します。コレをやっておくと当日、「あ、あの話かな？」と推測がつくようになります。

(2) 通訳の練習（英会話カフェ、Skype英会話、シャドーイング）

次に通訳自身の練習は専門の書籍がたくさんあるのでそっちを読んでください^^; 私がやってたのは英会話カフェやSkype英会話での英会話の練習、そしてPodcastを聞きながらシャドーイングしたり、見聞きしたものを英語に置き換えたりする練習をしていました。といっても、これは普段やっていることなので特別このためにやったわけではありませんが^^;

今回の通訳の振り返り（Keep、Problem、Try）

では、最後に今回の通訳の振り返りをしておきます。

Keep（良かった点、続けて行きたい点）

(1) 対象領域の知識を習得する時間を豊富に持てた

結果的にではありますが、今回通訳する前に原著の読書会をやり、インタビュー記事を書き、翻訳書のレビュー、今回のワークショップの資料翻訳をやっていました。ワークショップの内容は頭に入っている状態だったので、この点はほとんど心配はありませんでした。

(2) 講師と密に打ち合わせでき、講師の不安を解消できた

ワークショップ1週間前、そしてワークショップの2時間前に講師と打ち合わせをしました。ワークショップの流れ、どこで質問を入れるか？、デモはどのPCでやるか？などを講師と確認してお互いに疑問点を解消できました。おそらく講師の心理的な不安を事前に解消できた点は大きいと思います。

(3) ワークショップ中、アイコンタクトなしに自然と通訳できた

最初は講師に通訳するタイミングを指示してもらう予定でしたが、それでは気が散りすぎるので、本題に集中してもらうため、通訳を入れるタイミングはこちらで図ることになりました。講師はただ自然にワークショップを進行出来るように努めました。ときおり、間違えたり、講師の説明が分からなくて聞きなおす場面もありましたが全般的には上手く言ったと思います。

Problem（問題のあった点）

(1) 資料を完全に翻訳してしまい、講師自身が資料を読めなくなってしまった

今回、通訳がアマチュアである点を考慮して、翻訳した資料を投影した方が受講者にとっては良いだろうと判断して、講師の許可をもらって日本語版を投影しました。しかし、実際には（当たり前ですが）講師が資料を読めなくなって進行状況が分からなくなる事態がたびたび起こりました。手元に原文を用意していたので、手元の原文を確認しながらの説明になったので、講師に認知的負荷を与えてしまったことを申し訳なく思いました。

(2) ジョークが通訳できなかった^^;

講師は気さくなアメリカ人であり、ちょいちょいジョークを挟んで場を和ませようとしました。ところが、通訳がジョークを理解できなくて、講師に確認しようとして、講師に「もういいよ、次いこう」と言われてしまうことがあり、受講者にも逆に笑われてしまうことがありました^^;

Try（次回改善したい点）

(1) 資料は原文に日本語字幕を付ける

講師と受講者双方が理解できる落とし所として、キーノートの資料（平鍋さん翻訳）のように原文に日本語字幕をつけるやり方が良いのかなと思います。

(2) ジョークも通訳できるようにする

これは経験と sense of humor が必要ですかね？^^;

おわりに（初の通訳を終えてみて）

まず、今回の機会を与えていただいたアジャイルジャパン事務局の皆様ありがとうございました。TDDと通訳の両方において非常に良い勉強の機会となりました。今回の体験を今後の私の人生においても飛躍のきっかけにしたいと思います（おおげさではなく）。

そして、翻訳書監修者の蛸島さん、翻訳から始まりワークショップの実施まで一緒に作業し、いろいろ提案やアドバイスを頂いて助かりました。今回は2人でないと負荷が高くてこなせなかったと思います。ありがとうございます。

そして、講師のJamesさん、つたない通訳でしたが逆にフォローしてくださってありがとうございました。気さくな人柄で、なんでも提案を受け入れてくれる懐の広さに感激です。

以上。また通訳する機会あれば今回の振り返りの結果を生かしたいと思います。

#agilejapan 2013 キーノート1「Demand Technical Excellence」 by James Grenning の感想

2013-05-25T15:38:00.005+09:00

5/24（金）に開催されたAgile Japan 2013に参加してきました。このエントリーでは参加できなかった人向けにキーノート1つ目 James Grenningさんの"Demand Technical Excellence（邦題：アジャイルにおける品質と技術の重要性）"について講演の概要と私の感想を残しておきます。

Demand Technical Excellence James Grenning keynote at AgileJapan 2013 from Kenji Hiranabe

最初に所感を述べておきます

Agile Japanの帰り道、もやもやとキーノートの内容について考えていました。最初にアジャイル言い始めたおっちゃん達の一人であるJamesさんのメッセージは何だったのか？

今回のJamesさんの講演のメッセージはアジャイルマニフェストで言っていることと同じだと思います。こうじゃないでしょうか？
「未熟な個人をプロセスやら何やらでがんじがらみにするという考え方はやめよう。個人が自立したプロフェッショナルとなり、顧客も自分も満足できるような仕事を自分の力でやろう。そのために必要な学習はやろう。自分が自分の組織を変える旗手になろう。」
安っぽい自己啓発みたいですんません。

がんじがらめにされるのは楽なんですよ、何も考えなくていいから。自分で考えて、自分で行動するのは怖いですよね。失敗するかもしれないし、おかしなこと言っていると他人に笑われたるするかもしれないし。でも、自立していない状況で仕事しても楽しくないし、成果もついてこないですよね。何でもいいから、1つコレだといのを見つけて、実践して、他人と協調して何かをやりとげていく。そういうことを継続したいなと思う次第でした。

そして、Jamesさんの「dogma follower（宗教信者）になるな」という言葉はちょっとドキッとしました、手段が目的化しやすい自分への戒めとして手帳に書いておきました。周りが見えてへん状態にならないよう、自分を客観視したり、人の意見は素直に聞ける謙虚さ、冷静さも持っていたいです。

スピーカーのJames Grenningさんについて

プログラムに書かれているとおり、最初にアジャイルを推進した人の一人であり、現在も世界中の組み込みソフトウェア開発の現場でコーチングやトレーニングを行なっている方です。

アジャイルマニフェストに署名した17人のうちの一人
プランニングポーカーの考案者
世界中で組み込みソフトウェア分野でのアジャイル開発・TDDのコーチング・トレーニング
先日出版された「テスト駆動開発による組み込みプログラミング〜Cとオブジェクト指向によるアジャイルな設計〜」の原著「Test Driven Development for Embedded C」の著者

James Grenningさんの発表について

大きく分けて3つあったのかなと思います。

アジャイルマニフェストが書かれた背景
アジャイルマニフェスト10周年で挙がった課題
今、現場が取り組むべきこと（開発者、スクラムマスター、マネジャー）

なぜアジャイルマニフェストが書かれたのか？

アジャイルマニフェストが出される前に主流だったのは「プロセスさえちゃんとしていればいい。モジュールも開発者さえも交換可能な存在だ。」というもの考え方だったそうです。理論的土台となっているのがWatts S. Humphrey氏の「Managing the Software Process」。CMMIの元ネタだそうです。

JamesさんはWatts S. Humphrey氏自身がそう言ったわけではないけどと断りを入れながら、産業界のメッセージは「プロセスがすべてで、人は取り替え可能」だったといっていました。それに対して、そうじゃないよね、人が一番重要だよねと言ったのがアジャイルマニフェスト著者達で、彼らの考え方がまとめられたのがアジャイルマニフェストのようです。

これは以前公開したJames Grenningさんのインタビューで同じことを語っている事に気づきました。

驚いたことの一つが、彼らの考え方はその当時主流だった考え方と違っていたことです。90年代に一般的だったのは「正しい開発プロセスがあれば、開発者はもっと上手くやるだろう」というものでした。しかし、アジャイルソフトウェア開発宣言を共に検討したメンバーの意見は「スキルのある優れた開発者がいれば、彼ら自身が学習して開発プロセスを決めれば良い」です。
それとは対象的に、多くの会社ではソフトウェア開発の管理や開発プロセスの改善の話をするとき、会社がやって欲しい通りに仕事をさせようとします。IT産業のやっていることは「うちには取り替え可能なプログラミングユニットの開発者がいる。彼らが開発プロセスに従えば、ソフトウェアの問題はなくなるだろう。」というもの。しかし、アジャイルソフトウェア開発宣言で我々が語っているのは人の重要性です。これは驚くべきものでした。

日本の多くの現場ではどうでしょうか？人の協調を重要視することが日本の製造業の強みだったように思えますが、今の現場で同じことができているでしょうか？ただ、アジャイルコミュニティの活動の成果か、今変化の途上にある気がしますね。

アジャイルマニフェスト10周年で挙がった課題

アジャイルマニフェストが書かれたのが2001年。2011年は10周年ということで、アジャイルマニフェストの著者が10周年を祝うパーティーが開かれたそうです。そこで、今アジャイルコミュニティが抱えている問題について話し合ったのだそうです。

そこで挙がった今後アジャイルコミュニティがやるべきことは以下の2つだそうです。
InfoQを見ると実際には4つありますが、この講演で強調したかったのはこの2つのようです。

Demand Technical Excellence（卓越した技術を求める）
Promote Individual Change and Lead Organizational Change（個人の変化を促し、組織の変化を導く）

なぜ卓越した技術を求めるのか？

ここでScrumの父Jeff Sutherlandの言葉を引用しています。「The biggest problem worldwide for Scrum teams is getting shippable code at the end of every sprint. 」多くのスクラムチームで各スプリントの最後にリリース可能なコードを実装することに大きな問題があるようです。

Jamesさんによると、これは未だに1970年代の開発手法を続けている開発者が多くいるからだということです。それはdebug later programming。実装した後にprint文やデバッガのステップ実行でバグつぶしをやる方法です。この開発手法は、「後でバグを見つけて取り除く」手法であり、バグの混入は許容してしまっているわけです。さらに開発規模の増大に伴い、テストの規模が増大すれば、テストできない範囲にバグが混入され、一番最悪なタイミングにこそバグが見つかって、プロジェクトは大炎上してしまうのです。

debug later programmingの問題に対してJamesさんが提案しているのは「ScrumとXPの結婚」。XPで定義されていた進化的設計に必要な技術プラクティスを見つめなおすことです。

XPの技術プラクティスの中でもJamesさんが一番取り組んでいるがTDDです。開発とテストを連続させ、バグを未然に防止する方法ですね。Jamesさんによるとコンピュータサイエンス分野で有名なエドガー・ダイクストラの言葉「デバッグに時間を浪費するのではなく、バグの混入を最初から防ぐ」を実現する取り組みだと話していました。

今、現場が取り組むべきこと（開発者、スクラムマスター、マネジャー）

現場に対してJamesさんが推奨しているのが「2. Promote Individual Change and Lead Organizational Change（個人の変化を促し、組織の変化を導く）」だったと思います。個人が自立したプロフェッショナルとして成長し、自分が起点となって自分の組織を成長させていこうというアドバイスです。Twitter界隈でもここの言葉に同意している人は多くいたように思えます。

開発者がやるべきこと

ものづくりのエキスパートになれ

（TDDをやる時間がないって本当？バグを追いかけている時間があるんならテストを書いてデバッグ時間を減らしたらいいんじゃないの？）

新しいことを学習し、挑戰しよう

（今21世紀だよ？未だに70年代のdebug later programmingやってるってどういうこと？良い本がいっぱい出てるからまず読め！）

信頼を築き、自分の仕事を包み隠さずチームに見せよう

（自分の弱みを見せることを恐れるな、他人に失敗を知られることを恐れるな、包み隠さず明らかにしないと人は成長しない）

自分の組織のアドバイザーになれ

（ボスがTDDをやらせてくれないって？じゃ、君がTDDのプロになって上司に教えればいいだろ？）

スクラムマスターがやるべきこと

同僚が問題解決者になるよう勇気づけよう
宗教信者になるな、君はスクラム”マスター（主人）”であって、スクラム”スレーブ（奴隷）”じゃない

Scrum研修で教えられていることを絶対視するな、手段を目的化するな

マネジャーがやるべきこと

優れたチームを育てよう
チームのモチベーションを上げようとするな

人のモチベーションを上げることは難しい、無理にやろうとしないこと
無茶苦茶な納期を指示したり、生産性の低い作業をやらせなければ、本来プログラミングは楽しいはず！

モチベーションを下げるのをやめよう

モチベーションを上げるのは難しいのに、下げるのは簡単。余計なことをしないでいい。

最後に小ネタ

キーノートの感想などはおしまいですが、裏話を1つ。「テスト駆動開発による組み込みプログラミング ―C言語とオブジェクト指向で学ぶアジャイルな設計」の翻訳が落ち着き始めた去年の年末、監修者の蛸島さんに、レビュアーの私が「本の販促でJamesさんを日本に呼べませんかね？出版後だとAgile Japanですかね」と提案しました。そこから、2人でAgile Japan運営委員の方にJamesさんをキーノートスピーカーとして呼べないか交渉しにいきました。

何か難しい交渉になるのかと想定していましたが、運営委員の平鍋さんも「いいですね！Jamesさんは前から呼びたかったですよ！」といきなり快諾。まじですか！！実際の来日の交渉はAgile Japan運営委員の皆様が担当され、私は蛸島さんとTDDのワークショップの通訳および補助として準備をやらせていただくことになりました。

ワークショップについて別途エントリを書きますが、なかなか楽しいものでした。Jamesさんを日本に招聘する活動に携われ、日本の開発者が奮い立つようなキーノートを聞けて、大満足でした。コミュニティの可能性を感じる日々でした。関係者の皆様、ありがとうございました。また、よろしくお願いします！

CppUTestのインストール方法

2013-04-21T17:43:00.001+09:00

本エントリではC++テスティングフレームワークのCppUTestのインストール方法について紹介します。

元ネタは以下のURLにあります。
https://raw.github.com/cpputest/cpputest/master/README_InstallCppUTest.txt

1. ビルド環境を用意する。

Windows

gcc（cygwin）
Visual Studio（2008以上）

gcc（XCodeに付属）

Unix/Linux

2. 最新のCppUTestをダウンロードします。

最新版は以下のURLからダウンロードできます。
http://cpputest.github.io/cpputest/

（参考）ソースコードは以下のgithubレポジトリで確認できます。
http://cpputest.github.io/cpputest/

3. ダウンロードした圧縮ファイルを適当な場所に解凍します。

（注意）パスに空白が含まれないようにしてください。

4. CppUTestとサンプルをビルドし、テストを実行します。

CppUTestではプロダクトコードとテストコードをビルドして実行ファイルを作成し、その実行ファイルを実行するとテスト結果が表示されます。

ビルドの仕方はツールによって異なるので注意してください。

(a) gccでビルドする場合 (Windows上でcygwinを使う場合も含む)

> cd <someDirectory>/CppUTest

> make

(b) Visual Studio 2008でビルドする場合

CppUTest_VS2008.slnを開いて、ソリューションファイルをビルドしてください。
ビルドが完了したら「デバッグなしで実行」してください。

(b) Visual Studio 2010でビルドする場合

CppUTest_VS2010.slnを開いて、ソリューションファイルをビルドしてください。
ビルドが完了したら「デバッグなしで実行」してください。

5. テスト実行結果を確認する。

以下のような結果が出ればOKです。

Running CppUTest_tests
.........!!.......................................
..................................................
..................................................
.....................................!............
..................................................
..........................!.......................
..
OK (302 tests, 298 ran, 801 checks, 4 ignored, 0 filtered out, 9 ms)

以上です。

若いソフトウェアエンジニアにとって、日本の伝統的価値観は実は学びが多いんだね〜 Scrum Alliance Regional Gathering Tokyo 2013 2日目参加レポート

2013-01-16T23:23:00.001+09:00

タイトルの通り、Scrum Alliance Regional Gathering Tokyo 2013の2日目（1/16）に参加してきました。申し込み締め切り前日に業務調整して、潜り込みました^^; いやはや危なかったです。

今回、参加しようと思ったきっかけは、半年くらい前に職場の同僚から野中先生の「The New New Product Development Game」という1980年代の論文がScrumの父Jeff Sutherland氏に影響を与えて、Scrumが生まれたという歴史を教えてもらったことです。それまで他の開発手法と同じく輸入学問としてAgile/Scrumを学んでいたのですが、発祥が日本！という話を聞いて歴史に興味を持って、歴史を書いているブログを読んだりしていました。

その後しばらくして、Scrum Alliance Regional Gathering Tokyo 2013の開催がアナウンスされ、そして野中先生と平鍋さんの共著「アジャイル開発とスクラム顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント」が出版され、対談まであると知り、日本人なら聞いておくべきだろ！と思い立って参加に至りました。

■野中郁次郎氏：実践血リーダーシップとアジャイル/スクラム〜イノベーションを生み出し続ける組織に求めるリーダーとは〜

Phronetic Leadership And Agile Scrum Gathering Tokyo 2013 from Kenji Hiranabe

とりあえず発表が難しすぎてよくわかりませんです・・・^^; 難しくてよくわかりませんなりに、野中先生の話の中で私なりに大事だと感じたポイントをつらつらと挙げていきます。

これはアジャイルの大事な価値観であり、その源流にある日本のものづくりで大事にされている価値観でもあるんですよね。昔、本田宗一郎氏、井深大氏など偉大な職人達が実践していたことが、長い年月を経て、日本に逆輸入されて、もう一度脚光を浴びているという事実を認識して、昔のものづくり企業についての本をちゃんと読んで見たいと思いました^^;

(1) 場：知は場で創発される〜場：動く文脈の共有（Shared Context In Motion）（資料p.22）

まず、アジャイルそして日本のものづくりで大事にされている価値観がこの「場」だと思います。製造業ではよく使われている「ワイガヤ（資料p.44）」を行う「場」ですね。関係者が全員集まって、ご飯食べたり、生活の一部を共にしながら、仕事について本音で話し合うことで製品を洗練させていく。そういうことをやるのが「場」です。

私の考える、この動く文脈を共有する「場」が大事にされる理由は・・・

まず、野中先生もおっしゃったように「言語化には限界があること」。

人間の知識の大部分は暗黙知で、ウォーターフォール型開発プロセスのように工程間を成果物としての文書をバケツリレーするような形では人間の知は伝わらず、作っていくプロセスの中で劣化していってしまうのだと思います。
そして教育においてもマニュアルでは実践的な知は伝わらず、OJT（日本語的には徒弟制度）で師匠と一緒に仕事して、師匠の所作を目で見て覚えるしかない。

そして、今は組織としていかに付加価値を生み出すかが重要になっていること。付加価値を生み出すには、個人と個人が対話して、個人の知識を組み合わせ、増幅させ、そういう相互作用を通して、価値を作っていくということが大事なのかなと。

後者については、仕事の中で、あるいはコミュニティでよく体験する話だなと思います。いろんな人がとわいわいやっているうちに、いろいろな人のアイディアが結びついて、最初には思いつかなかったようなところに行き着く体験。ありませんか？例のあれです。

(2) 価値命題はユニークなコトの提供（資料p.28）

この話では、iPodの例が挙がっていましたね。Appleが消費者に提供したのは、どこでも音楽を持って出かけられるという新しい音楽体験、つまりコトです。でも、人はiPodやiTunesというモノを通してしかコトを理解できません。消費者に体験させたい音楽体験があって、それを実現するためにiPodやiTunesというモノを作って提供しているわけです。おそらくサービスを設計するプロセスもコト→モノの順番なんですよね？

仕事でソフトウェアを作るときも、上司やらお客さんから言われるのは価値、ソフトウェアが実現する体験の方ですよね。その価値や体験が何なのかは言っている方も最初は分からないので、私も最近はソフトウェアを作る時にヒアリングした範囲で一番コンパクトなプロトタイプを作ってはデモしてみせて、「要はこういうことですよね？」「いや違うって」というやり取りを繰り返しながら、モノを作って触りながら同時にコトの話を固めていきます。

モノを作ってみて、モノを触りながらコトを考えて、コトが明確になることでモノにフィードバックがかかって、目的の品質に到達する。アジャイルでやってることはこういうことですよね。

(3) 組織と技術のイノベーション：自己相似形のフラクタル組織へ（資料p.59）

資料に書かれているのは、ダイハツ「ミライース」の開発事例です。いろんな部署の人が連携するのではなく、1つのプロジェクトチームに全員を転籍し、チーフエンジニアに人事権を委任して、製品全体をカバーする組織を作ったという例。これは激しい変化に対応するには、現場と経営層が連絡を取りあって意思決定を遅らせるのではなく、会社内にある個々の組織が市場の変化に合わせて機動的に動けることの重要性が高まっているということでしょう。

こういう会社組織の中に、もう一つ全機能が揃って自律的に動く組織を作るというやり方は、急激な変化に対応するための有効な手段として色々な組織で実践されているようです。

JALを再建中の稲盛氏（京セラ会長）は著書「アメーバ経営（日経ビジネス人文庫）」で、同様に全機能を持って自律的に動く組織を作ることを推奨しています（資料p.61）。その組織が生み出した「時間あたりの付加価値」が分かるようなインセンティブ手法を確立し、製品開発に必要な社内の調達も市場取引と同じようにやっているそうです。これにより、市場が変わるとその変化が社内取引にダイレクトに反映されて、各組織が自律的に「時間あたりの付加価値」を最大化するように動き始めるそうです。
野中先生が研究されている海兵隊の組織も同様だそうです（p.64）。どの部隊を取っても陸海空の兵力を保有して、独立して任務を遂行できるようになっているとか。

#自動車業界ではけっこー有名なやり方？

(4) 日本的経営のDNA「武士道」：社会的価値の共創

海外では株式会社というのは、その出自からして投資家にとっての価値を最大化することが大事とされてきました。そして80年代から市場原理主義的な動きが体制を占めていました。結果として、行き過ぎた資本主義結果、貧富の格差いが拡大し、その抗議行動としてOccupy Wallstreatに類似したデモ活動が世界各地で行われましたね（資料p.73）。世界的にも市場原理主義への反発が行われていて、マイケル・サンデル教授の講義もその現れでしょう(p.76)。より良い生き方、共通善をもう一度問い直そうという動きです。

そういう中で、野中先生が主張しているのが日本的経営の価値観「世のため人のため」を見なおそうということ。投資家が良ければOKではなくて、従業員も地域社会も企業を取りまくステークホルダーの幸福を目指す企業であれということです。近江商人の三方良しの話からして、かなり昔からあったようです。社会が幸福になる理想を思い描きながら、絶えずベターな解を求めていくのが日本的価値観なのだという話をされていました。

野中先生の話を聞いていて、たしかに、私が子どもの頃に亡くなった父方の祖父や、あるいは母方の祖母（存命）の世代には日本古来の道徳心のようなものが感じられました。ただし、今の若い世代には失われたものと思っている人もいるかもしれませんが、3.11以後のボランティア活動の高まりとか見ても、若い人も頑張ってますね。

■最後に：野中先生からのメッセージ

最後に話されていたのは、これからの実践知リーダーには、資料p.81にあるように頭（Mind; 西洋的思考）と体（Body；東洋的思考）を併せ持った身体化された心を持ち、共通善に向かって「より良い」を追求していく姿勢が必要だということ。スクラムはこの西洋と東洋の思考スタイルが合流してできたスタイルですね。

そして、ソフトウェアでは海外（特にアメリカ）に負けちゃってるけど、日本の若い人には海外には負けない国にしてほしいとのこと。ものすごい壮大なこと期待されていますが、今、20〜30代の人はそういう使命を持っていると認識して明日から頑張って行きましょうか。

2012年の活動まとめ。初の勉強会主催、海外著者インタビュー記事公開、グローバルな技術系イベントで海外の人と交流、初の自著執筆など

2012-12-28T22:20:00.003+09:00

今年の振り返り。
今年意識したことは以下。それなりにできたので満足です。

自分の能力が最大限に発揮できる道と社会が発展する道がうまく交差するような場を見つける。頑張って楽しいと、社会に何がしかポジティブな影響を与えることを両立する。
国境や母国語の違いを超えてグローバルに海外のエンジニアとも交流する。そのために日本語だけでなく英語でコミュニケーションする。

----

■1月

2011年から検討してきた組み込みTDD読書会を告知しました。技術系の勉強会初のイベント主催です。

http://legoboku.blogspot.jp/2012/02/test-driven-development-for-embedded-c1.html

最初に告知に反応してくれたのが著者James Grenning氏でした。来日予定あったJames氏が僕のツイートを発見し、「本読んでくれてありがとう。近々日本に行くから、会おうよ。日本の読者と話してみたいし。」とコンタクトを受けました。ちょっとびっくりですが、著者と読者を交えて座談会をしようと企画を練り始めます。

■2月

読書会第1回を開催しました。ケッコー人が集まって嬉しかったです。

http://legoboku.blogspot.jp/2012/02/test-driven-development-for-embedded-c1.html

それなりの長さの英語ブログを書き始めました。redditに投稿してみると500アクセス/エントリくらいあって驚き。ブックマーク上でちゃんと内容に関する議論が行われてて、ちゃんと英語書けているだなと実感を得ることができました。

http://legobokueng.blogspot.jp/2012/02/book-club-of-test-driven-development.html

■3月

かねてから興味のあったアジャイルのイベントに参加しようと、Agile Samurai Dojo Gatheringに参加。Jonathan Rasmussonさんと他の参加者との通訳を合計で1時間ほどやり、英語を勉強しててよかったと実感を得ました。

■4月

Coderetreatに参加。TDD Boot Campに参加したときは、あやふやだったTDDですが、読書会で練習したおかげでTDD初心者に教えるまでになりました。組み込みCの人と出会ってCでTDDをやりました^^

http://legoboku.blogspot.jp/2012/04/coderetreat-in-tokyo-2nd.html

■5月

組み込みTDD本の著者James氏の来日がキャンセルになり、日本人読者との座談会の企画もキャンセルになりました。でも、計5名が横浜に集い、JamesさんはアメリカからSkypeで参加してくださり、こじんまり短時間ではありますが、意見交換をやりました。まさかこんな展開になるとは思わなかったので感動しました^^

http://legoboku.blogspot.jp/2012/05/james-grenningtddskype.html

この時に、原田さんから紹介頂いた名古屋の組み込み開発者の方がわざわざ横浜まで来て座談会に参加してくださりました。この方が後に翻訳書の企画を出版社に通し、監修者になります。

■6 - 7月

定例でTDDの読書会を開催したり、あとはJamesさんが来日キャンセルになったけど、いろいろ質問事項がたまっていたので、インタビューしようと企画しました。実施方法は悩みましたが、職場の方がAgile 2012に参加するから代理でインタビューしようかと言われたのでお願いしました。

■8月

インタビューの録音データをいただいたので、ここから自分がインタビューしたわけではないインタビュー音声のテープおこしが始まります^^; しんどいけどヒアリングは練習したかいもあってなんとかなりました。アジャイル開発をやるやらないに限らず、持続可能な開発をやる基盤としてTDDの可能性は感じていたので、やはりここはインタビュー記事をしっかり書いて公開したいなと思いました。僕だってたいしたことはできんけど、世の中の役には立ちたいという気持ちはあるからね。

■9月

Jamesさんのインタビュー記事を公開するに先立って、そもそも書籍がどういうものか認知度を上げる必要があるなと思い、書籍紹介の記事を公開しました。ニッチではあるけど、組み込み・テスト・アジャイルクラスタの間で本書の認知度が上がり始めます。

http://www.ogis-ri.co.jp/otc/hiroba/OoBook/tdd4ec/index.html

5月に座談会でご一緒した方から翻訳書の企画通りました！との連絡あり、監修体制について議論を始めました。出版社からは早く市場に出したいとのことで、翻訳はプロが監修やレビューについては我々が責任をもってやるという役割分担をすることに。インタビュー記事があり、レビューどこではありませんでしたが、幸い翻訳原稿が届くのは少し後とのことでホットしました。

■10月

Jamesさんのインタビュー記事前編を公開しました。僕にとってアジャイルマニフェストは社会に出た時にすでに本に書かれた昔のできごとであり、そんな人間がアジャイルマニフェストの著者のインタビュー記事を書いていることに違和感を感じました。XP/アジャイル直撃世代の方がふさわしいのでは？と思いましたが、企画したのは自分だし、これを世に送り出すことは僕の使命だなと思い、通勤電車の中で何度も読み返しながら推敲しました。Jamesさんが話していた「アジャイルソフトウェア開発宣言で我々が語っているのは人の重要性です。」という言葉を何度もかみしめました。

http://www.ogis-ri.co.jp/otc/hiroba/specials/JamesGrenning/interview1/index.html

この辺から翻訳書監修チームでの会合が始まり、おおまかな体制が決まりました。

■11月

Jamesさんのインタビュー記事後編を公開しました。アジャイル・テスト・組み込みクラスタJamesさんの話していることは、仕事の中で培ってきた価値観にすごい合う印象でうんうんそうそうと納得しました。テクニックというよりアジャイルのマインドを理解し始めました。

http://www.ogis-ri.co.jp/otc/hiroba/specials/JamesGrenning/interview2/index.html

Ultimate Agilist Tokyoに参加。これまでのTDDの活動についてプレゼンしました。短い時間ながらも、大きな規模のイベントで話する側に回れて満足感を得ました。
この辺から翻訳原稿が届き始め、ビューが本格的にスタートします。

■12月

Global Day of Coderetreatのファシリテータ研修に参加。テレビ会議をつないで4カ国から6名の人が研修に参加。受講者のうち一人がJamesさんの元クライアントであり、中国語版翻訳者の同僚であることが分かりびっくり！世界はせまい。
本番ではJava/JavaScript/Ruby/Scalaでペアプロをやり、大満足。TDDのリズム感は楽しいな！と実感。TDDが血肉になりつつあるのを感じました。

書き忘れてたけど、1年通して自著を書いてて、今ようやくゲラチェック中^^; 来年初めには出版です！

世界規模のプログラミング教育イベント Global Day of Coderetreat 2012 は楽しかった！！

2012-12-09T21:51:00.001+09:00

2012/12/9（日）にGlobal Day of Coderetreatに参加してきました。私は昨年のGlobal Day of Coderetreat以来、1年ぶり2回目の参加です。

このエントリでは、

Coderetreatとはどういうイベントなのか？
Global Day of Coderetreatとはどういうイベントなのか？
Coderetreatをどう楽しむか？学びを有意義にするか？

をお話したいと思います。

■参考

東京会場の告知ページ http://kokucheese.com/event/index/62144/
togetter http://togetter.com/li/419437
公式サイト coderetreat.org：http://coderetreat.org/

■Coderetreatとはどういうイベントなのか？

まず、告知ページを一見しただけでは、「プログラマが1日中ひたすらペアプロをするイベントかな？」と思われるかもしれませんが、それだけではありません。

Coderetreatはプログラマのretreat（避難所とか静養所という意味）です。プログラマという職業の人は、普段の業務では常にリリースで追われていて、プログラミング、設計、テストなどの基礎テクニックをあらためて習得する機会に巡りあうことは少ないでしょう。納期とは無縁な場所で基礎テクニックを習得する機会を与えるのがこのイベントの趣旨です。

特徴としては以下の通り。

題材は「コンウェイのライフゲーム」です。人工生命のシミュレーションをするやつですね。

45分で1セッションのペアプログラミングを6回繰り返します。ペアは毎回変更します。
セッション終了時にはコードを全て削除し、毎回、ゼロからライフゲームというゲームのコードを書いていきます。

これは新しい設計アイディアに挑戦させる狙いがあるそうです。
実際、セッションを経る度に、ファシリテータが設計制約を課してくるので、それを乗り越えるたびに普段と違った発想で設計する強制力が働きます。

ペアプログラミング、TDD、オブジェクト指向設計といったプラクティスを習得する機会が得られます。

手取り足取り教えられるわけではありませんが、やり方はファシリテータが説明しますし、ペアの人が詳しければ実地で教えてもらえます。

プログラミング言語が限定されていないので、やり方によってはいろんな言語の学習機会が得られます。

どの言語でコードを書くかはペア次第なので、ペアの話し合いの結果によってはあまり馴染みのない言語で書く場合もあります。私は普段、C/C++/Python/VBなど使っていますが、今回は「普段使ってない言語を使う」というポリシーなので、相手の特異なJava/Ruby/Scala/JavaScriptを使いました。

ちなみに公式イベントは昼食とおやつはスポンサー持ち！

■Global Day of Coderetreatとはどういうイベントなのか？

今回は単にCoderetreatではなく、頭に「Global Day of」とついています。つまり世界中で同時に開催されているわけです。実際公式サイトを「Global Day of Code Retreat 2012」で検索すると、ものすごい量の開催告知が出てきます。少なくとも50都市以上で開催されているのではないでしょうか？

今回、日本ではおそらく東京、大阪、福岡、愛媛で開催されていて、会場ではGoogle Hangoutというツールを使ってリアルタイムでお互いの状況が分かるようになっていました。たしか、海外の会場ともつながっていたと思います。昨年はインドと中継して、「How are you doing?」なんてやり取りする場面もあり、なかなかおもしろかったですが、今年は海外とのやり取りがなくて物足りなかったです^^;

■Coderetreatをどう楽しむか？学びを有意義にするか？

せっかく丸一日使うのだから十分楽しみ、有意義な時間にするべきだと思います。楽しめて有意義にするためには、どうしたらいいんでしょう？普段とは違うやり方に取り組んだり、他の人から違う考え方を学び、視野を広げることだと思います。

今回、私が意識したのは以下です。

○普段と違う言語・フレームワークを使う

私は組み込みソフトウェア開発者なので、主に業務で使うのはC/C++です。開発環境のマクロを組む時にVB、スクリプトを開発する時にPythonなどを触る機会がありますが、他の言語を触る機会はありません。

しかし、他の言語の方がプロダクトコードやテストコードを書きやすい言語仕様やテスティングフレームワークになっている場合があり、他の言語のやり方を学ぶ良い機会になります。

今回一番良かったのはRubyとそのテスティングフレームワークのRSpec。直感的に書いたコードがだいたい動く感じが非常に気持良いです。そして、RSpecのdescriptionやcontextという要素でテストコードを構造化していくやり方は非常に頭が整理されているようで良かったです。

普段の言語にはそのまま持ち込むことはできないケースが多いと思いますが、エッセンスを咀嚼して普段の開発に活かすことはできるかもしれません。

○普段と違う設計をする

今回のイベントの趣旨は、業務ではできない体験をすることなので、普段とは違う考え方で設計をやるのが一番でしょう。普段、モデリングして、オブジェクト指向的に設計していない人はオブジェクト指向にチャレンジする機会です。私はオブジェクト指向設計に慣れているので、あまり慣れていないペアの時はモデルを書きながら、オブジェクト指向設計をリードして、「なるほど、こんな風に考えるんですね。勉強になりました。」とペアの方に言われて嬉しかったです。

また、for文を使わないようにするという設計制約を乗り越える過程で、普段あまり使わない言語要素の map & filter で簡潔にコードを書く方法を教えてもらったりしました。これは勉強になりました。

○理想的な形で技術プラクティスにチャレンジする

1セッション45分で非常に短いのでちょっと焦りますが、仕事と違って完成しなくても上司とお客さんに怒られたりしないので、理想的な形で試してみたい技術プラクティスに取り組んでみるといいのではと思います。

TDDって知識として知ってはいるけど、やってみたことはないという人は絶好の機会なので本に書かれているTDDをやってみてみて下さい。きっちり歯車が噛み合っている状態でバグを発生せずに少しずつ前に進んいく感覚は非常に気持が良いと思います。

今回、私がやってみたのは「実践テスト駆動開発テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION) 」で紹介されている「二重のテストループ」です。翻訳者の和智さんがブログエントリ「テスト駆動開発の進化」で紹介されています。

coderetreatで起こりがちなのが部品となるクラスの完成度が上がっていったけど、ライフゲーム全体は殆どできずに終わるというケースです。本番のシステム開発でやるとダメパターンですね。

これをアジャイル開発のように常に全体が動くようにするために、ユーザ視点で意味のあるシナリオ1つに対して受け入れテストを書き、内部をテスト駆動で書いていきます。これをやると、特定のシナリオに対して動くシステムが早めにでき上がって確認できる上に、アーキテクチャ設計から細部の設計・実装までひと通り通しでやってみて気づくような設計判断が早め早めに分かるというメリットがあります。

実践テスト駆動の題材に比べると細かいテストコードを書いていましたが^^; 雰囲気だけ分かって良かったです。

○振り返りで面白かったネタをシェアする

セッションの最後にペアで振り返りし、その時の付箋をボードに貼って、皆と体験をシェアします。基本的にはファシリテータの方が全体にシェアすべきことを拾ってくれますが、特にこれは！と思う内容は付箋を貼る時に皆に話してみると取り上げてもらえる確率も上がると思います。

○海外の人と交流する

そして、今回は global day ということで、ハッシュタグ #gdcr12 で世界中の人がいっせいにつぶやいていました。私も #gdcr12 に対して質問してみたのですが、J. B. Rainsberger（@jbrains）というヨーロッパ系カナダ人のコンサルタントの方から即座にコメントがありました。

ちなみにcoderetreat.orgのActivity CatalogというページにCoderetreatでよくやれているアクティビティの紹介が書かれていて、そこに「Verbs Instead of Nouns」と書かれていたので、何ですか？と書かれたので質問しました。回答は「Name your modules or classes with verbs instead of nouns（モジュールやクラスの名前に名詞ではなく動詞を使いなさい）. It affects how I divide responsibilities（このやり方は責務の分割に影響します）.」とのこと。どう影響するのかは教えてもらえませんでしたが、ビデオを見つけたので後で見ようと思います。

Verbs Instead of Nouns - Next Up at Coderetreat from Coderetreat on Vimeo.

■最後に

本エントリでは、Coderetreat自体とその楽しみ方を紹介してきました。このイベントはかなりよく練られたイベントで、世界中でやられているのも頷ける内容です。

なにより、違う分野の人同士が、それも国境を超えて、切磋琢磨する場があるといいうのがすこい素晴らしいと思います。異業種の人にも紹介してみましたが、そんなイベントがあるなんて！と驚いていました。

今後も定期的に開催されると思うので、今後とも参加したいと思います。
#やっぱコード書きたいからなるべく一般参加者で・・・^^;

legoboku.jp

「4時間で学ぶ、効率的な自動テストスクリプトのメンテナンス」は実践的で良い教材ですね

Stanform大学のDBコース、半分くらい終わりました

DBコースを受講したわけ

DBコースの内容

受講の仕方

コースの修了について

教材が英語だけど大丈夫？

負荷について

進め方の工夫について

CodezineのSeleniumチュートリアルをやっています

【読書】海賊と呼ばれた男

【読書】SONYとマッキンゼーとDeNAとシリコンバレーで学んだ グローバル・リーダーの流儀

【読書】10年後の仕事のカタチ10のヒント シリコンバレーと、アジア新興国から考える

Java + Selenium Web Driver 2.x の入門書 or 記事

書籍

Selenium 2 Testing Tools: Beginner's Guide

記事

Selenium Documentation

The 5 Minute Getting Started Guide

WebDriverの採用で生まれ変わったOSSのブラウザテストツール「Selenium 2」入門

Selenium WebDriverでWebアプリのテストが変わる

BIの使い勝手が悪いとBIからExcelファイルにエクスポートして、そのExcelを加工する業務が増えて生産性が落ちるのだそうな

文字コード変換を簡単に行う Eclipse プラグイン = CharsetConvプラグイン

よく使うサービスに2段階認証を導入

Jaspersoft Studioの翻訳マニュアルの一部を翻訳しました

小林雅一著 「クラウドからAIへ 〜アップル、グーグル、フェイスブックの次なる主戦場〜」

マーク・ピーターセン著 「実践 日本人の英語」

Mac OS Xでテキストファイルの改行コード・文字コード一括置換は「MultiTextConverter 」が便利

Mac OS XにHomebrewでApache Antをインストールする

テスト駆動開発による組み込みプログラミングの集い＠関西で講師をやりました #tdd4ec

開催のきっかけ

まずは一歩踏み出す、他者とつながる

LTをやりました

ワークショップをやりました

ワークショップの流れ

良かったこと

反省点

次の機会でトライ ！

おまけ

HomebrewでMac OS X Montain Lion (10.8.4) にMySQLをインストールする

1. MySQL をbrewでインストールする

2. MySQL を起動する

3. rootユーザにパスワードを設定する

Mac OS X LionへPostgresSQLを導入する

(1) インストール

(2) データベースの初期化

(3) サーバプロセスの起動

(4) サーバへのアクセス

「テスト駆動開発による組み込みプログラミングの集い」用サンプルの動作確認方法

1. ビルド環境を用意する。

2. サンプルをダウンロードする。

3. サンプルをビルドし、テストを実行する。

(a) gccでビルドする場合 (Windows上でcygwinを使う場合も含む)

(b) Visual Studio 2010でビルドする場合

4. テスト実行結果を確認する。

プロ通訳じゃないソフトウェアエンジニアが #agilejapan 2013 のTDDワークショップで通訳した時に気をつけたこと

なぜ通訳をやることになったの？

技術的な通訳の基本

ワークショップの通訳って何をやるのか？

通訳の準備として何をしたらいいのか？

(1) 専門知識の習得

(2) 通訳の練習（英会話カフェ、Skype英会話、シャドーイング）

今回の通訳の振り返り（Keep、Problem、Try）

Keep（良かった点、続けて行きたい点）

(1) 対象領域の知識を習得する時間を豊富に持てた

(2) 講師と密に打ち合わせでき、講師の不安を解消できた

(3) ワークショップ中、アイコンタクトなしに自然と通訳できた

Problem（問題のあった点）

(1) 資料を完全に翻訳してしまい、講師自身が資料を読めなくなってしまった

(2) ジョークが通訳できなかった^^;

Try（次回改善したい点）

(1) 資料は原文に日本語字幕を付ける

(2) ジョークも通訳できるようにする

おわりに（初の通訳を終えてみて）

#agilejapan 2013 キーノート1「Demand Technical Excellence」 by James Grenning の感想

最初に所感を述べておきます

スピーカーのJames Grenningさんについて

James Grenningさんの発表について

なぜアジャイルマニフェストが書かれたのか？

【読書】SONYとマッキンゼーとDeNAとシリコンバレーで学んだグローバル・リーダーの流儀

【読書】10年後の仕事のカタチ10のヒント　シリコンバレーと、アジア新興国から考える

小林雅一著「クラウドからAIへ〜アップル、グーグル、フェイスブックの次なる主戦場〜」

マーク・ピーターセン著「実践日本人の英語」

次の機会でトライ！

若いソフトウェアエンジニアにとって、日本の伝統的価値観は実は学びが多いんだね〜 Scrum Alliance Regional Gathering Tokyo 2013 2日目参加レポート

■野中郁次郎氏：実践血リーダーシップとアジャイル/スクラム〜イノベーションを生み出し続ける組織に求めるリーダーとは〜