May - 11th
PEAR::PEPr::Package Proposals
Posted at 1:18 pm | Filed Under PHP
PEARのパッケージ候補がズラリ並んだページ。こんなのあったなんて気づかなかった。
ざっと眺めると、GoogleのWebサービスやOpenSSLによる暗号化などありそうでなかったものがけっこう見つかる。
scraping用パッケージが追加されるともっといいかも。
May - 8th
JavaとPHP、自動化ツール、不毛な争い
Posted at 12:23 am | Filed Under PHP, Work
久しぶりに不毛なJava対PHPの議論を耳にした。
趣旨としては、PHPの開発ツールの乏しさ（Javaと比較して）をブチ上げて、カイシャの発展のために今後はJavaで開発すべきだ、というもの。
あのさあ。
まず第一に、これまでのPHPでの開発実績をポンと捨てることにどんだけの意味があるのかね。人的資源は無尽蔵にあるとでも思ってるんだろうか。品質向上のために自動化のためのツールがほしい、という話だけど、Javaで例えば品質管理の現場でツールを使ってあれやこれを自動化するとしても、それでいったいどれだけのことが出来ているか知っているのかね。というか、自分がPHPで適切な環境整備が出来ないのを言語のせいにしとるだけちゃうんかと。
Java向けのコーディングルールのチェックツールがあるとする。でも、それで検知される内容って結局誰かが確認しないと、警告だのなんだのが出ても無視する奴は無視するわけで、だからまじめに運用しようとするとSEが人力でチェックを入れて徹夜したりしている。ちょっと極端な話だけど、ツールなんてそんなもんじゃないのか。
開発環境ひとつとっても、別にそんなに大仰なことが必要なケースって少ないんじゃないだろうか。Amazonのシステム丸ごとリプレースならいざ知らず、たかだかユーザ数５０万や１００万程度の携帯サイトだったら、リモートデバッグなんてややこしいツールなんかなくても、今だってサーバにログインしてそれなりにファイルを編集したりコマンドを実行したりする権限はみんな持っているんだから、Xdebugでもなんても使えればいい。テストの自動化だったらSeleniumでもなんでも使えればそれでいいじゃん。っていうかだったら携帯端末の挙動を模するエミュレータかプロクシの開発でも進めればいいんじゃないか。
以前習ったことだけれども、本当は言語自体がソフトウェア開発に関連するハウスキーピング作業をやってくれるのが一番理想的で、それがダメならツールがやってくれるのがいいことで、それでもダメなら慣習でそれが実践されるようにするのがいい、という尺度がある。つまり、どう足掻いてもツールのレベルにとどまるのであれば、言語を取り替えても効果はたかが知れているのだ。
品質管理の連中が言語を変えたいといってきたら要注意だ。開発チームからそんな声が聞こえてきたら、それはまた別の意味で要注意（やった方がいい）なのだけれども。
そうそう。プログラムにコメントなんて本当に必要なんだろうか。仕様書を更新する人はいても、コメントを更新する人なんていないんだし、結局最後は当てにならないんじゃないか。だから、個人的には、コーディングのルールでコメントの付け方までいちいち縛るのはあんまり意味がないし効果も薄いと思っている。別にコメント自体には反対はしないけど、何かの保守業務でコメントを読んだことなんかないし、自動的に出力したドキュメントなんて、ソースコードを読むより苦痛になることの方が多い。
May - 2nd
PHP-5.2.6
Posted at 4:29 pm | Filed Under PHP, Security
変更点はこんなかんじ。CVE-2008-0599ってのはPATH_TRANSLATEDの扱いに不具合があって、そこが脆弱性に繋がる可能性がある（参照）とのこと。
Apr - 27th
怠惰な午後
Posted at 3:29 pm | Filed Under Apple, PHP, Ruby
HDDを飛ばして以来、ずっと放置していたRoRとCakePHPとsymfopnyとCodeIgniterとDrupalの開発環境を用意したら満足してしまった。典型的な積ん読症候群である。
Apr - 25th
Services_Akismet
Posted at 10:42 am | Filed Under PHP
メモ。AkismetのコメントSPAM判定を利用する場合。
<?php
//例えばこんなSPAM
$author = "有名なスパム野郎";
$mail = "nasty-spam@spamspamspam.com";
$url = "http://every-spammer.com/";
$comment = "ジンバブエで妻がアリクイにバイアグラを激安で"
. "並行輸入したので貴方の銀行口座を教えておじいさん。";
//ここから下は$_SERVERから自動で取得されるけど指定することもできる
$referer = "http://another-spammer.com/";
$agent = "Hell Bot 2.0";
$ip = "123.456.789.0";
//設定
require_once 'Services/Akismet.php';
require_once 'Services/Akismet/Comment.php';
$key = trim(file_get_contents('akismet_key'));
$my_url = "http://selfkleptomaniac.org/";
$comment = new Services_Akismet_Comment();
$comment->setAuthor($author);
$comment->setAuthorEmail($mail);
$comment->setAuthorUri($url);
$comment->setContent($comment);
$comment->setUserIp($ip);
$comment->setUserAgent($agent);
$comment->setHttpReferer($referer);
try{
$akismet =& new Services_Akismet($my_url, $key);
if($akismet->isSpam($comment)){
print("やっぱりスパムでした。\n");
}else{
print("疑わしきは罰せず、ともいいますよ。\n");
}
}catch(Services_Akismet_InvalidApiKeyException $key){
print("APIキーが間違ってます。\n");
}catch(Services_Akismet_CommunicationException $com){
print("Akismetサーバとの通信に失敗しました。\n");
}catch(Services_Akismet_InvalidCommentException $commentEx){
print("送信されたコメントのフォーマットに不備があります。\n");
print($commentEx->getMessage() . "\n");
}
?>
Apr - 23rd
PHP Framework Fight
Posted at 3:12 pm | Filed Under PHP
PHP FrameworkはPHPによるFramework同士を対決させるイベント。今のところEthna、Zend Framework、symfony、CakePHP、rhaco、Konstructによる実装が予定されている。他のも受付中。
Apr - 21st
Those were the days
Posted at 8:20 pm | Filed Under PHP, Work
reddit経由で読んだが、antirez blogに掲載された「What we lost (now that web programming is mainstream)」は新たな「本物のプログラマ」シリーズのバリエーションだ。
本物のプログラマはアプリケーションプログラムなど書かず、まっさらな金属板にゼロから書き込んでいく。アプリケーションプログラミングなど、システムプログラミングのできない弱虫のすることだ。
という一節を思い起こせば、
I had a background in system programming, very high level programming languages and algorithms and most of my work was with C, Scheme and Tcl at the time (now I use C and Ruby instead): to switch to web programming and PHP was like shooting my technical-self
これが基本的にはまったく同じことをいっているのがわかる。どこかで同じようなことを読んだなあ、と思ったらちょっと前にメモしておいたのがあった。
“This is exactly what makes Rails a ghetto. A bunch of half-trained former PHP morons who never bother to sit down and really learn the computer science they were too good to study in college.”
これも同工異曲といったところ。
皮肉なことに、いわゆる本物のプログラマたる人々が仕事として取り組めるプログラムにも限りがあるので、その手の人たちの中にはプログラミング言語を開発したり、フレームワークを開発していたりすることも少なくない。
件のブログでは
The most interesting thing remains to write a framework
(this is why there are so many frameworks around, people like to write them more than actual applications) unless you are lucky enough to deal with an application where the web part is just the interface to the user, take Google for example, but this is of course a very little percentage of all web applications, including the ones having success.
なんて書かれている。確かに、ある程度以上の技量を持ったウェブアプリケーションのプログラマなら、フレームワークを書いてみたいと思う人はたくさんいる。
しかし、皮肉なことに、フレームワークは結局のところ、開発者が低レベルな部分を面倒みなくてもいいようにするものになってしまうので、ウェブアプリケーションからいわゆる本物のプログラマと分類される人たちの面白がる部分をますます無用のものとすることに貢献してしまう。
結局、この手の話はもう何十年も繰り返されていることなので、誰もがある程度のところであきらめるしかないと思うのだが、どうだろうか。
Apr - 16th
へたれな疑問
Posted at 10:03 pm | Filed Under Linux, PHP
Gnome端末でもPuttyでも、表示をEUC-JPに設定していてもメールをprocmailから標準入力で受け取ってMIMEデコードしただけのJIS（ISO-2022-JP）の文字列をきちんと表示する。あれ？と思ってただのJISを表示させたら、やっぱり文字化けしない。
$ cat test.php <?php $str = 'ダライラマ'; print(mb_convert_encoding($str, 'JIS', 'EUC-JP') . "\n"); ?> $ php -q test.php ダライラマ
この原理がわからない。JISのエスケープを見つけたらせこせこ処理してくれているんだろうか。viだとちゃんと文字化けする。
日本語環境の設定で苦労したのももう今は昔の話なので、この手の問題についてはぜんぜんわからなくなってしまった。
Apr - 10th
使い道がわからん
Posted at 11:02 am | Filed Under Javascript, PHP
もうすぐ廃止になるJavaScriptのescape関数なのだが、例えばこんな風に文字列をescape関数に渡すと
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=utf-8" />
<script language="javascript">
function test(){
var str = document.getElementById('tibet').innerHTML;
var esc = escape(str);
alert(esc);
}
</script>
</head>
<body>
<div id="tibet">ダライラマ</div>
<button onClick="test();">test</button>
</body>
</html>
alertに表示されるのは「%u30C0%u30E9%u30A4%u30E9%u30DE」という書式になっている文字列で、ようするにescape関数は文字列を%uで始まる16進数のかたまりにする。
これをそのままPHPに渡してデコードするには、
<?php
$str = '%u30C0%u30E9%u30A4%u30E9%u30DE';
$decode = preg_replace_callback("/(%u)([0-9a-zA-Z]+)/", '_decode', $str);
function _decode($array){
return mb_convert_encoding(pack("H*", $array[2]), 'UTF-8', 'UCS-2');
}
?>
こんな感じで処理する。逆に、PHP側で文字列をJavaScriptのescape処理と同様に加工する場合は
<?php
$str = 'ダライラマ';
preg_match_all("/(.)/u", $str, $matches);
foreach($matches[1] as $k => $v){
$matches[1][$k] = '%u' . strtoupper(bin2hex(mb_convert_encoding($v, 'UCS-2', 'UTF-8')));
}
$encode = implode("", $matches[1]);
?>
でできる。
と、ここまではいいのだが、JavaScriptでエスケープ処理された文字列をやり取りして面白いことができないか考えても、特に何も思いつかないので困った。
Apr - 7th
正規表現関数のバージョン互換
Posted at 8:42 pm | Filed Under PHP
PHP 4.3.2では
<?php $str = 'あいうえお'; $pattern = '/[ぁ-ん]/u'; preg_match_all($pattern, $str, $matches); print_r($matches); ?>
これが文字化けする。mb_internal_encoding、mb_regex_encoding、mb_languageは何を指定しても無駄。
一方、PHP 4.3.9では文字化けしない。
ところで、
<?php $str = 'あいうえお'; $pattern = '/[ぁ-ん]/'; preg_match_all($pattern, $str, $matches); print_r($matches); ?>
のようにパターン修飾子「u」の指定を外すと動作するようになる。
PHPのマニュアルによれば、
この修正子は、Perl 非互換な PCRE の機能を有効にします。パターン 文字列は、UTF-8 エンコードされた文字列として処理されます。 この修正子は、UNIX では PHP 4.1.0 以降、Win32 では PHP 4.2.3 以降で 使用可能です。 また、PHP 4.3.5 以降では、パターンの UTF-8 としての妥当性も確認されます。
とのことだが、これを読んだだけではこの挙動は予想できない。うーむ。
« go back — keep looking »