legoboku.jp

2011/10/10

#tddbc TDD Boot Camp 東京 for C++ に参加してきました

C++プログラマ向けのTDD Boot Campに参加してきました。「ブログに書くまでがTDDBCです」とのことなので、参加報告をまとめておきます。

■TDDC BootCampとは？

TDD Boot CampはTDD（テスト駆動開発）について、実習形式で手を動かして体得することを目的とするイベントです。全国各地で開催されているようです。
http://devtesting.jp/tddbc/

今回のプログラミング言語はC++でしたが、他の開催日は言語を複数やることが多いようです。例えば、11/5の横浜はJava(JUnit4)、Ruby、C (cunit)、C++ (Emacs+cppunit/Google Test)、Groovy(Spock)、PHP(PHPUnit)、JavaScript(QUnit)と多彩です。
http://devtesting.jp/tddbc/?TDDBC%E6%A8%AA%E6%B5%9C

■TDD Boot Camp 東京 for C++のプログラム

講演と実習＆レビューの繰り返しでした。みんなが煮詰まってきたら、適度なタイミングで講演やら休憩が入って助かりました。時折、チーム間のレビューや、全体でのレビューが入り、頭の中を整理しながら、課題に取り組めるように工夫されていました。

詳しくはイベント告知ページを参照。

09:30～10:00 開場
10:00～10:05 会場説明
10:05～10:35 中村薫さんによる講演(@kaoru)
10:35～12:00 実習＆レビュー
12:00～13:00 お昼休憩
13:00～13:40 井芹洋輝さんによる講演(@goyoki)
13:40～15:00 演習
15:00～15:30 レビュー、休憩
15:30～17:15 演習（続き）
17:15～18:15 レビュー、ふりかえり
18:15～18:30 和田さんによる総括と締めの講演(@t_wada)
18:30～お片づけと懇親会

■TDDの演習課題
いわゆる探索の問題でした。

TDD Boot Camp 東京 for C++ 課題

View more presentations from Takashi Imagire

近いうちにどんなコードになるか公開しますので、お楽しみに。

■講演：TDDBC中村ヘようこそ（by @kaorun）

Welcome tddbc

View more presentations from かおるなかむら

TDDをやる目的や考え方が良く分かる講演でした。内容の詳細に関してはslideshareやブログ記事を参照してください。講演の中で特に心に残ったのは以下ですね。

バージョン管理、タスク管理、自動化されたテストはプログラマの躾である。
これらの躾をする目的はプログラマの心と体の健康を保つこと。

非常に納得感がありました。
私の場合、業務でオブジェクト指向設計でテストしやすい構造にしていますが、今思うと「心と体の健康を保つ」を狙っていたように感じます。テストをしやすい設計にすると、単体テストでロジックのミスを検出できるので、実機でのシステムテストが楽になって心が穏やかな状態で開発できますから。

おそらくはTDDもインタフェースを意識した設計にすることを目的にしていると感じているので、オブジェクト指向設計と似た効果を狙っているんじゃないか？と思いました。

ここ1年は「開発者の心と体の健康を保つ」は自分の中のキーワードとして心に留めておきます。

■講演：TDDネクストステップ（@goyoki）

テスト駆動開発入門ネクストステップ

View more presentations from H Iseri

こちらはTDDを実践するときの知識や、今後学習を進めていく上で有益な情報がつまっていました。

テストコードもメンテナンスプログラムである以上、プロダクトコードと同じように保守性を高く保つ必要があるという点が非常に有益でした。テストコードの保守性を上げるには、プロダクトコードを設計するときの同じ考え方で設計することが重要になるようです。

また、なるべくテスティングフレームワークの機能を活用することだと感じました。googletestを調べた感じでは、フィクスチャやParameterized Testなどの機能をうまく使うと、重複を排除できて、テストコードを書く量自体も減らせそうです。

講演中にTDDを学ぶ上での良書を紹介してくれていました。特にお勧めは以下の3つ。

テスト駆動開発入門

ケントベック

ピアソンエデュケーション

発売日：2003-09

ブクログでレビューを見る»

xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler))

Gerard Meszaros

Addison-Wesley Professional

発売日：2007-05-31

ブクログでレビューを見る»

レガシーコード改善ガイド (Object Oriented SELECTION)

マイケル・C・フェザーズ

翔泳社

発売日：2009-07-14

ブクログでレビューを見る»

レガシーコード改善ガイドは積読しているので、読みきります。

■講演：〆の講演（by @t_wada)

さすがの @t_wada さんで、聴衆が引き付けられる、すごい力がありました。Twitterでめっちゃつぶやいたので、すごい心に残ったものを少し挙げておきます。私が書きとめたものなので、実際に話しした内容とは多少違ってるかもしれません。

なぜTDDをやるのか？自分が完璧ではないと知っているから。最初から思い通りにできるほど、対象は簡単ではない。素早く対処にちか付きながら、フィードバックを得ながらじりじりと動いて行く。
少しずつ動く開発の必要生を感じているからTDDをやる。テストは目的ではなく手段。ソフトウェア工学的なメリとではなく、書いたコードに自身を持つため。テストに通ったなら、少なくとも自分が考えた通りには動いている。
テスト設計は間引きの考え方。どれだけのテストをやれば全部テストしていると言えるかを考える。
知識のインデックスを作る。グラフ、経路、重み。全部知るのではなく、探したいものに対してインデックスを貼っておくことがスキルの差別かにつながる。
テストが無いコードがたくさんある。その現状に対してどう戦うか？その際にヒントになるのはレガシーコード改善ガイド。どうやって自信のある領域を作って行くか、そのヒントが詰まっている。
祈りではなく自信を。新規に書くときはテストコードを書こう。たくさん本を読もう。考え方を知ろう。書籍の中でよく参考文献に上がっている本を読む。
TDDはスキルである。才能ではない。テストコードを書けばばくほどうまくなる。

@t_wada さんの講演を聞いて心構えは十分だと感じました。あとは実践ですね。業務の品質改善ネタにテストが入っていたので、レガシーコード改善ガイドなどを片手にテストに取り組んでいこうと思います。

■全体を通しての感想

イベント中から懇親会にかけて、組み込み屋さん、ゲーム屋さんといろいろ話しました。皆、業務ではテストコードのないレガシーコードにまみれていて、リリース間近は踏んだり蹴ったりの状態になっているようです。自動化されたテストに対する期待感は高いよう。

だからこそ、TDDBCに疑問を解決するために皆さん集っているようです。その期待に対して、TDDBCはTDDの考え方や実践的なスキルを経験する場として期待にこたえていると感じました。一方で、TDDBCで扱える内容だけで、業務のプロダクトコードに対応できるかというとそうではないと思います。もっと仕様やコードが複雑だし、金も時間もないし、絶望的な状況は多いです。

TDDBCはひとつのきっかけ。もらったヒントを手に、それぞれ自分の戦場でいかに戦うかは自分次第でしょう。

といいつつ、私自身は参加して満足です。しばらく自動化されたテストは自分の中の大きなテーマに設定しているので、継続的に学習は続けようと思います。

■Stay Tuned
近いうちにTest Driven Development for Embedded Cの読書会をやろうと思います。
時期が決まれば仲間を募集したいっす。

Test-Driven Development for Embedded C (Pragmatic Programmers)

James W. Grenning

Pragmatic Bookshelf

発売日：2011-05-02

ブクログでレビューを見る»

2011/09/25

#etrobo ETロボコン東京地区大会モデリングワークショップに行って来た

9/24（土）に開催されたETロボコン東京地区大会Bブロックのワークショップに参加しました。良い話がいろいろ出たのでブログに書いておきます。

個人的なハイライトは「気になったモデルについてQ&A」でした。審査員と全員で対話的にモデルについて議論する良いセッションでした。時間が足りなさすぎたのが少し残念。

アジェンダ

審査内容の説明 - ニューウェイブシステム(株) 斎藤司氏
モデル審査結果の傾向 - (株)オージス総研阿左美勝氏
気になったモデルについてQ&A - (株)オージス総研田邉浩之氏
PMレポート共有について - (株)建設技術研究所東谷上氏

審査内容の説明 - ニューウェイブシステム(株) 斎藤司氏

公式サイトのモデル審査基準の紹介がありました。公式サイトに書いていますので、ここでは省略します。
http://www.etrobo.jp/2011/gaiyou/model.php

モデル審査結果の傾向 - (株)オージス総研阿左美勝氏

審査後に審査員同士の振り返りで挙った良いモデルとダメなモデルについて紹介がありました。

ここに紹介されている通り、まだUMLの文法として基本的な間違いをしているチームはまだまだ多いようです。こういうので減点はつまらないので、レビューで取り除くことをオススメします。

書き方
悪い例

UMLの文法として不備がある。

（例）多重度のないクラス図、開始状態のないステートマシン図、など。

印刷物として読み取れない。審査基準にも図の見やすさは明記しているので、印刷物として読めないと減点対象。

（例）文字が小さい、背景の画像で関連が見えない、など。

機能
悪い例

アクターを「NXT」にしている。アクターはシステムの価値提供の相手なので、アクターとしてNXTは不適切。
ユースケース間の関係に間違いがある。includeにすべきところがextendになっている。
ユースケース記述が詳細すぎる。ユースケースは要件定義の段階の成果物なので、利用者視点で書くべき。

構造
悪い例

継承しているのにメソッドオーバライドしていない。親クラスにない振る舞いを子クラスにさせるため継承するなら、子クラス側でメソッドをオーバーライドさせる方が適切。
不適切な継承関係。

（例）制御クラスの子クラスがデバイスクラスになっている。

良い例

汎用性の高いクラスが増えて来た。いくつかの部品の組合わせで難所を走るクラスを作る傾向が増えて来た。

振る舞い
悪い例

ステートマシン図で手順を書いている。ステートマシン図は状態遷移を書くダイアグラムなので、手順を書きたいならアクティビティ図を使うべき。

トレーサビリティ
悪い例

クラスを導出された理由が分からない。
やる！と宣言した戦略や要素技術が構造や振る舞いに反映されていない。
モデル間の対応関係が分からない。

追加課題
良い例

理由を書いている。
定量化するようになった。

悪い例

並行性設計について動機や効果が書かれていない。
開発支援について効果のエヴィデンスがない。

オリジナリティ
悪い例

読み手に「どうモデルを見てほしいか？」について解説がない。

気になったモデルについてQ&A - (株)オージス総研田邉浩之氏

このセッションでは審査員が審査中に気になったモデルを例として挙げ、審査員からモデルの作者に質問したり、インタタラクティブにモデルについて理解を深める内容でした。

機能

例として挙ったのは以下のようなユースケース図です。モデルを書いたチームがワークショップに参加していなかったので、審査員からの質問はできませんでした。

まず、本部審査員の鈴木氏から、includeやextendが使われているユースケース図の読み方について解説がありました。ユースケース図は英語圏で作られているので、ユースケース間の関係であるextendやincludeは英語の文章として読むと理解しやすいそうです。つまり、矢印の根元が主語（Subject）で、矢印の種類は述語（Verb）、矢印の先が目的語（Object）です。

（英語）「ベーシックステージを走る」 extends「コースをライントレースする」

（日本語）「ベーシックステージを走る」は「コースをライントレースする」を拡張する。

（英語）「ボーナスステージを走る」 extends「コースをライントレースする」

（日本語）「ボーナスステージを走る」は「コースをライントレースする」を拡張する。

~~（英語）「PID制御の旋回値を計算する」 includes「コースをライントレースする」~~
（英語）「コースをライントレースする」 includes 「PIDの旋回値を計算する」

~~（日本語）「PID制御の旋回値を計算する」は「コースをライントレースする」を含む。~~
（日本語）「コースをライントレースする」は「PIDの旋回値を計算する」を含む。

まだちょっと堅いので、もっと柔らかい表現で、どういう意味かを解釈します。例えば、includeとextendは以下のような関係になると言えます。

「PID制御の旋回値を計算する」は「コースをライントレースする」を含むので、「PID制御の旋回値を計算する」がないと「コースをライントレースする」が動かない。
「コースをライントレースする」は「PIDの旋回値を計算する」を含むので、「PIDの旋回値を計算する」がないと「コースをライントレースする」が動かない。
「ベーシックステージを走る」は「コースをライントレースする」を拡張したものなので、「ベーシックステージを走る」がなくても「コースをライントレースする」は動く。

このincludeとextendの関係をうまく使って、ユースケースを開発の単位とすれば、ユースケースを見積もりやマネジメントに使えるとのことです。

ちなみに上記の「コースをライントレースする」、「ベーシックステージを走る」、「ボーナスステージを走る」の関係はあくまで例です。チームの捉え方次第なので、上記の例のとおりでなければいけないわけではありません。

なお、extendを書いた場合はどの条件の時に拡張されるのか拡張点を書く必要があります。また、includeについてもどの場合にinclude先のユースケースが実行されるのかユースケース記述に書く必要があります。

構造

悪い例

として挙っていたのが以下のクラス図です。

クラスが継承関係にあるのに子クラスで「走行する」メソッドがオーバライドされず、別のメソッド「走行を開始する」が定義されていました。書いた本人に聞いてみると、結局は書き間違いだったそうですが、これで減点食らうのはちょっと損だと思いました。気をつければ気付くはずなので、作っている時にチェックすべきだと思います。

良い例

良い例として挙っていたのが以下のクラス図です（属性と操作は省略）。

ちょっと複雑なので、このクラスの意図を示しておきます。

「走行戦略」が一位に決まる単位をコースの最小単位である「経路」とする。
「走行戦略」には複数の「走法」が順序付きで含まれている。
「走法」が切り替わるタイミングは「走法切替条件」で決まる。
「走法」はもっと細かい制御の単位である「アクセル操作法」と「ハンドル操作法」に還元できる。

このクラス図で良い点はまず特定の難所に依存しないような作りになっていることです。部品の組合わせで、全ての難所は走ることができると示しています。

クラス図の例で言えば、コースは最終的には「アクセル操作法」と「ハンドル操作法」の制御量の違いに還元できると言っています。こうなっていると「アクセル操作法」と「ハンドル操作法」という低いレベルの部品は来年以降も再利用できます。

「経路」、「走行戦略」、「走法」については、その年のコースの特徴に依存して範囲を定義する必要がありますが、「アクセル操作法」と「ハンドル操作法」という部品をどう使うかを考えればいいわけです。ただし、実際にはコースの似た部分はあるので、「経路」、「走行戦略」、「走法」について全く再定義することはなく、部分的な流用は可能でしょう。

振る舞い

振る舞いで悪い例として挙ったのが以下のようなステートマシン図です。

作り手の意図としては、おそらく以下の通りだと思います。

ベーシックステージには、いくつかの区間があり、区間を順番に走る。
それぞれの区間を走っている時にコースアウトすると、リカバリ走行に切り替わる。
コースに復帰できると元の区間走行に戻る。

ただ、このモデルはリカバリ走行中にコース復帰した場合に、どの状態に戻るかは判別できません。

私自身はこのモデルの話があった時にリカバリ走行中を外に出し、履歴疑似状態でコース復帰した時に元の状態に戻ることを示せば良いのかなと思いました。

一方で、会場から「復帰の仕方は区間によって違うと考えられるので、区間ごとに内部状態を作って、そこでリカバリをやる必要があるのではないか？」という意見もありました。確かに、区間ごとにリカバリの振る舞いが異なるなら、リカバリを一緒にしてしまうのは問題ですが、本当にこの要求は正しいのかは結論が出せませんでした。

要求

要求では２種類のモデルが紹介されていました。

要求図を使って要求同士の関係を書いている。
ソフトウェア品質特性(ISO/IEC9126)の分類に対して、ETロボコンならでは品質目標を書いている。

どちらのアプローチでも良いと思います。ただ、要求が満たされる合格判定基準を定量的な指標で書くのは必須です。

全体を通じての所感

ETロボコンも10年続いて、成果物が参加者全体に継承されているため、昨年度の成果物の書きっぷりを見ることで成果物の質の底上げはなされていると感じています。

ただ、初参加組の人は、まだまだUMLの基本的な書き間違いが多いチームが多いようですし、常連組についても構造が貧弱、トレーサビリティが取れない、意図と違うモデルを書いているなどの毎年同じ指摘が挙っているようです。

チームは継続していても、人が入れ替わっている以上、これらの指摘がなくなることは難しいと思いますが、ワークショップでもっと上のレベルの議論ができるようになればいいと思いました。

ちなみに、審査員の方とも話しましたが、モデルシート全体のレベルは上がっても、構造のレベルは上がっていないとのこと。私も同感でした。モデリングの中でも特に構造は難しいと思っています。5〜10年継続してトレーニングが必要で、熟練したメンターに適切にフィードバックをもらわないと構造モデリングのスキルはなかなか上がらないと思いました。ETロボコン参加者の構造モデリングの質を上げることは、最大のチャレンジじゃないかと思います。

#etrobo ETロボコン東京地区大会Bブロックの結果

今年はエントリーしてませんが、後輩の応援に行って来ました。

まずは、東京地区大会Bブロックの結果から。ワークショップの模様などは別途書きます。

東京地区大会Bブロックの結果

総合部門

1位チームSUPRAパンダ
2位リターンオブタムラ
3位芝浦雑技団
4位 eRush
5位松浦La
特別枠※ ARASHI50

※今年は東京地区大会の10周年でその記念の特別枠として１チームがチャンピオンシップ大会に参加できるようです。

モデル部門

1位田町レーシング
2位チームSUPRAパンダ
3位リターンオブタムラ

競技部門

1位芝浦雑技団

合計リザルトタイム：31.8秒
インコースリザルトタイム：6.1秒（ベーシックステージ36.1秒、シーソーシングル・階段・ガレージイン成功）
アウトコースリザルトタイム：25.7秒（ベーシックステージ35.7秒、ルックアップゲート成功）

2位チームSUPRAパンダ

合計リザルトタイム：78.8秒
インコースリザルトタイム：44.6秒（ベーシックステージ44.6秒）
アウトコースリザルトタイム：34.2秒（ベーシックステージ44.2秒、ルックアップゲート成功）

3位松浦Lab

合計リザルトタイム：81.2秒
インコースリザルトタイム：45.4秒（ベーシックステージ45.4秒）
アウトコースリザルトタイム：35.8秒（ベーシックステージ45.8秒、ルックアップゲート成功）

所感

後輩チームがモデルと競技で1位を取ったので満足でした。田町はアウトコースが完走できなくて残念だった。また頑張ってほしい。

モデルの感想ですが、個々のチームのモデルの底上げはなされているように思いますが、やはり基本的なUMLモデルの書き方に間違いがあったり、クラス図の構造がいまいちなチームは散見されました。まだまだ東京地区は良くなって行く余地はあると思います。

また、競技面では全国の猛者と比べると、ちょっと弱い感がありますね。全国ではベーシックステージ25秒で、全難所クリアとかがいるそうなので、今のままでは競技で上位に行けません。東京連合でてこ入れしましょう。

#cook4geeks Cooking for Geeks by オライリージャパン×クックパッドに参加してきた

オライリージャパンとクックパッドの共同で開催された「Cooking for Geeks」というイベントに参加してきました。なかなか楽しいイベントだったのでブログにも感想を書いておきます。このような場を開催してくれたオライリー／クックパッドの両者に感謝！

Cooking for Geeks？

このイベントは9月にオライリーから出版された「Cooking for Geeks」という料理本を記念してのイベントです。

書籍の紹介や目次を見ていただければ分かりますが、料理の科学的な仕組みを紹介しており、内容は普通の料理本とは少し違ってます。

そして翻訳者の方もおっしゃってましたが、オライリーから出てる本だからかコンピュータ書に通じるところが随所にあります（笑）。「ハロー、キッチン！」「キッチンの初期化」、「O(1)（定数時間）での検索」とか。なかなか変わってます。

Cooking for Geeks ―料理の科学と実践レシピ (Make: Japan Books)

Jeff Potter

オライリージャパン

発売日：2011-09-22

ブクログでレビューを見る»

イベント概要

日時：2011年9月22日（木）：19：30～20：30（開場19：00、閉会後懇親会）
会場：クックパッド株式会社
主催：クックパッド株式会社、株式会社オライリー・ジャパン
内容：

発表

「食品の効果的な加熱方法」水原文（『Cooking for Geeks』翻訳者） - @bmizuhara
「情報科学からの食文化への挑戦」福地健太郎（明治大学特任准教授） - http://fukuchi.org/, @kentarofukuchi

ライトニングトーク

奥一穂（株式会社ディー・エヌ・エー） - @kazuho
佐々木達也（クックパッド株式会社） - @sasata299
佐々木抄子（株式会社ドワンゴ） - @shokos
塩谷啓（株式会社ドワンゴ） - @kwappa
高木誠（フリーランスプログラマ） - @2celeb
舘野祐一（クックパッド株式会社） - @hotchpotch
中村裕美（明治大学） - YouTaste | 電気で食事をもっと楽しく．
松野徳大 - tokuhirom's Profile - GitHub

参考：http://www.oreilly.co.jp/editors/archives/2011/09/ann-cooking-for-geeks.html

発表への感想
「食品の効果的な加熱方法」水原文（『Cooking for Geeks』翻訳者） - @bmizuhara

トップバッターは翻訳者の方。
このイベントの趣旨をあまり理解せずに参加してしまった僕は、Webとかプログラミングがらみの話をするのだとてっきり思っていたので、いきなり加熱方法とか化学的な話でぶっ飛びました。

話の内容は加熱の目的（おししくするため、食品衛生のため）、肉のコラーゲン量に応じた適切な加熱温度、ごはんを加熱する時に起こる科学変化、ごはんをおいしく保温する方法などなど。料理をする人がI型コラーゲンの変成とかメイラード反応を知っておく必要あるがというと疑問だけど、肉の加熱については皆知っておくべきじゃないかなと。肉を調理したい時って火加減大事だし。

ちなみに水原さんの発表内容は「Cooking for Geeks」の第4章「時間と温度: 料理の主要変数」に書いているようです。

（発表）「情報科学からの食文化への挑戦」福地健太郎（明治大学特任准教授） - http://fukuchi.org/, @kentarofukuchi

料理の発展に科学は大きく寄与してることは、まー周知の事実ですが、発表者は情報科学分野から食文化に貢献したいのだそう。
情報科学分野からの貢献って身近な例では、クックパッドとか食べログとか。もっと大掛かりなやつはホームオートメーションの特にキッチン周りとかもそうだとか。キッチンにディスプレイがあって、レシピが検索できるとかね。

で、発表者が提唱しているのはLaser Cookingというものだ。まな板の上にカメラを置いて、画像処理技術を使って、ベーコンの脂身だけに正確にレーザー光を照射して焼くのだそうだ。
他にもクッキーにちょっとした画像を焼き込んだり、立体造型のお菓子を作ったり。最初ばかばかしいと思ったけどw 、食品メーカーは全然興味しめすんじゃないかと思った。

いちおうベーコンを焼くネタは論文も書いているよう。
Laser-Cooking:レーザーカッターを用いた自動調理法の開発
http://ci.nii.ac.jp/naid/110008583670

(LT) 奥一穂（株式会社ディー・エヌ・エー） - @kazuho

楽しみとしての自炊を提案してました。外食は原価の3倍くらいするので、外食で高いものを食べるのは損とのこと。自炊だからこそ外食で食べると高くなるような良い食材を使うといいとのこと。ポイントは良い食器を使うこと。

僕は生活のための自炊派なので、考え方が違うなーと思いましたが、良い食材を選んで少し贅沢感を味わうのもいいかなと思った。

(LT) 佐々木達也（クックパッド株式会社） - @sasata299

唐揚げの話をしてました。唐揚げを好きと言ったのに、実は立田揚げの方が好きで、唐揚げはそれほどじゃないとか。どっちだよ！と数回突っ込んでしまいました。

(LT) 佐々木抄子（株式会社ドワンゴ） - @shokos

スピリチュアル自炊の話をしてましたが、展開が早くてよく分かりませんでした。でも爆笑しました。Haskellでスピリチュアルプログラミングをされているそうです。
あの「お前が言うんならそうなんだろう　お前の中ではな」って画像はちょくちょく見かけるけど、ネタは何？

(LT) 塩谷啓（株式会社ドワンゴ） - @kwappa

鶏ハムとか簡単でお得なレシピ紹介してました。あれはそのうちやってみたい。
ちなみに料理できると結婚できると断言してました。そうなのか。

(LT) 高木誠（フリーランスプログラマ） - @2celeb

自炊を効率的にやるための工夫を紹介してました。
一度に調理して、冷凍しておいて、日々の弁当作りを素早くやるとか。あとは、1つの調理方法のテンプレートで、具材や調味料を変えてみて楽しむとか。
僕の感覚は少しこの人近いかなと思いました。ちょっと弁当は試してみたい。

(LT) 舘野祐一（クックパッド株式会社） - @hotchpotch

残念ながらお休み。代々の型が「Ruby on Railsは炊き込みご飯のパクリ」という納得感のある主張をされていました。会場爆笑。

(LT) 中村裕美（明治大学） - YouTaste | 電気で食事をもっと楽しく．

食材や飲料を飲食する際に電気を流すことで、「電気味覚」と呼ばれる新しい味覚体験を与えるという提案でした。
ドリンクに電極を指して、飲みながら電気刺激で味にアクセントをつけるとか。かなりぶっ飛んでるw
なかなか誰特な印象はありましたが、興味はわきました（笑）少し試してみたい。
あと、電気との食べ合わせとかも調べているそう。

ちなみにググってみると「2010年度未踏IT人材発掘・育成事業未踏ユース」のに採択されているそうです。
http://www.ipa.go.jp/jinzai/mitou/2010/2010_1/youth/gaiyou/gm-6.html

(LT) 松野徳大 - tokuhirom's Profile - GitHub

とにかく高い食材を食い、高い酒を飲めとのこと。

日常的にはどうかと思うけど、高い日本酒とかは同感。たまに飲みたい。

懇親会の様子

冒頭の写真の通り、書籍に載っている変わった調理法の料理を食べつつ、ビールを飲んでいろいろな方とお話しました。なかなか楽しい会でした。

2011/09/21

Eclipseでgoogletestを使う方法（Mac OS X SnowLeopard編）

Emacs + gccで開発もいいですが、IDEも使ってみたいのでEclipseでgoogletestのテストを実行する方法を調べてみました。

なお、前回のエントリでgoogletestのライブラリを作成したり、テストを行うサンプルコードを作成する手順を紹介しています。そちらの手順を実施していない場合は、前回のエントリを参照してください。

環境

Mac OS X: 10.6.8（Snow Leopard）
gcc: 4.5.4
Eclipse: 3.7.0
Eclipse C/C++ Development Tools: 8.0.0

手順

C++のプロジェクトを作成し、ソースファイルを追加する
プロジェクトにライブラリを追加する
プロジェクトにインクルードパスを設定する
ビルドし、テストを実行する

(1)C++のプロジェクトを作成し、ソースファイルを追加する

メニューの File -> Project -> C/C++ Project でプロジェクトで作成します。プロジェクトの種類は「Executable -> 空のプロジェクト」で良いと思います。これは、実行ファイルを作るプロジェクトで、プロジェクト内にはファイルを追加しないという意味です。

ここにmain関数があるソースファイルおよびテストコードを追加します。昨日のエントリにサンプルを紹介しているので、そちらを参照ください。

(2)プロジェクトにライブラリを追加する

プロジェクトを右クリックして、Propertiesを開きます。

開いた画面の中から「C/C++ Build -> Settings -> Mac OS X C++ Linker -> Libraries」を選んでライブラリの設定画面を開き、以下を設定します。

Libraries(-l)

gtest
gtest_main

Library search path(-L)

gtestのライブラリがあるディレクトリパス

ライブラリの名前は "libgtest.a" と "libgtest_main.a" ですが、頭の "lib" とお尻の ".a" はつけません。これはgccの慣習です。

(3)プロジェクトにインクルードパスを設定する

Propertiesの画面の「C/C++ Build -> Settings -> GCC C++ Compiler -> Includes」を選んでインクルードパス設定画面を開き、googletestのヘッダファイルのあるパスを設定します。

場所は <googletest>/include です。<googletest> はgoogletestの配置場所です。自分の環境のものと置き換えてください。

(4)ビルドし、テストを実行する

これで設定は完了です。

メニューの「Project -> Build All or Build Project」をクリックし、ビルドします。エラーが出なければ成功です。

さらにメニューの「Run -> Run As -> Local C/C++ Application」をクリックすると、実行ファイルが実行され、テスト結果が表示されます。テストが通っていれば成功です。

2011/09/20

gccとCMakeでgoogletestをビルドする方法（Mac OS X編）

Webを調べていると、googletestをビルドする際にVC++かXCodeを使う例が多かったので、IDEを使わないでできる方法を調べてみました。なお、googletest自体の説明は割愛します。

環境
私の環境は以下の通りです。

Max OS X 10.6.8（Snow Leopard）
gcc 4.5.4
cmake 2.8.5

公式のREADMEには cmake 2.6.4 以上が必要とありますが、gccのバージョンは明記されていませんでした。

手順

svnリポジトリからgoogletestを取得する
cmakeでgoogletestをビルドする
main関数を持つソースファイルを作成する
テストコードを作成する
g++でテストコードでビルドする
テストを実行する

(1) svnリポジトリからgoogletestを取得する

適当な場所に配置します。

svn checkout http://googletest.googlecode.com/svn/trunk/ gtest-svn

(2) cmakeでgoogle testをビルドする

cmakeを実行するディレクトリも適当な場所で良いです。 {GTEST_DIR}はgoogletestのあるパスに置き換えてください。 libgtest.a と libgtest_main.a ができれば成功です。

mkdir mybuild
cd mybuild
cmake ${GTEST_DIR}
make

なお、ビルド関係はREADMEが参考になります。

(3) main関数を持つソースファイルを作成する

以下のソースファイルを参考に、main関数のあるソースファイルを作成します。

http://code.google.com/p/googletest/source/browse/trunk/src/gtest_main.cc

ファイル名はtestmain.ccとしました。ちなみに必ず以下の順に呼ばないといけないようです。

testing::InitGoogleTest(&argc, argv);
RUN_ALL_TESTS();

#include <iostream>

#include "gtest/gtest.h"

GTEST_API_ int main(int argc, char **argv) {
  std::cout << "Running main() from testmain.cc\n";

  testing::InitGoogleTest(&argc, argv);
  return RUN_ALL_TESTS();
}

(4) テストコードを作成する

テストコードを作成します。ファイル名はmytest.ccとしました。

#include "gtest/gtest.h"

TEST(firstTest, abs)
{
  EXPECT_EQ(1, abs( -1 ));
  EXPECT_EQ(1, abs( 1 ));
}

(5) g++でテストコードをコンパイルする

コンパイルする時はgoogle testのヘッダファイルがあるディレクトリをインクルードパスに入れる必要があります。また、cmakeでビルドした時にできたライブラリも含めてビルドします。

なお、以下のコマンド中の testmain.cc はmain関数が入っているファイル、mytest.cc がテストコードが入っているファイルです。また、{GTEST_DIR}はgoogletestが入っているディレクトリのパスに置き換えてください。

g++ -I{GTEST_DIR}/include testmain.cc mytest.cc libgtest.a libgtest_main.a -o mytest

(6) テストを実行する

できあがったバイナリを実行すると、テスト結果が表示されます。テスト結果がOKなら成功です。

2011/08/05

#SP_kayac 面白法人カヤックさん主催の「スマートフォンアプリエンジニアライトニングトーク交流会」に参加してきた

夏休み中に面白そうなイベントがあったので、面白法人カヤックさん主催の「スマートフォンアプリエンジニアライトニングトーク交流会」行ってきました。ちょろりと参加報告を書いておきます。

■面白法人カヤックとは？
http://www.kayac.com/

Webサービス/スマートフォンアプリetcの受託開発やら独自サービス展開をやっているそうです。サイトが大学生ノリで、良い意味で変な会社ですね。業績も順調に伸びているようです。

LT見てて知ったんですが、

知り合いの元組み込みソフト開発者で国産JavaScriptライブラリuupaa.jsの作者であるスーパーハッカー @uupaa さんやら、
メーカーの研究部門出身の人がいたり、
元組み込みの人いたり

純粋なWeb系の人だけじゃないようです。

■スマートフォンアプリエンジニアライトニングトーク交流会とは？
スマートフォンのアプリを開発しているエンジニアが集まって、LTやったり、飯食ったりしながら情報交換するゆるい会でした。

アジェンダは以下の通り。

” ナカマップの実装について ”, 大塚雅和さん（@maaash）, カヤック
”Reengoの技術ってどんななの？”, 村瀬大輔さん, カヤック
”EncountMeのできるまで”, 堤修一さん, カヤック
”スマートフォンアプリ開発のクロスプラットフォーム戦略”, 塩屋啓さん（@kwappa）, dwango

詳しくはサイトを参照してください。

■ナカマップの実装について
http://maaash.jp/lab/bowls-smartphone-lightning-talk/#landing-slide

ナカマップというのは、複数人のお友達で位置情報を共有したり、リアルタイムにグループチャットをできるiOS/Androidアプリとのことだそうです。

今回の発表は、リアルタイムなクライアント／サーバ間通信の工夫についてでした。

過去のナカマップでは、クライアントから定期的にサーバに定期的にポーリングする方式をとっていたそうですが、これではポーリング周期分遅れるという問題があったそう。

何度かの改善を経て今は、サーバとのコネクションは接続しっぱなしにして、イベントがある度にサーバからレスポンスをプッシュしてもらう形式にしたそうです。子のメリットは、リアルタイム性が高くて、サーバの負荷が低いとのこと。

発表中に、「multipart/mixed方式」とか「diggが提案した」というようなことを話していたと記憶していますが、ググってみると以下のブログを発見しました。
http://about.digg.com/blog/duistream-and-mxhr

diggの人はこの技術をMXHR (short for Multipart XMLHttpRequests)と読んでいるそうです。

今考えているアプリで複数のクライアント間でリアルタイム通信をやる必要があって、実現方法を検討していたので、ちょっと良い話聞けたなと思いました。あまりよく分かっていないので、ちらっと調べてみます。

ちなみに、懇親会の時に聞きましたが、いわゆるpush型の通信としてはC2DMというのもあるそうです。

■Reengoの技術ってどんななの？
Reengoは電話番号なしにfacebookの友達に電話がかけられるアプリだそうです。

この発表ではVoIPの待ち受けの実装について話していました。

待ち受けはアプリでは実装しておらず、OS自体にVoIPの通信を待ち受ける機能が存在するらしく、単にイベントハンドラを登録して待てば良いとのこと。

実装は以下の通り。クロスプラットフォーム開発のために可能な限り、C言語で書いているというのが興味深かったです。

クライアントのロジックはC言語
UI周りはネイティブ（iOSの場合はObjective-C、Androidの場合はJava）
サーバサイドはPerl/Node.js

■EncountMeのできるまで
EncountMeはスマートフォンで、いわゆる「すれ違い通信」ができるアプリだそう。

位置情報をサーバに蓄積して、マッチングして、「○○さんとすれ違いました！」とユーザに通知する機能があるとのこと。ただし、このアプリ電気をくいすぎる実装になっているそうで、アプリ提供は8月で終了するそう。でも、いろいろ反省点を活かして、次のゲーム開発に活かすそうです。

アプリとは関係ないですが、アプリ出すまでの過程が面白かったです^^; 発表者の方はたしか組み込み系の開発から転職組だそうで、転職したすぐはWeb系のプログラミングがまったくできず、戦力外通告を一度受けたとか。自分より若い人がバリバリ開発している中、PHPの本を読む毎日だったそうですが、ふんばってiPhoneアプリの勉強をして、アプリ開発者として今の立場を築いたとか。思わず拍手してしまいました。

■スマートフォンアプリ開発のクロスプラットフォーム戦略

スマートフォンアプリ開発のクロスプラットフォーム戦略

View more presentations from kwappa

TitaniumとかPhoneGapとか、iPhone/Androidなどクロスプラットフォームなアプリが簡単に開発できると言われている開発環境の現状についての発表でした。

まず「同じアプリを作りたい」という場合の「同じ」の定義から入っていました。同じという場合に、機能（ユーザに提供する価値）、UI（見た目）、ソースコードの3つに分けられるとのこと。

機能とUIを分けた理由は、UIは違ってても同じ機能（ユーザに提供する価値）が同じであれば、同じアプリだろ？ってことだそうです。実際に僕も使っているジョルダンの乗り換え案内はAndroid版とiOS版で少しUIが違うそうです。

詳しくは資料を見ていただきたいですが、PhoneGapについてはパフォーマンスがいまいちだけどソースは共通にできるとのこと。スマートフォンの性能が上がれば問題なく使えるレベルになりそうという印象でした。

実際に使っていないので何とも言えませんが、こういうツールってバグが多いとよく噂を聞くので、眉唾な感じがしました。しかし、私は個人でアプリ作ろうとしているだけなので、切迫感はありませんが業務でやっている場合、予算握っている人はこの辺は切実なんでしょうね。。。

■おわりに

自分の中で企画を考えている段階で、まだアプリできていない状況なんですけど、実際にやっている人達の話を聞けてモチベーションが上がりました。そのうち作ったアプリについてLTしたい！

機会あればまたイベント参加しますね。

登録: 投稿 (Atom)