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

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

[1からを表示]
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でも同じっていうことに言及しない
のはどうかとも思う。他にもいろいろ、わざとかも知れないけど香ばしい

234:nobodyさん
08/03/15 00:14:31
・・・なんかかぶったｗ

235:nobodyさん
08/03/15 01:27:32
>>230
いつまでも馬鹿相手にする輩なんか本人以外にありえんだろ

236:nobodyさん
08/03/15 08:30:08
ウェブサーバとアプリケーションサーバを別プロセスにした方がセキュアというのは正しいだろう。fastcgiの外部サーバとかJavaみたいに。

237:nobodyさん
08/03/15 16:57:53
最近どこもかしこもやたらSuExecだしなー

238:nobodyさん
08/03/15 17:23:26
suexec導入しようと思ったが
apacheのsuexecの説明見たら
suEXEC の設定には管理者の詳細にわたる慎重な注意が必要
とか書かれてｺﾜｽ

239:nobodyさん
08/03/15 18:23:12
suexecなんか使うくらいならfastcgi使うわ。

240:nobodyさん
08/03/15 18:30:06
suexecって要するにCGIをsetuidされたラッパーを通して実行するもの？
てことはモジュール版のPHPは普通にapacheの権限で実行される？

241:nobodyさん
08/03/15 20:29:23
みたいだね
ってことは、suexecが必要になるのって
不特定多数のユーザにリソースを貸すサーバ屋さんくらい？

242:nobodyさん
08/03/16 00:45:11
だってなぁ、suExecを使わないということは
ほぼApacheモジュールで動いているのと同じなわけで、

Apacheモジュールで動くということは、Apacheの権限で動いているわけで、
PHPを使えば、Apache権限になれるから、
Apache権限で読み出せる他ユーザーのファイルを読み出せるからな。

243:nobodyさん
08/03/16 21:39:19 9hRtdL6R
include_onceがアクセラレータで使われない問題って
apc.include_once_overrideで解決できるんじゃね？

244:nobodyさん
08/03/16 23:14:35
facebookってPHPなんだな
Ruby脂肪ｗｗｗ

245:nobodyさん
08/03/23 05:33:05
Perl=信長
PHP=光秀
Python=秀吉
Ruby=隠れキリシタンｗｗｗｗｗｗｗ

246:nobodyさん
08/03/23 12:01:53
Ruby=慶次

247:nobodyさん
08/03/23 12:28:04
いずれにしろ光秀のPHPって・・・

248:nobodyさん
08/03/23 15:47:03
mbstring系の設定をPHPのコード中でしてたら、どうも文字化けする。
.htaccessに書いたらしなくなったけど。
mbstring系の設定はphp.iniか.htaccessでするって常識？

249:nobodyさん
08/03/23 16:40:24
みなさんすいません。>>248と同じ会社の者です。
まだ見習い中なのでとりあえずphpに慣れてもらおうと課題を出したのですが、
何日たっても報告にこないのでついさっき報告をあげさせると共に指針を与えた所でした。

mbstringが、mbstringがと、説明が要領を得なくて時間がかかったのですが、
どうやらmbstring.languageをスクリプト中で指定しようとしていたらしく、
マニュアルで確認するように伝え、日々日報に問題点を記述するように厳しく指導いたしました。

今後このような事が無いように指導を行い、
また、ご迷惑をおかけしましたことをお詫び申し上げます。

250:nobodyさん
08/03/23 16:51:02
なんていうか不安でいっぱいな会社だな。まあガンガレ。

251:nobodyさん
08/03/23 19:26:02
常識なの？
誰も言わなかったじゃん
ちゃんと説明しろよ249のハゲ

252:nobodyさん
08/03/23 20:55:07
懐かしいコピペだな

253:nobodyさん
08/03/23 21:23:45
PHPのmb_send_mail()とかクソ過ぎだろ。どうやったらこんな分かりづらいAPI思いつくんだか。

254:nobodyさん
08/03/23 21:39:27
>>253
上の方で出てた
mb_send_mail使う奴はど素人、プロはmailを使うでFA

255:nobodyさん
08/03/23 21:48:36
プロなら直にSMTP

256:nobodyさん
08/03/23 22:31:41
>>255
まあ汎用的ではあるな。一度しっかりとモジュールを作ってしまえばいいわけだし
というわけで、マルチバイトや添付ファイル、HTMLメールにがっつり対応したメールモジュールのある
フレームワークの紹介よろしく！

257:nobodyさん
08/03/23 22:35:47
>>256
あとPOP before SMTP と SMTP Auth にも当然対応しているという奴かな
どこにでも転がってそうだけど、一つばっちりした物があればそれでいいんだし

258:nobodyさん
08/03/23 22:35:49
>>256
Zend

259:nobodyさん
08/03/23 22:47:42
>>258 thx
結局ライブラリの質というか筋がいいとかでいうと、Zendが一番なのかな

260:nobodyさん
08/03/23 22:52:37
そうだね

261:nobodyさん
08/03/23 23:09:14
餅は餅屋なんだからMTAに任せたらいいじゃん
わざわざSMTP叩く奴なんなの？変態なの？

262:nobodyさん
08/03/23 23:32:43
>>261
MTAはMUAの間違い？（sendmailコマンドの様な）
PHPの関数インターフェイス(mail(), mb_send_mail())もMUAと言えなくもないのかな

でも、外部SMTPサーバを使いたい時も同様に扱えるから初めからMTAのサーバを
ソケットから叩くっていうのはそんなにおかしくないと思うけどな
そりゃいちいちpopenとかベタベタでやるのは変態っぽいけど、ライブラリになっていれば
そんなに手間でもないと思うし、PHPの関数叩くのとやってることは大して変わらないと思う

263:nobodyさん
08/03/23 23:39:24
>>262
ソケット通信なら、popenじゃねえな
fsockopenとかそういうのだな。PEARでもいいけど

264:nobodyさん
08/03/24 00:44:07
あー
外部にメールサーバがある場合か
なるほどね

265:nobodyさん
08/03/24 00:53:41
ZFだと確かPOPも扱えたよね。

266:nobodyさん
08/03/24 01:03:45
そうだ。餅は餅屋に任せよう。
んで、sendmailで添付ファイルを送るにはどうすればいいんだ？

267:nobodyさん
08/03/25 15:59:11
餅は餅屋って、sendmailはMTAだから、そのおまけのコマンド起動送信も含めて
添付ファイルを処理させるのはおかどちがいだろう。
まぁ適当にmultipartなメールをでっちあげてください。

>>262
MUAって、MDAが落としたメールとかも読めなきゃいけないんじゃない?
たぶん、あれをMUAとは言わんような...どっちでもいいけど。
どっちも/sbin/sendmailだからややこしいな。

268:nobodyさん
08/03/29 02:49:42
PHP のフレームワーク: 第 5 回外部タスクを統合する
URLﾘﾝｸ(www.ibm.com)

3大フレームワークでのバッチ処理についての記事。
このシリーズは正にこのスレ向けだね。

269:nobodyさん
08/03/30 17:45:17
フレームワークでは例外がデファクト的に使われてるけど
例外だとApacheのエラーログに残らないのが難だな
フレームワークのログには残るけど。
Apacheのエラーログ見ながらテストってよくやるし、
そこで例外が確認できないのはイケてない。

270:nobodyさん
08/03/30 18:05:39
>>269
FWの一番上層のtry～catchで
error_log($exception->getMessage());
しておけばいい
mod_phpならapacheのerror_logに吐かれる
自分で例外をハンドリングもせずに例外が難だな、とか言われても

271:nobodyさん
08/03/30 19:45:47
>>270
>FWの一番上層のtry～catchで
その部分はFWが提供していて書き換えられない・拡張できない場合がほとんどだろ
自作FWじゃないんだから

272:nobodyさん
08/03/30 19:55:44
例外使わないCIが最強

273:nobodyさん
08/03/30 22:07:54
>>271
FW全域に渡ってのエラーハンドリングできないFWもアレだと思うし
仮にできなくてもブートストラップになるdispatch部分をtry-catchしたらいいし
それもいやならexception_handlerだってあるしやり方はいくらでもあるよ

274:nobodyさん
08/03/30 22:31:58
素直にframeworkのlog見ときゃいいだろ、と思ってしまう。

275:nobodyさん
08/03/30 23:06:10
ログが残る場所が変わるだけだろｗ

276:nobodyさん
08/03/30 23:37:57
だいたいアプリレベルのログをなんでapacheのエラーログでみたいのかが分からん

277:nobodyさん
08/03/30 23:45:40
アプリのログならその気になれば
HTTPヘッダやスタックトレースを出したりできるしな。

なんで不便なapacheログに頼るのだろう？

278:nobodyさん
08/03/31 01:07:38
html側の気づきにくいミスも分かるからapacheログ便利じゃん
fwのログではリソースへのリンクミスは分からない
どこかひとつにまとめておくならapacheログになる

279:nobodyさん
08/03/31 02:15:07
>>278
まとめて保存されてても
見る時は見づらいからフィルタリングして分けてるんじゃないの？

280:nobodyさん
08/03/31 02:58:55
俺なんてapacheログに日記書いてるよ

281:nobodyさん
08/03/31 03:01:14
その発想はなかったわ

282:nobodyさん
08/03/31 13:35:52 q29QDC7U
フレームワークのORMって
テンポラリテーブルやサブクエリ使うような処理はどうなってるの？
出来るのはせいぜいリレーションまで？

283:nobodyさん
08/03/31 14:57:48
サブクエリ対応のORMもあるんじゃないかな。はっきりあるとは言えないけど。
テンポラリテーブルはORMの範疇じゃないと思う。

284:nobodyさん
08/03/31 18:38:39
>>282
そういう場合はSQLを直接発行する。

285:nobodyさん
08/04/01 00:51:46
複雑なSQLになると、SQLは3分で書けたのに、それをORMの文法に直すのに1時間かけても出来無くって、挙げ句ORMのソースコード見たら対応不可能だったという。

286:nobodyさん
08/04/01 01:29:08
っていうか、ORMは80%の簡単なSQLを
簡単に使うのが目的なわけで。

表形式のデータを扱いやすい構造体に変更するの
面倒なんだよ。

287:nobodyさん
08/04/01 02:16:43
>>286
それはORMを理解してない。

> 表形式のデータを扱いやすい構造体に変更
「テーブルのリレーションをオブジェクトのグラフに」ってことだと思うが、
本来ORMはそれを半自動的(設定ファイルが必要)に実現するためのもの。

> 簡単なSQLを簡単に使うのが目的
これを実装したライブラリとかプロダクトがORMを理解してないのに
ORMとか言っちゃったもんだから、そう勘違いしてる人が多いんだけど。

288:nobodyさん
08/04/01 16:18:05
DBを単純なストレージとしてしか使えてない
joinとかサブクエリとか使いこなせてないわ
そんな俺は何から勉強したらいい？

289:nobodyさん
08/04/01 16:23:40
とりあえずは、普段自分が使うDBのSQLをしっかり覚えればいいんじゃない？
それ以上は、DB屋さんが面倒見てくれるでしょ。

290:nobodyさん
08/04/02 09:36:40
PHPじゃないけど、Bash on Railsなんてものが公開されてるね。
まぁ、ジョークなんだけど。

URLﾘﾝｸ(emasaka.blog65.fc2.com)

シェルスクリプトって、普段/bin/sh互換で書かされるから、
Bashの機能をフルに使って、のびのびと何か書きたい気持ちはわかる。
なんか、昔BashでIMAPを喋るスクリプトを書いたのを思い出した。

291:nobodyさん
08/04/02 21:41:33
bash爺さん乙

292:nobodyさん
08/04/02 21:57:39
頼むから少しでもbash絡みの構文が入ったら#!/bin/bashのサフィックス.bashにしてくれな。

293:nobodyさん
08/04/02 23:23:53
>>292
ファイル名のこと？
っていうか拡張子すら無いのも多いし、シェバングがきっちりしてれば気にしない

スレ的に展開すると、世の中には.htmlでPHP書く会社も結構あるしなあ
そこまでじゃなくてもテンプレートファイルが（実質PHPやテンプレート独自言語でも）.htmlなところも多いし
まああれだ。拡張子なんて飾りですよと。Windows使いにはそれがわからんのですよ

294:nobodyさん
08/04/03 00:32:15
今時糞文法のシェルスクリプト使うってどこのマゾだよ
Rubyでやればいいじゃん

295:nobodyさん
08/04/03 00:37:29
ほぼ存在が期待できるperlじゃなくてrubyってところにリッチさ？を感じる

296:nobodyさん
08/04/03 01:07:46
PerlがないならRubyを使えばいいじゃない

297:nobodyさん
08/04/03 07:21:38
>>296
そんな環境あり得ないだろ

298:nobodyさん
08/04/03 16:03:55 YXuoF4WI
perlとpythonはたいていひっついてくるよね

299:nobodyさん
08/04/03 17:23:53
>>296の滑りっぷりに萌えた

300:nobodyさん
08/04/03 23:27:45
Perlの場合、CPANモジュールのインストールを必要とすることが多いから。
BシェルはもちろんBASHの移植性にはかなわない。

301:nobodyさん
08/04/03 23:42:49
>>300
それがPerlではなくRubyの理由？
じゃないよな
この噛み合わなさはいい加減すごいな

っていうかPHPフレームワークの話題は無いのかｗｗｗ

302:nobodyさん
08/04/05 00:07:56
>>300
CPANモジュール使わなきゃいいじゃんっていうのは無し？
だってCPANモジュール使わなくても、bashに出来ることはPerlで書く方が楽じゃね？
俺はLinuxとかよくわからんが、bashで書けてPerlで書けないこととかってあるの？

次ページ