投稿

12月, 2011の投稿を表示しています

Redmine のリポジトリ全文検索プラグイン

メリークリスマス!でしたね。今年のクリスマスは ruby を書いて過ごしました。えぇ。ついに ruby デビューです。 作ってたのは Redmine のリポジトリ全文検索プラグインです。会社のプロジェクト管理サイトを Trac から乗り換えるにあたり、これ!ってのが見つけられなかった情弱です。 Trac では、full-text サーチエンジンに Hyper Estraier を使う  TracRepoSearch  という素晴らしいプラグインを使ってました。ということで、便乗して redmine_reposearch というプラグインを作って見ました。バックエンドも同じく Hyper Estraier です。  個人的に欲しかった機能は、 インストールステップが簡単 プロジェクト、サブプロジェクト、全プロジェクト間で検索できる Redmine のアクセス権管理に対応する MIME タイプを限定して検索する (今後実装予定) です。ある程度は満足がいく出来に作ることが出来ました。インストール方法等は wiki にまとめました。わかりにくかったらお気軽に Issue か Twitter でお申し付けください。 # インストールステップは 2 ステップ これは結構苦労しました。いろんな OSS 検索エンジンの仕様を調べ、一番インストールが簡単で、動作が軽快で、気の利いた ruby バインディングがあるやつを選びました。 ライブラリのインストールとプラグインのインストールのみで動作します。 Estraier の DB は RAILS_VAR/reposearch 以下にプロジェクト毎に作成されます。Ubuntu の場合は、 /var/lib/redmine/reposearch になります。クラスタ組みたい場合は、 RAILS_VAR はアップロードファイル保存ディレクトリでもあるので、ネットワークファイルシステムをマウントするなどすればいいと思います。 あと SCM との連携は fetch_changesets と同じ仕組を流用しています。まだ ruby script/runner "Repository.fetch_changesets" -e production のようなコマンドでは動きません。 /

Python の新ユニットテストフレームワーク (or unittest2)

これは Python3 Advent Calendar の記事です。夢はテストエンジニアです!ということでユニットテストについて書きます。 Python3 縛りとのことですが、この新ユニットテストフレームワークは Python 3.2 以降と 2.7 以降が対象です。これ以前のバージョンでこの新ユニットテストフレームワークを利用したい場合は、それぞれ unittest2py3k (3 系)、 unittest2 (2 系) というバックポートが用意されています。新ユニットテストは mock や IronPython 等の開発者としても知られている Michael Foord 氏を中心に開発されました。 >>> Python とユニットテストの歴史 Python のユニットテストは、1999 年 xUnit ファミリーの PyUnit として開発され、2001 年に公開された Python 2.1 から unittest として標準ライブラリとなりました。それ以降、アップグレードといえば assert* メソッドの追加や削除といった感じ。PyCon 2010 での Michael Foord 氏の プレゼンテーション によると " Python には革新的なテストインフラが数多くありますが、unittest は標準ライブラリという理由により最も利用されているテストフレームワークです。しかし、他のテストフレームワークが革新的な進歩を遂げている中、unittest は遅れを取っています "。 しかしついに、ユニットテストは Python 3.2, 2.7 で革新されることになりました。それも Python らしく "後方互換" がかなり意識されています。これも Michael Forrd 氏の言葉を借りると " これは革命ではなく、 進化 です "。 >>> どこが "進化" したのか 新ユニットテストフレームワークには以下の機能の追加や更新が行われています。 便利な assert* メソッドの追加 名称の統一、重複の排除 コマンドラインからの制御をより便利に / 或いはディスカバリ テストのスキップ モジュールレ

PyPy における Python のパフォーマンスチューニング

イメージ
これは PyPy Advent Calendar の記事です。PyPyのコアディベロッパーである " Maciej Fijalkowski " 氏のブログ " Analysing python's performance under PyPy " の抄訳+αです。 Python の一般的なパフォーマン解析のモデルは、" プロファイラ を実行して、ボトルネックを探し出し、それを最適化するか C で書き直す" ことです。しかし PyPy ではこのアプローチだけでは不十分です。なぜなら、 多くの大規模アプリケーションで、プロファイラはフラットです: PyPy のトランスレーションツールチェーン、Twisted、モダンな Web サーバ等が良い例です ボトルネックを発見したとしても、それが特定の関数内でのみ遅いのか、複数の関数が関係しているのか明確になるわけではありません。どうすれば遅くて、どうすれば速くなるかは CPython においても明確な答えはありません。JIT が適用されるとさらに複雑です。 JIT が特定のコードをどのようにコンパイルしたかを確認することが重要 になります。 パフォーマンスにおいては、特に GC 関連の問題は多くの関数に影響がありますが、プロファイルでは確認できません。 PyPy には、問題を解決するためのいくつかのツールが提供されています。プログラムのパフォーマン解析に関するいくつかの方法を示します。これはガイドラインであり、 銀の弾丸 ではありません。アプリケーションが複雑な場合は、多くの 鉛の弾丸 が必要でしょう。 >>>> テストを作成する これは品質に関するものではありません。多くの自動化されたテストを受けることで、その機能を失うことなく、よりパフォーマンスの高いコードにリファクタできるようにします。 >>>> ベンチマークを書く これが重要な出発点となります。ひとつのスクリプトで、できれば引数を指定して、変更の影響を測定できるようにする必要があります。 1 回だけしか実行されないスクリプトでない場合は、同じテストを繰り返し実

[memo] Ubuntu 11.10 (kernel 3 系) にアップグレード時の注意書き

kernel 3 系ではディレクトリツリーが整理されています。しかし、現在のところ Ubuntu 11.10 にアップグレードしても、新ディレクトリツリーに完全に対応してくれません。ちなみに新規インストールの場合は問題ありません。 以下の手順で新ディレクトリツリーに対応します。 新ディレクトリへ移行 sudo mv /var/run/* /run/ sudo mv /var/lock/* /run/lock/ sudo rm -r /var/run sudo rm -r /var/lock sudo ln -s /run /var/run sudo ln -s /run/lock /var/lock sudo rm /run/dbus/* 参考 apparmor の権限を更新 例) /etc/apparmor.d/usr.sbin.mysqld の場合 --- /var/run/mysqld/mysqld.pid w, --- /var/run/mysqld/mysqld.sock w, +++ /{,var/}run/mysqld/mysqld.pid w, +++ /{,var/}run/mysqld/mysqld.sock w, その他設定ファイルの見直し sock ファイルとか pid ファイルの設定は見直したほうがいいです VMWare 上にインストールしている場合は、ライブラリが競合するので blacklist に以下を追加する。 # sudo vi /etc/modprobe.d/blacklist.conf blacklist i2c_piix4 参考 pam が更新されているので、依存してるアプリケーションの更新が大変ですね。。。

PyPy! - PyPy Advend Calendar

イメージ
今年も Advent Calendar の季節が始まりました。この記事は Python を高速化するソリューション PyPy の Advent Calendar  の記事です。最初なので、簡単に PyPy の概要と PyPy-ja のご紹介をしたいと思います。 >>>> PyPy ってなんなの? @nati nati ueno PyPyは日本語で、おっぱいの意味なんだよ ってUSのpythonやってるエンジニアに教えたら「今日ほどいい日はない!って大喜びしてた」 Oct 06 via web Favorite Retweet Reply PyPy は Python 2.7.1 互換の高速な処理系です。現在、着々と py3k 対応の開発も進んでいます。Python 標準処理系である CPython と比較して以下のような特徴があります。 速度 : とにかく速いです。JIT パワーです。CPython と PyPy の速度は ここ に公開されています。現在は CPython の 5 倍ぐらい速いですね。特定の環境では Java より速いという 計測結果 もあります。ちなみに先日 Win32 環境で同じ計測をしましたが、Win32 環境では pypy 1.6 以降で Java よりも高速という 結果 がでましたよ。残念ながら 1.7 より 1.6 の方が高速という結果でしたが。。。 メモリ使用量 : 多い。ほんとにメモリ食います。JIT の作者 Antonio 氏に Python 生みの親の Guide (oh...) Guido 氏が "PyPy の JIT はなんで速いの?" と質問した時に、"オブジェクトが持っているデータをメモリ上の固定位置に配置してるのが効いているみたい" と答えたとのことです ( ats さんのブログより )。なるほど。 互換性 : 一部制限がありますが Python との互換性は高いです。1.7 になってさらに互換性が高まっています。動作する Python ライブラリは ここ にまとまっています。"このライブラリも動いたよ!" って方は是非この Wiki を編集してみてください。Django, Flask, Pyram