【PHP】フレームワークについて語るスレ12【総合】

【PHP】フレームワー� ..

417:nobodyさん
09/01/31 22:33:36
>>416
可能性じゃない。Yahooの場合はそうしているという話

おまえさん、壊れてきたね

418:nobodyさん
09/01/31 22:33:40
>>415
誰が困るってわけでもねーだろｗ

419:nobodyさん
09/01/31 22:34:48
>>417
つまり、Yahooの場合は、会社内で
ビジネスロジックであるライブラリを
使い回ししているということでいいんだよな？

420:nobodyさん
09/01/31 22:35:03
>>415

すまん、ちょっとおもしろかったんで。もうやめるわ。飽きたし。
そこの
> SSLページと非SSLページでセッションIDを共通にしたらセッションハイジャックされますよね。
のひと、
さぁ、勝利宣言どうぞ！
↓↓

421:nobodyさん
09/01/31 22:35:41
断る

422:nobodyさん
09/01/31 22:38:04
使い回しできるってことは、Yahooにとっては
一般的なロジックってことになるんだけどね。

いろいろいっている事が矛盾しだしてるｗ

423:nobodyさん
09/01/31 22:40:33
フレームワークじゃなくてライブラリだというが、
最近のフレームワークにはライブラリ相当のものが含まれているのが普通。

424:nobodyさん
09/01/31 22:42:02
やっと頭がおかしいやつが消えたか？

425:nobodyさん
09/01/31 22:43:38
おれは元の質問者ではないが、改めて。

> SSLページと非SSLページでセッションIDを共通にしたらセッションハイジャックされますよね。

至極単純に実装した場合、これは真だと思うんだが、どうなんでしょう。
また、これを避けるために例えば>>236の様な対策が施され、実装されているのは、（割合的に）
一般的なんでしょうかね。

（そうだとすると、自分の（会社の）作っているシステムがかなり後進的ry）

426:nobodyさん
09/01/31 22:58:58
ライブラリとフレームワークの違いは、「フレームワークとは何か？」って論争になりそうで触れたくねーけどな。
大雑把に言えば、SmartyとかPEARみたいに、特定の機能を提供するのがライブラリで、
アプリケーション全体の構造（MVC構造とか）を提供するのがフレームワーク。

フレームワークには複数のライブラリが含まれる事が多いけどな。
テンプレートライブラリとか、O/RマッパーみたいなDB中間層とか。

二重ログインを提供するだけならば、それは単なるライブラリ。
フレームワークの一部として組み込むと便利そうだ、というだけでな。

427:nobodyさん
09/01/31 23:00:50
>>426
餌をやらないでください

428:nobodyさん
09/01/31 23:05:05
>>426
んなもん、Yahooパターンか、それ以外かを
入れ替え可能な仕組みになっていれば
その程度でフレームワークになる。

そのフレームワークに沿ったつくりの
Yahooパターンクラスはなんになるんだろうな？
フレームワーク？プラグイン？

429:426
09/02/01 00:54:30
>428
前半は意味が不明なので読み飛ばす。

そいつが存在しないとフレームワークが動かないならば、フレームワークの一部。
存在しなくとも動くならプラグイン。

430:nobodyさん
09/02/01 00:58:57
正確にはフレームワーク標準のプラグイン

431:nobodyさん
09/02/01 00:59:12
継続ベースのPiece Frameworkなら、HTTPとHTTPSのスキーム切替えは簡単なんじゃないでしょうか？

URLﾘﾝｸ(trac.piece-framework.com)
フローIDによって別のフローに接続するビュースキーム
例えば、フローID /foo のフローにクエリ変数bar, bazをともなって接続するには下記のようにする。
flow:///foo.php?bar=baz&baz=qux
SSLで接続したい場合は、下記のようにする。
flows:///foo.php?bar=baz&baz=qux

たったこれだけでSSLにパッと切り替わるんですよね？

432:nobodyさん
09/02/01 01:04:47
URLﾘﾝｸ(trac.piece-framework.com)
Piece_Flowによって、実行中のフローの状態はHTTPリクエストをまたがって保持され、フローの状態遷移の順序は完全にコントロールされます。
このことは状態の保持を前提としてプログラムを書くことを可能にします。
さらに、Piece_Flowは不正リクエストやCSRF攻撃、セッション固定化攻撃から自動的にアプリケーションを保護します。

Piece Frameworkは使うときにやたらと設定ファイルをガシガシ書かなきゃいけないみたいだったので使おうと思ってなかったんですけど、
そういう仕込み作業って、Javaのフレームワークを使っている人にとっては、そんなに苦行じゃないですか？

433:nobodyさん
09/02/01 11:34:03
>>431-432
なんか面白そうだけど、Piece使ったことないや
ドキュメントだけでも読んでみようと思ったが・・・無いじゃないかｗ

聞き慣れない概念や用語をがしがし取り込むのはいいけど、その説明をしないでは
多分理解しにくいしちょっと手が出せない感じ
ソース頑張って読んだらわかってくるのかもしれないけど。
Piece_Flowの最後のstableが去年の夏で、半年間もドキュメント整備しないとか
どうなんだろう。
実際に使ってる人ほとんどいないんじゃなかろうか。

434:nobodyさん
09/02/01 16:33:19
>>433
Piece_Flowは単体でも使えるように設計されているけど、
普通はPiece_Unityを使うから存在を意識することはほとんどないよ。
フロー定義はPiece_IDEを使って作ると楽。

435:nobodyさん
09/02/01 17:11:42
一時期、PHPプロ（アシアル）さんが押してたみたいですが、最近あまり話題を聞かない…
ドキュメントの誤字脱字チェックぐらいなら協力できると思います！！！
ピースの中の人、頑張ってください＾＾

URLﾘﾝｸ(trac.piece-framework.com)
Piece Frameworkドキュメント

URLﾘﾝｸ(gihyo.jp)
連載　Piece Frameworkによるブログアプリケーションの作成

URLﾘﾝｸ(www.amazon.co.jp)
Piece Frameworkで作る対話的なアプリケーション

436:nobodyさん
09/02/01 17:14:39
　　　　　　　　　　　　　_,,..r'''""~~`''ｰ-.､
　　　　　　　　　　　 ,,.r,:-‐'''"""~~`ヽ､:;:;:＼
　　　　　　　　　　 r"r　　　　　　　　　ゝ､:;:ヽ
　　 r‐-､　　 ,...,,　|;;;;|　　　　　　　,,.-‐-:､ヾ;:;ゝ
　　 :i!　 i!　　|: : i! ヾ| r'"~~` :;:　::;",,-‐‐-　 `r'^!
　　　 !　 i!. 　|　 ;|　l| 　''"~~　　　､　　　　　　i' |
　　　 i!　ヽ　|　　|　|　　　 ,.:'"　　　､ヽ､　　　!,ﾉ　イェ～イ
　　　　ゝ　 `-! 　:|　i!　　.:;:　'~~ｰ~~'"　ﾞヾ　: : ::|　　ピースの中の人、
　　 r'"~`ヾ、　　　i!　i!　　 ,,-ｪェI二エﾌﾌ　: : :::ﾉ~|`　　頑張ってください＾＾
　　,.ゝ､　　r'""`ヽ､i!　`:､　　ー　-　'"　:: : :／ ,/
　　!､　 `ヽ､ー､　　ヽ‐''"`ヾ､.....,,,,＿,,,,.-‐'",..-'"
　　 | ＼ i:" ）　　　　 |　　　~`'''ー----''"~
　　　ヽ　`'"　　　　ノ

437:nobodyさん
09/02/01 17:26:04
今連載記事飛ばし読み中
ピースフローは、ZFと組み合わせて使えるらしい。

URLﾘﾝｸ(gihyo.jp)
Piece_Flowは汎用のフレームワークであり，他のフレームワークと容易に統合することが可能です
Zend Frameworkと統合したRevulo_Controller_Dispatcher_Flowがあります。

URLﾘﾝｸ(www.revulo.com)
Piece_Flow を Zend Framework に組み込み、 Piece Framework と同様のステートフルなプログラミングができるようにします。

　　　　　　　　　　　　　,.,.,.,.,.,.,.,.,__
　　　　　　　　　　　,,;f::::::::::::::::::::::ヽ
　　　　　　　　　　　i::/'￣￣￣ヾi::l
　　　　　　　　　　　|::|　／　　＼,|::|
　　　　　　　　　　　|r-（・ );（・ )-|
　　　　　　　　　　　(　ヽ :::(__)..:: 　}　　＜・・・で、SSLは簡単になるの？
　　　　 ,＿＿__／ヽ　 -==-　/
　　　　 r'"ヽ　　 t､　　ヽ＿＿_/
　　　　/ ､､i　　　ヽ＿＿,,/
　　　 /　ヽﾉ　　j　,　　　j　|ヽ
　　　 |⌒`'､__ /　/　　　/r　 |
　　　 {　　　　￣''ｰ-､,,_,ﾍ＾　|
　　　　ゝ-,,,＿＿＿＿_）--､j
　　　 /　　＼__　　　　　　/

438:nobodyさん
09/02/01 17:32:07
HTTPとHTTPSのスキーム切替えの対応方法を
>>1のテンプレFWのユーザーの皆様がご紹介ください！！！
トップバッターはシンフォニーでお願いします＞＜

↓↓↓

439:nobodyさん
09/02/01 17:47:35
ピース連載記事、チラ見でYAMLの嵐…
頭が痛くなりそうだけど、IDEを使えばサクサク書けるのでしょうか？>>434

URLﾘﾝｸ(gihyo.jp)
Piece_IDEのフローデザイナーはGUIベースのフロー定義を可能にします。
フローデザイナーを使うと複雑なフローでも混乱することなく開発を進められると思います。

URLﾘﾝｸ(trac.piece-framework.com)
Piece_IDEは、Eclipse上に構築されたPiece Frameworkの統合開発環境です。

440:nobodyさん
09/02/01 17:59:41
Gauche＋Kahuaで、ステートフルなWebアプリ作成を練習してみると、Piece Frameworkの利便性が分かるでしょうか？
URLﾘﾝｸ(www.thinkit.co.jp)
ｽﾚﾘﾝｸ(tech板)

URLﾘﾝｸ(txqz.net)
httpプロトコルはステートレス。
COOKIEとかGETパラメータとかPOSTパラメータとか他のヘッダとかを使って擬似的にステートフルにできている。
ステートレスだけで処理しようとすると問題が起こる。
[入力]→[確認]→[完了]と画面が推移するとき、ユーザが入力した情報をhiddenパラメータなどでクライアントに返してしまうと、確認の前と完了の前とで2回データチェックする必要が出てくる。
HTTPプロトコルがステートレスなのにアプリがステートフルを要求している。
いまさらHTTPプロトコルは変えようがない。
そこのギャップをフレームワークがうまく解決してくれる。

HTTPの仕組みの上でWEBアプリを作るのは、PHPだけの悩みじゃないんですよね～＞＜

441:nobodyさん
09/02/01 18:01:34
URLﾘﾝｸ(gihyo.jp)
現時点でステートフルな特性を持つフレームワークは少数派です。
それでも，筆者はステートフルな特性がWebアプリケーション開発において重要な価値があると考えています。
そして，Piece Frameworkはまだまだ進化の過程にあります。
アプリケーション開発の中心をより本質的な部分にシフトさせるべく，Piece Frameworkの開発は続きます。
Piece Frameworkの今後の発展にご期待ください。

ここまで読んで頂いた皆様に感謝いたします。
ありがとうございました。

442:nobodyさん
09/02/01 18:03:26
土日の勉強タイム終わり
ピース試す時間なかったorz

443:nobodyさん
09/02/01 18:10:30
オツカレ。
あとはブログにでも書いてくれ

444:nobodyさん
09/02/02 00:32:10
そうだよな
ステートレスなHTTPプロトコルを、フレームワークがステートフルにしてくれれば誰がWEBアプリを作ってもセキュアになる

445:nobodyさん
09/02/02 01:58:28
しかし自演し放題のスレだとくだらない煽り合い始まると
一部の馬鹿がオナニー覚えた猿みたいに自演連投し出して始末に終えないなｗ

446:nobodyさん
09/02/02 02:10:06
>>445
自覚しろよ。

447:nobodyさん
09/02/02 03:52:14
それセッション変数で（ｒｙ

ステートフルに作らないといけない処理は、webサービスのごく一部だしなぁ。
そのためにフレームワークいっこ覚える気にはならん。
大体そういう場所ってセキュリティ的にも大事な場所だから、曖昧な理解で他所のコード使うわけにもいかんし。

448:nobodyさん
09/02/02 07:12:40
>>>444
ステートフルになったら、誰が作ってもセキュアになるってセンス、ありえねぇ

449:nobodyさん
09/02/02 10:36:18
誰が作ってもセキュア…これはデジタル土方の間で流行る予感（・∀・）
フレームワークで無理ならもっと下のレイヤーで改善したら確実ですよね？
＝HTTP/HTTPSに代わる新しいセキュアなプロトコルを作ればいいんじゃないか？
でも、面倒くさし金にならんから誰もやらんか…俺はやる気以前の問題として知識がないから無理ｗ

450:nobodyさん
09/02/02 10:44:14
IDSに依存する開発者とか、バカすぎるだろ。あれと一緒。

451:nobodyさん
09/02/02 10:46:29
PCの場合、ユーザーを特定する方法って複雑そうですね＾＾
携帯電話は、端末IDを使えばユーザーの特定が安全＆楽でしょうか？

452:nobodyさん
09/02/02 11:01:12
>>451
携帯の端末IDって設定で許可していないと取れなかったような気がするが、
今はどうなってるの？

453:nobodyさん
09/02/02 13:51:06 xbZu7ZNv
ところで、ステートフルとスレートレスの違いって何？
PieceFrameworkの利点って何？教えてえらい人。

>>452
機種によって違うけど、アクセスするたびに許可を求めてくる物がほとんどだと思う。

454:nobodyさん
09/02/02 14:27:46
>>453

> ステートフルとスレートレスの違いって何？
ｽﾚﾘﾝｸ(php板)

> PieceFrameworkの利点って何？
URLﾘﾝｸ(piece-framework.com)

自分でもう少し掘り下げてから質問したらどうよ

455:nobodyさん
09/02/02 15:00:08
URLﾘﾝｸ(www.ruby-lang.org)

Ruby1.9安定版が出ていよいよPHP脂肪カウントダウン開始ｗｗｗ

456:nobodyさん
09/02/02 15:04:12
>>453
クッキーやIPアドレスに比べ、より直接的に個人特定・追跡できそうな情報なんだが、
前提にしているサイトって多いのかな？あんまり騒ぎにならないな
これって、その機体の契約の間ずっと不変なんでしょ？

457:nobodyさん
09/02/02 15:08:42
騒ぎになってるよ

458:nobodyさん
09/02/02 15:48:00
>>455
奇数バージョンは実験的なバージョンだよ
Linuxのカーネルと同じ

459:nobodyさん
09/02/02 16:08:03
待て、Rubyはどうかしらんが、Linuxカーネルに
今は偶数か奇数かで安定版と開発版の区別はないぞ。

Rubyも偶数奇数でわかれてたっけ?
そのへんは、おおらかにやってそうなふいんきだけど...

460:nobodyさん
09/02/02 17:14:57
URLﾘﾝｸ(blade.nagaokaut.ac.jp)

461:nobodyさん
09/02/02 17:22:35
なぜ本家リファレンスマニュアルを参照しない。

URLﾘﾝｸ(www.ruby-lang.org)

> Ruby のバージョンは、 major.minor.teeny という形式です
>
> version 1.8 までは、minor が奇数のバージョンは開発版、 minor
> が偶数のバージョンは安定版です。1.9.0 以降は、 teeny が 0
> のバージョンが開発版となる予定です。

なので1.9.1は安定版でよかろう。つかwww.ruby-lang.orgにそう書いてある。
しかし、それが本当に安定しているかどうかは別の問題だが。

462:nobodyさん
09/02/02 17:31:17
Rubyは文法が涙目だから駄目だろ
elsifだけは勘弁してくれよ

463:nobodyさん
09/02/02 18:12:53
>>462
じゃぁPerlと（略）とTT.pmの組み合わせにしなさい。

464:nobodyさん
09/02/02 18:24:05
>>462
そのキーワードの何がそんなに気に入らないのかわからん。
PHPのarray_**は気に入らんが、それだけで文法が駄目とか思わんし。

465:nobodyさん
09/02/02 18:28:15
elsifとかelifとか慣れの問題だろ。柔軟に適応できないやつはマに向いてないぞ。
あれこれ難癖つけて1つの言語にこだわって結局自滅するんだ。

466:nobodyさん
09/02/02 19:08:34
禿堂

467:nobodyさん
09/02/02 19:14:01
インターネットって危険がイッパイなんですね！＞＜
大事な用件は直接会って話そう！

468:nobodyさん
09/02/02 19:58:48
}
else
if () {
}

って書けなくて気持ち悪いからだろ
CやJava書いてる奴はそういう奴多い

469:nobodyさん
09/02/02 20:18:47
case～when があるから elsif なんかめったに使わないし

470:nobodyさん
09/02/02 20:44:56
>>468
そんなこだわりをもったまま他の言語を使おうと思う方がおかしくないか？
まるで世界中英語で押し通す英米人のようだ

471:nobodyさん
09/02/02 20:48:12
ハワイで日本語が通じないって怒ってる日本人だろ

472:nobodyさん
09/02/02 20:53:14
>>470
いやだからPHPフレームワークのスレにいるんだろこの人は
なんでそこでRubyやる覚悟を説く必要あるんだ

473:nobodyさん
09/02/02 20:57:03
C＝イギリス
Java＝アメリカ
PHP＝オーストラリア
だとして、
イギリス系やアメリカ系のオーストラリア人同士が、
フランス語って英語と文法違ってめんどいよねー
でもオーストラリアは英語だからいいよねーって話してたら、
急にフランス人が来てその意味解らん、そんなんでフランス語が
できるようになるわけないだろ、って言われてるようなもんだな。

474:nobodyさん
09/02/02 21:17:26
適応力があるかないかの差でしょ
言語として使う必要がくれば使うことに別段抵抗はないなぁ
重要なのは何を使うかじゃなくて何を作るかだしなー

まぁRubyは当面必要になるような場面が全然思い当たらないし
勉強する気もないけどさー

つか、好き好き語るならPHPFWの好き嫌いを語ったほうがよさそうだｗ

475:nobodyさん
09/02/02 21:17:34
オーストラリア馬鹿にすんな!!!

476:nobodyさん
09/02/02 21:28:22
本当に馬鹿にされてるのはおフランス

てゆーか一番問題なのは定期的に多言語界隈に沸く
Ruby信者の低脳な釣り餌に全力で食いつく雑魚どもだとおもうけどなｗｗ

477:nobodyさん
09/02/02 22:00:19
今回のエサはRubyアンチが撒いてるんじゃないか
どっちでも食いつきがいいんだけどなこのスレは

いつものこととはいえ、お前らほんとはPHP嫌いで使ってるだろｗ

478:nobodyさん
09/02/02 22:02:28
古女房みたいなもんだ
ミテクレはいまいちでも、いつでもやれるし、あそこのフィット感がいい。

479:nobodyさん
09/02/02 22:33:33
>>478
確かに。しかも安く済む。

480:nobodyさん
09/02/03 01:40:22
俺たちデジタル土方は、既製品を使う立場。
既製品が気に入らないなら、自分で好きなようにプログラミング言語を作ればいい。
でもプログラミング言語を開発する手間に比べたら、既製品を使う方がずっと手軽だ。
既製品を使う必然性は、すぐ使えるという利便性にある。
既製品とはいえ、ある程度の選択肢は用意されている。
PHPが気に入らないのなら、Perl、Python、Ruby、Java…他の既製品を使ってみればいいじゃないか？
ここで上から目線で語って「俺はスゴイ！」という気分に浸れるのか？
ちっぽけなプライドなんて何の役にも立たないぜ？
PHPのフレームワークで、WEBアプリをいかに速くセキュアで簡潔に作れるか？
その恩恵を享受できないとしたら、このスレに来ても時間の無駄だろう。
みんなでスキルアップしまくって、日本の開発スピードを世界最速レベルに引き上げようぜ！！！

URLﾘﾝｸ(q.hatena.ne.jp)
>どのような価値ある情報を日本語で蓄積するかが大切なはずです。

…以上、デジタル土方の主張でした＾＾

481:nobodyさん
09/02/03 06:50:56
キモッ

482:nobodyさん
09/02/03 07:15:56
別にデジタル土方じゃねーし

483:nobodyさん
09/02/03 10:07:10
>>468
だから適応能力のない人は食ってけませんよっと。

484:nobodyさん
09/02/03 11:05:42
>>480
言ってることは至極まともっぽいんだが、2chでアジ演説ってのはネタだなあ

485:nobodyさん
09/02/03 11:23:06
>>468
> }
> else
> if () {
> }
>
> って書けなくて気持ち悪いからだろ

俺は素直に} elseif () { って書くのでぱっと思いつかないが、
if と else がある言語でそういう書き方が出来ない言語ってあるのか？

486:nobodyさん
09/02/03 11:26:26
else
if () {
}
だとifとの差別化ができなくね？

487:nobodyさん
09/02/03 11:45:16
>>485
いや、だからRubyではelse ifとは書けないから云々ってずっと話をしてたんだけどなぁ...
つか蒸し返すなよ。

488:nobodyさん
09/02/03 12:03:09
>>487
どこのスレ来て言ってるんだよ。PHPもelse ifはできないだろうが。

489:nobodyさん
09/02/03 12:05:07
まさかPHP5は可能といかいうオチ？

490:nobodyさん
09/02/03 12:09:31
>>488-489
PHPでもできるよ。

491:nobodyさん
09/02/03 12:21:15
>>490
ほんとだ。PHPでもできた。ｽﾏｿ。

492:nobodyさん
09/02/03 12:36:42
マジレスすると、Rubyの実行速度がPHPを上回ったら、Rubyはシェアを取れると思う。
PHPで出来ることは、Rubyでも出来るからね。

Rubyの改善には期待してます。
ただし、続きはRubyスレでお願いします＞＜

493:nobodyさん
09/02/03 12:46:22 U0x1Z73i
それは夢のまた夢

494:nobodyさん
09/02/03 12:48:03
＞ただし、続きはRubyスレでお願いします＞＜
って言いながら香ばしい餌垂らしていくんじゃねえｗ

495:nobodyさん
09/02/03 12:51:48
ＰＨＰは実行時に余計な処理せずに最小処理だけして爆速にできるオプション選べるように
すればもっとシェア広がると思う。
普通使わない変数への初期値セットとか設定ファイルいちいち呼んだり余計なステップが多すぎ

<?php set_quickmode(); みたいに書いてさ・・

496:nobodyさん
09/02/03 13:07:20
速くしたいだけなら、VM作ってコンパイル・最適化済みのバイトコードを、
メモリにのっけておいて実行するようにすればいいんじゃない？
大体今風に作られたスクリプトではrequireあたりも大きなボトルネックっぽいし

ただ動作速度を速くしたってこれ以上シェアが広がるとも思えんけどな
すでに棲み分けって点では十分できてるだろ

497:nobodyさん
09/02/03 13:43:31
Javaにコンパイルできるぞ

498:nobodyさん
09/02/03 14:31:04
JRubyでJavaとして使う
これがRubyの生きる道？

499:nobodyさん
09/02/03 14:34:25
まあ、PHP以外も普通に使えるようにしとこうぜ！って話だな

500:nobodyさん
09/02/03 15:28:08
パフォーマンスの面ではPHPも人のこと言えないからなぁ
高負荷サイトだと今でも、調査の結果mod_perlにしましたみたいなことあるし

501:nobodyさん
09/02/03 15:45:39
っていうかフリーのＦＷって、全部実行時コンパイルじゃないの？
ＦＷの意味半減だと思うんだが。

502:nobodyさん
09/02/03 15:52:23
実行時コンパイルかどうかはフレームワークの問題じゃなくて実行環境の問題な気がするが
コンパイルが通るかどうかは別として他のフレームワークでつくってZendに食わせてもいいんだし

503:nobodyさん
09/02/03 16:00:32
自分の知る限りではPHPだとアプリケーションサーバとして動作する
（メジャーな、実績のある）フレームワークは存在しないし、
mod_phpもmod_{perl,python,ruby}のような常駐型として作られていないので
リクエストごとにインタプリタが動きます。

ただ、それとフレームワークのメリットとは全くもって関係ないです。
Webアプリケーションフレームワークは生産性・保守性の向上のためのもの。
コンパイルのコスト軽減にはAPCやeAccelerator等を使うのが一般的。

504:nobodyさん
09/02/03 16:05:48
超有名な
URLﾘﾝｸ(www.zend.co.jp)
これは、ダメですか。そうですか。すごいですね。

505:nobodyさん
09/02/03 16:09:14
>>503
アプリケーションサーバーかつフレームワークな実装もPHP以外なら存在するのはたしかだけど
それが一緒に提供されるメリットは感じないな。
その話とインタプリタの話がどうしてつながるのかわからないんだけど？

506:nobodyさん
09/02/03 16:11:52
本当ですね。Zend Platformがフレームワークだったとは寡聞にして知りませんでした。

507:nobodyさん
09/02/03 16:13:50
>>506
フレームワークなんて言ってないよ。（フレームワークとしての機能もあるけど）
PHPソースをコンパイルした状態で保持して実行するよって話

508:nobodyさん
09/02/03 16:16:37
>>507
失礼。前半じゃなくて後半へのレスでしたか。

509:nobodyさん
09/02/03 16:19:30
>>508
どうでもいいや。わけわかんねぇ

510:nobodyさん
09/02/03 17:44:52
Zend使えばJavaみたいにVMの上で動いてるのと同じような感じなるわけだが、
それじゃ不満なんだろうか。
もちろんZendFrameworkじゃないフレームワークでも問題ないし。

511:nobodyさん
09/02/03 17:50:27
>>510
Zendって省略しないで。それは会社名でしょ。
Zend PlatformでもVM上で動いているのと同じになるわけじゃないでしょ

512:nobodyさん
09/02/03 17:50:50
>>510
金かかるんじゃねーの？

513:nobodyさん
09/02/03 17:58:28
金かかるよ。それで？

514:nobodyさん
09/02/03 18:06:03
最近の顧客はWebアプリケーションは無料と思ってるところ多いから、
その手のを請求したらケチつけてくるよ。ライセンスがどうなってるのか
しらねーけど。

515:nobodyさん
09/02/03 18:09:42
Ａ「ＰＨＰで金が掛かるなんて聞いたことがないね」
Ｂ「フレームワークを使うからなんです。フレームワークを使えば
コードの保守・管理が楽になり色々とメリットが・・・」
Ａ「なるほど。あんたらが楽するためにこっちが金出せと？」

516:nobodyさん
09/02/03 18:13:29
>>510のはフレームワークじゃなくてサーバじゃないの？
今はなきColdFusionみたいな

517:nobodyさん
09/02/03 18:14:36
>Zend PlatformでもVM上で動いているのと同じになるわけじゃないでしょ

なるよ

518:nobodyさん
09/02/03 18:17:03
>>516
ColdFusionはまだAdobeからFlexと併売されてなかったっけ?
ていうかColdFusionやFlexこそがフレームワーク込みのサーバ製品だよね。

519:nobodyさん
09/02/03 18:29:22
Flexはともかく、ColdFusionをフレームワークというのは、
PHPそれ自体がフレームワークだ！っていう程度の意味しかないような。

520:nobodyさん
09/02/03 18:33:49
PHPもアクセラレータ使ったら充分速いよ
だいたいYahooがPHPで動いてるんだから99％のサイトはPHPでおk

521:nobodyさん
09/02/03 18:40:07
>>517
そのVMって、どういう意味？

522:nobodyさん
09/02/03 18:41:32
>>514
Webアプリが無料って・・・もしかして、それホームページ？

523:nobodyさん
09/02/03 21:24:57
>>520
PHPで大規模なサイトも作れますね！スゴイ（・∀・）
ちなみに私のホームページは、なんと！１日１００アクセスぐらいです＞＜

サーバが１台で済むような小規模サイトなら>>503の対策で十分ですよねー？＾＾
>APCやeAccelerator等を使うのが一般的

524:nobodyさん
09/02/03 21:35:53
URLﾘﾝｸ(www.atmarkit.co.jp)
Rubyが遅い理由
遅いのにはいくつか理由がある。
1つは変数に静的型がなく、コンパイル時に型が決まらないことから最適化が効きづらいこと。
しかし、これは動的言語共通だ。
ほかにRubyが遅い理由として前田氏はRubyには「関数がなく、すべてメソッドであること」があるという。
ただ、Rubyは次期開発バージョンのRuby1.9系ではインタープリタをまるごと差し替え、バイトコードを処理するVM を採用したことで多くの最適化を実施し、大幅に高速化しているという。

Pythonも3.0になったことだし、PHPの包囲網は強力だぞ！！！
Perl6.0は(ry

525:nobodyさん
09/02/03 21:40:37
>>517
VM＝ヴァーチャルマシンのこと。
Javaの仕組みで使われて有名だよ。
URLﾘﾝｸ(d.hatena.ne.jp)

526:nobodyさん
09/02/03 23:47:25
>>520
Yahoo!JapanはあんまりPHPで動いてないぞえ
知恵袋とかはそうだけど昔からある部分はCかJavaだお

527:nobodyさん
09/02/03 23:49:55
Zend EngineがJavaのVMっぽいってこういうことだな
URLﾘﾝｸ(journal.mycom.co.jp)

528:nobodyさん
09/02/03 23:57:32
そ、それ2000年の記事ですけど、PHP5でもそうなの？

529:nobodyさん
09/02/04 00:10:47
いったんバイトコードにコンパイルしてからVMで実行するのはPHP4でも5でも6でも同じ。
PythonやRuby 1.9でも大ざっぱに言うと同様の仕組みになってる。
あとはVM(エグセキュータ)に手を入れてia32/amd64だけでもJITコンパイラが搭載されるとおもしろいのだけど。

530:nobodyさん
09/02/04 00:16:08
勉強になりました。

531:nobodyさん
09/02/04 00:17:17
>>528
どうでもいいけど俺には2004年に見える

532:nobodyさん
09/02/04 00:18:04
>>528
どうでもいいけど俺にはPHP5の記事に見える

533:nobodyさん
09/02/04 00:37:31
>>527 >>529
普段意識してなかったけど、PHPってそうなってたんだ！
参考になりました。

534:nobodyさん
09/02/04 00:46:03
PHPフレームワークの本が揃い、使いやすい状況にある。
ダントツ１位がないのは、それぞれ一長一短だからだろうか？
各FWのユーザーから、「この実装は、このFWではこうやっているよ。メリットはこれこれ。」という報告をよろしく！
FW同士、切磋琢磨していいとこ取りをしよう！

他のLL言語のメリット・デメリットはこちらもどうぞ
ｽﾚﾘﾝｸ(tech板)
【Perl,PHP】LLバトルロワイヤル3【Ruby,Python】

535:nobodyさん
09/02/04 00:57:47
>>534
× こちらもどうぞ
○ こちらでどうぞ

でいいだろｗ

536:nobodyさん
09/02/04 01:07:12
mod_phpが常駐しないことのメリットは、なんと言ってもデプロイが簡単なことだな。単にファイルを差し替えるだけでいいんだから。
そして、これで十分なスピードがある。
スクリプト言語の処理速度の差なんて、ウェブに限って言えばどうでもいいレベル。速度差はDB部分にかかってるわけで。

537:nobodyさん
09/02/04 01:20:31
いやそんなことない。
DB部分は殆どキャッシュされてるがアクセスの多いページ、例えばサイトトップとか。

538:nobodyさん
09/02/04 01:22:05
重箱の隅をつつくようで悪いけど、mod_phpそのものは常駐してますやん。
バイトコードやシンボルテーブルはリクエストの度に初期化・実行・破棄されるけど。
あとは同意。

539:nobodyさん
09/02/04 01:22:45
はてなとかmixiくらいになるとその差が重要になってきて
だからわざわざめんどいmod_perl使ってるんだろ

540:nobodyさん
09/02/04 01:27:58
>>537
そういうのはコンテンツキャッシュでどうとでもなる。

mixiは知らんけど、はてなの場合は中の人がPerlを使える・Perlを使いたい、
かといってCGIは遅すぎるのが理由な希ガス。

541:nobodyさん
09/02/04 01:28:55
mod_perlとは懐かしい響きだ
それは確かに面倒くさそうだ。てか、未だにメンテされてるの？

542:nobodyさん
09/02/04 05:45:22
常駐するから速いとも一概に言えないじゃん
Rubyなんて常駐させても遅いよ

543:nobodyさん
09/02/04 11:41:49 cqQgvAqQ
YahooはRubyだお

544:nobodyさん
09/02/04 11:53:43
RubyもいいけどPHPもね
URLﾘﾝｸ(searchblog.yahoo.co.jp)

545:nobodyさん
09/02/04 13:04:10
世紀末Web土方伝説～LLの拳～
例えるなら、
Python（グーグル）…ラオウ
Ruby（楽天）…トキ
PHP（Yahoo）…ケンシロウ
Perl（はてな）…ジャギ
というポジションでしょうか？（・∀・）

546:nobodyさん
09/02/04 13:07:17
Perlは（現状ではなく）役割的にはリュウケンのような気もするが

547:nobodyさん
09/02/04 15:41:16
わかりやすく芸人に例えてくれ

548:nobodyさん
09/02/04 15:51:12
楽天はRuby殆ど使ってないぞ
99%がPHPとJava
研究してるけど全く表に出てこないｗ

549:nobodyさん
09/02/04 16:13:35
わかりやすく実写版ドラゴンボールに例えてくれ

550:nobodyさん
09/02/04 16:18:51
よけいわかりにくいわｗ

551:nobodyさん
09/02/04 16:20:06
>>545
Rubyはトキだと思ってたらアミバだったぜ！みたいな感じか？
PHPがケンシロウってのはｗバットかアインくらいで妥協しておけ

ECMAScript群はきっと南斗聖拳

552:nobodyさん
09/02/04 16:57:49
Googleも実はPythonあんまり使ってないんだよなｗ
サービスの殆どはCとJavaで、Pythonはヘルプ機能とか軽いところしか使われてない。

553:nobodyさん
09/02/04 17:28:36
Rubyはフリーザって感じだな。
出た当初は桁外れに強くて
今でも強いイメージがあるんだけど、
実はそんなでも無い？

PHPはクリリン？あまり強いわけじゃないが
登場回数は多い。でもよくよく考えると地球人最強？

えーと、クリリンって最後の方ではフリーザより強くなったんだっけ？

554:nobodyさん
09/02/04 17:36:40
ドラゴンボール戦闘力の軌跡なんてのがあるんだなｗ
フリーザ弱っ。天津飯つえー。

ｽﾚﾘﾝｸ(retro板:676番)
フリーザ；1億2000万
ヤムチャ：3億5000万
クリリン：12億6500万
天津飯：60億4500万
公式戦闘力（｢ドラゴンボール戦闘力の軌跡｣集英社より)

555:nobodyさん
09/02/04 17:37:36
うん。やけくそなインフレがよくわかる

で、ここはいったい何のスレなんだｗｗｗ

556:nobodyさん
09/02/04 17:41:26
ポタラ・フュージョン公式によると、もっとすごいよ。
URLﾘﾝｸ(www.geocities.jp)

557:nobodyさん
09/02/04 17:48:28
ヤムチャなめんなよおまいら

558:nobodyさん
09/02/04 18:00:45
URLﾘﾝｸ(www.youtube.com)

559:nobodyさん
09/02/04 23:39:35
新しい言語どんどんできたけど
結局今でもC、Java、Perl、PHPって感じだよね

560:nobodyさん
09/02/04 23:45:32
ＣとPerlとはすごいよな
JavaとPHPはウェブありきで作られた面もあるからすごくて当然だけど

561:nobodyさん
09/02/05 01:18:17
糞言語ばっかりだな

562:nobodyさん
09/02/05 01:57:20
JavaがWebに使われるようになったの結構後だぞ
J2EEとか最初無かったから

563:nobodyさん
09/02/05 09:11:17
>>562
HotJava......

564:nobodyさん
09/02/05 13:50:05
Applet...

565:nobodyさん
09/02/05 18:46:36
>>562
昔を知らないんだね。Appletとかちょっと書けると結構金になったもんだぞ。

566:nobodyさん
09/02/05 22:25:45
>>563
糞久しぶりに聞いたｗ

567:nobodyさん
09/02/05 23:19:28
C、Java、Perl、PHPの話してるんだからAppletとかそう言う問題じゃないだろうに
Flashとかとの比較になるだろそういうのは
もともとJavaはWebでApplet作るために設計された言語じゃないって事でしょ

568:nobodyさん
09/02/05 23:27:54
もっともなんだが、それ以前にずーっとスレ違(ry

569:nobodyさん
09/02/06 20:36:37
Javaって元々はHOTJava系で
売ろうとしてたんでしょ？

570:nobodyさん
09/02/06 20:55:40
Javaはもともとは組込用のC++の代替言語として開発された
そのうちにモザイクが発表されてこれは凄いって事になって
これからはWebだなってことでHotJavaもセットになって発表された

571:nobodyさん
09/02/07 08:38:14
Javaのホワイトペーパー第一版には、言語としての素晴らしさと、
中間ファイル出すから何でも動くぜーっていうのが中心として
書かれてたと思う。HotJavaはちょっと後じゃなかったっけ？

572:nobodyさん
09/02/07 09:15:33
てかJavaがweb前提ってどっから出てきた発想なんだろ

573:nobodyさん
09/02/07 10:10:14
>>572
どっかの勘違い君じゃない？

例のホワイトペーパーはそんなこと１つも書いてないよ。
ホワイトペーパーってのはリリース前に出すやつね。