PyCon 2016 参加ノート (カンファレンス1日目)

PyCon JP 2016 in Tokyo に聴講者として参加したので、以下に聴講ノートを記します。

PyCon JP 2016 in Tokyo について

PyConはPythonコミュニティのためのカンファレンスです。米国PyConや欧州のEuroPython、および科学系のEuroSciPyなどが知られているほか、各国でも各地域のカンファレンスが開催されています。
そのなかでもPyCon JPは、日本のコミュニティである一般社団法人 PyCon JPにより日本で開催されているカンファレンスです。
PyCon JP 2016 in Tokyoは、チュートリアル1日・カンファレンス(本会議)2日・スプリント2日からなり(スケジュール)、
このうち本会議2日間に参加したので、以下はそのトークの聴講ノートとなります。

キーノート (Jessica McKellar)

  - Breaking rulesについての話
  - USより。
  - Python Software Foundation の former director
  - Python communityを大きくするのに尽力してきた
    - Ksplice, ZというDjangoベースのリアルタイムコラボレーションソフトウェア, Dropbox
  - "It was not about Python , but systems."
    - "programming changes the way you think and debug, interact the world.
  - みなさんは、ソフトを、ライブラリをつくり、言語を変えていき、…エコシステムに影響を与えていく。
  - キーワード: Tenets of free software
    - c.f. GNUの自由ソフトウェアとは、などを参照
  - Everything important is a system
    - important: worth fighting for
  - System: Software (of course), hardware, and also people system (society system)...
  - → this is why i teach people to program
    - Programmers master a system they know they can change
  - しかし…誰もruleとは何か、powerとは何かとは教えてくてない
    - the ability, power, confidence to change the system
  - 例は?
    - Democracy, climatechange...
    - これらは領域が異なり、ことなる専門性が必要な問題ありsystemの例
  - Python meerups
    - 世界中で行われている
    - 多様なソフトウェア、成功をもたらしている
  - それだけではなく、U.S. digital serviceなどから、政治にも影響を及ぼしてきている
  - → the ability, power, confidence to change the system
    - 変革のための力を変えることを躊躇するな
    
  - いくつのときに学習をはじめた?
  
  - Most elegant system
    - 少数の式で表せる系などはエレガン度
    - 今取り組んでるシステムはエレガントではない
  
  - OSSへのコミットには、レビューに長い時間がかかり、つらい。あなたならどう耐えてる?
  
  - Q. プログラマとしてプログラミング未経験者にどう接するべきか?
    - A. 自分が何かしら未経験の分野に踏み入れてみること。そうすればビギナーの気持ちがわかる #pyconjp
  
  - Q. 「成功」をどう定義するか?プロジェクトが完遂できないときは?
    - A. 何行コードを書いたとかではなく、自らに対する評価に目を向けてみる
    - (もちろんプロジェクトの目的によるが)

[招待講演 / Invited Talk] Pythonを含む多くのプログラミング言語を扱う処理フレームワークとパターン

  - 多言語を扱う処理フレームワークを研究でも取り扱っており、それをテーマにする。
  - ToC
    - エンジニアリングと再利用
    - 多言語時代の処理フレームワーク
    - FWからデザインパターンへ
  - Q. SWEBOKを知っていましたか?
    - 大多数がNO.
    - NOの人へ: あなたのソフトウェアエンジニアリングは正当ではないかもよ!
  
  - 正当なエンジニアリングとは
    - 1. 知識・適格性の妥当性をコミュニティで判定できる環境
    - 2. コミュニティで妥当と確認される知識が、科学的な基盤に基づく
    - 3. 職業人が果たす判断、行為、助言が社会で実質的な価値を形成
  
  - 知識・経験・ガイドによりプロフェッショナリズムを
    - Kernel and Language for Software Engineering Practices.
    - ポイント: 知識の島々を体系化し、体系上のパターンや手法を疂ねる
      - ことで、より速く、確実にプロフェッショナリズムに近づける
  
  - SWEBOK: SoftWare Engineering Body of Knowledge
    - 要求・設計といったレイヤの下に、ベースとしてプロフェッショナル実線や経済、計算、数学、エンジニアリング基礎などがある
  
  - 再利用の技術と期待
    - 60%再利用すれば生産性2〜10倍、信頼性2〜3倍
    - 潜在的に再利用可能な部分は15〜85%
    - 国内企業への再利用の取り組み 40% 
  
  - 抽象から具象へならべた単位と、応用性
    - 設計原則 ← たいてい使える(裏を返せば、きちんと考えてつかわなければならない)
    - アーキテクチャパターン ← 使えるかも
    - デザインパターン ← 使えるかも
    - フレームワーク ← 特定の場合に使える
    - クラス・関数ライブラリ
  
  - 多言語時代
    - TIOBE Index top 15 lang の percentile → 86%('12)→ 70%('15)
    - 開発者によっては1プロジェクト4言語以上
  - 多言語時代のツールフレームワーク
    - テストカバレッジ測定フレームワーク
      - Open Code Coverage Framework
    - 汎用コード処理フレームワーク
      - UNIfied source COde ENgineering framework (UNICOEN)
  
  - 1. 問題と解決: コストと統一性
    - 開発と保守コストが大きい
    - カバレッジの種類がバラバラ
      - Python: Statement COverege, C: COVTOOL, Java: Cobertura
    - → フレームワークによる支援
      - 共通処理の再利用
      - カバレッジ種類の統一
      - 柔軟な機能拡張
      -  コード埋め込みの支援
  - 2. OCCFの構成
    - カバレッジ測定用コードの埋め込み
    - 自動で挿入・副作用なし
  - 3. UNICOENの構成
    - 特化API: 言語変換, コード補完
    - ツール開発者向け汎用API: バグ検出, 品質測定など
    - 対応言語拡張者向けAPI: C, Java, Rubyなど向け
  - 統合コードモデル
    - 自動コード挿入にあたり、言語を問わないメタモデルとしての統合的なモデルを作った
  
  - ツールの他の応用: 翻訳による言語学習
    - 言語感の共通部分については翻訳することで再利用を可能に
    - c.f. http://heroku-editor.herokuapp.com/converter
  
  - フレームワークからデザインパターンへ
    - 再利用・拡張実現の定石がデザインパターン
      - ホットスポット&コールドスポット 
      - IoC (or ハリウッドの原則 Don't call us)
    - デザインパターン: 設計の特定状況下での頻出問題&解決
      - 変更や再利用のための設計
      - 共通言語、共通指針
      - Gang of Four デザインパターン
  
  - 例: Template Methodパターン
    - 問題: アルゴリズムの構造を変えずに、場合によって処理内容を変更したい
    - テンプレメソッド、プリミティブオペレーションを分割
    - 我々は構文木の構築に利用
  
  - デザインパターン
    - 解決を知っておけば良い→NO
    - 使えば良い→NO
      - 複雑なパターンは欠陥率増大
      - 知識不足で作業時間増大
    - 最初から使わなければならない→NO
      - モダンプラクティスでは、リファクタリングが前提なので。

c.f.

  - http://www.nttdata.com/jp/ja/insights/trend_keyword/2014122501.html
  - https://www.computer.org/web/swebok

プロダクトフェア: Beyond deeplearning ~深層学習の次の一手~

  -  GFS→HDFS, MapReduce は Hadoop、BigtableはCasandraやHBaseなど、OSSがデファクト化した
  - それで、それらを作った開発者が、Google発のものをデファクトスタンダード化するためにTensorFlowを出す
  - Googleのエンジニアは外に出られない。国内にもSearchやChromeのエンジニアはいるが、立場上喋られない。
    - 外に出るのは、GCPやアド系のエンジニア。
  - TensorFlowの利用例
    - 農家による曲がっているきゅうりの分類 (良さ度9段階)
    - 7割の精度でイケている (正答率の話かな)

各社同士のQ&Aタイム

  - Azureで機械学習を利用しているユーザーはどの程度?
    - トラッキングしていないが、肌感覚では50%ほど。
  - コグニティブサービスのAPIなどが出た際は、どのような反応はどのようなものか?
    - REST APIなので、おバカアプリなどで結構よくつかわれる
    - 芸能人がAVに出演疑惑が起きたときに利用されるようなケースも…
  - Deep Learningはハードが戦場になると思っており、MSRは検索インデックスの構築やDLなどをハードで構築しているが、…NVIDIAからニューラルネットに特化したチップっていつ出る?
    - それは株価に影響するので言えないが…
    - アルゴリズムがどんどん変わっていく時代だと、まだSoftware-definedなほうが楽なのでは。
    - そもそも現時点ではハードに落とすときもハードを意識していない時代だし。
    - 一部はビット落としても良いとは言っているが、あの論文では全部落としても良いとは言っていないよ。
  - GPUの売り方って変わっている?クラウド、つまりサーバーレスが流行りであるが、それはクラウド経由での販路が出来たということでは。
    - はい。
  - MSでのハードの取り組みは
  - 「クラウドのサービスが始まると秋葉原からGPUが消える」
  - 日本の市場はChainerがリードしているというのが興味深い
    - 選択肢が多い中でパイが大きくなっているのではないか
    - TensorFlowも急に伸びている
  - Googleの今後のOSS戦略は?
    - GCPというブランドができ、ストラテジーが大きく変わった。
    - App Engineだけのときから変わった。
    - TensorFlowや、Apache Beamなど。(Google Cloud Dataflowが元)
  - ユーザの意識変化について
    - GPGPUはボトムアップだったが、データサイエンスはトップダウン。
    - 今のユーザはGPUのアーキテクチャを意識しない
    - Deep Learningは、モデルがしっかりしていなくても、データ量と計算量で殴れば成果がでるという意味では、Engineeringの領域に入ってきていると感じる。
  - 告知
    - GTP2016 (GPU Technology Conference)

Pythonで作るTiny DAW (Digitai Audio Workstation)

  - モチベーション
    - LaunchPadがおもしろそうだったが、付属ソフトが複雑で難しい!
    - ならPythonで書いてみよう
  - DAWの必須機能
    - リアルタイム性
      - UIと発音のレイテンシ
      - 発音中の操作可能性
    - 多重発音
  - リアルタイム性の確保
    - エフェクタを考えない。(こいつはめっちゃ重いので)
    - クリップを全部オンメモリで持つ。
    - 入出力のブロッキングだけ気をつける。
      - モダンなCPUだとスレッドを立てて回せば良い。
      - 今回の場合、Writer(+Queue)とReader(→Event発出)がいる。
  - 多重再生
    - 自前で作ると大変。
      - 複数のバイト列を合成して一つの波形に。
      - PCMバイトストリームは非同期に入ってくる。
      - 最終出力段のバッファリング精度も問題。
        - レイテンシを気にしすぎて小さくすると、音がプツプツ切れるようになる。
      - ここでもリアルタイム&ブロッキングが重要。
  - で、どうしたか… PyGame on SDL2
    - SDL2のPython wrapper
    - SDL: Simple Direct media Layer
      - メディア系総合ライブラリ
      - クロスプラットフォーム
      - 今回はpygame.mixerを利用
      - sound = pygame.mixer.Sound(FileName)
      - sound.play()
      - WAV, OggVorbisを読める。(144, 16bitが読める)
    - といっても…無限多重じゃない。
      - 内部的にChannelというオブジェクトで管理している。
      - プールから空きを取り出し利用。
      - channel = pygame.mixr.find_channel()
      - channel.play(sound)
      - channel.stop()
  
  - UI設計
    - LaunchPadButton
      - 各ボタンに対応するオブジェクトをつくる
      - キーコードを持つ
      - 再生状態や色なと、状態を持つ
    - ButtonGrid
      - グリッド全体のボタン集合オブジェクト
  
  - IO
    - LaunchPadはMIDIデバイス
      - /dev/snd/midiCxDyからアクセス可能
      - バイト列を読み書きするだけ
    - 機器固有の機能をつかうためのメッセージ (MIDI Exclusive. 先頭部分が-header)
      - 0F 00 20 29 02 10 <CMD> <PARAMS> ... F7
      - LaunchPadはドキュメントがあった

  - コード詳解
    - pressとreleaseを使い分けている
      - 音を出す時はpress時、音を止めるときはrelease時 (瞬時性と押しミス防止)

Q&A

  - どの程度の性能ではどのていどのチャネルまでいける?やりすぎるとどう劣化していく?
    - エフェクトかけないとほとんど制限なしという感覚。
    - エフェクトはフックで好きな処理を入れられる。
  - MIDIのラッパーはなかったのか?

ニューラルネットワークのフレームワークであるChainerで始める対話Botの作成

  - 対話の価値
    - 連続性
    - 双方向性(interactivity)
    - ユーザ体験
  
  - 連続例
    - テニスが好きなんだ→いいね!→あそれとバイトを探してるんだ→テニス関係のバイトを返答、など
  - interactive
    - ダイエットやってるんだ→
  - 新たなユーザ体験
    - りんなをつかうことで、特殊なユーザ体験を作れる、など
 
  - キャラクターの価値
    - スーツの男と赤ん坊の図を出しつつ、どっちのほうが賢そう?どっちと話したい?どっちにギャップを感じる?
    - 学習教科によるおどろき(はじめはイマイチな返答だったのが、話すうちにいい感じの返しをしてくれることで、驚きと受容)
    - 「こいつ頭悪そう、でも話してみたい」、そう思わせるアイデンティティが大事 (学習データ収集が効率的に)
  
  - しかし、キャラクターごとに文章のいいかえを用意しておくのはつらい(キャラクターにあった文章をどうやって用意するか)
    - 執事風、太っている人風、女性風のセリフに言い換えるなど
  - コレの実現: Neural Story Teller
  
  - 全体のアーキテクチャ
    - 質問文はElasticsearchでWikipediaから返却
    - 対話文はTwitterや対話コーパスから学習(using Chainer)
  
  - 話題の選定
    - 恋人に話すことと兄弟に話す内容の差異
    - 話題の分類を事前に挟むことで、良いのではないか?
    - Word Netを利用
    - 5万件あり、多い…グルーピングで簡略化
    - グルーピングにおいて、意味がわかる空間にマッピング
      - Entity linkingを使用
    - WikipediaEntityVector (Word2Vecで、ハイパーリンクなどを用いて学習)
  
    - 距離の図り方
      - 写像空間の選定が命取り
      - コサイン類似度を使用
    
    - これをやってもまだ多い
      - n単語以上を有するコンセプトのみ選択 (今回はn=1000)
    
    - ユーザの発話中の単語が多く含まれるコンセプトを、話題のコンセプトとして採用
    
  - ニューラルネットの採用
    - 価値
      - 表現力
        - 通常は bag of words
        - Deep Learningでは、BoWを圧縮し、なおかつ意味のあつ(1/0)数値が並ぶ、これがWord2Vec
      - continuousity
        - リカレントネットワークを使用
        - 長さを気にせず使える
      - focus
        - attention

  - 実装
    - 
    
  - Question answer
    - その前に…質問文か雑談文かの判断
      - 5W1Hをつかうと良いという話もあるが、今回は簡便のため「?」の有無で判断

  - DockerHubに今回のデータを公開中

Q&A

  - RNNでは、短くて一般的な言葉(はい、など)が出やすいという話があるが、それを防ぐ手立ては行う?
    - LSTNをつかうと、そういった問題を解決できると考えているため、特に手だてはない。あっているか?
  - 実際の学習に使ったセンテンス数は
    - 失念
  - タスク型と非タスク型が混ざったようなシステムなので、評価が大変そう。
    - タスク型については答えが決まっているのでF-measureが使える
    - 非タスク型はユーザの感じが大事なので、実験するしかないと思っている。

パッケージングを支える技術

  - PyPAとは?
    - Python Packaging Authority
    - github.com/pypa と bitbucker.org/pypa にあるが、ミラーリングではない(!)
  
  - setuptools
    - easy_installはもはややめよう。
    - フォークしたdistributeは、もはやマージされて数年経っているので死ぬ。
    - eggも死んだ。
  
  - 今日のsetuptools
    - 去年は18→今年27
  
  - Python3.3以降はvirtualenv同等のpyvenvが本体にマージ
  
  - pip
    - sdistとwheelをとリアル変える
    - requirements.txtでライブラリを構成管理できる
  - wheel
    - wheel形式パッケージを作成するツール
    - setuptoolsにbdist_toolsというサブパッケージが出来る
  
  - Python 3.4以降ではpip, setuptoolsを導入するensurepipが入っているので、Pythonインストール時にpipを利用可能
  
    - virtualenvは、環境作成時にpip,setuptools,wheelを導入する
    - どの環境でもget-pip.pyでpip,setuptools,wheelを導入できる。
  
  - Ubuntuのpyvenv
    - 14.04のpython3.4はensurepipが消されている!
    - --without-pipをつけないとエラーになる
    - 16.04のpython3.5はensurepipが謎のパッケージメタデータを作成する (pkg_resources-0.0.0)
    - そのままpip freezeするとエラーになる
    - 回避策は--without-pipで環境をつくり、get-pip.pyでツールど導入する
    - pkg_resourcesを消すと、setuptoolsのメタデータが残ったまま、setuptoolsのソースが消える(再インストールすらできない!)
  
  - PYTHONPATHは複数指定できる
  
  - site-packages/user-site-packages
    - サードパーティ性ライブラリのインストール先
    - Debianではさらにdist-packagesがある
    - user-site-packagesは--userでインストールする先
  
  - .pth
    - site-packagesに配置されるファイル
    - 中に羅列したファイルパスがsys.pathに追加される[
    - ./以外で始まる行があると、pythonコードとして実行される
    - easy_installで活用されていた
  
  - distutils
    - setup.pyのsetup関数の大もと
    - setuptoolsはこいつを拡張している
    
  - wheel
    - PEP427で定まっているバイナリ形式の配布フォーマット
    - C拡張を含まない場合、py2/py3で同一になる
  
  - Linux向けwheel
    - 今まで無かった。
      - Distributionによってライブラリが異なり、コンフィグが異なったので。
    - PIP513により進展はあった。
      - 仮想のdistributionであるmanylinux1というdistribution向けのパッケージをつくる
    - ライブラリの仮定、ABI互換性、依存ライブラリ同梱のためのハックがsetup.pyに散らばる
  
  - ABI?
    - ucs-4, pymallocの設定によってABIが違う(しかも、落ちるのは起動時ではない)
    - Python3ではすべてUCS-4ビルドになった。
  
  - wheelの名前規約
    - 名前-バージョン-CPythonのAPI-CPythonのpymallocビルドのABI-対象OS
  
  - manylinux1とは
    - CentOS5.11相当
    - x86とx86_64の両方
    - その他、前提として良いライブラリが想定
      - Gnomeの依存関係も入っている…
  
  - auditwheel
    - linux向けwheelをmanylinux1に変換するツール
    - 依存ライブラリをwheelに同梱させる
    - wheelファイル名のplatform tagをmanylinux1に変換
  
  - Dockerを利用してパッケージを作成する
    - quay.ioにDockerイメージが有る。
    - CIでこのイメージを利用してパッケジングする
    - werckerやgitlabでできるよ。
      - /opt/python以下にさまざまなpythonがある。
  
  - ソースディストリビューションsdistとはなにか
    - setuptoolsとpipの実装によりなんとなく定まっている (PEPでない)
    - setup.py installができればsdist (というしかない)
    - コミュニティでも問題か
    - setuptoolsなくてもwheelがつくれるので…
    - インストールフローを明確化し、setuptools依存を脱却したい
  
  - PEP 518
    - パッケージの定義
    - pyproject.toml
      - TOMLって標準ライブラリにないんだけど…
  - PEP 516
    - ビルドツールの指定や依存性を記述
    - しかしpyproject.tomlのtoolsセクションに書かれるものでは…
  
  - setuptoolsに依存せずにパッケージングしてみよう
    - distlibでできること
      - wheel作成、インストール、メタデータ作成、など
    - distlibと標準ライブラリだけでつくったよ bib
  
  - PEP 503
    - Simple Repository API
    - 登録やアップロード方法は定められていない
    
  - PEP 376
    - distlib.databaseでインストール済みパッケージが一覧できる
  
  - 様々なツールがエコシステムに参加できるようにsdistの定義が検討されている
  - wheelはがんがん使っていこう

How Python helped create the visual effects for an Emmy nominated TV show

Lighting Artistによる講演

  - 仕事はResident Evil, TRON, VIKING, HOLMES, INSPECTION
  - myplanet社にいる
  - VFX系アプリは多くがPython APIを持っている
    - Maya, 3DS Max, Houdini and more
  
  - Programming in VFX
    - CG Reaearch and Dev.
    - Pipline engineers and developers
    - Technical Directors
    - Eager Artists
  
  - TV showでも自働化要求は高い
  
  - 作成順序
    - Clean plate
    - Modeling
    - Layout and Animation
    - Texturing and shading
    - Lighting, Rendering and compositing
  
  - さまざまな視覚効果をレンダリングし、ポストプロセス時に選択可能にするようスクリプトを組んだ
  
  - Check with diligence
    - スクリプト化はヒューマンエラーの減少にも使える。
    - レンダリングはめちゃくちゃ高くつくのに対し、それに向けた設定画面は複雑すぎてヒューマンエラーが起きやすすぎる。
  
  - sQuery
    - jQuery風にノードを選択する仕組みをつくった。