はじめに
鈴木たかのりです。
前回 に引き続きPythonエンジニア養成読本 という書籍の読書会イベント についてレポートします。
第2回の読書会 は6月18日(木)にアライドアーキテクツ株式会社 の会議室で開催されました。
当日はだいたい以下のタイムテーブルで進めました。
19:00-19:15 参加者の自己紹介
19:15-19:45 「 Appendix1 便利な標準ライブラリ、サードパーティ製パッケージ」
19:45-21:00 「 第3章 開発環境とチーム開発」
21:00-22:00 ビアバッシュ(ビールとピザでの参加者懇親会)
今回も前回と同様に本書の読み合わせは行わず、ざっと内容について解説をしたあとに質疑応答を中心に進めました。
写真1 読書会の様子
自己紹介
最初に全体で自己紹介を行いました。全部で23名の方が参加してくださいました。また、今回は著者6名のうち5名が参加していました。全体としては1/3が初参加、2/3が2回目の参加という感じでした。
自己紹介の中では2回目参加の方から「会社でちょっとしたスクリプトをPythonで書き始めた」「 PyCharmを使い始めた」といったように、前回の内容を踏まえて進展があった内容が印象的でした。今後も、3回、4回と継続していく中で、参加者の方の新しい成果が自己紹介で聞けるといいなと思いました。
Appendix1 便利な標準ライブラリ、サードパーティ製パッケージ
Appendix1は筆者の担当です。今回は前回の反省を踏まえて、最初に自己紹介を行いました。@takanory のTwitterの画面を見せつつ、先週は台湾で開催されたPyCon APAC 2015 に参加していたことや、ちょうどこの日はPyCon Singapore 2015 が開催中で、知り合いのshimizukawaさんが参加している、といった話をしました。
写真2 発表中の鈴木たかのり氏
以下はPyCon APAC 2015の集合写真のツイートです。どこかに筆者がいます。
PyCon APAC、PyCon Singaporeについてはgihyo.jp の以下の連載記事でレポートされています。こちらもぜひ読んでみてください。
Pythonの付属バッテリー、標準ライブラリ
この節では、Pythonをインストールすると付属してくる標準ライブラリについて一部を紹介しています。最近のプログラミング言語では一般的だと思いますが、Pythonでもインストールするとさまざまな便利な標準ライブラリが使えるようになります。付属バッテリーとはおもちゃなどで「電池が同梱しているのですぐに遊べます」というような意味から取られています。
「こんなのあるといいな」と思ったらとりあえず標準ライブラリを探すと、だいたいすでに提供されているので、ぜひライブラリの一覧を見てください、という話をしました。
Python標準ライブラリについては下記のドキュメントにまとまっています。日本語化もされており、Pythonドキュメント日本語訳プロジェクト のみなさんには非常に感謝しています。
本書ではたくさんあるライブラリのうち「これくらいは知っておいたほうがいいかな」という一部のライブラリのさらに一部の機能だけを紹介しています。
たとえばOS依存の機能を操作するosモジュールでは以下のディレクトリ操作を行うコードを紹介しました。実際にはosモジュールのドキュメント を見てみると、たくさんのメソッドが用意されています。
osモジュールのサンプルコード
>>> import os
>>> os . mkdir ( 'spam' ) # ディレクトリを作成
>>> os . chdir ( 'spam' ) # ディレクトリを移動
>>> os . getcwd () # 現在のディレクト名を取得
'/Users/takanori/spam'
ここでは質疑応答で、本書で紹介している以外によく使うライブラリはなにか? という話が出ました。
ちなみに、本書の中で紹介しているライブラリは以下の通りです。
sys-システムパラメータと関数へのアクセス
os-オペレーティングシステムインターフェース
time-時刻データへのアクセスと変換
datetime-基本的な日付型および時間型
math-数学関数
random-擬似乱数の生成
itertools-効率的なループ実行のためのイテレータ生成関数
shutil-高レベルなファイル操作
json-JSONエンコーダおよびデコーダ
ここで筆者を含め会場から回答として挙がった、よく使うライブラリは以下のようなものでした。
urllib、urllib2-URLでのリソースへのアクセス
urlparse-URLの文字列解析
logging-ログ出力
argparse-コマンドラインオプションの解析
別の方から「shutilでできることはosでできるのではないか?」という質問がありました。答えはそのとおりですが、例えばshutilだとcopytree(src, dst)
でディレクトリツリーをまとめてコピーしてくれますが、osモジュールで実装しようとすると、自分でディレクトリとファイルを走査して一つずつコピーするなど大変です。そういう意味でもshutilはユーティリティー的に便利な機能を提供してくれています。
余談としてlogging はバッチファイルなどでも途中経過を出力するときに使うと便利であるという話をしました。また、コマンドライン引数の処理はoptparse とargparse が標準ライブラリにありますが、optparseは廃止予定 のため、argparseを使ってくださいという話もしました。
写真3 質疑応答中の鈴木たかのり氏
Pythonをさらに強力にするサードパーティ製パッケージ
この節では標準ライブラリ以外に多数のサードパーティ製パッケージが提供されていることを紹介しています。PythonではPyPI: Python Package Index (パイピーアイと読みます)というサイトで提供されており、pip コマンドでインストールして使用できます。
ここで「Windowsでは書いてある通りにpipをインストールができなかった」という質問がありました。本書で挙げているコードはLinuxを想定しているのでsudo でrootユーザになってpipをインストールしています。「 Windowsではsudoはおそらく不要である」という回答をしましたが、無事pipコマンドがインストールできたようです。
ちなみにpipのインストールはhttps://bootstrap.pypa.io/get-pip.py をダウンロードしてpython get-pip.py
を実行して行います。詳細はInstallation ドキュメントを参照してください。
また、ここでは良いパッケージを探す指標として、更新の履歴やダウンロード数がPyPIで確認できるので、更新が頻繁である、ダウンロード数が多いパッケージは良いパッケージである可能性が高いという話をしました。たとえばHTTPアクセスを人にわかりやすい形で記述できるrequests は、今年5月のバージョン2.7.0まで継続的に開発されており、1日に174,718回もダウンロードされていて、よく使われていることがわかります。
他に良いパッケージを探す手段としてStack Overflow で検索して回答を見るという方法が紹介されていました。確かに有用な方法だと思いますので、お勧めです。
まとめとしては、標準ライブラリ、サードパーティ製パッケージではたくさん便利なものが用意されているので、ぜひ良いものもを見つけて活用してほしいなという話をしました。
第3章 開発環境とチーム開発
第3章の著者の嶋田健志(@TakesxiSximada )氏にバトンタッチして、後半の読書会をはじめました。
写真4 発表中の嶋田健志氏
3-1 開発環境とチーム開発に求められること
この節ではこのあとに解説するそれぞれの項目について概要的に触れています。チーム開発として必要な以下の要素について簡単に解説がありました。
バージョン管理システム
チームで開発を行うためには、それぞれの担当箇所の開発を平行して行うために、バージョン管理システムが必要です。
隔離された実行環境
さまざまなプロジェクトの開発を行う場合に、プロジェクトごとに使用するライブラリのバージョンが異なる場合があります。環境を混在させないために隔離された実行環境が必要です。
ソフトウェア品質の担保
作成したソフトウェアがきちんと仕様どおりに動作するか確認するためにテストが必要です。
ドキュメント
仕様書や手順書などをチーム内で共有するために、あまり手間を掛けずにドキュメントを作成する必要があります。
統合開発環境
これからPythonで開発を行うのであれば統合開発環境を使用して、テストやデバッグを効率的に行う必要があります。
3-2 GitとGitHub
この節ではバージョン管理リステムとしてGitの紹介と、ホスティングサービスのGitHub について解説しました。
最初にGit、GitHubを使っているかどうか参加者に聞いていましたが、使ったことがない人がそこそこいたので、少し丁寧に解説をしました。
バージョン管理については馴染みの話題ということもあり、参加者からたくさんの質問が出て執筆者の嶋田さんが回答しました。
Q:ブランチはどの単位で作成しているか?
A:機能単位(Redmine、GitHub Issueの単位)で作成している。今のプロジェクトでは「fix_shimada_チケット番号」というようなブランチ名にしていて、ブランチは人に紐付いている。担当者が変わった場合はブランチを作成し直す
Q:普段はコマンドラインとGUIツールのどちらを使っているのか?
A:コマンドラインを使っている。GUIツールのSrouceTree は手になじまなかった(ちなみに筆者はGitを使いこなせていないのでSrouceTreeを使っています)
Q:コンフリクトをしたときにはコマンドラインだと大変じゃないか?
A:ガッツで乗り切っている(笑)
Q:Gitをデザイナーさんにどうやって使ってもらうか。今はメールとかでもらったものを代わりにcommitしている
A:(答えはない……)( 注1 )
またGitHubに関する質疑応答は以下のとおりです。
Q:仕事でGitHubを使っているか?
A:使っている。ただし、本書はMercurial(別のバージョン管理ツール)とBitbucket(別のホスティングサービス)を使用して執筆した
Q:GitHubに企業で開発しているコードを載せると他の人から見られるのでは?
A:無料プランは公開リポジトリしか作れないが、お金を払うとプライベートリポジトリが作成できる。仕事ではプライベートリポジトリを使用している。個人でプライベートリポジトリが必要であれば、無料で作成できるBitbucketがお勧め
3-3 virtualenv
この節ではプロジェクトごとにPythonの環境を独立させるための、virtualenvについて解説しました。以下のコードはvirtualenvをインストールして利用している手順です。
env環境でのみrequestsが利用可能になっていることが確認できます。
virtualenvのインストールと利用
$ pip install virtualenv # pipコマンドでインストール
$ virtualenv env # envという名前で環境を作成
New python executable in env / bin / python
Installing setuptools , pip ... done .
$ . env / bin / activate # env環境を有効にする
( env ) $ pip install requests # requestsをインストール
( env ) $ python
>>> import requests # requestsをインポートできる
>>> quit ()
( env ) $ deactivate # env環境を無効にする
$ python
>>> import requests # requestsのインポートに失敗する
Traceback ( most recent call last ):
File "<stdin>" , line 1 , in <module>
ImportError : No module named requests
virtualenvを使うことにより、プロジェクトごとに同じパッケージでも異なるバージョンを使用したりといったことが可能になります。また、vritualenvwrapperのようにvirtualenvをより便利に使うためのツールも提供されているので好みで使ってみてください、という話がありました。
virtualenv環境をどのように作成してどのフォルダに配置するかというのは、人それぞれなので、正解はないという解説もありました。
質疑応答では「Windowsでファイルの関連付けは変わらないのか?」という質問があり「おそらくファイルのダブルクリックやOS経由でPythonを呼び出すときには、virtualenv環境の外になるため元々のPythonが呼び出されるのではないか」という回答がされました。
他に「本番環境にリリースするときにはどうしているのか」という質問があり、「 OpsWorksを使用して、デプロイするスクリプトの中でvirtualenv環境を作成している」という回答がありました。
プロジェクトで沢山のサードパーティ製パッケージを使用している場合、本番環境にインストールするのが大変ではないか? という質問がありました。pipコマンドにはpip freezeという現在インストールしているパッケージの一覧を出力するコマンドがあり、これを使用することによって、同じ環境が簡単に作成できるという解説がありました。pip freezeを使用した例は以下のようになります。
pip freezeの利用例
( env1 ) $ pip freeze > requirements . txt # パッケージ一覧をファイル出力
( env1 ) $ cat requirements . txt # パッケージ一覧を確認
alabaster == 0.7 . 4
Babel == 1.3
docutils == 0.12
Jinja2 == 2.7 . 3
MarkupSafe == 0.23
Pygments == 2.0 . 2
pytz == 2015.4
six == 1.9 . 0
snowballstemmer == 1.2 . 0
Sphinx == 1.3 . 1
sphinx - rtd - theme == 0.1 . 8
( env1 ) $ deactivate
$ virtualenv env2 # 新規に環境(env2)を作成
$ . env2 / bin / acitvate
( env2 ) $ pip freeze # パッケージが存在しない
( env2 ) $ pip install - r requirements . txt # ファイルを使用してインストール
# ここで各パッケージがインストールされる
3-4 テストと品質
この節ではPythonでのテストについての解説を行いました。テストは大事ですが手で実行すると大変なので、ユニットテストコードを書きましょう、という話です。
最初にPythonにはdoctest というコメント(docstring)にテストを書く方法があります。次のコード例のように書くと、docstringがそのままサンプルコードになり、ユニットテストのコードにもなるため非常に便利です。
doctestのサンプル
# -*- coding: utf-8 -*-
def get_ok ():
"""
文字列 'OK' を返す
>>> get_ok()
'OK'
"""
return 'OK'
doctestは以下のように実行します。上記のコードをdoctest_sample.py
というファイルに保存します。なお、エラーが発生しない場合は何も出力されません。
doctestを実行
$ python - m doctest doctest_sample . py
$
doctestで複雑な単体テストコードを書こうとすると、コメントが長くなりすぎてわかりにくくなります。複雑な単体テストを行いたい場合はunittest を使用して、ユニットテストコードを書きましょう、という説明がありました。
3-5 Sphinx
Sphinx はreStructuredText という形式で作成したドキュメントを、HTML、PDF等に変換できるツールです。さきほど紹介したPython標準ライブラリーのドキュメントもSphinxで作成されています。
嶋田さんはsphinxcontrib-plantuml を使用してURLの図を作成しているそうです。しかし、複数の図があると1画像ごとにJavaのプロセスが起動するため、時間がかかるそうです。
Sphinxにはこのように拡張機能(directive)でさまざまな機能を拡張できます。sphinx-contrib に拡張機能がまとめてあるので参照してみてください。
「仕事でSphinxはどんなところで使っているか?」という質問がありました。最初にプロジェクトの要求リストをSphinxで書いて、コードの中にそのリストをコピーして実装を進めたりしていたそうです。ただ、途中からなし崩し的にうまくいかなくなり、ドキュメントとコードの同一性を保つのが難しいという話がありました。
また、嶋田さんは以前、Doxygen でコードを解析した結果のXMLを元にSphinxドキュメントを生成するdqn というツールを作っていたそうです。
3-6 PyCharm
この節ではPyCharm というPython用の統合開発環境(IDE)について解説しました。
PyCharmにはさまざまな機能がありますが、そのうちデバッグツールについては使いやすさ的にもうちょっと良くなるといい、というコメントがありました。ちなみに、PyCon APAC 2015ではPyCharmを作っているjetBrainsの人がPython Debugger Uncovered という発表をしていました。
また、Buildout という環境構築ツールがありますが、BuildoutとPyCharmを組み合わせてハマったことがあるそうです。
質疑応答では「実務上はCLIを使っているそうだが、PyCharmはどこで使っているのか?」という質問がありました。嶋田さんからの回答としては、新しく入ってきた人にはPyCharmの設定とかやデバッグの使い方を伝えている。チームで開発するときにはPyCharmがよさそう、とのことでした。
また「なにか実際に開発した例を教えてほしい」という質問があり、BattleHack Tokyo というイベントでスマホアプリのサーバ側をTornado Web Server で作成したそうです。Heroku上でサーバを動かし、Heroku賞をもらったそうです。すごいですね。作成したコードは以下に置いてあるそうです。
ビアバッシュ(懇親会)
読書会の終了後はビールとピザでビアバッシュという形式の懇親会を行いました。今回、実は筆者がネットでピザを注文したつもりが注文が完了しておらず、ギリギリのタイミングで再注文するというトラブルがありました。ピザが間に合ってよかったです。
一通りピザを食べ終わったら、ライトニングトーク(LT)大会になりました。今回は筆者を含めて3名が発表しました。
写真5 ビアバッシュ!!
LT1-業務のためのPython勉強会
阿久津(@akucchan_world )さんからは自身が主催している業務のためのPython勉強会 について紹介がありました。
写真6 LT1-業務のためのPython勉強会
この勉強会は阿久津さんがPythonスタートブック の著者の辻さんと知り合って立ち上げたもので、第1回は20名くらいの会場がいっぱいになったそうです。
第1回の勉強会の中で阿久津さんが発表した「私のPython独学奮闘記」をダイジェストで話してもらいました。以下の3種類のアプローチで学習を進めているという話でした。
初心者としてどのように勉強していったかなかなか興味深い発表でした。ぜひ、PyCon JPにもプロポーザルを出してほしいなと個人的に思いました。
第2回 は7月2日開催予定ですが、すでにキャンセル待ちで人気の勉強会のようです。第3回は8月開催予定とのことです。
LT2-slackpy
執筆者の一人の池内さん(@iktakahiro )からは最初に、業務で使っているチャットはなにか? という質問がありました。参加者からはSlack、HipChat、ChatWorkなどのツールの名前が挙がっていました。
写真7 LT2-slackpy
池内さんが作成しているslackpy というパッケージで、Slackに対して簡単にログメッセージを表示できることを紹介していました。
ログレベルを指定するとSlack上で色分けして表示されるため見た目にもわかりやすいです。
発表の後で「Pythonのloggingのhandlerにしてほしい」という提案がありました。次のバージョンアップに期待です。
LT3-Pythonエンジニア養成読本オモテウラ
最後は筆者のLTです。最初にPython関連イベント2つの告知をしました。どちらも参加者募集中、発表内容も募集中です。
LTではどのようにして本書が作られて行ったのかという話をしました。Googleスプレッドシートにレビューの指摘を書いてもらい、その対応状況をGoogle Apps ScriptでSlackチャットに投げたりといった工夫について紹介しました。
写真8 LT3-Pythonエンジニア養成読本オモテウラ
まとめ
2回目の読書会はビアバッシュでのライトニングトークも盛り上がりました。
次回は7月23日(木)に開催します。内容は「第4章 PyData入門」です。本書を読んで試して疑問がある方、もっとここが知りたい!! という所がある方など、ぜひ参加してください。参加申し込みは下記のURLからできます。
では、また来月もお会いしましょう。