【PHP】フレームワーク CakePHP　3ホール目【本命】

【PHP】フレームワー� ..

331:nobodyさん
08/03/26 03:36:11

なんだこの過剰反応ぶりｗ

みるからに同一人物のようだが、
ただの使用例に必死すぎだろｗ

332:nobodyさん
08/03/26 03:41:59
○○○を使わない人にとっては
激しく必要のない○○○じゃね？

なんにでも当てはまるなｗ
無理やり反論しようとして滑ってる。

333:nobodyさん
08/03/26 03:47:41
>>331
>>332
同一人物乙

334:nobodyさん
08/03/26 03:51:47
確かに同一人物だが、それが何か？

335:nobodyさん
08/03/26 04:15:24
>>333
cakephpとは外れたこと書くな

336:nobodyさん
08/03/26 04:38:16 pkIggipT
CakePHPで開発するアプリを設計する際にUMLで書いてる人いる？
シーケンス図やクラス図なんかどんな風に記述してるかとか見せてもらえると
参考になります。

337:nobodyさん
08/03/26 04:51:55
>>336
UMLを使うと従来の方法より効率が落ちる時もある。
なぜなら、従来なら手書きで適当に書いてきた図をUMLでどうやって書けばいいのか調べなければならないから。
書き方が全部頭の中に入った後でなら従来よりスムーズに開発ができるようになるかもしれない
が、しかし、それまでは相当の苦労が必要ｗ
オブジェクト指向開発とUMLとはまた別の話でUMLはオブジェクト指向開発の道具にすぎない

338:nobodyさん
08/03/26 04:59:22
>>336
UML？時間の無駄だろ。そんなん書いてたら
工数オーバーするしで誰も喜ぶもんおらんで

339:nobodyさん
08/03/26 05:04:03
Ｃ＃やＪＡＶＡならわかるけどＰＨＰでＵＭＬて
そんなクラスが複雑じゃないやん

340:nobodyさん
08/03/26 05:24:25
そういう問題じゃねーだろｗ

341:nobodyさん
08/03/26 10:28:27
>>339
確かにphpでＵＭＬてぐぐったけどあまり無いな

342:nobodyさん
08/03/26 10:50:05
そりゃぐぐったことが無いという人もいるだろう。
だがそれは個人の話であって統計的な意味は無い。

検索結果のほうがまだ意味があるな

PHP UML の検索結果約 957,000 件中 1 - 10 件目 (0.03 秒)
Java UML の検索結果約 593,000 件中 1 - 10 件目 (0.04 秒)
C# UML の検索結果約 404,000 件中 1 - 10 件目 (0.04 秒)

343:nobodyさん
08/03/26 11:29:28
Cakephpと関係ない話すんなやボケどもが

344:nobodyさん
08/03/26 11:31:39
なんでCakePHPにＵＭＬの話が出るのかわからんｗ

345:nobodyさん
08/03/26 11:37:41
>>340
そういう問題だろｗ

346:nobodyさん
08/03/26 11:58:29
俺はJavaをメインでやってるけどＵＭＬは
複雑になってくるクラス間の関連性の構造の手助けとしてＵＭＬを活用することが多い
だから>>339のいってるように複雑なクラスで無ければ必ずしもＵＭＬが必要とは思わない

347:nobodyさん
08/03/26 12:17:07
ユースケースは必ず書くけど、シーケンスみたいな実装よりの奴は
実装者が未熟な場合か、処理が複雑なときだけかな。
クラスダイアグラムはモデル限定でこれもテーブル構成が複雑なときだけ。

ユースケースは文書に起こして仕様書にするので必須。

PHPのクラスを自動生成してくれる奴なかったっけ?
あれでCakeのモデルを自動的に管理してくれると楽かも...楽じゃないかw

348:nobodyさん
08/03/26 12:24:40
UMLのクラス図ってようするに継承関係と関数定義（実装コード無し）を
書いているだけでしかないからなぁ。

それならコードで書いてコードからクラス図を自動生成したほうが楽。

349:nobodyさん
08/03/26 12:38:45
Javaだとクラスが複雑になってしまうんだよね。
正確にはEJBを使った場合だが、同じものを作るにしても
無意味に複雑になりすぎる。
あれじゃあ、UMLが必要になるのもわかる。

350:nobodyさん
08/03/26 13:44:26 ktIW9Uv7
ちょwww おまえら設計書も書かずに開発しちゃってるのかよ、涙がでるな。
それだから「できました」とかいいながらテストしたらバグ出まくりのプログラムなんか量産しちゃうんだよwwww

UMLじゃなくてもいいが、実装前に詳細なロジックを書き起こしてからコードつくるのは常識だろ。
時間がかかる、めんどくさい、頭の中にもう仕様書書いてあるから、という奴に限ってたいした技術力じゃないんだよな。
設計書ってのはコーディング作業が楽になるだけでなく、チーム関係者との意識共有や、リリース後しばらくたってメンテが必要になった時に効果がでるもんだぜ。
プロとして仕事でやってるならば当たり前だと思ってるが、ここにはプロはいないのか？

351:nobodyさん
08/03/26 14:32:19
楽譜の読めないミュージシャンもいるしな。

352:nobodyさん
08/03/26 15:25:48
>>350
実装前に詳細なロジックを書き起こしてからコードつくるのは常識だろ

それお前だけの常識乙ｗ
CakePHPのような小規模案件に無理があるぞお前ｗ

353:nobodyさん
08/03/26 15:29:27
>>350
どこの大手で働いてんだよCakePHPさわってる分際でｗ

354:nobodyさん
08/03/26 15:34:17
>>350
CakePHPでいくらも稼げてねーくせにｗ

355:nobodyさん
08/03/26 15:37:50
短納期で回転させるのがCakePHPのメリットなのに
わざわざＵＭＬとか工数伸びるだけやんけ
そんなんで、ほんまに黒字になってんのかｗ

356:nobodyさん
08/03/26 15:41:14
>>350
スレ違いながら言わせてもらうと・・

実際、開発しながら見えてくる事って多いよね。
キチンと設計や仕様固めが出来ないまま、見切りスタートを切ってしまうことも多々。
問題は、その仕様の追加、変更に対応出来るように設計する事だよ。

357:nobodyさん
08/03/26 16:12:51
そうなんだーUMLって書かないんだ。
俺は書き方すら知らないけど。

作る前に一応メモに何をどうするかを書き出して、その通りに作ってくね。
あまりに自分の頭の中だけで作ると変数とか何を使ったかわからなくなったり。

イラレで仕様書とか作るのが激しくめんどい。
よって手書きで自分はやってます。

358:nobodyさん
08/03/26 16:15:44
>ここにはプロはいないのか？
w

359:nobodyさん
08/03/26 17:32:25
え…設計フェーズ飛ばしていきなりコーディングに入るの？ギャグだろ？
最低限、要求定義書とユースケースとビジネスロジック(=モデル)の関係図とそれを基にしたスキーマ設計位は必要じゃねーの
打ち合わせ段階で作りまくるじゃん、そんなの
どやってクライアントのイチャモンに対応してるの？

>>357
イラレで仕様書とか正気？

360:nobodyさん
08/03/26 17:56:28
パワポが激しくめんどくさい。
よって俺もexcel＆イラレだな。

361:nobodyさん
08/03/26 17:58:19
まあ、コーディング前の設計は
概要みたいなもんだからね。

たとえば関数をすべてコーディング前に列挙できるかといったらまず不可能

プロのプログラマはコードで設計するんだよ。
鉛筆で図を書くか、キーボードでコードで書くかの違い。

362:nobodyさん
08/03/26 18:01:13
プロはソースにたくさんコメントを残す。

363:nobodyさん
08/03/26 19:04:34
×プロはソースにたくさんコメントを残す。
○プロはソースに意味のあるコメントを残す。

364:nobodyさん
08/03/26 20:37:18
>>359
もっとプログラマと交流深めた方がいいよ

365:nobodyさん
08/03/26 20:39:13
>>359
どんだけ狭い世界観なんだよ

366:nobodyさん
08/03/26 21:07:55
10分以内（　´,_ゝ`）

367:nobodyさん
08/03/26 21:55:41
>>364
この人、確実に嫌われてるだろうな、プログラマに。

368:336
08/03/27 00:00:03 d9lPRB8S
>>336です
意外と盛り上がっててびっくり…

369:nobodyさん
08/03/27 01:42:38
>>359

イラレで仕様書は普通。

370:336
08/03/27 02:53:28 d9lPRB8S
>>369
マジかよ。それなんてイラレ？

371:nobodyさん
08/03/27 11:48:14
たとえばフォームにある省略可能な数値型の項目に
値を省略して（空文字で）データベースに保存した場合空文字でINSERTされる。

このときのどう保存されるか動作はデータベース依存であり
MySQLは0になり、PostgreSQLはエラーになる。

URLﾘﾝｸ(trac.cakephp.org)
チケットが出ていたみたいだが、修正無しでクローズ？

これ直る見込みないんかいな。確かに空文字とNULLは違うものだが
「データベースの省略可能な数値フィールド」ってのは
数値とNULLしか入れられないんだよね。

どうせNULLが入ったフィールドをModelから読み込むと
空文字になるんだし（あってるよね？）
NULLに変換して保存したほうが実用的だと思うんだけどなぁ。

データベース間の違いも吸収したほうがいいし。

beforeSaveあたりで書き換えるか・・・

372:nobodyさん
08/03/27 15:25:42
>>371
それはCakePHPに限ったことでは無いから死んでこい

373:nobodyさん
08/03/27 15:27:34
>>371
そんなどうでもいい作業するくらいなら
コンビニでバイトするよ

374:nobodyさん
08/03/27 17:50:07
CakePHPのアソシエーションでBelongsToやhasOneを渡り歩いて
広範囲のテーブルから値を持ってくるにはどうすればいいんでしょうか

SQLならLEFTJOINを繋げて行けば済むのですが
単純にrecursiveを増やしていくとクエリの量が異常に増えて困っています

375:nobodyさん
08/03/27 19:31:16
最近低レベルの煽りしか返さない奴がいるなウザイ。
どうせ同一人物だろうからトリップつけてくれ。削除すっからさ。

376:nobodyさん
08/03/27 19:48:23
>>375
低レベルの質問しかないから仕方ないこと

377:nobodyさん
08/03/27 19:51:40
>>374
リファレンスみろよ
こんなとこで聞くなカス

378:nobodyさん
08/03/27 20:14:15
>>376-377 だからトリップつけろってｗ

379:nobodyさん
08/03/27 21:54:01
>>377
アソシエーションが直接繋がっている関係なら資料は山ほどあるのですが
例えば4テーブル先まで繋がっているデータを手繰り寄せてくる場合、デバッグ情報を見ると
一旦findで取得してきた配列をforeachで回して一つ一つまたfindを使っているように見えます
結果、データ自体は取ってこれるもののSQLの発行数が異常な量になってしまいとても使う気になれません

SQLの発行を抑えつつもアソシエーションを柔軟に広げるためには、自前でqueryを使うしかないのでしょうか？

380:nobodyさん
08/03/27 22:01:13
ユニットテストでfixturesの機能使っている人いる？

var $fixtures = array(～～～);

こんな感じでfixturesをしているわけだけどさ、
なんかテーブルの生成のタイミングとか変じゃない？

テストを単体で実行すると問題なく動くんだけど、
すべて実行するとテーブルが無いとか言われることがある。

381:nobodyさん
08/03/27 23:06:17
>>370
adobe社のイラレだと思うけど。

>>375

わかる。人をバカにしてばっかだよな。あおってるやつ。
見てて気分悪い。

>>376 >>377
リファレンス見てわかるならそのURL教えてあげようよ。
しかも、聞いてる 374 はある程度知識あると思うよ。
もうちょっと人を思いやる気持ちを持とうよ。

382:nobodyさん
08/03/27 23:10:00
>>372
まず、おまえがシネ

383:nobodyさん
08/03/27 23:23:59
>>379
質問の内容があまりにも素人すぎ
CakePHPばかにしてんのか？

384:nobodyさん
08/03/27 23:25:34
誰も馬鹿にしてないから答えろよｗ

385:nobodyさん
08/03/28 00:13:02
人をバカにすることで自分が上に立ったような感覚を味わいたいんだろうな
残念なやつが多い

>>379
その4テーブルはどんなリレーションなの？
で、今はどんなアソシエーションを記述してんの？
もしかしたらDB設計が悪いという可能性もある。

386:nobodyさん
08/03/28 00:51:53
>>385
各フレームワークの評価目的でプロトタイプを作っていますので
特定のテーブルの再設計で問題を解決するアプローチでは応用範囲が非常に限られてしまいます
申し訳ありませんがCakePHP側での解決を求めています

例えばごく単純にモデルが
A→B→C→D
とbelongsToで数珠繋ぎにアソシエーションが設定されている場合
AのリストにB～Dのデータを動的に付加して取得したいとすると
どのような指定をすればよいのでしょうか

SQLならJOINをただ書き連ねていけばいいのですが

387:nobodyさん
08/03/28 01:28:45
>>386
CakePHPさわってどれくらい？
あまりにも初心者的な質問やめてくれる

388:nobodyさん
08/03/28 01:30:56
スレ分けて欲しいな。ＣａｋｅＰＨＰ初心者スレ作ってよ

389:nobodyさん
08/03/28 01:42:40
>>386
初心者が他人の力借りて簡単にCakePHP評価しようなんて
CakePHPなめすぎだろ？
自分で死ぬ思いでググれボケ

390:nobodyさん
08/03/28 02:37:39
>>386
できそうにない。

URLﾘﾝｸ(trac.cakephp.org)
上で同じようなこと言ってたけど対応なしにcloseされた模様。
URLﾘﾝｸ(trac.cakephp.org)
上も同様のことを言ってる。3週間ほど前。

>>377 >>383 >>387 >>388 >>389
俺もこれの具体的な解決方法を知りたいです。どうか教えてください。

391:nobodyさん
08/03/28 02:57:36
>>390
CakePHPの知識全くないくせに英語力を自慢がしたいの？

392:nobodyさん
08/03/28 03:06:49
>>390
>>371
ここにいる馬鹿どもが、みんな英語わかると思ってんのか？ｗ
さりげなくバカにしてるだろ

393:nobodyさん
08/03/28 03:20:48
>>390
今調べて出来そうにないって。こういうケースはじめてなの？
経験浅すぎじゃね。１つのサイトをCakePHPで完成させたことないやろ

394:nobodyさん
08/03/28 03:22:38
>>391
いや、これに関しての日本語の情報がなかなか見つからなかったから英語の記事を探さざるを得なかっただけ。
で、CakePHPの知識がある人はこれをどうやって解決してるんでしょうか？

395:nobodyさん
08/03/28 03:31:35
>>390
どうして、できそうにないか具体的に日本語で説明しろ。わかったな命令だ

396:nobodyさん
08/03/28 03:56:27
このスレ、なんか冗談だと思えるくらい殺伐としてんな w

397:nobodyさん
08/03/28 06:59:33
>>396
何でだかアンチが混じっている。
で、cakePHPは重いとか、質問者を叩いたり。
無視推奨。

つか、アンチしてる人、cakePHPを無視すればいいのにね。

398:nobodyさん
08/03/28 08:46:16
英語のサイト貼りつけて叩かれるのは初めて見たw
日本のサイトで分からなければ、海外サイトくらい見るだろ。

分からなければWeb翻訳すればいいんだしな

399:nobodyさん
08/03/28 09:18:10
粘着気質で知性もないとか救いようがないな。
トリップの付け方も知らないらしいし、ほんと終わってんな。ｗ

400:nobodyさん
08/03/28 09:20:55
なんだこの流れ
とてつもないバカが何人かいるな

401:nobodyさん
08/03/28 09:29:46
>>390
まさしくそのtickets通りです
CakePHPは隣り合ったアソシエーション間ではJOINを繋いでSQLワンコールに最適化してくれますが
それ以上のテーブルをまたいだ関係を持とうとすると途端にクエリ量が増えてしまいます

個人的にrecursiveでアソシエーションの深度を指定する考え方は
好感が持てるのですが、負荷の高さを考えると使用をためらわざるを得ません

サブクエリをインテリジェントに挿入しろとは言いませんが
今回の様な使用頻度の高いと思われる(かつ、割と実装の想像しやすい)処理ならば
既に解決された方がいらっしゃるのかと質問に至りました

--
先ほどContainableBehaviorを試してみましたがクエリ量は変わりませんでした
やはりコアに直接手を加えないといけないようですね(´・ω・`)

402:nobodyさん
08/03/28 10:01:46
A→Bのクエリ発行したときに
モデルにB→Aのアソシエーションも記述してあると
B→Aのクエリも発行される
だから
A→B→C→D のようなのをそのままやっちゃうと
えらいことになる

だから、いらいないアソシエーションはunbindModelでぶった切る

あと、1.2だと発行クエリが1.1より最適化されている
（つまり、少なくなってるってこと）

403:nobodyさん
08/03/28 10:11:39
>>397
明らかにアンチじゃない奴のほうがたち悪いぞ。質問者叩いてるのもそう。

>>402
>>401の問題解決にはならないんじゃない。B->Aのアソシエーションがなくても起こるから。

>>401
DBにview作れば早いと思うよ。

404:nobodyさん
08/03/28 10:15:32
質問があまりにもバカすぎて・・・
レベル低いよな。
ここでアフォみたいな質問してるやつは
CakePHPでサイト構築したことあるのかと聞きたいよ

405:nobodyさん
08/03/28 10:19:27
あまりにもバカみたいな質問にバカみたいな回答が多すぎ
もっと常識レベルでの会話して欲しいな
駄文ばっかで何の役にも立たないよ

406:nobodyさん
08/03/28 10:27:40
>>405
それそのまま>>405に当てはまるのわかる？

407:nobodyさん
08/03/28 10:30:15
もっと常識的な質問たのむ

408:nobodyさん
08/03/28 10:36:03
かわいそうに

409:nobodyさん
08/03/28 10:57:56
バッチ処理で長くかかる処理をやるのなら話は別だけど
ウェブアプリなんて画面に表示する少ないデータを
表示するだけなんだからJOINしなくてもいいと思うんだけどね。
どうせ複雑なJOINならJOINするのにも負荷かかるわけだし。

ま、パフォーマンスと開発効率のトレードオフ。
どうしても必要なら、モデルに専用の検索メソッドでも作って
自分でクエリー書けばいいんじゃない？

410:nobodyさん
08/03/28 11:00:25
もっと常識的な質問たのむ

411:nobodyさん
08/03/28 11:03:37 q/btZ3WH
アンチがしつこくネガティブキャンペーンするのも
CakePHPが人気になって普及してきた証拠かなぁｗ

アンチじゃない人はIDだすようにするか？
そうすればID出していない人はアンチってわかるし。
出したら出したで削除できるしｗ

412:nobodyさん
08/03/28 11:10:07
アンチを勘違いしてると思うが
いい質問には、マナーをもって接するが
ろくでもないレスばっかりだからな

413:nobodyさん
08/03/28 11:13:12
>>411
自治厨乙。
だいたいにして、IDなんていつでも変えれるんだから意味ないじゃん。

414:nobodyさん
08/03/28 11:14:01
ろくでもないレスは無視するかマナーをもって
訂正を促すのが良い返答の仕方だよ。

415:nobodyさん
08/03/28 11:14:44 q/btZ3WH
>>413
やってみなきゃわからないじゃんｗ

416:nobodyさん
08/03/28 11:17:51
>>415
どんだけ必死なんだよｗ

417:nobodyさん
08/03/28 11:57:59 anJTbKap
>>409
もちろん速度を重視しなくてはならない場面ならば専用メソッド内でSQLを書きます
しかし、上記の様にシンプルなアソシエーションすら動作が怪しいとなると
フレームワーク自体に手を出して最適化させた方がコスト的にベターかなと思います

>>403
複雑なアソシエーションのパターンが出来上がってる時はView使った方がいいですね
今ふと考え付いたのですが、結合済みの仮想テーブルを作って、それを元に
CakePHP側のモデルを構築するアプローチは面白いかもしれません

#仮想テーブルへの更新作業はDB依存のため怪しい臭いはしますが

418:nobodyさん
08/03/28 12:20:53
>>417
負荷を考えるならフレームワークやめろ
CakePHPなんてのは、どうでもいいクライアントに高速納品するための道具てことに気づけよバカ

419:nobodyさん
08/03/28 12:26:48
>>417
今頃フレームワークの評価とか手を出すとか、どんだけ遅れてんだよ
この業界は進歩が早いの知ってる？

420:nobodyさん
08/03/28 12:43:39
>>417
> 結合済みの仮想テーブルを作って、それを元にCakePHP側のモデルを構築する
view作ればって言ったのはそういうこと。
面白いかどうかはおいといて、現状の打開策としてはアリかなと思うわけです。

> 仮想テーブルへの更新作業はDB依存のため怪しい臭いはしますが
このDB依存は仕方ないと割り切ればいいんじゃないかな。割り切れるところだと思うし。

421:nobodyさん
08/03/28 12:49:51
>>417
やる前にあれこれ聞かずにやってみろよ
こんなとこで解決できれば苦労しねーよクソが

422:nobodyさん
08/03/28 12:53:20
評価なんてソース解析して自分で実際にサイト構築しないとわからねーよ
やってくうちに想像しない難点が沢山でてくるよ

423:nobodyさん
08/03/28 13:01:42
>>417
速度重視とか柔軟性考えるならＣＩにしろや

424:nobodyさん
08/03/28 13:04:47
CakePHPを最適化させにくいフレームワーク
最適化したいならＣＩスレにいって、このスレからでていけや

425:nobodyさん
08/03/28 13:28:19
>>420

426:nobodyさん
08/03/28 13:34:05
っていうかJOINにならないというのは
どのフレームワークでも同じこと。
CIでもSymfonyでもRubyOnRailsでも同じだよ。

特にCIは最悪だね。いろんな意味で。
ここではすれ違いだから言わないけど。

427:nobodyさん
08/03/28 13:40:13
>>426
どのフレームワークも同じなら軽量でサクサク動作するＣＩの方がマシ

428:nobodyさん
08/03/28 13:44:02
>>417
> しかし、上記の様にシンプルなアソシエーションすら動作が怪しいとなると

シンプルではないよ。

CakePHPでもその他でもそうだけどO/Rマッピングというのは
従来の表形式の使いづらいリレーショナルデータベースを
高レベルに扱いやすく使えるようにするもの。

リレーショナルデータベースを基本に設計されたものではなく
より理想的なオブジェクト指向風なデータ構造をもとに設計されたもの。
だからいろんな取り出し方ができる出来る柔軟性がある。

たとえば、behaviorでデータ挿入・取り出し時に色んな処理をかませられる。

そういう柔軟性を持たせながらシンプルなSQLに置き換えるのは容易ではない。
不可能な場合すらある。

なんでもかんでもパフォーマンスを気にして無駄なものを作るのは
初心者のやること。一日働いて3万円人件費をかけるのなら、
その3万円でスペックをあげたほうが総合的に考えてメリットが
高いという時代だから、今は。

429:nobodyさん
08/03/28 13:50:03
CIはデータベースを使わない。使う頻度が少ない場合にはいいけど、
データベースを使う場合、貧弱だよな。

あれならSQL直書きした方がいいってほどメソッドがアホらしいしｗ
なによりビヘイビアが無いのが一番痛い。

430:nobodyさん
08/03/28 13:50:47
>>428
なんでもかんでもパフォーマンスを気にして無駄なものを作るのは
初心者のやること

サイトリニューアルなど
既存ユーザーが多数いる自社製品ならパフォーマンスを意識する

431:nobodyさん
08/03/28 13:52:21
> 既存ユーザーが多数いる自社製品ならパフォーマンスを意識する
マシンスペックを上げろ

432:nobodyさん
08/03/28 13:54:32
>>429
複雑なアソシエーションはＳＱＬ直書きになるんならＣＩが理にかなってる

433:nobodyさん
08/03/28 13:55:17
複雑なものじゃなくてシンプルにしようと考えような。

434:nobodyさん
08/03/28 13:55:42
>>426
symfony(というかpropel)はJOINになる

435:nobodyさん
08/03/28 13:56:08
>>431
ユーザーが増えるたびに、どんだけマシンが必要になるんだよ

436:nobodyさん
08/03/28 13:56:12
JOIN使わないで一回一回よんでも
パフォーマンスはたいして変わんないんだけどなｗ

437:nobodyさん
08/03/28 13:57:04
>>435
ユーザーが増えると重くなるのはどれでも一緒ですが？

働いていない人は、人件費というコストを計算に入れないからなぁｗ
まあ、がんばれやｗ

438:nobodyさん
08/03/28 13:57:54
>>436
変わるよ　あほか

439:nobodyさん
08/03/28 13:57:57
ＳＱＬ直書きになる機会が多いならＣＩがいい

440:nobodyさん
08/03/28 13:58:21
O/Rというのはリレーショナルデータベースからの
脱却に意味があるというのに、今時SQLなんて低レベルなことやるかよｗ

441:nobodyさん
08/03/28 13:58:54
>>437
ずっと開発してるわけじゃねーからｗ
人件費とか１回ぽっきりやん

442:nobodyさん
08/03/28 14:00:15
複雑なＳＱＬならＯ/Rマッピング使えないじゃん
今のＣａｋｅＰＨＰなら
だったらＣＩでＳＱＬ直書きが最高よ

443:nobodyさん
08/03/28 14:03:25
>>437
重くなりかたが異なってくるんですが？

1回で済む処理を2回のクエリで行ってるとアクセス数が増えたときにクエリ発行数が大きく変わることがわかんない？
ほんとにプログラマなのか？まぁ、がんばれや

444:nobodyさん
08/03/28 14:05:37
ぷｗ頭固いな。mixiの話とかしらんのかいな

mixiでは”高負荷に耐えるためにJOINを使っていない”んだよ。

URLﾘﾝｸ(www.google.co.jp)

445:nobodyさん
08/03/28 14:07:29
>>442
使えていますが？ JOINが使われないってだけでしょうが。

パフォーマンスに問題が無い場所で、
複雑なSQLを、SQLを書かずに作れる（買いても作れる）CakePHPと、
SQLを書くのと同等の手間をかけなければならないCIでは
どちらが優れているかは言うまでも無く、CakePHPですね。

446:nobodyさん
08/03/28 14:08:18
>>441
マシンスペックを上げるのも一回ぽっきりですが？

447:nobodyさん
08/03/28 14:09:13
ビヘイビアがない時点でCIは糞ｗ

448:nobodyさん
08/03/28 14:11:24
>>445
複雑なSQLを、SQLを書かずに作れる（買いても作れる）CakePHP

group byとかどうやんの？

449:nobodyさん
08/03/28 14:12:45
>>445
複雑なSQLを、SQLを書かずに作れる（買いても作れる）CakePHP

この発言無理がありすぎやろｗ

450:nobodyさん
08/03/28 14:13:42
>>444
あのさ、読解力なさすぎ。
「高負荷に耐えるためにJOINを使っていない」とは書いてない。

451:nobodyさん
08/03/28 14:14:14
結局アンチはいつものCI厨だったなｗ

452:nobodyさん
08/03/28 14:15:24
>>450
ではJOINを使わない理由になんて書いていますか？言ってみてください。

453:nobodyさん
08/03/28 14:17:30
>>452
スケールするためにデータベースを分割し、JOINが使用できなくなったから。

454:nobodyさん
08/03/28 14:20:13
スケールとはパフォーマンスをあげるということです。

455:nobodyさん
08/03/28 14:21:44
うん。だから？

456:nobodyさん
08/03/28 14:22:38
>>455
おまえの負けてことだよ

457:nobodyさん
08/03/28 14:24:15
>>456
あからさまにバカだな。論理的に考えられないんだな。

458:nobodyさん
08/03/28 14:24:38
>>447
1.1使ってる人は真性なる糞ですね

459:nobodyさん
08/03/28 14:25:14
高負荷に耐えられるパフォーマンスを作り出す為に、
データベースを分割してJOINが使用できなくなった。

負荷を考えるのなら、JOINなんかするより、
マシンに投資してデータベースを分割（当然マシンも増えているはず）して
アプリケーションで行ったほうがいいということです。

460:nobodyさん
08/03/28 14:28:55
>>457
さっきまでパフォーマンスの話してたやろうが
論理的な会話してないのお前だろｗ

461:nobodyさん
08/03/28 14:31:33
結局ＣＩが最強てことじゃんか

462:nobodyさん
08/03/28 14:37:17
CIはフレームワークを使っているとは思えないほど開発工数がかかる。

データベース部分は、SQLの単語（selectやfromやwhere）を
それぞれメソッドに置き換えて実行しないといけない。
なんとビックリｗ

だから糞。

463:nobodyさん
08/03/28 14:38:23
わろたｗ

$this->db->select('title')->from('mytable')->where('id', $id)->limit(10, 20);

$query = $this->db->get();

464:nobodyさん
08/03/28 14:38:41
>>459
ただ、「マシンに投資してデータベースを分割（当然マシンも増えているはず）して」が始めからできるわけじゃないんだよね。
だからSQL発行数も含め、パフォーマンスには常に気を遣うわけで。
mixiが今はソフトウェア側でパフォーマンスを気にしてないかっていったらそんなことはないし。

>>460
パフォーマンスの話してるよ。何言ってんの？
もう面倒だからお前いいよ。

465:nobodyさん
08/03/28 14:40:13
だからパフォーマンスを重視するところだけ
最適化して、あとは楽で速いコーディングをすればいいじゃんか。

パフォーマンスの基礎だよ？

466:nobodyさん
08/03/28 14:41:27
>>463
これいいね。わかりやすい構文だ
CakePHPの
find(null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,)
これに比べれば天と地に差

467:nobodyさん
08/03/28 14:42:45
>>466
引数の数を勝手に増やすなｗ

最後の引数の意味言ってみろよ。
いえなければ赤っ恥だなｗ

468:nobodyさん
08/03/28 14:42:48
>>464
おまえ誰だよ？トリップでも番号でもいいから付けろよｗ

469:nobodyさん
08/03/28 14:44:26
>>463はPHP4だと
$this->db->select('title');
$this->db->from('mytable');
$this->db->where('id', $id)
$this->db->limit(10, 20);
こうなります。

470:nobodyさん
08/03/28 14:45:17
>>464
名無しで必死にレスしてるようだが
名前に番号でもつけてくれないと
今までどんな発言してんかわかんないんだがｗ

471:nobodyさん
08/03/28 14:46:08
>>468
どうせトリップつけさせて削除しようって魂胆だろ。
そんな手に引っかかるか。ばーかｗ

472:nobodyさん
08/03/28 14:46:42
>>469
わかりやすくていいね、さすがＣＩ
ヌルヌルフレームワークとは大違い

473:sage
08/03/28 14:50:37 JUQ1v1x2
$this->flash で出てくるはずのページがIE6だと表示されん。ソースは吐かれてる。
ってことはUTF関係か。

474:nobodyさん
08/03/28 14:50:44
アンチレス繰り返してたら、えらい盛り上がってきた

475:425
08/03/28 14:54:55
すみません、途中投稿しました

>>420
その通りですね。同一アプリケーション内でDBをスイッチする事はありえないので
リスクとしては小さいため十分検討できます(一応、PostgreSQL使ってる方は注意です)

>>424
CodeIgniterもとてもいいフレームワークだと思います
ぜひその情熱で当該スレッドを活性化させて盛り上げて欲しいですね

>>428
確かにアソシエーションの自動判別が面倒(無理)という事情は分かります
面倒なSQLを叩かずオブジェクティブにデータセットを取得できる機能が
すでに実装されていているのですからそれを使うに越した事はありません
この辺りの実装はアプリケーション全体のパフォーマンスに影響するため
サーバ増設前の改良を十分に検討できる部分だと思います

476:nobodyさん
08/03/28 14:54:59
実はアンチを煽って盛り上げさせているというのはナイショだｗ
見ろ他フレームワーク（特にCI）の静けさを！

477:nobodyさん
08/03/28 14:56:44
>>469みたいなコードを書くぐらいなら
SQLをそのまま書いたほうがいいな。

478:nobodyさん
08/03/28 15:06:18
>>428
すみません
>>475の説明はちょっと意味不明ですね、スルー推奨です

479:nobodyさん
08/03/28 15:45:01
Ｃａｋｅは糞

480:nobodyさん
08/03/28 15:54:32
aki(ryが本出してるから糞

481:nobodyさん
08/03/29 07:40:57
あの本は確かに糞だったな

482:nobodyさん
08/03/29 09:07:16
あれは本当に酷かった

483:nobodyさん
08/03/29 15:28:58
文句だけは達者だな

484:nobodyさん
08/03/29 15:56:30
達者？

485:nobodyさん
08/03/29 16:10:19
このスレはいつも無駄に盛り上がるよな

486:nobodyさん
08/03/29 16:54:04
>>484
ゆとり乙

487:nobodyさん
08/03/29 17:43:56
>>486
ゆとり乙

488:nobodyさん
08/03/29 20:03:50
>>486
ゆとり乙

489:nobodyさん
08/03/29 22:04:16 t2qvxoud
CakePHPっていいフレームワークだよな

490:nobodyさん
08/03/29 22:08:25
ソース汚いけどな

491:nobodyさん
08/03/29 22:15:25
最高のフレームワークだね
完璧すぎる

492:nobodyさん
08/03/29 22:29:55
おまいらマインドマップ使ってる？

493:nobodyさん
08/03/29 22:57:31
30才過ぎるとマインドマップ使わないと
トイレ行った後とか今まで何考えてたかさえ忘れる

494:nobodyさん
08/03/29 23:43:43 VJRoSuRr
なんでマインドマップの話になったか分からないけど、自宅と会社のＰＣに
ＦｒｅｅＭｉｎｄインストール済み。

自宅ではCakePHPのシステム設計に使ってる。
ひとつずつやる事片付けて、終わったブランチに「レ」のアイコン付けるのが
楽しい。

495:nobodyさん
08/03/30 02:14:14
ＵＭＬはルール化した図解表現
マインドマップは自由な図解表現

496:nobodyさん
08/03/30 02:16:24
マインドマップで設計し形になったものをＵＭＬ化する

497:nobodyさん
08/03/30 02:17:48 xhO/sY7i
んで、UMLで書いた仕様書を投げ捨ててウンコする

498:nobodyさん
08/03/30 02:19:35
CakePHP使ってればUMLもマインドマップも必要ない

499:nobodyさん
08/03/30 02:26:47
作業途中に仕様的にやばい匂いがしたらマインドマップ使ってる

500:nobodyさん
08/03/30 02:31:49
問題を解決しやすい方法として
思ったことを、どんどん言葉として書き出す
わかってるからと頭の中でしまいこむと、全体的な解決図を結び付きにくくする

501:nobodyさん
08/03/30 02:45:33
難しい状況を言語化する能力がコミュニケーション能力での重要ポイントだと思う。
もっと言語化するクセつければ、コミュニケーション能力向上になるんじゃないかな

502:nobodyさん
08/03/30 17:27:12
render呼んだ後
すぐexit();
してる？

503:nobodyさん
08/03/30 20:27:27 3z+xm+ln
>>473
遅レスだが、ソースの頭にBOMを付けたら表示されるようになた。
が、viewのファイルは8Nで保存しておかないと、たまに悪さをするようだ。

504:nobodyさん
08/03/30 22:06:44
>>502
もっと常識的な質問たのむ

505:nobodyさん
08/03/31 10:30:36
>>502
してないよ

506:nobodyさん
08/03/31 10:59:21
>>505
コンポーネントでrenderを呼んだときは
exitしないとデフォルトのrenderが最後に読み込まれるよ

507:nobodyさん
08/03/31 11:00:31
cakePHPのテスト環境だけど
SeleniumとSimpleTestの組み合わせが最強？

508:nobodyさん
08/04/01 01:26:52 j0Vrw1hD
>>507
そっちのテストなら、ｾﾚﾆｳﾑだろうと手作業だろうとなんだって良くね？

ユニットテストをするのなら1.2から正式対応したSimpleTestって言うだろうけど。

ていうか、テスト駆動開発って面倒ですよね、時間がかかるけど出来上がり安定するのは確かだけど。

509:nobodyさん
08/04/01 01:34:29
正確にはテスト駆動じゃないけど、
ある程度の規模になったら、ユニットテストをやらないなんて
考えられないよ。

修正があるたびに同じテストなんてやってられない。
それこそ時間がかかる。

510:nobodyさん
08/04/01 02:09:46
Selenium IDE これいいね。これだけでも同じテストする必要がないし
なんといってもテストが楽

511:nobodyさん
08/04/01 12:33:08
Yahooが占いコンテンツ制作にCakePHPを採用

512:nobodyさん
08/04/01 20:20:10
なにこの寂びれぶり

513:nobodyさん
08/04/02 00:32:30 Ldo05SB7
んじゃ、おれがこのスレを潤わせてやるぜ
ビヘイビアって使ってる？

514:nobodyさん
08/04/02 00:38:10
>>512
荒らしが去ったので落ち着いただけ。

CakePHPを使って、ようやくサイトを公開できた。
思ったより使いやすいね、CakePHP。

515:nobodyさん
08/04/02 03:09:53
コンポーネント、ビヘイビア、ヘルパーの中では
ビヘイビアを一番使うな。

よくよく考えると、ソフトウェアの中心はモデル。
その中心の共通処理なんだからよく使うのは当たり前か。

516:nobodyさん
08/04/02 11:07:25
>>515
ソフトウェアの中心はコントローラー
なぜならコントローラーはモデルとビューにも指令を出すが
モデルは、たいていコントローラを介してのやりとりになるから

そういう考えで行けば、よく使うのはコンポーネントじゃないとおかしい

517:nobodyさん
08/04/02 11:18:11 Ldo05SB7
>>516
アフォがあらわれた

518:nobodyさん
08/04/02 11:57:50 KzinrGTW
findCount()で count(distinct hoge) を指定したいのですが
それは、findAll() でやるべきなのでしょうか？

519:nobodyさん
08/04/02 12:05:53
うん。アフォだ。ワロタｗ

コントローラなんて所詮インターフェースに過ぎんよ。
実際の処理じゃなくて、ブラウザから引数を受け取って
それを少々加工してモデルに渡す。
またモデルから受け取ったデータを少々加工してビューに渡す。

流れとしてはこんな感じだね。

「ブラウザ」→「コントローラ（加工）」→「モデル（実際の処理）」→「コントローラ（加工）」→「ビュー（HTML出力）」

っていうか、このように作らないとテストがしづらいったらありゃしない。

SeleniumやCakeWebTestCaseがあるとはいえ、
コントローラを操作してのテストでは範囲が大きすぎる。
もっと小さな範囲でテストできるようにしないといけない。

一番重要な処理を最小限の大きさ（なるべく他に依存しない）で
テストすること考えれば、自然とこうなるはず。

520:nobodyさん
08/04/02 15:46:57
ガソリン安いな～
これほど自民党の一党独裁の問題点が分かりやすい現象は無いなw

521:nobodyさん
08/04/02 16:07:32
>>519
そうなんだ。だから本にもモデルのテストの方法しか書いてなかったんだ。
モデルよりコントローラーをテストしたいんだけど・・・ってずっと思ってた。

ということは、僕のプログラムの組み方がよくないんでしょうか。

522:516
08/04/02 16:33:04 Ldo05SB7
>>515,>>121
さきほどはアフォと一言で片付けてしまって申し訳ない、2ch流の愛情表現だと思ってくれ

で、>>519のいうとおりアプリケーションの中心となるビジネスロジックについてはコントローラなどでは
なくモデル内で実装するべき。一番大切なテストはビジネスロジックであるわけだし、モデルに集約して
（かつコントローラとのｲﾝﾀﾌｪｰｽも疎結合にして）コアロジックを実装することでコアロジックを別システムに
再利用しやすくなるというメリットも受けられる。

なので、コントローラはある意味、テストをしなくても問題ないくらい「薄い」実装にするべきだし、コントローラ
内で繰り返しよく使う処理についてはコンポーネント化してあげたほうが、ユニットテストで品質を保証できるので
良いかと。

こんな感じで考えていますが、どうでしょう？

523:nobodyさん
08/04/02 16:44:10
>>519
Seleniumこれだけあれば、全く十分なんだが
これ以外でテストしようとすればコストかかるだけやろ
どんくさい作業してんな、赤字やろ？

524:nobodyさん
08/04/02 16:50:49
>>522
だから何ってかんじだが、それがどうしたんだよ
リファレンスに書いてあるようなこと、なんで必死に訴えてるのｗｗｗ

525:nobodyさん
08/04/02 16:52:59
自演厨きたー。うぜえええ

526:nobodyさん
08/04/02 16:56:38
Seleniumなんかでテストしたら時間（＝コスト）がかかるよ。
ブラウザを起動する為、そもそも動作が遅いってのもあるが、

Seleniumだといくつものモジュールが組み合わさった状態で
テストするしかないから、どこのバグがあるのか見つけにくい。

またデータの初期化などが出来ない。
途中で内部のデータを調べることも出来ない。

CakePHPにはSimpleTestでブラウザをエミュレートした状態の
テストもできるので基本はそれを使ったほうが良い。

Seleniumを使うとしたら、SimpleTestではできない
JavaScriptが絡んだ処理のテストぐらいだな。

527:nobodyさん
08/04/02 16:58:43
リファレンスに書いてあるようなことなのだから、
間違いではないということだなｗ

528:nobodyさん
08/04/02 17:01:36
>>522
アプリケーションの中心となるビジネスロジックて何？
どんなロジック？

一番大切なテストてどんなテスト？

>>モデルに集約して
（かつコントローラとのｲﾝﾀﾌｪｰｽも疎結合にして）コアロジックを実装

プラグインと違うの？

>>なので、コントローラはある意味、テストをしなくても問題ないくらい「薄い」実装にするべき

モデルとビューに命令出すのに薄い実装なんて物理的に無理
モデルはカラッポでＯＫ

529:nobodyさん
08/04/02 17:04:44
>>526
ブラウザ上でテストするだけなのにモジュールとか関係ないしｗｗｗ
JavaScriptテストやるなら加工しないと出来ないだろｗｗｗ

530:nobodyさん
08/04/02 17:05:56
>>526
Selenium使ったことないやろ？正直にいえ

531:nobodyさん
08/04/02 17:08:00
SimpleTestの方が時間かかるよ

532:nobodyさん
08/04/02 17:08:48
内部のデータを調べるようなテスト時間かかるに決まってるやろ

533:nobodyさん
08/04/02 17:09:00
また、例の嵐だな。

534:nobodyさん
08/04/02 17:09:39
とりあえず言っておくけど、CIは糞だから、
糞スレでやってねｗ

535:nobodyさん
08/04/02 17:13:49
>>532
たしかに！

536:nobodyさん
08/04/02 17:16:18
>>522
日本語でおｋ

537:nobodyさん
08/04/02 17:18:56
なんか、CI普及の為（？）にわざとアフォなことを言っている気がする。
いや、まて、わざと悪い例を出しているのか？

まあ、訂正している俺は考えをまとめられていいけどな。
（そして訂正している文を見て学習する人もいるだろう）

> モデルとビューに命令出すのに薄い実装なんて物理的に無理
> モデルはカラッポでＯＫ

コントローラが出す命令はすごく小さなものだよ。
モデルに対して、「データ取って来い！」「書き込め！」「削除しろ！」
そして、「複雑な一連の処理をしろ！」

前三つは、CakePHPの自動生成コードでも書いてあるから
簡単にわかると思うけど最後の「複雑な一連の処理をしろ！」を
モデルに書くべきってことをわかってない人が多いんだよね。
複雑な一連の処理をコントローラに書いてしまう。悪い例だ。

538:nobodyさん
08/04/02 17:27:44
>>537
テストのことを考えていってんの？俺はテストはブラウザでしかしないからｗ

539:nobodyさん
08/04/02 17:29:17
テスト中心に設計するならモデルに詰め込めるだけ詰め込めばいいんじゃね

540:nobodyさん
08/04/02 17:30:57
>>537
複雑な一連の処理を具体的に述べよ
はなしはそれからだ

541:nobodyさん
08/04/02 17:32:26
where が入るような条件文はモデルに書けばいいの？

542:nobodyさん
08/04/02 17:33:42
>>537
モデルにもっていっていいのは
どこからどこまで？

543:nobodyさん
08/04/02 17:45:27
>>537
いくら給料もらってんだよ
俺はＰＨＰプログラマで36万円

544:nobodyさん
08/04/02 17:53:38
　
　
　
モデル上で別のモデルのデータ取得できなくね？
　
　
　

545:nobodyさん
08/04/02 17:55:24
>>542
どこまでをモデルでやるかは結局設計しだいだけど、

>>541
ユーザーがフォームからの条件入力。URL形式での条件入力
、つまりコントローラのアクション関数の引数に入る場合。

その引数をもとにモデルを呼び出すわけだけど、
このときのモデルの関数は汎用的なfind関数でもいいし、
もっと簡単に扱いたければ、モデルに専用の関数を作って呼び出す。

汎用的なfind関数を使う場合には、array('key' => '= ' . $value)なんて
条件データに加工しないといけないよね？これがコントローラの処理。

モデルに専用の関数を作る場合、もっと簡単に使える関数にするね。
もちろんその場合、モデル内部でfind関数を使うことになるだろうし、
そのための条件の加工もモデルに書く。

ユーザーの入力した条件が、POSTでくる場合は、
$this->dataから条件を作り出す所までもうちょっと
コントローラでやる仕事が増えるだろう。

それでもコントローラの処理（モデルを呼び出すところまで）はこれだけ。
俺ならこのように作るよ。

あとモデルから戻ってきたデータを、ビューで使いやすいように
単純化するのもコントローラの仕事だね。

546:nobodyさん
08/04/02 17:59:00
>>544

> モデル上で別のモデルのデータ取得できなくね？

モデル上で別のモデルのデータを使用したいと思ったとき、
その二つのモデル間には関連性がある。

つまりアソシエーションを定義している。
アソシエーションを定義しているのなら、
モデル内で、別のモデルを呼び出すことが出来る。

Model1の中から、$this->Model2->findAll(); 感じで呼び出せる。

547:nobodyさん
08/04/02 18:01:31
>>545
モデルから戻ってきたデータを、ビューで使いやすいように単純化

数字にコンマ付けたりとか？

548:nobodyさん
08/04/02 18:02:43
>>546
そのやり方はCakePHPで推奨されてる方法なの？

549:nobodyさん
08/04/02 18:05:48
>>546
わざわざアソシエーションするの？
いつも結合されて重くなるじゃん

550:nobodyさん
08/04/02 18:06:46
>>547
それは見た目を変えるだけだからビューの仕事だろうね。

モデルから戻ってきたデータとは、汎用的なfind関数の場合、

$data => array(
　モデル名 => array(
　　フィールド名1 => 値1,
　　フィールド名2 => 値2,
　　フィールド名3 => 値3,
　)
)

こんな値が返ってくる。もちろん、これをそのまま
ビューに渡してもいいんだけど、これじゃあビューで使いにくい！
って言う場合加工する。

そんな場合あるのかって？余り無いだろう。
そう、だからコントローラの仕事は少ない。

モデルから取得した値をビューに渡す$this->set(・・・) は
コントローラの仕事ね。

次ページ