2012年9月15日から17日までの3日間、
本記事では3回に渡り、
ナウでヤングな17歳のVPS構築記
現在高校2年生でPyCon JP 2012最年少の発表者、
Call for Proposals
PyCon JP 2012が開催される2ヶ月以上前の6月、
事前準備
私のセッションは自宅サーバーを仮想化して仮想マシンを操作するウェブコントロールパネルを制作した、
そして、
そんな状態で発表を迎えたため、
発表当日
Armin Ronacher氏のキーノートの後が自分のセッションだったので、
Twitterで#pyconjpハッシュタグをウォッチしていたところ、
これが功を奏したのか、
発表終了後
Twitterでは多くの方からお褒めの言葉をいただけた上、
まとめ
発表資料作りはもっと計画的にやるべきであるという教訓を得ました。
自分が日ごろやっていることをアピールすることができ、
Python3でここまで出来るWebプログラミング
ビープラウドの小田切篤さんによるセッションです。
Python 2とPython 3の違い
Python 3の現在の安定版はPython3.
Python 3のPython 2との大きな違いとして、
- 標準ライブラリが整理されたこと
- 標準ライブラリの統廃合があり、
importパスが変わりました - str型がbytes型に、
unicode 型がstr型に変わったこと - 互いを直接結合できなくなりました
str型とbytes型の違いが明確になり、str型は文字列としてのみ、 bytes型は生データとしてのみ扱われるようになりました
bytes型で文字列のフォーマットを使えなくなりました - 相対importの扱いが変わったこと
- 相対モジュールのimportで"from ."が必要になりました
これらの変更により、
WebフレームワークのPython3対応の遅れ
PythonにはWebフレームワーク
Webアプリケーションを作るうえで必要なもの
小田切氏はWebアプリケーションを作る上でとりあえず必要だと思うものと、
- リクエストオブジェクト
- →Python 3ではWebObが使えます
- ルーティング
- ルーティング単体で用意されたものはなかなかなく、
探すのに苦労しました
Python 2とPython 3両対応で自分で作りました- →WebDispatch
- HTMLテンプレート
- WSGI 1.
0.1 が定義される前からテンプレートエンジンのPython 3対応は進んでいました
知っているテンプレートエンジンの半分以上がPython 3対応していました- →Jinja2
- →Mako
- →Chameleon
- →Tempita
- WSGIサーバ
- staticファイルはどうせNginxでやりますが、
開発中にNginxを使うのも萎えます - →webob.
FileApp, webob. DirectoryApp
- →webob.
まとめ
各レイヤのライブラリがPython 3対応してきていて、
しかし、
ただ、
筆者は以前Python 3対応を済ませているPyramidというフレームワークを使い、
各レイヤのライブラリのPython 3対応が着々と進んでいるとのお話でしたので、
ソーシャルゲームとメッセージキュー
株式会社gumiの幾田 雅仁氏によるセッションです。
メッセージキューの役割
メッセージキューはポイントからポイントに安全かつ非同期にメッセージを送る役割を果たします。ポイントとは何らかの計算実体で、
メッセージキューの仕組み
ポイントとポイントの間にメッセージを流す役割をするブローカーがあります。ブローカーは内部にキューを持っていて、
メッセージ送信時、
送信されるすべてのメッセージが一旦キューに貯められるので、
メッセージキューの利用場面
実際にソーシャルゲームでメッセージキューを利用しているのか、
課金処理
GREEのプラットフォームでゲームを提供する場合、
しかし時間がかかる処理はどうしても発生するため、
分割されたDBへの並行処理
ユーザ毎にDBを水平分割しているそうですが、
まとめ
筆者自身、
筆者が製作したシステムは個人的なプロダクト用の小規模なものでしたが、
Webフレームワークパネル
Flask作者でPyCon JP 2012で初日キーノートを行ったArmin Ronacher氏、
Webフレームワーク自己紹介
まずは、
- Flask
Flask開発のきっかけはエイプリルフールのジョークとして作ったフレームワークでした。もともとジョークであったこのフレームワークの後に、
まともなフレームワークを開発しようということでFlaskを開発しました。Flaskは開発者に使い方を強いることなく柔軟に、 自由に使えるフレームワークになることを目指して開発しました。 - Django
Djangoの大きな功績はWebの開発事情を変えたことだと思います。
Djangoはフルスタックのアプリケーションで、
このフルスタックというのはMVCのレベルにとどまらず、 世界各国の郵便番号のバリデーションができるなど、 アプリケーションを開発する上で必要な機能が詰め込まれているという意味だそうです。 InstagramやPinterestなどで使われるなど数多くの実績を持っていることも特徴です。また、
PyCon JP 2012の参加登録のために使われたconnpassというサービスもDjangoを使って実装されているため、 PyCon JP 2012来場者の全員はDjango製アプリケーションを利用したことになります、 ともおっしゃっていました。 - Pyramid
PyramidはDjangoの用に世界各国の郵便番号のバリデーションを持っていませんし、
本当にコアになる部分しか持っていませんが、 そのコアになる部分のテストカバレッジは100%に保ち続けられている上、 ドキュメンテーションのカバレッジも100%に近づける努力がされている質実剛健なフレームワークです。 Djangoなどのようにあっという間にアプリケーションが作れてすごい、
という事はありませんが、 内部から外側までフレームワークとしてよく作りこまれている上、 いたるところに手を入れていけるとても拡張性の高いフレームワークです。 また、
Python 3対応は早々に終わらせています。 - Google App Engine
Google App Engineは言わずと知れたGoogleが提供するPaaSです。
Google App Engineには2つの面があって、
それはプラットフォームとしての面、 ウェブアプリケーション作成に必要なライブラリが揃っている面です。Google App Engineの利用を勧めたいのはシステム管理にリソースを割きたくない人や団体で、 逆にインフラエンジニアのリソースをすでに持っていたり、 ものすごく速い性能を求める場合には向かないのだそうです。
フレームワークを開発する/プッシュするようになったきっかけ
次に、
- Flask
もともとはDjangoなどを使っていましたが、
もっと柔軟性のあるフレームワークが欲しくなりました。自分で開発したテンプレートエンジンのJinja2とWSGIライブラリのWerkzeugでウェブアプリケーションを開発していました。 このころにマイクロフレームワークが流行しだしました。この当時の多くのマイクロフレームワークは、
ライブラリに依存することは良くない、 という風潮により、 すでにライブラリとして実装されているものをフレームワークで再実装しているのが多く見られました。このことは良くない、 と思いエイプリルフールに記事を書き、 ジョークのフレームワークを公開したところ、 多くの人の支持されたため、 これがFlask の開発につながりました。 - Django
Railsが2004年に発表されて猛威を振るっていました。この頃のPython にはWebのフレームワークが100個くらいあり、
言い換えればよくわからないものが100個もありました。有名どころはZope, Ploneでしたが、 これは簡単に触れるものではありませんでした。そんな折、 2005年の4月にDjangoがオープンソース化されました。Djangoにはリーズナブルな機能が現実的に用意されていました。簡単に言いかえれば、 簡単に触れるのに普通なものが手元にある、 このことからDjango推しになったそうです。 - Pyramid
小田切氏がPythonを始めたころはすでにWebアプリケーションならZopeを使う、
という流れになっていてZopeを使っていましたが、 Ploneが出てきたあたりから追いきれなくなり脱落したそうです。 TurboGearsが出てきたことから、
再びPythonでのウェブ開発に戻って来て、 WSGIライブラリなどを追っかけている内に、 TurboGearsがPylons上に移植されました。 RepozeというZopeのコンセプトやコンポーネントをWSGIでも使えるようにしようというプロジェクトが出てきたことにより、
再びZopeをやれると思いましたが、 Repozeで使われていたフレームワークがPylons Projectに合流した事によって、 小田切氏が追っかけていたフレームワークがすべてPylons Projectに合流し、 必然的にPyramidを推すことになったそうです。 - Google App Engine
SIerをやっていたころにGoogle App Engine が公開され、
インフラ以下のことを開発者が気にする必要がないことを魅力に感じて、 Google App Engineを好きになりずっとウォッチしていました。インフラの重荷を開発者が背負うこと無く、 コードに集中して開発できることで開発者の能力を高められることを素晴らしいと思っているそうです。
自分のフレームワークについてこれだけは言いたいこと
ディスカッションの最後に自分が推すフレームワークについて、
- Pyramid
PyramidはPython 3に対応しています。
- Django
DjangoはまだPython 3に対応していません。しかし、
クリスマスに公開される予定のDjango 1. 5ではSixを使いイクスペリメンタルなPython 3対応がされます。Sixというのは、 Python 2とPython 3の違いを吸収して、 どちらの環境でも使えるようにする仕組みのことで、 2かける3でSixと呼ばれています。 - Flask
現在のところ自分がPython 3を使っているわけでもなく、
Python 3でFlaskを使いたいといっているユーザ数も少ないので、 Python 3に対応する予定はありませんが、 多くのユーザからの要望が寄せられればPython 3への対応が早まります。 - Google App Engine
Flaskと同様で、
Python 3を使いたいという要望が多くあればPython 3対応が早まります。
まとめ
他にも、
筆者は今回取り上げられたすべてのフレームワークをひと通りさわり、