nDiki : 2004年06月上旬

2004年6月1日 (火)

過去の今ごろ

過去の6月1日より。

  • プログラミング言語演習I第6回
    • そういえば、今は Ctrl-] でもIPA(quail)にはいらないな。昔はたまに押し間違えていたっけか。今だと M-x set-input-method で IPA だけれど、まあ使わないよな。
スポンサード リンク

HTTP/1.0 Simple-Response

「ある無線基地局のWeb管理画面の制御をスクリプトでしようとリクエストを送ったら、Status-Line 無しでボディが返ってきたよ」という話。 でRubyのライブラリや wget だとエラーになるとのこと。

HTTP/0.9 Simple-Response

RFC1945 6. Response で、Status-Line をともなわない「Simple-Response」というのが定義されている(HTTP/1.1 RFC2616 にはない)。

HTTP/0.9 Simple-Request (RFC1945 5. Request) を受けた時のみ Simple-Response を送信すべきとあるが must ではないようだ。 HTTP/1.0 Full-Request を送信して Status-Line で始まらないレスポンスを受けたら、Simple-Response とみなすべきとある。

 GET Request-URI HTTP/1.1 CRLF

を受信した HTTP/1.0 サーバが Simple-Request を返しても違反とはいえないのかな。 まぁ行儀が悪いことには違いないが。

Perl libwww-perl の場合

Perl のライブラリをみてみた。

libwww-perlNet::HTTP::Methods::read_response_headers では laxed => 1 が指定されると、Status-Line が無い場合 HTTP/0.9 な 200 と判断するようになっている。

LWP::UserAgent を使うと laxed => 1 が設定された状態で呼ばれるので、Simple-Response もうまく処理できるはず。

Server: GR-HTTPD Server/2.20

Server レスポンスヘッダフィールドにある GR-HTTPD っていうのは国産の組み込みWebサーバのようだ。

[ 6月1日全て ]

2004年6月2日 (水)

結婚記念日

image:http://www.naney.org/img/2004/U/U2004-06-02-0002.jpg image:http://www.naney.org/img/2004/U/U2004-06-02-0001.jpg

帰りに花でも買ってみる(一部は自己満足で、一部は nDiki ネタ用という気持ちがないわけでもない)。花瓶のありかがすぐわからなかったので、暗室用品のメスシリンダーで代用。

ディナーは松屋で。

過去の今ごろ

過去の6月2日より。

父の死

映画ビッグ・フィッシュ」の感想に

私は小6で父を亡くしているせいか、映画の中での父親との死別シーンというのはどうもドライな視点になってしまってあまり感情移入できないのだが、他のひとはどうなんだろう。

書いたところ(両親健在)が「意外だ」と。

単純に考えると、「父の死」を体験している人の方がそうでない人より感じるところがありそうに思えるのだがと。

もちろん人それぞれだと思うのだが、自分の場合はまだ小6だったからな。 その時も特に涙は出なかったし。 その後父がいないのが日常になり、もはや喪失の可能性はなくなった。 死は1度であるから。 逆に父の死という恐怖感はもう無いわけである。

ということで(父に関する)「死の悲しい記憶」も「恐怖」も無いからドライでいられるのかもしれない。

「(父ではなく)自分が亡くなった時、その記憶を思い出す時もドライなの?」との問い。 今後の人生における人の死はもっと重い記憶になるのは間違いない。

[ Perl ] Class::Virtual

先日「Perlでは子孫クラスにメソッドの作成を強制させられない(純粋仮想関数を宣言できない)のがネックだよね」という話をしたのだが、モジュールで実現している人がいた。

CPAN にある Class::Virtual では純粋仮想関数の宣言(呼ばれるとエラーをおこすサブルーチンを定義)をするためのサブルーチンと、継承したクラスで定義漏れのある仮想関数をチェックするメソッドが用意される。

また Class::Virtually::Abstract を使うとコンパイル時に自動的にチェックさせる事ができる。

[ 6月2日全て ]

2004年6月3日 (木)

過去の今ごろ

過去の6月3日より。

Perlプログラムのコードカバレッジ解析

真実32 充分テストをしたとプログラマが自信を持つソフトウェアでも、全パスの50〜60%程度しか網羅していない。 パス・カバレージ・アナライザのような自動化ツールを使うと、網羅率が85〜90%に上がる。しかし、100%のパスを網羅するのは不可能だ。

真実34 ツールを使わないと、不良除去はうまくいかない。デバッガはみんな使うが、カバレージ・アナライザは、ほとんど使わない。

ソフトウエア開発 55の真実と10のウソより。

ということで、Perl 用のカバレッジ分析ツールを探してみる。 CPAN にある Devel::Cover が良さそげ。

Debian BOX にインストール

 apt-get install libtest-differences-perl \
                 libpod-coverage-perl \
                 libtemplate-perl

してから Devel::Coverインストール

 dh-make-perl --cpan Devel::Cover --build
 dpkg --install libdevel-cover-perl_0.45-1_i386.deb

WiKickerコードカバレッジをチェックしてみる。

WiKickerExtUtils::MakeMaker を使ってパッケージ化しており、テストは t/*.t を使用するようになっているので、そのまま分析をする事ができる。

 perl Makefile.PL
 make
 cover -delete
 HARNESS_PERL_SWITCHES=-MDevel::Cover make test
 cover

出力はこんな感じ

 Reading database from /path/WiKicker/source/cover_db


 ---------------------------- ------ ------ ------ ------ ------ ------ ------
 File                           stmt branch   cond    sub    pod   time  total
 ---------------------------- ------ ------ ------ ------ ------ ------ ------
 blib/lib/WiKicker.pm          100.0    n/a    n/a  100.0    n/a    0.0  100.0
 ...cker/App/Configuration.pm   44.1    0.0    n/a   62.5    n/a    0.0   41.7
 ...icker/App/MarkUpAsHtml.pm   38.1    0.0    0.0   66.7    n/a    0.0   34.8
 ...CGI/AbstractController.pm   24.8    0.0    n/a   47.4    n/a    0.0   23.6
 [snip]
 ...ageHtmlFragmentVisitor.pm  100.0    n/a    n/a  100.0    n/a    0.0  100.0
 ...icker/WikiPage/WriNode.pm   96.4   83.3    n/a   88.9    n/a    0.9   93.0
 .../tDiaryFragmentVisitor.pm   32.3    0.0    n/a   33.3    n/a    0.0   29.8
 Total                          59.2   41.3   31.4   67.5  100.0  100.0   56.7
 ---------------------------- ------ ------ ------ ------ ------ ------ ------


 Writing HTML output to /path/WiKicker/source/cover_db/coverage.html ...
 done.

cover_db/coverage.html に各モジュール毎のコードカバレッジが表示される。 また、各モジュールファイル毎のレポートもHTMLで作成され、プログラムの各行毎のカバレッジがプログラムとともに表示される。

なかなかいい感じ。さすがにパスカバレッジはサポートしていない。

コードカバレッジを上げてもバグ0にはなるとは全然言えないのは承知しているが、テスト漏れを減らすための情報として結構使えそうだ。

[ 6月3日全て ]

2004年6月4日 (金)

過去の今ごろ

過去の6月4日より。

Devel::CoverAutoLoader

[ Perl ]

コードカバレッジをチェックするDevel::Coverであるが、AutoSplit / AutoLoader を使っていると分割されたサブルーチンが対象にならない。WiKicker では AutoLoader を多用しているので、ここがチェックされないと意味がない。

ということで Devel::Cover下でテストする時は AutoLoader を使わないようしてみる。

 perl Makefile.PL WIKICKER_NO_AUTOLOAD=1

とした時はExtUtils::MakeMaker::WriteMakefile に PM_FILTER として

 q($(PERL) -e "while (<>) {s!^\\\\s*use\\\\s+AutoLoader.*!!g; s!^__END__!!g; print} print qq(\\n1;\\n); ")

を渡すように Makefile.PL を修正。これで

 perl Makefile.PL WIKICKER_NO_AUTOLOAD=1
 make
 cover -delete
 HARNESS_PERL_SWITCHES=-MDevel::Cover make test
 cover

とすると AutoLoader を使わないバージョンでチェックができる。

[ 6月4日全て ]

2004年6月5日 (土)

過去の今ごろ

過去の6月5日より。

[ WiKicker ] キャッシュまわりにバグ

Memcached まわりをいじったので、キャッシュ具合をテストしていたら変な現象が。 WikiPage が表示されるべきところに、検索結果が表示されている。 あれ?

ページの内容が表示されるところに検索結果が

WiKicker では WikiPage のレンダリング結果も検索結果もキャッシュしているが、それぞれ別のキャッシュキーになるようにしている (WiKickerのバージョンを $V とすると、'$V:h:ページ名' と '$V:s:検索語')ので混ざるはずがないんだけれどな。 キャッシュしているデータの形式も違うし。

最初は Memcached まわりのアップデートで不具合がでたのかと思ったが、戻しても変わらない。ということは、ずっと以前からこの問題が発生していたのか。 やば。 設定でニックネームを設定している(cookie に保存している)と、その Web ブラウザに対してはキャッシュ機能が働かないようになっているので発見が遅れてしまった。

で結局コードをチェックしてみたら「WikiPage 表示と検索結果表示の View クラスを同じにしていたため、検索結果のレンダリングが WikiPage レンダリング結果と同じ領域にキャッシュされる」という風になってしまっていた。 ということで誰かがページ名で検索するとそれがキャッシュされてしまい、ページを読もうとしてもキャッシュ破棄されるまで検索結果が表示されてしまうというひどい状況になっていたと。

修正。

キャッシュキーのバグ

Memcached の出力をチェックしていたら、たまにエラーが起きていることを確認。 Memcachedプロトコルをチェックしたら、キーには制御文字と空白は使えないとある。 Cache::Memcached を見たらキーはそのまま through するだけ。 ということでページ名に空白が含まれている場合などの時には、まずい事になっていたようだ。 こちらは、キーを自前でエンコーディング(ページデータベースファイル名の作成に使っている base64 の亜種)するように修正。

パッチ作り

[ diff / patch ]

そういえばパッチなんて滅多に作らないな。Cache::Memcached のパッチを作った時の手順をメモしておく。 公開する場合のパッチの作り方はこんな感じでOK?

 --- 作成
 tar zxvf Cache-Memcached-1.13.tar.gz
 cp -a Cache-Memcached-1.13 Cache-Memcached-1.13.orig
 emacs Cache-Memcached-1.13/Memcached.pm
 diff -ur Cache-Memcached-1.13.orig Cache-Memcached-1.13 > Cache-Memcached-1.13-5.005_03-20040605.diff
 --- patch する時
 tar zxvf Cache-Memcached-1.13.tar.gz
 patch -p0 < /tmp/Cache-Memcached-1.13-5.005_03-20040605.diff

家庭教師の旦那は一級建築士

の学生時代の家庭教師だった方が最近リフォーム・引越しをし、そのリフォームの話がテレビ東京18:30からの番組「辰巳琢郎の夢リフォーム」で紹介されるというので視聴。

30分まるまるそのお宅の話だった。先生の顔こんなだったかなぁ。

リフォームは、さすが旦那自身の設計とあって夫婦の希望通りという感じ。 「大改造!!劇的ビフォーアフター」のように、デザイナーのひとりよがり(と私は感じる)一工夫が入っていなく無駄がなくていいな。 最初からリフォームを念頭に中古マンションを購入とのこと。

遠いかすかなツテではあるが、なにかの機会があったら頼みたいかも。 しかし「リフォーム代約800万円 (設計費除く)」ってそんな金ないない。

Cache::Memcached 1.13 の Perl 5.005_03 対応

WiKicker で使用しているキャッシュシステム Memcached 用の Perl API Cache::Memcached が新しくなっていたので、入れ換え。

1月に入れた時と同様、Perl 5.005_03 ではそのまま動かないので一部を修正。 前回はCVSスナップショット(Memcached.pm revision 1.8)に対する修正だったので手元で修正しただけだったが、今回はパッチも作っておく。

修正点は

  • our を使わないようにする。
  • fields::new を代替コードに。
  • IO::Handl::blocking を代替コードに。
  • use bytes を使わないようにする。

といったところ(WiKicker で使っているところのみ修正)。

以前は Use of uninitialized value がかなり出ていたのだが、 Cache::Memcached のコード自体が綺麗になったのかこれらも出なくなっていい感じ。

Memcached 1.1.11

Perl API (Cache::Memcached)のアップデートのついでに、Memcached 自体もアップデート

 cd /tmp
 wget http://www.monkey.org/~provos/libevent-0.8.tar.gz
 tar zxvf libevent-0.8.tar.gz
 cd libevent-0.8
 ./configure
 make
 cd ..
 wget http://www.danga.com/memcached/dist/memcached-1.1.11.tar.gz
 tar zxvf memcached-1.1.11.tar.gz
 cd memcached-1.1.11
 CFLAGS='-L../libevent-0.8 -I../libevent-0.8' ./configure --prefix=$HOME/local/memcached-1.1.11
 make
 make install
[ 6月5日全て ]

2004年6月6日 (日)

過去の今ごろ

過去の6月6日より。

パイナップル

めずらしく丸ごと買ってきた奴。 「芯抜く器具無いよ」と思ったが、考えてみたら普通に縦に切り分ければ関係ない。 最初にイメージしたのが輪切りだったので。

パイナップルといえば「おもひでぽろぽろ

父「たいしたもんじゃないな。」

うちで買ったやつは、甘くてなかなかよかった。

http://www.naney.org/img/2004/U/U2004-06-06-0001.jpg

[ WiKicker ] 0.23 リリース

キャッシュまわりのバグを修正した WiKicker 0.23 をリリース。

[ 6月6日全て ]

2004年6月7日 (月)

ハイパー日記システムLog::Log4perl

朝、Naney's Diary をチェックしたらエラーが出てしまっている。 昨日 WiKickerアップデートした事による影響か。

チェックしたところ、ハイパー日記システムではライブラリに HTTP というパッケージがありその中で Request サブルーチンが定義されていた。 これが HTTP::Request モジュールと被っており、今回 WiKicker の更新で間接的に使用されることになった Log::Log4perl の中での new HTTP::Request と衝突する事に。

名前空間大事。

hns の方の HTTP::Request サブルーチンはそのパッケージ内でしか呼ばれていないようなので、HTTP::RequestSub と名前を変更して対処。

過去の今ごろ

過去の6月7日より。

Unison展示会機器のセットアップ

来週の展示会の準備として、数台のWindows BOXにソフトウェアやらデータやらをセットアップ。 まだ確定していないデータなどもあるので、こまめに同期する必要あり。

ということで USB メモリ

  • unison.exe
  • ブートストラップバッチファイル
    • 共通ディレクトリ作成バッチファイル
    • USB メモリと共通ディレクトリのbinを同期させるための Unison 実行バッチファイル
    • 共通ディレクトリをUnisonで同期するためのバッチファイル (クライアント用と daemon 用)

を書き込む。

1台目(マスター):

  1. ブートストラップ関連を USB メモリから共通ディレクトリへ
  2. 共通ディレクトリ下にデータをセットアップ
  3. ブートストラップ関連の変更があれば、共通ディレクトリから USB メモリへ同期

2台目以降:

  1. ブートストラップ関連を USB メモリから共通ディレクトリへ
  2. マスターPCと同期

後はどっかで変更したら適宜同期。

Unisonインストール不要で exe 1個で動くのでこういう時に便利。 Windows だと -fastcheck true にしないとかなり遅いので注意。

時限的な作業で sshd を入れるのもなんなので Unison の Socket メソッドを使っているのだが、この方法だとまったく認証が無いのでちょっと気持ち悪い。 Socket モードでも rsync 程度の認証機能ぐらいは欲しい。

[ 6月7日全て ]

2004年6月8日 (火)

ソフトウエア開発 55の真実と10のウソ読了

いろいろ考えさせられる本。

ウソ5 - ソフトウエアには、もっと開発方法論が必要である。

というのはかなりドキっとさせられる。開発方法論が駄目だとどうすればいいのか。 (状況に応じて)自分なりのパターンを作って適用していくのも意味がないのか。 毎回毎回うんうん唸ってその場限りの作戦を立てなければならないのか…。

よく読むと

筆者の意見は、小文字の m の methodology は善である。 大文字の M の Methodology は悪であり、使う場合は相当の注意を払うべきだ。

とあり、なるほどと。

アジャイル開発エクストリーム・プログラミングに対する話も随所で述べられていて興味深い。

真実23 - プロジェクトが途中打ち切りになる二つの原因のうち、一つは、仕様を凍結できないことだ。

もかなり納得。

技術者もそうだが、ぜひ上層部の人たちに読んでもらいたい。 「見積もり」とか「要求仕様」とか「保守」とか。


[ 読書ノート ] [ お薦めの本 ] [ コンピュータ書籍 ]

過去の今ごろ

過去の6月8日より。

  • 座椅子
    • 1年たたないうちにガタがきた。尻の下のウレタンフォームがどうやらパックリ割れているようなそんな感蝕。ジーンズのベルトにつけっぱなしのカラビナがひっかかって、背もたれにほつれがきているのは自分の問題だ。
[ 6月8日全て ]

2004年6月9日 (水)

過去の今ごろ

過去の6月9日より。

ハッシュとは

新人に Perl のハッシュの話をしていて、ふと隣にいた5年選手のプログラマに「ハッシュって何ですか」と質問してみた。

「キーと…」と連想配列としての使い方は理解していたが、「もしや」と思った通りハッシュ表、ハッシュ関数、チェイン法、開番地法といったことはまったく知らず。 当然、自分で書いたこともなし。

「クラスとかあるから…」

まぁ Java でも C++ でも Perl でも基本的なデータ構造はだいたい何らかの方法で提供されており多くのケースではそれらを使うのがよいのは事実。

しかしハッシュ・リンクリストや各種ツリーは1度は実装した事があるべき。 そもそも原理を理解していないと適切にデータ構造を使い分けられないし、速度・メモリ効率とかの検討もできない。

データ構造とアルゴリズムの基本は(当然)押さえとけ。

誕生日()

本人の前で誕生カードを書くという初の試み (手抜き?)。

[ 6月9日全て ]

2004年6月10日 (木)

過去の今ごろ

過去の6月10日より。

  • Gauche 0.7
    • まただ。いつも「今度は Scheme でも」と思うのだが、すぐやめてしまう。

[ WiKicker ] Acceptor とか ロックとか

HTMLレンダリングなどは WikiPage の構文木に対する Visitor パターンで行っている。

かなりの回数呼ばれるダブルディスパッチ部分、現在は accept の中で 'visit_クラス名' を呼ぶようにしている。 Acceptor クラスの accept メソッドでインスタンスのクラス名を取得してディスパッチしているのだがもったいない。

各サブクラスで明示的に accept をオーバライドするのが面倒なのでそうしていたのだが、今回は Acceptor モジュールを use した時にそのパッケージに accept 定義を作ってしまうように修正してみた。

ロックの方

アクセスが連続的にある時はDBに対して共有ロックがかかり続けるため、書き込みのための排他ロックがなかなか取得できない。 現在はDB全体でロックしているのだが、そろそろ「ページ名リスト」と「各ページ」を別にロックするようにした方がいいかもしれない。

[ 6月10日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィでマネージャー・PO をしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.050047s / load averages: 0.58, 0.56, 0.49
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker