<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>ja-Python on Junpei Kawamoto</title>
    <link>https://www.jkawamoto.info/tags/ja-python/</link>
    <description>Recent content in ja-Python on Junpei Kawamoto</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <managingEditor>junpei.kawamoto@acm.org (Junpei Kawamoto)</managingEditor>
    <webMaster>junpei.kawamoto@acm.org (Junpei Kawamoto)</webMaster>
    <copyright>&amp;copy; 2016-2017 Junpei Kawamoto</copyright>
    <lastBuildDate>Fri, 27 Jan 2017 00:00:00 +0000</lastBuildDate>
    
	<atom:link href="https://www.jkawamoto.info/tags/ja-python/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>PyPIに登録するパッケージの説明文を半自動生成する</title>
      <link>https://www.jkawamoto.info/blog-ja/generate-readme-for-pypi/</link>
      <pubDate>Fri, 27 Jan 2017 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/generate-readme-for-pypi/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 PyPI にパッケージを登録するとき，特に指定しなければ説明文として README.md が使用される． しかし， Markdown 形式ではレンダリングされないため下記のように醜い文章が表示されることになる．

この説明文は，reStructuredText 形式ならばレンダリングされる． そこで，README.md から README.rst を生成し，説明文として設定する方法を備忘録として記す．
Markdown から reStructuredText への変換 GitHub 等でコードベースを管理しているならば，README.md は用意されていると考えられるので， この Markdown テキストを reStructuredText 形式へ変換する．
変換には，Pandoc を使う．
$ pandoc --from markdown --to rst README.md -o README.rst  なお，Pandoc は brew でインストールできる．
$ brew install pandoc  パッケージ情報への登録 README.md と README.rst が両方ともパッケージに含まれている場合， README.md の方が優先されてしまうので， setup.py で README.rst を説明文として使用するように設定する．
具体的には，setup 関数の long_description キーワード引数に README.</description>
    </item>
    
    <item>
      <title>PyPIに登録するパッケージバージョンをGitから取得する</title>
      <link>https://www.jkawamoto.info/blog-ja/determine-package-version-from-git-tags/</link>
      <pubDate>Fri, 27 Jan 2017 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/determine-package-version-from-git-tags/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 PyPI にパッケージを登録する場合，setup.py で呼び出す setup 関数に version 引数を渡す必要がある． このバージョン情報を今までは手作業で編集していたのだが，Gitのタグから引っ張ってこれたので備忘録として記しておく．
setuptools_scm setuptools_scm はバージョン管理システムから適当に情報を引っ張ってきて，setup.py を設定してくれるライブラリである． これを使えば，タグ情報を元にバージョン番号を算出し設定できる． また，トラッキングされているパッケージデータを自動的にパッケージへ追加する機能もある．
setuptools_scm を使用してバージョン番号を設定する場合， setup.py の setup 関数に次のようなパラメータを渡す．
from setuptools import setup setup( use_scm_version=True, setup_requires=[ &amp;quot;setuptools_scm&amp;quot; ], ... # 他の項目は省略 )  これで，python setup.py sdistとする時に適切にバージョン番号が計算される． バージョン番号の計算方法は次のルールに従っている．
 最新コミットにバージョンタグが付いており，更新されたファイルがない場合: そのバージョンタグ 最新コミットにバージョンタグが付いており，更新されたファイルがある場合: バージョンタグ＋現在の日付 バージョンタグ付きコミット以降にコミットがあり，更新されたファイルがない場合: 次のバージョン.dev(何コミット離れているか)+n(ハッシュ) バージョンタグ付きコミット以降にコミットがあり，更新されたファイルがある場合: 次のバージョン.dev(何コミット離れているか)+n(ハッシュ).日付  より詳しい情報はマニュアルを参照のこと．
パッケージデータの追加 トラッキングされているパッケージデータを自動で追加する場合， setup 関数に include_package_data=True を追加する． つまり，
from setuptools import setup setup( use_scm_version=True, include_package_data=True, setup_requires=[ &amp;quot;setuptools_scm&amp;quot; ], .</description>
    </item>
    
    <item>
      <title>pip install中に他所からデータファイルを取得する</title>
      <link>https://www.jkawamoto.info/blog-ja/download-data-files-during-pip-installation/</link>
      <pubDate>Wed, 25 Jan 2017 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/download-data-files-during-pip-installation/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 そんなことをしても良いのか分からないが，パッケージに必要なデータを PyPI サーバ以外から取得してインストールしたい． setup.pyに記載できるデータファイル関連の引数，package_data と data_files はどちらもソースコードと共に配布される ファイルしか対応していないと思われる． そこで，pip install中に呼び出される install_data コマンドをフックして，必要なファイルを別途ダウンロードするようにした．
コマンドのフック コマンドのフックというか置き換えは，setuptools.setup関数にキーワード引数 cmdclass として， 置き換えるコマンド名をキーに，実装を値にした辞書を渡すことで行える．(参考: 新しいコマンドの統合)
今回置き換える install_data コマンドの本来のソースは，ここにあるので， 参考にしながらカスタムの install_data コマンドを作成した．
import distutils.command.install_data from os import path import site import sys import urllib class CustomInstallData(distutils.command.install_data.install_data): def run(self): # self.data_files に setup 関数の data_files 引数に渡した値が入る． # これは，(データファイルの保存先，データファイルパスのリスト) タプルのリスト担っているので，個別に処理する． for f in self.data_files: if not isinstance(f, tuple): continue for i, u in enumerate(f[1]): # データファイルのパスが URL でなければ何もしない． if not u.</description>
    </item>
    
    <item>
      <title>レビューグラフ解析アルゴリズム評価用のTripAdvisorデータセット</title>
      <link>https://www.jkawamoto.info/blog-ja/rgmining-tripadvisor/</link>
      <pubDate>Wed, 25 Jan 2017 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/rgmining-tripadvisor/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 
スパムレビュア発見アルゴリズムの評価用データセットに加えて， イリノイ大学で公開されている TripAdvisor データセットを読み込むパッケージを作成しました．
インストール パッケージは PyPI に登録してあるので，次のコマンドでインストールできます．
$ pip install --upgrade rgmining-tripadvisor-dataset  なお，このインストール中に元データ配布先からファイルをダウンロードするので， ある程度の時間を要します．（参考: pip install中に他所からデータファイルを取得する）
グラフデータの読み込み rgmining-tripadvisor-datasetには tripadvosirモジュールが含まれており， load関数をエクスポートしています． この関数はレビューグラフオブジェクトを受け取り， TripAdvisor データセットのレビューデータを追加します．
このグラフオブジェクトは， グラフインターフェイス を実装し次のメソッドを持っている必要があります．
 new_reviewer(name): name という名前を持つレビュアーオブジェクトを作成して返す． new_product(name): name という名前を持つ商品オブジェクトを作成して返す． add_review(reviewer, product, rating, date): date に投稿された reviewer による product へのスコアが rating であるレビューを追加する．なお rating は 0 以上 1 以下に正規化されているものとする．  先日紹介した，Fraud Eagle, FRAUDAR は共にこのグラフインターフェイスを実装しているので， TripAdvisor データセットを読み込むことができます．
Fraud Eagle で解析する場合(事前に pip install --upgrade rgmining-fraud-eagle が必要)，</description>
    </item>
    
    <item>
      <title>カモフラージュするスパムレビュアの発見アルゴリズム</title>
      <link>https://www.jkawamoto.info/blog-ja/rgmining-fraudar/</link>
      <pubDate>Tue, 17 Jan 2017 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/rgmining-fraudar/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 
結託したスパムレビュアを発見するアルゴリズムに引き続き， オンラインショッピングやレストランレビューサイトにおいてスパムレビュアーを発見するために， 通常のレビュアーにカモフラージュするようなスパムレビュアを発見するアルゴリズム FRAUDAR を用意した．
FRAUDAR は 2016年の ACM SIGKDD International Conference on Knowledge Discovery and Data Mining (KDD 2016) でベストペーパー賞を受賞したアルゴリズムで， 著者らによって実装が公開されている．
今回は， スパムレビュア発見アルゴリズムの評価用データセットなどをより簡単に解析できるように 結託したスパムレビュアを発見するアルゴリズムと共通の インターフェイスを作成した．
使い方 今回作成した，FRAUDARのラッパー rgmining-fraudar は PyPI に登録してあるので，pip コマンドにてインストールできる．
$ pip install --upgrade rgmining-fraudar  fraudar というパッケージが追加され，その中の fraudar.ReviewGraph がこのアルゴリズムを実装するグラフクラスである． ReviewGraph クラスのコンストラクタは，オプションで何種類のカモフラージュパターンを考えるかというパラメータと，内部で使うサブアルゴリズムを受け取るが，前者のみデータセットに合わせて与えれば良いと思う（両方デフォルトでも問題ない）．
import fraudar # 例えば 10パタンのカモフラージュを考える場合． n = 10 graph = fraudar.ReviewGraph(n)  そして，グラフにレビュア，商品，そしてレビューを追加する． 結託したスパムレビュアを発見するアルゴリズムの例と同じ方法で追加できる．
reviewers = [graph.</description>
    </item>
    
    <item>
      <title>Travis でのテストを事前にローカルで試す</title>
      <link>https://www.jkawamoto.info/blog-ja/test-remote-ci-scripts-locally/</link>
      <pubDate>Sat, 07 Jan 2017 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/test-remote-ci-scripts-locally/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 

GitHub などでホストしているプロジェクトのテストに，Travis CI などのクラウド CI サービスを利用するケースは多いだろう．
基本的に，ローカルの開発環境でテストに通ったことを確認してから，コミット，プッシュを行うはずなので，Travis 上でもテストはパスするはずである．しかし，Travis の設定ファイルである.travis.ymlのミスや，依存ライブラリの追加忘れなどのうっかりで時々テストが失敗する．特に依存ライブラリの場合，開発環境ではたまたまインストールされていると，ローカルでのテストはパスしてしまうため，見落とすことがある．
テストが失敗すると，ローカル環境で修正の後，再プッシュとなりリモートブランチのコミット履歴が汚れて行くので，ミスはできるだけ避けるべきである（特に，他人のリポジトリでやらかすと気まずい）．そこで，Python または Go 言語のプロジェクト用に，Docker を使ってローカルにまっさらな環境を用意し，.travis.ymlに記載された通りにテストを実行するツール，Loci を作成した．
インストール まず，Docker が必要になるので，あらかじめインストールしておく（Docker の導入方法については割愛する）．
Loci のインストールは，Go がインストールされている環境ならば，
$ go get github.com/jkawamoto/loci  Homebrew がインストールされている環境ならば，
$ brew tap jkawamoto/loci $ brew install loci  にて行える．それ以外の場合は，GitHubにコンパイル済みのバイナリがあるので，ダウンロードしてパスの通ったところへ置けば良い．
使い方 カレントディレクトリに，.travis.yml がある場合，loci コマンドを実行するだけで良い．別ファイルをテストする場合は，loci &amp;lt;filepath&amp;gt;とファイルパスを渡す．
Loci はカレントディレクトリ以下に含まれるファイルを持ち，.travis.yml に記載されたパッケージをインストールしたコンテナイメージを作成する．元になるイメージは ubuntu:latest である．初回実行時は，パッケージのインストールなどである程度の時間を要するが，2回目以降は，依存パッケージに変更がなければ，過去のコンテナイメージを適宜再利用する（Dockerの機能）．
もし自前で， APT キャッシュサーバや PyPI キャッシュサーバを用意している場合，--apt-proxy や --pypi-proxy フラッグを使うことで，それらを利用するようになる．（参考: QNAP に Apt キャッシュサーバを建てる, QNAP に Pypi キャッシュサーバを建てる）</description>
    </item>
    
    <item>
      <title>GitHub のリポジトリを requirements.txt に含める</title>
      <link>https://www.jkawamoto.info/blog-ja/include-github-repositories-to-requirements-txt/</link>
      <pubDate>Wed, 19 Oct 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/include-github-repositories-to-requirements-txt/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 
PyPI には登録されていないが，GitHub では公開されているライブラリを依存関係に含める方法． また，setup.py から requirements.txt を参照している場合の対応方法について忘備録としてまとめる．
requirements.txt GitHub リポジトリの URL が https://github.com/rgmining/common の場合， requirements.txt には，
-e git+https://github.com/rgmining/common.git#egg=rgmining_common-0.9.0  のように書く．#egg= 以降は &amp;lt;パッケージ名&amp;gt;-&amp;lt;バージョン&amp;gt; という書式にするようだ． また，pip-tools を使って requirements.txt を生成している場合， requirements.in には上記と同じ文字列を記入する．
setup.py 今まで，setup.py では下記のようにrequirements.txtの内容をinstall_requiresに渡していた．
from setuptools import setup, find_packages def load_requires_from_file(filepath): with open(filepath) as fp: return [pkg_name.strip() for pkg_name in fp.readlines()] setup( # その他の項目は省略 install_requires=load_requires_from_file(&amp;quot;requirements.txt&amp;quot;) )  requirements.txtにURLが含まれている場合は，もう少し改良してパッケージ名だけをリストアップする．
def take_package_name(name): if name.startswith(&amp;quot;-e&amp;quot;): return name[name.</description>
    </item>
    
    <item>
      <title>スパムレビュア発見アルゴリズムの評価用データセット</title>
      <link>https://www.jkawamoto.info/blog-ja/rgmining-synthetic/</link>
      <pubDate>Wed, 12 Oct 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/rgmining-synthetic/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 
スパムレビュア発見アルゴリズムの評価用に， 論文 A Bipartite Graph Model and Mutually Reinforcing Analysis for Review Sites にて作成した 人工データを公開しました．本記事では使い方をまとめます． また，Google Cloud Platform を使った並列評価についてもまとめます．
インストール パッケージは PyPI に登録してあるので，pip コマンドでインストールできます．
$ pip install --upgrade rgmining-synthetic-dataset  人工グラフデータの読み込み rgmining-synthetic-datasetには，syntheticパッケージが含まれており， synthetic.load関数とsynthetic.ANOMALOUS_REVIEWER_SIZE定数をエクスポートします． synthetic.load関数は人工レビューグラフデータの読み込みを行い， synthetic.ANOMALOUS_REVIEWER_SIZE定数はこのデータセットに含まれている 特異なスパムレビュアの人数（５７）を表しています． 特異なスパムレビュアは，その名前に anomaly が含まれています． よって，このデータセットを使った評価では， ５７人のスパムレビュアをどれだけの精度・再現率で発見できるのか？を調べます．
なお人工データがどのようにして作られたのか，については割愛します． 興味のある方は元論文を参照してください．（いつか別記事でまとめるかも知れません）
synthetic.load関数は，引数としてグラフオブジェクトを受け取ります． このグラフオブジェクトは，
 new_reviewer(name): nameという名前を持つレビュアーオブジェクトを作成して返す． new_product(name): name という名前を持つ商品オブジェクトを作成して返す． add_review(reviewer, product, rating): reviewerによるproductへのスコアがratingであるレビューを追加する．なお．ratingは 0 以上 1 以下に正規化されているものとする．  という三つのメソッドを持っている必要があります．</description>
    </item>
    
    <item>
      <title>結託したスパムレビュアを発見するアルゴリズム</title>
      <link>https://www.jkawamoto.info/blog-ja/rgmining-fraud-eagle/</link>
      <pubDate>Wed, 05 Oct 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/rgmining-fraud-eagle/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 はじめに 
オンラインショッピングやレストランレビューサイトにおいて， 結託してレビュー結果が不当に高くまたは低くなるようにダミーレビューを投稿する スパムレビュアーを発見したい．
今回は，2013年に AAAI Conference on Weblogs and Social Media という国際会議で発表された，Fraud Eagle アルゴリズムを実装した．
レビューデータ Fraud Eagle では下の図のようなレビューグラフを考える．

つまり，レビューを投稿した人（レビュア）とレビューの投稿先（商品）をそれぞれ頂点とし， レビュー関係を枝で表す．レビュー自体は文章でも星何個でも良いが， そのレビューがポジティブなのかネガティブなのか判断できる必要がある． 今回は，レビューは 0 から 1 までの間の数値を取ることにし，0.5 以上ならばポジティブ， そうでなければネガティブと判断することにした．
使い方 今回作成した rgmining-fraud-eagle は PyPI からインストールできる．
pip install --upgrade rgmining-fraud-eagle  fraud_eagle というパッケージがインストールされるので， その中からReviewGraph クラスのインスタンスを作成する． なお，Fraud Eagle は 0 より大きく 0.5 未満ののパラメータを一つとる． パラメータはデータセットによって最適値が変わるが，今回は中央 0.25 を設定してみる．
import fraud_eagle as feagle graph = feagle.ReviewGraph(0.25)  次に，グラフにレビュア，商品，そしてレビューを追加する． 上記図の通りのグラフを作成する場合，</description>
    </item>
    
    <item>
      <title>SphinxドキュメントからGitHubへリンクする</title>
      <link>https://www.jkawamoto.info/blog-ja/link-github-from-sphinx-doc/</link>
      <pubDate>Sun, 14 Aug 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/link-github-from-sphinx-doc/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 Sphinx テンプレートの一つ sphinx_rtd_theme では， メタデータ :github_url: に URL を渡すことで，Edit on GitHub のリンクを生成してくれる．
ではそのメタデータはどこで定義するのか？という話．
メタデータの定義 Sphinx におけるメタデータは二種類ある．一つは今回必要なテンプレートの処理に使うメタデータであり， もう一つは HTML の meta タグを出力するためのものである．
前者は，.rst ファイルの先頭付近（A field list near the top of a file）に置く必要がある． 曖昧な表現だが，要するに他のマークアップより前に書いておけば良い．
:github_url: https://github.com/jkawamoto/roadie-gcp .. ここから本文を始める  などとすれば良い．
ちなみに，後者の方は .. meta:: で始まるセクションに記述する．
.. meta:: :viewport: width=device-width  メタデータの一括登録 上記の通り，各 .rst ファイルの先頭に :github_url:メタデータを追加すれば， 生成されたドキュメントには GitHub へのリンクが付く． しかし，一々記述するのは手間なので，rst_prolog オプションを使って一括登録する．
conf.py に rst_prolog 変数を定義すると，その内容を各 .rst ファイルの先頭に追加してくれる． よって，</description>
    </item>
    
    <item>
      <title>Mac に numba をインストール</title>
      <link>https://www.jkawamoto.info/blog-ja/install-numba-to-mac/</link>
      <pubDate>Fri, 29 Jul 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/install-numba-to-mac/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 
お手軽に python コードを高速化するために，numba を導入してみた． しかし，pip だけではインストールできなかったので，備忘録としてインストール手順を記録しておく．
インストール llvm と enum34 が別途必要らしい． 特に，llvm は最新の 3.8.x ではなく 3.7.x が要るようなので， homebrew/versions を tap してインストールする． また，環境変数 LLVM_CONFIG の設定を忘れないようにする．
$ brew tap homebrew/versions $ brew install homebrew/versions/llvm37 $ export LLVM_CONFIG=/usr/local/Cellar/llvm37/3.7.1/bin/llvm-config-3.7 $ pip install enum34 $ pip install numba  インポート numba がインストールされていない環境でも動くように， インポートできなかった場合は何もしないデコレータに差し替えておく．
try: from numba import jit except ImportError: def jit(*args, **_kwargs): if len(args) &amp;gt; 0 and hasattr(args[0], &amp;quot;__call__&amp;quot;): return args[0] else: def _(func): return func return _  @jit 以外も使う場合は同様のものをそれぞれ定義する． また，この場合型指定はオブジェクトではなく文字列で渡す必要がある．</description>
    </item>
    
    <item>
      <title>QNAP に Pypi キャッシュサーバを建てる</title>
      <link>https://www.jkawamoto.info/blog-ja/pypi-cache-server-on-qnap/</link>
      <pubDate>Wed, 27 Jul 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/pypi-cache-server-on-qnap/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 はじめに QNAP に Apt キャッシュサーバを建てるに続き， QNAP の NAS に Docker コンテナとして Pypi キャッシュサーバを建てる． LAN 内での pip の高速化とトラフィック削減を目指す．
Pypi キャッシュサーバ Pipit のキャッシュサーバとして，devpi server を用いる．Docker で運用するので，devpi のイメージを探す． 例えば，scrapinghub/docker-devpi などが見つかった．
前回 にも述べた通り，手元の NAS は ARM ベースであった． そのため，別途 ARM 用 devpi イメージを作成した． 作成したイメージの Dockerfile は，GitHub に，イメージは DockerHub に置いてある．
devpi server コンテナの起動 コンテナの管理には，Container Stationを利用する． もしなければ，App Center からインストールする．Container Station のマニュアルは ここ から参照できる．

コンテナの作成タブから，利用するコンテナイメージを検索する． デフォルトでは DockerHub にあるイメージを利用できる．

目的のイメージが見つかったらインストールする．</description>
    </item>
    
    <item>
      <title>Pythonモジュールの関係図を作る</title>
      <link>https://www.jkawamoto.info/blog-ja/relationship-graph-of-python-modules/</link>
      <pubDate>Sun, 24 Jul 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/relationship-graph-of-python-modules/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 はじめに リファクタリングのために，モジュール間の関係図を作る． Pythonでモジュールの依存関係図を描きたいとかPython dependencies inside a package によると， snakefood が良さそうだったので使ってみた．
snakefood pip でインストール可能．
$ pip install snakefood  いくつかのコマンドが提供されているが， sfood で解析し，stood-graph で Graphviz 用の dot ファイルを書き出せる．
解析したいパッケージのルートが ROOT だとすると，
$ sfood ROOT | sfood-graph &amp;gt; graph.dot  で graph.dot ができるので，後は適当にプロットする．
$ dot -Tjpg graph.dot -o graph.jpg -Gdpi=800  モジュールが多い場合解像度(-Gdpiオプションの値)は大きめに設定しないと潰れて読めなくなる． jpg 以外で出力する場合は，-Tpng などとすれば良い．
なお，sfood に -i オプションをつけると，外部パッケージは省くことができる．
サンプル 参考までに，selenium で試した結果を掲載しておく．

その他 pyreverseの結果の見方とオプションの使い方 によるとpyreverse というツールでもいけるみたい．</description>
    </item>
    
    <item>
      <title>Sphinx のセットアップまとめ</title>
      <link>https://www.jkawamoto.info/blog-ja/sphinx-setup/</link>
      <pubDate>Wed, 13 Jul 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/sphinx-setup/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 Python パッケージのドキュメント作成には Sphinx が便利．sphinx-apidoc, autodoc を使えば，docstrings から API リファレンスを自動で作成してくれる．これらを使う時，いつもだいたい同じセットアップが必要なので，備忘録としてまとめておく．
前準備 sphinx のインストールとドキュメント用ディレクトリの作成．
$ pip install sphinx $ mkdir docs $ cd docs  その結果，次のようなディレクトリ構成になっているとする．
. ├── README.md ├── docs ├── &amp;lt;your package&amp;gt; └── tests └── テストたち  sphinx-quickstart 基本的にはデフォルトで，次の項目だけ設定する．
 source と build は分ける autodoc: automatically insert docstrings from modules は yes mathjax は必要に応じて yes viewcode も必要に応じて yes  sphinx-apidoc の設定 Makefile を編集して，ドキュメントのコンパイル時に sphinx-apidoc を呼ぶようにする．</description>
    </item>
    
    <item>
      <title>docstrings から argparse を補完する</title>
      <link>https://www.jkawamoto.info/blog-ja/dsargparse/</link>
      <pubDate>Fri, 08 Jul 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/dsargparse/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 はじめに python でコマンドラインツールを作る場合，引数のパーサーには click が便利． しかし，複雑なことをやろうとすると argparse の方が簡単な気がして使い分けている． 一方で，argparse を使うと description や help をサブコマンドや引数に与える必要がある． これらは，大体の場合 docstring と情報が重複していて二度手間である． そこで，docstring を使って argparse に情報を渡す方法を考えてみる．
なお，docstrings は Googleのスタイルガイドに従って書かれているとする．
プログラム全体の description コマンド本体の説明，つまり argparse.ArgumentParser の description 引数． これは main 関数のあるモジュールの docstring に書かれているはずである． よって，ArgumentParser の作成は，
parser = argparse.ArgumentParser( description=__doc__, formatter_class=argparse.RawTextHelpFormatter)  とすれば良さそうである． なお，formatter_class に argparse.RawTextHelpFormatter を渡しているのは， これ以降設定する description や help から改行や空白を削除されるのを防ぐためである．
サブコマンドの description サブコマンドは,それを実行する関数とセットになっていると仮定する． つまり最低限，
a1_cmd = subparsers.add_parser(&amp;quot;a1&amp;quot;) a1_cmd.set_defaults(cmd=a1)  となっていると思う．であれば，サブコマンドを実装する関数，ここでは a1 が与えられれば，</description>
    </item>
    
    <item>
      <title>データ解析のための統計モデリング入門 第10章 を PyMC で解く</title>
      <link>https://www.jkawamoto.info/blog-ja/pymc-lesson-10/</link>
      <pubDate>Tue, 24 May 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/pymc-lesson-10/</guid>
      <description>  参考書籍  </description>
    </item>
    
    <item>
      <title>Travis CI に CVXOPT, NumPy, SciPy をインストールする</title>
      <link>https://www.jkawamoto.info/blog-ja/install-cvxopt-numpy-scipy-to-travis/</link>
      <pubDate>Thu, 24 Mar 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/install-cvxopt-numpy-scipy-to-travis/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 Travis CI で CVXOPT, NumPy, SciPy を使った Python プログラムをテストしたい． これらのライブラリは pip だけではインストールできなかったので，他に必要なパッケージをまとめる．
CVXOPTがSuiteSparseの同梱を辞めたことによる修正（2017年2月5日）
前提 テストの実行に必要なライブラリは requirements.txt に書かれているものとする． この時，Travisは自動で pip install -r requirements.txt してくれるので， install ステップは不要．
.travis.yml まとめると，CVXOPT のインストールに libblas-dev と liblapack-dev が， SciPy のインストールに gfortran が必要なので，.travis.yml の addons.apt.packages を使って用意しておく．
また，CVXOPTがSuiteSparseの同梱を辞めたため，自前で用意しておく必要がある． この手続きは before_install に記述する．
language: python python: - 2.7 addons: apt: packages: - libblas-dev - liblapack-dev - gfortran before_install: - wget http://faculty.cse.tamu.edu/davis/SuiteSparse/SuiteSparse-4.5.3.tar.gz - tar -xf SuiteSparse-4.</description>
    </item>
    
    <item>
      <title>64bit Anaconda に cvxopt をインストールする</title>
      <link>https://www.jkawamoto.info/blog-ja/install-cvxopt-in-anaconda/</link>
      <pubDate>Fri, 26 Feb 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/install-cvxopt-in-anaconda/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 Windowsで 64bit版 の Anaconda に cvxopt をインストールしようと思ったら非常に苦労したので作業内容をまとめる．
cvxopt のドキュメントには Windows へのインストール方法が書かれている． しかし，32bit 版の Python を想定しているらしく，ドキュメント通りにすんなりとインストールは出来ないので注意．本稿は，このドキュメントに沿って変更すべき点をまとめる．
想定環境  Windows 10 (64bit) Anaconda for 64bit Windows (Python2.7) MinGW (64bit)  これらは既にインストールされているものとする．
なお，以降の作業は専用のディレクトリを作って，その中で行うものとする．例として D:\glpk 内で行う場合は，次のようにすればコマンドプロンプトを開くことができる． 依存ライブラリの準備 これは ドキュメント 通りで良い．
BLAS BLAS のソースファイル をダウンロードする．そして，コマンドプロンプトから次のコマンドを実行する．
$ tar -xvf blas.tgz $ cd BLAS-3.5.0 $ sed &#39;s/_LINUX/_WIN/&#39; make.inc -i $ make &amp;amp;&amp;amp; cp blas_WIN.a ../libblas.a $ cd ..  ただし，2行目のディレクトリ名は取得した BLAS ソースファイルのバージョンによって変わるので適宜読み替える．</description>
    </item>
    
    <item>
      <title>コンテナにインストールする python パッケージの管理</title>
      <link>https://www.jkawamoto.info/blog-ja/python-package-management-for-containers/</link>
      <pubDate>Wed, 24 Feb 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/python-package-management-for-containers/</guid>
      <description>  本稿は Qiita 投稿記事 のバックアップです．
 概要 プログラムの実行に必要な python パッケージを Dockerfile に直接記述していたので，requirements を用いて一元管理する．
pip-tools で requirements の管理 requirements.in に必要なパッケージを記入する．
webapp2 paste webob  Dockerfile に pip-tools のインストールと，requirements.in の追加，パッケージのインストールに関する項目を追加する．
RUN apt-get update &amp;amp;&amp;amp; apt-get install -y python-pip RUN pip install -U pip pip-tools ADD ./requirements.in ./ RUN pip-compile &amp;amp;&amp;amp; \ pip install -r requirements.txt &amp;amp;&amp;amp; \ rm requirements.txt  参考  pip-toolsでrequirements.txtのパッケージバージョン番号を管理しよう  </description>
    </item>
    
    <item>
      <title>insecure string pickle を読み込む</title>
      <link>https://www.jkawamoto.info/blog-ja/read-insecure-string-pickle/</link>
      <pubDate>Thu, 18 Jun 2015 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/read-insecure-string-pickle/</guid>
      <description>  本稿は Qiita 投稿記事 のバックアップです．
 概要 バージョン 0 の pickle プロトコルは ASCII 表現でデータ直列化する．このテキストファイルを別のプラットフォームで利用する場合や，テキストモードでファイル転送する時にうっかり改行コードが書き変わるなどすると，insecure string pickle エラーが出て読み込めなくなることがある．
そんな時は，自前でファイルから読んで文字列を作成してから読み込めば良い．
ソースコード import pickle with open(inputfile, &amp;quot;r&amp;quot;) as fin: data = pickle.loads(&amp;quot;\n&amp;quot;.join([line.strip() for line in fin]))  参考  11.1. pickle — Python オブジェクトの整列化 - Python 2.7ja1 documentation  </description>
    </item>
    
    <item>
      <title>Python から I2C 接続のディスプレイを操作する</title>
      <link>https://www.jkawamoto.info/blog-ja/use-i2c-displayes-from-python/</link>
      <pubDate>Wed, 31 Dec 2014 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/use-i2c-displayes-from-python/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 RaspberryPi に I2C 経由で繋いだ LCD を Python から操作する． 今回は，HD44780 に SpikenzieLabs の MPTH を付けた LCD を使用する．
準備 RaspberryPi 側で I2C を利用する準備が必要． 先ずは，/etc/modules に次の2行を追加する．
i2c-bcm2708 i2c-dev  次に，/etc/modprobe.d/raspi-blacklist.conf から次の行を削除 / コメントアウトする．
blacklist i2c-bcm2708  一旦再起動し，その後 i2c-tools と python-smbus をインストールする．
sudo apt-get install i2c-tools python-smbus  I2C バス番号とデバイスアドレスの取得 始めに，使用する LCD のバス番号とアドレスを取得する． sudo i2cdetect 0 と sudo i2cdetect 1 を実行し， エラーの出ない方がバス番号（0 か 1）であり，出力からアドレスを取得する． 例えば，出力が次のような場合，0x20 がアドレスである．</description>
    </item>
    
    <item>
      <title>Pythonモジュールのインポート</title>
      <link>https://www.jkawamoto.info/blog-ja/importing-python-modules/</link>
      <pubDate>Wed, 24 Dec 2014 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/importing-python-modules/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 目的 いくつかのモジュールからなるパッケージを作成した場合、インポート時にフォルダ名(パッケージ名)、 ファイル名(モジュール名)、インポートする関数やクラス名を書く必要があり import 文が長くなる。 これらを短くしたい。もしくは、モジュールを跨いでデフォルト設定でインポートしたい。
Python におけるインポートの仕様 ここ によると、 &amp;gt; import されたモジュール名は import を行っているモジュールのグローバルなシンボルテーブルに置かれます。import 文には、あるモジュール内の名前を、import を実行 しているモジュールのシンボルテーブル内に直接取り込むという変型が あります。(from..import..)
とのことなので、__init__.py で import を行うと，パッケージを import するだけで，__init__.py 内で import したシンボルを利用できる．
例えば，
/foo - __init__.py - bar.py  というフォルダ構成で、
$ cat bar.py PIYO=100 $ cat __init__.py from bar import PIYO  とした場合、import foo で，foo.PIYO が利用できる．これを使えばモジュール内での複雑な実装を隠してライブラリを提供できる。</description>
    </item>
    
    <item>
      <title>Requests で Docker Remote API にアクセスする</title>
      <link>https://www.jkawamoto.info/blog-ja/docker-remote-api-from-requests/</link>
      <pubDate>Fri, 12 Dec 2014 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/docker-remote-api-from-requests/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 Python Requests から Docker Remote API を利用したい． 暗号化を行えば TCP からでも利用できるが，API を同じホストから利用することを考えているため unix ソケットを使う．
Unix ソケットの読み書き Docker のソケットファイルは /var/run/docker.sock にある．ソケットファイルの読み書きは，次の通り．
import socket s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) s.connect(&amp;quot;/var/run/docker.sock&amp;quot;) # s.recv, s.send, etc.  Requests で独自ソケットを使う こちらはかなり面倒で，Transport Adapterを実装する必要がある．そして，そのためには，PoolManager，HTTPConnectionPool，HTTPConnection も合わせて実装する必要がある．
import socket import requests from requests.adapters import HTTPAdapter from requests.packages.urllib3 import PoolManager, HTTPConnectionPool from httplib import HTTPConnection class MyAdapter(HTTPAdapter): def __init__(self, sockfile, **kwargs): self._sockfile = sockfile super(MyAdapter, self).</description>
    </item>
    
    <item>
      <title>Compute Engine インスタンスから Cloud Storage にアクセスする</title>
      <link>https://www.jkawamoto.info/blog-ja/use-cloud-storage-from-compute-engine/</link>
      <pubDate>Wed, 10 Dec 2014 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/use-cloud-storage-from-compute-engine/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 はじめに GCE インスタンスから Cloud Storage にアクセスしたい．プロジェクト内部からのアクセスなので OAuth 2.0 を直接用いた方法 より簡単なサービスアカウントを用いる．
認証 始めに，メタデータサーバからアクセストークンを取得する．
import json import urllib2 METADATA_SERVER = &amp;quot;http://169.254.169.254/computeMetadata/v1/instance/service-accounts&amp;quot; SERVICE_ACCOUNT = &amp;quot;default&amp;quot; req = urllib2.Request(&amp;quot;{0}/{1}/token&amp;quot;.format(METADATA_SERVER, SERVICE_ACCOUNT)) req.add_header(&amp;quot;Metadata-Flavor&amp;quot;, &amp;quot;Google&amp;quot;) data = json.load(urllib2.urlopen(req)) token = data[&amp;quot;access_token&amp;quot;] token_type = data[&amp;quot;token_type&amp;quot;]  トークンを用いたアクセス Cloud Storage へのアクセスは受け取ったトークンを使う．
オブジェクトの取得 from apiclient import discovery sp = discovery.build(&amp;quot;storage&amp;quot;, &amp;quot;v1&amp;quot;) req = sp.objects().get_media(bucket=&amp;lt;BUCKET&amp;gt;, object=&amp;lt;PATH&amp;gt;) req.headers[&amp;quot;Authorization&amp;quot;] = &amp;quot;{0} {1}&amp;quot;.format(token_type, token) res = req.execute()  サンプルコードでは oauth2_client.</description>
    </item>
    
  </channel>
</rss>