08/10/17 00:38:24
PHPプログラマーの方でPHP用フレームワークを使っている方へアンケート！ ※フレームワーク導入を検討中。先輩方は何を使っているのか？好んでいるのか？をアンケート。.. - 人力検索はてな
URLﾘﾝｸ(q.hatena.ne.jp)
Pradoが圧倒的ですねｗ
URLﾘﾝｸ(www.pradosoft.com)
233:nobodyさん
08/10/17 01:45:17
このpradoぶっちぎりはネタだよね?w
234:nobodyさん
08/10/17 03:15:57 7gkZ0lcc
>>233
PRADOの解説本が出てないじゃん！？
Zend、Symfony、CakePHP、CodeIgniterの本は出てるぞｗｗｗ
出版社は売れるであろう本を出すはず
235:nobodyさん
08/10/20 02:51:25 ya5easnJ
symfonyってページネーション機能はあるんですか？
ネットで検索しても「ajaxでページネーション」はあるんだけど・・・
236:nobodyさん
08/10/20 17:37:11
英語の情報をなかったことにするのは君にとって損失かもしれないよ?
URLﾘﾝｸ(www.google.co.jp)
237:nobodyさん
08/10/20 21:10:52 Kq4igHV+
>>236
でもそれも機能たいしてなくないか？
CakePHPみたいに同一ページの複数モデルに対応してないでしょ？
っていうか、ページネーションって掲示板ですら絶対に必要になる機能なのに
なんで標準で付けないんだろ
238:nobodyさん
08/10/20 21:57:19
>>237
最適化が難しいから。
一度でもページネイションの機能を作ったことがあればわかると思うが、
DBから全データ読み込んでから絞り込むのか、検索条件を考慮したデータを
取得しておいてからそれを絞り込むのか、なんだかんだ。
基本的に、データの「件数」がわからないとページング出来ない。
（それを無視してやるページングもあるが。）
どうせライトユーザ向けには、DBやらと連携したページングを求め
られるんだから、「始めからつけてない」は、ある意味賢明な選択だよ。
・・・↑が不満なら、PEARとか使えばいいじゃん、全く。
239:nobodyさん
08/10/20 22:10:00 Kq4igHV+
>>238
いや俺もたいしたやつじゃないけど作ったことあるし、
CakePHPのソースを解析したりしてみたけど、
そんなに難しくはないと思うけどな（だったらそれ使えばいいじゃんと言われるかもしれないが・・・）
＞基本的に、データの「件数」がわからないとページング出来ない。
これは渡せばいいだけ
240:nobodyさん
08/10/20 22:21:43
>>239
うん。だから、>>238の二行目
>最適化が難しいから
と、最終行
>・・・↑が不満なら、PEARとか使えばいいじゃん、全く。
が、結論なんだけどなｗ
「フレームワークに標準で付いていない」ってのが問題じゃ無かったのか？
241:nobodyさん
08/10/20 22:31:39 Kq4igHV+
>>240
PEARは使いたくない
まあ、付いてないことがはっきり分かったからもういいです
242:nobodyさん
08/10/20 23:11:01
paginationはZendなら標準で付いてる
しかも色んな状況に対応できる
さあ、ZFを使おう！
243:nobodyさん
08/10/20 23:27:07 Kq4igHV+
まあそれが普通だよな
244:nobodyさん
08/10/20 23:34:15
＞基本的に、データの「件数」がわからないとページング出来ない。
CakePHPはよくできてる。
データの件数ってのは、データ用のSQL文のうち条件は同じでselectするものが、
フィールド名の変わりにcount(*)になっただけ。
そこの部分（フィールド名の変わりにcount(*)）への変換を
自動でやってくれるから、データ用のSQLに相当する部分のみを書けばいい。
また、データ用のSQLにlimitを主導で追加する必要もない。これも自動で追加される。
つまり、「データを取ってくるSQL」を書いて「ペジネーション」処理を使うだけで内部的に、
「データを取ってくるSQL」には、自動的にlimitが追加されて発行され
「データを取ってくるSQL」には、自動的に件数を取得するcountに変更される。（当たり前だがこっちにはlimitはつかない）
（もちろんSQL直書きではなくモデルの操作だが）
最適化って話なら、データ件数を取得する関数をオーバーライドできる。（上のやつはデフォルト動作）
こういう目的でオーバーライドされるために存在するメソッドが用意されている。
245:nobodyさん
08/10/20 23:41:59
>>244
うーん。それは、例えばファイルベースのデータとかには適用できないよね。
メールボックスを漁るとか、さｗ
無理矢理使おうと思えば、いっぺんDBに放り込む必要がある。
そんな（SQLで全部済む）フレームワークばかりではない、っていう前提に
立てば、ページネイションの機能は汎用的なものにならざるを得ない。
データの件数と一ページ辺りの取得件数から、データ開始位置（番号）と
データ終了位置を取得する、みたいな。
SQLで言えば、OFFSET とそこからの LIMIT を取得するだけ、っていう。
んで、そんなクラスが乱立しても仕方ないので、PEARなりZendなり使えって
結論で多分無問題。
と思うんだけどなぁ
もちろん、>>244みたいな全自動？ページネイションを否定するわけではないけど。
246:nobodyさん
08/10/20 23:53:02
SQLを使わないページネイションなら別にある。
247:nobodyさん
08/10/21 00:20:07
mysqlならSQL_CALC_FOUND_ROWSを使いたいよね
248:nobodyさん
08/10/21 00:32:46
>>247
またそんな無茶ぶりをｗ
フレームワークなりライブラリなり作る身になれｗ
まあ、そんなこと言う人は自分で作るんだろうけど
249:nobodyさん
08/10/21 01:06:35
>>244
>CakePHPはよくできてる。
別にCakeだけがよくできてるわけじゃなくて、Cake以外もできてますよね？
250:nobodyさん
08/10/21 03:24:50
>>247-248
ページネイションとSQLをごっちゃにしてね？
SQL_CALC_FOUND_ROWSを使った独自SQL文からのデータを、
ページネイションに渡せばいいんですよ。
251:nobodyさん
08/10/21 03:26:05
>>249
symfonyにはないってことから、この話題がはじまっている。
252:nobodyさん
08/10/21 03:31:10
ページネーションくらい自分で書けばいいじゃん
253:nobodyさん
08/10/21 03:33:09
cakeなどという厨フレームワークを使える奴は恥知らず
それだけはガチ
254:nobodyさん
08/10/21 03:36:51
>>252
だからそういう問題じゃないんだって
そんなこといったらFWも自分で書けば（ｒｙ
255:nobodyさん
08/10/21 03:37:18
simplateの中の人が不治の病で引き継ぎする人募集してるね
面識ないし、simplateを使ったこともないけど泣きそうになっちゃった
256:nobodyさん
08/10/21 03:39:35
てかモデルは自分で書いた方がいい
FW付属のモデルだとクラスタリング対応とかしにくいじゃん
257:nobodyさん
08/10/21 03:41:23
こういうスレって必ず>>253みたいな奴が現れるよなｗ
258:nobodyさん
08/10/21 03:42:25
>>257
恥知らず乙ｗｗｗ
259:nobodyさん
08/10/21 03:46:39
>>255
もういいんだ。PHPの世界でテンプレートはもう死んだんだ。
みなが、PHPがテンプレートそのものじゃね？と気づいた。
君の役目は終わった。
260:nobodyさん
08/10/21 03:53:16
simplateの中の人はいい仕事をしている
いい仕事をしている人を愚弄するな
261:nobodyさん
08/10/21 03:57:54
愚弄？
262:nobodyさん
08/10/21 03:58:45
>>255
一度計ったことがあるけど
たしかに速いね
>>257
相手にしない方がいいよ
263:nobodyさん
08/10/21 04:04:16
cake使いって案外多いんだなｗ
高カロリー低栄養のケーキ喰いすぎてメタボm9(^Д^)ﾌﾟｷﾞｬー
264:nobodyさん
08/10/21 04:39:49
>>263
後半は、なんだい？ ケーキの話かい？ じゃあすれ違いだねｗ
265:nobodyさん
08/10/21 10:18:09
>>263
こいつ自分から頭悪い発言してるなｗ
266:nobodyさん
08/10/21 15:53:57
厨フレームワークだけあって
さすがにcake厨の煽りはレベル低いねｗ
267:nobodyさん
08/10/21 16:58:55
おまえらライスケーキでも食ってすこしもちつけ
268:nobodyさん
08/10/21 17:12:18
だいたいページネーションとmodelを一緒くたにするなんて愚かすぎだろ>cake
まず汎用的な単体ページネーションクラスを書いて
それにモデルをアタッチできる継承クラス書くなり
アダプタ書くなりするのが普通です
つまりsymfonyは神、cakeはホームレス
269:nobodyさん
08/10/21 18:03:54
> だいたいページネーションとmodelを一緒くたにするなんて愚かすぎだろ>cake
ページネーションがmodelと一緒くたになっていると
勘違いする人もいるんだなぁｗ
コントローラと一緒くたになっているというならまだしも。
（まあコントローラと一緒くたになるのは何の問題もありませんが）
いったいどこの部分を見て一緒くたといっているんだろうか。
modelから任意の範囲のデータを持ってくる機能？
これをmodelに入れないとしたらどこに入れるんだか。
270:nobodyさん
08/10/21 19:56:58
まぁ、cake見たことないから憶測で言ってるだけだけどね。
cakeってPHP4/5用だっけ？
4を切り捨てずにクリーンになんて書けるわけねーし
物乞い乙ｗｗ
271:nobodyさん
08/10/21 20:34:39
なんにしても厨っぽい発言していると説得力なくなるぜ
272:nobodyさん
08/10/21 21:33:22
code igniterにしてもcakephpにしても
ウリだったPHP4対応が今度は足かせになります
273:nobodyさん
08/10/21 23:07:36
切り捨てなかったからユーザがついたんじゃないの
274:nobodyさん
08/10/22 02:03:20
つかPHP4が使えないフレームワークなんて
仕事じゃ使えません
275:nobodyさん
08/10/22 02:05:32
>>274
とも限らなくなってきたな。
いつまでも古いサーバ使ってるんじゃないよー
276:nobodyさん
08/10/22 02:16:16 //oF70yn
>>275
クライアントに言ってくれよ…
verアップを勧めても、他のプログラムに不具合が出るかもしれないので
PHPのverアップはできません(^o^)
って言われるしな…
277:nobodyさん
08/10/22 02:32:46
実際クリーンとかピュアとかって商売としては・・
278:nobodyさん
08/10/22 05:53:06
>>274
すごいな。未だにこんな仕事してるやついるのか…
279:nobodyさん
08/10/22 08:21:37
ま、今でもPHP4を指定する案件は多い。サーバ上の他のプログラムがPHP4で動いているなら、新しいプログラムもPHP4にするしかないからな。
280:nobodyさん
08/10/22 08:43:18
>>279
歩のスパイラルだな
もうPHP４は絶体絶命のセキュリティ穴でも作って
使ってるサーバごとぶっ壊せばいいのに
281:nobodyさん
08/10/22 13:04:41
実際PHP4はもうセキュリティFIXも出さない予定なんだろ？
といいつつこないだ出たけど。
レン鯖でPHP4と5共存してるところとかあるよね。
282:nobodyさん
08/10/22 15:48:34
php4で作るならphp5より高いですよ。
とか言えばいいんじゃないのかな。
実際大変だし。
283:nobodyさん
08/10/22 16:26:31 Skk+7Du0
>>282
じゃあ他に頼みます
284:nobodyさん
08/10/22 16:29:12
こうしてダンピングも続くのであった
285:nobodyさん
08/10/22 16:32:01
一度出来上がったものを新しくするのにはコストもかかるから仕方がないってのはわかるが
踏ん切りつけれないとこ(クライアント)は総じて馬鹿な奴が多いよな。不思議と。
286:nobodyさん
08/10/22 16:42:21
IEも未だに6使ってるやつは馬鹿
作り手の気持ちを考えられない
287:nobodyさん
08/10/22 16:46:31
>>283
それで仕事逃すなんてもったいない。
php5で作る素晴らしさを説明して、説得するんだ。
php4なら高いというのは、言い換えればphp5なら安い。
実際php5で作るよりphp4の方が工数増えない？
クライアントというより、元請からの仕事なら、しょうがないが。
288:nobodyさん
08/10/22 17:31:12
というか、PHP5の方がセキュリティホール見つかるの多いし。
289:nobodyさん
08/10/22 17:50:12
>>287
クライアント「で、PHP5で作ったらいくら安くなるの？」
290:nobodyさん
08/10/22 18:01:25
PHP5%引き
291:nobodyさん
08/10/22 18:28:36
>>290
普及率かな？それなら合理的かな
292:nobodyさん
08/10/22 18:29:23
PHP5用に別鯖立てればいいじゃん
今から作るのにPHP4なんていくらなんでもあほすぎだよ
293:nobodyさん
08/10/22 18:46:54
将来的に何れ変更が必要になるわけで、今がチャンスですよと押し込む材料は十分あるしなｗ
294:nobodyさん
08/10/22 19:02:07
>>286
作り手の気持ちなんて考えるユーザやクライアントなんてほぼ皆無だと思うけど
295:nobodyさん
08/10/22 22:23:46
>>294
それを工数・予算に絡めて喋るのがいい営業・・・ってのは夢かなー（棒読み）
296:nobodyさん
08/10/23 00:13:27
>>292
確かに、今から作るならPHP5だね。
まっさらな新規案件なのにPHP4でっていうのは、
PHP4に慣れて自分のライブラリとかをPHP5で使えるようにしない技術者の怠慢。
ただ、PHP5だからって工数が圧倒的に圧縮できる訳じゃない。
そういう意味では、既存でPHP4で走ってるのの改良はかなりつらい。
297:nobodyさん
08/10/23 01:19:05
>>296
>PHP4に慣れて自分のライブラリとかをPHP5で使えるようにしない技術者の怠慢。
ちょっと違う。
使えるようにできない、ていうか、（できないことはまずないから）、できるかどうかすら
わからない、技術者の怠慢「と無能」
が正しいように思ってる。まあこんな事は職場では言いたくないけど。
298:nobodyさん
08/10/23 01:29:54
いや、クラの我儘だろ
299:nobodyさん
08/10/23 01:34:26
>>298
それすら、怠慢（自分の仕事を楽により良くする努力を怠っているという意味で）、
っていう次元ですよ。
「新規案件でPHP4」っていうお話はね。
既存スクリプトの保守案件はまた別と理解してます。
あと、教育コストが云々は認めません。少なくとも、俺がチーフ（笑）なら。
300:nobodyさん
08/10/23 08:08:47
PHP4もPHP5も使う立場ではほとんど変わらないから。PHP5がE_STRICTを強制するとかっていうなら、PHP5の方が難易度高くなるけど。
301:nobodyさん
08/10/23 12:08:45 yerXAIOJ
おいおい
サポート切れてるPHP4つかうなよ
302:nobodyさん
08/10/23 12:21:21
> PHP5がE_STRICTを強制するとかっていうなら、PHP5の方が難易度高くなるけど。
E_STRICT強制で難易度高くなるってなんだそりゃ？ｗ
警告をプログラムを完成させるまでの試練と考えているのかな？
俺にとっては、警告はプログラムを完成させるまでの
サポートだと思うんだが。
つまり、E_STRICTを強制されたほうが逆に難易度は低くなると感じる。
間違ったコード、良くないコード、そういったものを排除できるからね。
303:nobodyさん
08/10/23 12:24:37
致命的な不具合が見つかっても対応されない可能性が高いPHP4なんて
早く切り捨てるべきと説き伏せろ！
あれ、ここ何スレ？
304:nobodyさん
08/10/23 12:25:03
E_STRICTは正直うざいけどね
出すにしても、別にログを取りたくなるくらい
一方、E_NOTICEはデフォルトでONでもいいと思うんだ
この辺のバランスがなあ
305:nobodyさん
08/10/23 12:30:37
E_STRICTで出るエラーなんて潰していくのは基本だろ・・・
どんだけいい加減なもの作ってるんだ
306:nobodyさん
08/10/23 13:31:17
>>305
Java大好き志向でのコーディングかな？
まるまる新規コーディングじゃないとNon-static method ～～ とか、
出まくって修正も大変だと思うんだが。
「基本」は言い過ぎだし、頭でっかち感が否めない
いまだにnoticeすら無視されまくってる現状で
307:nobodyさん
08/10/23 13:42:27
保守案件はE_STRICT云々以前に、いろいろと大変なこと多いからな。
少なけりゃつぶすけど、多かったら放置にはなるね。
新規案件なら、E_STRICTなんてたまにしか出てこない。
たまにだから、出たらつぶすよ。
てかE_NOTICEもそんな頻繁に出ないような。
どっちかというと、Pear使っていい案件の時、Pear内に沢山あって
ゲンナリすることの方が多いなぁ。
308:nobodyさん
08/10/23 15:10:38
まあ、どっちみちPHPの場合、おおざっぱな警告メッセージとか変数のスコープなんで、あまり役に立たないと言えば立たないが。
それでも、下手なプログラムを排除できるというメリットはある。E_STRICTをオンにしたら、エラーばっか出て実装が進めないPHPプログラマーは多数いるだろう。
309:nobodyさん
08/10/23 16:06:40
> エラーばっか出て実装が進めないPHPプログラマーは多数いるだろう。
それはお前だけｗ
310:nobodyさん
08/10/23 16:58:02
E_STRICTうざいってどんだけー
311:nobodyさん
08/10/23 18:45:04
>>309
PHPプログラマーのレベルなんて、そんなもんだから。
312:nobodyさん
08/10/23 19:04:58
>>311
だからそれはお前だけｗ
313:そこそこ初心者
08/10/23 21:41:05
Cake←何て読むの？フレームワークはどこでダウンロードできますか？
なかなかダウンロードページにたどり着けません…
314:nobodyさん
08/10/23 21:41:33
終わってる
315:nobodyさん
08/10/23 22:04:30
>>312
類は友を呼ぶっていうだろ。
>>311の周りにはそういうゴミみたいな連中が沢山いるんだよ。
底辺の環境で仕事してる証拠。
316:nobodyさん
08/10/23 22:05:17
URLﾘﾝｸ(www.phppro.jp)
いまだに一番使われてるフレームワークはMojavi
317:nobodyさん
08/10/24 03:28:29
>>316
その言い方には語弊があるようなw
「現状使用したことがあるフレームワーク」という質問だから、今使用しているとは限らないと思うが
318:nobodyさん
08/10/24 08:18:02
ウェブフレームワークの使用経験があるのが70%、そのトップがMojavi。
しかも、PHPカンファレンス2008に参加したという、技術に関心の高いPHPプログラマーが対象のアンケートでこの有様。
319:nobodyさん
08/10/24 09:01:16
この間面接受けてきた会社
フレームワークは重くなる遅くなるから使いません！言ってたな
提供サービスを全部新しく作り直すらしいけど、次はJavaでもPHPでもなく、Rubyだ！
とか言ってた。でもRails遅過ぎるから速度が必要なとこだけFWなしのPHPだとかなんとか…
大丈夫か…ｗ
320:nobodyさん
08/10/24 09:09:26
フレームワークは重くなるとか言ってるようなアホ会社は
無駄なコード書いて死んだらええねん
321:nobodyさん
08/10/24 09:42:46
DRYなコードを書けば自ずとフレームワークに近くなるしなｗ
てか速度が必要なとこだけphpという選択はどうなの？何でphpなの？
322:nobodyさん
08/10/24 11:41:32
1つのファイルで完結できるから、とかいう意味じゃね？
323:nobodyさん
08/10/24 11:47:54
FastCGIとかMongrelとか調べたくも覚えたくもない、
とかいう意味かもね？
調べた上で使えねえ、って言ってるのかもしれんが
324:nobodyさん
08/10/24 12:30:23
自分仕事で開発とかやったことないような超ド素人だから、
そうなのかーってちょっと思わされかけてたけど、やっぱおかしいよねこれｗ
ちなみに、規模や今後の事なんかも考えると、Javaとかを選択したほうが
いいんじゃないかとかをきいてみたら、Javaは遅いし、もう古いとか言われてさ
さすがにその見解はちょっとどうなのって思っちゃったｗ
フレームワークを使わず自分でコード書くことは(勉強としては)すごく重要だと思うし
自社開発の会社だから、社員の成長のためにいろいろやらせたい、って感じな部分も
あるのかもしれないけど、メインの仕事で車輪の再発明みたいな事繰り返して
無駄な工数増やすのは間違ってると思ったｗ
325:nobodyさん
08/10/24 12:37:16
>>324
「Javaは遅いし」
ちょっと待てｗ
うーん。こういう面接（下手したら社長とか）も、あるあるｗとしか言えない
326:nobodyさん
08/10/24 12:47:42
確かに昔はVMとかすげー重くてもっさりって感じで、アプレットとかうぜぇって思ったりしてたけど
まさかJava=アプレットとしか知らなかったりしてナｗ
327:nobodyさん
08/10/24 13:27:47
「Javaは(開発速度が)遅いし」とかじゃ
328:nobodyさん
08/10/24 14:05:30
Javaはもう古いには同意するな。
元々Javaをやってる会社なら別だけど、今選択するならJavaは古いと思う。
あと既存のフレームワークを使わないで、自社で作るという選択肢はありだと思う。
既存のものは何かと合わなかったりするし、フレームワークが無いと開発できません。
は困るし。
自社のフレームワークもありません。
だと困るがｗ
329:nobodyさん
08/10/24 14:15:28
>>328
代替物が無い状況では、古いってのは意味がない
なんでまだC言語で開発が行われてるのかと
PHPやRubyがJavaを完全に代替できる筈もないし、
目指してもないだろ。
文脈無しでJavaが古い、はナンセンスだと思うよ
330:nobodyさん
08/10/24 14:24:54
それ以前に、PHPのスレで「Javaは古い」っていうのは笑止千万なようなｗ
331:nobodyさん
08/10/24 14:59:36
>>329
いやさ、これから会社が新たな「開発言語に取り組む！」って時に、
何の言語か聞いてみたら、
「これからはJavaです！」とかいってたら、
「いまさら？」って思わないかってことなんだが。
もちろんJavaは現役で使われてる言語だとは思うよ。
俺も案件によってはphpじゃなくてJava使うし。
332:nobodyさん
08/10/24 15:12:25
Java古いつってPHPやらRubyやらってのも説得力がないんだよなｗ
ある程度古く枯れてきてないと商用にはあまり向かないってのもあるだろうし
色々理由付けがあっての「古い」なのかも知れないから、深くは突っ込まなかったけど
なんかJavaを毛嫌いしてるって感じの印象を受けた感じだった
自社開発で提供してるサービスだったし、自社FWってのはありだと思うけど
日が建つにつれ混沌としてきて、組み込みなんかであるような
なんともドロドロした感じのものが出来そうなイメージもあるんだよなー
Web系で使う言語なんて結局は殆どが文字列操作をするためのもんだし、
自社製FWはどんなに突き詰めていっても
既存のものから使わないメゾッドとか減らしてHDDの使用量を減らしました！速度も気持ち速いです！
ってくらいの差しか出ないんじゃないかなーと
…と、スレチっぽい話題振ってスマソｗ
>>331
それは言語が古いんじゃなくて、その会社の取り組みの姿勢が遅れてるって感じなんじゃｗ
333:nobodyさん
08/10/24 15:30:39
その人の心の中ではJavaは古い物だったんだろう。
334:nobodyさん
08/10/24 15:39:06
rubyに比べると新しくはないという意味なら文脈としてもおかしくはないかと。
新しいからって理由で方向を決めるのもちょっと心配になるがw
335:nobodyさん
08/10/24 15:55:33
ことFWに関してはJavaはPHPに比べて圧倒的に成熟してる気がする
最近Java触り初めてSAStrutsやらS2JDBCやら使ってるけどめちゃくちゃ開発効率上がったよ・・・
俺なんかJava全然知らないのに知らなくても普通に使える。これすごいよ
336:nobodyさん
08/10/24 16:24:57
PHPフレームワークは色々あるけど「これなら！」ってのがなー
337:nobodyさん
08/10/24 16:38:07
標準になりそう（なってほしい）のがSymfony
PHP4からの移行とかで現実的なのがCakePHP
公式だけど、フレームワークとしてはいまいち、
どちらかといえばライブラリ？って感じなのがZendFramework
338:335
08/10/24 16:42:42
>>336
このスレのネタなのかマジなのかわからない「もうちいたんでいいよ」
っていう指摘はあながち間違ってないと思うんだよね
以前もどこかで同じ事言ってる人がいたが、デファクトスタンダードが
決まらない状況が続けば続くほど、リソースの集約もそれに輪をかけて遅れていくわけだし。
それに伴って余計スタンダードが決まらない・・・リソース（ｒｙ
の悪循環が続いて俺はPHPに限界を感じて、Javaに手を出すことにしたんだよ。
PHPの適当さ加減を一番活かすには必要最小限のFWでいいと思う。
逆にちいたんが成熟していったらかなりいい物ができあがるんじゃないかと思っている
339:nobodyさん
08/10/24 19:20:00
Javaでなんのフレームワーク使っている？
Struts？ Spring？ Seasar？
結局Javaでもフレームワーク乱立だと思うけどね。
Javaは長いようだが成熟しているというわけでもなく、
J2EE/EJBが否定されて根本的に覆ろうとしているし（覆った？）
DIコンテナはもう普及し終わったかな？
340:nobodyさん
08/10/24 21:35:46
そっちのスレでやってくれ
341:nobodyさん
08/10/24 22:23:02
オープンソースなんだから乱立が正常な状態だろ
多様性があるから発展性があるんだし
342:nobodyさん
08/10/24 22:31:56
結局JavaにしてもPHPと状況は変わらんってことだなｗ
343:nobodyさん
08/10/24 23:56:56
そのまとめ方はさすがに無理あるだろｗ
344:nobodyさん
08/10/25 14:14:16
結論
ちいたんでいい
345:nobodyさん
08/10/25 14:50:17
ちいたんはいつ1.0になるのだね
346:nobodyさん
08/10/25 16:14:43
作者が飽きるので永遠になりません。
347:nobodyさん
08/10/25 16:21:09
ってか実際ちいたんつかってる人っている？
仕事ではさすがに使えないだろうけど、個人でなら十分実用なんだよな
348:nobodyさん
08/10/25 17:16:18
あえて使うことはねえよｗ
349:nobodyさん
08/10/25 18:12:46
ごもっともｗ
350:nobodyさん
08/10/26 00:22:59
ちいたんってオチに使われてる以外にあまり見たこと無いがw
351:nobodyさん
08/10/26 00:59:20
オチに使われる奥さんｶﾜｲｿｽｗ
352:nobodyさん
08/10/26 01:07:17
ちぃたんって嫁の名前なのか
お前のために歌作ったんだみたいなアーティストっぽいな
353:nobodyさん
08/10/26 02:43:49
プログラマもアーティストって肩書きにすれば人気出るんじゃね？w
354:nobodyさん
08/10/26 02:45:15
アーティスチックなコーディングをされても周りは困る
355:nobodyさん
08/10/26 03:03:20
海外のハカーは奥さんの名前つけたりするね
356:nobodyさん
08/10/26 10:48:45
でもそういうのは日本じゃ流行らなさそうｗ
357:nobodyさん
08/10/26 11:45:37
あっちじゃ台風すら人名つけるしなあ
358:nobodyさん
08/10/27 20:03:18
名前空間の実装がダサすぎてPHP脂肪ｗｗｗ
\区切りキモス
359:nobodyさん
08/10/27 20:08:32
\区切り？ あぁ。頭の弱い人か。
360:nobodyさん
08/10/27 23:28:39
PHPER必死の強がりワロスｗｗ
361:nobodyさん
08/10/27 23:34:39
その釣り方はさすがに無理があるよ
362:nobodyさん
08/10/27 23:36:33
PHP5.3の名前空間は\区切りなの？
363:nobodyさん
08/10/28 00:57:04 Xl2JqkE7
('A`)
364:nobodyさん
08/10/28 01:00:04
ごめん。
>>358の真意が知りたい
365:nobodyさん
08/10/28 01:05:19
>>364
こちらをどうぞ
URLﾘﾝｸ(blog.ohgaki.net)
366:nobodyさん
08/10/28 01:14:15
>>365
thx
('A`)
367:nobodyさん
08/10/28 01:57:07
一応聞くけど、バックスラッシュだよね？\じゃないよね？
368:nobodyさん
08/10/28 02:03:16
>>367
あんたの環境でどう見えてるかは知らんｗ
2chを通したせいかも知れんが、あんたのレスの\と同じものだろ？
ASCIIで0x5cとも言う・・・っていうとなじみ深い気がして嫌だｗ
369:nobodyさん
08/10/28 02:07:06
thx
0x5cならおｋ
>>365 のリンク先がUTF-8なのにもかかわらず、
円マークになってたから気になった。
370:nobodyさん
08/10/28 02:14:58
>>369
ああ。本当だ。その記事はU00A5で書かれてるね。てかブログの仕様？
俺もその記事しか見なかったから、確かなことは言えないけどｗ
・・・まあぶっちゃけASCII or Latin-1 以外を奴ら（誰？）に強制できる
わけもないので、￥マークってのはありえない、はず！
ソースコードUTF-8強制とかなら、むしろ嬉しいかもだけどな！
371:nobodyさん
08/10/28 02:17:35
てか、この記事が壮大な釣り？
372:nobodyさん
08/10/28 02:24:27
一応こっちもどうぞ？
URLﾘﾝｸ(wiki.php.net)
誰か訳してｗ
373:nobodyさん
08/10/28 02:55:29
へーutf-8って\とバックスラッシュが違うコードなの？
374:nobodyさん
08/10/28 03:01:39
>>373
URLﾘﾝｸ(www.penlabo.net)
375:nobodyさん
08/10/28 03:12:19
ちょっと事実誤認があるかな。俺も詳しくないけど。
u00A5(？)は、ISO-8859-1(Latin-1)にこそ、ある文字だ。
本来の意味での、円通貨を表すシンボル？
と言うわけで、>>370の安心は、その理由ならちょっと早いｗ
もちろん、実際PHPの仕様としてそんな訳は無いだろうけどｗ
376:nobodyさん
08/10/28 09:24:12
PHPってパーサーが弱いよなあ。ちょっと複雑なプログラムでバグがあると、php -l でエラー行検出出来なかったりするからな。
377:nobodyさん
08/10/28 12:01:56
そらぁ構文エラーだけだから、複雑なシステムのバグってんなら
lintじゃぁ出ないエラーの方が多いだろう。
構文エラーが出るのは大抵の言語で括弧とかクオートの閉じ忘れくらい。
/.で、PHPがこの惑星で一番アホなプログラム言語とか書かれて
ちょっとかわいそう。しかもInsightful: 5だし。
海の向こうのGeekもPHPはお嫌いなようで。
378:nobodyさん
08/10/28 19:56:14
まあPHPがよく使われているって証拠でもあるよな。
オープンソースのウェブアプリは
ほとんどPHPだし。
379:nobodyさん
08/10/28 20:00:13
>>378
phpがよく使われているのは事実だが、
何が言いたいのかよくわからない
380:nobodyさん
08/10/28 20:07:39
>>378
そういうのをPHPERの遠吠えって言うんだよｗｗ
m9（＾Д＾）ﾌﾟｷﾞｬｰ
381:nobodyさん
08/10/28 20:24:18
アホなプログラム言語とか言う行為こそ遠吠えだろう。
382:nobodyさん
08/10/28 20:35:27
名前空間の区切りにバックスラッシュをつかうなんてのは実際 retarded だろうよ。
383:nobodyさん
08/10/28 20:39:58
日本語で書け
384:nobodyさん
08/10/28 20:45:16
日本語不自由な人なんで勘弁してあげてください
385:nobodyさん
08/10/28 21:21:52
名前空間の区切りに逆斜線をつかうなんてのは実際 retarded だろうよ。
386:nobodyさん
08/10/28 21:26:37
ディレクトリだって、斜め線なのに？
387:nobodyさん
08/10/28 21:27:12
いっそスラッシュでよかったんじゃまいか
388:nobodyさん
08/10/28 21:27:44
いやだめか
389:nobodyさん
08/10/28 21:41:50
::じゃだめだったん？
390:nobodyさん
08/10/28 21:46:17
だめだったん。
391:nobodyさん
08/10/28 21:52:07
なんであかんの？
392:nobodyさん
08/10/28 21:54:43
せめてちょっと前のリンク先だけでも読んでくれ
393:nobodyさん
08/10/28 22:52:01
こっちには、他の候補？もあるのかな
URLﾘﾝｸ(wiki.php.net)
でも (5) number of chars は基準としてどうなんだｗ
# とか候補に挙がらなかったのかな？バックスラッシュより遙かにマシだと思うんだけど。
どうせ # でのコメントは非推奨だったんだし、使ってる奴なんて極少数だろうし
394:nobodyさん
08/10/28 23:34:09
互換性が・・・
395:nobodyさん
08/10/28 23:43:35
中途半端に互換性なくなるくらいなら
完全に無視してちゃんと作ったほうがいいよね
396:nobodyさん
08/10/29 00:08:59
:=でいいやん
397:nobodyさん
08/10/29 00:58:53
：：
398:nobodyさん
08/10/29 01:17:59
>>397
それは却下されたんだよ
399:nobodyさん
08/10/29 02:00:15
バックスラッシュはなんだかなぁ。
400:nobodyさん
08/10/29 02:39:33
今まで通り、細かい互換性なんぞ無視してしまえばいいんだｗ
というか、現行の :: と -> の区別って必要なの？
メンバアクセスは全部 -> にしてしまえば、:: が使えるじゃない！
修正も多分、検索・置換でそれほど手間じゃなさそうだし
たかが名前空間って考えると、本末転倒な気もするけど
401:nobodyさん
08/10/29 02:56:57
スキーマのデータを毎回dbから取得するのと、
取得したデータをファイルにキャッシュしておいて随時読むのと、
どっちがコスト低いですか？
402:nobodyさん
08/10/29 02:59:03
スキーマのデータが分からんとDBにアクセスできんだろ
403:nobodyさん
08/10/29 03:12:12
スキーマのデータって何を指してるんだ？
404:nobodyさん
08/10/29 03:18:43
カラムの型データです
405:nobodyさん
08/10/29 03:39:09
どんなDAOを使ってるか知らないけど、
テーブルにどんなデータ型のカラムがあるかなんて取得する？
PropelとかDoctrineは定義ファイルを書くけど。
よくわからないけど、毎回DBから取得するより、
ファイルから取得した方が、普通に考えてコスト低いと思う。
んーなんか見当違いかな。
406:nobodyさん
08/10/29 08:12:34
code igniterを参考にしたオリジナルのdaoです
やっぱり、普通はファイルアクセスの方が速いですかね・・
407:nobodyさん
08/10/29 10:14:23
どうせカラム型なんかはメモリにキャッシュしてるだろうし
そんなに変わらないっつーかファイルに書くより早いかもね。
パフォーマンスが問題ならベンチして決めるしかないでしょ。
メンテ込みなら、自動的にカラム型を読み込むのは便利。
408:nobodyさん
08/10/29 15:12:56
DBからロードするって事は大抵はなんかしら変更の可能性があるデータってことだろうし
キャッシュを作成するとなると常時最新でなくなる可能性が出るんじゃないの？
更新タイミングとか考えたり余計な手間が増えるだけ
逆に、変更がめったに行われないとかってわかってるものなら、ただの定数
ハナからDBに保存しておく必要なくね？
つか、なによりまずスレ違いだ
409:nobodyさん
08/10/29 15:34:43
>>408
>>407で言っているのは、DBサーバはカラム型をメモリに置いているはずだということ。
つまりDBに問い合わせればディスクには読みにいかないだろうと言う読み。
付け加えると、SQLiteにしても、スキーマ情報はDBをオープンした後黙っても読まれるはずで、
それをメモリから取り出すだけだからいちいちファイルに書いとくのはどうよ、ってこと。
410:nobodyさん
08/10/29 16:45:25
>>377
エラーは検出するけど、何行目のエラーか検出できないんだよ。そんなのPHPだけだと思う。
411:nobodyさん
08/10/29 18:14:15
$ php -l <<EOF
<?php
echo "hello";
fuga();
foo();
();
?>
EOF
Parse error: syntax error, unexpected ')' in - on line 7
Errors parsing -
なんか出てる気がするよ?
412:nobodyさん
08/10/29 18:23:29
複雑になると出ない場合があるんだよ。
前にmatzがPHPのAPCが何でそんなに効果的なのか理由が分からないって言ってたけど、あれは単純にPHPの構文解析の性能が悪いからって理由だと思う。
413:nobodyさん
08/10/29 20:06:51
>>400
> というか、現行の :: と -> の区別って必要なの？
PHPに->ってあったっけ？
414:nobodyさん
08/10/29 21:03:04
->がPHPみたいなもんだろ
415:nobodyさん
08/10/29 21:15:12
＞PHPに->ってあったっけ？
え？
416:nobodyさん
08/10/29 21:38:30
->は好かん.がよい
417:nobodyさん
08/10/29 22:03:57
->は好かんがよい、に見えた
418:nobodyさん
08/10/30 02:18:50
そろそろPythonを勉強する時期かな？
419:nobodyさん
08/10/30 02:22:17
レンタル鯖で普通に入ってないやつなんて
学ぶ必要はないんだ
420:nobodyさん
08/10/30 03:20:43
どれか１つの言語でもちゃんとやっときゃ
他の言語なんてやる気になりゃ出来る
421:nobodyさん
08/10/30 08:03:13
>>420
できればその１つがPHPではない方が、幅は広そうだがｗ
422:nobodyさん
08/10/30 16:05:21
たしかにプログラムの基礎練習としてはやっぱ向かないよなｗ
まだ改修段階にあるってかんじで、他の言語で当たり前に出来ることが出来ないってのがむずむずするｗ
423:nobodyさん
08/10/30 16:14:12
その代わりほかの言語では、めんどくさいことが
さくっとできるんだぜ。
file('URLﾘﾝｸ(example.com)');
とかな！
ほんとダメな言語。
424:nobodyさん
08/10/30 16:39:09
きゃーすてき！
425:nobodyさん
08/10/30 16:56:50
>>421
実際はそうでもない。
例えばperlやpython、rubyから入るよりは、
phpから入ったほうがjavaやC++は覚えやすい。
まぁ古臭いってことなんだが
426:nobodyさん
08/10/30 18:09:36
安いレンサバの代表格のXREA、Xserver等には、Python、Rubyも入ってますな＾＾
RoRで一世を風靡したRubyをあえて選ばずに、Pythonを始めるのが通の嗜み？
427:nobodyさん
08/10/30 21:55:43
XREAを選ぶ奴の気が知れないよ
428:nobodyさん
08/10/30 21:58:07
ロリポップやヘテムルならいいのか？
429:nobodyさん
08/10/30 22:38:46
Rubyは知らんがPythonなら入ってるサーバは、最近だとそれなりにあるきがする。
430:nobodyさん
08/10/31 09:24:51
Railsもmod_railsというかPassengerの登場でPHP並に管理が楽になった感じだし、
これからは選べるようになるかも。
431:nobodyさん
08/10/31 13:33:41
変数型を気にする必要の無い言語から始めると取り掛かりやすいけど
いざ型がある言語に移るとき、ちゃんと理解しきれてないと苦労しやすいってのもあるから
PHPを最初に覚えるってのはちょっとオススメしないかもだなｗ
まぁ、触れやすいこと、覚えやすいことを重視したほうがスタートしやすいし、
やりたい事にもよるから一概には言えないと思うけどね
432:nobodyさん
08/10/31 13:47:03
変数型が無いPHPは
余計な心配が増えてよくない
433:nobodyさん
08/10/31 13:56:53
PHPをちゃんと理解すればPHPにも型があるって分かるはずだから問題ないだろ
434:nobodyさん
08/10/31 16:12:42
railsも深く知るほど「簡単」とはとてもいえないものだと分かってくる
railsを速く動かすソリューションを安定して稼働させるにはスキルがいるし、
スレッドセーフかそうでないかということも気を遣わなければいけない。
435:nobodyさん
08/10/31 16:17:00
Railsの中でスレッドなんて使ってるの？
少なくともFastCGIやらの同時起動なら、プロセス別じゃないの？
よくわかってないけど
436:nobodyさん
08/10/31 16:56:15
型とかの概念はプログラム覚えるなら最初のうちにやっといたほうがいい気はする
437:nobodyさん
08/10/31 17:05:48
まぁほんとに初めてがphpはあかんわな
でも普通は学校で最初にcやpascalやったりするんじゃないの？
438:nobodyさん
08/10/31 17:07:22
いいかげんフレームワークの話をしましょうよ。
439:nobodyさん
08/10/31 18:31:35
PHPは変数のスコープが関数単位というのがなんとも。
440:nobodyさん
08/11/01 04:31:36
配列すら参照渡しになるJavaScriptはPHPより糞
しかもcloneメソッド標準装備してないし
441:nobodyさん
08/11/01 11:07:00
===
442:nobodyさん
08/11/01 19:01:05
>>427
せめてどこなら良いか提示してからそういうこと言おうな
443:nobodyさん
08/11/01 20:20:40
XREAなんでだめなの？
444:nobodyさん
08/11/01 22:22:08
xreaだからだろ
445:nobodyさん
08/11/01 23:40:57
理由なんかないだろ。なんでも否定したくなる年頃なんだよ。
中学生とかおっさんとか。
446:nobodyさん
08/11/02 00:36:25
お前らxreaなんか使うレベルなんか・・
447:nobodyさん
08/11/02 02:51:59
xreaがダメな理由なんてちょっと調べたり確認すればわかるだろ…
そんなことも説明されないとわからないのか…
448:nobodyさん
08/11/02 02:54:45
話に全然信憑性無いわ
449:nobodyさん
08/11/02 03:43:51
まぁそういうやつはXREA使っとけばいいんじゃねｗ
サポートがだめすぎるけど、運よくトラブルに会わなければ、
まぁ安い金額で使えるし。
たまに、coreserverの方にxreaの設定を上書きして、
coreなのにXREA相当にしちゃったり、
mailmanがバグだらけでまったく機能しなかったり、
ほかにも色々トラブルおこしてるみたいだけど。
俺はxreaスレやcoreserverスレ読んだら、怖くて仕事には使えなくなった。
450:nobodyさん
08/11/02 03:46:29
てかxreaって何につかうの？個人サイト？
なんでフレームワークスレでxreaが出てくるのか謎
451:nobodyさん
08/11/02 06:29:42
なんでxreaがだめか教えてやろう。
それは安かろう悪かろうだから。
まあ常識で考えて安いところにろくなところはない。
俺が使っているところ。おすすめだから教えてやろうか？
今ならキャンペーン中だからお得だぞ。
452:nobodyさん
08/11/02 06:54:51
>>449
>>442
453:nobodyさん
08/11/02 07:07:41
凝った機能盛り込んだ個人的なブログ設置するのに、
わざわざ高いサービス選ぶ必要あるか？
xrea程度でも手軽に試せるものの方が、ユーザも増えて
ノウハウも蓄積するだろ。
>>446とか頭悪すぎるな
454:nobodyさん
08/11/02 07:15:59
個人ブログといっても財産ですからね。
財産をそんな簡単に盗まれてしまうところにおいておきますか？
おいておかないでしょう？
それでなくぐらいなら、ちょっとの費用で
安心を得られるほうを選びませんか？
そんなに気になるのなら私が使っているサーバーを教えてあげますが。
455:nobodyさん
08/11/02 09:05:42
>>452
使いたいのならどうぞ。
XREAはやめといたほうがいいという、ただの忠告だから、
参考にするしないは自由だよ。
俺はさっき書いた理由で使わないけどｗ
456:nobodyさん
08/11/02 10:56:50
>>453
あのサービスに不満がないならそんな噛みつかなくてもいいと思うよ
457:nobodyさん
08/11/02 12:05:53
>>449
xreaを仕事で使う馬鹿なんていたの？
サーバ運用するにもお金がかかるって知ってる？
458:nobodyさん
08/11/02 16:19:37
Symfonyて結構バグあるの？
CakePHPカンファレンス東京のレポート読んでたら、
そんなような記述があったんだが。
あまり詳しく書いてなかった。
459:nobodyさん
08/11/02 17:46:21
>>457
俺はプライベートでも勘弁だがｗ
460:nobodyさん
08/11/02 19:53:56
なんかxreaに仕事を奪われた
サーバー屋が裏工作しているみたいですねｗ
461:nobodyさん
08/11/02 20:59:33
正直お小遣い稼ぎの趣味サイトならxreaで十分だしな～
462:nobodyさん
08/11/03 04:52:26
>>458
まぁ細かいのはそこそこある。
ZFもsymfonyも、あれだけ規模がでかけりゃバグチケットが増えるのは当然。
あんまり比較の際の根拠にはならないな。
463:nobodyさん
08/11/03 17:39:38
>>451
>>454
おすすめサーバ教えてくれ
464:nobodyさん
08/11/03 19:52:45
他所でやれ
465:nobodyさん
08/11/04 17:33:27
symfonyはsubversion拾ってればわかるけど、1時間数十以上のファイルが修正されてるからな。
バグがあっても修正も早い
466:nobodyさん
08/11/05 06:01:16
1時間数十以上 = 一日数百以上 = 一週間数千以上 = 一ヶ月数万以上
一ヶ月数万以上って本当ですか？
467:nobodyさん
08/11/05 07:54:12
なんとも恐ろしいフレームワークだ
468:nobodyさん
08/11/05 09:38:54
>>466
本当だよ。subversionでチェックアウトしてみなよ
469:nobodyさん
08/11/05 11:13:18
Tracをみる限り、一日あたり10から30コミットというところ。
コミット一回につき、いくつかのファイルを触るだろうから、一回の変更の
影響範囲が大きい場合、ピーク時には一時間数十ファイル更新は充分ありうるが、
これがコンスタントに続くことはないでしょ。
まぁコミットはいっぱいあってもバグチケットをcloseするコミットは少ないように見えるが。
でも開発ブランチはこんなもの。
470:nobodyさん
08/11/06 16:26:58
CIって、早い分cakePHPやsymfonyと比べどんな機能が足りないの?
471:sage
08/11/06 19:26:19 W2KYlXPe
>>470
やさしさ
472:nobodyさん
08/11/06 19:35:59
>>470
痒いとこ
473:nobodyさん
08/11/07 09:14:59
>>470
モデルまわりは弱いと思った。
DBにselectした結果が配列なんで、そこがちょっと使いづらい。
あとバリデーションまわりはなんか不思議な仕様。もっとよくなりそうなもんだけど。
474:nobodyさん
08/11/07 19:13:25
>>472
痒いところってどの辺?
475:nobodyさん
08/11/07 20:22:58
ドクトリンってcodeigniterのパクリだろ？
476:nobodyさん
08/11/07 21:18:22
>>23って俺が昔別のスレに書いた質問だったと思うんだけど
何でこんなとこに記載されて議論が発生してるんだｗ
477:nobodyさん
08/11/07 21:20:39
ところでcakePHPのパフォーマンスの悪さは改善されてないのかな？
478:nobodyさん
08/11/07 21:22:48
>>477
RC3は使ってみた？
479:オリジナル23
08/11/07 21:27:02
>>23の質問を昔別スレに書いた本人だけど
結論としては、
・スタティックな方法では使う側も唯一性を意識しなければいけない
・シングルトンであれば使う側は唯一性を気にする必要が無い
と言うのが最も大きい違いだと思ってる。
要するに、シングルトンで書いておけば後からシングルトンじゃなくする時に
参照してる側は書き換えなくても良いって事。
抽象的に言えば、オブジェクトの特性である唯一性というものをカプセル化出来るということ。
480:nobodyさん
08/11/07 21:31:03
>>478
使ってませんが、ベンチ等で良い結果を出してるんですか？
>>15のような結果だとさすがに使えないので。
481:nobodyさん
08/11/07 21:34:48
自分で確かめることって大事
482:nobodyさん
08/11/07 21:37:02
時間がないんで
483:nobodyさん
08/11/07 21:37:33
こんなところに書き込んでる暇があるなら
484:nobodyさん
08/11/07 22:45:30
そりゃ自分でベンチマークとるよりは、ここに書き込む方が楽だし時間もかからないだろう。
485:nobodyさん
08/11/08 00:11:03
んな他力本願のやつに情報提供してくれる人がいる確率考えると
結局自分で調べたほうが結果がわかるのは早いと思うけどなｗ
486:nobodyさん
08/11/08 00:20:53
>>469
1.0=>1.1=>1.2と常にこの状態が続いています
487:nobodyさん
08/11/08 01:28:22
個人がつくってるのを見るのが好きだ
488:nobodyさん
08/11/08 01:29:27
おっとMapleに鞭打つのはやめるんだ
guessworkとか言うのももうやめるんだ
489:nobodyさん
08/11/08 01:37:07
>>479
まてまて
23は俺だがコピペじゃないよｗ
偶然同じ疑問を持っただけ
490:nobodyさん
08/11/08 01:38:31
cakePHPなんてドジでのろまな亀しか使ってないだろ
491:nobodyさん
08/11/08 02:29:27
>>479
出来ることは同じだけど、
唯一なものを唯一なものと知って使うのと、
唯一なのかインスタンスを複数作れるのかわからないけど、
普通に使えば唯一になってる、
の違いってこと？
ちょっとくどい聞き方かもだけど、ちゃんと確認したくって聞いてみた。
492:nobodyさん
08/11/08 03:23:29
>>490
本気でそう思うなら相手にしなきゃいいだけなのにw
493:nobodyさん
08/11/08 06:24:48
cakePHP 1.2のRC3は
”パフォーマンス改善中”と明確に言われている。
cakePHPの開発スタンスは、まず動くものを作る→リファクタリング（パフォーマンス改善含む）
494:nobodyさん
08/11/08 06:54:44
オープンソースで儲けるのって
サポート事業しかないのか？
495:nobodyさん
08/11/08 07:47:16
オープンソースは広く使ってもらっていると言う土壌を得る事がまず目的
広く使われればサポート事業や周辺ソフトが売れる
496:nobodyさん
08/11/08 08:04:00
実際に動くコードが重要なわりに
そのコードを作っても儲けられない。
それがオープンソースｗ
せっかく土壌を作っても
サポートや周辺ソフトや関連書籍を
他の人が提供して売り上げを持っていかれる。
それがオープンソースｗ
497:nobodyさん
08/11/08 12:36:54
いまだにオープンソースでガッツリ儲けようなんてプランのところがあるの？
本当に基幹的なDBとかhttpdとかならともかく
498:nobodyさん
08/11/08 13:25:19
ガッツリってのはいくらぐらいなのかな。
それにもよるだろうが、儲けるかどうかは才覚の問題。
OSSかどうかは関係ないだろうな。
499:nobodyさん
08/11/08 14:46:39
お金の名言
「タダほど高いものはない」
500:nobodyさん
08/11/08 16:19:59
タダほどお得なものはない
501:nobodyさん
08/11/08 17:38:16
>>499
ApacheやらLinuxやら使ってて「高くついた」って感じたことはないなあ。
むしろ安い労働力まで付いてきて、お得感しかないのが大多数では？ｗ
もちろん、大規模に「ガッツリ」儲ける分野では違うんだろうけど。
502:nobodyさん
08/11/08 18:55:54
中・小規模向けのフレームワークって何が良い？
cakeはどうもパフォーマンスが悪すぎて嫌なんだよねえ
503:nobodyさん
08/11/08 21:49:38
中・小ならEthnaでいいんじゃないの。
CIという手もあるが。
504:nobodyさん
08/11/08 23:30:51
ご冗談でしょう
505:nobodyさん
08/11/09 05:48:00
Ethnaとか、未だに選択肢に残ってるのかな？
仕事で昔触ったときに、いろいろドン引きした記憶があるんだが。
アクションを準備していないURL指定すると「全ファイル」のrequireを
し始めてプチDOSアタックになってしまう自前オートロード（笑）とかｗ
506:nobodyさん
08/11/09 09:19:25
大規模ならCI or ZFのチョイスってことでFA?
507:nobodyさん
08/11/09 11:56:58
CIってPHP4にも対応しててコードに無理が出てるみたいな話も聞くんだけど
大規模で使えるようなものなの？
小規模にしてもcakeとどっちが楽なんだろう
508:nobodyさん
08/11/09 13:41:32
ドッチかと言われればcakeだろ
でもcakeもイマイチなのはよくわかる
509:nobodyさん
08/11/09 14:55:46
ciで大規模はきつい
そういうふうには作られていない
510:nobodyさん
08/11/09 15:03:14
だよね
低機能だし
だからこそある程度自分達で実装しやすい面もあるから
逆に大規模での需要はありうるけど
かといって小規模でもCIはどうなんだろう
軽量なのは良いんだけど
511:nobodyさん
08/11/09 16:23:48
>>496
儲けなくても、一度つぶれた会社が
オプソで蘇ってうまくいってるケースはある
512:nobodyさん
08/11/09 16:25:12
オープンソースは技術的には最良の手段だよ
利益に繋げられるビジネスモデルを考えられるか、実行出来るかが問題
513:nobodyさん
08/11/09 19:20:35
そこが最大の問題だと思う。
ぶっちゃけメシ食えなきゃしょうがない
514:nobodyさん
08/11/09 19:27:31
オープンソースにかかわってるエンジニアがこれほどたくさんいるという事実は
形は違えど、オープンソースで稼げるってことの裏返しじゃないかと思うのは甘い？
515:nobodyさん
08/11/09 19:29:10
でも市場取らないとどうにもならない面もある
もしオープンソースな製品が何一つ無い分野があったら、オープンソースな製品を立ち上げる事で
その分野で一気に市場を奪える可能性がある
516:nobodyさん
08/11/09 20:01:09
>>513
gimpにしてもblenderにしても、オプソで生活してる開発者はいくらでもいる。
お前みたいな無知が日本には多いから、ボランティアみたいに見られるのは
しょうがないと思うけど。
517:nobodyさん
08/11/09 23:36:37
日本ではあまり話を聞かない気がするけど・・
518:nobodyさん
08/11/10 01:02:25
しかもFWの話で画像系とか3D系はちょっと実感わかないかも
519:nobodyさん
08/11/10 10:55:17
携帯サイト向けの機能も持ったフレームワークってあるの？
520:nobodyさん
08/11/10 11:15:09
DeNAのMobaSiFみたいなものってPHPでは聞いたことないなぁ
521:nobodyさん
08/11/10 15:28:02
携帯サイトって出力を携帯むけにするだけじゃないの？
なんか特別に機能必要け？
522:nobodyさん
08/11/10 15:29:05
セッションとかＰＣと同じじゃ動かないんだよ
そのほか端末識別番号の取得やらいろいろある
523:nobodyさん
08/11/10 16:04:14
そうそう。まともにサービスを開発したことがあったら、
携帯対応ほど煩雑なものはないと思えるよ。
キャリアと機種によって全然違う挙動するからね。
セッションもレイアウトも画像も。ま、小さいところでは絵文字とか。
524:nobodyさん
08/11/10 16:05:21
機種によって動かなかったりするからテストもコーディングも面倒
525:nobodyさん
08/11/10 16:55:03
KEMPは?
KEMP
ke-tai.org
URLﾘﾝｸ(ke-tai.org)
526:nobodyさん
08/11/10 17:07:31
それはＰＣ携帯両用サイトじゃなく携帯サイト作成のためのフレームワークっぽい
527:nobodyさん
08/11/10 17:09:27
両方できるものが欲しいのか
すまそ
というより両方やろうとしている時点で間違っていると思う
小規模、小機能ならありえるけど
528:nobodyさん
08/11/10 17:15:23
両対応サイトであったとしても別物と考えよ
529:nobodyさん
08/11/10 17:24:25
KEMPとやらはPHP5で動かない
携帯とＰＣで別フレームワークを使うとしたら
共通の機能を変更した場合どうすんの？
530:nobodyさん
08/11/10 18:47:01
セッション動かないのはクッキーがないからだろ？
単にget引数方式にしたらいいだけじゃないの？
531:nobodyさん
08/11/10 19:02:38
>>529
当然それぞれ変更する
532:nobodyさん
08/11/10 19:04:27
>>530
リファラーを送っちまう機種でそんなことしたら、セッションハイジャックされるべ
533:nobodyさん
08/11/10 19:05:00
実際携帯サイト向けのソリューションはいくつかあるんだけど
国内では情報少ないね
534:nobodyさん
08/11/10 19:10:08
>>530
POSTフォームだとACTIONに指定したパラメータを送らないっていう機種もあるしな
そういう機種ではPOSTフォームでセッションを維持できない。
535:nobodyさん
08/11/10 19:23:29
結局機種判別をして処理振り分けるような事をする必要があるんだよね
536:nobodyさん
08/11/10 19:35:22
URLﾘﾝｸ(gihyo.jp)
ここに書いてあるのでもまだまだ序の口だな。間違ってるとこもあるし。
いまんとこ、オープンソースだとMobaSiF最強じゃないかな。
537:nobodyさん
08/11/10 19:47:32
携帯の文字コードは、そろそろUTF-8統一でいいんでしょうか？
538:nobodyさん
08/11/10 19:48:52
結局そういうのは自分とこで作るしかないんじゃね
539:nobodyさん
08/11/10 19:54:03
>>536
Perlじゃん
>>538
別に汎用的な機能だから広く使われるものが無い現状が異常
携帯関連開発の低レベル差だと思う
540:nobodyさん
08/11/10 20:24:13
うん。perlなんだけどさ。
スレチ承知であえて、携帯だけはPerlでって思えるぐらいの完成度だと思う。
541:nobodyさん
08/11/10 21:08:55
だいたい携帯は規格が無さ杉なんだよ
ＯＳも別々のが乗ってるし
エンドユーザーにとってメリットがある事じゃないんだが、不経済だなあ
542:nobodyさん
08/11/10 22:50:10
>>541
それと、各社・各世代仕様のまとめ情報が少なすぎる。
ググれば出てきそうなクッキー仕様や対応文字コード等の情報が、ほとんど無い。
会社で仕事なんかでは資料を作るんだから、暇な自営業者あたりが自分メモで
作ってても良さそうなもんなんだが。
フレームワーク辺りと違って、いじって面白くないのと、商売上公開したくないって
のと、その他もろもろ理由はあるんだろうけど。
543:nobodyさん
08/11/10 22:58:35
Androidに期待
544:nobodyさん
08/11/10 23:09:02
携帯はフルブラウザで見る以外は廃止にすべき
545:nobodyさん
08/11/10 23:39:13
MobaSiF読んでPHP用携帯FWを作るプロジェクトとか
546:nobodyさん
08/11/11 00:37:30
そもそも初期のｉモードなんかの仕様がダメ杉
547:nobodyさん
08/11/11 02:17:34
>>545
PerlのコードをPHPのコードに変換するジェネレーターがあれば、簡単に移植できるかな？
548:nobodyさん
08/11/11 02:22:07
URLﾘﾝｸ(oshiete1.goo.ne.jp)
Perlコードを、自動的にPHPコードに変換してくれる、そんな「ドラえもん」のようなプログラムがありましたら教えて下さい！
無いですねえ。
URLﾘﾝｸ(www.cs.wcupa.edu)
Perl/Php Translation
549:nobodyさん
08/11/11 07:51:48
そういやperlで思い出したけど
PHP on parrotて進んでるんでしょうか？
550:nobodyさん
08/11/13 08:51:01
>>540
Perlの事情あまりしらはい。ﾗｲﾌﾞﾗﾘのどういうとこが携帯向き?
551:nobodyさん
08/11/13 10:31:16 kdvrTOAA
で、肝心のフレームワークなんだけど
結局今熱いのってなんなの？
いっぱいありすぎていまいちこれっていう特徴あるやつ
ないんだよな～
最近ちょっとさわってみようかな～って思ってるのあるんだけど
誰かいじったことある人いたら所感教えて～
PAJAJ
URLﾘﾝｸ(pajaj.sourceforge.net)
xFrameworkPX
URLﾘﾝｸ(px.xframework.net)
552:nobodyさん
08/11/13 14:00:08
PRADOみたいなイベントドリブンなのはどうなんだ
553:nobodyさん
08/11/13 16:16:39
ちいたんでいい
554:nobodyさん
08/11/13 23:25:55
やっぱり落ち担当w
555:nobodyさん
08/11/13 23:27:41
もうちょっとふくらませてからｗ
556:nobodyさん
08/11/13 23:41:23
いやらしい
557:nobodyさん
08/11/14 13:45:00
大規模向けのFWはどれ?
558:nobodyさん
08/11/14 13:52:53
ちいたん
559:nobodyさん
08/11/14 13:53:13
出ると思ったｗ
560:nobodyさん
08/11/14 14:12:00
ちいたん以外で
561:nobodyさん
08/11/14 14:31:47
Symfony
Cake
562:nobodyさん
08/11/14 14:34:00
あれ?遅いとか叩いてなかったっけか?
なぜ大規模向けと?
563:nobodyさん
08/11/14 14:42:11
軽量なフレームワーク≒自由度が高い≒多人数開発では混乱を招きやすい
(重量級フレームワーク=動作が遅い)≒自由度が低い=開発のルール化度が高い≒多人数でも均一なコードレベルを保ちやすい
とはいえ、フレームワークが案件に合う合わないもあるので、
どのフレームワークを使っても、大規模開発ならプロジェクトのルールが必要だと思われ。
逆を言えば、ルールさえ作れば軽量なフレームワークでもいいと思う。
重量級フレームワークが用意してくれる機能を、自分達で実装しないとならないけどね。
あと、大規模=多人数と勝手に解釈したけど。
564:nobodyさん
08/11/14 14:50:52
数年がかりの本当に大規模なものなら
逆に自由度が高いフレームワークを使って自分たちで実装したいって需要もかなりある
565:nobodyさん
08/11/14 15:31:36
>>564
開発期間が数年？PHPでそんな案件はほとんど無いけど。
あと、それを適当にやると、どんどん「フレームワーク」自体に修正が入ってしまって、地層のように
古いコーディングとより新しいコーディングがどんどん積み重なって手に終えなくなる。
やるなら、全くいじらないか、最初にきちんと徹底的にいじって固めてしまうのがいいのかな？
566:nobodyさん
08/11/14 16:00:34
１年未満じゃ大規模とは言えないし
567:nobodyさん
08/11/14 16:19:50
webアプリで開発に何年もかかってちゃビジネスになんね。
568:nobodyさん
08/11/14 16:22:17
PHPはインタフェース部分を担当するに過ぎないから
プロジェクト全体で数年っていうのはあるよ
複数サイトを作るような事業でも共通フレームワークを作成することはあるし
569:nobodyさん
08/11/14 16:31:35
単純にスピードを比較したものがよく出るけど、あまり意味無いよな。
しかも素の状態に近いベンチとか。
もちろん非常にシンプルに作りたいときにFWの軽さは重要かもしれないけど。
色々な機能を実装するなら、結局ある程度の重さにはなるだろうし。
だったら多少重いといわれる高機能FWを使用したほうが開発効率は良いと思う。
単純なスピード比較がよく話題が出るから、疑問に感じていた。
570:nobodyさん
08/11/14 16:52:52
何が言いたいのかさっぱりだ
帰れ
571:nobodyさん
08/11/14 22:44:45
必要な機能に一番近いものを使えばいいねん
多すぎず少なすぎず
572:nobodyさん
08/11/14 23:35:14
それがベストだけどちょうどいいFWってそうはない気も。
まぁ、一番近いものを選べばいいが
573:nobodyさん
08/11/14 23:36:59
フレームワークなんて多機能な奴はほとんど一緒だけどね
パフォーマンスくらいしか差が無い気が
574:nobodyさん
08/11/14 23:49:38
大規模の意味は100万ユーザ以上が使うというアクセス数の意味で
開発の工数ではなかったけどためになった
アクセス数という意味では軽量かどうかが非常に重要と思われ
サーバの台数などのメンテナンス代が高くつくから
とはいえ重量級のものを使ってあとからプロファイリングして
リファクタリングなりすればいいような気もしてきた
575:nobodyさん
08/11/14 23:58:04
必要な機能なら実装しなきゃならないんだから
効率的な実装になってるならいいんだけどね
cakeは実装が酷いよ
576:nobodyさん
08/11/14 23:59:29
cakeはインターフェイスが全てだからじゃん
その辺までRailsを踏襲していると言えばそうかも
577:nobodyさん
08/11/15 02:26:07
ウェブアプリで、大規模って言うと、アクセス数が多いって意味で使われることが多いんじゃないかな。
でも、それってフレームワークはあんまり関係ないよな。ハードウェアスペックとか、もっと低いレイヤーの問題であって。
PHPに限らずウェブサイトの開発で数年かけるなんて、まず有り得ないと思う。官公庁のサイトで、手続きが面倒とかでない限り。
GmailとかGoogle Mapsでもそこまで行かないでしょう。まして、よくあるショッピングサイトやSNSみたいなのに1年も時間使ってたらアフォだよ。
578:nobodyさん
08/11/15 02:37:10
アクセス数の多さはフレームワークのスレで大規模にあたらないだろ
１ページだけのHTMLを出力するサイトでも大量アクセスがあれば大規模なのか？
俺は普通コード量とか機能数だと思うけど
579:nobodyさん
08/11/15 02:38:10
Googleは独自のフレームワーク作ってそうだけどね
てか絶対作ってる
他にも大企業は手の込んだ事やってそうだけどなあ
580:nobodyさん
08/11/15 02:50:13
ウェブアプリで機能の数って言っても、単に画面を増やしていくだけだからなあ。
mixiとかamazonとか、確かに画面数は多いけど、結局のところ、掲示板作るのと変わりはない。
ユーザからの入力を受け取って、何枚かのテーブルを更新して、テーブルをSELECTしなおして、文字列を加工してHTMLに埋め込むって言う。
これをひたすら繰り返して巨大化するだけ。
581:nobodyさん
08/11/15 02:53:39
機能によっては違うこともあるんじゃないか。
ユーザからのデータを何かしら加工するとか、
なにか特別なアルゴリズムでデータを収集して、
それを提供するとか。
582:nobodyさん
08/11/15 03:02:01
ＷＥＢＡＰＩの提供に際する共通機能とか
自動的にＤＢを保守してくれたりＨＤＤ壊れたらバックアップの方へ自動的に繋いで新たなバックアップ先を作るとか
（ＰＨＰコード内の接続先ＤＢサーバＩＰが動的に変わるって事ね）
思いつきで書いた
583:nobodyさん
08/11/15 04:39:48
ウェブアプリで大規模とそれ以外の境目はウェブアプリ側がスケーラビリティを気にする必要があるかどうかだと思う。
584:nobodyさん
08/11/15 05:03:15
>>580
> ウェブアプリで機能の数って言っても、単に画面を増やしていくだけだからなあ。
> mixiとかamazonとか、確かに画面数は多いけど、結局のところ、掲示板作るのと変わりはない。
> ユーザからの入力を受け取って、何枚かのテーブルを更新して、テーブルをSELECTしなおして、文字列を加工してHTMLに埋め込むって言う。
> これをひたすら繰り返して巨大化するだけ。
それはウェブアプリだからではなく、SNSやオンラインショップという
システムが、そうなっているってだけだろ。
たとえば、YouTubeのようなウェブアプリではエンコード技術が使われる。
585:nobodyさん
08/11/15 05:05:22
それにウェブじゃないシステムが何をしているかというと、
結局、ファイルにデータ読み書きして、画面に点を表示しているだけともいえる。
586:nobodyさん
08/11/15 05:47:54
大したことやってないのにフレームワークは重いから使わない(ｷﾘｯ
なんて言っちゃってる企業とか腐るほどあるからなぁ
587:nobodyさん
08/11/15 09:41:57
>>585
インプット・アウトプットの対象の幅広さは、ウェブアプリなんかとは比べものにならんように思う。
ウェブアプリの場合は、一部APIサービス的なものを除けば、ほぼ「画面」相手でいいわけだが。
>>586
その理由でテンプレートエンジンを使いたがらない人も未だに多いがな。同じじゃね？
588:nobodyさん
08/11/15 13:00:48
フレームワークに比べて、テンプレエンジンは開発効率大してよくならないからな。
つーかＦＷに組み込まれてるし
589:nobodyさん
08/11/15 13:15:36
何かをしない理由にパフォーマンスを上げている場合、大概ちゃんと調べるのとか新しい
やり方を検討するのが面倒くさいことだけの事が多いと思う。
論理削除ってあるじゃん。レコードに削除フラグを立ててデータは残すって言う。
あのフラグのチェックををいちいち手で (del_flag IS NULL OR del_flag = 0) とか書いている
会社があった。
なぜ NOT NULL制約を付けないのかと聞いたら、「重くなる」って答えが返ってきた。
全力でこけた。いろいろ間違ってる。
590:nobodyさん
08/11/15 14:11:03
12のphp最適化テクニックとか、一時期ブログに出回ったけど、
そのテクニックが使われるタイミングを考えると、誤差でしかないとか、
よくあったよね。
むしろコードが読みにくくなったり、書きにくくなったりと、
その時間のほうがもったいないとか。
591:nobodyさん
08/11/15 14:39:00
大手でphp使ってサービスやってるといえばYahooなんだけど
たとえば、↓
URLﾘﾝｸ(www.sooey.com)
symponyだって。
でもサービスによって違いはあって
URLﾘﾝｸ(wakatsukichinatsu.yahoo.co.jp)
↑これなんてPHP?
592:nobodyさん
08/11/15 14:39:25
論理削除自体間抜け
593:nobodyさん
08/11/15 14:54:51
論理削除自体が間抜け？
方法がフラグってとこが間抜けってなら少しはわかる気もするが。
594:nobodyさん
08/11/15 14:55:03
論理削除は必要だろ。
595:nobodyさん
08/11/15 15:09:50
スレチだけど論理削除ってどういう指定にすればやりやすいですかね。
active enum('Y','N')か、status = 0 なら削除とか？
596:nobodyさん
08/11/15 15:11:46
>>593
わかんね。
フラグじゃなくてカウンタにするってこと？
597:nobodyさん
08/11/15 16:06:02
大規模向けではなく一番スケールアウトしやすいFWは?
598:nobodyさん
08/11/15 16:34:55
スケールアウト考えたらモデルは自分で書かないときつくね？
599:nobodyさん
08/11/15 16:57:52
ちｒｙ
600:nobodyさん
08/11/15 17:24:52
>>595
deleted（datetime）がnullかどうか
601:nobodyさん
08/11/15 17:52:20
int型にして、0だと削除扱いにするのが妥当だろうな。PHPやPerlなら、ブーリアン評価でfalseが帰ってくるし。
602:nobodyさん
08/11/15 17:55:22
勝手に値はいるのはtimestampだけだっけ？
603:nobodyさん
08/11/15 18:02:15
>>602
NOT NULL にしておいて default を設定すれば入るだろ
604:nobodyさん
08/11/15 18:49:10
mysqlはデフォルト値に関数が使えない
605:nobodyさん
08/11/15 18:51:03
>>600
deletedってどういうこと？
606:nobodyさん
08/11/15 19:09:25
フィールド名じゃないの？
607:nobodyさん
08/11/15 19:12:51
ああそういうことか、関数かと思ったｗ
608:nobodyさん
08/11/15 19:13:24
nullだとインデックスが使われないから論理値のほうが良くない？
609:nobodyさん
08/11/15 19:27:12
nullかどうかで求めるのは本来正しく無いだろうね
削除された、と言う状態がシステム上にありうるならそれはnullで表現すべきじゃない
610:nobodyさん
08/11/15 19:54:48
というか、３値論理っての？ NULL を理解していないとか必要性を感じないとかの場合は、
全フィールド NOT NULL で作ってしまえと言いたい。
その方が何かとトラブルが少ないし、コーディングも楽だ。
テキストフィールド？ 空文字でも入れとけ。 数値？ 0が初期値だ。それで都合がわるけりゃ、
-999999999 が初期値だ、文句あるか、ってな感じで。
611:nobodyさん
08/11/15 22:00:11
>>608
MySQLならenum型でnullを使う分にはNULLでインデックスされると思うよ
他のDBでは知らない
612:nobodyさん
08/11/15 23:07:45
>>607
そう、カラム名。
id, created(datetime), updated(datetime), deleted(datime)を標準的に使用。
あるいは、statusとしてa)Activei)/Inactive、h)Hidden, b)Obsoleted D)deleted
とか詳しい状態が必要な時に使うとか。
613:595
08/11/15 23:12:27
いろいろやり方あるんすね。すごい勉強になった。
皆さん有り難うございます。
614:nobodyさん
08/11/15 23:21:42
論理だろうがなんだろうが、削除っていうからカッチリ噛み合わないと思うんだよね
実際問題何も消してないわけなんだし
だから、そういうのは無効化とか不活性化とか利用不可とか、そういう「状態」で呼ぶべきで
削除って言うならならきっちりかっちりまるっと全部消してしまえ！
と思うんだよなー
スレ趣旨と全然関係ないんだけどなー
615:nobodyさん
08/11/15 23:47:46
>>612
頭文字使うぐらいなら、enum型かSET型じゃね？
まぁ、DB実装によって違うかもしれんけど。
616:nobodyさん
08/11/16 02:05:02
論理削除はDELETEより早い速度が求められる場合(index更新のコストが馬鹿にならない)とか
警察照会とか、CS対応で必要とかやっぱり要るシーンが多くて>>614みたいに消してしまえーが使えない場合も少なくないよ
>>615
そうだね。
617:nobodyさん
08/11/16 02:08:47
論理削除っていう呼び方はおかしいね
ソフトウェアなんだから全て論理だし
無効化、凍結、と言う呼び方が正しい
618:nobodyさん
08/11/16 02:19:28
そうかな？英文でもphysical delete、logical deleteって言葉よく使われるよ。
URLﾘﾝｸ(publib.boulder.ibm.com)
619:nobodyさん
08/11/16 03:13:45
処理速度の場合もあるだろうけど、後から参照しないといけない場面がよくあるからな。安易に削除するわけにはいかないことが多い。
620:nobodyさん
08/11/16 06:39:55
だからそれを削除って呼ぶなよﾊﾞｰﾔ!!って言いたいんだろう
621:nobodyさん
08/11/16 06:56:48
論理削除を削除と呼ぶか、単なるステータスかというのは
呼び方の慣習の問題。
言葉遊びをやってもしょうがないんで、ここでは便宜的に、論理削除とは、
物理的には削除せずにサービス上削除されたようにふるまわせること
でいいかな？
622:nobodyさん
08/11/16 09:11:01
>>600 >>612
滔々と語ってるが、>>612の前者のdeleted （削除日時） はまあともかく、
後者の方では、レコードにユニーク制約のカラムがあった時に不便だろ。
削除フラグ（というかカウンタなど）とセットでユニーク制約にしてしまうって
のは、あんまり流行って無いのか？
623:nobodyさん
08/11/16 12:27:21
partial index 使っちゃう。
624:nobodyさん
08/11/16 12:33:30
>>622
詳しく
625:nobodyさん
08/11/16 13:00:36
>>624
例えばユーザアカウントをユニークにしたいとかで、一意制約をユーザ名カラムに付けるとする。
んで、そのユーザが退会した後、そのデータを残してたら、そのユーザ名がずっと使えない。
それを避けるために、削除データだけ一意制約から考慮外にしたい場合、削除フラグと２カラム連結で
ユニークにしてしまう。
んでレコードを削除する時に、同一なユーザ名を持つデータの削除フラグを、一斉に +1 UPDATEしてしまう。
削除フラグが 1以上なら( というか、0でなければ ) 削除データという扱い。
こんなやり方。マイナーなのかな？と思った。
書いてて思ったが、これ一意制約のカラムが二つ以上あった場合、そのままでは使えないなｗ
もちょっと応用を利かさないと無理か。
整数部分と少数部分で分けるとか桁で分けるとかビットで分けるとかｗｗｗ
＃ DBの一意制約を使わずアプリで常にチェックするなら別にこんなことしなくていいんだけど。
626:nobodyさん
08/11/16 13:06:04
こんな風にやりたいのなら、削除フラグ自体もユニークにして削除日時を
マイクロ秒まで入れておけばいいのではと後から思ったのは内緒だ。
627:nobodyさん
08/11/16 13:24:25
って書いて、削除フラグをユニークにしたらそもそも「未削除」の状態はどうするんだと気づいた午後。
飲みながらレスするもんじゃないな。
退散します。
628:nobodyさん
08/11/16 13:45:33
>>625
その例だと使えなくするケースが多いのでむしろ好都合。たいていサポートチームが要望してくる。
629:nobodyさん
08/11/16 13:51:02
酔っ払いめ！ｗｗ
さて、ユーザーアカウントを例にすると、ちょっと怖すぎるんだが、
CMSなんかのアイテム管理だと、リビジョン管理に同一itemidで
複数のインスタンス、しかも最新以外は非アクティブっていう状態を
表現するという用途があったりする。
その場合、削除フラグを使わずに、使用目的に合わせたタグを振る。
外部キー側もタグやリビジョン番号を考慮した設計にしないといかんわけだけどね。
630:nobodyさん
08/11/16 14:12:40
>>629
そういうのの設計はちょっと知りたいなーと思っていたんだけど、
MediaWikiのソースでも読めばいいのかな？
631:nobodyさん
08/11/16 14:19:46
PACの解説記事でDrupalが良い実装とか見たことあるので同じCMSならこっちは?
リビジョンと直接は関係ないけどソースはしっかりしてるかも
632:nobodyさん
08/11/16 14:26:24
設計見るのになぜソースを読む
633:nobodyさん
08/11/16 14:43:16
オープンソースソフトウェアの設計書なんて公開されてる？
634:nobodyさん
08/11/16 15:05:16
おそれすになったな・・・
>>587
> インプット・アウトプットの対象の幅広さは、ウェブアプリなんかとは比べものにならんように思う。
> ウェブアプリの場合は、一部APIサービス的なものを除けば、ほぼ「画面」相手でいいわけだが。
それをいったら、ウェブじゃないアプリだって、ほぼ画面（ディスプレイ）相手だろ？
なんか比較している対象がずれてるよ。
画面じゃなくてOffice系の大規模アプリだって、結局は画面にGUI表示してファイルに書き込むだけなんだし。
ゲームだってそう。ハードウェアデバイスを扱うものもあるだろうけど、それをウェブアプリでやってはだめってことはない。
ブラウザでコーヒー沸かす装置とかｗ
635:nobodyさん
08/11/16 15:05:49
>>633
設計書 = ソースコード
636:nobodyさん
08/11/16 15:33:36
>>634
元のレスが、アプリとは書いてなくて、「ウェブじゃないシステム」って書いてあるからじゃね？
対象がずれてるというか、「Office系の大規模アプリ」とかゲームとかが念頭にあるのは
わかっててわざと書いてるんだろｗ
車のエンジン制御とか、通信インフラ系とかはシステムじゃねーの？って。
>>585
> それにウェブじゃないシステムが何をしているかというと、
> 結局、ファイルにデータ読み書きして、画面に点を表示しているだけともいえる。
いえねーよｗ
これがむしろ、言いたいことと表現がずれてるんじゃね？
637:nobodyさん
08/11/16 17:24:18 +7h73lOI
タグの実装を考えています
スペース区切りでtextカラムに入れて、全文検索するのがシンプルでいいかと思ったのですが、
他にいい方法があったら教えてください
638:nobodyさん
08/11/16 17:26:45
>スペース区切りでtextカラムに入れて、全文検索
これはひどい
639:nobodyさん
08/11/16 17:28:47 +7h73lOI
そうですか？ググっていたら同じようなことしてる人もいますが。
URLﾘﾝｸ(blog.nomadscafe.jp)
他にいい方法があれば教えてください。
640:nobodyさん
08/11/16 17:43:46
タグ単位で編集とかしないならいいんじゃない？
641:nobodyさん
08/11/16 17:44:48
普通に考えれば
タグテーブル作って
アイテムテーブルとの間に多対多のリレーションテーブル持てばいいだけだよね
いかにもリレーショナルに解決出来るケースだと思うけど
642:nobodyさん
08/11/16 17:45:10
>>639
それ、フレームワーク関係ないし、それ以前にPHPの問題でもないよ。
DBの問題だからDB関連スレで質問しろよ。
まぁ、正規化すら理解してないみたいだからまずは本でも買って勉強することをオススメするけどね
643:nobodyさん
08/11/16 17:52:11
だね
基礎知識が足りてなさそう
644:nobodyさん
08/11/16 17:59:55
なるほど、おっしゃる通りですね。
ありがとうございました。
645:nobodyさん
08/11/16 18:01:45
俺はついこの間タグテーブルと、タグと記事のリレーションテーブルで作った。
けど、割とありきたりの機能になったのに、
情報が少なくてベストプラクティスな設計が出来たか不安なんだよね。
タグはパターンとしてどっかに情報がまとまっててもいいと思うんだが。
646:nobodyさん
08/11/16 18:10:11
だから典型的なリレーショナルな設計でいいでしょ
それ以外に特別な事なんて無いんだから
647:nobodyさん
08/11/16 18:20:02
うん基本的すぎてまとめる気が起きない
不安ってのはRDBの理解が不十分なのかと。
648:nobodyさん
08/11/16 18:26:03
フレームワークの話題が無いのか
649:nobodyさん
08/11/16 19:46:05
symfony使ってるんだけどRoRと比べてモデル周りが貧弱で泣いた
650:nobodyさん
08/11/16 20:18:46
PHPの場合、標準的なDBドライバがないからな。どれも中途半端。
651:nobodyさん
08/11/16 20:20:48
具体的にちんぽにーとrorでどうちがうの？
652:nobodyさん
08/11/16 20:23:39
横レスだけど。
RoRのアプリケーションはRubyで書けるけどSymfonyではRubyで書けない。
これは大きい。それに比べりゃモデル周りなんて大差ないんじゃね？
653:nobodyさん
08/11/16 20:25:04
んなの当たり前じゃん
フレームワークの比較より言語の比較だし
654:nobodyさん
08/11/16 21:54:05
フレームワークを初めてつかったけど「便利な関数群」ってだけじゃん。
655:nobodyさん
08/11/16 21:56:08
違うよ
全然違うよ
656:nobodyさん
08/11/16 21:59:31
>>654
なんという前世紀のライブラリ
まあそれはそれで便利だけど
657:nobodyさん
08/11/16 22:07:04 tiBOVYsk
PHPを初めてつかったけど「便利な関数群」ってだけじゃん。
658:nobodyさん
08/11/16 22:19:55
それはそうだよ
659:nobodyさん
08/11/16 22:21:24
>>657
それは半分真実
ただWEBフレームワークであるという視点も抜けている
例えば$_POSTや$_COOKIEは関数か？
HTTPヘッダを自動で吐く機能は関数？
PHPはただ単にWEB入出力とDBアクセスに便利な関数群装備のインタプリタとして
使うのもいいし、不十分な（でも拡張も可能な）フレームワークとしても利用出来る
と思ってるけどどうだろ
660:nobodyさん
08/11/16 23:54:00
フレームワークはパターンとルール
661:nobodyさん
08/11/17 00:16:53
それは多分定義のレイヤが違う
662:nobodyさん
08/11/17 00:19:03
>>661
どういうこと？
ｋｗｓｋ
663:nobodyさん
08/11/17 03:03:18
「便利な関数群」つうだけならそれはライブラリ。
ワークはあるがフレームがない。
664:nobodyさん
08/11/17 22:29:41
>>657
webプログラミングがまだ試行錯誤だった時代に、
その「便利な関数群」ってだけのことがとても
大きかったから、シェアが取れた。
便利な関数群自体がほとんど無かったからね。
Javaと同じ。
665:nobodyさん
08/11/18 03:06:59
$_SESSIONとか$_REQUESTとか勝手にcontent-typeが出力されるとか、PHPの言語機能自体にウェブアプリ用の機能が組み込まれてるからな。
666:nobodyさん
08/11/18 03:12:50
１回Ｃ言語でＷＥＢアプリ作ってみると良く分かる
あとＰＨＰが流行ったのはＷＥＢアプリ（のインタフェース部分）はこの程度の機能で十分って事もあるだろうね
敷居を低くしてしまって素人プログラマーが流入してきても
ＷＥＢ分野には受け皿がある
667:nobodyさん
08/11/18 06:22:10
webアプリなんて一方通行だからな
アホでも書けるんだよ
668:nobodyさん
08/11/18 10:11:51
>>664
関数や機能がたくさんあるだけが問題ならPerlが圧勝したはず。
やっぱりmod_phpの管理のお手軽さとPHPの言語自体の簡便さ。
669:nobodyさん
08/11/18 10:27:37
>>668
ソースインストールはお世辞にもお手軽とは言えなかったがな
未だにrpm以外でのPHP管理を敬遠するサーバ屋もあるくらい
670:nobodyさん
08/11/18 12:15:39
URLﾘﾝｸ(ja.wikipedia.org)
ここで言うプル型アーキテクチャのフレームワークってPHPでなんかある？
671:nobodyさん
08/11/18 12:41:48
Smarty
672:nobodyさん
08/11/18 13:20:30
なんか新しいフレームワークがでてきたらしい
Yii Web Programming Frameworkは期待できそう。
URLﾘﾝｸ(cakephp.seesaa.net)
673:nobodyさん
08/11/18 14:00:58
Perlは組み込み関数は少ない。
CPANモジュールをインストールしなければ行けないから、リモートログインとシェルが使えない共用のレンタルサーバなんかだと使い物にならない。
多少なりともUNIXの知識も要求されるし。
その点、PHPの場合、mbstringが有効になってれば、Pearが使えなくてもどうにでもなる。
674:nobodyさん
08/11/18 14:55:14
>>673
それはかなり昔の話だけどね。
PHPで global $HTTP_GET_VARS とかしなきゃいけない、ってのに近いくらいｗ
特に、Perl5.8からはEncode標準添付だし、MovableTypeの流行以降は、
そこらのレンタルサーバでも一通りのモジュールは入るようになってる。
DBI・DBMやらも普通に使えるのが大半。
その頃にはみんなレンタルサーバでのPerl CGIから離れてしまってたがなｗ
675:nobodyさん
08/11/18 14:59:41
>>670
よくわからんが、「イベントドリブン」なんてのを謳ってるようなのは
そうなのかな？
676:nobodyさん
08/11/18 18:21:34
>>672
ActiveRecordじゃないですか。モデルに強くてうれしす。
制作者はPRADOのひとかぁ
677:nobodyさん
08/11/18 19:49:11
>>675
EDPとはまた違うような。
ビューがコントローラーにデータをリクエストするようなやつ。
678:nobodyさん
08/11/18 20:42:37
PHPは5-6年前の時点でPHP4が普及してたから。
そもそも国際版のPHP3ってレンタルサーバで提供されることはほとんどなかった。あっても、すぐに4に移行したから。
Perlの場合、5.8.10になっても標準モジュールだけでは既存のウェブフレームワークは動かない。
モジュールをインストールしても、CatalystみたいなのはCGI環境ではまともな速度が出ないし。
共用レンタルサーバへの設置の難しさがあって、MTがWordPressに抜かれて、XOOPSとかPukiWikiとかフリーのウェブアプリってPHPの一人勝ちになった。
Perlが使われるのは未だにKENTのCGIとか。
そういう反省があって、今のPerl界でMENTAとかの設置の簡単な、標準外のモジュールに依存しないウェブフレームワークが注目されてる。
けど、結局のところ、ベストプラクティスに載ってるようなモダンなPerlを書こうと思えば、適時CPANモジュールをインストールするしかないわけで、これはPerlっていう言語の性格上どうにもならないな。
679:nobodyさん
08/11/18 20:49:25
>>677
ビューがコントローラーにデータをリクエストする。を読むと、
すごいイベント駆動ぽい気がするんだけど・・・
プル型というのは、いったい何のための仕組みなんだ？
コントローラーがビューにデータを渡すのではなく、
あえてビューがコントローラーにデータをリクエストする理由が知りたい。
680:nobodyさん
08/11/18 21:21:31
ページデザインだけでサイトが完結しうるところがメリットかな。
オンデマンドに必要なデータを拾いに行くので、自由度が高くなる。
ページに組み込むパーツがいかように変化してもコントローラーを
いじらなくて済むところとか。
まぁ、プッシュ型でも、ビューからコントローラーを呼べるはず。
それが特殊な時だけ利用するのか、常にそうするのかの違いだな。
CMSでイベント駆動だとプル型っぽい動きさせてるのが結構ある。
フレームワークはなんだかんだボトムアップだからプッシュ型が普通で、
それに慣れすぎてる感はある。
681:nobodyさん
08/11/18 22:15:34
あとプル型はコントローラーが複数あるのも特徴とか英文Wikipediaにかいてなかったっけ
なんかフレームワークスレっぽくなってきた
682:nobodyさん
08/11/18 22:23:17
英文関係無かった須磨祖
683:nobodyさん
08/11/18 22:54:01
あんまり詳しくないから変なこと言ってるかもしんないけど
PHPだと複数ファイルに分けてあるものをIncludeしてくしかないわけで、
MVCはコード書く上での概念みたいな感じでPushもPullも厳密には関係ないよね？
JavaServletのforwardみたいに処理投げ渡したりとかできないよね
684:nobodyさん
08/11/18 23:09:54
フレームワークが何を自動化するかって事だろ
685:nobodyさん
08/11/18 23:29:54
URLﾘﾝｸ(ja.wikipedia.org)
Tapestryではこんな説明だった。
> Apache Tapestryは、アクションをベースとした仕組みのApache Strutsとは競合する。
> TapestryはStrutsとは違い、コンポーネントベースであり、コード量が少なくて済む点が特徴である。
> またStrutsのようにJSPカスタムタグライブラリを覚えなおす必要がなく、
> 必ずServlet/JSPを作成しなければならないということはなく、
> Javaやネットワークの知識がないウェブデザイナーでも簡単にJava製ウェブアプリケーションを作成できるという利点がある。
アクションをベースとしたStrutsとは違うというあたりが、
なんとなくプル型が分かるような分からないような。
使ってみないと、はっきりしないかなー
686:nobodyさん
08/11/19 00:16:11
URLﾘﾝｸ(en.wikipedia.org)
これ見たらpush/pullが一目瞭然。
687:nobodyさん
08/11/19 00:34:10
Propelでmany-to-manyってどうやるの？
688:nobodyさん
08/11/19 02:02:44
URLﾘﾝｸ(ja.wikipedia.org)ソフトウェアコンポーネント
ここ読んでたらなんとなく分かってきた。
MVCからVを分離して、MCを部品として考えて、
Vから複数の部品を使うってことかな。
ショッピングカートの機能をMCだけ作って、
掲示板の機能もMCだけ作って、
コントローラとのインターフェースが分かってれば、
ビューでうまいことやるだけで、掲示板が組み込まれたECサイトの出来上がり。
語弊を恐れずに、俺の想像をざっくりと書いてみた。
//最近のブラウザはURLエンコードしてくれないのね。
689:nobodyさん
08/11/19 02:09:05
普通にwikipedia読めば分かるじゃん
690:nobodyさん
08/11/19 02:12:01
どのページ？
691:nobodyさん
08/11/19 03:03:05
>>688
そう
Vからプルするから主はV。結果、Vのみさわるデザイナーが使いやすいものとなる。
692:nobodyさん
08/11/21 13:07:50
ちんぽプルプルですね
わかります
693:nobodyさん
08/11/21 15:29:21
ですね分かりますは終了したってどっかに書いてあったよ
694:nobodyさん
08/11/21 15:35:48
どっかで終了宣言したら終わりなんですね
分かります
695:nobodyさん
08/11/22 10:57:11 enBp98lH
グレイトなMVCフレームワークないかい？
696:nobodyさん
08/11/22 11:55:27
あったら困らん
697:nobodyさん
08/11/22 13:29:05
ZF出たね
698:nobodyさん
08/11/23 02:16:27
yii使ってみた人いる？
699:nobodyさん
08/11/23 20:39:26
symfonyとcakePHPってどっちがいいの？
ユーザーは常時アクセス百人ぐらいを想定してます。
700:nobodyさん
08/11/23 20:41:14
そのレベルではどっちでも大して変わらんかと
701:nobodyさん
08/11/23 20:43:11
軽いっちゃあcakePHPだろうね。機能的にはsymfonyかね。
まぁそれぐらいの人数じゃ負荷は別に別に気にしなくてもいいと思うけどね。
702:nobodyさん
08/11/23 20:54:39
>>700>>701
回答ありがとうございます。
学習コストはどっちが大きいのかな？
symfonyの方が難しい？
703:nobodyさん
08/11/23 22:07:52
やりたいことにもよるだろ。
ドキュメントぐらい見ろや。
704:nobodyさん
08/11/23 23:03:02
自分でちょっとした軽いサイトを作りたいなてとき
CakePHPがよい
どういうサイトが当たるかわかんないから
とにかく当たりそうなサイトを片っ端から量産したいときにはCakePHPがいい
大企業からマジ受けするならsymfonyかな
そんな大企業を相手できない俺は小回りが利いて時代にニーズにいち早く対応できるCakePHPが一番好きだ
705:nobodyさん
08/11/23 23:03:07 I/SHm+AO
Cakeの方がインストール簡単
706:nobodyさん
08/11/23 23:06:24
CakePHPみたいに作りたいなと思ったサイトをサクッと作れる快感がたまらん
時代の流れの速いＩＴ業界にあってるよ
707:nobodyさん
08/11/24 00:43:30
おれはSymfonyの方がよりオブジェクト指向な分使いやすいな
ドキュメントもしっかりしてるし
708:nobodyさん
08/11/24 01:31:16
その二つのどっちかが今の主流なのかな
709:nobodyさん
08/11/24 01:58:00
今の日本での主流はcake。
php6の後も稼動し続ける予定ならZFが無難。
URLﾘﾝｸ(www.google.com)
検索数だからあてにならないかもしれないけど
日本語圏はcakeを世界で2番目に使ってるっぽいぞ。
つーか、地域だと目黒区が1位だけどお前ら寄付とかしてんの？ｗ
710:nobodyさん
08/11/24 02:07:28
インドネシア語が一位って。。
それ眉唾すぎないか
711:nobodyさん
08/11/24 02:19:05
ZFだけはないわ
cakeはドジでのろまな亀しか使ってないし
普通はsymfonyだろうな
712:nobodyさん
08/11/24 02:34:38
ちょろっとしか見なかったらなぜZFがあんな駄目駄目言われるかわからん。
みんな言うからきっとそうなんだろう。
713:nobodyさん
08/11/24 09:30:25
俺フレームワークの基礎にするには、別にZFは悪くない
symfonyは知らんが、cakeとかCIとかのように、「こう書けばすぐアプリ」っていう
がっちがちの枠を、ZFでは用意していないだけ。
714:nobodyさん
08/11/24 10:58:13
PEARみたいなライブラリということか
715:nobodyさん
08/11/24 12:21:02
密であるが疎にはできないものと
密にも疎にもできるもののどちらがいいかっていったら
そりゃ後者だわな
716:nobodyさん
08/11/24 13:41:57
そこら辺の凡人ＰＧがPHP4時代に書いたど腐れライブラリなんかは、
全部ZFに置き換えてもいいくらいだと思うよ
なんつーの？ 割り切り仕様というか内部諒解仕様というか、そういった
よくわからん決め打ち系の記述は（マルチバイト関連を除けば）非常に少なく、
かなり汎用的に作られてるっぽい。
例外処理だけ、ZF流儀にあわせればあとはどう使おうと自由って感じで。
717:nobodyさん
08/11/24 18:12:50
>>713
> がっちがちの枠を、ZFでは用意していないだけ。
がっちがちの枠（フレーム）を用意するのが
フレームワークだと思うんだがねぇ。
718:nobodyさん
08/11/24 18:28:09
メリットもあるが色々弊害もあるのだよ、僕
719:nobodyさん
08/11/24 18:35:08
それはフレームワークでなくて別って意味でしょう。
ZFは自由に使えって言うけどライブラリとの違いが分からない。
そして、結局ライブラリを細切れに使うのと手間が一緒の気がするんだけど。
それ以上のメリットがあるのか良く分からない。
720:nobodyさん
08/11/24 18:43:34
>>719
具体的にそれでどんな悪い点が？
721:nobodyさん
08/11/24 18:51:52
>>719
使ってみればわかるが、ZFにフレームはある。
ただ、それは固定されたフレームではなくて、設計者が自由に拡張可能なフレームだ
設計を行わない人にとっては無用の長物。メリットだってわからない。
722:nobodyさん
08/11/24 20:20:21
決め打ちでしかプログラミングできない低脳にはおすすめできないってこった
723:719
08/11/24 20:59:56
>>720
あえて言えばメリットが見つからないというのが悪い点かと
>>721
使い込んでみないと分からないって事でしょうか。
もうちょっと機会があれば研究してみたいとは思います。
>>722
なるほどそうですかw
724:nobodyさん
08/11/24 22:26:16
Eclipseでsymfonyフレームワーク使ってプログラミングしたいんだけど、可能？
725:nobodyさん
08/11/24 23:50:06
どういう意味かはっきり書かないと答えようがない。
Eclipseはエディタだからそりゃ可能だ。
726:nobodyさん
08/11/25 05:20:59
PDTで書けるかって意味ぢゃね？
ethnaとかちょっと微妙だから。
symofnyは大丈夫だけど、少しコツがいる。
けど、なんか安定しないんだよなぁ。もう1.2の声が聞こえてくるし。またコンバート作業必要なんでしょ？
＞ 1.1→1.2
727:nobodyさん
08/11/25 15:20:48
微妙って意味がわからんのだが
htmlまわりの話か?
728:nobodyさん
08/11/25 15:32:12
最近は知らんけど、1年くらい前の状況だと、
Ethnaの構造ではPDTでは補完が働かなかったな。
あとコマンドラインでアクションやビューやテンプレートが生成されるので、
いちいちプロジェクトを更新するのが面倒だった。
ファイルの追加がPDT外で行われて、PDTの補完も働かないんじゃ、
わざわざ重たいPDTを使うメリットがないと思った。
symfonyは使ってないからしらね。
729:nobodyさん
08/11/25 15:43:10
プロジェクトの更新なんてF5一発でいいのでは。
そんなこと言ってたらSVNでの頻繁な更新なんてできないじゃないかｗ
補完もどのみち最初から微妙っちゃ微妙だし。
少なくともPCパワーさえある程度あれば、テキストエディタよりは便利だと思う
まあやりやすいようにやればいいんだけど
730:nobodyさん
08/11/25 15:51:45
俺の場合、PDTに感じる価値がちょうどプロジェクトの管理と補完だからな。
逆にエディタとして見ると融通が利かない駄目なやつと思っている。
最近は出来るようになったけど、全角スペースをマーク表示させたり出来なかったとか、
後は覚えてないけど細かいところでたまにイラっとする。
だから俺は、プロジェクト管理と補完のために使ってるようなもんだ。
731:nobodyさん
08/11/25 16:09:13
一応、Eclipseの特徴として on the fly な構文チェックってのはあるけどね。
しょうもないparse errorとか、未定義変数とか示してくれるのは、非常に効率アップしてくれる
自分が注意力散漫だけかもしれんけどｗ
他のエディタでもこの機能はあるのかな？
732:nobodyさん
08/11/25 16:32:01
PDTにsymfony用のプラグインってあるよね
使ったことはないけど
733:nobodyさん
08/11/25 16:38:15
URLﾘﾝｸ(www.symfony-framework.com)
URLﾘﾝｸ(noy.cc)
Symfoclipseつーやつかな？
734:nobodyさん
08/11/25 16:54:55
てか、Eclipse使ってる人はPDTが多いのか。
なぜか理由は忘れたが、PHPEclipseの方を使ってる俺は異端？
735:nobodyさん
08/11/25 17:45:10
オレなんて未だにTruStudioなんだぜ、自宅は
さすがに会社はPDTに乗り換えたが、自宅じゃ
めんどくせーからこのまんまでいいやみたいな
736:nobodyさん
08/11/25 22:37:49
>>727
スケルトンが拡張子が.phpだから（かつ中身がphpじゃないから）PDTだとずっと構文エラーになる。
拡張子ハードコーディングしてあるから直せん＞ethna
737:nobodyさん
08/11/26 01:42:35
PDTならZSの方がインスコも楽だしアナライザーもはいる。
無料でよろし。お薦めする。
738:nobodyさん
08/11/26 05:16:43
Zend Studio？ 無料？
739:nobodyさん
08/11/26 08:31:02
そう。ZSは試用期間が終わるとPDTとほぼ同様になる。
尚日本語版は勧めない。日本語化したければPDTと同じようにする。
740:nobodyさん
08/11/26 21:22:21
>>736
うそ
ethnaって .php -> .html とかに変えられないの?
ダメだそりゃ
741:nobodyさん
08/11/27 02:26:51
>>740
スケルトンがな。
ルーティングなんていくらでも変えられる。
しかし、スケルトンもEthnaのデフォを削除しちゃって、自分Appのは
Handlerを定義しちゃえばいけるんじゃね？そんな手間でもないと思うが。
742:nobodyさん
08/12/01 22:29:43 XLqJXNnh
URLﾘﾝｸ(www.yiiframework.com)
Yii 178
CakePHP 170
CodeIgniter 131
Prado 53
Zend 51
Symfony 36
数字はRequest Per Second
743:nobodyさん
08/12/01 22:39:29
いいねいいね
今度使ってみるか
744:nobodyさん
08/12/01 23:19:54 XLqJXNnh
こういうhello worldにベンチってどんくらい意味あんのかとか思ってたけど
そのページに書いてあるようにあくまでRPSの上限を計るベンチで（これ以上の値は出ない）、
ajaxとかhtmlレンダリングない場合もあるしでやっぱり価値はある。
745:nobodyさん
08/12/01 23:27:25
そのベンチ、Yiiだけecho 'Hello World';になってて
他のがdie('Hello World');になってるのは何で？
まあ大抵のベンチは信用出来ないのは知ってるけども。