pyconjp2012 行ってきたよ各セッション感想 #pyconjp
感想をメモする
おつかれさまでした
たぶんいまごろ運営スタッフは打ち上げでしょう。正式にはまだ3日目のSprintもあるけど、自分は参加しないしこういうでかいイベント(YAPCやHTML5ConfやRubyKaigiやPHPカンファレンス)は行ったことがないので新鮮だった。スピーカーや運営スタッフにも知り合いがけっこういたので半年くらい前からずっといろいろMTGしてたりしてたいへんそうだった。自分はたぶん発表者やLTはちょっとやってみたいけど運営は面倒だからいいやって感じかな。ほんとおつかれさまです。
Perty はひたすら社内の人やTwitter経由で知っていると話してたけど、半分以上は女の子を口説いていた。ごはんもビールもおいしかったです。DJもよかった。
以下見てきたセッションの感想を書いていこうと思う。基本的な方針としては仕事でPython/Djangoつかってるのが大きいしそこらへんを知りたかったので「英語トラックは避ける」「初心者中級者ハンズオンはさすがに見た感じまあ大丈夫かな」「Djangoまわりを聞きたい」「他のフレームワークの設計思想も知りたい」という感じでチョイスした。geventやunittestやSQLAlchemyの話も聞きたかったしSphinxはマジ最高のドキュメンテーションツールなので行きたかったが、そちらを優先した。
資料
公式な資料は connpass 上にあとでのっけられるかもしれない。というかそのためのサービスなんだし、残っていて欲しい(編集時時点ではまだ登録されてない) PyCon JP 2012 - connpass
有志のまとめがいまのところあるのでとても参考になる。
kashew_nuts-tech: PyConJP2012 スライド・資料まとめ
タイムテーブル
プログラム - PyCon JP 2012
まあ見ればわかるんだけど 日本語1、日本語2、英語、ハンズオン、Django/Pyraimid、Google App Engine、Sphinx、NVDAという構成
基調講演 Armin Ronacher(Flask、Jinja2など)
英語でよくわかんなかった。単語は聞き取れてもなにをいっているのかよくわかんなかった。 #pyconjp でやっと中身をしれたくらいだった。同時通訳をしていたようだけどスピーカーの調整のせいか自分の席(中央最後尾あたり)だとあんまりよく聞き取れなかった。
普段 StackOverFlow や man や help 文章だと単語とコードひろってどうにか読めるけど、口語ってかなり厳しかった。しかし英語トラック自体はわりと好評らしかった。外国人も400人中20人くらいはいた気がするし。
使えるDjango
使えるDjango1.4
1.0から1.4ではどう変わったかという話。なんだけど、時間の都合で project template の紹介で終わった。どうもそれが一番話したかったことらしい。「{% elif %}だけじゃないんだよ！」とはこのことで。 project template とは django-admin.py startproject で --template=... と引数を取ることでスキャッフォールドを作ってくれる感じ。簡単に言えば templates, static/js, static/image, static/css, scripts, apps などのディレクトリを切って __init__.py をおいてパスを通してあげるようなものを作ってくれる。ただしその project tempate 自体は継承やMixiinはまだできないらしい。
本当は Class Based View の話を聞きたかったが、まあそれは今度って感じらしい。
What Makes Pyramid Unique!
Webアプリケーションフレームワークである Pyramid の紹介。Zope のころって知らないんだけど、Zope/Plone とかのあたりの流れを通ってきてできたフレームワークらしい。
なんかこうめっちゃくちゃ機能が多くてフックできて拡張できてすごいなんでもできるかわりに「押し付けないフレームワーク」ということでORMやテンプレートエンジンなやフォームライブラリなどをそれこそ自由に選択してカスタマイズして使う。印象としては Flask は学習の入門としては最適だけど、業務でDjango以外をつかうなら Pyramid のほうがいい気がする。どうせ込み入った話になると英語文献しかないのは変わらないんだし。
Beginning Python
初学者としてどうやって学んできたかという話。いきなりエキスパートPythonプログラミング読んだり、公式チュートリアルをKindleの英語で読んだりしたけどダメで(とはいっても最初の環境構築はやはり役にったらしい)、公式チュートリアルを紙に印刷してがんばったりしたらしい。いやーなんか自分もPythonはまだ1.5年しかやってないけど学び方は人それぞれ違うんだなぁ。自分はいきなりDjangoの課題が出たから無理やりコピペしたりしてどうにかこうにか覚えたものだ。そりゃ代入とか簡単なのはわかるけど、文字列フォーマットや標準モジュールの os, sys, re, pdb あたりとかの使い方も知らなかったしなぁ。唯一の救いは自分は職場がMacで、すぐにMacBookAirを購入できたことで、インストールでハマるとかなかったし、Vimは少しはつかってたからそれはよかったね。でもシステムグローバルに easy_install や pip して環境汚したりしたなぁ。virtualenvもしらなかったころ。
Python入門者のコードをリファクタリングしてみた
上記に続いて Java でかかれた ISBN のチェックディジット計算課題みたいなものをいかにして Pythonic にしていくかという話。
Refactoring A Python Beginner’s Code
基本DEMOをみていく形になっているから資料だけみても雰囲気はわかりづらいと思う。リファクタリングだからまずはテストコードを書いて、それからいかにPythonicにするか diff をみていきながら説明していた。例えば enumerate をつかうとか、無駄な変数を減らすとか、print でエラーメッセージ出すより最終的には raise するとか、そういう。今の自分にとってはそこまで難しい話ではなかったけど、個人的には最初にテストをかくときにそのprint文と sys.exit() を潰す mock をどう潰してたのかがちょっと気になった。
Pyramidセキュリティ
Pyramid Security
Pyramid はともかくセキュリティの話を聞きたかったからいってみたけど、正直難しすぎてわからなかった。並行トラックの unittest のほうをうければよかった。とはいっても後からその unittest のトラックが Youtube にあがってたのでみたけどさすがに簡単過ぎる話ではあったような気がして、それはそれでうーんって感じだけど……。
Django-Celeryで非同期処理
Django-Celeryで非同期処理 — Django-Celeryで非同期処理 1 documentation
業務で非同期処理で celery まわりを(自分はまだやってないけど)そこら辺弱いので聞きに行った。有意義だった。しかし話が長すぎて10分くらいオーバーして55分くらいしても全体の 2/3 くらいの解説にとどまったけど、この資料はスライドと同時に下に説明があるというすごいいいドキュメントになっているから、なにか今度Celeryに関わることになったらたぶん見ると思う。ほんとこのドキュメントは良くて、スライドとしてアジェンダを提示しながら下にコードがシンタックスハイライトもあって載っていていい。ウワサによるとこれも Sphinx でできているらしい。すごいね。
ライトニングトーク
いわゆるLT。8人くらいが5分で強制終了するスピーチ。LTは役に立つ立たないってよりは宣伝とかネタに走っていくのがいい感じだね。ドラもよかった。
Django Lessons Learned @ BeProud
Djangoを0.96時代から使っててどうだったかって話ですごく期待していた、なんだけど、正直なんかあんまり手応えがなかった……。話もあんまり覚えてないですすいません……。
オープンスペース - PyCon JP 2012
Django質疑応答に行った。目新しいことはあんまりなかったけど、なんかよかった。すいません内容忘れました。ちなみに時間がかぶってなければエキPy読書会Pycon出張所に行ってみたかった。
基調講演 小飼 弾 / Dan Kogai
なんか正直 Python を dis ってるような印象を受けた。いや、 dis というか、Python としての流儀(それこそ import this; Zen of Python) のことわかった上で炎上芸しているのかなぁと。PerlでEncodeを担当したからか、なんかUnicode文字列の扱いについてつっこんでたけど(len(unicode_string)するとサロゲートペアによっては値が増えてしまう問題)、それも Python 2.x か Python 3.x か分けて言って欲しかったし、なんかなぁって感じだった。そのときの様子は PyConJP 2012 ２日目 基調講演 #PyConJP - Togetter にまとめられているけど、このまとめだと公式RTがカットされているのでかなりひかえめなテキストになってるけど、@xxxxさんの突っ込みは適切でRTされまくってた。全体的にまどマギネタを絡めて面白くしようとしているのは心意気として嬉しかったけど中身についてはなんかイマイチで終わったあとはモヒカンのマサカリが飛び交ってたらしい。まあ、炎上芸か。
ただこの講演で多言語との違いでいろいろ考えさせられることがあったので 小飼弾氏の基調講演を聞いて各言語の join と正規表現の実装についてなんかまあ考えた話 #pyconjp - atas にちょっとまとめてみた。
Python3でここまでできるWebプログラミング
正直このあたりの話は社内とか他の勉強会とかでもだいたい聞いてた内容ではあった。今現時点で(来週くらいに 3.3finalが出る) Python 3でやろうとしたらどうのこうの。「結局はDjango待ちですね」ってあたりがまあ結論ではあった。実際Djangoも six ってライブラリで(2to3みたいな)実験的に開発版があるし、これから 1.5 か 1.6 あたりで Python 3対応する方向性のようだ。スピーチはけっこう30分程度で終わって質疑応答が長かったけど、それがわりと参考になった。ってわりには内容けっこう忘れてるけど 3.3 で入る予定だった標準ライブラリ packaging はいまどうなってるのか尋ねたところ、setuptools や distribute でやっていることといろいろかみあってないらしく、標準化にもうちょっとかかるらしい。でもたぶん 3.x 系列で標準ライブラリにいれるんじゃないかなぁ、みたいな。3.3 で venv という virtualenv 相当のものを標準ライブラリとして組み込んでいるので、現在 easy_install/pip でやってることが置き換わればいいなぁ。
自社開発していなかった会社が python を選んだ理由
Perl使いだけどPythonに移行してみた話。Rubyもさわったりいろいろためしたけど、結局は「自分が面白そうだと思えたから」「スポンサー枠とったりして初期から目立てる」「さいあく失敗してもいいからチャレンジしよう」というようなお話。あと「結局外部(顧客やエンドユーザーなど)からしてみれば動けばなんでもいいのであるけど、ではなぜPythonなのか、それはエンジニアとして大切なことだ」という話。内容は忘れつつあるけど、もうちょっと Perl、Ruby、Pythonの言語としての比較があったらいいなぁと感じた。
Pythonコミュニティが私に与えてくれたもの
Pythonコミュニティが私に与えてくれたもの
ただのJava+HTML/CSS/JSの会社通いエンジニアでしかなかった人が blockdiag を知って感動してコンタクト、PyCon2011に参加、そしていろいろ勉強会に関わったり勉強会を主催しているうちに学んだ話。Python歴1年でブログシステムをつくったらしいからどんな実装にしたとか質問してみたけど実はアジャイルサムライ読書会主催で開発プロセスを改善するほうに興味がいってるからあんまりPython自体はそこまで書いていないらしい。しかしとても「小心者」「引っ込み思案」「人見知り」であったのに勉強会を通じて「エンジニアコミュニティはたのしい！」というところに至ったのはなかなかうれしい話だった。
ちなみに自分はむしろ勉強会からこの世界にはいった。シューカツがクソすぎるけどそれに適合できない自分もクソでいろいろあって、尊敬しているOpera UserJSコミュニティな人々をフォローしたりブログ読んだりしているうちに開発して助言もらっていろいろあって転職(バイト)して今に至る。
Webフレームワークパネル - PyCon JP 2012
Django, Flask, Pyramid, Google App Engine とあるなかで「自己紹介/ここがいいところ」「他のフレームワークのここがイケてないところ」「でも自分のフレームワーク以外のなにを褒めるか」という3点に絞ったパネルディスカッション。面白かったw。
やっぱこのセッションを感じたのは「Pythonの学習入門にはマイクロフレームワークである Flask」「業務でつかうフルスタックな便利フレームワークはやっぱり Django で決め打ち」「Pyramid はフックやカスタマイズが柔軟すぎて最高に使いこなせる人にはいい」という印象を受けた。
以上
参加したセッションの感想でした。来年は PyConJPどころか PyConAsia になるっぽいような話があるらしい。すごい。たのしみだね。運営スタッフになるのはダルいからいいけど、なにかスピーカーやLTできるレベルになれたらいいなぁ。
小飼弾氏の基調講演を聞いて各言語の join と正規表現の実装についてなんかまあ考えた話 #pyconjp
マサカリが飛び交ったPyCon2012 Day2 基調講演
講演を聞いたけど、いろいろ腑に落ちなかったりした。まあ各セッションとその講演についての感想は pyconjp2012 行ってきたよ各セッション感想 #pyconjp - atas に書いたのでそちらを参照してください。
404 Blog Not Found:my slides for #pyconjp
PyConJP 2012 ２日目 基調講演 #PyConJP - Togetter
そのなかで少し気になった print と join と 正規表現についてちょっとだらだらと考えてしまった。ツッコミがあったら欲しいです。自分はちょっとJavaScript、メインはPythonだけどまだ1.5年程度、他の言語はまともにさわったことはないレベルです。
printについて
Python 3 から print は組み込み関数になる。今まで print hoge と文で表現できていたのが print(hoge) になる。2.x でも print(hoge) しても内容は変わらないけど、より言語の統一性を求めた形になった。で、それってどうなの？って質問が飛び交った。「まあどちらでもいい」とか「やっぱり print hoge のほうが楽」とか「printは組み込み関数として定義されているほうが統一的で良い」といろいろあるだろう。僕は最後の「Python の統一性を求めるために print(hoge)のほうが良い」と考えてる。実際今は 2.7 を使ってるけど基本的に print(hoge) で書くようにしている。
join について
join関数はリスト(配列)を引数にとってそれらを任意のセパレータを追加して文字列として返す関数。たいていどの言語にも実装されている(と思う)。例えばあるオブジェクトのプロパティをとって組み合わせて "musician/album/truck" とか "2012_09_16"とかを生成するときに使ったりする。で、それの言語実装について。
以下、コード内でコメントでかきます。なおネタ成分薄めてわかりやすく書きます。
# 今回のスライドにあったのはこれ join "/" => qw/musician album truck/; # ベタ書きっぽい書き方 join("/", "musician", "album", "truck"); # 配列を引数にとる書き方 my @ary = ("musician", "album", "truck"); join("/", @ary)
Perl の場合はセパレータを第2引数、配列を第2引数以降にとってやる方式。正直1文目の書き方はよくわからない
# クオートを省略した書き方 %w[musician album truck].join('/') # 省略しない書き方 ['musician', 'album', 'truck'].join('/')
Ruby は配列にjoin関数を生やしている。クオートを省略できたりするところがいかにも ruby らしいなぁとおもう。
// 特になにかがあるわけでもない ['musician', 'album', 'truck'].join('/');
JavaScript は配列にjoin関数を生やしている。まあJS触ってきたしそんなもんかなって思ってた。
# 当たり前だと思ってた u"/".join(['musician', 'album', 'truck'])
Python は文字列にjoin関数を生やしている。そんなもんかなって思ってた。ってあれ？
join関数を配列に組み込むか文字列に組み込むか？どっちがいいんだろう？といってもまあもう実装されているし今更な話だけど、どっちのほうが「筋が通っている」んだろう？って考えちゃった。join関数は配列を引数にとって文字列にして返す。では、それは配列の関数であるべきか？文字列の関数であるべきか？
自分なりに考えたのは、どちらかというと文字列の関数であるPythonの書き方のほうが「筋が通っている」と思う。なぜか。考え方として「配列を扱ってよしなにする」というのは同じだけど、「配列"を"引数にとる"文字列を返す関数"なのだから、それは文字列の関数であるべきだ」「これは配列"そのものに対して操作する"関数ではない」からだ。なので、この部分では Python はいいなと思う。
正規表現の文字列置換について
まあスライドにおいて「魔女」という文字を Python において文字列を単に除去したいなら str.replace()でいい
# 特定文字列を空文字列に置換する u"やがて生まれる魔女".replace("魔女", "") # -> "やがて生まれる"
それはいいとして、正規表現だとどうするか
my $string = "やがて生まれる魔女" $string =~ s/魔女//g; print $string # "やがて生まれる"
Perl の場合。まあ普通に正規表現でパターンから空文字に置換してる。 =~ で「含んでいる」という演算子があるくらいか。
"やがて生まれる魔女".gsub(/魔女/, "") # "やがて生まれる"
Ruby の場合。これも同じ。ただ直接文字列から正規表現の関数を呼べること、あと gsub ってよくしらないけどたぶん s/pettern/string/g の g だよね。これもまた ruby っぽい感じする
"やがて生まれる魔女".replace(/魔女/g,'') // "やがて生まれる"
JavaScript の場合。自分はJavaScriptからプログラミングにはいったのですごく自然だ。文字列の関数として呼べるし、replace関数に単に正規表現パターンを使えるというだけだ。すごい便利だと思ってるし、これが好きかな
# 正規表現モジュールのインポートが必要 import re # スライドではこうしていた。 re.compile("魔女").sub("","やがて生まれる魔女") # ただ、re.compile は正規表現パターン処理が重くなるから先にコンパイルしたいという話らしいので簡単なパターンならこう書ける # ちなみに正規表現では r"" とつけることで \ エスケープ以外の諸々を無視して書きやすくできるからそうする re.sub(r"魔女", "", "やがて生まれる魔女") # "やがて生まれる"
これでいくと、Perl か Ruby か JavaScriptのほうが「筋が通っている」と感じる。Python の sub ってなんかヘンじゃない？だって、普通は置換される文字列が先に来て、正規表現パターンの通りに置換される。vimも同じですね。でもPythonだと「re.sub(正規表現パターン, 置換文字列, 置換元データ)」って、逆になってる。これってなんかヘンな感じがする。なんでこうなっているんだろう？なにをどう考えたらこういう形になるだろう？
あと Python はじめたてのころにハマったのだけど、正規表現は import re して正規表現モジュールとしてつかわなきゃいけない、つまり文字列の関数にしなかったのはなぜだろう？まあ、これに関しては別にいいのだけど、どういう設計思想したら文字列組み込み関数ではなくわざわざ標準モジュールとしたのだろう。ちょっと考えられるのは正規表現パターンのコンパイルのためなのかなぁとか思うけど。うーん
まあそんな
最初に言ったとおりに言語には言語ごとの文化や考え方があるのだからいいのだけど、それにしてもなんでまたこうなっちゃったんだろうなぁって考えさせられた。僕はあまりにもまだまだ未熟だし余裕ないので Python/Django と JavaScript/jQuery でまあ少なくても1年くらいはやっていこうと思うけど、少しは落ち着いたら他の言語も最速文法以上のもうちょっと文化的なレイヤーを抑えられたらいいなぁ。
