#ahack2 の幹事をしたよ

#ahack として実績のあったハッカソン第二弾ですね。@ashigeru氏、@y_koh氏なんかと、ちょっとITSの会議室どうかな?、というような話になり、僕もscala hack-a-thonなんかで発火村たのしいっすね、という感覚があって、やってみることにしました。

最初は人が集まるか不安でしたが、主催者より速いエントリをする@shin1ogawaを皮切りに、当日出席率100%なhack-a-thonとなりましたhttp://atnd.org/events/3508 。今回は正直、ahackという割とappengine界で影響力がありそうな人が集まるものではなく、最低3人くらいでもやろうかなーという感じでやってたのですが、あれよあれよで面白い集まりになりました。詳細が気になるかたは、#ahack2でtwitter検索すればだいたい大丈夫だと思います。


時系列でいろいろ思い返していくと、

前日:@shin1ogawa氏に前日徒歩で会場に向かうようにけしかけられる。さすがに無理。寝る。

当日午前:華麗に目覚める。ちょっと遅刻するかも、と焦りながらも、10:00には会場準備がほぼ整い、ちょうど時間通りの@WdWeaver氏のfon routerに救われる。@shin1ogawa氏の、ちょっとケーブルが気になる電源にも救われる。午前中は人が集まらない疑惑が浮上しつつも、この時点で11/12な集客率の高さ。

午前中は個人個人で書きたい放題書いてました。

当日昼:飯。近所の中華料理屋で@ashigeru氏の花粉症について、また、ハッカソンってどう?、な話題について。アウトプットが要求されるハッカソンもそれはそれで良さがあるけど、こういう個人個人でゆるく進めるのもいいよね、という話に。

午後Ⅰ:直近あったdevfestのフィードバック会議。資料はこちらなかなか参考になる話題がそろい踏み。特に、marge joinがapp sideの話題であること、appengineがgoogleにおいて支配的な話題ではなく他サービスの実装との兼ね合いであることはわりあい現実のSIとも事情が同じであるというようなところで、参考になるところでした。アーキテクチャのスケーラビリティに依存しつつも、アプリケーションのスケール容易性が意味が微妙に違うところも重要ですね。個人的には、marble-broker(笑)となってしまったのが残念と言えば残念ですが、もっとスピード感をもってリリースしないとgoogleには勝てないという、そんな勉強になりました。

スケールアウトがなんらかの規則性をもってリソース予測しているという話題で金融っぽい僕に話題がふられましたが、マルコフ連鎖なんて多分数学論理の世界でも金融ではつかってない(僕が知らないだけで数学レイヤの話ではなんかあるかも)、拡散過程は役に立たなそう、オルンシュタイン・ウーレンベック過程/レヴィ過程とか数学の素人としては思い返したりしつつもなんかそもそもちがうっぽいし、むしろ、統計的という観点では交通業界や飲食業会の一部で適用されるyield managementの話題がそれに近いのかも、と思いました。まぁなんか、直近のリソース使用量の線形回帰とか?とか思ったりしましたが、重いnodeを優先的に落として再ロードさせたりするようなので、たぶん情報工学の人がスループットあるいはTATを最大化させるような計画法を考える方が事実に近い結論が出るのだと思います。


さて、京都会場の@bufferings氏ともskype経由で合流し、いい感じにサテライト会場連携もできました。実は参加者13/12でしたね。skype経由でのサテライト連携はいいんじゃないかなと思います。LT挟むならust経由もありかな。とか。

午後Ⅱ:@ashigeruによるclassloderの説明。なんでこの話題になったかというと、僕のscalaツールでrunnnableをリモート実行できないか?というテーマがあったからです。ローカルのrunnableをシリアライズ/デシリアライズするだけだとコンテキストが引き継がれないのでいやーん、ということのvmレイヤからの整理ですね。RMIやなんや言葉としては知っていても使ったことも実装したこともないので、いろいろ勉強させてもらいました。@ashigeruがreturnするのを忘れていたあたりで人であることが再認識できて良かったです。「あのひと、コンパイラだと思ってた」。実装するまでには至りませんでしたが、もしかしたらあれやこれやするとリモートに処理を委譲させることができるかもしれない、という感触はつかめました。

その後、各自自作のアプリやツールを実装しつつ12人全員合流で黙々と作業していました。僕はscalaのリモート呼び出しツールをつくりつつ、@ashigeruの資料作りの悩みを聞きつつ、まぁ俺トランザクショニストじゃないしなぁ、まぁエンティティグループはもうそろそろわかってることでいいんじゃないか、という。僕はあんまり詳しくないですが、PHPについてそれっぽい意見交換もなされていたようでした。あとは煙草吸ったり。そんなまったりとした午後でした。

そうそう、最近google api expertに認定された@kazunori_279氏のノンアルコールビールへのこだわりの話も聞けました。僕は残念ながら薄味なkirin zeroが食中酒としてはいい感じと思っています。いつか袂を分つときがくるのかもしれません。

なんやかんやで、ローカルの開発環境問題を抱えつつも、scala interpreterによる一通りのappengineリモート呼び出しを実装したので、ちょっと簡単に説明してみることにしました。

LTⅠ:おれおれscalaツールの説明。Queryがselect * from kindなデータ構造になってることがわかるあたりは好印象。結局、gqlに翻訳されてるイメージなんですよね、あれ。できることはjrubyのリモートツールとそれほど変わりはないです。サービス呼び出しのrpc protocol bufferをもりもり出すあたりは来週金曜のajnにおあずけしました。あれはあれなんですよ、あえての演出なんですよ。スペルが間違ってるとか、きっとよく見るとそんなことはないんですよ。今後実装が進めば、sbazの形でリリースしたいです。乗り越えるべき壁がいくつかありますが。。

LTⅡ:@urekat氏によるrubyリモートプロファイラ(と言っていい?)の成果発表。すごく率直な感想として、jrubyのspin up問題を抱えつつも、現状のappengine/p /jと比較してjrubyが開発者に対して優れたツールを提供しているなぁと。このへんは、appengine/jが遅れていて、appengine/jが遅れているということはjruby/scala/closureにも影響があるので、それなりのツールセットのコア部分はjavaで実装されていてもいい気がしました。個別の言語の良さは、ラッパーみたいなものでカバーすれば活かせる?、だろうし。

LTⅢ:@kazunori_279氏によるdevfestのデモの説明と、ajn3から「あたためてきた」core warの紹介。core war面白げですね。サーバーの死活監視さながらのkazunori_279氏ロジックはクラウドのアーキテクチャを連想させるようで、これはこれでajnでの発表があってもいいのかもしれません。クラウドのノードの使用方法がゲームという形で置き換えられたルールで検討されてもいいのかもしれません。

その後、懇親会も10/12 + @najeira氏でおいしいあぶり焼きを堪能しました。みんな話に夢中だったかもしれませんが、あそこ結構おいしかったので、次回もあそこにしましょう。常連になったら色つけてくれそうです。


次回やるとすると、京都の@bufferings氏と一緒に京都/東京同時開催ですね。溜池山王で120人会場を押さえてもいいのですが、今のat homeな雰囲気がいいと思っているので、同じ場所の20人会議室、次回ajnの前週で開催予定ということにします。このへんは空気を読みつつですね。好きなタイミングで世界の亀山モデルを使ったLTができるのは面白いと思うので、今後も続けたいと思います。


ということで、参加者のみなさん、ありがとうございました。
次回もよろしくお願いします。