検索

PHPプロのニュースから辿り。
http://www.phppro.jp/news/304
http://blog.libssh2.org/index.php?/archives/51-Youre-being-lied-to..html

なんっつーかね。ホント、厭だね。多分中の人も、今頃「ああ、メモリ節約できるからってcopy on writeしたり、zval containerのコピーコンストラクタに凝ったりするんじゃなかった・・・」と後悔しているに違いないに10点。

あと、最近のPHPのセキュリティ周りの動向を見るに付け、どうもZend社の信用が徐々に落ちてるような・・・。

http://blog.ohgaki.net/index.php/yohgaki/2007/06/16/phpa_ra_a_ma_sa_sa_ra_ei_airasp

Zend社の社員でありながら、自社製品で動かなくなるようなパッチを作ってどうするよ、という話。

PHPの変数管理、シンボルテーブル周りについてはどうにも愛想が尽きた。PHPに愛想が尽きたというか。この上PHP6でUnicodeが入ってきた暁には、どういった混乱が引き起こされるか今から楽しみでならない。
とにかくいろいろむかつく。PHPのzval周りの関数をトラップするPHP Extension作って、せめて複雑で循環参照の発生する(Compositeパターンとかそれか？)オブジェクトパターンにおいて、「本当に」意図したとおりのzval操作が行われるのか、検証したい。
PHP、ぶちこわしてやりたい。

「残酷なニートのテーゼ」
http://phyphy.zombie.jp/zae09.htm

「残酷なネットのテーゼ」
http://blog.livedoor.jp/dankogai/archives/50863797.html

「残酷な年金のテーゼ」
http://blog.livedoor.jp/dankogai/archives/50863883.html

クラスのメソッドに、PHP関数(言語仕様で定められているissetなど、T_**トークンとして認識される種類)と同じ名前、使えない・・・。

class Hoge {
function isset($arg, ...) { ... }
}
Hoge::isset(...);

→これやると、こんなエラーになってしまう。

PHP Parse error:  parse error, unexpected T_ISSET, expecting T_STRING or T_VARIABLE or '$' in ...

・・・なんじゃそりゃあ！！！！！トークンパースのレベルで衝突しちゃうのか！！・・・く、・・・使えねえ・・・やろうと思えばデフォルトパッケージの、つまりBuildInのサブルーチンすら置換可能なPerlがうらやましい・・・。
っつーか、正直何の為の名前空間だよ、と突っ込みたくなった。真剣に。

yaccとlexの限界か？

サンプル：
http://ml.php.gr.jp/pipermail/php-users/2002-September/010431.html
http://jp.php.net/manual/ja/ref.regex.php
http://www.tin.org/bin/man.cgi?section=7&topic=regex

わかりやすくまとめてあった：

http://www.itmedia.co.jp/enterprise/articles/0507/20/news007.html

大垣さんのブログ。かなりいろいろな反応が寄せられていて、コメントレスが伸びている。良い意味で。

http://blog.ohgaki.net/index.php/yohgaki/2007/06/24/c_ra_a_a_ia_ca_la_lphpa_sa_fa_a_a_a_effa

preg_match()の'm'オプションも忘れがちなので注意～～～。

しかし、ほんと、このやたら長いperma link どうにかならんのかね。

BINDのバージョンを隠すのは見落としていた・・・。
http://www.atmarkit.co.jp/fsecurity/rensai/view05/view01.html

ゾーン情報の転送は、確か・・・制限・・・していた、ような、気が・・・。
確認しておこう。
とはいえ、自分が管理してる鯖は基本的にAll-In-Oneサーバーの一台だけで、運用環境だけ。他の鯖情報も載せて無くて、せいぜいがftpやsmtpやpopのCNAMEだけ。みりゃわかるだろ程度。ゾーン情報使わなくても、普通にdigってるだけで分かるような内容ではある。

my.cnfのmysqlセクションに、こんな設定値がありました。

no-auto-rehash

そもそも、mysqlコマンドでのターミナル上で、table名がtabで補完してくれないよね、というところで、どうもこの設定をコメントアウトするだけで自動補完が効くようです。
試しにコメントアウトしてみたところ、(mysqlセクションなのでデーモンの再起動は不要)確かに、tabキーでselectやdescなどでtable名が自動補完されるようになります。

・・・なんだろ、これ。ということで、どうもman mysqlすると見つかったようです。
no-auto-rehash自体は、"auto-rehash機能を無効化する"設定値で、で、auto-rehashってなんぞやというと。

Enable automatic rehashing.
This option is on by default, which enables table and column name completion.
Use --skip-auto-rehash to disable rehashing.
That causes mysql to start faster, but you must issue the rehash command 
 if you want to use table and column name completion.

だ、そうです。えーっと、つまり、auto-rehashやっておけば手動でrehashコマンドを叩かなくていいですよー、ということ。で、スピード重視であるならば --skip-auto-rehash をしてrehash自体を止めるのがオススメとのこと。ただし、その場合も、mysqlプロンプト上で手動でrehashコマンドを叩けば、table名の自動補完が有効になる。（正確には自動補完用のhashが再構築される）

で、ちなみに、rehashコマンドのショートカットが

\#

だそうです。

「3分LifeHacking：Webページのスクロールキャプチャを極める」
http://www.itmedia.co.jp/bizid/articles/0701/10/news043.html

「質問一覧 「スクロール キャプチャ」を含む質問」
http://q.hatena.ne.jp/list?word=%E3%82%B9%E3%82%AF%E3%83%AD%E3%83%BC%E3%83%AB+%E3%82%AD%E3%83%A3%E3%83%97%E3%83%81%E3%83%A3

はてなの方にもいろいろ出ているが、ITmediaの方の記事が簡潔。

IE : CaptureIt!

FF : "Pearl Crescent Page Server Basic" or "Screen grab !"

Screen grab! の方を入れてみた。Flash付きとかはやってないが、HTMLOnlyな所であれば大丈夫そう。

http://gihyo.jp/admin/feature/02/freebsd-7/0001

4.xBSDは2000年とかにリリースされてる。結構若いみたい。なるほど、それに比べればLinuxのスピードは段違いだよな。

↑のURLに載ってたリリース系譜のコピー：画像/2008/03/04/bsd_keiretu.png