【PHP】フレームワークについて語るスレ10【総合】
|
|
|
※ このスレは 【PHP】フレームワークについて語るスレ11【総合】 です
いきなりミス。ｽﾏｿ...
いきなりミス。ｽﾏｿ...
過去スレ
【PHP】フレームワークについて語るスレ10【総合】
http://pc11.2ch.net/test/read.cgi/php/1202521438/
【PHP】フレームワークについて語るスレ9【総合】
http://pc11.2ch.net/test/read.cgi/php/1197383840/
【PHP】フレームワークについて語るスレ8【総合】
http://pc11.2ch.net/test/read.cgi/php/1192604501/
【PHP】フレームワークについて語るスレ7【総合】
http://pc11.2ch.net/test/read.cgi/php/1181350116/
【PHP】フレームワークについて語るスレ6【総合】
http://pc11.2ch.net/test/read.cgi/php/1171896620/
[PHP]フレームワークについて語るｽﾚ5[総合]
http://pc10.2ch.net/test/read.cgi/php/1159579507/
[PHP]フレームワークについて語るｽﾚ4[総合]
http://pc8.2ch.net/test/read.cgi/php/1151706907/
[PHP]フレームワークについて語るｽﾚ３[総合]
http://pc8.2ch.net/test/read.cgi/php/1145971945/
[PHP]フレームワークについて語るｽﾚ２[総合]
http://pc8.2ch.net/test/read.cgi/php/1135847024/
【PHP】フレームワークについて語るスレ【総合】
http://pc8.2ch.net/test/read.cgi/php/1123608068/
【PHP】フレームワークについて語るスレ10【総合】
http://pc11.2ch.net/test/read.cgi/php/1202521438/
【PHP】フレームワークについて語るスレ9【総合】
http://pc11.2ch.net/test/read.cgi/php/1197383840/
【PHP】フレームワークについて語るスレ8【総合】
http://pc11.2ch.net/test/read.cgi/php/1192604501/
【PHP】フレームワークについて語るスレ7【総合】
http://pc11.2ch.net/test/read.cgi/php/1181350116/
【PHP】フレームワークについて語るスレ6【総合】
http://pc11.2ch.net/test/read.cgi/php/1171896620/
[PHP]フレームワークについて語るｽﾚ5[総合]
http://pc10.2ch.net/test/read.cgi/php/1159579507/
[PHP]フレームワークについて語るｽﾚ4[総合]
http://pc8.2ch.net/test/read.cgi/php/1151706907/
[PHP]フレームワークについて語るｽﾚ３[総合]
http://pc8.2ch.net/test/read.cgi/php/1145971945/
[PHP]フレームワークについて語るｽﾚ２[総合]
http://pc8.2ch.net/test/read.cgi/php/1135847024/
【PHP】フレームワークについて語るスレ【総合】
http://pc8.2ch.net/test/read.cgi/php/1123608068/
【洋モノ】
symfony
http://www.symfony-project.com/
code igniter
http://codeigniter.com/
Zend Framework
http://framework.zend.com/manual/ja/index.html
CakePHP
http://www.cakephp.org/
【和モノ】
ちいたん
http://php.cheetan.net/
Ethna
http://ethna.jp/
guesswork
http://classic.guesswork.jp/
maple
http://kunit.jp/maple/
symfony
http://www.symfony-project.com/
code igniter
http://codeigniter.com/
Zend Framework
http://framework.zend.com/manual/ja/index.html
CakePHP
http://www.cakephp.org/
【和モノ】
ちいたん
http://php.cheetan.net/
Ethna
http://ethna.jp/
guesswork
http://classic.guesswork.jp/
maple
http://kunit.jp/maple/
Mapleイラネ
6 ：nobodyさん：2008/08/25(月) 14:32:05 ID:qgfF3K9X
agavi
age
age
何使おうか考え中
ZendがPHPにかなり力を入れてるから将来性があると思うんだけど
評価が悪くて使えそうにない
ZendがPHPにかなり力を入れてるから将来性があると思うんだけど
評価が悪くて使えそうにない
9 ：nobodyさん：2008/08/25(月) 16:58:15 ID:hwjRu6i6
セッションデータって毎回全体を読み書きするから
あんまり大きいデータは扱いたくないよな。
かといってテンポラリーなデータを永続データが入ってるDBに突っ込むのは
抵抗がある。
こういう場合どうする？
あんまり大きいデータは扱いたくないよな。
かといってテンポラリーなデータを永続データが入ってるDBに突っ込むのは
抵抗がある。
こういう場合どうする？
xmlって一部を読み書きできるの？
結局全読み・全書きになるのでは？
結局全読み・全書きになるのでは？
>>9
1. 気にせずDBに放り込む
2. 「永続データが入って」いないDBに放り込む
3. 「一部を読み書きできる」ように細分化してファイルに放り込む
4. 気にせず毎回全部読み書きする
なんでもいいんじゃないの？
1. 気にせずDBに放り込む
2. 「永続データが入って」いないDBに放り込む
3. 「一部を読み書きできる」ように細分化してファイルに放り込む
4. 気にせず毎回全部読み書きする
なんでもいいんじゃないの？
>>7
>評価が悪くて使えそうにない
せめて情報が無くて使えそうにないって言ってくれｗ
ユーザの声（マニュアルではない、もすこし身近なTips、ノウハウなど）が
圧倒的に不足しているよね
でもそれはどのフレームワークも一緒か。
そもそも乱立しすぎじゃね？
例えばせめてライブラリ系はZendを使うとか、そんな風潮になればノウハウは
蓄積されていくんだろうけど
>評価が悪くて使えそうにない
せめて情報が無くて使えそうにないって言ってくれｗ
ユーザの声（マニュアルではない、もすこし身近なTips、ノウハウなど）が
圧倒的に不足しているよね
でもそれはどのフレームワークも一緒か。
そもそも乱立しすぎじゃね？
例えばせめてライブラリ系はZendを使うとか、そんな風潮になればノウハウは
蓄積されていくんだろうけど
シンプルなページを各フレームワークで実装したベンチマーク
http://talks.php.net/show/froscon08/
結果だけまとめると
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
http://talks.php.net/show/froscon08/
結果だけまとめると
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さん：2008/08/26(火) 00:48:34 ID:lM6BRZm9
cakephpってそんな遅いんだ。
いちおうDrupalはCMS向けのモジュラー式フレームワークってことになってる。
cakeで開発しようと思ったけど、
cakeもどきの俺様フレームワーク作ってやるかな。
cakeもどきの俺様フレームワーク作ってやるかな。
そういや、PEAR2ってどうなったの？
PEAR2は5.3合わせでしょ
23 ：nobodyさん：2008/08/27(水) 11:52:55 ID:n0GZd29C
思ったんですが、
singletonって全部staticなクラスとほとんど同じでは？
むしろ、singletonの機構を書く必要がない分、
staticなクラスの方がいいのではないかとも思うのですが
singletonのアドバンテージって何ですか？
singletonって全部staticなクラスとほとんど同じでは？
むしろ、singletonの機構を書く必要がない分、
staticなクラスの方がいいのではないかとも思うのですが
singletonのアドバンテージって何ですか？
>>23
顔洗って出直して来い
顔洗って出直して来い
signletonはobject
(PHPの)クラスはobjectではない
ぜんぜん違うだろ
(PHPの)クラスはobjectではない
ぜんぜん違うだろ
顔洗って出直してきました。
で？
で？
全然違うって言う奴は分かってないだけ
分かってる人の返答お待ちしております
分かってる人の返答お待ちしております
唯一のインスタンスを取り扱うためのsingletonでしょ
なのにstaticなクラスがいいとか全然違うよ
分かってないのはあなた
singletonをもう一度調べ直してみ
なのにstaticなクラスがいいとか全然違うよ
分かってないのはあなた
singletonをもう一度調べ直してみ
メソッドはstaticでもつかえるし、PHP5からはデータもクラスで持てる
Hoge::page() ではなく Hoge::instance()->page() にするメリットはなにかと
言うことだと思うんだけど
まあインスタンスにしておけば、変数に放り込んで引数で渡したり、
簡単に別クラスに差し替えたり、そう言う事ができるかもしれない
私もよくわからんので、違うっていう人の親切な解説があれば嬉しいな
Hoge::page() ではなく Hoge::instance()->page() にするメリットはなにかと
言うことだと思うんだけど
まあインスタンスにしておけば、変数に放り込んで引数で渡したり、
簡単に別クラスに差し替えたり、そう言う事ができるかもしれない
私もよくわからんので、違うっていう人の親切な解説があれば嬉しいな
singletonはsingletonっていうインスタンスは必ず一つなのが
保証されますよっていうパターンの概念なわけで、別に
staticなクラスの作りでsingleton的な扱いをすることもできるだろうけど、
ただそれが「singletonって全部staticなクラスとほとんど同じ」かと
言われればそりゃ違うって答えるだろう
概念の話とコードレベルの話だし質問がおかしい
ある程度有名なパターンだからsingletonってこういうもの、
という共通認識がプログラマにあるのがアドバンテージなわけであって
このクラスはsingletonだからインスタンスは唯一、とすぐ把握できるところを
オレオレsingleton概念で「これ俺なりのsingleton！インスタンスはナイっス！」
とか言われても困るわけで
Hoge::page() と Hoge::instance()->page() 云々も一緒で
要はそのクラスがどういう扱いなのかというのを認識するのに
singletonというパターンがあるよってだけの話であって
singletonだから絶対Hoge::instance()->page()な形ってわけでもないし
コードレベルの問題とはまた別の話かと
保証されますよっていうパターンの概念なわけで、別に
staticなクラスの作りでsingleton的な扱いをすることもできるだろうけど、
ただそれが「singletonって全部staticなクラスとほとんど同じ」かと
言われればそりゃ違うって答えるだろう
概念の話とコードレベルの話だし質問がおかしい
ある程度有名なパターンだからsingletonってこういうもの、
という共通認識がプログラマにあるのがアドバンテージなわけであって
このクラスはsingletonだからインスタンスは唯一、とすぐ把握できるところを
オレオレsingleton概念で「これ俺なりのsingleton！インスタンスはナイっス！」
とか言われても困るわけで
Hoge::page() と Hoge::instance()->page() 云々も一緒で
要はそのクラスがどういう扱いなのかというのを認識するのに
singletonというパターンがあるよってだけの話であって
singletonだから絶対Hoge::instance()->page()な形ってわけでもないし
コードレベルの問題とはまた別の話かと
>>23の無知さに全米が泣いたｗ
>>23はバカなの？死ぬの？
PHPでコンピュータプログラミングを学ぼうとすると、こうなっちゃう
ってことですね
ってことですね
34 ：nobodyさん：2008/08/27(水) 18:12:39 ID:8yHWP9d0
23 nobodyさん [] Date:2008/08/27(水) 11:52:55 ID:n0GZd29C Be:
思ったんですが、
singletonって全部staticなクラスとほとんど同じでは？
むしろ、singletonの機構を書く必要がない分、
staticなクラスの方がいいのではないかとも思うのですが
singletonのアドバンテージって何ですか？
晒しage
思ったんですが、
singletonって全部staticなクラスとほとんど同じでは？
むしろ、singletonの機構を書く必要がない分、
staticなクラスの方がいいのではないかとも思うのですが
singletonのアドバンテージって何ですか？
晒しage
おまえら説明出来ないからってシンプルに叩きすぎだｗ
ウェブアプリだとシングルトンパターンなんて使い道があんまりないからな。せいぜいDBハンドラぐらいだけど、それも普通にグローバル変数で扱えば十分だし。
結局説明はできない、と。
得意げにsingletonの解説始めちゃう奴なんなの？
そういうのを東洋じゃ釈迦に説法って言うんだぜ。
得意げにsingletonの解説始めちゃう奴なんなの？
そういうのを東洋じゃ釈迦に説法って言うんだぜ。
どこに釈迦がいるってんだい。
おつむがおしゃかな奴なら確かにいるようだが。
おつむがおしゃかな奴なら確かにいるようだが。
C++だとグローバル変数では初期化のタイミング不確定だから、シングルトンは有用だったりするけどな
>>23は質問自体が痛ｲよね
答えられなかった奴が必死の自己肯定ｗｗ
反論するなら論理的にしろ。な？
反論するなら論理的にしろ。な？
>>23の質問は別に痛いと思わない
痛々しさではむしろ>>31-34の方が
んで、>>23はsingletonと同じではないけど、別にそれでも
いいんじゃない？っていう認識はどんなもんですか ＞ エロい人
唯一性（？）の保証なら、コンストラクタ隠し忘れてたり__clone()上書き
してなかったりする半端singletonよりは確実とか考えたり。（そんな奴いない？）
インスタンスとして扱う必要がなくて、「singleton」と言いさえしなければ、
あれも十分実用的な考え方だと思うけど
叩くなら叩け
痛々しさではむしろ>>31-34の方が
んで、>>23はsingletonと同じではないけど、別にそれでも
いいんじゃない？っていう認識はどんなもんですか ＞ エロい人
唯一性（？）の保証なら、コンストラクタ隠し忘れてたり__clone()上書き
してなかったりする半端singletonよりは確実とか考えたり。（そんな奴いない？）
インスタンスとして扱う必要がなくて、「singleton」と言いさえしなければ、
あれも十分実用的な考え方だと思うけど
叩くなら叩け
object としてのふるまいが必要でないならそれでいいんじゃねえの。
staticメソッドとシングルトンパターンとじゃ、比較したり置き換えたり出来るもんじゃないんだよ。
>>30で十分説明してあるし、それ読んで分からないようなら、素養がなさ過ぎるので、プログラミングなんか止めた方が良い。
河原で野球でもしてろ。
>>30で十分説明してあるし、それ読んで分からないようなら、素養がなさ過ぎるので、プログラミングなんか止めた方が良い。
河原で野球でもしてろ。
>>30で書いているのは、singletonはパターンの名前で、型であり概念であると
いうことでおｋ？
OO言語でのstatic等と言うものの理解が全然ないのは確かだから
申し訳ないが、singletonと、くだんの実装方法との最大の違いはインスタンスを
使うかどうか、っていうことだけと思ってしまう。それはsingletonの概念に含まれるの？
>>23の手法に、また別な名前があったなら話はシンプルだとかそういう話？
いうことでおｋ？
OO言語でのstatic等と言うものの理解が全然ないのは確かだから
申し訳ないが、singletonと、くだんの実装方法との最大の違いはインスタンスを
使うかどうか、っていうことだけと思ってしまう。それはsingletonの概念に含まれるの？
>>23の手法に、また別な名前があったなら話はシンプルだとかそういう話？
そこで意表をついてガンパレードマーチ配信ですよ
誤爆ｽﾏｿ
>>45
もともとsingletonってデザインパターンは、Javaでのデザインパターンの話だし、
JavaプログラミングだとThreadって概念も出てくるから、全部staticなクラスよりも
singletonのほうが都合が良いとか、そういうことなんじゃないの？
もともとsingletonってデザインパターンは、Javaでのデザインパターンの話だし、
JavaプログラミングだとThreadって概念も出てくるから、全部staticなクラスよりも
singletonのほうが都合が良いとか、そういうことなんじゃないの？
>>48
うん。もともと、そういう実際上の都合も絡めての話題だと思った
てか singleton static でちょっとググっただけでわんさか出てきた
ttp://java-house.jp/ml/archive/j-h-b/048394.html
ttp://www.aerith.net/design/Singleton-j.html#no_use_case
ttp://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=22377&forum=12&start=16&23
ttp://www.sk-jp.com/java/pattern/singleton.html
ttp://oldblog.xenophy.com/index.php?entry=entry061224-024857
ttp://tome-programming.cocolog-nifty.com/blog/2006/08/singletonstatic_365e.html
↑（結構アレなのも混ざってるけど）
意外とみんな引っかかる点なんじゃないの？
>>23がそこで悩んだとしたら、むしろセンスがあるんじゃね？
痛いっていってる人らはみんなきっとこれを乗り越えているんだろうが優しくねえなー
うん。もともと、そういう実際上の都合も絡めての話題だと思った
てか singleton static でちょっとググっただけでわんさか出てきた
ttp://java-house.jp/ml/archive/j-h-b/048394.html
ttp://www.aerith.net/design/Singleton-j.html#no_use_case
ttp://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=22377&forum=12&start=16&23
ttp://www.sk-jp.com/java/pattern/singleton.html
ttp://oldblog.xenophy.com/index.php?entry=entry061224-024857
ttp://tome-programming.cocolog-nifty.com/blog/2006/08/singletonstatic_365e.html
↑（結構アレなのも混ざってるけど）
意外とみんな引っかかる点なんじゃないの？
>>23がそこで悩んだとしたら、むしろセンスがあるんじゃね？
痛いっていってる人らはみんなきっとこれを乗り越えているんだろうが優しくねえなー
>>49
俺も>>23の質問に対する正しい解答は知りたい。
>>44がいってる
＞staticメソッドとシングルトンパターンとじゃ、比較したり置き換えたり出来るもんじゃないんだよ。
っていうのも、少しずれてて、
>>23は、
全部staticなクラスを作るというデザインパターン と singletonというデザインパターンを比較してるのであって。
で、>>30の回答も、
そのアプリケーションを扱う人間が全部staticなクラスを作るというデザインパターンに対して共通認識を持ててたとしたら、
特に不都合は無い、ってことなのかな。
俺も>>23の質問に対する正しい解答は知りたい。
>>44がいってる
＞staticメソッドとシングルトンパターンとじゃ、比較したり置き換えたり出来るもんじゃないんだよ。
っていうのも、少しずれてて、
>>23は、
全部staticなクラスを作るというデザインパターン と singletonというデザインパターンを比較してるのであって。
で、>>30の回答も、
そのアプリケーションを扱う人間が全部staticなクラスを作るというデザインパターンに対して共通認識を持ててたとしたら、
特に不都合は無い、ってことなのかな。
全部staticなクラスって単なる構造化プログラミングじゃん。
>>51
それは言えるかも。オブジェクト指向ではないと。
まあぶっちゃけstaticなプロパティを、globalsのいらないglobal変数として
使ってる私が通りますよ、と。
原則がないといくら文法がJavaに近くなっても意味がないってことはありそう
でもそれはデザインパターンと直接には関係しないような
singletonにしたって、普通にglobalじゃんっていう評価みたいだし。俺はよくわからんけどね
それは言えるかも。オブジェクト指向ではないと。
まあぶっちゃけstaticなプロパティを、globalsのいらないglobal変数として
使ってる私が通りますよ、と。
原則がないといくら文法がJavaに近くなっても意味がないってことはありそう
でもそれはデザインパターンと直接には関係しないような
singletonにしたって、普通にglobalじゃんっていう評価みたいだし。俺はよくわからんけどね
オブジェクト指向は単なる表記方法ではなく考え方なので、
全部staticのクラスだろうがオブジェクト指向にすることは可能。
さらにいえば、別にクラスがなくても可能。
スレッドのないPHPではsingletonに色んなざっくばらんな代替方法があると。
ただ汎用的な知識としてはJavaのやり方が無難で
わざわざ他の方法をとることもないということだな。
よくわかった。
全部staticのクラスだろうがオブジェクト指向にすることは可能。
さらにいえば、別にクラスがなくても可能。
スレッドのないPHPではsingletonに色んなざっくばらんな代替方法があると。
ただ汎用的な知識としてはJavaのやり方が無難で
わざわざ他の方法をとることもないということだな。
よくわかった。
えらく短絡的なまとめきたー
てかそんな投げやりなまとめなら23とか名乗らず名無しで書けよｗ
ちょっとでも擁護したレスが軒並み後悔するような、嫌な感じだｗｗｗ
さあ寝よ
てかそんな投げやりなまとめなら23とか名乗らず名無しで書けよｗ
ちょっとでも擁護したレスが軒並み後悔するような、嫌な感じだｗｗｗ
さあ寝よ
？
別に君に擁護されなくても全く困らんよ？
もともと馬鹿に的外れな批判されても痛くもなんともないし
別に君に擁護されなくても全く困らんよ？
もともと馬鹿に的外れな批判されても痛くもなんともないし
56 ：nobodyさん：2008/08/29(金) 09:09:19 ID:EVgfNfnd
>>30みたいな説明じゃ、シングルトンがなにかも、staticメソッドと比べての利点もわかんないよ。
こんな説明をする先輩いるけど、ほんと自己満足だよな。
シングルトンのかわりにstaticメソッドでもいいじゃんというのは、そのとおり。
$obj = FooClass::getInstance();
$obj->method();
とするだけなら
FooClass::method();
でいいじゃんと思うのは自然なこと。
ただシングルトンはオブジェクト指向の機能を使えるので、
・継承が使える
・他のメソッドに引数として渡したりできる(オブジェクトなので)
・任意個の個数に設定できる(１個である必要はない)
という利点がある。こういった点が必要ないなら、staticメソッドで構わないよ。
たとえば
$obj = FooClass::getInstance();
other_function($obj);
ということをしたかったら、staticメソッドじゃなくてシングルトンのほうが自然だよね。
シングルトンもstaticメソッドもあくまで手段でしかないので、目的がstaticメソッドで満たせるなら
staticメソッドでもいいんじゃない。
こんな説明をする先輩いるけど、ほんと自己満足だよな。
シングルトンのかわりにstaticメソッドでもいいじゃんというのは、そのとおり。
$obj = FooClass::getInstance();
$obj->method();
とするだけなら
FooClass::method();
でいいじゃんと思うのは自然なこと。
ただシングルトンはオブジェクト指向の機能を使えるので、
・継承が使える
・他のメソッドに引数として渡したりできる(オブジェクトなので)
・任意個の個数に設定できる(１個である必要はない)
という利点がある。こういった点が必要ないなら、staticメソッドで構わないよ。
たとえば
$obj = FooClass::getInstance();
other_function($obj);
ということをしたかったら、staticメソッドじゃなくてシングルトンのほうが自然だよね。
シングルトンもstaticメソッドもあくまで手段でしかないので、目的がstaticメソッドで満たせるなら
staticメソッドでもいいんじゃない。
rubyのmixinみたいなことしたいのですが、どうしたらいいですか？
クラス定義の中から、
class Hoge {
self::mixin('OtherClass');
}
↓
HogeにOtherClassがmixinされる
みたいな形にしたいのですが。
runkitは不安定だったので使いたくありません。
クラス定義の中から、
class Hoge {
self::mixin('OtherClass');
}
↓
HogeにOtherClassがmixinされる
みたいな形にしたいのですが。
runkitは不安定だったので使いたくありません。
__call でがんばるか、ruby を使ってください
59 ：nobodyさん：2008/08/29(金) 11:13:07 ID:YM8BIoOF
>>57
RhacoというフレームワークではMix-inをサポートしているそうだからみてみるといいかも。
http://rhaco.org/
http://ll.jus.or.jp/2007/show/Event/Session/
> 変態的国産PHPフレームワークrhaco
> doctest、distutils、mix-in等PHPでは聞き慣れない機能について紹介します。
RhacoというフレームワークではMix-inをサポートしているそうだからみてみるといいかも。
http://rhaco.org/
http://ll.jus.or.jp/2007/show/Event/Session/
> 変態的国産PHPフレームワークrhaco
> doctest、distutils、mix-in等PHPでは聞き慣れない機能について紹介します。
>>59
ありが㌧みてみます
とりあえずsymfonyのsfMixerを見てみたけど
__callの中からsfMixerを呼んで、そこでバックトレース情報を利用して
混ぜられた側のメソッドにデレゲートしてる感じ
この方法だと、混ぜられた側のメソッドから
混ぜてる側のメンバにアクセスできないような・・・
ありが㌧みてみます
とりあえずsymfonyのsfMixerを見てみたけど
__callの中からsfMixerを呼んで、そこでバックトレース情報を利用して
混ぜられた側のメソッドにデレゲートしてる感じ
この方法だと、混ぜられた側のメソッドから
混ぜてる側のメンバにアクセスできないような・・・
rhacoのmixinはeval使ってました
速度さえ気にしなければeval使えば大抵のことできますね～
evalでいくしかないかな
速度さえ気にしなければeval使えば大抵のことできますね～
evalでいくしかないかな
全部staticメソッドにするというなら、それは構造化プログラミングそのものなわけで、それと比較するなら、オブジェクト指向プログラミングだろ。
シングルトンパターンという実装パターンの一つとじゃ比較の対象にならない。
シングルトンパターンという実装パターンの一つとじゃ比較の対象にならない。
構造化プログラミングとOOPを峻別してる奴なんなの？
OOPは構造化プログラミングを含んでるんだよ
書き方の問題ではない
OOPは構造化プログラミングを含んでるんだよ
書き方の問題ではない
64 ：nobodyさん：2008/08/29(金) 19:54:55 ID:YM8BIoOF
>>62
なに難しいこといってんの？
シングルトンでやろうとしていることは、staticメソッドでもできるんじゃね？というだけの話。
なんで構造化プログラムだとかオブジェクト指向との比較とかでてくるの？ばかなの？
なに難しいこといってんの？
シングルトンでやろうとしていることは、staticメソッドでもできるんじゃね？というだけの話。
なんで構造化プログラムだとかオブジェクト指向との比較とかでてくるの？ばかなの？
>>57
runkitは使ったことないですが、これは使ってます。
http://d.hatena.ne.jp/rsky/20080124/1201186473
qiqもすごくいい。もう普通のPHPは書けなくなるｗ
http://d.hatena.ne.jp/rsky/20080301/1204326365
runkitは使ったことないですが、これは使ってます。
http://d.hatena.ne.jp/rsky/20080124/1201186473
qiqもすごくいい。もう普通のPHPは書けなくなるｗ
http://d.hatena.ne.jp/rsky/20080301/1204326365
構造化プログラミングとオブジェクト指向プログラミングは比較して語られるものだよ。
あるプログラム、ある言語をを見て、それが構造化プログラミングなものなのか、オブジェクト指向プログラミングなのか、区別されるんだから。
その区別が出来ないというのは、人類皆兄弟とかいうたぐいの屁理屈だ。
あるプログラム、ある言語をを見て、それが構造化プログラミングなものなのか、オブジェクト指向プログラミングなのか、区別されるんだから。
その区別が出来ないというのは、人類皆兄弟とかいうたぐいの屁理屈だ。
もうお馬鹿ちゃんは書かない方がいいんじゃないか
自分を大きく見せようとする努力ほど無意味なものはない
自分を大きく見せようとする努力ほど無意味なものはない
オブジェクト指向プログラミングは、構造化プログラミングを含んでいるものだから、
プログラムを見て、オブジェクト指向プログラミング特有のクラス等を
（正しく）使っていればオブジェクト指向、使っていなければ構造化って判断をするな。
プログラムを見て、オブジェクト指向プログラミング特有のクラス等を
（正しく）使っていればオブジェクト指向、使っていなければ構造化って判断をするな。
69 ：nobodyさん：2008/08/30(土) 18:14:35 ID:OmTt4XZu
RUBYはオブジェクト指向を前提とした言語で、PERLは本来構造化言語なのをパッケージをクラスに流用することでオブジェクト指向の機能を持たせている。
昔の8ビットマイコン時代のBASICはGOTO文で処理を行き来する非構造化言語。
このプログラミングのパラダイムシフトは世界の共通認識だから。
昔の8ビットマイコン時代のBASICはGOTO文で処理を行き来する非構造化言語。
このプログラミングのパラダイムシフトは世界の共通認識だから。
>>68
「～判断をするな。」が、I do なのか you shouldn't do なのかわからん
>>69
>このプログラミングのパラダイムシフトは世界の共通認識だから。
だから、何なんだ
どうせならもう少し結論を明確にしてもいいんじゃないかと思う
話がふわふわして仕方がないｗ
「～判断をするな。」が、I do なのか you shouldn't do なのかわからん
>>69
>このプログラミングのパラダイムシフトは世界の共通認識だから。
だから、何なんだ
どうせならもう少し結論を明確にしてもいいんじゃないかと思う
話がふわふわして仕方がないｗ
71 ：nobodyさん：2008/08/30(土) 20:38:57 ID:/jeGwvoC
はじめまして、質問させてください。
社内でWebサービス構築のために
MVCモデルのPHPフレームワークを作ることになったのですが、
どのあたりまでの実装でフレームワークとして体をなすのか分かりません。
どなたか教えていただけませんでしょうか？
社内でWebサービス構築のために
MVCモデルのPHPフレームワークを作ることになったのですが、
どのあたりまでの実装でフレームワークとして体をなすのか分かりません。
どなたか教えていただけませんでしょうか？
それが分からない人達がフレームワークを作ることに意味があるとは思えない
既存のものを使った方がいいのでは？
既存のものを使った方がいいのでは？
73 ：nobodyさん：2008/08/30(土) 21:07:18 ID:/jeGwvoC
回答ありがとうございます。
私も車輪の発明になる気がしてどうも１００％乗り気になれないのです。
ちなみに72さんは自作フレームワークの作成または、
既存のフレームワークで、ずっと使い続けてるものありますか？
私も車輪の発明になる気がしてどうも１００％乗り気になれないのです。
ちなみに72さんは自作フレームワークの作成または、
既存のフレームワークで、ずっと使い続けてるものありますか？
>>72
オープンソース全面禁止とかいう規則の会社もあるらしいし、
意味が無いかどうかはわからないのでは？
（PHPやApache自体もオープンソースだから、それはないかもだけどｗ）
>>71
フレームワークを利用する目的って、多分複数案件で使い回す事が出来て、また
複数の開発者で、またある程度の期間にわたって共通認識・理解をもつことで、
開発コストおよび保守コストを抑えることだと思うんだ
後は、基本的な部品を気合い入れて作ることで、品質の最低ライン（主にセキュリティ面など）を
保証するという意味合いもあるけど
だから、どこまでというのは程度問題でしかないと、個人的には思う
やりすぎれば使い回しに自由がきかなくなったりするし、緩すぎれば保守コストの
軽減には役に立たなかったりするんじゃない？
極端に言えばディレクトリ構造を決めて使い回すだけでも、ある意味「フレームワーク」
だと思う
オープンソース全面禁止とかいう規則の会社もあるらしいし、
意味が無いかどうかはわからないのでは？
（PHPやApache自体もオープンソースだから、それはないかもだけどｗ）
>>71
フレームワークを利用する目的って、多分複数案件で使い回す事が出来て、また
複数の開発者で、またある程度の期間にわたって共通認識・理解をもつことで、
開発コストおよび保守コストを抑えることだと思うんだ
後は、基本的な部品を気合い入れて作ることで、品質の最低ライン（主にセキュリティ面など）を
保証するという意味合いもあるけど
だから、どこまでというのは程度問題でしかないと、個人的には思う
やりすぎれば使い回しに自由がきかなくなったりするし、緩すぎれば保守コストの
軽減には役に立たなかったりするんじゃない？
極端に言えばディレクトリ構造を決めて使い回すだけでも、ある意味「フレームワーク」
だと思う
75 ：nobodyさん：2008/08/30(土) 21:29:08 ID:/jeGwvoC
>>74
>だから、どこまでというのは程度問題でしかないと、個人的には思う
なるほど、なかなか外部の方との技術意見交換をする機会がなくて参考になります。
ありがとうございます。
実は1ヶ月ほど前に公開になったあるBtoBのWebサービスで
MVCではないですが、自作でフレームワークを作ってみました。
少しは楽できるのですが、ホントに方向性的に合ってるのか、
若干迷いつつあるんです。
上からMVCモデルのフレームワークを準備してくれと頼まれた中で、
また０から準備することが本当に必要なのか迷ってまして。。。
この掲示板でやめた方がいいなと思ったとしても
やらないといけないことには変わりないんですけれど。
>だから、どこまでというのは程度問題でしかないと、個人的には思う
なるほど、なかなか外部の方との技術意見交換をする機会がなくて参考になります。
ありがとうございます。
実は1ヶ月ほど前に公開になったあるBtoBのWebサービスで
MVCではないですが、自作でフレームワークを作ってみました。
少しは楽できるのですが、ホントに方向性的に合ってるのか、
若干迷いつつあるんです。
上からMVCモデルのフレームワークを準備してくれと頼まれた中で、
また０から準備することが本当に必要なのか迷ってまして。。。
この掲示板でやめた方がいいなと思ったとしても
やらないといけないことには変わりないんですけれど。
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>
なんてのを、どう分けるか、何のために分けるか、というお話だと思うんだ。
その具体的な分け方・方向については・・・うーん俺は人に教えるほど
きちんと勉強していません。頑張れ！（ｵｲ）
・各データの出し入れの基礎的な記述と、各データごとのロジック
・表示に関する基礎的な記述とロジック
を、実行スクリプトから切り離すのが最低限？
例えば、昔よく見た
<?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さん：2008/08/30(土) 22:03:54 ID:/jeGwvoC
>>75
>>78の言うように
まず既存のフレームワークを利用してみて、長所や短所を理解してから、
自分(とその周り)が使うに当たって必要な構造としてどうなってると使いやすいか考えて
設計しなきゃいけないんでない？
CIスレとかCakeスレで出てる疑問とかそこらのブログで出てるような疑問とかも割りと参考になりそうな気がします。
後、巷ではやってるフレームワークは付属のライブラリが充実してるってのもポイントだったり。
Viewにはテンプレートエンジンを使う必要があるのかとかも考えたり。
>>71がどのように考えてるか分かりませんが、結構重そうな内容ですね。
で、俺もまた、人に教えるほどきちんと勉強していません。頑張れ！(ｵｲ)
>>78の言うように
まず既存のフレームワークを利用してみて、長所や短所を理解してから、
自分(とその周り)が使うに当たって必要な構造としてどうなってると使いやすいか考えて
設計しなきゃいけないんでない？
CIスレとかCakeスレで出てる疑問とかそこらのブログで出てるような疑問とかも割りと参考になりそうな気がします。
後、巷ではやってるフレームワークは付属のライブラリが充実してるってのもポイントだったり。
Viewにはテンプレートエンジンを使う必要があるのかとかも考えたり。
>>71がどのように考えてるか分かりませんが、結構重そうな内容ですね。
で、俺もまた、人に教えるほどきちんと勉強していません。頑張れ！(ｵｲ)
80 ：nobodyさん：2008/08/31(日) 22:02:43 ID:BcOgvLp9
ありがとうございます。
ViewはSmartyの実績があるので、ほぼ確定かと思います。
あとはMCですね。
で、ご指摘の通り、既存のフレームワークをいくつか
実際に使ってみて、超シンプル版から作っていこうと思います。
それにしても結構種類ありますよね～。
ViewはSmartyの実績があるので、ほぼ確定かと思います。
あとはMCですね。
で、ご指摘の通り、既存のフレームワークをいくつか
実際に使ってみて、超シンプル版から作っていこうと思います。
それにしても結構種類ありますよね～。
>>80
とりあえずCakePHPとCodeIgniterは分かりやすいかな。
SinfonyやEthnaも人気あるっぽいけど。
後は、とりあえず有名なフレームワークをそのまま流用して、
自分の作りたい方向性に足りないものを追加/修正してやって、
作っちゃうっていう方向性も検討の余地がありそうです。
とりあえずCakePHPとCodeIgniterは分かりやすいかな。
SinfonyやEthnaも人気あるっぽいけど。
後は、とりあえず有名なフレームワークをそのまま流用して、
自分の作りたい方向性に足りないものを追加/修正してやって、
作っちゃうっていう方向性も検討の余地がありそうです。
骨は例えばちいたんでもいいのでは
他のはどうしても、流儀を覚えてそれに則らないと
カスタマイズも難しいような所があるし
ライブラリは、ぶっちゃけPEARやZendを引っ張ってきて、
そのままではごちゃごちゃになるなら、その一部のコードを、
流用して使えば済むことも多い
他のはどうしても、流儀を覚えてそれに則らないと
カスタマイズも難しいような所があるし
ライブラリは、ぶっちゃけPEARやZendを引っ張ってきて、
そのままではごちゃごちゃになるなら、その一部のコードを、
流用して使えば済むことも多い
83 ：nobodyさん：2008/08/31(日) 23:44:28 ID:BcOgvLp9
>>81
なるほど、参考になります。ありがとうございます。
CodeIgniterは知りませんでした。勉強になります。
>>82
>流儀を覚えて
そうですよね。そのコストもありますよね。
ライブラリについては私も同感です。
PEARは今でも使ってますし、DBはADODBを使ってます。
なるほど、参考になります。ありがとうございます。
CodeIgniterは知りませんでした。勉強になります。
>>82
>流儀を覚えて
そうですよね。そのコストもありますよね。
ライブラリについては私も同感です。
PEARは今でも使ってますし、DBはADODBを使ってます。
しかし、PEARやADODBを使えるのにフレームワークは自作しなきゃならん意味が分からんな。
勝ち馬に乗れなくてサポートが止まったらどうするんだ、とか、
複雑すぎると兵隊に書かせられないから却下
（自社開発なら開発者が目の前にいるから例外）とか、
その手の腐った理由かもな。
自作FWなんて最初からサポート止まってるも同然なんだけど。
あとあれだ、
FW使った分だけ工数が削減されるがそれじゃ困る、
なんていう理由じゃないか？
複雑すぎると兵隊に書かせられないから却下
（自社開発なら開発者が目の前にいるから例外）とか、
その手の腐った理由かもな。
自作FWなんて最初からサポート止まってるも同然なんだけど。
あとあれだ、
FW使った分だけ工数が削減されるがそれじゃ困る、
なんていう理由じゃないか？
フレームワーク使うと大幅に工数下がるね。
でも、フレームワークを勉強するためのコストが要るね。
でもさ、そもそも最低限の勉強をしてから実践投入しろと。
フレームワーク＝最低限の勉強だよ。
でも、フレームワークを勉強するためのコストが要るね。
でもさ、そもそも最低限の勉強をしてから実践投入しろと。
フレームワーク＝最低限の勉強だよ。
自分の印象では、CodeIgniterは分かりやすくて良かったです。
SymfonyとかCakePHPは、使い方を学習する段階で、面倒くさいな～と思ってしまいました。
辛抱強く性格でないと、じっくり腰をすえてフレームワークの使い方を学ぶ段階が苦痛に感じられますね？
Zend Frameworkも解説本は分かりやすかったです。
ちいたんはチュートリアルが不十分であると感じました。
EthnaやMapleは試してないので分かりません。
「日本向けの携帯サイトを作る」という視点で見た場合、各フレームワークの使いやすいさ、機能はどうでしょうか？
SymfonyとかCakePHPは、使い方を学習する段階で、面倒くさいな～と思ってしまいました。
辛抱強く性格でないと、じっくり腰をすえてフレームワークの使い方を学ぶ段階が苦痛に感じられますね？
Zend Frameworkも解説本は分かりやすかったです。
ちいたんはチュートリアルが不十分であると感じました。
EthnaやMapleは試してないので分かりません。
「日本向けの携帯サイトを作る」という視点で見た場合、各フレームワークの使いやすいさ、機能はどうでしょうか？
88 ：nobodyさん：2008/09/02(火) 19:21:26 ID:kKY94AaP
一般的に、フレームワークでは、
データベースの外部キー制約を設置していた場合、
親テーブルの行を削除したら、
対応する子テーブルの行も削除されるようになっているのでしょうか？
データベースの外部キー制約を設置していた場合、
親テーブルの行を削除したら、
対応する子テーブルの行も削除されるようになっているのでしょうか？
Zend_Dbはそんな感じのやつあったんじゃね？
ON DELETE CASCADEではだめなん?
DBのパフォーマンスのため、参照整合性制約を付けずにアプリケーション側で
実装する場合もあるとは思うけど、外部キー制約してるんだよね?
DBのパフォーマンスのため、参照整合性制約を付けずにアプリケーション側で
実装する場合もあるとは思うけど、外部キー制約してるんだよね?
既出だけどsabelなるフレームワークが出てるけど、最近はルーティングとかYAMLとかの設定ファイルに書かないのが流行りなの？
93 ：nobodyさん：2008/09/13(土) 19:22:25 ID:lKt9XZcp
テンプレートメソッドってだいたいprotectedにするじゃん
そしてzend規約では、protectedなメソッドの名前は_hogeにする
でも、子に_付きのメソッドのオーバーライドを求めるのって
何かきもくね？
_を付けるってのは、「内側で使ってる」っていうしるしで、
テンプレートメソッドは、子とはいえ、自分以外に実装をまかせるという、
ある種の外側志向。その齟齬がきもさの原因と思う。
publicにするか、規約を破るか、きもさを受け入れるか・・悩ましいぜ
そしてzend規約では、protectedなメソッドの名前は_hogeにする
でも、子に_付きのメソッドのオーバーライドを求めるのって
何かきもくね？
_を付けるってのは、「内側で使ってる」っていうしるしで、
テンプレートメソッドは、子とはいえ、自分以外に実装をまかせるという、
ある種の外側志向。その齟齬がきもさの原因と思う。
publicにするか、規約を破るか、きもさを受け入れるか・・悩ましいぜ
そういう文化的な気持ち悪さはわかりにくいな
例えば private と protected をわけるスタイルもある
_ と __ とか （←わかりにくいｗ）
Zendは特にわけてないのかな？
例えば private と protected をわけるスタイルもある
_ と __ とか （←わかりにくいｗ）
Zendは特にわけてないのかな？
__は__setとか__constratみたいのがあるじゃん
↑予約メソッドをリストアップして回避すればいいじゃん
そんなに無いよ
そんなに無いよ
そこはPHPが糞としか言いようがないな
せめて予約メソッドは、__set__ とか __clone__ とかにしておいてくれればｗ
せめて予約メソッドは、__set__ とか __clone__ とかにしておいてくれればｗ
めんどい
___set っていうのもありか。
コーディングの自由度の幅や読みやすさを考えるなら、
いっそ予約されたメソッドなんかは
__reserved_method_CONSTRUCT()
くらいやってくれてもなんの問題もないしな
コーディングの自由度の幅や読みやすさを考えるなら、
いっそ予約されたメソッドなんかは
__reserved_method_CONSTRUCT()
くらいやってくれてもなんの問題もないしな
->が一番嫌いなんだよな
.がいいよな.のほうがカッコいい
.がいいよな.のほうがカッコいい
>>96
__ で始まるのは 全部 予約メソッドなんだが
__ で始まるのは 全部 予約メソッドなんだが
>>100
そうすると、文字列連結が + になり、
連鎖的に toString() 的なメソッドが欲しくなり・・・
Cっぽいな strval() をがんがん使うつもりならそれでもいいが、
Perl派生言語のジレンマを、そう気軽に語ってくれるなｗ
>>101
それはPHPの「仕様」ではないよね。雰囲気ではそうかもだけど。
実際、ユーザ定義のメソッドで __ が使えない訳ではない。
そうすると、文字列連結が + になり、
連鎖的に toString() 的なメソッドが欲しくなり・・・
Cっぽいな strval() をがんがん使うつもりならそれでもいいが、
Perl派生言語のジレンマを、そう気軽に語ってくれるなｗ
>>101
それはPHPの「仕様」ではないよね。雰囲気ではそうかもだけど。
実際、ユーザ定義のメソッドで __ が使えない訳ではない。
protectedとprivateは別物なのに、_で一緒くたにしているのは、
ZF規約の欠点ではなかろうか。
ZF自体の作りの洗練されなさを考えると、
深い考えがあってそうしたものでもなさそう。
実際symfonyなんかは、Javaと同じでプレフィックス付けたりしてないし。
Rubyでもそんな習慣聞いたことない。
PHP4の呪縛を引きずってるだけじゃね？
こんな規約、いらないんじゃね？
ZF規約の欠点ではなかろうか。
ZF自体の作りの洗練されなさを考えると、
深い考えがあってそうしたものでもなさそう。
実際symfonyなんかは、Javaと同じでプレフィックス付けたりしてないし。
Rubyでもそんな習慣聞いたことない。
PHP4の呪縛を引きずってるだけじゃね？
こんな規約、いらないんじゃね？
>>103
publicと、private,protectedの区別をメソッド名でつけることは、
意味がないとは思わない
> protectedとprivateは別物なのに、
っていうのは同意だけどね
それについて、ここしばらくPHPの仕様がらみのレスが
付いてるように見えるんだがそれについてはどうなんだｗ
publicと、private,protectedの区別をメソッド名でつけることは、
意味がないとは思わない
> protectedとprivateは別物なのに、
っていうのは同意だけどね
それについて、ここしばらくPHPの仕様がらみのレスが
付いてるように見えるんだがそれについてはどうなんだｗ
配列が@とか%じゃないのは良いよな
あれきもいし
あれきもいし
PHPってびっくりするほど独自路線というものが無い言語のような気が...
Perlの遺産だったり、Cが透けて見えたり、Javaのパクリだったり...
で、だからこそ普及しているんじゃないかな。
あと関係ないけどPHP6で常にUnicodeモードを有効にしたのは英断だと思う。
パフォーマンスやメモリへの影響も今時のサーバで問題があるほどでもないし。
5系から6への移行は大変かもしれないけど、それで仕事が増えるなら構わないw
Perlの遺産だったり、Cが透けて見えたり、Javaのパクリだったり...
で、だからこそ普及しているんじゃないかな。
あと関係ないけどPHP6で常にUnicodeモードを有効にしたのは英断だと思う。
パフォーマンスやメモリへの影響も今時のサーバで問題があるほどでもないし。
5系から6への移行は大変かもしれないけど、それで仕事が増えるなら構わないw
ユニコードモードって何が変わるの？
未だにPHP４とかの鯖あるし
４，５，６とか大変なんだが～
４，５，６とか大変なんだが～
新規案件で4の鯖はないっしょ。てか誘導しようよ
保守案件で4なら、ご苦労様としか言えぬｗ
6は、一応5.3と互換性を持たせるつもりみたいだね
その5.3が大変なんだろうけど、まだ見ないねぇ
保守案件で4なら、ご苦労様としか言えぬｗ
6は、一応5.3と互換性を持たせるつもりみたいだね
その5.3が大変なんだろうけど、まだ見ないねぇ
別にPHP4でも困らないけどな。PHP5の機能で役に立つのは例外くらいなもんだし。
オブジェクトが代入でコピーされなくなったのは、地味に気持ちいい
&付ければいいだけじゃん。
cloneだろ
4だから困るとか言うよりは、2系統あるのが困る
>>115
コピーって言っちゃだめなの？
コピーって言っちゃだめなの？
>>117
>115は>114に対して
>115は>114に対して
PHPをやめるとしたら、何を使いますか？
・Ruby
・Python
・Perl
やっぱPythonかな？
・Ruby
・Python
・Perl
やっぱPythonかな？
Perlは個人的にないな。
つPerl & FastCGI
FastCGIの方は、95%にはちと足りんかな？ｗ
FastCGIの方は、95%にはちと足りんかな？ｗ
Rubyに移行しようと思ったけど
ZendStudioがあるから結局PHP使ってる・・
ZendStudioがあるから結局PHP使ってる・・
書いてて面白いのはPerlだね。
じょうだんよしこさん
PHPのつまらなさは異常
qiq入れればまだ楽しめるよ
ますかきおくん
qiq面白いとは思うけど
コードの依存部分が全体に広がるエクステンションを入れるのはやっぱり抵抗あるわ
もしそれがダメになった時のことを考えると
コードの依存部分が全体に広がるエクステンションを入れるのはやっぱり抵抗あるわ
もしそれがダメになった時のことを考えると
楽しめても、業務利用は無理っしょ
まだRubyで楽しんでる方が健全じゃねーかｗｗｗ
まだRubyで楽しんでる方が健全じゃねーかｗｗｗ
趣味用の言語ならもっとマイナーな奴でもやれよ
132 ：nobodyさん：2008/09/18(木) 19:12:59 ID:ykJuPDO5
そりゃあんた、なんか不可解な挙動があったときに、どこまで自分の力で
調べて修正できるのかって点で、違いすぎるだろｗ
ぶっちゃけ、PHPのコアに関わっている人間にとっての別実装や実験として
でもなければ、QIQなんておもちゃ以外の何者でも無かろうが
調べて修正できるのかって点で、違いすぎるだろｗ
ぶっちゃけ、PHPのコアに関わっている人間にとっての別実装や実験として
でもなければ、QIQなんておもちゃ以外の何者でも無かろうが
将来PHPがバージョンアップして
qiqの開発が停止して非対応だったら
それまで書いたqiq依存コードがもろとも脂肪じゃん。
フレームワーク使っててもフレームワーク非依存なプレーンなクラスは書いていくし
そういうのは流用が効く。
qiqの開発が停止して非対応だったら
それまで書いたqiq依存コードがもろとも脂肪じゃん。
フレームワーク使っててもフレームワーク非依存なプレーンなクラスは書いていくし
そういうのは流用が効く。
PHPにもApacheにも何も保証があるわけじゃないのに。
PHP5依存コードが脂肪しない保証もない。
Zendと契約結んでる？ そりゃ失礼しました。
PHP5依存コードが脂肪しない保証もない。
Zendと契約結んでる？ そりゃ失礼しました。
>>135
確率の問題
確率の問題
PHPのフレームワークと、土台のPHP・Apacheとを、どうやったら
同一視できるのか
また、ユーザの少ないというか皆無に近いQIQなるエクステンションと、
ばりばり商用利用され、長期間メンテの続いている普及率抜群の
プロジェクトとを同一視できるのも素晴らしい
>>132とか>>135とかは、きっと「フレームワーク」の中を調べたりましてや
いじったりなんて、思いもしないユーザなのかな？
ひょっとして全部同列に見えるくらいのスーパーハカーですか？
同一視できるのか
また、ユーザの少ないというか皆無に近いQIQなるエクステンションと、
ばりばり商用利用され、長期間メンテの続いている普及率抜群の
プロジェクトとを同一視できるのも素晴らしい
>>132とか>>135とかは、きっと「フレームワーク」の中を調べたりましてや
いじったりなんて、思いもしないユーザなのかな？
ひょっとして全部同列に見えるくらいのスーパーハカーですか？
PHPユーザーは裾野が広いってことでしょう。
サンデープログラマーから職業プログラマーまで幅が広い。
QIQは素晴らしいエクステンションだから、PHPを支援しているIBMやマイクロソフトとかの大手企業に支援してもらったらいいんじゃないですか？＞作者の方
サンデープログラマーから職業プログラマーまで幅が広い。
QIQは素晴らしいエクステンションだから、PHPを支援しているIBMやマイクロソフトとかの大手企業に支援してもらったらいいんじゃないですか？＞作者の方
ラムダとか5.3で導入されるじゃん
qiqって何が素晴らしいの？
qiqって何が素晴らしいの？
前スレでさんざん出てた [] じゃね？
執着してる人が結構いるようだし
執着してる人が結構いるようだし
[]とハッシュ{}はほしいねぇ
あと -> を . にすれば書くのも読むのも楽だ
あと -> を . にすれば書くのも読むのも楽だ
C/C++の話かよｗ
>>137
>PHPのフレームワークと、土台のPHP・Apacheとを、どうやったら
>同一視できるのか
おいおい、PHPの安定性をApacheと同じにしないでくれよ。
どうせPHPだってver4のサポートなんてもう打ち切られるじゃん。
未来永劫サポートされるわけじゃないし、どっちもどっち。
PHPもフレームワークもQIQも、どれもオープンソースじゃん。
だれかのメンテに頼るのもいいけど、必要なら自分でメンテすればいいじゃんか。
QIQなんてただのライブラリにすぎないんだから、そのくらいできるだろ。
でかいフレームワークのコード読むよりは小さいQIQのほうが楽。
>PHPのフレームワークと、土台のPHP・Apacheとを、どうやったら
>同一視できるのか
おいおい、PHPの安定性をApacheと同じにしないでくれよ。
どうせPHPだってver4のサポートなんてもう打ち切られるじゃん。
未来永劫サポートされるわけじゃないし、どっちもどっち。
PHPもフレームワークもQIQも、どれもオープンソースじゃん。
だれかのメンテに頼るのもいいけど、必要なら自分でメンテすればいいじゃんか。
QIQなんてただのライブラリにすぎないんだから、そのくらいできるだろ。
でかいフレームワークのコード読むよりは小さいQIQのほうが楽。
> QIQなんてただのライブラリにすぎないんだから、
ライ・・ブラリ・・・？
> でかいフレームワークのコード読むよりは小さいQIQのほうが楽。
確かにそうかもしれんが、QIQが何をやってどこを修正すれば
どうなるかってのをつかむ為には、少なくともCとBison(Yacc)と
PHPのCソースコードに関する知識が必要。
てか「楽」じゃねーよｗ
ライ・・ブラリ・・・？
> でかいフレームワークのコード読むよりは小さいQIQのほうが楽。
確かにそうかもしれんが、QIQが何をやってどこを修正すれば
どうなるかってのをつかむ為には、少なくともCとBison(Yacc)と
PHPのCソースコードに関する知識が必要。
てか「楽」じゃねーよｗ
QIQのソースコード読むのが楽なわけないが。少なくともPHPのウェブフレームワークなんかよりは遙かにスキルが要求される。
あれはPHPの拡張モジュール作るのには必要ない、文書化もされていないようなAPIを叩いてるからね...
単体では短くても、理解しようとするとZend Engineのソースコード全体を見る羽目になるw
それとは関係ないけど、拡張モジュールを作るなら何気にPHP6はAPIが使いやすくなってる。
5.3もUnicode関連を除いてほぼ6相当だけど、便利な関数が5.3だけZEND_APIとしてエクスポートされていなくて切ないことも。
単体では短くても、理解しようとするとZend Engineのソースコード全体を見る羽目になるw
それとは関係ないけど、拡張モジュールを作るなら何気にPHP6はAPIが使いやすくなってる。
5.3もUnicode関連を除いてほぼ6相当だけど、便利な関数が5.3だけZEND_APIとしてエクスポートされていなくて切ないことも。
>>145
>QIQのソースコード読むのが楽なわけないが。少なくともPHPのウェブフレームワークなんかよりは遙かにスキルが要求される。
それはおまえがWebのスキルしかないから。コンパイラコンパイラの初歩知識があれば、見れば分かる。
自分が慣れてる分野のコードは読めて、知識のない分野のコードは読めないのは当然。
>QIQのソースコード読むのが楽なわけないが。少なくともPHPのウェブフレームワークなんかよりは遙かにスキルが要求される。
それはおまえがWebのスキルしかないから。コンパイラコンパイラの初歩知識があれば、見れば分かる。
自分が慣れてる分野のコードは読めて、知識のない分野のコードは読めないのは当然。
PHPで描かれたウェブのフレームワークとPHPのエクステンション、どっちが難解かは子供でも分かること
いや、量によって変わるから、どちらが難解かは一概に言えない。
ただいえるのは、PHPという言語仕様を非公式変えてしまうようなものは
公式でPHPそのものが変わったときに対応が困難になるから
使うのはやめておけってこった。
ただいえるのは、PHPという言語仕様を非公式変えてしまうようなものは
公式でPHPそのものが変わったときに対応が困難になるから
使うのはやめておけってこった。
公式でPHPが変わったら、どっちもどっちじゃない?
じゃない。
アホな質問かも知れないけど、cakephpライクなフレームワークを作ろうかと
思ってるんですが、マジックメソッドの __get使ってモデルやコンポーネントの
呼び出しを下のようにやってみたいんだけど、何か問題あります？
class HogeController extends Controller
{
function index()
{
$data = $this->Model->classname->find();
$this->Component->classname->hogehoge();
}
}
思ってるんですが、マジックメソッドの __get使ってモデルやコンポーネントの
呼び出しを下のようにやってみたいんだけど、何か問題あります？
class HogeController extends Controller
{
function index()
{
$data = $this->Model->classname->find();
$this->Component->classname->hogehoge();
}
}
>>152
$this->Modelとか$this->Componentの__get()で、
与えられたクラス名のオブジェクトを生成・取得するって仕組み？
特に悪いとも思わないけど、必要とか便利とかもあんまり思わないｗ
例えば設計思想とか、利用時の利便性とかもあるんだろうけど、
同じ事をするのに、Model::factory()とかModel::singleton()でも
いい場合もあるかもだし
ピントはずれだったらｽﾏｿ
$this->Modelとか$this->Componentの__get()で、
与えられたクラス名のオブジェクトを生成・取得するって仕組み？
特に悪いとも思わないけど、必要とか便利とかもあんまり思わないｗ
例えば設計思想とか、利用時の利便性とかもあるんだろうけど、
同じ事をするのに、Model::factory()とかModel::singleton()でも
いい場合もあるかもだし
ピントはずれだったらｽﾏｿ
>>153 微妙に修正
> 同じ事をするのに、Model::factory()とかModel::singleton()でも
→ 同じ事をするのに、Model::factory(classname) とか new classname() とか classname::singleton() とかでも
> 同じ事をするのに、Model::factory()とかModel::singleton()でも
→ 同じ事をするのに、Model::factory(classname) とか new classname() とか classname::singleton() とかでも
new は method chain できないから却下
cakephpだとコントローラーのプロパティに
使うコンポーネント設定するのいちいち面倒だな～と思ってたんで。
そういうやり方もあるんですね、勉強になります。有り難うございました。
使うコンポーネント設定するのいちいち面倒だな～と思ってたんで。
そういうやり方もあるんですね、勉強になります。有り難うございました。
∧＿∧
（ ´∀｀）＜ ぬるぽプロジェクト
みんなで面白いサイト作って有名にしようぜ！
http://yutori.2ch.net/test/read.cgi/news4vip/1222156869/
★まとめwiki
http://www39.atwiki.jp/vipproject/
PHPのフレームワークとして symfonyを採用予定です。
（ ´∀｀）＜ ぬるぽプロジェクト
みんなで面白いサイト作って有名にしようぜ！
http://yutori.2ch.net/test/read.cgi/news4vip/1222156869/
★まとめwiki
http://www39.atwiki.jp/vipproject/
PHPのフレームワークとして symfonyを採用予定です。
>>157
スレ荒れすぎワロタ
スレ荒れすぎワロタ
>>158
自動保守おいしいです（^q^）
自動保守おいしいです（^q^）
フレームワークとは直接関係ないけど5.3でspl_autoload_register(function($name){...});
すると実際にautoloadされるときにbus erorrで落ちるね。
spl_autoload_register($f=function($name){...}); なら$fが生きている間だけは落ちない。
すると実際にautoloadされるときにbus erorrで落ちるね。
spl_autoload_register($f=function($name){...}); なら$fが生きている間だけは落ちない。
5が出ても枯れるまで結構時間かかったし
6も使えるようになるまでは長いだろうなぁ
6も使えるようになるまでは長いだろうなぁ
一人で最初期モックアップ作るなら、
railsとcakephpと、どっちが向いてる？
railsとcakephpと、どっちが向いてる？
その比較って意味あるのかな？
Ruby（少なくともRails）とPHPが同等にできる人にとってしか答えようがないし、
回答もしかりw
Ruby（少なくともRails）とPHPが同等にできる人にとってしか答えようがないし、
回答もしかりw
cakeみたいな厨フレームワーク使ってる人恥ずかしくないんですかぁ
んじゃ何使えばいいの？
☆Z☆E☆N☆D☆!!
Zend…
無いわー
無いわー
zend使いまくりだけど
何が不満なのかわからない
何が不満なのかわからない
モックならちいたんで良いジャマイカ。
モックなら素のPHPでいいよ
モックはHTMLで十分なこともおおくない？ｗ
ヘッダフッタ辺りのレイアウトとかで楽したいなら、
手慣れたテンプレートエンジンがあればいいかもだけど
フレームワークってのとはちょっと違うような
多分必要なのはView側の省力化・柔軟性かなあ
ヘッダフッタ辺りのレイアウトとかで楽したいなら、
手慣れたテンプレートエンジンがあればいいかもだけど
フレームワークってのとはちょっと違うような
多分必要なのはView側の省力化・柔軟性かなあ
マックでいいよ
楽天がセッションidごとgoogleにキャッシュされ、
個人情報を漏らしまくって最終的にPHP脂肪ｗｗｗ
個人情報を漏らしまくって最終的にPHP脂肪ｗｗｗ
174 ：nobodyさん：2008/09/30(火) 03:55:27 ID:CLW/UbJj
物区ならPencilでいいんじゃね
つーかsymfony一択だろ
フレームワーク作者で一番センスあるコード書くのがフランチョス。
フレームワーク作者で一番センスあるコード書くのがフランチョス。
symfonyは関数名がダサい
_区切りとかKENTかよｗ
_区切りとかKENTかよｗ
そんな規約ないよ
何かと間違えてないか？
何かと間違えてないか？
あれれ～symfonyじゃなかったっけ？
symfonyはJavaと同じキャメルケースだよ
そもそもPHPの標準関数の命名がいい加減なんだから、拘っても意味ない。
PHPはキャメルケースとアンダースコア混在しまくってるからな
クラス名とか関数名とか考えるとき、どっちにしようかいつも迷ってしまう
クラス名とか関数名とか考えるとき、どっちにしようかいつも迷ってしまう
それ単に昔の関数と最近のクラスメソッドなだけだろ
将来的にはほとんどオブジェクト指向のラッパーが用意されて
関数は地下に潜った存在になるだろうな
関数は地下に潜った存在になるだろうな
最近のは殆どキャメルケースに一本化の流れなんかね
アンダースコア派だったからどうもなじめない
アンダースコア派だったからどうもなじめない
オブジェクト指向な関数（メソッド）で
アンダースコアが普及しているような言語あるの？
アンダースコアが普及しているような言語あるの？
るｂｙ
くそ言語wｗ
PHPに言われたらしめぇだべ
PHPよりも糞な言語なんてINTERCALくらいだろ
キャメルケースでも、メソッド名でM$流のUpperCamelCaseは勘弁して欲しい
それはクラス名だけでいいと思う
それはクラス名だけでいいと思う
メソッドをアッパーキャメルケースで書く人なんているの？
そんなコード見たことない
そんなコード見たことない
C#とかかじった人はやる。
携帯ミドルウェアとかやっててC/C++は触るがJavaは触らない、って人もやる。
まあぶっちゃけ Java vs. C# なんだけど、PHPは中途半端なので混在してる。
その点Rubyは、作ってる・使ってる人間がC・Perl on *nix の人メインなので、
アンダースコア派が主流なのかな
また、RubyではUpperCamelCaseは文法的に定数扱いされるので、メソッド名や
通常の変数名には使えない。・・・MS流が嫌いなのか？ｗ
携帯ミドルウェアとかやっててC/C++は触るがJavaは触らない、って人もやる。
まあぶっちゃけ Java vs. C# なんだけど、PHPは中途半端なので混在してる。
その点Rubyは、作ってる・使ってる人間がC・Perl on *nix の人メインなので、
アンダースコア派が主流なのかな
また、RubyではUpperCamelCaseは文法的に定数扱いされるので、メソッド名や
通常の変数名には使えない。・・・MS流が嫌いなのか？ｗ
そういう書き方の自由を奪う言語は嫌われる。
Rubyの_でつなぐのはPerl由来だろうね。俺は_でつなぐのが見やすくて好きだけどな。
PHPはJava風なんだけど、初期に出来た関数の命名が超適当だからな。引数の取り方とかも。
C#とかJavaはどうせIDE使うんで、まあ、どうでもいいような気がする。
PHPはJava風なんだけど、初期に出来た関数の命名が超適当だからな。引数の取り方とかも。
C#とかJavaはどうせIDE使うんで、まあ、どうでもいいような気がする。
大文字小文字を区別しないものにCamelCaseを使うのは、ちょっと気持ち悪い
キャメルケースの種類
アッパーキャメルケース (UCC)、またはパスカルケース(PascalCase)
複合語の先頭を、大文字で書き始める。
つづり例：CamelCase
ローワーキャメルケース (LCC)、または単にキャメルケース
複合語の先頭を、小文字で書き始める。
つづり例：camelCase
アッパーキャメルケース (UCC)、またはパスカルケース(PascalCase)
複合語の先頭を、大文字で書き始める。
つづり例：CamelCase
ローワーキャメルケース (LCC)、または単にキャメルケース
複合語の先頭を、小文字で書き始める。
つづり例：camelCase
なんでわざわざ書いたん？
自分用メモか？
自分用メモか？
初めて知ってうれしかった
CSSですらできる多重継承ができないPHPって一体・・・
Mixinがあれば多重継承なんて必要ありませんよ
>>199
Javaもですが・・
Javaもですが・・
Mixinを提供しているRubyだけがCSSと肩を並べているということですね
つまり、いや、やめておこう
最後の文字だけ大文字にする逆キャメルケースにしてる人いる？
geThogEとか
geThogEとか
>>205
どうでもいいけど、読みづらくね？
どうでもいいけど、読みづらくね？
ゲ ソォグ イー と読んでしまった
難読化とかｗ
<?php
class Class_Name
{
public function methodName( )
{
functionName($valOne, $valTwo);
if ($a == 1){
$b = 2;
}
}
命名規則、俺の結論はこのあたり。
http://framework.zend.com/manual/en/coding-standard.naming-conventions.html
http://solarphp.org/manual:project_standards:naming_conventions
Zend, Solarあたり守っとけばPEARの規約でも問題ない。あとクラス名は_で区切っとかないとauto loaderがめんどい。
class Class_Name
{
public function methodName( )
{
functionName($valOne, $valTwo);
if ($a == 1){
$b = 2;
}
}
命名規則、俺の結論はこのあたり。
http://framework.zend.com/manual/en/coding-standard.naming-conventions.html
http://solarphp.org/manual:project_standards:naming_conventions
Zend, Solarあたり守っとけばPEARの規約でも問題ない。あとクラス名は_で区切っとかないとauto loaderがめんどい。
if (---) {
>>212
>>210じゃ無いけど、ディレクトリ構造を反映ってことじゃない？
Perlのモジュール風？
Zend_Db_Table_Rowクラス => Zend/Db/Table/Row.php
ってな感じじゃないかと想像
>>210じゃ無いけど、ディレクトリ構造を反映ってことじゃない？
Perlのモジュール風？
Zend_Db_Table_Rowクラス => Zend/Db/Table/Row.php
ってな感じじゃないかと想像
explodeですぐパスに変換できるってことか
たしかに_区切りはよさげだな
たしかに_区切りはよさげだな
へー
細かい話になってくるが、DBとかPDFとかいう略語の場合、
DBなのかDbなのか、PDFなのかPdfなのか、っていう違いも
あるねｗ
これがまた人によってまちまちだし、同じ人でも場合によって
違う場合がある
DBなのかDbなのか、PDFなのかPdfなのか、っていう違いも
あるねｗ
これがまた人によってまちまちだし、同じ人でも場合によって
違う場合がある
zendスタイルにした時、そこが一番しっくり来なかったような気がする
あとプロパティはどうせ全部 private なので _ が面倒
あとプロパティはどうせ全部 private なので _ が面倒
デザインパターン使うときはデザインパターンも名前に入れてる
例えば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クラスを実装
例えば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さん：2008/10/06(月) 14:16:23 ID:H0RcPBpG
みんな努力してるんだなー。
参考になります＾＾
参考になります＾＾
221 ：nobodyさん：2008/10/07(火) 00:37:43 ID:h510jQqa
>>205
意味不明で面白い。ウケる。
意味不明で面白い。ウケる。
>>219
> デザインパターン使うときはデザインパターンも名前に入れてる
それ、使うときもあったり使わないときもあったり、
クラスに単一のパターンしか適用されない場合、
そのパターンの為のクラスの場合には、そういう名前付けられるけど
一つのクラスに複数のパターンが適用される場合困るんだよな。
> デザインパターン使うときはデザインパターンも名前に入れてる
それ、使うときもあったり使わないときもあったり、
クラスに単一のパターンしか適用されない場合、
そのパターンの為のクラスの場合には、そういう名前付けられるけど
一つのクラスに複数のパターンが適用される場合困るんだよな。
俺様フレームワークをやめようと思って、CakeかSymfonyを導入しようと思うけど
結局どれがいいんだ…
結局どれがいいんだ…
逆に俺様フレームワークを公開して
スタンダードにしてやれ
スタンダードにしてやれ
結局はちいたんでいいじゃんっていうレスがつく未来が見える
ちいたんは、その名前が失敗の理由のひとつである。
>>225
結局はちいたんで（ｒｙ
結局はちいたんで（ｒｙ
>>227
早いわｗ
早いわｗ
まあ増えすぎたよね
機能追加しすぎで扱いにくいWEBサービスのようだ
機能追加しすぎで扱いにくいWEBサービスのようだ
なんだ？この妙に右よりの誤爆は
PHPプログラマーの方でPHP用フレームワークを使っている方へアンケート！ ※フレームワーク導入を検討中。先輩方は何を使っているのか？好んでいるのか？をアンケート。.. - 人力検索はてな
http://q.hatena.ne.jp/1210442237
Pradoが圧倒的ですねｗ
http://www.pradosoft.com/
http://q.hatena.ne.jp/1210442237
Pradoが圧倒的ですねｗ
http://www.pradosoft.com/
このpradoぶっちぎりはネタだよね?w
234 ：nobodyさん：2008/10/17(金) 03:15:57 ID:7gkZ0lcc
235 ：nobodyさん：2008/10/20(月) 02:51:25 ID:ya5easnJ
symfonyってページネーション機能はあるんですか？
ネットで検索しても「ajaxでページネーション」はあるんだけど・・・
ネットで検索しても「ajaxでページネーション」はあるんだけど・・・
英語の情報をなかったことにするのは君にとって損失かもしれないよ?
http://www.google.co.jp/search?hl=ja&q=site%3Asymfony-project.org+paginate
http://www.google.co.jp/search?hl=ja&q=site%3Asymfony-project.org+paginate
237 ：nobodyさん：2008/10/20(月) 21:10:52 ID:Kq4igHV+
>>236
でもそれも機能たいしてなくないか？
CakePHPみたいに同一ページの複数モデルに対応してないでしょ？
っていうか、ページネーションって掲示板ですら絶対に必要になる機能なのに
なんで標準で付けないんだろ
でもそれも機能たいしてなくないか？
CakePHPみたいに同一ページの複数モデルに対応してないでしょ？
っていうか、ページネーションって掲示板ですら絶対に必要になる機能なのに
なんで標準で付けないんだろ
>>237
最適化が難しいから。
一度でもページネイションの機能を作ったことがあればわかると思うが、
DBから全データ読み込んでから絞り込むのか、検索条件を考慮したデータを
取得しておいてからそれを絞り込むのか、なんだかんだ。
基本的に、データの「件数」がわからないとページング出来ない。
（それを無視してやるページングもあるが。）
どうせライトユーザ向けには、DBやらと連携したページングを求め
られるんだから、「始めからつけてない」は、ある意味賢明な選択だよ。
・・・↑が不満なら、PEARとか使えばいいじゃん、全く。
最適化が難しいから。
一度でもページネイションの機能を作ったことがあればわかると思うが、
DBから全データ読み込んでから絞り込むのか、検索条件を考慮したデータを
取得しておいてからそれを絞り込むのか、なんだかんだ。
基本的に、データの「件数」がわからないとページング出来ない。
（それを無視してやるページングもあるが。）
どうせライトユーザ向けには、DBやらと連携したページングを求め
られるんだから、「始めからつけてない」は、ある意味賢明な選択だよ。
・・・↑が不満なら、PEARとか使えばいいじゃん、全く。
239 ：nobodyさん：2008/10/20(月) 22:10:00 ID:Kq4igHV+
>>238
いや俺もたいしたやつじゃないけど作ったことあるし、
CakePHPのソースを解析したりしてみたけど、
そんなに難しくはないと思うけどな（だったらそれ使えばいいじゃんと言われるかもしれないが・・・）
＞基本的に、データの「件数」がわからないとページング出来ない。
これは渡せばいいだけ
いや俺もたいしたやつじゃないけど作ったことあるし、
CakePHPのソースを解析したりしてみたけど、
そんなに難しくはないと思うけどな（だったらそれ使えばいいじゃんと言われるかもしれないが・・・）
＞基本的に、データの「件数」がわからないとページング出来ない。
これは渡せばいいだけ
>>239
うん。だから、>>238の二行目
>最適化が難しいから
と、最終行
>・・・↑が不満なら、PEARとか使えばいいじゃん、全く。
が、結論なんだけどなｗ
「フレームワークに標準で付いていない」ってのが問題じゃ無かったのか？
うん。だから、>>238の二行目
>最適化が難しいから
と、最終行
>・・・↑が不満なら、PEARとか使えばいいじゃん、全く。
が、結論なんだけどなｗ
「フレームワークに標準で付いていない」ってのが問題じゃ無かったのか？
241 ：nobodyさん：2008/10/20(月) 22:31:39 ID:Kq4igHV+
paginationはZendなら標準で付いてる
しかも色んな状況に対応できる
さあ、ZFを使おう！
しかも色んな状況に対応できる
さあ、ZFを使おう！
243 ：nobodyさん：2008/10/20(月) 23:27:07 ID:Kq4igHV+
まあそれが普通だよな
＞基本的に、データの「件数」がわからないとページング出来ない。
CakePHPはよくできてる。
データの件数ってのは、データ用のSQL文のうち条件は同じでselectするものが、
フィールド名の変わりにcount(*)になっただけ。
そこの部分（フィールド名の変わりにcount(*)）への変換を
自動でやってくれるから、データ用のSQLに相当する部分のみを書けばいい。
また、データ用のSQLにlimitを主導で追加する必要もない。これも自動で追加される。
つまり、「データを取ってくるSQL」を書いて「ペジネーション」処理を使うだけで内部的に、
「データを取ってくるSQL」には、自動的にlimitが追加されて発行され
「データを取ってくるSQL」には、自動的に件数を取得するcountに変更される。（当たり前だがこっちにはlimitはつかない）
（もちろんSQL直書きではなくモデルの操作だが）
最適化って話なら、データ件数を取得する関数をオーバーライドできる。（上のやつはデフォルト動作）
こういう目的でオーバーライドされるために存在するメソッドが用意されている。
CakePHPはよくできてる。
データの件数ってのは、データ用のSQL文のうち条件は同じでselectするものが、
フィールド名の変わりにcount(*)になっただけ。
そこの部分（フィールド名の変わりにcount(*)）への変換を
自動でやってくれるから、データ用のSQLに相当する部分のみを書けばいい。
また、データ用のSQLにlimitを主導で追加する必要もない。これも自動で追加される。
つまり、「データを取ってくるSQL」を書いて「ペジネーション」処理を使うだけで内部的に、
「データを取ってくるSQL」には、自動的にlimitが追加されて発行され
「データを取ってくるSQL」には、自動的に件数を取得するcountに変更される。（当たり前だがこっちにはlimitはつかない）
（もちろんSQL直書きではなくモデルの操作だが）
最適化って話なら、データ件数を取得する関数をオーバーライドできる。（上のやつはデフォルト動作）
こういう目的でオーバーライドされるために存在するメソッドが用意されている。
>>244
うーん。それは、例えばファイルベースのデータとかには適用できないよね。
メールボックスを漁るとか、さｗ
無理矢理使おうと思えば、いっぺんDBに放り込む必要がある。
そんな（SQLで全部済む）フレームワークばかりではない、っていう前提に
立てば、ページネイションの機能は汎用的なものにならざるを得ない。
データの件数と一ページ辺りの取得件数から、データ開始位置（番号）と
データ終了位置を取得する、みたいな。
SQLで言えば、OFFSET とそこからの LIMIT を取得するだけ、っていう。
んで、そんなクラスが乱立しても仕方ないので、PEARなりZendなり使えって
結論で多分無問題。
と思うんだけどなぁ
もちろん、>>244みたいな全自動？ページネイションを否定するわけではないけど。
うーん。それは、例えばファイルベースのデータとかには適用できないよね。
メールボックスを漁るとか、さｗ
無理矢理使おうと思えば、いっぺんDBに放り込む必要がある。
そんな（SQLで全部済む）フレームワークばかりではない、っていう前提に
立てば、ページネイションの機能は汎用的なものにならざるを得ない。
データの件数と一ページ辺りの取得件数から、データ開始位置（番号）と
データ終了位置を取得する、みたいな。
SQLで言えば、OFFSET とそこからの LIMIT を取得するだけ、っていう。
んで、そんなクラスが乱立しても仕方ないので、PEARなりZendなり使えって
結論で多分無問題。
と思うんだけどなぁ
もちろん、>>244みたいな全自動？ページネイションを否定するわけではないけど。
SQLを使わないページネイションなら別にある。
mysqlならSQL_CALC_FOUND_ROWSを使いたいよね
>>249
symfonyにはないってことから、この話題がはじまっている。
symfonyにはないってことから、この話題がはじまっている。
ページネーションくらい自分で書けばいいじゃん
cakeなどという厨フレームワークを使える奴は恥知らず
それだけはガチ
それだけはガチ
simplateの中の人が不治の病で引き継ぎする人募集してるね
面識ないし、simplateを使ったこともないけど泣きそうになっちゃった
面識ないし、simplateを使ったこともないけど泣きそうになっちゃった
てかモデルは自分で書いた方がいい
FW付属のモデルだとクラスタリング対応とかしにくいじゃん
FW付属のモデルだとクラスタリング対応とかしにくいじゃん
こういうスレって必ず>>253みたいな奴が現れるよなｗ
>>257
恥知らず乙ｗｗｗ
恥知らず乙ｗｗｗ
simplateの中の人はいい仕事をしている
いい仕事をしている人を愚弄するな
いい仕事をしている人を愚弄するな
愚弄？
cake使いって案外多いんだなｗ
高カロリー低栄養のケーキ喰いすぎてメタボm9(^Д^)ﾌﾟｷﾞｬー
高カロリー低栄養のケーキ喰いすぎてメタボm9(^Д^)ﾌﾟｷﾞｬー
>>263
後半は、なんだい？ ケーキの話かい？ じゃあすれ違いだねｗ
後半は、なんだい？ ケーキの話かい？ じゃあすれ違いだねｗ
>>263
こいつ自分から頭悪い発言してるなｗ
こいつ自分から頭悪い発言してるなｗ
厨フレームワークだけあって
さすがにcake厨の煽りはレベル低いねｗ
さすがにcake厨の煽りはレベル低いねｗ
おまえらライスケーキでも食ってすこしもちつけ
だいたいページネーションとmodelを一緒くたにするなんて愚かすぎだろ>cake
まず汎用的な単体ページネーションクラスを書いて
それにモデルをアタッチできる継承クラス書くなり
アダプタ書くなりするのが普通です
つまりsymfonyは神、cakeはホームレス
まず汎用的な単体ページネーションクラスを書いて
それにモデルをアタッチできる継承クラス書くなり
アダプタ書くなりするのが普通です
つまりsymfonyは神、cakeはホームレス
> だいたいページネーションとmodelを一緒くたにするなんて愚かすぎだろ>cake
ページネーションがmodelと一緒くたになっていると
勘違いする人もいるんだなぁｗ
コントローラと一緒くたになっているというならまだしも。
（まあコントローラと一緒くたになるのは何の問題もありませんが）
いったいどこの部分を見て一緒くたといっているんだろうか。
modelから任意の範囲のデータを持ってくる機能？
これをmodelに入れないとしたらどこに入れるんだか。
ページネーションがmodelと一緒くたになっていると
勘違いする人もいるんだなぁｗ
コントローラと一緒くたになっているというならまだしも。
（まあコントローラと一緒くたになるのは何の問題もありませんが）
いったいどこの部分を見て一緒くたといっているんだろうか。
modelから任意の範囲のデータを持ってくる機能？
これをmodelに入れないとしたらどこに入れるんだか。
まぁ、cake見たことないから憶測で言ってるだけだけどね。
cakeってPHP4/5用だっけ？
4を切り捨てずにクリーンになんて書けるわけねーし
物乞い乙ｗｗ
cakeってPHP4/5用だっけ？
4を切り捨てずにクリーンになんて書けるわけねーし
物乞い乙ｗｗ
なんにしても厨っぽい発言していると説得力なくなるぜ
code igniterにしてもcakephpにしても
ウリだったPHP4対応が今度は足かせになります
ウリだったPHP4対応が今度は足かせになります
切り捨てなかったからユーザがついたんじゃないの
つかPHP4が使えないフレームワークなんて
仕事じゃ使えません
仕事じゃ使えません
276 ：nobodyさん：2008/10/22(水) 02:16:16 ID://oF70yn
実際クリーンとかピュアとかって商売としては・・
>>274
すごいな。未だにこんな仕事してるやついるのか…
すごいな。未だにこんな仕事してるやついるのか…
ま、今でもPHP4を指定する案件は多い。サーバ上の他のプログラムがPHP4で動いているなら、新しいプログラムもPHP4にするしかないからな。
実際PHP4はもうセキュリティFIXも出さない予定なんだろ？
といいつつこないだ出たけど。
レン鯖でPHP4と5共存してるところとかあるよね。
といいつつこないだ出たけど。
レン鯖でPHP4と5共存してるところとかあるよね。
php4で作るならphp5より高いですよ。
とか言えばいいんじゃないのかな。
実際大変だし。
とか言えばいいんじゃないのかな。
実際大変だし。
283 ：nobodyさん：2008/10/22(水) 16:26:31 ID:Skk+7Du0
>>282
じゃあ他に頼みます
じゃあ他に頼みます
こうしてダンピングも続くのであった
一度出来上がったものを新しくするのにはコストもかかるから仕方がないってのはわかるが
踏ん切りつけれないとこ(クライアント)は総じて馬鹿な奴が多いよな。不思議と。
踏ん切りつけれないとこ(クライアント)は総じて馬鹿な奴が多いよな。不思議と。
IEも未だに6使ってるやつは馬鹿
作り手の気持ちを考えられない
作り手の気持ちを考えられない
>>283
それで仕事逃すなんてもったいない。
php5で作る素晴らしさを説明して、説得するんだ。
php4なら高いというのは、言い換えればphp5なら安い。
実際php5で作るよりphp4の方が工数増えない？
クライアントというより、元請からの仕事なら、しょうがないが。
それで仕事逃すなんてもったいない。
php5で作る素晴らしさを説明して、説得するんだ。
php4なら高いというのは、言い換えればphp5なら安い。
実際php5で作るよりphp4の方が工数増えない？
クライアントというより、元請からの仕事なら、しょうがないが。
というか、PHP5の方がセキュリティホール見つかるの多いし。
>>287
クライアント「で、PHP5で作ったらいくら安くなるの？」
クライアント「で、PHP5で作ったらいくら安くなるの？」
PHP5%引き
>>290
普及率かな？それなら合理的かな
普及率かな？それなら合理的かな
PHP5用に別鯖立てればいいじゃん
今から作るのにPHP4なんていくらなんでもあほすぎだよ
今から作るのにPHP4なんていくらなんでもあほすぎだよ
将来的に何れ変更が必要になるわけで、今がチャンスですよと押し込む材料は十分あるしなｗ
>>286
作り手の気持ちなんて考えるユーザやクライアントなんてほぼ皆無だと思うけど
作り手の気持ちなんて考えるユーザやクライアントなんてほぼ皆無だと思うけど
>>294
それを工数・予算に絡めて喋るのがいい営業・・・ってのは夢かなー（棒読み）
それを工数・予算に絡めて喋るのがいい営業・・・ってのは夢かなー（棒読み）
>>292
確かに、今から作るならPHP5だね。
まっさらな新規案件なのにPHP4でっていうのは、
PHP4に慣れて自分のライブラリとかをPHP5で使えるようにしない技術者の怠慢。
ただ、PHP5だからって工数が圧倒的に圧縮できる訳じゃない。
そういう意味では、既存でPHP4で走ってるのの改良はかなりつらい。
確かに、今から作るならPHP5だね。
まっさらな新規案件なのにPHP4でっていうのは、
PHP4に慣れて自分のライブラリとかをPHP5で使えるようにしない技術者の怠慢。
ただ、PHP5だからって工数が圧倒的に圧縮できる訳じゃない。
そういう意味では、既存でPHP4で走ってるのの改良はかなりつらい。
>>296
>PHP4に慣れて自分のライブラリとかをPHP5で使えるようにしない技術者の怠慢。
ちょっと違う。
使えるようにできない、ていうか、（できないことはまずないから）、できるかどうかすら
わからない、技術者の怠慢「と無能」
が正しいように思ってる。まあこんな事は職場では言いたくないけど。
>PHP4に慣れて自分のライブラリとかをPHP5で使えるようにしない技術者の怠慢。
ちょっと違う。
使えるようにできない、ていうか、（できないことはまずないから）、できるかどうかすら
わからない、技術者の怠慢「と無能」
が正しいように思ってる。まあこんな事は職場では言いたくないけど。
いや、クラの我儘だろ
>>298
それすら、怠慢（自分の仕事を楽により良くする努力を怠っているという意味で）、
っていう次元ですよ。
「新規案件でPHP4」っていうお話はね。
既存スクリプトの保守案件はまた別と理解してます。
あと、教育コストが云々は認めません。少なくとも、俺がチーフ（笑）なら。
それすら、怠慢（自分の仕事を楽により良くする努力を怠っているという意味で）、
っていう次元ですよ。
「新規案件でPHP4」っていうお話はね。
既存スクリプトの保守案件はまた別と理解してます。
あと、教育コストが云々は認めません。少なくとも、俺がチーフ（笑）なら。
PHP4もPHP5も使う立場ではほとんど変わらないから。PHP5がE_STRICTを強制するとかっていうなら、PHP5の方が難易度高くなるけど。
301 ：nobodyさん：2008/10/23(木) 12:08:45 ID:yerXAIOJ
おいおい
サポート切れてるPHP4つかうなよ
サポート切れてるPHP4つかうなよ
> PHP5がE_STRICTを強制するとかっていうなら、PHP5の方が難易度高くなるけど。
E_STRICT強制で難易度高くなるってなんだそりゃ？ｗ
警告をプログラムを完成させるまでの試練と考えているのかな？
俺にとっては、警告はプログラムを完成させるまでの
サポートだと思うんだが。
つまり、E_STRICTを強制されたほうが逆に難易度は低くなると感じる。
間違ったコード、良くないコード、そういったものを排除できるからね。
E_STRICT強制で難易度高くなるってなんだそりゃ？ｗ
警告をプログラムを完成させるまでの試練と考えているのかな？
俺にとっては、警告はプログラムを完成させるまでの
サポートだと思うんだが。
つまり、E_STRICTを強制されたほうが逆に難易度は低くなると感じる。
間違ったコード、良くないコード、そういったものを排除できるからね。
致命的な不具合が見つかっても対応されない可能性が高いPHP4なんて
早く切り捨てるべきと説き伏せろ！
あれ、ここ何スレ？
早く切り捨てるべきと説き伏せろ！
あれ、ここ何スレ？
E_STRICTは正直うざいけどね
出すにしても、別にログを取りたくなるくらい
一方、E_NOTICEはデフォルトでONでもいいと思うんだ
この辺のバランスがなあ
出すにしても、別にログを取りたくなるくらい
一方、E_NOTICEはデフォルトでONでもいいと思うんだ
この辺のバランスがなあ
E_STRICTで出るエラーなんて潰していくのは基本だろ・・・
どんだけいい加減なもの作ってるんだ
どんだけいい加減なもの作ってるんだ
>>305
Java大好き志向でのコーディングかな？
まるまる新規コーディングじゃないとNon-static method ～～ とか、
出まくって修正も大変だと思うんだが。
「基本」は言い過ぎだし、頭でっかち感が否めない
いまだにnoticeすら無視されまくってる現状で
Java大好き志向でのコーディングかな？
まるまる新規コーディングじゃないとNon-static method ～～ とか、
出まくって修正も大変だと思うんだが。
「基本」は言い過ぎだし、頭でっかち感が否めない
いまだにnoticeすら無視されまくってる現状で
保守案件はE_STRICT云々以前に、いろいろと大変なこと多いからな。
少なけりゃつぶすけど、多かったら放置にはなるね。
新規案件なら、E_STRICTなんてたまにしか出てこない。
たまにだから、出たらつぶすよ。
てかE_NOTICEもそんな頻繁に出ないような。
どっちかというと、Pear使っていい案件の時、Pear内に沢山あって
ゲンナリすることの方が多いなぁ。
少なけりゃつぶすけど、多かったら放置にはなるね。
新規案件なら、E_STRICTなんてたまにしか出てこない。
たまにだから、出たらつぶすよ。
てかE_NOTICEもそんな頻繁に出ないような。
どっちかというと、Pear使っていい案件の時、Pear内に沢山あって
ゲンナリすることの方が多いなぁ。
まあ、どっちみちPHPの場合、おおざっぱな警告メッセージとか変数のスコープなんで、あまり役に立たないと言えば立たないが。
それでも、下手なプログラムを排除できるというメリットはある。E_STRICTをオンにしたら、エラーばっか出て実装が進めないPHPプログラマーは多数いるだろう。
それでも、下手なプログラムを排除できるというメリットはある。E_STRICTをオンにしたら、エラーばっか出て実装が進めないPHPプログラマーは多数いるだろう。
> エラーばっか出て実装が進めないPHPプログラマーは多数いるだろう。
それはお前だけｗ
それはお前だけｗ
E_STRICTうざいってどんだけー
>>309
PHPプログラマーのレベルなんて、そんなもんだから。
PHPプログラマーのレベルなんて、そんなもんだから。
>>311
だからそれはお前だけｗ
だからそれはお前だけｗ
Cake←何て読むの？フレームワークはどこでダウンロードできますか？
なかなかダウンロードページにたどり着けません…
なかなかダウンロードページにたどり着けません…
終わってる
http://www.phppro.jp/news/568
いまだに一番使われてるフレームワークはMojavi
いまだに一番使われてるフレームワークはMojavi
ウェブフレームワークの使用経験があるのが70%、そのトップがMojavi。
しかも、PHPカンファレンス2008に参加したという、技術に関心の高いPHPプログラマーが対象のアンケートでこの有様。
しかも、PHPカンファレンス2008に参加したという、技術に関心の高いPHPプログラマーが対象のアンケートでこの有様。
この間面接受けてきた会社
フレームワークは重くなる遅くなるから使いません！言ってたな
提供サービスを全部新しく作り直すらしいけど、次はJavaでもPHPでもなく、Rubyだ！
とか言ってた。でもRails遅過ぎるから速度が必要なとこだけFWなしのPHPだとかなんとか…
大丈夫か…ｗ
フレームワークは重くなる遅くなるから使いません！言ってたな
提供サービスを全部新しく作り直すらしいけど、次はJavaでもPHPでもなく、Rubyだ！
とか言ってた。でもRails遅過ぎるから速度が必要なとこだけFWなしのPHPだとかなんとか…
大丈夫か…ｗ
フレームワークは重くなるとか言ってるようなアホ会社は
無駄なコード書いて死んだらええねん
無駄なコード書いて死んだらええねん
DRYなコードを書けば自ずとフレームワークに近くなるしなｗ
てか速度が必要なとこだけphpという選択はどうなの？何でphpなの？
てか速度が必要なとこだけphpという選択はどうなの？何でphpなの？
1つのファイルで完結できるから、とかいう意味じゃね？
FastCGIとかMongrelとか調べたくも覚えたくもない、
とかいう意味かもね？
調べた上で使えねえ、って言ってるのかもしれんが
とかいう意味かもね？
調べた上で使えねえ、って言ってるのかもしれんが
自分仕事で開発とかやったことないような超ド素人だから、
そうなのかーってちょっと思わされかけてたけど、やっぱおかしいよねこれｗ
ちなみに、規模や今後の事なんかも考えると、Javaとかを選択したほうが
いいんじゃないかとかをきいてみたら、Javaは遅いし、もう古いとか言われてさ
さすがにその見解はちょっとどうなのって思っちゃったｗ
フレームワークを使わず自分でコード書くことは(勉強としては)すごく重要だと思うし
自社開発の会社だから、社員の成長のためにいろいろやらせたい、って感じな部分も
あるのかもしれないけど、メインの仕事で車輪の再発明みたいな事繰り返して
無駄な工数増やすのは間違ってると思ったｗ
そうなのかーってちょっと思わされかけてたけど、やっぱおかしいよねこれｗ
ちなみに、規模や今後の事なんかも考えると、Javaとかを選択したほうが
いいんじゃないかとかをきいてみたら、Javaは遅いし、もう古いとか言われてさ
さすがにその見解はちょっとどうなのって思っちゃったｗ
フレームワークを使わず自分でコード書くことは(勉強としては)すごく重要だと思うし
自社開発の会社だから、社員の成長のためにいろいろやらせたい、って感じな部分も
あるのかもしれないけど、メインの仕事で車輪の再発明みたいな事繰り返して
無駄な工数増やすのは間違ってると思ったｗ
確かに昔はVMとかすげー重くてもっさりって感じで、アプレットとかうぜぇって思ったりしてたけど
まさかJava=アプレットとしか知らなかったりしてナｗ
まさかJava=アプレットとしか知らなかったりしてナｗ
「Javaは(開発速度が)遅いし」とかじゃ
Javaはもう古いには同意するな。
元々Javaをやってる会社なら別だけど、今選択するならJavaは古いと思う。
あと既存のフレームワークを使わないで、自社で作るという選択肢はありだと思う。
既存のものは何かと合わなかったりするし、フレームワークが無いと開発できません。
は困るし。
自社のフレームワークもありません。
だと困るがｗ
元々Javaをやってる会社なら別だけど、今選択するならJavaは古いと思う。
あと既存のフレームワークを使わないで、自社で作るという選択肢はありだと思う。
既存のものは何かと合わなかったりするし、フレームワークが無いと開発できません。
は困るし。
自社のフレームワークもありません。
だと困るがｗ
>>328
代替物が無い状況では、古いってのは意味がない
なんでまだC言語で開発が行われてるのかと
PHPやRubyがJavaを完全に代替できる筈もないし、
目指してもないだろ。
文脈無しでJavaが古い、はナンセンスだと思うよ
代替物が無い状況では、古いってのは意味がない
なんでまだC言語で開発が行われてるのかと
PHPやRubyがJavaを完全に代替できる筈もないし、
目指してもないだろ。
文脈無しでJavaが古い、はナンセンスだと思うよ
それ以前に、PHPのスレで「Javaは古い」っていうのは笑止千万なようなｗ
>>329
いやさ、これから会社が新たな「開発言語に取り組む！」って時に、
何の言語か聞いてみたら、
「これからはJavaです！」とかいってたら、
「いまさら？」って思わないかってことなんだが。
もちろんJavaは現役で使われてる言語だとは思うよ。
俺も案件によってはphpじゃなくてJava使うし。
いやさ、これから会社が新たな「開発言語に取り組む！」って時に、
何の言語か聞いてみたら、
「これからはJavaです！」とかいってたら、
「いまさら？」って思わないかってことなんだが。
もちろんJavaは現役で使われてる言語だとは思うよ。
俺も案件によってはphpじゃなくてJava使うし。
Java古いつってPHPやらRubyやらってのも説得力がないんだよなｗ
ある程度古く枯れてきてないと商用にはあまり向かないってのもあるだろうし
色々理由付けがあっての「古い」なのかも知れないから、深くは突っ込まなかったけど
なんかJavaを毛嫌いしてるって感じの印象を受けた感じだった
自社開発で提供してるサービスだったし、自社FWってのはありだと思うけど
日が建つにつれ混沌としてきて、組み込みなんかであるような
なんともドロドロした感じのものが出来そうなイメージもあるんだよなー
Web系で使う言語なんて結局は殆どが文字列操作をするためのもんだし、
自社製FWはどんなに突き詰めていっても
既存のものから使わないメゾッドとか減らしてHDDの使用量を減らしました！速度も気持ち速いです！
ってくらいの差しか出ないんじゃないかなーと
…と、スレチっぽい話題振ってスマソｗ
>>331
それは言語が古いんじゃなくて、その会社の取り組みの姿勢が遅れてるって感じなんじゃｗ
ある程度古く枯れてきてないと商用にはあまり向かないってのもあるだろうし
色々理由付けがあっての「古い」なのかも知れないから、深くは突っ込まなかったけど
なんかJavaを毛嫌いしてるって感じの印象を受けた感じだった
自社開発で提供してるサービスだったし、自社FWってのはありだと思うけど
日が建つにつれ混沌としてきて、組み込みなんかであるような
なんともドロドロした感じのものが出来そうなイメージもあるんだよなー
Web系で使う言語なんて結局は殆どが文字列操作をするためのもんだし、
自社製FWはどんなに突き詰めていっても
既存のものから使わないメゾッドとか減らしてHDDの使用量を減らしました！速度も気持ち速いです！
ってくらいの差しか出ないんじゃないかなーと
…と、スレチっぽい話題振ってスマソｗ
>>331
それは言語が古いんじゃなくて、その会社の取り組みの姿勢が遅れてるって感じなんじゃｗ
その人の心の中ではJavaは古い物だったんだろう。
rubyに比べると新しくはないという意味なら文脈としてもおかしくはないかと。
新しいからって理由で方向を決めるのもちょっと心配になるがw
新しいからって理由で方向を決めるのもちょっと心配になるがw
ことFWに関してはJavaはPHPに比べて圧倒的に成熟してる気がする
最近Java触り初めてSAStrutsやらS2JDBCやら使ってるけどめちゃくちゃ開発効率上がったよ・・・
俺なんかJava全然知らないのに知らなくても普通に使える。これすごいよ
最近Java触り初めてSAStrutsやらS2JDBCやら使ってるけどめちゃくちゃ開発効率上がったよ・・・
俺なんかJava全然知らないのに知らなくても普通に使える。これすごいよ
PHPフレームワークは色々あるけど「これなら！」ってのがなー
標準になりそう（なってほしい）のがSymfony
PHP4からの移行とかで現実的なのがCakePHP
公式だけど、フレームワークとしてはいまいち、
どちらかといえばライブラリ？って感じなのがZendFramework
PHP4からの移行とかで現実的なのがCakePHP
公式だけど、フレームワークとしてはいまいち、
どちらかといえばライブラリ？って感じなのがZendFramework
>>336
このスレのネタなのかマジなのかわからない「もうちいたんでいいよ」
っていう指摘はあながち間違ってないと思うんだよね
以前もどこかで同じ事言ってる人がいたが、デファクトスタンダードが
決まらない状況が続けば続くほど、リソースの集約もそれに輪をかけて遅れていくわけだし。
それに伴って余計スタンダードが決まらない・・・リソース（ｒｙ
の悪循環が続いて俺はPHPに限界を感じて、Javaに手を出すことにしたんだよ。
PHPの適当さ加減を一番活かすには必要最小限のFWでいいと思う。
逆にちいたんが成熟していったらかなりいい物ができあがるんじゃないかと思っている
このスレのネタなのかマジなのかわからない「もうちいたんでいいよ」
っていう指摘はあながち間違ってないと思うんだよね
以前もどこかで同じ事言ってる人がいたが、デファクトスタンダードが
決まらない状況が続けば続くほど、リソースの集約もそれに輪をかけて遅れていくわけだし。
それに伴って余計スタンダードが決まらない・・・リソース（ｒｙ
の悪循環が続いて俺はPHPに限界を感じて、Javaに手を出すことにしたんだよ。
PHPの適当さ加減を一番活かすには必要最小限のFWでいいと思う。
逆にちいたんが成熟していったらかなりいい物ができあがるんじゃないかと思っている
Javaでなんのフレームワーク使っている？
Struts？ Spring？ Seasar？
結局Javaでもフレームワーク乱立だと思うけどね。
Javaは長いようだが成熟しているというわけでもなく、
J2EE/EJBが否定されて根本的に覆ろうとしているし（覆った？）
DIコンテナはもう普及し終わったかな？
Struts？ Spring？ Seasar？
結局Javaでもフレームワーク乱立だと思うけどね。
Javaは長いようだが成熟しているというわけでもなく、
J2EE/EJBが否定されて根本的に覆ろうとしているし（覆った？）
DIコンテナはもう普及し終わったかな？
そっちのスレでやってくれ
オープンソースなんだから乱立が正常な状態だろ
多様性があるから発展性があるんだし
多様性があるから発展性があるんだし
結局JavaにしてもPHPと状況は変わらんってことだなｗ
そのまとめ方はさすがに無理あるだろｗ
結論
ちいたんでいい
ちいたんでいい
ちいたんはいつ1.0になるのだね
作者が飽きるので永遠になりません。
ってか実際ちいたんつかってる人っている？
仕事ではさすがに使えないだろうけど、個人でなら十分実用なんだよな
仕事ではさすがに使えないだろうけど、個人でなら十分実用なんだよな
あえて使うことはねえよｗ
ごもっともｗ
ちいたんってオチに使われてる以外にあまり見たこと無いがw
オチに使われる奥さんｶﾜｲｿｽｗ
ちぃたんって嫁の名前なのか
お前のために歌作ったんだみたいなアーティストっぽいな
お前のために歌作ったんだみたいなアーティストっぽいな
プログラマもアーティストって肩書きにすれば人気出るんじゃね？w
アーティスチックなコーディングをされても周りは困る
海外のハカーは奥さんの名前つけたりするね
でもそういうのは日本じゃ流行らなさそうｗ
あっちじゃ台風すら人名つけるしなあ
名前空間の実装がダサすぎてPHP脂肪ｗｗｗ
\区切りキモス
\区切りキモス
\区切り？ あぁ。頭の弱い人か。
PHPER必死の強がりワロスｗｗ
その釣り方はさすがに無理があるよ
PHP5.3の名前空間は\区切りなの？
363 ：nobodyさん：2008/10/28(火) 00:57:04 ID:Xl2JqkE7
('A`)
ごめん。
>>358の真意が知りたい
>>358の真意が知りたい
一応聞くけど、バックスラッシュだよね？\じゃないよね？
>>369
ああ。本当だ。その記事はU00A5で書かれてるね。てかブログの仕様？
俺もその記事しか見なかったから、確かなことは言えないけどｗ
・・・まあぶっちゃけASCII or Latin-1 以外を奴ら（誰？）に強制できる
わけもないので、￥マークってのはありえない、はず！
ソースコードUTF-8強制とかなら、むしろ嬉しいかもだけどな！
ああ。本当だ。その記事はU00A5で書かれてるね。てかブログの仕様？
俺もその記事しか見なかったから、確かなことは言えないけどｗ
・・・まあぶっちゃけASCII or Latin-1 以外を奴ら（誰？）に強制できる
わけもないので、￥マークってのはありえない、はず！
ソースコードUTF-8強制とかなら、むしろ嬉しいかもだけどな！
てか、この記事が壮大な釣り？
へーutf-8って\とバックスラッシュが違うコードなの？
ちょっと事実誤認があるかな。俺も詳しくないけど。
u00A5(？)は、ISO-8859-1(Latin-1)にこそ、ある文字だ。
本来の意味での、円通貨を表すシンボル？
と言うわけで、>>370の安心は、その理由ならちょっと早いｗ
もちろん、実際PHPの仕様としてそんな訳は無いだろうけどｗ
u00A5(？)は、ISO-8859-1(Latin-1)にこそ、ある文字だ。
本来の意味での、円通貨を表すシンボル？
と言うわけで、>>370の安心は、その理由ならちょっと早いｗ
もちろん、実際PHPの仕様としてそんな訳は無いだろうけどｗ
PHPってパーサーが弱いよなあ。ちょっと複雑なプログラムでバグがあると、php -l でエラー行検出出来なかったりするからな。
そらぁ構文エラーだけだから、複雑なシステムのバグってんなら
lintじゃぁ出ないエラーの方が多いだろう。
構文エラーが出るのは大抵の言語で括弧とかクオートの閉じ忘れくらい。
/.で、PHPがこの惑星で一番アホなプログラム言語とか書かれて
ちょっとかわいそう。しかもInsightful: 5だし。
海の向こうのGeekもPHPはお嫌いなようで。
lintじゃぁ出ないエラーの方が多いだろう。
構文エラーが出るのは大抵の言語で括弧とかクオートの閉じ忘れくらい。
/.で、PHPがこの惑星で一番アホなプログラム言語とか書かれて
ちょっとかわいそう。しかもInsightful: 5だし。
海の向こうのGeekもPHPはお嫌いなようで。
まあPHPがよく使われているって証拠でもあるよな。
オープンソースのウェブアプリは
ほとんどPHPだし。
オープンソースのウェブアプリは
ほとんどPHPだし。
アホなプログラム言語とか言う行為こそ遠吠えだろう。
名前空間の区切りにバックスラッシュをつかうなんてのは実際 retarded だろうよ。
日本語で書け
日本語不自由な人なんで勘弁してあげてください
名前空間の区切りに逆斜線をつかうなんてのは実際 retarded だろうよ。
ディレクトリだって、斜め線なのに？
いっそスラッシュでよかったんじゃまいか
いやだめか
::じゃだめだったん？
だめだったん。
なんであかんの？
せめてちょっと前のリンク先だけでも読んでくれ
こっちには、他の候補？もあるのかな
ttp://wiki.php.net/rfc/namespaceseparator
でも (5) number of chars は基準としてどうなんだｗ
# とか候補に挙がらなかったのかな？バックスラッシュより遙かにマシだと思うんだけど。
どうせ # でのコメントは非推奨だったんだし、使ってる奴なんて極少数だろうし
ttp://wiki.php.net/rfc/namespaceseparator
でも (5) number of chars は基準としてどうなんだｗ
# とか候補に挙がらなかったのかな？バックスラッシュより遙かにマシだと思うんだけど。
どうせ # でのコメントは非推奨だったんだし、使ってる奴なんて極少数だろうし
互換性が・・・
中途半端に互換性なくなるくらいなら
完全に無視してちゃんと作ったほうがいいよね
完全に無視してちゃんと作ったほうがいいよね
:=でいいやん
：：
>>397
それは却下されたんだよ
それは却下されたんだよ
バックスラッシュはなんだかなぁ。
今まで通り、細かい互換性なんぞ無視してしまえばいいんだｗ
というか、現行の :: と -> の区別って必要なの？
メンバアクセスは全部 -> にしてしまえば、:: が使えるじゃない！
修正も多分、検索・置換でそれほど手間じゃなさそうだし
たかが名前空間って考えると、本末転倒な気もするけど
というか、現行の :: と -> の区別って必要なの？
メンバアクセスは全部 -> にしてしまえば、:: が使えるじゃない！
修正も多分、検索・置換でそれほど手間じゃなさそうだし
たかが名前空間って考えると、本末転倒な気もするけど
スキーマのデータを毎回dbから取得するのと、
取得したデータをファイルにキャッシュしておいて随時読むのと、
どっちがコスト低いですか？
取得したデータをファイルにキャッシュしておいて随時読むのと、
どっちがコスト低いですか？
スキーマのデータが分からんとDBにアクセスできんだろ
スキーマのデータって何を指してるんだ？
カラムの型データです
どんなDAOを使ってるか知らないけど、
テーブルにどんなデータ型のカラムがあるかなんて取得する？
PropelとかDoctrineは定義ファイルを書くけど。
よくわからないけど、毎回DBから取得するより、
ファイルから取得した方が、普通に考えてコスト低いと思う。
んーなんか見当違いかな。
テーブルにどんなデータ型のカラムがあるかなんて取得する？
PropelとかDoctrineは定義ファイルを書くけど。
よくわからないけど、毎回DBから取得するより、
ファイルから取得した方が、普通に考えてコスト低いと思う。
んーなんか見当違いかな。
code igniterを参考にしたオリジナルのdaoです
やっぱり、普通はファイルアクセスの方が速いですかね・・
やっぱり、普通はファイルアクセスの方が速いですかね・・
どうせカラム型なんかはメモリにキャッシュしてるだろうし
そんなに変わらないっつーかファイルに書くより早いかもね。
パフォーマンスが問題ならベンチして決めるしかないでしょ。
メンテ込みなら、自動的にカラム型を読み込むのは便利。
そんなに変わらないっつーかファイルに書くより早いかもね。
パフォーマンスが問題ならベンチして決めるしかないでしょ。
メンテ込みなら、自動的にカラム型を読み込むのは便利。
DBからロードするって事は大抵はなんかしら変更の可能性があるデータってことだろうし
キャッシュを作成するとなると常時最新でなくなる可能性が出るんじゃないの？
更新タイミングとか考えたり余計な手間が増えるだけ
逆に、変更がめったに行われないとかってわかってるものなら、ただの定数
ハナからDBに保存しておく必要なくね？
つか、なによりまずスレ違いだ
キャッシュを作成するとなると常時最新でなくなる可能性が出るんじゃないの？
更新タイミングとか考えたり余計な手間が増えるだけ
逆に、変更がめったに行われないとかってわかってるものなら、ただの定数
ハナからDBに保存しておく必要なくね？
つか、なによりまずスレ違いだ
>>408
>>407で言っているのは、DBサーバはカラム型をメモリに置いているはずだということ。
つまりDBに問い合わせればディスクには読みにいかないだろうと言う読み。
付け加えると、SQLiteにしても、スキーマ情報はDBをオープンした後黙っても読まれるはずで、
それをメモリから取り出すだけだからいちいちファイルに書いとくのはどうよ、ってこと。
>>407で言っているのは、DBサーバはカラム型をメモリに置いているはずだということ。
つまりDBに問い合わせればディスクには読みにいかないだろうと言う読み。
付け加えると、SQLiteにしても、スキーマ情報はDBをオープンした後黙っても読まれるはずで、
それをメモリから取り出すだけだからいちいちファイルに書いとくのはどうよ、ってこと。
>>377
エラーは検出するけど、何行目のエラーか検出できないんだよ。そんなのPHPだけだと思う。
エラーは検出するけど、何行目のエラーか検出できないんだよ。そんなのPHPだけだと思う。
$ php -l <<EOF
<?php
echo "hello";
fuga();
foo();
();
?>
EOF
Parse error: syntax error, unexpected ')' in - on line 7
Errors parsing -
なんか出てる気がするよ?
<?php
echo "hello";
fuga();
foo();
();
?>
EOF
Parse error: syntax error, unexpected ')' in - on line 7
Errors parsing -
なんか出てる気がするよ?
複雑になると出ない場合があるんだよ。
前にmatzがPHPのAPCが何でそんなに効果的なのか理由が分からないって言ってたけど、あれは単純にPHPの構文解析の性能が悪いからって理由だと思う。
前にmatzがPHPのAPCが何でそんなに効果的なのか理由が分からないって言ってたけど、あれは単純にPHPの構文解析の性能が悪いからって理由だと思う。
->がPHPみたいなもんだろ
＞PHPに->ってあったっけ？
え？
え？
->は好かん.がよい
->は好かんがよい、に見えた
そろそろPythonを勉強する時期かな？
レンタル鯖で普通に入ってないやつなんて
学ぶ必要はないんだ
学ぶ必要はないんだ
どれか１つの言語でもちゃんとやっときゃ
他の言語なんてやる気になりゃ出来る
他の言語なんてやる気になりゃ出来る
>>420
できればその１つがPHPではない方が、幅は広そうだがｗ
できればその１つがPHPではない方が、幅は広そうだがｗ
たしかにプログラムの基礎練習としてはやっぱ向かないよなｗ
まだ改修段階にあるってかんじで、他の言語で当たり前に出来ることが出来ないってのがむずむずするｗ
まだ改修段階にあるってかんじで、他の言語で当たり前に出来ることが出来ないってのがむずむずするｗ
きゃーすてき！
安いレンサバの代表格のXREA、Xserver等には、Python、Rubyも入ってますな＾＾
RoRで一世を風靡したRubyをあえて選ばずに、Pythonを始めるのが通の嗜み？
RoRで一世を風靡したRubyをあえて選ばずに、Pythonを始めるのが通の嗜み？
XREAを選ぶ奴の気が知れないよ
ロリポップやヘテムルならいいのか？
Rubyは知らんがPythonなら入ってるサーバは、最近だとそれなりにあるきがする。
Railsもmod_railsというかPassengerの登場でPHP並に管理が楽になった感じだし、
これからは選べるようになるかも。
これからは選べるようになるかも。
変数型を気にする必要の無い言語から始めると取り掛かりやすいけど
いざ型がある言語に移るとき、ちゃんと理解しきれてないと苦労しやすいってのもあるから
PHPを最初に覚えるってのはちょっとオススメしないかもだなｗ
まぁ、触れやすいこと、覚えやすいことを重視したほうがスタートしやすいし、
やりたい事にもよるから一概には言えないと思うけどね
いざ型がある言語に移るとき、ちゃんと理解しきれてないと苦労しやすいってのもあるから
PHPを最初に覚えるってのはちょっとオススメしないかもだなｗ
まぁ、触れやすいこと、覚えやすいことを重視したほうがスタートしやすいし、
やりたい事にもよるから一概には言えないと思うけどね
変数型が無いPHPは
余計な心配が増えてよくない
余計な心配が増えてよくない
PHPをちゃんと理解すればPHPにも型があるって分かるはずだから問題ないだろ
railsも深く知るほど「簡単」とはとてもいえないものだと分かってくる
railsを速く動かすソリューションを安定して稼働させるにはスキルがいるし、
スレッドセーフかそうでないかということも気を遣わなければいけない。
railsを速く動かすソリューションを安定して稼働させるにはスキルがいるし、
スレッドセーフかそうでないかということも気を遣わなければいけない。
Railsの中でスレッドなんて使ってるの？
少なくともFastCGIやらの同時起動なら、プロセス別じゃないの？
よくわかってないけど
少なくともFastCGIやらの同時起動なら、プロセス別じゃないの？
よくわかってないけど
型とかの概念はプログラム覚えるなら最初のうちにやっといたほうがいい気はする
まぁほんとに初めてがphpはあかんわな
でも普通は学校で最初にcやpascalやったりするんじゃないの？
でも普通は学校で最初にcやpascalやったりするんじゃないの？
いいかげんフレームワークの話をしましょうよ。
PHPは変数のスコープが関数単位というのがなんとも。
配列すら参照渡しになるJavaScriptはPHPより糞
しかもcloneメソッド標準装備してないし
しかもcloneメソッド標準装備してないし
===
>>427
せめてどこなら良いか提示してからそういうこと言おうな
せめてどこなら良いか提示してからそういうこと言おうな
XREAなんでだめなの？
xreaだからだろ
理由なんかないだろ。なんでも否定したくなる年頃なんだよ。
中学生とかおっさんとか。
中学生とかおっさんとか。
お前らxreaなんか使うレベルなんか・・
xreaがダメな理由なんてちょっと調べたり確認すればわかるだろ…
そんなことも説明されないとわからないのか…
そんなことも説明されないとわからないのか…
話に全然信憑性無いわ
まぁそういうやつはXREA使っとけばいいんじゃねｗ
サポートがだめすぎるけど、運よくトラブルに会わなければ、
まぁ安い金額で使えるし。
たまに、coreserverの方にxreaの設定を上書きして、
coreなのにXREA相当にしちゃったり、
mailmanがバグだらけでまったく機能しなかったり、
ほかにも色々トラブルおこしてるみたいだけど。
俺はxreaスレやcoreserverスレ読んだら、怖くて仕事には使えなくなった。
サポートがだめすぎるけど、運よくトラブルに会わなければ、
まぁ安い金額で使えるし。
たまに、coreserverの方にxreaの設定を上書きして、
coreなのにXREA相当にしちゃったり、
mailmanがバグだらけでまったく機能しなかったり、
ほかにも色々トラブルおこしてるみたいだけど。
俺はxreaスレやcoreserverスレ読んだら、怖くて仕事には使えなくなった。
てかxreaって何につかうの？個人サイト？
なんでフレームワークスレでxreaが出てくるのか謎
なんでフレームワークスレでxreaが出てくるのか謎
なんでxreaがだめか教えてやろう。
それは安かろう悪かろうだから。
まあ常識で考えて安いところにろくなところはない。
俺が使っているところ。おすすめだから教えてやろうか？
今ならキャンペーン中だからお得だぞ。
それは安かろう悪かろうだから。
まあ常識で考えて安いところにろくなところはない。
俺が使っているところ。おすすめだから教えてやろうか？
今ならキャンペーン中だからお得だぞ。
個人ブログといっても財産ですからね。
財産をそんな簡単に盗まれてしまうところにおいておきますか？
おいておかないでしょう？
それでなくぐらいなら、ちょっとの費用で
安心を得られるほうを選びませんか？
そんなに気になるのなら私が使っているサーバーを教えてあげますが。
財産をそんな簡単に盗まれてしまうところにおいておきますか？
おいておかないでしょう？
それでなくぐらいなら、ちょっとの費用で
安心を得られるほうを選びませんか？
そんなに気になるのなら私が使っているサーバーを教えてあげますが。
>>453
あのサービスに不満がないならそんな噛みつかなくてもいいと思うよ
あのサービスに不満がないならそんな噛みつかなくてもいいと思うよ
Symfonyて結構バグあるの？
CakePHPカンファレンス東京のレポート読んでたら、
そんなような記述があったんだが。
あまり詳しく書いてなかった。
CakePHPカンファレンス東京のレポート読んでたら、
そんなような記述があったんだが。
あまり詳しく書いてなかった。
>>457
俺はプライベートでも勘弁だがｗ
俺はプライベートでも勘弁だがｗ
なんかxreaに仕事を奪われた
サーバー屋が裏工作しているみたいですねｗ
サーバー屋が裏工作しているみたいですねｗ
正直お小遣い稼ぎの趣味サイトならxreaで十分だしな～
他所でやれ
symfonyはsubversion拾ってればわかるけど、1時間数十以上のファイルが修正されてるからな。
バグがあっても修正も早い
バグがあっても修正も早い
1時間数十以上 = 一日数百以上 = 一週間数千以上 = 一ヶ月数万以上
一ヶ月数万以上って本当ですか？
一ヶ月数万以上って本当ですか？
なんとも恐ろしいフレームワークだ
>>466
本当だよ。subversionでチェックアウトしてみなよ
本当だよ。subversionでチェックアウトしてみなよ
Tracをみる限り、一日あたり10から30コミットというところ。
コミット一回につき、いくつかのファイルを触るだろうから、一回の変更の
影響範囲が大きい場合、ピーク時には一時間数十ファイル更新は充分ありうるが、
これがコンスタントに続くことはないでしょ。
まぁコミットはいっぱいあってもバグチケットをcloseするコミットは少ないように見えるが。
でも開発ブランチはこんなもの。
コミット一回につき、いくつかのファイルを触るだろうから、一回の変更の
影響範囲が大きい場合、ピーク時には一時間数十ファイル更新は充分ありうるが、
これがコンスタントに続くことはないでしょ。
まぁコミットはいっぱいあってもバグチケットをcloseするコミットは少ないように見えるが。
でも開発ブランチはこんなもの。
CIって、早い分cakePHPやsymfonyと比べどんな機能が足りないの?
471 ：sage：2008/11/06(木) 19:26:19 ID:W2KYlXPe
>>470
やさしさ
やさしさ
>>470
痒いとこ
痒いとこ
>>472
痒いところってどの辺?
痒いところってどの辺?
ドクトリンってcodeigniterのパクリだろ？
>>23って俺が昔別のスレに書いた質問だったと思うんだけど
何でこんなとこに記載されて議論が発生してるんだｗ
何でこんなとこに記載されて議論が発生してるんだｗ
ところでcakePHPのパフォーマンスの悪さは改善されてないのかな？
>>477
RC3は使ってみた？
RC3は使ってみた？
>>23の質問を昔別スレに書いた本人だけど
結論としては、
・スタティックな方法では使う側も唯一性を意識しなければいけない
・シングルトンであれば使う側は唯一性を気にする必要が無い
と言うのが最も大きい違いだと思ってる。
要するに、シングルトンで書いておけば後からシングルトンじゃなくする時に
参照してる側は書き換えなくても良いって事。
抽象的に言えば、オブジェクトの特性である唯一性というものをカプセル化出来るということ。
結論としては、
・スタティックな方法では使う側も唯一性を意識しなければいけない
・シングルトンであれば使う側は唯一性を気にする必要が無い
と言うのが最も大きい違いだと思ってる。
要するに、シングルトンで書いておけば後からシングルトンじゃなくする時に
参照してる側は書き換えなくても良いって事。
抽象的に言えば、オブジェクトの特性である唯一性というものをカプセル化出来るということ。
自分で確かめることって大事
時間がないんで
こんなところに書き込んでる暇があるなら
そりゃ自分でベンチマークとるよりは、ここに書き込む方が楽だし時間もかからないだろう。
んな他力本願のやつに情報提供してくれる人がいる確率考えると
結局自分で調べたほうが結果がわかるのは早いと思うけどなｗ
結局自分で調べたほうが結果がわかるのは早いと思うけどなｗ
>>469
1.0=>1.1=>1.2と常にこの状態が続いています
1.0=>1.1=>1.2と常にこの状態が続いています
個人がつくってるのを見るのが好きだ
おっとMapleに鞭打つのはやめるんだ
guessworkとか言うのももうやめるんだ
guessworkとか言うのももうやめるんだ
cakePHPなんてドジでのろまな亀しか使ってないだろ
>>479
出来ることは同じだけど、
唯一なものを唯一なものと知って使うのと、
唯一なのかインスタンスを複数作れるのかわからないけど、
普通に使えば唯一になってる、
の違いってこと？
ちょっとくどい聞き方かもだけど、ちゃんと確認したくって聞いてみた。
出来ることは同じだけど、
唯一なものを唯一なものと知って使うのと、
唯一なのかインスタンスを複数作れるのかわからないけど、
普通に使えば唯一になってる、
の違いってこと？
ちょっとくどい聞き方かもだけど、ちゃんと確認したくって聞いてみた。
>>490
本気でそう思うなら相手にしなきゃいいだけなのにw
本気でそう思うなら相手にしなきゃいいだけなのにw
cakePHP 1.2のRC3は
”パフォーマンス改善中”と明確に言われている。
cakePHPの開発スタンスは、まず動くものを作る→リファクタリング（パフォーマンス改善含む）
”パフォーマンス改善中”と明確に言われている。
cakePHPの開発スタンスは、まず動くものを作る→リファクタリング（パフォーマンス改善含む）
オープンソースで儲けるのって
サポート事業しかないのか？
サポート事業しかないのか？
オープンソースは広く使ってもらっていると言う土壌を得る事がまず目的
広く使われればサポート事業や周辺ソフトが売れる
広く使われればサポート事業や周辺ソフトが売れる
実際に動くコードが重要なわりに
そのコードを作っても儲けられない。
それがオープンソースｗ
せっかく土壌を作っても
サポートや周辺ソフトや関連書籍を
他の人が提供して売り上げを持っていかれる。
それがオープンソースｗ
そのコードを作っても儲けられない。
それがオープンソースｗ
せっかく土壌を作っても
サポートや周辺ソフトや関連書籍を
他の人が提供して売り上げを持っていかれる。
それがオープンソースｗ
いまだにオープンソースでガッツリ儲けようなんてプランのところがあるの？
本当に基幹的なDBとかhttpdとかならともかく
本当に基幹的なDBとかhttpdとかならともかく
ガッツリってのはいくらぐらいなのかな。
それにもよるだろうが、儲けるかどうかは才覚の問題。
OSSかどうかは関係ないだろうな。
それにもよるだろうが、儲けるかどうかは才覚の問題。
OSSかどうかは関係ないだろうな。
お金の名言
「タダほど高いものはない」
「タダほど高いものはない」
タダほどお得なものはない
>>499
ApacheやらLinuxやら使ってて「高くついた」って感じたことはないなあ。
むしろ安い労働力まで付いてきて、お得感しかないのが大多数では？ｗ
もちろん、大規模に「ガッツリ」儲ける分野では違うんだろうけど。
ApacheやらLinuxやら使ってて「高くついた」って感じたことはないなあ。
むしろ安い労働力まで付いてきて、お得感しかないのが大多数では？ｗ
もちろん、大規模に「ガッツリ」儲ける分野では違うんだろうけど。
中・小規模向けのフレームワークって何が良い？
cakeはどうもパフォーマンスが悪すぎて嫌なんだよねえ
cakeはどうもパフォーマンスが悪すぎて嫌なんだよねえ
中・小ならEthnaでいいんじゃないの。
CIという手もあるが。
CIという手もあるが。
ご冗談でしょう
Ethnaとか、未だに選択肢に残ってるのかな？
仕事で昔触ったときに、いろいろドン引きした記憶があるんだが。
アクションを準備していないURL指定すると「全ファイル」のrequireを
し始めてプチDOSアタックになってしまう自前オートロード（笑）とかｗ
仕事で昔触ったときに、いろいろドン引きした記憶があるんだが。
アクションを準備していないURL指定すると「全ファイル」のrequireを
し始めてプチDOSアタックになってしまう自前オートロード（笑）とかｗ
大規模ならCI or ZFのチョイスってことでFA?
CIってPHP4にも対応しててコードに無理が出てるみたいな話も聞くんだけど
大規模で使えるようなものなの？
小規模にしてもcakeとどっちが楽なんだろう
大規模で使えるようなものなの？
小規模にしてもcakeとどっちが楽なんだろう
ドッチかと言われればcakeだろ
でもcakeもイマイチなのはよくわかる
でもcakeもイマイチなのはよくわかる
ciで大規模はきつい
そういうふうには作られていない
そういうふうには作られていない
だよね
低機能だし
だからこそある程度自分達で実装しやすい面もあるから
逆に大規模での需要はありうるけど
かといって小規模でもCIはどうなんだろう
軽量なのは良いんだけど
低機能だし
だからこそある程度自分達で実装しやすい面もあるから
逆に大規模での需要はありうるけど
かといって小規模でもCIはどうなんだろう
軽量なのは良いんだけど
オープンソースは技術的には最良の手段だよ
利益に繋げられるビジネスモデルを考えられるか、実行出来るかが問題
利益に繋げられるビジネスモデルを考えられるか、実行出来るかが問題
そこが最大の問題だと思う。
ぶっちゃけメシ食えなきゃしょうがない
ぶっちゃけメシ食えなきゃしょうがない
オープンソースにかかわってるエンジニアがこれほどたくさんいるという事実は
形は違えど、オープンソースで稼げるってことの裏返しじゃないかと思うのは甘い？
形は違えど、オープンソースで稼げるってことの裏返しじゃないかと思うのは甘い？
でも市場取らないとどうにもならない面もある
もしオープンソースな製品が何一つ無い分野があったら、オープンソースな製品を立ち上げる事で
その分野で一気に市場を奪える可能性がある
もしオープンソースな製品が何一つ無い分野があったら、オープンソースな製品を立ち上げる事で
その分野で一気に市場を奪える可能性がある
日本ではあまり話を聞かない気がするけど・・
しかもFWの話で画像系とか3D系はちょっと実感わかないかも
携帯サイト向けの機能も持ったフレームワークってあるの？
DeNAのMobaSiFみたいなものってPHPでは聞いたことないなぁ
携帯サイトって出力を携帯むけにするだけじゃないの？
なんか特別に機能必要け？
なんか特別に機能必要け？
セッションとかＰＣと同じじゃ動かないんだよ
そのほか端末識別番号の取得やらいろいろある
そのほか端末識別番号の取得やらいろいろある
そうそう。まともにサービスを開発したことがあったら、
携帯対応ほど煩雑なものはないと思えるよ。
キャリアと機種によって全然違う挙動するからね。
セッションもレイアウトも画像も。ま、小さいところでは絵文字とか。
携帯対応ほど煩雑なものはないと思えるよ。
キャリアと機種によって全然違う挙動するからね。
セッションもレイアウトも画像も。ま、小さいところでは絵文字とか。
機種によって動かなかったりするからテストもコーディングも面倒
それはＰＣ携帯両用サイトじゃなく携帯サイト作成のためのフレームワークっぽい
両方できるものが欲しいのか
すまそ
というより両方やろうとしている時点で間違っていると思う
小規模、小機能ならありえるけど
すまそ
というより両方やろうとしている時点で間違っていると思う
小規模、小機能ならありえるけど
両対応サイトであったとしても別物と考えよ
KEMPとやらはPHP5で動かない
携帯とＰＣで別フレームワークを使うとしたら
共通の機能を変更した場合どうすんの？
携帯とＰＣで別フレームワークを使うとしたら
共通の機能を変更した場合どうすんの？
セッション動かないのはクッキーがないからだろ？
単にget引数方式にしたらいいだけじゃないの？
単にget引数方式にしたらいいだけじゃないの？
>>529
当然それぞれ変更する
当然それぞれ変更する
>>530
リファラーを送っちまう機種でそんなことしたら、セッションハイジャックされるべ
リファラーを送っちまう機種でそんなことしたら、セッションハイジャックされるべ
実際携帯サイト向けのソリューションはいくつかあるんだけど
国内では情報少ないね
国内では情報少ないね
結局機種判別をして処理振り分けるような事をする必要があるんだよね
ttp://gihyo.jp/dev/feature/01/mobasif/0001
ここに書いてあるのでもまだまだ序の口だな。間違ってるとこもあるし。
いまんとこ、オープンソースだとMobaSiF最強じゃないかな。
ここに書いてあるのでもまだまだ序の口だな。間違ってるとこもあるし。
いまんとこ、オープンソースだとMobaSiF最強じゃないかな。
携帯の文字コードは、そろそろUTF-8統一でいいんでしょうか？
結局そういうのは自分とこで作るしかないんじゃね
うん。perlなんだけどさ。
スレチ承知であえて、携帯だけはPerlでって思えるぐらいの完成度だと思う。
スレチ承知であえて、携帯だけはPerlでって思えるぐらいの完成度だと思う。
だいたい携帯は規格が無さ杉なんだよ
ＯＳも別々のが乗ってるし
エンドユーザーにとってメリットがある事じゃないんだが、不経済だなあ
ＯＳも別々のが乗ってるし
エンドユーザーにとってメリットがある事じゃないんだが、不経済だなあ
>>541
それと、各社・各世代仕様のまとめ情報が少なすぎる。
ググれば出てきそうなクッキー仕様や対応文字コード等の情報が、ほとんど無い。
会社で仕事なんかでは資料を作るんだから、暇な自営業者あたりが自分メモで
作ってても良さそうなもんなんだが。
フレームワーク辺りと違って、いじって面白くないのと、商売上公開したくないって
のと、その他もろもろ理由はあるんだろうけど。
それと、各社・各世代仕様のまとめ情報が少なすぎる。
ググれば出てきそうなクッキー仕様や対応文字コード等の情報が、ほとんど無い。
会社で仕事なんかでは資料を作るんだから、暇な自営業者あたりが自分メモで
作ってても良さそうなもんなんだが。
フレームワーク辺りと違って、いじって面白くないのと、商売上公開したくないって
のと、その他もろもろ理由はあるんだろうけど。
Androidに期待
携帯はフルブラウザで見る以外は廃止にすべき
MobaSiF読んでPHP用携帯FWを作るプロジェクトとか
そもそも初期のｉモードなんかの仕様がダメ杉
>>545
PerlのコードをPHPのコードに変換するジェネレーターがあれば、簡単に移植できるかな？
PerlのコードをPHPのコードに変換するジェネレーターがあれば、簡単に移植できるかな？
http://oshiete1.goo.ne.jp/qa863429.html
Perlコードを、自動的にPHPコードに変換してくれる、そんな「ドラえもん」のようなプログラムがありましたら教えて下さい！
無いですねえ。
http://www.cs.wcupa.edu/~rkline/perl2php/
Perl/Php Translation
Perlコードを、自動的にPHPコードに変換してくれる、そんな「ドラえもん」のようなプログラムがありましたら教えて下さい！
無いですねえ。
http://www.cs.wcupa.edu/~rkline/perl2php/
Perl/Php Translation
そういやperlで思い出したけど
PHP on parrotて進んでるんでしょうか？
PHP on parrotて進んでるんでしょうか？
>>540
Perlの事情あまりしらはい。ﾗｲﾌﾞﾗﾘのどういうとこが携帯向き?
Perlの事情あまりしらはい。ﾗｲﾌﾞﾗﾘのどういうとこが携帯向き?
551 ：nobodyさん：2008/11/13(木) 10:31:16 ID:kdvrTOAA
で、肝心のフレームワークなんだけど
結局今熱いのってなんなの？
いっぱいありすぎていまいちこれっていう特徴あるやつ
ないんだよな～
最近ちょっとさわってみようかな～って思ってるのあるんだけど
誰かいじったことある人いたら所感教えて～
PAJAJ
ttp://pajaj.sourceforge.net/
xFrameworkPX
ttp://px.xframework.net/
結局今熱いのってなんなの？
いっぱいありすぎていまいちこれっていう特徴あるやつ
ないんだよな～
最近ちょっとさわってみようかな～って思ってるのあるんだけど
誰かいじったことある人いたら所感教えて～
PAJAJ
ttp://pajaj.sourceforge.net/
xFrameworkPX
ttp://px.xframework.net/
PRADOみたいなイベントドリブンなのはどうなんだ
ちいたんでいい
やっぱり落ち担当w
もうちょっとふくらませてからｗ
いやらしい
大規模向けのFWはどれ?
ちいたん
出ると思ったｗ
ちいたん以外で
Symfony
Cake
Cake
あれ?遅いとか叩いてなかったっけか?
なぜ大規模向けと?
なぜ大規模向けと?
軽量なフレームワーク≒自由度が高い≒多人数開発では混乱を招きやすい
(重量級フレームワーク=動作が遅い)≒自由度が低い=開発のルール化度が高い≒多人数でも均一なコードレベルを保ちやすい
とはいえ、フレームワークが案件に合う合わないもあるので、
どのフレームワークを使っても、大規模開発ならプロジェクトのルールが必要だと思われ。
逆を言えば、ルールさえ作れば軽量なフレームワークでもいいと思う。
重量級フレームワークが用意してくれる機能を、自分達で実装しないとならないけどね。
あと、大規模=多人数と勝手に解釈したけど。
(重量級フレームワーク=動作が遅い)≒自由度が低い=開発のルール化度が高い≒多人数でも均一なコードレベルを保ちやすい
とはいえ、フレームワークが案件に合う合わないもあるので、
どのフレームワークを使っても、大規模開発ならプロジェクトのルールが必要だと思われ。
逆を言えば、ルールさえ作れば軽量なフレームワークでもいいと思う。
重量級フレームワークが用意してくれる機能を、自分達で実装しないとならないけどね。
あと、大規模=多人数と勝手に解釈したけど。
数年がかりの本当に大規模なものなら
逆に自由度が高いフレームワークを使って自分たちで実装したいって需要もかなりある
逆に自由度が高いフレームワークを使って自分たちで実装したいって需要もかなりある
>>564
開発期間が数年？PHPでそんな案件はほとんど無いけど。
あと、それを適当にやると、どんどん「フレームワーク」自体に修正が入ってしまって、地層のように
古いコーディングとより新しいコーディングがどんどん積み重なって手に終えなくなる。
やるなら、全くいじらないか、最初にきちんと徹底的にいじって固めてしまうのがいいのかな？
開発期間が数年？PHPでそんな案件はほとんど無いけど。
あと、それを適当にやると、どんどん「フレームワーク」自体に修正が入ってしまって、地層のように
古いコーディングとより新しいコーディングがどんどん積み重なって手に終えなくなる。
やるなら、全くいじらないか、最初にきちんと徹底的にいじって固めてしまうのがいいのかな？
１年未満じゃ大規模とは言えないし
webアプリで開発に何年もかかってちゃビジネスになんね。
PHPはインタフェース部分を担当するに過ぎないから
プロジェクト全体で数年っていうのはあるよ
複数サイトを作るような事業でも共通フレームワークを作成することはあるし
プロジェクト全体で数年っていうのはあるよ
複数サイトを作るような事業でも共通フレームワークを作成することはあるし
単純にスピードを比較したものがよく出るけど、あまり意味無いよな。
しかも素の状態に近いベンチとか。
もちろん非常にシンプルに作りたいときにFWの軽さは重要かもしれないけど。
色々な機能を実装するなら、結局ある程度の重さにはなるだろうし。
だったら多少重いといわれる高機能FWを使用したほうが開発効率は良いと思う。
単純なスピード比較がよく話題が出るから、疑問に感じていた。
しかも素の状態に近いベンチとか。
もちろん非常にシンプルに作りたいときにFWの軽さは重要かもしれないけど。
色々な機能を実装するなら、結局ある程度の重さにはなるだろうし。
だったら多少重いといわれる高機能FWを使用したほうが開発効率は良いと思う。
単純なスピード比較がよく話題が出るから、疑問に感じていた。
何が言いたいのかさっぱりだ
帰れ
帰れ
必要な機能に一番近いものを使えばいいねん
多すぎず少なすぎず
多すぎず少なすぎず
それがベストだけどちょうどいいFWってそうはない気も。
まぁ、一番近いものを選べばいいが
まぁ、一番近いものを選べばいいが
フレームワークなんて多機能な奴はほとんど一緒だけどね
パフォーマンスくらいしか差が無い気が
パフォーマンスくらいしか差が無い気が
大規模の意味は100万ユーザ以上が使うというアクセス数の意味で
開発の工数ではなかったけどためになった
アクセス数という意味では軽量かどうかが非常に重要と思われ
サーバの台数などのメンテナンス代が高くつくから
とはいえ重量級のものを使ってあとからプロファイリングして
リファクタリングなりすればいいような気もしてきた
開発の工数ではなかったけどためになった
アクセス数という意味では軽量かどうかが非常に重要と思われ
サーバの台数などのメンテナンス代が高くつくから
とはいえ重量級のものを使ってあとからプロファイリングして
リファクタリングなりすればいいような気もしてきた
必要な機能なら実装しなきゃならないんだから
効率的な実装になってるならいいんだけどね
cakeは実装が酷いよ
効率的な実装になってるならいいんだけどね
cakeは実装が酷いよ
cakeはインターフェイスが全てだからじゃん
その辺までRailsを踏襲していると言えばそうかも
その辺までRailsを踏襲していると言えばそうかも
ウェブアプリで、大規模って言うと、アクセス数が多いって意味で使われることが多いんじゃないかな。
でも、それってフレームワークはあんまり関係ないよな。ハードウェアスペックとか、もっと低いレイヤーの問題であって。
PHPに限らずウェブサイトの開発で数年かけるなんて、まず有り得ないと思う。官公庁のサイトで、手続きが面倒とかでない限り。
GmailとかGoogle Mapsでもそこまで行かないでしょう。まして、よくあるショッピングサイトやSNSみたいなのに1年も時間使ってたらアフォだよ。
でも、それってフレームワークはあんまり関係ないよな。ハードウェアスペックとか、もっと低いレイヤーの問題であって。
PHPに限らずウェブサイトの開発で数年かけるなんて、まず有り得ないと思う。官公庁のサイトで、手続きが面倒とかでない限り。
GmailとかGoogle Mapsでもそこまで行かないでしょう。まして、よくあるショッピングサイトやSNSみたいなのに1年も時間使ってたらアフォだよ。
アクセス数の多さはフレームワークのスレで大規模にあたらないだろ
１ページだけのHTMLを出力するサイトでも大量アクセスがあれば大規模なのか？
俺は普通コード量とか機能数だと思うけど
１ページだけのHTMLを出力するサイトでも大量アクセスがあれば大規模なのか？
俺は普通コード量とか機能数だと思うけど
Googleは独自のフレームワーク作ってそうだけどね
てか絶対作ってる
他にも大企業は手の込んだ事やってそうだけどなあ
てか絶対作ってる
他にも大企業は手の込んだ事やってそうだけどなあ
ウェブアプリで機能の数って言っても、単に画面を増やしていくだけだからなあ。
mixiとかamazonとか、確かに画面数は多いけど、結局のところ、掲示板作るのと変わりはない。
ユーザからの入力を受け取って、何枚かのテーブルを更新して、テーブルをSELECTしなおして、文字列を加工してHTMLに埋め込むって言う。
これをひたすら繰り返して巨大化するだけ。
mixiとかamazonとか、確かに画面数は多いけど、結局のところ、掲示板作るのと変わりはない。
ユーザからの入力を受け取って、何枚かのテーブルを更新して、テーブルをSELECTしなおして、文字列を加工してHTMLに埋め込むって言う。
これをひたすら繰り返して巨大化するだけ。
機能によっては違うこともあるんじゃないか。
ユーザからのデータを何かしら加工するとか、
なにか特別なアルゴリズムでデータを収集して、
それを提供するとか。
ユーザからのデータを何かしら加工するとか、
なにか特別なアルゴリズムでデータを収集して、
それを提供するとか。
ＷＥＢＡＰＩの提供に際する共通機能とか
自動的にＤＢを保守してくれたりＨＤＤ壊れたらバックアップの方へ自動的に繋いで新たなバックアップ先を作るとか
（ＰＨＰコード内の接続先ＤＢサーバＩＰが動的に変わるって事ね）
思いつきで書いた
自動的にＤＢを保守してくれたりＨＤＤ壊れたらバックアップの方へ自動的に繋いで新たなバックアップ先を作るとか
（ＰＨＰコード内の接続先ＤＢサーバＩＰが動的に変わるって事ね）
思いつきで書いた
ウェブアプリで大規模とそれ以外の境目はウェブアプリ側がスケーラビリティを気にする必要があるかどうかだと思う。
>>580
> ウェブアプリで機能の数って言っても、単に画面を増やしていくだけだからなあ。
> mixiとかamazonとか、確かに画面数は多いけど、結局のところ、掲示板作るのと変わりはない。
> ユーザからの入力を受け取って、何枚かのテーブルを更新して、テーブルをSELECTしなおして、文字列を加工してHTMLに埋め込むって言う。
> これをひたすら繰り返して巨大化するだけ。
それはウェブアプリだからではなく、SNSやオンラインショップという
システムが、そうなっているってだけだろ。
たとえば、YouTubeのようなウェブアプリではエンコード技術が使われる。
> ウェブアプリで機能の数って言っても、単に画面を増やしていくだけだからなあ。
> mixiとかamazonとか、確かに画面数は多いけど、結局のところ、掲示板作るのと変わりはない。
> ユーザからの入力を受け取って、何枚かのテーブルを更新して、テーブルをSELECTしなおして、文字列を加工してHTMLに埋め込むって言う。
> これをひたすら繰り返して巨大化するだけ。
それはウェブアプリだからではなく、SNSやオンラインショップという
システムが、そうなっているってだけだろ。
たとえば、YouTubeのようなウェブアプリではエンコード技術が使われる。
それにウェブじゃないシステムが何をしているかというと、
結局、ファイルにデータ読み書きして、画面に点を表示しているだけともいえる。
結局、ファイルにデータ読み書きして、画面に点を表示しているだけともいえる。
大したことやってないのにフレームワークは重いから使わない(ｷﾘｯ
なんて言っちゃってる企業とか腐るほどあるからなぁ
なんて言っちゃってる企業とか腐るほどあるからなぁ
>>585
インプット・アウトプットの対象の幅広さは、ウェブアプリなんかとは比べものにならんように思う。
ウェブアプリの場合は、一部APIサービス的なものを除けば、ほぼ「画面」相手でいいわけだが。
>>586
その理由でテンプレートエンジンを使いたがらない人も未だに多いがな。同じじゃね？
インプット・アウトプットの対象の幅広さは、ウェブアプリなんかとは比べものにならんように思う。
ウェブアプリの場合は、一部APIサービス的なものを除けば、ほぼ「画面」相手でいいわけだが。
>>586
その理由でテンプレートエンジンを使いたがらない人も未だに多いがな。同じじゃね？
フレームワークに比べて、テンプレエンジンは開発効率大してよくならないからな。
つーかＦＷに組み込まれてるし
つーかＦＷに組み込まれてるし
何かをしない理由にパフォーマンスを上げている場合、大概ちゃんと調べるのとか新しい
やり方を検討するのが面倒くさいことだけの事が多いと思う。
論理削除ってあるじゃん。レコードに削除フラグを立ててデータは残すって言う。
あのフラグのチェックををいちいち手で (del_flag IS NULL OR del_flag = 0) とか書いている
会社があった。
なぜ NOT NULL制約を付けないのかと聞いたら、「重くなる」って答えが返ってきた。
全力でこけた。いろいろ間違ってる。
やり方を検討するのが面倒くさいことだけの事が多いと思う。
論理削除ってあるじゃん。レコードに削除フラグを立ててデータは残すって言う。
あのフラグのチェックををいちいち手で (del_flag IS NULL OR del_flag = 0) とか書いている
会社があった。
なぜ NOT NULL制約を付けないのかと聞いたら、「重くなる」って答えが返ってきた。
全力でこけた。いろいろ間違ってる。
12のphp最適化テクニックとか、一時期ブログに出回ったけど、
そのテクニックが使われるタイミングを考えると、誤差でしかないとか、
よくあったよね。
むしろコードが読みにくくなったり、書きにくくなったりと、
その時間のほうがもったいないとか。
そのテクニックが使われるタイミングを考えると、誤差でしかないとか、
よくあったよね。
むしろコードが読みにくくなったり、書きにくくなったりと、
その時間のほうがもったいないとか。
大手でphp使ってサービスやってるといえばYahooなんだけど
たとえば、↓
http://www.sooey.com/journal/2007/05/26/648/
symponyだって。
でもサービスによって違いはあって
http://wakatsukichinatsu.yahoo.co.jp/index.php?itemid=128
↑これなんてPHP?
たとえば、↓
http://www.sooey.com/journal/2007/05/26/648/
symponyだって。
でもサービスによって違いはあって
http://wakatsukichinatsu.yahoo.co.jp/index.php?itemid=128
↑これなんてPHP?
論理削除自体間抜け
論理削除自体が間抜け？
方法がフラグってとこが間抜けってなら少しはわかる気もするが。
方法がフラグってとこが間抜けってなら少しはわかる気もするが。
論理削除は必要だろ。
スレチだけど論理削除ってどういう指定にすればやりやすいですかね。
active enum('Y','N')か、status = 0 なら削除とか？
active enum('Y','N')か、status = 0 なら削除とか？
大規模向けではなく一番スケールアウトしやすいFWは?
スケールアウト考えたらモデルは自分で書かないときつくね？
ちｒｙ
>>595
deleted（datetime）がnullかどうか
deleted（datetime）がnullかどうか
int型にして、0だと削除扱いにするのが妥当だろうな。PHPやPerlなら、ブーリアン評価でfalseが帰ってくるし。
勝手に値はいるのはtimestampだけだっけ？
>>602
NOT NULL にしておいて default を設定すれば入るだろ
NOT NULL にしておいて default を設定すれば入るだろ
mysqlはデフォルト値に関数が使えない
>>600
deletedってどういうこと？
deletedってどういうこと？
フィールド名じゃないの？
ああそういうことか、関数かと思ったｗ
nullだとインデックスが使われないから論理値のほうが良くない？
nullかどうかで求めるのは本来正しく無いだろうね
削除された、と言う状態がシステム上にありうるならそれはnullで表現すべきじゃない
削除された、と言う状態がシステム上にありうるならそれはnullで表現すべきじゃない
というか、３値論理っての？ NULL を理解していないとか必要性を感じないとかの場合は、
全フィールド NOT NULL で作ってしまえと言いたい。
その方が何かとトラブルが少ないし、コーディングも楽だ。
テキストフィールド？ 空文字でも入れとけ。 数値？ 0が初期値だ。それで都合がわるけりゃ、
-999999999 が初期値だ、文句あるか、ってな感じで。
全フィールド NOT NULL で作ってしまえと言いたい。
その方が何かとトラブルが少ないし、コーディングも楽だ。
テキストフィールド？ 空文字でも入れとけ。 数値？ 0が初期値だ。それで都合がわるけりゃ、
-999999999 が初期値だ、文句あるか、ってな感じで。
>>607
そう、カラム名。
id, created(datetime), updated(datetime), deleted(datime)を標準的に使用。
あるいは、statusとしてa)Activei)/Inactive、h)Hidden, b)Obsoleted D)deleted
とか詳しい状態が必要な時に使うとか。
そう、カラム名。
id, created(datetime), updated(datetime), deleted(datime)を標準的に使用。
あるいは、statusとしてa)Activei)/Inactive、h)Hidden, b)Obsoleted D)deleted
とか詳しい状態が必要な時に使うとか。
いろいろやり方あるんすね。すごい勉強になった。
皆さん有り難うございます。
皆さん有り難うございます。
論理だろうがなんだろうが、削除っていうからカッチリ噛み合わないと思うんだよね
実際問題何も消してないわけなんだし
だから、そういうのは無効化とか不活性化とか利用不可とか、そういう「状態」で呼ぶべきで
削除って言うならならきっちりかっちりまるっと全部消してしまえ！
と思うんだよなー
スレ趣旨と全然関係ないんだけどなー
実際問題何も消してないわけなんだし
だから、そういうのは無効化とか不活性化とか利用不可とか、そういう「状態」で呼ぶべきで
削除って言うならならきっちりかっちりまるっと全部消してしまえ！
と思うんだよなー
スレ趣旨と全然関係ないんだけどなー
論理削除はDELETEより早い速度が求められる場合(index更新のコストが馬鹿にならない)とか
警察照会とか、CS対応で必要とかやっぱり要るシーンが多くて>>614みたいに消してしまえーが使えない場合も少なくないよ
>>615
そうだね。
警察照会とか、CS対応で必要とかやっぱり要るシーンが多くて>>614みたいに消してしまえーが使えない場合も少なくないよ
>>615
そうだね。
論理削除っていう呼び方はおかしいね
ソフトウェアなんだから全て論理だし
無効化、凍結、と言う呼び方が正しい
ソフトウェアなんだから全て論理だし
無効化、凍結、と言う呼び方が正しい
そうかな？英文でもphysical delete、logical deleteって言葉よく使われるよ。
http://publib.boulder.ibm.com/infocenter/wbihelp/v6rxmx/index.jsp?topic=/com.ibm.wbia_developer.doc/doc/connector_dev_java/java61.htm
http://publib.boulder.ibm.com/infocenter/wbihelp/v6rxmx/index.jsp?topic=/com.ibm.wbia_developer.doc/doc/connector_dev_java/java61.htm
処理速度の場合もあるだろうけど、後から参照しないといけない場面がよくあるからな。安易に削除するわけにはいかないことが多い。
だからそれを削除って呼ぶなよﾊﾞｰﾔ!!って言いたいんだろう
論理削除を削除と呼ぶか、単なるステータスかというのは
呼び方の慣習の問題。
言葉遊びをやってもしょうがないんで、ここでは便宜的に、論理削除とは、
物理的には削除せずにサービス上削除されたようにふるまわせること
でいいかな？
呼び方の慣習の問題。
言葉遊びをやってもしょうがないんで、ここでは便宜的に、論理削除とは、
物理的には削除せずにサービス上削除されたようにふるまわせること
でいいかな？
>>600 >>612
滔々と語ってるが、>>612の前者のdeleted （削除日時） はまあともかく、
後者の方では、レコードにユニーク制約のカラムがあった時に不便だろ。
削除フラグ（というかカウンタなど）とセットでユニーク制約にしてしまうって
のは、あんまり流行って無いのか？
滔々と語ってるが、>>612の前者のdeleted （削除日時） はまあともかく、
後者の方では、レコードにユニーク制約のカラムがあった時に不便だろ。
削除フラグ（というかカウンタなど）とセットでユニーク制約にしてしまうって
のは、あんまり流行って無いのか？
partial index 使っちゃう。
>>622
詳しく
詳しく
>>624
例えばユーザアカウントをユニークにしたいとかで、一意制約をユーザ名カラムに付けるとする。
んで、そのユーザが退会した後、そのデータを残してたら、そのユーザ名がずっと使えない。
それを避けるために、削除データだけ一意制約から考慮外にしたい場合、削除フラグと２カラム連結で
ユニークにしてしまう。
んでレコードを削除する時に、同一なユーザ名を持つデータの削除フラグを、一斉に +1 UPDATEしてしまう。
削除フラグが 1以上なら( というか、0でなければ ) 削除データという扱い。
こんなやり方。マイナーなのかな？と思った。
書いてて思ったが、これ一意制約のカラムが二つ以上あった場合、そのままでは使えないなｗ
もちょっと応用を利かさないと無理か。
整数部分と少数部分で分けるとか桁で分けるとかビットで分けるとかｗｗｗ
＃ DBの一意制約を使わずアプリで常にチェックするなら別にこんなことしなくていいんだけど。
例えばユーザアカウントをユニークにしたいとかで、一意制約をユーザ名カラムに付けるとする。
んで、そのユーザが退会した後、そのデータを残してたら、そのユーザ名がずっと使えない。
それを避けるために、削除データだけ一意制約から考慮外にしたい場合、削除フラグと２カラム連結で
ユニークにしてしまう。
んでレコードを削除する時に、同一なユーザ名を持つデータの削除フラグを、一斉に +1 UPDATEしてしまう。
削除フラグが 1以上なら( というか、0でなければ ) 削除データという扱い。
こんなやり方。マイナーなのかな？と思った。
書いてて思ったが、これ一意制約のカラムが二つ以上あった場合、そのままでは使えないなｗ
もちょっと応用を利かさないと無理か。
整数部分と少数部分で分けるとか桁で分けるとかビットで分けるとかｗｗｗ
＃ DBの一意制約を使わずアプリで常にチェックするなら別にこんなことしなくていいんだけど。
こんな風にやりたいのなら、削除フラグ自体もユニークにして削除日時を
マイクロ秒まで入れておけばいいのではと後から思ったのは内緒だ。
マイクロ秒まで入れておけばいいのではと後から思ったのは内緒だ。
って書いて、削除フラグをユニークにしたらそもそも「未削除」の状態はどうするんだと気づいた午後。
飲みながらレスするもんじゃないな。
退散します。
飲みながらレスするもんじゃないな。
退散します。
>>625
その例だと使えなくするケースが多いのでむしろ好都合。たいていサポートチームが要望してくる。
その例だと使えなくするケースが多いのでむしろ好都合。たいていサポートチームが要望してくる。
酔っ払いめ！ｗｗ
さて、ユーザーアカウントを例にすると、ちょっと怖すぎるんだが、
CMSなんかのアイテム管理だと、リビジョン管理に同一itemidで
複数のインスタンス、しかも最新以外は非アクティブっていう状態を
表現するという用途があったりする。
その場合、削除フラグを使わずに、使用目的に合わせたタグを振る。
外部キー側もタグやリビジョン番号を考慮した設計にしないといかんわけだけどね。
さて、ユーザーアカウントを例にすると、ちょっと怖すぎるんだが、
CMSなんかのアイテム管理だと、リビジョン管理に同一itemidで
複数のインスタンス、しかも最新以外は非アクティブっていう状態を
表現するという用途があったりする。
その場合、削除フラグを使わずに、使用目的に合わせたタグを振る。
外部キー側もタグやリビジョン番号を考慮した設計にしないといかんわけだけどね。
PACの解説記事でDrupalが良い実装とか見たことあるので同じCMSならこっちは?
リビジョンと直接は関係ないけどソースはしっかりしてるかも
リビジョンと直接は関係ないけどソースはしっかりしてるかも
設計見るのになぜソースを読む
オープンソースソフトウェアの設計書なんて公開されてる？
おそれすになったな・・・
>>587
> インプット・アウトプットの対象の幅広さは、ウェブアプリなんかとは比べものにならんように思う。
> ウェブアプリの場合は、一部APIサービス的なものを除けば、ほぼ「画面」相手でいいわけだが。
それをいったら、ウェブじゃないアプリだって、ほぼ画面（ディスプレイ）相手だろ？
なんか比較している対象がずれてるよ。
画面じゃなくてOffice系の大規模アプリだって、結局は画面にGUI表示してファイルに書き込むだけなんだし。
ゲームだってそう。ハードウェアデバイスを扱うものもあるだろうけど、それをウェブアプリでやってはだめってことはない。
ブラウザでコーヒー沸かす装置とかｗ
>>587
> インプット・アウトプットの対象の幅広さは、ウェブアプリなんかとは比べものにならんように思う。
> ウェブアプリの場合は、一部APIサービス的なものを除けば、ほぼ「画面」相手でいいわけだが。
それをいったら、ウェブじゃないアプリだって、ほぼ画面（ディスプレイ）相手だろ？
なんか比較している対象がずれてるよ。
画面じゃなくてOffice系の大規模アプリだって、結局は画面にGUI表示してファイルに書き込むだけなんだし。
ゲームだってそう。ハードウェアデバイスを扱うものもあるだろうけど、それをウェブアプリでやってはだめってことはない。
ブラウザでコーヒー沸かす装置とかｗ
>>633
設計書 = ソースコード
設計書 = ソースコード
>>634
元のレスが、アプリとは書いてなくて、「ウェブじゃないシステム」って書いてあるからじゃね？
対象がずれてるというか、「Office系の大規模アプリ」とかゲームとかが念頭にあるのは
わかっててわざと書いてるんだろｗ
車のエンジン制御とか、通信インフラ系とかはシステムじゃねーの？って。
>>585
> それにウェブじゃないシステムが何をしているかというと、
> 結局、ファイルにデータ読み書きして、画面に点を表示しているだけともいえる。
いえねーよｗ
これがむしろ、言いたいことと表現がずれてるんじゃね？
元のレスが、アプリとは書いてなくて、「ウェブじゃないシステム」って書いてあるからじゃね？
対象がずれてるというか、「Office系の大規模アプリ」とかゲームとかが念頭にあるのは
わかっててわざと書いてるんだろｗ
車のエンジン制御とか、通信インフラ系とかはシステムじゃねーの？って。
>>585
> それにウェブじゃないシステムが何をしているかというと、
> 結局、ファイルにデータ読み書きして、画面に点を表示しているだけともいえる。
いえねーよｗ
これがむしろ、言いたいことと表現がずれてるんじゃね？
637 ：nobodyさん：2008/11/16(日) 17:24:18 ID:+7h73lOI
タグの実装を考えています
スペース区切りでtextカラムに入れて、全文検索するのがシンプルでいいかと思ったのですが、
他にいい方法があったら教えてください
スペース区切りでtextカラムに入れて、全文検索するのがシンプルでいいかと思ったのですが、
他にいい方法があったら教えてください
>スペース区切りでtextカラムに入れて、全文検索
これはひどい
これはひどい
639 ：nobodyさん：2008/11/16(日) 17:28:47 ID:+7h73lOI
タグ単位で編集とかしないならいいんじゃない？
普通に考えれば
タグテーブル作って
アイテムテーブルとの間に多対多のリレーションテーブル持てばいいだけだよね
いかにもリレーショナルに解決出来るケースだと思うけど
タグテーブル作って
アイテムテーブルとの間に多対多のリレーションテーブル持てばいいだけだよね
いかにもリレーショナルに解決出来るケースだと思うけど
>>639
それ、フレームワーク関係ないし、それ以前にPHPの問題でもないよ。
DBの問題だからDB関連スレで質問しろよ。
まぁ、正規化すら理解してないみたいだからまずは本でも買って勉強することをオススメするけどね
それ、フレームワーク関係ないし、それ以前にPHPの問題でもないよ。
DBの問題だからDB関連スレで質問しろよ。
まぁ、正規化すら理解してないみたいだからまずは本でも買って勉強することをオススメするけどね
だね
基礎知識が足りてなさそう
基礎知識が足りてなさそう
なるほど、おっしゃる通りですね。
ありがとうございました。
ありがとうございました。
俺はついこの間タグテーブルと、タグと記事のリレーションテーブルで作った。
けど、割とありきたりの機能になったのに、
情報が少なくてベストプラクティスな設計が出来たか不安なんだよね。
タグはパターンとしてどっかに情報がまとまっててもいいと思うんだが。
けど、割とありきたりの機能になったのに、
情報が少なくてベストプラクティスな設計が出来たか不安なんだよね。
タグはパターンとしてどっかに情報がまとまっててもいいと思うんだが。
だから典型的なリレーショナルな設計でいいでしょ
それ以外に特別な事なんて無いんだから
それ以外に特別な事なんて無いんだから
うん基本的すぎてまとめる気が起きない
不安ってのはRDBの理解が不十分なのかと。
不安ってのはRDBの理解が不十分なのかと。
フレームワークの話題が無いのか
symfony使ってるんだけどRoRと比べてモデル周りが貧弱で泣いた
PHPの場合、標準的なDBドライバがないからな。どれも中途半端。
具体的にちんぽにーとrorでどうちがうの？
横レスだけど。
RoRのアプリケーションはRubyで書けるけどSymfonyではRubyで書けない。
これは大きい。それに比べりゃモデル周りなんて大差ないんじゃね？
RoRのアプリケーションはRubyで書けるけどSymfonyではRubyで書けない。
これは大きい。それに比べりゃモデル周りなんて大差ないんじゃね？
んなの当たり前じゃん
フレームワークの比較より言語の比較だし
フレームワークの比較より言語の比較だし
フレームワークを初めてつかったけど「便利な関数群」ってだけじゃん。
違うよ
全然違うよ
全然違うよ
657 ：nobodyさん：2008/11/16(日) 22:07:04 ID:tiBOVYsk
PHPを初めてつかったけど「便利な関数群」ってだけじゃん。
それはそうだよ
>>657
それは半分真実
ただWEBフレームワークであるという視点も抜けている
例えば$_POSTや$_COOKIEは関数か？
HTTPヘッダを自動で吐く機能は関数？
PHPはただ単にWEB入出力とDBアクセスに便利な関数群装備のインタプリタとして
使うのもいいし、不十分な（でも拡張も可能な）フレームワークとしても利用出来る
と思ってるけどどうだろ
それは半分真実
ただWEBフレームワークであるという視点も抜けている
例えば$_POSTや$_COOKIEは関数か？
HTTPヘッダを自動で吐く機能は関数？
PHPはただ単にWEB入出力とDBアクセスに便利な関数群装備のインタプリタとして
使うのもいいし、不十分な（でも拡張も可能な）フレームワークとしても利用出来る
と思ってるけどどうだろ
フレームワークはパターンとルール
それは多分定義のレイヤが違う
「便利な関数群」つうだけならそれはライブラリ。
ワークはあるがフレームがない。
ワークはあるがフレームがない。
>>657
webプログラミングがまだ試行錯誤だった時代に、
その「便利な関数群」ってだけのことがとても
大きかったから、シェアが取れた。
便利な関数群自体がほとんど無かったからね。
Javaと同じ。
webプログラミングがまだ試行錯誤だった時代に、
その「便利な関数群」ってだけのことがとても
大きかったから、シェアが取れた。
便利な関数群自体がほとんど無かったからね。
Javaと同じ。
$_SESSIONとか$_REQUESTとか勝手にcontent-typeが出力されるとか、PHPの言語機能自体にウェブアプリ用の機能が組み込まれてるからな。
１回Ｃ言語でＷＥＢアプリ作ってみると良く分かる
あとＰＨＰが流行ったのはＷＥＢアプリ（のインタフェース部分）はこの程度の機能で十分って事もあるだろうね
敷居を低くしてしまって素人プログラマーが流入してきても
ＷＥＢ分野には受け皿がある
あとＰＨＰが流行ったのはＷＥＢアプリ（のインタフェース部分）はこの程度の機能で十分って事もあるだろうね
敷居を低くしてしまって素人プログラマーが流入してきても
ＷＥＢ分野には受け皿がある
webアプリなんて一方通行だからな
アホでも書けるんだよ
アホでも書けるんだよ
http://ja.wikipedia.org/wiki/Web%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF
ここで言うプル型アーキテクチャのフレームワークってPHPでなんかある？
ここで言うプル型アーキテクチャのフレームワークってPHPでなんかある？
Smarty
なんか新しいフレームワークがでてきたらしい
Yii Web Programming Frameworkは期待できそう。
http://cakephp.seesaa.net/article/109833179.html
Yii Web Programming Frameworkは期待できそう。
http://cakephp.seesaa.net/article/109833179.html
Perlは組み込み関数は少ない。
CPANモジュールをインストールしなければ行けないから、リモートログインとシェルが使えない共用のレンタルサーバなんかだと使い物にならない。
多少なりともUNIXの知識も要求されるし。
その点、PHPの場合、mbstringが有効になってれば、Pearが使えなくてもどうにでもなる。
CPANモジュールをインストールしなければ行けないから、リモートログインとシェルが使えない共用のレンタルサーバなんかだと使い物にならない。
多少なりともUNIXの知識も要求されるし。
その点、PHPの場合、mbstringが有効になってれば、Pearが使えなくてもどうにでもなる。
>>673
それはかなり昔の話だけどね。
PHPで global $HTTP_GET_VARS とかしなきゃいけない、ってのに近いくらいｗ
特に、Perl5.8からはEncode標準添付だし、MovableTypeの流行以降は、
そこらのレンタルサーバでも一通りのモジュールは入るようになってる。
DBI・DBMやらも普通に使えるのが大半。
その頃にはみんなレンタルサーバでのPerl CGIから離れてしまってたがなｗ
それはかなり昔の話だけどね。
PHPで global $HTTP_GET_VARS とかしなきゃいけない、ってのに近いくらいｗ
特に、Perl5.8からはEncode標準添付だし、MovableTypeの流行以降は、
そこらのレンタルサーバでも一通りのモジュールは入るようになってる。
DBI・DBMやらも普通に使えるのが大半。
その頃にはみんなレンタルサーバでのPerl CGIから離れてしまってたがなｗ
PHPは5-6年前の時点でPHP4が普及してたから。
そもそも国際版のPHP3ってレンタルサーバで提供されることはほとんどなかった。あっても、すぐに4に移行したから。
Perlの場合、5.8.10になっても標準モジュールだけでは既存のウェブフレームワークは動かない。
モジュールをインストールしても、CatalystみたいなのはCGI環境ではまともな速度が出ないし。
共用レンタルサーバへの設置の難しさがあって、MTがWordPressに抜かれて、XOOPSとかPukiWikiとかフリーのウェブアプリってPHPの一人勝ちになった。
Perlが使われるのは未だにKENTのCGIとか。
そういう反省があって、今のPerl界でMENTAとかの設置の簡単な、標準外のモジュールに依存しないウェブフレームワークが注目されてる。
けど、結局のところ、ベストプラクティスに載ってるようなモダンなPerlを書こうと思えば、適時CPANモジュールをインストールするしかないわけで、これはPerlっていう言語の性格上どうにもならないな。
そもそも国際版のPHP3ってレンタルサーバで提供されることはほとんどなかった。あっても、すぐに4に移行したから。
Perlの場合、5.8.10になっても標準モジュールだけでは既存のウェブフレームワークは動かない。
モジュールをインストールしても、CatalystみたいなのはCGI環境ではまともな速度が出ないし。
共用レンタルサーバへの設置の難しさがあって、MTがWordPressに抜かれて、XOOPSとかPukiWikiとかフリーのウェブアプリってPHPの一人勝ちになった。
Perlが使われるのは未だにKENTのCGIとか。
そういう反省があって、今のPerl界でMENTAとかの設置の簡単な、標準外のモジュールに依存しないウェブフレームワークが注目されてる。
けど、結局のところ、ベストプラクティスに載ってるようなモダンなPerlを書こうと思えば、適時CPANモジュールをインストールするしかないわけで、これはPerlっていう言語の性格上どうにもならないな。
>>677
ビューがコントローラーにデータをリクエストする。を読むと、
すごいイベント駆動ぽい気がするんだけど・・・
プル型というのは、いったい何のための仕組みなんだ？
コントローラーがビューにデータを渡すのではなく、
あえてビューがコントローラーにデータをリクエストする理由が知りたい。
ビューがコントローラーにデータをリクエストする。を読むと、
すごいイベント駆動ぽい気がするんだけど・・・
プル型というのは、いったい何のための仕組みなんだ？
コントローラーがビューにデータを渡すのではなく、
あえてビューがコントローラーにデータをリクエストする理由が知りたい。
ページデザインだけでサイトが完結しうるところがメリットかな。
オンデマンドに必要なデータを拾いに行くので、自由度が高くなる。
ページに組み込むパーツがいかように変化してもコントローラーを
いじらなくて済むところとか。
まぁ、プッシュ型でも、ビューからコントローラーを呼べるはず。
それが特殊な時だけ利用するのか、常にそうするのかの違いだな。
CMSでイベント駆動だとプル型っぽい動きさせてるのが結構ある。
フレームワークはなんだかんだボトムアップだからプッシュ型が普通で、
それに慣れすぎてる感はある。
オンデマンドに必要なデータを拾いに行くので、自由度が高くなる。
ページに組み込むパーツがいかように変化してもコントローラーを
いじらなくて済むところとか。
まぁ、プッシュ型でも、ビューからコントローラーを呼べるはず。
それが特殊な時だけ利用するのか、常にそうするのかの違いだな。
CMSでイベント駆動だとプル型っぽい動きさせてるのが結構ある。
フレームワークはなんだかんだボトムアップだからプッシュ型が普通で、
それに慣れすぎてる感はある。
あとプル型はコントローラーが複数あるのも特徴とか英文Wikipediaにかいてなかったっけ
なんかフレームワークスレっぽくなってきた
なんかフレームワークスレっぽくなってきた
英文関係無かった須磨祖
あんまり詳しくないから変なこと言ってるかもしんないけど
PHPだと複数ファイルに分けてあるものをIncludeしてくしかないわけで、
MVCはコード書く上での概念みたいな感じでPushもPullも厳密には関係ないよね？
JavaServletのforwardみたいに処理投げ渡したりとかできないよね
PHPだと複数ファイルに分けてあるものをIncludeしてくしかないわけで、
MVCはコード書く上での概念みたいな感じでPushもPullも厳密には関係ないよね？
JavaServletのforwardみたいに処理投げ渡したりとかできないよね
フレームワークが何を自動化するかって事だろ
http://ja.wikipedia.org/wiki/Apache_Tapestry
Tapestryではこんな説明だった。
> Apache Tapestryは、アクションをベースとした仕組みのApache Strutsとは競合する。
> TapestryはStrutsとは違い、コンポーネントベースであり、コード量が少なくて済む点が特徴である。
> またStrutsのようにJSPカスタムタグライブラリを覚えなおす必要がなく、
> 必ずServlet/JSPを作成しなければならないということはなく、
> Javaやネットワークの知識がないウェブデザイナーでも簡単にJava製ウェブアプリケーションを作成できるという利点がある。
アクションをベースとしたStrutsとは違うというあたりが、
なんとなくプル型が分かるような分からないような。
使ってみないと、はっきりしないかなー
Tapestryではこんな説明だった。
> Apache Tapestryは、アクションをベースとした仕組みのApache Strutsとは競合する。
> TapestryはStrutsとは違い、コンポーネントベースであり、コード量が少なくて済む点が特徴である。
> またStrutsのようにJSPカスタムタグライブラリを覚えなおす必要がなく、
> 必ずServlet/JSPを作成しなければならないということはなく、
> Javaやネットワークの知識がないウェブデザイナーでも簡単にJava製ウェブアプリケーションを作成できるという利点がある。
アクションをベースとしたStrutsとは違うというあたりが、
なんとなくプル型が分かるような分からないような。
使ってみないと、はっきりしないかなー
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks
これ見たらpush/pullが一目瞭然。
これ見たらpush/pullが一目瞭然。
Propelでmany-to-manyってどうやるの？
http://ja.wikipedia.org/wiki/ソフトウェアコンポーネント
ここ読んでたらなんとなく分かってきた。
MVCからVを分離して、MCを部品として考えて、
Vから複数の部品を使うってことかな。
ショッピングカートの機能をMCだけ作って、
掲示板の機能もMCだけ作って、
コントローラとのインターフェースが分かってれば、
ビューでうまいことやるだけで、掲示板が組み込まれたECサイトの出来上がり。
語弊を恐れずに、俺の想像をざっくりと書いてみた。
//最近のブラウザはURLエンコードしてくれないのね。
ここ読んでたらなんとなく分かってきた。
MVCからVを分離して、MCを部品として考えて、
Vから複数の部品を使うってことかな。
ショッピングカートの機能をMCだけ作って、
掲示板の機能もMCだけ作って、
コントローラとのインターフェースが分かってれば、
ビューでうまいことやるだけで、掲示板が組み込まれたECサイトの出来上がり。
語弊を恐れずに、俺の想像をざっくりと書いてみた。
//最近のブラウザはURLエンコードしてくれないのね。
普通にwikipedia読めば分かるじゃん
どのページ？
ちんぽプルプルですね
わかります
わかります
ですね分かりますは終了したってどっかに書いてあったよ
どっかで終了宣言したら終わりなんですね
分かります
分かります
695 ：nobodyさん：2008/11/22(土) 10:57:11 ID:enBp98lH
グレイトなMVCフレームワークないかい？
あったら困らん
ZF出たね
yii使ってみた人いる？
symfonyとcakePHPってどっちがいいの？
ユーザーは常時アクセス百人ぐらいを想定してます。
ユーザーは常時アクセス百人ぐらいを想定してます。
そのレベルではどっちでも大して変わらんかと
軽いっちゃあcakePHPだろうね。機能的にはsymfonyかね。
まぁそれぐらいの人数じゃ負荷は別に別に気にしなくてもいいと思うけどね。
まぁそれぐらいの人数じゃ負荷は別に別に気にしなくてもいいと思うけどね。
やりたいことにもよるだろ。
ドキュメントぐらい見ろや。
ドキュメントぐらい見ろや。
自分でちょっとした軽いサイトを作りたいなてとき
CakePHPがよい
どういうサイトが当たるかわかんないから
とにかく当たりそうなサイトを片っ端から量産したいときにはCakePHPがいい
大企業からマジ受けするならsymfonyかな
そんな大企業を相手できない俺は小回りが利いて時代にニーズにいち早く対応できるCakePHPが一番好きだ
CakePHPがよい
どういうサイトが当たるかわかんないから
とにかく当たりそうなサイトを片っ端から量産したいときにはCakePHPがいい
大企業からマジ受けするならsymfonyかな
そんな大企業を相手できない俺は小回りが利いて時代にニーズにいち早く対応できるCakePHPが一番好きだ
705 ：nobodyさん：2008/11/23(日) 23:03:07 ID:I/SHm+AO
Cakeの方がインストール簡単
CakePHPみたいに作りたいなと思ったサイトをサクッと作れる快感がたまらん
時代の流れの速いＩＴ業界にあってるよ
時代の流れの速いＩＴ業界にあってるよ
おれはSymfonyの方がよりオブジェクト指向な分使いやすいな
ドキュメントもしっかりしてるし
ドキュメントもしっかりしてるし
その二つのどっちかが今の主流なのかな
今の日本での主流はcake。
php6の後も稼動し続ける予定ならZFが無難。
http://www.google.com/trends?q=cakephp%2CZend+framework%2Csymfony%2Ccodeigniter%2Cethna&ctab=0&geo=all&date=all&sort=0
検索数だからあてにならないかもしれないけど
日本語圏はcakeを世界で2番目に使ってるっぽいぞ。
つーか、地域だと目黒区が1位だけどお前ら寄付とかしてんの？ｗ
php6の後も稼動し続ける予定ならZFが無難。
http://www.google.com/trends?q=cakephp%2CZend+framework%2Csymfony%2Ccodeigniter%2Cethna&ctab=0&geo=all&date=all&sort=0
検索数だからあてにならないかもしれないけど
日本語圏はcakeを世界で2番目に使ってるっぽいぞ。
つーか、地域だと目黒区が1位だけどお前ら寄付とかしてんの？ｗ
インドネシア語が一位って。。
それ眉唾すぎないか
それ眉唾すぎないか
ZFだけはないわ
cakeはドジでのろまな亀しか使ってないし
普通はsymfonyだろうな
cakeはドジでのろまな亀しか使ってないし
普通はsymfonyだろうな
ちょろっとしか見なかったらなぜZFがあんな駄目駄目言われるかわからん。
みんな言うからきっとそうなんだろう。
みんな言うからきっとそうなんだろう。
俺フレームワークの基礎にするには、別にZFは悪くない
symfonyは知らんが、cakeとかCIとかのように、「こう書けばすぐアプリ」っていう
がっちがちの枠を、ZFでは用意していないだけ。
symfonyは知らんが、cakeとかCIとかのように、「こう書けばすぐアプリ」っていう
がっちがちの枠を、ZFでは用意していないだけ。
PEARみたいなライブラリということか
密であるが疎にはできないものと
密にも疎にもできるもののどちらがいいかっていったら
そりゃ後者だわな
密にも疎にもできるもののどちらがいいかっていったら
そりゃ後者だわな
そこら辺の凡人ＰＧがPHP4時代に書いたど腐れライブラリなんかは、
全部ZFに置き換えてもいいくらいだと思うよ
なんつーの？ 割り切り仕様というか内部諒解仕様というか、そういった
よくわからん決め打ち系の記述は（マルチバイト関連を除けば）非常に少なく、
かなり汎用的に作られてるっぽい。
例外処理だけ、ZF流儀にあわせればあとはどう使おうと自由って感じで。
全部ZFに置き換えてもいいくらいだと思うよ
なんつーの？ 割り切り仕様というか内部諒解仕様というか、そういった
よくわからん決め打ち系の記述は（マルチバイト関連を除けば）非常に少なく、
かなり汎用的に作られてるっぽい。
例外処理だけ、ZF流儀にあわせればあとはどう使おうと自由って感じで。
メリットもあるが色々弊害もあるのだよ、僕
それはフレームワークでなくて別って意味でしょう。
ZFは自由に使えって言うけどライブラリとの違いが分からない。
そして、結局ライブラリを細切れに使うのと手間が一緒の気がするんだけど。
それ以上のメリットがあるのか良く分からない。
ZFは自由に使えって言うけどライブラリとの違いが分からない。
そして、結局ライブラリを細切れに使うのと手間が一緒の気がするんだけど。
それ以上のメリットがあるのか良く分からない。
>>719
具体的にそれでどんな悪い点が？
具体的にそれでどんな悪い点が？
>>719
使ってみればわかるが、ZFにフレームはある。
ただ、それは固定されたフレームではなくて、設計者が自由に拡張可能なフレームだ
設計を行わない人にとっては無用の長物。メリットだってわからない。
使ってみればわかるが、ZFにフレームはある。
ただ、それは固定されたフレームではなくて、設計者が自由に拡張可能なフレームだ
設計を行わない人にとっては無用の長物。メリットだってわからない。
決め打ちでしかプログラミングできない低脳にはおすすめできないってこった
>>720
あえて言えばメリットが見つからないというのが悪い点かと
>>721
使い込んでみないと分からないって事でしょうか。
もうちょっと機会があれば研究してみたいとは思います。
>>722
なるほどそうですかw
あえて言えばメリットが見つからないというのが悪い点かと
>>721
使い込んでみないと分からないって事でしょうか。
もうちょっと機会があれば研究してみたいとは思います。
>>722
なるほどそうですかw
Eclipseでsymfonyフレームワーク使ってプログラミングしたいんだけど、可能？
どういう意味かはっきり書かないと答えようがない。
Eclipseはエディタだからそりゃ可能だ。
Eclipseはエディタだからそりゃ可能だ。
PDTで書けるかって意味ぢゃね？
ethnaとかちょっと微妙だから。
symofnyは大丈夫だけど、少しコツがいる。
けど、なんか安定しないんだよなぁ。もう1.2の声が聞こえてくるし。またコンバート作業必要なんでしょ？
＞ 1.1→1.2
ethnaとかちょっと微妙だから。
symofnyは大丈夫だけど、少しコツがいる。
けど、なんか安定しないんだよなぁ。もう1.2の声が聞こえてくるし。またコンバート作業必要なんでしょ？
＞ 1.1→1.2
微妙って意味がわからんのだが
htmlまわりの話か?
htmlまわりの話か?
最近は知らんけど、1年くらい前の状況だと、
Ethnaの構造ではPDTでは補完が働かなかったな。
あとコマンドラインでアクションやビューやテンプレートが生成されるので、
いちいちプロジェクトを更新するのが面倒だった。
ファイルの追加がPDT外で行われて、PDTの補完も働かないんじゃ、
わざわざ重たいPDTを使うメリットがないと思った。
symfonyは使ってないからしらね。
Ethnaの構造ではPDTでは補完が働かなかったな。
あとコマンドラインでアクションやビューやテンプレートが生成されるので、
いちいちプロジェクトを更新するのが面倒だった。
ファイルの追加がPDT外で行われて、PDTの補完も働かないんじゃ、
わざわざ重たいPDTを使うメリットがないと思った。
symfonyは使ってないからしらね。
プロジェクトの更新なんてF5一発でいいのでは。
そんなこと言ってたらSVNでの頻繁な更新なんてできないじゃないかｗ
補完もどのみち最初から微妙っちゃ微妙だし。
少なくともPCパワーさえある程度あれば、テキストエディタよりは便利だと思う
まあやりやすいようにやればいいんだけど
そんなこと言ってたらSVNでの頻繁な更新なんてできないじゃないかｗ
補完もどのみち最初から微妙っちゃ微妙だし。
少なくともPCパワーさえある程度あれば、テキストエディタよりは便利だと思う
まあやりやすいようにやればいいんだけど
俺の場合、PDTに感じる価値がちょうどプロジェクトの管理と補完だからな。
逆にエディタとして見ると融通が利かない駄目なやつと思っている。
最近は出来るようになったけど、全角スペースをマーク表示させたり出来なかったとか、
後は覚えてないけど細かいところでたまにイラっとする。
だから俺は、プロジェクト管理と補完のために使ってるようなもんだ。
逆にエディタとして見ると融通が利かない駄目なやつと思っている。
最近は出来るようになったけど、全角スペースをマーク表示させたり出来なかったとか、
後は覚えてないけど細かいところでたまにイラっとする。
だから俺は、プロジェクト管理と補完のために使ってるようなもんだ。
一応、Eclipseの特徴として on the fly な構文チェックってのはあるけどね。
しょうもないparse errorとか、未定義変数とか示してくれるのは、非常に効率アップしてくれる
自分が注意力散漫だけかもしれんけどｗ
他のエディタでもこの機能はあるのかな？
しょうもないparse errorとか、未定義変数とか示してくれるのは、非常に効率アップしてくれる
自分が注意力散漫だけかもしれんけどｗ
他のエディタでもこの機能はあるのかな？
PDTにsymfony用のプラグインってあるよね
使ったことはないけど
使ったことはないけど
http://www.symfony-framework.com/2007/12/10/best-symfony-ide-eclipse-pdt-symfoclipse-clay/
http://noy.cc/symfoclipse/index.html
Symfoclipseつーやつかな？
http://noy.cc/symfoclipse/index.html
Symfoclipseつーやつかな？
てか、Eclipse使ってる人はPDTが多いのか。
なぜか理由は忘れたが、PHPEclipseの方を使ってる俺は異端？
なぜか理由は忘れたが、PHPEclipseの方を使ってる俺は異端？
オレなんて未だにTruStudioなんだぜ、自宅は
さすがに会社はPDTに乗り換えたが、自宅じゃ
めんどくせーからこのまんまでいいやみたいな
さすがに会社はPDTに乗り換えたが、自宅じゃ
めんどくせーからこのまんまでいいやみたいな
PDTならZSの方がインスコも楽だしアナライザーもはいる。
無料でよろし。お薦めする。
無料でよろし。お薦めする。
Zend Studio？ 無料？
そう。ZSは試用期間が終わるとPDTとほぼ同様になる。
尚日本語版は勧めない。日本語化したければPDTと同じようにする。
尚日本語版は勧めない。日本語化したければPDTと同じようにする。
>>740
スケルトンがな。
ルーティングなんていくらでも変えられる。
しかし、スケルトンもEthnaのデフォを削除しちゃって、自分Appのは
Handlerを定義しちゃえばいけるんじゃね？そんな手間でもないと思うが。
スケルトンがな。
ルーティングなんていくらでも変えられる。
しかし、スケルトンもEthnaのデフォを削除しちゃって、自分Appのは
Handlerを定義しちゃえばいけるんじゃね？そんな手間でもないと思うが。
742 ：nobodyさん：2008/12/01(月) 22:29:43 ID:XLqJXNnh
http://www.yiiframework.com/performance/
Yii 178
CakePHP 170
CodeIgniter 131
Prado 53
Zend 51
Symfony 36
数字はRequest Per Second
Yii 178
CakePHP 170
CodeIgniter 131
Prado 53
Zend 51
Symfony 36
数字はRequest Per Second
いいねいいね
今度使ってみるか
今度使ってみるか
744 ：nobodyさん：2008/12/01(月) 23:19:54 ID:XLqJXNnh
こういうhello worldにベンチってどんくらい意味あんのかとか思ってたけど
そのページに書いてあるようにあくまでRPSの上限を計るベンチで（これ以上の値は出ない）、
ajaxとかhtmlレンダリングない場合もあるしでやっぱり価値はある。
そのページに書いてあるようにあくまでRPSの上限を計るベンチで（これ以上の値は出ない）、
ajaxとかhtmlレンダリングない場合もあるしでやっぱり価値はある。
そのベンチ、Yiiだけecho 'Hello World';になってて
他のがdie('Hello World');になってるのは何で？
まあ大抵のベンチは信用出来ないのは知ってるけども。
他のがdie('Hello World');になってるのは何で？
まあ大抵のベンチは信用出来ないのは知ってるけども。
dieの方が速いけどw
なんでこんな速いの？エクステンション？
http://phpimpact.wordpress.com/2008/07/02/which-php-framework-is-slower/
Baseline PHP 331.8
CodeIgniter 21.5
Zend Framework 9.2
CakePHP 3.7
Baseline PHP 331.8
CodeIgniter 21.5
Zend Framework 9.2
CakePHP 3.7
ま た ベ ン チ パ フ ォ ー マ ン ス か
一応客観的っぽい比較はできるのかもしれないが、だからどうしたってんだ。
ってまだ誰も、使うどころか中を見てもないんだろうけどｗ
一応客観的っぽい比較はできるのかもしれないが、だからどうしたってんだ。
ってまだ誰も、使うどころか中を見てもないんだろうけどｗ
>>749がコードを読んでパフォーマンスについての詳細な報告をしてくれるそうです
"Yii is a high-performance component-based PHP framework for developing large-scale Web applications."
コンポーネント指向？ってどんな感じのを言うの？
コンポーネント指向？ってどんな感じのを言うの？
また新しいFWが登場したの？
みなさんのレポ（人柱）に期待ｗ
みなさんのレポ（人柱）に期待ｗ
G5の方がインテルより速いといい張ってた企業があったしな・・
ベンチマークなんて所詮うんちマークです
それが偉い人には分からんのです
ベンチマークなんて所詮うんちマークです
それが偉い人には分からんのです
ボトルネックはDBまわりだったりするしな
>>751
サービス指向と一緒にググるとよくわかる多分
サービス指向と一緒にググるとよくわかる多分
helloのベンチなんて高機能FWが不利に決まってるジャマイカ
yiiって3メートル競走でフェラーリに勝ったと宣言する原付みたいだねm9（＾Д＾）ﾌﾟｷﾞｬｰ
一応ActiveRecordやpure OOP、ドキュメントの整備なんかもウリにしてるみたい
=等の演算子にスペースをつけないとか if ～ else で { } を省略したり ?> を書かない
スタイルだったり、ところどころに小さなこだわり（？）を感じるｗ
demoしか見てないけど、Controllerの記述なんかはシンプルでいい感じ。（guessworkみたい？）
簡単なWebアプリなら、ドキュメント読まなくても何とかなるかな？
=等の演算子にスペースをつけないとか if ～ else で { } を省略したり ?> を書かない
スタイルだったり、ところどころに小さなこだわり（？）を感じるｗ
demoしか見てないけど、Controllerの記述なんかはシンプルでいい感じ。（guessworkみたい？）
簡単なWebアプリなら、ドキュメント読まなくても何とかなるかな？
ベンチって脊髄反射で熱くなるやつ多いよな
CakePHPのフォーラムとか
CakePHPのフォーラムとか
>?> を書かない
これは当たり前だろ…
むしろ書く方がアホ
これは当たり前だろ…
むしろ書く方がアホ
762 ：nobodyさん：2008/12/02(火) 22:16:29 ID:FW3sGcTR
まあ、symfonyは重すぎるな。
>>749,753,754,756,757
I can hear the objections now:
* “Not realistic!”
* “Not comprehensive!”
* “Doesn’t account for features that I like!”
* “Who cares, I don’t need that level of responsiveness!”
* “Doesn’t matter if Framework X is slower, I’m more productive with it!”
Yes, yes, you’re all correct. ┐(´ー｀)┌
http://paul-m-jones.com/blog/?p=236
I can hear the objections now:
* “Not realistic!”
* “Not comprehensive!”
* “Doesn’t account for features that I like!”
* “Who cares, I don’t need that level of responsiveness!”
* “Doesn’t matter if Framework X is slower, I’m more productive with it!”
Yes, yes, you’re all correct. ┐(´ー｀)┌
http://paul-m-jones.com/blog/?p=236
>>760
決めつける奴も(ry
------------------------------------
<?php
echo "hello\n";
------------------------------------
↑こういうの、気持ち悪くないか？そういう感覚を大事にしてる人間も結構な割合でいるぞ。
決めつける奴も(ry
------------------------------------
<?php
echo "hello\n";
------------------------------------
↑こういうの、気持ち悪くないか？そういう感覚を大事にしてる人間も結構な割合でいるぞ。
>>764
それでいくと\nが気持ち悪い。ちゃんと書こうよ。
それでいくと\nが気持ち悪い。ちゃんと書こうよ。
ん？こうかな？
#!/usr/bin/php
<?php
echo "hello.\n";
#!/usr/bin/php
<?php
echo "hello.\n";
凄いな･･･理解して書いてないよな。
どっちも痛いけど>>767が果てしなく痛い
>>769
ﾎｯﾄｹ
ﾎｯﾄｹ
>>766でOSの違いを吸収したつもりだったけど・・・OSXなんてしらね orz
PHP_EOLってのでいいのか
PHP_EOLってのでいいのか
さすがPerlなんともないぜ
VBですら定数あったな
PHP_EOLはstr_replace(PHP_EOL,'<br />',$str)みたいな使い方するもんだろ。
PHP_EOLを出力に使うなよ。
PHPから抜け出して改行打った場合に、実行するOSによって
改行がバラけるだろ。
PHP_EOLを出力に使うなよ。
PHPから抜け出して改行打った場合に、実行するOSによって
改行がバラけるだろ。
タブやらヌルが一種類で本当によかったよな
新説ktkr
サーバのOSでの改行コードだから、両方関係ないだろ。
hello worldでPHP_EOL
見てる人のOSで改行されるとは限らない。
スクリプトで使ってる改行が実行サーバの改行コードと同じとは限らない。
str_replaceでPHP_EOL
見てる人のOSの改行コードがサーバと同じとは限らない。
hello worldでPHP_EOL
見てる人のOSで改行されるとは限らない。
スクリプトで使ってる改行が実行サーバの改行コードと同じとは限らない。
str_replaceでPHP_EOL
見てる人のOSの改行コードがサーバと同じとは限らない。
・・・見てる人？べつにブラウザ相手限定の話ではないとおもったが。
「スクリプトで使ってる改行」はPHPがなんか吸収してくれてるっぽいけどな。
LFでもCRLFでも動く。CRのみは知らないけどｗ
Perl CGI から移って最初のカルチャーショックはそれ。普通にLinuxマシンに
CRLFでアップロードしてるんじゃねーよって。
だから >>773 には半分だけ同意ｗ
>>776は新説。展開に期待しよう。
ブラウザがどの文字コードでどの改行コードでフォームデータを送ってくるか、
その辺もそろそろ定義および実装してほしいもんだ。
現状、なんとなく、UTF-8のページからは（ユーザの悪意がなければ）UTF-8で
飛んでくることを期待して作ってしまうんだが大丈夫なのかな・・・。
改行コードは仕方ないから変換するけど。
スレ違いｽﾏｿ
「スクリプトで使ってる改行」はPHPがなんか吸収してくれてるっぽいけどな。
LFでもCRLFでも動く。CRのみは知らないけどｗ
Perl CGI から移って最初のカルチャーショックはそれ。普通にLinuxマシンに
CRLFでアップロードしてるんじゃねーよって。
だから >>773 には半分だけ同意ｗ
>>776は新説。展開に期待しよう。
ブラウザがどの文字コードでどの改行コードでフォームデータを送ってくるか、
その辺もそろそろ定義および実装してほしいもんだ。
現状、なんとなく、UTF-8のページからは（ユーザの悪意がなければ）UTF-8で
飛んでくることを期待して作ってしまうんだが大丈夫なのかな・・・。
改行コードは仕方ないから変換するけど。
スレ違いｽﾏｿ
Perlだったらjcode.plとかJcode.pmとかEncodeとかあるだろうよ。
guess して不明なら全部はねる？
まあそういう作り方もあるだろうけどね
まあそういう作り方もあるだろうけどね
文字コードは、RFCでサーバが出力した文字コード以外でPOSTしても
違反ではない事になってるんだな。
accept-charsetっていうのもあるけど、対応して無いブラウザもある。
被ってる領域内の文字しか無かったら判別は不可能なのにね。
実際は大抵のブラウザはヘッダの指定と同じ文字コード送ってくれるし
mb_conbertとかで優先順の1位を出力にあわせればまず平気だけども
イレギュラーなブラウザは存在する。
あとはhiddenで文字コード判別出来る文字列送るって方法もある。
英語圏なら全てctypeでOKなのにな。
RFCもブラウザ作ってる奴も文字コード増やしてる奴も爆発しろ。
違反ではない事になってるんだな。
accept-charsetっていうのもあるけど、対応して無いブラウザもある。
被ってる領域内の文字しか無かったら判別は不可能なのにね。
実際は大抵のブラウザはヘッダの指定と同じ文字コード送ってくれるし
mb_conbertとかで優先順の1位を出力にあわせればまず平気だけども
イレギュラーなブラウザは存在する。
あとはhiddenで文字コード判別出来る文字列送るって方法もある。
英語圏なら全てctypeでOKなのにな。
RFCもブラウザ作ってる奴も文字コード増やしてる奴も爆発しろ。
イレギュラーなブラウザなんて少ないんだからそこらへんは趣味じゃない
でも、何となくいけてるだけっていうのに違いはないんだよね
まあ判別して不明なら受け入れるっていうのが慎重かつ幅広い対応なんだろうな
んで、Yiiはどこに行ったんだ。実は少し期待してるんだけど。
まあ判別して不明なら受け入れるっていうのが慎重かつ幅広い対応なんだろうな
んで、Yiiはどこに行ったんだ。実は少し期待してるんだけど。
結局はちいたんで（ｒｙ
>>763
symfonyは他のに比べて読み込むファイルが多すぎなんだよな。
symfonyは他のに比べて読み込むファイルが多すぎなんだよな。
PHPFWの色々な比較みたいなのやってるサイトとかないかねぇ
>>788
なんの比較?
なんの比較?
symfonyみたいに、自作クラスをどこにでも置ける機能を実装したFWって
他にない？
他にない？
>>790
コーディングのお手本に使ってる
コーディングのお手本に使ってる
蒼井ｿﾗｰ
>>791
kwsk
kwsk
俺のｿﾗｰ
そういうことやってるから、重くなるんだよな。
全ファイルrequireするってこと？
ものすごく愚かっぽいんだが
ものすごく愚かっぽいんだが
sfCoreAutoload.class.php
class sfCoreAutoload
protected $classes = array (
'sfAction' => 'action',
'sfActionStack' => 'action',
'sfActionStackEntry' => 'action',
'sfActions' => 'action',
'sfComponent' => 'action',
'sfComponents' => 'action',
こんなんが延々と350行もあんだぜ。
autoloaderのクラスファイルだけで3つもあるし
んで肝心のファイル読み込みは
require($this->classes[$class]);
とか
require($this->classes[$module.'/'.$class]);
だったら普通にPEAR/Zend/Solar系の命名規則の方がいいと思う。
class sfCoreAutoload
protected $classes = array (
'sfAction' => 'action',
'sfActionStack' => 'action',
'sfActionStackEntry' => 'action',
'sfActions' => 'action',
'sfComponent' => 'action',
'sfComponents' => 'action',
こんなんが延々と350行もあんだぜ。
autoloaderのクラスファイルだけで3つもあるし
んで肝心のファイル読み込みは
require($this->classes[$class]);
とか
require($this->classes[$module.'/'.$class]);
だったら普通にPEAR/Zend/Solar系の命名規則の方がいいと思う。
>>791
だいたい、仮にもフレームワークを使っていて、外部クラスを『どこにでも』置きたいとか思わない。
そういったもの(基本拡張やvendor等外部ライブラリ)が考慮されていない糞FWは別なのかな？
だいたい、仮にもフレームワークを使っていて、外部クラスを『どこにでも』置きたいとか思わない。
そういったもの(基本拡張やvendor等外部ライブラリ)が考慮されていない糞FWは別なのかな？
それでも最低40ﾌｧｲﾙ読み込まれるわけだ
APC使ったらファイル数そんなに関係なくね
誤爆した
>>803
ましにはなるけどやっぱり遅い。
ましにはなるけどやっぱり遅い。
symfony遅いって言ってるのはレンタル鯖使ってるようなD級プログラマだろ？
負荷について考えずに済むなんてどんだけ小さなシステム運用してんだよ
いいぞもっとやれ
例えばDBからのデータをとるとき。
オブジェクトの中に保持する
$WB = new Weblog;
$WB->findById( 1 );
echo $WB->getTitle() ;
みたいなヤツと
データセットを返すやつ
$WB = new Weblog;
$data = $WB->findById( 1 );
echo $data['title'] ;
どっちが好きですか？？
オブジェクト思考っぽいのは前者かなぁとか思うのですけども
後者のほうが、なんか使いやすい感じもする。
オブジェクトの中に保持する
$WB = new Weblog;
$WB->findById( 1 );
echo $WB->getTitle() ;
みたいなヤツと
データセットを返すやつ
$WB = new Weblog;
$data = $WB->findById( 1 );
echo $data['title'] ;
どっちが好きですか？？
オブジェクト思考っぽいのは前者かなぁとか思うのですけども
後者のほうが、なんか使いやすい感じもする。
前者はActiveRecordパターン、後者はDataMapperパターンですね。
自分はDataMapperのほうが好き。
自分はDataMapperのほうが好き。
>>810
前者はActiveRecordっぽいってことになるのかな？それなら、
$WB->findById( 1 );
echo $WB->getTitle() ; // $WB->title もたぶん可
$WB->title = 'new title';
$WB->save();
とかできるメリットが結構大きいような。あんまり直接比較できないような気がする。
例えば前者でも、後者との折衷で返値を持つようにして、
$data = $WB->findById(1);
echo $data->title; // 配列で返せば echo $data['title'] も可
とかやることは可能だろうし。
前者はActiveRecordっぽいってことになるのかな？それなら、
$WB->findById( 1 );
echo $WB->getTitle() ; // $WB->title もたぶん可
$WB->title = 'new title';
$WB->save();
とかできるメリットが結構大きいような。あんまり直接比較できないような気がする。
例えば前者でも、後者との折衷で返値を持つようにして、
$data = $WB->findById(1);
echo $data->title; // 配列で返せば echo $data['title'] も可
とかやることは可能だろうし。
あ、すみません。状況を書いていませんでした。
初心者教育みたいな感じで使うものです。
PHPの基礎的なこと、PHPとHTMLが混在するアレをやったあとで
実践編としてMVC的な考え方を導入しようと思っています。
Vの切り出しはわりとすんなりできるのですが
Mの例はどっちかなぁ。。という。
善し悪しは一概には言えないと思うので
いっそ、好き嫌いを聞いてみようとｗ
初心者教育みたいな感じで使うものです。
PHPの基礎的なこと、PHPとHTMLが混在するアレをやったあとで
実践編としてMVC的な考え方を導入しようと思っています。
Vの切り出しはわりとすんなりできるのですが
Mの例はどっちかなぁ。。という。
善し悪しは一概には言えないと思うので
いっそ、好き嫌いを聞いてみようとｗ
>>813
使うモノによるんだろうけど、>>810の前者の方は、「～～パターン」っていう思想をまず理解し、
そのライブラリのドキュメントのサンプルなんかを熟読して勉強しないと使えない気がする。
後者は、とりあえずニュアンスで使える感じ。
そんなざっくりした感想。
自分の好みはどちらかというと前者の、なんか有機的で乾いてない雰囲気でしかもよく考えられていて
またしっかり作り込まれている、っていうライブラリだけど、そんなものある程度以上は幻想な気がする
ので、どうせ中途半端になるんだからどっちでもいいやって思う。
言い方は悪いが、前者はトリッキー、後者は土方的、に感じる。
使うモノによるんだろうけど、>>810の前者の方は、「～～パターン」っていう思想をまず理解し、
そのライブラリのドキュメントのサンプルなんかを熟読して勉強しないと使えない気がする。
後者は、とりあえずニュアンスで使える感じ。
そんなざっくりした感想。
自分の好みはどちらかというと前者の、なんか有機的で乾いてない雰囲気でしかもよく考えられていて
またしっかり作り込まれている、っていうライブラリだけど、そんなものある程度以上は幻想な気がする
ので、どうせ中途半端になるんだからどっちでもいいやって思う。
言い方は悪いが、前者はトリッキー、後者は土方的、に感じる。
>>812
>あんまり直接比較できないような気がする。
はいｗ
なので好き嫌いを聞いてみようかな、と。
または感じるメリットかな？
有名そうなフレームワークを見てみましたが
どっちが優勢というわけでもないようです。
>あんまり直接比較できないような気がする。
はいｗ
なので好き嫌いを聞いてみようかな、と。
または感じるメリットかな？
有名そうなフレームワークを見てみましたが
どっちが優勢というわけでもないようです。
>>814
オブジェクトは実際に存在するモノ、という説明があるるじゃないですか。
それにメッセージを投げて、状態を変える、みたいな。
そうすると、前者のほうが、Weblogオブジェクトとしてより理解しやすいかな、と。
後者は、どっちかとういうとデータベースオブジェクトって感じ。
って、感覚ばっかりいってますね私。
オブジェクトは実際に存在するモノ、という説明があるるじゃないですか。
それにメッセージを投げて、状態を変える、みたいな。
そうすると、前者のほうが、Weblogオブジェクトとしてより理解しやすいかな、と。
後者は、どっちかとういうとデータベースオブジェクトって感じ。
って、感覚ばっかりいってますね私。
>>810
$weblog = new Weblog();
$weblog->getTitle(); // コンストラクタ実行した直後にメソッドが死んでるってふざけてるの？
$weblog->findById(1); // 何を見つけるの？え、getTitle が生き返るの？ザオリクなの？
$weblog->setTitle('new title');
$weblog->save(); // 今の状態を永続化しますね
$weblog->findById(2);
if ($weblog->getTitle() !== 'new title') {
// setTitle 呼んでないのになんでタイトル変わってるの？findById 呼んだせいなの？
// findById で始まるトランザクションはどこまで続くの？野をこえ山をこえるの？
// というか働きすぎじゃないの？コンストラクタ以上にコンストラクタ味なの？
}
そんな訳で後者が好きです
$weblog = new Weblog();
$weblog->getTitle(); // コンストラクタ実行した直後にメソッドが死んでるってふざけてるの？
$weblog->findById(1); // 何を見つけるの？え、getTitle が生き返るの？ザオリクなの？
$weblog->setTitle('new title');
$weblog->save(); // 今の状態を永続化しますね
$weblog->findById(2);
if ($weblog->getTitle() !== 'new title') {
// setTitle 呼んでないのになんでタイトル変わってるの？findById 呼んだせいなの？
// findById で始まるトランザクションはどこまで続くの？野をこえ山をこえるの？
// というか働きすぎじゃないの？コンストラクタ以上にコンストラクタ味なの？
}
そんな訳で後者が好きです
ようは、前者が参照渡しで後者が値渡しみたいな感じかな
前者でも、データセットを返す機能がほしければそういうメゾッドを実装すればいいわけで
基本的にはオブジェクトの中で簡潔してるほうがいいかなぁって気もするし
後者だけだと、なんか丸投げな感が機能不足って感じだから前者のが好みかな
ってか使用用途が微妙に違う気がする
前者でも、データセットを返す機能がほしければそういうメゾッドを実装すればいいわけで
基本的にはオブジェクトの中で簡潔してるほうがいいかなぁって気もするし
後者だけだと、なんか丸投げな感が機能不足って感じだから前者のが好みかな
ってか使用用途が微妙に違う気がする
前者も後者もドメインオブジェクトにデータベースへのアクセスロジックを持っているという点では
アクティブレコードに類似してるけど、教科書（PofEAA）にならうならfindByIdメソッドは
新たに生成したWeblogのインスタンスを返すべき。
function findById($id) {
...
$data = mysql_fetch...
$weblog = new Weblog();
$weblog->setTitle($data['title']);
return $weblog;
}
アクティブレコードに類似してるけど、教科書（PofEAA）にならうならfindByIdメソッドは
新たに生成したWeblogのインスタンスを返すべき。
function findById($id) {
...
$data = mysql_fetch...
$weblog = new Weblog();
$weblog->setTitle($data['title']);
return $weblog;
}
>>810のどっちかっていう話より、$obj->getTitle() が気になる
値を参照するだけならむしろ $obj->get('title') の方がわかりやすいし、場合によっては
配列使った方が楽できるような気もする
なんかこの辺の、Java風オブジェクト指向っぽいまわりくどい記述が好きになれない
値を参照するだけならむしろ $obj->get('title') の方がわかりやすいし、場合によっては
配列使った方が楽できるような気もする
なんかこの辺の、Java風オブジェクト指向っぽいまわりくどい記述が好きになれない
>>817
ごめんなさい。例がよくなかったかもです。
もしやるなら>>819のような実装を考えております。
ご指摘のサンプルで言えば
$weblog->findById(2);
じゃなくて
$weblog2->findById(2);
という使いかたです。
メソッド名が不自然かな？
ごめんなさい。例がよくなかったかもです。
もしやるなら>>819のような実装を考えております。
ご指摘のサンプルで言えば
$weblog->findById(2);
じゃなくて
$weblog2->findById(2);
という使いかたです。
メソッド名が不自然かな？
>>820
＞値を参照するだけならむしろ $obj->get('title') の方がわかりやすいし
はい。
クラス変数を直接触らせないためのgetter,setterって目的だったら同じことですよね。
実は私も、それでいいんじゃないのかな？と思ったりしましたが
いろいろなフレームワークやOOPの説明を見ても
そういう実例がなかったので入れませんでした。
＞値を参照するだけならむしろ $obj->get('title') の方がわかりやすいし
はい。
クラス変数を直接触らせないためのgetter,setterって目的だったら同じことですよね。
実は私も、それでいいんじゃないのかな？と思ったりしましたが
いろいろなフレームワークやOOPの説明を見ても
そういう実例がなかったので入れませんでした。
自分はget("title")よりgetTitle()派だなぁ
多機能メゾッドはあまり好きくない
多機能メゾッドはあまり好きくない
get('title')だとエディタで補完できないし、スペル間違える可能性もあるよね
>>824
__call() での自動呼び出しとかじゃないの？全部書いちゃうの？
今はどうなのか詳しくは知らないけど、RDBのフィールド名って大文字小文字を区別しないことがあって、キャメルケースは使いにくかったように思う。
だから、いちいち login_password <=> LoginPassword みたいな書き換えが起こるってことだけでJavaっぽいのは違和感があるなー
__call() での自動呼び出しとかじゃないの？全部書いちゃうの？
今はどうなのか詳しくは知らないけど、RDBのフィールド名って大文字小文字を区別しないことがあって、キャメルケースは使いにくかったように思う。
だから、いちいち login_password <=> LoginPassword みたいな書き換えが起こるってことだけでJavaっぽいのは違和感があるなー
> $obj->get('title')
引数に title2 を与えたら何が返ってくるんだ？
汎用的なコンテナじゃないのだから
部品へのインターフェイス、getTitle() を用意すべき
>>826
824は静的テストでチェックできるかどうかを言いたいんでしょ
引数に title2 を与えたら何が返ってくるんだ？
汎用的なコンテナじゃないのだから
部品へのインターフェイス、getTitle() を用意すべき
>>826
824は静的テストでチェックできるかどうかを言いたいんでしょ
nullが返って来ればいいじゃん
DAOが扱うデータの構造を知らないなんてことはないし、
ユーザ側が直接文字列を投げ込まないといけないようなメゾッドはなんかイマイチ感
ユーザ側が直接文字列を投げ込まないといけないようなメゾッドはなんかイマイチ感
そもそも（特にPHPで実装されている）DAOがダサイっていう意見ではないのかと。
利用する側からしたら、補完機能付きエディタを使うんでなければ 'title' を 'tilte' なんて
書き間違えてあちゃーも getTitle() を getTilte() であちゃーも大して違いはない。
どっちでも例外吐こうと思えば吐けるし。
メソッド名の補完や静的チェックに関しては思想が違うとしか言いようがない。
ActiveRecordも流行の実装は自動的で動的なメソッド定義だし。そんなの静的チェック
なんて（むちゃくちゃ頑張らないと）できないんじゃ？
利用する側からしたら、補完機能付きエディタを使うんでなければ 'title' を 'tilte' なんて
書き間違えてあちゃーも getTitle() を getTilte() であちゃーも大して違いはない。
どっちでも例外吐こうと思えば吐けるし。
メソッド名の補完や静的チェックに関しては思想が違うとしか言いようがない。
ActiveRecordも流行の実装は自動的で動的なメソッド定義だし。そんなの静的チェック
なんて（むちゃくちゃ頑張らないと）できないんじゃ？
シングルトンやサービスロケーターは結局のところグローバルじゃないかね、ケシカラン
とか
DIコンテナって結局GoFのストラテジーじゃないか、イランイラン
とか
OOPって偉い人同士でいつもそんな事言い合ってる、と俺印象。
とか
DIコンテナって結局GoFのストラテジーじゃないか、イランイラン
とか
OOPって偉い人同士でいつもそんな事言い合ってる、と俺印象。
cakePHPとsymfonyの違いってどんなところ？
こんなこと言う奴がいたらアホかと思うけどな
>DIコンテナって結局GoFのストラテジーじゃないか、イランイラン
>DIコンテナって結局GoFのストラテジーじゃないか、イランイラン
これでいいだろ。
error_reporting(E_ALL);
print $row['tilte'];
error_reporting(E_ALL);
print $row['tilte'];
>>834
http://www.infoq.com/jp/news/2007/12/does-di-pay-off
http://kohari.org/2007/08/15/defending-dependency-injection/
http://www.infoq.com/jp/news/2007/12/does-di-pay-off
http://kohari.org/2007/08/15/defending-dependency-injection/
ああそこか。
雰囲気を伝えたかっただけで正確に書いたわけではないのだ。
雰囲気を伝えたかっただけで正確に書いたわけではないのだ。
下らん議論してないで早く833の質問に答えろやｹﾞﾘｸｿ野郎ども
>>833
すみません、おもしろい話が思いつきません
すみません、おもしろい話が思いつきません
symfony使ったことない
PEARでインストール出来るみたいだけど、PEARに依存してる？
本体や拡張のどこかで PEAR.php をrequireしたりしてたりしないよね。
PEARでインストール出来るみたいだけど、PEARに依存してる？
本体や拡張のどこかで PEAR.php をrequireしたりしてたりしないよね。
ｼﾝﾌｫﾆー JAVA的
cake ROR的
CI PHP的
俺印象。どれも使った事は無い。
cake ROR的
CI PHP的
俺印象。どれも使った事は無い。
的外れでしかも使ったことがないとかなんで書き込んだのか分からん。
お前の意見を言えば
Java的とかPHP的とか例えが狂ってるだろ
使ったことがないんじゃなくて使えないんだろ
使ったことがないんじゃなくて使えないんだろ
人の事いいから
お前の意見は
お前の意見は
下らんことで荒らすなカス共
>>846
意見も何も>>842のやりたいことが意味不明だから
使ってないのに俺印象とか、何の印象だよ エスパーかよ
PHPとかJavaとかRoRとか何のカテゴライズだよ
なんでフレームワークと言語がごっちゃになってるんだよ
お前の意見は、意見は、って何が聞きたいんだよ
意見も何も>>842のやりたいことが意味不明だから
使ってないのに俺印象とか、何の印象だよ エスパーかよ
PHPとかJavaとかRoRとか何のカテゴライズだよ
なんでフレームワークと言語がごっちゃになってるんだよ
お前の意見は、意見は、って何が聞きたいんだよ
>>848
～的は使った人から聞いての俺なりの印象。
クリケットは英国的
これ聞いてスポーツの話してんのに国の話して狂ってるとか言ってるのがお前。イメージ伝わらなかったらそれでいいんでスルーしろよ。
それ以上やりたいならURL指定してくれ。そこでいくらでも粘着つき合ってやる。
～的は使った人から聞いての俺なりの印象。
クリケットは英国的
これ聞いてスポーツの話してんのに国の話して狂ってるとか言ってるのがお前。イメージ伝わらなかったらそれでいいんでスルーしろよ。
それ以上やりたいならURL指定してくれ。そこでいくらでも粘着つき合ってやる。
>>849
それどういうイメージ？
それどういうイメージ？
得られた答えが使ったことない人の先入観だけとは・・
cakeとsymfony両方使った人いないのですか？
早く答えろよ、ミクロちんぽ男どもが。
cakeとsymfony両方使った人いないのですか？
早く答えろよ、ミクロちんぽ男どもが。
yiiフォーラム、日本だけ書き込みないってのもなんか寂しいなｗ
きっと日本人はみんな英語のフォーラムで十分なんだよ！
と言ってみる。
と言ってみる。
yiiを試用したみたいなページが日本語であったので、参考に少し触ってみた。
viewファイルの拡張子が .php 決め打ちに見えるorz
CController.phpにハードコードしてるように見えるんだが、どこかで変えられるのかな・・・
ってのを、誰か英語で質問よろしく。
viewファイルの拡張子が .php 決め打ちに見えるorz
CController.phpにハードコードしてるように見えるんだが、どこかで変えられるのかな・・・
ってのを、誰か英語で質問よろしく。
>>856
ねらーっぽい記述なら多分それ
ねらーっぽい記述なら多分それ
なんだこの無茶振りしときながら上から目線
被害妄想？
'urlFormat'=>'path'指定したら
～hogehoge/index.php/hagehage～
みたいにはできるけど、このindex.phpもどうせなら表示しないようにしたいな
英語超苦手だけどちょっとドキュメントとにらめっこしてみるか…
～hogehoge/index.php/hagehage～
みたいにはできるけど、このindex.phpもどうせなら表示しないようにしたいな
英語超苦手だけどちょっとドキュメントとにらめっこしてみるか…
>>861
それはpathinfoみてやってるんだろうね。
mod_rewriteなんかを使わないと、実行スクリプトの省略はたぶん無理。
mod_rewriteでいいなら、railsでもcakeでもZFでも何でもいいから.htaccessをパクってくればおｋ。
フロントコントローラ置いてるフレームワークなら大概同じ。
それはpathinfoみてやってるんだろうね。
mod_rewriteなんかを使わないと、実行スクリプトの省略はたぶん無理。
mod_rewriteでいいなら、railsでもcakeでもZFでも何でもいいから.htaccessをパクってくればおｋ。
フロントコントローラ置いてるフレームワークなら大概同じ。
>>862
rewrite前提なのは理解してます
直接アンカータグ書いてURI決めうちしとけば問題ないんですが
たとえば、(略) array('label'=>'Home', 'url'=>array('site/index')), (ry)
て感じに指定してURL吐かせると /appname/index.php/site/index
といった絶対パスになるんすよ(urlFormat=>path設定しておいた場合)
なんで、これを相対( ./site/index ) とかで吐かせれないかなーと思いまして
rewrite前提なのは理解してます
直接アンカータグ書いてURI決めうちしとけば問題ないんですが
たとえば、(略) array('label'=>'Home', 'url'=>array('site/index')), (ry)
て感じに指定してURL吐かせると /appname/index.php/site/index
といった絶対パスになるんすよ(urlFormat=>path設定しておいた場合)
なんで、これを相対( ./site/index ) とかで吐かせれないかなーと思いまして
関係ないけど、そのURLの仕組みで相対は厳しくない？
/hoge/page の絶対指定が定番だと思ってた。てかデザイナにもそう頼んでるｗ
/hoge/page の絶対指定が定番だと思ってた。てかデザイナにもそう頼んでるｗ
そうでした。勘違いしてました
>>861
CUrlManager#showScriptName
CUrlManager#showScriptName
868 ：nobodyさん：2008/12/16(火) 10:35:42 ID:tHoVMtEc
hoge.com/poge/categoryId/100
って感じのPATHINFO的パスって、一時期はSEO的な意味もあったかもしれないが
今となっては何の意味もなくね？
むしろ今となっては非本質的で気持ち悪い気ｶﾞｽ
って感じのPATHINFO的パスって、一時期はSEO的な意味もあったかもしれないが
今となっては何の意味もなくね？
むしろ今となっては非本質的で気持ち悪い気ｶﾞｽ
俺も前からそう思ってた。
結局は&や?を/に置き換えてるだけだもんな。
グーグルとかのクローラーは知らんけど、人間が読む分には、すなおにindex.cgi?name=foo&passwd=barとやった方がわかりやすいよな。
結局は&や?を/に置き換えてるだけだもんな。
グーグルとかのクローラーは知らんけど、人間が読む分には、すなおにindex.cgi?name=foo&passwd=barとやった方がわかりやすいよな。
あ、ただ、フロントコントローラーを採用してて、アクションクラス名を指定する場合は、スラッシュ区切りの部分に含めた方がいいと思う。クエリパラメーター部分は?以降でいいと思うが。
<a href="../">上のカテゴリへ</a>
とかできて便利じゃないか。
<a href="./">やりなおし</a>
とかも、パラメタが全部引っ付いてきてお得じゃないか。
とかできて便利じゃないか。
<a href="./">やりなおし</a>
とかも、パラメタが全部引っ付いてきてお得じゃないか。
>>872
俺はPATH_INFO賛成派だが、
http://.../user/yamada/pass/word/sex/male
みたいなパラメタ付けは好きじゃない。
http://...../map/pref/12/
で、"../13/"で隣の県が参照できたり、"../"で都道府県一覧が
表示されるのが美しいと思う。
俺はPATH_INFO賛成派だが、
http://.../user/yamada/pass/word/sex/male
みたいなパラメタ付けは好きじゃない。
http://...../map/pref/12/
で、"../13/"で隣の県が参照できたり、"../"で都道府県一覧が
表示されるのが美しいと思う。
順序が固定されちゃうのが好かんな
>>875
そうそう。代弁ありがとう。
そうそう。代弁ありがとう。
>>869
ndex.cgi?name=foo&passwd=baが読みやすいというのは
プログラマー的な視点だと思う。
しかもpasswd筒抜けやんｗ
初心者は
hoge.com/poge/categoryId/100
で区切られてる方がわかりやすい
ndex.cgi?name=foo&passwd=baが読みやすいというのは
プログラマー的な視点だと思う。
しかもpasswd筒抜けやんｗ
初心者は
hoge.com/poge/categoryId/100
で区切られてる方がわかりやすい
グーグル様が(=^_^=) をよく拾うなら
俺は迷わずＵＲＬに(=^_^=) を使う
hoge.com(=^_^=) poge(=^_^=) categoryId(=^_^=) 100
ＵＲＬ形式はまさにグーグル様次第だ
俺は迷わずＵＲＬに(=^_^=) を使う
hoge.com(=^_^=) poge(=^_^=) categoryId(=^_^=) 100
ＵＲＬ形式はまさにグーグル様次第だ
google様的には、pathinfoとクエリで差はないんじゃね？
一度根付いた最適化をやめるのは
根拠となるデータがないとまず無理
根拠となるデータがないとまず無理
少しでもページランクが上がるなら
顔文字でも何でも使うよ
まずクエリでも差がないという信用できるデータが欲しい
顔文字でも何でも使うよ
まずクエリでも差がないという信用できるデータが欲しい
具体的には分からないが、
yahoo等の大手サイトでは、
めっきり「必然性のないpathinfo形式」を見なくなった気がする
yahoo等の大手サイトでは、
めっきり「必然性のないpathinfo形式」を見なくなった気がする
yahooはどちらかといえばページを収集する主役の方だから
yahooのＵＲＬはＳＥＯのお手本というより
自社都合のＵＲＬ形式にしてるんじゃないかな
yahooのＵＲＬはＳＥＯのお手本というより
自社都合のＵＲＬ形式にしてるんじゃないかな
コントローラとアクションはセパレータじゃないと嫌だ。
ディレクトリと同じで、コントローラの中にアクションがあるっていう
入れ子関係なんだし。
ドメイン/大枠/小枠/パラメータって決まってた方が綺麗じゃん。
ユーザが、URIを削ったりした時に、indexでカテゴリーの目次に飛んだり出来るじゃん。
クエリに&使う場合って、w3cのストリクトな文法ではHTML内でリンク書く時でも
HTML2.0の頃から、本当は&って書かなきゃいけない事になってるんだぜ。
ディレクトリと同じで、コントローラの中にアクションがあるっていう
入れ子関係なんだし。
ドメイン/大枠/小枠/パラメータって決まってた方が綺麗じゃん。
ユーザが、URIを削ったりした時に、indexでカテゴリーの目次に飛んだり出来るじゃん。
クエリに&使う場合って、w3cのストリクトな文法ではHTML内でリンク書く時でも
HTML2.0の頃から、本当は&って書かなきゃいけない事になってるんだぜ。
変換されちゃった。
下の&は＆amp;な。
下の&は＆amp;な。
>>877
> >>869
> ndex.cgi?name=foo&passwd=baが読みやすいというのは
> プログラマー的な視点だと思う。
> しかもpasswd筒抜けやんｗ
> 初心者は
> hoge.com/poge/categoryId/100
> で区切られてる方がわかりやすい
name=fooなら、nameとfooが対応してるのが誰でも分かるだろう。&ってANDが文章をつなぐ単語って小学生でも知ってる。
/で区切るとどこまでがURLでどこからがクエリパラメータか分からない。
http://example.com/news/name/10で、nameがアクションクラス名なのかクエリパラメータのキー名なのか、誰にも分からない。
> >>869
> ndex.cgi?name=foo&passwd=baが読みやすいというのは
> プログラマー的な視点だと思う。
> しかもpasswd筒抜けやんｗ
> 初心者は
> hoge.com/poge/categoryId/100
> で区切られてる方がわかりやすい
name=fooなら、nameとfooが対応してるのが誰でも分かるだろう。&ってANDが文章をつなぐ単語って小学生でも知ってる。
/で区切るとどこまでがURLでどこからがクエリパラメータか分からない。
http://example.com/news/name/10で、nameがアクションクラス名なのかクエリパラメータのキー名なのか、誰にも分からない。
まあ、ちっちゃな利点を上げてみると、
http://example.com/news/name/10.html というURLだったとして、
動的に出力されているのか静的に置かれているのかも誰にもわからない。
そしてそれは、いずれ静的なファイルに置き換えてもリンクを変更する必要がない。
こういう事をいうと You Aren't Gonna Need It とか言われるのかも知れないけど、あくまで一利点として。
http://example.com/news/name/10.html というURLだったとして、
動的に出力されているのか静的に置かれているのかも誰にもわからない。
そしてそれは、いずれ静的なファイルに置き換えてもリンクを変更する必要がない。
こういう事をいうと You Aren't Gonna Need It とか言われるのかも知れないけど、あくまで一利点として。
>>886
＞name=fooなら、nameとfooが対応してるのが誰でも分かるだろう
おまえがプログラマだからだろ？
初めてＰＣさわったとき、ＵＲＬの意味が全く不明でした
ＵＲＬつかってデータ飛ばしてるということ知らなかったし
だからＵＲＬは/区切りの方が単純明快でわかりやすい
わかりやすいといっても素人的観点からのわかりやすいという意味だよ
nameがわからないとかはプログラマ視点やろ
＞name=fooなら、nameとfooが対応してるのが誰でも分かるだろう
おまえがプログラマだからだろ？
初めてＰＣさわったとき、ＵＲＬの意味が全く不明でした
ＵＲＬつかってデータ飛ばしてるということ知らなかったし
だからＵＲＬは/区切りの方が単純明快でわかりやすい
わかりやすいといっても素人的観点からのわかりやすいという意味だよ
nameがわからないとかはプログラマ視点やろ
クエリは小さいサイトならわかるかもしれんけど
yahooとかのクエリて
どんだけパラメータはいってんねん、
これ何の変数なん？てくらい
長いで
あそこまで長いパラメータなら区切てのクエリでも
変わらんわな。ロボットも長いＵＲＬ拾わんやろうし
yahooとかのクエリて
どんだけパラメータはいってんねん、
これ何の変数なん？てくらい
長いで
あそこまで長いパラメータなら区切てのクエリでも
変わらんわな。ロボットも長いＵＲＬ拾わんやろうし
残念ながらそれはお前が低脳なだけだ
本来ディレクトリを示す記号をほかの事に使ってるというのがまず気持ち悪い
いっこ削って上の階層にいけないようならスラッシュ区切りにする意味ないとおもうわー
いっこ削って上の階層にいけないようならスラッシュ区切りにする意味ないとおもうわー
普通にウェブをみる分にはURLなんて意識する必要ないんだよ。リンクをクリックするだけ、ブックマークするだけなんだから、URLを見る必要はない。
携帯のブラウザなんかだと、URLが確認出来なかったりするぐらいだから。
あえてURLを見ようと思った時に、/区切りでパラメータとURLが一体になってる方がわかりやすいか、パラメータがハッキリ区別されてる方がわかりやすいか。当然、後者。
/区切りが有効なのは、昔のSEO対策ぐらいなもの。それ以外は開発者の自己満足。
携帯のブラウザなんかだと、URLが確認出来なかったりするぐらいだから。
あえてURLを見ようと思った時に、/区切りでパラメータとURLが一体になってる方がわかりやすいか、パラメータがハッキリ区別されてる方がわかりやすいか。当然、後者。
/区切りが有効なのは、昔のSEO対策ぐらいなもの。それ以外は開発者の自己満足。
でも wikipedia.org/WebProg が wikipedia.org/index.cgi?q=WebProg だったら面倒だろ。要は使いどこ
パラメータが多いときは普通両方合わせて使うだろ
>>886
URLで何を表してるか、なんじゃないかなぁ。。
そこで出てるニュースの例なら
news.php&year=2009&mon=12&day=17
よりも
news/2009/12/17
のほうが、意味あいとして分かりやすいと思うけど。
URLで何を表してるか、なんじゃないかなぁ。。
そこで出てるニュースの例なら
news.php&year=2009&mon=12&day=17
よりも
news/2009/12/17
のほうが、意味あいとして分かりやすいと思うけど。
別に http://example.com/news.cgi?2008&12&18 ってやったっていい。
URL本体とクエリストリングは本来機能が違う物なのに、わざわざごちゃ混ぜにしてるところに問題がある。
しかも、mod_rewriteに頼らないと行けない。
画面とURLのマッピング表を参照しなければ、クエリストリングが取り出せなくなるのは、開発性の低下。
手間がかかるくせにメリットが少ないから、/区切りにするのはくだらないと思う。
URL本体とクエリストリングは本来機能が違う物なのに、わざわざごちゃ混ぜにしてるところに問題がある。
しかも、mod_rewriteに頼らないと行けない。
画面とURLのマッピング表を参照しなければ、クエリストリングが取り出せなくなるのは、開発性の低下。
手間がかかるくせにメリットが少ないから、/区切りにするのはくだらないと思う。
> しかも、mod_rewriteに頼らないと行けない。
そんなことはない
そんなことはない
どうやるわけ？
問題は、要素によってpathinfoとクエリを使い分けたいのに、
ヘルパを通すと一括してpathinfoにされることではないか。
ヘルパを通すと一括してpathinfoにされることではないか。
PATH_INFOだな。
例えばnucleusのfancyモードもmod_rewirte使ってない。
例えばnucleusのfancyモードもmod_rewirte使ってない。
もう好みの問題だな
それだとApacheに別の設定を加えないと行けないじゃん。
俺も好みだと思うよ。けど、記号が少ない分、見た目が良いぐらいしかメリットないじゃん。後はどこまで効果があるか分からないSEO対策か。
開発効率落としてまでやる事じゃないと思うけど、それがこだわりだって言われれば、そりゃ勝手ではあると思う。
開発効率落としてまでやる事じゃないと思うけど、それがこだわりだって言われれば、そりゃ勝手ではあると思う。
>>902
.htaccessで済む。まぁ許可されていればの話しだが。
> 画面とURLのマッピング表を参照しなければ、クエリストリングが取り出せなくなるのは、開発性の低下。
フレームワーク使っているのなら、わざわざクエリストリングを直接弄るようなことはないだろうに。
>>901に同意。俺は/区切りの方がスッキリする。
.htaccessで済む。まぁ許可されていればの話しだが。
> 画面とURLのマッピング表を参照しなければ、クエリストリングが取り出せなくなるのは、開発性の低下。
フレームワーク使っているのなら、わざわざクエリストリングを直接弄るようなことはないだろうに。
>>901に同意。俺は/区切りの方がスッキリする。
意味のない区切り出なければ/で区切るのが自分の中での最適解
画像のサムネイルをキャッシュする場合は/区切りだとフェイクできるな
画像加工済みであれば、ファイルが存在するからそれを返して
まだであれば、加工して保存後それを返すって感じで
画像加工済みであれば、ファイルが存在するからそれを返して
まだであれば、加工して保存後それを返すって感じで
mod_rewriteだって、.htaccessで出来るだろ。
例えばhttp://example.com/news/2008/12/18だって、年月日の順で引数が渡されることを把握してなければいけない。
こんなのすごくくだらない。
func(2008,12,18)ってプロトタイプよりfunc(array(year=>2008,mon=>12,day=>18))の方がメンテナンス性の高いプロトタイプだよ。
例えばhttp://example.com/news/2008/12/18だって、年月日の順で引数が渡されることを把握してなければいけない。
こんなのすごくくだらない。
func(2008,12,18)ってプロトタイプよりfunc(array(year=>2008,mon=>12,day=>18))の方がメンテナンス性の高いプロトタイプだよ。
symfonyだと名前を付けられるよ
順番変更になってもルーティング弄れば全部反映されるし
ただパフォーマンス的にコストがちょっとかかるけど
順番変更になってもルーティング弄れば全部反映されるし
ただパフォーマンス的にコストがちょっとかかるけど
>>907
いや、>>904では、「mod_rewrite必須。でなければ、Apache別設定必要」という意見に答えたまで。
> こんなのすごくくだらない。
だからくだらないかどうかは好みの問題でいいんじゃね。
メンテナンス性も大事なのはわかるが、糖衣構文と同じで慣れもあるし。
いや、>>904では、「mod_rewrite必須。でなければ、Apache別設定必要」という意見に答えたまで。
> こんなのすごくくだらない。
だからくだらないかどうかは好みの問題でいいんじゃね。
メンテナンス性も大事なのはわかるが、糖衣構文と同じで慣れもあるし。
>>896
うーん。。そういうのが>>877が言ってる
プログラマ的視点ってことじゃないかなぁ。。
URLは場所やリソースを表すって意味じゃ
階層的にで表現できるものは/区切りがキレイな感じがする。
year=2008&month=12&day=18
ならまだしも
month=12&year=2008&day=18
って、なんか気持ち悪くない？
RESTにちょっと興味あるからかも知れんけどｗ
うーん。。そういうのが>>877が言ってる
プログラマ的視点ってことじゃないかなぁ。。
URLは場所やリソースを表すって意味じゃ
階層的にで表現できるものは/区切りがキレイな感じがする。
year=2008&month=12&day=18
ならまだしも
month=12&year=2008&day=18
って、なんか気持ち悪くない？
RESTにちょっと興味あるからかも知れんけどｗ
ようやくrestという単語が
ここでクエリクエリ言ってる人はrestを一通り勉強した上で言っているのかどうか気になる
一昔前の感覚から抜けきれないプログラマさんとしか思えない
ここでクエリクエリ言ってる人はrestを一通り勉強した上で言っているのかどうか気になる
一昔前の感覚から抜けきれないプログラマさんとしか思えない
>>910
それはRESTと全く関係ないでしょう
>>911
RESTだからpathinfoってのは違うよ。
RESTだってquerystringで基本処理することは問題ない。
なにか、910も911もRESTをちゃんと勉強してから、有意義なコメントを求む。
それはRESTと全く関係ないでしょう
>>911
RESTだからpathinfoってのは違うよ。
RESTだってquerystringで基本処理することは問題ない。
なにか、910も911もRESTをちゃんと勉強してから、有意義なコメントを求む。
以下、RESTバスワード問題についてに議論が移ります。
てか、本当に話題なんでもいいのなｗ
てか、本当に話題なんでもいいのなｗ
ZFって速いん？
低機能だから速そうではあるけど
低機能だから速そうではあるけど
RESTfulにするなら、階層構造を使うべきところは階層を、
そうでないところはクエリ文字列をつかうべきだよね。
なんかお前ら、どっちかしか使わないみたいな二元論にハマってないか？
使い分けてナンボでしょこういうのは。
http://.../news/08/12/18?query=money
なんて分かりやすいじゃないか。
そうでないところはクエリ文字列をつかうべきだよね。
なんかお前ら、どっちかしか使わないみたいな二元論にハマってないか？
使い分けてナンボでしょこういうのは。
http://.../news/08/12/18?query=money
なんて分かりやすいじゃないか。
大体、
・ステートレス
・PUT、DELETEを使え
って時点で、RESTfulにこだわってたらWEB APIは作れても普通のWEBアプリは無理だろ。
大体、RESTって認証はどうするんだ？ステートレスってぶっちゃけGET以外は非現実的じゃないの？
参考にするのはいいが、どうせRESTfulにはならないんだし、URLも違う視点でいいよね。
・ステートレス
・PUT、DELETEを使え
って時点で、RESTfulにこだわってたらWEB APIは作れても普通のWEBアプリは無理だろ。
大体、RESTって認証はどうするんだ？ステートレスってぶっちゃけGET以外は非現実的じゃないの？
参考にするのはいいが、どうせRESTfulにはならないんだし、URLも違う視点でいいよね。
http://sourceforge.jp/magazine/08/12/08/0347234
最適化したブートストラップファイル「Yiilite」を利用時、1秒当たり最大427のクエリを処理できるという。
サーバのスペックも書かずにこの数字って
何か意味あんのか？？？
最適化したブートストラップファイル「Yiilite」を利用時、1秒当たり最大427のクエリを処理できるという。
サーバのスペックも書かずにこの数字って
何か意味あんのか？？？
>>918
RoRのRESTは
PUT・DELETE → JavaScriptで疑似リンク作成（POSTだけどhiddenでメソッド種別埋め込み、サーバ側で処理）
ステートレス → 棚上げ？
フレームワークレベルで頑張ってるみたいね。
そこまでやるんならURL（URI）も頑張ってRESTfulにすればいいんじゃね？
↓こんなのもあったｗ
http://www.nicovideo.jp/watch/sm3823700
RoRのRESTは
PUT・DELETE → JavaScriptで疑似リンク作成（POSTだけどhiddenでメソッド種別埋め込み、サーバ側で処理）
ステートレス → 棚上げ？
フレームワークレベルで頑張ってるみたいね。
そこまでやるんならURL（URI）も頑張ってRESTfulにすればいいんじゃね？
↓こんなのもあったｗ
http://www.nicovideo.jp/watch/sm3823700
CRUDと混同してたorz
>>910
海外じゃじゃ12/18/2008って日付表記もメジャーだよ。12や18が何を意味するのか、コードの中を見ないと判断つかない。
海外じゃじゃ12/18/2008って日付表記もメジャーだよ。12や18が何を意味するのか、コードの中を見ないと判断つかない。
でもURLでその順で表記することはまずありえないよなｗ
2008年のなかの12月のなかの18日～みたいに書かないと階層化になんないし
2008年のなかの12月のなかの18日～みたいに書かないと階層化になんないし
yiiってpdoベースだけど、pdoって何かバグあったよね？
925 ：nobodyさん：2008/12/18(木) 21:13:55 ID:aX375k2z
ないよ
あったよ
なんだっけ
ほら、あれだ
タグ理解ｗｗｗ
pdo 不具合 に一致する日本語のページ 約 8,080
何この糞ライブラリ
何この糞ライブラリ
ここは呆け老人の巣か？ｗ
てのはいいとして、>>930
GoogleかYahooか知らんが、
PDO 不具合 (7,850) / PDO (346,000) ・・・ 2.27%
PEAR DB 不具合 (9,470) / PEAR DB (115,000) ・・・ 8.23%
PEAR MDB2 不具合 (3,440) / PEAR MDB2 (45,000) ・・・ 7.64%
JDBC 不具合 (39,700) / JDBC (161,000) ・・・ 24.65%
ODBC 不具合 (37,400) / ODBC (411,000) ・・・ 9.10%
（上記全てGoogle 日本語ページ）
むしろ優秀じゃね？そうでなくても、ただ単に普及率や話題性が数字で出てるだけじゃねーかと。
JDBCがなんか笑えるけどなｗｗ
てのはいいとして、>>930
GoogleかYahooか知らんが、
PDO 不具合 (7,850) / PDO (346,000) ・・・ 2.27%
PEAR DB 不具合 (9,470) / PEAR DB (115,000) ・・・ 8.23%
PEAR MDB2 不具合 (3,440) / PEAR MDB2 (45,000) ・・・ 7.64%
JDBC 不具合 (39,700) / JDBC (161,000) ・・・ 24.65%
ODBC 不具合 (37,400) / ODBC (411,000) ・・・ 9.10%
（上記全てGoogle 日本語ページ）
むしろ優秀じゃね？そうでなくても、ただ単に普及率や話題性が数字で出てるだけじゃねーかと。
JDBCがなんか笑えるけどなｗｗ
まぁ、不具合の話題にPDOその他の話題が含まれてる、みたいな
全く関係ないヤツが殆どなんだけどな
全く関係ないヤツが殆どなんだけどな
まぁ確かに不具合もあるだろうよ。
今度PHPとSQL Serverなんだが、PDO_DBLIBの完成度とか微妙そうだ。
今からgkbrだ。
今度PHPとSQL Serverなんだが、PDO_DBLIBの完成度とか微妙そうだ。
今からgkbrだ。
クエリて基本的にＰＯＳＴで飛ばしたときのパラメータデータと認識してるのだが。。。
ＧＥＴで飛ばした場合はクエリとはいわない
ＧＥＴで飛ばした場合はクエリとはいわない
何その思い込み
これはまた斬新な説だな
俺の場合はソケットプログラミング的発想だからな
なんだか俺の間違いくさいからクエリの話はもう終わりにしよう
アクセス解析の効率はURL決定に影響しないのじゃろか
確かに、クエリパラメータが順不同になる様な状態なら、アクセス解析の効率は落ちそうだねえ。
でもそれが設計にそれほどの影響を与えるかどうかは・・・正直そこまで気にしてらんねｗとか
でもそれが設計にそれほどの影響を与えるかどうかは・・・正直そこまで気にしてらんねｗとか
順不同だと効率が落ちる？頭イカれてるのですか
Apacheのログ解析みたいな処理の場合、頭から順にパス区切りでページが特定できる方が、
効率よさそうな気はするが。
list.php?q=hoge&page=2&cate=3とかなってるより、
list/cate/3?page=2&q=hoge の方が楽そうだなーとかは感じる。
実際はどうかわからんけどな。
効率よさそうな気はするが。
list.php?q=hoge&page=2&cate=3とかなってるより、
list/cate/3?page=2&q=hoge の方が楽そうだなーとかは感じる。
実際はどうかわからんけどな。
気がする（笑）
symfony以外のカスFWってエラー時のスタックトレース画面がショボいよねｗ
>>946
それは>945見たい書き込みのことか？
それは>945見たい書き込みのことか？
948 ：nobodyさん：2008/12/20(土) 18:52:04 ID:VXNsKNQ0
アクセス解析くらい自作しろよ。効率化とかしょぼい解析つかってるのかな
>>948
車輪の再発明
車輪の再発明
自作(笑)
アクセス解析を作るとしたら、
Google Analyticsでは対応できなくなったときだな。
アクセス数が少ないやつがアクセス解析を作ると
一人ひとりのアクセスしたページの履歴を見れるとか
わけのわからない機能を作りそうｗ
Google Analyticsでは対応できなくなったときだな。
アクセス数が少ないやつがアクセス解析を作ると
一人ひとりのアクセスしたページの履歴を見れるとか
わけのわからない機能を作りそうｗ
アクセス解析ですが、自分のサイト内を移動するユーザーの様子は、
リファラー情報をDBに保存して集計していますか？
リファラー情報をDBに保存して集計していますか？
GoogleでiGoogleアカウント作ると検索履歴をすべて保存される。
しかも頑張らないと消せないぜ。
しかも頑張らないと消せないぜ。
IPアドレスごとの検索履歴なら
昔から永久保存してるよ
昔から永久保存してるよ
955 ：nobodyさん：2008/12/21(日) 22:53:57 ID:V1c8MsfO
アクセス解析自作とかどんだけ
cgi?password=
コードが全てを物語ってるじゃないか。
相手にする価値無いだろ。
コードが全てを物語ってるじゃないか。
相手にする価値無いだろ。
>>956
何の話?
何の話?
どこがフレームワークの話？
959 ：nobodyさん：2008/12/22(月) 06:22:15 ID:UnYE/VzJ
CakePHPのアソシエーションでInner Joinを利用してレスポンス速度を向上
http://blog.katsuma.tv/2008/12/inner_join_on_cakephp.html
インナージョインとレフトジョインて別物だし、
簡単にテレコにできるもんじゃないよね？
これってどういうことなん？
http://blog.katsuma.tv/2008/12/inner_join_on_cakephp.html
インナージョインとレフトジョインて別物だし、
簡単にテレコにできるもんじゃないよね？
これってどういうことなん？
ってかレフトジョインてそんなに遅くなるの？
今作成してるサイト、テーブルいくつもレフトジョインしてるんだが・・・
今作成してるサイト、テーブルいくつもレフトジョインしてるんだが・・・
そんなもんRDMS依存だろ。
程度の違いはあれ、LEFT の方が遅い。
それより、CakeのモデルでINNERにできるところをLEFTにしてるとしたら
（たぶんそういうことなんだろうけど）ちょいとお粗末すぎる希ガス
それより、CakeのモデルでINNERにできるところをLEFTにしてるとしたら
（たぶんそういうことなんだろうけど）ちょいとお粗末すぎる希ガス
レフトジョイン→インナージョインにして問題ないのって
接続対象が0にならない場合だけでしょ
タグっぽいの駄目だし使いどころなさそう
接続対象が0にならない場合だけでしょ
タグっぽいの駄目だし使いどころなさそう
ナルホド
解析プログラムはアーチンで
１日で3Gくらいのログファイルを想定してた
ディレクトリ毎にアクセス状況を表示出来るので、そちらのがディレクション側にも理解し易いかなとか
GETで渡ったパラメータも項目別に出るけど、ページ検索だか訳判らん表現に
まぁ機能以外のつまらん理由で仕様が決まる事もあるねー
以上の話題にならんかったな
１日で3Gくらいのログファイルを想定してた
ディレクトリ毎にアクセス状況を表示出来るので、そちらのがディレクション側にも理解し易いかなとか
GETで渡ったパラメータも項目別に出るけど、ページ検索だか訳判らん表現に
まぁ機能以外のつまらん理由で仕様が決まる事もあるねー
以上の話題にならんかったな
スレチかもだけど、流れ乗じて聞いてみる。
LEFT JOINの方が遅いとか、その辺の知識が弱くて困ってるんだけど、
その辺を学ぶのにいい情報源ないですか？
CRUDなSQLは一通りかけるけど、JOINなんかは解説サイトを鵜呑みにして、
とりあえず出来てるレベル。
もうちょっとしっかりとした知識を身につけたいところ。
LEFT JOINの方が遅いとか、その辺の知識が弱くて困ってるんだけど、
その辺を学ぶのにいい情報源ないですか？
CRUDなSQLは一通りかけるけど、JOINなんかは解説サイトを鵜呑みにして、
とりあえず出来てるレベル。
もうちょっとしっかりとした知識を身につけたいところ。
>>968
LEFT JOINの方が遅いという一般的な事象については、RDBMSの内部動作の基本を
理解していれば、自明。RDBMSの基礎理論を扱ったドキュメントになら書いてあるでしょう。
RDBMSのドキュメントに結合の最適化やINDEXの使われ方、処理フローに
ついて書いてあることもある。そこは運だな。
LEFT JOINの方が遅いという一般的な事象については、RDBMSの内部動作の基本を
理解していれば、自明。RDBMSの基礎理論を扱ったドキュメントになら書いてあるでしょう。
RDBMSのドキュメントに結合の最適化やINDEXの使われ方、処理フローに
ついて書いてあることもある。そこは運だな。
>>969
難しいな。
難しいな。
あえてお勧めの書籍やどのRDBMSのドキュメントかなどを記さないスパルタな>>969
うーん、答えるのも難しいね
ttp://www.inter-office.co.jp/contents/157/
たとえば、ここにベンチ出てるんだけど、前のアイテムでLEFT JOINして性能が1/3になってるという話。
ただ、これは一般的に1/3になるというのではなく、LEFT JOINするときにどのくらいNullになるレコード
があるかによって速度は全然違うから、完全な比較はできない。
そもそも、使い路の違うものを速度比較っていう考え方自体がないんだよね。
ttp://www.inter-office.co.jp/contents/157/
たとえば、ここにベンチ出てるんだけど、前のアイテムでLEFT JOINして性能が1/3になってるという話。
ただ、これは一般的に1/3になるというのではなく、LEFT JOINするときにどのくらいNullになるレコード
があるかによって速度は全然違うから、完全な比較はできない。
そもそも、使い路の違うものを速度比較っていう考え方自体がないんだよね。
そりゃ1枚のテーブルに入ってる方が早いだろうけど、メンテナンス性が悪くなるじゃん。1日何百万PVもあるようなサイトなら、別の考え方もあるんだろうけどな。
１枚のテーブル？
あんまり関係ない希ガス
あんまり関係ない希ガス
>>973
1枚のテーブルを分割したいんならＩＤ振ってINNER JOINすればいいじゃん。
1枚のテーブルを分割したいんならＩＤ振ってINNER JOINすればいいじゃん。
大規模なウェブサイトは極力ジョイン使うなってよく紹介されてるだろ。ジョインそのものの話。
大規模サイトでも、テーブルを非正規化するのはほどほどにしておいて、
なんでもかんでもコンテンツはキャッシュにぶちこんで、
検索が必要な場合は専用のインデックスにでも(RDBMSじゃなく、いやRDBMSでもいいけd)放りこめ!って
やりかたがイマドキはアレな気がする。
チューンしたSQLは一発書いたら使いまわしのできないコードだし、
コンテンツキャッシュがちゃんとしてれば大方はそっちの方が数字は速いし、
フレームワークなんかにも組み込みやすいし、なのでまぁそういう流れなんだと思う。
大規模サイトっつってもいろいろあるだろうけどさ。
なんでもかんでもコンテンツはキャッシュにぶちこんで、
検索が必要な場合は専用のインデックスにでも(RDBMSじゃなく、いやRDBMSでもいいけd)放りこめ!って
やりかたがイマドキはアレな気がする。
チューンしたSQLは一発書いたら使いまわしのできないコードだし、
コンテンツキャッシュがちゃんとしてれば大方はそっちの方が数字は速いし、
フレームワークなんかにも組み込みやすいし、なのでまぁそういう流れなんだと思う。
大規模サイトっつってもいろいろあるだろうけどさ。
> やりかたがイマドキはアレな気がする。
アレってなに
アレってなに
INNER JOIN談義に花が咲く…LEFT JOINを多用していたので参考になります。＾＾
そもそも、INNER JOIN と LEFT JOIN は意味が違う。
>>976
> 大規模なウェブサイトは極力ジョイン使うなってよく紹介されてるだろ。ジョインそのものの話。
知識では知っていたが、最近実感した。
JOINにかかる速度というより、
一般的にSQLを実行したとき、条件やソート処理も一緒に行う。
条件やソートにインデックスがうまく使われれば速いが、
そうでない場合大幅に速度が遅くなる。
インデックスはRDMSによるが、一つのSQLで一回しか使われなかったりと
使われない場合がある。
JOINが絡むと結果的に複雑なSQLになり、インデックスをうまく使うのが難しい。
だからJOINを使った複雑なSQLを書くのではなくインデックスを使った
単純なSQLを複数回発行するほうが良い。
> 大規模なウェブサイトは極力ジョイン使うなってよく紹介されてるだろ。ジョインそのものの話。
知識では知っていたが、最近実感した。
JOINにかかる速度というより、
一般的にSQLを実行したとき、条件やソート処理も一緒に行う。
条件やソートにインデックスがうまく使われれば速いが、
そうでない場合大幅に速度が遅くなる。
インデックスはRDMSによるが、一つのSQLで一回しか使われなかったりと
使われない場合がある。
JOINが絡むと結果的に複雑なSQLになり、インデックスをうまく使うのが難しい。
だからJOINを使った複雑なSQLを書くのではなくインデックスを使った
単純なSQLを複数回発行するほうが良い。
そりゃjoinしないで済むならしないけど仕方ないじゃん
1対多とか多対多を一つのテーブルでやるなんて無理ぽ
1対多とか多対多を一つのテーブルでやるなんて無理ぽ
>>959
UserとProfileが一対一の関係で
しかも、
Userレコードに対応するProfileレコードが必ず存在する
という前提でないとINNER JOINは使えないと思う。
Userテーブルにたくさんデータがあって、Profileテーブルが空の場合、
$this->User->find('all');
としても、データが返ってこないことになる。
この場合CakePHPだとNULLになるのかな。
UserとProfileが一対一の関係で
しかも、
Userレコードに対応するProfileレコードが必ず存在する
という前提でないとINNER JOINは使えないと思う。
Userテーブルにたくさんデータがあって、Profileテーブルが空の場合、
$this->User->find('all');
としても、データが返ってこないことになる。
この場合CakePHPだとNULLになるのかな。
多対多は何も考えずにJOINで表現すると激重になるらしい
といって、インデックス？のシステムを利用してどう表現するのかよくわからない
うー頭が悪い
テーブル[A]： 1:太郎 2:花子 3:ジョニー
テーブル[B]： a:バナナ b:メロン c:マンゴー
テーブル[C]： 1-a, 1-b, 2-b, 2-c, 3-a, 3-c
こうすりゃJOINなんか使わなくていいんだぜ！ってのがあるのならだれか教えて下さい。
それとも、こんなのなら迷わずINNER JOINでいいのかな・・・
件数が少なけりゃ、例えばメロンが好きな人！ってので、テーブルCから名前キーを
取得して、テーブルAから IN (1, 2) とかでセレクトできるけど・・・そういうことするんでしょうか？
てか、PHPかDBの初心者スレいった方がいいかな；_；
といって、インデックス？のシステムを利用してどう表現するのかよくわからない
うー頭が悪い
テーブル[A]： 1:太郎 2:花子 3:ジョニー
テーブル[B]： a:バナナ b:メロン c:マンゴー
テーブル[C]： 1-a, 1-b, 2-b, 2-c, 3-a, 3-c
こうすりゃJOINなんか使わなくていいんだぜ！ってのがあるのならだれか教えて下さい。
それとも、こんなのなら迷わずINNER JOINでいいのかな・・・
件数が少なけりゃ、例えばメロンが好きな人！ってので、テーブルCから名前キーを
取得して、テーブルAから IN (1, 2) とかでセレクトできるけど・・・そういうことするんでしょうか？
てか、PHPかDBの初心者スレいった方がいいかな；_；
DBは切り離せない存在だけど
PHPに限ったことじゃないし、DB系のスレにいったほうが
多くの情報は集まるんじゃないかなって気はするねー
っと、そろそろ次スレだね
PHPに限ったことじゃないし、DB系のスレにいったほうが
多くの情報は集まるんじゃないかなって気はするねー
っと、そろそろ次スレだね
【PHP】フレームワークについて語るスレ12【総合】
http://pc11.2ch.net/test/read.cgi/php/1229960175/
http://pc11.2ch.net/test/read.cgi/php/1229960175/
>>976
Google App Engineはjoin禁止
Google App Engineはjoin禁止
>>985
JOINはしないほうがいいって言ったけど、
それはできるのならってことで、
JOINしたほうが自然な場合はしていいよ。
SQLパズルとでも言うべきな、
なんたらをgroup byした結果となんたらを結合して～なんて
ややこしいのはやめたほうが良いって話。
JOINはしないほうがいいって言ったけど、
それはできるのならってことで、
JOINしたほうが自然な場合はしていいよ。
SQLパズルとでも言うべきな、
なんたらをgroup byした結果となんたらを結合して～なんて
ややこしいのはやめたほうが良いって話。
ベンチが全てじゃね
（⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒
（ 俺の生活範囲って
Ο（ ベンチが全てじゃね
ο ～～～～～～～～～～～～～～～～～～
。
∧＿∧
＿＿＿／⌒（ｌ|ｌ･∀･）＿
/ | | ノ | |
| | | ／ |, | .|
＿＿| | | ＼ .| _|＿|
ヽ、（＿二二⌒)__）. ＼
＿＿＿_| | ＼二 ⌒l. ＼
| |￣￣ | |￣￣||
| | | | .||
| |_ | |_ .||
（＿＿） （＿＿） ||
（ 俺の生活範囲って
Ο（ ベンチが全てじゃね
ο ～～～～～～～～～～～～～～～～～～
。
∧＿∧
＿＿＿／⌒（ｌ|ｌ･∀･）＿
/ | | ノ | |
| | | ／ |, | .|
＿＿| | | ＼ .| _|＿|
ヽ、（＿二二⌒)__）. ＼
＿＿＿_| | ＼二 ⌒l. ＼
| |￣￣ | |￣￣||
| | | | .||
| |_ | |_ .||
（＿＿） （＿＿） ||
>>991
ダンボールもないのかよ(w
ダンボールもないのかよ(w
＼∧＿ﾍ ／￣￣￣￣￣￣￣￣￣￣￣￣
,,､,､,,, / ＼〇ノゝ∩ ＜ 1000取り合戦、いくぞｺﾞ……！！ ,,､,､,,,
/三√ ﾟДﾟ) / ＼＿＿＿＿＿＿＿＿＿＿＿＿ ,,､,､,,,
/三/| ﾟＵﾟ|＼ ,,､,､,,, ,,､,､,,,
,,､,､,,, Ｕ （:::::::::::） ,,､,､,,,
//三/|三|＼ ,,,, ,,､,､,,,
∪ ∪
,, , ,,,, ,,､,､,,, ,,､,､,,,
,,,,, ∧＿∧ うまいモナー,,,,, 、 ,,,,,, ,,,,,,,, ,,,,,
,,, （ ´∀｀）＿＿＿,,,,＿＿＿ ,, ∧＿∧ ｹﾞﾝｷﾆ ｼﾃﾙｶﾅ・・・＿＿＿,,
／￣ （ つ日ヽ ∧＿∧ （ ） ／
／ （＿＿）） （´∀｀ ） （ ） ∧＿∧∧＿∧ ／ マターリモナー
∧＿∧∧＿∧ドーゾ （日ノ ） ｜ ｜ | （ ´∀｀） ´∀｀）
（ ´∀｀） ´∀｀） (（＿＿） ,（＿（＿） （○）⊂ ） つ日⊂ ） モーナー
―（つ⊂ ） つ⊂ ）―――――――――――ヽ|〃(⌒)(⌒) (⌒)(⌒)
(⌒)(⌒) (⌒)(⌒)グーグー
,,､,､,,, / ＼〇ノゝ∩ ＜ 1000取り合戦、いくぞｺﾞ……！！ ,,､,､,,,
/三√ ﾟДﾟ) / ＼＿＿＿＿＿＿＿＿＿＿＿＿ ,,､,､,,,
/三/| ﾟＵﾟ|＼ ,,､,､,,, ,,､,､,,,
,,､,､,,, Ｕ （:::::::::::） ,,､,､,,,
//三/|三|＼ ,,,, ,,､,､,,,
∪ ∪
,, , ,,,, ,,､,､,,, ,,､,､,,,
,,,,, ∧＿∧ うまいモナー,,,,, 、 ,,,,,, ,,,,,,,, ,,,,,
,,, （ ´∀｀）＿＿＿,,,,＿＿＿ ,, ∧＿∧ ｹﾞﾝｷﾆ ｼﾃﾙｶﾅ・・・＿＿＿,,
／￣ （ つ日ヽ ∧＿∧ （ ） ／
／ （＿＿）） （´∀｀ ） （ ） ∧＿∧∧＿∧ ／ マターリモナー
∧＿∧∧＿∧ドーゾ （日ノ ） ｜ ｜ | （ ´∀｀） ´∀｀）
（ ´∀｀） ´∀｀） (（＿＿） ,（＿（＿） （○）⊂ ） つ日⊂ ） モーナー
―（つ⊂ ） つ⊂ ）―――――――――――ヽ|〃(⌒)(⌒) (⌒)(⌒)
(⌒)(⌒) (⌒)(⌒)グーグー
>>994
普通にベンチでぐぐって見つけたｗ
普通にベンチでぐぐって見つけたｗ
ume-
kono mikan
kono mikan
ふみだい
○|￣|＿ OTL on_ ｡,､ .
○|￣|＿ OTL on_ ｡,､ .
うめ
うめ
【PHP】フレームワークについて語るスレ12【総合】
http://pc11.2ch.net/test/read.cgi/php/1229960175/
http://pc11.2ch.net/test/read.cgi/php/1229960175/
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
もう書けないので、新しいスレッドを立ててくださいです。。。