本家より。Yahoo!がC/C++で書かれた独自使用のページテンプレートシステムからPHPにバックエンドのスクリプトエンジンを変更するみたいだ。YahooのエンジニアがPHP Con 2002で行ったプレゼンの資料がYahooの過去のシステム構成やなぜ、PerlやASP、JSP、XSLT等ではなくPHPになったのか詳しい。
簡単にまとめると。 (スコア:4, 参考になる)
でも、PHPがいろんな側面で優れているという証拠なのか。
"普通のやつらの上を行け"をいまさら読んで、『Lispかよ…』と驚いていたところだったのに…。
PHPは、
1.生産性がよい。
2web用に作られてる。
2.FreeBSD上でのサポートがある。
3.そこそこパフォーマンスがイイ。
・JSP->FreeBSD上のサポートがない(または移行に時間がかかる?)
・CFML->コードが醜い。M$プラットフォーム向け。
・ASP->M$でしか動かないジャン。
・Perl->早いけど、ストレスかけすぎる。
・XSLT->うちのエンジニアにさせる仕事じゃないような。
++ ftsh ++
Re:簡単にまとめると。 (スコア:2, 参考になる)
一応こういうのがあるやね。
http://developer.chilisoft.com/software/
使ったことないのでアレだけど。
Re:簡単にまとめると。 (スコア:1)
chilisoft独自拡張なんてのもありますが。
ASP が Apache を組み合わせて 100% 互換(且つネイティブ)に動けば、けっこう広まると思うんだけどなぁ。。。
＃そう言っておいて実は Perl 使いなのでハンドル
Re:簡単にまとめると。 (スコア:1)
JSPの項は、FreeBSD上でのサポートがないというよりは、
- FreeBSDのスレッド周りはイマイチ
- スレッド無いのにJavaなんて使う気起きねーよ
てゆーところではないかと。Re:簡単にまとめると。 (スコア:2, 興味深い)
微妙に違うような...。
確かに Thread 周りはあまり考慮されていないようなところもあるけどむしろ、FreeBSD 上の Java が Green Thread しか対応していないというのが本当のところかと(ただ SMP を使いたいという要望でなければさほど問題にならないと思う)。
それよりもむしろ標準の JIT や HotSpot がないということの方が大きいと思うなぁ(HotSpot についてはそろそろ開発版がリリースできそうな雰囲気)。
Green Thread？ (スコア:1)
なんじゃそりゃ、と思ってぐぐって見ましたが、要はユーザーレベルスレッド(OSが提供するモノではなく、ユーザーランドのプロセスが自前で提供するスレッド)のJava用語、という理解で良いですか？
いや、まぁ、そういう意味で「FreeBSDのJavaのスレッドはイマイチ」と言った訳なんですが(と言い訳してみる)。
Re:Green Thread？ (スコア:1)
はい。JDK 1.0 の頃(Java 2 SE SDK と呼ばれるよりも以前)の Java VM はすべて Green Thread でした。Native Thread に比べて不利な点もありますが、効率はそう悪くない印象です(Ruby もそうですよね？)。
了解です(誤解してました(^^;)とともに Java VM の Thread 対応が良くないというのは御意です。OS 固有の Native Thread の実装状況においては Linux でも FreeBSD でも同じような気がしています(つまり良くない)。ただし Linux, FreeBSD とも新しいカーネルだと良くなってきているようです。
Lisp は遥か昔からシリアル化を… (スコア:1)
> 『Lispかよ…』と驚いていたところだったのに…。
ちょっと話がはずれますけど、私もこれ読んで同じように驚いた上に、さらに改めて Lisp の凄さを思い知らされたことがありました。それは、いまではシリアル化と呼ばれる機能がすでに言語として定義されていたことです。
Java には Serializable があります。Perl では CPAN に Storable なんていうのがあるみたいですけど、標準的に添付はされていないみたいです。PHP は 4.0 から serialize() できるようになったようです。C++ にもPOST++ [ispras.ru]なんていうのがあるみたいです。XML なんてデータ自体がシリアルですからね。
Re:Lisp は遥か昔からシリアル化を… (スコア:1)
ちなみにStorableもPerl5.8からは標準モジュールになりました。
でもData::Dumperなら昔から標準じゃなかったかなぁまぁデータ構造を「文字列化」するんでねぇ...(^^;
あとはFreezeThawとか、XML::DumperなんかはXML化するし(SOAP::Liteもねぇ...）って、こんなにいろいろあるから Yahoo!に嫌われたんだろうけど(^^)
.com のほうですよね？ (スコア:2, 参考になる)
.co.jp だと全然別物だとおもうんですが～
知っているでしょう (スコア:1)
PHP房急増の予感 (スコア:2, すばらしい洞察)
それにしてもちゃんといろんなプロダクトでベンチマーク取ってるのは立派。(ってあたり前か)
私の予感 (スコア:1)
PerlよりPHPの方が軽くて速いは本当ではなくウソ (スコア:1)
別ツリーですけど、Storable も google で調べてこのページから見つけました。てっきりこれしかないものかと思っていました。
PerlよりPHPの方が軽いけど遅いという結果 (スコア:2, 参考になる)
私としては、この時点ではこれがウソとは 思っていません。間違いなんじゃない？とは思ってますけど。
mod_perlのバージョンも、YSPなるものもわかりませんし、 実際のスクリプトも見てみないと。
ただ私としては自分の印象を 裏づけするような資料だなぁと思っています。それにしても mod_perl速すぎって気もしないでもないですが。
いずれにしても今回のこの話題のおかげで、 mod_perlってやっぱり速いんじゃん と思うのと同時に
分かってない人も、それに点数つけちゃう人もいるのね っていう意味で非常に参考になる話題でした。
cheap (スコア:1, 興味深い)
しかしこれだけ大規模なサイトが
ほとんどオープンソースのソフトウェアで動いているのは
ある意味感動しますな。
#最近のY! Japanはトラブル続きだけどｗ
Re:cheap (スコア:2, すばらしい洞察)
また、オープンソースのソフトウェアを支えているのもインターネット。
そう考えると、インターネットとオープンソースは運命共同体なのでしょうか。オープンソースが滅んだらインターネットも滅ぶ。そのまた逆も然り。
#オープンソースにケチ付けるやつはインターネット使うな！特にASP作っている会社！
#冗談冗談
// Give me chocolates!
Re:cheap (スコア:1)
Perlを使わない理由のところ (スコア:1)
– There's More Than One Way To Do It
ワラタ。
-- wanna be the biggest dreamer
それに加えて (スコア:1)
- wasn’t designed as web scripting language
って、初めからPerlにする気なかったんじゃん(笑)。そのワリにはベンチマークのYSP(mod_perl)は速過ぎる ような気もするけど。
Re:それに加えて (スコア:1)
use HTML::Template;
. . .というアプローチは、富豪的過ぎるかな。やっぱり。
use Test::More 'no_plan';
Re:Perlを使わない理由のところ (スコア:1)
PHP!=Perlの
も大分笑えます。$a = $b || $c; (スコア:1)
Re:Perlを使わない理由のところ (スコア:1)
There's More Than One Way To Do It （TMTOWTDI [tuxedo.org])
は、Perl界でよく使われる言葉です(ホントか?)
ラクダ本あたりで、Larry Wall自ら使用していたように記憶しています
Re:Perlを使わない理由のところ (スコア:1)
は、Perl界でよく使われる言葉です(ホントか?)
さらに補足すると、利点というかポリシーとして挙げられるフレーズですね。
そこを欠点と挙げてるのが笑えるところ。
-- wanna be the biggest dreamer
Re:Perlを使わない理由のところ (スコア:1)
究極の開き直り。
日本のはどうなるんでしょうね (スコア:1)
Re:日本のはどうなるんでしょうね (スコア:1)
米Yahooが安定した後に日本語ローカライズが行われるのでは
ないかと思います。
統合開発環境 (スコア:1)
何にしようか調査してるとこなんです。
自分の担当は、JAVA+Strutsなんですが、
eclipse+TOMCATプラグインを使って、コード補完＆デバック
になれるとなかなか便利で離れられなくなりそうです。
ただ、コンフィギュレーションファイルの書き方覚えるまで
結構苦労するような(俺の頭が悪いだけか？）
yahooなんかとちがってそんなに負荷かからないので、
とにかく生産性、拡張性重視って事で考えると統合開発環境
やツールの充実度が重要になってくるとおもうんですが、
PHPとかはどんな感じですか？
個人的にはASP.NETとかよさげだけどUNIX限定だから
今回はつかえない（というか当分使えそうにない）。
統合開発環境に加え型や厳密性 (スコア:1)
私はこれまでの趣味の開発では php を使ってきましたけど、型や文法が曖昧なところがどうも落ち着かなくて、php に IDE があったとしてもやはり Java に乗り換えていたと思います。Perl や php でたった一行のコードを、Java だと数十行書かなければならなかったりすることもありますけど、それはそれでコストだと割り切っています。
でも php にもクラスがあってオブジェクト指向でコーディングできるんですよね。Perl のクラスにはブチ切れましたけど、php は割と普通に盛り込まれていて、そういったところも決め手になったのではないでしょうか。何年後かならコミュニティの拡大によって Python や Ruby といった選択肢があったとは思うのですが。
それでも私は Java ですかねえ。大規模なサイトなのですから、データベース以外のモジュールを分散実行させたりするなんてことは考えていないのでしょうか。シンプルに二層クラサバで十分なんですかね。
C++で、this-hogeやってます。 (スコア:2, 参考になる)
関係ないけど、僕は、C++とかでメンバを参照するとき、
変数なら例外なく、
this->hoge
とします。メンバであることを強調するためです。
同じ趣旨で、MS-DOGな人たちが、m_hogeとかやってますが、あんなの死んでも嫌です。
関数でも、必要に応じて、
Home::page()
とかします。
コーディング規約 (スコア:1)
規約ではほかに、関数の引数は aHoge にする、とかありました。こういうのってメジャーなんですかね。
Re:コーディング規約 (スコア:1)
function(char const *const file_name) {…}
とするかわり、
function(FileName const n) {…}
とするわけです。当然、プロトタイプは、
function(FileName);
です。FileNameは、ただのtypedef char const *FileName; の場合もありますし、class FileName; の場合もあります。
Hoge aHoge; (スコア:1)
前述したとおり僕は、C(++)なら、Hoge x;で十分と考えています。これで混乱するようだったら、スコープが長すぎること、自動変数が多すぎることを反省するべきだ、と考えています。
Re:統合開発環境 (スコア:1)
●長所
・内部にPHPインタプリタを装備していてクライアントで実行可能らしい
・IDEにお約束な機能はバッチリ
・サーバ上のPHPコードもリモートでデバッグ可能
・実行環境の設定もリモートで変更可能(再起動は手動)
●短所
・Javaなので遅い
・UIの練りこみ度がちょっといまいちらしい
・キーバインドの変更が充実してない(一部しか変更出来ない等)
・PEARの設定等、初心者にはわからない部分が多いかも
・IDEのphp.iniが最低限の設定なので、テキストエディタで手動で変更しないといけない
だそうです。私は使った事がありません(^^; 一度トライアル使ってみようかなぁ。
すらど宴会SNS開放中 [e-meet.jp]
Re:統合開発環境 (スコア:1)
PHPの統合開発環境はZendIDEだけではなくて、
などいくつかあります。私もどれも使ったことはないのでアレなんですが、レビューによるとどれもそこそこ使えるものではあるようです。
あ、あと、ZendIDEに関して
> ・Javaなので遅い
というのは私の感触では嘘ですね。たまーにひっかかる感じはありますが、それ以外はなんでこんなに速いねんというくらい軽快に動いてくれました。
Re:統合開発環境 (スコア:1)
ごめんなさい、きっと遅いのは私のマッスィーンなのかもしれません(^^; 何気にトライアルのインストールにチャレンジしましたがクライアントもサーバもインストールで挫折(ぉぃ) やはりトライアルは余裕のある時にやった方がいいのかも。ちょっとインストールの途中でインターネット経由で zend.com にアクセスするのはちょっと難儀です(^^;
＃私の環境は XEmacs + php-mode.el
すらど宴会SNS開放中 [e-meet.jp]
あくまでFreeBSDで行くんですね (スコア:1)
FreeBSDでスレッドのサポートがいまいち
とあって、ここは意地でもFreeBSDでやっていくんだなあ、と。
FreeBSDなワタシにはちょっと嬉しくもあり。
--------------------
/* SHADOWFIRE */
要約＆和訳 (スコア:0)
ソースの「プレゼン資料」の要約を日本語で、英語が
得意な人頼む！
Re:要約＆和訳 (スコア:1, おもしろおかしい)
・一つの事やるのにいろんな書き方がありすぎる
・サーバをぶっとばす危険が高い
・Webスクリプティング言語としてデザインされてない
ASP
・文法汚い
・金！金！金！
JSP
・スレッド無しでは本当に使うことができない
（？このへん詳しくないのでよくわからない）
・FreeBSDでのスレッドサポートがよろしくない
XSLT
・難しい
Re:要約＆和訳 (スコア:5, 参考になる)
1. サーバー側でのWebスクリプト用にデザインされている
2. 大きく、オープンソースな開発コミュニティ
• 統合されていて、ライブラリがある
• ドキュメントやトレーニングがしっかりしている
3. デバッグ、プロファイルツールがある
4. シンプルで明快な文法
5. テストでよい成績
• 効率的（アクセラレータ付きで）
• 必要なメモリ量が少ない
＃ちょっと意訳した。
Re:要約＆和訳 (スコア:1, 参考になる)
て、言うか、スレッド無しでは、JSPのパフォーマンスが著しく低いからかも知れません。あと、FreeBSD上でのJavaのパフォーマンスはとにかく悪いような気がする。
# FreeBSDでJavaを使って久しくなるので悪しからず。
Re:要約＆和訳 (スコア:0)
英語が苦手でもだいたい読めると思うよ。
Re:要約＆和訳 (スコア:3, 参考になる)
・速い
・コンパイルしないと動かないのでHTMLの変更だけでもう大変すぎ
・シングルプロセス、やはり実行時のメモリーの確保でロスがある。
・コーディングめんどくさすぎ
Perl
・シングルプロセス。（実行し終わると、そのままメモリー開放）
・5.6からスレッドも出来るらしいが…
・呼ばれてから、コンパイル、実行の為、究極に遅い
・利用者が多い。駄目なソースがたくさん公開されている。
ASP
・Microsoftで固めた環境じゃないと動かない。
・HTMLのコードの中にプログラムを書き込める感じのサーバーサイドの言語としては最初に実現化(たしか）
JSP
・JAVAだけど、無理やりHTML内に埋め込んでみた言語。
・JAVA VMは相変わらず速いとは言えない。
・なかなかリッチにメモリーを占領する。
・マルチスレッド、オブジェクト指向
PHP
・アパッチのモジュールとして動く。PHP自体HTTPDのメモリーで動く
・最初に呼ばれるとコンパイルされてずっとその後メモリー上に置かれるらしい。
・Zendエンジンを乗っけると早くなるらしい。
・言語的にPerlに酷似してる
・使い捨てページ生成言語（再利用しにくい）
XSLT
・重くて使い物にならない。
・新しいし、思想が良いので期待だけ高い。
Re:要約＆和訳 (スコア:2, 参考になる)
原文にないことばっかり書いてあるんですけど。
Re:要約＆和訳 (スコア:2, 興味深い)
Perl
・呼ばれてから、コンパイル、実行の為、究極に遅い
て書いておいて、実際には mod_perl を評価しているので、
結果は最速なんですよね。もっとも最終的に PHP を選んだのは
人の確保しやすさと、サーバーの内部処理に手を突っ込んで
色々やりたくなってしまうという mod_perl の諸刃の剣度（？）の
高さを考えると妥当かなという気はします。
XSLTは…期待はともかくとして、誰か本格的に使っている人は
います？凝ったことをやろうとするとすぐ XML パズルが待って
いるので、開発者からは（プログラミング言語ではないので）
疎まれ、デザイナからも（実はプログラミングなので）意味
不明、ということになってしまうような…
Re:要約＆和訳 (スコア:1)
>> * Cons
>> - CF has ugly syntax
>私なら以下のように和訳しますね
>* 悪い所「CF(繰り返し?)の文法が醜悪」「言語やWindowsに金かかる」
CF = Cold Fusion では。
-- wanna be the biggest dreamer
Re:要約＆和訳 (スコア:0)
軽く流してみましたが、スライド部分を読む分にはそれほど困ることもないと思うのですけど。
Re:要約＆和訳 (スコア:1)
同感。
やっぱ、これくらい読めないと困るね。
PCにECC Registeredメモリの利用を推奨します。
Re:XSLTをPHPやASPやPerlと同列に比較するのはおかす (スコア:0)
まあ、この場合は、こくーんとか使ってサーバ上に おく直接的なコンテンツとして使うことを さしてるんでしょう。同列に使うような場合で比較してる わけで、特におかしいことはないと思われ。 別から扱えるかどうかはまた別の話ってことで。
俺もあれでページごりごり作成はあんまやりたくないに一票。