08/08/24 21:44:41
※ このスレは 【PHP】フレームワークについて語るスレ11【総合】 です
いきなりミス。ｽﾏｿ...
3:nobodyさん
08/08/24 21:47:34
過去スレ
【PHP】フレームワークについて語るスレ10【総合】
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワークについて語るスレ9【総合】
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワークについて語るスレ8【総合】
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワークについて語るスレ7【総合】
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワークについて語るスレ6【総合】
ｽﾚﾘﾝｸ(php板)
[PHP]フレームワークについて語るｽﾚ5[総合]
ｽﾚﾘﾝｸ(php板)
[PHP]フレームワークについて語るｽﾚ4[総合]
ｽﾚﾘﾝｸ(php板)
[PHP]フレームワークについて語るｽﾚ３[総合]
ｽﾚﾘﾝｸ(php板)
[PHP]フレームワークについて語るｽﾚ２[総合]
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワークについて語るスレ【総合】
ｽﾚﾘﾝｸ(php板)
4:nobodyさん
08/08/24 21:48:23
【洋モノ】
symfony
URLﾘﾝｸ(www.symfony-project.com)
code igniter
URLﾘﾝｸ(codeigniter.com)
Zend Framework
URLﾘﾝｸ(framework.zend.com)
CakePHP
URLﾘﾝｸ(www.cakephp.org)
【和モノ】
ちいたん
URLﾘﾝｸ(php.cheetan.net)
Ethna
URLﾘﾝｸ(ethna.jp)
guesswork
URLﾘﾝｸ(classic.guesswork.jp)
maple
URLﾘﾝｸ(kunit.jp)
5:nobodyさん
08/08/24 22:11:57
Mapleイラネ
6:nobodyさん
08/08/25 14:32:05 qgfF3K9X
agavi
age
7:nobodyさん
08/08/25 16:50:03
何使おうか考え中
ZendがPHPにかなり力を入れてるから将来性があると思うんだけど
評価が悪くて使えそうにない
8:nobodyさん
08/08/25 16:54:50
>>7
ちいたん使えｗｗｗ
で「今回のプロジェクトではフレームワークとして「ちいたん」を採用しました」
って上司に報告してくれｗｗｗ
9:nobodyさん
08/08/25 16:58:15 hwjRu6i6
セッションデータって毎回全体を読み書きするから
あんまり大きいデータは扱いたくないよな。
かといってテンポラリーなデータを永続データが入ってるDBに突っ込むのは
抵抗がある。
こういう場合どうする？
10:nobodyさん
08/08/25 17:14:13
>>9
XMLファイルにでもしておけば？
11:nobodyさん
08/08/25 17:25:37
xmlって一部を読み書きできるの？
結局全読み・全書きになるのでは？
12:nobodyさん
08/08/25 18:59:26
>>9
1. 気にせずDBに放り込む
2. 「永続データが入って」いないDBに放り込む
3. 「一部を読み書きできる」ように細分化してファイルに放り込む
4. 気にせず毎回全部読み書きする
なんでもいいんじゃないの？
13:nobodyさん
08/08/25 20:03:51
>>7
zend使ってくれ
専用スレが過疎ってつまんないから
14:nobodyさん
08/08/25 21:13:10
>>7
>評価が悪くて使えそうにない
せめて情報が無くて使えそうにないって言ってくれｗ
ユーザの声（マニュアルではない、もすこし身近なTips、ノウハウなど）が
圧倒的に不足しているよね
でもそれはどのフレームワークも一緒か。
そもそも乱立しすぎじゃね？
例えばせめてライブラリ系はZendを使うとか、そんな風潮になればノウハウは
蓄積されていくんだろうけど
15:nobodyさん
08/08/25 23:48:18
シンプルなページを各フレームワークで実装したベンチマーク
URLﾘﾝｸ(talks.php.net)
結果だけまとめると
1位 素のPHP
611.78 trans/s
2位 CodeIgniter 1.6.3
305.9 trans/s
3位 Solar 1.0.0alpha1
271.18 trans/s
4位 Zend Framework 1.6.0-rc1
130.08 trans/s
5位 Agavi 1.0-beta1
126.91 trans/s
6位 Symfony 1.1
100.63 trans/s
7位 Prado 3.1.2
76.95 trans/s
8位 Drupal 6.4
51.37 trans/s
9位 CakePHP 1.2.0rc2
25.88 trans/s
16:nobodyさん
08/08/26 00:48:34 lM6BRZm9
>>9
マジレスすると、セッションみたいな永続じゃないデータの場合memcache使うのが良い。
レンサバじゃ無理だけどな。
17:nobodyさん
08/08/26 01:23:19
cakephpってそんな遅いんだ。
18:nobodyさん
08/08/26 01:38:25
>>15
DrupalってF.W.じゃないじゃんｗ。
それより遅いcakeって・・・・。
19:nobodyさん
08/08/26 10:05:38
いちおうDrupalはCMS向けのモジュラー式フレームワークってことになってる。
20:nobodyさん
08/08/26 11:02:15
cakeで開発しようと思ったけど、
cakeもどきの俺様フレームワーク作ってやるかな。
21:nobodyさん
08/08/26 23:18:20
そういや、PEAR2ってどうなったの？
22:nobodyさん
08/08/27 00:05:44
PEAR2は5.3合わせでしょ
23:nobodyさん
08/08/27 11:52:55 n0GZd29C
思ったんですが、
singletonって全部staticなクラスとほとんど同じでは？
むしろ、singletonの機構を書く必要がない分、
staticなクラスの方がいいのではないかとも思うのですが
singletonのアドバンテージって何ですか？
24:nobodyさん
08/08/27 12:52:05
>>23
顔洗って出直して来い
25:nobodyさん
08/08/27 15:02:44
signletonはobject
(PHPの)クラスはobjectではない
ぜんぜん違うだろ
26:nobodyさん
08/08/27 15:06:09
顔洗って出直してきました。
で？
27:nobodyさん
08/08/27 15:13:19
全然違うって言う奴は分かってないだけ
分かってる人の返答お待ちしております
28:nobodyさん
08/08/27 15:56:42
唯一のインスタンスを取り扱うためのsingletonでしょ
なのにstaticなクラスがいいとか全然違うよ
分かってないのはあなた
singletonをもう一度調べ直してみ
29:nobodyさん
08/08/27 16:01:55
メソッドはstaticでもつかえるし、PHP5からはデータもクラスで持てる
Hoge::page() ではなく Hoge::instance()->page() にするメリットはなにかと
言うことだと思うんだけど
まあインスタンスにしておけば、変数に放り込んで引数で渡したり、
簡単に別クラスに差し替えたり、そう言う事ができるかもしれない
私もよくわからんので、違うっていう人の親切な解説があれば嬉しいな
30:nobodyさん
08/08/27 17:22:46
singletonはsingletonっていうインスタンスは必ず一つなのが
保証されますよっていうパターンの概念なわけで、別に
staticなクラスの作りでsingleton的な扱いをすることもできるだろうけど、
ただそれが「singletonって全部staticなクラスとほとんど同じ」かと
言われればそりゃ違うって答えるだろう
概念の話とコードレベルの話だし質問がおかしい
ある程度有名なパターンだからsingletonってこういうもの、
という共通認識がプログラマにあるのがアドバンテージなわけであって
このクラスはsingletonだからインスタンスは唯一、とすぐ把握できるところを
オレオレsingleton概念で「これ俺なりのsingleton！インスタンスはナイっス！」
とか言われても困るわけで
Hoge::page() と Hoge::instance()->page() 云々も一緒で
要はそのクラスがどういう扱いなのかというのを認識するのに
singletonというパターンがあるよってだけの話であって
singletonだから絶対Hoge::instance()->page()な形ってわけでもないし
コードレベルの問題とはまた別の話かと
31:nobodyさん
08/08/27 17:55:26
>>23の無知さに全米が泣いたｗ
32:nobodyさん
08/08/27 17:56:52
>>23はバカなの？死ぬの？
33:nobodyさん
08/08/27 18:06:57
PHPでコンピュータプログラミングを学ぼうとすると、こうなっちゃう
ってことですね
34:nobodyさん
08/08/27 18:12:39 8yHWP9d0
23 nobodyさん [] Date:2008/08/27(水) 11:52:55 ID:n0GZd29C Be:
思ったんですが、
singletonって全部staticなクラスとほとんど同じでは？
むしろ、singletonの機構を書く必要がない分、
staticなクラスの方がいいのではないかとも思うのですが
singletonのアドバンテージって何ですか？
晒しage
35:nobodyさん
08/08/27 18:27:10
おまえら説明出来ないからってシンプルに叩きすぎだｗ
36:nobodyさん
08/08/27 19:08:36
ウェブアプリだとシングルトンパターンなんて使い道があんまりないからな。せいぜいDBハンドラぐらいだけど、それも普通にグローバル変数で扱えば十分だし。
37:nobodyさん
08/08/28 02:21:17
結局説明はできない、と。
得意げにsingletonの解説始めちゃう奴なんなの？
そういうのを東洋じゃ釈迦に説法って言うんだぜ。
38:nobodyさん
08/08/28 03:28:58
どこに釈迦がいるってんだい。
おつむがおしゃかな奴なら確かにいるようだが。
39:nobodyさん
08/08/28 08:08:13
C++だとグローバル変数では初期化のタイミング不確定だから、シングルトンは有用だったりするけどな
40:nobodyさん
08/08/28 14:16:10
>>23は質問自体が痛ｲよね
41:nobodyさん
08/08/28 21:36:39
答えられなかった奴が必死の自己肯定ｗｗ
反論するなら論理的にしろ。な？
42:nobodyさん
08/08/28 21:49:55
>>23の質問は別に痛いと思わない
痛々しさではむしろ>>31-34の方が
んで、>>23はsingletonと同じではないけど、別にそれでも
いいんじゃない？っていう認識はどんなもんですか ＞ エロい人
唯一性（？）の保証なら、コンストラクタ隠し忘れてたり__clone()上書き
してなかったりする半端singletonよりは確実とか考えたり。（そんな奴いない？）
インスタンスとして扱う必要がなくて、「singleton」と言いさえしなければ、
あれも十分実用的な考え方だと思うけど
叩くなら叩け
43:nobodyさん
08/08/28 22:07:43
object としてのふるまいが必要でないならそれでいいんじゃねえの。
44:nobodyさん
08/08/28 22:08:43
staticメソッドとシングルトンパターンとじゃ、比較したり置き換えたり出来るもんじゃないんだよ。
>>30で十分説明してあるし、それ読んで分からないようなら、素養がなさ過ぎるので、プログラミングなんか止めた方が良い。
河原で野球でもしてろ。
45:nobodyさん
08/08/28 22:26:50
>>30で書いているのは、singletonはパターンの名前で、型であり概念であると
いうことでおｋ？
OO言語でのstatic等と言うものの理解が全然ないのは確かだから
申し訳ないが、singletonと、くだんの実装方法との最大の違いはインスタンスを
使うかどうか、っていうことだけと思ってしまう。それはsingletonの概念に含まれるの？
>>23の手法に、また別な名前があったなら話はシンプルだとかそういう話？
46:nobodyさん
08/08/28 22:33:07
そこで意表をついてガンパレードマーチ配信ですよ
47:nobodyさん
08/08/28 22:35:06
誤爆ｽﾏｿ
48:nobodyさん
08/08/28 22:49:37
>>45
もともとsingletonってデザインパターンは、Javaでのデザインパターンの話だし、
JavaプログラミングだとThreadって概念も出てくるから、全部staticなクラスよりも
singletonのほうが都合が良いとか、そういうことなんじゃないの？
49:nobodyさん
08/08/28 23:05:35
>>48
うん。もともと、そういう実際上の都合も絡めての話題だと思った
てか singleton static でちょっとググっただけでわんさか出てきた
URLﾘﾝｸ(java-house.jp)
URLﾘﾝｸ(www.aerith.net)
URLﾘﾝｸ(www.atmarkit.co.jp)
URLﾘﾝｸ(www.sk-jp.com)
URLﾘﾝｸ(oldblog.xenophy.com)
URLﾘﾝｸ(tome-programming.cocolog-nifty.com)
↑（結構アレなのも混ざってるけど）
意外とみんな引っかかる点なんじゃないの？
>>23がそこで悩んだとしたら、むしろセンスがあるんじゃね？
痛いっていってる人らはみんなきっとこれを乗り越えているんだろうが優しくねえなー
50:nobodyさん
08/08/28 23:25:03
>>49
俺も>>23の質問に対する正しい解答は知りたい。
>>44がいってる
＞staticメソッドとシングルトンパターンとじゃ、比較したり置き換えたり出来るもんじゃないんだよ。
っていうのも、少しずれてて、
>>23は、
全部staticなクラスを作るというデザインパターン と singletonというデザインパターンを比較してるのであって。
で、>>30の回答も、
そのアプリケーションを扱う人間が全部staticなクラスを作るというデザインパターンに対して共通認識を持ててたとしたら、
特に不都合は無い、ってことなのかな。
51:nobodyさん
08/08/29 01:26:14
全部staticなクラスって単なる構造化プログラミングじゃん。
52:nobodyさん
08/08/29 01:39:13
>>51
それは言えるかも。オブジェクト指向ではないと。
まあぶっちゃけstaticなプロパティを、globalsのいらないglobal変数として
使ってる私が通りますよ、と。
原則がないといくら文法がJavaに近くなっても意味がないってことはありそう
でもそれはデザインパターンと直接には関係しないような
singletonにしたって、普通にglobalじゃんっていう評価みたいだし。俺はよくわからんけどね
53:23
08/08/29 03:15:53
オブジェクト指向は単なる表記方法ではなく考え方なので、
全部staticのクラスだろうがオブジェクト指向にすることは可能。
さらにいえば、別にクラスがなくても可能。
スレッドのないPHPではsingletonに色んなざっくばらんな代替方法があると。
ただ汎用的な知識としてはJavaのやり方が無難で
わざわざ他の方法をとることもないということだな。
よくわかった。
54:nobodyさん
08/08/29 03:25:48
えらく短絡的なまとめきたー
てかそんな投げやりなまとめなら23とか名乗らず名無しで書けよｗ
ちょっとでも擁護したレスが軒並み後悔するような、嫌な感じだｗｗｗ
さあ寝よ
55:nobodyさん
08/08/29 03:31:33
？
別に君に擁護されなくても全く困らんよ？
もともと馬鹿に的外れな批判されても痛くもなんともないし
56:nobodyさん
08/08/29 09:09:19 EVgfNfnd
>>30みたいな説明じゃ、シングルトンがなにかも、staticメソッドと比べての利点もわかんないよ。
こんな説明をする先輩いるけど、ほんと自己満足だよな。
シングルトンのかわりにstaticメソッドでもいいじゃんというのは、そのとおり。
$obj = FooClass::getInstance();
$obj->method();
とするだけなら
FooClass::method();
でいいじゃんと思うのは自然なこと。
ただシングルトンはオブジェクト指向の機能を使えるので、
・継承が使える
・他のメソッドに引数として渡したりできる(オブジェクトなので)
・任意個の個数に設定できる(１個である必要はない)
という利点がある。こういった点が必要ないなら、staticメソッドで構わないよ。
たとえば
$obj = FooClass::getInstance();
other_function($obj);
ということをしたかったら、staticメソッドじゃなくてシングルトンのほうが自然だよね。
シングルトンもstaticメソッドもあくまで手段でしかないので、目的がstaticメソッドで満たせるなら
staticメソッドでもいいんじゃない。
57:nobodyさん
08/08/29 10:42:02
rubyのmixinみたいなことしたいのですが、どうしたらいいですか？
クラス定義の中から、
class Hoge {
self::mixin('OtherClass');
}
↓
HogeにOtherClassがmixinされる
みたいな形にしたいのですが。
runkitは不安定だったので使いたくありません。
58:nobodyさん
08/08/29 10:51:30
__call でがんばるか、ruby を使ってください
59:nobodyさん
08/08/29 11:13:07 YM8BIoOF
>>57
RhacoというフレームワークではMix-inをサポートしているそうだからみてみるといいかも。
URLﾘﾝｸ(rhaco.org)
URLﾘﾝｸ(ll.jus.or.jp)
> 変態的国産PHPフレームワークrhaco
> doctest、distutils、mix-in等PHPでは聞き慣れない機能について紹介します。
60:nobodyさん
08/08/29 11:39:37
>>59
ありが㌧みてみます
とりあえずsymfonyのsfMixerを見てみたけど
__callの中からsfMixerを呼んで、そこでバックトレース情報を利用して
混ぜられた側のメソッドにデレゲートしてる感じ
この方法だと、混ぜられた側のメソッドから
混ぜてる側のメンバにアクセスできないような・・・
61:nobodyさん
08/08/29 12:35:23
rhacoのmixinはeval使ってました
速度さえ気にしなければeval使えば大抵のことできますね～
evalでいくしかないかな
62:nobodyさん
08/08/29 13:15:34
全部staticメソッドにするというなら、それは構造化プログラミングそのものなわけで、それと比較するなら、オブジェクト指向プログラミングだろ。
シングルトンパターンという実装パターンの一つとじゃ比較の対象にならない。
63:nobodyさん
08/08/29 13:57:50
構造化プログラミングとOOPを峻別してる奴なんなの？
OOPは構造化プログラミングを含んでるんだよ
書き方の問題ではない
64:nobodyさん
08/08/29 19:54:55 YM8BIoOF
>>62
なに難しいこといってんの？
シングルトンでやろうとしていることは、staticメソッドでもできるんじゃね？というだけの話。
なんで構造化プログラムだとかオブジェクト指向との比較とかでてくるの？ばかなの？
65:nobodyさん
08/08/30 03:25:30
>>57
runkitは使ったことないですが、これは使ってます。
URLﾘﾝｸ(d.hatena.ne.jp)
qiqもすごくいい。もう普通のPHPは書けなくなるｗ
URLﾘﾝｸ(d.hatena.ne.jp)
66:nobodyさん
08/08/30 04:23:53
構造化プログラミングとオブジェクト指向プログラミングは比較して語られるものだよ。
あるプログラム、ある言語をを見て、それが構造化プログラミングなものなのか、オブジェクト指向プログラミングなのか、区別されるんだから。
その区別が出来ないというのは、人類皆兄弟とかいうたぐいの屁理屈だ。
67:nobodyさん
08/08/30 11:36:30
もうお馬鹿ちゃんは書かない方がいいんじゃないか
自分を大きく見せようとする努力ほど無意味なものはない
68:nobodyさん
08/08/30 12:39:53
オブジェクト指向プログラミングは、構造化プログラミングを含んでいるものだから、
プログラムを見て、オブジェクト指向プログラミング特有のクラス等を
（正しく）使っていればオブジェクト指向、使っていなければ構造化って判断をするな。
69:nobodyさん
08/08/30 18:14:35 OmTt4XZu
RUBYはオブジェクト指向を前提とした言語で、PERLは本来構造化言語なのをパッケージをクラスに流用することでオブジェクト指向の機能を持たせている。
昔の8ビットマイコン時代のBASICはGOTO文で処理を行き来する非構造化言語。
このプログラミングのパラダイムシフトは世界の共通認識だから。
70:nobodyさん
08/08/30 20:22:14
>>68
「～判断をするな。」が、I do なのか you shouldn't do なのかわからん
>>69
>このプログラミングのパラダイムシフトは世界の共通認識だから。
だから、何なんだ
どうせならもう少し結論を明確にしてもいいんじゃないかと思う
話がふわふわして仕方がないｗ
71:nobodyさん
08/08/30 20:38:57 /jeGwvoC
はじめまして、質問させてください。
社内でWebサービス構築のために
MVCモデルのPHPフレームワークを作ることになったのですが、
どのあたりまでの実装でフレームワークとして体をなすのか分かりません。
どなたか教えていただけませんでしょうか？
72:nobodyさん
08/08/30 20:57:57
それが分からない人達がフレームワークを作ることに意味があるとは思えない
既存のものを使った方がいいのでは？
73:nobodyさん
08/08/30 21:07:18 /jeGwvoC
回答ありがとうございます。
私も車輪の発明になる気がしてどうも１００％乗り気になれないのです。
ちなみに72さんは自作フレームワークの作成または、
既存のフレームワークで、ずっと使い続けてるものありますか？
74:nobodyさん
08/08/30 21:12:11
>>72
オープンソース全面禁止とかいう規則の会社もあるらしいし、
意味が無いかどうかはわからないのでは？
（PHPやApache自体もオープンソースだから、それはないかもだけどｗ）
>>71
フレームワークを利用する目的って、多分複数案件で使い回す事が出来て、また
複数の開発者で、またある程度の期間にわたって共通認識・理解をもつことで、
開発コストおよび保守コストを抑えることだと思うんだ
後は、基本的な部品を気合い入れて作ることで、品質の最低ライン（主にセキュリティ面など）を
保証するという意味合いもあるけど
だから、どこまでというのは程度問題でしかないと、個人的には思う
やりすぎれば使い回しに自由がきかなくなったりするし、緩すぎれば保守コストの
軽減には役に立たなかったりするんじゃない？
極端に言えばディレクトリ構造を決めて使い回すだけでも、ある意味「フレームワーク」
だと思う
75:nobodyさん
08/08/30 21:29:08 /jeGwvoC
>>74
>だから、どこまでというのは程度問題でしかないと、個人的には思う
なるほど、なかなか外部の方との技術意見交換をする機会がなくて参考になります。
ありがとうございます。
実は1ヶ月ほど前に公開になったあるBtoBのWebサービスで
MVCではないですが、自作でフレームワークを作ってみました。
少しは楽できるのですが、ホントに方向性的に合ってるのか、
若干迷いつつあるんです。
上からMVCモデルのフレームワークを準備してくれと頼まれた中で、
また０から準備することが本当に必要なのか迷ってまして。。。
この掲示板でやめた方がいいなと思ったとしても
やらないといけないことには変わりないんですけれど。
76:nobodyさん
08/08/30 21:46:18
MVCにこだわるなら
・各データの出し入れの基礎的な記述と、各データごとのロジック
・表示に関する基礎的な記述とロジック
を、実行スクリプトから切り離すのが最低限？
例えば、昔よく見た
<?php
// DB接続処理ほげほげ
（省略）
$sql = 'SELECT * FROM customer;';
$ret = mysql_query($sql, $db);
$rows = array();
while($row = mysql_fetch_assoc($ret)){ $rows[] = $row; }
?>
<html>
（略）
<?php
foreach($rows as $row){
（略）
}
?>
（略）
</html>
なんてのを、どう分けるか、何のために分けるか、というお話だと思うんだ。
その具体的な分け方・方向については・・・うーん俺は人に教えるほど
きちんと勉強していません。頑張れ！（ｵｲ）
77:nobodyさん
08/08/30 22:03:54 /jeGwvoC
>>76
ありがとうございます。参考にさせていただきます。
78:nobodyさん
08/08/31 11:40:02
>>75
えーとな。
まずフレームワークを使ってから
考えれ。
79:nobodyさん
08/08/31 18:59:51
>>75
>>78の言うように
まず既存のフレームワークを利用してみて、長所や短所を理解してから、
自分(とその周り)が使うに当たって必要な構造としてどうなってると使いやすいか考えて
設計しなきゃいけないんでない？
CIスレとかCakeスレで出てる疑問とかそこらのブログで出てるような疑問とかも割りと参考になりそうな気がします。
後、巷ではやってるフレームワークは付属のライブラリが充実してるってのもポイントだったり。
Viewにはテンプレートエンジンを使う必要があるのかとかも考えたり。
>>71がどのように考えてるか分かりませんが、結構重そうな内容ですね。
で、俺もまた、人に教えるほどきちんと勉強していません。頑張れ！(ｵｲ)
80:nobodyさん
08/08/31 22:02:43 BcOgvLp9
ありがとうございます。
ViewはSmartyの実績があるので、ほぼ確定かと思います。
あとはMCですね。
で、ご指摘の通り、既存のフレームワークをいくつか
実際に使ってみて、超シンプル版から作っていこうと思います。
それにしても結構種類ありますよね～。
81:nobodyさん
08/08/31 22:18:42
>>80
とりあえずCakePHPとCodeIgniterは分かりやすいかな。
SinfonyやEthnaも人気あるっぽいけど。
後は、とりあえず有名なフレームワークをそのまま流用して、
自分の作りたい方向性に足りないものを追加/修正してやって、
作っちゃうっていう方向性も検討の余地がありそうです。
82:nobodyさん
08/08/31 23:09:43
骨は例えばちいたんでもいいのでは
他のはどうしても、流儀を覚えてそれに則らないと
カスタマイズも難しいような所があるし
ライブラリは、ぶっちゃけPEARやZendを引っ張ってきて、
そのままではごちゃごちゃになるなら、その一部のコードを、
流用して使えば済むことも多い
83:nobodyさん
08/08/31 23:44:28 BcOgvLp9
>>81
なるほど、参考になります。ありがとうございます。
CodeIgniterは知りませんでした。勉強になります。
>>82
>流儀を覚えて
そうですよね。そのコストもありますよね。
ライブラリについては私も同感です。
PEARは今でも使ってますし、DBはADODBを使ってます。
84:nobodyさん
08/09/01 07:50:32
しかし、PEARやADODBを使えるのにフレームワークは自作しなきゃならん意味が分からんな。
85:nobodyさん
08/09/01 16:27:37
勝ち馬に乗れなくてサポートが止まったらどうするんだ、とか、
複雑すぎると兵隊に書かせられないから却下
（自社開発なら開発者が目の前にいるから例外）とか、
その手の腐った理由かもな。
自作FWなんて最初からサポート止まってるも同然なんだけど。
あとあれだ、
FW使った分だけ工数が削減されるがそれじゃ困る、
なんていう理由じゃないか？
86:nobodyさん
08/09/01 20:42:35
フレームワーク使うと大幅に工数下がるね。
でも、フレームワークを勉強するためのコストが要るね。
でもさ、そもそも最低限の勉強をしてから実践投入しろと。
フレームワーク＝最低限の勉強だよ。
87:nobodyさん
08/09/02 15:46:31
自分の印象では、CodeIgniterは分かりやすくて良かったです。
SymfonyとかCakePHPは、使い方を学習する段階で、面倒くさいな～と思ってしまいました。
辛抱強く性格でないと、じっくり腰をすえてフレームワークの使い方を学ぶ段階が苦痛に感じられますね？
Zend Frameworkも解説本は分かりやすかったです。
ちいたんはチュートリアルが不十分であると感じました。
EthnaやMapleは試してないので分かりません。
「日本向けの携帯サイトを作る」という視点で見た場合、各フレームワークの使いやすいさ、機能はどうでしょうか？
88:nobodyさん
08/09/02 19:21:26 kKY94AaP
一般的に、フレームワークでは、
データベースの外部キー制約を設置していた場合、
親テーブルの行を削除したら、
対応する子テーブルの行も削除されるようになっているのでしょうか？
89:nobodyさん
08/09/02 20:08:08
>>88
参照整合性制約（外部キー）までチェックしてデータ操作してくれる
モデルを実装しているフレームワークは寡聞にして聞いたことが無い。
有ったら俺も知りたいな。
90:nobodyさん
08/09/02 20:41:21
Zend_Dbはそんな感じのやつあったんじゃね？
91:nobodyさん
08/09/02 20:51:11
ON DELETE CASCADEではだめなん?
DBのパフォーマンスのため、参照整合性制約を付けずにアプリケーション側で
実装する場合もあるとは思うけど、外部キー制約してるんだよね?
92:nobodyさん
08/09/09 00:13:17
既出だけどsabelなるフレームワークが出てるけど、最近はルーティングとかYAMLとかの設定ファイルに書かないのが流行りなの？
93:nobodyさん
08/09/13 19:22:25 lKt9XZcp
テンプレートメソッドってだいたいprotectedにするじゃん
そしてzend規約では、protectedなメソッドの名前は_hogeにする
でも、子に_付きのメソッドのオーバーライドを求めるのって
何かきもくね？
_を付けるってのは、「内側で使ってる」っていうしるしで、
テンプレートメソッドは、子とはいえ、自分以外に実装をまかせるという、
ある種の外側志向。その齟齬がきもさの原因と思う。
publicにするか、規約を破るか、きもさを受け入れるか・・悩ましいぜ
94:nobodyさん
08/09/13 21:34:17
そういう文化的な気持ち悪さはわかりにくいな
例えば private と protected をわけるスタイルもある
_ と __ とか （←わかりにくいｗ）
Zendは特にわけてないのかな？
95:nobodyさん
08/09/13 22:06:52
__は__setとか__constratみたいのがあるじゃん
96:nobodyさん
08/09/13 22:09:06
↑予約メソッドをリストアップして回避すればいいじゃん
そんなに無いよ
97:nobodyさん
08/09/13 22:11:08
そこはPHPが糞としか言いようがないな
せめて予約メソッドは、__set__ とか __clone__ とかにしておいてくれればｗ
98:nobodyさん
08/09/13 22:12:10
めんどい
99:nobodyさん
08/09/13 22:14:01
___set っていうのもありか。
コーディングの自由度の幅や読みやすさを考えるなら、
いっそ予約されたメソッドなんかは
__reserved_method_CONSTRUCT()
くらいやってくれてもなんの問題もないしな
100:nobodyさん
08/09/13 22:25:24
->が一番嫌いなんだよな
.がいいよな.のほうがカッコいい
101:nobodyさん
08/09/13 22:30:28
>>96
__ で始まるのは 全部 予約メソッドなんだが
102:nobodyさん
08/09/13 22:35:44
>>100
そうすると、文字列連結が + になり、
連鎖的に toString() 的なメソッドが欲しくなり・・・
Cっぽいな strval() をがんがん使うつもりならそれでもいいが、
Perl派生言語のジレンマを、そう気軽に語ってくれるなｗ
>>101
それはPHPの「仕様」ではないよね。雰囲気ではそうかもだけど。
実際、ユーザ定義のメソッドで __ が使えない訳ではない。
103:nobodyさん
08/09/13 22:53:57
protectedとprivateは別物なのに、_で一緒くたにしているのは、
ZF規約の欠点ではなかろうか。
ZF自体の作りの洗練されなさを考えると、
深い考えがあってそうしたものでもなさそう。
実際symfonyなんかは、Javaと同じでプレフィックス付けたりしてないし。
Rubyでもそんな習慣聞いたことない。
PHP4の呪縛を引きずってるだけじゃね？
こんな規約、いらないんじゃね？
104:nobodyさん
08/09/13 22:59:30
>>103
publicと、private,protectedの区別をメソッド名でつけることは、
意味がないとは思わない
> protectedとprivateは別物なのに、
っていうのは同意だけどね
それについて、ここしばらくPHPの仕様がらみのレスが
付いてるように見えるんだがそれについてはどうなんだｗ
105:nobodyさん
08/09/14 00:28:45
>>100
.のが使いやすいのは同意なんだけど、加算演算子と文字列連結演算子が別なのは
PHPの数少ない美点の一つだと思ってる。
106:nobodyさん
08/09/14 01:05:36
>>105
それは単純にPerl由来なんだけどな。$ と同様に。
$ の使い方としては劣化してるし、この辺はもうPerl文化を切り捨てるか、
PHPの独自路線が欲しい所ではある
107:nobodyさん
08/09/14 01:09:29
配列が@とか%じゃないのは良いよな
あれきもいし
108:nobodyさん
08/09/14 02:35:06
PHPってびっくりするほど独自路線というものが無い言語のような気が...
Perlの遺産だったり、Cが透けて見えたり、Javaのパクリだったり...
で、だからこそ普及しているんじゃないかな。
あと関係ないけどPHP6で常にUnicodeモードを有効にしたのは英断だと思う。
パフォーマンスやメモリへの影響も今時のサーバで問題があるほどでもないし。
5系から6への移行は大変かもしれないけど、それで仕事が増えるなら構わないw
109:nobodyさん
08/09/14 03:31:07
ユニコードモードって何が変わるの？
110:nobodyさん
08/09/14 04:04:33
未だにPHP４とかの鯖あるし
４，５，６とか大変なんだが～
111:nobodyさん
08/09/14 04:10:29
新規案件で4の鯖はないっしょ。てか誘導しようよ
保守案件で4なら、ご苦労様としか言えぬｗ
6は、一応5.3と互換性を持たせるつもりみたいだね
その5.3が大変なんだろうけど、まだ見ないねぇ
112:nobodyさん
08/09/14 09:51:48
別にPHP4でも困らないけどな。PHP5の機能で役に立つのは例外くらいなもんだし。
113:nobodyさん
08/09/14 10:42:39
オブジェクトが代入でコピーされなくなったのは、地味に気持ちいい
114:nobodyさん
08/09/14 10:44:44
&付ければいいだけじゃん。
115:nobodyさん
08/09/14 11:30:26
cloneだろ
116:nobodyさん
08/09/14 14:34:14
4だから困るとか言うよりは、2系統あるのが困る
117:nobodyさん
08/09/16 20:53:37
>>115
コピーって言っちゃだめなの？
118:nobodyさん
08/09/16 23:08:17
>>117
>115は>114に対して
119:nobodyさん
08/09/17 13:33:07
PHPをやめるとしたら、何を使いますか？
・Ruby
・Python
・Perl
やっぱPythonかな？
120:nobodyさん
08/09/17 13:35:32
Perlは個人的にないな。
121:nobodyさん
08/09/17 13:41:27
>>119
仕事的には、PHPより高速で安定的に動作して、
月額1000円程度以上のレンサバには95%以上の確率で入ってるなら
なんでもいい。
そんなのある？
122:nobodyさん
08/09/17 13:43:47
つPerl & FastCGI
FastCGIの方は、95%にはちと足りんかな？ｗ
123:nobodyさん
08/09/17 13:50:56
Rubyに移行しようと思ったけど
ZendStudioがあるから結局PHP使ってる・・
124:nobodyさん
08/09/17 18:12:51
書いてて面白いのはPerlだね。
125:nobodyさん
08/09/17 18:45:58
じょうだんよしこさん
126:nobodyさん
08/09/17 22:00:15
PHPのつまらなさは異常
127:nobodyさん
08/09/18 02:36:03
qiq入れればまだ楽しめるよ
128:nobodyさん
08/09/18 16:41:27
ますかきおくん
129:nobodyさん
08/09/18 16:49:43
qiq面白いとは思うけど
コードの依存部分が全体に広がるエクステンションを入れるのはやっぱり抵抗あるわ
もしそれがダメになった時のことを考えると
130:nobodyさん
08/09/18 16:52:54
楽しめても、業務利用は無理っしょ
まだRubyで楽しんでる方が健全じゃねーかｗｗｗ
131:nobodyさん
08/09/18 19:11:26
趣味用の言語ならもっとマイナーな奴でもやれよ
132:nobodyさん
08/09/18 19:12:59 ykJuPDO5
>>129
別に、フレームワーク使ったってそのフレームワークに依存するじゃん
なんでQIQだと抵抗があるのか
133:nobodyさん
08/09/18 20:57:09
そりゃあんた、なんか不可解な挙動があったときに、どこまで自分の力で
調べて修正できるのかって点で、違いすぎるだろｗ
ぶっちゃけ、PHPのコアに関わっている人間にとっての別実装や実験として
でもなければ、QIQなんておもちゃ以外の何者でも無かろうが
134:nobodyさん
08/09/18 21:38:02
将来PHPがバージョンアップして
qiqの開発が停止して非対応だったら
それまで書いたqiq依存コードがもろとも脂肪じゃん。
フレームワーク使っててもフレームワーク非依存なプレーンなクラスは書いていくし
そういうのは流用が効く。
135:nobodyさん
08/09/19 00:57:48
PHPにもApacheにも何も保証があるわけじゃないのに。
PHP5依存コードが脂肪しない保証もない。
Zendと契約結んでる？ そりゃ失礼しました。
136:nobodyさん
08/09/19 03:33:16
>>135
確率の問題
137:nobodyさん
08/09/19 12:02:16
PHPのフレームワークと、土台のPHP・Apacheとを、どうやったら
同一視できるのか
また、ユーザの少ないというか皆無に近いQIQなるエクステンションと、
ばりばり商用利用され、長期間メンテの続いている普及率抜群の
プロジェクトとを同一視できるのも素晴らしい
>>132とか>>135とかは、きっと「フレームワーク」の中を調べたりましてや
いじったりなんて、思いもしないユーザなのかな？
ひょっとして全部同列に見えるくらいのスーパーハカーですか？
138:nobodyさん
08/09/19 18:10:39
PHPユーザーは裾野が広いってことでしょう。
サンデープログラマーから職業プログラマーまで幅が広い。
QIQは素晴らしいエクステンションだから、PHPを支援しているIBMやマイクロソフトとかの大手企業に支援してもらったらいいんじゃないですか？＞作者の方
139:nobodyさん
08/09/20 13:23:29
ラムダとか5.3で導入されるじゃん
qiqって何が素晴らしいの？
140:nobodyさん
08/09/20 13:42:12
前スレでさんざん出てた [] じゃね？
執着してる人が結構いるようだし
141:nobodyさん
08/09/21 05:27:57
[]とハッシュ{}はほしいねぇ
あと -> を . にすれば書くのも読むのも楽だ
142:nobodyさん
08/09/21 05:32:43
C/C++の話かよｗ
143:nobodyさん
08/09/21 18:00:01
>>137
>PHPのフレームワークと、土台のPHP・Apacheとを、どうやったら
>同一視できるのか
おいおい、PHPの安定性をApacheと同じにしないでくれよ。
どうせPHPだってver4のサポートなんてもう打ち切られるじゃん。
未来永劫サポートされるわけじゃないし、どっちもどっち。
PHPもフレームワークもQIQも、どれもオープンソースじゃん。
だれかのメンテに頼るのもいいけど、必要なら自分でメンテすればいいじゃんか。
QIQなんてただのライブラリにすぎないんだから、そのくらいできるだろ。
でかいフレームワークのコード読むよりは小さいQIQのほうが楽。
144:nobodyさん
08/09/21 19:43:02
> QIQなんてただのライブラリにすぎないんだから、
ライ・・ブラリ・・・？
> でかいフレームワークのコード読むよりは小さいQIQのほうが楽。
確かにそうかもしれんが、QIQが何をやってどこを修正すれば
どうなるかってのをつかむ為には、少なくともCとBison(Yacc)と
PHPのCソースコードに関する知識が必要。
てか「楽」じゃねーよｗ
145:nobodyさん
08/09/21 20:08:55
QIQのソースコード読むのが楽なわけないが。少なくともPHPのウェブフレームワークなんかよりは遙かにスキルが要求される。
146:nobodyさん
08/09/21 21:37:07
あれはPHPの拡張モジュール作るのには必要ない、文書化もされていないようなAPIを叩いてるからね...
単体では短くても、理解しようとするとZend Engineのソースコード全体を見る羽目になるw
それとは関係ないけど、拡張モジュールを作るなら何気にPHP6はAPIが使いやすくなってる。
5.3もUnicode関連を除いてほぼ6相当だけど、便利な関数が5.3だけZEND_APIとしてエクスポートされていなくて切ないことも。
147:nobodyさん
08/09/22 00:20:44
>>145
>QIQのソースコード読むのが楽なわけないが。少なくともPHPのウェブフレームワークなんかよりは遙かにスキルが要求される。
それはおまえがWebのスキルしかないから。コンパイラコンパイラの初歩知識があれば、見れば分かる。
自分が慣れてる分野のコードは読めて、知識のない分野のコードは読めないのは当然。
148:nobodyさん
08/09/22 00:46:48
PHPで描かれたウェブのフレームワークとPHPのエクステンション、どっちが難解かは子供でも分かること
149:nobodyさん
08/09/22 01:04:16
いや、量によって変わるから、どちらが難解かは一概に言えない。
ただいえるのは、PHPという言語仕様を非公式変えてしまうようなものは
公式でPHPそのものが変わったときに対応が困難になるから
使うのはやめておけってこった。
150:nobodyさん
08/09/22 07:15:01
公式でPHPが変わったら、どっちもどっちじゃない?
151:nobodyさん
08/09/22 10:49:18
じゃない。
152:nobodyさん
08/09/22 16:45:08
アホな質問かも知れないけど、cakephpライクなフレームワークを作ろうかと
思ってるんですが、マジックメソッドの __get使ってモデルやコンポーネントの
呼び出しを下のようにやってみたいんだけど、何か問題あります？
class HogeController extends Controller
{
function index()
{
$data = $this->Model->classname->find();
$this->Component->classname->hogehoge();
}
}
153:nobodyさん
08/09/23 00:47:41
>>152
$this->Modelとか$this->Componentの__get()で、
与えられたクラス名のオブジェクトを生成・取得するって仕組み？
特に悪いとも思わないけど、必要とか便利とかもあんまり思わないｗ
例えば設計思想とか、利用時の利便性とかもあるんだろうけど、
同じ事をするのに、Model::factory()とかModel::singleton()でも
いい場合もあるかもだし
ピントはずれだったらｽﾏｿ
154:nobodyさん
08/09/23 00:51:04
>>153 微妙に修正
> 同じ事をするのに、Model::factory()とかModel::singleton()でも
→ 同じ事をするのに、Model::factory(classname) とか new classname() とか classname::singleton() とかでも
155:nobodyさん
08/09/23 02:07:19
new は method chain できないから却下
156:152
08/09/23 15:14:04
cakephpだとコントローラーのプロパティに
使うコンポーネント設定するのいちいち面倒だな～と思ってたんで。
そういうやり方もあるんですね、勉強になります。有り難うございました。
157:nobodyさん
08/09/23 17:34:13
∧＿∧
（ ´∀｀）＜ ぬるぽプロジェクト
みんなで面白いサイト作って有名にしようぜ！
ｽﾚﾘﾝｸ(news4vip板)
★まとめwiki
URLﾘﾝｸ(www39.atwiki.jp)
PHPのフレームワークとして symfonyを採用予定です。
158:nobodyさん
08/09/23 20:55:42
>>157
スレ荒れすぎワロタ
159:nobodyさん
08/09/23 21:24:50
>>158
自動保守おいしいです（^q^）
160:nobodyさん
08/09/26 16:21:57
フレームワークとは直接関係ないけど5.3でspl_autoload_register(function($name){...});
すると実際にautoloadされるときにbus erorrで落ちるね。
spl_autoload_register($f=function($name){...}); なら$fが生きている間だけは落ちない。
161:nobodyさん
08/09/26 16:42:24
5が出ても枯れるまで結構時間かかったし
6も使えるようになるまでは長いだろうなぁ
162:nobodyさん
08/09/27 08:37:12
一人で最初期モックアップ作るなら、
railsとcakephpと、どっちが向いてる？
163:nobodyさん
08/09/28 11:02:03
その比較って意味あるのかな？
Ruby（少なくともRails）とPHPが同等にできる人にとってしか答えようがないし、
回答もしかりw
164:nobodyさん
08/09/28 11:49:26
cakeみたいな厨フレームワーク使ってる人恥ずかしくないんですかぁ
165:nobodyさん
08/09/28 15:59:10
んじゃ何使えばいいの？
166:nobodyさん
08/09/28 18:15:32
☆Z☆E☆N☆D☆!!
167:nobodyさん
08/09/28 22:06:23
Zend…
無いわー
168:nobodyさん
08/09/28 23:15:36
zend使いまくりだけど
何が不満なのかわからない
169:nobodyさん
08/09/29 06:03:55
モックならちいたんで良いジャマイカ。
170:nobodyさん
08/09/30 00:08:37
モックなら素のPHPでいいよ
171:nobodyさん
08/09/30 00:17:33
モックはHTMLで十分なこともおおくない？ｗ
ヘッダフッタ辺りのレイアウトとかで楽したいなら、
手慣れたテンプレートエンジンがあればいいかもだけど
フレームワークってのとはちょっと違うような
多分必要なのはView側の省力化・柔軟性かなあ
172:nobodyさん
08/09/30 00:41:51
マックでいいよ
173:nobodyさん
08/09/30 01:56:27
楽天がセッションidごとgoogleにキャッシュされ、
個人情報を漏らしまくって最終的にPHP脂肪ｗｗｗ
174:nobodyさん
08/09/30 03:55:27 CLW/UbJj
物区ならPencilでいいんじゃね
175:nobodyさん
08/09/30 06:24:36
つーかsymfony一択だろ
フレームワーク作者で一番センスあるコード書くのがフランチョス。
176:nobodyさん
08/09/30 07:01:23
symfonyは関数名がダサい
_区切りとかKENTかよｗ
177:nobodyさん
08/09/30 07:07:59
そんな規約ないよ
何かと間違えてないか？
178:nobodyさん
08/09/30 07:12:10
あれれ～symfonyじゃなかったっけ？
179:nobodyさん
08/09/30 07:26:27
symfonyはJavaと同じキャメルケースだよ
180:nobodyさん
08/09/30 19:28:17
そもそもPHPの標準関数の命名がいい加減なんだから、拘っても意味ない。
181:nobodyさん
08/10/01 01:38:54
PHPはキャメルケースとアンダースコア混在しまくってるからな
クラス名とか関数名とか考えるとき、どっちにしようかいつも迷ってしまう
182:nobodyさん
08/10/01 01:50:42
それ単に昔の関数と最近のクラスメソッドなだけだろ
183:nobodyさん
08/10/01 07:31:56
将来的にはほとんどオブジェクト指向のラッパーが用意されて
関数は地下に潜った存在になるだろうな
184:nobodyさん
08/10/02 19:06:50
最近のは殆どキャメルケースに一本化の流れなんかね
アンダースコア派だったからどうもなじめない
185:nobodyさん
08/10/02 19:46:59
オブジェクト指向な関数（メソッド）で
アンダースコアが普及しているような言語あるの？
186:nobodyさん
08/10/02 19:54:09
るｂｙ
187:nobodyさん
08/10/02 19:55:23
くそ言語wｗ
188:nobodyさん
08/10/02 19:59:51
PHPに言われたらしめぇだべ
189:nobodyさん
08/10/02 20:29:01
PHPよりも糞な言語なんてINTERCALくらいだろ
190:nobodyさん
08/10/02 20:58:24
キャメルケースでも、メソッド名でM$流のUpperCamelCaseは勘弁して欲しい
それはクラス名だけでいいと思う
191:nobodyさん
08/10/02 21:19:41
メソッドをアッパーキャメルケースで書く人なんているの？
そんなコード見たことない
192:nobodyさん
08/10/02 21:28:23
C#とかかじった人はやる。
携帯ミドルウェアとかやっててC/C++は触るがJavaは触らない、って人もやる。
まあぶっちゃけ Java vs. C# なんだけど、PHPは中途半端なので混在してる。
その点Rubyは、作ってる・使ってる人間がC・Perl on *nix の人メインなので、
アンダースコア派が主流なのかな
また、RubyではUpperCamelCaseは文法的に定数扱いされるので、メソッド名や
通常の変数名には使えない。・・・MS流が嫌いなのか？ｗ
193:nobodyさん
08/10/03 00:28:34
そういう書き方の自由を奪う言語は嫌われる。
194:nobodyさん
08/10/03 02:07:48
Rubyの_でつなぐのはPerl由来だろうね。俺は_でつなぐのが見やすくて好きだけどな。
PHPはJava風なんだけど、初期に出来た関数の命名が超適当だからな。引数の取り方とかも。
C#とかJavaはどうせIDE使うんで、まあ、どうでもいいような気がする。
195:nobodyさん
08/10/03 11:11:04
大文字小文字を区別しないものにCamelCaseを使うのは、ちょっと気持ち悪い
196:nobodyさん
08/10/03 14:57:50
キャメルケースの種類
アッパーキャメルケース (UCC)、またはパスカルケース(PascalCase)
複合語の先頭を、大文字で書き始める。
つづり例：CamelCase
ローワーキャメルケース (LCC)、または単にキャメルケース
複合語の先頭を、小文字で書き始める。
つづり例：camelCase
197:nobodyさん
08/10/03 15:09:46
なんでわざわざ書いたん？
自分用メモか？
198:nobodyさん
08/10/03 15:43:33
初めて知ってうれしかった
199:nobodyさん
08/10/03 16:36:40
CSSですらできる多重継承ができないPHPって一体・・・
200:nobodyさん
08/10/03 17:18:11
Mixinがあれば多重継承なんて必要ありませんよ
201:nobodyさん
08/10/03 17:57:27
>>199
Javaもですが・・
202:nobodyさん
08/10/03 18:04:06
Mixinを提供しているRubyだけがCSSと肩を並べているということですね
203:nobodyさん
08/10/03 19:59:32
つまり、いや、やめておこう
204:nobodyさん
08/10/03 20:27:36
>>185
pythonもメソッド名は、アンダースコアが一般的かな。
クラス名はキャメルケースだけど。
205:nobodyさん
08/10/03 20:55:12
最後の文字だけ大文字にする逆キャメルケースにしてる人いる？
geThogEとか
206:nobodyさん
08/10/03 23:42:27
>>205
どうでもいいけど、読みづらくね？
207:nobodyさん
08/10/03 23:48:08
ゲ ソォグ イー と読んでしまった
208:nobodyさん
08/10/04 00:29:16
>>205
まずそうしようと思った意図はなんだｗ
さすがにこれは利点も考え付かんｗｗ
209:nobodyさん
08/10/04 00:31:58
難読化とかｗ
210:nobodyさん
08/10/04 04:52:10
<?php
class Class_Name
{
public function methodName( )
{
functionName($valOne, $valTwo);
if ($a == 1){
$b = 2;
}
}
命名規則、俺の結論はこのあたり。
URLﾘﾝｸ(framework.zend.com)
URLﾘﾝｸ(solarphp.org)
Zend, Solarあたり守っとけばPEARの規約でも問題ない。あとクラス名は_で区切っとかないとauto loaderがめんどい。
211:nobodyさん
08/10/04 07:46:06
if (---) {
212:nobodyさん
08/10/04 13:25:04
>>210
>あとクラス名は_で区切っとかないとauto loaderがめんどい。
kwsk
213:nobodyさん
08/10/04 15:19:20
>>212
>>210じゃ無いけど、ディレクトリ構造を反映ってことじゃない？
Perlのモジュール風？
Zend_Db_Table_Rowクラス => Zend/Db/Table/Row.php
ってな感じじゃないかと想像
214:nobodyさん
08/10/04 15:29:32
explodeですぐパスに変換できるってことか
たしかに_区切りはよさげだな
215:nobodyさん
08/10/04 20:31:20
へー
216:nobodyさん
08/10/05 02:47:20
>>213
その通り。フォローthx
PEARでもその命名でディレクトリきってるし、PEAR2ではそのルールでauto loader標準だと思ったよ。
217:nobodyさん
08/10/05 04:57:56
細かい話になってくるが、DBとかPDFとかいう略語の場合、
DBなのかDbなのか、PDFなのかPdfなのか、っていう違いも
あるねｗ
これがまた人によってまちまちだし、同じ人でも場合によって
違う場合がある
218:nobodyさん
08/10/05 05:28:14
zendスタイルにした時、そこが一番しっくり来なかったような気がする
あとプロパティはどうせ全部 private なので _ が面倒
219:nobodyさん
08/10/05 11:01:14
デザインパターン使うときはデザインパターンも名前に入れてる
例えばSolar_Auth_Adapter_Sql はパッケージ名はSolarで認証クラスをアダプターでSQLクラスで実装してるクラス。
Solar/Auth.php
Solar/Auth/Adapter.php Solar_Auth_Adapterクラスで抽象クラスを定義
Solar/Auth/Adapter/Sql.php Solar_Auth_Adapter_Sql クラスでSolar_Auth_Adapterクラスを実装
220:nobodyさん
08/10/06 14:16:23 H0RcPBpG
みんな努力してるんだなー。
参考になります＾＾
221:nobodyさん
08/10/07 00:37:43 h510jQqa
>>205
意味不明で面白い。ウケる。
222:nobodyさん
08/10/07 14:11:17
>>219
> デザインパターン使うときはデザインパターンも名前に入れてる
それ、使うときもあったり使わないときもあったり、
クラスに単一のパターンしか適用されない場合、
そのパターンの為のクラスの場合には、そういう名前付けられるけど
一つのクラスに複数のパターンが適用される場合困るんだよな。
223:nobodyさん
08/10/07 14:44:16
俺様フレームワークをやめようと思って、CakeかSymfonyを導入しようと思うけど
結局どれがいいんだ…
224:nobodyさん
08/10/07 14:53:14
逆に俺様フレームワークを公開して
スタンダードにしてやれ
225:nobodyさん
08/10/07 14:58:34
結局はちいたんでいいじゃんっていうレスがつく未来が見える
226:nobodyさん
08/10/07 20:28:02
ちいたんは、その名前が失敗の理由のひとつである。
227:nobodyさん
08/10/07 21:32:19
>>225
結局はちいたんで（ｒｙ
228:nobodyさん
08/10/08 02:29:04
>>227
早いわｗ
229:nobodyさん
08/10/10 00:45:42
まあ増えすぎたよね
機能追加しすぎで扱いにくいWEBサービスのようだ
230:nobodyさん
08/10/16 15:04:15
>>225
まあ徴兵制だろうね。
戦前（に成人した）世代と戦後世代の日本人を見比べれば一目瞭然。
231:nobodyさん
08/10/16 15:31:37
なんだ？この妙に右よりの誤爆は
232:nobodyさん
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のパフォーマンスの悪さは改善されてないのかな？