くまりゅう日記

もっと過去の日記
[.NET | BeOS | Blender | COLLADA | fossil | mono | monotone | NPR | OpenGL | PeerCastStation | Riko | Ruby | Silverlight | TRPG | XNA | ゲーム | ゲーム作り | プログラム | | 模型]

2016-06-02

[Ruby] TokyoRubyKaigi 11に行った

TokyoRubyKaigi 11に行ってきた。

何で気付いたか覚えてないが(gihyo.jpの最近のイベント欄あたりかなぁ)、たまたまサイトを見たら面白そうなセッションばかりが並んでいたので興味がわいた。しかし28日は既に妖精帝國のライブが予定に入ってたので無理じゃねーか! て話をしたらはしごしようと言われ、まあライブは夜からだし行けるかと思って両方行くことにした。

朝は9時50分に着けばいいんだろうと思ってゆっくりしてたら出るの遅くなって10時着。しかし9時50分からなのは開会の挨拶だったのでまあいいか、と思って中入ったら10時から開会の挨拶が始まった。間に合った……?

Streemの話。Streemの話だった。 パイプの定義?が終わってから実行されるて話なので宣言的プログラミングなのか? なんかErlangとかもそんな感じと聞いたことがあるのでそういうものなのかもしれない。 知らんけど。 ゲームにもいいかもしんないというのはまあまああるかもしれない。 でも最近のゲームだとNPCも環境を受け取って脊髄反射するだけじゃなくて記憶持ったりとかあちこち参照するからどうなんだろなー。 多次元の参照が云々という質問は描画というか画像処理をStreemでやるような想定だったんだろうけど、どっちかというとキャラクタの制御についてゲームって話なので描画は対象外だろう。

mruby/cの話。mrubyでもまだちょっとでかいので、もうちょい小さいデバイス用のmrubyを作ったてやつ。 とはいえまだ400kBくらいはメモリ使うようなので、Arduinoのような極小デバイスでは無理ぽい。 まあ動いたとしても速度的に問題あるよね……。 一つのVMで複数のプログラムを同時実行できるように拡張されてるようだ。 mrubyの1命令実行毎にコンテキストスイッチするようなマルチプロセス機能。いいですね。 割り込みに対応してこのプログラムが動くとかいうのはできるんですかっていうそりゃ当然できるだろ的な質問をしてしまったが、複数のプログラムが起動直後に割り込み待ちに入って寝るという使い方を想定してるとのことだった。なるほど。 しかしだいぶ機能もまだ少ないようだし、動作環境的にあんまり派手なプログラム動かすもんじゃなさそうなんだけど、それでもRubyで何を作ろうってのかがいまいち想像つかんな……。

Rubyの型の話。型の話だっt……じゃねーよ! クラスのチェックをするのがあれば便利かという話で進んでたが、最終的にはそうでもなくてパターンマッチぽい。 想定外の型を入れた時にエラー投げてくれるTypeStruct1というのを作ったよという話。 Structのようにメンバ定義する時に、型を指定しておくと値が入る時にそれをチェックしてくれるとのこと。 しかし指定する型は型じゃなくてもよくて===でマッチすればなんでもいいので正規表現でもいいみたい。パターンマッチだ。

最初はシンプルだったが、JSON読み込んでぶちこんだ時に検証したいということで、配列を指定できたり、○○の配列を指定したり、複数の型のいずれかを指定できたりするように拡張していったとのこと。 面白いのがTypeStruct自体の拡張はされてなくて===に反応するラッパオブジェクトみたいなのをどんどん追加してったてのがいい。アクティブパターンぽい。 まあそれで最終的にJSONが検証できるようになって型があるとうれしいこともあるねとかでまとめてたんだけど……つっこみどころは多いなぁ。

JSONの検証をしたいなら、そういうDSLとライブラリなり使えばできるんでそれで済むじゃん。JSON用のスキーマフォーマットっていくらもあるし検証器もいくらもあるよね。検証だけじゃなくてRubyでパースしてアクセスしたいってなら、スキーマからアクセス用のRubyプログラム生成すればいいよね。おわり。 型があるといいよねとは言ってたが、どちらかというとデータの検証がしたいというところだったので、プログラムの一般的にあるといいかって話ではなかったわな。スキーマと検証器はあると便利だと思います。スキーマをRubyで書く必要は無いと思われます。

型の話ってよりはパターンマッチとして見た方が面白かった。 なんでも===でマッチさせるから===に反応するオブジェクトを作っていこうってのがいいね。 まあだたのcase~whenだと言われりゃそうなんだけど、なんか難しいパターンマッチを導入するよりは、やっぱりcase~whenをもうちょい上手くすればいいんじゃないかなぁと思わせてくれる感じだった。

お昼。土曜日12時過ぎの秋葉原駅前で一人で飯食えるところなんてあるんだろうかと思ったが、とりあえず近くのアキバ・イチを覗いてみたところ、どこも空いてて一人で入るのも余裕であった。こんな空いてて大丈夫なんだろうか。平日の方が逆に混んでるやつかもな。適当な店で1000円のランチを頼んだら思ったよりおいしくて良かった。

午後。Webサーバの話。HTTP/2対応のWebサーバでH2Oてのがあるらしいんだけど、それで速くするのにどんなことやってるかなど。 RTTばっかりはなんとも短くならんので、パケット自体を少なくしたいとか。送信キャンセルする時も確実に最小パケット数でキャンセルできるように、書いたらすぐに送られるサイズをできる限りOSから取得(+予測)して常にその分ずつしか書かないとかすごいわくわくするチューニングが語られた。TLS部分も自前で書いてるようだ。そりゃそうなるだろうけどすごいなぁ。

アプリからCRubyを呼び出す話。初期化がいろいろ大変だとか、forkすると大変だとかシグナルの処理が大変だとか。まあだいたい知ってたので特に新しいところはなかった。 話には出てなかったけど初期化とかバージョンによっていつの間にかしれっと変わったりするのが大変だよね。 あとこれも話に出てなかったけど、CRuby自体をビルドしてリンクするってのが大変だよね……ってWindowsじゃないからいいのか。 拡張ライブラリもいいけどmkmfがしょっちゅうしれっと変わってるのが大変なんだよな。

パターンマッチングの話。本当にパターンマッチングの話。パターンマッチングの文法の叩き台になるライブラリを作ったってことだった。しかしアンダーバー頻出で見辛いしよくわからなかった。なんか正規表現的なのがどうこうとかバックトラックがどうこうとか言ってたような。パターンマッチングにそこまでいるかなぁ……。 正規表現がどうこう言うならPEG書けるような内部DSL欲しいよ。パターンマッチングと別に。 ちょっと複雑すぎるのでよくわからん。とりあえず===でマッチさせますくらいがわかりやすいんだが……。

Rubyで画像認識した話。MtGのカードを売ろうと思ったが、持ってる8000枚のカードのDB作って価値を調べるのはきつすぎるのでそれをやるプログラムを書いたとのこと。まずマスターのDBは公式サイトから30分で1.6GB分もぶっこ抜いてきた(ひでえ)が、実は既にそれをJSONで提供してくれてるサイトがあったのでそれ使えば良かったとのこと。先にググれと。 画像認識はOpenCVだけどそれなりにステップは必要なようだ。とはいえ自前で書こうとしたら諦めるレベルだし、ずいぶん簡単だよな……。 取り込んだ画像の判別はphashっていう画像のハッシュ値があるらしくそれを計算してくれるライブラリを使い、あとはハッシュ間のハミング距離が近いものを表示してユーザが選んで学習させていくと。ほえー、簡単そう。 で簡単なライトボックスの前にWebカメラ設置して、そこにカードを置くと勝手に認識してカード候補を出してくれると。\しかしWebカメラの自動ピント調整が数秒かかるのが遅いみたい。そんなにピント変わるような想定のカメラじゃなさそうだしなぁ。あと手動でカード置くのもめんどいとのこと。カメラはともかくカード送り機は大変そうだな……。

というあたり。残り2つもすごい聞きたかったんだけど時間的に17時前になってしまったのでそこで抜けてきた。 ライブが渋谷で18時開演だったので……。

エモい話は無しでっていう方針だったらしくテクい(?)話ばかりでやっぱり面白かったな。今後もこの方向で期待したい。

  1. しかしTypeStructじゃなくてTypedStructの方が名前として妥当よね……。TypeStructだと型自体を入れとく構造体ぽい。 


ページのトップへ | トップ «前の日記(2016-05-30) 最新 次の日記(2016-06-13)» | 編集 | kumaryu.net by kumaryu