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英会話だと、こちらからチューターに話題を提案すれば、記事について話できると思います。ただし、チューターが記事を読んでいないので、記事の内容を説明する手間がありますが、それ自体も簡潔に話す練習だと思えばよいのではないでしょうか?


---

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

2011/11/16

#etrobo で勝つために、どういう考え方が必要なのか?


まずは競合チームは何を考えているのか?それに対して我々は何ものか?我々しか提供できない価値は何なのか?という考え方です。

それだけではトップ10は入れても、トップ3に入れません。

トップ3に入るために何が必要でしょうか?

最終的な評価を行っている人が、あなた達がやっていることはすごい価値がありますとどうやって言ってもらえるかを考えることにあると思います。

ETロボコンであれば、競技規約でリザルトタイムが一番短いやつが優勝って言っているので、リザルトタイムを短縮するためにどう役にたっているかを提示する必要があります。

それは、ETロボコンを横においておいて、自分達が普段作っている製品の価値を考えると分かりやすいと思います。

我々はソフトウェアをキレイに作っています。論理的にうまくいく事を検証し、裏取ってますと言ったところで、自分の製品を使っている人にとっては、「それが私に何の関係があるんですか?」になってしまいます。

難しいのは、自分達がやりたいこととどう折り合いをつけるか?それは非常に難しい問題で、考えていかないといけない課題だと思います。

自分たちがやりたいこと、皆に求められていることが大きく重なるポイントを考えるのが一番でしょうけど、それできたらそもそも苦労しないしw

2011/11/13

#CJP クーリエ12月号で朝食会@自由が丘をやりました

これで三回目です。

COURRiER Japon (クーリエ ジャポン) 2011年 12月号 [雑誌]
前回の社会企業家特集の時は、わりと人が集まったんですが、今回の経済特集は人が少なかったです。集め方が悪かったのか、経済というテーマに集客力がないのかは今後観察していきます。

今回、「Occupy wall strert」を取り上げました

今回、私が取り上げたのは町山智浩氏の『激変するアメリカのメディア界を追え!USニュースの番犬『第23回ウォール街を選挙する若者達の講義活動が意味するもの』」。ウォール街で「Occupy wall street」という若い学生/フリーター/失業者を中心に、貧富格差の拡大を容認している政府を批判するデモがあったというやつです。アメリカでは上位5%が国富の40%を独占する一方で、公的医療保険がないあまりに、医療すらろくに受けられない貧困層が拡大しています。

私自身は、このデモ自体に興味があるわけではないですが、彼らがデモをやらざるをえない状況を生み出している経済状況を無視できない事情があります。

彼らが失業した理由の一旦は、技術の発達によって労働が機械に代替されていること、経済のグローバル化によって賃金が安い途上国に労働が移転していることだと言われています。これは製造業が事実上壊滅したアメリカに限った話ではなく、日本においても同じ状況にあります。実際にうちの身内も、何度か派遣切りにあって、かなり真剣な家族会議を何度も繰り返した時期がありました。世界の情勢に疎いうちの両親には理解できないメカニズムによって、身近な人の労働が奪われています。

先進国と途上国の賃金格差が埋まるまで、これは避けられない時代の流れであり、私自身はそれでも生きて行けるような道を自分で選んで行かざるをえないと思っています。どうしたら機械や途上国の労働者に仕事を代替されないか、先進国の全ての人が考える必要があります。

ある人は、金融や情報のような知的サービス産業の就業人口を増やせば良いと言っていました。私も同じ考えはあります。一人一人の生き方としてはそれが適切だと思います。私に子供がいたら、世界の動きと今後自分の身に降り掛かる状況について説明して、どういう考え方をすべきか話をするでしょう。

しかし、それを皆ができるほど強いのか疑問に思います。私の実家のあたりの人のように情緒的な日本人に、そのような強さを求めることに疑問を感じてしまいます。

一番良いのは、今後、民間の設備投資を促すような分野に政府がインフラ投資を行い、国内の雇用を吸収できるような産業が発達することですが、今、そういうことを考えている政治家は少ないです。残念。

#お上に頼れと言っている訳ではないですよ。民間が国内に設備投資をしない以上、政府が需要を作り出す以外に方法ないと思っています。ただし、政府がやる産業政策は失敗するのでNGで。あくまで需要が伸びるようなインフラ投資をすること。

クーリエジャポンに期待すること

なんかとりとめも無い感じになりました。
私は、クーリエジャポンは最近まれに見る質の高い雑誌だと評価しているので、今後ともいろいろ考えさせられる編集をやってほしいと思います。応援の意味でも、朝食会は続けて行こうと思います。

ただし、最近の特集は
  • 個々の記事は良くても、全体を通してのテーマ性が弱かったり、
  • 現状分析があっても、今後どういう考え方をすればよいか提案がなかったり、
するものが多いように思います。海外の記事を集めましただけではなく、何か読者に訴えかけてくるような何かを期待します。値段の割に高い注文ですんませんですが。

では、また来月朝食会やります。今度は人集まるといいなー。

2011/11/12

#etrobo 「VDMで戦うETロボコン2011~Project VDM 2年目の挑戦~」を読んで


オブジェクトの広場2011年11月号にProjectVDMさんのETロボコン2011参戦記が掲載されました。

著者の植木さんは、私が2011年4月から6月にかけてロボコンのモデルに関する記事を連載したときに、Twitterに記事の感想をつぶやいていたのをきっかけに知り合った方です。

今回は、2011年の東京地区大会が終わった直後に参加しての感想をつぶやいていたので、参戦記を書いてみませんか?と誘ったところ、快く了承していただいて立派な記事を書いてくださりました。ありがたいです。

実は直接お会いして話した経験はありません・・・。

■Project VDMさんの取り組みについて

ProjectVDMさんがやっていることは、ロボコンの制御プログラムを実装してしまう前に、アーキテクチャ(全体的な構成)の実現性を形式手法という手法で検証したというものです。形式手法の実装言語としてはVDM++、ツールとしてはVDMToolsやVDMUnitというものを使っています。

また、2010年参加時に検証に使ったコードをそのままモデルシートに載せても審査委員に伝わらなかったという反省を生かして、2011年はUMLモデルとの対応付けを分かりやすくしたとのことです。

■ETロボコンでも形式手法は使えそうだ

この形式手法というのは、私は業務で見た経験はないですが、航空業界などミッションクリティカルな分野で活用されているようですね。仕様の間違いによって発生する不具合で、大きな損害(人命、金銭)が出てしまう場合に、ものを作る前に仕様が正しいことを保証しようという目的で使われるようです。

複雑な状態遷移や、並行処理の微妙なタイミングによって不具合がおきやすいところは使いどころだと感じます。ETロボコンで言えば、以下のようなところに使えるのではないでしょうか?
  • 各難所の走行制御の仕様化
  • マルチタスクにした場合に時間制約を守れることの確認
    • 走行体内の各ハードウェア制御や、Bluetooth通信を活用する場合の走行と通信応答の兼ね合いなど
実際に、ほぼ組さんはBluetoothを使って制御パラメタをPCに送信する仕組みを作っているようですが、その際にマルチタスク処理の仕様はLTSA(Labelled Transition System Analyser)という形式手法のツールで検証されていたようです。

■Project VDMさんのVDM活用について

一方で、Project VDMさんが活用しているのは、よくある区間切り替え部分の検証です。記事に書いている範囲では、UMLのクラス図やコミュニケーション図(もしくはシーケンス図)で確認できる範囲かな?という印象を受けました。「マルチタスクやらハードの制御が複雑に絡み合って、UMLでは確認できない」というものではない印象を受けました。

ただ、まとめの部分に制御アルゴリズムへの適用を匂わせている記述があるので、本当にVDMが生きてくるところは来年以降出てくるのかな?と期待しています。

■開発プロセスとの絡みが知りたい

読んでいて疑問に思ったのは開発プロセスとどう関係してくるのか?というところです。

実開発では、仕様が固まっていない状態で大規模に人員を投入するわけにもいかないので、実開発が始まる前に仕様を固める段階で形式手法によるモデル検証を行うのでは?と予想しています。

一方、ETロボコンでは、時間的にも人手的にも、そう悠長なことを言っていられないはずなので、開発のプロセスとモデル検証のプロセスが平行して、フィードバックをまわしていくのではないかと思います。
  • 開発のプロセスでは、UMLでアーキテクチャとサブシステムを設計し、実装に落として、コースでの走行テストを行う。
  • モデル検証のプロセスでは、仕様化が難しそうなところをピックアップして、モデルで検証した仕様を開発のプロセスに展開する。
両者は完全に分離しているわけではなく、開発のプロセスの中で走らせて分かったことはモデル検証のプロセスにインプットされるし、モデル検証のプロセスで検証したことは開発のプロセスへのインプットになります。

実際にやったわけじゃないので、妄想ですがw どなたかノウハウ持っていたら、ブログ記事にでも挙げてくれるとうれしいです。ワークショップに行って聞けば教えてもらえるかもしれないけど、ネットを補完的に使えたらいいなー^^;

■参戦記募集!

地区大会の参戦記では1本のみでしたが、希望者いれば他にも参戦記を書いてもらいたいと思っています。もし希望者いたら、私までご連絡ください。「地区大会敗退したけど書いてみたい」という人でも歓迎しますよ。

2011/11/06

#etrobo ETロボコン東京・南関東地区合同合宿をやりました


ETロボコンの東京地区・南関東地区のチャンピオンシップ大会参加者を中心に合宿つき合同試走会をやりました。結構珍しい取り組みかと思われるので、記録に残しておきます。


合宿の概要

  • 日時:2011/11/5(土)〜11/6(日)
  • 場所:TDI人材開発センター(静岡県熱海市)
  • 目的
    • チャンピオンシップ大会向けの合同試走会
    • ETロボコン参加チーム間の交流

参加チーム
※総勢40人近くいたんじゃないでしょうか?

○CS選抜チーム

  • StrayCab06(東京)
  • 芝浦雑技団(東京)
  • AEK RUNNER11(南関東)
  • BERMUDA(南関東)
  • みらいウォーカー(南関東)
  • ほぼ組(南関東)

○地区大会敗退チーム

  • マイペース(南関東)
  • こっぺぱん♪♪(南関東)
  • H23(南関東)
  • チームてづっち(東海)

スケジュール
○11/5(土)
13:00 第一陣が到着。コース設営開始。
13:30 全員集合後、各チーム自己紹介。
14:00 試走開始
18:00 夕食
20:00 モデルワークショップ(と称した飲み会)
    - 各チームのモデルを見ながらわいがや
※この辺はただの飲み会です。

○11/6(日)
08:00 朝食
〜試走時間〜
12:00 昼食
13:30 模擬競技会
15:00 片付け後解散

模擬競技会

本番と全く同じ形式で競技をやりました。
各チーム、練習場との環境の違いに苦しんで、うまく調整できていなかったようです。競技会では、リタイアが続出しました。

そんな中、AEK RUNNER11、みらいウォーカーはぶっちぎりの速さでした。この2チームは本番でもきっちり仕上げてくるんでしょうね。

面白かったのは、ほぼ組。Bluetooth通信でPCから制御パラメタを送信して、パラメタ調整できるようにしていました。確かに、コンパイル&ダウンロードはいっさいせずにコース付近でずっと調整をやっていたのには驚きでした。これは作業効率化の効果は大きそうです。

モデルワークショップ(と称した飲み会)

プロジェクターを用意して、モデルシートをスクリーンに投影しつつ、だらだら飲む感じの懇親会をやりました。結構議論が白熱したのは、ほぼ組とマイペースのモデルだったと思います。

ほぼ組は、いかにBluetooth通信経由でPCからパラメタ調整しやすくするかを徹底して考えていました。視点がかなり独特ですが、目的が明確で分析が徹底しているので、CSでもかなり評価されるのでは?と思いました。

マイペースについては、本人達がクラス図が分からないとよく口にしてたので、私が企画してネタふりしてみました。ここで話した内容は気が向いたら、ブログに書いてみようと思います。モデリングやオブジェクト指向に入門した人が素朴に疑問に思うことを話してたと思います。

所感

これまでうちの会社のコースを開放し、南関東地区のチームが混じっている合同試走会はよくやっていました。しかし、これだけ大規模で、かつ合宿つきは初めてです。

試走やるだけじゃなく、お酒を飲みながらお互いのロボコンの取り組みについて話するのは、お互いに刺激になっていたようです。皆さんが楽しそうにされていたので、スタッフ側としてうれしく感じました。
今回は、M田さんにいろいろ段取りしていただいたおかげで開催できました。来年以降も何かやれるといいっすね。

おまけ



湯河原ええ感じのとこでしたよ〜
ロボコン抜きで自然を散策&温泉でも良かった〜

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の演習課題
いわゆる探索の問題でした。

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

■講演:TDDBC中村ヘようこそ(by @kaorun


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


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


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

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

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

■講演:TDDネクストステップ(@goyoki



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

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

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

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

ケント ベック
ピアソンエデュケーション
発売日:2003-09

マイケル・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の読書会をやろうと思います。
時期が決まれば仲間を募集したいっす。


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先のユースケースが実行されるのかユースケース記述に書く必要があります。

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

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

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

ちょっと複雑なので、このクラスの意図を示しておきます。
  • 「走行戦略」が一位に決まる単位をコースの最小単位である「経路」とする。
  • 「走行戦略」には複数の「走法」が順序付きで含まれている。
  • 「走法」が切り替わるタイミングは「走法切替条件」で決まる。
  • 「走法」はもっと細かい制御の単位である「アクセル操作法」と「ハンドル操作法」に還元できる。
このクラス図で良い点はまず特定の難所に依存しないような作りになっていることです。部品の組合わせで、全ての難所は走ることができると示しています。
クラス図の例で言えば、コースは最終的には「アクセル操作法」と「ハンドル操作法」の制御量の違いに還元できると言っています。こうなっていると「アクセル操作法」と「ハンドル操作法」という低いレベルの部品は来年以降も再利用できます。

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

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

作り手の意図としては、おそらく以下の通りだと思います。
  • ベーシックステージには、いくつかの区間があり、区間を順番に走る。
  • それぞれの区間を走っている時にコースアウトすると、リカバリ走行に切り替わる。
  • コースに復帰できると元の区間走行に戻る。
ただ、このモデルはリカバリ走行中にコース復帰した場合に、どの状態に戻るかは判別できません。

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

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

要求
要求では2種類のモデルが紹介されていました。
  • 要求図を使って要求同士の関係を書いている。
  • ソフトウェア品質特性(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チームがチャンピオンシップ大会に参加できるようです。

モデル部門
  • 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』翻訳者) - @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のバージョンは明記されていませんでした。

手順

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

(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関数のあるソースファイルを作成します。

ファイル名は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アプリの勉強をして、アプリ開発者として今の立場を築いたとか。思わず拍手してしまいました。

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

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

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

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

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

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

■おわりに

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

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

2011/07/18

ETロボコン2011 東京連合第2回集会を開催しました

先日、オブジェクトの広場にて東京連合第1回集会の模様を紹介した記事が掲載されました。ETロボコン参加者の皆様は、もうお読みいただけましたか?

そして、7/17(日)に株式会社オージス総研東京オフィスにて第2回集会が開催されました。

■参加チーム
今回の参加チームは以下の通り。総勢27名が参加しました。
  • 飛べ! ぼくらの夢ヒコーキ
  • リンク二郎同好会
  • 電大ロボメカ
  • StrayCab06
  • チームSUPRAパンダ
  • AEKRUNNER11
  • 特命平社員2
  • H23
  • 勝ちロボ
  • 芝浦雑伎団
  • 田町レーシング
■開催内容

第2回は”難所攻略祭り”と題して、チームの代表者に各難所の攻略方法について解説していただいた後、全チームが入り交じって難所攻略についてグループディスカッションを行っていただきました。


13:00〜 案内(手嶋さん@東京連合)
13:10〜 第1回集会アンケート結果の紹介(大西@東京連合)
13:20〜 難所の攻略 個人発表(担当チーム)
14:35〜 休憩
14:45〜 グループワークのやり方(大西@東京連合) 
14:55〜 難所の攻略 グループ検討
16:25〜 休憩
16:35〜 難所の攻略 グループ発表(難所グループ)
18:05〜 案内
18:15〜 終了

■難所攻略の検討および発表について


皆さん、まだ難所攻略の検討を始めたばかりで、まだ手探り状態のようでした。
しかし、皆さん、今の段階で分かっていることや、昨年の経験をふまえて活発に議論していました。
各難所の検討グループは必ず他チームメンバとの混成になるようにグループ分けを行い、意図的に他チームの人と交流を行えるようにしました。主催側としては、ギクシャクしてしまうかと思いましたが、そこは同じETロボコン参加者同士、すぐに打ち解けて議論ができたようです。

■どんな奇抜なアイディアが出た?

どんな議論をしたかは、そのうちオブジェクトの広場でも公開されます。
今は秘密です^^

実は、タイムマネジメントに忙しく、あまりメモできなかったからですが><

■次回の予定

第3回は8月に開催予定です。
今のところ、本番コースを敷いての試走会、モデルレビュー、ワークショップなどを行おうかと話し合っています。
ワークショップは、参加者が疑問に思っていることなどを持ち寄って、みんなでわいわい議論したりする企画です。

そのうち、関係者にはアナウンスする予定です。お楽しみに。

■(補足)当日使った資料

2011/07/03

Mac OS XでJavaのkeytoolコマンドを使用する時の文字化け対応

英語のブログの方に書きましたが、Androidアプリを作ってたらkeytoolというJava関係のコマンドを使う機会がありました。

これMac上で使ってみると、以下の理由で文字化けします。
  • MacにインストールされているJavaの文字コードがShift-JIS
  • ターミナルの文字コードはUTF-8
ターミナルの「文字エンコーディング」を一時的にShift-JISにして対処しましたが、今時Javaの文字コードがShift-JISとかちょっとばかばかしいです。

どうやらcocotというツールを使うとターミナルとプロセスの間に入り込んで、エンコーディングの変換を行うツールとかあるようですが、Javaの方をUTF-8にしてほしいところですね。

2011/06/21

実践でまいまい式を使うための改善策

先日の東京連合では、外乱光対策として有力候補の「まいまい式」を実際に使うための改善策について話しました。

結論から言うと、まいまい式の弱点である輝度計算の周期が遅い問題を多少改善できることは分かりましたが、速さを競う競技ではまだまだのレベルでした。ここに調査結果を記しますので、ETロボコン有志が改善策を練ってくれることを期待しています(私は参加者じゃないので^^;)。

調査して何か分かったら、 #maimai #etrobo でつぶやいていただけるとうれしいです^^

■まいまい式について

slideshareにアップしたプレゼン資料にも書いていますが、特に東京地区大会の会場のように太陽光がコースに直接入射する場合、光センサーの仕組み上、地面の反射率が高い(明るい色)なのか、太陽光が強いのか区別できなくなります。そして、レーンが識別できなくまります。


それを回避する手法として、ETロボコン界隈では「まいまい式」がよく知られています。
原理については、すねいるさんのブログを参照してください。

http://www.chihayafuru.jp/etrobo/?p=1349
http://www.chihayafuru.jp/etrobo/?p=1371
http://www.chihayafuru.jp/etrobo/?p=1326

■まいまい式の問題点 - 輝度計算周期が長い

このまいまい式は「効果が絶大」との報告がありますが、1つ難点があります。コースの輝度を早く計算できないことです。サンプルだと20ミリ秒周期になっていますが、倒立制御の周期が4ミリ秒なのに対して、これはあまりにも長過ぎる。

では、何が問題なのか?を考えました。

(1) LED光の点滅周期が遅い

まず疑ったのが、LED光を早く点滅できないんじゃないかということ。普通に考えると、こんなシンプルな回路でミリ秒もかかるわけないのですが、裏を取ってみました。

http://mindstorms.lego.com/en-us/support/files/default.aspx

上記のURLから取得できるNXTの回路図を見ると、LED光の点滅はメインプロセッサのARM側でやっています。LED光を点滅するための回路がARMに直接つながっているシンプルな構成です。回路的には問題ないと思います。

また、デバドラのソースコードはnxtOSEKの下にありますので、探してみてください。レジスタを操作してるだけなの普通のコードです。これも問題ないと思います。

(回路図とデバドラに問題ないので、問題ないと自分の中では結論付けていますが、電気的な特性で何かあると分かる人いましたら、ご連絡ください)

(2) 光センサ測定値の測定周期が遅い


もしかすると光センサの測定値を早い周期で取得できないのではないかと考え、こちらも調べてみました。ハードウェアの仕様書によると、とある事情でAVRのサブプロセッサが3ミリ周期で光センサのA/D変換結果を取得し、2ミリ秒周期でARMのメインプロセッサに送っているようです。

つまりは3ミリ以上は速くなりません。また、ARM側が値を取得するタイミングとARM-AVR間の通信周期が合わない場合もあるので、ARM側の取得が約2ミリ遅れることもありえます。

つまり、以下の3つの周期が噛み合ないと最新のデータが期待するタイミングで取得できません。

  • AVRのA/D変換が3ミリ周期
  • AVR - ARM間の通信が2ミリ周期
  • ユーザプログラム側で光センサ測定値を取得する周期・・・実装次第

ボトルネックはここにも存在することが分かりましたが、20ミリとかのオーダーの問題を調べているので、他にも問題は潜んでいそうです。

(2)' 光センサの測定速度が遅い

ちなみに、光センサのデバドラはAVRのサブプロセッサ側にありますが、こちらも回路図とデバドラともにシンプルで問題ないはずです。ドキュメントによると0.1ミリ秒くらいで処理は終わっているよう。

デバドラのソースコードはこちらで入手できますので、興味ある方は調べてみてください。

(3) 光センサがLED光の点滅の影響を受ける

これは調べきれていませんが、点滅と光センサの測定がほぼ同時期に実施されると、何らかの影響を受けてもおかしくはありません。きっちり点灯(もしくは消灯)してから光センサ測定をするように、タスク設計すると良いと思います(まだ調べてないのでなんとも言えません)。

(4) まいまい式の差分計算の計算量が多い

これは、まいまいさんが現実の光センサ値を線形補正するやり方をご紹介しています。
http://www.chihayafuru.jp/etrobo/?p=1371

計算量をおさえるように工夫されていて、問題ないようでした。
ちなみに、ここの補正係数は各自で調整が必要です。

(5) その他のオーバヘッドが大きい

オリジナルの実装ではタスクの生成/破棄を頻繁にやってるので、ここは少し冗長だなと思いました。周期タスクで処理をやりつつ、一切破棄をしない実装だとどうなるのか調べてみました。


ライントレースしての実験ではないので不完全ですが、8ミリ周期でLED光を点滅しながら、光センサも測定し、輝度計算もできていました。

■まとめ

ちょっと工夫したら、少し遅めに走る分には問題ないレベルに改善することが分かりました。ただ、AVRのデバドラを規約上書き換えることができないので、根本的に直すのは無理のようです。

会場からは「マップ走行(光センサを使わず、モータエンコーダ値で位置を計算する方法)をメインに使って、補助としてまいまい式の輝度計算結果を使ってみてはどうか?そうするとまいまい式の計算速度は気にならない」という意見もありました。これはなかなか現実的な提案なので、どなたか試してみてください!

2011/06/19

ETロボコン東京連合の第1回を開催しました

6/18(土)に株式会社オージス総研東京オフィスにて、ETロボコン東京連合の第1回集会を開催しました。そのうちオブジェクトの広場でも、報告記事が載ると思いますが、ここでも報告します。

■東京連合とは?

ETロボコン東京地区参加者の有志による独自勉強会です。2010年から始めて、今年で2年目です。だいたいモデルのレビュー、合同試走会を行っています。

昨年の様子はこちらを参照してください。
http://www.ogis-ri.co.jp/otc/hiroba/technical/ETRoboconTokyoRengo/index.html

■第1回の参加チーム


  • 勝(かち)ロボさん
  • 笑's3人娘さん
  • 飛べ!僕らの夢ヒコーキさん
  • すねいるさん
  • 田町レーシング
  • 芝浦雑技団

■スケジュール

今回は初回なので全員で顔合わせ。そして、常連の人が講演するという内容でした。次回以降はもっと参加者全員で対話的に議論する形になると思います。


  • 13:45 全員で自己紹介
  • 14:05 東京連合とは?(手嶋さん@東京連合)
  • 14:15 大胆予想〜今年のモデル/競技はこう変わる〜(手嶋さん@東京連合)※全員でのブレストあり
  • 15:15 休憩
  • 15:30 要求分析入門(片山さん@田町レーシング)
  • 16:00 縦横無尽走行解説(瀬尾さん@勝ロボ)
  • 16:30 休憩
  • 16:45 まいまい式解説(大西@東京連合)
  • 17:45 第2回集会のお知らせ(手嶋さん@東京連合)
  • 18:00 終了
  • 18:30 懇親会(南関東地区の方も4名参加されました)

■講演の感想

○ 大胆予想〜今年のモデル/競技はこう変わる〜(手嶋さん@東京連合)

2011年で規約が変わった箇所について、モデル審査や競技面の両方について議論しました。詳細は、後日公開予定のオブジェクトの広場の記事を参照してください。

気になったのはBluetoothでPCとロボットが通信できるようになったこと。ある人は無限の可能性が広がったと期待感を示していました。一方で、通信の信頼性の問題があるので、頼りすぎるのは良くないとの意見も。可能生はありますが、どこまで使えるかは各自検討が必要です。

○15:30 要求分析入門(片山さん@田町レーシング)

要求分析の入門として、要求分析の目的やユースケース図および要求図の書き方について紹介していただきました。

会場からは要求を整理することは大事だとは重々承知だけど、最初に要求図をちゃんと書けるの?との意見も。田町レーシングのメンバが昨年使った感想として、「最初から一発でできない。反復型の開発を取り入れて、開発を通じて分かったことを要求図に盛り込むやり方が良い」とのコメントしました。

○16:00 縦横無尽走行解説(瀬尾さん@勝ロボ)

これは、いわゆるマップ走行という光センサを使わない走り方の紹介です。光センサは一切使わず、エンコーダ値からロボットの位置を計算し、あらかじめ決めたルート通りに走ります。

ここでは書ききれませんが、高校数学レベルの知識があれば、すべて計算できます(三角関数、ベクトル演算など)。おそらくは、数学の知識に関しては2Dのゲームなどを作った経験ある人はみんな知ってる内容です。

ロボコンでやる場合は、エンコーダ値のズレなどを補正する必要があります。やり方としては、光センサで直線部分などコースの特徴的な場所を検知して各種パラメタをリセットすると良いようです。

○16:45 まいまい式解説(大西@東京連合)

これは後日ブログに掲載します。

■懇親会の感想

南関東の方も来られて、地区を超えた熱い議論をしました。ロボコンも地区内外の交流が増えてきましたね。

■第1回を終えてみて

2011年の参加者がひとまず一カ所に集って、勉強会できたことは大きな成果です。
皆さん、今後も参加を希望しているとのことで、東京地区全体のレベルアップ、そしてチャンピオンシップ大会で東京地区参加者の上位総なめを目標に支援していきたいと思います。

あと、もしかすると南関東の人達とコラボするかもしれません。

2011/05/09

@mas0061 さんのETロボコンモデル記事に対するコメントへ回答

@mas0061 さんがETロボコンの記事についてblogでコメントしてくださったので、さらに疑問点について回答します。

■UMLだからこそ取れるモデル間のトレーサビリティって何だろう?

これは「2.2 モデルの読みやすさを意識してトレーサビリティを向上させた」にある以下の発言を指してのコメントだと思います。
林田:でも、実際にモデルを作って社内レビューをすると、トレーサビリティがあるモデル、つまり複数のモデルの内容が一貫している方が自分達が理解しやすいし、レビュアにも理解してもらいやすいですよね。やはり、ここはUMLを使うことの強みをより生かせるところやと思いますよ。
ここでは大層なことを言っていたわけではなく、モデル審査基準にある通り、構造モデルと振る舞いモデルの要素が対応しているなどの基礎的なことだと思います。UMLの場合、文法で対応関係が定義されている便利さはあると思います。

一方で、「2.3 複数のダイアグラムを読みやすくする工夫を施した」に書いてあるような分類の粒度を揃えたり、情報を整理してトレーサビリティを取ることはモデラ自身がちゃんと考えないといけないと思います。

後者のは文法を守っていればOKという話ではないので、かなり難しいです。ある程度のトレーニングを受けたり、本業で経験を積まないと難しい類の作業だと思いました。
この点、私はへっぽこですが、本業がモデリングの講師であるメンバーと一緒に作業出来た点は恵まれているなと思いました。

■読みやすい=ストーリー性があるってことかな

人によって読みやすさは主観的に決まると思うし、色々な要素が組み合わさって決まることなので、何とも言えません。

2010年のモデルでは、ストーリー展開(概略から詳細へ、全体像から部分へ、結論から理由へ)だけでなく、分析の粒度や切り口にもこだわっています(「2.3 複数のダイアグラムを読みやすくする工夫を施した」を参照)。

■対象ドメインが徹底的に分析されていて、それを審査員の立場でどう表現するかが、戦略的に練られてる

読み手の立場は意識していますが、表現する際に審査員の立場になることはないんじゃないでしょうか?

対象ドメインの分析については、2011年は競技規約が大きく変わっているので、ドメイン分析がより重要になると思います。

記事でも言及しているように、2010年から競技規約が変わった部分が適切にモデルに反映されていると評価は高いと思います。ただし、競技内の本質的な部分は変わっていないので、クラス図を大きく変えるところ、変えないところは出てくるかもしれません。

■UMLの基本に忠実に、かつ適切な図の選択をすることが重要

目的に応じた適切なダイアグラムを使うことは大事だと思います。

■要求図は、要求と機能と制約の関係が1つの図で示せる反面、ゴチャゴチャしがちな印象だけど、ここに対する審査員の評価ってどうなんだろう?
→コメントなかったんだ…

記事では「評価されていない」と書いているので、誤解を与えたかもしれませんが、個人的にはコメントの有無や量は評価と直接は関係ないと思います。コメントをたくさんつけていることは、審査員の関心が高いので評価も高い可能生がありますが、コメントがなかったからといって全く評価されていないわけでもないと思います。

この辺は、審査員に聞かないと分からないので、ワークショップや懇親会で聞いた方がいいでしょう。

■これだけのモデルが、どの段階でできあがったか?に興味がある。開発段階で基礎的な部分はできあがってて、それをモデリングシート用に見た目を変えたのか、開発がほぼ終わってから説明のためにできあがったのか

UMLで描いている部分の原形は6月くらいにでき上がっています。ただ、モデルシートを作成する段階で、モデルをより分かりやすく、納得性を高めるために、見た目だけでなく中身をいじっています。
(例)ユースケースの粒度、開発で得た知識を要求図の内容に反映、クラス図の属性の配置やクラス間の責務の再配置、etc.

正直なところだと、モデルの完成度を上げたのは提出直前の追い込みだと思います。

■去年も要求図を良く見たけど、今年は定着フェーズになりそう。だって、この記事見てると、要求図でモデル書きたくなるw

田町レーシングが描いているやり方以上に、もっとうれしさや良さがはっきり分かるような手法を開発してくれるとうれしいなと思います。

2011/04/21

はてなから引っ越してきました

どうも、はてなダイアリーよりbloggerの方が書きやすそうなので。

元の日記はこちら。
http://d.hatena.ne.jp/legoboku/

データのエクスポート & インポートがうまくいかないようなので、データ引っ越しはしません。