こえむの編集後記

コンピュータ スキー そして旅の話を綴ります

プログラミング 催し

PyCon JP 2014 Day 2 感想とノート #pyconjp

2014/09/12(金)から始まっている、PyCon JP 2014に来ています。今は3日目の朝に行われる西尾さんの基調講演を待っている所です。楽しみです！実はPyConは初めてなのですが、YAPC::Asiaとまた違った趣があって楽しいところです。

それでは、今回もノートをアップしておきます。こちらは2014/09/13(土)に行われた2日目、カンファレンスとしては1日目のノートです。

オープニング

  • 感想
    • しょっぱなから英語
    • 海外から人を招聘しているんだ感が高かった

Keynote

  • Kenneth Reitzさん
    • Heroku
    • PSFの中の人
  • 感想
    • 安定と変化のバランスの難しさを再認識させられる話だった。
    • Python開発の中心にいる人たちは早めにPython 3に移行してもらいたいいのだろう。
    • 言語を選ぶより、言語の中のコミュニティを選ぶ方が、開発の時に幸せになれそうな気がしている。
  • 軸
    • Self
    • Time
    • Other
    • Space
  • そもそもLanguaeだよね
    • Pythonの前に集っている
    • 自然言語のように今日は扱ってみる
  • 言葉の歴史
    • 言葉を通じて考えている事を人に伝えている
    • 時間とともに考えを保存して伝承できる
    • とっても素晴らしい事だよね！
    • 人というハードは変わっていないけど、スキルを通じてソフトウェアをアップデートしている。
  • 1-to?1
    • 実際ではもっと多くの人とコミュニケーションしている
    • エジプトの石盤
  • 1-to-many
    • 印刷機の発明
    • ひとりが何千の人とコミュニケーションできる、これは革命。
    • 新聞、本、テレビ、ラジオ、等。
  • many-to-many
    • the Internet !
    • 全ての世界から情報にアクセスできる。
    • 大規模だ(huge)
  • 空間(space)
    • 知らない間に、たくさんの人とコラボレーションできる空間。
  • 軸をまたぐもの
    • 様々なツールがある
    • テクノロジーがあるように言語がある
  • Pythonの未来に恐れを抱いている、怯えている。
    • これは世界の将来が危ぶまれている。
    • 2と3の分断された世界
    • (挙手の状況が2の方が比較的多かった)
    • 3はみんな怖がっている、話者も使ってない。
    • Flask開発者によるとUnicodde ,Codex, and Friendsの物事をどれだけ破壊したか長い話があった
    • Standard Libraryが壊れていて辛い(僕自身も辛い)
    • こりゃ残念な事だ
    • 改善は毎日進んでるけどね
  • なぜ？
    • Python 3のユーザが少ないから
    • (挙手の状況を見てもわかるよね！)
    • PyPi, pipに変更が加わった→利用しているPythonのバージョンによって切り替える仕組みができた
    • 2週間で、2は81百万、3百万ダウンロード。偏りがあるのがわかるよね？これが現実。
    • (動かない→使わない→改善されない、悪循環っぽい。)
      –
  • Python 3
    • 新しい人が、Python 3を選び始めている。
    • 初めてだから、選択する事ができる。
    • 既存の確立されたコミュニティとは違う。
    • 開発者、Pythonのコミュニティの間にも断絶がある。
    • 製品を開発する時のマーケットの問題。
    • 2と3で2倍のメンテコスト。辛い。
    • 分裂が促進されている。
  • これは貴方の問題です
    • 同時にあなた方がソリューション。
    • 2つのものが1つになる。
    • 知識と愛。
    • 直接体験して自分で決めてほしい。
    • Python 3を使って、何かあればブログを書こうぜ。体験を共有しよう。
    • Python 3の食わず嫌いはやめよう。
    • 静かに、何かを待っているのは良くない。
  • 質疑
    • Q: Perl5/6の問題とにてるけど、あっちはPerl6は別のものとして分かれた。Pythonは分かれずに収束していこうとしているけど、どうして？
    • A: 変換はできるパワフルなツールはあるけど、それだけでは間に合わない。だから、多くの人がどちらにも対応できるコードを書くようになってきた。でも、それって良くない。Python 3の利点が活かせない。
    • 同時にみんながPython 2をやめて3に移行するならいいけど、そんなわけにはいかない。
    • PSFでは2.8はないと決めている。ただ、もっといいソリューションがあればいい。
    • ご自身の意見をみんな持ってほしい。
    • Q: 同時にどっちもサポートするのは辛いのは知ってると思う。で、Python 3で書くメリットとは？
    • A: ない…な(ここで一同爆笑)。でも、いろいろいいものは入ってるよね。他の言語でできる新しい事もできる。エキサイティングだ、でも、同時に…ここで2をきっぱりやめる事もむずい。
    • Q: 自然言語処理をやってるんだけれど、C, C++のような標準化は行われるの？Pythonの標準化活動ってあるの？長期的なPJでは、そうあったほうがいい。
    • A: Python 2.7は今後10年変わらない(多分RedHatがサポートする事は踏まえられているんだと思う)から、それを選ぶのはどう？2系がいいと思うよ。
    • Q: 2つ目の質問に近いんだが、Python 3を使おうと言いながら2を使っている。クリアなコミュニケーションが行われていない、3の方向性もよくわからん。悲観主義的な話を唱えているのではなくて、クリアなビジョンも難しいと思う。ダウンロード数を見りゃわかるでしょう。
    • A: コア開発者と話をすると、10年かかるかもしれないが対した事はないさ、と話題になっている。参加して、発言して行くことが必要。コア開発者は数値をあまり気にしていない。言語の改善を考えている。その対立が分断を引き起こしている。私が理想的な状況とは、みんなが2.7を使い、3は忘れるってのがいいと思う。ただ、公式な意見は確立されて行く必要はあるよね。
    • 私は3を嫌いになってもいいと思う。
    • Q: 2と3で違う見方なのだが、1年前に3が選択肢となる話が出始めて、ここ最近互換性が問題になってきた。Ubuntu, Debianが3がデフォルトになって増えたっぽい。2から3に必要なものをポーティングすりゃいい気がするけど。
    • A: それでいいと思う。
    • Q: RubyとPythonの比較
    • A: Rubyの場合は1.8→1.9の変化は急だった。RubyとPythonはだいぶ違っていて、Pythonはこれまでstableで後方互換を保つようにしていて、安定していた。この歴史が、科学的な背景があった。Rubyの変化はとても早い、ポイントリリースも違う、パッチりリースでも違う、でもそう言うのに慣れているから大きな変化にも慣れている。それがRubyの文化。でも、Pythonではそんな変化にあまり対応できない。Rubyは変化を楽しんでいるのはいいし、Python 2,3でもそれができればいいなと思う。僕らも慣れて行く事も必要だと考えている。

Programming the Performance Co-Pilot toolkit

  • Nathan Scottさん
    • RedHatのなかのひと
  • 感想
    • PCP知らなくて不勉強だったことを反省する。
    • Pythonで拡張できるのはなかなか良い。
    • そしてリモートホストからのデータも取得できる点も非常にいい。
    • 検証時のメトリクス取得にもってこいと思われる。
  • 今日のお話
  • PCPとは
    • オープンソースの ツール集
    • システムアナリシス
    • ライブで履歴をとれる
    • 拡張性が高い
    • 分散できる
  • アーキテクチャ
    • pmlogger
      • 各種ミドルウェア、カーネルから拾ってくる。
    • pmchart
      • ビジュアライズ
    • pmie
      • インタフェース、こねくり回す時にはこいつを使う。
  • メトリック
    • pminfo コマンド
      • データ拾う時に使う
      • Sensuメトリックを拾う時の名前ににてるっぽいな
    • Collector extentions in Python
      • 目標: new dmcache metrics
      • dmcacheの推移がわかってキャッシュあたりの追跡をするのによさそう
      • かなり密な単位でとれるっぽいな 1秒単位がある
    • git clone git.pcp.io/pcp からどうぞ。
    • プログラミングガイドブックもあります
    • pmchartはJavaっぽい
  • 質問した
    • Q: リモートシステムからデータは取れるの？
    • A: できます。Ciscoのルーターとかのデータを、TCP/IP経由でとれます。
    • 英語の質問緊張した

Gunicorn, the thundering herd and other concurrency programming challenges

  • Benoit Chesneauさん
    • gunicorn開発者
  • 感想
    • gunicorn開発者本人から話が聞ける事が貴重。
    • 英語で後で話に行けないの、いろいろ損している気がしている。
  • gunicorn = じゅにこーん
  • デザイン
    • prefork-workerモデル
    • ソケット共有 (spawn-share sockets)
  • ソケット共有
    • arbiterがworkerにspawnする、よくある話。Unicornと変わらん。
    • copmetiton to accept (競合管理)
      • バックログに溜め込む
      • 同期ワーカーは1接続まで
      • 非同期ワーカーはいくつものコネクションを支えられる
    • ワークフロー
  • なんでいろいろなワーカーが？
    • 同時接続の戦略
    • 違うプラットフォームのサポート
    • WSGI以外にハンドルしてほしい
    • いろいろ
  • The thundering herd problem
    • 重たい処理が引っかかると全ての処理が引っかかってしまう
    • 対策
      • ＃792 参照
      • パイプを通じてシグナルをやり取り Workerプロセスの状態を聞いてまわっている模様
      • arbiterがソケットの読み込みが可能かチェック
  • One command to rule them all
    • gunicorn_ほげほげ とか書かなくていいよ！
    • プリロード問題は直しました
    • ?paste, ?pythonpath, ?env をサポートしました
    • 20個の引数です (非推奨は勘定していない)
  • Enhance the user experience
    • ＃837 参照
    • plugin everywhere: logging, workers
    • more embeddable: the gunicorn engine
    • https://github.com/gunicorn/ に移ります
    • 2014/12までにやります！！！

Data collection, analysis and optimization with python

  • Shinji Iwakiさん
    • @shinji071
    • 構造計画エンジニアリング
    • Python歴 1.5年
  • 感想
    • iPythonのデモンストレーションとして見ていても非常に興味深かった。
    • Pythonが書けるなら、無理にRでデータ分析に取り組まずとも、データ分析に取り組める事がわかった。
  • 膨大なデータの計算どうすっぺ
    • まず、全体の構造及びライブラリ構成を紹介。
    • 最適化
  • データ収集
    • HTMLをかき集める
    • BeautifulSoup4で解析(スクレイピング)
      • 時間・タイトル・出演者をとる (価格.comのテレビ番組欄)
      • 出演者の出演頻度を出してみる
  • データ分析
    • pandas
    • skleam
    • そしてビジュアライズwww
    • k-means法による出演者のクラスタリング
  • 最適化
    • pulp
      • LP modeler
      • 線形計画法を解くライブラリ いろいろあるんですなー
      • ナップサック問題を解くとか
  • 質問
    • Q: GAのライブラリって？
    • A: scipyとか、でもあんまつかってないな。

Effective numerical computation in Numpy and Scipy

  • Kimikazu Katoさん
    • Egg technology に勤務
    • CSのPh.D
    • Python暦 2年未満
    • 科学計算歴は10年以上っぽい
  • 感想
    • 行列圧縮を自力で実装していた事があるが、もうそんな事をしなくて良いのは助かる。
    • 自然言語処理の研究を手伝っている時に、これがあればどれだけ楽だったかと想いを馳せた。
    • 講演中、もっと抑揚がある話し方があると注意を引きやすくて良かったのではないか。
    • 1つ後のセッションと入れ替えた方が、より理解が深まったのではと考えた。
  • 流れ
    • NumMyについて
      • 展開
      • インデクシング
    • スパース行列
    • ケーススタディ
  • 数値計算をなぜPythonで？
    • プロダクティビティの高さ: 書きやすい・デバッグあすい
    • ビジュアライズしやすい
    • Webシステムとつなぎ込みやすい
  • だけど、Pythonは遅い！
    • CとPythonでは80倍違う計算があった
    • だけど、numpyを使うと…Cに近いくらい速度が出た！
    • まあ、PythonからCに書き換えるってのは大変だしな、こう言うのがあるならいいね。
  • パフォーマンスの肝
    • forなどのループを減らす
    • 良いライブラリがあれば使おうぜ
    • メモリコピーのコストとか、忘れてません？(確かにヤバい)
  • スパース行列
    • 行列の圧縮のメリット→メモリ空間の削減、計算量の削減。
    • 3つのメソッド→[lil,scr,csc]_matrix
    • ある計算において 1000×1000 のsparse matrix でlil は11.7 sec, cse 0.06 sec
    • ただ、性質を熟知している場合は、自力で書いた方が早い 場合 もある。

Introduction to scientific programming in python

  • Olivier Hervieuさん
  • 感想
    • 科学計算ライブラリのサーベイ発表だった。
    • matplotlibがあればRを使わなくてもビジュアライズできるなと改めて理解した。
    • 今の本業で使う事はないが、以前は必要だったし、今後また必要になるかもしれないので、改めて動向は見ておこうと思った。
  • もうあんたらは科学計算プログラマだよ！こんなにセッションあるしw
  • 今日の話
    • 科学計算プログラマ必携のライブラリ・ツールを紹介するよ！
    • 製品化のための注意点を話すよ
  • iPython
    • Must Use だってさ〜
    • インタラクティブシェル
    • ブラウザベースで実行可能 いろいろサポートしてる
    • 簡単に使えて並列計算機でも高いパフォーマンスが出せる
    • Data collection, analysis and optimization with pythonでも使ってた
    • コメントはHTML, LaTeX, Markdown等等に保存できる
    • notebookのエクスポートも簡単
  • NumPy
    • (Effective numerical computation in Numpy and Scipyでも紹介されたもの)
    • 多次元オブジェクトをこねくり回せる
      • 行列計算のアルゴリズムを実装する手間が省けていいですね
    • フロントエンドはnotebookという
    • 線形アルゴリズムに最適化
    • ただしメモリを食う
    • Julia benchmarkの結果なんて信じちゃダメだ！！！(本当かはわからん)
      • numpy使っているか否かは言及してなかった
  • SciPy
    • 科学計算ライブラリ (名前の通りですね)
  • matplotlib
    • 2D, 3Dのハイクオリティプロッター
    • MATLABっぽくいける
      • 実際でもを見ると本当にそれっぽい
    • Introduction to Numpy and Matplotlib ってビデオを見るといいよ！4時間あるけど。
  • scikits
    • 機械学習
  • pandas
    • データ操作ライブラリ グルーピング、マージ、そしてインデクシング。
  • 注意点
    • numpy, scipy, scikit-lean をつなげて行くと、 Fortranレベルでいけるっぽい。
    • 再コンパイルは長い。(辛い)
    • パフォーマンス重視: numba, cython
    • DSL: sympy, nltk
    • bindings: rpy2
    • storage: pytables
    • 無料で利用できる
      • なんかあったら直そう、直します。

リファクタリングツールあれこれ

  • @tell-k さん
  • 感想
    • コーディング基準を守るんでなくて、コーディング基準に沿ったコードを自動的に生成する時代となった。
    • そして僕の前に狂戦士がやってきて殺される。
    • 心を入れ替えて.vimrcをアップデートします。
    • ごめんなさいごめんなさい。
    • 一方で、コードの見通しやコメントの良さはこれらではカバーできない事でもあるので、引き続き広い視野を持ってコードを書くのを忘れないようにしたい。
  • リファクタリングそのものの話はしない！
  • リファクタリング ツール の話をします。
    • vim中心に説明します！
  • pep8, pep257
    • 文法チェック
  • pyflakes
    • 文法エラー
  • flake8
    • pep8, pyflakes
    • pep257対応のために flake8-docstring を突っ込む
  • gofmtの代わり
    • autopep8
    • autoflake
  • 支援/リファクタリング
    • jedi
  • 特にリファクタリング
    • Rope
      • IDEに見劣りしない編集ができるようになる
  • Code Climate
    • 自動でレビューしてくれるサービス
    • ただRuby, PHPのみで、Pythonは使えない。
  • Radon
    • 2つの指標で評価
      • Cyclomatic Complexity: 循環的複雑度 6段階で評価
      • Maintainability Index: 保守容易性

Python を支える技術: ディスクリプタ編

  • Nozomu Kanekoさん
    • @knzm2011
    • 公式ドキュメント 翻訳担当者
  • 感想
    • いろいろはまった時に、この事を思い出すとコーディングでつまづかないのではと考えた。
    • ただ、自分自身で改めて人に説明できるほど深く理解できたとは思っていない。
  • はい
    • シリーズ物ってことではありません。
    • ドキュメント、ソースを読めば一通り書いてある。
    • Python 構文解説にディスクリプタの事が書いてあるwww かぶった。
    • 公式ドキュメント 翻訳担当者 大募集中！
  • 分類
    • データディスクリプタ
    • 非データディスクリプタ
    • 読み取り専用のデータディスクリプタ
  • 分類は属性アクセスの優先順位に影響してくる
  • プロパティはディスクリプタの一種
  • インスタンスメソッドの読み出しは、ディスクリプタによって単なる関数呼び出しに変換される。だから、第1引数にselfがある。

関連投稿

催し 日記 音楽

初・ピアノの発表会で息子と連弾をしてきたよ #ピティナ

プログラミング 身の上話

プログラミングを始めたきっかけ – 1997年にさかのぼって

プログラミング

Software Design 短期連載「Webサービスを裏で支える!! バッチ処理設計の勘所」を終えて #gihyosd