Hatena::ブログ(Diary)

xmallocのプログラミングノート

2009年12月25日

PHPでテンプレートエンジンを使うことに対する疑問

有名なところだとSmartyとか・・・まあ他のでも良いのですが、そもそもPHP自体がテンプレートみたいなものなのにさらにテンプレートエンジンとか使う理由って何ですか?


MVCがどーとかみたいな?

MとVとCを分けたいのなら「このディレクトリにあるPHPはビューだ」と論理的に決めちゃうだけでも良いんですよね。テンプレートエンジンみたいの用意する必然性はなさそうですが。WordPressのテーマなんかその良い例だと思います。


作業を切り分けれる?

少なくとも私の知ってる範囲では、Smartyみたいなのを使いこなせるデザイナーはいません。ま、私の知ってるデザイナーが特別レベル低いのかもしれませんが。

いずれにしてもHTMLテンプレートに変換するのはプログラマの仕事になってます。プログラマがやるなら素のPHPを使えば良いのでは?その方が手っ取り早くないですか?

もっと大規模なプロジェクトだと違うのでしょうか。私のやってるのは家内制手工業的な仕事が多いので確かに小規模です。でもそれを言うなら、そもそもPHPって大規模プロジェクトに向いてますか?ある程度の人数集まったプロジェクトならTomcatとかでやってる方が多いんじゃないですか?


バグが減りますか?

テンプレート構文だからといってバグを作り込むこと自体が減るってことは無いと思います。Typoとかってテンプレート使わないから発生しないようなものでもないですよね。

テンプレート構文しか使えないからややこしいバグを作り込めなくなるというのは一理あるような気もします。その代わりプログラムの仕様的なバグは影響範囲も増えますが。テンプレートファイルと、それに変数埋め込んでるスクリプトと、少なくとも二倍。

フレームワーク的なのを使ったら良いのですか?自動的にテンプレートとそれを呼び出すためのスクリプト作ってくれるようなやつですか。そういうのだけで済むような仕事ならこちらも助かるんですけどね・・・


実行速度が上がりますか?

ファイルキャッシュしないと上がらないですよね。あ、別にデータベースでもいいですけど、出力をキャッシュしないと。

ちなみにファイルキャッシュするだけならそれ用のライブラリありますよね、テンプレートと関係なく使えるやつ。PEARにあったと思いますが。それはダメなんでしょうか。

どっちにしてもスピード上げたいならPHP Accelerator使うとかReverse Proxy立てるとか、そういう方向じゃないですか?


結局こういうことです

知り合いにテンプレート厨がいまして、彼曰くテンプレート使わないとかありえないそうです。

いつもそんな感じに言うので、いつも「お前バカじゃね?」とだけ返してるのですが、さすがに何度も繰り返してると気分を害されたようで・・・一応こちらも気分を害すつもりで言ってますので、当たり前と言えば当たり前ですが。

言われるだけじゃ彼も可哀想ですので「バカじゃね?」の理由を今日ブログに書きました。ただ彼は私がブログ書いてるのは知りませんので伝わるかどうかは知りません。とりあえず頑張って見つけて頂ければと思います。

情報が配信しやすくなって何が悪い?/我々のせいにするのはそろそろやめませんか?

わたしたちさえまともになれば、日本は圧倒的独り勝ちに近づく。人のせいにするのはそろそろやめませんか?に反論したいと思います。

まずわたしたちさえまともになれば、日本は圧倒的独り勝ちに近づく。から。


インターネットにおいてしばしば見られる展開だ。

手抜き記事ほどアクセス(広告収入)が増え、丁寧な記事を書けば時期を逃してほとんどアクセス(広告収入)が稼げない。

そんなシステムが成立している。

これでは大抵の「企業」は前者を選択するのも仕方がない。

システムが「マスゴミ」を生み出しているのだ。

わたしたちさえまともになれば、日本は圧倒的独り勝ちに近づく。

確かに「マスゴミ」という言葉はインターネット以降だと思いますが、それが揶揄するところのマスコミの本質を逸脱した行動は別にインターネットとは関係なく存在したと思います。なのでシステムがマスゴミを創造したというのはミスリードに思いました。

あと手抜き記事でコンスタントにアクセスが増えるのは一部有名サイト/ブログだけです。


それとこの前段で、

とにかく速度優先で記事を書く。ちょっと刺激的な推測を混ぜる。

2chの各板に取り上げられる

わたしたちさえまともになれば、日本は圧倒的独り勝ちに近づく。

速度優先で記事を書くこと自体に問題あるような雰囲気ですが、それのどこが悪いと言うのでしょう。そもそも記事が公開されるまでの速度があがったのは配信コストの低下が主な要因ですよね。配信コストの低下はまさにインターネットによるものでしょう。速報性が上がって、すぐニュースを読めるようになって・・・良いことではありませんか?

それに速報性が高いということは検閲されている可能性が低い、もしくは検閲から逃れられる可能性が高いということですよね。まあ今の日本では検閲とか無いはずですが、ニュースにはそういった機能も必要だと思います。先日のイランにおけるツイッターの果たした功績はこの機能が無ければありえなかったと考えてますが、イランの速報性は良い速報性で、日本の速報性は悪い速報性と言うつもりでしょうか。

また、配信コストの低下は発信の敷居も下げてますよね。私の雑文がどこぞの新聞に載るなんて想像もできませんが、それは私の文章のレベルが新聞に掲載するコストに見合ってないからですよね。

発信の敷居が下がって始めて、私のような昨日今日ブログを始めたような人間が(今日トラックバックしてるお二方のような)有名ブロガーに対して、ご意見しようなどというおこがましいことも可能になるのです。これがもし相手が新聞の論説委員かなにかで、新聞のなんとか欄の意見に対して何か言いたいと思ったなら、私はわざわざ投書しなくてはなりません。投書したところで紙面には取り上げられず誰の目にも触れないでしょうから、普段そんなことはしてません。

いずれにしても私にとって発信の敷居の低さは重要で、それを実現するために必要となっている配信コストの低さも同様に重要です。速度優先である風潮は配信コスト低下から誘因されたものですので、それを否定することは自分にとっての不利益を産むことに繋がると考えます。


マスゴミマスゴミと叩きながら、そのマスゴミにアクセスをプレゼントしていないだろうか?

[これはひどい]タグを付けてそこで興味を失い、次の話題を読みに行っていないだろうか?

ネット社会に酷い記事がはびこり、良記事が商業的に成り立たなくなる世界を形作っている群の一部になっていないだろうか?

わたしたちさえまともになれば、日本は圧倒的独り勝ちに近づく。

はてなに限らずソーシャルブックマークサービスは、発信の敷居の低さがブログに比べてさらに低いとは思います。いずれにしてもそれの何が問題なのでしょうか。

[これはひどい]タグだけ付けてるような例ですとコミュニケーション不全のような気もしますが、そもそもはてブってコミュニケーションの場なんでしょうか?そう捉えている人もいると思いますが、そう捉えてない人もいます。少なくとも私はあれをコミュニケーションの場だと思ってません。コミュニケーションの場でないのなら、コミュニケーション不全は必然ですよね。


少なくてもはてな界隈ではそのような風潮が見られる。

何かの事件について調べるとき、素晴らしい記事にはブクマが一つも付いておらず、一番ひどい記事に3桁のブクマがついているということが珍しくない。

わたしたちさえまともになれば、日本は圧倒的独り勝ちに近づく。

素晴らしい記事を掘り起こしたいなら自分のブログとかでその記事を宣伝すれば良いと思いますが、なぜ他人に何かしてくれとばかり望むのでしょう。ブログで宣伝したところで広まらないし、そんな記事だとアクセス増えないし、ひいては広告収入が増えないからですか?


次に人のせいにするのはそろそろやめませんか?から。


  • 問題意識を持った人が自律分散的に良質な記事を生成する活動してこそWebやネットの力が発揮されるのではないでしょうか?誰かに「世界を良くして下さい」と頼んでも、恐らく自分が望むような結果には到達出来ません。
人のせいにするのはそろそろやめませんか?

ネット上で何かを表現しないとその人は自律分散的に活動してないかのような意味に読めました。拡大解釈かもしれませんが。

その前提で、ネットで「マスゴミマスゴミ」とだけ言ってる人(がいたとして)も普段の生活においては世界を良く・・・してるかどうかは知りませんけど、それぞれの場において成すべきことをされている方もいらっしゃるでしょう。その人たちもネットにおいて、ネットの力が発揮するために労力を提供しないといけないのでしょうか。面倒な話ですね。


人のせいにするのはそろそろやめませんか?

少なくとも「これはひどい」と言うだけなら虚偽の情報を流布している訳ではありません。主観を表明しているだけで捏造したりはしてません。


  • センセーショナルさが少なかったとしても「これは良い」と思う物を見たり褒めたり、逆に「これはひどい」と思うものをスルーすることを各自がコツコツと始めてみることを提案したいと思った今日この頃です。
人のせいにするのはそろそろやめませんか?

「これは良い」も「これはひどい」も主観的な話ですよね。誰かが「これは良い」と表明することにより、「いやそれはひどい」という意見が出ることもあると思います。逆に「これはひどい」に反対意見を表明する場合もある訳で、「これはひどい」を否定するとそういった機会を否定することになりませんか?とりあえず「これはひどい」を否定すれば済むほど単純な話では無いと思いますが。


いずれにしても、みんなで「これは良い」と思う物だけを見せ合いっこするような世界って、考えにくいというか、気持ち悪いです。

2009年12月22日

ウェブアプリ作る時に読んどいた方が良いRFC/W3C/ECMAドキュメントのリンク集

前のエントリで、ウェブアプリ作る時はRFC読むべきみたいなこと書いたのですが、よくよく考えてみたら自分も最初どの辺りから見たら良いものかと思案したことがありますので、ウェブアプリ作ったことあるけどRFCは読んだこと無いという人用にこの辺から読めばいーんじゃね?って感じでまとめてみました。

RFCだけだとカバーできない部分もありますので、W3CECMAのドキュメントもリストしています。


RFC

一応簡単に説明付けていますが、本当にちょっとコメントしてるだけですので、とりあえずリンク集だと思って中身を見ていただいた方が良いと思います。


RFC3875 The Common Gateway Interface (CGI) Version 1.1

このRFCはinformatialでいわゆる標準ではありません。なので最初に持ってくるのはどうかと思いましたが、ウェブアプリの場合とりあえず読んどくべきはこれかなーと言うことで。


RFC2616 Hypertext Transfer Protocol -- HTTP/1.1

ウェブアプリ作るならHTTPは必須かと。HTTPヘッダとContent Negotiationあたりを知らずにまともなウェブアプリを作るのは難しいかと思います。


RFC1945 Hypertext Transfer Protocol -- HTTP/1.0

ウェブアプリの場合はHTTP/1.0だけ気にしといた方が楽な場合も多いので一応載せときました。これもinformatialで標準ではありません。


RFC2045-2047 Multipurpose Internet Mail Extensions (MIME) Part One-Three

HTTPヘッダはMIMEになってますので、クライアントHTTPヘッダを送信したり、クライアントから受け取ったHTTPヘッダを解析する際はこれらに従う必要があります。Content-Typeやら見慣れたものが載ってると思います。

続きのPart FourとかのRFCもあるのですが、ウェブアプリ作るだけならあまり関係ないと思いますので省略しました。興味ある方はwikipedia:Multipurpose_Internet_Mail_Extensionsをご覧ください。


RFC5322,2822,822 Internet Message Format

そもそもMIMEがMultipurpose Internet Mail Extensionsなので、Extensions元のRFCの知識も多少あった方が良いです。それとメールを送るウェブアプリの場合はメッセージ組み立てるためにこれらを知っておく必要があります。またその場合、SMTP(RFC5321,2821,821)も読んどいた方が良いでしょう。

メール関係は使ってるシステム/ライブラリにより古い標準にしか従ってない場合がたまにありますので、最新版以外も一応目を通しておいた方が良いと思いましたので古いRFCのリンクも載せてます。


RFC2183 Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field

Content-Dispositionヘッダの定義。ファイルをダウンロードさせたい場合などに使います。


RFC2231 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations

パラメータに文字セットを指定するためのMIMEの拡張。日本語ファイル名を指定する場合などに使います。


RFC2388 Returning Values from Forms: multipart/form-data

ファイルアップロード時はmultipart/form-dataでクライアントから送信されます。その際のMIME形式がmultipart/form-dataです。


RFC3986 Uniform Resource Identifiers (URI): Generic Syntax

URLの定義です。ライブラリによっては古い仕様に対応している場合もあります。RFC1738 Uniform Resource Locators (URL)、RFC1808 Relative Uniform Resource Locators、RFC2396 Uniform Resource Identifiers (URI): Generic Syntaxが古い仕様になりますので適宜参照してください。


RFC2854 The 'text/html' Media Type

このRFCは、HTML関係のRFCを廃止してW3Cへの関連箇所を示すものです。ということでW3C関係のドキュメントに続きます。


W3C

W3Cについてはお馴染みのものが多いと思いますのでURLだけ載せてます。


HTML/XHTML

DOM

CSS

ECMA

DOMW3CですがJavaScriptECMA標準化されてます。実際のところ標準文書だけだとアプリは作れないと思いますので、MDCMozilla Developer Center)とMSDNInternet Explorer関係のURLも一緒に載せてます。


最後に、最新版を載せるように注意しましたが一部古いRFCをリンクしてるかもしれません。他にあれもこれもみたいなのがありましたらコメントお願いします。

2009年12月20日

CSRFの簡単な説明

だいたいCSRFってさ、中身に比べて名前がゴツすぎないか?

クロスサイトリクエストフォージェリ、Cross site request forgeries、直訳すれば「サイトを跨って(HTTP)リクエストを偽造」でいいのかな?そのまま覚えちゃってるのでどう訳すのが正解なのか知らないけど、とりあえずこのゴツい名前とCSRFの実態のギャップが激しいと思う。


CSRFなんてクリリンより強そうな名前だけどさ、他サイトからformを送信してるだけなんだぜ。

例えばこれ、Googleのフォームなんだけど、

<form method="get" action="http://www.google.co.jp/search">
  <input type="text" name="q" />
  <input type="submit" />
</form>

このフォームに値を入力してサブミットすると、http://www.google.co.jp/search?q=ググレカスみたいなURLに移動するよね。

このURLをimgタグで自分のサイトとかに埋め込んだらCSRF

<img src="http://www.google.co.jp/search?q=%E3%82%B0%E3%82%B0%E3%83%AC%E3%82%AB%E3%82%B9"
     width="1" height="1" border="0" />

Googleの様に他のサイトからのリクエストを受け付けるように設計されているサイトなら、極々普通の動作。こんなの埋め込まれたサイト行ったらうっとおしいとは思うけど、無駄なトラフィックが発生したこと以外に実害はない。


つまりCSRFが問題になるのは以下のようなケース。

  1. クッキー等でセッション管理している
  2. 認証しないと使えないフォームがある
  3. そのフォームは認証されたユーザーの意図しない方法で投稿できる
  4. 「こんにちはこんにちは!」

「ユーザーの意図しない方法」ってのを真面目に考えたら定義がクソややこしくなるような気がするけど、Amebaなうの例なら投稿するつもりが無かったのに投稿されたとか、オンラインショップの場合なら買うつもりが無いのにカートに入れられたとか、常識的に考えてそらマズいっしょレベルで考えたらいんじゃね?

ちなみにCSRF対象のフォーム*1が、GETメソッドも受け付ける*2なら上のようなimgタグでユーザーの意図しないリクエストを発生させられるし、POSTメソッドしか受け付けないならwikipedia:CSRFのようなやり方でiframeのonloadでPOSTすればCSRFできる。


ウェブアプリとか作ってるなら、CSRFっていう単語知らなくても、そういったことが可能だってことはHTTPRFCでも見ればだいたい想像が付くじゃん。だからあんまり小難しく考えずにさ、対処すればいいと思うんだ。

とか言いつつ、最近のウェブアプリ作ってる層でRFC理解して作ってるのって少数派だとも思うんだ。初心者向けのCGI入門とかPHP入門とかの本やらサイトやらいっぱいあるじゃん、でもこの手の話を積極的に取り上げてるのはあまり見たことが無い。まあ確かにそういう内容じゃあんまり売れなさそうだわな。結局その辺のギャップがこの問題の一番ややこしい部分なんだろうなー・・・

*1:実際に問題になるのはリクエストハンドラだけどフォームの方が話しやすいのでフォームで

*2PHPの$_REQUESTとか使ってたりするとたぶんそうなる

2009年12月15日

そういや昔、満員電車でオッサンがいきなりチンコ掴んできてさ、

いやもういきなりチンコ掴んでくる訳ですよ。オッサンが。

まあでも俺も男だし相手はハゲかけてるし、こけかけた拍子にたまたまそういう体制になっただけかもしれないと思って何秒か待ったのね。そしたらチンコ離すどころかシコり出して、俺のチンコを、ハゲたオッサンが。

あーこれホモ系の痴漢?とか思ったのと同時に背筋に寒いものが走ったのはよく覚えてる。寒気の次は吐き気がするぐらいムカついて、そいつ捕まえて次の駅で下ろしたのね。

それからひと悶着あったあと一緒に警察行って、だいたい状況説明したら「男同士の痴漢って迷惑防止条例にしかならないよ」みたいなこと言われたんよ。警察の人から。要は痴漢にはならないし、微罪だから許してやろうよ、謝ってるし、みたいな感じの話になって。こっちも仕事行く途中だったからそんな長時間付き合ってられないし、もういっかってなったんだけど。


なんでこんなこと書いたかって言うと、

ですがこれは女性への暴力に関する調査の一つです。

つまり調査対象に男性が含まれていません。

男性性被害の実態は、全く把握されていません。

日本の性犯罪はあまりに多く、ただ隠蔽されているだけです。CommentsAdd Star

ってことらしいので、俺のも隠蔽された一つなのかなーと思って。


え、チンコ握られたぐらいで騒ぐなって?上で問題にしてるのは強姦とかそういうちゃんとした犯罪?それは失礼しました。

でも俺が女なら相手の人生吹っ飛ぶよね。本当に痴漢されてなくてもさ。

2009年12月14日

セイントに同じ技は二度と通じぬ…だがエンジニアの考えは違った?

URL踏むと「こんにちは こんにちは!!」 AmebaなうCSRF脆弱性で“意図しない投稿”広がるという記事が話題になっていたが、正直割と俺はAmeba側に同情的である。

エンジニアが金持ちになって次の世代を作る未来 - 狐の王国

Amebaなうの騒ぎについて同情的らしい。

エンジニアだってね、自分で作ったものがおもしろいと思えないとつまらないんですよ。自分もおもしろいと思えるものを作りたいって、みんな考えてる。

エンジニアが金持ちになって次の世代を作る未来 - 狐の王国

おもしろくないからちゃんと作れないってね、もう人間的にダメダメですよ。今どき小学生でももっとしっかりしてる。

twitterなんかだってそういうの乗り越えて来てるのよ。はまちちゃんtwitterでも同じことやって、英語圏にまで「こんにちは!こんにちは!」を広げてなんだこれはーってのやってたんだから。

エンジニアが金持ちになって次の世代を作る未来 - 狐の王国

そもそもAmebaなうなんざ明らかにツイッターのパクりでしょ。パクりサービスがパクり元の既知の脆弱性を持ち込むのは明らかにおかしい。同情する余地なんてこれっぽっちも無い。

パクりかどうかは置いといても、CSRF防ぐなんて基礎ですよ基礎。

mixiでも2005年、あるURLをクリックすると「ぼくはまちちゃん!」という日記が勝手に投稿されるという、CSRFを利用したスパムが流通したことがあった。コミュニティーサイト構築に詳しい専門家は、「CSRF対策は基本的なところ。Amebaなうが対策していなかったのは意外だ」と話している。

URL踏むと「こんにちは こんにちは!!」 AmebaなうのCSRF脆弱性で“意図しない投稿”広がる

それにね、Amebaなうの立ち上げはスタートアップ企業が誰にも使ってもらえないかもしれないようなサービスのベータテストを始めるのとは訳が違う。芸能人をある程度巻き込んでやってんだし、少なくともその周りに群がる人達が使うことぐらいは立ち上げ前から想定できてたはず。なのにCSRFすら考慮できてなかったってことは、本来作るべき人に作業をオファーしなかった証拠。Amebaなうの開発陣のスキル不足でしょ。*1

開発陣は単にCSRFを見抜けなっただけかもしれないし、CSRFの問題を知りつつ納期とかの問題でそのままリリースしたかもしれない。後者だってスキルの問題ですよ。


Amebaみたいなでかいところでこういうショボい問題が起こると外野からIT連中のすることなんて信用できないって声が上がるんじゃないですか?同情するとか言って身内を庇うような態度取るよりも、外から何か言われる前に

なーにー!

やっちまったな!!


男は黙って、トークン埋め込む

男は黙って、トークン埋め込む


意外と実装面倒くさいんですよー*2

ぐらいは言っとかないと。でないとエンジニアが金持ちになるなんて、夢のまた夢だと思いますが。

*1スキルが不足している技術者に仕事をまかせるのは経営陣の問題

*2:最後の一言余分だけど

2009年12月13日

なぜあいつはerror_reporting(E_ALL)の必要性を理解してくれないのだろう

アクセス稼ぎにPHPdisろうと思って、とりあえずネタが被らないように他のブログ巡回してたら、どちらかと言えばPHPよりもPHPerをdisってるるとこが多いような気が。とりあえずその手のブログ何個か読んでみたんだけど、基本PHPerは(レベル|意識|なんか色々)が低いって話みたいだ。まあ同感。正確にはPHPしか知らないPHPerは低いって感じみたいだけど。


それで思い出したんだけど、error_reporting(E_ALL)、display_errors=Onにしたら消してくれと文句を言われたことが前にあった。そいつは連想配列の添字を文字列で指定してないので、俺がerror_reporting(E_NOTICE)を有効にしたとたん警告だらけになったので文句を言ってきた。まあ実際はそんな風にちゃんと説明を受けた訳じゃなく「なんかいっぱい出たので戻してくれ」とだけ言われたんだが。

そいつが書いてたコードのエッセンスを抽出したらだいたいこんな感じ。

<?php
$a[hoge] = 10;
?>

でそんときは一応「いやそれは未定義の定数を添字として扱ってるだけだから後からバグが入り込む可能性もある*1ので直した方が良い」と説得を試みたんだけど、「納期に間に合わないからやめてくれ」だってさ。結局そいつと話してても時間の無駄っぽかったので自分のコードだけerror_reporting(E_ALL)にした。


error_reportingの必要性

あーあー言うとりますが、やっぱerror_reportingはE_ALLにしておいた方が良いと思うんだよね。あとdisplay_errors=Onも。こっちは開発時だけでいいけど。

なんでE_ALLにしておいた方が良いかって言うと、処理系が認識可能な問題は処理系にまかせた方が良いから・・・って説明じゃ難しいかな。別に上から目線で言いたい訳じゃなくて、この説明ではE_ALLなんか不要と言ってる奴を説得できそうにないな、って意味だけど。


例えば、ファイルを開いた後にファイルハンドルが有効かどうかチェックしてなくて後続する処理が正しく行われてない場合などもE_ALLで検出できる。こんな感じ。

<?php
$fh = fopen('fuga.txt', 'r');
while (($line = fgets($fh)) !== FALSE) {
    // ...
}
fclose($fh);
?>

fuga.txtが存在せずにこれを実行すると、E_WARNINGで警告*2が出る。つまりPHPインタプリタがエラーかもしれない箇所を検出してくれる。

処理系(=PHPインタプリタ)が認識可能な問題(上の例とか)を処理系にまかせるとはこういうこと。処理系は認識可能な問題を人間よりも効率的に探してくれるので、可能なら処理系に見つけさせた方が早い*3


重要なのは警告が出る場合は何かバグがあるかもしれないと疑うきっかけを作ること。坑道のカナリアと同じ仕組み。

特に正常に処理されてるみたいなのに警告が出るときは、ややこしいバグを組み込んじゃってることがままあると思う。そういうときはソースだけ見ながらあーだこーだするより、error_reportingを追跡した方がだいたい速い。


ログを見る方法を覚える必要もある

display_errorsもOnにしといた方が良いと書いたんだけど、個人的には別にOffでも良いとも思う。display_errors=Offにしてサーバエラーログでerror_reportingを確認しながらコーディングしてることの方が多いし。

ログの見方は、サーバの種類Windows/*NIXやウェブサーバの設定によって異なる。*NIXでApacheなら、デフォルトだと/var/log/httpd/error_logとか/usr/local/apache/log/error_logになってると思う。パスは自分で調べてもらいたいけど、/var/log/httpd/error_logならtail -fで流しっぱなしにできる。

% tail -f /var/log/httpd/error_log

これでウェブサーバのログが追加される都度表示されるようになる。


ただPHPの場合、その辺の共有サーバプログラミング始めた人も結構いると思うんだよね。共有サーバだとログを見れないところも多いから、ブラウザに警告表示するしか方法がない。なのでログの見方が分からなかったらdisplay_errors付けるしか方法はない。


これでいいのかね?

一応error_reporting(E_ALL)の必要性を理解してもらおうと思って具体的な相手を想定しながら書いてたんだけど、この内容だとそいつを説得するのはちょっときついかもしれない。誰かうまい説明書いてくれないかな?・・・

*1:誰かが定数を足したり、モジュール足すことで定数が追加されたりして、未定義の定数が本当の定数になると値が変わってバグ

*2:E_WARNINGなのでデフォルトの設定で表示されるんだけど、まったくログ見ないバカがいるのでちゃんと説明しといた方が良いと思う

*3:可能ならっていうのは、Cとかだとfopenの例なんかは処理系は見つけてくれずコアダンプして異常終了するだけであるように、使ってる言語や環境に左右されるという意味

2009年12月12日

Pythonの起動ってそんなに遅いの?ということで試してみた

Pythonは速い。その辺のレンタルサーバで使えるスクリプティング言語の中では抜群に速い。どの程度速いかは、Facebookが大規模スケーラビリティへの挑戦で学んだこと(前編)〜800億枚の写真データとPHPのスケーラビリティ問題 − PublickeyRuby vs PHP Performance Revisited — Elliott C. Backに掲載されている実行速度の比較結果を参照して頂きたい。簡単にまとめるとRubyPHP>Perl>Pythonとなる。つまりPythonが一番速いということだ。


ところで、ちょっと前に気になるブログを見かけた。

Python も遅い。CGI には向かない。しかし Pythonライブラリを事前にコンパイルすることができるので、ライブラリの読み込みは他の言語よりも速い。もし多くのライブラリを読み込むことになると、他との差はかなり縮まるはず。

スクリプト言語の起動時間を調べてみた

こちらによるとPythonの起動は遅いらしい。詳細はリンク先をご覧頂くとしてPythonの起動時間だけ抜群に遅い。Python>(越えられない壁)>PHP>Ruby>Perlとなっている。つまりPythonがズバ抜けて遅いということだ。


さて、私は普段PythonCGIを作っている。必要なら他の言語も使うがとりあえずPythonだ。しかしこれほど明確にPythonが遅いのなら、今後はとりあえずPerlもしくはRubyと言わなければならない。特にCGIの場合、スクリプト自体でそれほど複雑な処理を行っていることも少なく、プログラムの特性的にもGUIプログラムなどと比べプログラム実行時間全体に占める起動時間の割合が大きいため、なおさらだ。

ただ、「ブログを見たのでプログラミング環境を変えました」ではちょっとお粗末なので、本当にそれほど遅いのか自分でも試してみることにした。


とりあえずテスト

まずローカルで使っているテスト用サーバで/dev/nullを引数*1に各コマンドを動かしてみた。このように起動することで、ほぼプロセス実行時間=インタプリタの起動時間となる。

サーバを起動してから一回目の各コマンドの実行時間と二回目以降の実行時間が少し違ったので、別にまとめた。


以下はサーバを起動してから一回目の実行時間。

実行環境実行時間usersys
Python 2.6.20.04秒0.0秒0.0秒
Perl 5.10.00.00秒0.0秒0.0秒
PHP 5.2.110.26秒0.1秒0.0秒
Ruby 1.8.70.04秒0.0秒0.0秒

PHP>(越えられない壁)>Python=Ruby>Perlとなった。


次にサーバを起動してから二回目以降の実行時間。

実行環境実行時間usersys
Python 2.6.20.02秒0.0秒0.0秒
Perl 5.10.00.00秒0.0秒0.0秒
PHP 5.2.110.14秒0.1秒0.0秒
Ruby 1.8.70.00秒0.0秒0.0秒

PHP>(越えられない壁)>Python>Ruby=Perlとなった。


二回目以降のPerl以外の実行時間が短くなったのは、コマンドやライブラリOSキャッシュに乗ったためだと思われる。よくある挙動なのであまり細かく調べていないが。ついでに言うとPerlも短くなってるはずだが有意な数値が出ていないだけだろう。なお、何度実行しても実行時間に差が出なかったので、平均ではなくサンプリングしたプロセス実行時間*2を掲載してある。

とりあえずテスト環境だとPerlRubyが速いのは分かった。ただPythonも2.6になってからだいぶ速くなったようである。これならPerlRubyと比べて少し遅い程度だ。(スクリプト言語の起動時間を調べてみたではPython 2.5.1を使用しており、手元にあったPython 2.5.4でも似たような数字となっている。)


レン鯖でも調べてみた

テスト環境での実行時間が前掲したブログと同じような結果になったならそこで調べるのをやめにしようと思っていたが、それほどPythonが遅くなかったので、レンタルサーバでの実行時間も調べることにした*3

以下、さくらインターネットスタンダードのサーバでのコマンド実行時間である。上と同様に/dev/nullを引数に各コマンドを起動している。

実行環境実行時間usersys
Python 2.6.20.02秒0.0秒0.025秒
Perl 5.8.90.00秒0.0秒0.003秒
PHP 5.2.110.03秒0.006秒0.027秒
Ruby 1.8.70.01秒0.0秒0.011秒

ご覧のとおり、PHP>Python>Ruby>Perlと綺麗に0.01秒の差が出た。何回かコマンドを実行してみたが特に目立った差は見られなかったので、テスト環境での実行結果と同じく平均ではなくサンプリングしたプロセス実行時間を掲載してある。


速くならねーの?これ

以上の結果から、起動時間を主眼にするならPythonは少なくとも最良の選択肢では無いと言える。確かにPerlRubyの方が起動は速いが、これをもって使用言語を変えるほどの話ではないようである。

しかしPythonが遅いことに変わりはなく、この結果だけで終わりにするのも癪なので速くならないか調べてみた。結論から言うとPython起動時に-Eオプションを付けると起動時間を少しだけ短くできる可能性がある。

% time python /dev/null
0.008u 0.016s 0:00.02 50.0%     2904+2760k 0+0io 0pf+0w
% time python -E /dev/null
0.018u 0.000s 0:00.01 100.0%    2904+2760k 0+0io 0pf+0w

python -Eで起動するとPYTHONPATH等の環境変数の処理が行われなくなる。これにより少しだけ速くなることがある。上の出力はさくらインターネットでのもので少し速くなっているが、テスト環境ではpython -Eしても変わらなかった。必ずしも速くなる訳ではない。


ちなみにさくらインターネットではCGI起動時に.htaccessから環境変数を設定する方法が無いので、PYTHONPATH等の処理はそもそも要らない。従って-Eを指定すること自体に問題は無いだろう。他の環境では状況に応じて考慮した方が良い。


個人的な結論とか

ぶっちゃけPythonが最速であることは求めていないので、とりあえずpython -Eでおk。それと、たまにはPerlのことを思い出してあげてくだしあ

あと、処理系に限らずプロセスの起動時間は環境に依存する度合いが大きいので、私のブログも含めて「あそこにこう書いてあったから○○が良い/悪い」という考え方はやめた方が良いと思う。都度調べる、これ最強、インディアン嘘付かない

*1python /dev/null, etc

*2サンプリングしたプロセス実行時間=ターミナルに残っていた値を適当にコピペ

*3:よくよく考えたらテスト環境の実行時間なんかどうでもいい

2009年12月11日

西横浜市役所基幹システムにトラブル、原因は叱るちゃん

2010年12月11日、西横浜市役所は基幹システムにトラブルが発生したと発表した。復旧は未定。

市システム担当課によると、本日付けで提出された山田叱るちゃんの出生届の入力時にトラブルが発生したとのこと。叱るちゃんの「叱」という漢字は2010年まで常用漢字として登録されておらず昨年の常用漢字表改正の際に追加されたものであるが、該当システムでは新常用漢字表への対応は予定していなかった。

トラブルの詳細について担当職員から話を伺うことができたので、記者の質問と交え掲載する。

記者 今回のトラブルの概要について教えてください。


職員 今回のトラブルは戸籍システムのサブシステムである出生届の受付システムにおいて発生しました。市役所では出生届を頂くとまずこのシステムで登録します。その入力時にエラーが発生したため、叱るちゃんの出生届はまだ受け付けていない状態です。他のシステムへの影響はありません。


記者 新常用漢字表告示は昨年から知られていましたが、対応予定は無かったのですか?


職員 該当システムにおいて今回の問題が発生するのは予見されていましたが、まさかこのようなDQN名をつける親がいるとは想定外であり、システム的な対応を行う予定はありませんでした。また今後も対応する予定はありません。


記者 対応する予定は無いというのはどういうことですか?


職員 実は新常用漢字のうち「叱」を除くすべての文字については現行システムは対応しております。「叱」という文字はUTF-8の4バイト範囲に属しており、新常用漢字への対応時にシステムベンダーに依頼した見積りによるとこの一字の対応に数千万規模の費用が必要とのことで、新常用漢字対応時に「叱」のみ対応しない形で改修を行いました。また、本件は親権の濫用にあたる可能性も高く、このようなバカ親の気まぐれに付き合うためだけにそれだけの税金を注ぎ込むのもどうかという意見が役所内からもあがっており、出生届が不受理となるとシステム改修も不要となるため、その方向で調整中です。


記者 つまり不受理になるとウハウハということでしょうか?


職員 はい。ウハウハです。

現在親権の濫用による不受理を目指して鋭意努力中とのことである。このような無駄な税金の乱用は回避すべきであろう。



うん、また「ネタ」なんだ、済まない。元ネタはこれ。

常用漢字表が迫るUnicode移行、「シフトJIS」では対応不可能 - 新常用漢字が引き起こす文字コード問題:ITpro

http://itpro.nikkeibp.co.jp/article/COLUMN/20091209/341831/

それと西横浜市は実在しないはず。


最後に個人的な意見。

UTF-8を3バイト固定で作っちゃってるOracleのシステムとか結構あると思うんだけど、どうすんだろーって感じで書きました。UTF-8の話よりもUCS-2が使えなくなる話の方がシステム全体としては面倒な気もします。

いずれにしても、どうしてこうなった

2009年12月10日

日本のSIerは意外とアジャイルである

はてなブックマーク人気エントリーから。

「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイル専門家の答え

http://www.publickey.jp/blog/09/post_77.html

こちらを読んだところ、日本のSIerがやってる仕事の進め方って意外とアジャイルっぽいような気がしました。引用を交えて私の考えを述べたいと思います。


質問 日本のSIerに務めています。日本では、設計書をエクセルを使って画面や処理などの書類を作成しています。海外のアジャイル開発手法では、どのように設計書や仕様書を作成しているでしょうか。


Guo氏 アジャイルの中にデザイン(設計)はありません。設計があるとしても、それはアプリケーションのすべてを決定するのではなく、アーキテクチャレベル、つまり作ろうとしているものがクライアントサーバ型なのか、リッチクライアントなのか、非機能要件をどのようにして満たすのか、といったものになるでしょう。

http://www.publickey.jp/blog/09/post_77.html

なんというか、質問者のミスリードであろう。

そもそも日本では、エクセルを使って作成された画面や処理などの書類は納品のためだけに存在する。上司もしくは取引先に提出され、人事考課の重要な要素となる。開発者がそれを必要とするのは、メモを取るための紙が必要な場合や、紙飛行機を大量生産する必要に迫られた場合に限定される。

従って日本のSIベンダの中にデザイン(設計)は表向き存在するだけで実際は存在せず、実質はアジャイルであると言えよう。


質問  画面のデザインはどうでしょう? 最初はスケッチのように簡単に書いておくのでしょうか?


Guo氏 画面デザインについては、アジャイルの新しいトレンドがあります。それは、ほとんどのユーザーインターフェイス設計は前倒しにしなければいけないと、多くの企業が気がついたことです。ユーザーインターフェイスの決定は先延ばしにするのは難しいと気がつきました。

http://www.publickey.jp/blog/09/post_77.html

このGuo氏の発言から考察するに、日本のSIerの実力は最先端アジャイルすら凌駕していると言わざるを得ない。なぜなら特に顧客との折衝フェーズにおいて、ユーザーインターフェースは唯一会話が通じるフェーズであり、自然と打ち合わせの中心事項となる。

むしろUI以外が話題に登ることは意図的に避けられる。なぜなら日本のソリューションビジネスにおける顧客は一般的に無知であるとされており、設計書に存在する開発者サイドから見ると本質的でありかつまた顧客のビジネスに直接的な影響を及ぼす重要な項目は顧客の理解を越えるため、折衝フェーズにおいては「ここは飛ばしてよろしいでしょうか」とベンダーが絶妙な心配りを見せることで顧客の無知が暴露されるのを回避するための阿吽の呼吸が求められ、本来上位工程において解決されえた問題が先送りされる。これぞアジャイルである


Guo氏 アジャイルは、アンチドキュメンテーションというわけではありません。ドキュメントがないわけではないのです。大きな違いは、デザインが進化する、ということです。ハイレベルのアーキテクチャを説明する図が(ドキュメントとして)必要なときもありますが、その知識がドキュメントによって伝わるわけではありません。

http://www.publickey.jp/blog/09/post_77.html

Guo氏の言葉を借りて言うならば、「日本の伝統的な開発はドキュメントドリブンはありません。ドキュメントは空気のように存在しないかのごとく扱われるのです。大きな違いは、仕様は常に確定的ではない、ということです。見積りは(お金を請求するために)必要なときもありますが、それ以外がドキュメントによって伝わるわけではありません。」となるであろう。つまりアジャイルである


Guo氏 (中略)

コードを書くというのは、例えて言えば地面にタイヤが接地するようなもので、有能な人がコードを書くべきです。賢い人がマネージャでそうではない人がコードを書く、というのは企業文化における課題だと思います。

http://www.publickey.jp/blog/09/post_77.html

これこそまさに日本のSIerアジャイルである証明と言える。なぜなら日本のSIerにおいては「火消し」と呼ばれる、プロジェクトが佳境を迎えたまさにそのとき、有能な技術者が華々しく登場しすべてを解決するという伝統的儀式が存在する。また、開発途中に発生した、解決可能はすべてのバグは、この儀式のため先送りにされるのが通例である。

なお「火消し」の副作用として、鬱、出社拒否、過労死自殺などが問題になることがあるが、これは伝統的儀式を継承していく上で発生する不可避な問題と考えられており、これらの問題に対してなんらかのソリューションを提案することは伝統への背信行為として忌避されている。もちろんアジャイルデスマーチは相性が良い。


質問 日本はウォーターフォールが盛んな状況ですが、それは顧客が昔からそうした契約の発注を続けていることにも一因があると思っています。自分の顧客にもウォーターフォール型の開発を望んでいるところが多くあります。こうした顧客にアジャイルを理解してもらうためのアドバイスをいただきたい。


Guo氏 これはアジャイルに関してよくある課題です。顧客からすれば、これだけ払うのでその対価としてこれだけやってもらいたい、この料金を支払えばこの機能が手に入る、という契約は、なかなか変えにくいものがあります。

http://www.publickey.jp/blog/09/post_77.html

これまた質問者のミスリードであろう。日本のSIerの顧客の多くが求めているのはフレキシブルな対応と安全安心のみである。それを多くの企業ではウォーターフォールに従ったかのごとくソリューションすると喧伝するが、仕様変更は過度であり、本質的にはウォーターフォールではない。すなわちアジャイルである


Guo氏 (中略)

契約というのは、問題が発生したときにお互いを守るためのものです。失敗した場合にはこれだけのペナルティがあります、といった。こうした契約をベースにしてビジネスは動いているので、これを変えるのは簡単ではありません。

http://www.publickey.jp/blog/09/post_77.html

契約というのは他社に何かを強制するための拘束力である。すなわち「死んでも今日中に納品しろ。会社がつぶれるんじゃボケ!できないんだったら死ね、ここで死ね、早く死ね、今すぐ死ね!!」という雄叫びがこれからも日本のSIerでは繰り返されるであろう。こうした契約をベースにしてビジネスは動いているので、これを変えるのは簡単ではありません。


一応言っとくけど、ネタだかんなwww

2009年12月09日

ping送ってなかったのね・・・

はてなってデフォルトだと更新ping送らない仕様だったのね・・・

早く言ってよママンorz

初めてping送るのが初日に続いてまたグチブログとは・・・

マトモなブログまだ一回しか書いてないじゃねーか。

どーもすいませんw

2009年12月08日

できるプログラマはGit/SVN/CVSを使う→理由:バグが減るから

タイトルに結論出てますので簡単に。

バージョン管理システムを使うとバグが減る
だから使え
以上

え?ちゃんと書け。そうですね!*1


まず最初に、個人的にはほとんどGitを使ってますがバグを減らすが目的ならどれでも変わらないと思います。CVSはファイルをリネームできないのでこの目的だとちょっと使いにくいかもしれませんので、これから使うなら他のをお薦めします。

ではちゃんと書きます。


なぜバグが減るのか

既にプログラムがある程度完成してる状態からバグ対応をしたり機能追加をしたりする場合を想定してください。バージョン管理システムが無いときはこんな感じのフローで作業してると思います。

  1. 変更箇所を調べる。お行儀悪いですが、あたりを付けるためにちょろちょろとコード直しながら調べてるかもしれない。
  2. 修正するファイルの一覧を作る。
  3. 修正する。
  4. ビルドアップロード等々、配布/更新を行う。

実際の作業では順番が前後してたり工程があったりなかったりすると思いますが、あくまでも一般的な話ということで。


この作業フローは、バージョン管理システムを使うとこうなります。

  1. 変更箇所を調べる。お行儀が悪いと言われてもその方が楽だったらあたりを付けるためにちょろちょろとコード直しながら調べる。不要な修正は調べ終わったら全部元に戻す。
  2. 修正するファイル一覧を出力する
  3. 修正する。
  4. 修正前と差分を取る。
  5. リポジトリに修正をコミットする。コミット=変更を確定すること。)
  6. ビルドアップロード等々、配布/更新を行う。

太字箇所が変わった部分です。差分を取ったりコミットしたりする作業が増えます。作業増えるの嫌がる人には大した作業ではないと言っときます。


さて、元のフローで発生しそうなバグを考えてみます。

  • 変更箇所を調べる際に不要に直したコードがそのまま残ってしまった。
  • 他にソースを直してる人がいたのに気づかず古い版を元にソースを直していた。
  • 修正する仕様を誤って理解していた。
  • アップロードするファイルが漏れてて動かなくなった。
  • 何かの作業に失敗して戻せなくなった。
  • その他もろもろ

他にも色々あると思いますが考え出すと切りがないのでこの辺で。これらのうち、作業ミス的な問題のほとんどはバージョン管理システムを使うだけで解決できます。

なぜか。

バージョン管理システムには以下のような機能があります。

  • 前の版に戻す
  • 最後の状態と今(修正後)の状態の差分を取る
  • 修正中のファイルとは別にマスタをリポジトリに保存する
  • リポジトリの変更を行う際はコミットする

これらの機能が複合して上のようなバグを含んだままコミットされることを防ぎます。(仕様を誤って理解したケースについては直接的に防いでくれないので後述します。)

バージョン管理システム使ってても操作を間違えて他人の作業を増やす奴は出てくると思いますが、その際も元の版に戻せば良いだけですし、操作ミスしそうなバカにはコミット権限渡さないとかフリーソフトのプロジェクトでよくある手法を採用しても良いと思います。


仕様を誤って理解したケースについて。このケースはバージョン管理システムが完全に解決してくれる問題ではありませんが、ある程度は解決してくれます。

バージョン管理システムではコミットする前に修正前との差分を取ります。以下はGitdiffですがだいたいどのシステムでもこのような形式の差分を取れます。

% git diff
diff --git a/hello.c b/hello.c
index 87d0d31..b65723c 100644
--- a/hello.c
+++ b/hello.c
@@ -3,6 +3,6 @@
 int
 main(void)
 {
-       printf("Hello, World!\n");
+       printf("Hello, Git!\n");
        return 0;
 }

Hello, World!Hello, Git!に変えたのですが、削除された行の先頭には-、追加された行の先頭には+が付いてて一目瞭然です。

バージョン管理システムを使うと、この差分を確認する工程が常に入ることになります。厳密に言うと差分取らずにコミットできますが、その辺はルールベースの対応ということで。いずれにしても差分を確認する際に「あ?これ何やってんの?」という話になることがしばしばですので、バグったままリポジトリコミットすることが減ります。もちろん見落としてしまうこともありますが、使ってなければ見つける機会もない訳で、そこを文句言うのは筋違い。


使え使え使え!!

ということで今すぐバージョン管理システムを使いたくなった方は以下のリンクからどうぞ。個人的なお薦めはGitですが、まずはお好みで。

*1:©森田和義アワー

2009年12月07日

下書き消えたな・・・

「イェ〜イはてなブログ作ったお!」とか思いながら初ブログしてたんだけど、Firefoxのアドオン入れたんで下書き保存してからブラウザをリスタートしたらバッサリ消えたな。

さよならー

さよならー

さよならーあぁー

もうすぐー 外はー 白い雪ー

初回からこれかい。前途多難だ・・・今回はちゃんと保存して終わろう。

ということでブログ始めました。どぞよろしく。

ってこれが初回かい。もっとマシなこと書けよ。

だいたいプログラミングノートじゃないのか?いきなりグチノートになってるじゃねぇか。

マジで前途多難だ・・・(引き続き無限ループをお楽しみください)