デブサミ2012

勉強会

お邪魔してきました。
朝っぱらから眼鏡が壊れたので、修理の都合でこれしか参加できませんでした。
直行直帰レポート不要で、業務扱いしてくれた会社と部長に感謝。


○17-D-1 Kinectで創る10年後のカタチ
http://www.slideshare.net/kaorun55/devsumi2012-17d1-kinect10

中村さん(@kaorun55)の講演。もちろんKinectです。
Kinectの開発環境から運用事例から、現状のKinect関連情報を俯瞰できるという意味で、興味はあるがよーわからん、という人の心をガッチリ掴む講演だったと思います。
講演後、ブースで実演されていたので遊ばせて貰いました（壁をカンバスとして自分の指で絵を描く）が、実際に動いているのを見ると、いろいろアイディアが浮かんできますね。
インタフェースとは、そもそもの目的とは、といった根源的な問いを励起する、キーボード、ファミコンのコントローラ、マウス、Wiiリモコンに続く、良い切っ掛けデバイスだなぁと。
これらすべてに共通することは、見ただけじゃ「ふーん」で終わること。少なくとも私は、知っているだけの時は何とも思わなかったけれども、実際にいじってみて「おおー」というSense of wonder体験をして、ようやく頭が回り始めました。このあたりもキーボードなどと共通の体験でした。

まぁわたしゃ天才ではないので、想像だけだと動けないことが多い（TRPGは別よ）です。そういうのを直観的に理解しちゃう人が、多分天才なのでしょう。

とにかく体験は、してみるべき。目の当たりにして、実際にやってみると、操作を妨げないカメラの位置とか、アンビエントのレベリングとか、リバーブのパラメータだとか、自分の持っている他の知識といろいろ繋がりますね。
「指で壁をなぞると絵が描ける」って言葉で書くと「ふーん」ですが、実際に指で壁をなぞって、手触りとともに線が描けるという体験をすると、鳥肌が立ちます。指向性マイク×４ってのも面白そう。

そして…まさかのヴァーチャル鼻メガネ！ｗ


○17-C-2 仕事のバトン、渡っていますか？ - プロジェクト管理におけるコミュニケーション基盤作り
(資料未公開？)

JIRAというよりもTicketによる課題やバグの管理、TiDDについての考え方、啓蒙的な部分がメインでした。
そういう方法があることは知っているが、現実に自分が抱えている問題を解決できるのか、という「蜘蛛の糸」を求めているSIerの方々がターゲットだと最初に言われてしまったので、正直初っ端で聞く気が失せました。
で、そのお言葉通り、既にTiDDというものについて一定以上考えている人にとっては得るところがなかったのではないかと思いました。
タイトルに偽りあり。コミュニケーション基盤とは何か、基盤づくりの実例、といった話がなんもなかった。
自分にとっては１点だけ、末梢レベルで役立つ情報があったので、全く無駄だったとは言わない。
会場では熱心に頷いている方もいらしたので、たまたま私がターゲット外だっただけですね。


○17-C-3 オフェンシブな開発〜「納品しない受託開発」にみるソフトウェア受託開発の未来
http://www.slideshare.net/kuranuki/devsumi2012-11631411

倉貫さん(@kuranuki)の講演。
喋る速度がどんどん上昇して行くのですが、聞きやすく楽しいセッションでした。
頷きたくなる言葉が次から次へとでてきて、心楽しくなれます。
製造業の因習から脱却することで、実はお客さんも開発者も同じ方向を向いて幸せになれるという提案を、実際にやって成果をだしていて、なおかつ技術を向上させることと勤務時間の矛盾まで解消することで、開発者と経営者との対立まで解決してしまうという、素晴らしいコロンブスの卵だなぁと再認識しました。
普段ツイート等で伺っている内容を、事例付きでまとめてドカンと受け取れた（＝自分のモチベーションが上がった）のが収穫です。早速上司にメール出しましたしｗ


そうそう、お昼は鼻メガネ界隈の方々と一緒にランチ。
会長ズ(@riskrisk、@inda_re
こくぼさん(@yusuke_kokubo)きょんさん(@kyon_mm)、名古屋からお疲れ様でした。
品川redmine＆渋谷tracの懇親会も参加したかったわぁ。


たまたまオライリーのJenkins本を先行販売していたので、思わず衝動買い。
帰る時に覗いたら完売していました。
アジャイル見積本を買おうと思っていたのですが、こちらは今回持ってこなかったらしいので残念。別途買う。


といったところで撤収して、地元で眼鏡を直そうとしたらエライ金額になるので、結局作りなおしましたとさ。
本当は夜まで居たかった…orz

鼻メガネとはなんだったのか。

というわけで、日本鼻メガネの会第二回会合？に参加してきました。
前日に休出回避したはずが、当日の朝に喰らい込む罠のおかげで、二次会にも出られない体たらく。

ちょっと遅れて到着したが会長挨拶には間に合いました。
実は予約名とか覚えていなくて、店員さんに「コレの集まりなんですが…」と鼻メガネを見せたら即案内して貰えましたｗ

で、鼻メガネ装着して入ったら誰も鼻メガネしてねーでやんの。ヤラレマシタ。

で、まぁ@orange_clover氏の隣に陣取って@megascus氏からSIer話を伺ったり@krakeneye氏から個人名刺貰ったり@heroween氏（←妖怪退治の達人？どういうことなのか聞きそびれた）と名刺交換したり。

そう、個人名刺。作ろうと思ってずーっとそのままでした。作った方が便利だよね。会社変わったら名刺役立たずになるんだから。

軽食ｍｇｍｇやっていたら@kyon_mm氏がわざわざ席まで来てくれた。軽く軽口叩いて名刺渡し。個人名刺ェ…orz

軽く腹ごしらえが終わった段階で適当に移動して空いている席に座ったら、よく怖い怖い言われる人達（@changeworlds氏、@macneko_ayu氏）の間だった。会長と@inda_re氏に「挟まれたら裏っかえるよ！」って言われたが、元々そっち側ですしわたし。知ってるくせに。
そういや@sinsoku_listy氏のテンションが低めだったのだけれども、いまやっているプロジェクトがとんでもなく楽しいという話を聞いてちょっとほっこり。その節は（ピーーー）がご迷惑をお掛けしました…orz まぁもう俺関係ないんだけど（無責任）。

あとは荒ぶる冥土様とか総長様とかのお話は、多分他の方ががっつり書かれることでしょう。NUBoardを以前売り切れで買えず、そのまま忘れていたので、思い出せてよかった。買わねば。

そんなこんなで一次会だけで撤収。帰宅して設計に戻りましたとさ。
まぁ休日ダイヤなの忘れていてバスがなくて、最寄駅から一時間歩きましたけれども。

特にきょん様には申し訳ないことをしました。組込のいやーなお話をせねばならんかったのに。スケブ持っていくくらいには覚えていたんですよっていうかごめんなさい。次の機会には是非。

で、他の方のレポートを読んだら、@enumさんがとっても面白そうなお話をしていたとか。聞きたかったわぁまじで。多分いまうちの会社に一番必要な内容だから。

以上、技術ネタがなにもない記事、一巻の終わり。

再帰について考える

１）「再入」と「再帰」を区別する
まず用語の確認をしておきます。


○再入（reentrant）
メモリ上でユニークなあるモジュールを、複数の文脈で非同期に使用するケースを再入という、と理解しています。
文脈固有の情報はそのモジュールでなく呼び出し元が保持するので、複数タスクが非同期に、メモリ上の同一プログラムを使える状態です。


○再帰（recursive）
そのモジュールの中で、そのモジュールを（パラメータを変えて）呼び出すケースを再帰という、と理解しています。
計算の中間結果をモジュール自身が保持するので、呼び出し元はひとつでないとまずいです。


２）再帰の考え方
よく階乗やフィボナッチ数列が例に出されるが、結局は「ある処理の結果が、ある条件になるまではそのまま同じ処理の入力になるケース（＝再帰的アルゴリズム）」に対して適用できる考え方です。

ｎの階乗：ｎ〜１までの自然数を全部掛けた数（総乗）
→例えば５の階乗なら、５×４×３×２×１
→5×4＝20
→20×3＝60
→60×2＝120
→120×1＝120


ってな計算をしますが、これを、


・ある値を与えられたら、それが1なら1を、さもなくばその値×その値-1を返す関数を用意する
→値=5：5×(値4で呼出)
　→値=4：4×(値3で呼出)
　　→値=3：3×(値2で呼出)
　　　→値=2：2×(値1で呼出)
　　　　→値=1：1を返す
　　　→値=2×1が確定
　　→値=3×2が確定
　→値=4×6が確定
→値=5×24が確定


と考えるのが再帰。
これだと呼びだし元では
・5の階乗=値5で呼出
で済む、というお話。


でも大概はふつーの繰り返し構造でも実装できるし、再帰し過ぎてスタックを壊さずにすむ（普通の環境では関数呼び出しのたびにスタックを積むことになるので、再帰し過ぎるとスタック領域が溢れる）ので、パラメータ範囲がわからなかったりスタック量が潤沢でないなら、その方が安全。
所詮アルゴリズムなので、使えそうなら使えばいいし、さもなくば使わなければいい、というだけのことです。ただし知っていると思索の幅は広がります。
ソート済みのツリー構造で経路探索のアルゴリズムなんかやると、結構便利に書けますよね。


で、私が20年以上前に師匠から教わった端的な再帰の例。拡張BNF記法で数列の生成規則を表現したものです。


数字 = "0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9";
数列 = 数字,[数列];
※|はor、,は連続、[]は省略可を表す


実はこれ、先頭に0が来るケースがNGなのですが、とても直感的なので、むりやり再帰にこじつけたくて敢えて出しました。
wikipediaのEBNFに自然数の定義例がありますので、ご確認下さい。


こんなんで何かの一助になればいいのですが。

関数マクロスキー

コンパイルすら通していませんよっと。

#define ISBITON0_8(bytedat) (((bytedat) & 0x01)? 1: 0)
#define ISBITON1_8(bytedat) (((bytedat) & 0x02)? 1: 0)

…

#define ISBITON7_8(bytedat) (((bytedat) & 0x80)? 1: 0)

-----
unsigned char testdat;

if( ISBITON0_8(testdat) ) {
  /* 第0ビットが1 */
}

とか

/* arg0=byte-data, arg1=check-bit-num */
#define ISBITONn(bytedat, n) (((bytedat) & (0x01<<(n)))? 1: 0)

なんてのが好きな人もいますね。

ビットフィールドと共用体と

スーパーpre記法つかうとセンタリングされる…なんでやねん。

typedef struct {
  unsigned s1:1;  /* センサ1 */
  unsigned s2:1;  /* センサ2 */
  unsigned s3:1;  /* センサ3 */
  unsigned s4:1;  /* センサ4 */
  unsigned s5:1;  /* センサ5 */
  unsigned rsv:3  /* 予約（未使用） */
} SixthByteSt_t;  /* ６番目のバイトデータ構造体 */

typedef union {
  SixthByteSt_t bitdat;
  unsigned char bytedat;
} SampleUnion_t;  /* お試し共用体 */

-----
SampleUnion_t smpldat;

smpldat.bytedat = 入力値（byte）;  /* byte単位でデータセット */
if( 0 != smpldat.bitdat.s1 ) {  /* bit取り出し */
  /* センサ1がOn */
}

Wiiバーチャルコンソールでリモコンアサインがリセットされる

Wii トラブルシューティング

４歳になる息子はいま、Wiiバーチャルコンソールのバトルシティにはまっておりますが、リモコンの扱いが雑で、ついにメインのリモコンが壊れてしまいました。


※クラシックコントローラを挿すとハングする


で、大掃除のついでに新しいリモコン（モーションプラス内臓！）を購入してきたのですが…

０）リモコンを以下の通り規定
　旧１：壊れたメインリモコン（本体同梱）
　旧２：壊れていないリモコン（追加購入）
　新３：購入した新しいリモコン

１）Wiiのメイン画面でリモコンのプレイヤーアサインを変更する
　事前：旧１→１　旧２→２
　事後：旧１→（アサインしない）　旧２→１　新３→２

２）WiiSportsResortで動作確認
　→問題なし

３）バトルシティ（バーチャルコンソール）起動
　リモコンのアサインが以下の通りに変更される
　旧１：１　…のみ！
　※クラシックコントローラを挿すとハングするので遊べません


で、調べました。
結論としては、「Wiiリモコンのホーム登録が必要」でした。


ホーム登録＝Wii本体にWiiリモコンを教えてあげる

○Wii Q&A
http://www.nintendo.co.jp/wii/q_and_a/015.html


（３）の症状ですが、追加購入したリモコンもホーム登録していなかったので、バーチャルコンソールで認識しなかったようです。
バーチャルコンソールを起動すると、リモコン構成をリセットして、ホーム登録から取りなおすのですかね？
Wii用のゲームでは取りなおさないで、今あるデバイス構成を継承するから問題が起きない、と。。。


で、ホーム登録の方法は上のリンクにありますが、簡単に書いておくと、


１）リモコンの電池フタを開け、SYNCボタンを押す
　→インジケータが点滅する
２）Wii本体のSDカードパネルを開け、SYNCボタンを押す
　→しばらくするとインジケータが点滅を終え、プレイヤー番号になる


これで登録完了のようです。
バーチャルコンソールェ…。

分散バージョン管理勉強会

勉強会 Shibuya.trac バージョン管理

Shibuya.trac勉強会(公式タグ：#shibutra)にお邪魔してきました。

http://kokucheese.com/event/index/6329/
http://sourceforge.jp/projects/shibuya-trac/wiki/FrontPage

自分のニーズとしては、現在抱えている案件の作業環境が、

・客先業務で、【秘】案件である
・客先にサーバ(有線接続のみ)を立ててバージョン管理している
・「別館」に拉致されて長時間／下手すると徹夜作業することが多い
　→Subversionではこの間のコミットができない

というものがあり、同僚(@riskrisk)からgit-svnでいいじゃん、という話を社内での勉強会でいろいろ教わったのですが、他にもいろいろあるよ、というこれまた同僚(@kaorun55)に誘われまして、無理やり時間作って参加してきました。

全ての発表が非常に興味深かったのですが、他の方も日記更新されているので、自分にとって優先度の高いものだけをピックアップします。


○GitとHudsonによるきれいなリポジトリの作り方(@bleis)
・名古屋のイケメン首都襲来
・Masterの他に各UserCommit用リポジトリを用意し、MasterへのCommitはUserCommitが成功したときだけ、自動(Hudson)で行われる
　→理想的。しかも既に数か月稼働している！　真似したい！


○git-svn使ってみる？(@riskrisk)
http://highrisklowreturn.blogspot.com/2010/12/shibutra_19.html
・神速さんファンクラブ
・社内勉強会の復習＋α。目先の自分ニーズはまさにこれ


○Hudsonからみるバージョン管理(@cactusman)
・Hudson側からのLT
　→時間の使い方が絶妙
・自分のニーズにマッチ＆bleisさんの発表とも被って心強い


○SVNユーザのためのBazaarガイド(@wonderful_panda)
http://www.slideboom.com/presentations/266404/Bazaar-guide-(for-SVN-users)
・git、hgと比較して非常に露出が少ない３大ツールの一角
・建築デザイン屋の友人が資料のバージョン管理したいと言っていたのを思い出した
　→PC詳しくない人にも使い勝手が良いと聞いて！


○Git での歴史の改変方法の紹介(@sinsoku_listy)
・名古屋のイケメンvs東京のイケメン
・一番興味深いわけではないが一番楽しい発表！
　→会場の盛り上がり的な意味で…
・なんだかんだで強心臓？


○ビューティフルなデバッグの話(@tosikawa)
・神速さんファンクラブ会長
・最高にビューティフルなデバッグ＝デバッグしないこと！


Mercurialは、自分で使おうとはあまり思わなかった。なぜだろう。
git-svnとBazaarだなぁ。

最後に、運営の皆様お疲れ様でした＆素晴らしい場をありがとうございました。
時間作れたら次も行くぜ。