YAPC::Asia 2009に行ってきました(9.11)

·4 分で読めます
YAPC::Asia

すごい今更ですが、記憶が残っているうちに9.11のYAPC::Asiaのレポートをば。2日目も色々セッションに参加したのですが、特に記憶に残っている最初の2つだけ。

DeNA loves Perl

notoさん。スライド

  • DeNAはエンジニアは100人ぐらいで半分ぐらいはモバゲー

  • 今回のYAPCでも3人がセッションで発表している。(hidek, zigorou, matsuda)

  • 最初のbiddersはJava+Oracleだった

  • モバオクを川崎さんが作る時に初めてPerlをつかった

  • Perlは読みやすい、実行速度も速い

  • 最近はmyDNSのDNS RRの代わりにLVSを使うようになった

  • memcachedも使っている

  • MySQLのshardingもしている。モバゲーでは90個ぐらいに分割されている

  • mobamail

  • モバイルのメール配信 - キャリアの都合で接続がdenyされることがある。大量に送り続けるとdenyされる

  • キャリアのMXレコードは異様に少ない

  • docomo.ne.jp - 4IP

  • ezweb.ne.jp - 1IP

  • softbank.ne.jp - 1IP

  • キャリアのメールサーバが少ないから、送信側で送信先を分散できない

  • mobamail - Perlで実装したモバイルメール向けの配信サーバ。配信するだけなのでMTAじゃない(SMTP受ける方は実装してない)

  • コネクションを貼るところでIO::Selectを使っている

  • キャリアの制限の範囲内でなんとか最速で配信できるようにする。キャリアごとに細かい設定ができるように。

  • SIELLA Engine - より速い。さらに自分たちで設定しなくても楽。最近はこっちを使っている(ズコー)

  • (話は変わって)モバゲーのオープン化について

  • OpenSocial + Game API 法人に解放

  • 10/5 にフォーラム。来年1月以降に一般公開

  • DeNAのエンジニアのポリシー - ビジネスの成功にコミットすること

  • お金で解決しない。技術で「安く、早く」

  • ビジネスの成功を重視しているので、きれいな技術が二の次になっているのは否めない

  • 100人近くPerlエンジニアがいるのにCPANコミットがない

  • 他社の特許侵害のリスク(一部上場しているので目をつけられてしまう)

  • やりたい人がいたら推奨しようとしているが...

  • DeNAのPerlでの開発方針

  • 「一筆書き文化」：再利用せいや汎用性の設計に時間をかけるくらいならそういうことは考えずに書く方が速い

  • サービス単位の独自性・機動性重視＝モジュールの共有なし

  • 割り切りの思想、逆転の発想、これでサービスを速くリリースしてきた面も

  • 今後の展望

  • 大きな開発チームでのポリシー

  • more test code

  • MobaSiFの次のバージョン

  • DeNAで一緒にコードを書きましょう!

  • as DeNA software engineer / architect

  • as developer of moba-ga town

  • as CPAN author

携帯向けのメール配信でSIELLA Engineを使っているのが驚きでした。ああいうモバイル向けのパッケージ製品って他にもKlabのアクセルメールとか良さそうなのいっぱいあるし、やっぱり餅は餅屋にって感じなのでしょうか。

モバゲーのAPIがオープン化されるということは、PC向けにFlashでゲームも作れるのかな？というのが気になりました。現状モバゲーのPCサイトってモバイル版のはりぼてみたいなものなので、これを機にPCサイトも盛り上がるといいのかなぁと。

endeworksでのWeb Appの作り方

33rpmさん(船木太郎さん)。スライド

  • 牧さんが代表の会社です。

  • 特別なことはやっていない

  • 開発サーバは用意していない(個人のMac上で開発)

  • Test::FITesque が最近の流行り（読み方よくわからない）

  • ディプロイ - git pullするだけ。ディプロイツールといったものは使用していない

  • Apache+FCGI - daemontoolsでFCGIのプロセスを管理

  • Catalystを使用

  • Mooseを使用 - Catalyst 5.8をプロダクション環境で使用

  • APIモジュール

  • CatalystのModelを使用しない

  • CatalystのModelは当たり前だけどCatalyst依存

  • ModelはWebという枠組みの外、たとえばCLIやWorkerからも呼び出したいことが多い

  • MyApp::API::* という名前空間

  • 中身はORM+アプリケーションロジック

  • キャッシングのロジックもここ

  • DIコンテナは？ - アプリケーション全体で共有されるインスタンスはRegistryというモジュールに格納

  • Registry - メモリ上のKVSに保存するだけのsingleton object

  • Formの作成はHTML::FormFuを使用

  • 生成されるHTMLに不満

  • HTML::FormFuのValidatorはとてもよくできているので、レンダリングはさせないでValidatorだけ使うというのが最近の流行

  • pixis(フレームワーク)の説明(githubで公開されている)

  • WebサービスやSNSでありがちなメッセージ管理などのソーシャル機能をまとめたフレームワーク

  • Catalyst 5.8依存

  • 依存モジュールが多い

共有

X Facebook LinkedIn Bluesky