2012/02/26

C/C++でTDDする時の手順をステートマシン図で描いてみた


タイトルで描いてみたと言いつつ、「Test-Driven Development for Embedded C (Pragmatic Programmers)」の第3.7節「Test-Driven Development State Machine」より引用です。著者のJames W. Grenning氏はTDDの作業を以下のステートマシン図のように捉えると良いと書いています。

TDDの作業を状態遷移として表現したステートマシン図


※作業を状態として書いているので良い書き方じゃないのですが、そこは置いときましょう。

TDDをやっている人ならご存知だと思いますが、テスト対象を実装する前にいきなりテストを書いて、わざわざコンパイルエラーを起こすとこからやるのが大事です。そして、コンパイルエラーの次は、リンクエラー、テスト失敗と来てからようやくテストを通るように実装します。

この一連の流れをやる目的は、

  • 今あるテストを通すための最小限の実装を常に維持する
  • テストが通っていないなら、どこに問題があるか明確に分かるようにする

です。

まずはテストを書いて目標を定めておいて、エラーまたはテスト失敗で作業ステップを確認しつつ、1歩1歩歩いていくのです。本当に1歩ずつです。ちょっとでも道から外れていれば、そこ道外れているよ!と警告を上げてくれます。

(TDDをやらない人でもIDEを使っている人は、IDEについている構文チェックのサポートを受けてコードを書いているので似ているようなことをやっているかもしれません。)

TDDをやらないコーディングの場合、本人が気付かないだけで、作業と並行して細かなミスが蓄積していったり、実装モレがあったりします。実装が一通り終わったという状態になっていても、どこにバグや実装モレが潜んでいるか分からない状態でテスト or デバッグをすることになります。

しかし、このステップをきれいに守ることで、何か問題が起こっていれば明確に問題の箇所が把握できます。テストしていないとか、実装し終わっていないとか、不安定な状態でいる期間が短くなります。常に動くコードをさわっているという核心を持ち、非常に安心感をもって作業ができます。

慣れてくるとビシッと歯車がかみ合った状態で1個1個作業が進んでいる感覚が得られて気持ち良いです。少なくとも読書会をやっているときはきっちりTDDのステップでコードを書き続けてみます。

2012/02/25

TDDする時は少しでもコードを書いたら即ビルド・テストを実行させる

Test-Driven Development for Embedded C (Pragmatic Programmers)」の第1章「Test-Drivern Development」 p.8に以下の記述がありました。
With every change, run the tests. The tests show you when the new code works; they also warn when a change has unintended consequences. In a sense, the code screams when you break it!
この本ではコードがテストされていない期間を可能な限り短くすることを強調していて、理想的には少しでもコードを書いたらビルドしてテストすべきと推奨しています。聞いたところによると、Kent Beckもかなり短いサイクルでコーディングとテストをまわすことを推奨しているとか。これはアジャイル開発に共通する考え方ですね。

Eclipse CDTでやる場合は、プロジェクトのプロパティ -> C/C++ Buildタブ -> Behavior -> Build on resource save (Auto build) にチェックを入れます(下図を参照)。必要に応じてビルドターゲットも設定しましょう。


実際にやってみるとちょっとした記述ミスがあると、すぐにテスト失敗が起きて知らせてくれるので割と便利です。ただし、前提としてテストが数秒で終わらないと作業が止まってので、単体テストの処理時間は短くした方がよさそうです。

それでもテストが増えてくると、そうも言っていられないと思うので、自分が開発中のところだけテストを実行するようにテスティングフレームワークの設定をしておくと良いと思います。
一部をテストさせるやり方はまた後日ブログにのせたいと思います。


2012/02/18

BlogにCoderwallのバッジを貼ろう

Githubのリポジトリの内容をかっこいいバッジで表現してくれるCodewallというサービスがあります。リポジトリの内容、言語の種類やforkされた数などを解析してバッジにしてくれます。

このサービスを利用するメリットとしては以下が考えられるかなと思います。
  • 見た目にもCodewallのバッジはかっこいい。
  • Githubの活用度合いを視覚的に表現するツールとして使える。
  • バッジを増やしていく楽しみもあり、ゲームのようで楽しい。 
バッジを増やすためにがんばる!ってのもどうかと思いますが、がんばった結果がバッジの種類や数として表現されているとなんか勲章のように感じられるかもしれません。

気に入ったので、ちょっとブログのサイドバーにつけてみました。今のところバッジ2つ。C++のリポジトリとJavaのリポジトリを持っていることの証明のようです。今度、種類と数が増やせるようにがんばりたいと思います。

#今、C言語でTDDするコードをコミットしてるので、少なくともC言語のバッジは増えると思います。

ちなみに以下のようなJavaScriptのコードを埋め込むとバッジを表示できます。”yohei1126”は私のアカウント名なので自分のものに置き換えてください。

<script="" type="text/javascript">
    function display_coderwall(args) {
        var badges = args["data"]["badges"];
        for ( var i = 0; i < badges.length; i++ ) {
            document.write('<img '"="" +="" badge"]="" height="48" src="'+ badges[i][" width="48" />');
        }
    }

  <script src="http://coderwall.com/yohei1126.json?callback=display_coderwall"/>
  
</script>


2012/02/05

「Test Driven Development for Embedded C」読書会第1回をやりました #tdd #tdd4ec

Test Driven Development for Embedded C」読書会第1回をやりました。


そもそものきっかけは、2011年の「TDD Boot Camp 東京 for C++」というイベントです。これは組み込みやゲーム業界でC/C++の開発をやっているエンジニアがTDDを実践的に演習するというイベント。

その時に私がポジションペーパーに「Test Driven Development for Embedded Cの読書会をやりたい」と書いたところ、2名が名乗りを上げくれたのでやってみようとなりました。Twitterで呼びかけたところ、10名のエンジニアが参加を表明してくれて、それなりの規模の会になりました。

参加者のモチベーションは?

参加者は、複合機、医療機器、通信機器、家電などの組み込みソフトウェアを開発しているソフトウェアエンジニアです。皆それぞれプロジェクトの中で、レガシーコード(テストコードのない製品コード)を大量に抱えていて、いつも開発時間の大半をデバッグ時間に費やすという不毛な状況に追い込まれているようです。

そのような状況に対して、どうにかしてデバッグ時間を減らすために、不具合を早期に見つけるために、解決策の1つとしてTDDを使えないかと考えていました。

今回読んだ内容

第1回の今回は、第1章「Test Driven Development」、第2章「Test Driving Tools and Conventions」、第3章「Starting a C Module」をやりました。

第1章ではTDDをやる目的、TDDとは何か、TDDをやることで得られる恩恵は何か?を書いていました。
TDDは設計手段の1つとのことで、TDDの目的の1つとして設計改善があることは挙げられます。ただ、私は最大の目的は迅速にテスト結果のフィードバックを受けることで、即場に間違いを見つけること、バグを未然に防ぐことだと思いました。この点は、皆のやりたいことと一致していると思いました。

第2章では、この書籍で扱うテスティングフレームワークの使い方を紹介していました。C向けのUnity、C/C++向けのCppuTestの使い方が紹介されていました。
googletestと同様にCppuTestは自動的にTestRunnerにテストを追加する機能もあり、TDDにはもってこいのツールだと思いました。また、C++の枯れた仕様しか使っていないとのことで、古いコンパイラを使っている人にも安心して使えるツールです。
Unityは単体ではTestRunnerに自動的にテストを追加する機能はないそうですが、Rubyスクリプトでそれを代替しているようです。

第3章では、LEDのドライバソフトを題材に本格的にTDDをやって行く手順について紹介されています。
この章の中では、組み込みの中でのDevendency Injectionのやり方として、物理的なLEDドライバのアドレスを実行時に与えるというやり方を紹介していました。実行時に物理アドレスを与える方法を取ることで、ハードウェアとソフトウェアが分離され、ハードウェアがない状態でもテストできるというメリットが得られるようです。

分からなったこと

分からないなと思ったことが2つありました。
まず1つ目は、第3章のLEDドライバの例はシンプルだからアドレスを渡すみたいな設計にできるんだということです。実際に複雑な例であれば、アドレスを書き換えることによって、別のハードウェアのステータスが変わって・・・という依存関係が複雑になる問題があるので、そういう設計にはしないよねとのこと。

おそらくは、複雑なハードウェアの相互作用、あるいは複雑なタイミングの問題などを全て再現することなく、テストしたいところだけ取り上げてテストできるようにしたりするか(いや、どうするのか分かりませんよ?)。

あるいは、もっとも底辺なレベルのテストをTDDでやらずに、もう1段上のレイヤー、ハードウェアを抽象化している部分のテストをメインにやるのではないかということ。こちらは、全てをTDDしないので網羅的ではないですが、ポイントを絞ってテストすることで、実機を使ったデバッグに専念できるようにする効果はあると思います。

2つ目はレガシーコードが大量にあるシステムに対して、どうやってTDDをやっていくのかという問題。テストを動かすまでの準備が巨大であれば巨大であるほど、最初にTDDをやるモチベーションが下がっています。現場で実戦するなら、初期コストを抑えながら、徐々にTDDを導入する方法が必要です。
どうやらレガシーコードとの戦い方は13章に書いているらしいとのことで、このあたりの考え方は後半解消できるかもしれません。

第1回を終えて

当たり前ですが、第1回では我々の疑問に対する答えは部分的にしか解消できませんでした。しかし、共通した問題意識を持っているメンバーがそろうことができたのが今日の成果だと思います。
この会を重ねていくことで、現実とどう折り合いをつけていくか、何かしらの解を出せるのではと思います。

まず、この会のきっかけを作ってくれた「TDD Boot Camp 東京 for C++」の主催者の皆さんや、「Test Driven Development for Embedded C」の著者James W. Grenning氏には感謝したいです。

さて、主催者として参加者が満足できるような会にしていきます :)


2012/02/02

#読書 2012年1月に読んだ本

なんかbooklogに月単位で読んだ本を整理する機能があったので記念ポスト。

1月に読んだ本の中では「弱い日本の強い円 (日経プレミアシリーズ)」が一番良かったですかね。為替のトレーダーの著者が為替の仕組みを紹介しています。
為替がどういう原理で決まるのか良く知らないのにFXでリバレッジをかけて大損した人多いんじゃないでしょうか?この本で基本原則を理解すると少なくとも長期的なトレンドで失敗することは防げると思います。

legobokuの本棚
2012年01月
アイテム数:5
錯覚の科学
クリストファー・チャブリス,ダニエル・シモンズ
読了日:01月17日
{book['rank']

世界でいちばん!日本経済の実力
三橋 貴明
読了日:01月17日
{book['rank']

powered by ブクログ

2012/01/14

#etrobo 2011東京・南関東・関西合同飲み会をやりました


1/14(土)に東京・南関東地区、そして関西地区それぞれで慰労会をやりました。その中で、Skypeでビデオチャットをつなげて、お互いに質問をやりとりをしてみました。

非常に有意義な会で、お互いに刺激を与え合うことができました。面白い取り組みだと思うので、やり取りの内容を乗っけてみます。

参加チーム

<東京地区>

  • 飛べ! ぼくらの夢ヒコーキ
  • StrayCab06
  • チームSUPRAパンダ
  • 田町レーシング
  • 芝浦雑伎団

<南関東地区>

  • TAKOS
  • みらいウォーカー
  • BNX
  • ほぼ組
  • AEK RUNNER11
  • マイペース

<関西地区>

  • HAK
  • 電子くん
  • R-GRAY NEXT
  • 猪名寺駅前徒歩1分
  • NEXT KOBE 
(東京・南関東地区から関西地区へ質問その1)モデルとソースコードはどこまで一致していますか? by ほぼ組

(関西地区)8~9割一致がちょこちょこです。逆に質問をしたいですが、どこまでやって100%なのでしょうか?完全にモデルから生成するだけで終わっているということでしょうか?

(東京・南関東)静的なクラス構造が一致していることです。関数内部のロジックは問いません。

(関西地区)クラス構造なら一致してるさ!

(関西地区)振る舞いなら100%だけど構造は90%とか謎のセリフも出ています。抽象的な部分は100%だけど具象化部分がもうちょっと、ということのようです。

(関西地区)そっちはどうですか?

(東京・南関東地区)静的構造の90%は一致しているけど、モデリングツールの機能的に難しいところがあり、100%には至りませんでしたた。by ほぼ組


(関西地区から東京・南関東地区へ質問その1)太陽光の影響が強いとのことですが、どのくらいですか?

(東京・南関東地区)試走と本番でセンサ値が違うのはざらです。by 芝浦雑技団

(関西地区)コース上に光の帯が出ている写真を見ましたが、その帯は移動するのですか? by HAK

(東京・南関東地区)ちょっとずつ移動しますよ。 by 田町レーシング2010大西

(関西地区)対応方法はマイマイ式だけですか?何か追加のやり方とか、そのあたりしか使わないとか、そんなTIPSがありますか?

(東京・南関東地区)マイマイを使ったのはチームSUPRAパンダさんだけでした。

(関西地区)それでも走れてしまうのですか??

(東京・南関東地区)うちは光センサ値の移動平均とってました。移動平均を取るだけで、光の帯があるとこでもコースアウトしませんでした。by田町レーシング

(関西地区)そうなんですか。意外でした。


(東京・南関東地区から関西地区へ質問その2)R-GRAY NEXTさんへ。アイコンによるトレーサビリティはどれくらい時間かかりましたか?いつごろ導入しましたか?終盤?最初から?

(関西地区)アイコンを書くのは時間は滅茶苦茶かかりました。アイコンは3~4年前から導入していたので、最初から入っていました。

(東京・南関東地区)導入したのはロボコンですか?業務?アイコン入っている業務用のドキュメントを見てみたい!byほぼ組

(関西地区)業務じゃ使うわけないですよw


(関西地区から東京・南関東地区へ質問その2)SysMLの要求図を実際に業務で使っている方はどのくらいいますか?

(東京・南関東地区)ゼロです。そちらは?

(関西地区)学生さん(電子くん)が少し使ってみたと言われています。社会人は0ですね。

(東京・南関東地区)メリットは感じましたか?

(関西地区)機能と非機能をあわせて考えられたのが良かったです。


(東京・南関東地区から関西地区への質問その3)ロボコンのモデル図やロボコンの経験を業務にどれくらい生かせそうですか?byほぼ組

(関西地区)クラス図は超役立ってます。by R-GRAY NEXT

(関西地区)シーケンス図を書いたらUMLの説明に1時間かかりました…。by HAK

(関西地区)浸透してきたら分かりやすいとコメントされているそうです。 by HAK

(関西地区)ロボコンをやって読めるから書けるにステップアップしました。 by 猪名一

(関西地区)ぼくはよめるようになりました。by みずの

(関西地区)学外の人たちと触れられたのがとても刺激的でした。 by 電子くん

(関西地区)社会人でもこうやってたくさんの社外の人と触れられてつながりが出来るのが一番大きいとは思っています。

(東京・南関東地区)はい。いい意見ですね。たぶん、こっちも同じような意見ですね。


(関西地区から東京・南関東地区への質問その3)南関東・東京では連合活動が多いですが、具体的にどんな事をしましたか? あわせて、連合でどこまで共有してどこまで企業秘密にしているか、というあたりも教えてください。

(東京・南関東地区)月1くらいでモデルレビューしたり、試走会しました。また合宿しての試走会もしました。

(関西地区)合宿!?


(東京・南関東地区)企業の研修施設で、試走したり、モデルについてディスカッションしたり、卓球したり、マッサージチェアでマッサージうけたり。。卓球とマッサージで忙しくてワークショップに遅れたチームが1つ^^;

(関西地区)何??めっちゃ楽しそう!!

(東京・南関東地区)情報共有の程度ですが、企業秘密はあまりなさそうです。ただ、終盤にモデルや競技の完成度が上がるので、結果的に一番大事な部分は共有できません。

(関西地区)コードレベルの共有もあったりしますか?

(東京・南関東地区)コードの共有はないですね。

(東京地区・南関東地区)では、そろそろコラボタイムは終わりですね。ありがとうございました。今年は、ともに上位を狙いましょう!

(関西地区)はい。お互いにがんばりましょう!!


本会を終えての所管


東京・南関東地区の方の〆の挨拶で、若いエンジニア達が企業の枠組みを超えて交流し、お互いに切磋琢磨していくことで、我々から日本をよくしていこう。経済を立て直していこうという、幾分か壮大な、でも本当にそうだと思える意見が出ました。


僕が個人の時間を使って、こういう活動をしている目的の一つと一致していると思いました。もちろん、個人の成長や仕事での成果につなげたいという個人的な気持ちはありますが。。がんばっている同世代の人たちを応援したいという気持ちが強いです。


今後も、企業とかチームとか地区とかせまいコミュニティだけでなく、参加者全体が切磋琢磨して成長していきましょう。それが自分のためにもなります。

2011/12/03

英語を勉強する時はインプットとアウトプット両方やると良い

みなさん英語勉強していますか?私はほぼ毎日やってます。

先日、英語学習者の集まりに参加したのですが、英語を勉強している人が集まると、どういう勉強方法がいいか?という話題が挙がりますね。これまでの傾向で言うと、入門者の人ほどインプット中心で、文法やボキャブラリの学習に偏っている印象です。一方、ある程度、英語が使えるようになた人は会話や文章を書いたり、アウトプットの比率を増やしているようです。

僕の持論としては、バランスよくインプット・アウトプットの量をこなすのが一番だと思います。インプットに偏ると読んだり聞いたりはできるけど、英語を書く時や話すことができず、スムーズにコミュニケーションできなくなります。

このエントリでは、僕が日々やっているインプットとアウトプットを組み合わせた勉強方法を紹介します。

1. 文章と音声がついている英語記事を探す。

まずインプットのネタを探します。リーディングとリスニングの両方できる教材を探すのがポイントです。文章だけだと、どう発音されるか分からないし、音声だけだとちょっと聞き取るのに苦労します。だから両方付いている教材を探すわけです。

この時、自分が興味が持てる分野で、自分の英語レベルにちょうど良い、ある程度語彙が抑えているものを選ぶとよいと思います。興味が持てないような話題だと続かないし、語彙が難しすぎても続きません。英語はスポーツと一緒で継続が大事です。

 自分がお勧めなのは以下の3つです。私はVOA Special Englishから初めて、最近はBBC 6 minutes EnglishとTED Talkを併用しています。
VOA Special Englishはアメリカの国営放送VOA(Voice of America)がノンネイティブ向けに放送しているpodcastです。配信元の性格上、テーマがアメリカ寄りではありますが、テーマが多岐に渡っていて、いろいろな話を聞けるのが特徴。サイトでスクリプトを入手できます。スピードはかなり遅いので、初心者向けだと思います。

BBC 6 minutes EnglishはBBCが配信しているpodcastです。BBCのニュースをコンパクトに紹介しつつ、語彙の解説などもついていて親切です。語彙も比較的やさしめ。音声のスピードはネイティブに比べて少し遅い程度。中級者向けだと思います。

TED Talkは、15分程度の長さのスピーチがたくさん提供されています。テーマは非常に多岐に渡っていて、しかも個々のスピーチはとにかくレベルが高く、あきません。プレゼンの教材としても使えそうなのもよくあります。そして、カンファレンスのスピーチなので比較的聞き取りやすい話し方で話している点も良いと思います。ちょっとニュースだけじゃ飽きてきたという中級者向きだと思います。

2. 音声を聞きながらシャドーイングする(インプット:リスニングの練習)

入手したスクリプトを印刷しておきます。そして、1で入手したpodcastをiPodで聞きながら、同時にスクリプトも読みます。音声だけでは難しくても、スクリプトがついていると、かなり理解できると思います。

ここの練習としては、リスニングだけでなくシャドーイングという音声に続いて一緒に話す練習をするとよいと思います。シャドーイングをやる時は、続いて話さないといけないのでより注意深く聞くようになります。繰り返しやると、リスニング力の向上が自覚できるようになると思います。

私は通勤途中によくシャドーイングをしています。あまり大きな声でやると怪しい人だと思われます。恥ずかしがらずに(ただし少し小声で)やりましょう。

3. 音声を聞きながらスクリプトを音読する(インプット:リーディングの練習)

リスニングやシャドーイングだけでなく、音声を聞きながらの音読なども組み合わせてやるとよいと思います。

音声を聞く理由は、文章の順番に意味を取る練習をするためです。日本人の多くは学校の英語の影響で、英語を見ると文章を解体して、日本語に翻訳する傾向にありますが、はっきりいうとスピードが落ちるのでお勧めできません。英語は英語の順番で理解すべきです。それを強制的にやるためにも音声を聞きながら読んだ方がよいと思います。

4. 英語で感想文を書き、英語学習者のSNSに公開する(アウトプット:ライティングの練習)

ここからがこのエントリのハイライトですよ。英語を聞いたり読んだりインプットしだけで満足しちゃいけません。英語はコミュニケーションの道具です。アウトプットもできないと英語スキルは不完全です。

アウトプットする時のお勧めとしては、自分の日記に書いて終わりにせずに、誰かに伝えた方が練習としても効果は高くなります。レベルがある程度にならないと恥ずかしいとか言う人いますけど、気にせずどんどん出してください。はっきり言って自分の語学力が低いから文章を人に読ませたくないなんて言ってるの日本人だけです。国際会議とか行くと、発音がめちゃくちゃでもインド人や中国の人が積極的に活躍していますよ。不完全なものでも出しましょう。どんどん人にさらして相手の反応を見ないと、改善サイクルが回っていきません。

ここで日記を書く場として、お勧めしたいのが英語学習に関心のある人がいる場所に文章をさらすことです。おすすめは以下です。
アルコムワールドは、アルクという英語教材を販売している会社がやっているSNSですが、アルクの教材を買わなくても利用できます。実は、私はあまり英語にお金をかけない主義なので、アルクの教材を買ったことありません ^^; 

アルコムワールドはクラブというコミュニティがたくさんあって、活発に議論が行われています。私は、「英語記事を読む(聞く)会」というのに所属してて、ここに書かれている記事を読んだり、自分でも記事を書いたりしています。翻訳など英語を武器に仕事している人とかも混じっており、非常にレベルが高いので、彼らのやり取りを見るだけでもモチベーション維持の効果があります。

後者のlang8は、多言語対応の相互添削型SNSです。 英語や日本語だけじゃなく、アラビア語やロシア語やら、あらゆる言語の学習者がお互いの日記を添削しています。アルコムワールドがほぼ日本人だったのに対し、こちらはいろんな国籍の人が参加しています。

lang8が少し変わっているのが相互に添削をすること。相互添削が原則なので、こちらの日記を添削してもらう代わりに、日本語を学んでいる人の日記も添削してあげるとよいでしょう。たくさん添削してあげるとこちらも添削してもらいやすくなります。 いろんな人がお互いの学習を支援しあうという形態は、非常にインターネット的でもあり、私はすごいしっくり着ています。

ただし、語学を教えるのが専門の人が添削してくれるわけでもないので、添削の質は期待しないほうがいいかもしれません。「ネイティブから見て自然な書き方になっているか?」という使い方をするのがベターだと思います。

5. 読んだ記事について誰かと話す(アウトプット:スピーキングの練習)

ここは私はあまりやっていませんが、スピーキングの練習として読んだ記事について話すことも入れるとパーフェクトだと思います。日記を書いて添削してもらった後にやると、トピックについて理解できているので、スムーズに会話できると思います。

英語で話す相手がいない人は、最近はやりのSkype 英会話などを使うと良いと思います。Skype英会話だと、こちらからチューターに話題を提案すれば、記事について話できると思います。ただし、チューターが記事を読んでいないので、記事の内容を説明する手間がありますが、それ自体も簡潔に話す練習だと思えばよいのではないでしょうか?


---

いかがでしたか?英語の勉強の仕方は千差万別です。ここに書いているやり方は、お金がかからないし、楽しいので私は気に入っています。よかったら皆さんの勉強法も教えてください。