10/12/12 10:47:08
PHPのフレームワークに関する話題用のスレッド
●国外産●
symfony
URLﾘﾝｸ(www.symfony-project.com)
code igniter
URLﾘﾝｸ(codeigniter.com)
Zend Framework
URLﾘﾝｸ(framework.zend.com)
CakePHP
URLﾘﾝｸ(www.cakephp.org)
Yii Framework
URLﾘﾝｸ(www.yiiframework.com)
●国産
ちいたん
URLﾘﾝｸ(php.cheetan.net)
Ethna
URLﾘﾝｸ(ethna.jp)
guesswork
URLﾘﾝｸ(classic.guesswork.jp)
maple
URLﾘﾝｸ(kunit.jp)
●前スレ
【PHP】PHPフレームワーク総合スレ14
ｽﾚﾘﾝｸ(php板)
2:nobodyさん
10/12/12 10:47:46
●過去スレ一覧
14ｽﾚﾘﾝｸ(php板)
13ｽﾚﾘﾝｸ(php板)
12ｽﾚﾘﾝｸ(php板)
11ｽﾚﾘﾝｸ(php板)
10ｽﾚﾘﾝｸ(php板)
. 9ｽﾚﾘﾝｸ(php板)
. 8ｽﾚﾘﾝｸ(php板)
. 7ｽﾚﾘﾝｸ(php板)
. 6ｽﾚﾘﾝｸ(php板)
. 5ｽﾚﾘﾝｸ(php板)
. 4ｽﾚﾘﾝｸ(php板)
. 3ｽﾚﾘﾝｸ(php板)
. 2ｽﾚﾘﾝｸ(php板)
. 1:ｽﾚﾘﾝｸ(php板)
3:nobodyさん
10/12/12 11:19:10
頭の悪い言い争いする前にスレ立てとけ
既に実装されてしまった内容なんだから、使う使わないは案件なりで決めれ
不満があるなら開発途上の段階で割り込んでおけよと
仕様みてみたが、バックスラッシュは格好悪いけど、実装自体は普通のnamespaceじゃん
バックスラッシュは格好悪いけど、常に完全修飾名を要求されるとか、使い方知らないだけじゃ
再利用を考えたら、結局namespaceは必要だしな。バックスラッシュは格好悪いけど
ほんとバックスラッシュは格好悪いけどな
わざわざコード書く環境だけ正しいフォントに直すのも面倒だし
4:nobodyさん
10/12/12 11:57:31
ﾊｲﾗｲﾄ
992 nobodyさん [sage] 2010/12/12(日) 03:24:51 ID:???
PHPの名前空間は、
URLﾘﾝｸ(www.php.net)
Prefix付の長いクラス名を何とかする為のアプローチに見えるな。
実際には、使用時に絶対パスで記述しないとクラス名の衝突が起こる可能性があるので、
何も解決出来ていない(結局絶対パスで記述する必要がある)
情弱は使えばいいよ。
993 nobodyさん[sage] 2010/12/12(日) 03:46:35 ID:???
なんでこいつは名前空間とパスを同一視してるの？
こんなんだからPHP使いはレベルが低いとか言われるんだよ…
994 nobodyさん [sage] 2010/12/12(日) 03:49:53 ID:???
>>993
パス＝クラス名への絶対修飾子って意味ね。
Zend_Hoge_Moge と書くのも \Zned\Hoge\Moge と書くのも同じだし、
このように絶対パスで書かないとクラス衝突は防げない。
となると本来目標にかかげていた、冗長なクラス名の廃止はどうなったのかと･･･
明らかに設計ミスだろ。
5:nobodyさん
10/12/12 11:57:47
995 nobodyさん [sage] 2010/12/12(日) 03:52:41 ID:???
？
その目的の為の名前空間でありそれは達成されてるわけだが？
5.2を切り捨てて対応してるフレームワークなりなんなりみてみろよ
綺麗に切り分けられクラス名は短くなってる
997 nobodyさん [sage] 2010/12/12(日) 04:00:46 ID:???
>>995
されてねーよ。
定義側は省略形で書けるかもしれんが、
実際に使用する側はフルパスで書かないといかんだろ。
打開策として use で別名エイリアスが付けられるが、
エイリアスが他クラスと被る可能性があるという本末転倒っぷり。
それならエイリアスなんか作らず
$className = 'Hoge\Moge\Class';
$class = new $className;
と書く方が利口。
どちらにせよ、当初の目的は果たせていない。
6:nobodyさん
10/12/12 12:11:41
Zendが考えた擬似ネームスペースはもう捨てて
namespace + 新しい規約で
なんとかしろや。
7:nobodyさん
10/12/12 21:55:13
既に有名なフレームワークはそうしてる
ぶっちゃけ今更感が半端無い
3年前の話題だろ…
8:nobodyさん
10/12/13 04:12:37
＞既に有名なフレームワークはそうしてる
symfony2.0
9:nobodyさん
10/12/13 19:03:50
ZendFramework2 も namespace採用されるよ。
ただsymfony2もだけど、PEAR命名規約のアンダースコアをバックスラッシュに変えただけ感はある。
前スレ>>1000
他の言語と比較した上での発言だ。
＞エイリアスが他クラスとかぶる可能性とか何を言ってるんだと言わざるを得ない
namespace project;
use lib\ClassName as ClassName;
という記述があった場合に ClassName が project\ClassName と衝突する可能性があるから、
基本的には絶対パスでの記述になる。
コンパイル時に走査してくるような言語とは使い勝手が全く違う。
＞jsですらjqueryやらprototypeやら他のライブラリつかって名前空間を表現しようって風潮なのにどんだけ取り残されてるんだよ
それらは疑似名前空間で、実装ではなく規約の話だ。
PHPのアンダースコア区切りのクラス名と同類だよ。
namespaceの実装が望まれたECMA4が廃案になったのは知ってるかい？ｗ
10:nobodyさん
10/12/13 19:11:09
何で :: とかにしなかったんだろう。\だと末尾に「.php」が抜けてるような気持ち悪さが…
フレームワーク関係ないね、すまそ
11:nobodyさん
10/12/13 19:37:03
サーバOSがWindowsとかだとますます混乱しそうだよね。
>>10
:: はクラス内のスタティックメソッドやプロパティやクラス内定数の参照の時に既に使ってるし、そっちとかぶるからじゃない？
12:nobodyさん
10/12/13 19:57:00
メソッドだろうがプロパティだろうが名前空間だろうが
全部ピリオドにすればよかったのに
13:nobodyさん
10/12/13 22:06:38
文字列連結に使ってる時点でもうダメだろ。
14:nobodyさん
10/12/13 23:31:53
もう面倒だからサーバサイドJavaScriptに移行しようず
15:nobodyさん
10/12/13 23:54:10
jsは言語が汚れすぎてる
オライリーですら擁護しきれずに綺麗な部分だけ使おうっていう本を出してるぐらいにねｗ
16:nobodyさん
10/12/14 00:52:00
>>11
Perlだってスタティックメンバの参照に::使ってるけど
名前空間の区切りは::だよ。
17:nobodyさん
10/12/14 01:58:34
まぁすでに実装されてしまったものだし諦めるしか
18:nobodyさん
10/12/14 03:45:08
言語仕様もエンジンの実装もドロドロに汚れちゃってるからなPHPは。
namespaceが中途半端な機能で、
区切り文字がバックスラッシュになったのも、
fainallyが実装されないのも、
ZendEngine2への実装が困難だからだよ。
19:nobodyさん
10/12/14 07:54:18
なんでfinally実装できないの？
20:nobodyさん
10/12/14 16:44:36
Lithiumのその後を知ってる人いる？
そろそろリリースかな
21:nobodyさん
10/12/15 00:20:25
>>19
単純に技術的な問題。
良い実装案が出れば、実装したいと開発者は言っている。
22:nobodyさん
10/12/15 01:19:20
へ？構築するスキルがないってだけ？ZendEngineの問題でなく？
23:nobodyさん
10/12/15 01:58:32
>>22
ZendEngineに実装する上での技術的な問題だよ。
24:nobodyさん
10/12/15 02:14:25
だからそれどういう問題？
25:nobodyさん
10/12/15 03:14:43
>>24
だから、技術的な問題だよ。
興味あるならPHP自体のソースコードを読めばいいよ。
26:nobodyさん
10/12/15 06:24:51 mlC32vdu
そういう理由じゃないだろ
URLﾘﾝｸ(bugs.php.net)
27:nobodyさん
10/12/15 06:35:05 mlC32vdu
Bjarne Stroustrup's C++ Style and Technique FAQ
Why doesn't C++ provide a "finally" construct?
URLﾘﾝｸ(www2.research.att.com)
28:nobodyさん
10/12/15 08:08:22
finally、無いよりもあったほうがいい。それは間違いない。finallyの導入にどれくらい開発コストがかかるかは知らないが。
29:nobodyさん
10/12/15 08:15:57
スクリプト言語にfinallyねぇ
中々面白いギャグだ
マジだったらプログラムを一からやり直して欲しいレベル
30:nobodyさん
10/12/15 08:56:06
>>26-27
で、どういう理由なん？
31:nobodyさん
10/12/15 20:09:51
javascript には finally あるんだが
32:nobodyさん
10/12/15 21:17:34
RubyにもPythonにもfinally相当あるよ。ついでにPerl6にもある。
33:nobodyさん
10/12/15 21:25:47
>>25
ﾜﾛｽ 知ったか乙ｗ
34:nobodyさん
10/12/15 22:28:49
英語の読めない俺の為に簡単に訳してくれ
35:nobodyさん
10/12/15 22:29:38
どこが分からんの？
36:nobodyさん
10/12/15 22:39:21
>>35
URLﾘﾝｸ(bugs.php.net)
return文との兼ね合いで、構文が複雑になるから実装しなかったって事？
それとも技術的な問題？
37:nobodyさん
10/12/15 22:40:05
全部訳せとな？
38:nobodyさん
10/12/15 22:59:50
>>37
散々議論されたってのは読み取れたけど、
最終的に何故実装されなかったのかが読み取れませんでした先生。
39:nobodyさん
10/12/16 00:33:53
声の大きな人に限って結論をぼかすよなｗ
40:nobodyさん
10/12/16 01:20:05
26は最初か2番目に出てくるコードで代用できると
27はリソースの開放は利用側じゃなくて利用されるデストラクタで実装すべきという主張。C だが
41:nobodyさん
10/12/16 01:54:17
URLﾘﾝｸ(gihyo.jp)
「finallyも，もしよい実装があれば追加されるかも知れません。」
PHP構文的に排除したのでは無く、実装が困難だから実装されていないだけだ
>>26-27
お前英語読めないだろ？
せめてメーリングリストのログ持って来いよ
42:nobodyさん
10/12/16 02:32:06
C++にfinallyが無いのと同じ理由。
43:nobodyさん
10/12/16 03:44:17
>>42
ﾜﾛｽ、ｷﾞﾌﾞﾐｰｿｰｽ
44:nobodyさん
10/12/16 07:26:50
よい実装があれば可能＝技術的に困難、なのか？
45:nobodyさん
10/12/16 08:13:53
>>41
おまえその日本語読めてない。
空気も英語も読めてないのにメーリングリスト読めないだろ
46:nobodyさん
10/12/16 11:55:51
>>45
空気読めてないのはお前だろｗ 顔赤くしてないで該当メーリングリストのソースを示せよ。
大垣：
実装して欲しい，実装しておくべき機能は思い浮かびますか？
Rasmus：
オブジェクト指向プログラミングのサポートについては実装されるでしょう
traitsにはよい実装があるのでPHP 5.4に含まれることになるでしょう。
finallyも，もしよい実装があれば追加されるかも知れません。
どう読んでも、実装の問題。
47:nobodyさん
10/12/16 20:01:14
よい実装ってどういうこと？
48:nobodyさん
10/12/16 20:23:29
プライオリティが低いってだけじゃないの？
49:nobodyさん
10/12/17 00:29:50
>>47
そのままの意味だよ。
実装出来なくは無いんだろうけど、影響範囲の大きさや、ロジックの改修規模がでかくて難しい。
>>48
どこにプライオリティの話が書いてあるんだｗ
50:nobodyさん
10/12/17 00:33:18
>>49
However namespaces are much harder to implement yet I think finally is relatively straightforward since we can already emulate it using try/catch, but with the quirks.
namespaceの方が実装難しいと書いてあるんだが？
51:nobodyさん
10/12/17 01:54:36
>>50
ん？それは誰の発言？
52:nobodyさん
10/12/17 01:55:07
実際finallyが必要になる場面って、どういうのがあるだろう
そもそもfinallyの代替になる方法、そんなに面倒？
53:nobodyさん
10/12/17 04:00:30
実際namespaceが必要になる場面って、どういうのがあるだろう
そもそもnamespaceの代替になる方法、そんなに面倒？
54:nobodyさん
10/12/17 07:14:13
>>49
>実装出来なくは無いんだろうけど、影響範囲の大きさや、ロジックの改修規模がでかくて難しい
のソースは？
55:nobodyさん
10/12/17 09:59:22
例えば、アクセス制御だって、アンダーバーから始まるメソッドはプライベート扱いにするってルールでコーディングすれば、publicやprivateは不要。
が、そんなローカルルールに頼るよりも言語機能を使った方が良い。
PHPでPearが盛り上がらない理由の1つは、PHPにネームスペースやパッケージがなかったからだと思う。
56:nobodyさん
10/12/17 11:09:01
PEARが盛り上がら･･･ない？
57:nobodyさん
10/12/17 12:19:50
PHPって、WAFがフルスクラッチ・フルスタックなのばっかだからな。
PEAR::DBとSmartyくらいか。どっちもPHP4全盛時で、今じゃ大して使われてないな。
後は、日本だけでNet_UserAgent_Mobileくらいか。
58:nobodyさん
10/12/17 12:33:27
PHPのnamespaceの一番ダメな所は、標準で規約が無いところ。
・パッケージとディレクトリ構造は一致
・クラスファイル名はクラス名+.php
・パッケージ名はドメイン名+プロジェクト名を接頭とし、Camelcaseで記述する
・クラス名はCamelcaseで記述する
のような規約があり、かつuse文でオート（Lazy）ロードに対応
くらいして欲しかった。
自分で実装出来るが、
標準でuse構文が上記に対応していたら、標準化が進むのになぁと思ったりした
59:nobodyさん
10/12/17 13:57:30
一番ダメなのは5.0の時に出さなかったところだと思う
60:nobodyさん
10/12/18 10:24:28
C言語の一番ダメなところは、
ネームスペースがなかったり
クラスがなかったり、
例外がなかったり
61:nobodyさん
10/12/18 11:39:11
>>60
唐突になにいいだすんかとおもうが、
高級アセンブリ言語だからあれでいいのです。
62:nobodyさん
10/12/18 13:01:19
N88BASICこそが究極であり至高ですよとベーマガ読者は言う。
63:nobodyさん
10/12/19 00:45:35
>>60
だからC++が出来たんだろ？馬鹿なの？
64:nobodyさん
10/12/19 11:24:03
C++って最初は例外もネームスペースもなかったの知ってる？
65:nobodyさん
10/12/19 12:10:21
ま、名前空間とは別に、パッケージの仕組みも合った方が良いな。
66:nobodyさん
10/12/20 04:22:59
名前空間、パッケージに関しては
やはり色々考えられているPerlの方が上だな。
67:nobodyさん
10/12/23 14:23:44
自社フレームワークを使ってるところが多い気がするが、
自社のフレームワーク開発すべき？
68:nobodyさん
10/12/23 15:24:40
必要ない
69:nobodyさん
10/12/23 15:41:39
>>68
俺もそう思う。バグだらけのFWを、開発した奴はスキルアップになったかもしれんが、
それを使わされる方はマジたまらんわー。
他の人の意見も求む！
70:nobodyさん
10/12/23 15:45:19
必要ない
71:nobodyさん
10/12/23 16:38:01
半端なFW使うよりかは、もともとある奴をちゃんと検証して
バージョンアップしながら使ってくほうが後々考えると有益
ちょっとしたことのためにFWいじくって対応とかアホなことすると、
大抵はあとで酷いことになる
72:nobodyさん
10/12/23 20:37:52
既存のフレームワークを、自分らの使いやすいようにラップするケースは多々ある。
一からフレームワークを作るのは、勉強目的以外ではあまりメリット無いかな・・・
73:nobodyさん
10/12/25 05:58:05
>>71
>ちょっとしたことのためにFWいじくって対応とかアホなことすると、
あるある。ありすぎて困る。
「それはフレームワークじゃねぇ、ただのライブラリだ！」
と言っても、社内のPHP屋は理解出来ない。
PHPでOSSのフレームワーク使ってない(使い方わからない)時点で、
その程度だわな・・・
74:73
10/12/25 06:00:58
あ、普段はASP.NETやってます。
あれは立派なフレームワークな反面、
社内製フレームがクソすぎて・・・・
（なぜOSSのフレームワークを作らないのか・・・）
という背景があることをいちおう言っておきます。
75:73
10/12/25 06:01:48
（なぜOSSのフレームワークを”使わないか”）だった
76:nobodyさん
10/12/25 13:40:32
>>73
PHPだけでいえば、CakeぐらいはできるがSymfonyはさすがにできないという、
中途半端な技術者が社内製フレームワークを作ってる気がする
77:nobodyさん
10/12/25 14:19:58
>>76
SymfornyはCakeに比べて設計が難しいという意味？
78:nobodyさん
10/12/25 20:35:21
URLﾘﾝｸ(www.google.com)
トレンドでみるとyiiが順調に伸びているが、来年もこのままの勢いを保つか。
79:nobodyさん
10/12/25 20:40:16
これはtwitterをもとにした集計によるトレンド
PHP Frameworks Trends
The data below is generated automatically from twitter
URLﾘﾝｸ(trends.phpmagazine.net)
80:nobodyさん
10/12/26 02:03:25
名前空間があってよかったことってなんかある？
81:nobodyさん
10/12/26 07:39:41
英語、新しいものダメダメな日本のPHPerにはウケわるいけど
お外じゃYiiは結構人気でてるっぽいよね
82:nobodyさん
10/12/26 08:18:08
URLﾘﾝｸ(www.google.co.jp)
・・・どこが？
83:nobodyさん
10/12/26 11:02:41
>>82
Yii って他の意味あるのか？ Yii Frameworkでググル意味は？
84:nobodyさん
10/12/26 11:58:57
>>82
おまえは何がしたいんよ。
85:nobodyさん
10/12/26 13:39:26
新しいモノ＝良いモノとも限らないし、、
今の日本の保守的でグダグダなWEB開発業界を考えると、
枯れてリソースの揃いきったFWを深く使いこなす方が得なんだろうね。
既存のFWを捨てて、新しいFWに移行する明確なメリットデメリットが示せない限りね･･･
86:nobodyさん
10/12/26 14:15:12
>>83
yii -phpの検索結果：約 9,160,000 件 （0.07 秒）
URLﾘﾝｸ(www.google.com)
>>84
人気出てるというから検証しただけ。
87:nobodyさん
10/12/26 14:49:37
それだったらこうだろ
URLﾘﾝｸ(www.google.co.jp)
88:nobodyさん
10/12/26 14:58:30
>>86
Yii の検索結果：約 5,200,000 件 （0.04 秒）
しかし"Yii"のキーワードだけで検索するよりも多いってのがな～ｗ
一体何の検証になってるんだか
・マイナス検索をすると検索結果が増える場合があります
URLﾘﾝｸ(groups.google.com)
89:nobodyさん
10/12/26 15:09:18
Yii Frameworkの他に"Yii"のつく目新しいものなんてないだろ、たぶん。
Yiiフレームワークが登場してから"Yii"のトレンドが上昇してるのは、
明らかにYiiフレームワークの成果だろ。
90:nobodyさん
10/12/26 15:17:53
>>85
yiiのパフォーマンス優位は検証されてるけど
URLﾘﾝｸ(www.yiiframework.com)
URLﾘﾝｸ(www.sheldmandu.com)
91:nobodyさん
10/12/26 15:33:41
こんなのもあるよ。
URLﾘﾝｸ(erickennedy.org)
92:nobodyさん
10/12/26 16:58:09
今後もPHPが続くとしたら、新規の際の選択肢には入れたほうがいいとは思う
93:nobodyさん
10/12/26 17:09:03
蓄積された情報やノウハウ、学習コストを含めるとYiiはまだまだかな。
職業PGが増えてる昨今、まともな学習教材が無いと開発者の足並みが揃わない。
>>90
Hello Worldベンチマーク・・・
94:nobodyさん
10/12/26 17:23:31
＞Hello Worldベンチマーク・・・
何が言いたいの？
検証に問題があるならはっきり指摘して
95:nobodyさん
10/12/26 17:34:00
職業PGなんて教材があっても
多分こうだろう的な、なんも考えてない場当たり実装を次々編み出してくし
日本語で説明されてるコピペできる参考例が多くないと、確かに難しいだろうなｗ
96:nobodyさん
10/12/26 17:34:29
symfony2はYiiより速いらしいよ。
設定がめんどいようだけど。
URLﾘﾝｸ(symfony-reloaded.org)
URLﾘﾝｸ(www.symfony.gr.jp)
97:nobodyさん
10/12/26 17:46:27
symfonyはsfFormがどうもだめだ…
symfony2で変わったのかな。
98:nobodyさん
10/12/26 18:39:55
>>94
Hello Worldの値なんて理論値みたいなもので、
実際の実用環境では他のロジック部分がボトルネックになるから、ほとんど意味の無い値って事。
上の比較ではsymfonyが数倍遅いと錯覚してしまうが、
実際に作るコンテンツ内容、コーディング方法、ファイルI/O、DB処理等の方が遙かに比重が高い。
開発者全員が完璧な最適化を行えるのなら、フレームワークのオーバーヘッドを考慮するのも有意義かもしれんが、
現実的では無いし、大抵は枯れた技術の方が最適な実装が出来るし、学習コストも低い。
その浮いたコストをハードウェアやネットワークに回す方が遙かにパフォーマンスは上がる。
それ以上のチューニングを行う場合は、フレームワーク自体導入しない事の方が多い。
99:nobodyさん
10/12/26 19:30:20
地味にYiiスレ出来てんのな
で、このスレをディスってんのなｗ
100:nobodyさん
10/12/26 19:48:30
半年放置しても落ちる板じゃないしあって困るこたないんじゃね
既存のPHPFWのスレは大抵できてんじゃないかな？kohanaスレとかもあるし
101:nobodyさん
10/12/26 20:03:18
よーしパパLithiumスレ立てちゃうぞー
102:nobodyさん
10/12/26 21:46:11
Yiiは見た感じ良さそうだった。symfonyとYiiで行こうぜ。
日本人が言語やFW開発しても意味ないから、それだけはやめてくれよな。
103:nobodyさん
10/12/26 21:52:10
>>98
ベンチマーク自体意味無しって言ってるのね。
枯れた技術とか学習コストって言ってるのも、「英語を読めない日本人PHPer」限定の話でしょ。
フレームワークの性能評価としては関係ないね。
実際は乗り換え学習コストなんてたいしたこと無いし。
104:nobodyさん
10/12/26 22:55:05
>>103
Hello Worldでパフォーマンスの優位性を語ることに意味は無いって事。
静的な文字列を出力するだけのWEBアプリなんて、今日日存在しないだろう、
せめてDB接続用インスタンスを生成したり、各種ユーティリティクラスを読み込んだ上で実測しなきゃね。
＞枯れた技術とか学習コストって言ってるのも、「英語を読めない日本人PHPer」限定の話でしょ。
逆だろ、一部の自称ギーク限定で新しいモノを導入したがっているだけでしょ。
英語読めても職業PGの応用力の無さでは、新しい物を自力で吸収するのは難しい、
ググレば日本語でかみ砕いた情報が得られるFWと、学習コストは比較にならんよ。
105:nobodyさん
10/12/26 23:07:35
YiiとSymfony ってどっちが学習コスト低い？Kohanaは？CakePHPは？Zend Frameworkは？
学習コストでソートするとどんな感じ？
106:nobodyさん
10/12/26 23:17:34
>>104
それははベンチマークの一番最初の疑問だろうけど、じゃあ公平な評価法は何ってこと。
Why "Hello World"の反論になってないよ。
URLﾘﾝｸ(code.google.com)
107:nobodyさん
10/12/26 23:27:10
>>106
＞Why "Hello World"の反論になってないよ。
反論以前の問題。公平な方法が無いからHello World？
それなら極限までそぎ落とした俺の自作MVCフレームワークの方が数倍軽いかもね。
フレームワークとしてのパフォーマンスじゃなくて、
「HelloWorldを行うには最速」って表現ならいいんじゃない？
それでパフォーマンスの優位性語られても、まっとうなPGなら疑問を抱くだろうけど。
108:nobodyさん
10/12/26 23:46:32
極論出たね。
なんでHelloWorldで”オーバーヘッドを測る”のが「HelloWorldを行うには最速」とかにすり替えるんだろう。
自作のフレームワークがここにならぶのと遜色無い機能を持ってるなら「自作MVCフレームワークの方が数倍軽いかもね。」と自慢してもいいよ。
URLﾘﾝｸ(www.phpframeworks.com)
でもそうじゃないでしょ。
109:nobodyさん
10/12/26 23:50:30
じゃあ他の部分は遅いのYii？
110:nobodyさん
10/12/26 23:59:34
たかがHello Worldって文字出すだけですらこんなに差が出るって考えると
なんだかんだで必要なロジックの選択はよく出来てるってことなのかな
ようは余計な処理とか通さないようにできるってことだよね
つーか、新しいものは金にするチャンスなんだから
既存のーとか枯れたーとか、そういう保守的なスタンスは儲けないよ
まぁ今日日PHP自体がアレなんだけれど
111:nobodyさん
10/12/27 00:09:21
どのFrameworkがいいかなんて比較やってことないし、俺にはわからんが、
結局明確なデータに基づいた比較を行ったわけでも、ソース持ってきてるわけでもなしに、
俺がこう思ってるから俺は正しいって叫んでるだけじゃ
資料もスライドもなしにプレゼンするくらい馬鹿なことだと思う
112:nobodyさん
10/12/27 00:10:32
FWって速度が評価基準なの？
開発効率のために用いるものかと思った。
113:nobodyさん
10/12/27 00:13:09
ベンチマーキングの意味は>>106に書いてあるとおりで、こうも書いてある。
＞Do not interpret the numbers alone
＞The benchmarking results should NEVER be interpreted alone.
＞The server configuration and the way of running the benchmarking applications could affect the results significantly.
＞And do not choose a framework purely based on this benchmarking result.
＞You should consider many other factors, such as feature set, documentation, code quality, user community, technical support, etc.
＞We all know that using a plain PHP script would easily beat any of the frameworks in performance comparison.
ここに書いてあることがフレームワーク選びの正論だろ。
そのうえで「ベンチマークなんて意味無い」ってフレームワークの性能向上を否定しちゃうのは
やっぱり自分が使っている技術が廃れる事への恐れがあるんだろう。
114:nobodyさん
10/12/27 00:15:09
Symfony2使っとけばno problem
115:nobodyさん
10/12/27 00:16:10
>>107
＞自作のフレームワークがここにならぶのと遜色無い機能を持ってるなら「自作MVCフレームワークの方が数倍軽いかもね。」と自慢してもいいよ。
＞URLﾘﾝｸ(www.phpframeworks.com)
ここに並ぶフレームワークとしての機能を使っていないベンチマークで、
パフォーマンスの優位性を語る事は出来ないって事だよ。
Yiiは遅延読込を積極的に採用しているから、Hello worldには強いかもしれないが、
実際に諸々のロジックを実装した場合、どれだけ差が出るのか解るの？
＞でもそうじゃないでしょ。
俺のFWはMVCの基底部分だけ自作だから、Hello Worldは最速かな。
内部ファンクションコール数で言えば数回じゃないかな。
他のFWと連携出来るようになってるから機能的には遜色無いどころか多すぎて困るかもね。
116:nobodyさん
10/12/27 00:22:23
>>112 が書いてるように、大抵は開発効率向上の為に導入するんじゃない？
明確なソースも資料も無しに、Yiiは凄い！とか言ってる人はただのミーハーな開発者としか思えない。
本当に素晴らしいと思うなら、率先して普及活動を行えばいいと思うよ。
Hello World最速なのはわかったから、具体的に他のFWから乗り換えるメリットを提示すればいい。
>>113
＞Do not feel attacked¶
＞This project has no intention to attack any framework. On the contrary, it tries to help frameworks to find out their performance bottlenecks and make improvements.
Hello Worldのパフォーマンスがフレームワーク選定にはさほど重要では無い、と書いてある気がするのだが･･･
117:nobodyさん
10/12/27 00:26:10
結局どのフレームワークを使えばいいんだよ
皆投票してね
CakePHP
Symfony
ZendFW
Yii
Ethna
kohana
俺俺FW
118:nobodyさん
10/12/27 00:33:12
CakePHP
Symfony 1
ZendFW
Yii
Ethna
kohana
俺俺FW
119:nobodyさん
10/12/27 00:34:55
>>117
選定基準による。
日本語情報はいる？ドキュメントはいる？IDEは使う？ActiveRecordが欲しい？開発規模は？etc･･･
120:nobodyさん
10/12/27 00:43:37
>>119
日本語情報いる
ドキュメントいる
IDE使わない
ActiveRecord欲しい
開発規模は会員10万人ぐらいのブログ機能
これでお願い
121:nobodyさん
10/12/27 00:50:44
使うほうのことは関係なくて、開発効率だけのためにFW選ぶのも何か違う気はしないでもない
122:nobodyさん
10/12/27 00:56:00
>>120
無難にCake/Symfony/Zendのどれかじゃないかね。
>>121
ユーザはフレームワーク以前に、PHPかどうかすら気にしないだろう。
123:nobodyさん
10/12/27 00:56:10
いやだって速度で言ったら素のPHPが一番に決まってるじゃん
124:nobodyさん
10/12/27 00:59:25
その速度の差がユーザーエクスペリエンスにどの程度影響するんだって話だろ
125:nobodyさん
10/12/27 01:01:03
123は121宛だよ
126:nobodyさん
10/12/27 01:03:42
開発効率や速度をだすことより、会社が儲かることが大切だと上は言う。
127:nobodyさん
10/12/27 01:05:09
無難にというか、日本語しか駄目ならCake・Symfony・Zendだけしか選択肢ないだろ。
英語のドキュメント読むスキル無いとキビシーわ。
128:nobodyさん
10/12/27 01:07:39
PHPみたいな言語を使う人らからすると、この言語の壁はでかいよなぁ
129:nobodyさん
10/12/27 01:07:43
英語のドキュメント読める奴って、PHPプログラマ10人に1人いるかどうか
130:nobodyさん
10/12/27 01:08:37
馬鹿に組ませた素のPHPより、低速なフレームワークを使ったほうが
数百倍マシだったりするけどなｗ
131:nobodyさん
10/12/27 01:09:46
>>124
そういう実用レベルの話であれば、
ネットワーク、ディスクI/O、CPU等のハードウェアの増強をして、
APCやmemcached等のチューニングを行って、
HTML/CSSのチューニングを行う、
のが普通。
フレームワークの最小オーバーヘッドがユーザエクスペリエンスに影響するのなんて、
根本的に設計がおざなりな場合くらいじゃね？
クラウドのおかげもあり、ハードウェアの増強が最も費用対効果が高いけど。
132:nobodyさん
10/12/27 01:16:52
バッドノウハウを含む情報量の差も大事だろう。
Cake、Symfony、Zendあたりなら、バグが発生した場合や、規格外の処理を追加したくなった時に、
ググるだけで先人の知恵を得られたりする。
>>126
効率を上げる＝人件費が浮く＝会社が儲かる。だろｗ
PG一人雇うのに数十万の費用かけるなら、同じ金額を機材に当てる方が効率も速度も上がる。
既存の技術なら学習コストも無いようなもの。
133:nobodyさん
10/12/27 01:17:27
>>115
外部依存の俺俺でも「フレームワーク」と言えるの？
開発にそんなの使いたくないんだけど…
134:nobodyさん
10/12/27 01:18:32
英語のドキュメント読める人はどのフレームワーク使ってるの？
135:nobodyさん
10/12/27 01:19:17
PHPの場合、mod_phpで使う事が前提で、ファイルインクルードだとかのロードタイムが無視できないんだよね。
最近流行のソーシャルゲームみたいなサイトだと。
他の言語だとmod_perlだとかFastCGIだとかPassengerだとかで、複雑なクラス構成のアプリケーションでもいったん立ち上げてしまえば高速に動かせるアプリケーションサーバ環境があるけど。
まあ、フレームワーク以外にも、SQLを見なおすとかコーディングレベルで改善出来る余地がある場合も多いけど。
136:nobodyさん
10/12/27 01:25:47
>>133
外部依存かどうかは関係無いよ。
Symfonyだって積極的に外部ライブラリを取り込んでいる。
137:nobodyさん
10/12/27 01:28:19
本当にSymfonyできるやつでてこいやー
いるわけないか･･･
138:nobodyさん
10/12/27 01:34:36
＞無難にというか、日本語しか駄目ならCake・Symfony・Zendだけしか選択肢ないだろ。
Symfonyやったことないんだなｗ
139:nobodyさん
10/12/27 01:41:41
test対応も評価条件に
140:nobodyさん
10/12/27 01:53:58
ﾜﾗﾀｗ
レスするだけなら誰にでも出来るわなｗ
141:nobodyさん
10/12/27 02:31:49
OpenPNE3はsymfony採用してたけど、さすがにあれは重すぎじゃね？
symfonyのせいなのかあれは。
俺にはわからん。
142:nobodyさん
10/12/27 08:14:49
>>135
＞PHPの場合、mod_phpで使う事が前提で、ファイルインクルードだとかのロードタイムが無視できないんだよね。
(snip)
＞他の言語だとmod_perlだとかFastCGIだとかPassengerだとかで、
(snip)
そんなときこそ、php-fpm (fast CGI process manager)を導入してみては？
143:nobodyさん
10/12/27 23:43:52
test
144:nobodyさん
10/12/27 23:53:32
すると独自フレームワークが必要になるな。
145:nobodyさん
10/12/27 23:56:46
3大FWは機能が多すぎる
皆そんなに仕事で大きなシステム作ってるんか？
146:nobodyさん
10/12/28 02:15:49
３大FWって、Kohana, Yii, ちいたん のことか
147:nobodyさん
10/12/28 12:14:19
>>145
普通にCRUDでデータをひと通り処理するシステムだと小さくてもFW使っちゃうな。
148:nobodyさん
10/12/29 01:05:57
必要ない機能があってもそれを通さないならさして問題ない
コード記述量が減らせるならFWを使う意味はそれだけでも出てくるんじゃね
149:nobodyさん
11/01/07 18:56:09
※ただしLazy Loading を実装したFWに限る
150:nobodyさん
11/01/09 03:13:49
> ３大FWって、Kohana, Yii, ちいたん のことか
よく分かってらっしゃる。
面白いネタフレームワークだと思ってるから、
それをだしたんだろ？
151:nobodyさん
11/01/09 17:41:12
落ち担当のちいたんはさておき、前者2つは比較的新しいから期待は出来る
152:nobodyさん
11/01/10 15:52:37
なにを期待？
153:nobodyさん
11/01/14 21:16:48
先生の次回作に期待
154:nobodyさん
11/01/15 00:35:15
打ち切り
155:nobodyさん
11/01/22 23:03:09
最近分かった
所詮phpはHTMLに簡単に上書きするだけの用途以外では使うべきじゃない
フレームワークをphpで作るのは無謀
156:nobodyさん
11/01/22 23:15:20
いまさら分かったのかい
で、Webアプリケーションを構築するのに最適な言語は何だと思う？
157:nobodyさん
11/01/23 00:06:42
「最適」なんてないのさ
158:nobodyさん
11/01/23 22:47:33
>>156
しava
159:nobodyさん
11/01/24 02:15:15
>>155
どんな経緯でそういう結論になったのか気になるな。
単に使いこなせなて無いだけじゃね？
160:nobodyさん
11/01/24 21:51:22
フレームワークをPHPで ”作る" とか
言ってる時点で、なんちゃってプログラマでしょｗ
161:nobodyさん
11/01/25 13:46:17
まぁ低レベルは、PHPですらフレームワークを使えないし、
デザインパターンも知らないし、PHPでオブジェクト指向ｗとか言う。
かといってJavaでバリバリ組めるわけでもない。
あんた何ができるのさっ？って言ったら、
「PHPをベタで組む！その方が早い！クラスなんて作るな！」と
162:nobodyさん
11/01/25 18:06:16
デザインパターンかじって底辺プログラマ相手に優越感浸ってる連中が一番無駄にコストかかるよな
せめて東大大学院卒で世の中に一石を投じるアルゴリズムの一つや二つ作れるぐらいになってから偉そうにソファーに踏ん反り返って欲しいものだ
163:nobodyさん
11/01/25 18:12:17
ちゃんと板の間に正座してプログラムしてます
164:nobodyさん
11/01/25 19:57:46
底辺プログラマだってデザパタぐらい使いこなせる
底辺プログラマだってSymfonyぐらい使いこなせる
底辺プログラマだって頑張って生きている
165:nobodyさん
11/01/25 20:19:20
そうだそうだ死んでいるような顔色してたってよく見ると生きてるんだぞ！
166:nobodyさん
11/01/26 06:30:45
底辺は1メソッドのなかに全てのやりたいことを書いてるんじゃないかってくらいメソッド分けもできんぞ
そんな奴の書いたコードでバグの修正とかまじうんざりする
にわかでもある程度自分で考えてかじってる奴のほうが数倍はいいぞ
167:nobodyさん
11/01/26 17:49:51
昔のままの俺だと思ってんじゃねえよ！
参考にするソースが悪すぎただけだろ
1メソッドで一つのことしかしないことぐらい独学済み
人はいつでも成長している。底辺プログラマだってだ
168:nobodyさん
11/01/26 21:25:24
1メソッドの長さとか、もうそういうことは我慢する
変数名に数字のsuffixついてたりも目を瞑ろう
だから
「ｘｘｘのとき呼ばれる処理」
その一言で全てを説明した気になってるんじゃねええよおおおおおおおぉぉォォォォーーーッッ！！
メソッドに分解ができないなら、その分岐、ループの意図するところくらいコメントに残せよばーか
で、ここ何の愚痴スレだっけ？
169:nobodyさん
11/01/26 21:26:33
それだけ自分が低レベルな環境に身を置いているってことだろ
170:nobodyさん
11/01/26 21:44:33
速度優先な事もあらーな
171:nobodyさん
11/01/26 21:53:08
関数で組むのと、オブジェクティブに組むの、どれぐらい速度変わる？
172:nobodyさん
11/01/26 22:09:47
何の速度が？
173:nobodyさん
11/01/27 00:45:18
処理速度
プログラムのことは全く知らないが、
オブジェクトの大きさや生成したインスタンスの数によって変わるの？
174:nobodyさん
11/02/02 22:56:35
私は、配達時間の関係で仕方なく朝日新聞を読んでますけど、愛読者では有りません。あんなものは愛読するものでは有りませんよ。在宅勤務になった
ので４月から読売に替えました。朝日新聞を読んでいると、カルト宗教の機関紙を読んでいるような気分になる。とてもじゃないけど子供には読ませら
れないので、本来なら「新聞ぐらい読みなさい」と言うべきところを「朝日はおかしいから読んではいけません」としか言えないのが悲しい。漢字が奇
妙な当て字が多くて、熟語も一部がひらがなになってる。近頃はその傾向が顕著だ。そこで本社に電話して尋ねてみたところ「韓国を見習って、少しず
つ漢字を減らして、やがて日本語から漢字を全廃させる方針」だそうだ。こんなことは国民の総意で決めるべきこと。一新聞社が決めて実行するのは僭
越だ。何を考えているのだろう。ともかく戦争反対というのも訳分からん。湾岸戦争のときも「日本が巻き込まれるからクウェートを助けに行くな」と
いうキャンペーンを張った。侵略者はみんなで寄ってたかってやっつけなければいけないのにおかしいぞ。そして他国が苦労して築き上げた平和は、当
然の権利として享受しようというのでは、日本が侵略されたときに助けてくれる国は居ないだろうに。昨年９月11日のアメリカでの同時多発テロの首謀
者であるオサマ・ビンラディンについては必ず敬称をつけるように徹底させている。テレビ朝日でもゲストコメンテーターに「必ずオサマ・ビンラディ
ン氏というように氏をつけて発言してください」と徹底させているし、朝日新聞本紙では、今でも必ず敬称をつけている。恐いのは外国の人がオサマ・
ビンラディンと呼び捨てにして発言しても翻訳では勝手に「オサマ・ビンラディン氏」に変えてしまうことである。これでは正しい報道とは言えない。
冷酷な人殺しをここまで敬うその心理は如何に。朝日新聞は、いつのまにか宗教になってしまったのではないだろうか。しかもカルトと呼ばれる変な宗教に。
175:nobodyさん
11/02/15 12:17:21
cakeの次スレは立たないのか？
176:nobodyさん
11/02/15 20:06:35
cakephpスレ立たないところを見ると
既に終わったFrameworkってことかな？
177:nobodyさん
11/02/15 20:17:58
2chがすべてという価値観の人間にはそう思えるかもしれんが
普通は2chにスレが立つ立たないでそんなこと考えないだろう
178:nobodyさん
11/02/15 23:55:17
Cakeの次スレはLithiumが乗っ取ります
179:nobodyさん
11/02/16 00:22:24
cakephpで質問です。
idを主キーにしていて
データの取り出しで
this->model->
findAllByName($hoge)
として
this->model->save($this->data)
した場合、上書き更新ではなく新レコード挿入になりますよね？
主キーでモデルのデータを取り出さない限り新レコード挿入になるのは分かるのですが、CakePHP仕様だと主キーを一つしか扱えないのでupdateAll()を使うしかないのでしょうか？
主キー以外のフィールドでの検索対象の
レコードを更新したい場合、
スマートなやり方だと、どういうやり方が一般的でしょうか？
180:nobodyさん
11/02/16 00:25:32
オイラもcakephpで質問！
生成されたpotを弄ってviewの中のctpファイルはローカライゼーション出来るようになったんだけど、
バリデーション(モデル)とか
プログラム上での(コントローラー)表記を
ローカライゼーションしたい場合は
どうしたらいいの？
181:nobodyさん
11/02/16 01:58:37
CakePHPスレ立てろよｗ
182:nobodyさん
11/02/16 04:17:51
このスレッドは、【PHP】フレームワーク CakePHP 11ホール目【v1.3】になりました。
183:nobodyさん
11/02/16 12:04:28
建ててもいいけどテンプレしらないからここに張ってくれれば良いと思うよ
184:nobodyさん
11/02/16 17:04:29
CakePHPはオワコン
185:nobodyさん
11/02/16 17:07:56
PHP5.3もまともに対応してないフレームワークとか使えねえよ
186:nobodyさん
11/02/16 18:05:46
というわけでLithiumが始まります。
Symfony様、ZendFW様、CodeIgniter様、お疲れさまでした。
187:nobodyさん
11/02/16 21:55:42
情弱なオレに教えてくれ
cakeって5.3に対応する気ある？
188:nobodyさん
11/02/16 22:37:06
というかもう対応してる。
189:nobodyさん
11/02/16 22:40:09
どこが対応しているのですか？
error_reportingを甘くしないとエラーでまくりですよ
190:nobodyさん
11/02/16 22:42:13
warnじゃなくてerrorが出るんだっけ？
191:nobodyさん
11/02/16 22:54:59
URLﾘﾝｸ(blog.goo.ne.jp)
これか？1.3系で解決してるとよ
URLﾘﾝｸ(trac.cakephp.org)
5.3、5.3と煩いようだが
みんなそんなにラムダや無名関数を使いたいのか？
Lithium使っとけ。
192:nobodyさん
11/02/17 01:02:00
CakePHP1.3系のDeprecated errorはうざすぎて開発に支障をきたすレヴェル
193:nobodyさん
11/02/23 02:49:02.24
結局、どのフレームワークが一番のおすすめなの？
194:nobodyさん
11/02/23 02:55:45.82
結局は自分で触ってみないとわからない
195:nobodyさん
11/02/23 14:01:12.13
毛深いのはあまり好きではありません
196:nobodyさん
11/02/23 23:05:12.94
ならLithiumだな。ツルッツルだよ
ちいたんは、ぱっと見はツルツルだが中の方は結構、癖毛もち
197:nobodyさん
11/02/26 11:38:36.81
LithiumはCakeと比べると機能はライトかい？
198:nobodyさん
11/03/05 12:37:56.82
天下のツイッター様はPHPのフレームワークなんて使わないよ。
199:nobodyさん
11/03/05 19:46:45.73
俺の周りではPHP5.3導入を検討し始めているクライアントが増え始めてるから
警告ばっかりでるCakePHPなんて使わない
高速に開発するフレームワークなんてこれ以外にもあるし
手っ取り早く作るならCodeIgniterお勧め
200:nobodyさん
11/03/06 13:47:41.75
CakePHPは学ぼうにも参考書に地雷しかないからな
クックブックが一番わかり易いというのが、初心者におすすめできない痛いところ
201:nobodyさん
11/03/06 13:55:20.83
>>200
ニコ生ユーザー？
202:nobodyさん
11/03/07 21:48:59.30
CodeIgniterのスレが落ちてたので誰か立ててくださ
一応テンプレらしくしてみたもの用意
■公式サイト
URLﾘﾝｸ(www.codeigniter.com)
■チュートリアル
URLﾘﾝｸ(codeigniter.com)
■CodeIgniter User Guide （公式マニュアル）
URLﾘﾝｸ(codeigniter.com)
■CodeIgniter ユーザガイド 日本語版
URLﾘﾝｸ(codeigniter.jp)
■前スレ
[PHP][フレームワーク]CodeIgniterスレ
ｽﾚﾘﾝｸ(php板)
203:nobodyさん
11/03/12 09:57:31.43
しかしCodeIgniterも時代遅れ感が・・・
204:nobodyさん
11/03/12 10:13:06.06
それcakephpの事じゃね？
CIは今流行りだしてる訳だが
205:nobodyさん
11/03/13 00:12:45.45
流行ってはいないｗ
良くも悪くもPHP5のFWは決定打が無い感じだよな
206:nobodyさん
11/03/13 02:12:53.32
PHPだから仕方がないな！
207:nobodyさん
11/03/13 10:37:54.66
いや流行ってるよ
むしろCakeは衰退している
208:nobodyさん
11/03/13 11:34:32.07
すでにCIを使ってる人はいいが
今から使い始めるのは考え物だ
209:nobodyさん
11/03/13 15:28:36.79
>>207
何をもって流行ってるの？
CIはFW過渡期に高速軽量って事で鳴り物入りしたが、普及してないイメージしかないんだがｗ
Cakeは衰退と言っても固定層がかなりいる。
210:nobodyさん
11/03/13 16:05:56.36
なんだかんだで知らないことを覚えようとする奴はすくねーからな
もうカビが生えててもCakeしか食べ物を知らない連中はいっぱいいる
211:nobodyさん
11/04/09 21:57:32.05
会社で採用されてるのがcake。
しにたい。
212:nobodyさん
11/04/10 00:01:31.03
>>211
どのフレームワークだったらうれしいのよ？
213:nobodyさん
11/04/10 01:28:56.40
まあPHP４は考慮してなくていいよな、さすがに
214:nobodyさん
11/04/10 11:32:17.85
cake使うならkohana使えよ
php5.2はサポート打ち切られたのにphp5.3に対応してないFWなんて使うなよ
215:nobodyさん
11/04/10 13:24:51.31
kohanaは尚早な気がするね。
216:nobodyさん
11/04/11 11:15:32.36
＞php5.3に対応してないFW
CakeはPHP5.3でも動くよ
217:nobodyさん
11/04/11 11:37:27.61
動くと対応しているはイコールでは無い件
ソースコード読んでから書いたほうが良いかもよ。
218:nobodyさん
11/04/11 12:28:07.11
>>214
5.3に対応していないってソースありますか？
FW選定の資料のひとつにしたいので。
219:nobodyさん
11/04/11 14:40:13.25
>>217
意味がわからんが
部分的に動かないところがあるってこと？
220:nobodyさん
11/05/20 09:38:28.92
Cake使ってる理由 ＝ 名前が美味しそうだから
Symfony使う理由 ＝ エレガントかつ高速な設計を追及したいから
ZFを使う理由 ＝ Zendっていう名前が付いてるからなんとなく安心
結論：Symfonyを使う人間が一番賢い。
みんなのdailymotion様も、Symfonyで大量アクセスを捌いておられるのだ。
これからはSymfonyをメインで使い、内部的にSmartyやZF等を使う方法が主流となる時代がやってくる。
221:nobodyさん
11/05/20 11:23:51.69
えっ
222:nobodyさん
11/05/23 12:19:46.87
>>218
cakephp自体がソースとして読める形なんだから嫁よ
223:nobodyさん
11/05/27 10:24:38.31
Yiiが良い
224:nobodyさん
11/06/18 17:10:48.95
結局どれがいいんだいっ!!
225:nobodyさん
11/06/18 17:20:26.63
ZF
226:nobodyさん
11/10/23 14:34:18.24
ethna
227:nobodyさん
11/10/24 01:19:05.33
CI2はPHP4切ってるんだろ？
使ってる人どう？
228:nobodyさん
11/10/24 13:32:17.87
>>227
Kohana3に移行してたから気付かんかったわ
229:nobodyさん
11/11/02 08:41:44.67
ci終了のお知らせ
230:nobodyさん
11/11/03 18:10:44.29
まだだ、まだ終わらんよ
231:nobodyさん
11/11/03 18:21:16.30
すべてが遅すぎた
232:nobodyさん
11/11/28 02:13:13.00
はじめまして、相談させてください。
「よくわかるPHPの教科書」という初級本を一冊読んだだけのPHP勉強したての見習いWEBデザイナーです。
以下のサイトのような情報サイトを作ろうと思っております。
URLﾘﾝｸ(www.nightstyle.jp)
この後、何かのPHPフレームワークを勉強して作ってみたいと思うのですが
どのフレームワークを勉強していったほうがいいのか分かりません。
アドバイスいただけませんか？ よろしくお願いします。
233:nobodyさん
11/11/28 02:30:39.13
>>232
宣伝乙
234:nobodyさん
11/12/08 00:49:58.91
認定脳
235:nobodyさん
11/12/09 23:07:04.62 nHunuLCR
ここ1週間くらいCakePHPの入門書読んできてフレームワークがどんなものかは理解したけど
cakephpってhtml5とか対応してないっぽいしもっといいフレームワークあるの？
日本語の資料が多いもので認証機能とユーザごとにアクセス権限(cakephpのauthとACL)があるものって他にある？
やっぱり無難なのっていうとcakephpになるの？
236:nobodyさん
11/12/09 23:17:23.11
>>235
HTML5のどこに対応してないって言ってる？
ほぼほぼHTML5に対応してると思うんだけど。
237:nobodyさん
11/12/10 00:12:37.51
1週間Cakeの入門書を読んだだけで、フレームワークを理解した気になってる時点で･･･('c_`
AuthもACLもメジャーフレームワークは全て実装されてる。
そもそもHTML5対応って何を指してるの？ｗ
238:235
11/12/10 12:24:35.06
html5対応じゃないって言ったのは$html->doctype()がまだ古いほうだったりhtml5で追加されたタグは$html->tag()使わないとだめだったりするところ
それくらい我慢しろって言われたらそれまでだけどやっぱり気持ち悪い
日本語の入門書籍とかcakephp辞典みたいな命令一覧が充実してるメジャーフレームワークってcakephp以外にあるの？
あとだれもフレームワークをすべて理解したとは言ってないぞｗ
239:nobodyさん
11/12/10 13:20:09.06
いまからやるならyiiのがいいんじゃね
まぁメインにするのがないときは浅く広くやるほうがいいと思うけど
240:nobodyさん
11/12/10 16:06:08.20
>>238
doctypeもhtml5のフォーム要素も対応してるんだけど
241:nobodyさん
11/12/10 16:52:05.33
$html->doctype()と書いている時点で
おそらくそれは1.3系以下の情報ですので、勘違いしていますよ
2.0系ではhtml5のフォームinputをサポートしています
あと書籍や日本語の情報などは、自分で容易に調べられますよね？
242:235
11/12/10 17:12:37.55
検索してヒットすれば日本語の資料があることはわかるけど
ない場合本当にないのかわからないから聞いてるんです
どうせおまえら知ってて教えてくれないんだろ
243:235
11/12/10 17:18:52.08
そもそもメジャーフレームワークってなんなのさ？
244:nobodyさん
11/12/10 17:25:42.34
とりあえず涙拭け
245:nobodyさん
11/12/10 20:31:41.62
cakephp = 情弱
246:nobodyさん
11/12/10 21:17:00.25
きちんと更新されてて日本語の最新の情報があるフレームワークってどれ？
どこかに比較表ないの？
247:nobodyさん
11/12/10 21:44:23.87
cakephpはほんとに日本語ブログの情報が減って来てる
あっても1.1とか1.2のものばかり。(07~09年あたりに書かれたものばかり)
2.0もcookbookの解説が未だに英語のまま。リファレンス本も出ない。
今から始める人にはつらい環境です。
248:nobodyさん
11/12/10 22:00:22.74
>>246
今、PHPのフレームワーク界隈で一番話題になってるのは
間違いなくCodeIgniterだな
日本語ドキュメントもかなり充実してる
249:nobodyさん
11/12/10 22:38:31.14
>>248
CodeIgniterってプラグイン系はどうなの？
アジア圏で利用ユーザーが多いらしいから、そっちの
人達がいっぱい作ってたりするのかな。
日本語ドキュメントの充実には同意。
あれは他のフレームワークも見習うべき。
250:nobodyさん
11/12/11 04:43:07.24
間違いなくCodeIgniterが盛り上がってるとかは、半年前の話です
今はライセンスの問題で敬遠されがちになっているのが現状ですよ
CakePHP, Symfony, Yii, FuelPHPらへんで選べば問題ありません
251:nobodyさん
11/12/11 19:02:03.74
ネタだろ？
一番話題になってるのは確かだし
でも、ユーザ会のMLで今後どうするかとか話し合ってるのに
初心者に泥船勧めちゃダメだろｗ
ciからの乗り換えだったらfuelは時期尚早な気がする
kohanaの方がよさげ
ci乗り換えとかじゃなく普通にこれからやるならyiiがお勧め
252:nobodyさん
11/12/11 21:57:25.39
kohanaも尚早な気がするね
まだ安定して無くて元気がありすぎるわ
253:nobodyさん
11/12/12 01:45:14.04
なんだかんだでyiiが鉄板になりそうな気はするよ。便利
254:nobodyさん
11/12/12 03:54:51.16
自分もyiiですねー。PHPフレームワーク4つくらい触ってきましたが、ダントツですばらしいです。
255:nobodyさん
11/12/16 23:12:15.19
fuelphpなんざまだ利用者少ないからバグばっかりで使い物にならねえよ
256:nobodyさん
12/01/14 20:02:17.79
CakePHPとSymfonyどちらを習得するか悩んでいるのですが、
個人開発でコードを管理しやすいのはどちらだと思いますか？
257:nobodyさん
12/01/14 23:01:14.11
個人開発ならどっちも違うんじゃね？ チームワークし易いように、多少面倒が増えてもコードを細分化させてるFW達だし。
258:nobodyさん
12/01/17 10:05:43.01
codeigniter はオワコンなんですか ; _ ;
259:nobodyさん
12/01/17 12:17:06.21
コンテンツとしては終わってないが、日本のコミュニティは終わった。
260:nobodyさん
12/01/17 20:25:25.28
Phalanger 3.0 (2012年1月) をリリースしました。
ｽﾚﾘﾝｸ(poverty板)
261:nobodyさん
12/01/20 01:08:59.07
YiiとCakeの比較をどなたかお願いします
262:nobodyさん
12/01/24 17:49:32.46
ARとかORMは正直いらんと思う
いやむしろ存在自体が悪ですらある
263:nobodyさん
12/01/26 12:41:17.56
ならお前はそう言い続けていればいい
264:nobodyさん
12/01/31 01:37:29.87 vL8UhXp0
拡張子が.jsだったら自動的に難読化してくれるフレームワークなんてありますか？
そんな便利なのないですかね？
265:nobodyさん
12/01/31 02:29:11.63
httpdのフィルタで出来そう
266:nobodyさん
12/01/31 03:44:28.12 vL8UhXp0
>>265
マジっすか？！
267:nobodyさん
12/01/31 08:21:57.07
>>266
URLﾘﾝｸ(phpspot.org)
しかし記事の下に可読化の方法のリンク有り
268:nobodyさん
12/01/31 19:56:17.06 wEgOhILt
cakeって複合の主キー使えないの？ 不便じゃね？
他のフレームワークでは使えますでしょうか？
269:nobodyさん
12/01/31 20:29:55.91
>>268
複合キー使えるようにできるよ
270:nobodyさん
12/01/31 20:30:57.44 wEgOhILt
>>269
そうなの！ ｋｗｓｋ
271:nobodyさん
12/01/31 21:32:10.28 mg92XRmL
ビューはJavaScript使ってクライアントサイドだけでやるわ
モデルのSQLは自分で書くわ
という仕様のアプリケーション向きのフレームワークってある?
272:nobodyさん
12/02/01 14:26:40.09
jQuery
273:nobodyさん
12/02/02 00:52:23.33
JSDB
274:nobodyさん
12/02/03 00:28:14.26
cakePHPっての使ってみたいんですが、
これってトップディレクトリに設置しないとダメなんですか？
できれば、
URLﾘﾝｸ(192.168.0.111)
の下とかで試したいんです。。
275:nobodyさん
12/02/03 00:36:17.07
その方式でいいんですよ。
httpd.confに
Alias /test "/opt/lampp/test"
<Directory "/opt/lampp/test">
Options FollowSymLinks Includes ExecCGI
AllowOverride All
Order allow,deny
Allow from all
</Directory>
こんな感じで。
276:nobodyさん
12/02/03 21:47:49.01
>>275
どもでした。やってみます。
277:nobodyさん
12/02/05 14:31:16.93
Zend frameworkを鯖に入れて使ってみたいのですが
eclipseでの開発はどうやるのが良いのでしょうか？
ググるとZend Studioを買えと出てくるのですが、
貧乏なので、無料でやりたいのです。
linuxテスト鯖 + (windows+eclipse)クライアントで
便利にやる場合の、ベストプラクティスがあったらお願いします。
（クライアントは別にeclipseじゃなくても良いです。これまでずっとeclipse使ってたので続行したいだけで。。
こっちのほうが良いってのあれば、それも教えてください。）
278:nobodyさん
12/02/05 15:35:53.65
>>277
つnetbeans
279:nobodyさん
12/02/05 21:03:47.39
>>278
ｔｈｘです。tryしてみます。
280:nobodyさん
12/02/07 00:40:55.32
つvim
281:nobodyさん
12/02/13 19:19:09.37
@methane INADA Naoki
phpはFacebookのような大規模サイトでの運用実績があります（ただし自分でVMを開発する程度の技術力が必要です）
URLﾘﾝｸ(twitter.com)
@methane INADA Naoki
Facebook が Python で書かれていたら、Hiphop PHP や Hiphop VM を作らなくても、CythonかPyPyを使うだけで済んだだろうに。
URLﾘﾝｸ(twitter.com)
282:nobodyさん
12/02/16 03:42:55.71
アメリカでもPythonのコーダー集めんの手間だってのは意外だわ
283:nobodyさん
12/02/17 01:05:30.34
言語人気はそれほどでもないし、Googleが熱心に勧めてるだけで、いまいち流行ってないじゃん。
284:nobodyさん
12/02/17 17:22:50.75
ガイジン＝Pythonじゃないのか！
285:nobodyさん
12/02/18 01:13:34.11
バカかあんたは。
286:nobodyさん
12/02/18 11:51:39.05
Cakeしか使ったことのない俺に、Yiiのよさを教えてください
287:nobodyさん
12/02/18 12:54:09.20
Yiiはいい
288:nobodyさん
12/02/19 09:12:44.92
Cakeより扱いにくいものってあるの？
289:nobodyさん
12/02/19 10:51:32.51
CodeIgniterは使いにくかった
290:nobodyさん
12/02/19 11:49:31.56
FuelPHPは簡単だった。
291:nobodyさん
12/02/19 23:10:09.07
学習コストがもっとも低いフレームワークをおしえてください
292:nobodyさん
12/02/19 23:34:51.84
学習コストだけならCodeIgniterじゃない？
でも、学習コストでフレームワーク選ぶと痛い目にあるので注意を
293:nobodyさん
12/02/20 00:32:47.80
学習コストが低い＝機能が少ない
だからその辺に転がってる自作フレームワークとかになるんじゃないだろうか
294:nobodyさん
12/02/20 06:04:20.72
要は簡単に覚えられるもんを探しているんだろうと思う
でも作るアプリは一緒なのだから、学習コストはどれも一緒ってなるのに気づいたほうが良い
295:nobodyさん
12/02/20 12:14:38.61
まさに簡単に覚えられるものを探していました。
ＣＩを使っていたのですがライセンスの話がややこしくて他に移ろうと思いまして。
しかし>>292、>>293さんのレスを見てしっかり腰据えて勉強することにしました。
いろいろ比較記事を読んでyiiがよさそうなのでやってみます。
ありがとうございました。
296:nobodyさん
12/02/20 15:43:09.47
Yiiなぁ。いいんだけど、CI使い的には余計なお節介が多いんだよな～。HMVCは楽に作りたいけど、UIはカスタムするからシンプルがいいって時に、無駄に作業増える。
297:nobodyさん
12/02/20 21:08:19.38
それは「使えて」ないからだろ。
298:nobodyさん
12/02/21 00:11:16.86 3wZdUskl
Slimは学習コストが低くていい。
PHPでビューまで面倒みるってやり方はもう見なおしてもいい。
299:nobodyさん
12/02/21 00:30:35.98
Slimは、せめてValidationあったらもっと使うんだが。
300:nobodyさん
12/02/21 00:43:32.64
学習コストっても、マニュアルがしっかりつくってるあるフレームワークなら
やりたいことがでた時に都度みればいいだけじゃん。
301:nobodyさん
12/02/21 08:43:37.33 Ts0sDPGu
>>299
PHP標準のFilterとかPEAR::Validateとかじゃ不足?
302:nobodyさん
12/02/27 17:29:26.13
>>281
こいつバカだろ
CythonとHiphopじゃ全然比較にならない
303:nobodyさん
12/02/29 11:55:36.41
PHPを大規模で扱ってるところは大体PHPのソースコード自体をカスタマイズして使ったりしてるから
C言語ぐらいは使えないとダメだよ
304:nobodyさん
12/02/29 14:34:06.08
>>303
ねぇよｗｗｗｗｗ あるなら具体的事例をだせ
せいぜい拡張作ってるくらいだわ
305:nobodyさん
12/02/29 15:02:35.45
>>303
コナミとか
306:nobodyさん
12/02/29 16:18:55.05
大規模で使ってるとこならそういう事もあるわな
307:nobodyさん
12/02/29 16:33:39.90
>>304
真っ赤にしてやろうか
308:nobodyさん
12/02/29 17:17:06.23
>>305
具体的事例って書いてあるだろ
コナミのどこでどう使われてるんだ。
記事付きでちゃんと出してみろ
309:nobodyさん
12/02/29 17:39:13.19
まぁネイティブなとこまで手を入れるようなことは早々ないから、C必須だってこたないと思うが
出来ないより出来たほうがいいわなぁ
手を入れれるならそれだけやれることが広がるわけだし
310:nobodyさん
12/02/29 17:39:20.94
それくらいも知らない＆探せないような素人に用はない
311:nobodyさん
12/02/29 17:48:00.33
今のゆとりは己の無知を威張りながら人に聞くのが流行ってるんだなｗｗｗｗｗｗ
恥ずかしい奴ｗ
312:nobodyさん
12/02/29 18:24:18.19
教えて君の特徴
・相手の発言を信用してないのに、何故か自分で探して確かめようとしない
・分からないことがあると煽れば相手がムキになると思い、すぐ教えてくれると思っている
313:nobodyさん
12/03/01 01:45:27.49
>>303
大規模だろうと、新規案件でそんなCPも保守の効率も悪い提案通らねぇけどなw
おっさんのC言語云々てテンプレ発言もそろそろ飽きたわ
314:nobodyさん
12/03/01 08:56:41.56
>>309
Cうんぬんは別として、本体いじるのはデメリットの方がはるかにでかいわな。
セキュリティアップデートがあった時とか悲惨
315:nobodyさん
12/03/01 09:00:29.68
>>310
探して見つかるわけがないだろ。お前の虚言妄言なんだからそもそも存在しないもんな。
だからお前はソースを出せないんだろ。
316:nobodyさん
12/03/01 10:51:16.64
まだ言ってるよｗｗｗｗｗｗｗｗ
317:nobodyさん
12/03/01 11:41:12.05
>>314
2行目でお前のレベルが知れてる
318:nobodyさん
12/03/01 12:43:57.52
まあ、古くからの会社なら、部分的に自社のライブラリを使うような、オレオレバッチファイルをアプデの度に当ててる所も多いだろ。
319:nobodyさん
12/03/01 12:46:39.46
本人がソースコードを改変して使うことは無いと断言してるんだからそれでいいんでないかな
一生そういう狭い考え方をしてれば
320:nobodyさん
12/03/02 00:15:48.25
大規模って前提があるから、僧いう事するところは少なくはないって話でしょ
省きたい処理やネイティブで処理させたいことなんていくらでもあるしな
321:nobodyさん
12/03/02 01:09:11.44
そんなとこねーよ
322:nobodyさん
12/03/02 09:22:51.84
個人の趣味の範囲ならともかく大規模こそないわ
それだけのコストに見合ったメリットを説明できないと本体に手を入れたいなんて提案通らないだろ
何人か言っているようにCで作った独自ライブラリを使うとかならわかるけど
323:nobodyさん
12/03/02 10:31:53.55
もうそれでいいよループするから
324:nobodyさん
12/03/02 10:43:15.02
>>312
325:nobodyさん
12/03/02 18:23:47.94
ループが嫌ならソースだせよ
326:nobodyさん
12/03/02 18:30:16.28
自分の脳内妄想を否定されると、相手を悪く言う不思議。
327:nobodyさん
12/03/02 19:08:33.60
企業はどこもそんなに暇じゃないよ
オレオレソース保守管理に人件費かけて、更なるメンテに金かけて
ってアフォな企業を早く知りたいものだｗ
328:nobodyさん
12/03/02 19:11:57.50
>>324
いい加減教えを請われてるんじゃなくて虚言癖を指摘されてることに気付こうぜ
329:nobodyさん
12/03/02 22:56:22.69
レベル低い同士頑張れや
330:nobodyさん
12/03/03 11:27:25.89
しかしさ、CI系とCake系の違いってなんだろうね。CI系で充分効率いいと思うをだが。Cakeとか覚える事一杯あっても、ちょっと便利なコマンドがつかえるくらい。
331:nobodyさん
12/03/03 11:47:11.42
小波はドラコレでPHP使ってなかったっけ
たぶんぐぐれば講演レポが出てくる
332:nobodyさん
12/03/03 12:06:12.74
大規模でPHP使ってるとこは大体ソースコード自体をカスタマイズして使ってると豪語した人、
早くこれの情報源を
何社ぐらい調査したのかもよろ
333:nobodyさん
12/03/03 12:12:50.27
CIは縛りが緩い
cakeは縛りがキツイ
大人数で作業するなら縛りがあるほうがいい
少人数で作業するなら縛りがないほうが楽
334:nobodyさん
12/03/03 12:14:28.75
>>332
そんな偉そうな態度で知識の浅い人に親切に教えてくれる人はいないよ
335:nobodyさん
12/03/03 12:20:34.10
逃げちゃったんだよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
言いだしっぺ逃亡につき何一つソースも無く誰もわからないまま幕引き
336:nobodyさん
12/03/03 12:24:28.03
うん、それでいいっす
こちらは教えても特無いからね
337:nobodyさん
12/03/03 12:29:44.34
きっと逃げ足速い人は、大規模でPHP使ってるとこほとんど回りつくして
ソースコードレベルで確認できる立場の大人物なんだよ。
コンサルティングとかだとソースコードレベルまで見れないかもだからハイパーメディアなんちゃらとかいうやつだな
338:nobodyさん
12/03/03 12:58:41.06
>>310=334さん意外誰も知らない、いくら探しても見つけられないソースを出すことで、
この不毛な争いに終止符をうつことができるんです。
探せないって言ってるくらいだから、きっと探せばソースはあるとおもうんです。
>>310=334さんだけが知っているその記事、是非拝見したいです。
それともくだスレで質問すれば出てくるのかな？
虚言じゃなければきっと誰か知っているはず！
339:nobodyさん
12/03/03 13:08:32.42
SilexとSlimだったらどっちがいいんかなあ
340:nobodyさん
12/03/03 14:57:46.64
そうか、SymfoとかCakeとかYiiのいいところって、縛りがキツいから、誰がどう書いても、同じような仕上がりになる所なのか。
341:nobodyさん
12/03/03 15:24:06.66
cake…？
342:nobodyさん
12/03/03 23:17:04.05
Zenderのわたしがやってきましたよ(´・ω・｀)
343:nobodyさん
12/03/03 23:38:00.10 wGPoNHA5
なるべく息が長くて、個人の開発者に依存してなくて、下位互換性に重点が置かれるフレームワークが
一番いいと思うよ。
344:nobodyさん
12/03/04 10:33:31.23
>>338
虚言癖のある奴とは距離を置いたほうがいい
345:nobodyさん
12/03/04 11:59:57.71
大手は知らんが
APCとapacheは手を入れてる
各々二台だけど
346:nobodyさん
12/03/04 12:06:53.30
荒らしが丸一日相手にされてなくてフイタ
347:nobodyさん
12/03/04 12:11:30.03
相手してるじゃん
348:nobodyさん
12/03/04 12:45:43.61
PHPはソースコードなんていじりません
↑
そこまで否定するならこれを実名で講演会で発表してもらいたいよなｗ
349:nobodyさん
12/03/04 15:41:54.98
具体的に何をやるかってのがないから、自分とこは手を入れずに使ってるけど
手を入れたいところが出たときに手を入れるのは普通にやるかなー
そういうのは、会社の技術レベルや仕事の内容の問題だと思う
委託とかなら他に責任があるとこには手を出すことはしないだろうし
自社サービスとかなら、手を入れたほうがいい部分には手を入れる
こんなの真新しいことじゃないし、そもそもフレームワークでもないから
引っ張る話題じゃないと思うけどなｗ
350:nobodyさん
12/03/04 17:26:51.39
まだ言い訳してんのか虚言壁さん
351:nobodyさん
12/03/04 18:01:35.68
>>350
お前も何時までも見えない敵と戦いすぎ自重しろ。
352:nobodyさん
12/03/04 18:35:06.49
むか～し、MidgardというCMSだかフレームワークだかあったが、それがextension必須だった気がする
面白そうだったから後でいじろうと思って放置してたが、最早探そうと思って検索してみてもロクな情報出てこないな
353:nobodyさん
12/03/06 23:44:35.29
長文書く暇があるならURL貼りゃいいのにｗ
354:nobodyさん
12/03/07 00:15:28.72
煽る暇が（ｒｙ
355:nobodyさん
12/03/07 00:18:48.46
煽るってか、少なくとも教えて君には得がないから教えないって秘匿してる
ソースに興味があるからなｗ
損得気にするくせに>>349みたいなしょうもない長文書くのは滑稽だろ
356:nobodyさん
12/03/07 01:36:28.94
ここはいつしかソースを１つも明示せずに、妄想を膨らませるスレとなった
357:nobodyさん
12/03/07 08:30:48.88
すげ、何日粘着してんだよw ネクラにもほどがある。
358:nobodyさん
12/03/07 10:37:23.12
自分で探しきれなくて追い込みに入ってるんだよ
たった去年の年末に出た情報も探せないとかゆとり過ぎる奴はほっとけ
構うと調子に乗るから飽きるまでスルーしとくのが一番
359:nobodyさん
12/03/07 13:17:14.98
そういう話にもっていくしかしのぐ手立てないもんなｗｗｗｗｗｗ
360:nobodyさん
12/03/07 17:23:15.84
こういう教えて君ってどうせWindows+XAMPPでしか使ったこと無いようなカスなんだろ
361:nobodyさん
12/03/08 00:28:28.85
>>338が知らない＝＝皆知らないとかｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
マジキチｗｗｗｗｗｗｗ
362:nobodyさん
12/03/08 00:56:18.18
技術系のスレッドでも
ただただ他人を馬鹿にするためだけにレスする人増えましたよね
ｽﾄﾚｽぶつける場所はいくらでもあるでしょうに。。
なんていうと2ｃｈだからどうこうっていう人いるけど
技術系はそうではありませんでした
煽りつつもなんとなく正解を臭わせてもらってましたよ
363:nobodyさん
12/03/08 01:19:02.29
なるほど、これの事か
364:nobodyさん
12/03/08 10:49:53.59
知らないくせに偉そうに聞くほうが悪い
365:nobodyさん
12/03/08 11:44:14.06
２ちゃんだろうが現実の社会だろうが変わりは無いな
知らないのに最初から否定してきて、教えて貰うまで煽るような人間は誰も教えたがらないしな
そんな人間にわざわざ教える意味なんてない
366:nobodyさん
12/03/09 01:54:46.07
>>333
なんかやらしい
367:nobodyさん
12/03/15 18:13:30.09
>>365
>>328
まだ気付かないのか
368:nobodyさん
12/03/15 18:19:26.45
なんか郵便受けにつっこまれてた宗教の本に同じようなこと書かれてたな。
大宇宙について人類はほとんどわかってないのに、なんとか神の存在を
なぜ否定するのかとかｗ
369:nobodyさん
12/03/15 19:36:59.93
vs Mr. Unknown.
370:nobodyさん
12/03/15 20:42:32.99
レスが伸びたと思ったらまだ情弱が書き込みしてたのか
371:nobodyさん
12/04/02 05:09:08.25 IFAunYHl
Smartyってスレも続かないほど廃れてんの？
使われてるけど変化や更新がなくて話題がないだけ？
URLﾘﾝｸ(www.google.com)
それはさておき、
「default_modifiersでエスケープしたらいいじゃん」→「配列を拾ってどうのこうの」
みたいな話題があると思うんだけど、エスケープじゃなくて未定義変数のエラー回避に使うのはまずい？
$this->default_modifiers = array('default:null');
未定義エラー(undefined index)を放置するとバグの温床になる、とかだけ？
php側なら分かるけど、テンプレートにそんな厳密性が必要？
372:nobodyさん
12/04/02 10:16:42.21
>>371
そもそもSmartyってFrameworkに分類されるべきものなの？
自らTemplate engineと言っているよね
cakePHPやSymfonyのような機能が豊富なFWと比較することに違和感がある。
373:nobodyさん
12/04/02 11:33:02.90
>>372
うん、時々見かけますが、わたしも違和感があります。
ただ、やむなく広義に含めるのも場面によっては仕方ないかと。
たとえば>>371は、質問総合スレみたいのよりここの方がふさわしいと思いました。
テンプレートエンジンスレのひとつもあっていいとは思うんですけどね。
cakeとかのせで、生phpで書くひとが増えたのかな？
374:nobodyさん
12/04/02 12:13:09.90
>>373
cakePHPやsymfonyといったフレームワークに
テンプレート機能があるからsmartyをわざわざ使う必要、覚える必要が
なくなったってのは十分ありえる理由だと思う。
海外では日本ほど人気ないらしい、smarty。
375:nobodyさん
12/04/02 14:57:18.55
<?php echo $var; ?> とか視認性悪いと思っちゃうんだけどなぁ。
376:nobodyさん
12/04/02 17:03:24.27
長さが気になるなら <?= $v ?> でいいじゃないか
377:nobodyさん
12/04/02 17:25:40.80
長さをつきつめれば {$v} になるじゃん。
単純な文字数もそうだけど、書式そのものの気持ち悪さというか。
まあ、確かPHPの \(名前空間) だか :: も外野の評判は悪いんだっけ？
そう考えると、慣れの問題もあるのかなーとは思う。
てか default_modifiers についての話をしたかったんだけど…ｗ
378:nobodyさん
12/04/03 18:32:04.05
文字列接続の . とかもぶっちゃけると気持ち悪いよな
379:nobodyさん
12/04/07 09:42:24.65
Smartyはテンプレートの域を外れてしまってるからな。
っつか、俺の考えだと、Smartyがウケのはデザイン側じゃなくて主にプログラマ側で、単にコンパイルする、というコンセプトが面白かっただけだと思うよ。
初心者はSmartyじゃなくて、phpLib時代のテンプレートとか、もっとシンプルにデザインとプログラムの分離を目指していた頃のテンプレートエンジンから学ぶべきだと思うんだな
380:nobodyさん
12/04/07 14:13:31.54
最初くすぐったがってるけど、だんだん口数が減り息が荒く…みたいなのは割と見かけるきもする
381:nobodyさん
12/04/07 14:13:48.18
あらやだ酷い誤爆
382:nobodyさん
12/04/08 07:53:17.68
どこの誤爆かkwsk
383:nobodyさん
12/04/19 12:51:51.07
初めてwebprog板に来たんですが、ここではdoophpはどういう評価ですか？
高速性が2chのイメージ的に受けそうな気もするのですがテンプレにもないので
384:nobodyさん
12/04/26 05:15:22.88
PHPはポンコツ言語だから高速化は期待できない
385:nobodyさん
12/04/28 09:45:15.24
>>384の命令によりこのスレは終了します
386:nobodyさん
12/04/28 10:11:29.79
終了について特に異議もありませんでした
387:nobodyさん
12/05/03 14:18:09.76
Googleトレンド以外で、
PHP Frameworkのマーケットシェアのデータはあるのかな？
Symfony, cakePHP, Zend Framework, CIの勢力図はどう変化してるんだろ
388:nobodyさん
12/05/03 14:56:05.77
このスレは終了しました
389:nobodyさん
12/05/03 18:10:52.09
このスレが再開しました
390:nobodyさん
12/05/05 01:04:58.98
Phalconって言うC extensionで書かれたPHP用のフレームワーク見つけて、
今、ドキュメント読んでるけど、ベンチマークが半端無くすげえ。
URLﾘﾝｸ(phalconphp.com)
phpのフレームワークで同様の処理をさせてみた結果。（速さは重要じゃないと言いつつ）
Yii (YII_DEBUG=false) Version yii-1.1.10.r3566
-> Time taken for tests: 1.469 seconds
Symfony Version 2.0.11
-> Time taken for tests: 8.105 seconds
Zend Framework Version 1.11.11
-> Time taken for tests: 4.264 seconds
CodeIgniter 2.1.0
-> Time taken for tests: 1.184 seconds
Phalcon Version 0.3.1 <- こいつ、桁が違う。
-> Time taken for tests: 0.385 seconds
Zend Frameworkの１２倍の速さ。さすがC/C++のネイティブコードは段違い。
自分で作ろうと思ってたけど、同じこと考えてる人は世界にいるのね。。
391:nobodyさん
12/05/05 02:52:16.62
Phalcon良いわ。発展途上なのが理解しやすくて良い。
あとはバグがどんだけあるかって感じ。
ざっと読んでみたけど、弱いのは以下。
・DBの抽象化やってるけど、
adapterが今んとこMySQLしかないから、事実上DBはMySQL固定。
・Layoutとパーシャルの使い方がいまいちわからない・・・。
全体的にviewの説明が不足してる気がする。
・ACLはあるけどAuth系が無い。まあ、俺は不要だけど。
・キャッシュ用のクラスがあるけど、キャッシュ先は現状ファイルだけ・・。
・理由がわからないけど、スケルトンツール使うならPHP5.3.6推奨。
テンプレート作るのにPHP関係無い気がするから、出来そうだけど。。。
・APIの説明がほとんど無い。
・多国語対応が無い。
他は概ね、ZFを弱くした感じ。
DBもフィルタにサニタイズにエラーチェックにJOINも可能で、これならぎりぎり使える。
392:nobodyさん
12/05/07 20:01:14.71 UtpQziV0
CMSで作るのとフレームワークで作るのと
どれくらい自由度や制作効率が違うのでしょうか。
393:nobodyさん
12/05/08 19:44:11.13
>>392
まじで聞いてるの？
CMSは自分でプログラム書く必要ない。
誰でも、ある程度自由に
そのCMSがテーマとするコンテンツを作れる。
フレームワークは自分でプログラム書く。プログラム作成の補助機能。
よく使う処理の部分は、ワークフレーム側でプログラムを予め書いておいてくれる。
プログラム書く人が楽できる。
よくわからないならCMSが良いと思うよ。
394:nobodyさん
12/05/08 22:33:44.49
CMSに乗っかるプラグインやら何やらのシステム開発したけど、ありゃ苦行だよ。使い回しする予定なら良いけど、無駄に考える事が多くて、開発に集中できない。
395:nobodyさん
12/05/09 13:46:54.03 SZ6jgFk0
>>393-394
回答ありがとうございます。
WordPressをブログ以外で使っているサイトいろいろ・国内編
URLﾘﾝｸ(kachibito.net)
みたいに、CMSでもかなりのことができるみたいなのですが
これはあくまで純正にプラグインそのままの組み合わせて制作したのではなく
プラグインのプログラムやDB構造を
自分で改造できてはじめてできるものなのですか？
プラグインを解析して改造する必要があるのなら、はじめから１から
フレームワークを土台に自分で作ったほうがよさそうですね。
396:nobodyさん
12/05/09 17:21:51.33
基本機能と既存プラグイン調べて、自分の要件に合っていればそれでいいのでは？足りない機能はFWでもプラグインでもAPIに沿って組むのは一緒だから、コスト計算同じだし。
397:nobodyさん
12/05/10 07:03:41.74
394だが、
プラグインが客の要望に微妙にマッチしていなかったり、プラグインごとの操作感の違いだったり、完全にそのまま使えるって事はほとんどない。
ごり押しできる立場にいるなら、もしくは自分とごく内輪で使って、文句言わせない状態なら良いけどね。
398:nobodyさん
12/05/10 07:25:13.05
>>395
自分も前にCMS(Drupal)使うべきか悩んだ。
WordPressは設計が悪くて有名。
もうWPのブームはとっくに終わってる。
日本は遅れてるからWPだけど、海外ではPHPではDrupalとかが主流。
で、Drupalは、そのフレームワークにSymfonyを使ってる。
Drupal機能そのまま使えるってことはまずない。
ちょっとデザインいじろうとすると、DrupalとSymfonyの知識がないといじれない。
Symfonyの知識を身につけるだけでもたいへんなのにそのうえにDrupalスタックの
勉強も必要。
自分で好きなフレームワーク覚えて、それで作るほうがはるかに楽という
結論に達した。
カスタマイズが必要ならCMSは逆に時間がかかって非効率。
まず一番機能が豊富で人気があるといわれるCMSのDrupalを使ってみるといい。
CMSでは特に画面のデザイン、レイアウトは柔軟にはいじれない。
399:398
12/05/10 07:48:29.65
>>395
ここにFrameworkとCMSの一覧がある。
URLﾘﾝｸ(en.wikipedia.org)
PHP系で人気あるCMSは、DrupalとJoomla!。
Joomla!のがとっつきやすい。
URLﾘﾝｸ(www.joomla.org)
URLﾘﾝｸ(drupal.org)
まずJoomla!とDrupal試してみるといいとおもう
それで納得いかないなら、cakePHP、CodeIgniter、Symfonyあたりの
フレームワークで作ればいい。
PHPである必要もないけど
俺はCMSの導入はやめて、フレームワークで作ることに決めSymfonyを
学び始めたが、仕様がころころ変わる事に嫌気が差して変更検討中。
PHPそのものが中途半端なオブジェクト指向なのに納得できず、
結局、Python系かRuby系フレームワークに落ち着きそうｗｗ
400:nobodyさん
12/05/10 08:02:55.82
中途半端なんだよな
401:nobodyさん
12/05/10 08:42:27.09
そこまでするなら、もうJavaがいいのでは？
402:nobodyさん
12/05/10 09:20:32.56
ＰＨＰだＣだって言ってる奴いるけど、パフォーマンス気になるなら
鯖分散すれば良いだけじゃないの？
１モジュールのパフォーマンス上げようってのは、ｗｅｂ開発では
あまり意味なさないと思うんだけど。
もちろんxdebug程度は使いこなせた方が良いとは思うけど。
403:nobodyさん
12/05/10 09:32:58.81
随分長いことパフォーマンスの話はでてないが。。
404:nobodyさん
12/05/10 09:58:00.30
>>401
Performance考えたらJava, C#のがいいだろうね。
JavaはSpringがめんどくさいと言われてるので手を出してないけど、
フルスタックのPlay! Frameworkもさわるかも。
Rubyは速くないけどRuby on Railsが有名だからいじり始めたんだ。
Tutorial終わったらさようならするかもしれない。
Pythonは欧米でかなり人気だからいじってみたくなって・・ｗ
PythonのFrameworkはDjangoのヘルプを読み始め。
Java並の速度で、簡潔にかける言語と、Railsのようなお手軽な
フルスタックフレームワークがあればいいけど、まだ見つかってない。
>>402-403
そうは言ってもパフォーマンスが原因でJava系に移行する企業増えてるみたいよ。
RubyをやめてJava系にしたTwitterとか有名だよね。
動けばいいじゃないって人もいるだろうけど、どうせ作るなら
速く動いたほうが気持ちいいよね
405:nobodyさん
12/05/10 12:19:53.42
railsは論外だな。あれrakeが遅すぎて使い物にならん。
406:nobodyさん
12/05/10 12:48:48.07
>>404
長々と書いて結局「コンパイル言語は速い、スクリプト言語は遅い」かい
407:nobodyさん
12/05/11 00:34:14.48
自分の言いたい事だけ言って、他人のレスは一切読んでないからパフォーマンスだの言語の話になるんだよ。
ちなみにDrupalとJoomlaのどちらもクソだと思う。上の人には悪いが。
408:nobodyさん
12/05/11 03:27:49.21
>>407
「自分の言いたい事だけ言って、他人のレスは一切読んでない」っておまえのことだろ
質問者がCMSを検討してるから、>399有名どころのふたつをあげて、
要件を満たすかどうか、まず試してみることを勧めてるわけだろ。
本人はCMS使ってないって書いてるしな
質問者に何も情報をあたえてないおまえのレスのが間違いなくクソだ。
409:nobodyさん
12/05/11 04:02:20.61
何が嫌いかより、何が好きかで自分を語れよﾄﾞﾝって、ルフィさんが言ってた。
410:nobodyさん
12/05/11 04:31:35.20
>>408
すでにその前に書いたし、俺は他人を簡単にクソだと言う奴にどうこう言われたくないね。
411:nobodyさん
12/05/11 22:11:45.56
PHPで速度語るならPhalcon使えよ・・。
Cネイティブだぞ。Javaの１０００倍以上高速で動くんだぞ。
まあ、フレームワークの部分だけだけど。
412:nobodyさん
12/05/12 01:07:01.11
複数言語が入り混じるFWは使いづらそう
413:nobodyさん
12/05/12 02:26:27.89
PHPな時点でCが絡むわな
414:nobodyさん
12/05/12 02:32:29.57
前から疑問に思ってたんだけどWebサービス云々でPHP自体がボトルネックになることってあるのん？
100%張り付いたから同じ構成のFWを別の言語にしたら30%になりますた！！みたいな事がさ
415:nobodyさん
12/05/12 07:12:48.55
>>398
> で、Drupalは、そのフレームワークにSymfonyを使ってる。
こんなの初めて聞いた。別のものと勘違いしてない？
416:nobodyさん
12/05/12 07:26:41.65
>>415
トップページに出てる。
URLﾘﾝｸ(symfony.com)
Drupal, one of the world most popular Open-Source content
management platform, uses the Symfony Components as of version 8.
417:nobodyさん
12/05/12 22:30:53.06
DrupalがSymfonyアプリケーションって感じではないんだな
418:nobodyさん
12/05/12 23:12:25.20
>>412
Cは使わない。Cで書いてあるコードを呼び出すだけ。
PECLやZend APIと同じ。
419:nobodyさん
12/05/14 17:21:48.99
>>416
クラスローダーとHTTPリクエスト/オブジェクトにSymfony 2のそれを使おうぜって話が出てるだけで
それすら約2年弱あるリリースまでに変わるかも知れないものだぞ
420:nobodyさん
12/05/31 15:38:56.92 IzK2Xy2G
CMSでも本来のプラグインとかを使わず、
フレームワークとして使えるって本当ですか？
問い合わせフォームの面倒な部分はCMSにまかせて
自由度の必要な場所はMVCフレームワークのごとく
つかえるみたいなんですが・・・。
421:nobodyさん
12/06/05 07:52:11.09 YB7szyDX
URLﾘﾝｸ(d.hatena.ne.jp)
↑こんな感じで、bakeみたいなことをWebインターフェイスから実行できるしくみって、ほかにありますか?
422:nobodyさん
12/06/08 01:44:01.85 EOwIYA3r
PHPでアスペクト指向フレームワークはありますか？
「下らなぇ」スレで聞いても返答はありませんでした。
423:nobodyさん
12/06/08 02:20:11.83
Seasar2.PHPかSymfony2
424:nobodyさん
12/06/08 05:53:52.20
下らなぇスレを責任持って立てろ
425:nobodyさん
12/06/08 13:06:08.71
アスペルガー
426:nobodyさん
12/06/08 19:43:22.20
上の方で学習コストの話があるけどさ、
学習コストの低いフレームワークを選択して足りない機能がでてきた場合は
自分でコーディングすることになるわけじゃん？
ある程度スキルのある人なら問題ないだろうけど、初心者が調子乗って
拡張機能つくってもろくなコードにはならんぜ。保守性・安全性の面で。
427:426
12/06/08 19:49:09.78
大抵はあとで別の人間が書き直すハメになって、
最初からちゃんとしたフレームワークつかっておけばよかったね
ってなるというおはなし
連投そまそ
428:nobodyさん
12/06/08 21:23:48.12
でも作る経験は財産になるから難しい
429:nobodyさん
12/06/09 00:22:58.18
アスペクト指向プログラミングはどうしていますか？
430:nobodyさん
12/06/09 15:33:04.84
でも機能豊富なゴテゴテしたフレームワークを選択しても
スキルの低い人は、理解できない使いこなせないで
結果ものすごいものが出来上がるというのも
よくあるおなはしなわけで。
431:nobodyさん
12/06/09 18:16:18.24
機能豊富なフレームワークで、そのご自慢の機能使おうとしたら
まともに動かなくて、結局自分で書く羽目になるというオチ
俺はCakePHPでそれくらった
432:nobodyさん
12/06/09 19:38:34.84 3pAJ5sr2
1. (自分のスキルがしょぼいせいで)まともに動か(せ)なくて
2. (自分の使ってるサーバーがしょぼいせいで)まともに動かなくて
3. (ご自慢の機能が実は自分の期待よりしょぼかったせいで)まともに動かなくて
433:nobodyさん
12/06/09 21:45:29.70
で？
434:nobodyさん
12/06/09 21:59:38.62
感覚的な学習コストの序列ってどんな感じかね？
個人的には
code igniter << Yii < Cake PHP < Symfony
と言う感じだが、最初に触ったのがSymfonyだったから思い出補正あると思う
435:nobodyさん
12/06/10 00:25:31.42
どういう序列なんだ？Symfonyが一番簡単って意味か？
436:nobodyさん
12/06/10 00:49:47.75
コスト低 <- ->コスト高 ね
437:nobodyさん
12/06/10 13:51:41.36
Cake PHPやSymfony って情報量多いし、学習コスト低いと思うんだが。
438:nobodyさん
12/06/10 22:57:43.91
ciなんて作りが雑過ぎて、その分をフォローするための学習コストが多すぎる
439:nobodyさん
12/06/11 01:14:21.03
オレオレと変わらないからな
440:nobodyさん
12/06/11 03:30:12.33
他人が作ったオレオレフレームワークだな。
441:nobodyさん
12/06/11 09:35:44.15
学習コストねぇ
有用なら高くても使うがね
442:nobodyさん
12/06/11 16:06:17.97
学習コストは人によって違うからね。
有用でも情報量が少なければ理解するまで時間がかかるし、
そう言う面で学習コストがかかるならマイナスだよ
443:nobodyさん
12/06/11 16:53:54.85
何をもって有用とする？
444:nobodyさん
12/06/11 17:54:11.00
それも人それぞれでしょ。
個人や少人数でやるなら好みや感触で決めてもいいような気がするけど
多人数チームでやる場合はほんと悩ましいよね・・・
445:nobodyさん
12/06/11 18:53:49.81
そもそもPHP自体が、使いもしない要らない機能だらけで、有用ではない
446:nobodyさん
12/06/11 20:10:54.07
ガラパゴス化している日本人にピッタリじゃないか
447:nobodyさん
12/06/12 09:46:48.90 Yrv/uaCb
検索エンジン等、動的部分はフレームワークで、
会社概要等、静的な部分CMSにまかせるってどうなんでしょうか
448:nobodyさん
12/06/12 09:56:18.31
作り方が異なるファイルが混雑するとややこしくなるよ。
静的な部分もフレームワークで作った方が良いと思う
449:nobodyさん
12/06/12 11:55:20.93
プログラマが更新するか、
デザイナーも関わるか
450:nobodyさん
12/06/12 13:10:31.60
デザイナーが関わるのは無理だよ。むしろ関わらせちゃ行けない。
451:nobodyさん
12/06/12 13:17:41.45
デザイナーもグラフィカルに編集できるものを目指してるんしゃないのか
452:nobodyさん
12/06/12 19:50:03.28 Yrv/uaCb
CMSがフレームワークに置き換わる日
URLﾘﾝｸ(blogs.itmedia.co.jp)
今の時代、フレームワークを土台にして作るのではなく、
CMSを土台につくったほうがいいんですかね。
フレームワークも便利ですけど
RSS発行とか、フォーム作成とか
自分でプログラム組まないとだめじゃないですか。
フレームワークでは数時間かかるRSS発行処理作成とか
CMSでは数クリックでできるし
処理されたデータを、どう煮るか焼くかは
CMSもフレームワークも変わらないし。
ただ
>>393さん
みたいに、高度な改変となるとCMSは
プログラムの解析が大変という意見もありますし、
何を作るかによってかわってくるんでしょうが
フレームワークに自作関数や、自作ライブラリを相当作りためてでもいないかぎり
ＣＭＳを使ったほうが効率がいいんですかね。
453:nobodyさん
12/06/12 21:40:37.73
プログラミングができない人から見るとそうなのかもね。俺は全く別物だと思うけど。
CMSで事足りるならそれでいいのではないかと。要件を満たすかどうかの問題。
454:nobodyさん
12/06/12 22:18:15.27
フレームワークは高機能で便利な魔法のツール、みたいに思っているのかもしれないけど
それ以上に大事なのは、制限やルールといった枠組みを与えることで、
人それぞれバラバラになりがちな開発の手法や方向性を統一できること。
って誰かえらいひとが言ってたような気がする。
455:nobodyさん
12/06/12 22:27:13.88
表示系はなんとかなるけど、
DBから取り出す条件設定の制御が面倒な事多くね？
クエリ直接書かせろ！みたいな…
456:nobodyさん
12/06/12 22:34:40.75
官公庁はCMSが主流
457:nobodyさん
12/06/13 01:30:46.38
オリジナル要素が高くなければCMSで良いかもね
458:nobodyさん
12/06/13 02:45:26.95
CMSが勝手のいいフレームワークで作られていれば良い
459:nobodyさん
12/06/13 04:11:16.55
WordPressやEC-CUBEがが使いやすいMVCフレームワークで作られてればよかったのに…と何度思ったことか
カスタマイズつらいです…
460:nobodyさん
12/06/13 08:23:18.71
ワープレって、MVCじゃないのか。
MVCじゃなかったらプラグインひとつ作るのも
かなり手間かかりそうなんだが・・・。
461:nobodyさん
12/06/13 11:38:34.22
違うね。共通ファイルは分けてるけど、細かくビュー分けはしていない
EC-CUBEは独自フレームワークだけど、
こちらも複雑すぎてどこがどこにあるかわかりづらい
462:nobodyさん
12/06/20 01:22:18.24
複雑ってのは俗に言うスパゲッティってことだな
463:nobodyさん
12/06/20 01:27:38.99
そうそう。EC-CUBEは色んな開発者が共同で作ってるらしいから
どうしてもスパゲティになるよね
464:nobodyさん
12/06/20 04:31:46.45
EC-CUBEはソースひどいよな。トランザクションとかちゃんとしてなさそうだし、いくらでも穴がありそう。
// これで勘弁してください…
的なコメントが書いてあったりするし。ジョーク系のサイトでよく似たネタ見るけどオープンソースでは初めて見たわ。
465:nobodyさん
12/06/20 06:50:24.76
ソースの具体例は？
466:nobodyさん
12/06/20 08:32:01.15
>>463
＞色んな開発者が共同で作ってるらしいからどうしてもスパゲティになるよね
いや、その理屈はおかしい
467:nobodyさん
12/06/20 13:21:19.05
>>466
おかしくないよ。だって規約が統一してないんだから。
開発者が違うって言っても社内じゃなくて、他社って意味だし。
468:nobodyさん
12/06/20 13:25:22.16
スパゲティの意味をまずわかってください
469:nobodyさん
12/06/20 13:37:07.72
>>467
外部の異なる組織からフリーランスまでさまざまな開発者が
参加して作ってるオープンソースソフトなんて山ほどあるんだが
さすがにそれらのほぼ全てがスパゲティだなんて話は聞かないよ
470:nobodyさん
12/06/20 14:16:22.28
>>469
ほぼ全てのOSSの話しじゃなくて、あくまでEC-CUBEの話しな
471:nobodyさん
12/06/20 16:40:25.69
どうしてもスパゲティになる
を他のソフトにも適用するのはやめたまえ
472:nobodyさん
12/06/20 23:41:36.16
なんで他のOSSが大丈夫で、EC-CUBEだけ
スパゲティになるんだよｗ
473:nobodyさん
12/06/20 23:48:35.68
いやぁ、WordPressのごちゃっぷりは良いレベルよー
474:nobodyさん
12/06/21 00:01:15.17
PHP自体がスパゲティだよ。
標準関数の首尾一貫性の無さはスゴすぎ！
475:nobodyさん
12/06/21 00:22:06.05
>>472
普通、OSSって特定のグループ・会社が作ってないか？
OpenPNEなら手島屋って会社が作ってるし、
phpBBも海外のグループが作ってたはず。
一方、Wordpressは開発者はいるけど
プラグインで拡張していくから開発者も違うし、一貫性がない
476:nobodyさん
12/06/21 04:41:52.92
すべてのOSSを調べてから言えよハゲ
477:nobodyさん
12/06/21 07:43:24.24
OpenPNEもひでえソースだったなあ
478:nobodyさん
12/06/21 07:44:57.64
OpenPNEのカスタマイズは断念したな
479:nobodyさん
12/06/21 08:17:09.84 9C4PuuPO
逆に、このフレームワークは美しいソースだったなぁってのはないの？
480:nobodyさん
12/06/21 09:58:36.15
symfony2
ソースの見てくれの代わりに使い勝手が犠牲になったけど。
481:nobodyさん
12/06/21 10:14:39.77
PHP自体が美しくない
482:nobodyさん
12/06/21 10:32:53.94
そもそも「美しさ」の感じ方は個人差によるからな
483:nobodyさん
12/06/21 14:29:18.00
EC-CUBEは番人に共通する醜さだけど
484:nobodyさん
12/06/21 14:37:44.78
EC-CUBEはあんなソースでそこそこ動いちゃってるのが不思議なくらいだな
管理とかちゃんとなってない会社なんだろうな
スキルの低いエンジニアが会社の床で寝ながら泥沼のようにして作った印象
あのスタイルで書いたコードのデバッグをやりきるには大変な根性が要るはず
485:nobodyさん
12/06/21 15:56:14.33
俺の見立てではわざとやっていると思う。
OpenPNEもそうだけど、わざとソースを複雑にして
有償サポートを狙っている気がする
※あくまで個人の感想です
486:nobodyさん
12/06/21 16:43:08.98
PHPが汚いとえば
文字コードを変換する
mb_convert_encoding の配列版はないかいな思って調べたら
mb_convert_variables という関数を見つけた。
早速使ってみると、ちっとも機能しない。
なんと、
mb_convert_encoding は変換したいソース元を第一引数に入れるけど
mb_convert_variables は 第三引数にいれるという仕様！
そして
mb_convert_encoding は、
$hoge = mb_convert_encoding みたいに再度代入してやらないといけないけど
mb_convert_variables 代入しなくてもよいという仕様！！
そもそも mb_convert_variables というネーミングセンスなんなの?
mb_convert_encoding_array とかにでけんかったの？
487:nobodyさん
12/06/21 16:46:48.28
>>485
実は確かな技術を持った賢い集団で
自分らの開発は綺麗なソースで行い、リリースの際特製コンバータを通すと
あら不思議、ぐちゃぐちゃスパゲティコード＆意味不明コメント入りオープンソースのできあがり
てな感じか
488:nobodyさん
12/06/21 18:01:46.35
一貫性のなさはPHPの悪習
名前の付け方も引数の並べ方もこの上なく下手糞
489:nobodyさん
12/06/21 20:12:50.67
Zendは綺麗、それとDrupal
490:nobodyさん
12/06/21 20:15:41.23
>>487
俺の場合とは異なるかもしれないけど、
外部に公開するソースは難読化してるわ。コメントも削除してるし。