- 1 名前：nobodyさん [2008/03/14(金) 15:16:00 ID:HF9x5ODX]
- www.cakephp.org/
10分で作るCakePHPアプリ for Windows
p4life.jp/cake/
マニュアル日本語化
www.cakephp.jp/doc/
日本語フォーラム
cakephp.jp/modules/newbb/
あとこのへんとか（初心者向けTIPS）
www.avatarfinancial.com/pages/cake/
CakePHP入門リンク集
ttp://pub.studio15.jp/2007/11/13/cakephp-links/
【PHP】フレームワーク CakePHP 2ホール目
pc11.2ch.net/test/read.cgi/php/1194976228/
【PHP】フレームワーク CakePHP
pc11.2ch.net/test/read.cgi/php/1163850802/
- 401 名前：nobodyさん mailto:sage [2008/03/28(金) 09:29:46 ID:???]
- >>390
まさしくそのtickets通りです
CakePHPは隣り合ったアソシエーション間ではJOINを繋いでSQLワンコールに最適化してくれますが
それ以上のテーブルをまたいだ関係を持とうとすると途端にクエリ量が増えてしまいます
個人的にrecursiveでアソシエーションの深度を指定する考え方は
好感が持てるのですが、負荷の高さを考えると使用をためらわざるを得ません
サブクエリをインテリジェントに挿入しろとは言いませんが
今回の様な使用頻度の高いと思われる(かつ、割と実装の想像しやすい)処理ならば
既に解決された方がいらっしゃるのかと質問に至りました
--
先ほどContainableBehaviorを試してみましたがクエリ量は変わりませんでした
やはりコアに直接手を加えないといけないようですね(´・ω・`)
- 402 名前：nobodyさん mailto:sage [2008/03/28(金) 10:01:46 ID:???]
- A→Bのクエリ発行したときに
モデルにB→Aのアソシエーションも記述してあると
B→Aのクエリも発行される
だから
A→B→C→D のようなのをそのままやっちゃうと
えらいことになる
だから、いらいないアソシエーションはunbindModelでぶった切る
あと、1.2だと発行クエリが1.1より最適化されている
（つまり、少なくなってるってこと）
- 403 名前：nobodyさん mailto:sage [2008/03/28(金) 10:11:39 ID:???]
- >>397
明らかにアンチじゃない奴のほうがたち悪いぞ。質問者叩いてるのもそう。
>>402
>>401の問題解決にはならないんじゃない。B->Aのアソシエーションがなくても起こるから。
>>401
DBにview作れば早いと思うよ。
- 404 名前：nobodyさん mailto:sage [2008/03/28(金) 10:15:32 ID:???]
- 質問があまりにもバカすぎて・・・
レベル低いよな。
ここでアフォみたいな質問してるやつは
CakePHPでサイト構築したことあるのかと聞きたいよ
- 405 名前：nobodyさん mailto:sage [2008/03/28(金) 10:19:27 ID:???]
- あまりにもバカみたいな質問にバカみたいな回答が多すぎ
もっと常識レベルでの会話して欲しいな
駄文ばっかで何の役にも立たないよ
- 406 名前：nobodyさん mailto:sage [2008/03/28(金) 10:27:40 ID:???]
- >>405
それそのまま>>405に当てはまるのわかる？
- 407 名前：nobodyさん mailto:sage [2008/03/28(金) 10:30:15 ID:???]
- もっと常識的な質問たのむ
- 408 名前：nobodyさん mailto:sage [2008/03/28(金) 10:36:03 ID:???]
- かわいそうに
- 409 名前：nobodyさん mailto:sage [2008/03/28(金) 10:57:56 ID:???]
- バッチ処理で長くかかる処理をやるのなら話は別だけど
ウェブアプリなんて画面に表示する少ないデータを
表示するだけなんだからJOINしなくてもいいと思うんだけどね。
どうせ複雑なJOINならJOINするのにも負荷かかるわけだし。
ま、パフォーマンスと開発効率のトレードオフ。
どうしても必要なら、モデルに専用の検索メソッドでも作って
自分でクエリー書けばいいんじゃない？
- 410 名前：nobodyさん mailto:sage [2008/03/28(金) 11:00:25 ID:???]
- もっと常識的な質問たのむ
- 411 名前：nobodyさん [2008/03/28(金) 11:03:37 ID:q/btZ3WH]
- アンチがしつこくネガティブキャンペーンするのも
CakePHPが人気になって普及してきた証拠かなぁｗ
アンチじゃない人はIDだすようにするか？
そうすればID出していない人はアンチってわかるし。
出したら出したで削除できるしｗ
- 412 名前：nobodyさん mailto:sage [2008/03/28(金) 11:10:07 ID:???]
- アンチを勘違いしてると思うが
いい質問には、マナーをもって接するが
ろくでもないレスばっかりだからな
- 413 名前：nobodyさん mailto:sage [2008/03/28(金) 11:13:12 ID:???]
- >>411
自治厨乙。
だいたいにして、IDなんていつでも変えれるんだから意味ないじゃん。
- 414 名前：nobodyさん mailto:sage [2008/03/28(金) 11:14:01 ID:???]
- ろくでもないレスは無視するかマナーをもって
訂正を促すのが良い返答の仕方だよ。
- 415 名前：nobodyさん [2008/03/28(金) 11:14:44 ID:q/btZ3WH]
- >>413
やってみなきゃわからないじゃんｗ
- 416 名前：nobodyさん mailto:sage [2008/03/28(金) 11:17:51 ID:???]
- >>415
どんだけ必死なんだよｗ
- 417 名前：nobodyさん [2008/03/28(金) 11:57:59 ID:anJTbKap]
- >>409
もちろん速度を重視しなくてはならない場面ならば専用メソッド内でSQLを書きます
しかし、上記の様にシンプルなアソシエーションすら動作が怪しいとなると
フレームワーク自体に手を出して最適化させた方がコスト的にベターかなと思います
>>403
複雑なアソシエーションのパターンが出来上がってる時はView使った方がいいですね
今ふと考え付いたのですが、結合済みの仮想テーブルを作って、それを元に
CakePHP側のモデルを構築するアプローチは面白いかもしれません
#仮想テーブルへの更新作業はDB依存のため怪しい臭いはしますが
- 418 名前：nobodyさん mailto:sage [2008/03/28(金) 12:20:53 ID:???]
- >>417
負荷を考えるならフレームワークやめろ
CakePHPなんてのは、どうでもいいクライアントに高速納品するための道具てことに気づけよバカ
- 419 名前：nobodyさん mailto:sage [2008/03/28(金) 12:26:48 ID:???]
- >>417
今頃フレームワークの評価とか手を出すとか、どんだけ遅れてんだよ
この業界は進歩が早いの知ってる？
- 420 名前：nobodyさん mailto:sage [2008/03/28(金) 12:43:39 ID:???]
- >>417
> 結合済みの仮想テーブルを作って、それを元にCakePHP側のモデルを構築する
view作ればって言ったのはそういうこと。
面白いかどうかはおいといて、現状の打開策としてはアリかなと思うわけです。
> 仮想テーブルへの更新作業はDB依存のため怪しい臭いはしますが
このDB依存は仕方ないと割り切ればいいんじゃないかな。割り切れるところだと思うし。
- 421 名前：nobodyさん mailto:sage [2008/03/28(金) 12:49:51 ID:???]
- >>417
やる前にあれこれ聞かずにやってみろよ
こんなとこで解決できれば苦労しねーよクソが
- 422 名前：nobodyさん mailto:sage [2008/03/28(金) 12:53:20 ID:???]
- 評価なんてソース解析して自分で実際にサイト構築しないとわからねーよ
やってくうちに想像しない難点が沢山でてくるよ
- 423 名前：nobodyさん mailto:sage [2008/03/28(金) 13:01:42 ID:???]
- >>417
速度重視とか柔軟性考えるならＣＩにしろや
- 424 名前：nobodyさん mailto:sage [2008/03/28(金) 13:04:47 ID:???]
- CakePHPを最適化させにくいフレームワーク
最適化したいならＣＩスレにいって、このスレからでていけや
- 425 名前：nobodyさん mailto:sage [2008/03/28(金) 13:28:19 ID:???]
- >>420
- 426 名前：nobodyさん mailto:sage [2008/03/28(金) 13:34:05 ID:???]
- っていうかJOINにならないというのは
どのフレームワークでも同じこと。
CIでもSymfonyでもRubyOnRailsでも同じだよ。
特にCIは最悪だね。いろんな意味で。
ここではすれ違いだから言わないけど。
- 427 名前：nobodyさん mailto:sage [2008/03/28(金) 13:40:13 ID:???]
- >>426
どのフレームワークも同じなら軽量でサクサク動作するＣＩの方がマシ
- 428 名前：nobodyさん mailto:sage [2008/03/28(金) 13:44:02 ID:???]
- >>417
> しかし、上記の様にシンプルなアソシエーションすら動作が怪しいとなると
シンプルではないよ。
CakePHPでもその他でもそうだけどO/Rマッピングというのは
従来の表形式の使いづらいリレーショナルデータベースを
高レベルに扱いやすく使えるようにするもの。
リレーショナルデータベースを基本に設計されたものではなく
より理想的なオブジェクト指向風なデータ構造をもとに設計されたもの。
だからいろんな取り出し方ができる出来る柔軟性がある。
たとえば、behaviorでデータ挿入・取り出し時に色んな処理をかませられる。
そういう柔軟性を持たせながらシンプルなSQLに置き換えるのは容易ではない。
不可能な場合すらある。
なんでもかんでもパフォーマンスを気にして無駄なものを作るのは
初心者のやること。一日働いて3万円人件費をかけるのなら、
その3万円でスペックをあげたほうが総合的に考えてメリットが
高いという時代だから、今は。
- 429 名前：nobodyさん mailto:sage [2008/03/28(金) 13:50:03 ID:???]
- CIはデータベースを使わない。使う頻度が少ない場合にはいいけど、
データベースを使う場合、貧弱だよな。
あれならSQL直書きした方がいいってほどメソッドがアホらしいしｗ
なによりビヘイビアが無いのが一番痛い。
- 430 名前：nobodyさん mailto:sage [2008/03/28(金) 13:50:47 ID:???]
- >>428
なんでもかんでもパフォーマンスを気にして無駄なものを作るのは
初心者のやること
サイトリニューアルなど
既存ユーザーが多数いる自社製品ならパフォーマンスを意識する
- 431 名前：nobodyさん mailto:sage [2008/03/28(金) 13:52:21 ID:???]
- > 既存ユーザーが多数いる自社製品ならパフォーマンスを意識する
マシンスペックを上げろ
- 432 名前：nobodyさん mailto:sage [2008/03/28(金) 13:54:32 ID:???]
- >>429
複雑なアソシエーションはＳＱＬ直書きになるんならＣＩが理にかなってる
- 433 名前：nobodyさん mailto:sage [2008/03/28(金) 13:55:17 ID:???]
- 複雑なものじゃなくてシンプルにしようと考えような。
- 434 名前：nobodyさん mailto:sage [2008/03/28(金) 13:55:42 ID:???]
- >>426
symfony(というかpropel)はJOINになる
- 435 名前：nobodyさん mailto:sage [2008/03/28(金) 13:56:08 ID:???]
- >>431
ユーザーが増えるたびに、どんだけマシンが必要になるんだよ
- 436 名前：nobodyさん mailto:sage [2008/03/28(金) 13:56:12 ID:???]
- JOIN使わないで一回一回よんでも
パフォーマンスはたいして変わんないんだけどなｗ
- 437 名前：nobodyさん mailto:sage [2008/03/28(金) 13:57:04 ID:???]
- >>435
ユーザーが増えると重くなるのはどれでも一緒ですが？
働いていない人は、人件費というコストを計算に入れないからなぁｗ
まあ、がんばれやｗ
- 438 名前：nobodyさん mailto:sage [2008/03/28(金) 13:57:54 ID:???]
- >>436
変わるよ あほか
- 439 名前：nobodyさん mailto:sage [2008/03/28(金) 13:57:57 ID:???]
- ＳＱＬ直書きになる機会が多いならＣＩがいい
- 440 名前：nobodyさん mailto:sage [2008/03/28(金) 13:58:21 ID:???]
- O/Rというのはリレーショナルデータベースからの
脱却に意味があるというのに、今時SQLなんて低レベルなことやるかよｗ
- 441 名前：nobodyさん mailto:sage [2008/03/28(金) 13:58:54 ID:???]
- >>437
ずっと開発してるわけじゃねーからｗ
人件費とか１回ぽっきりやん
- 442 名前：nobodyさん mailto:sage [2008/03/28(金) 14:00:15 ID:???]
- 複雑なＳＱＬならＯ/Rマッピング使えないじゃん
今のＣａｋｅＰＨＰなら
だったらＣＩでＳＱＬ直書きが最高よ
- 443 名前：nobodyさん mailto:sage [2008/03/28(金) 14:03:25 ID:???]
- >>437
重くなりかたが異なってくるんですが？
1回で済む処理を2回のクエリで行ってるとアクセス数が増えたときにクエリ発行数が大きく変わることがわかんない？
ほんとにプログラマなのか？まぁ、がんばれや
- 444 名前：nobodyさん mailto:sage [2008/03/28(金) 14:05:37 ID:???]
- ぷｗ 頭固いな。mixiの話とかしらんのかいな
mixiでは”高負荷に耐えるためにJOINを使っていない”んだよ。
www.google.co.jp/search?hl=ja&rlz=1T4GGIH_jaJP221JP221&q=MIXI+MYSQL+JOIN+%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3&lr=
- 445 名前：nobodyさん mailto:sage [2008/03/28(金) 14:07:29 ID:???]
- >>442
使えていますが？ JOINが使われないってだけでしょうが。
パフォーマンスに問題が無い場所で、
複雑なSQLを、SQLを書かずに作れる（買いても作れる）CakePHPと、
SQLを書くのと同等の手間をかけなければならないCIでは
どちらが優れているかは言うまでも無く、CakePHPですね。
- 446 名前：nobodyさん mailto:sage [2008/03/28(金) 14:08:18 ID:???]
- >>441
マシンスペックを上げるのも一回ぽっきりですが？
- 447 名前：nobodyさん mailto:sage [2008/03/28(金) 14:09:13 ID:???]
- ビヘイビアがない時点でCIは糞ｗ
- 448 名前：nobodyさん mailto:sage [2008/03/28(金) 14:11:24 ID:???]
- >>445
複雑なSQLを、SQLを書かずに作れる（買いても作れる）CakePHP
group byとかどうやんの？
- 449 名前：nobodyさん mailto:sage [2008/03/28(金) 14:12:45 ID:???]
- >>445
複雑なSQLを、SQLを書かずに作れる（買いても作れる）CakePHP
この発言無理がありすぎやろｗ
- 450 名前：nobodyさん mailto:sage [2008/03/28(金) 14:13:42 ID:???]
- >>444
あのさ、読解力なさすぎ。
「高負荷に耐えるためにJOINを使っていない」とは書いてない。
- 451 名前：nobodyさん mailto:sage [2008/03/28(金) 14:14:14 ID:???]
- 結局アンチはいつものCI厨だったなｗ
- 452 名前：nobodyさん mailto:sage [2008/03/28(金) 14:15:24 ID:???]
- >>450
ではJOINを使わない理由になんて書いていますか？言ってみてください。
- 453 名前：nobodyさん mailto:sage [2008/03/28(金) 14:17:30 ID:???]
- >>452
スケールするためにデータベースを分割し、JOINが使用できなくなったから。
- 454 名前：nobodyさん mailto:sage [2008/03/28(金) 14:20:13 ID:???]
- スケールとはパフォーマンスをあげるということです。
- 455 名前：nobodyさん mailto:sage [2008/03/28(金) 14:21:44 ID:???]
- うん。だから？
- 456 名前：nobodyさん mailto:sage [2008/03/28(金) 14:22:38 ID:???]
- >>455
おまえの負けてことだよ
- 457 名前：nobodyさん mailto:sage [2008/03/28(金) 14:24:15 ID:???]
- >>456
あからさまにバカだな。論理的に考えられないんだな。
- 458 名前：nobodyさん mailto:sage [2008/03/28(金) 14:24:38 ID:???]
- >>447
1.1使ってる人は真性なる糞ですね
- 459 名前：nobodyさん mailto:sage [2008/03/28(金) 14:25:14 ID:???]
- 高負荷に耐えられるパフォーマンスを作り出す為に、
データベースを分割してJOINが使用できなくなった。
負荷を考えるのなら、JOINなんかするより、
マシンに投資してデータベースを分割（当然マシンも増えているはず）して
アプリケーションで行ったほうがいいということです。
- 460 名前：nobodyさん mailto:sage [2008/03/28(金) 14:28:55 ID:???]
- >>457
さっきまでパフォーマンスの話してたやろうが
論理的な会話してないのお前だろｗ
- 461 名前：nobodyさん mailto:sage [2008/03/28(金) 14:31:33 ID:???]
- 結局ＣＩが最強てことじゃんか
- 462 名前：nobodyさん mailto:sage [2008/03/28(金) 14:37:17 ID:???]
- CIはフレームワークを使っているとは思えないほど開発工数がかかる。
データベース部分は、SQLの単語（selectやfromやwhere）を
それぞれメソッドに置き換えて実行しないといけない。
なんとビックリｗ
だから糞。
- 463 名前：nobodyさん mailto:sage [2008/03/28(金) 14:38:23 ID:???]
- わろたｗ
$this->db->select('title')->from('mytable')->where('id', $id)->limit(10, 20);
$query = $this->db->get();
- 464 名前：nobodyさん mailto:sage [2008/03/28(金) 14:38:41 ID:???]
- >>459
ただ、「マシンに投資してデータベースを分割（当然マシンも増えているはず）して」が始めからできるわけじゃないんだよね。
だからSQL発行数も含め、パフォーマンスには常に気を遣うわけで。
mixiが今はソフトウェア側でパフォーマンスを気にしてないかっていったらそんなことはないし。
>>460
パフォーマンスの話してるよ。何言ってんの？
もう面倒だからお前いいよ。
- 465 名前：nobodyさん mailto:sage [2008/03/28(金) 14:40:13 ID:???]
- だからパフォーマンスを重視するところだけ
最適化して、あとは楽で速いコーディングをすればいいじゃんか。
パフォーマンスの基礎だよ？
- 466 名前：nobodyさん mailto:sage [2008/03/28(金) 14:41:27 ID:???]
- >>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さん mailto:sage [2008/03/28(金) 14:42:45 ID:???]
- >>466
引数の数を勝手に増やすなｗ
最後の引数の意味言ってみろよ。
いえなければ赤っ恥だなｗ
- 468 名前：nobodyさん mailto:sage [2008/03/28(金) 14:42:48 ID:???]
- >>464
おまえ誰だよ？トリップでも番号でもいいから付けろよｗ
- 469 名前：nobodyさん mailto:sage [2008/03/28(金) 14:44:26 ID:???]
- >>463はPHP4だと
$this->db->select('title');
$this->db->from('mytable');
$this->db->where('id', $id)
$this->db->limit(10, 20);
こうなります。
- 470 名前：nobodyさん mailto:sage [2008/03/28(金) 14:45:17 ID:???]
- >>464
名無しで必死にレスしてるようだが
名前に番号でもつけてくれないと
今までどんな発言してんかわかんないんだがｗ
- 471 名前：nobodyさん mailto:sage [2008/03/28(金) 14:46:08 ID:???]
- >>468
どうせトリップつけさせて削除しようって魂胆だろ。
そんな手に引っかかるか。ばーかｗ
- 472 名前：nobodyさん mailto:sage [2008/03/28(金) 14:46:42 ID:???]
- >>469
わかりやすくていいね、さすがＣＩ
ヌルヌルフレームワークとは大違い
- 473 名前：sage [2008/03/28(金) 14:50:37 ID:JUQ1v1x2]
- $this->flash で出てくるはずのページがIE6だと表示されん。ソースは吐かれてる。
ってことはUTF関係か。
- 474 名前：nobodyさん mailto:sage [2008/03/28(金) 14:50:44 ID:???]
- アンチレス繰り返してたら、えらい盛り上がってきた
- 475 名前：425 mailto:sage [2008/03/28(金) 14:54:55 ID:???]
- すみません、途中投稿しました
>>420
その通りですね。同一アプリケーション内でDBをスイッチする事はありえないので
リスクとしては小さいため十分検討できます(一応、PostgreSQL使ってる方は注意です)
>>424
CodeIgniterもとてもいいフレームワークだと思います
ぜひその情熱で当該スレッドを活性化させて盛り上げて欲しいですね
>>428
確かにアソシエーションの自動判別が面倒(無理)という事情は分かります
面倒なSQLを叩かずオブジェクティブにデータセットを取得できる機能が
すでに実装されていているのですからそれを使うに越した事はありません
この辺りの実装はアプリケーション全体のパフォーマンスに影響するため
サーバ増設前の改良を十分に検討できる部分だと思います
- 476 名前：nobodyさん mailto:sage [2008/03/28(金) 14:54:59 ID:???]
- 実はアンチを煽って盛り上げさせているというのはナイショだｗ
見ろ他フレームワーク（特にCI）の静けさを！
- 477 名前：nobodyさん mailto:sage [2008/03/28(金) 14:56:44 ID:???]
- >>469みたいなコードを書くぐらいなら
SQLをそのまま書いたほうがいいな。
- 478 名前：nobodyさん mailto:sage [2008/03/28(金) 15:06:18 ID:???]
- >>428
すみません
>>475の説明はちょっと意味不明ですね、スルー推奨です
- 479 名前：nobodyさん mailto:sage [2008/03/28(金) 15:45:01 ID:???]
- Ｃａｋｅは糞
- 480 名前：nobodyさん mailto:sage [2008/03/28(金) 15:54:32 ID:???]
- aki(ryが本出してるから糞
- 481 名前：nobodyさん mailto:sage [2008/03/29(土) 07:40:57 ID:???]
- あの本は確かに糞だったな
- 482 名前：nobodyさん mailto:sage [2008/03/29(土) 09:07:16 ID:???]
- あれは本当に酷かった
- 483 名前：nobodyさん mailto:sage [2008/03/29(土) 15:28:58 ID:???]
- 文句だけは達者だな
- 484 名前：nobodyさん mailto:sage [2008/03/29(土) 15:56:30 ID:???]
- 達者？
- 485 名前：nobodyさん mailto:sage [2008/03/29(土) 16:10:19 ID:???]
- このスレはいつも無駄に盛り上がるよな
- 486 名前：nobodyさん mailto:sage [2008/03/29(土) 16:54:04 ID:???]
- >>484
ゆとり乙
- 487 名前：nobodyさん mailto:sage [2008/03/29(土) 17:43:56 ID:???]
- >>486
ゆとり乙
- 488 名前：nobodyさん mailto:sage [2008/03/29(土) 20:03:50 ID:???]
- >>486
ゆとり乙
- 489 名前：nobodyさん [2008/03/29(土) 22:04:16 ID:t2qvxoud]
- CakePHPっていいフレームワークだよな
- 490 名前：nobodyさん mailto:sage [2008/03/29(土) 22:08:25 ID:???]
- ソース汚いけどな
- 491 名前：nobodyさん mailto:sage [2008/03/29(土) 22:15:25 ID:???]
- 最高のフレームワークだね
完璧すぎる
- 492 名前：nobodyさん mailto:sage [2008/03/29(土) 22:29:55 ID:???]
- おまいらマインドマップ使ってる？
- 493 名前：nobodyさん mailto:sage [2008/03/29(土) 22:57:31 ID:???]
- 30才過ぎるとマインドマップ使わないと
トイレ行った後とか今まで何考えてたかさえ忘れる
- 494 名前：nobodyさん [2008/03/29(土) 23:43:43 ID:VJRoSuRr]
- なんでマインドマップの話になったか分からないけど、自宅と会社のＰＣに
ＦｒｅｅＭｉｎｄインストール済み。
自宅ではCakePHPのシステム設計に使ってる。
ひとつずつやる事片付けて、終わったブランチに「レ」のアイコン付けるのが
楽しい。
- 495 名前：nobodyさん mailto:sage [2008/03/30(日) 02:14:14 ID:???]
- ＵＭＬはルール化した図解表現
マインドマップは自由な図解表現
- 496 名前：nobodyさん mailto:sage [2008/03/30(日) 02:16:24 ID:???]
- マインドマップで設計し形になったものをＵＭＬ化する
- 497 名前：nobodyさん [2008/03/30(日) 02:17:48 ID:xhO/sY7i]
- んで、UMLで書いた仕様書を投げ捨ててウンコする
- 498 名前：nobodyさん mailto:sage [2008/03/30(日) 02:19:35 ID:???]
- CakePHP使ってればUMLもマインドマップも必要ない
- 499 名前：nobodyさん mailto:sage [2008/03/30(日) 02:26:47 ID:???]
- 作業途中に仕様的にやばい匂いがしたらマインドマップ使ってる
- 500 名前：nobodyさん mailto:sage [2008/03/30(日) 02:31:49 ID:???]
- 問題を解決しやすい方法として
思ったことを、どんどん言葉として書き出す
わかってるからと頭の中でしまいこむと、全体的な解決図を結び付きにくくする
|
 |
