PyCon APAC 2013 に参加した
野良Pythonエンジニアとしては行くしかない、ということで初参加。 プライベートで行くカンファレンスなので、自由に聴講レポートが書ける。すばらしい。
資料や動画は、タイムテーブルのページから確認できる。 特に動画は会期中にリアルタイムで追加されていっていて、すごいと思った。
Keynote: Python and Neutrons -- or, how to make it fun to move motors (by Georg Brandl)
Python 3.2, 3.3のリリースマネージャで、Sphinxの作者でもある方による基調講演。 主な内容は、Python 3.3の新機能と、ドイツの研究用原子炉 FRM II で使われている Network Instrument Control System (NICOS) の設計・実装について。
Python 3.3の新機能については、generatorの中で他のgeneratorの値を返せるようにする(移譲できるようにする)yield from
文の話が興味深い。
下の記事が参考になる。
NICOSについては、ユーザからのさまざまな要望(「実行中にコードを動的に書き換えたい」など)をどう解決しているかの話が面白かった。 のだけど、主に自分の英語力の低さにより、若干理解が追い付かない感じでつらかった。
パッケージングの今と未来 (by @aodag)
今なお混沌を極めるパッケージングについての話。 こういった形でまとめられることそれ自体が有意義といった感じで、ためになる話だった。 途中にPEPベースでの仕様策定の功罪みたいなものにも触れられていたけど、この辺の話はいい感じにまとまっていってほしいなと思う。
Test failed, then... (by torufurukwa)
プログラムも人も疎結合にして、コミュニケーションコストを減らそうという話の実践例。 デバッグ用のDB CRUD APIを定義したり、requestsにcurl形式のURLをデバッグ出力するようラッパーを噛ませたりといった例がへーって感じだった。
Fabric for fun and profit (by jairtrejo)
デプロイツール Fabric の実践的な使用例についての話。 FabricやVagrantをそもそも使ってない状態で聞いたため、コード多めな内容と英語力の低さでいまいちついていけず。 無念。
VFX業界におけるPython活用事例 (by 齊藤弘)
タイトルの通り。人間の3DCGがGUIで作られていくデモがおもしろい。 アプリの拡張は独自スクリプトが多かったが、最近主力級ソフトがPythonをサポートするようになってきたとのこと。 この分野に詳しくないのであまり細かくは書けないが、期待していたものが見れてよかった。
Graphillion: Python module for very large sets of graphs (by Takeru Inoue)
大規模グラフ集合に対する各種演算を扱うPythonモジュール graphillion の話。 Pythonの流儀にのっとったインタフェース、C extension使用で高速、ランダムイテレータなど複雑な処理にも対応といった感じで、かなり実用的っぽい。 質疑応答がプレゼンの作法・ルールみたいな突っ込みで混沌を極めていて、ちょっと講演者の方が気の毒だった。
Deployment, Configuration Management and more with Salt Stack (by izquierdo)
Ansible と双璧をなすPython製構成管理ツール(だと個人的に思っている)Salt Stack についての話。 Saltは1対nのサーバ・クライアント構成をとり、それぞれMaster、Minionと呼ばれる。 また(chef-soloでない)Chefと同様に、クライアント側であるMinionにもエージェントのインストールが必要となる。 なお、Ansibleの場合はクライアント側にエージェントのインストールは不要(sshdが利用される)。
Saltは元々高速なリモートコマンド実行ツールとして作られたとのことで、この点にAnsibleとの違いがある。 たとえば、下記のようにすることで、複数台のサーバで同じコマンドを実行し結果を集約できる。
# salt 'app*.example.com' cmd.run ls /tmp/ app01.example.com: hello.txt pycon.html app02.example.com: myapp.py somethingelse.py
ここでは、cmdモジュールのrunコマンドを使っているが、この部分は拡張可能で brew, iptables, virtualenv などさまざまなモジュールが用意されているとのこと。
日本ではSalt Stackの情報はあまり見かけることがないのだけど、上記の機能も含めて一度使ってみたいと思った。
about mock (by podhmo)
mockモジュールの概要、かと思いきや、mockの機能がどのように実装されているかについての「実践メタプログラミングPython」とでもいえる内容。 全体的に丁寧に追っていけばわかる話だとは思うのだけど、Pythonのメタプログラミング機構をよく知らないため、流れに取り残されてしまった。
後半は、mockを使うことで生じるテストのfalse positive(テストは通っているのに実際はエラーで落ちる)をなくすためのアプローチの話。 アクセスできる属性を制限したり、引数の数をチェックしたりという内容で、セキュリティ技術っぽくて一人テンションが高まる感じだった。
Keynote: One Million Lines of Python (by Rian Hunter)
ここからは台風が到来した2日目の内容。 KeynoteはDropboxの3番目のエンジニアによる、PythonのGood parts / Bad partsの話。 マルチスレッドの話や実行速度の話などいろいろあったが、個人的にはダックタイピングの話、特に「type()/isinstance() ではなく hasattr() を使え」という話がなるほどといった感じだった。 そういう話自体はされているのだろうけど、個人的にPythonでダックタイピングの話を聞いたのはこれが初めてだったので新鮮だった。
PofEAA in SQLAlchemy (by methane)
Pythonの定番ORM SQLAlchemy の設計が、PofEAA (Catalog of Patterns of Enterprise Application Architecture) の設計パターンとどのように対応しているかについての話。 PofEAAも読んでなければSQLAlchemyもきちんと使いこなせてない自分には、得るものが多い内容だった。
不正確であることを前提として、軽く内容をメモしておくと、
- Unit of Work
- 一連の操作の責任を持つオブジェクトを作る。途中で部分的な変更が起こった場合は、これまでの操作を踏まえて全体の整合性を取る。SQLAlchemyではSessionとして実装されている。
- Single / Class / Concrete Table Inheritance
- 継承関係にあるテーブルをどのように扱うか。一つのクラスで表す(カラム値で区別させる)、親のカラム値をもとに子のクラスを参照する、親のカラムを持たせた子のクラスのみを作る。
- Data Source Architectural Patterns
- クラスとDBアクセスをどう対応させるか
- Table Data Gateway
- クラスをテーブルに対する処理の集まりとして対応させる
- Row Data Gateway
- クラスをテーブルの各レコードに対する処理の集まりとして対応させる。インスタンスがテーブルの各レコードに対応するので、
user.delete()
がそのレコードを消す操作に対応する。
- クラスをテーブルの各レコードに対する処理の集まりとして対応させる。インスタンスがテーブルの各レコードに対応するので、
- Active Record
- Row Data Gatewayにドメインロジックも持たせる。
user.get_fullname()
で姓名を繋げて返す、など。
- Row Data Gatewayにドメインロジックも持たせる。
- Data Mapper
- DBアクセスを行うクラスとドメインロジックを表すクラスをそれぞれ作り、間を繋ぐクラスで対応させる
最後には私見として、複雑なクラスについてはシンプルなActive Recordをベースに、会員登録はAccountServiceクラス、フレンド申請はFriendServiceクラスといったようにServiceという概念で分離するのがよいのではないかという話もあり、なるほどといった感じだった。
あとは、Twitterで参加者から挙げられていた下記サイトが参考になりそう。
Python 2.5 から 3.3 で動作するツールの作り方 (by Takayuki Shimizukawa)
タイトルの通り。
Python 2.5のサポートはかなり大変。
sixというPython 2, 3の互換レイヤモジュールがあり、便利とのこと (six = 2 * 3)。
聞いている中で、__future__
モジュールにはwith_statement以外にもprint_functionなどいろいろあることに気づいたりした。
NodeBox で始めるジェネラティブ・アート (by Shinichi Morimoto)
Processingのようなアートプログラミングツールの一種 NodeBox と、生成に使われるアルゴリズム (Parlin Noise, Boids) の話。 NodeBoxにはマルチプラットフォームなVersion 3があるが、これはGUIでプログラミングするタイプのものでPythonは拡張言語という扱い。 Version 1はMacオンリーだが、Pythonで書ける。
アルゴリズムの話は軽く聞いたことがあったのだけど、実際に動かしているデモが見れたのはおもしろかった。 最後には、ジェネラティブ・アートの実例集として、http://abandonedart.org/ が挙げられていた。 JavaScriptで動くものが見れておもしろい。
MoSQL: More than SQL, but Less than ORM (by Mosky)
SQLベタ書きとORMの中間的な立ち位置となる、SQL文を生成するライブラリ MoSQL についての話。 ORMではないのでDB接続はふつうのドライバを使うことになるのだけど、インタフェースがPython for Humansな感じでかなりよい、というか、すごくよい。 ドキュメントから引用すると下のような感じ。
>>> print select('person', {'person_id': 'mosky'}) SELECT * FROM "person" WHERE "person_id" = 'mosky' >>> print insert('person', {'person_id': 'mosky', 'name': 'Mosky Liu'}) INSERT INTO "person" ("person_id", "name") VALUES ('mosky', 'Mosky Liu')
(どうでもいいけどドキュメントの例示コードに自分の名前使いまくってるのすごい)
SQLインジェクションにはエスケープで対策(バインド機構を使わない)というあたりが不安なんだけど、sqlmapでテスト済みということである程度は考えて作られているんだろうな……と思っていたら、質疑応答でバインド機構に対応したSQL文も生成できるとのこと。
あと、後半はターミナルでデモだったのだけど、Serious Usageとして紹介されたコードが、context managerを使ってトランザクション管理してたり、部分適用した関数をインスタンス変数に持たせて利用してたりで、洗練された感じだった。 Python trainerをやってるとのことで、なるほどと思う。 下のような資料もあるみたいなので、そのうち読んでみたい。
bpmappers の紹介 (by 岡野 真也)
オブジェクトの属性から辞書(JSON)へのマッピングを行うライブラリ bpmappers の紹介。 最初はわからなかったけど、社内で広く使われている的な話もあったので、"bp" は社名 (Be Proud) の略なのだと思う。
複数のオブジェクトから辞書を作ることはもちろん、メソッドの戻り値を組み込んだりなど柔軟性は高く、設計も洗練されている。 今はあまり使う機会がない、というかそもそも適用場面が限られる類のものではあると思うけど、いざ必要となったら役立ちそう。
Lightning Talks
JSON schemaによるvalidationの話や、pep8に従うようにコードを変換する autopep8 の話などいろいろ。 トップバッターがいい意味でコメディアンしてて、会場を沸かせていてすごかった。
全体を通して
すべてのトピックがPython、そして国外エンジニアの発表も多数あり、おもしろい話が多く聞けてよかった。
いろいろ聞いてるうちに、__init__
以外のSpecial method namesも知っとかないとな、と思ったりもした。
あと、ランチで出てきた弁当がおいしかった。
総じて、Pythonコミュニティの盛り上がりを感じられるよいイベントでした。 スタッフのみなさまありがとうございました & おつかれさまでした。