leapmotion sdkをsbtで動かしてみた

LeapMotionを購入して、いろいろ遊んでいる。

で、SDKを見ると、javaのSDKがあったので、せっかくだからScalaで実装して遊ぼうと思い、まずはSBTでLeapMotion SDKが動く環境を作ってみた。

まずはLeapMotionのDeveloperサイトでユーザ登録し、SDKをダウンロードする。

次にSBTプロジェクトを作成し、libディレクトリに"LeapJava.jar", "libLeap.dylib", "libLeapJava.dylib"を置く。

SDKにJava用のサンプルコードが入っているので、それをScalaで書きなおす（IntelliJ IDEAでコピペしたら勝手にScalaに変換してくれるw)。

ここまでは順調に行ったのだが、僕はここで詰まった。

lib配下に置いた "libLeap.dylib", "libLeapJava.dylib"はネイティブライブラリであるので、普通のjarファイルと違ってlibに置いただけではSBTでロードすることができない。

"-Djava.library.path"で明示的にlibディレクトリを指定する必要がある。

SBTでrunコマンドを実行すると、通常はSBTが動いているのと同じJVMで実行されるから、単純に考えるとSBTの起動時に"-Djava.library.path"オプションを指定してやればよさそうなのだが、これではうまく動かなかった。

なので他の方法を。

build.scalaにいくつかの設定を加えてやることで、runコマンドでの実行時に使用するJVMをSBTが動いているのとは別のものにすることができる。

Forking

そこでbuild.scalaに以下の設定を入れてみる。

fork := true

javaOptions ++= Seq(
   "-Djava.library.path=.:./lib"
)

これで実行してみたが、コンソールからの入力を受け付けてくれず、思った通りに動かない。fork run時に、標準入出力の設定をきちんと書いてやらないといけないようだ。

そこで次の設定を追加。

connectInput in run := true

これで動いた！！

ちなみにこれらの設定を入れたsbtプロジェクトのテンプレートをgithubに上げといた。

leapmotion-sbt

さて。やっとスタートラインに立ったので、なにを作ろうかなー？

デュシャンの「大ガラス」に出会った不思議な旅

この土日に東京に行っていた。

目的は土曜日の夜に、某オフ会に参加するためだ。

彼らとは２年ほど前からの付き合いで、年に1, 2度会うだけなのだが、会えば昔からの友人同士のように語り合える。この2年、いろいろなコミュニティに参加してきたが、ここが今の僕の原点で、人生で最初に参加した「コミュニティ」でもある。

彼らとは出会う前からオンライン上の付き合いがあったためか、初めて顔を合わせた時から、旧知の友人同士のような関係が築けていたような気がする。

彼らとの出会いで、僕はIT系コミュニティという存在を知り、はじめてのライトニングトークを経験し、多くの仲間と出会えた。

去年、僕が転職した当時、このコミュニティで知り合った友人の二人が京都にいた。僕も京都の会社に就職したので、これで彼らとしょっちゅう飲みに行けるぞ、と思っていたが、結局それが叶わないまま、二人とも時期は異なるものの、仕事の都合で東京に行ってしまった。このオフ会は彼らと久しぶりに再開した場でもあった。

オフ会の主旨自体は、コミュニティのメンバーだった一人と、諸事象によりしばらく会えなくなってしまうため、その前にみんなで会おう、という集まりだった。

なんだかみんな、遠くに行っちゃうなー。そんな事を思いながら、その夜はお酒を飲んだ。

翌日。ホテルを出て、このまままっすぐ帰ろうかと思ったのだが、なにげに道路に設置されていた周辺地図を見ると、近くに大橋ジャンクションがあるというので見学して帰ろうと思った。僕は洋の東西や規模の大小を問わず、珍しい「建築物」が好きなのだ。

ひとしきり大橋ジャンクションの威容を愛でたあと、帰りの時間は特に決めていなかったので、周囲を散歩してみようと思った。

特にあてもなく住宅街を歩いていると、なにやら緑の深い一帯が見える。公園でもあるのかと思いそちらに行ってみると、そこは公園ではなくて、東大だった（笑）

駒場キャンパスだ。

一人で日曜日に大学キャンパス内を歩いていて、不審者と思われたらやっかいなので、とっとと立ち去ろうと思ったが、そういえばここにはアレがあったんじゃないか？ とある記憶が頭をよぎった。

僕はマルセル・デュシャンが大好きで、死ぬまでに必ずフィラデルフィア美術館で彼の遺作を見ようと心に決めている。そんなデュシャンの代表作『花嫁は彼女の独身者達によって裸にされて、さえも』（通称大ガラス）の東京バージョンが、駒場の美術博物館に常設されていたはずだ。

いつか観た来たいと思っていたが、東大のキャンパスやその近くに来る用事などあるはずもなく、また、わざわざこのために来るというのもはばかられていたので、ずっと機会を伺っていたのだ。

キャンパス内を探すと、美術博物館はすぐに見つかった。中に入ると、展示ホールの中央にそれはあった。去年、マン・レイの写真展で、彼の「埃の培養」という作品越しに観た、ガラス板（埃の培養に写っているのはオリジナル版で東京バージョンではない）。
あの、作品を象徴するガラスのヒビが入っていない、フラットな表面。念願の「大ガラス 東京バージョン」だ。

これを観た瞬間、すごく不思議な気持ちになった。昨夜、なんとなくさびしい気持ちでお酒を飲んで、その翌日にまったくの偶然に、ここにたどり着いた。この作品が向こうから僕に近づいてきてくれたような、そんな感覚だった。

この土日は、なんだが不思議な旅だったが、来てよかったと思った。

関西ソーシャルゲーム勉強会は超熱い勉強会だった

第4回関西ソーシャルゲーム勉強会 で発表してきました。

先日、ソーシャルゲーム会社の交流会 に参加した折に登壇の依頼をいただいてお話をしてきたのですが、想像以上に熱い勉強会でした。

80名近い人が参加する、という大盛況ぶりで「関西にソーシャルゲーム関係者ってこんなにいるのか！？」と驚きました（そりゃいるだろうけどもw）

今回はDeNAの川上さんが登壇されるということも、楽しめたポイントでした。これまで、GREEさんとか、サイバーエージェントさんの人とは他の勉強会で交流する機会がありましたが、DeNAさんの中の人とお会いするのははじめてだったので。

僕はいつものごとく「乙女ゲーム」の話をしてきました。
以前、Scalaカンファレンスで発表した際に、「発表タイトルに"乙女ゲーム"と入っていたから期待してたのに、あまり乙女ゲーム成分がなかった」というフィードバックをいただきまして、その反省を踏まえて構成を考えました。

ご依頼があればどこにでも喋りに行きますので、オファーお待ちしておりますw


今回の勉強会では、広告戦略の話などで具体的な金額の話なども飛び出し、「えっ！ そこ言っちゃうの！？」というこれぞ関西のノリ、という濃い勉強会だったと思います。おそらくは「ソーシャルゲーム関係者の集まり」という会場のコンテキストだからこそ実現できた内容なのだろうと思います。Google相手に金額交渉で値切る、というのはすごい話でしたw

懇親会は、LTを交えながらビアバッシュ形式で行われました。
僕らが普段よく参加する勉強会は、エンジニアの集まりがほとんどなので、懇親会でも技術の話が多いです。しかし、今回はデザイナさんや営業さんなど「ソーシャルゲーム」に関わるいろんな職種、業種の方が集まっていました。そのため懇親会でも、開発会社さんやデータセンター事業者さんからの売り込みがあったり、すごく新鮮な感じでした。

普段、「ソーシャルゲーム」という枠組みの中で、各社が交流する機会というのがまだまだ少ないですから、こういう懇親会もいいなー、と思います。

ソーシャルプラットフォーム各社さんも関西に進出してきていますし、もっと業界を盛り上げていきたいです。

DevLOVE関西「SQLアンチパターン・レトロスペクティブ関西・リターン 」 に参加しました。

DevLOVE関西「SQLアンチパターン・レトロスペクティブ関西・リターン 」 に参加しました。

「SQLアンチパターン」の監訳者である和田さん親子を招いての勉強会です。



最初に、和田卓人さん の講演で25のパターンに関する説明を受け、その後グループディスカッションで自分たちの経験を25のパターンに当てはめて議論し、最後に26個目のパターンを見つけて名前をつける、という流れでした。

個人的には「SQLアンチパターン」に書かれてある内容は、ほとんどすべて見たことがあります。実際に自分がデータベース設計をするにあたって、やってしまったパターンもいくつもありました。

ただ、最近はソーシャルゲーム開発に携わっていることもあって、あまり設計時にガチガチにER図とにらめっこすることが無くなりました。DB側で制約をつけすぎると、柔軟性が損なわれるので、DBは最低限の「入れ物」と見なす事が多いからです。

また、ORMなどを使うのであまりアプリ側でSQLを直接書いたりしませんから、複雑なSQLクエリを書いて仕事をさせる、というよりは最低限のWhere句でデータの塊をとってきて、実装側で加工することが多いです。特にScalaのコレクションAPIはそれをしやすい機能だったりするので。

そのため、最近はここに書かれているアンチパターンは、特に意図せずとも遭遇する機会が減ったなー、という印象でした。

そういう話をしていたら、「RDBネイティブとNoSQLネイティブの世代間ギャップを最近感じる」という意見が出されたりして、興味深いディスカッションになりました。

最後に、いつも会場提供くださる楽天さん、ありがとうございます！
毎回おもしろい勉強会を開催してくださるDevLOVE関西スタッフの皆さん、ありがとうございます！

上司に怒られないExcel方眼紙の作り方

Excel方眼紙 Advent Calender 2日目です。

Excel方眼紙ドキュメントには、それ自身よりもやっかいな問題があります。

それはレビューです。
Excel方眼紙はその特性上、レビューにおいては、その設計内容よりも罫線のズレだとか、印刷がはみ出るとか、本質とまったく関係ないクソみたいな指摘に終始する傾向があります。

Excel方眼紙には、制作時点で気にかけておかないといけないことが山のようにあり、これらを怠ると徹夜で方眼紙の罫線を引き直す、という謎の作業に従事させられることになるわけです。

そういったことがないよう、いくつかの注意点をみていきましょう。

１． 印刷プレビューを信じるな。

Excelの印刷プレビューはエイプリルフールのインターネットのように信用ならないものです。印刷プレビューで綺麗に枠の中に文字が収まっていたとしても油断なりません。枠線ぎりぎりの文字は、必ずはみ出ます。枠に対して、文字は余裕をもって余白を開けるようにしましょう。
Excelはワープロソフトじゃないからね！

2.  改ページの罫線に注意

ちょうど罫線が改ページに差し掛かっている場合、注意が必要です。
改ページの上側のページでは、印刷時に綺麗に線が出力されていても、下側では線が出力されないことがあります。
こういうところは、レビューする上司もまっさきに目をつけるポイントですのできちんと確認しておきましょう。
そんなことよりロジックの妥当性を見ろよ！

3. お絵かきの図は、方眼紙の枠線にあわせる

Excelでシーケン図とか、クラス図を書く場合があります。
このような場合、シーケンス図の縦線や、クラス図の四角い箱の線が、方眼紙のマス目の線と完全に一致するように書かないと、たいていの上司に怒られるはめになります。

オートシェイプを選択し、ダブルクリック。描画ツールの書式タブの[配置]を選択し、[枠線にあわせる]にチェックを入れましょう。

これで、オートシェイプは方眼紙のマス目に沿って描画されるようになるはずです。

Excelは図形描画ツールじゃねーよksg!

これらの注意点を守って、みなさんも快適なドキュメントライフを送ってください。

さて、わたしはこれからwikiに仕様書を書かないといけないので、これにて失礼！

2012年度末をもって退職しました #hogedriven

この度、株式会社HOGEDRIVENを退職することになりました。

株式会社HOGEDRIVEN

この会社にはいろいろな思い出があります。
最初に携わったプロジェクトは、「焼肉小倉優子のサイトにあるゆうこりんのプロモーション動画を再生する」という案件でした。

@irofさん、@backpaper0さん、@kiy0takaさん、@tan_go238さんといったそうそうたる顔ぶれが集結していたプロジェクトでしたが、結局誰ひとりとして動画を再生することができず、デスマプロジェクトの深淵を垣間見たものでした。

その焼肉小倉優子西中島店も、今は閉店してしまったようです。

メンバー全員、楽しく仕事をしていたわけですが、いつからか「だいくしーは老害化した」という話題を社内で聞くようになりました。

僕がSIer時代に培ったExcel方眼紙マネジメントを推進しようとした結果ですが、誰も賛同してくれなかったのです。

@tan_go238さんはカレーばかり作っているし、@kiy0takaさんはなにかにつけてGroovyを推してくるし、@backpaper0さんはPCの壁紙を新婚旅行のイタリア写真にしてドヤ顔。@s_kozakeさんに至ってはある金曜日に「この土日はドラクエ三昧ですよ」と言って帰宅したまま、二度と出社してきません。

@Posauneさんの開発環境はMacのVMware FusionでIKVM使ってC# でTwitter4jを動かす、というわけのわからない始末。

そしていつの頃からか、楽しそうにテストを書いている@irofさんの腕に輝くグリーンバンドですら、僕にとって嫉妬の対象となってしまいました。

ある日、社長の@hogedrivenに会議室に呼び出され、こんな事を言われました。
「我が社も某社の海鮮丼のような目玉が欲しい。@tan_go238のカレーをその位置に据えようと思うがどうか」というので、「カレーはもう他社がすでにやっていますよ」と答えたところ、逆切れされるという事がありました。

ぼくはこれ以上、この会社で働くことはできそうにありません。

そんなわけでHOGEDRIVEを退職し、@kuchitama さんとフリューという会社で楽しく乙女ゲームを作っていますので、みなさん今後共よろしくお願いします。

今度のhoge駆動はなぜ再演なのか？

2013年最初のhoge駆動イベントの募集がはじまりました。

ステーキ駆動 - なるほど！ザ・春の再演スペシャル！ あのステキな発表をもう一度

今回は少しいつもと趣向が違って「再演スペシャル」です。基本的にこのイベントで登壇者が発表する内容は、以前にどこかの勉強会でやった再演に限定する、というルール。

つまり、みんなの自信作、鉄板ネタが持ち寄られるはずだから、全発表バカウケ間違いなし、まさに、スベらない勉強会！！

というのはまぁ、半分冗談なんですが、なぜ僕が今回再演イベント面白そうだなーと思ったのか、その理由をちょっと書こうと思います。

コミュニティ活動に熱心なITエンジニアはいろんなところで発表機会があります。しかし、たいていはどれも一発勝負です。まれに、懇親会で飛び込みLT大会なんかがはじまって過去のLTネタを引っ張りだしてやったりする場合はありますが、やはりそれもレアケース。

一発勝負というのは少しもったいないなーと思うのです。

僕は、去年１年間と、今年のScalaカンファレンスとで、『乙女ゲームを支える技術』という発表をあちこちの勉強会で披露しました。勉強会によって枠の時間が違ったり、play勉強会とscala勉強会では内容の比重をそれぞれ向けに少し倒したりとアレンジは毎回変えていますが、たぶん6, 7回くらい、同内容の発表をしました。

毎回新作を作ることもできますが、僕は意図的に去年１年かけて、同じ発表をし続けました。毎回、顔をあわせるような勉強会の常連さんからは、「もうそろそろ、だいくしーさんの新作見たいです」と言われたりもしましたし、そう言ってくださる方には申し訳ないのですが、これは自分なりのチャレンジだったのです。

去年一年間は、新しい会社に入社した直後だし、せっかくScalaとかplayとか、面白い技術を使って、乙女ゲームという面白いサービスを作っているのだから、それのブランディングをしたいと考えました。

ひとつの勉強会に50人が集まるとして、一発勝負だと僕の発表が届くのは50人です。それを５回続けると、250人にまで拡がります。もちろん、聞いてくださる人には重複している人もいらっしゃるでしょうから、単純に250人ではないでしょうが。しかし、発表者としては同じ発表の繰り返しであっても、それを聞くほとんどの人にとっては「最初で最後の1回」なわけです。その意識を持ち続けて同じ発表を繰り返すことも、なかなかしんどいチャレンジでした。

発表者的にも再演はいろいろなメリットがあります。同じ発表でも、その時々で、ウケるポイントとか、反応が全然違ったりします。
同じ発表を、それぞれ異なる雰囲気の勉強会で、クオリティのブレなく繰り返すというのは、物凄く難しいことで、この１年で場の空気を読みながら発表の間の取り方とか、話し方を変える、というスキルを身に付けることができました。

僕自身が「再演」でいろんな得がたい経験をしたので、みんなもプレゼン力を鍛えるためにやってみるといいよ、と思って企画した「再演スペシャル」。ぜひチャレンジしてみてください！！