「Python Workshop 2010/12」に行ってきた
PyJUGのイベント「帰ってきたPython Workshop 2010/12」に行ってきました。
以下、メモほぼそのまま。
mixiアプリとGoogle App Engine(mixi 山下英孝、Google 松尾貴史、Bascule 田中謙一郎)
- mixiアプリ(山下)
- mixiはPerlの会社w
- なので、松尾さんと田中さんにも話してもらう
- mixiプラットフォーム
- mixiアプリのほかに
- イイネ!ボタン
- 今日リリース
- mixi Graph API
- スマートフォン
- mixi OpenID
- けっこう昔から
- 個人開発者がつかえるのは少ない
- 近日中に個人開発者にも提供予定
- 細かいAPIはたくさん
- mixi Developer Centerにドキュメント
- Pythonのサンプルコードもある
- mixiアプリ
- PC、モバイル、スマートフォンに対応
- 一般的なWebサイトでユーザーを集めると大変
- mixiアプリだと一気にユーザーが
- 華麗なる女優たち:1週間で10万ユーザー
- mixi Xmas:6日で130万、もう200万人
- mixiアプリだと一気にユーザーが
- ソーシャルアプリがなんで流行るの?
- ユーザー登録不要
- ユーザーが勝手に宣伝してくれる
- バイラルマーケティングの手段がAPIとして整備されている
- mixiアプリの構成
- モバイルの場合
- mixiサーバーがプロキシー
- デベロッパーのサーバーにリクエスト
- モバイルは毎回リクエストが来る。かなりのアクセス数
- 人気のアプリは1,000万~数億PV
- サーバーが耐えられない
- インフラ支援サービスが続々
- NIFTY Cloud、IDC Frontierなど
- GAE:無料からスタート
- モバイルの場合
- App Engine for Mixi Apps(Google 松尾)
- ソーシャルアプリ
- おすすめに載るとアクセスアップ
- 時間帯でアクセス数違う
- 人気がでないとアクセス少ない
- GAEがいい
- 人気がでなければ0円
- オートスケール
- フロントエンド、DB
- 1.4.0リリースのときの数字で、アクティブ開発者月間15万
- Quotaが2種類
- お金を払うと増えるものと、増えないもの
- システム全体の健康を保つため
- mixiアプリで人気がでると固定Quotaじゃ足りなくなる
- 私に連絡してください
- お金を払うと増えるものと、増えないもの
- スケーラブルなアプリを書くために気をつけること
- 最小限のことだけやる
- 1000msルール
- 越えるとインスタンスが抑制される
- datastore contentionをさける
- Task Queueとmemcacheを使う
- DBのオペレーションにデッドラインを設定
- 困ったときは私に
- 最小限のことだけやる
- 広報サイトにBest practice記事がある
- SDK 1.4.0リリース
- 今年最大のリリース
- ロードマップ
- バックグラウンドサーバーも
- ずっと動き続けるインスタンス
- データストアの可用性とレイテンシーのどちらを優先するか選べるように
- バックグラウンドサーバーも
- Bascule 田中さん
- Bascule
- 2000年スタート
- 最近モバイルアプリ
- プロモーションアプリも
- 45名ぐらい
- ほとんどFlashデベロッパー、サーバー関係はパートナーさん
- 華麗なる女優たち:LUXのプロモーション
- ブランド体験ができるソーシャルゲーム
- たくさんのユーザーに使ってもらって従来の広告にないアプローチ
- ハリウッド女優体験+ソーシャルグラフ+GAE
- 通算65万人以上が登録
- DAU 10万以上
- ピークで200~300req/sec
- 1000~1500リクエスト/日
- すべてダイナミックリクエスト
- リソースが確保できなかったので新たにパートナー
- 高負荷の運用経験のあるチームがみつからなかった(当時)ので育てる
- 去年のmixiXmasでの経験
- トラブルなど
- 今回の件でも新たな問題
- 404の大量発生
- ImportError → 不完全なインスタンス → 404
- ビープラウドにサポートしてもらった
- GAEの管理コンソールを共有してKayを修正してもらう
- Kay 1.4.0でインスタンスを落としてリスタートするように直した(松尾)
- 突発的にレイテンシーが悪くなる
- → mixiによりJOIN停止の通告
- 松尾さんに連絡
- HTTP QUEのタイムアウトを短く変更
- Kay 1.4.0ではだいぶ改善されているはず(松尾)
- 404の大量発生
- GAEのメリット
- スケーラビリティ
- 驚異的な集客
- コスト
- いままでの経験で、1000万リクエスト = 100ドル
- すべてDynamic Requestの場合
- staticはAmazon CDNなどを利用している
- いままでの経験で、1000万リクエスト = 100ドル
- スケーラビリティ
- サーバーエンジニアを抱えていない会社で、スケーラビリティとコストを気にせずに企画できるようになった
- ユーザーにはドキドキ、我々はウキウキ
Harvester - CG映像制作用ジョブディスパッチシステム(MARZA 齊藤淳、石川雄介)
- マーザ・アニメーションプラネット
- セガのCG部門が独立した会社
- サンプル動画(いちおうust NGいちおう)
- ProjectDiva
- CGを使ってストーリーテリンングをやりたい
- 映画を目指す
- 90名のうち、ソフトウェアエンジニア7名
- インハウスツールを開発
- CG業界ではPythonがけっこう使われている
- Mayaなどにも組み込まれている
- なくては仕事できない状態
- 社内でもC++の次にPython
- Maya上のツール
- パイプライン:作業工程をつなぐしくみ
- その他の組み込みPythonでの利用
- ディスパッチシステム
- 映像制作にはたくさんのCPUリソースを使う
- 1台だとトータルで820日とか
- サーバーを使って分散処理
- レンダーファーム
- 140台、1300コアちょい
- ストレージ100TBちょい
- レンダリングのほか、シミュレーション、エンコード、ベイク(頂点データをはきだす)など
- 映像制作にはたくさんのCPUリソースを使う
- アーティストがトライ&エラーしやすくなり、作品のクオリティが上がる
- キューのスケジューリング
- Harester
- とある会社の仕事管理(ディスパッチャ)
- サーバープログラミングの経験なしで開発
- 最初はボロボロ
- v2、作り直して落ちなくなった
- v3、キューをとるところをpushからpullに
- Client
- Manager
- Apacheベース
- ClientとJSONベースで通信
- Worker
- Managerにリクエストする
- ManagerとJSONベースで通信
- Manager
- Python 2.6
- ManagerはLinux
- WorkerはWindows中心
- サーバーをグループに分けるときに、マシン固定ではなく割合として管理
- サーバーの追加削除で再設計不要
- 新しいプロジェクトでも
- グループごとの台数
- 固定だとリソースが無駄
- 空いているサーバーはどんどん使うように
- タグを割り振ることで特定のノード群でのみ実行させる
- 特定のソフトが入っているマシンとか
- ライセンスの数を数えるのもタグを使って
- テンプレート
- 処理を簡易的に記述
- WebのGUIでユーザーが処理状況を確認できる
- ExtJSベース
- アーチストがアプリをインストールしなくていい
- バージョンアップしてもらう手間もはぶける
- ローカルの簡易サーバー
- ローカルのフォルダを開いたり
- JSONベースのAPI
- WSGIを使ってZopeのScriptPytonに似た仕組み
- ステートレスなのでトランザクションのようなことは難しい
- APIのドキュメント
- Web
- WSGIミドルウェア
- PyDocを自動整形
- GUIからの強制再起動
- エンクロージャの電源管理機能
- Zabbixで消費電力や稼働率のデータをグラフ化
- 苦労
- レンダラーはメモリをくいまくる
- Pythonが起動できなくなる
- あらかじめメモリを確保する?
- SQLクエリが重い
- SQLを使わないように?
- たまに長いジョブ
- データサイズ
- 通信量がボトルネック
- deflate
- かなりの圧縮率
- フレーム間のデータは似通っている?
- WMIをPythonからとると調子よくない
- ふつうのAPIを使ったり
- time.sleepを使うとまれにおかしい
- Win32 APIを呼ぶように
- 16コア以上の環境だと古いアプリが起動しなかったり
- レンダラーはメモリをくいまくる
- 今後
- pullでもpushでも
- コアのフラグメントの問題
- 電力管理
- Q: タスクの指定はどんな
- A: アプリケーションに組み込まれている。Mayaから、今のシーンを見たい、とか。コマンドラインも
- Q: 分散のしかたは指定しなくていか
- A: そういう感じ。Mayaの上のツールがやってくれたり
- Q: 割合の単位
- A: 台数ベースのみ
パネルディスカッション「Pythonはここがイケてるイケてない」
- 司会:郷田まり子
- 殺伐としたタイトルですがw
- 5つの言語のかたに集まっていただいて語る
- Java代表 @yoshiori
- Asakusa.rbのほうから来ましたw
- いろいろな言語で書いている
- Perl代表 @tokuhirom
- Perlで仕事
- Pythonもたまに
- PHP代表 @moriyoshi
- 本業はPythonとかC++とか
- 「2位ではだめなんでしょうか」な仕事
- Ruby代表 @takahashim
- 仕事でPerl、PHP
- Pythonはサンプル程度
- 達人出版会はRuby(Rails)
- Pythonの本を書いていただける方募集
- Python代表 @nishio
- いきなりハードルをあげないでw
- 僕フルボッコじゃないですかw
- ワンライナーw
- WEB+DB次号「言語設計の基礎知識」
- (郷田)pythonのイケてるところ
- yorhiori
- むちゃぶりw
- インデントはイケてる
- disられるけど
- Javaと比べるとすべてがイケてるんじゃないかw
- 僕以外LLじゃないですかw
- ダックタイピング
- インタプリタ
- 数字の0や空配列がFalseになるところ
- 賛否あるけど
- tokuhirom
- インデントぐらいしかないんでw
- PerlでもAcme::Pythonicってのがあってw
- メソッドのimportがちゃんと定義されている
- Perlは自分でやってる
- クラス定義にblessがいらないw
- 略語を覚えなくていいw
- 標準ライブラリが多い
- PerlはHTTPクライアントも標準でついてないんで
- たいていの言語はついてる
- PHPもないかなw
- moriyoshi
- インデントって言わなくちゃならないのかなw
- 昔Python嫌いだった
- インデントは守るほうなので気に入った
- 標準ライブラリが充実
- PHPは標準関数が多いけど、まとまりがない
- Pythonはモジュールとかで整理されている
- PHPについでドキュメントが充実
- takahashim
- Rubyは海外ではRails。Webの色合い
- Web以外ではPython有利
- GAEがPython
- JRubyだと無理している感
- Rubyは英語っぽいDSLがはやった
- よくもあり悪くもあり
- Pythonはきちんとしている感じ
- nishio
- インデントを強制しなくてもいいんじゃないかと
- use strictみたいなモード切り替えとか
- ほめるのに反対するつもりできたので
- Javaはコンパイルできる
- コンパイルエラーを検出
- (yoshiori)PythonはIDE充実してるよね
- (nishio)Javaほどではない
- (yoshiori)IDEは言語ではないけど
- (nishio)IDEは言語を使うツール
- (yoshiori)EclipseがあるからJavaを使う。でも型などの問題
- インデントを強制しなくてもいいんじゃないかと
- (郷田)Pytonはここがイケてない
- takahashim
- ここはインデントと言うんでしょうかw
- 女性プログラマの話で、本を買うと表紙に蛇の絵が描いてあるw
- (nishio)ブランチして言語を作ればいい
- (郷田)萌え擬人化
- (nishio)それはそれで女の人に抵抗が
- (takahashim)見た目重要。Railsはカッコいいサイトがばんばん作られて人気に
- moriyoshi
- やっぱインデントですかねw
- PHP的にはテンプレート言語としてイケてないw
- HTMLにインデント?
- (nishio)全部式で書けばいいんじゃないでしょうか
- tokuhirom
- 正規表現リテラルがない
- import
- マッチ結果を$1とかでとれない
- (nishio)正規表現リテラルほしいですね
- 正規表現リテラルがない
- yoshiori
- 歴史的経緯があるという話は、わかるけど、イケてない
- Pyton 3でも捨てきれていない
- len()、str()
- 説明するのが面倒くさいw
- Pyton 3でも捨てきれていない
- 予約語が少ない?
- TrueとかFalseとか予約語じゃないけど覚える必要
- None
- ほかの言語で使わないから…あ、使うのか…馴染みがないのでわかりにくい
- (nishio)len()とか、なんでつけたのかな。オブジェクト指向っぽくないと言われるけど、見た目にまどわされているんじゃないか
- 予約語を少なくしたC++がどうなったか。0とか。
- 歴史的経緯があるという話は、わかるけど、イケてない
- (郷田)Pythonの立場からほかの言語を
- (nishio)僕に負荷が…
- (郷田)Pythonのイベントですから
- (nishio)PHPはmoriyoshiがおもしろいことをやってくれる。
- 数学の重要さがわかる。==。
- (moriyoshi)解説すると、PHPではA === B、B == Cでも、A == Cが成り立つとはかぎらない
- (nishio)Perlは静的スコープと動的スコープが使えるので、変数スコープの言語仕様の説明に便利
- (tokuhirom)Pythonにダイナミックスコープない?
- (nishio)なんの必要が?
- (tokuhirom)グローバルな値を一時的に変えるとか
- (nishio)一時的に変えて自分で戻すのでいいのでは?
- (tokuhirom)自動的に戻る
- (yorhiori)マルチスレッドなら意味がある。マルチスレッドはJava
- Q: Pythonのself
- A(nishio):嫌いな人もいるみたいですが
- Q: 面倒くさくないですか
- A(nishio): 面倒くさい。でもしょせん見かけ。意味論的には同じ
- (yoshiori)selfは基本的にはいいんですが、引数の数があわないときのエラーがわかりづらいのでは?
- (nishio)そうですね
- (郷田)ここらでPythonはイケている言語ということで
LT:Python sf 計算ソフトの1.1(小林)
- Matlabに対抗
- コマンドライン
- エディタからを想定
- ワンライナー
- vimやwzからデモ
- プリプロセッサ
- 数値微分
- 行列ベクトル積
- 3Dグラフ描画
- tanの分布
- 元利均等払い
- 等比級数の和
LT:遷移図作成ツールblockdiagの紹介(小宮)
- タイムインターメディア
- Python歴1年ぐらい
- プロジェクトで遷移図の担当に
- ExcelやVisioで作ることが多い
- やってみると大変
- 追加・削除が大変
- ずらして入れる
- ずれる
- Excelのバージョン、調整ばかり、Excelが嫌いに
- 追加・削除が大変
- 生成ツール作った
- blockdiag
- Graphvizっぽい文法のテキストからPNGやSVGを生成
- PyPIにあげてある
- 点線、色、ラベル、画像、選択肢のラベル、グルーピングなどに対応
- Webのインタラクティブシェルも作った(GAE)
- ブラウザがSVGに対応していること
- Sphinx用プラグインも作った
- Sphinxに埋め込める
- 今後
- 形状増やす
- レイアウトエンジンのバグを直す
- 遷移図以外のブロック図
LT:SciPy-Japan 2011 Project (NOUVEL, Bertrand)
- プロジェクトを始める
- SciPy-Japan
- みんなでやりましょう
- 背景
- 1985 MS/Matlab/Mapple時代のはじまり
- 198x Scilab Octave OpenSource Rion?
- 2005 Sage?
- 2007 SciPy/NumPy時代?
- 世界的なカンファレンス
- US、ヨーロッパ、インド
- 日本も?
- 日本ではまだSciPy/NumPyが知名度低い?
- 英語と日本語で
- 3~5日間
- チュートリアル、キーノート
- NumPy、SciPy、3D、GPU
- ポスター発表
- スプリント(ハッカソン)
- パーティ
- チュートリアル、キーノート
- 現在
- スタッフの募集
- 次回ミーティング
- PyJUGの忘年会で
- Google Groups
- IRCミーティング
コメント
コメントの投稿
トラックバック
https://emasaka.blog.fc2.com/tb.php/848-4342f351