2007年8月アーカイブ

親に頼まれた買い物の請求先住所を会社宛にしてしまったよ。。。

以前、会社で使うメモリを注文する際に請求先を変えたまま、戻すのを忘れていました。あぁ、親に「横領」してるなんて心配されたらどうしよう。

まあ、本当に会社のお金を使う訳ではないので気にしませんが、一応親には届く前に説明しておきます。

MacBookProにシネマディスプレイをつないで2画面で表示している訳ですが、VirtueDesktopsでデスクトップを切り替えると、両画面ともに切り替わるようです。

会社でもデュアルですが、デュアルならいらないだろうと仮想デスクトップは使っていません。なので、あまり考えた事がなかったのですが、何もしなければすべての画面が1つのデスクトップとして扱われるんですね。

ひとまず、ログイン項目から外しておこう。

Scrybeのinvitationが来た

かなり前に応募(?)したのですっかり忘れてました。

メールを読む限りでは、まだBetaテスト中のようです。正直、何のアプリか忘れていて、「あ、プレゼンアプリだっけ」なんて思ってました。ガイドラインを読んだりアプリ自体を触って、何となく思い出してきました(まだ、ぼんやりですが)。

「スケジュールを折り畳める形で印刷してくれる」とかでしたね。オフラインのは何だったか思い出せません。

なんだか、Flashが新鮮。

ノリで注文した"DVI to ADC Adapter"が今朝届きました。

PowerMacG4で使っていたシネマディスプレイが古いせい(?)で、MacBookProに直つなぎできませんでしたが、これでつなげるようになりました。

いやぁ、しかしでかいですね、アダプタ。もう少しでMac Miniじゃないですかね。

実は、ついでに新しいApple Kyboard(JIS)も購入したのですが、使い心地は不思議。平たいからかな。Caps Lockが右下にある事にちょっとびっくりしました。

さて、そろそろリンゴ祭りに浮かれる時期は終わりかな。


キーボードのアルミが冷たくて気持ちよい。

何の事か伝わりにくいかもしれませんが、そういう事です。

OSXでは、Cmd+Tabで起動中のアプリケーションを切り替える事ができます。で、Cmd+Tabで切り替えメニューが表示されたときに、Cmdキーを離さない限りは切り替えは行われません(表示的に)。ところが、フォーカスしたままCmdキーを離さず、Tabキーを離してQキーを押すとフォーカスしたアプリケーションが終了します。

大事な作業をしていた訳ではないので問題ありませんでしたが、知らなかったのでびっくりしました。MacBookProのTabキーは多分普通のキー(Qとか)よりも小さいので、油断できませんね(?)。

さて、相変わらずアプリケーションの切り替わりがおかしいままですが、あきらめず探っていきます(多分)。

どこで設定するのだろう?

  • アプリを終了したときに直前に選択していたアプリが選択されない
  • ドロップしたらドロップ先のアプリにフォーカスが移る

ひとまず、上記2点をどうにかしたい。

ヘルプには"Ctrl+Shift+J"と書いてあるけど何もおきない。
Mozilla Japan - Thunderbird サポート - キーボードショートカット

Google経由で調べたら、"Ctrl+Shift+C"との事。隣の人の手の動きを中々トレースできなかったけど、これでスッキリ。

mod_top

mod_topなんていうツールがあったんですね。

mod_top is a production monitoring tool for LAMP applications with user interfaces modeled after the popular unix top. mod_top plans to support PHP, Perl, Ruby, Python, mySQL, Postgres, Apache1+2 on Linux.
mod_top LAMP PHP Ruby Rails Perl MySQL Postgres application monitor

lamp1701dというデーモンを動かしておくと、mod-topコマンドでサーバ上のプログラムの実行状態の様なものをみれるようです。

PHPプログラムをCLIで動かしただけですが、etchで動作する事は確認できました。興味深いです。


会社のcoLinuxでも試してみようかな。

Terminal.appでは送れない(?)キーがあるので、iTermを試しています。

例えば、Emacsのundoに割り当てているC-/とか、バッファ送りに割り当てているC-.とかC-,とか。とりあえず、C-/でundoができるようにすることが狙いです。

PowerMac時代はレンダリングの遅さにあきらめていたのですが、MacBookProにしたら特に違和感なく使える速さな気がします。何ですかね。パワーが関係してるんでしょうか。それともフォース?

iTermを日本語環境で使うと、optionキーをmetaキーとして使えないようですが、これはあきらめました。USにするのも面倒だし、パッチ当てるのも面倒。
blog.8-p.info: 日本語環境の iTerm で option キーを meta キーにする
とりあえず、(escは遠いので)C-[を使って何とかなるような気がします。emacsが使えればいい気がしてるので。だめかな。

なんだかんだでTerminal.appを使ってしまいそうですが、とりあえずレンダリングに関しては問題を感じなくなりました(多分)。


Terminal.appでC-/とC-.とC-,を送れるようにする事はできるんですかね?

このブログに貼っている"あわせて読みたい"をなんとなしにみてみたら、身内(といっていいのかな?)のブログが。

まあ、PHPとRSSについて結構書いてきたので当然ですがね。

夏バテかな

お昼食べてからどうもおかしかった。

うなぎ食べてないからかなぁ。

HTML形式のドキュメントをいろいろ集めています。

Apache2.2
apache2-doc(aptitude)
MySQL4.1, 5.1
MySQL ABで配布されているHTML
PHP5
php.netで配布されているHTML
PHPUnit
ポケットガイドをsvnリポジトリからチェックアウトしてビルド
SQLite3
sqlite3-doc(aptitude)
Django
svnリポジトリのdocs/にある.txtをそのまま利用
Subversion
Subversion BookのCHMを展開(Subversion Bookのサーバにつながらなかった)
SVK Book
ソースをsvnリポジトリからチェックアウトしてビルド
Python2.4
python.jpで配布されているHTML

もちろん、Hyper Estraierで検索できるようにしています。

さて、あとは何があっただろうか。

Parallels DesktopのゲストOS

"Parallels Desktop for Mac"でWindows XPとetchをインストールしてみました。

Windows XPはかなり昔に購入したもので、Windows2000からのアップグレード版です。SPはどうだったかな。

推奨されている高速インストールを選択してインストールしてみましたが、キー操作もマウス操作も反応がありません。少し情報を集めてみたりしましたが、さっぱりです。

という訳で、カスタムインストールでやり直したところ、無事操作できるようになりました。原因はよくわかりません。

さて、取り急ぎWindowsでしたいことがある訳でもないので、アップデートのインストールなどでいったん終了。

引き続き、etchをインストール。netinstallのisoを使って普通に作業完了。CUI環境でaptitudeが動くのでよしとします。osxをできるだけいじらずにetchで開発作業を進めたいので、これから少しずつ環境を整えたいと思います。

わりとさくさくできていい感じです。

PCセットアップ一区切り

木曜日からリンゴ祭りな訳ですが、とりあえず基本的なアプリのインストール作業は一段落しました。

以下、勢いに乗って入れておきました。

1) QuickSilver
http://quicksilver.blacktree.com/
2) CarbonEmacs
http://homepage.mac.com/zenitani/emacs-j.html
3) SIMBL
http://culater.net/software/SIMBL/SIMBL.php
4) SafariStand
http://hetima.com/safari/stand2.html
5) PresButan
http://alum.hampshire.edu/~bjk02/software.htm#presbutan
6) MacPorts
http://www.macports.org/
7) Xcode
http://developer.apple.com/tools/download/
8) Utilities
  • subversion
  • zsh
  • screen
  • coreutils
  • lv
9) VirtueDesktop
http://virtuedesktops.info/
10) Parallels Desktop
購入
11) iWork '08
購入
12) Joost
https://www.joost.com/
13) Firefox(lzyc; intel)
http://fox.lazycat.info/
  • Google Browser Sync
  • All-in-One Sidebar
  • Copy URL +
  • Firebug
  • YSlow
  • Live HTTP Headers
  • Sidebar on Right
  • Tabbrowser Preferences
  • Web Developer
  • GrApple (EOS)
14) Witch
http://www.manytricks.com/witch/
15) M+ OUTLINE FONT
http://mplus-fonts.sourceforge.jp/mplus-outline-fonts/index.html
16) ソフトウェア・アップデート
apple

アプリケーションじゃないのも混ざっていますが、まあそれはそれ。本当に基本的な有名どころだけを入れておきました。

これから、PowerMacからのデータ以降や、ParallelsのVM作り。ほか、開発環境など。やることはたくさんですが、チョビチョビいこうと思います。

しかし、熱い。暑いせいで熱くて暑い。室温を快適にしておかないとまずそうです。

さて、DVI-ADCアダプタキットを購入すべきか悩みどころです。しばらくはPowerMacと併用するつもりなので、シネマディスプレイを持て余すこともありませんが、後々のことを考えれば手元においておいた方がいいのかも。でも、1万円オーバーかぁ。

そんなこんなで、嬉し恥ずかしリンゴウィークまっただなかです。

はぁ、またしてもドキュメントを読んでいないことが露呈しました。

ALTER TABLE の処理では、元のテーブルの一時的なコピーが作成されます。 変更はこのコピーに対して実行されます。その後元のテーブルが削除され、新しいテーブルの名前が変更されます。この変更処理は、すべての更新が、エラーになることなく、確実に新しいテーブルに自動でリダイレクトされるように実行されます。ALTER TABLE の実行中、元のテーブルは他のクライアントによって読み取り可能です。このテーブルの更新とテーブルへの書き込みは、新しいテーブルの準備が整うまで停止されます。

注意: RENAME 以外のオプションを ALTER TABLE に指定した場合は、厳密にはデータをコピーする必要がないとき(カラム名の変更時など)でも、必ずテンポラリテーブルが MySQL によって作成されます。これについては今後修正する予定ですが、通常 ALTER TABLE はそれほど頻繁に使用されないため、TODOリストにおけるこの修正の優先順位はそれほど高くありません。 MyISAM テーブルについては、myisam_sort_buffer_size 変数に高い値を設定することによって、インデックスの再作成部分(再作成プロセスでもっとも処理が遅い部分)を迅速化することができます。
MySQL AB :: MySQL 4.1 リファレンスマニュアル :: 6.5.4 ALTER TABLE 構文

なるほど、どうりでディスクフルになるわけですよ。対象テーブルのサイズは空き容量を超えてますから。

どうしたものか。。。

りんごぅ!

おお!おお!おぉぅ!

蝉がやたらと元気

蝉が部屋の玄関の前に転がっていたので、「おぉ、一週間経ったのか、お前」と思いながらも、つついてみたら元気に復活。荒れ狂うように飛び回っていた。

数時間経って日をまたいだ今。阿呆の子のごとく鳴き狂っている。

なんとなく、会社に行かなければいけない気になってしまう。

今何時だと思ってんのっ、あんた!

りんご臭

猛省中ですが、ついつい浮かれてしまう今日この頃。ホント、駄目な人です。

週末あたりにやってきそうな予感(受け取れるのがね)。むしゃぶりついてやりますよ、もう。

ちなみに、今日の朝には桃がやってきました。両親からの送りもの。

恥ずかしさのあまり、穴を掘ってでも穴に入りたい気分です。

PHPのセッションは、session.gc_maxlifetimeに従ってGCされますが、このsession.gc_maxlifetimeが適用される範囲がsession.save_pathだという事を見落としていました。session.gc_maxlifetimeを変える場合は知っていなければならない事ですが、どうやら勝手に勘違いして自分に都合の良い解釈をしてしまっていたようです。本当に恥ずかしいです。

注意: 異なる値を session.gc_maxlifetime に指定している 別々のスクリプトがセッションデータの保存場所を共有している場合、 一番小さい設定値に達した時点でデータが消去されます。このような場合には、 お互いに session.save_path を使用します。

注意: デフォルトのファイルに基づくセッションハンドラを使用している場 合、使用するファイルシステムは、アクセス時間(atime)を記録できる 必要があります。Windows FATはこれができないため、 FATファイルシステムまたはatimeの記録ができない他のファイルシス テムで問題を発生した場合は、セッションのガベージコレクト処理を 行う他の手段を用意する必要があります。 PHP4.2.3以降、atimeの代わりにmtime(更新時刻)が使用されます。 このため、atimeが利用できないファイルシステムでの問題は無くなりました。
PHP: セッション処理関数(session) - Manual

php.netのセッションに関するドキュメントに(日本語で)ちゃんと書いてあります。セッションのGCはmtimeとsession.gc_maxlifetimeを利用して、有効期限切れのセッションファイルを回収するわけです。セッションデータにメタデータとして有効期限が格納されるなんて事は無いわけです。あっても、それはデフォルトのハンドラでは無いわけです。

つまり、session.save_pathを同じにしたままsession.gc_maxlifetimeが異なるスクリプトを動かしていたせいで、より短い方の有効期限でセッションが破棄されてしまっていました。

はぁ。いつになったら、胸を張って「技術者です」と言えるようになるのでしょうか。。。

レスポンスヘッダに"Content-Encoding: deflate"とある場合、HTTP_Requestはデコードしない模様。
Request #11246 Problem with deflate encoding

HTTP_Requestは、リクエストヘッダのContent-Encodingを探し、その値がgzipだった場合に自動的にデコードしてくれます。ところが、"Content-Encoding: deflate"の場合にはデコードしてくれません。ソースを読む限り、gzip圧縮の判定を「Content-Encodingの値がgzipである場合」としており、それ以外についてはどこにも記述されていません。deflateは無視しているようです。

gzipのデコードは_decodeGzipメソッドで行われます。PHPにはgzinflate関数が用意されており、_decodeGzipメソッドでも伸長処理にはこれを使っています。ただし、RFC1952に従ったパース処理などを行ってから、gzinflate関数を実行します。このため、deflateのデコードを_decodeGzipメソッドで行うのは駄目っぽいです。

ひとまず、deflateの場合はgzinflate関数で伸長するようにしてその場をしのいでおきます。


Zend_Http_Response::decodeDeflateでは、gzuncompress関数を使っているようです。一方で、Zend_Http_Response::decodeGzipではgzinflate関数を使ってるのはなぜでしょうか。やはり、deflate圧縮とgzip圧縮について深追いしないと駄目でしょうか。

PHPのドキュメントに、「HTTPサーバの言うdeflateとPHPの言うdeflateは違う」というようなことが書いてありました。

Take care that that "PHP deflate" != "HTTP deflate".

The deflate encoding used in HTTP is actually zlib encoded.

This is what PHP functions return:
gzencode() == gzip
gzcompress() == zlib (aka. HTTP deflate)
gzdeflate() == *raw* deflate encoding
PHP: gzdeflate - Manual

RFCを見てみると、なんだかんだでzlibとの事。つまり、PHPのgzuncompress関数を使うのが正しい模様。

The "zlib" format defined in RFC 1950 [31] in combination with the "deflate" compression mechanism described in RFC 1951 [29].
RFC 1951 [29] に記述されている "deflate" 圧縮メカニズムと結合した、RFC 1950 [31] にて定義されている "zlib" フォーマット。
ハイパーテキスト転送プロトコル -- HTTP/1.1

(gzinflate関数で解決できた)URLについてgzuncompress関数を使うようにしたところ、gzuncompress関数がfalseを返しました。とりあえず、gzuncompress関数→gzinflate関数という体制でやっておくことにしてみます。

また別のURLについて試したところ、gzuncompress関数で正しく処理され、gzinflate関数でfalseとなりました。サーバによってはdeflateのデータフォーマット(?)が違うようですね。

大失態を逃げの一手でごまかすべきか、悩みどころです。

素直に、新たなリンゴスターを受け入れるべきか。

とりあえず、温泉宿のパンフレットでも貰ってきますかね。

v1.4.1で、LocationヘッダをallowRedirectsオプションで自動的に処理する場合、パスが空だと"GET HTTP/1.1"のようなリクエストラインでリクエストするようです。

Locationヘッダのフォローの際、setURLメソッドを使わないでリクエスト先のURLをセットしていますが、このときにパスについて何もしていません。なので、パスが空だった場合(http://www.example.comとか)、パスは空のままです。

パスが空だとしても、リクエストラインに使うRequestURIを正しく組み立てればよいのですが、ここ(_buildRequestメソッド)でもパスはそのまま使われてしまいます。v1.3.0だと、空の場合は'/'で置き換えているんですが、v1.4.1ではその処理が消えています。

先ほども書きましたが、通常のリクエストとリダイレクトのフォローとで何が違うかといえば、setURLメソッドを使うか否かです。つまり、パスが空だったときに'/'で置き換えるか否かです。

以下、テストコード。

<?php
 
/**
 * 'http://lab.koshigoe.jp/pear_http_request_141_redirect.php'
 *   --> http://pear.php.net
 */
 
require_once 'HTTP/Request.php';
 
$url  = 'http://lab.koshigoe.jp/pear_http_request_141_redirect.php';

$http = new HTTP_Request($url, array('allowRedirects' => true));
 
$res  = $http->sendRequest();

if (PEAR::isError($res)) {
    echo $http->_buildRequest() . "\n";
    echo $res->getMessage() . "\n";

}
 
/** (output)
 * GET  HTTP/1.1
 * Host: pear.php.net
 * User-Agent: PEAR HTTP_Request class ( http://pear.php.net/ )
 * Connection: close
 * Accept-Encoding: gzip
 * 
 * 
 * Malformed response.
 */
 
?>

ひとまず、以下のようなパッチでごまかしてみました。

--- Request.php 2007-05-19 04:24:29.000000000 +0900
+++ Request.php-new     2007-08-09 16:39:07.000000000 +0900

@@ -761,8 +761,7 @@
 
             // Absolute URL
             if (preg_match('/^https?:\/\//i', $redirect)) {

-                $this->_url = &new Net_URL($redirect);
-                $this->addHeader('Host', $this->_generateHostHeader());
+                $this->setURL($redirect); // Bugfix: 2007/08/09, set '/' if path was empty.

             // Absolute path
             } elseif ($redirect{0} == '/') {
                 $this->_url->path = $redirect;
@@ -877,7 +876,7 @@

 
         $host = isset($this->_proxy_host) ? $this->_url->protocol . '://' . $this->_url->host : '';
         $port = (isset($this->_proxy_host) AND $this->_url->port != 80) ? ':' . $this->_url->port : '';

-        $path = $this->_url->path . $querystring;
+        $path = (empty($this->_url->path)? '/': $this->_url->path) . $querystring; // Bugfix: 2007/08/09, set '/' if path was empty.

         $url  = $host . $port . $path;
 
         $request = $this->_method . ' ' . $url . ' HTTP/' . $this->_http . "\r\n";

リダイレクトURLが絶対URLだった場合に、setURLメソッドを使って情報を更新し、リクエストを作る際にパスが空だったら'/'に置き換えるだけです。リクエストを作るときだけを直せばよいはずですが、一応。

で、バグか分からないながらもバグ報告を出そうと思ったわけですが、気づいてしまいました。英語書けません!どうしましょう。

やってしまった

さて、どうしたものか。。。

メモリ4GB購入

会社のPCですが、VM(coLinux)の重さに我慢出来なくなったので、メモリを4GBほど買ってもらいました。

これで、運用環境のDBを使った作業が快適になってくれればいいんですが。とりあえず、coLinuxのメモリを512MBから1GBに増やしておきました。それでも駄目なら1.5GBまでは許容範囲です。

チップセットか何かに問題があるのか、3200MBしか認識できていないっぽいですが、全部同じ製品でデュアルチャンネルでとか考えて、このまま1GBの4枚差しを貫きます。一応、BIOSは新しい(と思われる)もので書き換えたんですが、どうも効果はない模様。まあ、2年以上前の安いやつですからね。

さて、話は変わりますが、Mac Pro凄いですね。Apple Storeで全部付けて見積もると210万円超えますね。3GHzの4コア2基とか、メモリ16GBとか、HDD3TBとか、30インチ2枚とか。何していいか分かりませんね。映像とかなんですかね。

1コア1VMと考えてみると、OSX+7VMですか。メモリは2GBずつで、HDDは375GBずつ。ディスプレイはOSXに1枚でVMで1枚かな。いっそ、OSXを8個くらい動かしてみますかね。


ローンかぁ。でもなぁ、時代はノートっぽいしなぁ。あー、爆発するしなぁ。ハンズオン出たかったしなぁ。そこそこの車買えるしなぁ。バイクもいいなぁ。そもそも自宅作業じゃ、モンスターマシンなんかいらないしなぁ。今のPowerMacG4がかわいいしなぁ。

HTTP_Request_Listenerなんてあったんですね。
PEAR :: Manual :: HTTP_Request_Listener

connect, sentRequest, gotHeaders, tick, gzTick, gotBody, dissconnectというイベントを補足し、その際の処理を記述出来るという事らしいですね。

元々は、Keep-Aliveについて「新しいので対応したような気が…」という事で調べていたのですが、棚からぼたもちです。1.3では無かった機構ですよね?あったかな?

何はともあれ、とりあえず触ってみました。ドキュメントのコードを少し変えて動作を確認した程度ですが、以下サンプルコードです。

『ウェブアプリケーションセキュリティ(金床 著)』を読んで初めて知りました。なるほど、ログ監視のメールにGoogle AnalyticsらしきURLがあったのはそういうわけですか(?)。

ページの中に別サーバの画像があると、まとめてページが置かれているサーバにリクエストを投げてしまう事があるとか。細かい情報は書かれていなかったので、バージョンがいくつかとか修正済みなのかとかは分かりません。名前解決をさぼるという事なのでしょうか?

この現象によって別サーバ(ドメイン)の管理者にCookieの内容が伝わってしまう事があるようですが、狙ってできる事でもないようです。

さて、このバグは修正済みなんでしょうか?

プロフィール

このアーカイブについて

このページには、2007年8月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2007年7月です。

次のアーカイブは2007年9月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。