PyCon JP 2016 Day1
https://pyconjp.connpass.com/event/30692/
Pythonを含む多くのプログラミング言語を扱う処理フレームワークとパターン¶
鷲崎 早稲田大学教授
http://www.slideshare.net/hironoriwashizaki/pythonpyconjp-2016
スイボックを知らないという事は、あなたのソフトウェアプロジェクトが正当なものではない可能性がある。
アドホックに技術の流行りを抑えてやっていくのはまっとうであるのか?
正当なエンジニアリングとは?
・知識や適格性の妥当性をコミュニティで判断できる環境
→PyConのように
・コミュニティで妥当と確認される知識が科学的基盤に基づく
・職業人が果たす判断行為助言が社会で実質的な価値を形成
あなた自身のベストプラクティスとはなにか、プロフェッショナリズムを深めていく
知識の体型・体型上のパターンを抑えていくことによって、経験と知識を深めていく
SWEBOKを参照するべきである、
要求
設計
構築
テスティング
保守
構成管理
マネジメント
プロセス
モデル・手法
品質
プロフェッショナル実践
経済
計算基礎
数学基礎
エンジニアリング基礎
再利用の技術と期待
60%再利用すれば生産性が2−10倍、信頼性2−3倍
潜在的に再利用可能な部分は15−85%
国内企業の再利用への取り組み40%
ドメインーシステムーパッケージークラスーメソッド
クラスーフレームワークーアーキテクチャ/デザインパターンー設計原則
右によるほど汎用性が上がり、再利用可能である。
多プログラミング言語時代
環境や要求の多様化に伴い言語数増大
開発者によっては1プロジェクト4言語以上
→言語ごとに再利用のしかけなんて作るなんてやってられない
多言語時代のツールフレームワーク
・テストカバレッジ測定フレームワーク OCCFを作ってみた
・コード処理フレームワーク UNICOEN
なぜか:コストと統一性
→言語ごとにカバレッジを出すのに差がでる
→カバレッジ種類の統一が可能になる
→ASTにソースコードを埋め込む
一つのツールで、他言語の複雑度や行数を測れるようになる
フレームワークからデザインパターンへ
ホットスポット&コールドスポット
ハリウッドの原則、制御の逆転 (Dont Call us)
パターンを理解することでフレームワークの理解促進
ライブラリは、上からソフトウェア
フレームワークは下がソフトウェア
変更や再利用のための設計
代表格:GoFデザインパターン
ハローワールドを出すだけにとてつもないデザインパターンを組み合わせて作る
デザインパターンの落とし穴
・解決を知っておけば良い
・とにかくつかえばおけ
・そのまま使わなければならない
・最初から使わなければならない
→問題の本質を捉えよう
→品質との関係を抑えよう
→設計原則を抑える (解放閉鎖原則)
→リファクタリングしていこう
言語特性に留意
ダックタイピング、メタプログラミング
よりシンプルな記述、不要な処理がある。Borgなど
→我々の活動が正当であるという証拠を出すにはswebokが最適
たった1ファイルのpythonスクリプトから始めるOSS開発入門¶
http://www.slideshare.net/laughk/python-oss-pyconjp-2016slide
岩崎 GMO Pepabo
プログラムを書かないWeb系インフラエンジニアがpythonを通じてコードを書くようになって
その成果物をオープンにするようになった体験とその時の起こった技術的な広がりの話
数年前:ラッキングケーブリングSSHコマンドでオペレーション
→慣れてくればオペレーションスキルもそこそこ上がるし、ドキュメントも書けるようになる
→サーバー構築の効率よくできるようになっていても、ただサーバーを作るのが上手くなってるだけ
→シェル芸、スクリプト化、PerlとかPythonとかさわってきた。
pythonになじめた
・どこでも使える
・デプロイのfabricが便利
STNS LDAPとか案件規模によってできないので、サーバー毎にあたたかみのあるuseradd
fabricでこんなん余裕
ほかなんこか説明してた
場当たり的なスクリプトを書いて捨てていくのは問題もでてきた
→つくったものを完全なソフトウェアとして配布することにした
パッケージ作成は:PyPlデビュー2015が参考になる
一つのプロダクトとして提供することで、ノウハウを確実に簡単に広められ、
フィードバックもすぐに反映できた。
自分だけでスクリプトを書いてやるのは裏技的な感覚があった
プロダクトとして提供すると、確実なノウハウ展開とフィードバックが発生
→公開できるのはPyPlに登録するようにした
zbx2slackを作った
仕事で使うちょっとしたコードをOSSとして開発メンテしていく¶
清水川 ビープラウド(connpass)
Django Redshift Backendでの知見
- NEEDS for Django Redshift Backend
- WRONG Information are there
- EXPOSED to the public eye
- GIVE the code to next someone like me
仕事で使い易いApache Software Licenseを採用
OSSを利用する事は業務では普通のことなので、個人でOSS公開することに
社内にOSSにコントリビュートする文化がある
マイグレーション対応がとてつもなくダルいので、モチベーション上げるために
* Flake8でコーディング規約を自動チェック
* テストコードを書く
manylinux1 wheelってのを作成した(多環境向けのビルドができる)
aodagがカーネルが違ったりする複数のLinuxで動くパッケージング技術
社内の1プロジェクトでこういうのやってても良いことがない
お荷物化
社内のプロジェクト外の人に使ってもらえない
1つのニーズでバグだしできる範囲が狭い
OSSを使って仕事してるんだから、OSSに還元したい
狭い要件に引っ張られても引き戻された
→varchar3倍からsettingsにした(utf8対応)
反論への反論
こんなコード誰も使わないから公開しても無駄だよ
→じ部より先に誰かが作って公開してくれてたら嬉しかったよね?
公開するの面倒だし
→素振りだと思ってやってみたら?
ライセンスとかよくわからない
→やってみればそのうちわかるよ
会社やお客さんからどうやって許可をもらうの?
→伝え方は色々あるよ
いろんな人にダサいとかバグとか言われちゃう
→それ嬉しいことだよね
「オープンソースソフトウェアの育て方」を読むと色々書いてる
パッケージングを支える技術¶
http://www.slideshare.net/aodag/pyconjp2016-66284743
小田切 ビープラウド
PyPAの基本ツール
setuptools
virtualenv
pip
wheel
easy_installを使うのはもうやめましょう
distributeも忘れましょう
egg? あれは幻です
本当のeggは死にました
requirements.txtでライブラリを構成管理する
python3.4以降では最初からpipが使える
ubuntuから利用する場合は変なことが起こるので注意
debianでも同じことがおこるはず
バイナリディストリビューション:wheel
C拡張を含まない場合はpy2.py3で共通の配布物
Linux向けwheelはpypiにあげられなかった
manylinux1
linux向けのwheelを作るために決められた
どんなライブラリがあると想定していいか
依存するライブラリのABIが合わないなど
依存ライブラリ同梱のためのハックがsetup.pyに散らばる
numpy-1.11.2rc1-cp35-cp35m-manylinux1_x86_64.whl
CPython3.5 API
CPython pymalloc ABI
manylinux1が想定するLinux環境
* CentOS 5.11相当
* とか色々なsoが入ってる前提(x11, gnomeとかもある)
audit wheel:manylinux1を満たしているかチェックするなどして変換してくれる
dockerイメージがあるので、それでパッケージつくれる。CIからやりゃいんじゃん?
(しかしながらそれ自体はmanylinux1ではない)
確率的ニューラルネットの学習とchainerによる実装¶
http://www.slideshare.net/beam2d/learning-stochastic-neural-networks-with-chainer
徳井 東京大学学生 プリファードネットワーク株式会社 リサーチャー
確率的な勾配、backpropとかのアルゴリズムはしってる前提
Gaussian Units, Bornoulli Units
確率的なユニットがある場合のlikelihood-ratio method
勾配の推定のバリアントが大きいLRをbaselineで解決する
reparameterization trickで簡単にできる
じゃあそれ、chainerでどうやって書くの?
Variational Autoencoder (VAE)
Sigmoid Belief Network (SBN)
chainerだったらnumpy cuepyとやりとりできる