Ryuzee.com

2008/09/05 06:23:41 日記 none Comments

Tracは標準では全てのリクエストがcgi経由なので、よほどのマシンでないかぎり動作は非常にもっさりした感じになる。

通常のcgi経由で、100回リクエストを発行した場合（abコマンド）

平均して秒間2.5件程度はさばける感じだ。

さてチューニングだが、通常2点の対応をする。

• Tracアプリを、mod_python経由で動作させる
• cssやjs等の非アプリファイルを、python経由ではなく直接参照させる

順に手順を書く。

Tracアプリを、mod_python経由で動作させる

まずは、mod_pythonを導入する。CentOSなら

次に、apacheの設定ファイルを変更する。
cgi経由で利用する場合は、以下のような設定になっていると思われる。
単に特定のURLの場合、Tracの環境変数を設定するのと認証の設定をしているだけ。

こいつをmod_python対応にすると、こうなる。TRAC_ENVの環境変数を外して、PYTHON_EGG_CACHE以下の5行を自分の環境に合わせて変更する。

以上が終わったら、apache再起動を実施だ。

cssやjs等の非アプリファイルを、python経由ではなく直接参照させる

上述の通り、cssやjsもcgi経由で読み込まれているので、こいつを直接参照するように変えた方が良い。

Tracでは通常、画像やjs等の部品が/usr/share/trac/htdocs/に配置されており、こいつを直接参照するようにするには以下の手順になる。

次にtrac.iniを開く。中にhtdocs_locationという設定項目があるので、

のように設定する。

最後にまた性能を見てみる。

ということで、10倍程度の性能向上が出来ていることが分かる。
こりゃ絶対やらないといかんでしょ。

※abコマンドでは画像やcssは読み込まないので、単純にTracのページの性能になる。

2008/09/04 23:03:11 日記 2 Comments

会社で、「もう俺は知らん。後は任せた。」といって、机ひっくり返して帰る。

一生の中で一度はやってみたい。

2008/09/04 06:03:59 書評 none Comments

自分がいなくてもまわるチームをつくろう!
著者／訳者：山口 正人 豊田 圭一
出版社：明日香出版社/クロスメディア・パブリッシング(発行)( 2008-01-17 )
定価：￥ 1,470
単行本（ソフトカバー）
ISBN-10 : 4756911552
ISBN-13 : 9784756911551

先週末偶然行った本屋で店頭に並んでいて、タイトル買いしてしまった。
うーーん。この手の本に反応して買ってしまうということは、それだけ自分が悩んでいるということなのだろうね。あとは自己評価高すぎるかも知れないが、自分がいないとチームが回らなくなってしまう気がする。これは今のうちに改善しておかないと、安心して転職できないからな～。

リーダーには考える時間が必要

激しく同意。組織が忙しくなってしまうと、自分の考える時間を犠牲にしてプレイヤーになってしまうことはままある。リーダーは方向性を示し、組織をドライブするのが仕事であると定義すると、自分がプレイヤーになると組織の統率が取れなくなってしまう可能性が高い。
なお、自分自身がリーダーが好きか、プレイヤーが好きか、という問題は別の問題として存在する。

業務をマニュアル化する

結構取り組みが進んできたけど、まだまだ出来る。これをやっておくと、マニュアルどおりにやれば終わる仕事は、全て代替可能なリソースによって対応が可能になるというメリットがある。あとは自分自身でやるにしたって、毎度毎度、前回どのようにやったっけな～、みたいなことをやるより、予めマニュアル作っておくなり、前回の作業ログとって置くなりして、そいつ参照したほうが間違いがないよな。

チームのビジョンや目標をつくる

あー、これは全く出来ていない。生産性の高いチームを作るって目標はあるんだけど、何のために生産性を高くする必要があるのか、それによってメンバーがどういうメリットを受け、会社はどのようなメリットを受けるのかについて説明したことは無い。個人的には裏にあるものは自分で想像して、勝手に気づいてよ、という気持ちもあるけどね。それが優秀な人と凡人の違いだ。

メンバーの役割を決める

一応決めているんだけどね。なんか中途半端。これも自分で気づけよ、という気がしなくも無いが（自分自身が気づいているかも不明）。ただ明確な役割を決めないと、成果も評価も定義しようが無いはずなので、下期に向けてはちょっと考える。

何はともあれ、早く自分がいなくても回るチームを作らないといけない。

2008/09/02 23:50:18 日記 1 Comments

Google，オープンソースのWebブラウザ「Google Chrome」を公開へ：ITpro

米Googleは米国時間2008年9月1日，オープンソースのWebブラウザ「Google Chrome」を開発したことを公式ブログで発表した。9月2日にWindows用のベータ版を世界100カ国以上で公開する。

とりあえずWeb系の仕事をしている身としては

• うひょーー。またテスト対象ブラウザ増えるのかよ～（萎
• こりゃーすげぇーんじゃねーの。楽しみだな～

ってのと両方だね。
レンダリングエンジンにWebkitを使ってて、オープンソースってことなので、早速実装見てみよう。

・・・って日本時間2日23:54現在まだ公開されていない。時差か・・・。

2008/09/01 19:04:16 書評 none Comments

ラクをしないと成果は出ない
著者／訳者：日垣 隆
出版社：大和書房( 2008-05-23 )
定価：￥ 1,500
単行本（ソフトカバー）
ISBN-10 : 4479792368
ISBN-13 : 9784479792369

昨日ブックオフに行って見つけた本。今年の5月初版で、有名な著者だったから、まだ500円したよ（笑

この人の文体は読みやすい。夕刊ゲンダイやメールマガジン等、軽い感じの文章を書くのにも慣れているのだろうか。ローラーしながら１時間で読み終えた。読後感としては・・・、前書きと後書きは面白かったんだけど、あとは、どっかで聞いたことあるような感じかなぁ。。何度も読み返すってよりは、さらっと読んで自分の使えるところだけ取り出すといいかも。

そうはいいつつ気になった項目を抜粋しておく。

• 「つまらない」と思ったら、できるだけ早く撤退する
• 人から薦められたものは、無理をしてでも即日取り入れる
• 先輩の一言アドバイスには、とにかくまず従ってみる
• 依頼には即決で答える
• 「やりたいこと」を周囲に話しておく
• 好きな仕事を増やすために、好きではない仕事を毎年２割ずつ削除する
• 「なるほど」と思ったことは、２４時間以内に「やる」メドをつける
• 常に確率を意識する
• 休暇中も仕事をしたほうが、のんびりできる
• 数値目標とその根拠を明白に持つ
• 毎晩アルコールが欠かせない人は伸びない

2008/09/01 06:33:23 日記 none Comments

塹壕よりScrumとXP
Scrum and XP from the Trenches v.2.2（上記の日本語訳PDF）

日本語で130ページある、Scrumの実践本。これが無償で配布されていることに驚く。内容も結構面白かった。これからじっくり読む。

2008/08/31 07:44:10 日記 none Comments

ということで、平均5時35分。やっぱり週末に目覚ましかけないで寝ると、起床時間が遅くなっている。これは仕方ないような気がするが、やはり出だしが遅いと一日がグダグダになってしまう傾向にあるので、改めた方がいいかなぁ~。

2008/08/29 06:46:33 日記 2 Comments

Joel on Softwareによるソフトウェア開発チームの評価について、あちこちでエントリがあったので便乗。
このテスト、12項目あるが、12点は完璧、11点は許せる範囲、10点以下だったらその組織は深刻な問題かかえている、とかいってしまう厳しいテストだ。
はてなは12点満点。
アプレッソは10点

ちなみに自分の所は、１，２，４，５，６，７、９、１２で、８点。ちょっと甘目かも知れないけど、いま目指している所で、順次適用中なので、そのように採点してみた。
ただ、大事な事は、「成し遂げたい目標のために、今何をやるべきか、この先何をやるべきかを決めたら、腹くくってやり続ける」ってことだ。色々な本に色々な事が書いてある。同じことが書いてある場合もあれば矛盾する場合もある。でも一度決めたら自分が納得して良し悪しが分かるまで徹底的にやるしかない。中途半端にあちこち齧っては方向転換を繰り返すような組織ではいかん。

1. ソース管理システムを使っているか？
2. １オペレーションでビルドを行えるか？
3. 毎日ビルドを行うか？
4. 障害票データベースを持っているか？
5. 新しいコードを書くまえにバグを修正するか？
6. 更新可能なスケジュール表を持っているか？
7. 仕様書を持っているか？
8. プログラマは静かな労働環境にあるか？
9. 買える範囲で一番良い開発ツールを使っているか？
10. テスト担当者はいるか？
11. プログラマを採用するときにコードを書かせるか？
12. 「廊下での使い勝手テスト」を行っているか？

1. ソース管理システムを使っているか？

使っている。Subversion。少なくとも最近全案件で必須にしていて、ソースだけじゃなく、ドキュメントやテストコードも対象範囲にしているから、まぁ問題ないだろう。しかし一方で静的サイト構築案件をやっているチームだとこれが出来ていない。自分の管轄ぢゃないけど、いつもデグレしたとか、大騒ぎしている。

2. １オペレーションでビルドを行えるか？

DBに初期データ登録して、設定変更して、どうのこーのして、みたいなことは順次止めている。昔の協力会社が作った糞なソースなんて、IF文で、快活環境だったらこっちに繋げて本番環境だったらあっちに繋げるみたいな記述があって、本番用にはコンパイルしなおす、とかいう驚愕の実装があったな。最近は、デプロイ⇒即稼動前提にしているし、初期データの投入もインストーラ化しちゃうから問題ないだろう。

3. 毎日ビルドを行うか？

そもそも俺らはスクリプト系ばっかだ。ビルドって概念は無い。まぁ毎日自動回帰テストするかどうかって聞かれればしていない。CruiseControlとかPHPUnderControlとか使うと良いのは分かっているが、まだ出来ていない。

4. 障害票データベースを持っているか？

Tracで全部管理。新規要望も不具合もTracに突っ込んで、チケットドリブンで開発。沢山のメールに追われてどの不具合が直し終わった/終わってない、とかの苦労をすることはなくなっている。個数が見えると減らしたくなるのが人情だ。

5. 新しいコードを書くまえにバグを修正するか？

そりゃそうだよ。テストコードが全部書けているわけではないところが痛いところだが。

6. 更新可能なスケジュール表を持っているか？

普通にある。まぁたまに納期だけ先に決まったスケジュールがあるが、そういう場合は実装機能を減らす。それも許されなかった案件があるが、品質はとてつもない。もうそんな経験はしたくないな。

7. 仕様書を持っているか？

普通に概要設計、詳細設計、テスト仕様書・・・と揃っているものもあれば、テストコードだけが揃っているものもある。但し仕様書は所詮中間生成物なので、個人的には大量なものは要らないと考えている。設計の思想と、本当に重要な箇所だけに絞れば良い。あとはテストコードが仕様を明らかにしてくれる。

8. プログラマは静かな労働環境にあるか？

こりゃダメ。とにかく電話が鳴りすぎ。思考を中断されると、生産性は格段に低下する。家でソース書くと会社の数倍のパフォーマンスは出るな。

9. 買える範囲で一番良い開発ツールを使っているか？

これは口をすっぱくして言っている。人的コストが一番高いのだから、生産性をあげるためには、必要な道具は揃えるべきだ。僕のところだと、全員パソコン２台以上、メモリも増設、デュアルディスプレイもOKで、20インチ以上の環境。良いものが出たらどんどん買い換えている。
開発ツールは、Eclipseとか、Subversionとか、デファクトスタンダードに揃えている。

10. テスト担当者はいるか？

この間やった案件ではいたんだけどね。ひたすらSeleniumでテストを記録しては、デイリーで実行したり、モンキーテストしたり。ただ全部の案件でやるのは無理だなぁ。テストはテストのための能力が必要だとは思う。

11. プログラマを採用するときにコードを書かせるか？

これやりたい。けどやっていいのかなぁ？一応ブログの有無は聞いている。アドレスは聞いていないけど。でもやっぱり会社のためにも本人のためにも、お互いが理解しあった上で採用した方が良いとは思う。人事と親分に相談してみるか。

12. 「廊下での使い勝手テスト」を行っているか？

まぁやっているように思う。俺なんかは特に、作ったものは直ぐ見せたい人だし。

2008/08/27 06:41:00 日記 2 Comments

現行システムの見える化，どうしていますか？：ITpro
http://itpro.nikkeibp.co.jp/article/OPINION/20080825/313313/

「見える化するよい方法があれば，ぜひ教えてほしいよ」――。取材で訪れたある製造業のIT部門に所属するAさんはこうぼやく。Aさんは最近，生産管理システムの刷新に伴い，現行システムの調査に乗り出した。ところが，過去に各プログラマがソースコードを次々とコピーして修正を加えた結果，同じようなソースコードがあちこちにあった。どれが信頼できるソースコードなのか分からない。これじゃあプロジェクトが始められないと，Aさんらは数カ月をかけて全ソースコードを一つずつ確認する羽目になった。Aさんは言う。「現行システムを見える化する“魔法の杖”はないものか。結局，目視による地道な調査をするしかないのか」と。

えーと、こんなソース調査するのやめて、改めて要件確認して、不要機能も選別して、作り直した方が良いと思われ。

• 長い時間かけて調査した結果を受けて何するんだっけ？仕様の洗い出し？その仕様が正しいかどうか保証できないんだったらくまなく調査するだけ時間の無駄。
• そもそも数ヶ月かけてソース解析するくらいなら、１ヶ月くらいでコア機能作って、それベースに仕様調整した方が早いんぢゃ？
• 過去度重なる機能拡張をしたというが、本当に全機能くまなく使っているはずがない。不要部分は一杯あるはずだ。システムは小さく保てが鉄則だ
• 刷新ってことは完全作りなおしだと思うが、万一、こいつに機能追加した時に、既存部分の動作に影響がないかどうかのテスト(品質保証)が極めて難しい。作り直してユニットテスト化するなり、自動回帰テストできるようにしちゃった方が良い。自動テストできれば、やったらめったらな大量ドキュメントなんていらん。
• ちなみにうちの会社でもそうだが、プログラマが次々コピペしちゃうようなレベルだと、品質は時間とともに悪化していく。
• そういうレベルだとハードコーディングとかマジックナンバーだらけとか、意味不明な特殊対応とか一杯ある
• 当然、過去になんでその対応をしたのか経緯は分からない。どうすんだ？ゴルァ。

ちなみに「現行システムを見える化する“魔法の杖”」はある。使っているユーザに、聞きに行けば良いだけだ。その仕様が正しいのか業務で使えるのかを決めるのはエンドユーザーだ。ソースだけ見たってそんなもん分からんよ。

2008/08/26 07:18:57 日記 none Comments

部下が使っていたPCがちょっと前に壊れて、新しいのを買いつつ保証期間内なので修理したみたいなんだけど、結局そのPC使わないらしいので、バッテリーだけ貰った。
これで長野出張の際に「バッテリーがneeeeee」みたいな悲しい思いをしなくて良くなる。

そういえば、昔まだ競馬場に行って馬券を買っていた頃、ノートPC持って行って色々やってたんだけど、その時も替えのバッテリー持参で行ってたな~。東芝のDynabookSS3010。社会人１年目の冬のボーナスで買ったような記憶がある。当時にしては、超軽量薄型で画期的だったと記憶している。
その前も東芝のリブレット30かなんかを使ったなぁ。そのうち使わなくなって知り合いに譲ってしまったが。

« 前の記事 

日記 PHP オープンソース Linux Perl フリーソフト Trac wordpress 自宅サーバ phpMyFaq Plugin 書評 Delphi apache プラグイン セキュリティ アジャイル Ajax/Web2.0 Zope Ruby eclipse Firefox フレームワーク サーバ 翻訳・日本語化 自宅 scuttle CakePHP 文字化け mojavi CMS phpBB OpenVZ Excel LDAP XAMPP ApacheDS 修正 CodeIgniter 生産性向上 仮想化 taskfreak 言語ファイル HTML::FillInForm Ajax mod_security SBM 情報共有 ダウンロード フリーズ 移転 熱暴走 情報公開 メンテナンス 翻訳 格安 アンケート PhpScheduleIt API レンタル