いがいが日記

_ 五＋嵐氏、Poken over 弁当箱プロトコル対応製品を発表

五＋嵐氏は1日、新世代の名刺交換ができるサービスPokenを利用した

新しいサービスとそのプロトコル、およびその製品を作成したと発表した。（ライター共同）

Pokenはスイス生まれのデジタル名刺で、

マスコットを同士をタッチするとお互いのIDやブログURLなどが交換できる。

五＋嵐氏はこれを日本の伝統文化である

「お弁当のおかず交換」に応用できないかとひらめき、

Poken over 弁当箱プロトコル(PoBP)を制定、それに対応した新製品を出すと発表した。

PoBPはお弁当のおかずを交換した際にお互いのID情報交換を行う。

本人のIDの交換だけでなく、

お母様のブログ情報や、レシピを公開している場合はそのURLもやりとりできる。

さらに対応弁当箱に搭載されたカメラとマイクにより、

食べたユーザーの感想がその場でUPできるようになっていて、

モニターのお母様方にも「子供の笑顔を見ると作り甲斐が出る」と好評だ。

五＋嵐氏は

「この技術を用いれば子供がどの子と仲良しかの交友関係がわかり、

今までおかずを交換をしていた子が交換をしなくなるなどの情報から、

いじめの早期発見にもつながる可能性がある。

また、ピーマンやニンジンの送出が多いなどの傾向から子供が嫌いな食材情報を得られ、

それに応じてニンジンを見えないほど細かくしていれるなどの調理方法の工夫も可能だ。」

と語った。

今後はコンビニ弁当への搭載を売り込むとともに、

「お弁当のおかずの交換をしたくてもなかなか、、、」

という昔の少年少女たち向けにお弁当をみんなで食べる

「友達100人できるかなピクニック」を開催するのが夢だと語った。

イメージ画像
B001UWOTKO
お弁当(Google画像検索)

_ 高専カンファレンス 東京Lite006

今回は株式会社オプティムさんの会議室で開催。

部屋は窓を開けておくと外から風がはいってきて、

なんだか高専時代の授業を思い出しました。

オプティムさんは社内の勉強会に学生さんや社外の人も呼んだりしてるそうで先進的。

シドニーにもオフィスがあるとかすごいな。

さて、今回は運営の長田さんの想いから少人数での開催。

しかも全員LT。

これ面白いねー。

話題もOS、仮想化、デジイチ、メタボ、自作ハード、言語、

起業、名言、物理、そしてまいどお馴染み高専病とほんとに多彩。

みんな引き出したくさん持ってんなー。

全部紹介したいのだけど、そこは発表資料（リンク）を見て頂くとして

1つだけ挙げると、物理話でガウス加速器の紹介があった。

(twitter ID @nakamot0さん)

鉄球と磁石球をくっつけてそこに鉄球を衝突させると

反対側の鉄球がすごい速さですっとんでいく。

○が鉄球、●が磁石球とすると、

　　　○○●　　　　←○

　　　○○●☆衝突☆←○

←←○　○●○

って感じか。

んー、磁性がどうからんでるのかなー？

と考えてたけどわかんなくて答えを聞くと非常に単純。

すっとんで行く鉄球がもともともってる位置エネルギーは、

衝突した鉄球がくっつく場所より球1個分大きい。

（磁力ポテンシャルに対する位置エネルギー。磁石に近い方が低い。）

その位置エネルギーが運動エネルギーに変換されてすっとんでいくと。

高専1年の物理で解ける問題だったのかー。

これ、学生実験に良さそうですね。

飛び出した鉄球の速度を計測して、

磁性ポテンシャルの位置エネルギーを求めなさい、的な。

その後のビアバッシュでもいろいろ面白い話をできて満喫しました。

今回はヒューマンネットワーク高専の会長さんもいらしてくれて、

運営の話もいろいろ聞けたし。

高専カンファレンス、やっぱりおもしろい！

_ [book] プロダクティブプログラマ - プログラマのための生産性向上術

プログラマ個人の生産性を上げるにはどうすればいいのか？

この命題に技法と思想の両面から答える一冊。

Ruby札幌の島田さんが監訳、私もレビュアとしてお手伝いさせてもらいました。

生産性をあげることにより、

高まった生産力を活かしてさらに加速することができる。

しかもその恩恵を一生涯に渡って受けることができる。

これは私たちがプログラムを作り未来を創るお手伝いをしてくれる本です。

目次を見て頂ければ分かる通り、

マクロや正規表現の話からエディタの使い方、

さらには静的解析の方法にTDD、DSL、メタプログラミングと

ありとあらゆる分野に渡るノウハウを蓄積した、

おそらく世界一ノウハウ密度が高い1冊。

新人の頃、隣の席の先輩エンジニアが使っている

魔法にしか見えない技のからくりを聞くような、

そんな情報がつまっている本です。

そばに先輩もあまりいない学生さんやエンジニアさんはもちろん、

既に技術に明るい方にも必ず何か新しい発見があるのでは。

監訳の島田さんはRuby札幌を立ち上げ、運営するだけではなくて、

その活動の中でいろんな新しい技術を分かりやすく紹介しています。

そんな島田さんがついカッとなって想定外の量のノウハウを日本中に届けるために

レビュアの角谷さんと力を合わせて醸造させた、

この本はそんな一冊なんだと思います。:)

さらに自重せず札幌ジュンク堂でのトークセッションも4/25(土)に開催が決定！

私も遊びに行こうと思います。

島田さんの発表をじっくり生で聞くのは初めてなので楽しみです！

_ [book] ハーバード流交渉術-仕事が100倍うまくいくNoの言い方-

fkinoさんの日記で読んでこれは面白そうだと即買いしました。

交渉、とおおげさに言わなくても人に対してNoと言わなくてはならないときはままあります。

したくないことを押しつけられそうになったり、

無理な約束を強要されたり。

この本はたくさんの実例を通じて効果的にNoを言う方法を説く一冊です。

基本はYes, No, Yes? の流れを作ることだそうです。

最初のYesは自分の守るべきものを述べ、

次のNoで自分の力を行使し、

最後のYes?でお互いの利益を一緒に探していく姿勢を作ること。

別にこれだけだと当たり前のことしか言ってないようですが、

この本は実例を通じてこの3つに力を与えて行く方法を説明していきます。

実例はどれも面白いのだけど、特に面白いと思ったのは「名付けゲーム」。

相手から交渉中にねちねち言われたら、その1つ1つに名前をつけていく。

これは「脅迫」、これは「罪悪感の喚起」、これは「口約束と、あとは野となれ山となれ」。

そうしてると言い言葉に買い言葉にならずに客観的に交渉を見続けることができると。

また、一般的にNoを受容するまでの感情は以下のような道のりを示すとのこと。

回避→拒否→懸念→立腹→交渉→悲嘆→受容。

なので、このプロセスをスムースに渡らせてあげれば、交渉もスムースに行くと。

私は交渉や人を説得するのが苦手です。

人狼をやって気づきました。

（人狼は推理するゲームじゃなくて、人を説得するゲーム。）

物事を客観視する訓練ばかりしてきた副作用かもしれません。

（自然科学屋でしたからある程度は仕方ない）

この本に書いてある通りにうまく行くようになるとは思わないけど、

この本を通じていろいろと考える土台を仕入れられたのが収穫でした。

Noと言うのが苦手な方にオススメです。

ちなみにこの本、三部作の三作目だそう。

前の2冊も読みたいな。

_ [ruby] rubyで別のフォルダにあるファイルをrequireする

自分メモ。

rubyで別のフォルダにある（自分が書いた）ファイルをrequireするにはどうすればいいのかな？

というのが分からずにunixのシンボリックリンク機能で逃げてた。

やっぱり不便なので(いまさらようやく)調べてみた。

$LOAD_PATH($: も同意) という配列にrequireされた時に見にいくパスが書いてある。

この配列に見たいパスをつめていくのが普通なのかなー？

とtwitterで聞いてみたら@walf443先生から

「場合によりますが大抵そうですね」と回答を頂いた。ありがたや。(-人-)

さらに、

$LOAD_PATH.unshift で前側に入れる(走査順先頭に)

$LOAD_PATH いじる場合は絶対パスにしてから入れる

というなるほどなアドバイスもいただきました。

例えばこんな感じかな。

これでだいぶスッキリ。ヽ(´▽`)ノ

---

this_file_s_path = File.expand_path(File.dirname(__FILE__))

lib_path = File.expand_path(this_file_s_path + "/../lib/")

$LOAD_PATH.unshift lib_path

$LOAD_PATH.unshift this_file_s_path

---

_ [twym][mac] TwYM(IRCログ表示機能付きタイマー) ver.0.50 release

TwYM(IRCログ表示機能付きタイマー)を久々にバージョンアップしました。

前のバージョンで一番の問題だった

ログ受信から表示まで最大20秒のタイムラグがある

を修正するために、ほぼ全部コードを書き直しました。

先月のGenesisLightningTalksさん(Vol.14)で試験運用させてもらい、

デプロイ準備（やっぱり時間かかるなぁ）をして今日google code へupしました。

あちこちの勉強会で使ってもらえるとうれしいです。

今後は（ようやく着手できる）デザインを少しいじりたい。

あとは・・・

gem対応

ruby1.9対応

gitHubで開発

をやっていきたい。

また、今回の変更で IRC bot -> QC の通信を yaml/RSS 方式からUDP通信に変更しました。

その辺の話を次の日記に書きたいと思います。

_ [twym][mac] QuartzComposer へUDP通信で入力

TwYM(IRCログ表示機能付きタイマー)を作る際に困ったのが

どうやってQuartzComposerへ文字列を送り込むかでした。

最初のバージョンは咳さんのページにあるRSSで流し込む方法にしました。

ただ、何秒分か貯めてRSSを作っていたので

ログ受信から表示まで最大20秒のタイムラグがありました。

これを解消しようといろいろ調べました。

mootohさんの SocketReaderPatch を使おうと思ったのですが、

あるバージョンのQCから動作しなくなってしまったとのこと。

また、QCのサンプルにunixコマンドを実行して結果を得るパッチがあったのですが、

これを使うとなぜか縮尺がおかしくなるバグ？が。

さらに調べて、

Network Receiver というpatchがあることが分かりました。

network通信でStringを受け付けるものだそうです。

たぶん昔はなかったんじゃないかなこれ。

Leopardくらいのタイミングで増えたんじゃないかと。

さて、network通信のプロトコルは何を使えばいいの？

と調べていくと、海外のサイトに

『"Apple"って送る場合は、UDPでこう送るといいよ。』

→"\0\0\0A\0\0\0p\0\0\0p\0\0\0l\0\0\0e"

と書いてあった。

早速rubyでサンプル書いて試す。数行で書けるruby便利。

さて、ここでいつものように日本語で困るわけです。

しかし、さきほどのサイトのコメント部に

「UTF-32BEで送るといいよ！」

とありました。なるほど、だから\0が3つなのか。

でもUTF-32BEなんて聞き慣れないエンコードだけどどうすれば？

とrubyのライブラリを調べていくと、

ruby 1.9.1 だと標準ライブラリのkconvが対応してました。すごい！

サンプルコードを書くとこんな感じ。

QC側のサンプルとあわせて添付しておきます。(QC_UDP_sample.zip)

QCでUDP通信をどのアドレス、どのポートで待つかはInspectorのSettingで指定できます。

1.8系の場合は外部ライブラリのrbuconvを使うとできます。

TwYM ver.0.50 にrbuconvを使ったサンプルコードが入っているので、そちらも参照ください。

# -*- coding: utf-8 -*-
# kconv の UTF-32対応が必要なので、要ruby1.9 
require 'socket'
require 'kconv'
socket = UDPSocket.open()
socket.connect("225.0.0.0", 50000) # address, port
str_u8 = "いがいが".encode("UTF-8")
str_u32BE = Kconv.kconv(str_u8,  Kconv::UTF32,  Kconv::UTF8)
socket.send(str_u32BE, 0)

http://igarashikuniaki.net/data/QC_UDP_sample.zip
http://arrifana.org/blog/2007/11/leopards-quartz-composer-and-network-events/
http://code.google.com/p/twym/
mootohさんのSocketReaderPathc

_ [book] プロダクティブ・プログラマ

献本いただきました！ヽ(´▽`)ノ

やっぱり本になると読みやすいなぁ。

この大きさだと電車で読めていいですね。

（でも、今回のレビューでiPodTouchは非常に読みやすいことに気づいた。(・∀・)イイ！）

感想に関しては4/7の日記を読んでいただくとして、

今日は初めて読んだ監訳者あとがきにふれます。

「なぜ、生産性の高いプログラマを目指すのか？」

について島田さんはRails作者のDHHの言葉を引用してこう述べています。（一部意訳）

「生み出した時間を使って、自分と仲間の人生をより豊かにするための投資をすることができるのです。

それが、プログラマが生産的であるべきたった1つの理由です。」

この本を読んだみなさんが生み出した時間で、

みなさんが笑顔になれること、

私たちの世界がよりよくなること、

それが島田さんの今回の仕事の動機なのだと思います。

そんな話がきっと札幌ジュンク堂のトークセッションでは聞けるはずです。

（ハードル上げてみた。(^^ゞ）

まだ席もあるようなので（満席って書いてないので推測）

興味のあるみなさん、今週土曜日はぜひ札幌ジュンク堂へ！

_ Windowsプログラムで生じるAccessViolationなどの例外を検知する方法

先日、Debug Hacks Conferenceに行ってきました。

みんなのDebugノウハウを共有ってのは勉強になっていいですね。(^^)

今日はそれと関係しなくもない話題で書いてみます。（どちらかというとテスト技法か）

しばらく前に業務でセキュリティのことを調べていたときに、

Fuzzingという攻撃手法があることを知りました。

入力をランダムにふって、対象アプリのふるまいを観察して、

AccessViolationなどを起こしているようならそこを攻撃の足がかりにするものです。

そういう攻撃手段があるのであれば、

それを開発者側が使ってあらかじめ防御する手段にすればいいわけです。

リンクの本は日本語で読めるたぶん唯一のFuzzing本で、

FileFuzzというWindows用のOSSFuzzingツールの作者さんらが書いてあります。

この本は大変丁寧に解説されていてオススメなのですが、

FileFuzzに関してはGUI部が数KB以上の入力ファイルに対応してないなど問題が。

そこで、FileFuzzの簡易デバッガ部分（ふるまいを観察。例外が発生したら検知。）と

GUI部分（ランダムにふって入力など）に分けて、足りないところを自作しました。

以降はそのデバッガ部分の話。

コードでいうとFileFuzzパッケージ内の src/crash/crash.c です。

このデバッガ、WindowsAPIを使って対象のプログラムの例外発生を検知してくれるのですが、

C++のコード中で投げられた（プログラマが意図した処理中の）例外も拾ってそこで処理停止してしまいます。

VC++はstd:exceptionはSEH(構造化例外)として扱うので、

この例外の場合は続行する処理を追加するように修正します。

SEHは

WaitForDebugEvent(&dbg, 100)

でとれてくる

dbg.u.Exception.ExceptionRecord.ExceptionCode

の値が 0xE06D7363 になります。

ExceptionCodeで判別してSEHのときは

ContinueDebugEvent(dbg.dwProcessId, dbg.dwThreadId, DBG_EXCEPTION_NOT_HANDLED)

を呼んでDBG_EXCEPTION_NOT_HANDLEDを指示してあげると、

通常の例外は続行され、AccessViolationなど有用なものだけを検知できるようになります。

詳しくは修正したcrash.cのリンクか

またはFileFuzzPatch.zipをDLして読んでみてください。

私はVC++2005で動かしました。

FileFuzzの作者さんにメールしたのですがスルーされてしまったので、ここで公開します。

ライセンス通りGPLでどぞー。

英語でもこの話書きたいけど、どこに書こうかな。。。

また、この部分の調査にあたっては同僚のIさんに多々アドバイスいただきました。4q! (^^)

http://igarashikuniaki.net/data/FileFuzzPatch.zip
修正したcrash.cをwebで見る
■ http://labs.idefense.com/software/fuzzing.php
4839926298

_ 札幌ジュンク堂「プロダクティブ・プログラマ」トークセッション

昨日のジュンク堂でのトークセッションは大変楽しいものでした。

一夜明けると札幌は春の雪が降っていました。

北海道から東京へ向かう飛行機の中でこれを書いています。

監訳者である札幌の島田さんが、東京の編集者、翻訳者、レビュアと

やりとりしてできた本、

そのトークセッションが札幌で行われ、

ネット配信で全世界に配信されるという札幌を主舞台とした壮大な企画。

それは札幌に住んでいた私にとっても大変うれしいものでした。

トークセッションの内容は本屋で行われるということで

技術書の紹介、解説を主に

プログラマの生産性をあげるにはどうすればいいか、どう学習すればいいかを

島田さんとレビュアの角谷さんとが楽しそうに語るというスタイル。

監訳の作業について

「原著を人に紹介しようと思って訳すと、理解が深まって見える景色が変わる。」

「訳を既に発売されている本と同じになるように定訳を探す作業が大変。

また、日本に初めて紹介されるような言葉は責任を感じた。」

と語りつつ、

「札幌と東京との遠隔作業も大事なのはコミュニケーションなので、

それができれば札幌での作業はなんの問題もない。」

（お客さんを指して）

「ですからみなさんもこれから翻訳や監訳の作業をされる分けですから、」

と笑顔で会場をさらりと鼓舞する一幕も。

「僕は新人の頃に隣の先輩を見て技を盗んだけど、

この本があればその内容が系統立って説明されている。

こんな本があるなら『早く言ってよ！』と。（笑）」

そしてトークセッション後には

「若い人たちはこの本でその辺を簡単に学べるので、

その向こうに広がっている、もっと遠くの世界をどんどん切り開いて欲しいなぁ。」

と島田さんらしい、後輩を導く暖かい言葉を語っていました。

様々な目標をひとつひとつクリアしていく島田さんの本が出たことを本当にうれしく思い、

私もいつか本に携われるようにがんばりたいとライバル心を抱いた、（笑）

そんな今回の札幌への旅でした。

_ 札幌の大型書店

札幌ではここ2年ほどで大型書店が3つできました。

駅ビルにある三省堂、

駅前の紀伊国屋、

大通りにあるジュンク堂です。

それぞれに特色があり、

三省堂はステラプレイスの中で買い物途中に寄りやすい、

紀伊国屋はモダンな建物と広い店内で雑誌コーナーや漫画コーナーの棚も大きい、

ジュンク堂は品揃えが多い、といったところでしょうか。

またどの書店もカフェがあり、

ジュンク堂や三省堂は著者さんを呼んだトークセッションもやっているようです。

東京の街を見ても、

これだけの範囲にこれだけ大きな書店が3つもあるところはないと思うし、

人口あたりで考えると日本一なのではと思います。

紀伊国屋の雑誌コーナーを眺めていると、

広いので東京と違いゆったりと見ることができるのがいいなぁ、と。

しかも壁いっぱいを使って陳列しているので表紙が見やすいし、

眺めているとその雰囲気に浸れるのがいいです。

立派な音楽ホールのKitaraもあるし、

芸術の森やイサムノグチがデザインしたモエレ沼公園もあるし、

札幌は豊かな文化を持つ街だね。

_ [book] ソフトウェア開発を成功させるチームビルディング

岡島さんの新刊読了。

「受託開発の極意」もそうですが、

岡島さんの本は岡島さんが今まで培ったノウハウを

経験談をふんだんに交えて分かりやすく説明しています。

なので、全ての項目に新しい気づきがあり

読みながら考えることでいろいろなことを疑似体験できます。

なのでしっかり全部読んで欲しいのですが、

いくつか取り上げるとすると、印象的なのは最初のチームの定義。

「プロジェクトの目標を達成するために、

メンバーが自律的に行動し、

それぞれの持つ能力を発揮しあうことができる。

そのような人の集まり」

自律的に動いているチームを見るとわくわくしてきますよね。

他にはキックオフミーティングで話すことも気づきが多かった。

最後の方にある岡島さん自身が苦しんだ体験談が書いてある

「責任を取るということ」も心に残る。

経験談がふんだんに詰まったこの本を読んで、

もっと他の話もぜひ聞いてみたいと思うようになりました。

機会があれば直接いろいろと聞いてみたいです。

_ 高専カンファレンス、東京と九州で2週連続開催

九州では初めての開催になる高専カンファレンスが久留米高専で5/16(土)に行われます。

今回はポスター類が充実していて、

素敵なポスターが2種類、そのほかに参加者募集リーフレットもある。

今回のポスターは現地の方が作成してくれました。

そろそろ高専カンファレンスポスター展とか開けちゃうね。(^^)

さて、発表内容も公開されたので眺めてみると

・産学連携のホンネ

・技術応用研究会の結成

・これからの高専図書館

・工学からビジネスへ

・レコメンデーションを考える

ガチである。地元高専出身の方々の話や

地元で起業している方など、東京では聞けない九州ならではの内容。

これは楽しみ。

さらにこのほかにLTもある。

私も遊びに行きますのでどうぞよろしくお願いします！

そしてついカッとなって高専カンファレンス007東京にも申し込んでみた。

こちらは5/9(土)。

まだ募集開始したばかりで空席たくさんあるのでみなさんぜひ！