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

0001nobodyさん

2008/08/24(日) 21:43:37ID:???

前スレ
http://pc11.2ch.net/test/read.cgi/php/1202521438/

0497nobodyさん

2008/11/08(土) 12:36:54ID:???

いまだにオープンソースでガッツリ儲けようなんてプランのところがあるの？
本当に基幹的なDBとかhttpdとかならともかく

0498nobodyさん

2008/11/08(土) 13:25:19ID:???

ガッツリってのはいくらぐらいなのかな。
それにもよるだろうが、儲けるかどうかは才覚の問題。
OSSかどうかは関係ないだろうな。

0499nobodyさん

2008/11/08(土) 14:46:39ID:???

お金の名言

「タダほど高いものはない」

0500nobodyさん

2008/11/08(土) 16:19:59ID:???

タダほどお得なものはない

0501nobodyさん

2008/11/08(土) 17:38:16ID:???

>>499
ApacheやらLinuxやら使ってて「高くついた」って感じたことはないなあ。
むしろ安い労働力まで付いてきて、お得感しかないのが大多数では？ｗ
もちろん、大規模に「ガッツリ」儲ける分野では違うんだろうけど。

0502nobodyさん

2008/11/08(土) 18:55:54ID:???

中・小規模向けのフレームワークって何が良い？
cakeはどうもパフォーマンスが悪すぎて嫌なんだよねえ

0503nobodyさん

2008/11/08(土) 21:49:38ID:???

中・小ならEthnaでいいんじゃないの。
CIという手もあるが。

0504nobodyさん

2008/11/08(土) 23:30:51ID:???

ご冗談でしょう

0505nobodyさん

2008/11/09(日) 05:48:00ID:???

Ethnaとか、未だに選択肢に残ってるのかな？
仕事で昔触ったときに、いろいろドン引きした記憶があるんだが。

アクションを準備していないURL指定すると「全ファイル」のrequireを
し始めてプチDOSアタックになってしまう自前オートロード（笑）とかｗ

0506nobodyさん

2008/11/09(日) 09:19:25ID:???

大規模ならCI or ZFのチョイスってことでFA?

0507nobodyさん

2008/11/09(日) 11:56:58ID:???

CIってPHP4にも対応しててコードに無理が出てるみたいな話も聞くんだけど
大規模で使えるようなものなの？

小規模にしてもcakeとどっちが楽なんだろう

0508nobodyさん

2008/11/09(日) 13:41:32ID:???

ドッチかと言われればcakeだろ
でもcakeもイマイチなのはよくわかる

0509nobodyさん

2008/11/09(日) 14:55:46ID:???

ciで大規模はきつい
そういうふうには作られていない

0510nobodyさん

2008/11/09(日) 15:03:14ID:???

だよね
低機能だし
だからこそある程度自分達で実装しやすい面もあるから
逆に大規模での需要はありうるけど

かといって小規模でもCIはどうなんだろう
軽量なのは良いんだけど

0511nobodyさん

2008/11/09(日) 16:23:48ID:???

>>496
儲けなくても、一度つぶれた会社が
オプソで蘇ってうまくいってるケースはある

0512nobodyさん

2008/11/09(日) 16:25:12ID:???

オープンソースは技術的には最良の手段だよ
利益に繋げられるビジネスモデルを考えられるか、実行出来るかが問題

0513nobodyさん

2008/11/09(日) 19:20:35ID:???

そこが最大の問題だと思う。
ぶっちゃけメシ食えなきゃしょうがない

0514nobodyさん

2008/11/09(日) 19:27:31ID:???

オープンソースにかかわってるエンジニアがこれほどたくさんいるという事実は
形は違えど、オープンソースで稼げるってことの裏返しじゃないかと思うのは甘い？

0515nobodyさん

2008/11/09(日) 19:29:10ID:???

でも市場取らないとどうにもならない面もある
もしオープンソースな製品が何一つ無い分野があったら、オープンソースな製品を立ち上げる事で
その分野で一気に市場を奪える可能性がある

0516nobodyさん

2008/11/09(日) 20:01:09ID:???

>>513
gimpにしてもblenderにしても、オプソで生活してる開発者はいくらでもいる。
お前みたいな無知が日本には多いから、ボランティアみたいに見られるのは
しょうがないと思うけど。

0517nobodyさん

2008/11/09(日) 23:36:37ID:???

日本ではあまり話を聞かない気がするけど・・

0518nobodyさん

2008/11/10(月) 01:02:25ID:???

しかもFWの話で画像系とか3D系はちょっと実感わかないかも

0519nobodyさん

2008/11/10(月) 10:55:17ID:???

携帯サイト向けの機能も持ったフレームワークってあるの？

0520nobodyさん

2008/11/10(月) 11:15:09ID:???

DeNAのMobaSiFみたいなものってPHPでは聞いたことないなぁ

0521nobodyさん

2008/11/10(月) 15:28:02ID:???

携帯サイトって出力を携帯むけにするだけじゃないの？
なんか特別に機能必要け？

0522nobodyさん

2008/11/10(月) 15:29:05ID:???

セッションとかＰＣと同じじゃ動かないんだよ
そのほか端末識別番号の取得やらいろいろある

0523nobodyさん

2008/11/10(月) 16:04:14ID:???

そうそう。まともにサービスを開発したことがあったら、
携帯対応ほど煩雑なものはないと思えるよ。
キャリアと機種によって全然違う挙動するからね。
セッションもレイアウトも画像も。ま、小さいところでは絵文字とか。

0524nobodyさん

2008/11/10(月) 16:05:21ID:???

機種によって動かなかったりするからテストもコーディングも面倒

0525nobodyさん

2008/11/10(月) 16:55:03ID:???

KEMPは?

KEMP
ke-tai.org
http://ke-tai.org/index.php?KEMP

0526nobodyさん

2008/11/10(月) 17:07:31ID:???

それはＰＣ携帯両用サイトじゃなく携帯サイト作成のためのフレームワークっぽい

0527nobodyさん

2008/11/10(月) 17:09:27ID:???

両方できるものが欲しいのか
すまそ

というより両方やろうとしている時点で間違っていると思う
小規模、小機能ならありえるけど

0528nobodyさん

2008/11/10(月) 17:15:23ID:???

両対応サイトであったとしても別物と考えよ

0529nobodyさん

2008/11/10(月) 17:24:25ID:???

KEMPとやらはPHP5で動かない
携帯とＰＣで別フレームワークを使うとしたら
共通の機能を変更した場合どうすんの？

0530nobodyさん

2008/11/10(月) 18:47:01ID:???

セッション動かないのはクッキーがないからだろ？
単にget引数方式にしたらいいだけじゃないの？

0531nobodyさん

2008/11/10(月) 19:02:38ID:???

>>529
当然それぞれ変更する

0532nobodyさん

2008/11/10(月) 19:04:27ID:???

>>530
リファラーを送っちまう機種でそんなことしたら、セッションハイジャックされるべ

0533nobodyさん

2008/11/10(月) 19:05:00ID:???

実際携帯サイト向けのソリューションはいくつかあるんだけど
国内では情報少ないね

0534nobodyさん

2008/11/10(月) 19:10:08ID:???

>>530
POSTフォームだとACTIONに指定したパラメータを送らないっていう機種もあるしな
そういう機種ではPOSTフォームでセッションを維持できない。

0535nobodyさん

2008/11/10(月) 19:23:29ID:???

結局機種判別をして処理振り分けるような事をする必要があるんだよね

0536nobodyさん

2008/11/10(月) 19:35:22ID:???

ttp://gihyo.jp/dev/feature/01/mobasif/0001

ここに書いてあるのでもまだまだ序の口だな。間違ってるとこもあるし。
いまんとこ、オープンソースだとMobaSiF最強じゃないかな。

0537nobodyさん

2008/11/10(月) 19:47:32ID:???

携帯の文字コードは、そろそろUTF-8統一でいいんでしょうか？

0538nobodyさん

2008/11/10(月) 19:48:52ID:???

結局そういうのは自分とこで作るしかないんじゃね

0539nobodyさん

2008/11/10(月) 19:54:03ID:???

>>536
Perlじゃん

>>538
別に汎用的な機能だから広く使われるものが無い現状が異常
携帯関連開発の低レベル差だと思う

0540nobodyさん

2008/11/10(月) 20:24:13ID:???

うん。perlなんだけどさ。
スレチ承知であえて、携帯だけはPerlでって思えるぐらいの完成度だと思う。

0541nobodyさん

2008/11/10(月) 21:08:55ID:???

だいたい携帯は規格が無さ杉なんだよ
ＯＳも別々のが乗ってるし
エンドユーザーにとってメリットがある事じゃないんだが、不経済だなあ

0542nobodyさん

2008/11/10(月) 22:50:10ID:???

>>541
それと、各社・各世代仕様のまとめ情報が少なすぎる。
ググれば出てきそうなクッキー仕様や対応文字コード等の情報が、ほとんど無い。
会社で仕事なんかでは資料を作るんだから、暇な自営業者あたりが自分メモで
作ってても良さそうなもんなんだが。

フレームワーク辺りと違って、いじって面白くないのと、商売上公開したくないって
のと、その他もろもろ理由はあるんだろうけど。

0543nobodyさん

2008/11/10(月) 22:58:35ID:???

Androidに期待

0544nobodyさん

2008/11/10(月) 23:09:02ID:???

携帯はフルブラウザで見る以外は廃止にすべき

0545nobodyさん

2008/11/10(月) 23:39:13ID:???

MobaSiF読んでPHP用携帯FWを作るプロジェクトとか

0546nobodyさん

2008/11/11(火) 00:37:30ID:???

そもそも初期のｉモードなんかの仕様がダメ杉

0547nobodyさん

2008/11/11(火) 02:17:34ID:???

>>545
PerlのコードをPHPのコードに変換するジェネレーターがあれば、簡単に移植できるかな？

0548nobodyさん

2008/11/11(火) 02:22:07ID:???

http://oshiete1.goo.ne.jp/qa863429.html
Perlコードを、自動的にPHPコードに変換してくれる、そんな「ドラえもん」のようなプログラムがありましたら教えて下さい！

無いですねえ。

http://www.cs.wcupa.edu/~rkline/perl2php/
Perl/Php Translation

0549nobodyさん

2008/11/11(火) 07:51:48ID:???

そういやperlで思い出したけど
PHP on parrotて進んでるんでしょうか？

0550nobodyさん

2008/11/13(木) 08:51:01ID:???

>>540
Perlの事情あまりしらはい。ﾗｲﾌﾞﾗﾘのどういうとこが携帯向き?

0551nobodyさん

2008/11/13(木) 10:31:16ID:kdvrTOAA

で、肝心のフレームワークなんだけど
結局今熱いのってなんなの？

いっぱいありすぎていまいちこれっていう特徴あるやつ
ないんだよな～

最近ちょっとさわってみようかな～って思ってるのあるんだけど
誰かいじったことある人いたら所感教えて～

PAJAJ
ttp://pajaj.sourceforge.net/

xFrameworkPX
ttp://px.xframework.net/

0552nobodyさん

2008/11/13(木) 14:00:08ID:???

PRADOみたいなイベントドリブンなのはどうなんだ

0553nobodyさん

2008/11/13(木) 16:16:39ID:???

ちいたんでいい

0554nobodyさん

2008/11/13(木) 23:25:55ID:???

やっぱり落ち担当w

0555nobodyさん

2008/11/13(木) 23:27:41ID:???

もうちょっとふくらませてからｗ

0556nobodyさん

2008/11/13(木) 23:41:23ID:???

いやらしい

0557nobodyさん

2008/11/14(金) 13:45:00ID:???

大規模向けのFWはどれ?

0558nobodyさん

2008/11/14(金) 13:52:53ID:???

ちいたん

0559nobodyさん

2008/11/14(金) 13:53:13ID:???

出ると思ったｗ

0560nobodyさん

2008/11/14(金) 14:12:00ID:???

ちいたん以外で

0561nobodyさん

2008/11/14(金) 14:31:47ID:???

Symfony
Cake

0562nobodyさん

2008/11/14(金) 14:34:00ID:???

あれ?遅いとか叩いてなかったっけか?
なぜ大規模向けと?

0563nobodyさん

2008/11/14(金) 14:42:11ID:???

軽量なフレームワーク≒自由度が高い≒多人数開発では混乱を招きやすい
(重量級フレームワーク=動作が遅い)≒自由度が低い=開発のルール化度が高い≒多人数でも均一なコードレベルを保ちやすい

とはいえ、フレームワークが案件に合う合わないもあるので、
どのフレームワークを使っても、大規模開発ならプロジェクトのルールが必要だと思われ。
逆を言えば、ルールさえ作れば軽量なフレームワークでもいいと思う。
重量級フレームワークが用意してくれる機能を、自分達で実装しないとならないけどね。

あと、大規模=多人数と勝手に解釈したけど。

0564nobodyさん

2008/11/14(金) 14:50:52ID:???

数年がかりの本当に大規模なものなら
逆に自由度が高いフレームワークを使って自分たちで実装したいって需要もかなりある

0565nobodyさん

2008/11/14(金) 15:31:36ID:???

>>564
開発期間が数年？PHPでそんな案件はほとんど無いけど。

あと、それを適当にやると、どんどん「フレームワーク」自体に修正が入ってしまって、地層のように
古いコーディングとより新しいコーディングがどんどん積み重なって手に終えなくなる。
やるなら、全くいじらないか、最初にきちんと徹底的にいじって固めてしまうのがいいのかな？

0566nobodyさん

2008/11/14(金) 16:00:34ID:???

１年未満じゃ大規模とは言えないし

0567nobodyさん

2008/11/14(金) 16:19:50ID:???

webアプリで開発に何年もかかってちゃビジネスになんね。

0568nobodyさん

2008/11/14(金) 16:22:17ID:???

PHPはインタフェース部分を担当するに過ぎないから
プロジェクト全体で数年っていうのはあるよ
複数サイトを作るような事業でも共通フレームワークを作成することはあるし

0569nobodyさん

2008/11/14(金) 16:31:35ID:???

単純にスピードを比較したものがよく出るけど、あまり意味無いよな。
しかも素の状態に近いベンチとか。

もちろん非常にシンプルに作りたいときにFWの軽さは重要かもしれないけど。
色々な機能を実装するなら、結局ある程度の重さにはなるだろうし。
だったら多少重いといわれる高機能FWを使用したほうが開発効率は良いと思う。

単純なスピード比較がよく話題が出るから、疑問に感じていた。

0570nobodyさん

2008/11/14(金) 16:52:52ID:???

何が言いたいのかさっぱりだ
帰れ

0571nobodyさん

2008/11/14(金) 22:44:45ID:???

必要な機能に一番近いものを使えばいいねん
多すぎず少なすぎず

0572nobodyさん

2008/11/14(金) 23:35:14ID:???

それがベストだけどちょうどいいFWってそうはない気も。
まぁ、一番近いものを選べばいいが

0573nobodyさん

2008/11/14(金) 23:36:59ID:???

フレームワークなんて多機能な奴はほとんど一緒だけどね
パフォーマンスくらいしか差が無い気が

0574nobodyさん

2008/11/14(金) 23:49:38ID:???

大規模の意味は100万ユーザ以上が使うというアクセス数の意味で
開発の工数ではなかったけどためになった

アクセス数という意味では軽量かどうかが非常に重要と思われ
サーバの台数などのメンテナンス代が高くつくから

とはいえ重量級のものを使ってあとからプロファイリングして
リファクタリングなりすればいいような気もしてきた

0575nobodyさん

2008/11/14(金) 23:58:04ID:???

必要な機能なら実装しなきゃならないんだから
効率的な実装になってるならいいんだけどね
cakeは実装が酷いよ

0576nobodyさん

2008/11/14(金) 23:59:29ID:???

cakeはインターフェイスが全てだからじゃん
その辺までRailsを踏襲していると言えばそうかも

0577nobodyさん

2008/11/15(土) 02:26:07ID:???

ウェブアプリで、大規模って言うと、アクセス数が多いって意味で使われることが多いんじゃないかな。
でも、それってフレームワークはあんまり関係ないよな。ハードウェアスペックとか、もっと低いレイヤーの問題であって。
PHPに限らずウェブサイトの開発で数年かけるなんて、まず有り得ないと思う。官公庁のサイトで、手続きが面倒とかでない限り。
GmailとかGoogle Mapsでもそこまで行かないでしょう。まして、よくあるショッピングサイトやSNSみたいなのに1年も時間使ってたらアフォだよ。

0578nobodyさん

2008/11/15(土) 02:37:10ID:???

アクセス数の多さはフレームワークのスレで大規模にあたらないだろ
１ページだけのHTMLを出力するサイトでも大量アクセスがあれば大規模なのか？
俺は普通コード量とか機能数だと思うけど

0579nobodyさん

2008/11/15(土) 02:38:10ID:???

Googleは独自のフレームワーク作ってそうだけどね
てか絶対作ってる
他にも大企業は手の込んだ事やってそうだけどなあ

0580nobodyさん

2008/11/15(土) 02:50:13ID:???

ウェブアプリで機能の数って言っても、単に画面を増やしていくだけだからなあ。
mixiとかamazonとか、確かに画面数は多いけど、結局のところ、掲示板作るのと変わりはない。
ユーザからの入力を受け取って、何枚かのテーブルを更新して、テーブルをSELECTしなおして、文字列を加工してHTMLに埋め込むって言う。
これをひたすら繰り返して巨大化するだけ。

0581nobodyさん

2008/11/15(土) 02:53:39ID:???

機能によっては違うこともあるんじゃないか。
ユーザからのデータを何かしら加工するとか、
なにか特別なアルゴリズムでデータを収集して、
それを提供するとか。

0582nobodyさん

2008/11/15(土) 03:02:01ID:???

ＷＥＢＡＰＩの提供に際する共通機能とか
自動的にＤＢを保守してくれたりＨＤＤ壊れたらバックアップの方へ自動的に繋いで新たなバックアップ先を作るとか
（ＰＨＰコード内の接続先ＤＢサーバＩＰが動的に変わるって事ね）

思いつきで書いた

0583nobodyさん

2008/11/15(土) 04:39:48ID:???

ウェブアプリで大規模とそれ以外の境目はウェブアプリ側がスケーラビリティを気にする必要があるかどうかだと思う。

0584nobodyさん

2008/11/15(土) 05:03:15ID:???

>>580
> ウェブアプリで機能の数って言っても、単に画面を増やしていくだけだからなあ。
> mixiとかamazonとか、確かに画面数は多いけど、結局のところ、掲示板作るのと変わりはない。
> ユーザからの入力を受け取って、何枚かのテーブルを更新して、テーブルをSELECTしなおして、文字列を加工してHTMLに埋め込むって言う。
> これをひたすら繰り返して巨大化するだけ。

それはウェブアプリだからではなく、SNSやオンラインショップという
システムが、そうなっているってだけだろ。

たとえば、YouTubeのようなウェブアプリではエンコード技術が使われる。

0585nobodyさん

2008/11/15(土) 05:05:22ID:???

それにウェブじゃないシステムが何をしているかというと、
結局、ファイルにデータ読み書きして、画面に点を表示しているだけともいえる。

0586nobodyさん

2008/11/15(土) 05:47:54ID:???

大したことやってないのにフレームワークは重いから使わない(ｷﾘｯ
なんて言っちゃってる企業とか腐るほどあるからなぁ

0587nobodyさん

2008/11/15(土) 09:41:57ID:???

>>585
インプット・アウトプットの対象の幅広さは、ウェブアプリなんかとは比べものにならんように思う。
ウェブアプリの場合は、一部APIサービス的なものを除けば、ほぼ「画面」相手でいいわけだが。

>>586
その理由でテンプレートエンジンを使いたがらない人も未だに多いがな。同じじゃね？

0588nobodyさん

2008/11/15(土) 13:00:48ID:???

フレームワークに比べて、テンプレエンジンは開発効率大してよくならないからな。
つーかＦＷに組み込まれてるし

0589nobodyさん

2008/11/15(土) 13:15:36ID:???

何かをしない理由にパフォーマンスを上げている場合、大概ちゃんと調べるのとか新しい
やり方を検討するのが面倒くさいことだけの事が多いと思う。

論理削除ってあるじゃん。レコードに削除フラグを立ててデータは残すって言う。
あのフラグのチェックををいちいち手で (del_flag IS NULL OR del_flag = 0) とか書いている
会社があった。
なぜ NOT NULL制約を付けないのかと聞いたら、「重くなる」って答えが返ってきた。
全力でこけた。いろいろ間違ってる。

0590nobodyさん

2008/11/15(土) 14:11:03ID:???

12のphp最適化テクニックとか、一時期ブログに出回ったけど、
そのテクニックが使われるタイミングを考えると、誤差でしかないとか、
よくあったよね。
むしろコードが読みにくくなったり、書きにくくなったりと、
その時間のほうがもったいないとか。

0591nobodyさん

2008/11/15(土) 14:39:00ID:???

大手でphp使ってサービスやってるといえばYahooなんだけど
たとえば、↓
http://www.sooey.com/journal/2007/05/26/648/
symponyだって。
でもサービスによって違いはあって
http://wakatsukichinatsu.yahoo.co.jp/index.php?itemid=128
↑これなんてPHP?

0592nobodyさん

2008/11/15(土) 14:39:25ID:???

論理削除自体間抜け

0593nobodyさん

2008/11/15(土) 14:54:51ID:???

論理削除自体が間抜け？
方法がフラグってとこが間抜けってなら少しはわかる気もするが。

0594nobodyさん

2008/11/15(土) 14:55:03ID:???

論理削除は必要だろ。

0595nobodyさん

2008/11/15(土) 15:09:50ID:???

スレチだけど論理削除ってどういう指定にすればやりやすいですかね。
active enum('Y','N')か、status = 0 なら削除とか？

0596nobodyさん

2008/11/15(土) 15:11:46ID:???

>>593
わかんね。
フラグじゃなくてカウンタにするってこと？