頭の悪い言い争いする前にスレ立てとけ
既に実装されてしまった内容なんだから、使う使わないは案件なりで決めれ
不満があるなら開発途上の段階で割り込んでおけよと
仕様みてみたが、バックスラッシュは格好悪いけど、実装自体は普通のnamespaceじゃん
バックスラッシュは格好悪いけど、常に完全修飾名を要求されるとか、使い方知らないだけじゃ
再利用を考えたら、結局namespaceは必要だしな。バックスラッシュは格好悪いけど
ほんとバックスラッシュは格好悪いけどな
わざわざコード書く環境だけ正しいフォントに直すのも面倒だし
ﾊｲﾗｲﾄ
992 nobodyさん [sage] 2010/12/12(日) 03:24:51 ID:???
PHPの名前空間は、
http://www.php.net/manual/ja/language.namespaces.rationale.php Prefix付の長いクラス名を何とかする為のアプローチに見えるな。
実際には、使用時に絶対パスで記述しないとクラス名の衝突が起こる可能性があるので、
何も解決出来ていない(結局絶対パスで記述する必要がある)
情弱は使えばいいよ。
993 nobodyさん[sage] 2010/12/12(日) 03:46:35 ID:???
なんでこいつは名前空間とパスを同一視してるの？
こんなんだからPHP使いはレベルが低いとか言われるんだよ…
994 nobodyさん [sage] 2010/12/12(日) 03:49:53 ID:???
>>993 パス＝クラス名への絶対修飾子って意味ね。
Zend_Hoge_Moge と書くのも \Zned\Hoge\Moge と書くのも同じだし、
このように絶対パスで書かないとクラス衝突は防げない。
となると本来目標にかかげていた、冗長なクラス名の廃止はどうなったのかと･･･
明らかに設計ミスだろ。
995 nobodyさん [sage] 2010/12/12(日) 03:52:41 ID:???
？
その目的の為の名前空間でありそれは達成されてるわけだが？
5.2を切り捨てて対応してるフレームワークなりなんなりみてみろよ
綺麗に切り分けられクラス名は短くなってる
997 nobodyさん [sage] 2010/12/12(日) 04:00:46 ID:???
>>995 されてねーよ。
定義側は省略形で書けるかもしれんが、
実際に使用する側はフルパスで書かないといかんだろ。
打開策として use で別名エイリアスが付けられるが、
エイリアスが他クラスと被る可能性があるという本末転倒っぷり。
それならエイリアスなんか作らず
$className = 'Hoge\Moge\Class';
$class = new $className;
と書く方が利口。
どちらにせよ、当初の目的は果たせていない。
Zendが考えた擬似ネームスペースはもう捨てて
namespace + 新しい規約で
なんとかしろや。
既に有名なフレームワークはそうしてる
ぶっちゃけ今更感が半端無い
3年前の話題だろ…
＞既に有名なフレームワークはそうしてる
symfony2.0
ZendFramework2 も namespace採用されるよ。
ただsymfony2もだけど、PEAR命名規約のアンダースコアをバックスラッシュに変えただけ感はある。
前スレ
>>1000 他の言語と比較した上での発言だ。
＞エイリアスが他クラスとかぶる可能性とか何を言ってるんだと言わざるを得ない
namespace project;
use lib\ClassName as ClassName;
という記述があった場合に ClassName が project\ClassName と衝突する可能性があるから、
基本的には絶対パスでの記述になる。
コンパイル時に走査してくるような言語とは使い勝手が全く違う。
＞jsですらjqueryやらprototypeやら他のライブラリつかって名前空間を表現しようって風潮なのにどんだけ取り残されてるんだよ
それらは疑似名前空間で、実装ではなく規約の話だ。
PHPのアンダースコア区切りのクラス名と同類だよ。
namespaceの実装が望まれたECMA4が廃案になったのは知ってるかい？ｗ
何で :: とかにしなかったんだろう。\だと末尾に「.php」が抜けてるような気持ち悪さが…
フレームワーク関係ないね、すまそ
サーバOSがWindowsとかだとますます混乱しそうだよね。
>>10 :: はクラス内のスタティックメソッドやプロパティやクラス内定数の参照の時に既に使ってるし、そっちとかぶるからじゃない？
メソッドだろうがプロパティだろうが名前空間だろうが
全部ピリオドにすればよかったのに
文字列連結に使ってる時点でもうダメだろ。
もう面倒だからサーバサイドJavaScriptに移行しようず
jsは言語が汚れすぎてる
オライリーですら擁護しきれずに綺麗な部分だけ使おうっていう本を出してるぐらいにねｗ
>>11 Perlだってスタティックメンバの参照に::使ってるけど
名前空間の区切りは::だよ。
まぁすでに実装されてしまったものだし諦めるしか
言語仕様もエンジンの実装もドロドロに汚れちゃってるからなPHPは。
namespaceが中途半端な機能で、
区切り文字がバックスラッシュになったのも、
fainallyが実装されないのも、
ZendEngine2への実装が困難だからだよ。
なんでfinally実装できないの？
Lithiumのその後を知ってる人いる？
そろそろリリースかな
>>19 単純に技術的な問題。
良い実装案が出れば、実装したいと開発者は言っている。
へ？構築するスキルがないってだけ？ZendEngineの問題でなく？
>>22 ZendEngineに実装する上での技術的な問題だよ。
だからそれどういう問題？
>>24 だから、技術的な問題だよ。
興味あるならPHP自体のソースコードを読めばいいよ。
26 ：
nobodyさん：2010/12/15(水) 06:24:51 ID:mlC32vdu
27 ：
nobodyさん：2010/12/15(水) 06:35:05 ID:mlC32vdu
finally、無いよりもあったほうがいい。それは間違いない。finallyの導入にどれくらい開発コストがかかるかは知らないが。
スクリプト言語にfinallyねぇ
中々面白いギャグだ
マジだったらプログラムを一からやり直して欲しいレベル
javascript には finally あるんだが
RubyにもPythonにもfinally相当あるよ。ついでにPerl6にもある。
英語の読めない俺の為に簡単に訳してくれ
どこが分からんの？
全部訳せとな？
>>37 散々議論されたってのは読み取れたけど、
最終的に何故実装されなかったのかが読み取れませんでした先生。
声の大きな人に限って結論をぼかすよなｗ
26は最初か2番目に出てくるコードで代用できると
27はリソースの開放は利用側じゃなくて利用されるデストラクタで実装すべきという主張。C だが
C++にfinallyが無いのと同じ理由。
よい実装があれば可能＝技術的に困難、なのか？
>>41 おまえその日本語読めてない。
空気も英語も読めてないのにメーリングリスト読めないだろ
>>45 空気読めてないのはお前だろｗ 顔赤くしてないで該当メーリングリストのソースを示せよ。
大垣：
実装して欲しい，実装しておくべき機能は思い浮かびますか？
Rasmus：
オブジェクト指向プログラミングのサポートについては実装されるでしょう
traitsにはよい実装があるのでPHP 5.4に含まれることになるでしょう。
finallyも，もしよい実装があれば追加されるかも知れません。
どう読んでも、実装の問題。
よい実装ってどういうこと？
プライオリティが低いってだけじゃないの？
>>47 そのままの意味だよ。
実装出来なくは無いんだろうけど、影響範囲の大きさや、ロジックの改修規模がでかくて難しい。
>>48 どこにプライオリティの話が書いてあるんだｗ
>>49 However namespaces are much harder to implement yet I think finally is relatively straightforward since we can already emulate it using try/catch, but with the quirks.
namespaceの方が実装難しいと書いてあるんだが？
実際finallyが必要になる場面って、どういうのがあるだろう
そもそもfinallyの代替になる方法、そんなに面倒？
実際namespaceが必要になる場面って、どういうのがあるだろう
そもそもnamespaceの代替になる方法、そんなに面倒？
>>49 >実装出来なくは無いんだろうけど、影響範囲の大きさや、ロジックの改修規模がでかくて難しい
のソースは？
例えば、アクセス制御だって、アンダーバーから始まるメソッドはプライベート扱いにするってルールでコーディングすれば、publicやprivateは不要。
が、そんなローカルルールに頼るよりも言語機能を使った方が良い。
PHPでPearが盛り上がらない理由の1つは、PHPにネームスペースやパッケージがなかったからだと思う。
PEARが盛り上がら･･･ない？
PHPって、WAFがフルスクラッチ・フルスタックなのばっかだからな。
PEAR::DBとSmartyくらいか。どっちもPHP4全盛時で、今じゃ大して使われてないな。
後は、日本だけでNet_UserAgent_Mobileくらいか。
PHPのnamespaceの一番ダメな所は、標準で規約が無いところ。
・パッケージとディレクトリ構造は一致
・クラスファイル名はクラス名+.php
・パッケージ名はドメイン名+プロジェクト名を接頭とし、Camelcaseで記述する
・クラス名はCamelcaseで記述する
のような規約があり、かつuse文でオート（Lazy）ロードに対応
くらいして欲しかった。
自分で実装出来るが、
標準でuse構文が上記に対応していたら、標準化が進むのになぁと思ったりした
一番ダメなのは5.0の時に出さなかったところだと思う
C言語の一番ダメなところは、
ネームスペースがなかったり
クラスがなかったり、
例外がなかったり
>>60 唐突になにいいだすんかとおもうが、
高級アセンブリ言語だからあれでいいのです。
N88BASICこそが究極であり至高ですよとベーマガ読者は言う。
C++って最初は例外もネームスペースもなかったの知ってる？
ま、名前空間とは別に、パッケージの仕組みも合った方が良いな。
名前空間、パッケージに関しては
やはり色々考えられているPerlの方が上だな。
自社フレームワークを使ってるところが多い気がするが、
自社のフレームワーク開発すべき？
必要ない
>>68 俺もそう思う。バグだらけのFWを、開発した奴はスキルアップになったかもしれんが、
それを使わされる方はマジたまらんわー。
他の人の意見も求む！
必要ない
半端なFW使うよりかは、もともとある奴をちゃんと検証して
バージョンアップしながら使ってくほうが後々考えると有益
ちょっとしたことのためにFWいじくって対応とかアホなことすると、
大抵はあとで酷いことになる
既存のフレームワークを、自分らの使いやすいようにラップするケースは多々ある。
一からフレームワークを作るのは、勉強目的以外ではあまりメリット無いかな・・・
>>71 >ちょっとしたことのためにFWいじくって対応とかアホなことすると、
あるある。ありすぎて困る。
「それはフレームワークじゃねぇ、ただのライブラリだ！」
と言っても、社内のPHP屋は理解出来ない。
PHPでOSSのフレームワーク使ってない(使い方わからない)時点で、
その程度だわな・・・
74 ：
73：2010/12/25(土) 06:00:58 ID:???
あ、普段はASP.NETやってます。
あれは立派なフレームワークな反面、
社内製フレームがクソすぎて・・・・
（なぜOSSのフレームワークを作らないのか・・・）
という背景があることをいちおう言っておきます。
75 ：
73：2010/12/25(土) 06:01:48 ID:???
（なぜOSSのフレームワークを”使わないか”）だった
>>73 PHPだけでいえば、CakeぐらいはできるがSymfonyはさすがにできないという、
中途半端な技術者が社内製フレームワークを作ってる気がする
>>76 SymfornyはCakeに比べて設計が難しいという意味？
名前空間があってよかったことってなんかある？
英語、新しいものダメダメな日本のPHPerにはウケわるいけど
お外じゃYiiは結構人気でてるっぽいよね
>>82 Yii って他の意味あるのか？ Yii Frameworkでググル意味は？
新しいモノ＝良いモノとも限らないし、、
今の日本の保守的でグダグダなWEB開発業界を考えると、
枯れてリソースの揃いきったFWを深く使いこなす方が得なんだろうね。
既存のFWを捨てて、新しいFWに移行する明確なメリットデメリットが示せない限りね･･･
Yii Frameworkの他に"Yii"のつく目新しいものなんてないだろ、たぶん。
Yiiフレームワークが登場してから"Yii"のトレンドが上昇してるのは、
明らかにYiiフレームワークの成果だろ。
今後もPHPが続くとしたら、新規の際の選択肢には入れたほうがいいとは思う
蓄積された情報やノウハウ、学習コストを含めるとYiiはまだまだかな。
職業PGが増えてる昨今、まともな学習教材が無いと開発者の足並みが揃わない。
>>90 Hello Worldベンチマーク・・・
＞Hello Worldベンチマーク・・・
何が言いたいの？
検証に問題があるならはっきり指摘して
職業PGなんて教材があっても
多分こうだろう的な、なんも考えてない場当たり実装を次々編み出してくし
日本語で説明されてるコピペできる参考例が多くないと、確かに難しいだろうなｗ
symfonyはsfFormがどうもだめだ…
symfony2で変わったのかな。
>>94 Hello Worldの値なんて理論値みたいなもので、
実際の実用環境では他のロジック部分がボトルネックになるから、ほとんど意味の無い値って事。
上の比較ではsymfonyが数倍遅いと錯覚してしまうが、
実際に作るコンテンツ内容、コーディング方法、ファイルI/O、DB処理等の方が遙かに比重が高い。
開発者全員が完璧な最適化を行えるのなら、フレームワークのオーバーヘッドを考慮するのも有意義かもしれんが、
現実的では無いし、大抵は枯れた技術の方が最適な実装が出来るし、学習コストも低い。
その浮いたコストをハードウェアやネットワークに回す方が遙かにパフォーマンスは上がる。
それ以上のチューニングを行う場合は、フレームワーク自体導入しない事の方が多い。
地味にYiiスレ出来てんのな
で、このスレをディスってんのなｗ
半年放置しても落ちる板じゃないしあって困るこたないんじゃね
既存のPHPFWのスレは大抵できてんじゃないかな？kohanaスレとかもあるし
よーしパパLithiumスレ立てちゃうぞー
Yiiは見た感じ良さそうだった。symfonyとYiiで行こうぜ。
日本人が言語やFW開発しても意味ないから、それだけはやめてくれよな。
>>98 ベンチマーク自体意味無しって言ってるのね。
枯れた技術とか学習コストって言ってるのも、「英語を読めない日本人PHPer」限定の話でしょ。
フレームワークの性能評価としては関係ないね。
実際は乗り換え学習コストなんてたいしたこと無いし。
>>103 Hello Worldでパフォーマンスの優位性を語ることに意味は無いって事。
静的な文字列を出力するだけのWEBアプリなんて、今日日存在しないだろう、
せめてDB接続用インスタンスを生成したり、各種ユーティリティクラスを読み込んだ上で実測しなきゃね。
＞枯れた技術とか学習コストって言ってるのも、「英語を読めない日本人PHPer」限定の話でしょ。
逆だろ、一部の自称ギーク限定で新しいモノを導入したがっているだけでしょ。
英語読めても職業PGの応用力の無さでは、新しい物を自力で吸収するのは難しい、
ググレば日本語でかみ砕いた情報が得られるFWと、学習コストは比較にならんよ。
YiiとSymfony ってどっちが学習コスト低い？Kohanaは？CakePHPは？Zend Frameworkは？
学習コストでソートするとどんな感じ？
>>106 ＞Why "Hello World"の反論になってないよ。
反論以前の問題。公平な方法が無いからHello World？
それなら極限までそぎ落とした俺の自作MVCフレームワークの方が数倍軽いかもね。
フレームワークとしてのパフォーマンスじゃなくて、
「HelloWorldを行うには最速」って表現ならいいんじゃない？
それでパフォーマンスの優位性語られても、まっとうなPGなら疑問を抱くだろうけど。
極論出たね。
なんでHelloWorldで”オーバーヘッドを測る”のが「HelloWorldを行うには最速」とかにすり替えるんだろう。
自作のフレームワークがここにならぶのと遜色無い機能を持ってるなら「自作MVCフレームワークの方が数倍軽いかもね。」と自慢してもいいよ。
http://www.phpframeworks.com/ でもそうじゃないでしょ。
じゃあ他の部分は遅いのYii？
たかがHello Worldって文字出すだけですらこんなに差が出るって考えると
なんだかんだで必要なロジックの選択はよく出来てるってことなのかな
ようは余計な処理とか通さないようにできるってことだよね
つーか、新しいものは金にするチャンスなんだから
既存のーとか枯れたーとか、そういう保守的なスタンスは儲けないよ
まぁ今日日PHP自体がアレなんだけれど
どのFrameworkがいいかなんて比較やってことないし、俺にはわからんが、
結局明確なデータに基づいた比較を行ったわけでも、ソース持ってきてるわけでもなしに、
俺がこう思ってるから俺は正しいって叫んでるだけじゃ
資料もスライドもなしにプレゼンするくらい馬鹿なことだと思う
FWって速度が評価基準なの？
開発効率のために用いるものかと思った。
ベンチマーキングの意味は
>>106に書いてあるとおりで、こうも書いてある。
＞Do not interpret the numbers alone
＞The benchmarking results should NEVER be interpreted alone.
＞The server configuration and the way of running the benchmarking applications could affect the results significantly.
＞And do not choose a framework purely based on this benchmarking result.
＞You should consider many other factors, such as feature set, documentation, code quality, user community, technical support, etc.
＞We all know that using a plain PHP script would easily beat any of the frameworks in performance comparison.
ここに書いてあることがフレームワーク選びの正論だろ。
そのうえで「ベンチマークなんて意味無い」ってフレームワークの性能向上を否定しちゃうのは
やっぱり自分が使っている技術が廃れる事への恐れがあるんだろう。
Symfony2使っとけばno problem
>>107 ＞自作のフレームワークがここにならぶのと遜色無い機能を持ってるなら「自作MVCフレームワークの方が数倍軽いかもね。」と自慢してもいいよ。
＞
http://www.phpframeworks.com/ ここに並ぶフレームワークとしての機能を使っていないベンチマークで、
パフォーマンスの優位性を語る事は出来ないって事だよ。
Yiiは遅延読込を積極的に採用しているから、Hello worldには強いかもしれないが、
実際に諸々のロジックを実装した場合、どれだけ差が出るのか解るの？
＞でもそうじゃないでしょ。
俺のFWはMVCの基底部分だけ自作だから、Hello Worldは最速かな。
内部ファンクションコール数で言えば数回じゃないかな。
他のFWと連携出来るようになってるから機能的には遜色無いどころか多すぎて困るかもね。
>>112 が書いてるように、大抵は開発効率向上の為に導入するんじゃない？
明確なソースも資料も無しに、Yiiは凄い！とか言ってる人はただのミーハーな開発者としか思えない。
本当に素晴らしいと思うなら、率先して普及活動を行えばいいと思うよ。
Hello World最速なのはわかったから、具体的に他のFWから乗り換えるメリットを提示すればいい。
>>113 ＞Do not feel attacked¶
＞This project has no intention to attack any framework. On the contrary, it tries to help frameworks to find out their performance bottlenecks and make improvements.
Hello Worldのパフォーマンスがフレームワーク選定にはさほど重要では無い、と書いてある気がするのだが･･･
結局どのフレームワークを使えばいいんだよ
皆投票してね
CakePHP
Symfony
ZendFW
Yii
Ethna
kohana
俺俺FW
CakePHP
Symfony 1
ZendFW
Yii
Ethna
kohana
俺俺FW
>>117 選定基準による。
日本語情報はいる？ドキュメントはいる？IDEは使う？ActiveRecordが欲しい？開発規模は？etc･･･
>>119 日本語情報いる
ドキュメントいる
IDE使わない
ActiveRecord欲しい
開発規模は会員10万人ぐらいのブログ機能
これでお願い
使うほうのことは関係なくて、開発効率だけのためにFW選ぶのも何か違う気はしないでもない
>>120 無難にCake/Symfony/Zendのどれかじゃないかね。
>>121 ユーザはフレームワーク以前に、PHPかどうかすら気にしないだろう。
いやだって速度で言ったら素のPHPが一番に決まってるじゃん
その速度の差がユーザーエクスペリエンスにどの程度影響するんだって話だろ
123は121宛だよ
開発効率や速度をだすことより、会社が儲かることが大切だと上は言う。
無難にというか、日本語しか駄目ならCake・Symfony・Zendだけしか選択肢ないだろ。
英語のドキュメント読むスキル無いとキビシーわ。
PHPみたいな言語を使う人らからすると、この言語の壁はでかいよなぁ
英語のドキュメント読める奴って、PHPプログラマ10人に1人いるかどうか
馬鹿に組ませた素のPHPより、低速なフレームワークを使ったほうが
数百倍マシだったりするけどなｗ
>>124 そういう実用レベルの話であれば、
ネットワーク、ディスクI/O、CPU等のハードウェアの増強をして、
APCやmemcached等のチューニングを行って、
HTML/CSSのチューニングを行う、
のが普通。
フレームワークの最小オーバーヘッドがユーザエクスペリエンスに影響するのなんて、
根本的に設計がおざなりな場合くらいじゃね？
クラウドのおかげもあり、ハードウェアの増強が最も費用対効果が高いけど。
バッドノウハウを含む情報量の差も大事だろう。
Cake、Symfony、Zendあたりなら、バグが発生した場合や、規格外の処理を追加したくなった時に、
ググるだけで先人の知恵を得られたりする。
>>126 効率を上げる＝人件費が浮く＝会社が儲かる。だろｗ
PG一人雇うのに数十万の費用かけるなら、同じ金額を機材に当てる方が効率も速度も上がる。
既存の技術なら学習コストも無いようなもの。
>>115 外部依存の俺俺でも「フレームワーク」と言えるの？
開発にそんなの使いたくないんだけど…
英語のドキュメント読める人はどのフレームワーク使ってるの？
PHPの場合、mod_phpで使う事が前提で、ファイルインクルードだとかのロードタイムが無視できないんだよね。
最近流行のソーシャルゲームみたいなサイトだと。
他の言語だとmod_perlだとかFastCGIだとかPassengerだとかで、複雑なクラス構成のアプリケーションでもいったん立ち上げてしまえば高速に動かせるアプリケーションサーバ環境があるけど。
まあ、フレームワーク以外にも、SQLを見なおすとかコーディングレベルで改善出来る余地がある場合も多いけど。
>>133 外部依存かどうかは関係無いよ。
Symfonyだって積極的に外部ライブラリを取り込んでいる。
本当にSymfonyできるやつでてこいやー
いるわけないか･･･
＞無難にというか、日本語しか駄目ならCake・Symfony・Zendだけしか選択肢ないだろ。
Symfonyやったことないんだなｗ
test対応も評価条件に
ﾜﾗﾀｗ
レスするだけなら誰にでも出来るわなｗ
OpenPNE3はsymfony採用してたけど、さすがにあれは重すぎじゃね？
symfonyのせいなのかあれは。
俺にはわからん。
>>135 ＞PHPの場合、mod_phpで使う事が前提で、ファイルインクルードだとかのロードタイムが無視できないんだよね。
(snip)
＞他の言語だとmod_perlだとかFastCGIだとかPassengerだとかで、
(snip)
そんなときこそ、php-fpm (fast CGI process manager)を導入してみては？
test
すると独自フレームワークが必要になるな。
3大FWは機能が多すぎる
皆そんなに仕事で大きなシステム作ってるんか？
３大FWって、Kohana, Yii, ちいたん のことか
>>145 普通にCRUDでデータをひと通り処理するシステムだと小さくてもFW使っちゃうな。
必要ない機能があってもそれを通さないならさして問題ない
コード記述量が減らせるならFWを使う意味はそれだけでも出てくるんじゃね
※ただしLazy Loading を実装したFWに限る
> ３大FWって、Kohana, Yii, ちいたん のことか
よく分かってらっしゃる。
面白いネタフレームワークだと思ってるから、
それをだしたんだろ？
落ち担当のちいたんはさておき、前者2つは比較的新しいから期待は出来る
なにを期待？
先生の次回作に期待
打ち切り
最近分かった
所詮phpはHTMLに簡単に上書きするだけの用途以外では使うべきじゃない
フレームワークをphpで作るのは無謀
いまさら分かったのかい
で、Webアプリケーションを構築するのに最適な言語は何だと思う？
「最適」なんてないのさ
>>155 どんな経緯でそういう結論になったのか気になるな。
単に使いこなせなて無いだけじゃね？
フレームワークをPHPで ”作る" とか
言ってる時点で、なんちゃってプログラマでしょｗ
まぁ低レベルは、PHPですらフレームワークを使えないし、
デザインパターンも知らないし、PHPでオブジェクト指向ｗとか言う。
かといってJavaでバリバリ組めるわけでもない。
あんた何ができるのさっ？って言ったら、
「PHPをベタで組む！その方が早い！クラスなんて作るな！」と
デザインパターンかじって底辺プログラマ相手に優越感浸ってる連中が一番無駄にコストかかるよな
せめて東大大学院卒で世の中に一石を投じるアルゴリズムの一つや二つ作れるぐらいになってから偉そうにソファーに踏ん反り返って欲しいものだ
ちゃんと板の間に正座してプログラムしてます
底辺プログラマだってデザパタぐらい使いこなせる
底辺プログラマだってSymfonyぐらい使いこなせる
底辺プログラマだって頑張って生きている
そうだそうだ死んでいるような顔色してたってよく見ると生きてるんだぞ！
底辺は1メソッドのなかに全てのやりたいことを書いてるんじゃないかってくらいメソッド分けもできんぞ
そんな奴の書いたコードでバグの修正とかまじうんざりする
にわかでもある程度自分で考えてかじってる奴のほうが数倍はいいぞ
昔のままの俺だと思ってんじゃねえよ！
参考にするソースが悪すぎただけだろ
1メソッドで一つのことしかしないことぐらい独学済み
人はいつでも成長している。底辺プログラマだってだ
1メソッドの長さとか、もうそういうことは我慢する
変数名に数字のsuffixついてたりも目を瞑ろう
だから
「ｘｘｘのとき呼ばれる処理」
その一言で全てを説明した気になってるんじゃねええよおおおおおおおぉぉォォォォーーーッッ！！
メソッドに分解ができないなら、その分岐、ループの意図するところくらいコメントに残せよばーか
で、ここ何の愚痴スレだっけ？
それだけ自分が低レベルな環境に身を置いているってことだろ
速度優先な事もあらーな
関数で組むのと、オブジェクティブに組むの、どれぐらい速度変わる？
何の速度が？
処理速度
プログラムのことは全く知らないが、
オブジェクトの大きさや生成したインスタンスの数によって変わるの？
私は、配達時間の関係で仕方なく朝日新聞を読んでますけど、愛読者では有りません。あんなものは愛読するものでは有りませんよ。在宅勤務になった
ので４月から読売に替えました。朝日新聞を読んでいると、カルト宗教の機関紙を読んでいるような気分になる。とてもじゃないけど子供には読ませら
れないので、本来なら「新聞ぐらい読みなさい」と言うべきところを「朝日はおかしいから読んではいけません」としか言えないのが悲しい。漢字が奇
妙な当て字が多くて、熟語も一部がひらがなになってる。近頃はその傾向が顕著だ。そこで本社に電話して尋ねてみたところ「韓国を見習って、少しず
つ漢字を減らして、やがて日本語から漢字を全廃させる方針」だそうだ。こんなことは国民の総意で決めるべきこと。一新聞社が決めて実行するのは僭
越だ。何を考えているのだろう。ともかく戦争反対というのも訳分からん。湾岸戦争のときも「日本が巻き込まれるからクウェートを助けに行くな」と
いうキャンペーンを張った。侵略者はみんなで寄ってたかってやっつけなければいけないのにおかしいぞ。そして他国が苦労して築き上げた平和は、当
然の権利として享受しようというのでは、日本が侵略されたときに助けてくれる国は居ないだろうに。昨年９月11日のアメリカでの同時多発テロの首謀
者であるオサマ・ビンラディンについては必ず敬称をつけるように徹底させている。テレビ朝日でもゲストコメンテーターに「必ずオサマ・ビンラディ
ン氏というように氏をつけて発言してください」と徹底させているし、朝日新聞本紙では、今でも必ず敬称をつけている。恐いのは外国の人がオサマ・
ビンラディンと呼び捨てにして発言しても翻訳では勝手に「オサマ・ビンラディン氏」に変えてしまうことである。これでは正しい報道とは言えない。
冷酷な人殺しをここまで敬うその心理は如何に。朝日新聞は、いつのまにか宗教になってしまったのではないだろうか。しかもカルトと呼ばれる変な宗教に。
cakeの次スレは立たないのか？
cakephpスレ立たないところを見ると
既に終わったFrameworkってことかな？
2chがすべてという価値観の人間にはそう思えるかもしれんが
普通は2chにスレが立つ立たないでそんなこと考えないだろう
Cakeの次スレはLithiumが乗っ取ります
cakephpで質問です。
idを主キーにしていて
データの取り出しで
this->model->
findAllByName($hoge)
として
this->model->save($this->data)
した場合、上書き更新ではなく新レコード挿入になりますよね？
主キーでモデルのデータを取り出さない限り新レコード挿入になるのは分かるのですが、CakePHP仕様だと主キーを一つしか扱えないのでupdateAll()を使うしかないのでしょうか？
主キー以外のフィールドでの検索対象の
レコードを更新したい場合、
スマートなやり方だと、どういうやり方が一般的でしょうか？
オイラもcakephpで質問！
生成されたpotを弄ってviewの中のctpファイルはローカライゼーション出来るようになったんだけど、
バリデーション(モデル)とか
プログラム上での(コントローラー)表記を
ローカライゼーションしたい場合は
どうしたらいいの？
CakePHPスレ立てろよｗ
このスレッドは、【PHP】フレームワーク CakePHP 11ホール目【v1.3】になりました。
建ててもいいけどテンプレしらないからここに張ってくれれば良いと思うよ
CakePHPはオワコン
PHP5.3もまともに対応してないフレームワークとか使えねえよ
というわけでLithiumが始まります。
Symfony様、ZendFW様、CodeIgniter様、お疲れさまでした。
情弱なオレに教えてくれ
cakeって5.3に対応する気ある？
というかもう対応してる。
どこが対応しているのですか？
error_reportingを甘くしないとエラーでまくりですよ
warnじゃなくてerrorが出るんだっけ？
CakePHP1.3系のDeprecated errorはうざすぎて開発に支障をきたすレヴェル
結局、どのフレームワークが一番のおすすめなの？
結局は自分で触ってみないとわからない
毛深いのはあまり好きではありません
ならLithiumだな。ツルッツルだよ
ちいたんは、ぱっと見はツルツルだが中の方は結構、癖毛もち
LithiumはCakeと比べると機能はライトかい？
天下のツイッター様はPHPのフレームワークなんて使わないよ。
俺の周りではPHP5.3導入を検討し始めているクライアントが増え始めてるから
警告ばっかりでるCakePHPなんて使わない
高速に開発するフレームワークなんてこれ以外にもあるし
手っ取り早く作るならCodeIgniterお勧め
CakePHPは学ぼうにも参考書に地雷しかないからな
クックブックが一番わかり易いというのが、初心者におすすめできない痛いところ
しかしCodeIgniterも時代遅れ感が・・・
それcakephpの事じゃね？
CIは今流行りだしてる訳だが
流行ってはいないｗ
良くも悪くもPHP5のFWは決定打が無い感じだよな
PHPだから仕方がないな！
いや流行ってるよ
むしろCakeは衰退している
すでにCIを使ってる人はいいが
今から使い始めるのは考え物だ
>>207 何をもって流行ってるの？
CIはFW過渡期に高速軽量って事で鳴り物入りしたが、普及してないイメージしかないんだがｗ
Cakeは衰退と言っても固定層がかなりいる。
なんだかんだで知らないことを覚えようとする奴はすくねーからな
もうカビが生えててもCakeしか食べ物を知らない連中はいっぱいいる
会社で採用されてるのがcake。
しにたい。
>>211 どのフレームワークだったらうれしいのよ？
まあPHP４は考慮してなくていいよな、さすがに
cake使うならkohana使えよ
php5.2はサポート打ち切られたのにphp5.3に対応してないFWなんて使うなよ
kohanaは尚早な気がするね。
＞php5.3に対応してないFW
CakeはPHP5.3でも動くよ
動くと対応しているはイコールでは無い件
ソースコード読んでから書いたほうが良いかもよ。
>>214 5.3に対応していないってソースありますか？
FW選定の資料のひとつにしたいので。
>>217 意味がわからんが
部分的に動かないところがあるってこと？
Cake使ってる理由 ＝ 名前が美味しそうだから
Symfony使う理由 ＝ エレガントかつ高速な設計を追及したいから
ZFを使う理由 ＝ Zendっていう名前が付いてるからなんとなく安心
結論：Symfonyを使う人間が一番賢い。
みんなのdailymotion様も、Symfonyで大量アクセスを捌いておられるのだ。
これからはSymfonyをメインで使い、内部的にSmartyやZF等を使う方法が主流となる時代がやってくる。
えっ
>>218 cakephp自体がソースとして読める形なんだから嫁よ
Yiiが良い
結局どれがいいんだいっ!!
ZF
ethna
CI2はPHP4切ってるんだろ？
使ってる人どう？
>>227 Kohana3に移行してたから気付かんかったわ
ci終了のお知らせ
まだだ、まだ終わらんよ
すべてが遅すぎた
はじめまして、相談させてください。
「よくわかるPHPの教科書」という初級本を一冊読んだだけのPHP勉強したての見習いWEBデザイナーです。
以下のサイトのような情報サイトを作ろうと思っております。
http://www.nightstyle.jp/ この後、何かのPHPフレームワークを勉強して作ってみたいと思うのですが
どのフレームワークを勉強していったほうがいいのか分かりません。
アドバイスいただけませんか？ よろしくお願いします。
認定脳
235 ：
nobodyさん：2011/12/09(金) 23:07:04.62 ID:nHunuLCR
ここ1週間くらいCakePHPの入門書読んできてフレームワークがどんなものかは理解したけど
cakephpってhtml5とか対応してないっぽいしもっといいフレームワークあるの？
日本語の資料が多いもので認証機能とユーザごとにアクセス権限(cakephpのauthとACL)があるものって他にある？
やっぱり無難なのっていうとcakephpになるの？
>>235 HTML5のどこに対応してないって言ってる？
ほぼほぼHTML5に対応してると思うんだけど。
1週間Cakeの入門書を読んだだけで、フレームワークを理解した気になってる時点で･･･('c_`
AuthもACLもメジャーフレームワークは全て実装されてる。
そもそもHTML5対応って何を指してるの？ｗ
238 ：
235：2011/12/10(土) 12:24:35.06 ID:???
html5対応じゃないって言ったのは$html->doctype()がまだ古いほうだったりhtml5で追加されたタグは$html->tag()使わないとだめだったりするところ
それくらい我慢しろって言われたらそれまでだけどやっぱり気持ち悪い
日本語の入門書籍とかcakephp辞典みたいな命令一覧が充実してるメジャーフレームワークってcakephp以外にあるの？
あとだれもフレームワークをすべて理解したとは言ってないぞｗ
いまからやるならyiiのがいいんじゃね
まぁメインにするのがないときは浅く広くやるほうがいいと思うけど
>>238 doctypeもhtml5のフォーム要素も対応してるんだけど
$html->doctype()と書いている時点で
おそらくそれは1.3系以下の情報ですので、勘違いしていますよ
2.0系ではhtml5のフォームinputをサポートしています
あと書籍や日本語の情報などは、自分で容易に調べられますよね？
242 ：
235：2011/12/10(土) 17:12:37.55 ID:???
検索してヒットすれば日本語の資料があることはわかるけど
ない場合本当にないのかわからないから聞いてるんです
どうせおまえら知ってて教えてくれないんだろ
243 ：
235：2011/12/10(土) 17:18:52.08 ID:???
そもそもメジャーフレームワークってなんなのさ？
とりあえず涙拭け
cakephp = 情弱
きちんと更新されてて日本語の最新の情報があるフレームワークってどれ？
どこかに比較表ないの？
cakephpはほんとに日本語ブログの情報が減って来てる
あっても1.1とか1.2のものばかり。(07~09年あたりに書かれたものばかり)
2.0もcookbookの解説が未だに英語のまま。リファレンス本も出ない。
今から始める人にはつらい環境です。
>>246 今、PHPのフレームワーク界隈で一番話題になってるのは
間違いなくCodeIgniterだな
日本語ドキュメントもかなり充実してる
>>248 CodeIgniterってプラグイン系はどうなの？
アジア圏で利用ユーザーが多いらしいから、そっちの
人達がいっぱい作ってたりするのかな。
日本語ドキュメントの充実には同意。
あれは他のフレームワークも見習うべき。
間違いなくCodeIgniterが盛り上がってるとかは、半年前の話です
今はライセンスの問題で敬遠されがちになっているのが現状ですよ
CakePHP, Symfony, Yii, FuelPHPらへんで選べば問題ありません
ネタだろ？
一番話題になってるのは確かだし
でも、ユーザ会のMLで今後どうするかとか話し合ってるのに
初心者に泥船勧めちゃダメだろｗ
ciからの乗り換えだったらfuelは時期尚早な気がする
kohanaの方がよさげ
ci乗り換えとかじゃなく普通にこれからやるならyiiがお勧め
kohanaも尚早な気がするね
まだ安定して無くて元気がありすぎるわ
なんだかんだでyiiが鉄板になりそうな気はするよ。便利
自分もyiiですねー。PHPフレームワーク4つくらい触ってきましたが、ダントツですばらしいです。
fuelphpなんざまだ利用者少ないからバグばっかりで使い物にならねえよ
CakePHPとSymfonyどちらを習得するか悩んでいるのですが、
個人開発でコードを管理しやすいのはどちらだと思いますか？
個人開発ならどっちも違うんじゃね？ チームワークし易いように、多少面倒が増えてもコードを細分化させてるFW達だし。
codeigniter はオワコンなんですか ; _ ;
コンテンツとしては終わってないが、日本のコミュニティは終わった。
YiiとCakeの比較をどなたかお願いします
ARとかORMは正直いらんと思う
いやむしろ存在自体が悪ですらある
ならお前はそう言い続けていればいい
264 ：
nobodyさん：2012/01/31(火) 01:37:29.87 ID:vL8UhXp0
拡張子が.jsだったら自動的に難読化してくれるフレームワークなんてありますか？
そんな便利なのないですかね？
httpdのフィルタで出来そう
266 ：
nobodyさん：2012/01/31(火) 03:44:28.12 ID:vL8UhXp0
268 ：
nobodyさん：2012/01/31(火) 19:56:17.06 ID:wEgOhILt
cakeって複合の主キー使えないの？ 不便じゃね？
他のフレームワークでは使えますでしょうか？
270 ：
nobodyさん：2012/01/31(火) 20:30:57.44 ID:wEgOhILt
271 ：
nobodyさん：2012/01/31(火) 21:32:10.28 ID:mg92XRmL
ビューはJavaScript使ってクライアントサイドだけでやるわ
モデルのSQLは自分で書くわ
という仕様のアプリケーション向きのフレームワークってある?
jQuery
JSDB
その方式でいいんですよ。
httpd.confに
Alias /test "/opt/lampp/test"
<Directory "/opt/lampp/test">
Options FollowSymLinks Includes ExecCGI
AllowOverride All
Order allow,deny
Allow from all
</Directory>
こんな感じで。
Zend frameworkを鯖に入れて使ってみたいのですが
eclipseでの開発はどうやるのが良いのでしょうか？
ググるとZend Studioを買えと出てくるのですが、
貧乏なので、無料でやりたいのです。
linuxテスト鯖 + (windows+eclipse)クライアントで
便利にやる場合の、ベストプラクティスがあったらお願いします。
（クライアントは別にeclipseじゃなくても良いです。これまでずっとeclipse使ってたので続行したいだけで。。
こっちのほうが良いってのあれば、それも教えてください。）
つvim
アメリカでもPythonのコーダー集めんの手間だってのは意外だわ
言語人気はそれほどでもないし、Googleが熱心に勧めてるだけで、いまいち流行ってないじゃん。
ガイジン＝Pythonじゃないのか！
バカかあんたは。
Cakeしか使ったことのない俺に、Yiiのよさを教えてください
Yiiはいい
Cakeより扱いにくいものってあるの？
CodeIgniterは使いにくかった
FuelPHPは簡単だった。
学習コストがもっとも低いフレームワークをおしえてください
学習コストだけならCodeIgniterじゃない？
でも、学習コストでフレームワーク選ぶと痛い目にあるので注意を
学習コストが低い＝機能が少ない
だからその辺に転がってる自作フレームワークとかになるんじゃないだろうか
要は簡単に覚えられるもんを探しているんだろうと思う
でも作るアプリは一緒なのだから、学習コストはどれも一緒ってなるのに気づいたほうが良い
まさに簡単に覚えられるものを探していました。
ＣＩを使っていたのですがライセンスの話がややこしくて他に移ろうと思いまして。
しかし
>>292、
>>293さんのレスを見てしっかり腰据えて勉強することにしました。
いろいろ比較記事を読んでyiiがよさそうなのでやってみます。
ありがとうございました。
Yiiなぁ。いいんだけど、CI使い的には余計なお節介が多いんだよな～。HMVCは楽に作りたいけど、UIはカスタムするからシンプルがいいって時に、無駄に作業増える。
それは「使えて」ないからだろ。
298 ：
nobodyさん：2012/02/21(火) 00:11:16.86 ID:3wZdUskl
Slimは学習コストが低くていい。
PHPでビューまで面倒みるってやり方はもう見なおしてもいい。
Slimは、せめてValidationあったらもっと使うんだが。
学習コストっても、マニュアルがしっかりつくってるあるフレームワークなら
やりたいことがでた時に都度みればいいだけじゃん。
301 ：
nobodyさん：2012/02/21(火) 08:43:37.33 ID:Ts0sDPGu
>>299 PHP標準のFilterとかPEAR::Validateとかじゃ不足?
>>281 こいつバカだろ
CythonとHiphopじゃ全然比較にならない
PHPを大規模で扱ってるところは大体PHPのソースコード自体をカスタマイズして使ったりしてるから
C言語ぐらいは使えないとダメだよ
>>303 ねぇよｗｗｗｗｗ あるなら具体的事例をだせ
せいぜい拡張作ってるくらいだわ
大規模で使ってるとこならそういう事もあるわな
>>305 具体的事例って書いてあるだろ
コナミのどこでどう使われてるんだ。
記事付きでちゃんと出してみろ
まぁネイティブなとこまで手を入れるようなことは早々ないから、C必須だってこたないと思うが
出来ないより出来たほうがいいわなぁ
手を入れれるならそれだけやれることが広がるわけだし
それくらいも知らない＆探せないような素人に用はない
今のゆとりは己の無知を威張りながら人に聞くのが流行ってるんだなｗｗｗｗｗｗ
恥ずかしい奴ｗ
教えて君の特徴
・相手の発言を信用してないのに、何故か自分で探して確かめようとしない
・分からないことがあると煽れば相手がムキになると思い、すぐ教えてくれると思っている
>>303 大規模だろうと、新規案件でそんなCPも保守の効率も悪い提案通らねぇけどなw
おっさんのC言語云々てテンプレ発言もそろそろ飽きたわ
>>309 Cうんぬんは別として、本体いじるのはデメリットの方がはるかにでかいわな。
セキュリティアップデートがあった時とか悲惨
>>310 探して見つかるわけがないだろ。お前の虚言妄言なんだからそもそも存在しないもんな。
だからお前はソースを出せないんだろ。
まだ言ってるよｗｗｗｗｗｗｗｗ
まあ、古くからの会社なら、部分的に自社のライブラリを使うような、オレオレバッチファイルをアプデの度に当ててる所も多いだろ。
本人がソースコードを改変して使うことは無いと断言してるんだからそれでいいんでないかな
一生そういう狭い考え方をしてれば
大規模って前提があるから、僧いう事するところは少なくはないって話でしょ
省きたい処理やネイティブで処理させたいことなんていくらでもあるしな
そんなとこねーよ
個人の趣味の範囲ならともかく大規模こそないわ
それだけのコストに見合ったメリットを説明できないと本体に手を入れたいなんて提案通らないだろ
何人か言っているようにCで作った独自ライブラリを使うとかならわかるけど
もうそれでいいよループするから
ループが嫌ならソースだせよ
自分の脳内妄想を否定されると、相手を悪く言う不思議。
企業はどこもそんなに暇じゃないよ
オレオレソース保守管理に人件費かけて、更なるメンテに金かけて
ってアフォな企業を早く知りたいものだｗ
>>324 いい加減教えを請われてるんじゃなくて虚言癖を指摘されてることに気付こうぜ
レベル低い同士頑張れや
しかしさ、CI系とCake系の違いってなんだろうね。CI系で充分効率いいと思うをだが。Cakeとか覚える事一杯あっても、ちょっと便利なコマンドがつかえるくらい。
小波はドラコレでPHP使ってなかったっけ
たぶんぐぐれば講演レポが出てくる
大規模でPHP使ってるとこは大体ソースコード自体をカスタマイズして使ってると豪語した人、
早くこれの情報源を
何社ぐらい調査したのかもよろ
CIは縛りが緩い
cakeは縛りがキツイ
大人数で作業するなら縛りがあるほうがいい
少人数で作業するなら縛りがないほうが楽
>>332 そんな偉そうな態度で知識の浅い人に親切に教えてくれる人はいないよ
逃げちゃったんだよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
言いだしっぺ逃亡につき何一つソースも無く誰もわからないまま幕引き
うん、それでいいっす
こちらは教えても特無いからね
きっと逃げ足速い人は、大規模でPHP使ってるとこほとんど回りつくして
ソースコードレベルで確認できる立場の大人物なんだよ。
コンサルティングとかだとソースコードレベルまで見れないかもだからハイパーメディアなんちゃらとかいうやつだな
>>310=334さん意外誰も知らない、いくら探しても見つけられないソースを出すことで、
この不毛な争いに終止符をうつことができるんです。
探せないって言ってるくらいだから、きっと探せばソースはあるとおもうんです。
>>310=334さんだけが知っているその記事、是非拝見したいです。
それともくだスレで質問すれば出てくるのかな？
虚言じゃなければきっと誰か知っているはず！
SilexとSlimだったらどっちがいいんかなあ
そうか、SymfoとかCakeとかYiiのいいところって、縛りがキツいから、誰がどう書いても、同じような仕上がりになる所なのか。
cake…？
Zenderのわたしがやってきましたよ(´・ω・｀)
343 ：
nobodyさん：2012/03/03(土) 23:38:00.10 ID:wGPoNHA5
なるべく息が長くて、個人の開発者に依存してなくて、下位互換性に重点が置かれるフレームワークが
一番いいと思うよ。
>>338 虚言癖のある奴とは距離を置いたほうがいい
大手は知らんが
APCとapacheは手を入れてる
各々二台だけど
荒らしが丸一日相手にされてなくてフイタ
相手してるじゃん
PHPはソースコードなんていじりません
↑
そこまで否定するならこれを実名で講演会で発表してもらいたいよなｗ
具体的に何をやるかってのがないから、自分とこは手を入れずに使ってるけど
手を入れたいところが出たときに手を入れるのは普通にやるかなー
そういうのは、会社の技術レベルや仕事の内容の問題だと思う
委託とかなら他に責任があるとこには手を出すことはしないだろうし
自社サービスとかなら、手を入れたほうがいい部分には手を入れる
こんなの真新しいことじゃないし、そもそもフレームワークでもないから
引っ張る話題じゃないと思うけどなｗ
まだ言い訳してんのか虚言壁さん
>>350 お前も何時までも見えない敵と戦いすぎ自重しろ。
むか～し、MidgardというCMSだかフレームワークだかあったが、それがextension必須だった気がする
面白そうだったから後でいじろうと思って放置してたが、最早探そうと思って検索してみてもロクな情報出てこないな
長文書く暇があるならURL貼りゃいいのにｗ
煽る暇が（ｒｙ
煽るってか、少なくとも教えて君には得がないから教えないって秘匿してる
ソースに興味があるからなｗ
損得気にするくせに
>>349みたいなしょうもない長文書くのは滑稽だろ
ここはいつしかソースを１つも明示せずに、妄想を膨らませるスレとなった
すげ、何日粘着してんだよw ネクラにもほどがある。
自分で探しきれなくて追い込みに入ってるんだよ
たった去年の年末に出た情報も探せないとかゆとり過ぎる奴はほっとけ
構うと調子に乗るから飽きるまでスルーしとくのが一番
そういう話にもっていくしかしのぐ手立てないもんなｗｗｗｗｗｗ
こういう教えて君ってどうせWindows+XAMPPでしか使ったこと無いようなカスなんだろ
>>338が知らない＝＝皆知らないとかｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
マジキチｗｗｗｗｗｗｗ
技術系のスレッドでも
ただただ他人を馬鹿にするためだけにレスする人増えましたよね
ｽﾄﾚｽぶつける場所はいくらでもあるでしょうに。。
なんていうと2ｃｈだからどうこうっていう人いるけど
技術系はそうではありませんでした
煽りつつもなんとなく正解を臭わせてもらってましたよ
なるほど、これの事か
知らないくせに偉そうに聞くほうが悪い
２ちゃんだろうが現実の社会だろうが変わりは無いな
知らないのに最初から否定してきて、教えて貰うまで煽るような人間は誰も教えたがらないしな
そんな人間にわざわざ教える意味なんてない
なんか郵便受けにつっこまれてた宗教の本に同じようなこと書かれてたな。
大宇宙について人類はほとんどわかってないのに、なんとか神の存在を
なぜ否定するのかとかｗ
vs Mr. Unknown.
レスが伸びたと思ったらまだ情弱が書き込みしてたのか
371 ：
nobodyさん：2012/04/02(月) 05:09:08.25 ID:IFAunYHl
>>371 そもそもSmartyってFrameworkに分類されるべきものなの？
自らTemplate engineと言っているよね
cakePHPやSymfonyのような機能が豊富なFWと比較することに違和感がある。
>>372 うん、時々見かけますが、わたしも違和感があります。
ただ、やむなく広義に含めるのも場面によっては仕方ないかと。
たとえば
>>371は、質問総合スレみたいのよりここの方がふさわしいと思いました。
テンプレートエンジンスレのひとつもあっていいとは思うんですけどね。
cakeとかのせで、生phpで書くひとが増えたのかな？
>>373 cakePHPやsymfonyといったフレームワークに
テンプレート機能があるからsmartyをわざわざ使う必要、覚える必要が
なくなったってのは十分ありえる理由だと思う。
海外では日本ほど人気ないらしい、smarty。
<?php echo $var; ?> とか視認性悪いと思っちゃうんだけどなぁ。
長さが気になるなら <?= $v ?> でいいじゃないか
長さをつきつめれば {$v} になるじゃん。
単純な文字数もそうだけど、書式そのものの気持ち悪さというか。
まあ、確かPHPの \(名前空間) だか :: も外野の評判は悪いんだっけ？
そう考えると、慣れの問題もあるのかなーとは思う。
てか default_modifiers についての話をしたかったんだけど…ｗ
文字列接続の . とかもぶっちゃけると気持ち悪いよな
Smartyはテンプレートの域を外れてしまってるからな。
っつか、俺の考えだと、Smartyがウケのはデザイン側じゃなくて主にプログラマ側で、単にコンパイルする、というコンセプトが面白かっただけだと思うよ。
初心者はSmartyじゃなくて、phpLib時代のテンプレートとか、もっとシンプルにデザインとプログラムの分離を目指していた頃のテンプレートエンジンから学ぶべきだと思うんだな
最初くすぐったがってるけど、だんだん口数が減り息が荒く…みたいなのは割と見かけるきもする
あらやだ酷い誤爆
どこの誤爆かkwsk
初めてwebprog板に来たんですが、ここではdoophpはどういう評価ですか？
高速性が2chのイメージ的に受けそうな気もするのですがテンプレにもないので
PHPはポンコツ言語だから高速化は期待できない
終了について特に異議もありませんでした
Googleトレンド以外で、
PHP Frameworkのマーケットシェアのデータはあるのかな？
Symfony, cakePHP, Zend Framework, CIの勢力図はどう変化してるんだろ
このスレは終了しました
このスレが再開しました
Phalconって言うC extensionで書かれたPHP用のフレームワーク見つけて、
今、ドキュメント読んでるけど、ベンチマークが半端無くすげえ。
http://phalconphp.com/documentation/benchmark phpのフレームワークで同様の処理をさせてみた結果。（速さは重要じゃないと言いつつ）
Yii (YII_DEBUG=false) Version yii-1.1.10.r3566
-> Time taken for tests: 1.469 seconds
Symfony Version 2.0.11
-> Time taken for tests: 8.105 seconds
Zend Framework Version 1.11.11
-> Time taken for tests: 4.264 seconds
CodeIgniter 2.1.0
-> Time taken for tests: 1.184 seconds
Phalcon Version 0.3.1 <- こいつ、桁が違う。
-> Time taken for tests: 0.385 seconds
Zend Frameworkの１２倍の速さ。さすがC/C++のネイティブコードは段違い。
自分で作ろうと思ってたけど、同じこと考えてる人は世界にいるのね。。
Phalcon良いわ。発展途上なのが理解しやすくて良い。
あとはバグがどんだけあるかって感じ。
ざっと読んでみたけど、弱いのは以下。
・DBの抽象化やってるけど、
adapterが今んとこMySQLしかないから、事実上DBはMySQL固定。
・Layoutとパーシャルの使い方がいまいちわからない・・・。
全体的にviewの説明が不足してる気がする。
・ACLはあるけどAuth系が無い。まあ、俺は不要だけど。
・キャッシュ用のクラスがあるけど、キャッシュ先は現状ファイルだけ・・。
・理由がわからないけど、スケルトンツール使うならPHP5.3.6推奨。
テンプレート作るのにPHP関係無い気がするから、出来そうだけど。。。
・APIの説明がほとんど無い。
・多国語対応が無い。
他は概ね、ZFを弱くした感じ。
DBもフィルタにサニタイズにエラーチェックにJOINも可能で、これならぎりぎり使える。
392 ：
nobodyさん：2012/05/07(月) 20:01:14.71 ID:UtpQziV0
CMSで作るのとフレームワークで作るのと
どれくらい自由度や制作効率が違うのでしょうか。
>>392 まじで聞いてるの？
CMSは自分でプログラム書く必要ない。
誰でも、ある程度自由に
そのCMSがテーマとするコンテンツを作れる。
フレームワークは自分でプログラム書く。プログラム作成の補助機能。
よく使う処理の部分は、ワークフレーム側でプログラムを予め書いておいてくれる。
プログラム書く人が楽できる。
よくわからないならCMSが良いと思うよ。
CMSに乗っかるプラグインやら何やらのシステム開発したけど、ありゃ苦行だよ。使い回しする予定なら良いけど、無駄に考える事が多くて、開発に集中できない。
395 ：
nobodyさん：2012/05/09(水) 13:46:54.03 ID:SZ6jgFk0
基本機能と既存プラグイン調べて、自分の要件に合っていればそれでいいのでは？足りない機能はFWでもプラグインでもAPIに沿って組むのは一緒だから、コスト計算同じだし。
394だが、
プラグインが客の要望に微妙にマッチしていなかったり、プラグインごとの操作感の違いだったり、完全にそのまま使えるって事はほとんどない。
ごり押しできる立場にいるなら、もしくは自分とごく内輪で使って、文句言わせない状態なら良いけどね。
>>395 自分も前にCMS(Drupal)使うべきか悩んだ。
WordPressは設計が悪くて有名。
もうWPのブームはとっくに終わってる。
日本は遅れてるからWPだけど、海外ではPHPではDrupalとかが主流。
で、Drupalは、そのフレームワークにSymfonyを使ってる。
Drupal機能そのまま使えるってことはまずない。
ちょっとデザインいじろうとすると、DrupalとSymfonyの知識がないといじれない。
Symfonyの知識を身につけるだけでもたいへんなのにそのうえにDrupalスタックの
勉強も必要。
自分で好きなフレームワーク覚えて、それで作るほうがはるかに楽という
結論に達した。
カスタマイズが必要ならCMSは逆に時間がかかって非効率。
まず一番機能が豊富で人気があるといわれるCMSのDrupalを使ってみるといい。
CMSでは特に画面のデザイン、レイアウトは柔軟にはいじれない。
399 ：
398：2012/05/10(木) 07:48:29.65 ID:???
中途半端なんだよな
そこまでするなら、もうJavaがいいのでは？
ＰＨＰだＣだって言ってる奴いるけど、パフォーマンス気になるなら
鯖分散すれば良いだけじゃないの？
１モジュールのパフォーマンス上げようってのは、ｗｅｂ開発では
あまり意味なさないと思うんだけど。
もちろんxdebug程度は使いこなせた方が良いとは思うけど。
随分長いことパフォーマンスの話はでてないが。。
>>401 Performance考えたらJava, C#のがいいだろうね。
JavaはSpringがめんどくさいと言われてるので手を出してないけど、
フルスタックのPlay! Frameworkもさわるかも。
Rubyは速くないけどRuby on Railsが有名だからいじり始めたんだ。
Tutorial終わったらさようならするかもしれない。
Pythonは欧米でかなり人気だからいじってみたくなって・・ｗ
PythonのFrameworkはDjangoのヘルプを読み始め。
Java並の速度で、簡潔にかける言語と、Railsのようなお手軽な
フルスタックフレームワークがあればいいけど、まだ見つかってない。
>>402-403 そうは言ってもパフォーマンスが原因でJava系に移行する企業増えてるみたいよ。
RubyをやめてJava系にしたTwitterとか有名だよね。
動けばいいじゃないって人もいるだろうけど、どうせ作るなら
速く動いたほうが気持ちいいよね
railsは論外だな。あれrakeが遅すぎて使い物にならん。
>>404 長々と書いて結局「コンパイル言語は速い、スクリプト言語は遅い」かい
自分の言いたい事だけ言って、他人のレスは一切読んでないからパフォーマンスだの言語の話になるんだよ。
ちなみにDrupalとJoomlaのどちらもクソだと思う。上の人には悪いが。
>>407 「自分の言いたい事だけ言って、他人のレスは一切読んでない」っておまえのことだろ
質問者がCMSを検討してるから、>399有名どころのふたつをあげて、
要件を満たすかどうか、まず試してみることを勧めてるわけだろ。
本人はCMS使ってないって書いてるしな
質問者に何も情報をあたえてないおまえのレスのが間違いなくクソだ。
何が嫌いかより、何が好きかで自分を語れよﾄﾞﾝって、ルフィさんが言ってた。
>>408 すでにその前に書いたし、俺は他人を簡単にクソだと言う奴にどうこう言われたくないね。
PHPで速度語るならPhalcon使えよ・・。
Cネイティブだぞ。Javaの１０００倍以上高速で動くんだぞ。
まあ、フレームワークの部分だけだけど。
複数言語が入り混じるFWは使いづらそう
PHPな時点でCが絡むわな
前から疑問に思ってたんだけどWebサービス云々でPHP自体がボトルネックになることってあるのん？
100%張り付いたから同じ構成のFWを別の言語にしたら30%になりますた！！みたいな事がさ
>>398 > で、Drupalは、そのフレームワークにSymfonyを使ってる。
こんなの初めて聞いた。別のものと勘違いしてない？
>>415 トップページに出てる。
http://symfony.com/ Drupal, one of the world most popular Open-Source content
management platform, uses the Symfony Components as of version 8.
DrupalがSymfonyアプリケーションって感じではないんだな
>>412 Cは使わない。Cで書いてあるコードを呼び出すだけ。
PECLやZend APIと同じ。
>>416 クラスローダーとHTTPリクエスト/オブジェクトにSymfony 2のそれを使おうぜって話が出てるだけで
それすら約2年弱あるリリースまでに変わるかも知れないものだぞ
420 ：
nobodyさん：2012/05/31(木) 15:38:56.92 ID:IzK2Xy2G
CMSでも本来のプラグインとかを使わず、
フレームワークとして使えるって本当ですか？
問い合わせフォームの面倒な部分はCMSにまかせて
自由度の必要な場所はMVCフレームワークのごとく
つかえるみたいなんですが・・・。
421 ：
nobodyさん：2012/06/05(火) 07:52:11.09 ID:YB7szyDX
422 ：
nobodyさん：2012/06/08(金) 01:44:01.85 ID:EOwIYA3r
PHPでアスペクト指向フレームワークはありますか？
「下らなぇ」スレで聞いても返答はありませんでした。
Seasar2.PHPかSymfony2
下らなぇスレを責任持って立てろ
アスペルガー
上の方で学習コストの話があるけどさ、
学習コストの低いフレームワークを選択して足りない機能がでてきた場合は
自分でコーディングすることになるわけじゃん？
ある程度スキルのある人なら問題ないだろうけど、初心者が調子乗って
拡張機能つくってもろくなコードにはならんぜ。保守性・安全性の面で。
427 ：
426：2012/06/08(金) 19:49:09.78 ID:???
大抵はあとで別の人間が書き直すハメになって、
最初からちゃんとしたフレームワークつかっておけばよかったね
ってなるというおはなし
連投そまそ
でも作る経験は財産になるから難しい
アスペクト指向プログラミングはどうしていますか？
でも機能豊富なゴテゴテしたフレームワークを選択しても
スキルの低い人は、理解できない使いこなせないで
結果ものすごいものが出来上がるというのも
よくあるおなはしなわけで。
機能豊富なフレームワークで、そのご自慢の機能使おうとしたら
まともに動かなくて、結局自分で書く羽目になるというオチ
俺はCakePHPでそれくらった
432 ：
nobodyさん：2012/06/09(土) 19:38:34.84 ID:3pAJ5sr2
1. (自分のスキルがしょぼいせいで)まともに動か(せ)なくて
2. (自分の使ってるサーバーがしょぼいせいで)まともに動かなくて
3. (ご自慢の機能が実は自分の期待よりしょぼかったせいで)まともに動かなくて
で？
感覚的な学習コストの序列ってどんな感じかね？
個人的には
code igniter << Yii < Cake PHP < Symfony
と言う感じだが、最初に触ったのがSymfonyだったから思い出補正あると思う
どういう序列なんだ？Symfonyが一番簡単って意味か？
コスト低 <- ->コスト高 ね
Cake PHPやSymfony って情報量多いし、学習コスト低いと思うんだが。
ciなんて作りが雑過ぎて、その分をフォローするための学習コストが多すぎる
オレオレと変わらないからな
他人が作ったオレオレフレームワークだな。
学習コストねぇ
有用なら高くても使うがね
学習コストは人によって違うからね。
有用でも情報量が少なければ理解するまで時間がかかるし、
そう言う面で学習コストがかかるならマイナスだよ
何をもって有用とする？
それも人それぞれでしょ。
個人や少人数でやるなら好みや感触で決めてもいいような気がするけど
多人数チームでやる場合はほんと悩ましいよね・・・
そもそもPHP自体が、使いもしない要らない機能だらけで、有用ではない
ガラパゴス化している日本人にピッタリじゃないか
447 ：
nobodyさん：2012/06/12(火) 09:46:48.90 ID:Yrv/uaCb
検索エンジン等、動的部分はフレームワークで、
会社概要等、静的な部分CMSにまかせるってどうなんでしょうか
作り方が異なるファイルが混雑するとややこしくなるよ。
静的な部分もフレームワークで作った方が良いと思う
プログラマが更新するか、
デザイナーも関わるか
デザイナーが関わるのは無理だよ。むしろ関わらせちゃ行けない。
デザイナーもグラフィカルに編集できるものを目指してるんしゃないのか
452 ：
nobodyさん：2012/06/12(火) 19:50:03.28 ID:Yrv/uaCb
CMSがフレームワークに置き換わる日
http://blogs.itmedia.co.jp/yoshimasa/2011/06/cms-f1f8.html 今の時代、フレームワークを土台にして作るのではなく、
CMSを土台につくったほうがいいんですかね。
フレームワークも便利ですけど
RSS発行とか、フォーム作成とか
自分でプログラム組まないとだめじゃないですか。
フレームワークでは数時間かかるRSS発行処理作成とか
CMSでは数クリックでできるし
処理されたデータを、どう煮るか焼くかは
CMSもフレームワークも変わらないし。
ただ
>>393さん
みたいに、高度な改変となるとCMSは
プログラムの解析が大変という意見もありますし、
何を作るかによってかわってくるんでしょうが
フレームワークに自作関数や、自作ライブラリを相当作りためてでもいないかぎり
ＣＭＳを使ったほうが効率がいいんですかね。
プログラミングができない人から見るとそうなのかもね。俺は全く別物だと思うけど。
CMSで事足りるならそれでいいのではないかと。要件を満たすかどうかの問題。
フレームワークは高機能で便利な魔法のツール、みたいに思っているのかもしれないけど
それ以上に大事なのは、制限やルールといった枠組みを与えることで、
人それぞれバラバラになりがちな開発の手法や方向性を統一できること。
って誰かえらいひとが言ってたような気がする。
表示系はなんとかなるけど、
DBから取り出す条件設定の制御が面倒な事多くね？
クエリ直接書かせろ！みたいな…
官公庁はCMSが主流
オリジナル要素が高くなければCMSで良いかもね
CMSが勝手のいいフレームワークで作られていれば良い
WordPressやEC-CUBEがが使いやすいMVCフレームワークで作られてればよかったのに…と何度思ったことか
カスタマイズつらいです…
ワープレって、MVCじゃないのか。
MVCじゃなかったらプラグインひとつ作るのも
かなり手間かかりそうなんだが・・・。
違うね。共通ファイルは分けてるけど、細かくビュー分けはしていない
EC-CUBEは独自フレームワークだけど、
こちらも複雑すぎてどこがどこにあるかわかりづらい
複雑ってのは俗に言うスパゲッティってことだな
そうそう。EC-CUBEは色んな開発者が共同で作ってるらしいから
どうしてもスパゲティになるよね
EC-CUBEはソースひどいよな。トランザクションとかちゃんとしてなさそうだし、いくらでも穴がありそう。
// これで勘弁してください…
的なコメントが書いてあったりするし。ジョーク系のサイトでよく似たネタ見るけどオープンソースでは初めて見たわ。
ソースの具体例は？
>>463 ＞色んな開発者が共同で作ってるらしいからどうしてもスパゲティになるよね
いや、その理屈はおかしい
>>466 おかしくないよ。だって規約が統一してないんだから。
開発者が違うって言っても社内じゃなくて、他社って意味だし。
スパゲティの意味をまずわかってください
>>467 外部の異なる組織からフリーランスまでさまざまな開発者が
参加して作ってるオープンソースソフトなんて山ほどあるんだが
さすがにそれらのほぼ全てがスパゲティだなんて話は聞かないよ
>>469 ほぼ全てのOSSの話しじゃなくて、あくまでEC-CUBEの話しな
どうしてもスパゲティになる
を他のソフトにも適用するのはやめたまえ
なんで他のOSSが大丈夫で、EC-CUBEだけ
スパゲティになるんだよｗ
いやぁ、WordPressのごちゃっぷりは良いレベルよー
PHP自体がスパゲティだよ。
標準関数の首尾一貫性の無さはスゴすぎ！
>>472 普通、OSSって特定のグループ・会社が作ってないか？
OpenPNEなら手島屋って会社が作ってるし、
phpBBも海外のグループが作ってたはず。
一方、Wordpressは開発者はいるけど
プラグインで拡張していくから開発者も違うし、一貫性がない
すべてのOSSを調べてから言えよハゲ
OpenPNEもひでえソースだったなあ
OpenPNEのカスタマイズは断念したな
479 ：
nobodyさん：2012/06/21(木) 08:17:09.84 ID:9C4PuuPO
逆に、このフレームワークは美しいソースだったなぁってのはないの？
symfony2
ソースの見てくれの代わりに使い勝手が犠牲になったけど。
PHP自体が美しくない
そもそも「美しさ」の感じ方は個人差によるからな
EC-CUBEは番人に共通する醜さだけど
EC-CUBEはあんなソースでそこそこ動いちゃってるのが不思議なくらいだな
管理とかちゃんとなってない会社なんだろうな
スキルの低いエンジニアが会社の床で寝ながら泥沼のようにして作った印象
あのスタイルで書いたコードのデバッグをやりきるには大変な根性が要るはず
俺の見立てではわざとやっていると思う。
OpenPNEもそうだけど、わざとソースを複雑にして
有償サポートを狙っている気がする
※あくまで個人の感想です
PHPが汚いとえば
文字コードを変換する
mb_convert_encoding の配列版はないかいな思って調べたら
mb_convert_variables という関数を見つけた。
早速使ってみると、ちっとも機能しない。
なんと、
mb_convert_encoding は変換したいソース元を第一引数に入れるけど
mb_convert_variables は 第三引数にいれるという仕様！
そして
mb_convert_encoding は、
$hoge = mb_convert_encoding みたいに再度代入してやらないといけないけど
mb_convert_variables 代入しなくてもよいという仕様！！
そもそも mb_convert_variables というネーミングセンスなんなの?
mb_convert_encoding_array とかにでけんかったの？
>>485 実は確かな技術を持った賢い集団で
自分らの開発は綺麗なソースで行い、リリースの際特製コンバータを通すと
あら不思議、ぐちゃぐちゃスパゲティコード＆意味不明コメント入りオープンソースのできあがり
てな感じか
一貫性のなさはPHPの悪習
名前の付け方も引数の並べ方もこの上なく下手糞
Zendは綺麗、それとDrupal
>>487 俺の場合とは異なるかもしれないけど、
外部に公開するソースは難読化してるわ。コメントも削除してるし。
PHPの難読化ツールでおすすめのある？
安ければ無料じゃなくてもいいけどなるべく無料で
Zend Guardかbcompierくらいか
494 ：
nobodyさん：2012/06/22(金) 08:55:26.21 ID:LmibApcQ
オープンソースです!!って謳うだけでもたらされる効果ってのもありそう。
FREE商法の一種だからな
頭の中がぐちゃぐちゃなのを晒すだけ
オープンソースです！
↓
SEX
こういうわけだな
>>486 そこら辺は俺も学習時に感じたなー
PHPの初期に引数の順番や命名規則を統一していなかったら
もうどうしようもないよね。
PHPは馬鹿が何も考えずに作った言語だからな
どうやらこのスレには天才がたくさんいるらしいから
後世に残る画期的な言語が生まれるのも時間の問題だな
implode
explode
がその例
俺が考えた馬鹿が使う為の言語
間口を広げたら書かれたコードも多種多様となって理解するのに能力が必要に
書く時もその場の乗りで動く状態に出来ちゃう
自然言語を適切に解釈してくれればいい話
504 ：
uy：2012/06/23(土) 13:36:42.79 ID:???
ゴミ
それでもこんだけ広まってしまったんだから使い続けようや
ただし別ブランチで「きれいなPHP」というものを作って
そちらに乗り換える方向がいい
というわけで誰か作って
array地獄がなくなった5.4が普及したら本気出すわ
507 ：
uy：2012/06/23(土) 18:09:11.12 ID:???
きれいなジャイアンのどこがいいんだ？
5.4でarray地獄って解消したっけ？
509 ：
nobodyさん：2012/06/25(月) 16:36:33.93 ID:7BNFjCsx
配列地獄ってこういうの？
foreach($hogehoge['hage'][55]['fuge'][3]['view'] as $key => $value){
foreach($value[$this->row] as $key => $value){
$splited = split($value['hogehoge']);
}
}
echo $splited[4];
単にarray()て書き方がうっとうしいってことじゃないかな。
5.4なら[]って書けるし。
設定のためのarray(array(array(array())))みたいなのがなくなるのか
あれあれあれあれあれ～？
CakePHPも配列多いね。中途半端なオブジェクト指向で気持ち悪いし、非効率。
今CakePHPを使うのは保守くらいだろう
自分出作るのにあえて選ばない
俺はあえて選んでるけど
しばらく使い込んじゃって慣れちゃったから
つい新規の案件もCakeで作っちゃう
乗り換えるとしたらYiiがよさそうだが学習コストが読めなくて躊躇している
フレームワーク使う規模の案件にはPHPは使用しなくなった。
じゃ、なぜこのスレ見に来てるの？
みんなにも「使うなー」って言いに来たのか？
>>518 そういうこと。
仕事ではPHPは単なるテンプレート言語になった。
日本語で尾k
OOPフレームワークでオススメはありますか？
配列地獄は勘弁です。
CakePHPは配列地獄だから、Akelosに移ったという話は見たことあるからそっちがいいんでね？俺はいじった事ないけど。
実際にいじった中では、Pinocoくらいがライトでいいと思ってるんだがまぁ、Symfonyも悪くない選択だと思う。
使えるようになるまでの学習量が半端なく違うけどな。
よほど大規模なければ機能過多だと思うんだ
別に学習しなかったらしなかったで、その分を自前実装するだけなんだけどな
symfonyはダメ。OpenPNEのプラグイン開発でよくわかった。
で、うちはPHPから可能な限りオサラバすることになりました。
よかったね、おめでとう。
俺のとこの会社もPHPから離れつつあるな。
きっかけはVPSの普及やな。
何に移行してるの？Java？
その次がMonoでその次がCobolだな
一回離れたけど、意外とメモリに対してのパフォーマンスが良くて結局PHPに戻ってきた
apache+mod phpはVPS程度の小規模じゃ地味に優秀なんだよな。
浮いたメモリ分をデータベースに割り当てたほうが結果パフォーマンスが上がる
メモリやら鯖のスペックは気にしなくても良いレベルまで来てるからな
処理のパフォーマンスよりも、「いかに早く作れるか？」が重要だろうし、
その点でPHPは優秀だからな
＞メモリやら鯖のスペックは気にしなくても良いレベルまで来てるからな
それはないｗ
サーバーのスペックをどこまで意識するかはアクセスされる数ややる事次第だしな
いかに早く作れようとも、クソコード書いてたら保守でぐだってあいつはダメだって評価になりかねない
自分の仕事としては作りっぱなしのものであっても、最低限の事はできてないと
クソコーダーだってが露見する可能性が常にある状態になるから、流石にアレ
PHPは糞コードを量産しやすい。
糞コーダーが多いだけで、そいつはどんな言語つかっても結果は同じ
とか言ってる奴のコード見るとスパゲティだったりするんだよなw
お前の場合は頭の中がスパゲッティだな
お前の脳はアイスみたいに溶けてるけどな
だからPHPは言語自体がごちゃ混ぜスパゲティだって！
htmlspecialchars
糞関数名の代表
541 ：
nobodyさん：2012/07/07(土) 16:36:29.58 ID:8jbUotM9
h()
えっちなのはよくないと思います！
hnano()
個人でiphoneアプリ、Windowsアプリをマーケットに売って生き残れ
格安iPhoneEラーニング(学習動画多数あり)
http://tinyurl. com/7wj77om
コワーキングスペースJP
http://tinyurl. com/76vdrny
コワーキング帳
http://tinyurl. com/brzs486
javaやlinuxは手間がかかる 一人でやるには手間がかかりすぎる 手間がかからないで一人で開発できて
人の多いところで直接販売できる仕組みが提供されているメーカ製の言語だけやる ずばりiphone またはWindow 8 Metro App Store C#
やるならメーカー製の言語 洗練された仕様 脆弱性が少なく 開発ソフトが優れ 課金ライブラリ アップデートライブラリが提供されていて 情報、書籍が多く開発しやすい
奴隷になりたければオープン系をやればいい 時間がかかり 人は多く 仕事の取り合い 足の引っ張り合い 脆弱性が多く 互換性がなく 癖があり 大規模開発中心
詳細設計しかやれない体になって年取ってぽいだ 独立もできない 手間のかかりすぎる仕様だから
派遣屋 IT経営者はその方が喜ぶ 大規模分割開発では使い捨てしても独立はできまい 代わりはいくらでもいる 嫌なら辞めろ
若い派遣営業は舐めた態度をとってくる ひどいピンハネ
オープン言語、日本独自開発言語・フレームワーク ガラパコ携帯 javascript html5 android java linux python rubyやnode.jsとかやめとけ
メディアに金を払ってステマ宣伝してくるが釣られて手を出しても情報は少なく手間がかかりスパゲッティコードで未完成 デスマに陥る
コンパイルできないからパクられ 直接売る場所がないから企業に買い叩かれ金にならない 生きれない ずっと奴隷仕様のままだ
ここから抜け出すにはiPhone一択 またはWindow 8 Metro App Store(未確) C#
Objective-CやC#を覚えるとサーバーサイドからクライアントサイドまでカバーでき人の多い場所でソフトを売る権利を得られる
仕事や趣味でObjective-CやC＃を覚えれば派遣切りされても会社辞めることになってもソフトを売って生きていける それはセーフティーネットになる
WEBサーバーIIS Win2008ServerVPS SqlServer Oracle MySql 言語はマーケットで売れるメーカー製のみ C#は自分用業務支援ツールとして使える
例えばPHPでWEBアプリを作っていて管理者画面はC＃(EXEアプリ)で作るとかなり早く作れる（Smartyなんか使うよりもかなり早くだ）
ASP.net(C#)+管理EXEアプリ(C#)+iPhone C#のソースを出さなければWEBアプリの著作権も守れる
C#マーケット Windows8 Metroアプリ WindowsPhone pad PS Vita Xbox360 iphone(mono使用)
iPhoneマーケット iPhone iPad 予定 iTv iCar i (家電製品)
地方に安い土地を買いコンテナ型の格安高性能オフィスを建て(300万～500万)
レンタル自習室＆シェアオフィス・コワーキングで収入を得ながらそこでアプリを開発する
http://tinyurl. com/7pb2yaa
http://bit. ly/iLIpJa
これからPHP始める他人に1つ勧めるならCake2.xですかね？
symfony2も人気あるようですが、嫌ってる人も結構いるので
Cakeが一番無難かなと思うんのですが、どうでしょう？
Cakeとsympony、ファイル多すぎ。
549 ：
546：2012/07/21(土) 20:26:04.02 ID:???
国内人気、日本語情報量、レンタルサーバーCGIで使いづらい～とか
全体を見てとにかく無難なのがいいのです。
一端全部触ってみるのはきついです。
>>548 Zendとかに比べて設定ファイルが多いのですか？
設定するファイルは多くないけど、構成ファイルが多い。
作法にそって作る場合はよく考えられてると思うけど、
ちょっと流儀から離れた場合に面倒なことが多いと思う。
フレームワーク一般てそんなもんか。
PHPならではだと思うよ。
これからならYii一択ではないの？
そうでもない
>>552 よう知らんのですが、rubyやpythonのだと、違うの？
Yii普及しないとおもう
新しいこと覚え切れないおっさんには辛いだろうから、下請けに投げたらcakeとか使うんじゃね
なんでおっさんなの？普通、若い子がプログラミングするだろ
若い奴の書いたプログラムなんて、危なっかしくて使えるか
どっちもどっちだな
年齢は全然有益な情報にならない
持ってる知識とかどれくらい興味をもってるかあたりが全て
年齢は関係ないよね。キャリアも関係ない。
fizzbuzzは多少あるっていうか足切りにはなるよね（ならない？）
で、色々あるけど、やっぱりYiiがいーんじゃないか？
Yii選ぶならオレオレの方がマシ。情報量が少ない
新しいけど、fuelphpとかは？
というかPHPはフレームワークに向いていないかと。
俺々は仕事では100%聳え立つ糞
読めない
ただでさえ実行速度が遅くのにフレームワークを使ったらますます遅く
フレームワーク遅くなるのはORMだろ？仕方ないさ。
View+ControllerとModel(ORM)でフレームワーク分かれててほしいとは思うな。
ただでさえメンテ効率悪いのに、フレームワーク使わなかったらますます悪く…
PHP使わなければいいんだけどな。
VSP環境であればうちはPHPは使用しない。
従来のレンタルサーバーであればPHP。
PHPはデータベース周りがクソだから仕方ないさ。
PHPの場合はORMというよりARMだよ。Aは配列。
Cakeは配列指向フレームワークだな。
それはJavaのHibernate(ORM)より
RubyのActiveRecord(ハッシュ？配列？)の方が人気があった流れで
そうなったんだからPHP利用者には受けがいいと思ったんだが、違うのか
＞レンタルサーバーであればPHP。
PHP使う理由ってこれしかないな
軽量とかいうけど、結局効率悪いし
「手軽に使える」ってのは最大の利点だと思うけどな
手軽って何？ hello world するだけならいいけど
Apache Moduleの設定とか含めたら未経験者は大変だと思うぜ
じゃあtomcat？
>>577 未経験者が大変なのはPHPに限った話しじゃないだろw
PHPなら簡単、手軽、軽量ってのが嘘っぱちということ。
一昔前はCライクなのでクラス使うJavaより簡単とか言われてたけど、
多くのフレームワークがクラスのない、オブジェクト指向ではない
古いバージョンのPHPを切り捨てたことでその欺瞞が明らかになった。
プラットフォーム（レンタル鯖）でJavaに対して優位、
政治的な力（世の中の利用者数）でPythonに対して優位だから
使われているのが本音でしょ。
なんだかんだで、PHPで作るのが一番楽だわ
それだけ
>>580 なんだかんだと駄目な理由を付けたいんだな
そんな奴がこのスレに用はないだろ
足軽女が来たのか！？
PHPのフレームワークはまともなものが無いと思っていましたが誤解でした。
PHP自体が難ありの言語のためまともなフレームワークができなかったのです。
もうちょっと美味しそうな餌を
餅に見えた
>>585 で、きみの考えた最強の言語は何ですか？
今世紀最強にしてファイナルアンサーはPHPです。
PHPを拡張したPHP++を作りましょう
PHPPP
PHPは完全に作りなおした方がいい。
別の言語使えよw
日本語操作関数が多くて便利なんだよなPHP
pythonはそのあたり結構弱い
その日本語操作関数がこれまた癖だらけ
そうでもない
phpは全部作り変えないとまともにはならないな
日本語処理に特に強いあらゆる文字コードにも対応できる言語を
日本人が作ればいいのだが
そんなの日本でしか使われない
何人が作ってもいいから、マルチ言語に対応してればいいだけ
PHPはダメダメ言語
rubuは？
rubuはうぶです
一旦ageる
symfonyは一体何がしたいわけ？
キャッシュいれても重すぎるよ。
symfony2が最強
ないわー。
このスレの結論として、
PHPはフレームワークを使うとますます重くなるのでフレームワーク不使用を推奨
最近鯖の性能が上がってるからかそこそこ動いちゃうよね
意外とチューニングなしでも運用できてるわ
フレームワークは非推奨になりました。
なんのこっちゃ
PHP自体が重いから、さらに重くするフレームワークを使うなど愚の骨頂
お前は少し体重を軽くしろよ
ＰＨＰ「もう食べられないよ」
重いだけなら状況次第では選択肢にしても良いのでわ
もう食べれないデブー
お前らが作るサイトなんてどうせ人なんて来ないんだから
重くても軽くても一緒だろ
特にセッションがどうのとか言ってたやつ
どうせお前のサイトになんか誰も来ないって
PHPフレームワークは非推奨という結論が出ましたか
お前らのプログラムが非推奨
もう、PHPにはプログラマーなんていらないよ。趣味で覚えたデザイナーだけで充分。
フレームワークが使えないのではなくて、技術者が使えないってのが問題
っていうか技術者と呼べるレベルの奴がほんと少ない
同僚のスキルの低さに涙出そう
PHPだから仕方がないかと。
>>622 スキルが低いのはお前だけ
そう、お前だけだ
ないわ
PHPerは技術者ではない。
フレームワーク上のプログラムが心配なレベルの人に
好きに作ってなんて言えない…
こんな所で愚痴ってるやつのスキルなど高が知れている
結論でたな。
PHPではフレームワークの使用は非推奨
そもそも、フレームワークフレームワーク叫ぶだけで、実用レベルでOOP使える奴が居ないんだよ。。。
PHPでOOPなんて学べません。実装自体が中途半端です。
OOフレームワークもありません。あるのは配列指向フレームワークです。
phpでオブジェクト指向とか言ってたら笑われますよ・・・
PHPはグローバル関数が1500個以上もある糞言語
OOPとはほど遠い
無能な奴って何でも言語のせいにするよねｗ
煽ることしかできないのかよ…
phpでも工夫次第でなんとかなる。
工夫しなければ論外
PHPで工夫？
ただの悪あがきだろ？
もともとポンコツ言語なんだから何をしようと無駄
そのポンコツ言語に興味持ってるんだろ？
バッドノウハウが身に付きます
cakePHPでcreateした後にsaveしてるんですが
常にアップデートがかかるのみで、インサートがされません。
どういった事が問題として考えられますか？
818 ：nobodyさん [↓] ：2012/08/13(月) 23:03:29.06 ID:???
cakePHP 使ってるんですけど常に行が新規追加されると思いきや更新されてしまいます。
しっかり、 create(); を挟んでいるのですが。
$insert_data = array(
'hoge' => array (
'id' => $login_user_id,
'name' => $post_name,
)
);
$this->hoge->create(); // ← 常に新規追加させる。
$this->hoge->save($insert_data);
819 ：nobodyさん [↓] ：2012/08/13(月) 23:06:25.32 ID:???
>>818 このスレは終了したので別スレで質問してください。
820 ：nobodyさん [mail] ：2012/08/13(月) 23:07:54.81 ID:???
>>818 hogeとか何の疑問も持たずに使ってるお前のような脳弱には無理
821 ：nobodyさん [↓] ：2012/08/13(月) 23:08:02.97 ID:???
>>818 このスレは終了。
【PHP】フレームワーク CakePHP 14ホール目【v2.1】
http://kohada.2ch.net/test/read.cgi/php/1335859124/ <link rel="start" href="file:///C|/Users/じゅん/desk/index.html" />
646 ：
nobodyさん：2012/08/26(日) 11:42:24.40 ID:7pnTNGfF
647 ：
646：2012/08/26(日) 11:47:13.14 ID:???
ドキュメント整備してないから
サンプルのindex.php見てね。
648 ：
646：2012/08/26(日) 11:51:35.31 ID:???
ちなみに公開はしてないけどCakePHPのレプリカで軽量な奴を作成中。
モデルの検索結果を配列じゃなくてオブジェクトを返すようにしてあります。
名前が嫌だ
>>646 シンプルでいいんじゃない。
EL式とか知らないけど、テンプレートとindex見るだけで何となく動きが見えるし、
そういった方では分かりやすい方だと思う。
SQLは利点がいまいち見えていないので、コメントなし。
あくまで個人的な要望だけど、
テンプレートが短く書ける仕組みとかあったらうれしかった。
651 ：
nobodyさん：2012/08/27(月) 00:41:12.51 ID:0d99xblq
> テンプレートが短く書ける仕組み
たとえばどゆこと？
メソッドチェーンとか？
現段階で他のテンプレートライブラリには無い利点は持ってないみたいだし、
個人的に欲しい物を上げようとしたら、短く書ける仕組み。
ただし、具体案はちょっと浮かばないんだけど
$_POSTを渡せばinputとかのname見て勝手に全部入れてくれたら便利じゃない？
まぁ、私が現在進行形で自作してるフレームワークのSmarty連携の機能なんだけど
いわゆるシリアライズ？
655 ：
646：2012/08/27(月) 11:40:43.07 ID:???
>>649 名前はまぁ確かに微妙だとは思ってる・・・
>>650 ご意見どうもです。
これはJSP2.0をPHPで再現しただけなんで
Java使いの人にはなじみやすいかなと。
2Way-SQLはまぁせっかく作ったので公開しただけですｗ
656 ：
nobodyさん：2012/08/27(月) 14:37:12.80 ID:0d99xblq
>>652 $user->foo->bar って書式？これそもそもPHPの文法的に許されるんだっけ。
許されないとすれば、そういう書式を許す独自ファイルタイプ作ってパースする…なんてことじゃないよね。
>>653 > $_POSTを(どこに)渡せばinputとかのname見て勝手に全部(どこに)入れてくれたら便利じゃない？
テンプレート側のvalue=""内にデフォルト値として表示してくれるってこと？
>>653 それはテンプレートエンジンの仕事じゃなくて
フレームワークの仕事だと思うよ。
>>646 なるへそ。元Java屋にはいいかもしれんね。
ただ、SmartyやTwigはIDEのサポートが進んでいるからなぁ。
元Java屋でエディタ派ってそう多くは無さそう。
659 ：
nobodyさん：2012/10/08(月) 23:29:54.69 ID:WXDnX3pZ
無名なフレームワーク利用するのと、
オレオレ利用するのって大差ないと思うんだが。
暇だからチンパンジーのマニュアルを読んでるんだけど、説明が分かり難いと思った。
コンセプトは面白そうかもしれない。
チンパンジーって国産だけあって痒いところに手が届くな…
ガラケーサポートとか
あと軽量らしいし
アシアルへのリンク？
お前らサルにはお似合いだな
>>664 猿とチンパンジーは割と遠いんだけど・・・
>>659 version 1.0未満でfixってことはないよね？
いまどうなってるんだろう...
667 ：
nobodyさん：2012/10/12(金) 15:48:21.74 ID:Pt7Gt5Ms
>>659 Twitterも見事に停止してるな。
誰かフォローしてやれよ。
お前ら使ってやらないの？じゃあ俺が使ってやるよ！
669 ：
nobodyさん：2012/10/12(金) 19:30:08.83 ID:CFQsw2CA
>>668 ﾅﾃﾞﾅﾃﾞ ﾅﾃﾞﾅﾃﾞ ﾅﾃﾞﾅﾃﾞ
ﾅﾃﾞﾅﾃﾞ ﾅﾃﾞﾅﾃﾞ
∧_∧
.∧_∧( ･ω･)∧_∧
( ･ω･)Ｕ)) .(･ω･ )
⊃)))（ ･ω･)(((⊂
.∧_∧∩))((∩∧_∧
( ) .( )
ﾅﾃﾞﾅﾃﾞ ﾅﾃﾞﾅﾃﾞ ﾅﾃﾞﾅﾃﾞ
670 ：
nobodyさん：2012/10/12(金) 21:06:03.98 ID:zs1r8xUJ
チンパンジーって暴力的で愛がないんだって。ボノボは愛があって暴力がないんだって。ボノボの方が良かったんじゃない？
ボノボってあのIBMの
それはレノボ
俺の後ろに立つな
これアシアルが作ってるの？
んじゃ完成度は推して知るべし
676 ：
nobodyさん：2012/10/13(土) 18:40:47.69 ID:MXAZ4qau
そんなことばっか言ってる子のとこには
しまっちゃうおじさんがあらわれて、どこか知らないところにつれていかれて
どんどんしまわれちゃうんだ…(´；ω；｀)
オープンソースなのに情報が少ないからクローズソース
動的だから変更のたびに チェックと確認が必要
ローカル環境→開発サーバー→ステージング→本番 これを毎回やる
クラス・関数一覧のドキュメント一覧とか大量に必要にしかも仕様変更
のたびに変更が必要 大規模だと必ずこんがらがる
バージョンアップのたびに別物に生まれ変わり また学習しないといけない
新しいＦＷがしょっちゅう出て それがデフォルトスタンダードのような
宣伝やめてくれないか
実行しないとバグがわからなすぎる動的言語は過去のライブラリを使うの
ためらう 結局過去の資産を生かせない 関数の名前の変更のたびに
ソース検索が必要で手間がかかる これが静的言語だったらエラーはくから
確認チェックの手間がローカル環境内で収まることが多い 動的は作れば
作るほど負債化し 作っては捨てたほうが早いの繰り返し どうしようもない
動的言語をはてぶを始め技法やCodeZine アシアルの宣伝は本当に
罪深い
結局これは短期記録力がある人間の驕りなんだよね。（東大とかアシアルとか）
彼らは自分たちの記憶能力を生かしたいがために
ガラクタ言語をチョイスしてそれをスタンダードのような流れにしたいと思っている
このガラクタ言語を使うことで短記録のある自分たちが有利であることを知っていて
他を蹴落としたいと潜在的に思っている。ハテブやらで流れを作ろうとたくらんでいる
静的言語を使えば（主にＣ＃）こんな苦労なんて全然ないのに
それでは自分たちが存在意義が問われるからあえて使わないようにしている
いい加減こんなガラクタ言語やっていても無限に苦労することなる
動的はやめとけ無限に苦労することになる 書けば書くほど大変になる
記録力のあるやつだけやつしか現場に残らない 記録に止めないといけないこと
多すぎるからだ VisualStudioやC#だったらバグ、リファレンスエラーを教えてくれる 記憶力よりプログラムを書く想像力方が大事になってくる
動的は流れを把握するのが時間がかかるから、ＭＶＣに合わせていたが ソフトがバグを教えてくれるならも っと効率的な書きをして 他人はVisualStudioやC#の機能から理解にいたることできる
つまらない他人のＭＶＣに合わせないでも効率的な面白い書き方でやっていけるはず ドカタから芸術家に脱却できる
日本語でおk
何処縦に読めばいいかわからない
もしかして斜め？高度だな
アサヒビールが販売してる焼酎がお気に入りだ。
この商品名は良い香りという意味で付けたらしい。
こんな中身のない長文を思いつきで書ける人ってすごいと思うの
あー、あの第64代横綱ね
688 ：
nobodyさん：2012/10/15(月) 11:43:45.53 ID:0/gKp0mh
チンパンジーってZFの影響を受けてるとみた。
ってか、焼き直しっぽい感じがした。
国産のFWってのは魅力だけど、これから新しい物作るんなら
少なくとも英語には対応したサイトで間口を広げないと
コミュニティの広がりに関してはなかなか難しいよな気がする。
なんだかんだ言っても英語を使うと新しいつながりが半端ないし、
やっぱりインターネットって米軍のお下がりだしな。
少なくとも新しいPHPFWはもうちょっと無理がある気がする
いっぱいある古参系のを使い続けるか、Yiiだとかそのあたりの
比較的あたらしめの奴を覚えて乗り換えるかのどっちかじゃね
俺々フレームワークに毛が生えたようなだけの小規模系FWだと、
需要が限りなく0なので覚える時間が無駄になる可能性が高すぎるんだもの…
小規模すぎると、覚えた途端に開発終了もあり得るしな
で、別人たちの改造版に分裂
おっと、CodeIgniterの悪口はそこまでだ
本家もまったり続いてるけどな
もうどのFWも単なる言語拡張積み上げてるだけな気がしてきた
正直MVCすら要らん、MVCの思想は凄いけど形だけあっても無意味なような。
symfonyの1だけはちゃんと思想が脈打ってて感動した。2は何であんなことになったのだろう
symfonyのアレを思想というのか。
それほど崇高な印象はないなぁ。
開発ブログを読む限り、BEAR.Sundayは良いかも知れない。
完成すれば、既存のFWの対抗軸になりうる予感。
laravelがよさそう
fuelphp流行ってるのは日本だけだし
yiiかlaravelに乗り換えたい
fuelも別に流行ってないけどな
最近はCakeの情報が少し充実してきたのかな？
cake2の情報が少ないし
見つかるプラグインは1用ばっか
PHPの開発自体減ってるのかな？記事関係はRubyばっかりだ。
だが、新サイトで見るのは大体PHPだけど
特に最近は、自分から発信する開発者がRubyのほうが多い感じを受ける。
言語としての優位性の比較はともかく、その点ではRubyはいいかもね。
>>703 情報発信者が多いのは結構だけどなぁ・・・
rubyってバッドノウハウ多くね？
っと、PHPスレで他言語disっちゃいかんな。ごめんよ
PHPをdisれ
バッドノウハウの多さを競うならPHPだって負けてないぞ
yiiとCodeIguniter迷いすぎる
CodeIguniterでいんじゃね？
710 ：
71：2012/11/27(火) 13:31:53.86 ID:???
スペルが違うんじゃね？
CodeInuguier
Wii
ASP.net 2人かかる仕事は
PHP 3人
RUBY 4人
JAVA 5人
機能を追加時の増員の必要割合
ASP.net 開発者 小 デバッカー 小
PHP 開発者 中 デバッカー 大
RUBY 開発者 中 デバッカー 大
JAVA 開発者 大 デバッカー 中
動的言語やLAMPはバットノウハウなのは確か
まねするとコストばかりかかり 雪達だるま式にデバッグやらコード修正が増えていき
苦労することになる
大手しか開発できないような仕組まれてる ガラパコス利権
デバッカー
バットノウハウ
雪達だるま
コード修正が必要なのはお前だ
ガラパコスについては大目に見てやろう
アプリ起業iPhoneC#まとめ Ver 1.5
ｈｔｔｐ:／／tinyurl. com/9w97424
ブラクラ
もしブラクラだったら警察に通報して逮捕になるから別にいい
綺麗なサンプルphpコードを一つ見本にして全員で真似するのが
一番開発もメンテも楽な（メタ的な）フレームワーク
その作業工程は、延焼していく炎を思わせるため、flameworkと呼ばれる[3][4]。
721 ：
nobodyさん：2013/06/20(木) 23:35:41.10 ID:NY+i8nF6
714と715、面白いな。
723 ：
nobodyさん：2013/07/08(月) 13:47:44.29 ID:JFWVTYwY
>>720 flameworkって普通にある単語なんだが
>>723 その普通のflameworkの意味をちょっと説明してみてよ
flamework (三人称単数 現在形 flameworks, 現在分詞 flameworking, 過去形および過去分詞形 flameworked)
To lampwork.
んで、
lampwork (uncountable)
(glassblowing) A method for working with blown glass that does not require a furnace.
(glassblowing) Glass pieces made by this method.
(glassblowing) The activity of producing glass pieces using this method.
726 ：
nobodyさん：2013/07/08(月) 14:28:29.12 ID:CcFF0+Dd
普通にスレチ(´ω`)
普通に使われてることの証明になってない
>>727 辞書をひくことすらできないお馬鹿さん、乙
ウィクショナリーが辞書だと思い込んでるゴミ乙
PHPのフレームワークって、よく名前が出るものだけでも
いくつもあるから、いまいち何使っていいかわからん。
適当に選んで、使って試して、だんだんわかっていくしかないのか・・・
しばらく前にZendでやってみたものの、利点も欠点もなにも、
これといった印象なかったし、違いのわかる男にはなれそうにないぜｗ
>>730 俺もそう。何使っていいかわからん。
ただ、規約に縛られるフレームワークは嫌。
規約を知らないと摩訶不思議な動作をするように見えるから。
規約なんて、開発完了しちゃえば直ぐ忘れてしまうもの。
規約を忘れた１年後の自分は、そのコードをメンテできそうもない。
規約に縛られないフレームワークでは
自分で規約を作るだけ。
結局、規約に従ってプログラムするのは当たり前。
でなければ、行き当たりばったりの開発をするかだ。
こっちはもっと最悪。
何も決まっていない、似ている処理なのに
規約がないから、微妙に違ったコードになってる。
開発をするたびに、コードを読まないとわからない。
忘れる以前に覚えられない。
>>730 > しばらく前にZendでやってみたものの、利点も欠点もなにも、
> これといった印象なかったし
アーキテクチャってものを知っているか？
設計のことだが、どちらかと言えばコードレベルの設計の話。
アーキテクチャを知らなければ、フレームワークを見ても
単にいろんなライブラリがあるようにしか見えない。
アーキテクチャを知っていれば全体がひとつの塊として
考えられて作られていると理解できるようになる。
どう作っていいかがわかってくる。
経験を積めば、コードを見るだけで
あぁ。こうしろってことねと意図がわかる。
そうなると、ここにこの機能があるはずと推測できるようになる。
つまり君はまだアーキテクチャを知らんのだ。動けばそこで終わりという開発をしてるだろう？
単にフレームワークを使うのではなく、フレームワークをどのように使ったら
効率がいいかを考えながら作れば、アーキテクチャを理解できるようになる。
734 ：
nobodyさん：2013/07/26(金) 01:03:16.98 ID:WG0iVkUb
コードレベルって書くとむしろ1～数行レベルの話しに聞こえちゃう
733は随分上から目線だけど、そんなヤツに限ってデキないんだよな。
これは俺の回りの現場の人間を見ての経験則だけどね。
アーキテクチャって言葉を知りはじめて、使ってみたいのかな。
>>732 俺の言う規約というのは、例えば、CakePHPの場合、
DBのテーブルに created_at というフィールドがあれば自動的に
値が書き込まれる・・・
ということ。
これらは、自分が書いたコードを追うだけでは挙動を理解でき
ず、CakePHPを知っていないとダメなんだよね。
規約に縛られるフレームワークは、規約により自動化されることが
多いのでコードを書く量が減り開発が速いけど、規約を忘れたときの
メンテが大変、という感じがします。
慣れてしまえば心配無用なのかな？
規約が紳士協定レベルじゃなくて制限として存在してくれれば
困ることはないんだけどな
>>736 created_at は ROR
CakePHPは created
>>736 もしそういう規約がなかったらで考えよう。
日付が格納されるフィールド名はバラバラ
ある所はcreated_atだったり、ある所はcreatedだったり
ある所はcreate_dateだったり。
そうならないときに「コーディング規約で決める」というふうにやっぱり規約が出てくる。
規約を忘れたら、バラバラのフィールド名になる。
規約を思い返すのならCakePHPの規約を思い出せるだろう。
フィールド名がバラバラなだけではなく、あるところは
日時なのにあるところは日付だけだったり、コードを読めばわかるだろうが、
フィールド名を見ただけでわからず、該当フィールドに格納しているコードを
一つ一つ読まないと確証が得られない。
規約を忘れたらというが、規約を忘れるような人は手作業で書いたコードも忘れる。
コードを読み返す時間があるのなら、CakePHPの規約を読んだほうが早い。
忘れた時にメンテが大変なのはどっち？ コードを読むのが苦痛じゃないから
実際に時間がかかってるはコードを読む方なのに楽だと勘違いしているだけ。
コピペしたほうが早い。
forループはfor文を忘れた時にメンテナンスが大変。
結局はこう言ってるのと同じ。
はい？
>>733 ダラダラ書いてるが1～数行レベルで済むレベルの話
規約違反はエラーになるPHP用文法チェッカがほしい
って探せばありそうだな
つ codesniffer
>>745 こんなのがあるんだ
これってCake用っぽいけど、オレフレームワークでも使えるかな
ちょっと試すか
全然Cake専用とかじゃなかった。 これ便利そう！ありがとう！
え？なに？ なんか知らないけど、どういたしまして！
749 ：
nobodyさん：2013/07/31(水) 20:54:30.02 ID:1ypj5657
とりあえず初心者は何やれば良いの？
初心者なら、一度でいいからフレームワークを使わずに作る
で、「あれができたらいいな」とか「これを簡略化したい」などを
まとめ、それから、それらを実現できそうなフレームワークを探す
PHP初心者じゃなくてFW初心者ってことなら
とりあえず情報量の多いCakePHPからやるのが無難だろうな。
まわりに詳しい人がいたらその人が使ってるFWでも良いと思う。
地力の無い奴がフレームワークに手を出すと大抵コードが腐る。
まず大半の初級者は Model = DBテーブル と刷り込まれて、
正しいMVC分けが出来なくなり、Controllerが糞みたいに肥大化する。
普通に考えれば、別途ライブラリ(真の意味でモデルに該当するモノ)を構築すれば良いのだが、
それが出来ない。全部コントローラに記述しちゃう。
また大半のフレームワークではメソッドやコントローラアクションに関する粒度が規定されていない為、
1メソッドが糞みたいに長かったり、1コントローラに全ロジックが書かれたりする。
素人は一度は自作FWを作る経験をすべき。
一度でいいけどな
モデルを理解したうえであらためてCake使うと
「ファーーーｗｗｗｗ よう考えられとんねーー」
と思うこと請け合い
え？
cakeがよく考えられてることとはネタですか
笑ってるから、馬鹿にしてるんでしょ
実際は笑えないことが多いんだけど
cake激安レンタル鯖に入れたら重すぎて使う気起きなかったよｗ
cakeなんか使うからｗ
で、何がお勧めなの？
出来ればそれを選ぶメリットも一緒に
ケースバイケースとしか言いようが無い。
FWのせいで効率が落ちる＆保守性が落ちるのは本末転倒なので好きなの選べばいい。
Cakeは開発グダグダだし、独自方言大杉で他FWに移行し辛いし、一緒に心中する覚悟が必要かな
最近だとIDEとの親和性も大事だね
fuelPHPとか最近よく聞くけどどうなんだろう
FuelPHP
CodeIgniter のライセンスの問題で話題になっただけで、
他と比べて特別何か優れてるわけでは無い
＞IDEとの親和性も大事だね
俺もそう思う。
もうこれほとんど生PHPだろ・・・ 超便利だけど・・・
というようなフレームワークってある？
文句は出るがお勧めはないってのがさすがphp
>>763 生PHP＝独自設定ファイルが不要という意味ならば、
Zendとかじゃね？フレームワークとしては微妙だけど、ライブラリとしてはまぁまぁ便利
>>764 どのFWも一長一短な上、無駄に種類が多いからね･･････
slimオススメ
>>759 >>762 IDEと親和性が高いフレームワークでオススメってある？
phpStorm使い始めたんだけど、コード補完が効かないと耐えられない体になってしまったよ
俺も知りたい。
VisualStudioでアプリ作ってると、コード補完が効かないのは耐えられない。
CakePHPはプラグインあるよ
他もあると思うけど使わないから知らない
NetBeansにCakeのプラグインあって入れたけど
結局素のPHPの部分しか、解釈してくれないようだ
コンポーネントの関数とかまで見つけてサジェストしてくれたら、最高なんだが
ウェブ系って静的解析が難しい言語ばかりだからね。
実際に実行される直前になるまで
変数に入っている型がわからないなら
補完できなくて当然なわけで。
>>771 ＞実際に実行される直前になるまで
＞変数に入っている型がわからないなら
＞補完できなくて当然なわけで。
そう思っていた時期が俺にもありました。
が、最近のIDEはコードとコードコメントから中身を推察して、凄い精度で補完してくれるんだよ。
ただし、マジックメソッドを多用してたり、PHPコードでは無く文字列や設定ファイルを多用してると、流石に無理でCakeは相性が悪い。
コメントから中身を推察ってすげえな。本当にできるの？
// たぶん動くと思う
>>773 出来るどころか、その逆、コードを解析してコメント入力の補完までしてくれるよ。
以下のメソッドがあるとする。
function getHoge($a = 1) {
return new Hoge($a)
}
1. コードから型を推察する
$a = getHoge(); // $a はHogeインスタンスとして認識される
$a->xxxxx; // $a-> と入力すると xxxxx が補完される
2. コードからコメントを補完
/** と打つと、以下のコメントひな形を自動入力してくれる。
この @return にメソッドが返すべき型を指定すると、IDEはそれを認識する。
(@returnが無くても上記のコード推察機能は動く)
/**
* @param int $a
* @return Hoge
*/
function getHoge($a = 1)
言語の欠陥をコメントで補ってる系
間違いなく言語の欠陥
型付けが無いメリットとデメリットのうち、デメリットだけをアノテーションで解決出来るとかどこの神言語だよ
変数の型をコメントで指定するぐらいなら、
普通に変数に型を書いたほうが
見やすいと思うよｗ
Bare Sunday なんかはフレームワークそのものを
アノテーションで駆動させてますよ
あ、 Bear Sunday の間違いだった
DRYの原則からすると、
/**
* @param int $a
* @return Hoge
*/
function getHoge($a = 1)
$aを二回書くのは無駄でしか無いね。
もっと言えば@paramも無駄だし@returnも無駄。
こんな感じでコメントを書く場所が厳密に決まっていて
同じ事を二回書かなくて済む言語出来ないかねぇ。
// 関数と戻り値のコメントを書く。
function Hoge getHoge(
int value, // ここに引数のコメントを書く
string str, // ここに引数のコメントを書く
) {
・・・
}
valueが@paramなのは自明だし型も自明
アノテーションがどういう物か判ってて書いてるんだろか
DRYが何か判ってて書いてるんだろか
読んでるこっちが恥ずかしくなるわ
そう言葉を残すだけで
反論はできないのであった
完でいい？
>>780 変数に対する型指定アノテーションも存在するよ
厳密に型指定したいならPHP以外を使えば良いんじゃね？
>>783 コメントは別に「型」を記載する為だけのものじゃないからね。
あと、君が上げてるサンプルは長文になった時、確実に可読性が確実に落ちると思うんだがｗ
＞コメントを書く場所が厳密に決まっていて
うん。それがphpdocだ。
C～C#、Javaあたりのソース読んでみ同じような事してるよ
> あと、君が上げてるサンプルは長文になった時、確実に可読性が確実に落ちると思うんだがｗ
長文になる時は別の書き方を用意すればいいだけの話。
// 関数と戻り値のコメントを書く。
// [*1] : 長いコメント
// [*2] : 長いコメント
function Hoge getHoge(
int value, // 短いコメント [*1]
string str, // 短いコメント [*2]
) {
・・・
}
重要なのは、コードを変更した時、同じ事を二度やらなければいけないということ。
コードとドキュメントの整合性が取れなくなるのは、これが理由。
>>786 > 変数に対する型指定アノテーションも存在するよ
いや、だから型指定アノテーション＝型指定でしょ？
>>787 君が言いたい事はわかるが、とうの昔に多言語で実装されている。
・MS系(VB/C/C#)のドキュメントコメント
・Java系のjavadoc
・ECMAScript(JS/AS/etc)のコメント
phpdocはそれに倣っただけだ。
あとアノテーションについて学べ。まずはそこからだ。
＞重要なのは、コードを変更した時、同じ事を二度やらなければいけないということ。
IDEが自動で変えてくれる。
＞コードとドキュメントの整合性が取れなくなるのは、これが理由。
整合性がとれなくなるのは、開発者が無知だからであって、言語のせいでは無いよ。
＞長文になる時は別の書き方を用意すればいいだけの話。
長いコメントと短いコメントの記載場所が2箇所に別れちゃうんだｗ
で、長いコメント書く場合の改行やパラメータの区切りはどうすんの？ @param とか明示的な文法が必要じゃね？
> 長いコメントと短いコメントの記載場所が2箇所に別れちゃうんだｗ
> で、長いコメント書く場合の改行やパラメータの区切りはどうすんの？ @param とか明示的な文法が必要じゃね？
短い時に短くかけるのがメリット。
たいていは短いのだから
多くのものを短く出来るのはいいことだ。
>>788 ＞型指定アノテーション＝型指定
違う。「言語」としての型指定では無い、所詮はただのコメント文。
コメントにルールと意味を含める事で、言語を拡張するイメージだよ。
最近ならAndroid系のソースコード読めばアノテーションの存在意義が理解しやすいよ。
ピュアなJavaコードなんだけど、Android独自文法を実現している。
>>791 ＞たいていは短いのだから、多くのものを短く出来るのはいいことだ。
答えになっていない。
長いコメントの区切りはどうするの？
パラメータの順番が変わったらどうするの？
お前、まともにとリファレンスコメント書いた事ないだろ。
＞IDE使わないときはどうすんの？
IDEの為にアノテーション使おうって話なんだが？
僕の考えた最強のコメントルールってやつだな･･････ｗ
独自フレームワークより害悪だわ
/ /ヽi,',. ', ヽ. ヽ ヽ _
,' i ,' '"´ ヽ.l＼ ',,ヽ '､ ､.'､!_ゝ-r- ､
,. '"i .i l .,' ,./ヾヽ,ヽヾヽ .l､. N ヽi i., ' ., ,.' ﾍ
,'-_.,' .l /!.l..-‐'´ ｀ヾ''''ヽ l.', l }｀'‐l l' .,.,'i´ i
',__/, ! ,'´'l _,,,,_ ､ r-==.-'､.l,' .'z ..', V/ヾ.､ ﾉ
ゝ,'l N ,ｨr'´￣｀ ｀r'っ 'i _. ｨ'ヽ--｀'
'´ .! i'l !r'/i/i 丶 '´'´' ｀i ! ´,ヾl !
',!.l.ll.! r=＝ﾆ'‐ヽ. l ! ,' ,.,i !
i. ',l. !:::;: -‐‐-:;i l.! , ','.ｲ.l ! やっと【PHPフレームワーク総合スレ15】
! ','､ l.{ ,l ,'i.,.'.'´ .l. ! .l が盛り上がってまいりました！
i !.l＼. ヾ=== ' ' ノイ´ .l. l i
! .! ! ｀' .､ ,. ｰ',.. 'i .l. l l
! .! ! ','､' ー. '"r;''"‐'´i .!. ! .!
! .! l !ヽ'i´i-´' .| !. i !
. ! .i .! ! ! | '､ !. i i
i .i .i ,.- ' く.r'_,,.''''' ヽ、 ',. i i
! i_,i.ｨ'" i i ｀'i;--' ､ .i
i , '´ 〃＿＿ .,'.,' ＿_ ,',' ヽ i
>>793 > 長いコメントの区切りはどうするの？
[*1]って書いてるじゃんｗ
> パラメータの順番が変わったらどうするの？
変わってなにか困るの？
>>796 [*1]とか[*2]は無いｗｗ
@param $var の方が良いわｗ
＞＞パラメータの順番が変わったらどうするの？
＞変わってなにか困るの？
>> 787 で
＞重要なのは、コードを変更した時、同じ事を二度やらなければいけないということ。
[*1] だと数字を全て書き換える必要があるよね？
(書き換えないのであれば、相当可読性落ちる)
何より長文と短文を紐付ける [*1] が人的管理とかねぇわｗ
試しにそのコメント処理パーサ実装してみ？
引数と戻り値の言及ばかりで、
@see / @author / @todo / @throw あたりを考慮してない時点で察してやれよ･･････
コメント文をまともに書いた事も、ドキュメントを作成した事も無いんだよ･･････
>>783 で
＞ $aを二回書くのは無駄でしか無いね。
と言っているのに
>>787 では
$aの代わりに [*1] を二回書いているというねｗ
>>799 > $aの代わりに [*1] を二回書いているというねｗ
長文だからだろ？
短文（大半）は一回でいい。
PHPerが総じてキモイのがよく分かった
PHPerだけど、こんな奴と一緒にしないで欲しい
>>800 がピーピー騒いでるだけだろｗ
Markdown記法持ち出してるが･･････で？
IDEとの親和性が抜群に上がるので皆phpdoc書こうぜ！って話なのだから、
当然IDE用の何かがあるんだよな？ｗ
（ ヽ ―――― ○ ――――
, ⌒ヽ ( ） ／/ | ＼
（ ' （ ヽ⌒ヽ 、 ／ / | ＼
ゝ ｀ヽ( ）.. | (⌒ 、
( ⌒ ヽ （ ヽ
∧__∧ 【PHPフレームワーク総合スレ15】が
（ ´･ω･） 盛り上がってまいりました
（ つ(＼
(＼_ノ(___)⌒ ⌒ヽ_
） ＿＿＿＿ ・_つ
（／ （／
｡ ﾟ
｡ ﾟ
～～～～ ～～ ～～ ～～ ～～ ～～ ～～ ～ ～
～～ ～～ ～～ ～～ ～～ ～～ ～～ ～～ ～
～～ ～～ ～ ～～ ～～ ～ ～～ ～～ ～
PHPerでも無いだろｗ
俺の考えた最強の言語厨ｗ
まともにコード書いた事が無いんだろうよ
まーた、中身の無い反論（？）をｗ
IDEを使って無い情弱が混ざっているという事だけは確かだなｗ
PHPerは補完に頼りっきりの行き当たりばったりのコードを書くからそんなことになる
そんなことって？
×PHPerは補完に頼りっきり
○PHPerは補完に頼れなかったのが、頼れるようになってきた
僕は ほかんなんてなくても ゆうしゅうです てか？涙拭けよｗ
補完されなくてもできるが、機械的にできることに注力するのはただの無駄
無駄なことに凝ってるのは、優秀ではないよ
道具を使いこなせなければ猿ですらない
道具に使われてる典型的な例だな
こういう奴に限ってIDE無いとプログラム書けなかったりする
環境に左右される様なプログラミングしてる奴が優秀とかよく言えたもんだ
>>812 GJ
>>813 うわー、懐古厨？老害？
何か勘違いしてるようだけど、PHPerはIDEが無くても書ける。
（今までまともなIDEが存在し無かった)
故にコード品質を保つのに、人手が･･･つまり「無駄」な時間が割かれていた。
IDEを使えば、綺麗に短時間で効率良く書ける。
コメント、リファクタリング、テストコード、バージョン管理、コードリーディング、全て補佐してくれる。
「使わない」理由があるか？
君が「道具」すら使いこなせず、選択肢を狭めてるだけじゃね？
>>814 >何か勘違いしてるようだけど、PHPerはIDEが無くても書ける。
>（今までまともなIDEが存在し無かった)
>故にコード品質を保つのに、人手が･･･つまり「無駄」な時間が割かれていた。
自覚してんじゃん
XPHPerはIDEが無くても書ける
○IDEが無いと品質を保ったコードが書けない
>IDEを使えば、綺麗に短時間で効率良く書ける。
>コメント、リファクタリング、テストコード、バージョン管理、コードリーディング、全て補佐してくれる。
当たり前だろ
IDEって何の略か知ってんのか？
>「使わない」理由があるか？
>君が「道具」すら使いこなせず、選択肢を狭めてるだけじゃね？
使いこなすとか使いこなせないとかじゃなくて
「当たり前」の事をドヤ顔で誇らしげに言ってるPHPerが気持ち悪い
大体PHPでアノテーション使えるようになったのはいつからだよ
PHPerはほんとにPHPしか知らないんだな
>>815 お前は他言語はおろかPHPもIDEも使って無いっぽいねｗ
てか、話の前後を読めないの･･･アスペ？
＞大体PHPでアノテーション使えるようになったのはいつからだよ
PHPという名前になる前からアノテーション自体は定義出来たよ。
アノテーションの意味解ってる？ｗ
＞当たり前だろ
＞IDEって何の略か知ってんのか？
＞使いこなすとか使いこなせないとかじゃなくて
＞「当たり前」の事をドヤ顔で誇らしげに言ってるPHPerが気持ち悪い
「当たり前」であるIDEを使って無い奴がいる、
「当たり前」であるIDEを環境依存と難癖つけてる
>>813 がいる
そして残念ながら、PHPという言語はIDEが「当たり前」に浸透してないんだよ。
アノテーション定義は出来ても解釈出来るIDEが無かったんだよ。
それが、昨今急激に進化して他言語IDEと肩を並べられるようになった。
故にフレームワークとIDEの親和性が重要になってきた。
昔のPHP事情で煽れても、情弱としか言いようが無い。
そいつ書籍スレや質問スレを荒らしてるキチガイだろ
Javaで挫折してPHP入門しようとたところ、スレで無知を馬鹿にされた逆恨みでタタリ神になってから
PHPを貶めるため年中スレを監視するお仕事をしてる
アノテーションをIDEで利用する注釈程度にしか理解してないのはよく判った
言語仕様の話してんのになにが「PHPという名前になる前からアノテーション自体は定義出来たよ」だよ
本物のアホだな
それとな
>てか、話の前後を読めないの･･･アスペ？
とか
>そいつ書籍スレや質問スレを荒らしてるキチガイだろ
とかさ
別に2chだからとかって言い訳したいんだったらそれでいいけどよ
そういう煽りしか出来ないからお前らゆとりは相手にされてないんだよ
技術的な話するなら技術的な事で煽れよ
だいたい「そいつ」って何だ
IDもないスレで人物を特定して何の意味があるんだ
PHPと同じで存在する価値がないゴミだな
なんかこの板的に、今までにない勢いでスレが伸びてるな
>>818 ＞言語仕様の話してんのになにが「PHPという名前になる前からアノテーション自体は定義出来たよ」だよ
phpdoc等のアノテーションは言語仕様としては「コメント」以外の意味を持たない。
(コメントを取得するリフレクションクラスは存在し、それを使ってアノテーションを解析するコードを書く事は可能)
で、「言語仕様」としてPHPがアノテーションを定義出来るバージョンていくつからだい？
定義方法と併せて、無知な私に教えてください
>>822 え、アノテーションて Java からじゃなかったのか
C# は殆ど触ったこと無いんだが、意外
あぁなるほど
>>815は公式にアノテーションがサポートされてないのにいつから使える様になったのか？って言ってるのか
それを
>>816が定義ができるとか言ってるから話がおかしくなってるんだな
それに対しての
>>818のレスで意味が通じたわ
公式にサポートしてないからアノテーションの記法をしてもただのコメントなのに
定義が出来るとか言うのがおかしいって事であってる？
とりあえず話の流れ的には勉強になって良いんだけど
スレ違いだから他でやって欲しい気もするかな
>>825 ＞公式にサポートしてないからアノテーションの記法をしてもただのコメントなのに
＞定義が出来るとか言うのがおかしいって事であってる？
いや、アノテーションとは本来言語に影響を与えない、コメント(注釈)に意味を持たせる事にあるんだよ。
それが「公式」か「非公式」は関係無いんだよ。
phpdoc の @author @param 等も立派なアノテーション
(IDEや、phpDocumentor/Doxygen等のドキュメント生成ソフトが対応している)
なのでPHP3だろうが4だろうが、定義は可能だし、上で上げたソフトで処理も可能だ。
今日もまた不毛な議論が続いてるなｗ
不毛な議論は飽きたから無毛女子の議論をしようぜ
ていうか、ここフレームワークのスレだよね
じゃあネタ振りしてみる
最近、マイクロフレームワークが気になってるんだけど
スレ住人的にはマイクロフレームワークって使ってる？
俺はSlimとSilexを勉強してたりするんだけどシンプルでいいよね
使いどころは？初心者ならともかく、どこにつかうんだろ
>828
＞アノテーションとは、あるデータに対して関連する情報（メタデータ）を注釈として付与すること。
＞XML等の記述形式を用いてメタデータをタグ付けする場合が多い。付与したメタデータやタグを指してアノテーションという場合もある。
は読んだ？
その上で phpdoc がアノテーションでは無い、と思うならアノテーションでは無いのだろう。お前の中では。
なぜこんなに必死なのか
>>832 むしろフルスタックのフレームワークの方が初心者向けな気がするが
シンプルな方が縛りが無くて自由な分PHPに慣れてないと使えないと思う
phpdocはアノテーション使えるって必死な奴以外は、phpって言語でアノテーション使えるかって聞いてるだけに見えるんだが。
アプリレベルの話と言語レベルの話とごっちゃにしてるから一生解り会えないと思う。いい加減スレチだから他でやれや
アノテーション云々は置いておいて、
IDEと親和性の高いフレームワークの話しようぜ
具体的に教えて欲しい。
例えば、
NetBeansでCodeIgniterの補完をさせたいときのオススメの方法。
EclipseでCakePHPの補完をさせたいときのオススメの方法。
コメントに@propertyとか書くだけではダメなんだけど、”高い精度”で
補完させる方法を教えて。
フレームワークの話題だからここでいいだろ
>>838 まず Netbeans と Eclipse(PDT) は補完精度が非常に低い
・全てのメソッドに @return で型を指定する
・全ての変数/プロパティに @var で型を指定する
この二つを満たさないとまともに機能しない
マジックメソッド(__get や __call)を使用しているFWとは非常に相性が悪い。
最近話題の phpStorm を一度試してみ？
PHPコードを解析して"桁違いの精度"で補完してくれる
コメントを書く必要が無いどころか、コメントすら自動生成してくれる
自動生成のコメントになんの意味があるのやら。
見た目っすか？ｗ
>>842 コードを書く → コメントを書く → リファレンスが生成される
PHPに限らず、一般的なワークフローだけど？
まぁ、業務開発やオープンソース開発をしていないなら不要かもね･･････
酷い自演を見た気がする今日この頃
スレ伸びてるから何かと思ったら・・・・
今月のスルー推奨ワード
・phpStorm
・phpdoc
・アノテーション
・IDE
上記の話題をしたい奴はスレタイ10回読んだ後で
他のスレでやってくれな
phpdocとかアノテーションとかどうでもいいが
IDEと親和性の良いフレームワークの情報は需要あるだろ
教えてえろい人
>>846 お前
>>837=838=840=841=843だろ
それが既にスレ違いだって言ってんだよ
＞IDEと親和性の良いフレームワークの情報は需要あるだろ
フレームワークと相性の良いIDEってんならまだ話は判るけど逆だろ
なんでIDEありきでフレームワーク選ばなきゃならんのよ
どうしてphpStormに話題を持っていきたいのか知らんけど
IDEについて語りたいなら自分でスレ立ててそこでやれよ
ついでに言うとアノテーションで必死になってたのもお前だろ
文体が一緒だわ。()で括って補足書くとことかな
ID出ないから自演してんだろうけど、うざいから程々にしとけよ
>>847 フレームワークと相性の良いIDE聞く方がスレ違いだろ、、、
IDEを使うと
>>838 のようなフラストレーションは出てくるんだよ
cake 1.xとかで $this->model->【補完出来ない】 みたいな事とかさ
俺としては話題の軌道修正したつもりだったんだが、すまんな
文体が一緒？別人なのに不思議だね。
可哀想だから一応聞いておこう
>>847 様のオススメのフレームワークとその理由を是非ご教授ください＞＜
FuelPHP
顔真っ赤だな
纏めるとPHPerはIDEがないとFW使えないって事でおｋ？
>>835 FW初心者が学習コストをかけずに簡単なサイト構築に使えるのがメリットだと思うんだけど
マイクロフレームワークを独自に拡張してあれこれやるのは本末転倒だろうし
マイクロフレームワークは割り切って使うには良いんじゃない？
簡単な問い合わせフォームを作る時とか
既存CMSカスタマイズするより楽だし、汎用知識として身につくし、選択肢としては悪く無いと思う
IDE云々みて思うのは、静的な型じゃないという言語欠陥を補うのはとてもしんどいってことだな
個人で開発出来る規模を超えてチーム開発が必要になるようなら、素直に別言語メインにしたほうが捗る
これだけじゃスレチだからフレームワークについても
結局新しいものがでても、既存の知識しか持ち合わせない不勉強層が
新規FWとかに難色を唱えて騒ぐから、新しいFWを採用すること自体業務でコーディングする上では難しいんだよな
結局俺々か、cake、symfony使ってるとこが殆どな状況、PHPが今まで以上にもっと下火になるまで続くと思うわ
その頃には新しいFWが出なくなってそうだけど
>>956 うちと状況が似てる
チームワークに新しいのを持込むの難しいよねぇ･･･ＣａｋｅＰＨＰやＳｍｙｆｏｎｙxが蔓延してる。
不勉強層は学習コストと、自分たちに実績が無いから責任は取らない！と頑なに新しい技術は拒否する。
少しでも開発効率を上げるって名目で、ＩＤＥ導入は自由になったけど、改善にはならんな
その状況で導入してみたいＦＷとか使ったＩＤＥとか聞いていい？
IDEの情報が出ているこの勢いで質問してみます。
上の方でPhpStorm推している人がいますが、誰か他に使っている人いますか？
3年前ぐらいに一度試してみたんですが、しっくりこなくて早く見切りをつけてしまいました。
Eclipse→NetBeansときて今に至るんですが、これらと比べてどうなんでしょうか？
>>858 私も今はnetbeans一本です。
これよりいいのに出会ったことがないです。
俺仕様に拡張しまくりたいならAptanaStudio使えお(´^ω^`)
php初心者に易しいMVCフレームワークを探してるならCodeIgniterから始めろお(´^ω^`)
AptanaStudioってベースはEclipseなんだよな・・・うん・・・
DW→秀丸→phpeditor→NetBeans→Aptanaな育ちなもんで、2chでEclipseがどうして悪く言われているのかよくわからなくてごめんお(´^ω^`)ゞ
開発環境を変えた理由をそれぞれ教えて！
総じてどれが良かったかも。
昔いた会社でZendStudio使ってたけど、途中からEclipseベースになったな
だったらEclipse+PDTでいいだろッて思ったわ
たいした機能もないのに金とろうとするうえに、ベース部分のアップデートは本家よりも遅い
862を見るに、Dreamweaver(だよね？)が入っているのでWebオーサリング機能が欲しいのでしょう
まあ個人的にはいらんな
Aptana ･･･ 一度PHPサポート打ち切られ、選択肢から外れた
Eclipse PDT ･･･ 全体的に優秀。重い＆環境設定が面倒。
Netbeans ･･･ 軽いしUIが日本語でとっつきやすい。若干コード補完が弱い。
phpStorm 5以降 ･･･ 有償。PHPとJSのコード補完が飛び抜けている。
ZendStudio 7,以降 ･･･ 有償。PDT上位互換、重い以外の不満は特に無い。
867 ：
763：2013/08/19(月) 12:47:13.40 ID:???
>>765 Zendかぁ・・・
これ以上を求めると、一気にガチガチになっていくのかな
そんなにコード補完必要か？
俺はSublime Textの補完程度で満足してるが。
フレームワークを使ってそれなりの規模のシステムを作ることになると道具の違いが快適さに直結する
テキストエディタの補完機能なんて、せいぜい言語構造や標準関数の名称を補完するぐらいでしょう？
870 ：
868：2013/08/19(月) 16:16:51.08 ID:???
>870
「$this->add(」とか打ったときに思っていた候補が出てこないと、「あれっ、なんかミスった？」と見直すことはよくある。
vim使ってるので、補完はomniくらいだが不便とは思わない。
複数人で並行開発するようになるとバグを大きく減らす自動補完は工数の削減に大きく影響する
()みたいに閉じ括弧も一度に入力するので、
閉じ括弧を補完するやつなら大迷惑
>>874 『(』を入力した時点で『)』が出てくるんだけど、
そのまま『)』を入力しても上書きされておかしなことにはならない。
NetBeansではそうなってる。
エディタとしても便利だけど、負の遺産コードを読むツールとして便利だよ＞最近のIDE
HTMLやSQLやJSが混在していても、それぞれの定義元に飛べたりするし。
>>870 Sublimetext は文脈を解析しての補完はしてくれなくね？
$hoge = new Hoge();
$unknown = $hoge->getHogeeeee(); .// 戻り値も定義元も不明
の後に
$unknown->
とタイプすると、どこまで補完してくれるんだろ。
延々とIDEの話してる奴はスレタイ読めないアホなの？
IDEも大きな視点で見ればフレームワークの一環だよね
<?php
って打ったら俺の仕事が全部補完されてるIDEを教えてください(*´艸｀*)
同僚の井出さんは、すっごい仕事のできる人で、プログラミングのみならず全て補完してくれます。
ただし有料です。
オチがわからない・・・解説たのむ。
井出 = I DE
だろ？
>>880 補完はどうでもいいけど、定義元が解るのは他人の書いたコードを読む時に捗る
CodeIgniterはMVC初学者にとっては良い学習用フレームワークである
いまどきのフレームワークはComposerを使った外部ライブラリと依存する方向へシフトしてきている
それに加えて、開発元はCodeIgniterを手放そうとしている
CodeIgniterに未来は描けなくなった
もはやCodeIgniterを選択するべきではない
では、何を選択するのがよいか？
中規模 CakePHP|Laravel|FuelPHPのいずれか
大規模 Symfony
長いものにまかれるためにSymfony2使ってる。
国内だと1.xがまだ現役ぽいけど
Symfony2 どうよ？
個人的にCLIツール群はいらんのだけど、ビジネスロジック部実装するにあたって便利だなぁって思う機能ある？
仕事でやるならCLIになれとかないと
CodeIgniterは、開発元とか将来性とか気にするほどのものじゃないだろ
興味があったら使えばいいし、嫌になったらやめればいいし、気軽に使えよ
CLIで作業する事はあってもsymfony コマンドとか使いたくねぇなぁ
PHP5.5に変えてから、pearライブラリで、
「Fatal error: Call-time pass-by-reference has been removed in 」が
頻出するようになった。修正が面倒くさい。いい方法ない？
>895
なるほど。ありがとうございます。早速アップデートしてみます。
久しぶりに来たら、CakePHPのスレってなくなってる？
composer使っている人いる？
fuelPHP使ってると、コンポーザー使わざるを得ない
fw自体の更新も楽だからcomposer使ってる
iphone用の画面に特化したのがほしい
LichKing使ってる人いる？
もぅCakeはいいだろ・・・
Cakeがいやならパンを食べればいいじゃない
いいねえ今度のFWの名前が決まったな
マリーアントワネットフレームワークか。
マリー・アントワネット・ジョゼファ・ジャンヌ・ド・ロレーヌ・ドートリシュ フレームワーク
PanPHPだな。
BreadPHPだろ、ってツッコミいれたら負けですか？
bakeコマンドはそのまま使えますね
パンが無ければクッキーを焼けばいいじゃない
秒間4億枚くらい
BbaPHP です
CookiePHPとかありそう
cookieとか ややこしいだろ
CookiePHPは紛らわしいからCookieClickerPHPにすれば良いね
おれおれCookieClickerが簡単につくれるそうでいいね
つくれるそうって誰からの伝聞だ
クーキーはbbaがつえーからなぁ
最近 Curry というフレームワークの存在を知って、
気に入って使い始め、ある程度作りこんだ矢先に本家ウェブサイトが消えてしまった。
作者様の身に何があったのかは分からないけど、マイナーなフレームワークは
こういうことになると、情報の参照先が完全になくなるから困っちゃうな。
作者様、これ見てたらどうか復活してください。
>>918 それはフレームワークに使われてる
段階だからだめなんだよ。お前の技術不足。
まずフレームワークはどれも対して変わらない。
ステートフルなフレームワークみたいに発想そのものが違うものはあるが
同じ発想で作られているものは基本的に同じ。
機能が実装されてるかまだ実装されてないかの違いだけ。
だから長く使われそうなフレームワークを選ぶべき。
もちろん、いろんな事情でマイナーなフレームワークを使うことが
ダメとは言わないが、その場合はフレームワークに依存しないように作るべき。
つまり、今回、お前がやらなければならなかったこと。それが出来ないのはお前の技術不足。
フレームワークが消えそうならば、フレームワーク部分を比較的簡単に取り替えられるように
抽象化しておくするべきだ。そしてコアの部分はフレームワークに依存させないように開発する。
それが出来るように、技術を磨けよ。
920 ：
918：2013/09/21(土) 23:17:38.05 ID:???
>>919 しかと受け止めました。
親切にありがとうございます。感謝です。
>>919 > フレームワークが消えそうならば、フレームワーク部分を比較的簡単に取り替えられるように
> 抽象化しておくするべきだ。
ムリムリ
それ以前にフレームワークを更に抽象化させようとする意図が掴めない
実際にZend Framework/Symfony/CakePHP/FuelPHPに対する具体的なコードを見せてもらいたいな
フレームワークを抽象化するフレームワークですね解ります
>>921 お前には無理なの？
そうか、そうなんだね。
>>922 フレームワークを抽象化させてどうするのさｗ
誰もフレームワークを抽象化するなんて言ってないし。
ヒント、デザインパターンより
・Adapter パターン
互換性のないインタフェースを持つクラス同士の接続を可能にします。
はずれのFWを選んだってだけのことだろう
927 ：
922：2013/09/24(火) 22:36:34.00 ID:???
>>925 フレームワークが用意した仕組みを無視して
自作のラッパークラスを使えって事？
アホくさい
>>927 だからお前は馬鹿なんだ。
Adapterって言ってるだろ、
フレームワークが用意した仕組みを使うからこそ
Adapterなんだってわからんのか？
929 ：
922：2013/09/24(火) 23:10:53.37 ID:???
>>928 s/仕組み/API/
これでいいか？
フレームワークが用意したAPIを無視して
自作のラッパークラスを使えって事？
アホくさい
930 ：
922：2013/09/24(火) 23:15:26.20 ID:???
まぁ言葉遊びとかどうでもいいから具体的なコードを見せてくれ
自分が知ってるフレームワーク間だけのでいい
こっちはあんたの理想とやらをどう具体化してるのか知りたいんだからさ
>>920 だからさAdapterを使う＝フレームワークが用意したAPIも使う
という意味であるということを、理解できてないのはなんで？
あんたは話をする最低レベルにすら到達してないんだけど？
>>930 Adapterパターンって言ってるだろ。
それでわからんのか？
つーかさ、ユニットテストどうやってるのさ？
お前の作ったアプリは、当然ブラウザなしでも
メインの処理行えるよな？
（ユニットテストでは通常ブラウザは使わない）
あとは、そのメインの処理をフレームワークと
つなげるAdapter作るだけじゃん
最低限度の基礎知識さえ知ってれば、わかることだよ？
934 ：
922：2013/09/24(火) 23:22:06.99 ID:???
>>932 悪いがエスパーじゃないんでね
Adapterで何と何を繋げるんですかね
コード出してくんなきゃ話が進まないんだけど
> メインの処理をフレームワークと
> つなげるAdapter作るだけじゃん
読めないの？ｗ
936 ：
922：2013/09/24(火) 23:26:29.62 ID:???
>>935 > コード出してくんなきゃ話が進まないんだけど
読めないの？
>>936 出すつもりはないよ。
だから、最初っからヒントって書いただろｗ
自分で考えろって意味さ。
938 ：
922：2013/09/24(火) 23:54:23.97 ID:???
>>937 コードはもういいけどよ
言葉遊びは止めろつってんだろ馬鹿野郎
Adapterは実装手段であって目的じゃねぇんだよ馬鹿
APIの差異を吸収するレイヤーを作れとなんで一言で表せねぇんだよ
アプリケーションへのHTTP Requestを表すオブジェクトに対するAPIを例にしたらこうだろ？
+----------------------------------------------
| アプリケーション
+-----------------------------------------------
| オレオレRequest API
+---------------------+---------------------+--
| Symfony 2#Request API | CakePHP#Request API | ..
+-------------------------------------------+----
このオレオレAPIを挟むのがアホくさいってんだよ
ボトムアップで機能を殺していくアホの設計
知識の共有化をスポイルするアホの所業
> Adapterは実装手段であって目的じゃねぇんだよ馬鹿
いつAdapter が目的だといった？
お前本当に馬鹿じゃないのか？
> このオレオレAPIを挟むのがアホくさいってんだよ
その図を考えたのは誰だ？
おまえだよな。
その図は間違いだ。
つまり、お前は間違いを書いたんだ。
アホ？ アホはお前だろう？
> APIの差異を吸収するレイヤーを作れとなんで一言で表せねぇんだよ
「APIの差異を吸収するレイヤーを作れ」と言うわけがないだろ。
そんなもん作らないんだから。
本当にアホだなぁｗ
941 ：
922：2013/09/25(水) 00:09:46.28 ID:???
>>939-940 じゃAdapterをどこで何に使おうと思ったのかな？
あ、コードを出す気はないし答えも言わないんだったな
もう1人で後出しジャンケンやっててくれや
>>941 もう触るな。Adapterの意味すらわかってないよきっと
>>938 普通にフレームワーク使ってても、拡張すると俺俺層が出来てくるだろ？
MVCガッチリかみ合ったフルスタックFWを、他のFWに置き換えるのは相当しんどいけど、
一部機能を載せ替えるのは案外楽だよ。
アダプタでもいいし、プラグインでも拡張でも、何でも･･････
ただ意味があるのかどうかは知らん。
>>943 > 普通にフレームワーク使ってても、拡張すると俺俺層が出来てくるだろ？
何のフレームワークを使ってて、どの部分にどんな俺俺層ができるの？
945 ：
922：2013/09/25(水) 12:15:05.05 ID:???
>>943 俺俺層自体を否定してませんよ
拡張のために自分も普通に作りますからね
でも「FWの移植に備えるため」には用意しません
アダプターを介して使えと言われた側はそれで済むから別にいいです
で、移植する先のアダプターを用意する人は誰なんですか、結局自分でしょ？
そのアダプターは移植する前の機能を備えていないといけない、移植先でも動くようにしなければいけない
移植する未知のFWがどんな設計なのかも分からないのにできるんです？
モデル/ビュー/コントローラー/データベースへのインターフェイス/マイグレーション/コードジェネレーター/etc...
出来たとしてもキリがないですよ
そしてFWに変更があれば「自分のアダプターも更新しないといけない」、やる気になれないでしょ…
銀の銃弾みたいに抽象化だのアダプターだの言ってるから
どう対応するのか、どう設計するのかを知りたかったんですけどね
口先だけの人みたいだからがっかりですわ
未来永劫、一人で開発してメンテナンスもするということが確実なら、趣味で膨大な俺俺層を作ってもかまわないけど。
新しい言語を覚える必要の無いフレームワーク ってある？
>>945 えとさ、お前の書いたアプリのメインロジックって
なんかのフレームワークに依存しちゃってるの？
普通POPO（Plain Old PHP Object）で作るよね？
もしメインのロジックまでフレームワークに依存していたら
やばい。フレームワークを乗り換えることもできないし
フレームワークが死んだら大変なことになるよ。
素人がFWを使うより、玄人が作った俺俺コードの方が遙かに保守性が高いし、
長期運用考えるならFWのメンテナンスより、DB設計や機能単位の切り分け設計の方が遙かに大事だ
> 素人がFWを使うより、玄人が作った俺俺コードの方が遙かに保守性が高いし、
不要な単語が多いので重要な点だけ抜き取りますね。
> 素人より、玄人の方が遙かに保守性が高いし、
当たり前じゃね？
玄人＋FW ＞ 玄人＋俺俺 ＞＞＞＞＞＞ 素人＋FW≒素人＋俺俺
まあ当たり前の話だよ。
当たり前だよな
でも、PHPのFW使いの大半はプログラマとして素人だ。
だからPHPerは質が低いと馬鹿にされる。
上でアダプタパターンが云々言ってるアホがいるけど、
中途半端に解った風になったPHPerが一番恐い、糞コード生成マシンになる
traitsとか使い始めたら世界は崩壊する
訂正
×でも、PHPのFW使いの大半は
○
>>952とその仲間たちはプログラマとして素人だ。
誰かと思えばBootstrapスレで暴れてたキチガイじゃねぇか
>>954 つまりあなたは両方のスレで暴れているということですね？
今度はフレームワークをセマンティックしに来たか
なんか他のスレで暴れていた奴が
こっちに逃げてきてるな。
こっち来んな。はげ
958 ：
922：2013/09/26(木) 03:24:14.21 ID:???
>>948 俺はフレームワークに躊躇なく依存するよ
普通と言うなら基本的にフレームワークが用意しているベースモデルを継承して
そこにビジネスロジックを書くのが普通なんだけど
RailsでもDjangoでもフルスタックのものは大抵そのスタイルだしね
POJOを持ち出すからそれについても突っ込むけど
Java界隈じゃ継承の代わりにアノテーション使ってるだけでやってる事は変わんないぜ？
結局はそれを解釈するフレームワークに依存してるんだしな
継承はベースクラスがないと
クラス単体で使えない。
アノテーションはベースクラスが不要
この点でぜんぜん違うわけだが？
> 俺はフレームワークに躊躇なく依存するよ
具体的に、どのフレームワークの
どのクラスに依存するのか書いてみ。
念の為に言っておくが、ロジック、
つまりモデルの話だぞ。
お前のモデルはなんのクラスを継承するのだ？
>>958 >>960 ビジネスロジックがFW依存するのは、FWと共に命運を共にするなら有りじゃね？
そもそもベースモデルが存在するFWって何よ？
大抵はモデルという名のORM実装じゃねぇ
962 ：
922：2013/09/26(木) 10:52:21.81 ID:???
>>959 クラス単体で動くアプリですかそうですか良かったですね
>>960 ごめん、FWみんながモデルの継承を強要されてるみたいなおかしな書き方をした俺が間違ってる
継承してるのは逆に一部だ
Symfony 2はDoctrineでアノテーション式、
Zend FrameworkもFuelPHPも自前のマッパーやらアダプターを任意で使える
CakePHP 2 :
http://api.cakephp.org/2.3/class-Model.html Rails: ActiveRecord::Base
Django: django.db.models.Model
そもそも確認するけど、俺はビジネスロジックに
データベースへのアクセスも含まれる認識で話してたんだけどあんたは違うのか？
MVCの、モデルの、更にその一部、そこだけ切り取って「はい移植性高い」なんて喜んでる話だったの？
だとしたらやっぱやるだけ無駄だわ
>>961 ORMでもなんでもいいよ
ビジネスロジックがどうのとかモデルはこうあるべきなんて焦点にしてないから
俺の主張はフレームワークが決めた方法に従え、
移植のために小細工なんてせずに使えって事だ
>>960 > 念の為に言っておくが、ロジック、
> つまりモデルの話だぞ。
なんでここまで後退してるんだ？
そもそもの話は
>>919 > フレームワークが消えそうならば、フレームワーク部分を比較的簡単に取り替えられるように
> 抽象化しておくするべきだ。
であり、それを実現するために、
>>925 > ・Adapter パターン
を使えということだった。
「フレームワーク部分を比較的簡単に取り替えられるように」するためには、Modelのみならず、
当然Controller/View部分も対応しておく必要がある。
964 ：
961：2013/09/26(木) 13:05:02.91 ID:???
>>962 ＞俺の主張はフレームワークが決めた方法に従え、
＞移植のために小細工なんてせずに使えって事だ
そこは同意する。
ただ俺が言いたいのは、
Cake, Rails, Djamgo等、君が挙げているフレームワークはＯＲＭやＤＢ操作クラスを「モデル」と定義しており、
闇雲に従ってしまうのはよろしくないと思う。
時々素人が「このロジックはControllerに書くべきでしょうか？Modelに書くべきでしょうか？」と聞いてくるけど、
FWでモデル＝DB操作クラスと定義されている為、DBを必要としないロジックを書く場合どうするのか無駄に悩んでしまうんだろうね。
これは、DB操作クラスを内包する本来の意味でのモデルを作るのが正解だと思う。
俺はCakeを使う場合 CakeMdodel(DB) ⇔ 俺俺モデル ⇔ CakeController という方法で実装している
>>964 > 俺はCakeを使う場合 CakeMdodel(DB) ⇔ 俺俺モデル ⇔ CakeController という方法で実装している
糞実装の見本
>>965 お前がモデルを理解していない事だけはわかった
黙ってBakeしてろ
>>964 それ、俺俺モデルの内容をCakeModelで実装すればいいだけじゃないの？
分離するとclass loaderとか面倒なことになりそうな気がするが、それを上回るメリットは？
俺俺モデルというか、AppModelを継承して、Cakeの枠組み内で実装すればいいんじゃ？
つか、CakePHPのModelのありようが気にくわないならCakePHP使うなって話だな
>>964 フルスタックなFWを使うのをやめれば解決。
>>967 >>968 Cake の AppModel & Model の内部実装見た事ねーだろ？
あれはモデルじゃなくてDB抽象化クラスだ。
class loaderは命名規約守ってれば何1つ問題無いけど、何が問題になるの？
>>969 何か勘違いしてねーか？
CakeがDBアクセスクラスをModelと命名してしまったせいで、
MVC本来のModelとして俺俺モデル作ってるだけだよ
973 ：
922：2013/09/26(木) 14:06:19.56 ID:???
>>964 済みませんがモデルについての是非は別の人とオナシャス
アプリ実装者や各FWがモデルをどう考えてどう設計してるのかには俺も興味あるけど
移植性の話から逸れるしｗ
RailsやCakePHPのModelが、MVCにおけるModelとは違うというのは既知の話題。
で、どう実装すべきかというのは
>>971にもあるようにさんざん既出。
そういうのはもうどうでもいいので、
>>963 > そもそもの話は
>>919 > > フレームワークが消えそうならば、フレームワーク部分を比較的簡単に取り替えられるように
> > 抽象化しておくするべきだ。
に対して意見がないなら、もう黙ってくれる？
そもそもCakePHPがDBアクセスクラスをModelと命名したんじゃなくて、RoRをまねしたから似たような役割になっただけ
CakePHPのModelが駄目駄目だと見破った俺すげー自慢
>>973 >>974 ああすまん、話逸れてたね。
> そもそもの話は
>>919 > > フレームワークが消えそうならば、フレームワーク部分を比較的簡単に取り替えられるように
> > 抽象化しておくするべきだ。
個人的には「無し」だな。
フレームワーク差し替えを考慮するなら、昨今のフルスタックフレームワークを採用するべきでは無い。
アダプタにしろ何にしろ技術的に不可能では無いが、どう考えてもコストもリスクも見合わない。
というか取り替えるシーンが全く思いつかないｗ
>>962 > データベースへのアクセス
データベースへのアクセスに使うのはライブラリであって
フレームワークじゃないよ。
Railsが馬鹿なんだけど、モデルがActiveRecordを
継承するという設計は間違い。
モデルはActiveRecordを使うが、
モデルはActiveRecordではない。
http://d.hatena.ne.jp/k-sato_at_oiax/20100722/1279803193 > ActiveRecord の後継と目される DataMapper では、継承を使わずに Mix-in を採用していますね。
> 継承を使いすぎたという反省が、Rails 業界にあるんじゃないかと思います。
> 他にも、MongoDB 用の mongoid も Mix-in アプローチを採用しています。
まあだいたい継承し過ぎでやめましょうってなるのは
どのフレームワークでも一緒ｗ
Javaが遠い昔に通りすぎた道。
そしてPOJOにいたる。
未来にはよ来い、PHPフレームワーク使いｗ
>>979 素人がtraitを覚える
↓
フレームワークの使い方がよくわからない＞＜
↓
traitで拡張しよっと（＾ｐ＾)俺スーパープログラマだ
↓
カオス
継承より委託にシフトしてった理由は、単純にテストでの優位性ってのがでかい
継承がダメっていうか、委託するように作っておけば、依存性を注入出来るようにも記述できるから
テスト対象ロジックと対象外ロジックの切り分けがしやすくなる
抽象化ができる部分の継承は悪ではない
馬鹿のいる職場で、データアクセスのライブラリの例外処理の隠蔽や機能制限のためにラッパー噛ませることはあるけど、
フレームワークそのものにラッパーとか何のメリットもないな
再発明とテスト工数の増大を引き起こすデメリットしか見えてこない
>>978 そのフレームワークに実装されてるライブラリを使ってたら
いっしょじゃね？
委譲を委託と言う奴の言うことなんか聞かないし
delegateのことを委託っていう人もいるみたいよ
でもまあ文脈からして委譲の方が正解な気がするけど
>985
日本のカレーは本家じゃないでしょ
>>978 例え話って話が逸れるから嫌いなんだけどさぁ…
さんま焼き定食に味噌汁がついてくると仮定するでしょ？
別に味噌汁が無くたって成立するけどさぁ
お店がセットで出す限りそれはさんま焼き定食という集合の一部じゃん
さんま焼き定食と言う名の集合に味噌汁を含めるか含めないかなんてお店次第じゃん？
これフレームワークとして置き換えてみたら
ライブラリは味噌汁、コンソールやらツールやらはおしんこって感じにならね？
じゃあさんまは何になるんだろうな
ってずれていくから例え話は嫌なんだよなぁ
でもその主張はおかしいと思うんだよな
>>986 Curryの作者って日本人じゃないの？
