>>699
その勝手に変える作業に金出してもらえないって話じゃないか？

>>701
そんなもん、普段の開発費に含めればいいじゃないか。

>>700
君の非難はちょっと違うと思うんだよ。
俺がオレオレフレームワークなり、ライブラリを作った上で
「PHPのバージョンが変わったら全て書き換えないといけない」
的な事を言い出すなら、「技術がないだけ」って切り捨てるのもわかる。

でも、CakePHPというフレームワークでの話だろ？
Cakeが1.3→2に変わっても、君の言うようにどのバージョンでも
動けるコードになっているかな？なっていないよね。

もちろん、「CakePHP選んだお前が悪い」っ
てのなら自身の選択ミスだ。俺が悪い。
だが、俺の言う「折り合いをつける」ってのは、
「なんだかんだ言われてもやる」なんだけどな。
>>693の書き込み見てくれればわかると思うが。

>>703
やっぱり技術力がないだけ。

CakePHPを選ぶのが間違いとかそういう話ではない。
何を選ぼうが未来がどうなるかはわからない。
安全な未来を選ぶ力が重要なのではなく、
どんな未来が来ても、そこに至るルートを見つける力が重要。

まず、フレームワークは使うが
本質的なコード＝重要なコード＝大部分のコード
というのはフレームワークに依存しないように作る。
（作れるのが技術力）

フレームワークにべったりくっついた設計にするのではなく

フレームワーク ⇔ 薄い中間層 ⇔ 大部分のコード
こういう設計にしておく。フレームワークは変わるのは
当たり前の話なんだから、最初からそうすべきと判断する
（これも技術力）

> Cakeが1.3→2に変わっても、君の言うようにどのバージョンでも
> 動けるコードになっているかな？なっていないよね。
フレームワークに依存しまくるから、動かないコードが”大量に"できる。

フレームワークに依存しない部分を大量にして、依存している部分を
最小限にしておけば、動かないコードを最小限の力で移行させられる。

CakePHP1.3の時代に、まだ見ぬ2に対応することは不可能だが、
CakePHP1.3の時代でも、フレームワークが無いとみなして作るのは可能だ。

フレームワーク等、バージョンが違ったとき
互換性が100%でないのは知っているし100%の互換性はないのが普通。

http://book.cakephp.org/2.0/ja/appendices/2-0-migration-guide.html
> 2.0 移行ガイド
> このページはプロジェクトを2.0に移行する手助けをする、
> CakePHP 1.3からの変更点の要約をします。 またこれは、コアへの
> CakePHP 1.3ブランチからの変更点への最新の開発者リファレンスともなります。
> 必ずこのガイドにある新機能とAPIの変更の全てのページを読んでください。

こういうのもある。たいていの有名どころであれば移行する手段は用意されている。
これを読めば、何が良くて何がダメでダメなものはどう対処すればいいかわかるはず。

こういうのを読んで、移行できない問題点を見つけて、すぐに諦めてるでしょ？

移行っていうのは、自分の作ったシステムのフレームワークを入れ替えて
そのままじゃ動かない。あーだめでした。もうお手上げだー。
移行できない。いつまで延命できるかなー。ってこういうものではない。

移行できないものをどうやれば移行できる形にできるか見つけて、
直して、必要ならば新旧両対応できる書き方に書き換えながら、
移行できない問題点を潰していくのが本当の移行の仕方だ。

これが技術力なんだよ。

>>704
君の非難を素直に受けるし、技術が無いのも確かだろう。
でも、怒りの矛先を向けるのは俺じゃないと思うんだが。

君は技術ありきで話をしているけど、話の最初は>>687だよ？
君が作った素晴らしいコードなら、1.3だろうと2だろうと3だろうと
チョチョイのチョイでバージョンアップできるから、困らないかもしれないね。

だから、バージョンアッップ後の更新作業をしてもお金取ろうとしないのかもね。
でも、そういう考えならやっぱり俺が提示する
「技術の進化と客の要求に対応して折り合いをつける」
ってな事にならないかな？

そもそもスレの流れをちゃんと見てるか？
ちゃんと見ないのに非難する人間って技術力高いのかなぁ。

>>706
> 君が作った素晴らしいコードなら、1.3だろうと2だろうと3だろうと
> チョチョイのチョイでバージョンアップできるから、困らないかもしれないね。

それは大きな勘違い。

未来なんてわからないし、最初は技術力低いのが当たり前
フレームワークなんて難しい物を、最初から完璧に使いこなすことなんて不可能。
最初から素晴らしいコードなんてかけるわけがない。

じゃあどうするか。
それが連続的に変化させていく技術力だよ。

高い開発技術ではなく
汚いコード（古いコード）から、綺麗なコード（新しいコード）へ
変化させていく技術力。

それが圧倒的に足りない。

具体的にどんなコード書いてるんだかｗ
全部ラップしてるんでしょ？オーバーヘッドえらいことになるやん

>>707
だったら、それを俺じゃなくて
「Cakeのバージョン変えたいけど、お金もほしい」
って奴に言ってくれよ。

俺はどちらかというと、あんたみたいな考え方だよ。
向上心もなく、単に金がほしいなら
「技術の進化と客の要求に対応して折り合いをつける」
ってな言い方はしないだろ？

どこがあんたの気に触ったのかしらないけど、
頼むからスレの流れを読んで非難してくれ。技術云々を語る前にな。

普通に考えて、必要なのは技術力でなく交渉力だと思うんだな。

金出せよ（直球

>>696
なんか俺へのレスから長々と続いてるみたいだけど、それは置いといて。

もっと動作を早くするとか、別のサーバーにのせるために、
CakePHP1から2にする必要があるなら、
それは客が負担するコストじゃね？
実際CakePHP2は1より早くなってるし、キャッシュエンジン使うとかリバースプロキシの導入とか、
他の手も考えてみて、CakePHP2化が有効なら、
後は普通に見積もって提案するのがいいと思った。

機能追加のために、CakePHP2用のライブラリが使えないことに関しても、
CakePHP2化してあれば、機能追加時に使えるライブラリの選択肢が増えて、
機能追加の見積もりが安くなるかもしれないから、コストかけてCakePHP2化しませんか？
って話にならんかね。
それで、CakePHP1のままって言われたら、機能追加は相対的に高めの見積もりになり続ける、と。
まぁCakePHP1で保守開発するのは、高めにもらってもあまりやりたくは無いけど。

全部ラップするくらいならオレオレフレームワーク作れよと。
フレームワークの上にフレームワーク乗っけてるようなもんだから
何がやりたいのかわけわからんわ。
どんなにラップしようがcakephpのバージョン上がったら
それに合わせて書き換えないと動かないんだから
それならはじめからラップなんてしなくていいのよ。
ビジネスロジックだけ分けておくとかならともかく。
ばかばかしいわ

>>713
御意。

>>713
> 全部ラップするくらいなら

誰がそんなこと言ってんの？

あぁ、こいつか。>>708

> 全部ラップしてるんでしょ？オーバーヘッドえらいことになるやん

いきなり的はずれなこと言い出したのはこいつだな。
こいつ以前にはラップという話は出てきていない。

なんでラップなんかするんだか。

上の方で、バージョンの差異を吸収出来る様に云々って言葉が出てきたから、
ラップって言ったんじゃない？

なんか言っている事はすごく正論なんだが、金という最も大事な項目を考えないで議論している人がいる気がする。
現実と理想とで議論しても何時までもかみ合わないというか。

>>712
みんな名無しなので話がややこしくなるが、
俺は>>693、696を書き、なぜか煽ってきた>>700は
「他人（客）のせいにするのではなく、自身の技術の無さを問題視しろ！」
と言ってるわけだ。

だが、俺はそもそも技術云々なんて論じてないし、
出来ない（やらない）とも書いてない。

俺の意見としては>>696に書いたとおり、
「客がバージョンアップを希望する場合もあるし、
　だからといってその分のコストを請求し、納得させるのも難しいから、
　どこかで折り合いを付けなければいけないね」
と言った、中立的な発言をしたわけだ。

開発者としてはバージョンアップでもお金欲しいけど、
客は見た目変わらないからお金を出しづらいね、みたいな。

なのに、なぜか「技術が無いから対応できないんだ！｝みたいな非難をされている。
きっとレスの流れを見ずに一部だけを切り取って腹が立ったのだろうけど、
未だに俺のレスの何が癇に障ったのかはわからない。

>>718
お金を出さない客のためになぜ働くんだろうか？

>>719
俺が1.3→2.2にした時は、
フレームワークのバージョンアップとは言わずに、
他の機能を追加する面目で対応したよ。
1.3のままだと不都合を感じたし、蔵も新機能が欲しかったからね。

だけど、バージョンアップだけで見積請求してもいいと思うし、
それに苦言を呈してくる客に対してメリットを感じなければ、
付き合いを止めればいい。それだけの話だよ。
どっちの言い分も考えた上で発言しているだけだから。

>>720
> 他の機能を追加する面目で対応したよ
それが普通

で、そういうことができないって言ってるんでしょ？
自分の書いたコードが1.3にがっつり依存してしまって
全部書き直しぐらいな、そうとう大変なことになってしまってるから。

だからフレームワークを使うのはいいが、
依存しまくらないようにしろという話。
それが出来ない奴は技術力無いってことよ。

そういったらなぜか全部ラップするとか言う
斜め上の対応策が出てきてワロタ。
そうか、技術力低いと、そういう間違った対応をするのか。

>>718
> なのに、なぜか「技術が無いから対応できないんだ！｝みたいな非難をされている。

違う違う。「技術がないから金がかかるんだ」って非難してる。
CakePHPの1系から2系へのバージョンアップなんて
>>720みたいに、他の機能を追加する名目で対応しろよ。

>>722
どのくらい大変かは、アプリのボリュームにもよるだろうなぁ。
コンポーネントやビヘイビアをちゃんと書いて、DRYに作っていれば、
移行系は手を入れる必要がある箇所が少なくなって楽になるとは思うけど、
影響がある化も知れないアクションは全てだから、
ボリュームが大きいと、動作確認だけで大変になる。
テストを書いてたとしても、フロントの振舞いこみで確認しないと、
もしエンバグしたら事だからなぁ。
あと確か、1系から2系で、テストフレームワークが変更になった気がするし。

フレームワークのバージョンの移行なんて、ボタンひとつで出来るわけじゃないし、
時間を使う以上金はかかるよ。お仕事だもの。
単純に移行だけで、機能も増えないし見た目も変わらないとなると、
無知な客からすると、どんな見積もりを出しても高く見えるだろうけどね。
でも、無知な客はむしろよりコストを負担して欲しいわ。

誰が誰だかよくわからなくなってるなw

>>721
>で、そういうことができないって言ってるんでしょ？
「それが普通」って認めてるのに、出来ないって言ってるとは？？

>>722
718=720なわけだが。レスの感じでわかると思ったけど。

結論、世の中、金。

かねくれかね

ここ数年、Cakeを卒業したいと思いつつ、やはり金と時間が大事で
Cakeを使い続けてるわ…

まあね、Cake以外を勉強する時間も
書籍に消える金も大切ですもんね。

そんなみみっちい

CakePHPよりいいフレームワークなんてないからね

皆さん、良いお年を

来年はCakePHP卒業

ついでにPHPも卒業

そして２ちゃんも卒業

童貞も卒業

ブラックIT会社も卒業

人生も卒業

マジレスするとCake PHPよりゆるくて俺俺ができるフレームワークないからCake最強
ただし引き継ぎは出来ないと思う

ああYiiを忘れてた
ゆるゆる具合が素晴らしいな

ゆるいってどういう意味？

Cakeは緩すぎてダメだ
次のシステムは別なのにするわ

Viewがひとつの<?php ・・・ ?>で括られてたり、モデルやコンポーネントを呼んでゴリゴリロジック書いてたりするシステムのメンテはもう無理

>>744
URLに対応したファイルがあって、そこにあれこれ書かないと理解できない人たちの産物か

PHPスレから来ました

Cakeで途中からMySQLのテーブルに列を増やしたんだがクエリがそれに追随して増えてくれん
そりゃ、$this->query()で直接書けばいいんだが、fetchなんかが増えた列に対応してくれん、、、
どこをなおせばいいんだ？
Model/*phpでdisplay属性に追加すればいいのか？

>>746
>クエリがそれに追随して増えてくれん

普通はフィールドの変更は即座に反映されるぞ。
もっと詳しく書かないと何も言えんがな。

「display属性」って、もう何が何だか・・・

cakePHPだとどの位の大規模サイトまで耐えられるのかな？

コントローラーが400個あるぐらいのサイトまでなら仕事したことある

>>749
テーブル数はどのくらい？