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

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

1:nobodyさん
08/02/09 10:43:58
前スレ
ｽﾚﾘﾝｸ(php板)

2:nobodyさん
08/02/09 10:44:59
過去スレ
【PHP】フレームワークについて語るスレ9【総合】
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワークについて語るスレ8【総合】
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワークについて語るスレ7【総合】
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワークについて語るスレ6【総合】
ｽﾚﾘﾝｸ(php板)
[PHP]フレームワークについて語るｽﾚ5[総合]
ｽﾚﾘﾝｸ(php板)
[PHP]フレームワークについて語るｽﾚ4[総合]
ｽﾚﾘﾝｸ(php板)
[PHP]フレームワークについて語るｽﾚ３[総合]
ｽﾚﾘﾝｸ(php板)
[PHP]フレームワークについて語るｽﾚ２[総合]
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワークについて語るスレ【総合】
ｽﾚﾘﾝｸ(php板)

3:nobodyさん
08/02/09 10:45:40
【洋モノ】
symfony
URLﾘﾝｸ(www.symfony-project.com)
code igniter
URLﾘﾝｸ(codeigniter.com)
Zend Framework
URLﾘﾝｸ(framework.zend.com)
CakePHP
URLﾘﾝｸ(www.cakephp.org)

【和モノ】
ちいたん
URLﾘﾝｸ(php.cheetan.net)
Ethna
URLﾘﾝｸ(ethna.jp)
guesswork
URLﾘﾝｸ(classic.guesswork.jp)
maple
URLﾘﾝｸ(kunit.jp)

4:nobodyさん
08/02/09 12:36:07
>>1
乙です

5:nobodyさん
08/02/09 16:05:48
最近期待しているのを２つ追加

Piece Framework
URLﾘﾝｸ(piece-framework.com)

rhaco
URLﾘﾝｸ(www.rhaco.org)

でも、正直おなかいっぱいというかんじ。
3大フレームワーク(Cake, Symfony, ZF)+1(CodeIgniter)で十分という気も

6:nobodyさん
08/02/09 17:36:48
3大フレームワークのサブセット版がほしい。

ごてごてとしたフレームワークをごそっと入れるんじゃなく、
ファイル一枚か少数で完結したフレームワーク・・・

だが、命令などに互換性があり、必要になった時点で、
フルセットのフレームワークに容易に入れ替え可能。

7:nobodyさん
08/02/09 19:08:55
どこで聞くべきか迷ったんですけど、ここにします。

今SimpleTestを使ってテストしています。
SimpleTestにはWebTestCaseといってあたかもブラウザで
アクセスしたかのように、ウェブページに対してhttpプロトコルで
接続・・・その結果をテストということができるのですが、
このメール版はないでしょうか？

つまり、自分のPHPアプリからメール送信・・・そしたら（仮想の）テスト用メールサーバーにメールがたまり、
テストコードから、メールサーバーに来たメールを見てアサーションや、そのメールに書かれているリンクを
クリックなどしてテストを続行という、一連の処理にメールが入る場合のテストの自動化をしたいのです。

なにか良いライブラリ、良い手は無いでしょうか？

8:nobodyさん
08/02/09 20:29:30
あー、そういう手作業テストって面倒だよな
なんか良い手あるなら俺も知りたい

9:7
08/02/09 20:29:50
SimpleMailを見つけました。

10:7
08/02/09 23:11:53
SimpleMail URLﾘﾝｸ(www.curioussymbols.com)

ちなみに、Windowsで使うときの注意点です。

SimpleMailがSMTPサーバーとしてFakeMailを使用するので別途インストールする必要があります。
perl版は必要なライブラリが入れづらいようなのでpython版を使いました。
python版はWindows版があるのでインストーラーで簡単に入れられます。
あらかじめpython自体も入れておく必要があります。

URLﾘﾝｸ(www.lastcraft.com) ここに情報が少し書いてあります。
fakemailerを起動するときは、インストールしたフォルダで、
> fakemail.py --host=localhost --port=10025 --path=.
でいいのですが、そのままではエラーになりました。

エラーメッセージを見ると、「signal.SIGHUP」が定義されていないそうです。
どうせテストだし、あまり重要なものではなさそうなので、削除しました。

> for sig in (signal.SIGINT, signal.SIGTERM, signal.SIGHUP):
↑fakemail.pyの中の「, signal.SIGHUP」を消す。

SimpleMailにはstart()メソッドでfakemailを実行する機能があるのですが、
Linux/Unix用のパスで、perl版のコードの上、fakemail.pyをバックグラウンドで
実行しようとすると、forkなんたらのエラーが発生するのであきらめます。
start()、stop()メソッドを呼ばなくても使えます。
その代わり、テスト開始前にfakemailerを起動しておきましょう。

11:nobodyさん
08/02/10 02:22:40
PHPはモジュールたっぷり入ってるxamppに
perlはperl.exeしか入ってなくて子飼弾脂肪ｗｗｗ

12:nobodyさん
08/02/10 03:34:26
PHPってフレームワーク地獄ですよねｗ

13:nobodyさん
08/02/10 04:00:38
どういう意味？
フレームワークありすぎって意味？

14:nobodyさん
08/02/10 04:23:36
ただ、PHPは良くも悪くも言語仕様が緩いので、
デファクト・スタンダードになったフレームワークは標準で取り込んで、
言語仕様上の優遇を受けるんじゃないか、と思ってる
そうなったらこのフレームワーク地獄も終わるんじゃないの
政治的にZend Frameworkになるのかなと思ってるけど

15:nobodyさん
08/02/10 16:37:08
フレームワーク自体にはそれぞれコンセプトがあるんだから、
一つに落ち着くことはないと思うけどね。
ちょうど.comみたいに、たくさん出てきて、いろいろ淘汰されて、
最終的に数個残るみたいになるんじゃないかなぁ。
ま、資金力や人気もあるからZend Frameworkは残りそうだけど

16:nobodyさん
08/02/11 03:33:18
PHPのフレームワークは、誰でも作れるところが、
利点でもあり、欠点でもあるんだろうね。
ASP.NETのように誰も参入できないようにしてしまうと
選択肢が無い分すっきりとするが、その設計手法から
洩れてしまうと、言語など根本的な部分から変更せざるを
得なくなってしまう。

17:nobodyさん
08/02/11 20:35:51
URLﾘﾝｸ(slashdot.jp)
linuxカーネルに穴があってPHPもちろん脂肪ｗｗｗ

18:nobodyさん
08/02/12 14:36:51
その理屈だとRuby他も脂肪じゃんｗ

19:nobodyさん
08/02/12 18:06:57
Piece以外に継続を利用したWebフローエンジンを持っているPHPフレームワークってある？
JavaだとSpring Web Flowに近いと思うけど、LightweightだとほとんどがFront Controllerだから、
なかなか野心的でないかと思っている。

20:nobodyさん
08/02/12 19:41:40
>>19
WebFlowって継続なの？知らんかった。
つうか、言語で継続サポートしてないのによくやるな。

21:nobodyさん
08/02/12 19:45:13
Pieceはやってる人を応援したくなる
ただ、Piece_ORMのinsertのテーブルデフォルト値の扱いが未だに納得がいかん。
もう少し説明をしてくれればな・・・

22:nobodyさん
08/02/13 00:59:29
WebFlowに近いというか、Pieceは元々がWebFlowとJBoss Seamを参考にしてるからな。当然ある程度は似る。

23:nobodyさん
08/02/13 09:03:46
やっぱそうなんだ。
それぞれのモジュールが個別に使えるようになっているみたいだし、
そのうち既存のアプリにPiece_Flowを組み込んでみたいと思ってるんだよね。
（今はORMとRightはドキュメントがあるけど、Flowの方はちょっと…なので）

24:nobodyさん
08/02/13 11:57:39 BE:23084227-2BP(2)
今から始めるとするとどのフレームワークがおすすめかな？
少しだけcakePHPをかじってみたけど、まだ日本語のドキュメントが十分とは言い難いし。

25:nobodyさん
08/02/13 12:07:10
>>24
これから始めるなら、php4対応は気にしなくてもいいんじゃない？
俺はまだまだ業務で４を引きずるから、cakeとethnaだけど。

26:nobodyさん
08/02/13 22:38:07
>>24
CodeIgniter
間違っても Symfony はすすめない

27:nobodyさん
08/02/13 22:46:18
>>26
理由をどうぞ

28:nobodyさん
08/02/14 00:48:59
CIは確かにいいけどこれ使うならCakeの方が多少デブになるけどベターかな。
多分組み方にコダワルやつはZendを使って苦労したがるのだろう

29:nobodyさん
08/02/14 01:42:15
>>24
どう考えてもsymfony。作りこみが他の比じゃない。
そもそも全体が太るのを避けるならFWなんて使うべきじゃない。Rasmasのやつ使え。

30:nobodyさん
08/02/14 02:11:57
>>28
Zendが本命とかよく本とかには書かれてますが、どういうところが駄目なんですか？

31:nobodyさん
08/02/14 02:30:57
設計として疎結合を重視しすぎていて、
そのせいで痒い所に手が届かない部分が、
フル装備のsymfonyやcakeに比べると物足りなく思える。

ZFは言ってみれば、
軽量な骨組みに綺麗なクラスライブラリを置いてある感じ。

というのがZFについて人から聞いた話。

32:nobodyさん
08/02/14 02:35:13
symfonyやcakeで届く痒いところってどんなところ？

33:nobodyさん
08/02/14 10:57:40
bakeで焼いてる(笑)ヤツらは、便利と思ってるのかな。

34:nobodyさん
08/02/14 11:16:32
bakeで焼いたら焦げました('A`)

35:nobodyさん
08/02/14 16:32:38
>>34
baka

36:nobodyさん
08/02/14 20:03:37
mb_send_mailまわりってダメダメだな・・・
mb_encode_mimeheaderはmb_internal_encodingが必要って見たけど
PHP4の稼働してるバージョンじゃそれでもだめだったし
自分でヘッダ組み立ててmailで送るしかないじゃん・・・('A`)

37:nobodyさん
08/02/14 22:00:33
mb_send_mail()で使えているけど。
ただ、引数指定にはいろいろノウハウがあったような…
単純にテキストメール送るだけなら、楽なことは楽。

38:nobodyさん
08/02/14 22:01:07
つーか、ここはフレームワークスレじゃん。
フレームワークにメールモジュールないの？

39:nobodyさん
08/02/14 22:52:13
あるけどしょっちゅう化ける
特に洋モノは。
南蛮人に極東のマイナー言語のサポートなんか期待できないのは
当然っちゃ当然だが

40:nobodyさん
08/02/15 00:58:46
まあいい加減ISO-2022-JP（だったっけ？）に変換して送る様なローカル慣習も無くなってくれてもいいんだが。
UTF-8通らないサーバとかメールクライアントとかはもう無視する方向で行きたいな。
（どのみちそっちの方向にしか進まないんだから）

41:nobodyさん
08/02/15 02:02:23
70文字で区切るとかいう仕様も今の時代意味あんの？
そのせいでmb_encode_mimeheaderも腐ってるし
いつの時代の仕様なんだっての

42:nobodyさん
08/02/15 03:18:39
ってか実際的に考えて、70文字区切りなんていらないんじゃないか？
mail関数のサブジェクトの説明には「改行を含んではいけません。」って書いてるし、
実際サブジェクトを適当な文字数で区切ってbase64エンコードした場合と
まったく区切らずにbase64エンコードした場合の結果が
gmail,shuriken,docomo(foma)で同じだったし
恐らく今のクライアントだったらほとんど問題ないだろう。
mb_encode_mimeheader的な区切り処理は
むしろ何かと害があるんじゃないか。

43:nobodyさん
08/02/15 03:25:30
そういう風に考えていくと
mb_send_mailの存在意義が分からないな。
出来ないことを出来ると見せかけるという意味で
むしろ悪影響の方が大きい
前もってmb_internal_encodingを設定しろとか
バッドノウハウが広まってること自体がおかしいだろ
常識で考えて

44:nobodyさん
08/02/15 11:46:50
MIMEの仕様に文句があるならRFCを修正してくれ。

45:nobodyさん
08/02/15 21:41:50
mb_send_mail関数があるおかげで、PHPerにメール(というかMIME)関連の知識が付かない、という弊害もある。
・・・仕様が半端だしあちこちで不具合が出るから結果的にはある程度知らなきゃいけないんだがｗ

本当に半端な関数で、こんなもの実装するくらいならPEARででもまともなMailクラスを育てればいいのに。

46:nobodyさん
08/02/15 22:11:53
俺もmb_send_mailの存在意義がわからん。
mail関数じゃダメなのか？というか何が問題でmb_send_mailが出来たんだ？

調べろと？そうですなｗ

とりあえず、subjectはISO-2022-JPにしたあとbase64エンコードしている。
本文はISO-2022-JPにしている。

これでmail関数使っているが、なにか罠があるのか？

47:nobodyさん
08/02/15 22:18:51
>>38
> つーか、ここはフレームワークスレじゃん。
> フレームワークにメールモジュールないの？

じゃあ、フレームワークに絡める。
CakePHP 1.2にはメールモジュールEmailComponentがあるのだが、
このモジュール。mb_send_mailではなく、mail関数を使っている。
当然日本語とか考慮されていない。

charsetというプロパティはあるにはあるのだが、これだけじゃうまくいかない。
なので、EmailComponentを継承して__encode、__renderTemplateメソッドを
オーバーライドしてエンコードおよび、半角カナなどを変換しているよ。

48:nobodyさん
08/02/15 22:22:04
確かにメール関連知識付くの遅かったな
mb_send_mailの挙動が変だから
ずっとメールに対して奇々怪々なイメージがあった
やってみればたいして難しくないんだが。
mailを直接触る方が健康的だな

49:nobodyさん
08/02/16 20:07:48
PHPのCLIって起動やたら遅くね？
CLIが速いスクリプト言語って何？

50:nobodyさん
08/02/17 00:10:17
bash

51:nobodyさん
08/02/17 11:55:49
まあ、PHPはウェブ専用だよ。

52:nobodyさん
08/02/17 19:25:33
>>49
マジレスすると Perl
Ruby は普通
Python はかなり遅い
起動の早さはバイナリサイズによるところも大きくて、awkやluaのようにバイナリが小さいものだとPerlよりも起動が早い。

53:nobodyさん
08/02/18 20:19:24
じゃあPerlにしようと思って
Perlの本買ってきた
Perlは糞記号が多いな
$にいろんな意味持たせすぎ。
こういうタイピング時点での節約がなんか前時代的
CLIのスクリプトってフレームワークの階層のどこに置けばいいんだろ？

54:nobodyさん
08/02/18 20:41:46 7b3e8wHY
CLIなら別にPHPとかPerlとかRubyとかPythonとかに限らなくてもいいんじゃね？
もうおそいか

55:nobodyさん
08/02/19 01:36:48
>52も罪深いが、>53は単純すぎる。　

56:nobodyさん
08/02/19 02:08:39
>>46

調べろ

57:nobodyさん
08/02/19 05:15:52
実際PHPもPythonもCLI重いじゃん
shなんて単純なものしか書きたくないし
そうなるとPerlは充分妥当な線だろ。
スクリプト言語の中ではPHPに一番近いし。

58:nobodyさん
08/02/19 05:27:17
まあPHPの既存のクラスを使うようなもので
速度がいらない処理（scaffolding等）はPHPで全然問題ないけどね

59:nobodyさん
08/02/19 07:47:46
URLﾘﾝｸ(www.timestretch.com)

ここの結果だとPythonの方が速いけど。
まあ、当たり前だけど目的による。
なんで盲目的にPerlが速いといえるのかがわからん。

60:nobodyさん
08/02/19 12:02:30
Perlでも例えば
use Encode;
use CGI;
use Data::Dumper;

とかやると結構違うんじゃね？
結局CLIの起動速度とか、言語の選択にそれほど影響する場面ってあるか？
まあRubyは結構がつんと引っかかるのを感じることはあるけど

61:nobodyさん
08/02/20 03:45:15
チープなWebアプリケーションを作る場合には、PHPは他を圧倒するな。
extで話が済んでるうちは、荒っぽくいえばCのWebフレームワークなわけだし。

rubyとか今やRailsないとWebアプリ作れねーんじゃねーかと。

62:nobodyさん
08/02/20 08:15:36
ruby作った松本も神だけど
rails作った奴も神だな
神と神が合体して偉大なるソフト

63:nobodyさん
08/02/20 08:57:52
多神教なんですね

64:nobodyさん
08/02/20 11:16:03
ワラタｗ

65:nobodyさん
08/02/20 16:36:10
>>62
神と神を合体させると何が出来るのですか？
URLﾘﾝｸ(members.jcom.home.ne.jp)

66:24
08/02/20 18:10:02
うーん、どれも似たり寄ったりなのかな？
じゃあ、質問を変えてajax（というより、DHMLメイン？）前提ではどれが作りやすいかな？
たとえば、xhrを用いた非同期通信をサポートする上での仕様が覚えやすいとか、
prototype.js系に限らずほかのJSライブラリ（dojo系やYahooUI系）でも利用可能な仕様が公式側で用意されているとか。

67:nobodyさん
08/02/20 21:07:41
あ、それ俺も知りたい。
別途jQuery叩いてて不満ないのでフレームワーク側のAJAXサポートとか評価したことない。もちろん手間はある
識者のお勧め希望

68:nobodyさん
08/02/21 00:14:33
外国の技術系サイト見たら
システム周りのちょっとした作業するのに使われてるのRubyばっかだな
逆にPythonはあんまり見ない
Ruby知らないとイモって言われる時代もすぐそこか・・・(´・ω・`)

69:nobodyさん
08/02/21 00:38:11
>>66
なんか前スレのJaxerを彷彿とさせる流れだ

サーバサイドとフロントエンドをそれほど上手に連携させていて、しかも汎用的な
フレームワークとかまだそんなに無い雰囲気だけど、あるなら俺も知りたい

強いて言うなら、RubyはJavaScriptと近い記述も可能な印象があるので、スクリプトを
組む人間の脳みそ的に楽かも知れない。
オブジェクトやブロックの扱いとか、記述の柔らかさというかその辺で、少なくとも、PHP
よりは感覚が近いような

なんだこの印象論はと書いてて自分で思った。

70:nobodyさん
08/02/21 00:56:06
記述で言えば{}や;やら表面上はPHPの方が似てるんじゃね？w
まあ確かになんでもかんでもオブジェクトでござい、てあたりは似てるね

71:nobodyさん
08/02/21 01:12:47
ruby on railsは神と神のフュージョン
いいかえればキリストとアッラーが融合合体した「究極生命体」

72:nobodyさん
08/02/21 01:17:10
キリストは神じゃないよ(´・ω・`)

73:nobodyさん
08/02/21 01:18:32
神と神が合体するとフレームワークが出来上がるが
バカとバカが合体すると子供が生まれる

74:nobodyさん
08/02/21 01:21:07
>>68
Rubyはもう古い
時代はScala

75:nobodyさん
08/02/21 01:23:24
>>74
Scalaをググってみましたが
SCALA:(スカラ)は岡山市のヘアーサロンらしいです

76:nobodyさん
08/02/21 02:54:43
>68
GNOME周りの細かいスクリプトってPythonばっかでしょ？
海外でRuby使っている人ってRoRの流れの人じゃないかな
正直なところ、RoRは偉大だと思うけどRubyはそうは思わない
「RoRのプログラマに選ばれた言語」として評価はするけど

77:nobodyさん
08/02/21 12:49:51
BlenderのPython
Google SketchUpのRuby

PHPをスクリプト言語として搭載した色物3DCGソフトがあったら色んな意味で面白そうだ

78:nobodyさん
08/02/21 13:39:33
将来的にRubyが来るかPhthonが来るかPerlがしぶとく生き残るか。
ずぅっと混戦状態な気もするけど。

案外Webだけに的を絞ったPHPが一番長生きだったりしてね。
でも10年後、PHPの役目が今のCOBOL的な負の遺産管理とか、そういう生き残りかたはやだな。

79:nobodyさん
08/02/21 14:20:40
結局phpもjavascriptやperlみたいに上級者と初心者が乖離して
その間を埋める新しい言語が出てくるんじゃないの
一方extract($_POST);的なコードはいつまでも再生産されるっていう

80:nobodyさん
08/02/21 16:47:46
PHPからPython使えてRuby脂肪ｗｗｗ
URLﾘﾝｸ(pecl.php.net)

81:nobodyさん
08/02/21 18:22:05
マッツがむかつくから今までRubyしなかったけど
外人が大量にやってるからRuby始めました
YAMLが簡単に扱えてｲｲ(･∀･)！

82:nobodyさん
08/02/21 18:47:15
>>81
これよりも簡単に扱えるん？
URLﾘﾝｸ(itpro.nikkeibp.co.jp)

PHP版がこのコード↑として、Ruby版はどういうコードなん？

83:nobodyさん
08/02/21 19:00:50
require 'yaml'
file_dir = './hoge.conf'
str = open(file_dir).read()
data = YAML.load(str)

こんなん
もっとキレイに書けるのか知らないけど。
コード自体はたいして変わらないか。
でも変なパースされてハマったことあるからspycにはいい印象ないな

84:nobodyさん
08/02/21 19:09:48
ってか、やっぱり標準で装備されてる安心感が大きい

85:nobodyさん
08/02/21 19:19:43
じゃあ、YAMLが簡単に扱えるじゃなくて、

YAMLライブラリが標準添付されているって言うべきだな。

86:nobodyさん
08/02/21 19:23:34
ある文に後から関数的な処理を加えたい時、PHPだと
[追加部分前半](元の文)[追加部分後半]
って分かれるのが普通だけど
Rubyだと
（元の文）[追加部分]
で済むのが気持ちええ～
多重に追加する時も
（元の文）[追加][追加][追加]
って書いていけるのがオルガスムス(´ρ｀)

87:nobodyさん
08/02/21 19:40:27
ここRubyスレじゃないんだ。わかってる？ｗ

88:nobodyさん
08/02/21 19:43:13
関数塗れな処理で、カッコでgdるかドットシンタクスで繋げられるかって事か
地味だがjQueryハマってるので気持ちは判る

しかしスレ違いではないか

89:nobodyさん
08/02/21 20:06:49
すぐスクリプト言語についてぬるく語るスレになるなここはｗ
よっぽどPHPのフレームワークにネタがないのか

90:nobodyさん
08/02/21 21:58:56
他言語も含めてフレームワークでネタが続いているの
どこにあるんだよｗ

91:nobodyさん
08/02/22 09:46:47
>>59
>URLﾘﾝｸ(www.timestretch.com)
>
>ここの結果だとPythonの方が速いけど。
>まあ、当たり前だけど目的による。
>なんで盲目的にPerlが速いといえるのかがわからん。

>>49と>>52よく読め。起動時間の話をしてるのに違うベンチマーク結果だしてどうする。

>>82
SpycはまともにYAML扱えないから止めた方がいい。いくらなんでも機能低すぎ。バグ大杉。しかもクソ遅い。

92:nobodyさん
08/02/22 12:35:59
PHPもYAMLパーサ標準装備されるんじゃなかったっけ？

93:nobodyさん
08/02/22 12:47:30
まじで？早くしてほしいね

94:nobodyさん
08/02/22 15:13:53
Symfonyでふんだんに使われているSpycが
そんなに悪いとは思えないが？

95:nobodyさん
08/02/22 15:16:53
Pieceでも前提にしてるね Spyc

96:nobodyさん
08/02/22 15:19:12
いままで parse_ini_file も有効利用出来なかったPHPerがYAMLってだけで何でそんなに騒ぐのか

97:nobodyさん
08/02/22 15:25:54
spycは単純な設定ファイルを読む程度なら充分だけど、
ヘビーに使おうと思うとあきらかに役者不足だよ。

98:nobodyさん
08/02/22 15:37:27
取り立てて良いわけでもないが、まともにyaml扱えないなんて印象はないけどな
だいたいyamlなんて設定ファイルで使うケースがほとんだと思うが
遅いって言っても実環境で使うなら普通キャッシュするし
機能低いとかヘビーに使うとか一体どういう局面で困ってるの？

99:nobodyさん
08/02/22 16:34:52
YAMLってヘビーに使うものなのか？
通常は設定ファイル程度に使わないか？
そういうのは一度キャッシュしてしまうだろうし。

（ってろく読まずに書いたら>>98も同じこといってるじゃんｗ）

100:nobodyさん
08/02/22 17:13:10
YAMLのパース処理なんて単純だし固定的だからエクステンションにするのがベストだろうな
symfonyってsyckとかいうの使うようになったんじゃなかったけ？

101:nobodyさん
08/02/22 17:18:54
>91
いや、起動が遅くてもインクルードで遅れたら意味ないでしょ？
だから、「目的による」と書いてあるの。それ以上は自明だと思ったから説明しなかっただけで。
それについては、Perlでもインクルードするモジュールによると他の人も書いてるでしょ。
この人は意図をよく理解してる。あなたはもう少しよく考えましょう。

102:nobodyさん
08/02/22 17:31:08
web+db press　ちょうどyamlについての特集してるな
web+db pressの個人的タイムリー感は異常

103:nobodyさん
08/02/22 17:33:55
「起動が遅くてもインクルードで遅れたら」ってどゆこと？
「起動が速くてもインクルードで遅れたら」のtypo?

104:nobodyさん
08/02/22 18:29:49
>>101
>いや、起動が遅くてもインクルードで遅れたら意味ないでしょ？
>だから、「目的による」と書いてあるの。それ以上は自明だと思ったから説明しなかっただけで。

起動の速さを話題にしているんだから、それ以外の要素を持ち出すならそれを説明すべきだろ。
>>49,52,59を順に読んでみろ。どこにインクルードやrequireの話がでている?
「目的による」のひとことで分かるわけがない。おまえの脳内で勝手に補完するな。

>それについては、Perlでもインクルードするモジュールによると他の人も書いてるでしょ。
それは>>60からだろ。60はちゃんと説明しているが、59まではそんな話でてきてない。時系列を無視して語るな。

>この人は意図をよく理解してる。あなたはもう少しよく考えましょう。
おまえこそもう少しよく読め。

105:nobodyさん
08/02/23 21:58:54
web+db press読んだ
YAMLって結構高機能なんだな～

106:nobodyさん
08/02/24 09:22:41
ワロタｗ高機能の内容も言わず、高機能とか言っても信用されないｗ

107:nobodyさん
08/02/24 11:54:48
信用って何だよ
仕様を見ればわかるがな

108:nobodyさん
08/02/24 19:48:11
最も使われているYAMLパーサのSyckはRuby出身
Rubyの手のひらの上で暴れてるだけのPHP乙

109:nobodyさん
08/02/24 20:10:52
最も使われてるの？
PHPのプロダクションてほかの言語からの輸入物多いからいまさらそんなん言われても

110:nobodyさん
08/02/24 23:46:30
PHP＝ポリシーのないパクリパッチワーク言語でおk？

111:nobodyさん
08/02/25 00:58:06
>>110
そう書くと、それはそれでとても魅力的な言語に見えます。

112:nobodyさん
08/02/25 03:41:00
PHPにいいとこどりされて他の言語脂肪ｗ

113:nobodyさん
08/02/25 10:52:39
最近、Ruby本多くなったけど誰がRuby使ってんの？　

114:nobodyさん
08/02/25 14:43:04
異教徒

115:nobodyさん
08/02/26 00:07:04 /Sycx4p+
言語崇拝者でしょ。

116:nobodyさん
08/02/26 00:42:37
なぜ島根県が出て来ないのだ

117:nobodyさん
08/02/26 02:09:18
おまいらＰＨＰ，ｐＨＰていうどやなあ
今までＰＨＰでいくら稼いだんや？

118:nobodyさん
08/02/26 02:10:31
松本は島根県民としては誇りだ
しかしネゴシックスは県民の恥さらし

119:nobodyさん
08/02/26 02:13:42
世界に通用する言語開発した唯一の日本人が
島根県民だから同県民として素直にうれしいし
松本も地元に愛着を持ってるらしく
Ｒｕｂｙ検定やら松江を発信基地として活動してくれる

120:nobodyさん
08/02/26 02:15:05
島根県民は案外、人口の割りに頭のいい奴は多いぞ

121:nobodyさん
08/02/26 02:39:30
頭は良いが、常識はないってパターンか
いい加減書き込むときはスレタイぐらい読めよ

122:nobodyさん
08/02/26 08:59:32
Rails使いたくてこの1ヶ月Ruby勉強してた
確かに書きやすいしPHPに比べるときれい
でも肝心のRails環境があまり無い
実用面ではPHPがNo.1だと思います

それで質問ですが、最もRailライクなフレームワークはSymfonyでよろしいでしょうか？
この1ヶ月の勉強の知識でそのままPHPフレームワークに移行したいのです

123:nobodyさん
08/02/26 16:01:26
>>122
>それで質問ですが、最もRailライクなフレームワークはSymfonyでよろしいでしょうか？

YES

>この1ヶ月の勉強の知識でそのままPHPフレームワークに移行したいのです

その判断は誤りだといっておこう。
PHPはRubyと比べてできないことが多いから、PHPでRailsを真似てもたいしてうまくいかない。

124:nobodyさん
08/02/26 20:24:36
>>123
具体的に何が出来ないんですか？

125:nobodyさん
08/02/26 20:29:50
>>124
簡潔な記述、とかかなぁ

126:nobodyさん
08/02/26 20:38:57
(　´д`;)…

127:nobodyさん
08/02/26 21:49:40
>>122
akelos

128:nobodyさん
08/02/26 22:30:12
>>122
Railsに最も近いのは、現状でいえばakelos
でも、Railsがベストなわけじゃないってのは認識したほうが。
symfonyはRailsよりリッチ。いい意味でも悪い意味でも。

129:nobodyさん
08/02/26 22:47:06
そりゃどちらがrailsクローンかと言われると
akelosだけど現実的に考えるとsymfonyだろう
リッチってなんだよリッチって曖昧過ぎるだろ

130:nobodyさん
08/02/26 23:46:19
リッチかどうかは良くわからないけど、
symfonyの方がエンタープライズ向けな感じはする。

131:nobodyさん
08/02/26 23:56:03
>>124
簡潔な記述もそうだけど、PHPはメタプログラミングが弱いんだよ。
Rubyはそこが強力で、だからこそActiveRecordみたいなのが実現できる。
ActiveRecordがほんとに望ましいものかどうかは別として。

132:nobodyさん
08/02/27 00:00:57
PHPユーザーはPHPだけで何もかもこなそうとする傾向にある。

133:nobodyさん
08/02/27 00:03:44
今は亡き？Plaggerよりは、何でも出来るけどなｗ

134:nobodyさん
08/02/27 01:13:23
>>131
PHPの言語仕様がRubyよりも少ないのはわかるけどさ、
それで開発をする上で何ができないということなの？

135:nobodyさん
08/02/27 09:17:34
>>133
Plaggerをここで出す意味がわからない。
スペルの似た別の何か？

136:nobodyさん
08/02/27 09:27:49
>>129
akelosも十二分に実用だと思うよ。

ｽﾚﾘﾝｸ(php板)
URLﾘﾝｸ(www.akelos.org)
URLﾘﾝｸ(www.akelos.org)
URLﾘﾝｸ(blogs.atanaka.biz)
URLﾘﾝｸ(blog.takeda-soft.jp)
URLﾘﾝｸ(blog.hakuja.jp)
URLﾘﾝｸ(d.hatena.ne.jp)

137:nobodyさん
08/02/27 21:44:16
Railsでこのまま行くか、PHPのフレームワークを覚えるか迷うな・・

akelosは>>136の上から5番目のブログ見て良さげと思った

138:nobodyさん
08/02/28 13:46:19
俺のフレームワークの使い方

・RDB使わずテキストの場合
ちいたん（ちょっと改造）

・PHP4でRDB使う
ちいたん（ちょっと改造） + PieceORM

・PHP5でRDB使う
symfony

こんな感じ

139:nobodyさん
08/02/28 13:51:16
php4かphp5かとか言ってるさなか今時３かよ。
キツい・・。perlにするかな。

140:nobodyさん
08/02/28 17:43:37
PHP3とかいっている環境しか使えない状態なら
その環境のPerlも当然バージョンが古く、
そのバージョンのPerlに対応しているフレームワークも無い。

141:nobodyさん
08/02/28 19:01:25
>>134
Railsはどうか知らんが、RakeはPHPじゃ無理だと思った。

142:nobodyさん
08/02/28 19:18:01
>>141
pakeがあるし、普通に雑務タスク書く分にはpakeでもわりと使えるよ
まあrakeみたいにDSLっぽく書けない、という意味で書いてるんだろうけども

143:nobodyさん
08/02/28 19:27:24
言語仕様が劣っていても、それをライブラリ・フレームワークとして
提供すれば、ほぼ同等のことが出来る。

違った形での実装、使い方になるだろうが、どちらを使っても
普段の仕事で使う分には大差がない。

大差があれば、われわれは○言語を使うから、
大幅に工数が減って、結果、”安く”作れます。といえるはずだろう？

安く作るって事は給料が減るわけだが、本当に工数が減るのなら問題ないはずだ。
実際は工数が減らないから「優れた言語を使うから安く作れる」なんて話を聞いたことが無い。

144:nobodyさん
08/02/28 20:48:04
>>143
どちらを使っても大差がないんだと思うなら
優れた言語使えばいいんじゃないのと思うがｗ

相手も同種のベンダーとかじゃない限り、
顧客にとっちゃどんな言語使ってようがあまり関係がない
「われわれは○言語を使うから云々」とか意味不明

安いのどうのっていうのは見積判断次第なわけで
工数とコストが比例するのが前提っておかしいだろう

145:nobodyさん
08/02/28 20:53:41
「優れた言語」の定義も曖昧なまま、意味の無い話をしている人たちが気持ち悪い。

146:nobodyさん
08/02/28 20:54:47
>>144
＞工数とコストが比例するのが前提っておかしいだろう

上記の「コスト」は見積もり、のこと？

この業界の最大のコストは人件費なんだから、コストは素直に比例でいいんじゃね？
まあ商用パッケージ等を使うこととかは別問題だけど、それでも「工数」を比較的上手に
コストと交換しているみたいなもんだし。

まあ、見積もりは別だ。・・・でもあんまり無茶なダンp(ry

147:144
08/02/28 21:09:31
>>146
コストじゃねー見積orz
工数とコスト（経費）が比例しなかったらまずいｗ
俺が意味不明だった

内部的な工数の変化と外部への見積とはまた別だろう的な
意味で書いたつもりだったけど変な文章になってた

148:nobodyさん
08/02/28 22:37:10
プログラマの言うすぐれた言語を使っても、
フレームワークを使うと、工数も作りやすさも変わらない罠。

なぜかというと、フレームワークを使うとビジネスロジックに専念できる。
そのビジネスロジックでは高度な言語機能なんて使わないから

149:nobodyさん
08/02/28 23:57:02
もともと SIerが作るシステムなんて仕様が汚いんだから、きれいに書ける仕組みがあっても意味がない。

それどころか、コピペで作られたシステムじゃないと、修正した場合の影響範囲が大きくなるから嫌がられる。
変更箇所が多くても土方仕事の方が良いというプロマネは多いはず。

土方仕事なんだから、職人技が使えないのは当然。

150:nobodyさん
08/02/29 02:19:49
Perl5.6は2000年リリースだけど、使えないCPANモジュールなんて数えるほどだと思うよ。
それどころかPerl5以降なら、たいていそのまま動くよ。15年前のリリースだけど。

151:nobodyさん
08/02/29 10:50:18
バージョンあがってないんだから当然だろ

152:nobodyさん
08/02/29 12:09:50
Railsがいずれ主流になるのは確信してるが
まだまだ時期が早い。
symfonyだよな、
春くらいに大手サイトでのsymfony採用実績がどんどん発表されるのを
知ってる人は少ないだろうな

153:nobodyさん
08/02/29 12:11:59
大規模で使えるフレームワークで考えれば
長い期間でsymfony独占だろうな
規模でかいフレームワークが乱立することは、マズ無い
会社を上げてその競争に入るのに多大なコストがかかる

154:nobodyさん
08/02/29 13:21:45
>>153
>大規模で使えるフレームワーク
これってなにをもってそういってるの？
大規模って何が大規模？大規模向けにsymfonyがもっていて他がもっていない特徴って何？

155:nobodyさん
08/02/29 15:41:39
あちこちでsymfonyほめ殺しやってるのはsymfonyアンチなんだろうなあ
なにかアンチをひきつける要素があったのか

156:nobodyさん
08/02/29 18:20:40
>>154
ここでいう大規模てのは人それぞれだからね
あえて俺が境界定義する必要はない
大規模に向けにある機能といったら
Viewからコンポーネント、モデルに手軽にアクセスできる柔軟性

157:nobodyさん
08/02/29 18:24:46
スケールしやすいとかそういう事言うのかと思ったら
えらく特化された大規模向け機能だな
よっぽど小回り利かないFWを使ってるのか

158:nobodyさん
08/02/29 18:26:58
多分 >>154 が言いたかったのは、「規模」は利用者数なのか、プログラムの大きさなのかって事じゃないかと思うんだが。

159:nobodyさん
08/02/29 19:55:13
>>158
あとは開発者数ってのもある

>>156
>Viewからコンポーネント、モデルに手軽にアクセスできる柔軟性
これもうちょっと詳しく説明できる？どんな機能で、どう大規模な開発で便利なのか。

160:nobodyさん
08/02/29 20:10:06
>>156
＞Viewからコンポーネント、モデルに手軽にアクセスできる柔軟性

具体的に想像出来ないが、Viewからとりあえず Hoge::new とか Hoge::factory とか Hoge::singleton とか
Hoge::getInstance とかであらゆるオブジェクトを気軽に作成できて、またそうするのが前提で、みたいな？

すっごくネガティブな方向でしか想像できない。
なんか、上の方とか他に影響のありそうな所とかをいじらなくて済むから、お伺いを
立てずにとりあえず現場でなんでも出来る、うーん効率的、などなど

直行性を高く保って実現する、ていうことなのかな？DRYはある程度犠牲にして、ていう？
なんかふわふわｽﾏｿｗ

161:nobodyさん
08/02/29 20:57:56
ビューごときが直にモデルにアクセスしたいなんて思い上がりすぎわろた
コントローラー様を介せよｶｽ

162:nobodyさん
08/02/29 21:05:30
コントローラを経由すると何が良いの？

163:nobodyさん
08/02/29 21:12:31
>>156
少し考えたが、Ethnaみたいになるのか？
どのオブジェクトもあらゆるオブジェクトを持ってるみたいな
Ethnaはもう循環参照で開き直ってるけどｗ

$this->af->ae->af->ae みたいな（← これはなかったかもｗ）
もしくは$this->backend->(永遠に続くオブジェクトループ)　みたいな
っていうか、backendの範囲広すぎｗ

そこまでするんなら、もうオブジェクトそれぞれ$GLOBALSに置いておいて
変更は禁止で（変更するならcloneでもして）勝手にアクセスすればいいん
じゃね？とかいう気がすごくする。

164:nobodyさん
08/02/29 21:34:21
>>151
は？5.8、5.10とリリースされてるんだけど。PHPみたいに0.1のバージョンアップでもう動かなくなる方がどうかしてる。
PHPの場合、間違いなくPHP4系、PHP5系、PHP6系が平行して使われていくだろう。

165:nobodyさん
08/02/29 22:14:57
4は使われねーだろ

166:nobodyさん
08/02/29 23:02:18
symfonyはVからコンポーネントにアクセスする場合
CとVがワンセットでコンポーネントされてる場合
コンポーネントで定義されてるV切り離してCだけ呼ぶことも出来るし
CとＶをワンセットで呼ぶことも出来る
この辺り便利

167:nobodyさん
08/03/01 00:01:06
>>166
その説明じゃわからん。特に1行目と2行目。
コンポーネントされてる場合ってなんのことだ
CとVをワンセットで呼び出すってどういうことよ

168:nobodyさん
08/03/01 00:45:22
適当につけているバージョン番号の数値に
意味を考えるなんて馬鹿だよな。

169:nobodyさん
08/03/01 14:08:24
===がRubyでは範囲比較演算子として使われててPHP脂肪ｗｗｗ

170:nobodyさん
08/03/01 23:54:17
小中規模フレームワーク　Akelos
大規模フレームワーク symfony
CakePHPは作者がバカそう

171:nobodyさん
08/03/02 01:01:22
一番はやっているものに、嫉妬して
悪口を言う気持ちは、わかります。

172:nobodyさん
08/03/03 17:23:19
URLﾘﾝｸ(slashdot.jp)
日本PostgreSQLユーザー会のWebページがクラックされてPHP脂肪ｗｗｗ

173:nobodyさん
08/03/03 18:05:14
スレ違い

174:nobodyさん
08/03/04 00:15:16
PHP5.3は正式にはいつリリースされるの？
名前空間が入ることはもう確定っぽいけど、そういうのを使ったフレームワークとかはいつ頃出てくるんだろうか
普及すれば、フレームワークの書き方が思いっきり変わりそうな機能だけど、まだしばらくはお手本とかなさそう？

175:nobodyさん
08/03/04 02:04:28
あんまりかわんないと思うけど。

176:nobodyさん
08/03/04 03:18:14
PEARみたいな外部ライブラリは充実するかも。やっとスタートラインに立つってだけだけど。

177:nobodyさん
08/03/04 14:37:23
独自拡張を、下の方の継承ではなく、上の方の差し替えで出来る可能性はあるかも？
// import Zend::DB as DB
import MyFramework::DB as DB;
$table = new DB::Table();
として差し替える、とか。配布スクリプトがカオスになる可能性もあるな

178:nobodyさん
08/03/04 18:08:54
名前空間とかgotoとかどうでもいいしね…
個人的にはicuがどうなるかだな
まぁ時代はqiqってことで

179:nobodyさん
08/03/04 20:48:12
qiqはもちろんすげーけど
gotoと名前空間を同列に語るなよ
程度が知れるぞ

180:nobodyさん
08/03/04 21:32:54
qiq見てみたけどすげーじゃん。phpに不足していると指摘されている機能がもう実現できてんじゃん。始めて知った。

181:nobodyさん
08/03/04 21:45:54
？？？
無名関数・クロージャ・配列の構文糖衣が主な拡張？
そんなに欲しかったのか？

182:nobodyさん
08/03/04 21:49:23
じゃ他に何が必要なん？

183:nobodyさん
08/03/04 22:06:37
namespace

184:nobodyさん
08/03/04 22:07:34
列挙型とかクラスの動的な再定義とかモジュールのmixinとか

・・・って別にいらないと言えばいらないし、むしろ必要なのは標準ライブラリかな
いい加減、メール送信とかDBアクセスとかに外部のライブラリをいちいち吟味って
結構めんどい。さっさと標準で十分にするんだ。

Zend Framework付属のライブラリ群がそうなる予定なのかも知れないけど、そうすると
PEAR2の立ち位置が微妙になるし。
PEAR2にZend Frameworkからのバックポートがあるんなら、それが良いのかも知れない

185:nobodyさん
08/03/04 22:52:02
名前空間やパッケージを今更導入しても、PEAR、Zend、各種フレームワーク付属のライブラリの整合性を取るのは至難だろうな。PHP4.0程度で導入すべきだった。

186:nobodyさん
08/03/04 23:05:45
いや、やっとPHP4が死んでくれたので、これからPHP5（の記述）に移行する腰の重ーい
人たちや企業がまた慣れて旧態依然としたコードを乱発してしまう前にがんがん新機軸を
入れてしまえっていう、最後の機会かも知れない

187:nobodyさん
08/03/05 02:03:59
PHP4で動いているサイトは星の数ほどある。今動いてるサイトは、今後PHP4で動き続ける。機能追加もされていく。互換性のないPHPだから仕方ない。

188:nobodyさん
08/03/05 02:11:31
トリッキーなことしてなかったら4のサイトも5で普通に走るだろ…常考

189:nobodyさん
08/03/05 03:29:57
いやあ屑コード依存が多岐に渡ると作り直すぞ
俺が体験した範囲だと、4→5よりも古い4とlatestの4の間でコケて
5+ZFで作り直しってのがこの所多発

190:nobodyさん
08/03/05 04:22:14
多発ってどんだけ。

191:nobodyさん
08/03/05 07:13:06
クラスで3人くらい持ってたら「みんな持ってる」と言ってしまう
子供と同じ心理

192:nobodyさん
08/03/05 11:55:03
まぁ XPからVista並には移行するんじゃなかろうか。

193:nobodyさん
08/03/05 15:30:39
>>190
先月七回きたよ

194:nobodyさん
08/03/05 19:36:02
そんなあるのか

195:nobodyさん
08/03/05 20:10:34
あ、同じクラからだけどね
別案件でばらばら投げられて苛々したけど、ZFでやれたので最終的にDB一本化はけっこう綺麗にいった

運用ベースで見たら古い環境って相当な数居るように感じるのよね
問題でない限り使い続ける（というかリプレースする理由がない）もんだし

196:nobodyさん
08/03/05 23:07:01
そりゃ問題ない物までリプレースする必要はないが、
古い４って脆弱性問題にならなかったのか

197:nobodyさん
08/03/05 23:16:55
最新版のPHPは機能が多くなった分、もっとセキュリティに問題あるから。枯れてるPHP4の方がよほど安全。

198:nobodyさん
08/03/05 23:20:10
新しい４、なら気持ち同意

199:nobodyさん
08/03/07 02:17:48
PHP本体のセキュリティをちゃんとソースコード読んだ上で語ってる奴ってどんだけいるんだろうね。

200:nobodyさん
08/03/07 04:59:46
>>199
suhosin乙

201:nobodyさん
08/03/07 09:49:44
Windows本体のセキュリティをちゃんとソースコード読んだ上で語ってる奴ってどんだけいるんだろうね。

Windowsのセキュリティを語っているやつ死亡ｗｗｗ

202:nobodyさん
08/03/07 10:01:43
>>201
オープンソースのWEBフレームワーク言語と、ソースの秘匿されている商用OSを同列に並べるのは
ちょっと無理があるんじゃね？
せめてLinuxにしとけよ

203:nobodyさん
08/03/08 02:20:42
>>197
ですよね。
WindowsもVistaなんかより枯れてるNTですよね。

204:nobodyさん
08/03/09 02:17:33
Ruby書き慣れたらPHPの行末の;を書き忘れるなぁ
従ってPHP脂肪ｗｗｗ

205:nobodyさん
08/03/12 03:50:21
>>86
URLﾘﾝｸ(jp2.php.net) ?

206:nobodyさん
08/03/13 02:05:36
>>204
俺も、VBやっていたら、C言語の行末の;忘れたよ。
なんか似てるね。

207:nobodyさん
08/03/13 03:53:53
rubyって
if (式) {hoge()}
みたいな書き方出来ないのな
ブロック付きメソッドでは{}を使うのにifで{}使えないって何なの？

208:nobodyさん
08/03/13 04:08:48
>>207
その {} を then end に変えるだけなんだがな
何なのって言われると、文法としか言いようが無さそう
PHPって hoge() if (式) って出来ないのな、ってなもんだ

MLで聞けばひょっとするとMatzが答えてくれるかも知れないよ
ってか、スレ違い

209:nobodyさん
08/03/13 04:17:52
何で一貫性がないの？Matzは美意識が欠けてるの？

210:nobodyさん
08/03/13 07:21:58
URLﾘﾝｸ(blog.pasonatech.co.jp)
Matz & Dan : コンピュータサイエンスとしての知識が高まると
PHPに対して不満がでてくるかもよというのは予言しておきます（笑）

PHPER=コンピュータサイエンスとしての知識が低い人ｗｗｗ

211:nobodyさん
08/03/13 10:49:22
>>207
if文はブロックじゃないから
ブロック付メソッドはブロックを伴うから

212:nobodyさん
08/03/13 11:00:47
>>210
お前、読解力ないのな・・

213:nobodyさん
08/03/13 17:36:30
>>212
それ以外のどんな解釈があるんすかｗｗｗ

214:nobodyさん
08/03/13 18:49:20
いい加減あぼーん機能使おうよ

215:nobodyさん
08/03/13 20:53:17
>>211
一文ならブロックじゃないけど
複合文ならブロックじゃん

216:nobodyさん
08/03/13 21:40:53
>>215
違う
if文はrubyでいう意味の「ブロック」じゃない
rubyのifやwhileやforはスコープを持たない
だからdo～endの代わりにブレスが使えない
eachのようにブロック付き呼び出しで使うのがブロック
こちらはブロックスコープを持つ

217:nobodyさん
08/03/13 23:01:09
変な文法の言語は流行らない法則

218:nobodyさん
08/03/14 05:52:57
>>216
Rubyにおいてはブロック付メソッドが例外で
それ以外ではカーリーブラケットは使わないってことか
Cに喧嘩売りすぎワロタ

219:nobodyさん
08/03/14 16:06:52
PHPフレームワークとの組み合わせでおすすめのアクセラレータは何です？

220:nobodyさん
08/03/14 16:16:37
zend

221:nobodyさん
08/03/14 17:48:44
zendオプチマイザ？
アクセラレータじゃなくね

222:nobodyさん
08/03/14 18:10:09
多言語併用してたら関数とかメソッドまじ忘れてくるな
すべての言語が統一されればいいのに・・・

223:nobodyさん
08/03/14 18:41:06
すぐリファレンスできる言語ならどうでもいいよ
バッドノウハウ頼みな制限や変態仕様が全ての言語から根絶されたら素敵だろうなあ

224:nobodyさん
08/03/14 18:44:08
javaとphpでプロジェクトたらい回しされる・・。

225:nobodyさん
08/03/14 18:44:37
PHPが滅べばいいだけじゃないの？

226:nobodyさん
08/03/14 18:51:29
>>225
そうなっても別にJavaに統一されるわけでもないんじゃね？

227:nobodyさん
08/03/14 21:58:17
Perl=信長
PHP=光秀
Python=秀吉
Ruby=家康

PHPERﾃﾗ三日天下ｗｗｗ

228:nobodyさん
08/03/14 22:01:10
>>227
他はともかく、Ruby=家康だけはあり得ないｗ
むしろ色物だろ

229:nobodyさん
08/03/14 22:13:19
>>227-228
自演乙

230:nobodyさん
08/03/14 22:25:17
何で自演だと思ったんだろうね

231:nobodyさん
08/03/15 00:01:12
URLﾘﾝｸ(enterprisezine.jp)
PHP＝トラブルｗ
LAMPセキュリティ問題の主犯ｗｗ
人知れずPHP3やPHP4を使い続けているサイトはたくさんｗｗｗ
もはやキリシタンみたいな扱いだな

232:nobodyさん
08/03/15 00:11:35
>>231
URLﾘﾝｸ(blog.ohgaki.net)

233:nobodyさん
08/03/15 00:13:21
>>231
そのサイトはひどい釣りにしか見えんな
確かに、既存サーバのPHPが硬直してしまっているっていうのは必要な指摘だとは思うんだけど、
その書き方が突飛と言うか無理過ぎるというか、とにかく説得力がない

例えば
＞Apacheのmod_phpを使ってPHPをApacheモジュールとして実行すると、Apacheプロセスの
＞すべての資格情報がPHPに引き継がれます
って、SuExec等を使わない限り、Perl、Ruby、Python等のCGIでも同じっていうことに言及しない
のはどうかとも思う。他にもいろいろ、わざとかも知れないけど香ばしい

次ページ