トップページ⇒php
1001コメント282KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん2008/08/24(日) 21:43:37ID:???
前スレ
http://pc11.2ch.net/test/read.cgi/php/1202521438/
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
わかんね。
フラグじゃなくてカウンタにするってこと？
0597nobodyさん2008/11/15(土) 16:06:02ID:???
大規模向けではなく一番スケールアウトしやすいFWは?
0598nobodyさん2008/11/15(土) 16:34:55ID:???
スケールアウト考えたらモデルは自分で書かないときつくね？
0599nobodyさん2008/11/15(土) 16:57:52ID:???
ちｒｙ
0600nobodyさん2008/11/15(土) 17:24:52ID:???
>>595
deleted（datetime）がnullかどうか
0601nobodyさん2008/11/15(土) 17:52:20ID:???
int型にして、0だと削除扱いにするのが妥当だろうな。PHPやPerlなら、ブーリアン評価でfalseが帰ってくるし。
0602nobodyさん2008/11/15(土) 17:55:22ID:???
勝手に値はいるのはtimestampだけだっけ？
0603nobodyさん2008/11/15(土) 18:02:15ID:???
>>602
NOT NULL にしておいて default を設定すれば入るだろ
0604nobodyさん2008/11/15(土) 18:49:10ID:???
mysqlはデフォルト値に関数が使えない
0605nobodyさん2008/11/15(土) 18:51:03ID:???
>>600
deletedってどういうこと？
0606nobodyさん2008/11/15(土) 19:09:25ID:???
フィールド名じゃないの？
0607nobodyさん2008/11/15(土) 19:12:51ID:???
ああそういうことか、関数かと思ったｗ
0608nobodyさん2008/11/15(土) 19:13:24ID:???
nullだとインデックスが使われないから論理値のほうが良くない？
0609nobodyさん2008/11/15(土) 19:27:12ID:???
nullかどうかで求めるのは本来正しく無いだろうね
削除された、と言う状態がシステム上にありうるならそれはnullで表現すべきじゃない
0610nobodyさん2008/11/15(土) 19:54:48ID:???
というか、３値論理っての？ NULL を理解していないとか必要性を感じないとかの場合は、
全フィールド NOT NULL で作ってしまえと言いたい。
その方が何かとトラブルが少ないし、コーディングも楽だ。
テキストフィールド？ 空文字でも入れとけ。 数値？ 0が初期値だ。それで都合がわるけりゃ、
-999999999 が初期値だ、文句あるか、ってな感じで。
0611nobodyさん2008/11/15(土) 22:00:11ID:???
>>608
MySQLならenum型でnullを使う分にはNULLでインデックスされると思うよ
他のDBでは知らない
0612nobodyさん2008/11/15(土) 23:07:45ID:???
>>607
そう、カラム名。
id, created(datetime), updated(datetime), deleted(datime)を標準的に使用。

あるいは、statusとしてa)Activei)/Inactive、h)Hidden, b)Obsoleted D)deleted
とか詳しい状態が必要な時に使うとか。
06135952008/11/15(土) 23:12:27ID:???
いろいろやり方あるんすね。すごい勉強になった。
皆さん有り難うございます。
■ このスレッドは過去ログ倉庫に格納されています