はてなブックマーク

Github Pages にSphinxで生成したドキュメントを公開するほうほうです。 Github Pages では各リポジトリごとにプロジェクトページを作成することができます。 各プロジェクトごとにページを作成することでマニュアルなどの公開が便利にできます。 Sphinx で生成したドキュメントをそのまま公開すると、スタイルシートなど静的ファイルへのリンクが切れてしまいます。 静的ファイルは、ルートからのパスを想定しているためです。 html 生成時にリンクを修正してくれるプラグインが公開されています。 sphinxtogithub を利用すると、 Github Pages 用のリンクに修正してくれます。 利用方法 1. sphinxtogithub をインストールする。 $ easy_install -ZU sphinxtogithub2. conf.py で、プラグインを有効にする

はじめに 最近、dotcloud のアカウントを入手したので、Flaskアプリをデプロイしてみました。 dotcloud の最初の手順は、id:ymotongpoo の記事がわかりやすいです。 アプリケーションをデプロイする Flask アプリケーションをデプロイしてみます。 ディレクトリ構成は次のようにしました。 $ tree www/ www/ ├── hello │%% ├── hello.py │%% └── hello.pyc ├── requirements.txt └── wsgi.py dotcloud 用に wsgi.py を用意します。 http://flask.pocoo.org/snippets/46/ wsgi.py (公式にあるスニペットをアプリケーションパスだけ修正して使います。) import sys sys.path.append('hello') fro

はじめに リポジトリを共有モードにするのを忘れていてトラブったので、解決した際の方法を紹介します。 今回は、 ssh経由でアクセスことが前提です。 http/https を利用する場合は別途手順がありますので、機会があれば後日紹介します。 解決方法 まず、 Git リポジトリをチームで共有する際には、 --shared オプションを付与し、リポジトリを初期化します。次に、チームのメンバーの umask を 002 もしくは 007 に変更します。 手順さえ間違えなければ、リポジトリの共有は簡単です。 --shared を忘れた場合はどうなるのかというと、正しく共有できる状態となっていないため、Permission denied が発生します。 この状態は、次の手順で解消できます。 $ cd /your/git/repository $ git config core.sharedRepos

はじめに nose のプラグインの作成方法です。 役割 テスト関数から外れた処理をする場合は、プラグインを作成する必要があります。 たとえば、次のような場合にプラグインを作成します。 各テスト実行後に特定処理を実行させたいが、テスト関数ごとに teardown を書くのがめんどくさい。 レポートの出力形式を独自のものにしたい。 書き方 nose.plugins.Plugin を継承したクラスを作成します。 必要なことは、 name を指定すること、プラグインを動作させたいエントリポイントをオーバーライドすることです。 name は、実行時にプラグインを指定するときに使用します。 エントリポイントは、プラグインの動作を定義します。 from nose.plugins import Plugin class AfterLog(Plugin): """テスト実行ごとに、ログを出力させます。 ""

はじめに nose には、簡単にテストするための機能が用意されています。 機能は、 nose.tools パッケージにまとまっています。 いくつかの機能は、前回までに出ていますが、あらためて書いてあります。 使い方 nose.tools.ok_ ok_(expr, msg=None) expr が True かどうかを評価します。 msg がある場合は、テスト結果に出力します。 nose.tools.eq_ eq_(a, b, msg=None) a と b が等しいかどうかを評価します。 msg がある場合は、テスト結果に出力します。 nose.tools.raises @raises(TypeError) def raise_test(): raise TypeError("This test passes") @raises(TypeError, ValueError) def ra

はじめに nose の基本的な使い方その２です。 setup/teardown の動作についてです。 役割 テストを行う上で、あらかじめデータを用意しておく必要あったり、 テスト後に作成したデータを削除するときに利用します。 詳しくは、他のブログなどをみましょう。 書き方 nose では、パッケージレベル、モジュールレベル、関数レベルで定義することができます。 パッケージレベルでは、 __init__.py に setup/teardown を定義します。 モジュールレベルでは、テスト用モジュールに setup/teardown を定義します。 関数レベルでは、 nose.tools.with_setup に関数ごとに呼び出したい、setup/teardown をデコレータに渡します。 呼び出し順 テストパッケージ内に上の3つのレベルで、 setup/teardown が定義されていると呼

はじめに nose の基本的な使い方です。 条件式がTrueかどうか、2値が等しいかどうかをチェックする方法です。 テストの作成 まずテスト用モジュールを作成します。 モジュール名には、 "test" を含んでいる必要があります。 そのためテストしたいモジュール名+"_test"などとするとわかりやすくなると思います。 つぎに、同じルールでテスト用関数を作成します。 関数名にも、 "test" を含んでいる必要があります。 1つの機能ごとに名前を付けていくと良いです。 ソースコード # coding: utf-8 """ テスト対象のモジュール """ def add(x, y): return x + y def sub(x, y): return x - y # coding: utf-8 """ テスト用モジュール """ from nose.tools import ok_, eq

はじめに nose を勉強しているので、自分用のまとめを公開していくことにしました。 nose とは nose は、Python 用のテストフレームワークです。 Python には、 doctest、 unittest といったいくつかのテスト方法があります。 nose は、特に利便性が高く、かつプラグインが充実しているため便利です。 まずは、インストール方法の紹介です。 インストール方法 Python のライブラリは、 インストールコマンドからインストールするの一般的です。 基本的には、パッケージ名を指定することで、インストールが完了します。 easy_install $ easy_install nose pip $ pip install nose プラグイン nose を利用したテストを実施していくような環境では、同時にカバレッジを取得したり、テスト件数の増加を確認することが多いで

はじめに nose の組み込みプラグインを利用するとテストで実行された時のカバレッジを取得できます。 テスト実行時のカバレッジを取得できるので、テストでカバーできていない範囲など確認できます。 カバレッジを取得する nose と python-coverage がインストールされている必要があります。 nosetests コマンド実行時に、 --with-coverage オプションを付けることでカバレッジを取得できます。 --cover-tests を付与すると実行されたテスト用コードのカバレッジを取得できます。 インストール手順 $ easy_install -ZU nose $ easy_install -ZU coveragenose からのカバレッジ取得し、HTMLに変換する。 $ cd myproject $ nosetests -v --with-coverage tests

はじめに nohup を利用した運用でも十分利用できますが、動作ログの管理が面倒になります。 そこで、Tomcatなどのアプリケーションサーバを利用します。 内容は、公式サイトほぼそのままです。 Tomcat を用意する まずは、Tomcatをダウンロードして、解凍します。 Jenkins を実行できるようにする。 Tomcatは、Jenkinsだけを運用するため、解凍したTomcatディレクトリ内のwebapps/* をすべて削除します。 次に、jenkins.war を webapps/ROOT.war にコピーします。 実行前にTomcat 用の環境変数を設定するsetenv.shを作成します。 setenv.sh では、 Jenkins のホームディレクトリとヒープサイズを設定します。 ヒープサイズは、環境にあわせて調整すると良いです。 binディレクトリのファイルに対して、アクセ

はじめに Twitter で、rpmで利用している人もいるようでしたので、その手順の紹介です。 rpm でのインストール Tomcat の他に、Fedora, CentOS は、rpmでインストールすることで、サービスとして実行することができます。 インストールから起動までの手順 Jenkins の rpm が yum で見つられるようにする。 yum install する。 サービスを実行する。 # wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo # rpm --import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key # yum search jenkins # yum install jenkins # /

はじめに 今回は、Jenkins と Python の連携についてです。 使用するツールは、とても便利なテストフレームワーク nose と カバレッジ coverage との連携についてです。 nose連携 まず、 nose との連携からです。 nose をそのまま実行したのでは、Jenkinsに取り込めないため、XUnit形式のレポートを出力する必要があります。 XUnit形式のレポート出力には、 unittest-xml-reporting を導入する必要があります。 unittest-xml-reporting がインストールされていると、noseの出力レポートをXUnit形式にすることができます。 インストール $ easy_install -ZU nose $ easy_install -ZU unittest-xml-reportingnose の使い方は割愛しますが、コマンド

プラグイン一覧 使い始めて、３日ですが現在使っているインストール済みのプラグインです。 Green Ball 青色がなじめなくて。 Git Plugin Gitリポジトリ連携用 Hudson Post build task ジョブの失敗通知用に利用している。 Cobertura Plugin python-coverage用に利用中。 Monitoring 入れてみた。 Python Plugin 使いどころがいまいちわからず。 TODO ジョブが失敗したときに、シェルスクリプトを動かしたいけど どのプラグインがいいのか分からないので調査する。 ジョブ失敗通知の決定版は、まだ調査中。

はじめに Buildbotを常用していたのですが、Erlangと相性の悪い部分があったので、Jenkinsに乗り換えました。 ソースコードも読みつつ、パッチを当てようかとも思ったのですが、 アップデートのたびに個別パッチは、結局のところ、大変になるだけなのでCIツールを変更しました。 Buildbot の機能に依存している部分が少なかったため、ツール変更しても問題ない感じです。 せっかくなので、いろいろとまとめていきたいと思います。 インストール war ファイルをダウンロードして、好きなディレクトリに置くだけです。 テスト起動 $ cd /home/kuma8 $ wget http://hudson-ci.org/downloads/war/latest/hudson.war $ java -jar hudson.war適当に GUI からジョブを作ってみましょう。 これだけで、CIを

レスポンスの遅い応答を返すデバック用サーバがほしかったので、 Tornadoで作ってみました。 Tornado は、 URLパターン中に正規表現を入れると、リクエストハンドラーへリクエスト引数として渡すことができます。 class himote_check_handler(tornado.web.RequestHandler): # ([0-9]+)にマッチする箇所が、 uidとして渡される def get(self, uid): response_json = "{'mote_event_avg': %2.11f, 'user_id': %s}" # response delay uid_val = int(uid) if uid_val > 6000: os.system('sleep %d' % (uid_val / 1000)) # response json format sel

日本語情報を調べてみたけども、情報量が少ないのでメモがわりに。 Tracとmod_wsgiの公式サイトに設定例が載っています。 :OS: Fedora 11 :Python: python-2.6-9.fc11.i586 :Apache: httpd-2.2.11-8.i586 :mod_wsgi: mod_wsgi-2.3-3.fc11.i586 :Trac: 0.11.5 Apache + mod_wsgi をインストールする。 # yum install httpd # yum install mod_wsgi Pythonの環境を整える。 # yum install setuptools # yum install setuptools-devel # easy_install -ZU trac Tracのプロジェクトを作成する。 /home/kuma8/trac に、Tracのプ

Tracで全文検索したくなったので、構築中メモ。 できるかどうかはまだわからない:-P s/toritonn/tritonn 環境 1. OS: CentOS 5.3 2. Python: 2.4.3 2-1. Trac 0.11.4 2-2. Genshi 0.5.1 2-3. docutils 0.5 2-4. pygments 1.0 2-5. mysql-python 1.2.3c1 3. MySQL 5.0*1 Trac + MySQLのインストール 1. 必要なライブラリのインストール # yum install mysql mysql-server mysql-devel # easy_install -ZU trac # easy_install -ZU docutils # easy_install -ZU pygments # easy_install -ZU mysq

P905iに機種変更したので、写真へ埋め込んだGPS情報を取得してみた EXIFのデータ構造がどうなっているかわかってないですが、 EXIF.pyを使うことで、データ自体は簡単に取得できました。 import EXIF file = 'P905i.JPG' fp = open(file, 'rb') exif = EXIF.process_file(fp) print str(exif['GPS GPSLongitude']) print str(exif['GPS GPSLongitudeRef']) print str(exif['GPS GPSLatitude']) print str(exif['GPS GPSLatitudeRef']) print str(exif['GPS GPSMapDatum']) fp.close()

フィクスチャの読み込みに関して、MiCHiLUさんにアドバイスをもらったので試してみた。 １．生成したフィクスチャをDjangoのプロジェクト配下に置く ２．TestCaseに、 fixtures クラス属性を指定する （フィクスチャの読み込み から抜粋） ユニットテストは、以下のように動作します ・ テストケースの開始時で、かつ setUp() の実行前に、 Django はデータベースを一掃して、データベースを syncdb 直後の状態に戻します。 ・ 次に、テストケースクラスに指定した全てのフィクスチャをインストールします。上の例では、 mammals という名前の JSON フィクスチャと、 birds という名前のフィクスチャがインストールされます。フィクスチャの定義とインストールに関する詳細は loaddata のドキュメント を参照してください。 このフラッシュ／ロードの作業

Djangoでのテスト まずは、ここを見る。 Django勉強会 Disc4の資料 Djangoアプリケーションのテスト 大事なところ テストデータの作成は、開発中にデータをadmin画面などから作成していると思うので、 $ python manage.py dumpdata --indent=2 > app/fixtures/test.json などで、ファイル出力しておくと便利。 デフォルトの出力形式は、json形式　--indentを指定するとエディタから見やすい。 作成したテストデータは、tests.py から読み込ませて使用することができる。 tests.py >>> from django.core import management >>> management.call_command('loaddata', 'blog/fixtures/k8w.json') Loadin

環境： VirtualBox on CentOS : 5.0 Apache : 2.2.3 mod_wsgi : リビジョン 204 mod_wsgi を入手します。 $ svn checkout http://modwsgi.googlecode.com/svn/trunk/ modwsgi A modwsgi/configure A modwsgi/LICENCE A modwsgi/configure.ac A modwsgi/Makefile-1.X.in A modwsgi/Makefile-2.X.in A modwsgi/mod_wsgi.c A modwsgi/README U modwsgi リビジョン 204 をチェックアウトしました。 mod_wsgiインストール 以下の手順で、簡単にインストールできます。 $ ./configure $ make # make in