【PHP】PHPフレームワーク総合スレ15
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
2010/12/12(日) 10:47:08ID:???●国外産●
symfony
ttp://www.symfony-project.com/
code igniter
ttp://codeigniter.com/
Zend Framework
ttp://framework.zend.com/manual/ja/index.html
CakePHP
ttp://www.cakephp.org/
Yii Framework
ttp://www.yiiframework.com/
●国産
ちいたん
ttp://php.cheetan.net/
Ethna
ttp://ethna.jp/
guesswork
ttp://classic.guesswork.jp/
maple
ttp://kunit.jp/maple/
●前スレ
【PHP】PHPフレームワーク総合スレ14
http://hibari.2ch.net/test/read.cgi/php/1253912143/
0687nobodyさん
2012/10/15(月) 10:05:51.72ID:???0689nobodyさん
2012/10/15(月) 14:00:44.00ID:???ってか、焼き直しっぽい感じがした。
0690nobodyさん
2012/10/18(木) 23:59:30.29ID:???少なくとも英語には対応したサイトで間口を広げないと
コミュニティの広がりに関してはなかなか難しいよな気がする。
なんだかんだ言っても英語を使うと新しいつながりが半端ないし、
やっぱりインターネットって米軍のお下がりだしな。
0691nobodyさん
2012/10/19(金) 22:12:39.78ID:???いっぱいある古参系のを使い続けるか、Yiiだとかそのあたりの
比較的あたらしめの奴を覚えて乗り換えるかのどっちかじゃね
俺々フレームワークに毛が生えたようなだけの小規模系FWだと、
需要が限りなく0なので覚える時間が無駄になる可能性が高すぎるんだもの…
0692nobodyさん
2012/10/20(土) 16:35:20.96ID:???0693nobodyさん
2012/10/20(土) 18:03:44.43ID:???0694nobodyさん
2012/10/21(日) 19:41:06.47ID:???本家もまったり続いてるけどな
0695nobodyさん
2012/10/28(日) 06:12:40.22ID:???正直MVCすら要らん、MVCの思想は凄いけど形だけあっても無意味なような。
symfonyの1だけはちゃんと思想が脈打ってて感動した。2は何であんなことになったのだろう
0696nobodyさん
2012/10/28(日) 18:13:20.92ID:???それほど崇高な印象はないなぁ。
0697nobodyさん
2012/10/29(月) 17:25:12.76ID:???完成すれば、既存のFWの対抗軸になりうる予感。
0698nobodyさん
2012/10/30(火) 21:39:35.43ID:???fuelphp流行ってるのは日本だけだし
yiiかlaravelに乗り換えたい
0699nobodyさん
2012/10/31(水) 06:20:49.70ID:???0700nobodyさん
2012/11/01(木) 02:26:55.54ID:???0701nobodyさん
2012/11/01(木) 08:51:39.45ID:???見つかるプラグインは1用ばっか
0702nobodyさん
2012/11/01(木) 14:27:44.18ID:???だが、新サイトで見るのは大体PHPだけど
0703nobodyさん
2012/11/02(金) 13:15:13.76ID:???言語としての優位性の比較はともかく、その点ではRubyはいいかもね。
0705nobodyさん
2012/11/03(土) 12:56:44.68ID:???0706nobodyさん
2012/11/03(土) 19:11:23.15ID:???0707nobodyさん
2012/11/03(土) 19:30:35.09ID:???0708nobodyさん
2012/11/26(月) 17:41:16.91ID:???0709nobodyさん
2012/11/26(月) 21:56:27.66ID:???071071
2012/11/27(火) 13:31:53.86ID:???0711nobodyさん
2012/11/27(火) 18:38:02.57ID:???0712nobodyさん
2012/11/27(火) 22:58:25.65ID:???0713nobodyさん
2012/12/21(金) 22:59:39.63ID:???PHP 3人
RUBY 4人
JAVA 5人
機能を追加時の増員の必要割合
ASP.net 開発者 小 デバッカー 小
PHP 開発者 中 デバッカー 大
RUBY 開発者 中 デバッカー 大
JAVA 開発者 大 デバッカー 中
動的言語やLAMPはバットノウハウなのは確か
まねするとコストばかりかかり 雪達だるま式にデバッグやらコード修正が増えていき
苦労することになる
大手しか開発できないような仕組まれてる ガラパコス利権
0714nobodyさん
2012/12/22(土) 12:25:06.36ID:???バットノウハウ
雪達だるま
コード修正が必要なのはお前だ
0715nobodyさん
2012/12/22(土) 22:40:10.26ID:???0716nobodyさん
2013/01/05(土) 15:30:52.70ID:???ｈｔｔｐ:／／tinyurl. com/9w97424
0717nobodyさん
2013/01/05(土) 23:00:05.00ID:???0718nobodyさん
2013/01/18(金) 13:39:36.56ID:???0719nobodyさん
2013/01/26(土) 04:49:54.75ID:???一番開発もメンテも楽な（メタ的な）フレームワーク
0720nobodyさん
2013/01/26(土) 07:23:14.58ID:???0721nobodyさん
2013/06/20(木) 23:35:41.10ID:NY+i8nF6---------------------------------------------------------
CodeIgniter Talk #01 2013/06/22 (土) 14:30 - 17:30 @ 渋谷
http://codeigniter-talk.doorkeeper.jp/events/4062
0722nobodyさん
2013/07/05(金) NY:AN:NY.ANID:???0723nobodyさん
2013/07/08(月) NY:AN:NY.ANID:JFWVTYwYflameworkって普通にある単語なんだが
0725nobodyさん
2013/07/08(月) NY:AN:NY.ANID:???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.
0726nobodyさん
2013/07/08(月) NY:AN:NY.ANID:CcFF0+Dd0727nobodyさん
2013/07/08(月) NY:AN:NY.ANID:???0729nobodyさん
2013/07/08(月) NY:AN:NY.ANID:???0730nobodyさん
2013/07/25(木) NY:AN:NY.ANID:???いくつもあるから、いまいち何使っていいかわからん。
適当に選んで、使って試して、だんだんわかっていくしかないのか・・・
しばらく前にZendでやってみたものの、利点も欠点もなにも、
これといった印象なかったし、違いのわかる男にはなれそうにないぜｗ
0731nobodyさん
2013/07/25(木) NY:AN:NY.ANID:???俺もそう。何使っていいかわからん。
ただ、規約に縛られるフレームワークは嫌。
規約を知らないと摩訶不思議な動作をするように見えるから。
規約なんて、開発完了しちゃえば直ぐ忘れてしまうもの。
規約を忘れた１年後の自分は、そのコードをメンテできそうもない。
0732nobodyさん
2013/07/25(木) NY:AN:NY.ANID:???自分で規約を作るだけ。
結局、規約に従ってプログラムするのは当たり前。
でなければ、行き当たりばったりの開発をするかだ。
こっちはもっと最悪。
何も決まっていない、似ている処理なのに
規約がないから、微妙に違ったコードになってる。
開発をするたびに、コードを読まないとわからない。
忘れる以前に覚えられない。
0733nobodyさん
2013/07/26(金) NY:AN:NY.ANID:???> しばらく前にZendでやってみたものの、利点も欠点もなにも、
> これといった印象なかったし
アーキテクチャってものを知っているか？
設計のことだが、どちらかと言えばコードレベルの設計の話。
アーキテクチャを知らなければ、フレームワークを見ても
単にいろんなライブラリがあるようにしか見えない。
アーキテクチャを知っていれば全体がひとつの塊として
考えられて作られていると理解できるようになる。
どう作っていいかがわかってくる。
経験を積めば、コードを見るだけで
あぁ。こうしろってことねと意図がわかる。
そうなると、ここにこの機能があるはずと推測できるようになる。
つまり君はまだアーキテクチャを知らんのだ。動けばそこで終わりという開発をしてるだろう？
単にフレームワークを使うのではなく、フレームワークをどのように使ったら
効率がいいかを考えながら作れば、アーキテクチャを理解できるようになる。
0734nobodyさん
2013/07/26(金) NY:AN:NY.ANID:WG0iVkUb0735nobodyさん
2013/07/26(金) NY:AN:NY.ANID:???これは俺の回りの現場の人間を見ての経験則だけどね。
アーキテクチャって言葉を知りはじめて、使ってみたいのかな。
0736nobodyさん
2013/07/26(金) NY:AN:NY.ANID:???俺の言う規約というのは、例えば、CakePHPの場合、
DBのテーブルに created_at というフィールドがあれば自動的に
値が書き込まれる・・・
ということ。
これらは、自分が書いたコードを追うだけでは挙動を理解でき
ず、CakePHPを知っていないとダメなんだよね。
規約に縛られるフレームワークは、規約により自動化されることが
多いのでコードを書く量が減り開発が速いけど、規約を忘れたときの
メンテが大変、という感じがします。
慣れてしまえば心配無用なのかな？
0737nobodyさん
2013/07/26(金) NY:AN:NY.ANID:???困ることはないんだけどな
0739nobodyさん
2013/07/26(金) NY:AN:NY.ANID:???もしそういう規約がなかったらで考えよう。
日付が格納されるフィールド名はバラバラ
ある所はcreated_atだったり、ある所はcreatedだったり
ある所はcreate_dateだったり。
そうならないときに「コーディング規約で決める」というふうにやっぱり規約が出てくる。
規約を忘れたら、バラバラのフィールド名になる。
規約を思い返すのならCakePHPの規約を思い出せるだろう。
フィールド名がバラバラなだけではなく、あるところは
日時なのにあるところは日付だけだったり、コードを読めばわかるだろうが、
フィールド名を見ただけでわからず、該当フィールドに格納しているコードを
一つ一つ読まないと確証が得られない。
規約を忘れたらというが、規約を忘れるような人は手作業で書いたコードも忘れる。
コードを読み返す時間があるのなら、CakePHPの規約を読んだほうが早い。
忘れた時にメンテが大変なのはどっち？ コードを読むのが苦痛じゃないから
実際に時間がかかってるはコードを読む方なのに楽だと勘違いしているだけ。
0740nobodyさん
2013/07/26(金) NY:AN:NY.ANID:???forループはfor文を忘れた時にメンテナンスが大変。
結局はこう言ってるのと同じ。
0741nobodyさん
2013/07/27(土) NY:AN:NY.ANID:???0744nobodyさん
2013/07/29(月) NY:AN:NY.ANID:???って探せばありそうだな
0745nobodyさん
2013/07/29(月) NY:AN:NY.ANID:???0747nobodyさん
2013/07/30(火) NY:AN:NY.ANID:???0748nobodyさん
2013/07/30(火) NY:AN:NY.ANID:???0749nobodyさん
2013/07/31(水) NY:AN:NY.ANID:1ypj56570750nobodyさん
2013/08/01(木) NY:AN:NY.ANID:???で、「あれができたらいいな」とか「これを簡略化したい」などを
まとめ、それから、それらを実現できそうなフレームワークを探す
0751nobodyさん
2013/08/02(金) NY:AN:NY.ANID:???とりあえず情報量の多いCakePHPからやるのが無難だろうな。
まわりに詳しい人がいたらその人が使ってるFWでも良いと思う。
0752nobodyさん
2013/08/07(水) NY:AN:NY.ANID:???まず大半の初級者は Model = DBテーブル と刷り込まれて、
正しいMVC分けが出来なくなり、Controllerが糞みたいに肥大化する。
普通に考えれば、別途ライブラリ(真の意味でモデルに該当するモノ)を構築すれば良いのだが、
それが出来ない。全部コントローラに記述しちゃう。
また大半のフレームワークではメソッドやコントローラアクションに関する粒度が規定されていない為、
1メソッドが糞みたいに長かったり、1コントローラに全ロジックが書かれたりする。
素人は一度は自作FWを作る経験をすべき。
0753nobodyさん
2013/08/07(水) NY:AN:NY.ANID:???モデルを理解したうえであらためてCake使うと
「ファーーーｗｗｗｗ よう考えられとんねーー」
と思うこと請け合い
0754nobodyさん
2013/08/07(水) NY:AN:NY.ANID:???cakeがよく考えられてることとはネタですか
0755nobodyさん
2013/08/07(水) NY:AN:NY.ANID:???実際は笑えないことが多いんだけど
0756nobodyさん
2013/08/08(木) NY:AN:NY.ANID:???0757nobodyさん
2013/08/09(金) NY:AN:NY.ANID:???0758nobodyさん
2013/08/09(金) NY:AN:NY.ANID:???出来ればそれを選ぶメリットも一緒に
0759nobodyさん
2013/08/09(金) NY:AN:NY.ANID:???FWのせいで効率が落ちる＆保守性が落ちるのは本末転倒なので好きなの選べばいい。
Cakeは開発グダグダだし、独自方言大杉で他FWに移行し辛いし、一緒に心中する覚悟が必要かな
最近だとIDEとの親和性も大事だね
0760nobodyさん
2013/08/09(金) NY:AN:NY.ANID:???0761nobodyさん
2013/08/09(金) NY:AN:NY.ANID:???CodeIgniter のライセンスの問題で話題になっただけで、
他と比べて特別何か優れてるわけでは無い
0762nobodyさん
2013/08/09(金) NY:AN:NY.ANID:???俺もそう思う。
0763nobodyさん
2013/08/09(金) NY:AN:NY.ANID:???というようなフレームワークってある？
0764nobodyさん
2013/08/09(金) NY:AN:NY.ANID:???0765nobodyさん
2013/08/09(金) NY:AN:NY.ANID:???生PHP＝独自設定ファイルが不要という意味ならば、
Zendとかじゃね？フレームワークとしては微妙だけど、ライブラリとしてはまぁまぁ便利
>>764
どのFWも一長一短な上、無駄に種類が多いからね･･････
0766nobodyさん
2013/08/09(金) NY:AN:NY.ANID:???0767nobodyさん
2013/08/10(土) NY:AN:NY.ANID:???IDEと親和性が高いフレームワークでオススメってある？
phpStorm使い始めたんだけど、コード補完が効かないと耐えられない体になってしまったよ
0768nobodyさん
2013/08/10(土) NY:AN:NY.ANID:???VisualStudioでアプリ作ってると、コード補完が効かないのは耐えられない。
0769nobodyさん
2013/08/10(土) NY:AN:NY.ANID:???他もあると思うけど使わないから知らない
0770nobodyさん
2013/08/10(土) NY:AN:NY.ANID:???結局素のPHPの部分しか、解釈してくれないようだ
コンポーネントの関数とかまで見つけてサジェストしてくれたら、最高なんだが
0771nobodyさん
2013/08/10(土) NY:AN:NY.ANID:???実際に実行される直前になるまで
変数に入っている型がわからないなら
補完できなくて当然なわけで。
0772nobodyさん
2013/08/10(土) NY:AN:NY.ANID:???＞実際に実行される直前になるまで
＞変数に入っている型がわからないなら
＞補完できなくて当然なわけで。
そう思っていた時期が俺にもありました。
が、最近のIDEはコードとコードコメントから中身を推察して、凄い精度で補完してくれるんだよ。
ただし、マジックメソッドを多用してたり、PHPコードでは無く文字列や設定ファイルを多用してると、流石に無理でCakeは相性が悪い。
0773nobodyさん
2013/08/10(土) NY:AN:NY.ANID:???0774nobodyさん
2013/08/10(土) NY:AN:NY.ANID:???0775nobodyさん
2013/08/10(土) NY:AN:NY.ANID:???出来るどころか、その逆、コードを解析してコメント入力の補完までしてくれるよ。
以下のメソッドがあるとする。
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)
0776nobodyさん
2013/08/10(土) NY:AN:NY.ANID:???0778nobodyさん
2013/08/10(土) NY:AN:NY.ANID:???0779nobodyさん
2013/08/10(土) NY:AN:NY.ANID:???0780nobodyさん
2013/08/11(日) NY:AN:NY.ANID:???普通に変数に型を書いたほうが
見やすいと思うよｗ
0781nobodyさん
2013/08/11(日) NY:AN:NY.ANID:???アノテーションで駆動させてますよ
0782nobodyさん
2013/08/11(日) NY:AN:NY.ANID:???0783nobodyさん
2013/08/11(日) NY:AN:NY.ANID:???/**
* @param int $a
* @return Hoge
*/
function getHoge($a = 1)
$aを二回書くのは無駄でしか無いね。
もっと言えば@paramも無駄だし@returnも無駄。
こんな感じでコメントを書く場所が厳密に決まっていて
同じ事を二回書かなくて済む言語出来ないかねぇ。
// 関数と戻り値のコメントを書く。
function Hoge getHoge(
int value, // ここに引数のコメントを書く
string str, // ここに引数のコメントを書く
) {
・・・
}
valueが@paramなのは自明だし型も自明
0784nobodyさん
2013/08/11(日) NY:AN:NY.ANID:???DRYが何か判ってて書いてるんだろか
読んでるこっちが恥ずかしくなるわ
0785nobodyさん
2013/08/11(日) NY:AN:NY.ANID:???反論はできないのであった
完でいい？
0786nobodyさん
2013/08/11(日) NY:AN:NY.ANID:???変数に対する型指定アノテーションも存在するよ
厳密に型指定したいならPHP以外を使えば良いんじゃね？
>>783
コメントは別に「型」を記載する為だけのものじゃないからね。
あと、君が上げてるサンプルは長文になった時、確実に可読性が確実に落ちると思うんだがｗ
＞コメントを書く場所が厳密に決まっていて
うん。それがphpdocだ。
C〜C#、Javaあたりのソース読んでみ同じような事してるよ
0787nobodyさん
2013/08/11(日) NY:AN:NY.ANID:???長文になる時は別の書き方を用意すればいいだけの話。
// 関数と戻り値のコメントを書く。
// [*1] : 長いコメント
// [*2] : 長いコメント
function Hoge getHoge(
int value, // 短いコメント [*1]
string str, // 短いコメント [*2]
) {
・・・
}
重要なのは、コードを変更した時、同じ事を二度やらなければいけないということ。
コードとドキュメントの整合性が取れなくなるのは、これが理由。
■ このスレッドは過去ログ倉庫に格納されています