プラグインリアクション:2004年10月24日日曜日DBDesigner4フリーのデータベースのモデリングツールDBDesigner4を試してみました。気に入った点は-直感的に使える。-動作が軽快(テーブル定義しまくるとちょっと重くなるが許容範囲)-リバースエンジニアリングできる。PostgreSQLで出来ないのは残念)-HTML出力ができる(仕様書代わりになりそう)-保存形式がXMLなので他のアプリで使い回せそう。使ってみようと思います。モデリングツールリアクション:2004年10月22日金曜日mod_perl使用時はMaxClientsの値に気をつけましょう導入するだけで既存のCGIスクリプトがお手軽に10~200倍高速になるmod_perlですが、mod_perl自体がサイズがでかいのと、高速化のため、モジュールをキャッシュするため、apacheのプロセスサイズが結構大きくなってしまいます。経験的にはだいたい1プロセスあたり20~30MByte位にはなります。このような性質上、mod_perlを使う場合はメモリの使用量を考えなくてはいけません。ところで、Apacheのデフォルトの設定ではMaxClientsの値は150に設定されています。これは同時に最大150のリクエストをさばく、つまり最大150まで子プロセスを同時に生成するということです。仮に150個の子プロセスを生成するとすると、mod_perlを利用時の1プロセスのサイズをおよそ20Mbyteとすれば20×150=3000[MByte]=3[GByte]のメモリを必要とすることになります。この場合、スワップ領域を含めてメモリの容量が3[GByte]に満たないサーバはすべてメモリを使い切り、最悪落ちることになります。いうことでほんとに落ちるかどうか実際に試してみました。方法はApache付属のベンチマークツールabを使い同時アクセス数100、で1000回のリクエストを送るというものです。http://targetsite.hostname/対象サーバのスペックはCPU:Pentium3の600MHz、メモリ:512MByte、スワップ領域は1GByteです。結果はというと、、abはタイムアウトで測定不能となりました(当たり前)。ab終了後のサーバにも問題が。サーバが落ちることはなかったんですが、abはタイムアウトで終了しているのにめちゃめちゃサーバのレスポンスが悪くなってしまいました。sshでの接続にも数十分かかる始末。事でログインし、Apacheを終了させるとようやくレスポンスが生き返りました。結論、mod_perlを使うときはMaxClientsの値に注意しましょう。Apacheのデフォルト設定で運用すると最悪サーバが落ちます。Apacheの1子プロセスのサイズ」でおおざっぱに計算できます。今回試したサーバでは512/20=25位に設定しておけば、メモリを使い切ってサーバが落ちる危険がなくなります。perlリアクション:Gmailに転送したらピンポン以前から使ってみたいなーと思っていたGmailですが、先日kaoponさんにinvitationを頂き、ついにアカウントを手に入れました!快くinvitationを送っていただいたkaoponさん、どうもありがとうございました!僕は普段Becky+IMAPでメールをみているんですが、メールの検索が遅くて困るんです。そこでGmailにもメールを転送して、検索はGoogleの強力な検索機能を利用しようと考えました。.procmailを編集しGmailにも転送するように設定しました。問題なく動いていたんですが、少ししたら、あやしい添付ファイル付きのメールがピンポンしはじめました。Gmailは怪しい添付ファイル付きのメールをはじき返すみたいです。はじき返したメールがまたGmailに転送されてまたはじかれる、、そうやってピンポンしてたんですね。対策としてとりあえず、PostmasterとかMailer-DaemonからくるメールはGmailに転送しないように設定しておきました。これで今のところ、うまくいっているみたいです。ループリアクション:2004年10月20日水曜日MT3.1にアップグレードしたけど、、MTを3.1にアップロードしてみたところmod_perl環境で動かなくなっちゃいました。エラーログとソースを眺めてみると、なんかApache:::Requestのオブジェクトができてないっぽいです。原因究明する時間がないのでとりあえずCGI環境で動かすことにします。コンテストが開催されている。「ゴッゴル」という単語で検索して一番上に表示された人が優勝!海外で行われたSECコンテストでは指定された単語を使ってエントリーを書いただけで優勝したっていってたので、意外と上位に食い込んだりしないかなー。いやー、今日はなんだかんだで7ゴッゴルは稼げましたよ。あそこで滑った時には今日は2ゴッゴル止まりかとひやっとしましたが最後のジャンプで4ゴッゴル出せたのがよかったです。あのとき滑らなければ久しぶりに10ゴッゴル越えがねらえたんですけどねー。無駄にゴッゴルってみました。昨日買ってきた無線LAN機器からアクセスできるようにと、久しぶりに自宅の無線LANアクセスポイントの設定を変更したら、書き込みに失敗したのか、全く無線LANを使えなくなってしまいました。電源を抜き差ししてみたり、初期化ボタンをおしてみたり、一通りのことはしてみましたが、症状全く変わらず。修理に出しても時間もお金もかかるし、なにより今のは11bにしか対応していない古いものなので、これを機に新しく買うことにしました。kakaku.comで調べてみると、WHR3-AG54/Pという製品が人気があって、値段も手頃でよさそう。このとき一番安い店はPC-Successだったのでのぞいてみると、たまたまWHR3-AG54/Pがタイムセール中!限定10台¥10,980で売り出されてました!これを逃す手はないと即購入しちゃいました。紹介したSledge::Template::TT::Shift_JISのtarボールを作成しました。テンプレートファイルをShift-JISでかけるようにするSledgeは出力するコンテンツがShift-JISの場合でもテンプレートはEUC-JPで書く仕様になっています。僕の会社では基本的にHTMLの文字コードはShift-JISということになっているのでコーダーからあがってくるHTMLは当然Shift-JISです。これをテンプレート化するにはパラメータの埋め込みの他、文字コードをEUC-JPに変換をしなければなりません。一括変換すればすむ話ですが、それがちょっとめんどくさい(笑)ということで、テンプレートをShift-JISで書くためのSledge::Template::TTのサブクラス、Sledge::Template::TT::Shift_JISを作ってみました。Sledge::Template::TT::Shift_JIS;に変更するだけです。Sledge::Template::TT::Shift_JISのコードはこんな感じです。$output;}1;最初は下のようなコードを書いたんですが、テンプレートのオプションのfilenameがスカラーリファレンスだとSledge::Tempate::TTのリビジョンが1.3より以前のものでは動かないことに気づいて、Sledge::Tempate::TTのコードをそのまま借りてきて、文字コード変換を差し込んだ結果、上のようなコードに落ち着きました。ベータ版がダウンロード出来るようになったので、僕も早速ダウンロードして、インストールしてみました。Searchとは、簡単に言えば自分のパソコン内のファイルに対してGoogleを使った検索を行うためのツールです。現在検索の対象となるファイルはOutlook、OutlookExpressのメール、AOLメッセンジャーのチャットの内容とか、エクセル、ワード、パワーポイント、テキストファイル、Webの履歴だそうです。使ってみましたが、エクセルとかパワーポイントの検索が熱いですね。ローカルファイルを高速に検索できますし、日本語も使えますし、かなりいい感じです。どこにファイルを保存したかをすぐに忘れてしまうB型の僕にとってはまさに救世主の登場です。ソフトリアクション:2004年10月14日木曜日Sledgeでセッションを使わないときSledge::Doc::FAQにも書いてあるようにセッション管理が必要ない場合はconstruct_sessionを空のメソッドでオーバーライドすればいいのですが、さらにcreate_managerも空メソッドでオーバーライドしておけば、SessionManagerもuseしなくてすみます。これでほ~~んのちょっぴりメモリが節約できます。詳細を見るAmazonでドラクエ8の予約を受付中です。15%OFFの¥7,854円で買えるみたい。300円キャッシュバックらしいので、実質¥7,354てことですね。perlでtry~catch構文。Error.pmでどうやってるのかと不思議だったんだけど、謎が解けた。中カッコは無名サブルーチン、catchはサブルーチンへのリファレンスを受け取ってそのまま返すだけのサブルーチン、tryは無名サブルーチンを二つ取るサブルーチン。perlの文法で書けてるわけね。遅れそうだったので、駅まで走ったら若干筋肉痛になった。高品質なWebアプリケーションの開発手法ここ最近、高品質なWebアプリケーションを効率よく開発するにはどうしたらいいかということを真剣に考えています。いうのも、今まで構築してきたシステムにプログラムのバグが立て続けに発生するようになってきたためです。今までのプログラマ個人主義の開発体制の限界がきたのかもしれません。この問題を解決するために、まずはシステムになぜバグが発生したのか、その原因を把握することから始めたいと思います。単純にテストが足りないユーザは時として、プログラマが予測しないようなデータを入力してきますし、XSS、SQLインジェクションなどをねらった悪意あるデータを入力される可能性もあります。それらの想定される様々な入力に対して十分なテストが行われていないと、一見正常に動いているように見えても、後々バグが見つかるということになってしまいます。システムのあまり重要でない機能に多いのですが、単純にプログラムのアルゴリズムが間違っていたなんていうはずかしいバグもありました。何の開発手法も確立していない状態で、数年にわたりシステムを継続的に開発していくと、コードはスパゲティのように複雑に絡み合い、あるバグの修正が別のバグを引き起こすというようなひどい状況になりえます。数年前のプロジェクトということもあり、ソースコードの管理がきちんと行われていなかったりして、修正したつもりがデグレードというような恐ろしいことも起こりえます。このケースではクライアントさんとの付き合いも長くなっているので、問題は深刻です。開発担当者はもういない古いプロジェクトになるとそのシステムを開発した人間がすでにいなくなっているケースです。バグが発生したときには仕方なく今いる人間が、ソースコードを読み直し、システムの内容を把握、そして修正を行わないとなりません。コーディング規約などが整備されていないため、なれない人間だとソースコードの解読にかなりの時間を要します。このような非建設的な事柄に貴重な時間を浪費してしまいます。問題可決には何をすべきかこうやって、失敗したケースを並べてみると何をしたらいいのか何となく見えてきます。おおざっぱにまとめると以下のような感じでしょうか。テスト方法の整備コーディング規約の整備ドキュメントの整備ではこれらをどう実践していくかということですが、XP(エクストリーム・プログラミング)という開発手法を応用することで、うまくいきそうな気がします。XPというとペアプログラミング、テストファーストという言葉がすぐ浮かんでくるんじゃないかと思いますが、物事をできるだけシンプルに考えようという姿勢が僕は好きです。開発速度が上がることも期待できそうです。開発速度について、はてなのnaoyaさんのWeblogには以下のように書かれています。NDO::Weblogフレームワークを使って、もう一人のエンジニアとのペアプログラミング。毎朝にスタンディング・ミーティング(立って会議)をして仕様を策定し、二日ちょっとで作り上げました。いいとこ取りをした開発スタイルに依るところが非常に大きいです。XPとフレームワークを利用して、3日で機能を開発したそうです。他にもXPを導入している会社の話をちらほらと聞きますし、どうやらWebアプリケーション開発にXPが有用なのは確かなようです。単純にテストが足りない。これを解決するためにはテスト方法を整備しなければなりません。XPではテストを機能テスト、単体テストの2つに分けて行います。機能テストはユーザ(クライアント)がこのように動いてほしいと思った通りの挙動を示すかのテストで、単体テストはプログラム内の各オブジェクトのメソッドが期待通りに動くかのテストです。前者はテストの性質上、ユーザ側に行ってもらうのが理想です。いってもクライアントによってはWebの知識があまりない場合も多いので現実的にはディレクタがユーザと話し合ってテストケースを決めるという形になるでしょうか。後者の単体テストはプログラマの仕事になります。ここで重要なのがテストもプログラミングするという点です。テストスクリプトを作成し、残しておくことで繰り返しテストを行うことができますし、様々な良い副作用も期待できます。これらの2つのテストをきちんと行うことで、バグはグンと減ると考えられます。ペアプログラミングを行い、もう一人の人間がテストケースを考えるというようにすれば、さらにバグの比率は減るでしょう。長期の継続的な追加開発によるシステムの破綻XPを使うことで、このケースも失敗のリスクを減らすことができます。機能を追加するごとに単体テストを行うことを義務づけます。テストはテストスクリプトとして残っているため、それを毎回実行することで、ある機能を実装したおかげで別のところにバグが生じた場合も事前にそれを見つけることができるようになります。CVSなどのリソース管理システムを導入し、リソースを管理することでデグレードの危険を回避します。開発担当者はもういないこれを解決するにはドキュメントの整備が必要ですが、得てしてプログラマはドキュメントを書くのが嫌いです(偏見?)。XPでは単体テスト用に書いたテストスクリプトがそのままドキュメントになり得ます。メソッドがどのような振る舞いを期待されているかがテストをみればわかります。プログラマにとっては文章でまとめられたドキュメントよりもこちらの方がシステムを理解するのに役立つのではないでしょうか。いない誰かが書いたテストケースをすぐに実行できます。自分の修正が正しいのかもそれで確認ができます。自分のせいでシステムが壊れていないかも確認できます。テストスクリプトを書くということにはこのような副作用もあるんです。XPをいきなりどかんとすべて導入というのはちょっと無理があるので、まずはコーディング規約の整備、単体テストの義務づけあたりからやっていこうかと思います。エクストリーム・プログラミングリアクション:ブログを借りる前にここを読め。待て、ブログを借りる前にここを読め。タイトル通りブログを借りる前に読むブログです(笑)。各レンタルブログの情報が詳しく載っていて非常に参考になります。おそおそランキングはサービス提供者にとっては嫌でしょうねー。旅行にいっている間にBloglinesがWebサービスを公開してました。miyagawaさんがすでにこのWebサービスを簡単に利用するためのperl用API、WebService::Bloglinesを公開してました。