cake2の情報が少ないし
見つかるプラグインは1用ばっか

PHPの開発自体減ってるのかな？記事関係はRubyばっかりだ。
だが、新サイトで見るのは大体PHPだけど

特に最近は、自分から発信する開発者がRubyのほうが多い感じを受ける。
言語としての優位性の比較はともかく、その点ではRubyはいいかもね。

>>703
情報発信者が多いのは結構だけどなぁ・・・
rubyってバッドノウハウ多くね？

っと、PHPスレで他言語disっちゃいかんな。ごめんよ

PHPをdisれ

バッドノウハウの多さを競うならPHPだって負けてないぞ

yiiとCodeIguniter迷いすぎる

CodeIguniterでいんじゃね？

スペルが違うんじゃね？

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コードを一つ見本にして全員で真似するのが
一番開発もメンテも楽な（メタ的な）フレームワーク

714と715、面白いな。

>>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.

普通に使われてることの証明になってない

>>727
辞書をひくことすらできないお馬鹿さん、乙

ウィクショナリーが辞書だと思い込んでるゴミ乙

PHPのフレームワークって、よく名前が出るものだけでも
いくつもあるから、いまいち何使っていいかわからん。
適当に選んで、使って試して、だんだんわかっていくしかないのか・・・

しばらく前にZendでやってみたものの、利点も欠点もなにも、
これといった印象なかったし、違いのわかる男にはなれそうにないぜｗ

>>730
俺もそう。何使っていいかわからん。

ただ、規約に縛られるフレームワークは嫌。
規約を知らないと摩訶不思議な動作をするように見えるから。

規約なんて、開発完了しちゃえば直ぐ忘れてしまうもの。
規約を忘れた１年後の自分は、そのコードをメンテできそうもない。

規約に縛られないフレームワークでは
自分で規約を作るだけ。

結局、規約に従ってプログラムするのは当たり前。


でなければ、行き当たりばったりの開発をするかだ。
こっちはもっと最悪。
何も決まっていない、似ている処理なのに
規約がないから、微妙に違ったコードになってる。
開発をするたびに、コードを読まないとわからない。
忘れる以前に覚えられない。

>>730
> しばらく前にZendでやってみたものの、利点も欠点もなにも、
> これといった印象なかったし

アーキテクチャってものを知っているか？
設計のことだが、どちらかと言えばコードレベルの設計の話。
アーキテクチャを知らなければ、フレームワークを見ても
単にいろんなライブラリがあるようにしか見えない。

アーキテクチャを知っていれば全体がひとつの塊として
考えられて作られていると理解できるようになる。
どう作っていいかがわかってくる。

経験を積めば、コードを見るだけで
あぁ。こうしろってことねと意図がわかる。
そうなると、ここにこの機能があるはずと推測できるようになる。

つまり君はまだアーキテクチャを知らんのだ。動けばそこで終わりという開発をしてるだろう？
単にフレームワークを使うのではなく、フレームワークをどのように使ったら
効率がいいかを考えながら作れば、アーキテクチャを理解できるようになる。

コードレベルって書くとむしろ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～数行レベルで済むレベルの話

>>742
じゃあ一～数行でかけよｗ

規約違反はエラーになるPHP用文法チェッカがほしい
って探せばありそうだな

つ codesniffer

>>745
こんなのがあるんだ
これってCake用っぽいけど、オレフレームワークでも使えるかな
ちょっと試すか

全然Cake専用とかじゃなかった。 これ便利そう！ありがとう！

え？なに？ なんか知らないけど、どういたしまして！

とりあえず初心者は何やれば良いの？

初心者なら、一度でいいからフレームワークを使わずに作る
で、「あれができたらいいな」とか「これを簡略化したい」などを
まとめ、それから、それらを実現できそうなフレームワークを探す