auでRengeRequest

しばらく悩んでいて漸く実装できたのでメモ。多分これが最小構成。

<?php
$fp = fopen("./test.3gp2", "r");
while (!feof($fp)) {
    $contents_data .= fread($fp,1024);
}
fclose($fp);
if (array_key_exists("HTTP_RANGE", $_SERVER)) {
        list($dummy, $start, $end) = preg_split("/[=\-]/", $_SERVER['HTTP_RANGE']);
        $total_size = strlen($contents_data);
        $contents_data = substr($contents_data, $start, ($end + 1 - $start));
}
header("HTTP/1.1 206 Partial Content");
header("Accept-Ranges: bytes");
header("Content-Range: bytes " . $start . "-" . $end . "/" . $total_size);
header("Content-Type: video/3gpp2");
echo $contents_data;

exit();
?>

分割した分だけこのスクリプトが実行されるので、ダウンロード時に何かの処理をさせたい場合には注意。$startや$endの値で判別すること。あと、通常のリクエストではRangeヘッダを送ってこないのでObject要素でリンクする。ひょっとしたらやれる方法があるかもしれないけど、未調査。

一方miracleさんはJavaScriptをマスターした

なんちゃってプログラマJitohたんの今日のたわごと。

動的言語

Webアプリケーション開発で、もしもクライアントサイドスクリプトの利用が避けられないとするならですが、サーバサイドも同一の言語で書ければ、理想的です。

基本的にASPというのはプアな能力しかもたないVBプログラマが職にあふれないための手段だと認識していて、HTTPを理解してあれこれやるための手段としては（.netも含めて)ASPでは弱いと考える。また、クライアントサイドでエージェントとして動くのは主にブラウザのため、ブラウザ上のオブジェクト操作にはJavaScript以上に優れたものが存在しない。

つまり、Jitohたんのいうようなサーバサイドも同一の言語で書ければ、理想的です。というのは開発者にとって理想的なものであり、アプリケーションやおそらくユーザにとっても理想的なものではない。

思うに、どんな言語も適材適所であって、PHPにはPHPの、JavaにはJavaの、JavaScriptにはJavaScriptのよいところがあり、ひとつの言語だけで全てを賄おうとするのはある種の横着だと考える。そんな馬鹿がMS系の技術者に非常に多いことが嫌で、おいらは極力その方面に関わらないように生きている。きっと近寄ったら堕落するに違いない。こういうおいらでさえ必要であればCにも触り、C#も面白そうだなと思うのに、JavaScriptに触れないでWebアプリ作ろうということがもう間違ってるだろ。

まあ、JitohたんはVB系のヌルい案件で細々と飯を食っていくがよいよ。VBプログラマがなんかツールでフォーム部品をこねこねやってるの見たことあるけど、あんなのコーディングじゃない。

楽しかったひと時が

PHP4は8月8日でEOL。ということでPHP4送別会をやろうかと思う

PHP5.3もいつでるかと言われている状態で、PHP5の終了なんて当分先ですから、滅多にない記念日です。(もしかしたらフェードアウトしてEOLすら無いかもしれないしね！)

元ネタはakkyさんのつぶやきですが、この2008年8月8日(金)に、PHP勉強会なのか、たん清で焼肉なのかは追って考えるとして、「PHP4送別会」をやろうかなと思います。

やっぱりPHP4は今までの人生で一番お世話になったツールなのでなんか自分に区切りをつける意味でも盛大に送りたい。東京でやるなら参加したいな。

PHPコミュニティは優しい

PHP 4.4.9

As it's about a month until the end of PHP 4, it's time to make the last release. There have been a few important fixes, which need to be part of a release. If you have anything else, please let me know so we can integrate it in the release as well. I'm planning to make a release candidate Wednesday next week (for a release on Thursday).

こんなことやってるからみんなPHP5を使わないんだよ。もういい加減見捨ててもいいと思うけど、こういう優しさが好きなんだよなあ。

えっちしよ？

今年のPHPカンファレンスのプログラムが発表になってますが。

Saityせんせい、わたしとピーえっちピーしよ？

〜キミと学んだPHP〜

アシアル株式会社 海原才人

故意に一部の文言が見えなくなる。やばいやばい。数年ぶりに行ってみるか。ものすごい濃いメンバーを集めたパネルディスカッション　「激論！PHPの次に学ぶ言語はこれだ」も気になるし。

PHPerが増えるのは楽しい

しばらく前に各所で暴れまわった野原燐がどうもこちらに近づいているらしい。

skip-character-set-client-handshake

「オープンソース徹底活用 MySQL4/PHP5によるWebデータベース構築」（isbn:9784798008608 発売日：2004/09/13）という長い題の本を前に買っていたので、（この本はwindows用だがlinuxでも使えた*1）読んでみた。

おお、がんばってほしい。エントリを読んでみるといろいろ手探りでやっている感じが伝わって面白い。おいらもこういう時期があったよなとか思ったりなんだり。んで気になったところ。

mysqlは4.1から変更があり、 文字コードの自動変換機能が追加された、と。それにより日本語はだいたい文字化けする？と。しかし、skip-character-set-client-handshakeを追加すると大丈夫ということで、だれでも体験することのようだった。

確かにその通りなのだが野原の解法よりもむしろqueryごとにset names utf8を投げたほうがよい。初学者は正しく明示的に文字コードのセットを行う方法を学んだほうが、後々困らなくてすむだろう。どの環境でもmy.cnfをいじれるわけではない。

ついでに書いておけば、PHPとHTMLとも文字コードは明示的に統一するべきだ。php.iniのmbstring関連とか、出力時にheader関数でhttpヘッダで出力文字コードを指定するとかやるべき。skip-character-set-client-handshakeはそれらの文字コード指定の役割と影響範囲を理解したうえで自分が楽をするために使うべき設定だと思う。基本的に環境が限定できないのならばこの手の楽チン設定は使うべきではないと思うのだが。

たとえ野原燐といえども、やるからには正しく覚えて、良いものを作っていただきたいものだ。

しかし、

ウィンドウズ用サンプルプログラム（付録CDについているもの）をlinuxで使う場合、元は文字コードがsjisなので

というのも酷いな。もはやwwwで使うものは無条件で文字コードはUTF8にしてよいと思うのだが。

おいらも大好きだ！

なんかAttacking PHPの界隈をいろいろ見ると、「Rubyの作者であるまつもと氏がそんなことを言うな」的な意見が結構あって絶望。そんなことどうでもいいじゃんかよ。PHPはヌルいコードで動いちゃうけれども、プロとしてPHPに関る人間はがんばりましょうねって言うことでさ。別にPHPでセキュアなコードが書けないって言われてるわけじゃないんだから。

つー感じでいろいろ巡ってみたら面白いものを見つけたよ。

"諸君、私はPHPが大好きだ"

そうだそうだ！ おいらも大好きだ！

みんなPHPが好きだった

Rubyの作者であるまつもとゆきひろ氏のBLOGがちょっと炎上している。理由は下記エントリ。

Attacking PHP

PHPは初心者に学びやすい(と言われていることが問題である)」という部分に共感する。 PHPは初心者に簡単かもしれないが、初心者による手を抜いたWebアプリケーションは PHPが作られた当初はともかく、現代では害悪ではないだろうか。

Webアプリケーションをなめるな

PHPならではの理由がないわけではないことはわかる。どこでもインストールされているとか、デプロイが簡単とか。

でも、「初心者に簡単」を一般公開されるWebアプリケーションを開発するための言語としての利点にするのはもうやめようよ。

PHP萌え萌えなおいらとしてはごもっともというほかない。PHPは初心者に優しいかもしれないが、それを良いことにアプリケーション作成時にきちんと踏むべき手順を省略して説明している資料が多く存在し、PHPからこの世界に入った人間にセキュアなシステムの製造のために当然考えてしかるべき事を意識させない。もちろん、我々はこのような耳の痛い意見があることを認識した上で、正しくセキュアなシステムを世に出さなければならないと思う。PHPに限った話ではないんだけれども、目に付きやすさから仕方の無いことなのだろう。

んで、問題は何故このエントリに世のPHP愛好者が強烈に吸い寄せられてしまうのかというところであってですねｗ

ダメな言語があるのではなくダメなプログラマがいるだけの話であって、ダメな人はCで書いてもJavaで書いてもPerlで書いてもRubyで書いても凄い物を作ってしまうのだと思う。んで、今現在においてPHPという言語を選択した（させられた）ダメプログラマが大量生産されているという話で、我々PHP使いはこういう外部からの視線を意識した上で襟を正しましょうね。とおいらなんかは思ったのだがこのエントリを「Ruby開発者によるPHP排除のためのネガティブキャンペーン」と受け取るってどんだけ被害妄想だよと。

まあ、世にPHP好きが沢山いるのは分かった。御託並べるのはもうやめにして、コードを書こうぜ。

あ、これってさららさんに見たことないって言っちゃった「エントリ著者に責任の無いBLOG炎上の例」かも。

htmlspecialcharsは長い

htmlspecialcharsと言うのは出力中に含まれるHTML特殊文字を勝手にエスケープしてくれると言うPHPでは基本の関数だが、いかんせんスペルが長くおいらのような記憶に問題のある人間にとっては使用するのがめんどくさいｗ　だからと言って使用しないわけには行かないのだが、基本Flexyのような勝手にhtmlspecialcharsを通してHTML出力するようなテンプレートエンジンを使用していたりなんだり。

昔後輩に「いい加減覚えましょうよ〜」なんていわれてて困ってしまったものですが、世の中にはそういう人が結構いるらしい。

htmlspecialchars関数を簡単に扱えるようにする

まあ、そのまんまなんですがね。ただ、こういうショートカット関数を多用しすぎるとソースが訳の分からないことになるので適切に使用することが大事だと思う。あくまでも、可読性が一番大事。

リンク追加

リンクにどう書く？orgを追加。お題を出していろいろなプログラム言語でそれをどう書くかを競い合うサイト。レベル高い。

ついでにちょっと時間があったので、年間カレンダーをやってみた。CLIで実行してください。

<?php

$yyyy = $_SERVER['argv'][1];

if($yyyy == ""){
        print("Error1");
        exit();
}

if(!ctype_digit($yyyy)){
        print("Error2");
        exit();
}

for($mm=1; $mm<13; $mm++){

        // Print header
        print(date("F", mktime(0, 0, 0, $mm, 1, $yyyy))."\n");

        // maxday of month
        $max_day = cal_days_in_month(CAL_GREGORIAN, $mm, $yyyy);

        for($dd=1; $dd<=$max_day; $dd++){

                $day_of_week = date("w", mktime(0, 0, 0, $mm, $dd, $yyyy));

                if($dd == 1){
                        for($w=0; $w<7; $w++){
                                if($day_of_week != $w){
                                        print("    ");
                                }else{
                                        printf(" %3s", $dd);
                                        break;
                                }
                        }
                }else if($dd == $max_day){
                        printf(" %3s", $dd);
                        print("\n\n");
                }else{
                        printf(" %3s", $dd);
                }

                // on Saturday
                if($day_of_week == "6"){
                        print("\n");
                }
        }
}
?>

駄目だ。全然駄目

なんちゃってプログラマですが

小飼弾――35歳からのプログラミングこそ無上の至悦 (5/9)

Q44　なんちゃってプログラマーってどんな人を指しますか？

PHP使ってる人？　なんちゃってでいいところがPHPのいいところでもあり、存在理由でもあるのだけど。これはPHPをディスっているわけでも何でもなく、使いどころを間違えなければPHPもいいもの。ただ、PHPでプログラミングの奥義を究めたいと言い出すと、「それは違うだろう」と思う。なんちゃってプログラミングがPHPの一番正しい使い方であって、PHPでクロージャとか、それはあさっての方向に進んでいるよといいたくなる。

断言されちゃったよｗ　否定できないけれども。

ただ、PHPプログラマってPHPの使い方を極めようとしているんであって、プログラミングの奥義を究めたいとか思っていないんじゃないかなと思ったりなんだり。PHPLoveでPerler氏ねのおいらでさえも最近Perlでこねこねやっていて、いろいろ目から鱗が落ちたりしているのが現状。要はPerlにはPerlの、PHPにはPHPの向いていることがあって、それを間違えなければなんちゃってプログラマでもいいと思うのだ。需要にあったものを供給できれば。

PHPは確かにおもちゃだと思う。だが、おもちゃを扱うのは楽しい。そういうこと。

感慨深いなあ

The last PHP 4 release

なんつーか、自分がこの業界に入ってもっともいじってきたツールが終焉するだけに感慨深いものがあります。これからはPHP5をいじって楽しもうかと思っていますが、これまで楽しませてくれたPHP4に心からの感謝を送りたいと思います。

とはいってもセキュリティホールが見つかって4.4.9リリースとかあると思うけどｗ

PHPもお前なんぞに使ってもらいたくはないだろう

昨日Jitohﾀﾝの他人任せ根性を目の当たりにしてすっかりゲンナリしていたおいらですが、こんな記事も見つけていました。

PHP 脆弱性 fix

PHPとってもいいんだけど、どうしてもこういうのから逃れられなくて管理が面倒なんですよね〜
　って、これはほかのプロダクトでも一緒だけど、プラットホームが Windows なら、MS Update で一括更新できるらから楽なのです。それで、私が .NET を薦めて、選択してくださるお客様多数ですlol

まあ、あれだ。管理が面倒なんじゃなくて出来ないんだろ？　そもそもPHP（に限った話ではなくオープンソース全般）とかってみんなで使ってみんなで不具合に対処するものだからJitohのように自分が使いこなせないのは他人のせいとしか考えられない低脳には敷居が高いのであろう。

.netって触ったことは無いけどまあ、.netなりのいいところはあるのだろうし、.netしか出来ないことというのがたぶんあるのだろう。翻ってPHPしか出来ないということはたぶん存在しないんだよね。じゃあなんでPHPを使うのかといえば、自分で１から１０まで何とかできる点と、自分ですべてを管理できる部分だと思う。それが出来ないんじゃ仕方ないんだけれどもさ。

だから何が言いたいのかといえばJitohに騙された顧客に「考え直せ。お前がサーバに蓄積している情報はMicrosoftにだだ漏れだ」といいたいのさ。

MDB2は使えないニダ！ と騒ぐ前に

今日は思うところがあってちょっと会社に行っていろいろやってきたのですが、PEAR::MDB2というものをPEAR::DBからそろそろ乗り換えてつかってみようかなと思ってインストールしてやってみたのですが、extendedのモジュールがどうもうまく動かなくて、prepare, execute, autoExecuteが使えない。

これでは使い勝手が悪いのうとか考えていたら、英語力のアレなmiracleさんは見つけてしまったんですよ。

module to have access to it:

$mdb2->loadModule('Extended');

Now you can

$mdb2->autoExecute('people', $data, MDB2_AUTOQUERY_INSERT);

The above will work in PHP5 only. In PHP4, due to the limited support of object overloading (Thanks again to Lukas for clarifying this!), you'd need to do:

$mdb2->extended->autoExecute('people', $data, MDB2_AUTOQUERY_INSERT);

最初の方法しかマニュアルに書いていないんだもん。うちは4.4.6を一生懸命うごかしてますよーだ。

株売ってくれ

[雑記]本日入社しました

ということで、ウノウ株式会社に入社しました。

今後ともよろしくお願いします :-)

ウノウってそんなにすごい会社なのか。上鍵さんも入っていたようなとおもったら既に移られていたのね。ウノウラボには平素からお世話になっております。なんかすごそうな会社なので頑張って株を買ってみるか。くださいな

PHPカンファレンス

PHPカンファレンス2007プログラム概要

今年は行きたいなあ。

• 大規模サイトの構築・運用ノウハウ(仮題)
• PHP Framework Update
• PHP at Yahoo! JAPAN

あたりが興味しんしんですぬ。

悩むなあ

そろそろPHP4終了について言っておくか

個人的な事を言わせてもらえば、PHP4からPHP5への移行の話しは3年ほど前に終了してる話しでありなんというか今更な感じ。まあ、自分はPHP5 beta1から実戦投入してるという変態さん研究熱心な人なので置いておくとして一般的に見ても今更騒いでるのはどうなのかと思う。

PHP4が終了する、なんていうのはいつか来る話しだとわかっていたはず。「PHP4でもPHP5でも問題なく動くコード」は多少意識すれば書けるし、2年近く前からそういうコードを書こう、というのは繰り返し言われてきた。(というか、自分もPHPConでそんなことを言った覚えがあるような気もする)様々な可能性を考えリスクに備えるのも、技術者としてすべきことの一つでしょう。選択肢としてはPHP4そのもののコードを深く理解し、メンテナンス終了後も自分で修正してやるぜ！というのもあり。それよりはPHP4からPHP5に以降するときに気をつけるポイント何点か覚える方が遙かに楽だけど。

PHP4とPHP5の両用コードを書く上で気をつける事は(PHP4の知識がベースにあるとすれば)多分10に満たない。たかがその程度の情報を探したり試したりする手間・努力を惜しむような人は正直プログラマー辞めた方がいいんじゃないのか。

(もうちょっと広い範囲でいうと、企業だって「自分らが飯食っていくための財産なんだから企業としてもリスクヘッジ考えないと駄目だよね)

わずかな向上心すら持ち合わせてない人に続けられるほど、この職業は甘くないと思います。

うぐう、ごもっとも。確かに、PHP5で出来ることのほうが広がるはずだし、ほんの少しの注意で、両対応スクリプトは書けたはず（今書いているのも動くと思うけど、実証していない）。

いつかは終わるとわかっているのだからいまさら慌てるなよという話は理解できる。

しかし、現実には上司（顧客でも可）にPHP5に移行しましょうよと説明して理解をしてもらうのが大変なのではないのかなとか思ったり。技術者はあんまり「移行メンドクセ」とか思わないんじゃないかなあ。

あと、個別の関数について以下のような問題がある。

そうはいっても移行は簡単ではない

返り値

成功時はタイムスタンプ、そうでなければ FALSE を返します。 PHP 5.1.0 以前ではこの関数は失敗時に -1 を返します。

PHP: strtotime - Manual

注意: encoding パラメータは、 PHP 5.2.0 以降は三番目のパラメータではなく四番目のパラメータに変わりました。過去との互換性を保つために encoding を三番目の引数で指定することもできますが、これは推奨されません。 将来は削除される予定です。

PHP: mb_strrpos - Manual

とかもあるわけです．マニュアルに落ちていない仕様変更もあるでしょう．

この辺をどれ位技術者が熟知しているか，仮に安定しているシステムをどれ位デグレードさせずにPHP 5系に対応していくか，PHP 4のライフタイムと案件のライフタイム，コストのバランスから見てやるべきことなのか?

あるいはそもそも単純に上司，経営者，クライアントを説得できるか，など踏まえるとそんな簡単な話ではないと思います．

また，そもそもPHP 5になって依存関係のライブラリのバージョンも上がってきています．そのために簡単に移行できない(へたしたらOSレベルから入れなおしの話)になる可能性も十分あります．

うむう。超悩む。こんなに悩む問題は久しぶりだと思う。現実的ではない回答だけれども、今から個人の環境ではPHP5を動かすべきなんだろうか。んで、さっきも書いた通りホスティング業者の動向をみて「どうしましょう」→「実は準備していたんですよ」となるとカッコいいかも。

いまどきPHP4.4使ってる人間は滅ぶべき

とPEARの中の人が仰せです。

Joining the GoPHP5.org's movement

After being the leader and most used PHP applications and libraries for many years with over 30 Million downloads, the PEAR Project is happy to announce that the next version of PEAR, named PEAR2, is going to aim at being only available for PHP5.2 and newer versions of PHP.

PEAR2 is currently not released but under development with a new installer (Pyrus) coming along the way. Using the benefits of the PHP Archiver (PHAR) and the features that PHP5.2 offers, we can now produce better applications than ever using the PHP language.

Thanks to all our users and especially our dedicated developers for making this possible. Without them, we would not be able to achieve and reach a goal that has been important to us for the few past years, moving to PHP5.

まあしかし、実際のところはレンタルサーバ業界がどう動くかによって、移行の時期というのは変ってくると思うな。自分で鯖立ててる会社もそれ程多くはないでしょ。

大手のレンタルサーバ屋の動向を注意して探っていきたいと思います。ロリポップとXREAかな。とりあえずは。

PHP4終了のお知らせ

PHP 4 end of life announcement

Today it is exactly three years ago since PHP 5 has been released. In those three years it has seen many improvements over PHP 4. PHP 5 is fast, stable & production-ready and as PHP 6 is on the way, PHP 4 will be discontinued.

The PHP development team hereby announces that support for PHP 4 will continue until the end of this year only. After 2007-12-31 there will be no more releases of PHP 4.4. We will continue to make critical security fixes available on a case-by-case basis until 2008-08-08. Please use the rest of this year to make your application suitable to run on PHP 5.

For documentation on migration for PHP 4 to PHP 5, we would like to point you to our migration guide. There is additional information available in the PHP 5.0 to PHP 5.1 and PHP 5.1 to PHP 5.2 migration guides as well.

がーん。オレの飯の種が一つ減ってしまうということですか。これを機会にPHP5に移行するか。Rubyもありだな。今からPHP5をサーバに組み込んで準備をするしかないですね。

あくまで最低限の話

Webアプリケーションを作る前に知るべき10の脆弱性

あくまで最低限の話として認識すべきです。が、チェック項目としては有効でしょう。

1. クロスサイトスクリプティング（XSS）
2. インジェクションの欠陥
3. 悪意のあるファイルを読み込んで実行
4. オブジェクトの直接参照
5. クロスサイトリクエストフォージェリ
6. 設定情報などの漏えい、不適切なエラーハンドリング
7. 不適切な認証やセッション管理
8. 暗号の使い方が不適切
9. 通信方法が不適切
10. URLへのアクセス制限の不備

会社用にチェックリストを作成してもいいかもしれませんね。