[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 09/11 22:53 / Filesize : 241 KB / Number-of Response : 932
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

【PHP】フレームワークについて語るスレ10【総合】



1 名前:nobodyさん mailto:sage [2008/02/09(土) 10:43:58 ID:???]
前スレ
pc11.2ch.net/test/read.cgi/php/1197383840/

663 名前:nobodyさん mailto:sage [2008/06/10(火) 12:15:11 ID:???]
ZFが無くなったときの心配は、ZFが無くなってからすればいいんじゃないか?
大体、オープンソースなんだからZF自体が消えてもコード資産はまるまる残るだろう。

まぁノウハウって奴を蓄積したいのならべつにどうぞ


664 名前:nobodyさん mailto:sage [2008/06/10(火) 12:27:28 ID:???]
俺俺ラッパー書いてそこからZFなり呼び出すようにしたら
ZFが死んでもなんとかなるじゃん

665 名前:661 mailto:sage [2008/06/10(火) 13:05:21 ID:???]
>>662
確かに俺俺FWは俺しか使えないけど、共通処理をクラス化したときに、
その内容を整理して文書にすればいいんじゃないのかな。
それ以外は素PHPでいいわけだから、ZFのようにいろいろな制約が
無い分だけPHPを使える人は多いし、知らない人もちょいと学習すれば
使えるようになる。

>>663
ZFが消滅してもオープンソースだから残るだろう。
でもセキュリティホールや新しい技術は一切入ってこないよねえ。

>>664
ラッパーという手はあるが、実際簡単にいく?

666 名前:nobodyさん mailto:sage [2008/06/10(火) 13:13:11 ID:???]
>>665
なんかもう>>661の中で結論決まってる予感。


667 名前:nobodyさん mailto:sage [2008/06/10(火) 13:17:29 ID:???]
> でもセキュリティホールや新しい技術は一切入ってこないよねえ。
だからさ、その心配はZFが無くなってからすればいいってこと。
そんなもん心配していまから俺フレームワーク作るわっていうのなら、
セキュリホールだのなんだのはどっちみち全部自分で面倒みるんだろう?

668 名前:nobodyさん mailto:sage [2008/06/10(火) 14:27:18 ID:???]
> 確かに俺俺FWは俺しか使えないけど、共通処理をクラス化したときに、
> その内容を整理して文書にすればいいんじゃないのかな。

その文章を読まないといけないだろ?
初めて会った人が、あんたが書いたオレオレ文書を
すでに読んでいるなんてことはまずありえない。

その点ZFなら読んでいることはありえる。

> それ以外は素PHPでいいわけだから、ZFのようにいろいろな制約が
オレオレFWの制約を受けるだろう。

何の制約もないフレームワークがあったとしたら、それは
フレームワークじゃなくて、ただのライブラリだ。

> 知らない人もちょいと学習すれば 使えるようになる。
使えるということと、開発の早さ・楽さは別の話。

> でもセキュリティホールや新しい技術は一切入ってこないよねえ。
オレオレFWは、すでにセキュリティホールや新しい技術は一切入ってこないよねえ。


669 名前:nobodyさん mailto:sage [2008/06/10(火) 14:50:32 ID:???]
FW乗り換えたら全てチャラっていう前提がおかしな話
WEBアプリのFW全般に対するノウハウってのもあるし
現に今のFWはほとんどMVCベースなわけで
基本的なコンセプトが大きく変わるわけじゃない

個人的なFWを作って使うのも別に悪くはないと思うけど、
オープンソースで開発されているFWが
どれだけレビューされてテストされた上で
リリースされているかよく考えてみるべき

乗り換えたら全部チャラだし俺俺FWの方がいい、
と安易に考える奴は自惚れてるとしか思えない

FWが変わったら覚えた事が全て無駄になる、ってのは
結局表面的な部分でしかFWを扱えてないわけで
FWに「使われている」プログラマでしかないよ

670 名前:nobodyさん mailto:sage [2008/06/10(火) 15:11:29 ID:???]
いきなり俺俺は無謀だな
一回メジャーなFW使ってみてから手を出すならともかく

671 名前:nobodyさん mailto:sage [2008/06/10(火) 16:42:19 ID:???]
オレオレFWを公開して普及させようと言うならともかく、自分に必要な仕組みだけ
自分で作るのが、そんなに悪い選択とは思わないけど。




672 名前:nobodyさん mailto:sage [2008/06/10(火) 17:28:40 ID:???]
単純にZF死んだら困るから自分で作るよ!っていう理由に納得できないだけだろう。


673 名前:661 mailto:sage [2008/06/10(火) 17:29:20 ID:???]
>>669

FW乗り換えでも、MVCの考え方やノウハウは残るが、
現実的にアプリはすべて書き換え。
数十本ならそうでもないが、1000本単位なら相当な手間。
「FWに使われているプログラマ」はいいけど、現実的に手間を
掛けられないというところをわかってないのは問題。
同じFWに縛られ続けていくのはいいが、消滅しちゃったとき
どうやって資産をメンテしていくのか。
そういう意味でチャラって書いた。

だから >>665 が書いたようにオープンソースであること
を考えると、そういった問題が解決できそうだ。
また多くの人が使ってこなれている面はメリットだよな。


それで、実際どれだけのモンがFWで構築されてんだろ。
cakePHPなんかも有名だが、ZFが出て乗り換えを考える
人もいるだろうし、どうするんだろ。

674 名前:nobodyさん mailto:sage [2008/06/10(火) 17:32:43 ID:???]
zfに乗り換える人なんていないでしょ
ショボfwじゃん

675 名前:nobodyさん mailto:sage [2008/06/10(火) 17:35:53 ID:???]
どうやって資産をメンテしていくっていうか、
それは普通にソースツリーをフォークしてメンテするだけだろう?

自分でゼロから作るよりは随分と楽だと思うが。


676 名前:nobodyさん mailto:sage [2008/06/10(火) 19:10:47 ID:???]
>>673
採用しているFWが変わったからって
既に出来上がってるアプリをそのFWに
全て書き換えるケースなんてそうそう無いだろ
完全な自社コンテンツでアクティブなものか
コンテンツ自体を総リニューアル時に合わせて移行、くらいなもんで
元から運用してるものは普通そのままメンテだろ?
千本単位とかそれこそ非現実的じゃないか?

677 名前:nobodyさん mailto:sage [2008/06/10(火) 19:46:40 ID:???]
たとえばsymfony作られたサイト
世界全体でも1000もないだろw

678 名前:nobodyさん mailto:sage [2008/06/10(火) 21:11:39 ID:???]
とりあえずDISる

少し釣れる

ツンデレ教えて君

こうするとggrksと言われないんですねわかります

679 名前:nobodyさん mailto:sage [2008/06/10(火) 21:26:00 ID:???]
数字おおげさに言い過ぎる

突っ込まれる

雲隠れですねわかります

680 名前:661 mailto:sage [2008/06/11(水) 09:37:45 ID:???]
>>676
なるほど、すべて書き換えないケースもあるな....
しかし、千本単位が非現実的なら、「大規模開発」って
謳っているのはどのくらいの規模なんだろうか。

>>677が書いたように、事実上PHPのFWはまだまだ
浸透していない、PHPでの開発は結局小規模なもののみ
ってことなんかな。

681 名前:nobodyさん mailto:sage [2008/06/11(水) 09:58:12 ID:???]
>>680
大規模開発って、ふつうプロジェクト数のことじゃなくて、
ユーザ数とか、高信頼性を確保するために大きいシステムを組むってことだろう?

そんなものは、当然一件ごとに何年もかかることがままあるから、
大規模なプロジェクトを千なんてオーダーで抱えてるとこなんてありえないよ。


ていうか、自分が抱えてもいない数のプロジェクトの事と、
(まだつぶれていない)ZFが潰れることを心配して
自分で作った方がいいと思ったの???




682 名前:nobodyさん mailto:sage [2008/06/11(水) 23:15:02 ID:???]
どれもこれも、今となっては、PHP4で書き続ける理由に説得力が伴っていないわな。
もうとっくに殆どの環境はPHP5に移行している。
lib/php内やフレームワークのコードだけがPHP4。
自分で書く時、例えば、varなんて使う機会が無い。
そのせいで、細かく曖昧さを指摘する目に見えないエラーがリクエスト毎に何10何100と出ている。

683 名前:nobodyさん mailto:sage [2008/06/11(水) 23:37:36 ID:???]
>>681

>>661 ではないけど、大規模開発って言ったら、コード量をイメージするなぁ。
大規模サイトだと、ユーザ数が多いって意味なのかなぁって感じもするけど。

外部のフレームワークの適用については、例えばバグとかセキュリティホールが
あるからバージョンアップしてくださいって言われても、影響範囲が読めないと
二の足踏むし、かといってそのままってのも気持ち悪いし、自作しても知れてる
程度の使い方しかしないのなら、使いたくないってのは良く分かる。

684 名前:nobodyさん mailto:sage [2008/06/12(木) 00:08:14 ID:???]
S2Container.PHP5 を勉強しようとセットアップのページ読んでるんですが、解りづらくないですか?
一番初めに書いてあるS2Container.version.tgzを落としてきたら拡張子が.tgになってるし、
>S2Container.php と S2ContainerSplAutoLoad.php を require して下さい
って何のファイルに書けばいいのか書いてないし・・・。

685 名前:nobodyさん mailto:sage [2008/06/12(木) 00:18:48 ID:???]
>>684
pear installコマンドって、ダウンロードした後、勝手にセットアップまでしてくれんじゃないの?

で、PEARのディレクトリってPHP5を入れた時点でパス通ってて、
ソレを、これから加工と思ってる空のPHPにrequire_onceで例に書いてあるとおりに書けばいいんじゃないの?

違うの?

686 名前:nobodyさん mailto:sage [2008/06/12(木) 04:04:39 ID:???]
>>685
個人的に、pearコマンドを使わないインストール方法をきちんと書いてくれないFWは信用できない。
S2Containerは触ったこと無いけど。

最初からPEAR必須ライブラリも把握できるし、必要最低限の設定等がわかっていれば、環境を
変えるときも対処しやすいと思う

687 名前:681 mailto:sage [2008/06/12(木) 12:13:00 ID:???]
>>683
つまり、アップデートのパッチを調べる労力 > 自分で書く+メンテする労力
ならば自分で書いてもいいってことね。で、コード量が少ないなら
書くのもメンテするのもたいした労力はいらないからそれもあり、と。
まぁそういう理由なら納得できる。

個人的にはFWを導入した時点で自分で書く+メンテしてもいいと思える
コード量を越える気がするけど、そこはまぁヒトそれぞれ。


大規模開発ってやつについては、言うとおりコード量もあると思う。
なんていうか、大規模開発っていうのはプロジェクト一件あたりの
必要な金、期間や人力がデカいっていうことで。



688 名前:nobodyさん [2008/06/12(木) 13:50:39 ID:5LtH7vFx]
JavaもどきのFW使うなら、素直にJava使えばいいと思う
Seaserは簡易版のTeedaに期待

689 名前:nobodyさん mailto:sage [2008/06/12(木) 23:10:10 ID:???]
Webのページ上でボタン押したり、何かした時の処理は、
全部 Ajax 経由でいいと思う。
何かする度に、フォームの全ての値がサーバに送られて
画面全体がリロードされるのって変すぎる。
で、Ajaxと一体になってるフレームワークって何かありませんか?

690 名前:nobodyさん mailto:sage [2008/06/12(木) 23:17:19 ID:???]
>>689
極端な意見キター
っていうかそれならもうMS製品で作っちゃえよ・・・
その方向で少し間違えると、キーを押したりマウスを動かしたりするたびにリクエストの発生する
糞サイトになるぞw

で、そんなFWはこれから大流行するだろうから、しばらくのんびり待ってたら?AIRとかもあるしね

691 名前:689 mailto:sage [2008/06/12(木) 23:58:39 ID:???]
>>690
作ってて違和感あるんだよね。なんだかばかばかしい。
.NETって言われるだろうなと思ったけど、MSに閉じた技術ってのがね。

Ajaxから戻ってきたデータによって、JavaScriptで画面上の
変化部分を更新するとか、ある程度自動でできる仕組みがあると嬉しい。
更新したデータは、セッション変数で保持してればいい。
かと言って、ブラウザにプラグインが必要になるような技術もいやだな。
今のWebと親和性をなるべく保ちながら、より自然な開発がしたい。
もうちょっと真剣に探してみるかな。



692 名前:nobodyさん mailto:sage [2008/06/13(金) 00:15:02 ID:???]
>>690
>AIRとかもあるしね
あれは勧めちゃいかんわさ。MSの.net以上の勘違い製品。

どうしてもその手の処理が必要な時は
「ユーザに断ってから」Applet立ち上げれば今時でさえ通じるもんだ
他不要

693 名前:nobodyさん mailto:sage [2008/06/13(金) 00:25:04 ID:???]
>>691が感じている違和感がどの辺にあるのかよくわからないけど
サーバサイドはPHPで、クライアントはJavaScriptなりFlash(ActionScript)なりっていうのが
面倒ってこと?

>>691で書いているくらいやりたいことが決まっていれば、例えばW3CとECMAScript標準に
完全準拠の理想フレームワークなら、作ろうと思えば作れるかもね

どのみちデザインのためにHTMLで小細工しなくちゃいけないなら、それがやりにくい様なフォー
ムデータの扱いを強要するFWは結局流行らないだろうと思う
Ajaxを含むJavaScriptやFlashの技術は、まさにクライアント依存の妥協案というか手法というか、
っていう部分なんだから、それをサーバ側の組み方と違うと言って敬遠していては現状何も作れ
ない、とみんなそう思ってるんじゃないかなあ

だから、俺は今日もしこしこ正しいかどうか解らないJavaScriptを書きますよ、と。

694 名前:691 mailto:sage [2008/06/13(金) 01:22:41 ID:???]
>>693
違和感ってのは、>>689に書いた内容です。
画面の一部を変更したい時でも、画面全体に影響があるので、
プログラムがそれを考慮した構造になり、分かりにくいものになってしまいます。
GETとPOSTを分けたりすると、更に分かりにくくなります。
WindowsのGUIプログラミングのような開発ができたらいいなと。
イベントドリブンで感じで。
サーバサイド言語 + JavaScript (Ajax含む) でそういう仕組み
になってるフレームワークがないかなと思ったんですよね。
今の自分の作り方が悪いだけかもしれませんが。

695 名前:nobodyさん mailto:sage [2008/06/13(金) 02:12:02 ID:???]
>>694
イベントドリブンって言葉だけに反応すると、
PRADOとか、PHPのフレームワークはイベントドリブンらしいよ。

後、Ajaxだと、AjaxCoreとかってフレームワークがあるみたいだけど、ここら辺組み合わせたらなんかできるのかな。


696 名前:nobodyさん mailto:sage [2008/06/13(金) 02:15:42 ID:???]
まあ、HTTPやHTMLはビジネスアプリケーションを実装するために考えられたものじゃないからな。
Windowsフォームのアプリケーションと同じことをウェブに求めるのは無理がある。
凝ったウェブデザイン(というか、普通のエンドユーザ向けウェブサイトで求められるデザイン)を、DOMによるCSSの操作だけでデザイン対応するのは相当無理がある。
そこまで機能性を求められるアプリなら、.ウェブアプリじゃなくてNETのアプリにするのが妥当と思うし、マルチプラットフォームにしたいならJavaでも使えばいいと思う。


697 名前:nobodyさん mailto:sage [2008/06/13(金) 20:10:11 ID:???]
>>696
だが不可能ではない。
そして確実に流れはそちらに向かっている。

698 名前:nobodyさん mailto:sage [2008/06/13(金) 23:34:10 ID:???]
向かってねー与。

699 名前:nobodyさん mailto:sage [2008/06/13(金) 23:43:31 ID:???]
googleやadobeの動向も知らないのか?

700 名前:nobodyさん mailto:sage [2008/06/14(土) 00:22:27 ID:???]
PhotoShopがFirefoxのプラグ印になるといいね。

701 名前:nobodyさん mailto:sage [2008/06/14(土) 00:27:33 ID:???]
>>699
kwsk

運用上でも昨今のAjaxライブラリの伏魔殿具合見ても、
けっこ前に壁にぶちあたったきり進歩がないしな。
javascript1.7以上が普及してくれれば、スコープ汚しまくりで
setTimeout地獄な糞Ajaxの現状を打破できるのかもしれないが。

air入れてる奴もsilverlight入れてる奴も見ないしな

Ajaxは割り切って使うに限る。
GoogleはFlashも使ってる。必要に応じて適用してるだけじゃないのかね



702 名前:nobodyさん mailto:sage [2008/06/15(日) 14:13:27 ID:???]
muninのグラフ見てたらiowaitで埋まってる時間があるんだけど原因がわからんちん
mysqlのスロークエリみたいに
処理速度が遅ければログ取る機構とか付けてる?
てかそんなのフレームワークの標準機能で付けとけよ

703 名前:nobodyさん mailto:sage [2008/06/16(月) 12:59:18 ID:???]
HD壊れかけ?

704 名前:nobodyさん [2008/06/18(水) 02:05:34 ID:ZYTHmHR0]
データが飛んで初めて分かる、バックアップの重要性><

705 名前:nobodyさん mailto:sage [2008/06/19(木) 21:58:18 ID:???]
バックアップ?ああ、そういやPHPやってる雑魚どもはSVN使わんな。どいつもこいつもWindowsでeclipseを使いつつ、subclipseを入れてないw

706 名前:nobodyさん mailto:sage [2008/06/19(木) 22:29:31 ID:???]
何この頭の悪そうな書き込み

707 名前:nobodyさん mailto:sage [2008/06/20(金) 00:37:33 ID:???]
お手軽にCVS使って、時々圧縮・暗号化したのをYahooブリーフケースにおいてる。

708 名前:nobodyさん mailto:sage [2008/06/20(金) 00:41:52 ID:???]
svnって開発時には使うけど稼働時に使うか?

709 名前:nobodyさん mailto:sage [2008/06/20(金) 01:08:36 ID:???]
>>708
稼動時でもバグが見つかれば更新しないといけないから
稼働環境でもマージ作業せなあかんやろ

710 名前:nobodyさん mailto:sage [2008/06/20(金) 02:15:40 ID:???]
何この頭悪そうな話題のずれて行き方

711 名前:nobodyさん mailto:sage [2008/06/20(金) 12:38:43 ID:???]
PRADOわかる人いる?




712 名前:nobodyさん [2008/06/23(月) 10:47:52 ID:isKyS0yI]
以前、使ってみた(というか実験してみた)ことある。

以下、個人の感想だが、設計は面白いが、web用のフレームワークとして間違った方向に行ってる気がしたので、実践では使ってない。
フレームワークの勉強をするにはいいとは思うよ。

713 名前:nobodyさん mailto:sage [2008/06/23(月) 16:04:32 ID:???]
>>712の言うweb用のフレームワークとして間違った方向とか正しい方向とかは意味不明だが、
PRADOは構築ルール縛りをするには良いとおもう。
開発効率は生だとものすごく悪いので、Radを待つか自前でつくるなりしないと使い物にならん。

714 名前:nobodyさん mailto:sage [2008/06/25(水) 00:06:13 ID:???]
そういや、Kohanaって話題になったことある?
CIからforkして、PHP5 Strictと安定性・堅牢性を進めると聞いてるけど。
ググっても日本語サイト少ない・・・

715 名前:nobodyさん mailto:sage [2008/06/25(水) 01:09:00 ID:???]
Kohana使ってるよ。
日本語情報どころか英語の情報もあまりない。

716 名前:nobodyさん [2008/06/25(水) 11:12:53 ID:2TehNRcN]
>>713
詳しく書かないでスマン。

自分の感じた事を伝えようと思って、昔実験したサンプルを見ながら今書いてるんで現在のバージョンとは違うかもしれんけど

home.page
<com:TForm>
<com:TButton Text="Click me" OnClick="buttonClicked" />
</com:TForm>

確か、テンプレート風にこう書いて

Home.php
class Home extends TPage
{
public function buttonClicked($sender,$param)
{
$sender->Text="Hello World!";
}
}

で、アクションはこう書くだろ?
なんか、symfonyだと(というか、俺の主に使ってるフレームワークがsymfonyなのでそれとの比較になるが)request、responseっていうのがあって、webアプリなんだなぁ、と見るからに分かるんだが、
Pradoの場合、これ見るだけだとwebアプリだって分からないんじゃない?と思って「間違った方向」って言ってしまったんだ。
あくまで個人的な感想だと思って「間違った方向」については受け流してくれ。

# 改めて見るとやっぱり面白いフレームワークだとは思うな。
# ただ、実際に使うのは、request responseが無いとか、どうしても実装に何か無理がありそうな気がしてしまう、というのが感想な訳だ。
# バリバリに使ってる人の感想を聞いてみたい所かも?

717 名前:nobodyさん mailto:sage [2008/06/25(水) 13:22:19 ID:???]
Webアプリ、しかもPHPでDelphi丸出しは厳しいものがあるよね

718 名前:nobodyさん mailto:sage [2008/06/25(水) 17:48:03 ID:???]
>>716
なるほど。2.0の仕様だな。


719 名前:nobodyさん mailto:sage [2008/06/25(水) 19:18:36 ID:???]
突然すんません。

いまいち『フレームワーク』ってのがわからないんです。

ググって調べたりしてるんだけど、『?』な感じなんです。


すご〜くカンタンでいいんで説明してくれる方いませんでしょうか?
あと、こんなオレにおすすめの本あったら紹介して下さい。

プログラムは一応、データベースとか使って基本的なCMSとかつくれます。


今度、作ろうと思ってるサイトがあるんですが、『フレームワーク』ってのを
使った方がいいような感じがしてここへきました。

よろしくお願いします。

720 名前:nobodyさん mailto:sage [2008/06/25(水) 19:20:21 ID:???]
ググれ

721 名前:nobodyさん mailto:sage [2008/06/25(水) 19:39:02 ID:???]
>>719
framework
【名】
1. 骨組み{ほねぐみ}、フレームワーク、枠組み{わくぐみ}、下部構造{かぶ こうぞう}、骨格{こっかく}

なんか作るときに土台が出来てると楽だろ?
でもその土台に制限されてしまうこともある。



722 名前:nobodyさん mailto:sage [2008/06/25(水) 19:49:30 ID:???]
>>721
ありがとうございます。

ググってました。

『車』で例えるとしたら、
”キーを回すとエンジンがかかる”とかの仕組みができていて
一から作らなくてもいいってことなんでしょうか?

『いろんな仕組みのセットがあって、ボタンひとつで簡単に組み込める』
みないな感じですかね…?

723 名前:nobodyさん mailto:sage [2008/06/25(水) 20:15:21 ID:???]
>>722
家を建てるに当たって、その骨組みが出来ているって感じ。
で、その骨組みに合わせて作っていくので、やりやすいよと。

>>722の車の例えだと、PEARとか見たいなライブラリだね。フレームワークではない。

724 名前:nobodyさん mailto:sage [2008/06/25(水) 20:27:52 ID:???]
>>723
ありがとうございます。

ってことは、一戸建ての骨組みができている状態からスタートして
中身の部屋とかキッチンとかを入れて(?)いく。ような感じ?

フレームワークの違いってのは、その『骨組み』がマンションだったり一戸建て
だったりするってことなんでしょうか?



今、悩んでいるのは、フレームワークを使った方がいいのか、今までのように
普通(?)に作るのがいいのか。という所なんです。


725 名前:nobodyさん [2008/06/25(水) 20:34:00 ID:gyu7FUKS]
直訳すると枠組み、だと思うんだが、骨組みの方が俺的にもしっくり来るね。

PHPを粘土と例えて、像を作ってみよう、という事になった時の事を考えてみると
いきなり粘土で像を作る事はできると思うが、やっぱり、予め骨組みあった方が作りやすいだろ?

でも、骨組みが、犬の骨組みだとしたら、人間の像を作るのは却って難しいと思う。

>>716
なるほど。という事は現在は大分変わってるのか。
そのうち、また見てみる事にするよ。


726 名前:nobodyさん mailto:sage [2008/06/25(水) 20:34:34 ID:???]
>>724
そういうところで悩む人は、多分人のソースなんかあんまり読まない様なタイプの
人だろうから、いっぺん使ってみるのは勉強になるんではないかと偏見だけど思う。

まあ業務に使うかどうかは置いておいて、PHPでお仕事しているんなら触って損は
無いかと思う。

727 名前:nobodyさん mailto:sage [2008/06/25(水) 20:40:00 ID:???]
こんな抽象的な話を聞いて何が分かるんだろうw

728 名前:nobodyさん mailto:sage [2008/06/25(水) 20:41:46 ID:???]
>>724
ページの遷移部分だとか、データの検証(バリデーション)部分だとかが簡単に出来たり、
フレームワーク自身が持っているライブラリが便利だったりとか。
データベースへのアクセスに関しては各フレームワーク共に工夫されてて凄く使いやすいです。

>フレームワークの違いってのは、その『骨組み』がマンションだったり一戸建て
だったりするってことなんでしょうか?

そうですね。「ちいたん」見たいなライトウェイトなフレームワークは一戸建てな感じで、
synfonyやEthnaやCakePHPなんかはマンションみたいな巨大なプロジェクトの開発に向いてるかと。


>今、悩んでいるのは、フレームワークを使った方がいいのか、今までのように
普通(?)に作るのがいいのか。という所なんです。

フレームワークは、できるなら使ってみたほうがいいと思います。
開発の規模や趣味趣向によって合う合わないってのはあると思いますが、
プログラムを組む上での手法として、勉強になる部分は大きいですし。

とりあえず、賛否両論歩けど、CodeIgniterなんかを触ってみてはいかがでしょう。
日本語のマニュアルが充実しているのと、割かしライトウェイトなので、扱いやすいのではないでしょうか。



729 名前:nobodyさん mailto:sage [2008/06/25(水) 20:43:00 ID:???]
>>725
ありがとうございます。

>>でも、骨組みが、犬の骨組みだとしたら、人間の像を作るのは却って難しいと思う。
これ気になります…

>>726
ありがとうございます。

自分はまだ、人のソースをじっくり見て分かる所まで行ってないと思います。
なんか、好きなようにしたくて。ソースはかなり変かもしれません。

今『CakePHP』の関連サイトを見てました。
CakePHPってどうでしょうか?


明日、ジュンク堂とか行って関連本探してこようと思います。




730 名前:nobodyさん [2008/06/25(水) 20:46:21 ID:gyu7FUKS]
下げ忘れた(汗)

>今、悩んでいるのは、フレームワークを使った方がいいのか、今までのように
>普通(?)に作るのがいいのか。という所なんです。
なるほど。フレームワークを学習するのには、コストがかかるからそういう風に悩むのは正しい姿勢だと思うよ。

で、まずは、どれだけの時間があるか?という所をはっきりさせるべきだと思うね。今書いたように「コストがかかる」から。

フレームワークを使わないでもできない事はないレベル & 時間が無い(半年以下)なら、たぶん今まで通り作った方がいいと思う。
(半年、というの人によるかな。でも、最低1ヶ月は学習する時間が欲しい。)

かなり大きなアプリになる予定(設計がまだ未定。先が見えない)& 時間がある、というのなら、なにかフレームワークを使う事を考えた方がいい。
後で付け足す事になったとしても、フレームワークで作ってあると、部品を付け足せるように設計されている(事が多い)からね。



・・・実際のお客様というのは、かなーり想定外の要求してくるから、それでも吸収できないくらいの事を言ってくる事もあるんだがな・・・

731 名前:nobodyさん mailto:sage [2008/06/25(水) 20:47:14 ID:???]
もうすでに無駄なコストかかってるんでは



732 名前:nobodyさん mailto:sage [2008/06/25(水) 20:53:37 ID:???]
また忘れた(汗)
ってか、みんなレス早いな。

>>でも、骨組みが、犬の骨組みだとしたら
実際には、webアプリの骨組みだから、あまり気にしないで大丈夫だと思う。
まぁ、時間あるならいくつかいじってみて、そのフレームワークの癖を見ておくのもいい勉強になるはず。
(あぁ。結構勉強してそうだからこんな事言っちまったが・・・たぶん、PEARを使いこなせる・・・使えるくらいの力量あるよね?もし無かったとしたら、まずは、ライブラリを使いこなせるようになってから、がいいと思う。)

# Cakeについては、使ってないので他の方に

733 名前:nobodyさん mailto:sage [2008/06/25(水) 20:58:58 ID:???]
>>729
CakePHPで一回チュートリアルとか「10分で作る〜」とかを見て、一回作っていいかもしれない。
普通にプログラム作ってるだけだったりすると、なんでこんな動きするのか分からないような動きする。

今後、フレームワークを使わないプログラムを書くにしても、凄く勉強になるよ。

734 名前:nobodyさん mailto:sage [2008/06/25(水) 21:03:51 ID:???]
>>728
ありがとうございます。

CodeIgniterってのは聞いたことがなかったのでちょっと
見てきます。


>>730
ありがとうございます。

メインはデザイン仕事でやっているので、時間はそれなりに
とれそうです。
自分としても勉強したい部分もあります。

ライブラリに関しては…”使いこなしてる”とまでは…


>>733
ありがとうございます。
>CakePHPで一回チュートリアルとか「10分で作る〜」とかを見て、

やっぱりそれが一番かもしれませんね。

>普通にプログラム作ってるだけだったりすると、
なんかコワイですね。

明日本屋行ってきます!

皆さん、いきなりなのに本当にいろいろありがとうございました!




735 名前:nobodyさん mailto:sage [2008/06/25(水) 21:41:34 ID:???]
「フレームワークを使えば、アプリケーションを効率よく開発できます」
っていう言葉は、誤解を招く売り文句だと思う。

現実には、フレームワークの内部動作を調べて、
中で何をやってるかだいたい分かるレベルになって初めて
効率よく安全なアプリを自信を持って作れるようになる。
と思うけどな。

736 名前:nobodyさん mailto:sage [2008/06/25(水) 22:45:59 ID:???]
>>735
正しい動作がしないとか、問題が出たときに見ればいいんじゃないのかね。
そのためにチュートリアルとか、マニュアルサイトとかあるわけだし。

PHPやるのに、PHPの関数のソースコードまで読まないでしょ?

737 名前:nobodyさん mailto:sage [2008/06/25(水) 23:06:49 ID:???]
>>736
それはその通りなんだけどね
世の中には、想像を絶するような要求をしてくる人がいたりして、そういう要求を満たす為には・・・という事なんじゃないかな。
普通は、チュートリアルをこなせば(一応)使えるようなレベルにはなるはず。

とはいえ、そのレベルだと、そのフレームワーク臭さ(?)が抜けないアプリしか出来ないけど。

あぁ。現在のPHPのフレームワークはRAD機能がついているのばっかりだから、そういう奴で標準的なアプリを作って試してみるといいんだな。
で、そのフレームワークらしさが気に入ったら使えばいいと。

738 名前:nobodyさん mailto:sage [2008/06/25(水) 23:22:18 ID:???]
>>735
Emacsとかviのような変態エディタみたいなもんか
操作を覚えるまでの過程を考えると必ずしも開発効率が向上するとは限らないみたいな

739 名前:nobodyさん mailto:sage [2008/06/25(水) 23:42:13 ID:???]
>>737
ちょっと話題とずれるけど、
d.hatena.ne.jp/sotarok/20080422/php_framework_fight
最近、こんなの見つけた。

各フレームワークで同一アプリケーションを作成して、その使いやすさだとか、コーディング量が少ないのがどれか
とかを決めるような大会みたい。

740 名前:nobodyさん mailto:sage [2008/06/26(木) 00:01:32 ID:???]
>>736
PHPのソースコード(C++?)は読まないけど、マニュアルは死ぬほど読む
ヴァージョンの差異もでかいしorz

んで、フレームワークでソースコードを読むのは、PHP程ドキュメントが整備されて
いないから、っていうのが一番大きい気がする。「正しい動作」とか「使い方」が、実は
サンプルを含めてソースを読まなきゃわからない、みたいな。

だから「問題が出たとき」だけソースを読めばいいとは思わない。
というか、それで現行のフレームワークが使える気がしない俺がいる

741 名前:nobodyさん mailto:sage [2008/06/26(木) 00:06:30 ID:???]
>>736
たまにPHPのソースコード(Cだよ)も読むよ

>>738
そうそう
苦労量保存の法則

でも、覚えてしまえば、品質を保ったままで開発スピード
を上げられるから、やればやるほど楽して儲けられるはず。



742 名前:nobodyさん mailto:sage [2008/06/26(木) 00:40:00 ID:???]
>>740,>>741
なるほど〜。

フレームワークってちょろっと眺めてちょっと使ってみる、ぐらいしかしたこと無いわけだけど、
確かに理解しきるのは困難極めそう。

実際、Webで結構出てるPHPフレームワークって、日本の企業さんとかはつかってるところあるのかな?


743 名前:nobodyさん mailto:sage [2008/06/26(木) 05:27:45 ID:???]
そんなの使いまくりにきまってるやん
企業が使わずしてどこで使うの

744 名前:nobodyさん mailto:sage [2008/06/26(木) 07:21:25 ID:???]
大きめの企業でなら、Ethnaとか一時期多かったんじゃない?
さすがにCakePHPやちいたんを使うようなイメージは持ちにくい

まあベンチャーというか中小業者なら、担当者の趣味で半年
単位で採用フレームワークが変わってても驚かない
それをもって企業が使っていると言うのは、抵抗があるけど

745 名前:nobodyさん mailto:sage [2008/06/26(木) 07:26:20 ID:???]
フレームワークを使ってない企業の方が少ないだろ

746 名前:nobodyさん mailto:sage [2008/06/26(木) 14:03:08 ID:???]
日本で作られたフレームワークは使う気がしない。

やっぱり世界規模で進んでいるものの方が安心だよね。

747 名前:nobodyさん mailto:sage [2008/06/26(木) 14:07:52 ID:???]
>>746
そーでもない。マルチバイトって何?おいしいの?っていう開発者?も
英米圏にはてんこ盛りだということを忘れてはいけない

だからといって国産が使いやすいわけでも無いけど、日本はそれなりに
良い線いってるんじゃ無いかとも思う。
世界規模にならないのは、コミュニティやドキュメントが英語ベースじゃ
ないからだけじゃね?

748 名前:nobodyさん mailto:sage [2008/06/26(木) 14:16:13 ID:???]
今時UTF8対応じゃないフレームワークは、使う気がしない。

749 名前:nobodyさん mailto:sage [2008/06/26(木) 14:18:26 ID:???]
そんなのあるか?

750 名前:nobodyさん mailto:sage [2008/06/26(木) 14:25:59 ID:???]
まあメールライブラリはそのまま使えると思わない方が無難
Validationや文字数カウントが入る部分も微妙

UTF-8に限定すれば問題は少ないだろうけどね・・・。
コメントのコピーライト部分のラテン文字が必ず文字化けして
いるのは多分仕様です。・・・奴らはUTF-8使ってるのか?

751 名前:nobodyさん mailto:sage [2008/06/26(木) 14:41:05 ID:???]
ひと昔前までの印象としては欧州産はまだマシで、米国産はI18NとかM17Nとかいう発想が無いのが多かった気がする



752 名前:nobodyさん [2008/06/26(木) 19:00:58 ID:0xtx7Zko]
ethnaがとっつきやすくてよかった。
必要最小限の機能でやりたい事は全部やれた。


753 名前:nobodyさん mailto:sage [2008/06/26(木) 22:54:59 ID:???]
これからSmartyの仕事にかかる。本当に馬鹿らしい。もうこれでPHPの仕事を最後にしたい。

754 名前:nobodyさん mailto:sage [2008/06/27(金) 00:09:22 ID:???]
なるほど。Ethnaとかは使われてるんだね。

自社開発のクローズなフレームワーク使ってるっていう例も多いの?

755 名前:nobodyさん mailto:sage [2008/06/27(金) 00:25:40 ID:???]
俺はもうPHPを捨てたぜ!
もう醜いのはうんざりだ
これからはRubyたんとちゅっちゅするんだ

756 名前:nobodyさん mailto:sage [2008/06/27(金) 01:10:55 ID:???]
醜いのにうんざりしたと言いながら、よりにもよってRubyかいな

ありゃ便利だけど、あくまでbetter perlであって綺麗な世界ではないぜ
まだJavaScriptの方が一貫性と綺麗な世界、シンプルさ保っててる
醜いこと嫌ってweb用となら、pythonも併せて検討した方がいいかもね
Rubyが気になるようなら、もしかしたら君は醜いモノもある程度必要としている方の人かもしれん

もし醜くないことだけが評価されるなら、CのCGIはもっと普及していることだろうw

757 名前:nobodyさん mailto:sage [2008/06/27(金) 02:15:02 ID:???]
PythonよりRubyの方が美しく書けるだろJK
PythonのOOは後付で一貫してない部分があるし
OOPと手続き型の混在感がある
JSは悪くはないが、まじめなだけが取り柄でおもしろみに欠ける

758 名前:nobodyさん mailto:sage [2008/06/27(金) 03:07:52 ID:???]
醜く書き散らせてこそLL
汚く書きたくなきゃ制約の多い言語で十分だ
PHPに不満ある奴は、もっと泥に塗れられる言語を求めてるんだぜ
QIQとか、自由度と混沌を一緒に提案してくれてるんだ
本家にマージされてほしいぜ

あとJSはまじめどころか変態だぜw

759 名前:nobodyさん mailto:sage [2008/06/27(金) 03:35:51 ID:???]
うむ。JSはPythonもC++0xも取り込もうとしている変態言語(褒め言葉)

760 名前:nobodyさん mailto:sage [2008/06/27(金) 09:10:17 ID:???]
あいかわらずレベル低いやつらしかいないな。

761 名前:nobodyさん mailto:sage [2008/06/27(金) 09:32:26 ID:???]
RubyはPerlをオブジェクト指向風に作り直したような感じだもんな。



762 名前:nobodyさん mailto:sage [2008/06/27(金) 09:37:50 ID:???]
760みたいなこと書く奴が最もカス

763 名前:nobodyさん mailto:sage [2008/06/28(土) 19:37:31 ID:???]
非phpのfwを見て回ったが
CGIを高速に運用する環境で決定打を持つものがないな
どれも不安定っぽい
そう考えるとmod_phpの安定感は偉大だった






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<241KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef