投稿日 2009年8月26日 水曜日 カテゴリ Trac 投稿者 omaeコメント(0) » 

omae です。

今回は Trac のパフォーマンスを上げるためにやっている設定を紹介したいと思います。

1. trac.ini の [trac] htdocs_location を設定し、Apache に静的ファイルを処理させる

この方法は TracCgi Mapping Static Resources に書かれていることでありよく知られているものです。 CGI ではなく mod_python などで実行している場合でも Apache に処理させるようにしたほうが速いです。

2. Trac plugin の静的ファイルを Apache に処理させる

Trac plugin は自身が使うための静的ファイルのディレクトリを ITemplateProvider.get_htdocs_dirs() というインターフェイスから返すことになっています。 このディレクトリへのアクセスも Apache に処理させるようにします。

ここでインストールしている plugin からこのディレクトリを一つ一つ調べてもよいのですが、めんどくさいので次のスクリプトを書きました。 引数に TRACENV のパスを指定すると ITemplateProvider.get_htdocs_dirs() の値を収集して出力します。

#! /usr/bin/python

import sys
try:
    set = set
except NameError:
    from sets import Set as set

from trac.env import open_environment
from trac.web.chrome import Chrome

def print_providers(path):
    try:
        env = open_environment(path)
    except Exception, e:
        print('%s: %s', path, e)

    chrome = Chrome(env)
    container = set()
    for provider in chrome.template_providers:
        dirs = provider.get_htdocs_dirs()
        for dir in dirs:
            container.add(dir)

    container = [v for v in container]
    container.sort()

    print('%s:' % path)
    for prefix, dir in container:
        print('\t%s\t%s' % (prefix, dir))

for arg in sys.argv[1:]:
    print_providers(arg)

これを実行すると以下のような出力が得られます。

/var/lib/trac/opengroove:
        bitten  /usr/share/trac/plugins/Bitten-0.6dev_r641-py2.3.egg/bitten/htdocs
        common  /usr/lib/python2.3/site-packages/trac/htdocs
        customfieldadmin        /usr/share/trac/plugins/TracCustomFieldAdmin-0.2-py2.3.egg/customfieldadmin/htdocs
        iniadmin        /usr/share/trac/plugins/IniAdmin-0.2-py2.3.egg/iniadmin/htdocs
        s5      /usr/share/trac/plugins/S5-0.1-py2.3.egg/s5/htdocs
        site    /var/lib/trac/opengroove/htdocs
        ticketdelete    /usr/share/trac/plugins/TracTicketDelete-2.0-py2.3.egg/ticketdelete/htdocs
        tracfreemind    /usr/share/trac/plugins/TracFreeMind-0.2-py2.3.egg/tracfreemind/htdocs
        tracnav /usr/share/trac/plugins/TracNav-4.0pre7-py2.3.egg/tracnav/htdocs
        tracwysiwyg     /usr/share/trac/plugins/TracWysiwyg-0.2_r4353-py2.3.egg/tracwysiwyg/htdocs
        workfloweditor  /usr/share/trac/plugins/WorkflowEditorPlugin-1.0.1_r5329-py2.3.egg/workfloweditor/htdocs

ここで最初の文字列は get_htdocs_dirs() が返す prefix であり、この値をキーにファイルがどのディレクトリにあるかを Trac は判断しています。 また common に関しては htdocs_location の設定値で URL が変更できるようになっています。 site に関しては $TRACENV/htdocs/ に置いたファイルへアクセスできるようするために Trac 自身が get_htdocs_dirs() で登録してくるようになっています。

この出力から http://localhost/trac/ で複数プロジェクトを処理している場合は以下のような設定を書きます。

AliasMatch ^/trac/[^/]+/chrome/bitten/(.+) /usr/share/trac/plugins/Bitten-0.6dev_r641-py2.3.egg/bitten/htdocs/$1
AliasMatch ^/trac/[^/]+/chrome/customfieldadmin/(.+) /usr/share/trac/plugins/TracCustomFieldAdmin-0.2-py2.3.egg/customfieldadmin/htdocs/$1
AliasMatch ^/trac/[^/]+/chrome/iniadmin/(.+) /usr/share/trac/plugins/IniAdmin-0.2-py2.3.egg/iniadmin/htdocs/$1
AliasMatch ^/trac/[^/]+/chrome/s5/(.+) /usr/share/trac/plugins/S5-0.1-py2.3.egg/s5/htdocs/$1
AliasMatch ^/trac/[^/]+/chrome/ticketdelete/(.+) /usr/share/trac/plugins/TracTicketDelete-2.0-py2.3.egg/ticketdelete/htdocs/$1
AliasMatch ^/trac/[^/]+/chrome/tracfreemind/(.+) /usr/share/trac/plugins/TracFreeMind-0.2-py2.3.egg/tracfreemind/htdocs/$1
AliasMatch ^/trac/[^/]+/chrome/tracnav/(.+) /usr/share/trac/plugins/TracNav-4.0pre7-py2.3.egg/tracnav/htdocs/$1
AliasMatch ^/trac/[^/]+/chrome/tracwysiwyg/(.+) /usr/share/trac/plugins/TracWysiwyg-0.2_r4353-py2.3.egg/tracwysiwyg/htdocs/$1
AliasMatch ^/trac/[^/]+/chrome/workfloweditor/(.+) /usr/share/trac/plugins/WorkflowEditorPlugin-1.0.1_r5329-py2.3.egg/workfloweditor/
AliasMatch ^/trac/([^/]+)/chrome/site/(.+) /var/lib/trac/$1/htdocs/$2

mod_python で運用している場合には上記だけでなく /trac/*/chrome/ へのアクセスが mod_python に処理させてしまわないように SetHandler None が必要になると思います(未確認。mod_rewrite でないとうまくいかないかも知れません)

<Location /trac/*/chrome/>
    SetHandler None
</Location>

これで体感的な速度が上がるかと思います。

更なる速度改善としては添付ファイルへのアクセスを Apache に処理させる…というのが考えられます。 画像を貼りすぎた Wiki ページでは、やはりその分の速度劣化があるので Apache で処理できれば早く表示できるようになります。 ただし Apache に処理させるということは Trac が行う権限チェック(WIKI_VIEW があるかなど)が効かなくなるので、そのあたりは注意が必要です。

投稿日 2009年8月24日 月曜日 カテゴリ ソフトウェア開発, プロジェクト管理 投稿者 syojiコメントは受け付けていません。 

バグのライフサイクルを管理する仕組みがバグトラッキングシステムの特徴の1つである。

簡単に言うと、「バグの発生~調査~対策~確認」のバグ1件毎にステータスを管理する仕組みのことである。

なぜ、バグのステータスを管理必要があるか、というとExcelをつかったバグ管理を実践してみるとわかると思う。

こちらの記事(「とりあえずバグ管理」のための Excel テンプレート)

でバグ管理に必要な項目をリストアップしたが、バグの「状態」をもう少し運用に沿った仕組みで管理したくなる。

Excelを使ってバグ管理の運用をしていくと以下のような課題が挙がると考えられる。

  • いつ、だれが、どのような対応をしたのか?わかりにくい
  • 対応履歴の管理が出来ない
  • 状態の変更履歴(どのようなフローを経由してきたか)がわからない
  • Excelファイルをメール添付してやりとりするため、最新がどれかわからない
  • 複数の版にわかれたファイルをマージしなければいけない
  • YYYYMMDD_○○○.xls という管理になってしまう

など、Excelではバグ管理できないわけではないが、開発者にとっては運用するだけでストレスを感じてしまう場合が多い。

弊社ではバグトラッキングシステムを利用しているが、これは開発者にストレスをかけないために導入したという経緯があるためである。

これまでの経験上、Excelで運用していくと破綻してしまう場合があるので、バグトラッキングシステムはソフトウェア開発では必須のツールになっている。

バグトラッキングシステムの中で最も必要な機能が「状態(ステータス)」とワークフローである。 以前にブログで紹介した、「ソフトウェア開発:バグ管理方法の紹介」で簡単にワークフローについてイメージ図を紹介したが、バグのフローとは

  • 1. バグの発生(発見者)
  • 2. 担当者への振り分け
  • 3. 担当者の対応
  • 4. バグの完了確認(対応済みかどうか)
  • 5. バグの完了

である。 ソフトウェア開発の現場では、バグの数も半端な数ではなく大量に発生する。それらバグ1つ1つのワークフローをきちんと管理できる仕組みがバグトラッキングシステムの大きなメリットであると考えている。

会社やプロジェクトによって、ワークフローはもっと複雑になっていると思うが、

基本的には

[発生->割当->対応中->確認待ち->完了]

[         ->対応なし             ]

が管理できれば十分である。

今回はバグの場合のワークフローについて書いたが、機能追加の要望、タスクなども同様にワークフローを決めて運用することでソフトウェア開発の効率は格段に上がると思う。

OpenGrooveの社内検索システム : zeera document search

zeera document searchで社内文書検索

対応履歴の管理が出来ない
投稿日 2009年8月20日 木曜日 カテゴリ デザイン 投稿者 sugimotoコメント(0) » 

sugimotoです。

Web開発をしている人なら、HTMLやCSSは基本的な知識です。 でも、Webシステムの見た目をセンスあるデザインにするのは意外と難しくて、毎度、なやみます。

デザイナーさんがいるプロジェクトなら、問題ありませんが、小さなプロジェクトや、ちょっとしたツールは自分でデザインすることになったりまします。

とはいえ、それほどデザインに凝っている時間も無く、さらりとそれなりのデザインをしたいところです。

そんなときに、『素人でもそれなりの。』デザインをするために使っている支援ツールをご紹介します。

1. 配色を決める

凝ったバックグラウンドイメージやヘッダーイメージを使わないとすると、見た目を決めるのはやっぱり配色のセンスです。

間違った配色はセンスのない雰囲気を作ってしまいます。 それに、システムを利用するユーザーさんから見ても、「長時間見ているとなんとなく疲れる」ということになります。

色相環を使ってセンスある色の組み合わせを作るツールでベースになる色を決めます。 「自分にだってセンスある色の組み合わせが作れる!!」なんて思いそうになりますが、なにぶん素人なので、ツールにお任せします。

kuler

Color Scheme Designer

作った配色はログイン画面など、すぐに見えるところに書いておいて、開発環境では表示されるようにしておきます。

2. アイコンを使う

Illustrator も少しくらい使えますが、きれいなアイコンを作るなんて、ぜんぜんできません。。

そんなわけで、アイコンは探して使います。

iconlet

ICONFINDER

ライセンスを確認して、使えるものを使うようにしましょう。

3. ボタンを作る

Webシステムに欠かせないボタンもツールで作ります。

Buttonator.com

日本語のテキストにも対応しているのと、複数のテキストを一括作成できるのが便利です。

4. Ajaxを使う

最近のWebシステムではAjaxを使ったコンテンツのロードや、データの更新は当たり前になっています。 データ更新中などに表示されるくるくる回るイメージもツールを使って作成します。

ajaxload.info

このときももちろん、先ほど決めた配色に従って作成します。

いろいろな種類のイメージが作れるので、いつも使わせていただいてます。

5. 角丸にしてみる

見た目をいまどきなイメージにするために角丸でコンテンツを囲む、なんてことがしたくなるときがあります。

そんなときにも、ツールで作成したイメージを使います。

Jalenack’s Complete Rounded Corners Maker

デザイナーさんがつくるものにはほど遠いですが、ツールを使うと時間をかけなくても、「それなりの」ものができます。 ちょっとしたツールや小さなシステムでも、ユーザーさんが使いたくなるようなシステムにしたいものです。

OpenGrooveの社内検索システム : zeera document search

エンタープライズ検索 zeera document search

zeera document searchで社内文書検索

投稿日 2009年8月17日 月曜日 カテゴリ Apache, ソフトウェア開発, テスト 投稿者 syojiコメントは受け付けていません。 

Webアプリケーションやクライアントサーバ型のシステム開発の中で性能要件を満たすために負荷試験やロード試験といわれる工程がある。

重要な工程として考えているが、スケジュールの厳しいプロジェクトなどでは後回しにされることがあった。 特に、開発が遅れている場合、要件を満たすための開発が重視されることは理解しているが、負荷試験を実施することは同じくらい大切な工程である。試験で起こることは当然、本番環境でも起こり、あとで痛い目をみないためにも必須の工程である。

負荷試験を設計する上での考え方をまとめてみたいと思う。 以下のサイトが参考になる。

負荷試験とは

構築するシステムがどの程度の負荷に耐えられるかを測定し、システムの信頼性と耐用範囲を明確にする。ウェブアプリケーションの場合、同時アクセスユーザ数をどれだけ処理出来るか、閾値を越えた場合のシステムの振る舞いを検証する試験である。

負荷試験で使われる試験環境は本番環境と同一であることが望ましい。しかし、実際には機器調達が難しいことが多い(例えば、想定している分だけのクライアントマシンを用意する等)。機器が準備できない場合、サーバに負荷を発生させるツール等を使用し、高負荷、過負荷を与え、システムの振舞いについて検証する。

負荷試験の計画(設計)に必要なこと 負荷試験を計画するときに最低限、考えなければいけないことを説明したい。

前提条件

試験を実施するときの試験環境について、サーバの役割、台数、クライアント数、負荷をかける時間等の環境について条件を明確化しておく必要がある。

監視ポイント

例えば、Webアプリケーションの場合、クライアントがアクセスしトップページが表示されるまでの時間。など要件を満たすために必要な監視ポイントを明確にしておく必要がある。サーバサイドではDBに対する大量のI/O(書込、読み出し等)がそれにあたると思われる。

目的と対象範囲

負荷試験でクリアしなければいけない要件、ユーザ数などの試験の目的と対象範囲/ハード情報(各サーバのOS情報/CPU/DISK IO/MEMORY/NETWORK)、過負荷時の測定範囲を明確にする。

性能要件(目標値)

想定されるクライアント数から性能要件を予測し、定義する。レスポンス時間等の試験項目から測定可能な数値を予測する。 例えば年に1度のみ過負荷が発生するといった事象に合わせてシステムを組んだ場合、性能要件は十分であるが、コスト面で満足するものにはならない場合がある。そのため、要件にあった目標値を設定することは重要である。

想定シナリオ

構築するシステムの利用シーンを考えたシナリオを作成する。試験実施はそのシナリオに沿って行われるべきである。 例えば、メールクライアントの場合、社員が出社する時間(09:00頃)が大量のアクセスが発生する、など。その利用シーンをシナリオに組み込む。

実施方法

市販のツールを利用する、自作ツールを利用する、など目標値を達成するためには過負荷状態を作らなければいけない。疑似的に過負荷状態を作り出す必要がある。Webアプリケーションに限定されるが無料ですばらしいツールが多く提供されている。

試験結果

負荷試験計画時の「目的と対象範囲」を達成したかどうか、 実測値が予測値より悪い場合や、目標値ギリギリの場合、チューニングを実施することになる。 問題点の原因については、計測データなどを使って

  • トランザクション数/クライアント数が増加しているとき、スループットの増加傾向が変化した時点
  • レスポンスタイムが急速に遅くなった点

分析するポイントとして、システムの測定値が急激に変化したとき、関連するモジュールがボトルネックと考えられる。 チューニングについては、そのようなボトルネックと予測されるモジュールから優先的に検証する必要がある。

以上のような点について、負荷試験の計画フェーズで考えておけば良いのではないかと考える。 負荷試験が実施されるのはシステムが構築され、結合試験も終わった以降になる。一番忙しいフェーズであるが 負荷試験の重要性を説明し、しっかりと計画をして実施していきたいと思う。

投稿日 2009年8月17日 月曜日 カテゴリ 読書 投稿者 matsushitaコメントは受け付けていません。 

こんにちは。 松下です。

以前に読んだのですが、達人プログラマを読みましました。
とは言っても,読んだのが何年も前の話でよく覚えていません。 やはり古いで、8年ぐらい前の古い本ですが、いい本はいつまでもいい本です。普段、何気なく他の本を読んでいても、この本からの引用されている記述も多くみかけます。

さて,本の中では沢山のことが書かれています。多分,この本を読むのは,本が手に入りさえすれば簡単で,すぐに終る作業です。
でも,この本の中の1つでもちゃんとやろうとすると大変です。
例えば,知識のポートフォリオなんて,ちゃんとやろうと思ったら読書量は凄いことになります。
決してできない量ではないです。
ちゃんと勉強していない人にとっては続けるのは、つらい量と言うことです。

僕はちゃんとできていない派なのですが、少しでもいいので、ちゃんと続けてみたいと思います。たぶん、何年か後も同じことを思うのかもしれませんがw
できるだけ、過去の振り返りを行って改善できるように努力していきたいものです。

次ページへ »