【PHP】フレームワークについて語るスレ10【総合】
|
|
|
過去スレ
【PHP】フレームワークについて語るスレ9【総合】
http://pc11.2ch.net/test/read.cgi/php/1197383840/
【PHP】フレームワークについて語るスレ8【総合】
http://pc11.2ch.net/test/read.cgi/php/1192604501/
【PHP】フレームワークについて語るスレ7【総合】
http://pc11.2ch.net/test/read.cgi/php/1181350116/
【PHP】フレームワークについて語るスレ6【総合】
http://pc11.2ch.net/test/read.cgi/php/1171896620/
[PHP]フレームワークについて語るｽﾚ5[総合]
http://pc10.2ch.net/test/read.cgi/php/1159579507/
[PHP]フレームワークについて語るｽﾚ4[総合]
http://pc8.2ch.net/test/read.cgi/php/1151706907/
[PHP]フレームワークについて語るｽﾚ３[総合]
http://pc8.2ch.net/test/read.cgi/php/1145971945/
[PHP]フレームワークについて語るｽﾚ２[総合]
http://pc8.2ch.net/test/read.cgi/php/1135847024/
【PHP】フレームワークについて語るスレ【総合】
http://pc8.2ch.net/test/read.cgi/php/1123608068/
【PHP】フレームワークについて語るスレ9【総合】
http://pc11.2ch.net/test/read.cgi/php/1197383840/
【PHP】フレームワークについて語るスレ8【総合】
http://pc11.2ch.net/test/read.cgi/php/1192604501/
【PHP】フレームワークについて語るスレ7【総合】
http://pc11.2ch.net/test/read.cgi/php/1181350116/
【PHP】フレームワークについて語るスレ6【総合】
http://pc11.2ch.net/test/read.cgi/php/1171896620/
[PHP]フレームワークについて語るｽﾚ5[総合]
http://pc10.2ch.net/test/read.cgi/php/1159579507/
[PHP]フレームワークについて語るｽﾚ4[総合]
http://pc8.2ch.net/test/read.cgi/php/1151706907/
[PHP]フレームワークについて語るｽﾚ３[総合]
http://pc8.2ch.net/test/read.cgi/php/1145971945/
[PHP]フレームワークについて語るｽﾚ２[総合]
http://pc8.2ch.net/test/read.cgi/php/1135847024/
【PHP】フレームワークについて語るスレ【総合】
http://pc8.2ch.net/test/read.cgi/php/1123608068/
【洋モノ】
symfony
http://www.symfony-project.com/
code igniter
http://codeigniter.com/
Zend Framework
http://framework.zend.com/manual/ja/index.html
CakePHP
http://www.cakephp.org/
【和モノ】
ちいたん
http://php.cheetan.net/
Ethna
http://ethna.jp/
guesswork
http://classic.guesswork.jp/
maple
http://kunit.jp/maple/
symfony
http://www.symfony-project.com/
code igniter
http://codeigniter.com/
Zend Framework
http://framework.zend.com/manual/ja/index.html
CakePHP
http://www.cakephp.org/
【和モノ】
ちいたん
http://php.cheetan.net/
Ethna
http://ethna.jp/
guesswork
http://classic.guesswork.jp/
maple
http://kunit.jp/maple/
>>1
乙です
乙です
最近期待しているのを２つ追加
Piece Framework
http://piece-framework.com/
rhaco
http://www.rhaco.org/
でも、正直おなかいっぱいというかんじ。
3大フレームワーク(Cake, Symfony, ZF)+1(CodeIgniter)で十分という気も
Piece Framework
http://piece-framework.com/
rhaco
http://www.rhaco.org/
でも、正直おなかいっぱいというかんじ。
3大フレームワーク(Cake, Symfony, ZF)+1(CodeIgniter)で十分という気も
3大フレームワークのサブセット版がほしい。
ごてごてとしたフレームワークをごそっと入れるんじゃなく、
ファイル一枚か少数で完結したフレームワーク・・・
だが、命令などに互換性があり、必要になった時点で、
フルセットのフレームワークに容易に入れ替え可能。
ごてごてとしたフレームワークをごそっと入れるんじゃなく、
ファイル一枚か少数で完結したフレームワーク・・・
だが、命令などに互換性があり、必要になった時点で、
フルセットのフレームワークに容易に入れ替え可能。
どこで聞くべきか迷ったんですけど、ここにします。
今SimpleTestを使ってテストしています。
SimpleTestにはWebTestCaseといってあたかもブラウザで
アクセスしたかのように、ウェブページに対してhttpプロトコルで
接続・・・その結果をテストということができるのですが、
このメール版はないでしょうか？
つまり、自分のPHPアプリからメール送信・・・そしたら（仮想の）テスト用メールサーバーにメールがたまり、
テストコードから、メールサーバーに来たメールを見てアサーションや、そのメールに書かれているリンクを
クリックなどしてテストを続行という、一連の処理にメールが入る場合のテストの自動化をしたいのです。
なにか良いライブラリ、良い手は無いでしょうか？
今SimpleTestを使ってテストしています。
SimpleTestにはWebTestCaseといってあたかもブラウザで
アクセスしたかのように、ウェブページに対してhttpプロトコルで
接続・・・その結果をテストということができるのですが、
このメール版はないでしょうか？
つまり、自分のPHPアプリからメール送信・・・そしたら（仮想の）テスト用メールサーバーにメールがたまり、
テストコードから、メールサーバーに来たメールを見てアサーションや、そのメールに書かれているリンクを
クリックなどしてテストを続行という、一連の処理にメールが入る場合のテストの自動化をしたいのです。
なにか良いライブラリ、良い手は無いでしょうか？
あー、そういう手作業テストって面倒だよな
なんか良い手あるなら俺も知りたい
なんか良い手あるなら俺も知りたい
SimpleMailを見つけました。
SimpleMail http://www.curioussymbols.com/simplemail/
ちなみに、Windowsで使うときの注意点です。
SimpleMailがSMTPサーバーとしてFakeMailを使用するので別途インストールする必要があります。
perl版は必要なライブラリが入れづらいようなのでpython版を使いました。
python版はWindows版があるのでインストーラーで簡単に入れられます。
あらかじめpython自体も入れておく必要があります。
http://www.lastcraft.com/fakemail.php ここに情報が少し書いてあります。
fakemailerを起動するときは、インストールしたフォルダで、
> fakemail.py --host=localhost --port=10025 --path=.
でいいのですが、そのままではエラーになりました。
エラーメッセージを見ると、「signal.SIGHUP」が定義されていないそうです。
どうせテストだし、あまり重要なものではなさそうなので、削除しました。
> for sig in (signal.SIGINT, signal.SIGTERM, signal.SIGHUP):
↑fakemail.pyの中の「, signal.SIGHUP」を消す。
SimpleMailにはstart()メソッドでfakemailを実行する機能があるのですが、
Linux/Unix用のパスで、perl版のコードの上、fakemail.pyをバックグラウンドで
実行しようとすると、forkなんたらのエラーが発生するのであきらめます。
start()、stop()メソッドを呼ばなくても使えます。
その代わり、テスト開始前にfakemailerを起動しておきましょう。
ちなみに、Windowsで使うときの注意点です。
SimpleMailがSMTPサーバーとしてFakeMailを使用するので別途インストールする必要があります。
perl版は必要なライブラリが入れづらいようなのでpython版を使いました。
python版はWindows版があるのでインストーラーで簡単に入れられます。
あらかじめpython自体も入れておく必要があります。
http://www.lastcraft.com/fakemail.php ここに情報が少し書いてあります。
fakemailerを起動するときは、インストールしたフォルダで、
> fakemail.py --host=localhost --port=10025 --path=.
でいいのですが、そのままではエラーになりました。
エラーメッセージを見ると、「signal.SIGHUP」が定義されていないそうです。
どうせテストだし、あまり重要なものではなさそうなので、削除しました。
> for sig in (signal.SIGINT, signal.SIGTERM, signal.SIGHUP):
↑fakemail.pyの中の「, signal.SIGHUP」を消す。
SimpleMailにはstart()メソッドでfakemailを実行する機能があるのですが、
Linux/Unix用のパスで、perl版のコードの上、fakemail.pyをバックグラウンドで
実行しようとすると、forkなんたらのエラーが発生するのであきらめます。
start()、stop()メソッドを呼ばなくても使えます。
その代わり、テスト開始前にfakemailerを起動しておきましょう。
PHPはモジュールたっぷり入ってるxamppに
perlはperl.exeしか入ってなくて子飼弾脂肪ｗｗｗ
perlはperl.exeしか入ってなくて子飼弾脂肪ｗｗｗ
PHPってフレームワーク地獄ですよねｗ
どういう意味？
フレームワークありすぎって意味？
フレームワークありすぎって意味？
ただ、PHPは良くも悪くも言語仕様が緩いので、
デファクト・スタンダードになったフレームワークは標準で取り込んで、
言語仕様上の優遇を受けるんじゃないか、と思ってる
そうなったらこのフレームワーク地獄も終わるんじゃないの
政治的にZend Frameworkになるのかなと思ってるけど
デファクト・スタンダードになったフレームワークは標準で取り込んで、
言語仕様上の優遇を受けるんじゃないか、と思ってる
そうなったらこのフレームワーク地獄も終わるんじゃないの
政治的にZend Frameworkになるのかなと思ってるけど
フレームワーク自体にはそれぞれコンセプトがあるんだから、
一つに落ち着くことはないと思うけどね。
ちょうど.comみたいに、たくさん出てきて、いろいろ淘汰されて、
最終的に数個残るみたいになるんじゃないかなぁ。
ま、資金力や人気もあるからZend Frameworkは残りそうだけど
一つに落ち着くことはないと思うけどね。
ちょうど.comみたいに、たくさん出てきて、いろいろ淘汰されて、
最終的に数個残るみたいになるんじゃないかなぁ。
ま、資金力や人気もあるからZend Frameworkは残りそうだけど
PHPのフレームワークは、誰でも作れるところが、
利点でもあり、欠点でもあるんだろうね。
ASP.NETのように誰も参入できないようにしてしまうと
選択肢が無い分すっきりとするが、その設計手法から
洩れてしまうと、言語など根本的な部分から変更せざるを
得なくなってしまう。
利点でもあり、欠点でもあるんだろうね。
ASP.NETのように誰も参入できないようにしてしまうと
選択肢が無い分すっきりとするが、その設計手法から
洩れてしまうと、言語など根本的な部分から変更せざるを
得なくなってしまう。
http://slashdot.jp/security/article.pl?sid=08/02/11/0012230
linuxカーネルに穴があってPHPもちろん脂肪ｗｗｗ
linuxカーネルに穴があってPHPもちろん脂肪ｗｗｗ
その理屈だとRuby他も脂肪じゃんｗ
Piece以外に継続を利用したWebフローエンジンを持っているPHPフレームワークってある？
JavaだとSpring Web Flowに近いと思うけど、LightweightだとほとんどがFront Controllerだから、
なかなか野心的でないかと思っている。
JavaだとSpring Web Flowに近いと思うけど、LightweightだとほとんどがFront Controllerだから、
なかなか野心的でないかと思っている。
Pieceはやってる人を応援したくなる
ただ、Piece_ORMのinsertのテーブルデフォルト値の扱いが未だに納得がいかん。
もう少し説明をしてくれればな・・・
ただ、Piece_ORMのinsertのテーブルデフォルト値の扱いが未だに納得がいかん。
もう少し説明をしてくれればな・・・
WebFlowに近いというか、Pieceは元々がWebFlowとJBoss Seamを参考にしてるからな。当然ある程度は似る。
やっぱそうなんだ。
それぞれのモジュールが個別に使えるようになっているみたいだし、
そのうち既存のアプリにPiece_Flowを組み込んでみたいと思ってるんだよね。
（今はORMとRightはドキュメントがあるけど、Flowの方はちょっと…なので）
それぞれのモジュールが個別に使えるようになっているみたいだし、
そのうち既存のアプリにPiece_Flowを組み込んでみたいと思ってるんだよね。
（今はORMとRightはドキュメントがあるけど、Flowの方はちょっと…なので）
今から始めるとするとどのフレームワークがおすすめかな？
少しだけcakePHPをかじってみたけど、まだ日本語のドキュメントが十分とは言い難いし。
少しだけcakePHPをかじってみたけど、まだ日本語のドキュメントが十分とは言い難いし。
>>26
理由をどうぞ
理由をどうぞ
CIは確かにいいけどこれ使うならCakeの方が多少デブになるけどベターかな。
多分組み方にコダワルやつはZendを使って苦労したがるのだろう
多分組み方にコダワルやつはZendを使って苦労したがるのだろう
>>28
Zendが本命とかよく本とかには書かれてますが、どういうところが駄目なんですか？
Zendが本命とかよく本とかには書かれてますが、どういうところが駄目なんですか？
設計として疎結合を重視しすぎていて、
そのせいで痒い所に手が届かない部分が、
フル装備のsymfonyやcakeに比べると物足りなく思える。
ZFは言ってみれば、
軽量な骨組みに綺麗なクラスライブラリを置いてある感じ。
というのがZFについて人から聞いた話。
そのせいで痒い所に手が届かない部分が、
フル装備のsymfonyやcakeに比べると物足りなく思える。
ZFは言ってみれば、
軽量な骨組みに綺麗なクラスライブラリを置いてある感じ。
というのがZFについて人から聞いた話。
symfonyやcakeで届く痒いところってどんなところ？
bakeで焼いてる(笑)ヤツらは、便利と思ってるのかな。
bakeで焼いたら焦げました('A`)
>>34
baka
baka
mb_send_mailまわりってダメダメだな・・・
mb_encode_mimeheaderはmb_internal_encodingが必要って見たけど
PHP4の稼働してるバージョンじゃそれでもだめだったし
自分でヘッダ組み立ててmailで送るしかないじゃん・・・('A`)
mb_encode_mimeheaderはmb_internal_encodingが必要って見たけど
PHP4の稼働してるバージョンじゃそれでもだめだったし
自分でヘッダ組み立ててmailで送るしかないじゃん・・・('A`)
mb_send_mail()で使えているけど。
ただ、引数指定にはいろいろノウハウがあったような…
単純にテキストメール送るだけなら、楽なことは楽。
ただ、引数指定にはいろいろノウハウがあったような…
単純にテキストメール送るだけなら、楽なことは楽。
つーか、ここはフレームワークスレじゃん。
フレームワークにメールモジュールないの？
フレームワークにメールモジュールないの？
あるけどしょっちゅう化ける
特に洋モノは。
南蛮人に極東のマイナー言語のサポートなんか期待できないのは
当然っちゃ当然だが
特に洋モノは。
南蛮人に極東のマイナー言語のサポートなんか期待できないのは
当然っちゃ当然だが
まあいい加減ISO-2022-JP（だったっけ？）に変換して送る様なローカル慣習も無くなってくれてもいいんだが。
UTF-8通らないサーバとかメールクライアントとかはもう無視する方向で行きたいな。
（どのみちそっちの方向にしか進まないんだから）
UTF-8通らないサーバとかメールクライアントとかはもう無視する方向で行きたいな。
（どのみちそっちの方向にしか進まないんだから）
70文字で区切るとかいう仕様も今の時代意味あんの？
そのせいでmb_encode_mimeheaderも腐ってるし
いつの時代の仕様なんだっての
そのせいでmb_encode_mimeheaderも腐ってるし
いつの時代の仕様なんだっての
ってか実際的に考えて、70文字区切りなんていらないんじゃないか？
mail関数のサブジェクトの説明には「改行を含んではいけません。」って書いてるし、
実際サブジェクトを適当な文字数で区切ってbase64エンコードした場合と
まったく区切らずにbase64エンコードした場合の結果が
gmail,shuriken,docomo(foma)で同じだったし
恐らく今のクライアントだったらほとんど問題ないだろう。
mb_encode_mimeheader的な区切り処理は
むしろ何かと害があるんじゃないか。
mail関数のサブジェクトの説明には「改行を含んではいけません。」って書いてるし、
実際サブジェクトを適当な文字数で区切ってbase64エンコードした場合と
まったく区切らずにbase64エンコードした場合の結果が
gmail,shuriken,docomo(foma)で同じだったし
恐らく今のクライアントだったらほとんど問題ないだろう。
mb_encode_mimeheader的な区切り処理は
むしろ何かと害があるんじゃないか。
そういう風に考えていくと
mb_send_mailの存在意義が分からないな。
出来ないことを出来ると見せかけるという意味で
むしろ悪影響の方が大きい
前もってmb_internal_encodingを設定しろとか
バッドノウハウが広まってること自体がおかしいだろ
常識で考えて
mb_send_mailの存在意義が分からないな。
出来ないことを出来ると見せかけるという意味で
むしろ悪影響の方が大きい
前もってmb_internal_encodingを設定しろとか
バッドノウハウが広まってること自体がおかしいだろ
常識で考えて
MIMEの仕様に文句があるならRFCを修正してくれ。
mb_send_mail関数があるおかげで、PHPerにメール(というかMIME)関連の知識が付かない、という弊害もある。
・・・仕様が半端だしあちこちで不具合が出るから結果的にはある程度知らなきゃいけないんだがｗ
本当に半端な関数で、こんなもの実装するくらいならPEARででもまともなMailクラスを育てればいいのに。
・・・仕様が半端だしあちこちで不具合が出るから結果的にはある程度知らなきゃいけないんだがｗ
本当に半端な関数で、こんなもの実装するくらいならPEARででもまともなMailクラスを育てればいいのに。
俺もmb_send_mailの存在意義がわからん。
mail関数じゃダメなのか？ というか何が問題でmb_send_mailが出来たんだ？
調べろと？ そうですなｗ
とりあえず、subjectはISO-2022-JPにしたあとbase64エンコードしている。
本文はISO-2022-JPにしている。
これでmail関数使っているが、なにか罠があるのか？
mail関数じゃダメなのか？ というか何が問題でmb_send_mailが出来たんだ？
調べろと？ そうですなｗ
とりあえず、subjectはISO-2022-JPにしたあとbase64エンコードしている。
本文はISO-2022-JPにしている。
これでmail関数使っているが、なにか罠があるのか？
>>38
> つーか、ここはフレームワークスレじゃん。
> フレームワークにメールモジュールないの？
じゃあ、フレームワークに絡める。
CakePHP 1.2にはメールモジュールEmailComponentがあるのだが、
このモジュール。mb_send_mailではなく、mail関数を使っている。
当然日本語とか考慮されていない。
charsetというプロパティはあるにはあるのだが、これだけじゃうまくいかない。
なので、EmailComponentを継承して__encode、__renderTemplateメソッドを
オーバーライドしてエンコードおよび、半角カナなどを変換しているよ。
> つーか、ここはフレームワークスレじゃん。
> フレームワークにメールモジュールないの？
じゃあ、フレームワークに絡める。
CakePHP 1.2にはメールモジュールEmailComponentがあるのだが、
このモジュール。mb_send_mailではなく、mail関数を使っている。
当然日本語とか考慮されていない。
charsetというプロパティはあるにはあるのだが、これだけじゃうまくいかない。
なので、EmailComponentを継承して__encode、__renderTemplateメソッドを
オーバーライドしてエンコードおよび、半角カナなどを変換しているよ。
確かにメール関連知識付くの遅かったな
mb_send_mailの挙動が変だから
ずっとメールに対して奇々怪々なイメージがあった
やってみればたいして難しくないんだが。
mailを直接触る方が健康的だな
mb_send_mailの挙動が変だから
ずっとメールに対して奇々怪々なイメージがあった
やってみればたいして難しくないんだが。
mailを直接触る方が健康的だな
PHPのCLIって起動やたら遅くね？
CLIが速いスクリプト言語って何？
CLIが速いスクリプト言語って何？
bash
まあ、PHPはウェブ専用だよ。
>>49
マジレスすると Perl
Ruby は普通
Python はかなり遅い
起動の早さはバイナリサイズによるところも大きくて、awkやluaのようにバイナリが小さいものだとPerlよりも起動が早い。
マジレスすると Perl
Ruby は普通
Python はかなり遅い
起動の早さはバイナリサイズによるところも大きくて、awkやluaのようにバイナリが小さいものだとPerlよりも起動が早い。
じゃあPerlにしようと思って
Perlの本買ってきた
Perlは糞記号が多いな
$にいろんな意味持たせすぎ。
こういうタイピング時点での節約がなんか前時代的
CLIのスクリプトってフレームワークの階層のどこに置けばいいんだろ？
Perlの本買ってきた
Perlは糞記号が多いな
$にいろんな意味持たせすぎ。
こういうタイピング時点での節約がなんか前時代的
CLIのスクリプトってフレームワークの階層のどこに置けばいいんだろ？
54 ：nobodyさん：2008/02/18(月) 20:41:46 ID:7b3e8wHY
CLIなら別にPHPとかPerlとかRubyとかPythonとかに限らなくてもいいんじゃね？
もうおそいか
もうおそいか
>52も罪深いが、>53は単純すぎる。
実際PHPもPythonもCLI重いじゃん
shなんて単純なものしか書きたくないし
そうなるとPerlは充分妥当な線だろ。
スクリプト言語の中ではPHPに一番近いし。
shなんて単純なものしか書きたくないし
そうなるとPerlは充分妥当な線だろ。
スクリプト言語の中ではPHPに一番近いし。
まあPHPの既存のクラスを使うようなもので
速度がいらない処理（scaffolding等）はPHPで全然問題ないけどね
速度がいらない処理（scaffolding等）はPHPで全然問題ないけどね
http://www.timestretch.com/FractalBenchmark.html
ここの結果だとPythonの方が速いけど。
まあ、当たり前だけど目的による。
なんで盲目的にPerlが速いといえるのかがわからん。
ここの結果だとPythonの方が速いけど。
まあ、当たり前だけど目的による。
なんで盲目的にPerlが速いといえるのかがわからん。
Perlでも例えば
use Encode;
use CGI;
use Data::Dumper;
とかやると結構違うんじゃね？
結局CLIの起動速度とか、言語の選択にそれほど影響する場面ってあるか？
まあRubyは結構がつんと引っかかるのを感じることはあるけど
use Encode;
use CGI;
use Data::Dumper;
とかやると結構違うんじゃね？
結局CLIの起動速度とか、言語の選択にそれほど影響する場面ってあるか？
まあRubyは結構がつんと引っかかるのを感じることはあるけど
チープなWebアプリケーションを作る場合には、PHPは他を圧倒するな。
extで話が済んでるうちは、荒っぽくいえばCのWebフレームワークなわけだし。
rubyとか今やRailsないとWebアプリ作れねーんじゃねーかと。
extで話が済んでるうちは、荒っぽくいえばCのWebフレームワークなわけだし。
rubyとか今やRailsないとWebアプリ作れねーんじゃねーかと。
ruby作った松本も神だけど
rails作った奴も神だな
神と神が合体して偉大なるソフト
rails作った奴も神だな
神と神が合体して偉大なるソフト
多神教なんですね
ワラタｗ
うーん、どれも似たり寄ったりなのかな？
じゃあ、質問を変えてajax（というより、DHMLメイン？）前提ではどれが作りやすいかな？
たとえば、xhrを用いた非同期通信をサポートする上での仕様が覚えやすいとか、
prototype.js系に限らずほかのJSライブラリ（dojo系やYahooUI系）でも利用可能な仕様が公式側で用意されているとか。
じゃあ、質問を変えてajax（というより、DHMLメイン？）前提ではどれが作りやすいかな？
たとえば、xhrを用いた非同期通信をサポートする上での仕様が覚えやすいとか、
prototype.js系に限らずほかのJSライブラリ（dojo系やYahooUI系）でも利用可能な仕様が公式側で用意されているとか。
あ、それ俺も知りたい。
別途jQuery叩いてて不満ないのでフレームワーク側のAJAXサポートとか評価したことない。もちろん手間はある
識者のお勧め希望
別途jQuery叩いてて不満ないのでフレームワーク側のAJAXサポートとか評価したことない。もちろん手間はある
識者のお勧め希望
外国の技術系サイト見たら
システム周りのちょっとした作業するのに使われてるのRubyばっかだな
逆にPythonはあんまり見ない
Ruby知らないとイモって言われる時代もすぐそこか・・・(´・ω・`)
システム周りのちょっとした作業するのに使われてるのRubyばっかだな
逆にPythonはあんまり見ない
Ruby知らないとイモって言われる時代もすぐそこか・・・(´・ω・`)
>>66
なんか前スレのJaxerを彷彿とさせる流れだ
サーバサイドとフロントエンドをそれほど上手に連携させていて、しかも汎用的な
フレームワークとかまだそんなに無い雰囲気だけど、あるなら俺も知りたい
強いて言うなら、RubyはJavaScriptと近い記述も可能な印象があるので、スクリプトを
組む人間の脳みそ的に楽かも知れない。
オブジェクトやブロックの扱いとか、記述の柔らかさというかその辺で、少なくとも、PHP
よりは感覚が近いような
なんだこの印象論はと書いてて自分で思った。
なんか前スレのJaxerを彷彿とさせる流れだ
サーバサイドとフロントエンドをそれほど上手に連携させていて、しかも汎用的な
フレームワークとかまだそんなに無い雰囲気だけど、あるなら俺も知りたい
強いて言うなら、RubyはJavaScriptと近い記述も可能な印象があるので、スクリプトを
組む人間の脳みそ的に楽かも知れない。
オブジェクトやブロックの扱いとか、記述の柔らかさというかその辺で、少なくとも、PHP
よりは感覚が近いような
なんだこの印象論はと書いてて自分で思った。
記述で言えば{}や;やら表面上はPHPの方が似てるんじゃね？w
まあ確かになんでもかんでもオブジェクトでござい、てあたりは似てるね
まあ確かになんでもかんでもオブジェクトでござい、てあたりは似てるね
ruby on railsは神と神のフュージョン
いいかえればキリストとアッラーが融合合体した「究極生命体」
いいかえればキリストとアッラーが融合合体した「究極生命体」
キリストは神じゃないよ(´・ω・`)
神と神が合体するとフレームワークが出来上がるが
バカとバカが合体すると子供が生まれる
バカとバカが合体すると子供が生まれる
>68
GNOME周りの細かいスクリプトってPythonばっかでしょ？
海外でRuby使っている人ってRoRの流れの人じゃないかな
正直なところ、RoRは偉大だと思うけどRubyはそうは思わない
「RoRのプログラマに選ばれた言語」として評価はするけど
GNOME周りの細かいスクリプトってPythonばっかでしょ？
海外でRuby使っている人ってRoRの流れの人じゃないかな
正直なところ、RoRは偉大だと思うけどRubyはそうは思わない
「RoRのプログラマに選ばれた言語」として評価はするけど
BlenderのPython
Google SketchUpのRuby
PHPをスクリプト言語として搭載した色物3DCGソフトがあったら色んな意味で面白そうだ
Google SketchUpのRuby
PHPをスクリプト言語として搭載した色物3DCGソフトがあったら色んな意味で面白そうだ
将来的にRubyが来るかPhthonが来るかPerlがしぶとく生き残るか。
ずぅっと混戦状態な気もするけど。
案外Webだけに的を絞ったPHPが一番長生きだったりしてね。
でも10年後、PHPの役目が今のCOBOL的な負の遺産管理とか、そういう生き残りかたはやだな。
ずぅっと混戦状態な気もするけど。
案外Webだけに的を絞ったPHPが一番長生きだったりしてね。
でも10年後、PHPの役目が今のCOBOL的な負の遺産管理とか、そういう生き残りかたはやだな。
結局phpもjavascriptやperlみたいに上級者と初心者が乖離して
その間を埋める新しい言語が出てくるんじゃないの
一方extract($_POST);的なコードはいつまでも再生産されるっていう
その間を埋める新しい言語が出てくるんじゃないの
一方extract($_POST);的なコードはいつまでも再生産されるっていう
PHPからPython使えてRuby脂肪ｗｗｗ
http://pecl.php.net/package/python/download/0.8.0/
http://pecl.php.net/package/python/download/0.8.0/
マッツがむかつくから今までRubyしなかったけど
外人が大量にやってるからRuby始めました
YAMLが簡単に扱えてｲｲ(･∀･)！
外人が大量にやってるからRuby始めました
YAMLが簡単に扱えてｲｲ(･∀･)！
>>81
これよりも簡単に扱えるん？
http://itpro.nikkeibp.co.jp/article/COLUMN/20070507/270080/
PHP版がこのコード↑として、Ruby版はどういうコードなん？
これよりも簡単に扱えるん？
http://itpro.nikkeibp.co.jp/article/COLUMN/20070507/270080/
PHP版がこのコード↑として、Ruby版はどういうコードなん？
require 'yaml'
file_dir = './hoge.conf'
str = open(file_dir).read()
data = YAML.load(str)
こんなん
もっとキレイに書けるのか知らないけど。
コード自体はたいして変わらないか。
でも変なパースされてハマったことあるからspycにはいい印象ないな
file_dir = './hoge.conf'
str = open(file_dir).read()
data = YAML.load(str)
こんなん
もっとキレイに書けるのか知らないけど。
コード自体はたいして変わらないか。
でも変なパースされてハマったことあるからspycにはいい印象ないな
ってか、やっぱり標準で装備されてる安心感が大きい
じゃあ、YAMLが簡単に扱えるじゃなくて、
YAMLライブラリが標準添付されているって言うべきだな。
YAMLライブラリが標準添付されているって言うべきだな。
ある文に後から関数的な処理を加えたい時、PHPだと
[追加部分前半](元の文)[追加部分後半]
って分かれるのが普通だけど
Rubyだと
（元の文）[追加部分]
で済むのが気持ちええ～
多重に追加する時も
（元の文）[追加][追加][追加]
って書いていけるのがオルガスムス(´ρ｀)
[追加部分前半](元の文)[追加部分後半]
って分かれるのが普通だけど
Rubyだと
（元の文）[追加部分]
で済むのが気持ちええ～
多重に追加する時も
（元の文）[追加][追加][追加]
って書いていけるのがオルガスムス(´ρ｀)
ここRubyスレじゃないんだ。わかってる？ｗ
関数塗れな処理で、カッコでgdるかドットシンタクスで繋げられるかって事か
地味だがjQueryハマってるので気持ちは判る
しかしスレ違いではないか
地味だがjQueryハマってるので気持ちは判る
しかしスレ違いではないか
すぐスクリプト言語についてぬるく語るスレになるなここはｗ
よっぽどPHPのフレームワークにネタがないのか
よっぽどPHPのフレームワークにネタがないのか
他言語も含めてフレームワークでネタが続いているの
どこにあるんだよｗ
どこにあるんだよｗ
>>59
>http://www.timestretch.com/FractalBenchmark.html
>
>ここの結果だとPythonの方が速いけど。
>まあ、当たり前だけど目的による。
>なんで盲目的にPerlが速いといえるのかがわからん。
>>49と>>52よく読め。起動時間の話をしてるのに違うベンチマーク結果だしてどうする。
>>82
SpycはまともにYAML扱えないから止めた方がいい。いくらなんでも機能低すぎ。バグ大杉。しかもクソ遅い。
>http://www.timestretch.com/FractalBenchmark.html
>
>ここの結果だとPythonの方が速いけど。
>まあ、当たり前だけど目的による。
>なんで盲目的にPerlが速いといえるのかがわからん。
>>49と>>52よく読め。起動時間の話をしてるのに違うベンチマーク結果だしてどうする。
>>82
SpycはまともにYAML扱えないから止めた方がいい。いくらなんでも機能低すぎ。バグ大杉。しかもクソ遅い。
PHPもYAMLパーサ標準装備されるんじゃなかったっけ？
まじで？早くしてほしいね
Symfonyでふんだんに使われているSpycが
そんなに悪いとは思えないが？
そんなに悪いとは思えないが？
Pieceでも前提にしてるね Spyc
いままで parse_ini_file も有効利用出来なかったPHPerがYAMLってだけで何でそんなに騒ぐのか
spycは単純な設定ファイルを読む程度なら充分だけど、
ヘビーに使おうと思うとあきらかに役者不足だよ。
ヘビーに使おうと思うとあきらかに役者不足だよ。
取り立てて良いわけでもないが、まともにyaml扱えないなんて印象はないけどな
だいたいyamlなんて設定ファイルで使うケースがほとんだと思うが
遅いって言っても実環境で使うなら普通キャッシュするし
機能低いとかヘビーに使うとか一体どういう局面で困ってるの？
だいたいyamlなんて設定ファイルで使うケースがほとんだと思うが
遅いって言っても実環境で使うなら普通キャッシュするし
機能低いとかヘビーに使うとか一体どういう局面で困ってるの？
YAMLのパース処理なんて単純だし固定的だからエクステンションにするのがベストだろうな
symfonyってsyckとかいうの使うようになったんじゃなかったけ？
symfonyってsyckとかいうの使うようになったんじゃなかったけ？
>91
いや、起動が遅くてもインクルードで遅れたら意味ないでしょ？
だから、「目的による」と書いてあるの。それ以上は自明だと思ったから説明しなかっただけで。
それについては、Perlでもインクルードするモジュールによると他の人も書いてるでしょ。
この人は意図をよく理解してる。あなたはもう少しよく考えましょう。
いや、起動が遅くてもインクルードで遅れたら意味ないでしょ？
だから、「目的による」と書いてあるの。それ以上は自明だと思ったから説明しなかっただけで。
それについては、Perlでもインクルードするモジュールによると他の人も書いてるでしょ。
この人は意図をよく理解してる。あなたはもう少しよく考えましょう。
web+db press ちょうどyamlについての特集してるな
web+db pressの個人的タイムリー感は異常
web+db pressの個人的タイムリー感は異常
「起動が遅くてもインクルードで遅れたら」ってどゆこと？
「起動が速くてもインクルードで遅れたら」のtypo?
「起動が速くてもインクルードで遅れたら」のtypo?
>>101
>いや、起動が遅くてもインクルードで遅れたら意味ないでしょ？
>だから、「目的による」と書いてあるの。それ以上は自明だと思ったから説明しなかっただけで。
起動の速さを話題にしているんだから、それ以外の要素を持ち出すならそれを説明すべきだろ。
>>49,52,59を順に読んでみろ。どこにインクルードやrequireの話がでている?
「目的による」のひとことで分かるわけがない。おまえの脳内で勝手に補完するな。
>それについては、Perlでもインクルードするモジュールによると他の人も書いてるでしょ。
それは>>60からだろ。60はちゃんと説明しているが、59まではそんな話でてきてない。時系列を無視して語るな。
>この人は意図をよく理解してる。あなたはもう少しよく考えましょう。
おまえこそもう少しよく読め。
>いや、起動が遅くてもインクルードで遅れたら意味ないでしょ？
>だから、「目的による」と書いてあるの。それ以上は自明だと思ったから説明しなかっただけで。
起動の速さを話題にしているんだから、それ以外の要素を持ち出すならそれを説明すべきだろ。
>>49,52,59を順に読んでみろ。どこにインクルードやrequireの話がでている?
「目的による」のひとことで分かるわけがない。おまえの脳内で勝手に補完するな。
>それについては、Perlでもインクルードするモジュールによると他の人も書いてるでしょ。
それは>>60からだろ。60はちゃんと説明しているが、59まではそんな話でてきてない。時系列を無視して語るな。
>この人は意図をよく理解してる。あなたはもう少しよく考えましょう。
おまえこそもう少しよく読め。
web+db press読んだ
YAMLって結構高機能なんだな～
YAMLって結構高機能なんだな～
ワロタｗ 高機能の内容も言わず、高機能とか言っても信用されないｗ
信用って何だよ
仕様を見ればわかるがな
仕様を見ればわかるがな
最も使われているYAMLパーサのSyckはRuby出身
Rubyの手のひらの上で暴れてるだけのPHP乙
Rubyの手のひらの上で暴れてるだけのPHP乙
最も使われてるの？
PHPのプロダクションてほかの言語からの輸入物多いからいまさらそんなん言われても
PHPのプロダクションてほかの言語からの輸入物多いからいまさらそんなん言われても
PHP＝ポリシーのないパクリパッチワーク言語でおk？
>>110
そう書くと、それはそれでとても魅力的な言語に見えます。
そう書くと、それはそれでとても魅力的な言語に見えます。
PHPにいいとこどりされて他の言語脂肪ｗ
最近、Ruby本多くなったけど誰がRuby使ってんの？
異教徒
115 ：nobodyさん：2008/02/26(火) 00:07:04 ID:/Sycx4p+
言語崇拝者でしょ。
なぜ島根県が出て来ないのだ
おまいらＰＨＰ，ｐＨＰていうどやなあ
今までＰＨＰでいくら稼いだんや？
今までＰＨＰでいくら稼いだんや？
松本は島根県民としては誇りだ
しかしネゴシックスは県民の恥さらし
しかしネゴシックスは県民の恥さらし
世界に通用する言語開発した唯一の日本人が
島根県民だから同県民として素直にうれしいし
松本も地元に愛着を持ってるらしく
Ｒｕｂｙ検定やら松江を発信基地として活動してくれる
島根県民だから同県民として素直にうれしいし
松本も地元に愛着を持ってるらしく
Ｒｕｂｙ検定やら松江を発信基地として活動してくれる
島根県民は案外、人口の割りに頭のいい奴は多いぞ
頭は良いが、常識はないってパターンか
いい加減書き込むときはスレタイぐらい読めよ
いい加減書き込むときはスレタイぐらい読めよ
Rails使いたくてこの1ヶ月Ruby勉強してた
確かに書きやすいしPHPに比べるときれい
でも肝心のRails環境があまり無い
実用面ではPHPがNo.1だと思います
それで質問ですが、最もRailライクなフレームワークはSymfonyでよろしいでしょうか？
この1ヶ月の勉強の知識でそのままPHPフレームワークに移行したいのです
確かに書きやすいしPHPに比べるときれい
でも肝心のRails環境があまり無い
実用面ではPHPがNo.1だと思います
それで質問ですが、最もRailライクなフレームワークはSymfonyでよろしいでしょうか？
この1ヶ月の勉強の知識でそのままPHPフレームワークに移行したいのです
>>122
>それで質問ですが、最もRailライクなフレームワークはSymfonyでよろしいでしょうか？
YES
>この1ヶ月の勉強の知識でそのままPHPフレームワークに移行したいのです
その判断は誤りだといっておこう。
PHPはRubyと比べてできないことが多いから、PHPでRailsを真似てもたいしてうまくいかない。
>それで質問ですが、最もRailライクなフレームワークはSymfonyでよろしいでしょうか？
YES
>この1ヶ月の勉強の知識でそのままPHPフレームワークに移行したいのです
その判断は誤りだといっておこう。
PHPはRubyと比べてできないことが多いから、PHPでRailsを真似てもたいしてうまくいかない。
>>123
具体的に何が出来ないんですか？
具体的に何が出来ないんですか？
>>124
簡潔な記述、とかかなぁ
簡潔な記述、とかかなぁ
( ´д`;)…
>>122
akelos
akelos
そりゃどちらがrailsクローンかと言われると
akelosだけど現実的に考えるとsymfonyだろう
リッチってなんだよリッチって曖昧過ぎるだろ
akelosだけど現実的に考えるとsymfonyだろう
リッチってなんだよリッチって曖昧過ぎるだろ
リッチかどうかは良くわからないけど、
symfonyの方がエンタープライズ向けな感じはする。
symfonyの方がエンタープライズ向けな感じはする。
>>124
簡潔な記述もそうだけど、PHPはメタプログラミングが弱いんだよ。
Rubyはそこが強力で、だからこそActiveRecordみたいなのが実現できる。
ActiveRecordがほんとに望ましいものかどうかは別として。
簡潔な記述もそうだけど、PHPはメタプログラミングが弱いんだよ。
Rubyはそこが強力で、だからこそActiveRecordみたいなのが実現できる。
ActiveRecordがほんとに望ましいものかどうかは別として。
PHPユーザーはPHPだけで何もかもこなそうとする傾向にある。
今は亡き？Plaggerよりは、何でも出来るけどなｗ
>>129
akelosも十二分に実用だと思うよ。
http://pc11.2ch.net/test/read.cgi/php/1187333485/
http://www.akelos.org/docs/tutorials/booklink-ja
http://www.akelos.org/
http://blogs.atanaka.biz/tanaka/index.php?catid=18&blogid=2
http://blog.takeda-soft.jp/blog/category/17
http://blog.hakuja.jp/articles/tag/akelos
http://d.hatena.ne.jp/simpraight/searchdiary?word=%2a%5bAkelos%5d
akelosも十二分に実用だと思うよ。
http://pc11.2ch.net/test/read.cgi/php/1187333485/
http://www.akelos.org/docs/tutorials/booklink-ja
http://www.akelos.org/
http://blogs.atanaka.biz/tanaka/index.php?catid=18&blogid=2
http://blog.takeda-soft.jp/blog/category/17
http://blog.hakuja.jp/articles/tag/akelos
http://d.hatena.ne.jp/simpraight/searchdiary?word=%2a%5bAkelos%5d
俺のフレームワークの使い方
・RDB使わずテキストの場合
ちいたん（ちょっと改造）
・PHP4でRDB使う
ちいたん（ちょっと改造） + PieceORM
・PHP5でRDB使う
symfony
こんな感じ
・RDB使わずテキストの場合
ちいたん（ちょっと改造）
・PHP4でRDB使う
ちいたん（ちょっと改造） + PieceORM
・PHP5でRDB使う
symfony
こんな感じ
php4かphp5かとか言ってるさなか今時３かよ。
キツい・・。perlにするかな。
キツい・・。perlにするかな。
PHP3とかいっている環境しか使えない状態なら
その環境のPerlも当然バージョンが古く、
そのバージョンのPerlに対応しているフレームワークも無い。
その環境のPerlも当然バージョンが古く、
そのバージョンのPerlに対応しているフレームワークも無い。
>>134
Railsはどうか知らんが、RakeはPHPじゃ無理だと思った。
Railsはどうか知らんが、RakeはPHPじゃ無理だと思った。
言語仕様が劣っていても、それをライブラリ・フレームワークとして
提供すれば、ほぼ同等のことが出来る。
違った形での実装、使い方になるだろうが、どちらを使っても
普段の仕事で使う分には大差がない。
大差があれば、われわれは○言語を使うから、
大幅に工数が減って、結果、”安く”作れます。といえるはずだろう？
安く作るって事は給料が減るわけだが、本当に工数が減るのなら問題ないはずだ。
実際は工数が減らないから「優れた言語を使うから安く作れる」なんて話を聞いたことが無い。
提供すれば、ほぼ同等のことが出来る。
違った形での実装、使い方になるだろうが、どちらを使っても
普段の仕事で使う分には大差がない。
大差があれば、われわれは○言語を使うから、
大幅に工数が減って、結果、”安く”作れます。といえるはずだろう？
安く作るって事は給料が減るわけだが、本当に工数が減るのなら問題ないはずだ。
実際は工数が減らないから「優れた言語を使うから安く作れる」なんて話を聞いたことが無い。
>>143
どちらを使っても大差がないんだと思うなら
優れた言語使えばいいんじゃないのと思うがｗ
相手も同種のベンダーとかじゃない限り、
顧客にとっちゃどんな言語使ってようがあまり関係がない
「われわれは○言語を使うから云々」とか意味不明
安いのどうのっていうのは見積判断次第なわけで
工数とコストが比例するのが前提っておかしいだろう
どちらを使っても大差がないんだと思うなら
優れた言語使えばいいんじゃないのと思うがｗ
相手も同種のベンダーとかじゃない限り、
顧客にとっちゃどんな言語使ってようがあまり関係がない
「われわれは○言語を使うから云々」とか意味不明
安いのどうのっていうのは見積判断次第なわけで
工数とコストが比例するのが前提っておかしいだろう
「優れた言語」の定義も曖昧なまま、意味の無い話をしている人たちが気持ち悪い。
>>144
＞工数とコストが比例するのが前提っておかしいだろう
上記の「コスト」は見積もり、のこと？
この業界の最大のコストは人件費なんだから、コストは素直に比例でいいんじゃね？
まあ商用パッケージ等を使うこととかは別問題だけど、それでも「工数」を比較的上手に
コストと交換しているみたいなもんだし。
まあ、見積もりは別だ。 ・・・でもあんまり無茶なダンp(ry
＞工数とコストが比例するのが前提っておかしいだろう
上記の「コスト」は見積もり、のこと？
この業界の最大のコストは人件費なんだから、コストは素直に比例でいいんじゃね？
まあ商用パッケージ等を使うこととかは別問題だけど、それでも「工数」を比較的上手に
コストと交換しているみたいなもんだし。
まあ、見積もりは別だ。 ・・・でもあんまり無茶なダンp(ry
>>146
コストじゃねー見積orz
工数とコスト（経費）が比例しなかったらまずいｗ
俺が意味不明だった
内部的な工数の変化と外部への見積とはまた別だろう的な
意味で書いたつもりだったけど変な文章になってた
コストじゃねー見積orz
工数とコスト（経費）が比例しなかったらまずいｗ
俺が意味不明だった
内部的な工数の変化と外部への見積とはまた別だろう的な
意味で書いたつもりだったけど変な文章になってた
プログラマの言うすぐれた言語を使っても、
フレームワークを使うと、工数も作りやすさも変わらない罠。
なぜかというと、フレームワークを使うとビジネスロジックに専念できる。
そのビジネスロジックでは高度な言語機能なんて使わないから
フレームワークを使うと、工数も作りやすさも変わらない罠。
なぜかというと、フレームワークを使うとビジネスロジックに専念できる。
そのビジネスロジックでは高度な言語機能なんて使わないから
もともと SIerが作るシステムなんて仕様が汚いんだから、きれいに書ける仕組みがあっても意味がない。
それどころか、コピペで作られたシステムじゃないと、修正した場合の影響範囲が大きくなるから嫌がられる。
変更箇所が多くても土方仕事の方が良いというプロマネは多いはず。
土方仕事なんだから、職人技が使えないのは当然。
それどころか、コピペで作られたシステムじゃないと、修正した場合の影響範囲が大きくなるから嫌がられる。
変更箇所が多くても土方仕事の方が良いというプロマネは多いはず。
土方仕事なんだから、職人技が使えないのは当然。
Perl5.6は2000年リリースだけど、使えないCPANモジュールなんて数えるほどだと思うよ。
それどころかPerl5以降なら、たいていそのまま動くよ。15年前のリリースだけど。
それどころかPerl5以降なら、たいていそのまま動くよ。15年前のリリースだけど。
バージョンあがってないんだから当然だろ
Railsがいずれ主流になるのは確信してるが
まだまだ時期が早い。
symfonyだよな、
春くらいに大手サイトでのsymfony採用実績がどんどん発表されるのを
知ってる人は少ないだろうな
まだまだ時期が早い。
symfonyだよな、
春くらいに大手サイトでのsymfony採用実績がどんどん発表されるのを
知ってる人は少ないだろうな
大規模で使えるフレームワークで考えれば
長い期間でsymfony独占だろうな
規模でかいフレームワークが乱立することは、マズ無い
会社を上げてその競争に入るのに多大なコストがかかる
長い期間でsymfony独占だろうな
規模でかいフレームワークが乱立することは、マズ無い
会社を上げてその競争に入るのに多大なコストがかかる
あちこちでsymfonyほめ殺しやってるのはsymfonyアンチなんだろうなあ
なにかアンチをひきつける要素があったのか
なにかアンチをひきつける要素があったのか
スケールしやすいとかそういう事言うのかと思ったら
えらく特化された大規模向け機能だな
よっぽど小回り利かないFWを使ってるのか
えらく特化された大規模向け機能だな
よっぽど小回り利かないFWを使ってるのか
多分 >>154 が言いたかったのは、「規模」は利用者数なのか、プログラムの大きさなのかって事じゃないかと思うんだが。
>>156
＞Viewからコンポーネント、モデルに手軽にアクセスできる柔軟性
具体的に想像出来ないが、Viewからとりあえず Hoge::new とか Hoge::factory とか Hoge::singleton とか
Hoge::getInstance とかであらゆるオブジェクトを気軽に作成できて、またそうするのが前提で、みたいな？
すっごくネガティブな方向でしか想像できない。
なんか、上の方とか他に影響のありそうな所とかをいじらなくて済むから、お伺いを
立てずにとりあえず現場でなんでも出来る、うーん効率的、などなど
直行性を高く保って実現する、ていうことなのかな？DRYはある程度犠牲にして、ていう？
なんかふわふわｽﾏｿｗ
＞Viewからコンポーネント、モデルに手軽にアクセスできる柔軟性
具体的に想像出来ないが、Viewからとりあえず Hoge::new とか Hoge::factory とか Hoge::singleton とか
Hoge::getInstance とかであらゆるオブジェクトを気軽に作成できて、またそうするのが前提で、みたいな？
すっごくネガティブな方向でしか想像できない。
なんか、上の方とか他に影響のありそうな所とかをいじらなくて済むから、お伺いを
立てずにとりあえず現場でなんでも出来る、うーん効率的、などなど
直行性を高く保って実現する、ていうことなのかな？DRYはある程度犠牲にして、ていう？
なんかふわふわｽﾏｿｗ
ビューごときが直にモデルにアクセスしたいなんて思い上がりすぎわろた
コントローラー様を介せよｶｽ
コントローラー様を介せよｶｽ
コントローラを経由すると何が良いの？
>>156
少し考えたが、Ethnaみたいになるのか？
どのオブジェクトもあらゆるオブジェクトを持ってるみたいな
Ethnaはもう循環参照で開き直ってるけどｗ
$this->af->ae->af->ae みたいな （← これはなかったかもｗ）
もしくは$this->backend->(永遠に続くオブジェクトループ) みたいな
っていうか、backendの範囲広すぎｗ
そこまでするんなら、もうオブジェクトそれぞれ$GLOBALSに置いておいて
変更は禁止で（変更するならcloneでもして）勝手にアクセスすればいいん
じゃね？とかいう気がすごくする。
少し考えたが、Ethnaみたいになるのか？
どのオブジェクトもあらゆるオブジェクトを持ってるみたいな
Ethnaはもう循環参照で開き直ってるけどｗ
$this->af->ae->af->ae みたいな （← これはなかったかもｗ）
もしくは$this->backend->(永遠に続くオブジェクトループ) みたいな
っていうか、backendの範囲広すぎｗ
そこまでするんなら、もうオブジェクトそれぞれ$GLOBALSに置いておいて
変更は禁止で（変更するならcloneでもして）勝手にアクセスすればいいん
じゃね？とかいう気がすごくする。
>>151
は？5.8、5.10とリリースされてるんだけど。PHPみたいに0.1のバージョンアップでもう動かなくなる方がどうかしてる。
PHPの場合、間違いなくPHP4系、PHP5系、PHP6系が平行して使われていくだろう。
は？5.8、5.10とリリースされてるんだけど。PHPみたいに0.1のバージョンアップでもう動かなくなる方がどうかしてる。
PHPの場合、間違いなくPHP4系、PHP5系、PHP6系が平行して使われていくだろう。
4は使われねーだろ
symfonyはVからコンポーネントにアクセスする場合
CとVがワンセットでコンポーネントされてる場合
コンポーネントで定義されてるV切り離してCだけ呼ぶことも出来るし
CとＶをワンセットで呼ぶことも出来る
この辺り便利
CとVがワンセットでコンポーネントされてる場合
コンポーネントで定義されてるV切り離してCだけ呼ぶことも出来るし
CとＶをワンセットで呼ぶことも出来る
この辺り便利
適当につけているバージョン番号の数値に
意味を考えるなんて馬鹿だよな。
意味を考えるなんて馬鹿だよな。
===がRubyでは範囲比較演算子として使われててPHP脂肪ｗｗｗ
小中規模フレームワーク Akelos
大規模フレームワーク symfony
CakePHPは作者がバカそう
大規模フレームワーク symfony
CakePHPは作者がバカそう
一番はやっているものに、嫉妬して
悪口を言う気持ちは、わかります。
悪口を言う気持ちは、わかります。
http://slashdot.jp/security/article.pl?sid=08/03/03/0115231
日本PostgreSQLユーザー会のWebページがクラックされてPHP脂肪ｗｗｗ
日本PostgreSQLユーザー会のWebページがクラックされてPHP脂肪ｗｗｗ
スレ違い
PHP5.3は正式にはいつリリースされるの？
名前空間が入ることはもう確定っぽいけど、そういうのを使ったフレームワークとかはいつ頃出てくるんだろうか
普及すれば、フレームワークの書き方が思いっきり変わりそうな機能だけど、まだしばらくはお手本とかなさそう？
名前空間が入ることはもう確定っぽいけど、そういうのを使ったフレームワークとかはいつ頃出てくるんだろうか
普及すれば、フレームワークの書き方が思いっきり変わりそうな機能だけど、まだしばらくはお手本とかなさそう？
あんまりかわんないと思うけど。
PEARみたいな外部ライブラリは充実するかも。やっとスタートラインに立つってだけだけど。
独自拡張を、下の方の継承ではなく、上の方の差し替えで出来る可能性はあるかも？
// import Zend::DB as DB
import MyFramework::DB as DB;
$table = new DB::Table();
として差し替える、とか。配布スクリプトがカオスになる可能性もあるな
// import Zend::DB as DB
import MyFramework::DB as DB;
$table = new DB::Table();
として差し替える、とか。配布スクリプトがカオスになる可能性もあるな
名前空間とかgotoとかどうでもいいしね…
個人的にはicuがどうなるかだな
まぁ時代はqiqってことで
個人的にはicuがどうなるかだな
まぁ時代はqiqってことで
qiqはもちろんすげーけど
gotoと名前空間を同列に語るなよ
程度が知れるぞ
gotoと名前空間を同列に語るなよ
程度が知れるぞ
qiq見てみたけどすげーじゃん。phpに不足していると指摘されている機能がもう実現できてんじゃん。始めて知った。
？？？
無名関数・クロージャ・配列の構文糖衣 が主な拡張？
そんなに欲しかったのか？
無名関数・クロージャ・配列の構文糖衣 が主な拡張？
そんなに欲しかったのか？
じゃ他に何が必要なん？
namespace
列挙型とかクラスの動的な再定義とかモジュールのmixinとか
・・・って別にいらないと言えばいらないし、むしろ必要なのは標準ライブラリかな
いい加減、メール送信とかDBアクセスとかに外部のライブラリをいちいち吟味って
結構めんどい。さっさと標準で十分にするんだ。
Zend Framework付属のライブラリ群がそうなる予定なのかも知れないけど、そうすると
PEAR2の立ち位置が微妙になるし。
PEAR2にZend Frameworkからのバックポートがあるんなら、それが良いのかも知れない
・・・って別にいらないと言えばいらないし、むしろ必要なのは標準ライブラリかな
いい加減、メール送信とかDBアクセスとかに外部のライブラリをいちいち吟味って
結構めんどい。さっさと標準で十分にするんだ。
Zend Framework付属のライブラリ群がそうなる予定なのかも知れないけど、そうすると
PEAR2の立ち位置が微妙になるし。
PEAR2にZend Frameworkからのバックポートがあるんなら、それが良いのかも知れない
名前空間やパッケージを今更導入しても、PEAR、Zend、各種フレームワーク付属のライブラリの整合性を取るのは至難だろうな。PHP4.0程度で導入すべきだった。
いや、やっとPHP4が死んでくれたので、これからPHP5（の記述）に移行する腰の重ーい
人たちや企業がまた慣れて旧態依然としたコードを乱発してしまう前にがんがん新機軸を
入れてしまえっていう、最後の機会かも知れない
人たちや企業がまた慣れて旧態依然としたコードを乱発してしまう前にがんがん新機軸を
入れてしまえっていう、最後の機会かも知れない
PHP4で動いているサイトは星の数ほどある。今動いてるサイトは、今後PHP4で動き続ける。機能追加もされていく。互換性のないPHPだから仕方ない。
トリッキーなことしてなかったら4のサイトも5で普通に走るだろ…常考
いやあ屑コード依存が多岐に渡ると作り直すぞ
俺が体験した範囲だと、4→5よりも古い4とlatestの4の間でコケて
5+ZFで作り直しってのがこの所多発
俺が体験した範囲だと、4→5よりも古い4とlatestの4の間でコケて
5+ZFで作り直しってのがこの所多発
多発ってどんだけ。
クラスで3人くらい持ってたら「みんな持ってる」と言ってしまう
子供と同じ心理
子供と同じ心理
まぁ XPからVista並には移行するんじゃなかろうか。
>>190
先月七回きたよ
先月七回きたよ
そんなあるのか
あ、同じクラからだけどね
別案件でばらばら投げられて苛々したけど、ZFでやれたので最終的にDB一本化はけっこう綺麗にいった
運用ベースで見たら古い環境って相当な数居るように感じるのよね
問題でない限り使い続ける（というかリプレースする理由がない）もんだし
別案件でばらばら投げられて苛々したけど、ZFでやれたので最終的にDB一本化はけっこう綺麗にいった
運用ベースで見たら古い環境って相当な数居るように感じるのよね
問題でない限り使い続ける（というかリプレースする理由がない）もんだし
そりゃ問題ない物までリプレースする必要はないが、
古い４って脆弱性問題にならなかったのか
古い４って脆弱性問題にならなかったのか
最新版のPHPは機能が多くなった分、もっとセキュリティに問題あるから。枯れてるPHP4の方がよほど安全。
新しい４、なら気持ち同意
PHP本体のセキュリティをちゃんとソースコード読んだ上で語ってる奴ってどんだけいるんだろうね。
>>199
suhosin乙
suhosin乙
Windows本体のセキュリティをちゃんとソースコード読んだ上で語ってる奴ってどんだけいるんだろうね。
Windowsのセキュリティを語っているやつ死亡ｗｗｗ
Windowsのセキュリティを語っているやつ死亡ｗｗｗ
Ruby書き慣れたらPHPの行末の;を書き忘れるなぁ
従ってPHP脂肪ｗｗｗ
従ってPHP脂肪ｗｗｗ
rubyって
if (式) {hoge()}
みたいな書き方出来ないのな
ブロック付きメソッドでは{}を使うのにifで{}使えないって何なの？
if (式) {hoge()}
みたいな書き方出来ないのな
ブロック付きメソッドでは{}を使うのにifで{}使えないって何なの？
>>207
その {} を then end に変えるだけなんだがな
何なのって言われると、文法としか言いようが無さそう
PHPって hoge() if (式) って出来ないのな、ってなもんだ
MLで聞けばひょっとするとMatzが答えてくれるかも知れないよ
ってか、スレ違い
その {} を then end に変えるだけなんだがな
何なのって言われると、文法としか言いようが無さそう
PHPって hoge() if (式) って出来ないのな、ってなもんだ
MLで聞けばひょっとするとMatzが答えてくれるかも知れないよ
ってか、スレ違い
何で一貫性がないの？Matzは美意識が欠けてるの？
http://blog.pasonatech.co.jp/mitani/104/6550.html
Matz & Dan : コンピュータサイエンスとしての知識が高まると
PHPに対して不満がでてくるかもよというのは予言しておきます（笑）
PHPER=コンピュータサイエンスとしての知識が低い人ｗｗｗ
Matz & Dan : コンピュータサイエンスとしての知識が高まると
PHPに対して不満がでてくるかもよというのは予言しておきます（笑）
PHPER=コンピュータサイエンスとしての知識が低い人ｗｗｗ
>>210
お前、読解力ないのな・・
お前、読解力ないのな・・
>>212
それ以外のどんな解釈があるんすかｗｗｗ
それ以外のどんな解釈があるんすかｗｗｗ
いい加減あぼーん機能使おうよ
>>215
違う
if文はrubyでいう意味の「ブロック」じゃない
rubyのifやwhileやforはスコープを持たない
だからdo～endの代わりにブレスが使えない
eachのようにブロック付き呼び出しで使うのがブロック
こちらはブロックスコープを持つ
違う
if文はrubyでいう意味の「ブロック」じゃない
rubyのifやwhileやforはスコープを持たない
だからdo～endの代わりにブレスが使えない
eachのようにブロック付き呼び出しで使うのがブロック
こちらはブロックスコープを持つ
変な文法の言語は流行らない法則
PHPフレームワークとの組み合わせでおすすめのアクセラレータは何です？
zend
zendオプチマイザ？
アクセラレータじゃなくね
アクセラレータじゃなくね
多言語併用してたら関数とかメソッドまじ忘れてくるな
すべての言語が統一されればいいのに・・・
すべての言語が統一されればいいのに・・・
すぐリファレンスできる言語ならどうでもいいよ
バッドノウハウ頼みな制限や変態仕様が全ての言語から根絶されたら素敵だろうなあ
バッドノウハウ頼みな制限や変態仕様が全ての言語から根絶されたら素敵だろうなあ
javaとphpでプロジェクトたらい回しされる・・。
PHPが滅べばいいだけじゃないの？
>>225
そうなっても別にJavaに統一されるわけでもないんじゃね？
そうなっても別にJavaに統一されるわけでもないんじゃね？
Perl=信長
PHP=光秀
Python=秀吉
Ruby=家康
PHPERﾃﾗ三日天下ｗｗｗ
PHP=光秀
Python=秀吉
Ruby=家康
PHPERﾃﾗ三日天下ｗｗｗ
>>227-228
自演乙
自演乙
何で自演だと思ったんだろうね
http://enterprisezine.jp/article/detail/311?p=2
PHP＝トラブルｗ
LAMPセキュリティ問題の主犯ｗｗ
人知れずPHP3やPHP4を使い続けているサイトはたくさんｗｗｗ
もはやキリシタンみたいな扱いだな
PHP＝トラブルｗ
LAMPセキュリティ問題の主犯ｗｗ
人知れずPHP3やPHP4を使い続けているサイトはたくさんｗｗｗ
もはやキリシタンみたいな扱いだな
>>231
そのサイトはひどい釣りにしか見えんな
確かに、既存サーバのPHPが硬直してしまっているっていうのは必要な指摘だとは思うんだけど、
その書き方が突飛と言うか無理過ぎるというか、とにかく説得力がない
例えば
＞Apacheのmod_phpを使ってPHPをApacheモジュールとして実行すると、Apacheプロセスの
＞すべての資格情報がPHPに引き継がれます
って、SuExec等を使わない限り、Perl、Ruby、Python等のCGIでも同じっていうことに言及しない
のはどうかとも思う。他にもいろいろ、わざとかも知れないけど香ばしい
そのサイトはひどい釣りにしか見えんな
確かに、既存サーバのPHPが硬直してしまっているっていうのは必要な指摘だとは思うんだけど、
その書き方が突飛と言うか無理過ぎるというか、とにかく説得力がない
例えば
＞Apacheのmod_phpを使ってPHPをApacheモジュールとして実行すると、Apacheプロセスの
＞すべての資格情報がPHPに引き継がれます
って、SuExec等を使わない限り、Perl、Ruby、Python等のCGIでも同じっていうことに言及しない
のはどうかとも思う。他にもいろいろ、わざとかも知れないけど香ばしい
・・・なんかかぶったｗ
>>230
いつまでも馬鹿相手にする輩なんか本人以外にありえんだろ
いつまでも馬鹿相手にする輩なんか本人以外にありえんだろ
ウェブサーバとアプリケーションサーバを別プロセスにした方がセキュアというのは正しいだろう。fastcgiの外部サーバとかJavaみたいに。
最近どこもかしこもやたらSuExecだしなー
suexec導入しようと思ったが
apacheのsuexecの説明見たら
suEXEC の設定には管理者の詳細にわたる慎重な注意が必要
とか書かれてｺﾜｽ
apacheのsuexecの説明見たら
suEXEC の設定には管理者の詳細にわたる慎重な注意が必要
とか書かれてｺﾜｽ
suexecなんか使うくらいならfastcgi使うわ。
suexecって要するにCGIをsetuidされたラッパーを通して実行するもの？
てことはモジュール版のPHPは普通にapacheの権限で実行される？
てことはモジュール版のPHPは普通にapacheの権限で実行される？
みたいだね
ってことは、suexecが必要になるのって
不特定多数のユーザにリソースを貸すサーバ屋さんくらい？
ってことは、suexecが必要になるのって
不特定多数のユーザにリソースを貸すサーバ屋さんくらい？
だってなぁ、suExecを使わない ということは
ほぼApacheモジュールで動いているのと同じなわけで、
Apacheモジュールで動くということは、Apacheの権限で動いているわけで、
PHPを使えば、Apache権限になれるから、
Apache権限で読み出せる他ユーザーのファイルを読み出せるからな。
ほぼApacheモジュールで動いているのと同じなわけで、
Apacheモジュールで動くということは、Apacheの権限で動いているわけで、
PHPを使えば、Apache権限になれるから、
Apache権限で読み出せる他ユーザーのファイルを読み出せるからな。
243 ：nobodyさん：2008/03/16(日) 21:39:19 ID:9hRtdL6R
include_onceがアクセラレータで使われない問題って
apc.include_once_overrideで解決できるんじゃね？
apc.include_once_overrideで解決できるんじゃね？
facebookってPHPなんだな
Ruby脂肪ｗｗｗ
Ruby脂肪ｗｗｗ
Perl=信長
PHP=光秀
Python=秀吉
Ruby=隠れキリシタンｗｗｗｗｗｗｗ
PHP=光秀
Python=秀吉
Ruby=隠れキリシタンｗｗｗｗｗｗｗ
Ruby=慶次
いずれにしろ光秀のPHPって・・・
mbstring系の設定をPHPのコード中でしてたら、どうも文字化けする。
.htaccessに書いたらしなくなったけど。
mbstring系の設定はphp.iniか.htaccessでするって常識？
.htaccessに書いたらしなくなったけど。
mbstring系の設定はphp.iniか.htaccessでするって常識？
みなさんすいません。>>248と同じ会社の者です。
まだ見習い中なのでとりあえずphpに慣れてもらおうと課題を出したのですが、
何日たっても報告にこないのでついさっき報告をあげさせると共に指針を与えた所でした。
mbstringが、mbstringがと、説明が要領を得なくて時間がかかったのですが、
どうやらmbstring.languageをスクリプト中で指定しようとしていたらしく、
マニュアルで確認するように伝え、日々日報に問題点を記述するように厳しく指導いたしました。
今後このような事が無いように指導を行い、
また、ご迷惑をおかけしましたことをお詫び申し上げます。
まだ見習い中なのでとりあえずphpに慣れてもらおうと課題を出したのですが、
何日たっても報告にこないのでついさっき報告をあげさせると共に指針を与えた所でした。
mbstringが、mbstringがと、説明が要領を得なくて時間がかかったのですが、
どうやらmbstring.languageをスクリプト中で指定しようとしていたらしく、
マニュアルで確認するように伝え、日々日報に問題点を記述するように厳しく指導いたしました。
今後このような事が無いように指導を行い、
また、ご迷惑をおかけしましたことをお詫び申し上げます。
なんていうか不安でいっぱいな会社だな。まあガンガレ。
常識なの？
誰も言わなかったじゃん
ちゃんと説明しろよ249のハゲ
誰も言わなかったじゃん
ちゃんと説明しろよ249のハゲ
懐かしいコピペだな
PHPのmb_send_mail()とかクソ過ぎだろ。どうやったらこんな分かりづらいAPI思いつくんだか。
プロなら直にSMTP
>>255
まあ汎用的ではあるな。一度しっかりとモジュールを作ってしまえばいいわけだし
というわけで、マルチバイトや添付ファイル、HTMLメールにがっつり対応したメールモジュールのある
フレームワークの紹介よろしく！
まあ汎用的ではあるな。一度しっかりとモジュールを作ってしまえばいいわけだし
というわけで、マルチバイトや添付ファイル、HTMLメールにがっつり対応したメールモジュールのある
フレームワークの紹介よろしく！
>>256
Zend
Zend
>>258 thx
結局ライブラリの質というか筋がいいとかでいうと、Zendが一番なのかな
結局ライブラリの質というか筋がいいとかでいうと、Zendが一番なのかな
そうだね
餅は餅屋なんだからMTAに任せたらいいじゃん
わざわざSMTP叩く奴なんなの？変態なの？
わざわざSMTP叩く奴なんなの？変態なの？
>>261
MTAはMUAの間違い？（sendmailコマンドの様な）
PHPの関数インターフェイス(mail(), mb_send_mail())もMUAと言えなくもないのかな
でも、外部SMTPサーバを使いたい時も同様に扱えるから初めからMTAのサーバを
ソケットから叩くっていうのはそんなにおかしくないと思うけどな
そりゃいちいちpopenとかベタベタでやるのは変態っぽいけど、ライブラリになっていれば
そんなに手間でもないと思うし、PHPの関数叩くのとやってることは大して変わらないと思う
MTAはMUAの間違い？（sendmailコマンドの様な）
PHPの関数インターフェイス(mail(), mb_send_mail())もMUAと言えなくもないのかな
でも、外部SMTPサーバを使いたい時も同様に扱えるから初めからMTAのサーバを
ソケットから叩くっていうのはそんなにおかしくないと思うけどな
そりゃいちいちpopenとかベタベタでやるのは変態っぽいけど、ライブラリになっていれば
そんなに手間でもないと思うし、PHPの関数叩くのとやってることは大して変わらないと思う
あー
外部にメールサーバがある場合か
なるほどね
外部にメールサーバがある場合か
なるほどね
ZFだと確かPOPも扱えたよね。
そうだ。餅は餅屋に任せよう。
んで、sendmailで添付ファイルを送るにはどうすればいいんだ？
んで、sendmailで添付ファイルを送るにはどうすればいいんだ？
餅は餅屋って、sendmailはMTAだから、そのおまけのコマンド起動送信も含めて
添付ファイルを処理させるのはおかどちがいだろう。
まぁ適当にmultipartなメールをでっちあげてください。
>>262
MUAって、MDAが落としたメールとかも読めなきゃいけないんじゃない?
たぶん、あれをMUAとは言わんような...どっちでもいいけど。
どっちも/sbin/sendmailだからややこしいな。
添付ファイルを処理させるのはおかどちがいだろう。
まぁ適当にmultipartなメールをでっちあげてください。
>>262
MUAって、MDAが落としたメールとかも読めなきゃいけないんじゃない?
たぶん、あれをMUAとは言わんような...どっちでもいいけど。
どっちも/sbin/sendmailだからややこしいな。
PHP のフレームワーク: 第 5 回 外部タスクを統合する
http://www.ibm.com/developerworks/jp/opensource/library/os-php-fwk5/?ca=drs-jp
3大フレームワークでのバッチ処理についての記事。
このシリーズは正にこのスレ向けだね。
http://www.ibm.com/developerworks/jp/opensource/library/os-php-fwk5/?ca=drs-jp
3大フレームワークでのバッチ処理についての記事。
このシリーズは正にこのスレ向けだね。
フレームワークでは例外がデファクト的に使われてるけど
例外だとApacheのエラーログに残らないのが難だな
フレームワークのログには残るけど。
Apacheのエラーログ見ながらテストってよくやるし、
そこで例外が確認できないのはイケてない。
例外だとApacheのエラーログに残らないのが難だな
フレームワークのログには残るけど。
Apacheのエラーログ見ながらテストってよくやるし、
そこで例外が確認できないのはイケてない。
>>269
FWの一番上層のtry～catchで
error_log($exception->getMessage());
しておけばいい
mod_phpならapacheのerror_logに吐かれる
自分で例外をハンドリングもせずに例外が難だな、とか言われても
FWの一番上層のtry～catchで
error_log($exception->getMessage());
しておけばいい
mod_phpならapacheのerror_logに吐かれる
自分で例外をハンドリングもせずに例外が難だな、とか言われても
例外使わないCIが最強
>>271
FW全域に渡ってのエラーハンドリングできないFWもアレだと思うし
仮にできなくてもブートストラップになるdispatch部分をtry-catchしたらいいし
それもいやならexception_handlerだってあるしやり方はいくらでもあるよ
FW全域に渡ってのエラーハンドリングできないFWもアレだと思うし
仮にできなくてもブートストラップになるdispatch部分をtry-catchしたらいいし
それもいやならexception_handlerだってあるしやり方はいくらでもあるよ
素直にframeworkのlog見ときゃいいだろ、と思ってしまう。
ログが残る場所が変わるだけだろｗ
だいたいアプリレベルのログをなんでapacheのエラーログでみたいのかが分からん
アプリのログならその気になれば
HTTPヘッダやスタックトレースを出したりできるしな。
なんで不便なapacheログに頼るのだろう？
HTTPヘッダやスタックトレースを出したりできるしな。
なんで不便なapacheログに頼るのだろう？
html側の気づきにくいミスも分かるからapacheログ便利じゃん
fwのログではリソースへのリンクミスは分からない
どこかひとつにまとめておくならapacheログになる
fwのログではリソースへのリンクミスは分からない
どこかひとつにまとめておくならapacheログになる
俺なんてapacheログに日記書いてるよ
その発想はなかったわ
282 ：nobodyさん：2008/03/31(月) 13:35:52 ID:q29QDC7U
フレームワークのORMって
テンポラリテーブルやサブクエリ使うような処理はどうなってるの？
出来るのはせいぜいリレーションまで？
テンポラリテーブルやサブクエリ使うような処理はどうなってるの？
出来るのはせいぜいリレーションまで？
サブクエリ対応のORMもあるんじゃないかな。はっきりあるとは言えないけど。
テンポラリテーブルはORMの範疇じゃないと思う。
テンポラリテーブルはORMの範疇じゃないと思う。
>>282
そういう場合はSQLを直接発行する。
そういう場合はSQLを直接発行する。
複雑なSQLになると、SQLは3分で書けたのに、それをORMの文法に直すのに1時間かけても出来無くって、挙げ句ORMのソースコード見たら対応不可能だったという。
っていうか、ORMは80%の簡単なSQLを
簡単に使うのが目的なわけで。
表形式のデータを扱いやすい構造体に変更するの
面倒なんだよ。
簡単に使うのが目的なわけで。
表形式のデータを扱いやすい構造体に変更するの
面倒なんだよ。
>>286
それはORMを理解してない。
> 表形式のデータを扱いやすい構造体に変更
「テーブルのリレーションをオブジェクトのグラフに」ってことだと思うが、
本来ORMはそれを半自動的(設定ファイルが必要)に実現するためのもの。
> 簡単なSQLを簡単に使うのが目的
これを実装したライブラリとかプロダクトがORMを理解してないのに
ORMとか言っちゃったもんだから、そう勘違いしてる人が多いんだけど。
それはORMを理解してない。
> 表形式のデータを扱いやすい構造体に変更
「テーブルのリレーションをオブジェクトのグラフに」ってことだと思うが、
本来ORMはそれを半自動的(設定ファイルが必要)に実現するためのもの。
> 簡単なSQLを簡単に使うのが目的
これを実装したライブラリとかプロダクトがORMを理解してないのに
ORMとか言っちゃったもんだから、そう勘違いしてる人が多いんだけど。
DBを単純なストレージとしてしか使えてない
joinとかサブクエリとか使いこなせてないわ
そんな俺は何から勉強したらいい？
joinとかサブクエリとか使いこなせてないわ
そんな俺は何から勉強したらいい？
とりあえずは、普段自分が使うDBのSQLをしっかり覚えればいいんじゃない？
それ以上は、DB屋さんが面倒見てくれるでしょ。
それ以上は、DB屋さんが面倒見てくれるでしょ。
PHPじゃないけど、Bash on Railsなんてものが公開されてるね。
まぁ、ジョークなんだけど。
ttp://emasaka.blog65.fc2.com/blog-entry-379.html
シェルスクリプトって、普段/bin/sh互換で書かされるから、
Bashの機能をフルに使って、のびのびと何か書きたい気持ちはわかる。
なんか、昔BashでIMAPを喋るスクリプトを書いたのを思い出した。
まぁ、ジョークなんだけど。
ttp://emasaka.blog65.fc2.com/blog-entry-379.html
シェルスクリプトって、普段/bin/sh互換で書かされるから、
Bashの機能をフルに使って、のびのびと何か書きたい気持ちはわかる。
なんか、昔BashでIMAPを喋るスクリプトを書いたのを思い出した。
bash爺さん乙
頼むから少しでもbash絡みの構文が入ったら#!/bin/bashのサフィックス.bashにしてくれな。
>>292
ファイル名のこと？
っていうか拡張子すら無いのも多いし、シェバングがきっちりしてれば気にしない
スレ的に展開すると、世の中には.htmlでPHP書く会社も結構あるしなあ
そこまでじゃなくてもテンプレートファイルが（実質PHPやテンプレート独自言語でも）.htmlなところも多いし
まああれだ。拡張子なんて飾りですよと。Windows使いにはそれがわからんのですよ
ファイル名のこと？
っていうか拡張子すら無いのも多いし、シェバングがきっちりしてれば気にしない
スレ的に展開すると、世の中には.htmlでPHP書く会社も結構あるしなあ
そこまでじゃなくてもテンプレートファイルが（実質PHPやテンプレート独自言語でも）.htmlなところも多いし
まああれだ。拡張子なんて飾りですよと。Windows使いにはそれがわからんのですよ
今時糞文法のシェルスクリプト使うってどこのマゾだよ
Rubyでやればいいじゃん
Rubyでやればいいじゃん
ほぼ存在が期待できるperlじゃなくてrubyってところにリッチさ？を感じる
PerlがないならRubyを使えばいいじゃない
>>296
そんな環境あり得ないだろ
そんな環境あり得ないだろ
298 ：nobodyさん：2008/04/03(木) 16:03:55 ID:YXuoF4WI
perlとpythonはたいていひっついてくるよね
>>296の滑りっぷりに萌えた
Perlの場合、CPANモジュールのインストールを必要とすることが多いから。
BシェルはもちろんBASHの移植性にはかなわない。
BシェルはもちろんBASHの移植性にはかなわない。
>>300
CPANモジュール使わなきゃいいじゃんっていうのは無し？
だってCPANモジュール使わなくても、bashに出来ることはPerlで書く方が楽じゃね？
俺はLinuxとかよくわからんが、bashで書けてPerlで書けないこととかってあるの？
CPANモジュール使わなきゃいいじゃんっていうのは無し？
だってCPANモジュール使わなくても、bashに出来ることはPerlで書く方が楽じゃね？
俺はLinuxとかよくわからんが、bashで書けてPerlで書けないこととかってあるの？
303 ：nobodyさん：2008/04/05(土) 08:17:54 ID:ELSeDes5
現場だと、ネットワークがガチガチSecureに構築されていて、CPANに届かないことがある。
Perl(without CPAN) < bash なマゾが集まるスレはここですか
移植性を考えるとシェルの方がいい場合も多いってことだ。
>>305
なにと比べて、を書かないとあんまり意味がないな。逆もあるから
例えばシェルの場合はUnixコマンド（互換性があるとは限らない）を必要とすることでも、
Perlなら力業でベタに書けてしまうかも知れない
もっというとPerlで書いたものはWindowsにも持ってこられる場合も多い
shをBATに書き直す事を考えると、移植性って何？ってな事にもなるなｗ
なにと比べて、を書かないとあんまり意味がないな。逆もあるから
例えばシェルの場合はUnixコマンド（互換性があるとは限らない）を必要とすることでも、
Perlなら力業でベタに書けてしまうかも知れない
もっというとPerlで書いたものはWindowsにも持ってこられる場合も多い
shをBATに書き直す事を考えると、移植性って何？ってな事にもなるなｗ
Rubyなければ入れればいいじゃん
シェルの仕事はコマンド発行とパイプ、リダイレクトまで
制御構造の文法がいびつすぎ
シェルの仕事はコマンド発行とパイプ、リダイレクトまで
制御構造の文法がいびつすぎ
LinuxでもFreeBSDでもシステム標準で使われるのは、若干PerlやPythonスクリプトもあるが、ほとんどはシェルスクリプトだろ。
そうだなぁ。趣味だったら、PHPやRubyを使えばすっごい楽なんだが、
業務だとシェルスクリプトを「使わないといけない」んだよなぁ・・・。
そういう場では、「Ruby使いましょう」なんて言える空気ないよ。
Rubyは枯れてないしね。
ところで、Symfonyはそろそろ何かテンプレート機構は装備されたの？
未だに<?php echo $hoge ?>なの？
業務だとシェルスクリプトを「使わないといけない」んだよなぁ・・・。
そういう場では、「Ruby使いましょう」なんて言える空気ないよ。
Rubyは枯れてないしね。
ところで、Symfonyはそろそろ何かテンプレート機構は装備されたの？
未だに<?php echo $hoge ?>なの？
<?php echo $hoge ?>で何の問題もないわけだけど
そうそう。PHP自体がテンプレートエンジンなのに要らんことすんな馬鹿だろと思う。
short_open_tag をONにしたときの問題って、ぶっちゃけXML宣言との衝突だけ？
それなら自分でサーバの設定をいじれるときは、テンプレートファイルに限定して
<? ?> <?= ?>形式で記述するのも手だなと感じる。
だれかえろいひと教えて
それなら自分でサーバの設定をいじれるときは、テンプレートファイルに限定して
<? ?> <?= ?>形式で記述するのも手だなと感じる。
だれかえろいひと教えて
>>310
やはり自民党清和会の下に結集し、日教組を壊滅させることでしょうね。
日教組の教師に｢労働者の権利｣などという左翼思想を吹き込まれた連中が義務も果たさずに
サビ残は嫌だ、非正規雇用は止めろ、などと権利ばかり主張しています。
あとは残業代を要求して裁判を起こしてるような腐った輩を社会全体で徹底的に叩くことでしょう。
やはり自民党清和会の下に結集し、日教組を壊滅させることでしょうね。
日教組の教師に｢労働者の権利｣などという左翼思想を吹き込まれた連中が義務も果たさずに
サビ残は嫌だ、非正規雇用は止めろ、などと権利ばかり主張しています。
あとは残業代を要求して裁判を起こしてるような腐った輩を社会全体で徹底的に叩くことでしょう。
みんなうすうす<?=$var?>が効率的なことに気づきだしてる。俺は5-6年前から気づいて田が名。
何をいまさら・・
>>310, >>311
個人的には、<% %>が廃止は馬鹿だろ、と思った。
使ってはなかったが、Rails使い始めて、やはり必要だと思った。
<?php echo $hoge ?> と <%= $hoge %>
はどちらがすっきり見えますか？どちらがタイプ数（補完なしで）少ないですか？
って事を言いたくて、例えばSmarty正式サポートしろという事ではない。
>>312
自サバならそれもありだと思う。
けど、エロい人がこう言ってるから、凡人の俺は使うのを控えてしまう。
ttp://wiki.poyo.jp/read/Reviewes/Book/IT/PHP
>■ショートタグを使っている
>まだそういう本出てきますか．ハァ．
個人的には、<% %>が廃止は馬鹿だろ、と思った。
使ってはなかったが、Rails使い始めて、やはり必要だと思った。
<?php echo $hoge ?> と <%= $hoge %>
はどちらがすっきり見えますか？どちらがタイプ数（補完なしで）少ないですか？
って事を言いたくて、例えばSmarty正式サポートしろという事ではない。
>>312
自サバならそれもありだと思う。
けど、エロい人がこう言ってるから、凡人の俺は使うのを控えてしまう。
ttp://wiki.poyo.jp/read/Reviewes/Book/IT/PHP
>■ショートタグを使っている
>まだそういう本出てきますか．ハァ．
もうそろそろショートタグの正しい使い方を
認めてもいいと思う。
認めてもいいと思う。
phpはタイプしやすさなんて一㍉も考えてないからなぁ…
htmlspecialchars, array(); preg_replace...
htmlspecialchars, array(); preg_replace...
phpはタイポしやすさを考えてるんだよ
PHPはタイプしやすさよりも読みやすさ優先
読みやすい...のか?
まぁ、フラットな名前空間で、メソッドの動的書き換えなしというのは
読みやすさに貢献しているのかもしれない。
まぁ、フラットな名前空間で、メソッドの動的書き換えなしというのは
読みやすさに貢献しているのかもしれない。
Pythonしか使えないGoogle App Engine開始でPHPとRuby仲良く脂肪ｗｗｗ
frameworkはサイト丸ごと作るとかの場合いいんだけど
単体Webアプリの開発すると全く役に立たないのがなあ。
昔はPerlでよくCGIの配布がされていて、PHPも後から増えてきたが
当時は完璧にMVCなんて欠片もないデザイン＆コード全部ひっくるめソース。
だがそれだけに、配布して掲示板だけ使いたいとかいう場合も
そのPHPファイルさえ設置して設定ちょこちょこ弄れば出来た。
しかし今もしframeworkありきでBBSとか作っても、それを配布するとなるとframeworkをまずインストールしなければならない。
大体掲示板とか配布されてるCGI使うのなんて素人だし、そんなframeworkの導入なんてできないし
第一例えばZFで作っていた場合、ディスパッチャが統括してるから普通の巣HTMLコンテンツまで影響が出る。
ただBBSを設置したいだけなのに、今まで普通にそのままアクセスできていたHTMLをZFのルールに従って設置しないといけない。
とか色々面倒すぎる。
frameworkの特にこの部分が気に入らないんだけど、諸兄らは特に気にしない？
index.phpで統括して振り分けるってのね。
普通に配下に全部おいてディレクトリ構成そのままと同じアドレスでアクセスできりゃいいじゃねえか、って思うんだけど。
コントローラー名/アクション名/
とかプログラマは理解してもデザイナが理解しないだろうと。
完全にプログラムばかりなサイトだといいけど、静的コンテンツが殆どで一部に動的コンテンツがある程度じゃ無駄すぎる。
かといってじゃあそういう時は今まで通りの直PHPファイルのみにしろってなると、なんの為のframeworkだかって思ってしまう。
なげーなｗ
単体Webアプリの開発すると全く役に立たないのがなあ。
昔はPerlでよくCGIの配布がされていて、PHPも後から増えてきたが
当時は完璧にMVCなんて欠片もないデザイン＆コード全部ひっくるめソース。
だがそれだけに、配布して掲示板だけ使いたいとかいう場合も
そのPHPファイルさえ設置して設定ちょこちょこ弄れば出来た。
しかし今もしframeworkありきでBBSとか作っても、それを配布するとなるとframeworkをまずインストールしなければならない。
大体掲示板とか配布されてるCGI使うのなんて素人だし、そんなframeworkの導入なんてできないし
第一例えばZFで作っていた場合、ディスパッチャが統括してるから普通の巣HTMLコンテンツまで影響が出る。
ただBBSを設置したいだけなのに、今まで普通にそのままアクセスできていたHTMLをZFのルールに従って設置しないといけない。
とか色々面倒すぎる。
frameworkの特にこの部分が気に入らないんだけど、諸兄らは特に気にしない？
index.phpで統括して振り分けるってのね。
普通に配下に全部おいてディレクトリ構成そのままと同じアドレスでアクセスできりゃいいじゃねえか、って思うんだけど。
コントローラー名/アクション名/
とかプログラマは理解してもデザイナが理解しないだろうと。
完全にプログラムばかりなサイトだといいけど、静的コンテンツが殆どで一部に動的コンテンツがある程度じゃ無駄すぎる。
かといってじゃあそういう時は今まで通りの直PHPファイルのみにしろってなると、なんの為のframeworkだかって思ってしまう。
なげーなｗ
そういうケースにフルスタックのFWは向かないってだけだし、
あとZFに限らずフロントコントローラ形式のFWでも
mod_rewriteのルール次第で特定のディレクトリ以下や
ファイルのみに限定して動作させる事はそれほど面倒な事でもない
ディレクトリ構成そのままで一部分だけFW管轄下にする事もできるだろう
mod_rewriteやrouterの使い方が分からない人の言い訳にしか聴こえない
あとZFに限らずフロントコントローラ形式のFWでも
mod_rewriteのルール次第で特定のディレクトリ以下や
ファイルのみに限定して動作させる事はそれほど面倒な事でもない
ディレクトリ構成そのままで一部分だけFW管轄下にする事もできるだろう
mod_rewriteやrouterの使い方が分からない人の言い訳にしか聴こえない
まぁたまにファンクション寄せ集めの使いたくなるけど
結局全部framework上につくれば無問題
結局全部framework上につくれば無問題
>>326
FWによるでしょ
FWによるでしょ
rewriteとかinclude_pathとか全部ぶんなげか
>>324
だからPHP技術者が理解できても、一般人が理解できないだろって話をしてるんだが。
昔のPHPやPerlならちょっとだけ勉強すれば素人でもいけるレベルだったが
mod_rewriteを弄る素人いないだろ、ってか無料レン鯖だと弄れないところ多いだろ。
有効になってるかどうかすら怪しい。
お手軽が利点だったのに、そういう配布しても一部の技術者しか設定して使えないようなPHPプログラム作ってもなと。
今までPHPファイルを好きな場所に放り込んで、confとかをちょこちょこ弄った程度で使えていたものが
まずFWを導入して、mod_rewriteとかapacheの設定を弄って更に仕様に則った方式に従ってファイルを配置する
なんての誰が使うんだと。
ZFでいえば、PHP.iniのincludeパスまで設定しないといけない（PHP大本ファイルに全てincludeを書くというてもあるが、まあないわな）
そういうケースってか、後からこの機能だけ他で使いたいな って事があるだろ？
趣味でもいいが、FWフル活用であるシステムを作りました、その中の一部機能が評判なのでそこだけ配布する事にしました
が、当然元のFWに依存しているのでそれ以外のFWじゃ動かないし、FW前提の作りなのでファイル置いてconfファイル設定程度じゃ動きません。
で結局配布しても使えるのはほぼPHP技術者のみ。
ちょっと自分のページにCGI設置したい、とかそういう昔からいる人間には無理。
仕事のになら別にいいんだよ。
だが仕事でFW使ってそんな配布するのは昔みたいな作りにすればいいとかナンセンスだしな。
それじゃお互いが有効利用しあえないし。
仕事で作ってた一部を配布したいって時無理だし、趣味で配布用に作ったのをFW使ってる方に使いたいって時も無理（または変換に手間）だし。
>>326
フォルダ作ってぶっこんだだけでちゃんと動くFWがいくつあるよ？
だからPHP技術者が理解できても、一般人が理解できないだろって話をしてるんだが。
昔のPHPやPerlならちょっとだけ勉強すれば素人でもいけるレベルだったが
mod_rewriteを弄る素人いないだろ、ってか無料レン鯖だと弄れないところ多いだろ。
有効になってるかどうかすら怪しい。
お手軽が利点だったのに、そういう配布しても一部の技術者しか設定して使えないようなPHPプログラム作ってもなと。
今までPHPファイルを好きな場所に放り込んで、confとかをちょこちょこ弄った程度で使えていたものが
まずFWを導入して、mod_rewriteとかapacheの設定を弄って更に仕様に則った方式に従ってファイルを配置する
なんての誰が使うんだと。
ZFでいえば、PHP.iniのincludeパスまで設定しないといけない（PHP大本ファイルに全てincludeを書くというてもあるが、まあないわな）
そういうケースってか、後からこの機能だけ他で使いたいな って事があるだろ？
趣味でもいいが、FWフル活用であるシステムを作りました、その中の一部機能が評判なのでそこだけ配布する事にしました
が、当然元のFWに依存しているのでそれ以外のFWじゃ動かないし、FW前提の作りなのでファイル置いてconfファイル設定程度じゃ動きません。
で結局配布しても使えるのはほぼPHP技術者のみ。
ちょっと自分のページにCGI設置したい、とかそういう昔からいる人間には無理。
仕事のになら別にいいんだよ。
だが仕事でFW使ってそんな配布するのは昔みたいな作りにすればいいとかナンセンスだしな。
それじゃお互いが有効利用しあえないし。
仕事で作ってた一部を配布したいって時無理だし、趣味で配布用に作ったのをFW使ってる方に使いたいって時も無理（または変換に手間）だし。
>>326
フォルダ作ってぶっこんだだけでちゃんと動くFWがいくつあるよ？
まー確かに要求される知識レベルが昔と比べると格段にあがってるよな
昔は「オブジェクト指向が分かっている人間はプログラマの中でもほとんどいない」
なんて本に書かれていたもんだけど
プログラマ界の被差別層PHPERの間でも
オブジェクト指向なんてもはや前提条件だし
昔は「オブジェクト指向が分かっている人間はプログラマの中でもほとんどいない」
なんて本に書かれていたもんだけど
プログラマ界の被差別層PHPERの間でも
オブジェクト指向なんてもはや前提条件だし
>>329
> フォルダ作ってぶっこんだだけでちゃんと動くFWがいくつあるよ？
有名どころは全部対応しているが？
mod_rewriteだって、index.phpを隠すためだけに使用されているわけで、
デフォルト設定のまま使える。
mod_rewriteでコントローラ/アクションに振り分けているんじゃないんだよ？
> フォルダ作ってぶっこんだだけでちゃんと動くFWがいくつあるよ？
有名どころは全部対応しているが？
mod_rewriteだって、index.phpを隠すためだけに使用されているわけで、
デフォルト設定のまま使える。
mod_rewriteでコントローラ/アクションに振り分けているんじゃないんだよ？
http://www.modrails.com/
mod_rails登場でmod_php雪崩式に脂肪ｗｗｗ
mod_rails登場でmod_php雪崩式に脂肪ｗｗｗ
やっと、mod_phpに追いついただけじゃん
しかもプリインストールされるまではきてないし、
何年遅れだよｗｗ
しかもプリインストールされるまではきてないし、
何年遅れだよｗｗ
は？
フレームワークレベルでmodになってるんだからとっくにphpをぶち抜いてるよ
mod_symfonyとかmod_zend_frameworkみたいなもの
ﾌﾟｰﾌﾟﾌﾟﾌﾟ
フレームワークレベルでmodになってるんだからとっくにphpをぶち抜いてるよ
mod_symfonyとかmod_zend_frameworkみたいなもの
ﾌﾟｰﾌﾟﾌﾟﾌﾟ
rubyに手を出すとスレタイすら読めない無能になるのか
MySQLがオープンソースじゃなくなってPHPまた一歩脂肪ｗｗｗ
その理由なら、rubyも死亡だろｗ
まじでMySQL終わりっぽいじゃん
新規開発はpostgresにした方がいいんかな
新規開発はpostgresにした方がいいんかな
クローズドになったらMySQLなんて誰も使わないよな
ポスグレも充分に速くなってるから代替効くし
Sunの戦略がわからんわ
ポスグレも充分に速くなってるから代替効くし
Sunの戦略がわからんわ
クローズドになるとかいってんのお前だけだよｗ
ソースはこれ？↓
MySQL、新機能追加は有償版の「MySQL Enterprise」だけを対象に
http://www.technobahn.com/news/2008/200804172000.html
MySQL、新機能追加は有償版の「MySQL Enterprise」だけを対象に
http://www.technobahn.com/news/2008/200804172000.html
別にフリーだから使うなんて事はないんだぞ？
趣味ならそれは重要だが。企業レベルじゃあまり関係ない。
SQLServerやらMySQLの有料版が実際使われているのがいい証拠。
企業の場合どっちかというとサポート体制が重要。
金払ってるといざって時サポート呼べるし、場合によっては責任もとらせられる。
無料版だとサポート呼べないし責任は全部自分ところ。
なんでもオープンソース使え使えっていってるのは2流の技術者と、そういうのに疎い有料無料かでしかみれない上役だけ。
現場でわかってるプロの技術者なら有料か無料かなんて選択肢の中ではかなり優先度は低い。
少なくとも、これオープンソースだから使いましょうよ、なんていってる技術者いたらその時点で役立たずのレッテル貼るわ。
その構築するシステムに向いてるかどうかで判断するのならまだしも。
趣味ならそれは重要だが。企業レベルじゃあまり関係ない。
SQLServerやらMySQLの有料版が実際使われているのがいい証拠。
企業の場合どっちかというとサポート体制が重要。
金払ってるといざって時サポート呼べるし、場合によっては責任もとらせられる。
無料版だとサポート呼べないし責任は全部自分ところ。
なんでもオープンソース使え使えっていってるのは2流の技術者と、そういうのに疎い有料無料かでしかみれない上役だけ。
現場でわかってるプロの技術者なら有料か無料かなんて選択肢の中ではかなり優先度は低い。
少なくとも、これオープンソースだから使いましょうよ、なんていってる技術者いたらその時点で役立たずのレッテル貼るわ。
その構築するシステムに向いてるかどうかで判断するのならまだしも。
>>342
プロの技術者乙
プロの技術者乙
新機能が追加されないMySQLを使い続けてPHPERジリ貧ｗｗｗ
その理由なら、rubyも死亡だろｗ
RoRはMySQLをポイ捨てしてsqliteに乗り換え済み
先見の明の違いが出たねｗ
先見の明の違いが出たねｗ
ひどいつりだな
sqliteはパブリックドメイン（何しても自由）だから
フレームワークに内蔵してデフォルトにしているだけで
別に良いものだから選んでいるわけじゃないんだけどな。
あくまで開発・プロトタイプ・個人用のもので
複数の人が同時にアクセスするものとしての
本番利用は現実的じゃない。
それにPHPは、sqliteをとっくの昔に言語の標準
データベースとして組み込んでいる。お前に言わせれば先見の明だなｗ
フレームワークに内蔵してデフォルトにしているだけで
別に良いものだから選んでいるわけじゃないんだけどな。
あくまで開発・プロトタイプ・個人用のもので
複数の人が同時にアクセスするものとしての
本番利用は現実的じゃない。
それにPHPは、sqliteをとっくの昔に言語の標準
データベースとして組み込んでいる。お前に言わせれば先見の明だなｗ
末端の利用者が評論家気取りでグダグダ言ってるなよ。
みっともないｗ
みっともないｗ
はぁ？ 普通利用しているからことちゃんとした意見言えるわけで。
使ってもいないくせに何か言おうとしているなこいつｗ
使ってもいないくせに何か言おうとしているなこいつｗ
>>350
つれたつれた
つれたつれた
>>342
一般企業で有償MySQLってなかなかないんじゃないかな？
OracleかSQL Serverでしょう、有償なら。
現場で解ってるプロの技術者には選択肢ないんじゃないかと思う。
俺の周りだけの話だけかもしれないけど。
一般企業で有償MySQLってなかなかないんじゃないかな？
OracleかSQL Serverでしょう、有償なら。
現場で解ってるプロの技術者には選択肢ないんじゃないかと思う。
俺の周りだけの話だけかもしれないけど。
裾野が狭まるから頂も低くなるんだよ
オープンソースからプロプライエタリに移行して成功した製品あんのかと
オープンソースからプロプライエタリに移行して成功した製品あんのかと
> オープンソースからプロプライエタリに移行して成功した製品あんのかと
どうやら、あなたはオープンソースからプロプライエタリに移行したら
失敗するといいたいようですが、そもそも
オープンソースからプロプライエタリになった製品があるのですか？
あと、MySQLはsunが買収したとしても、オープンソースのままなのは
知っていますか？
どうやら、あなたはオープンソースからプロプライエタリに移行したら
失敗するといいたいようですが、そもそも
オープンソースからプロプライエタリになった製品があるのですか？
あと、MySQLはsunが買収したとしても、オープンソースのままなのは
知っていますか？
>>354
オープンソースからプロプライエタリに移行した製品がないという
悪魔の証明に自ら挑むとはｗ
製品を殺す愚策なんだから知られないのは当然
まぁ俺も知らないけどね
本当に無償版の開発を停止して有償版しか出さなくなったら
MySQLは死んでいくと思うよ
オープンソースからプロプライエタリに移行した製品がないという
悪魔の証明に自ら挑むとはｗ
製品を殺す愚策なんだから知られないのは当然
まぁ俺も知らないけどね
本当に無償版の開発を停止して有償版しか出さなくなったら
MySQLは死んでいくと思うよ
>>341を読む限り、「新機能」がCommunityServer版に付かなくなる、とも読めるな
もしメンテ（および機能改良）が続くんなら別にいいかなと、無理矢理楽観してみる
もしメンテ（および機能改良）が続くんなら別にいいかなと、無理矢理楽観してみる
ウェブシステムの性格的に、信頼性が低くても安い方がいいってことでApacheとかMySQLとかPHPとかが流行ってるわけだからな。
金かかるんだったら、ポスグレにして、その分自分の収入にする罠。
金かかるんだったら、ポスグレにして、その分自分の収入にする罠。
358 ：nobodyさん：2008/04/19(土) 09:19:18 ID:Pd4VwcNb
くだらん書き込みが続いてるなぁ。
ApacheもMySQLも信頼性が低いってー事はないぞ。PHPについてはシランが。
あと、普通にPHPでwebプログラムを組める奴は必然的にPHPとJavascriptという風に複数言語使えるようになってるからそこから更にrubyとかいうことになってもそんなにコストかかるわけじゃないと思う。
俺もrubyについては手をつけてないが、Cやらpythonやらに手をつけてるし。
PHP脂肪とか言われたら他の言語使えばいいだけだって気づかないんかね。
# あと、ここはフレームワークのスレかと
ApacheもMySQLも信頼性が低いってー事はないぞ。PHPについてはシランが。
あと、普通にPHPでwebプログラムを組める奴は必然的にPHPとJavascriptという風に複数言語使えるようになってるからそこから更にrubyとかいうことになってもそんなにコストかかるわけじゃないと思う。
俺もrubyについては手をつけてないが、Cやらpythonやらに手をつけてるし。
PHP脂肪とか言われたら他の言語使えばいいだけだって気づかないんかね。
# あと、ここはフレームワークのスレかと
>>355
あんた、悪魔の証明が何かわかってないんじゃね？
あんた、悪魔の証明が何かわかってないんじゃね？
http://d.hatena.ne.jp/naoya/20080418/1208520196
Community Server開発継続でPHP余命一年延びるｗｗｗ
Community Server開発継続でPHP余命一年延びるｗｗｗ
src php 捨てたい
けどまだ時期尚早だよな
けどまだ時期尚早だよな
http://blog.ohgaki.net/ruby-1-9-0-webrick
Ruby1.9以下のWEBrickにディレクトリ遷移攻撃脆弱性があってPHP脂肪ｗｗｗ
Ruby1.9以下のWEBrickにディレクトリ遷移攻撃脆弱性があってPHP脂肪ｗｗｗ
Delphi for PHPってどうなんだろう
「データベースに特別なコードを書かずとも容易に接続できるようにした」
とかいう説明読むとフレームワークと認識してもいいように思うけど
「データベースに特別なコードを書かずとも容易に接続できるようにした」
とかいう説明読むとフレームワークと認識してもいいように思うけど
そりゃMVC一通りあるんじゃないの？使ったことないから分からないけど
Python厨だけにGoogle App Engine使って配信したのかもな
そんな攻撃的な信者はphperにもrubyistにもいないよな
phythonerﾔﾊﾞｽ
しかも単なるセキュリティー情報で誹謗中傷ですらねーし
phythonerﾔﾊﾞｽ
しかも単なるセキュリティー情報で誹謗中傷ですらねーし
フォームヘルパーって使ってます？
せっかくMVCなのにテンプレートに関数入れるなんて、とっても矛盾してると
思うのですが・・・
そういう需要もあるってだけなんですかね
せっかくMVCなのにテンプレートに関数入れるなんて、とっても矛盾してると
思うのですが・・・
そういう需要もあるってだけなんですかね
Viewのロジックじゃん
MVC=Viewの動的要素を一切省こうってわけじゃないよ
MVC=Viewの動的要素を一切省こうってわけじゃないよ
確かにプルダウンとかラジオボタンのHTMLをコントローラ（やモデル？）でつくって
準備するのはなんだかなーだ
分担としては間違いなくViewの仕事だろう。ヘルパーって言うのが微妙なんだけどな
準備するのはなんだかなーだ
分担としては間違いなくViewの仕事だろう。ヘルパーって言うのが微妙なんだけどな
だからViewHelperはViewの範疇なんだっての
高校生か？
高校生か？
DIにアスペクト志向にアノテーション……採用前評価がめんどくさそうなw
採用検討／評価するにしてもうちはGW終わってからだなー。
おまえら頑張れ
採用検討／評価するにしてもうちはGW終わってからだなー。
おまえら頑張れ
symfonyってcodeigniterの何倍くらい重い？
rubyてmysql使うのにもmakeとかしなきゃいけないのか・・俺脂肪
ふつー gem install mysql
380 ：nobodyさん：2008/05/01(木) 17:01:00 ID:1aec6u7x
ethnaがシンプルでよかったので
社内システムの標準FWに採用しました。
社内システムの標準FWに採用しました。
ethnaってまだ開発続いているの？
382 ：nobodyさん：2008/05/02(金) 00:35:33 ID:ulIGiMsU
地味に続いてるよ。
383 ：nobodyさん：2008/05/02(金) 14:05:51 ID:ulIGiMsU
新しいバージョンでるみたいだね。
symfonyはcodeigniterの3倍遅いみたいね
同じパフォーマンスをあげようと思ったら3倍のリソースが必要か…
同じパフォーマンスをあげようと思ったら3倍のリソースが必要か…
単純に機能とスピードのトレードオフだろう。
http://jp.techcrunch.com/archives/20080501twitter-said-to-be-abandoning-ruby-on-rails/
twitterがRoRを放棄でPHP復活ｗｗｗ
twitterがRoRを放棄でPHP復活ｗｗｗ
RoRがスケーリングに対応できないというが
それならRoRをパクっただけのPHPのFWが対応できるのか？
それならRoRをパクっただけのPHPのFWが対応できるのか？
全部erlangで書きゃいいのに
389 ：nobodyさん：2008/05/02(金) 17:16:36 ID:mpl3PtrU
phpは素で書けば速いもんな。
390 ：nobodyさん：2008/05/02(金) 18:38:44 ID:ulIGiMsU
エスナも早いよ
ciはソースに今どき閉じタグが書かれているのがイモ
閉じたり閉じなかったりで動きが変わる事自体がイモじゃね
仕方ないんだろうけどさ
仕方ないんだろうけどさ
>>391は所得も知能も底辺に位置する者の喚き声だなｗ
なんで？
>>393の頭には虫がわいてんだろうなww
ソースに今どき開きタグが書かれているのがイモ
閉じタグを書かない俺ってＧＥＥＫ！
ciはsystemディレクトリの中にapplicationディレクトリが入ってるのがイモ
そこは分けとけよ
そこは分けとけよ
>>398はもっと評価されるべき
しばらくsymfony使ってて
久しぶりにci触ったら身軽でいいわ～
久しぶりにci触ったら身軽でいいわ～
402 ：nobodyさん：2008/05/04(日) 23:06:36 ID:QrBYi/l0
結局 中小規模だとどれがおすすめ？？
CakePHP
-> DBと密接すぎる
CodeIgniter
-> セッションがクッキーに保存される
とどっちも肝心なとこがいまいちだった…
CakePHP
-> DBと密接すぎる
CodeIgniter
-> セッションがクッキーに保存される
とどっちも肝心なとこがいまいちだった…
>>402
ちゃんと使えば？CIのセッションについては、DBに保存することもできたと思うけど。
っていう自分はドキュメントよんで評価して改良してっていう手間がもうしんどくて、
guesswork classic をカスタマイズしたものを延々つかってるけど
ちゃんと使えば？CIのセッションについては、DBに保存することもできたと思うけど。
っていう自分はドキュメントよんで評価して改良してっていう手間がもうしんどくて、
guesswork classic をカスタマイズしたものを延々つかってるけど
CakePHP ってそんなにDBと密接だろうか？
usesプロパティにnull代入すれば
それで終わりじゃね？
usesプロパティにnull代入すれば
それで終わりじゃね？
普通に作ればモデルを作るのが当たり前なんだが・・・。
まあ経験をつめ。
まあ経験をつめ。
変態セッションがいやなら$_SESSION使えばいいじゃない
たとえば？
それはどのFWを使うかというより、
FWを使うべきかどうかを検討する規模の開発だと思う。
生PHP+何かしら必要なライブラリで事足りそう。
FWを使うべきかどうかを検討する規模の開発だと思う。
生PHP+何かしら必要なライブラリで事足りそう。
>>407
自分は、>>406じゃないけど、具体的にはどんな感じでモデル組んでます？
オンメモリな処理はともかく、DB上のデータに対しては、SQLの実行はパフォーマンスに
直結するから、内部の処理は隠すべきではないんじゃないかって思うところもあって、
結構悩ましい。
自分は、>>406じゃないけど、具体的にはどんな感じでモデル組んでます？
オンメモリな処理はともかく、DB上のデータに対しては、SQLの実行はパフォーマンスに
直結するから、内部の処理は隠すべきではないんじゃないかって思うところもあって、
結構悩ましい。
内部の処理をモデルの中に隠せばいいのでは？
だって、最適なSQLって画面とか機能ごとに違うことが多いじゃん。
画面とか機能からの独立性がほとんど無いものを個別に作り上げて、
それをモデルと呼べるのかといえば、かなり疑問。
っていうか、モデルとしてのメリットがほとんどない。
画面とか機能からの独立性がほとんど無いものを個別に作り上げて、
それをモデルと呼べるのかといえば、かなり疑問。
っていうか、モデルとしてのメリットがほとんどない。
MVCを勉強しなおしてね。
416 ：nobodyさん：2008/05/06(火) 01:40:18 ID:Db+mgkTm
CIのルータが変態なので自前ルータを書いてるんだが
hoge/moge/
と
hoge/moge
を同一と判定すべき？しないべき？
hoge/moge/
と
hoge/moge
を同一と判定すべき？しないべき？
417 ：nobodyさん：2008/05/06(火) 01:45:13 ID:iGu8GQhf
すべき
だよな
ファイルシステムとの類推で考えると
同名のファイルとディレクトリは同階層に存在できないもんな
ファイルシステムとの類推で考えると
同名のファイルとディレクトリは同階層に存在できないもんな
どちらでも同じコンテンツにアクセスできることが望ましいと思うが、
どちらかに転送した方が良いと思われ
どちらかに転送した方が良いと思われ
質問スレで知ったんだがRhacoってどうなの？
和製フレームワークっぽいけど
このスレで出たことないよね？
和製フレームワークっぽいけど
このスレで出たことないよね？
どうも和製はなぁ。
結局海外製に押し切られる気がする。
だからRubyもいまいち使う気になれない。
結局海外製に押し切られる気がする。
だからRubyもいまいち使う気になれない。
Rhacoのオフィシャルサイトがなんか重いなァ
パフォーマンスでないのかな？
パフォーマンスでないのかな？
結構作り込んである印象
なんでまったく話題に出なかったんだろ？
なんでまったく話題に出なかったんだろ？
CIがあまいだけでは？
いや、少し考えてみた。
URLが hoge/moge なら、一番最初に hoge/moge を探すべきだな。rewriteやaliasを含めて。
いきなり hoge/moge/ に書き換えるのは乱暴か
で、そうやって探して hoge/moge が見つからなかった時のみ、hoge/moge/(DirectoryIndex) と
するのが一応は順序かと思った。
>>426はそういう意味かな
URLが hoge/moge なら、一番最初に hoge/moge を探すべきだな。rewriteやaliasを含めて。
いきなり hoge/moge/ に書き換えるのは乱暴か
で、そうやって探して hoge/moge が見つからなかった時のみ、hoge/moge/(DirectoryIndex) と
するのが一応は順序かと思った。
>>426はそういう意味かな
/hoge/mogeでも/hoge/moge/でもどっちでも
mogeがディレクトリ的存在だったら
/hoge/moge/index.html
が表示されるべきで、
その判断はサーバ側でおこなう。
最後の/の有無だけに、エンティティの判断基準を委ねない。
ってことだな
mogeがディレクトリ的存在だったら
/hoge/moge/index.html
が表示されるべきで、
その判断はサーバ側でおこなう。
最後の/の有無だけに、エンティティの判断基準を委ねない。
ってことだな
なんかかぶったｗ
>>430
結論は反対だけどねｗ
結論は反対だけどねｗ
ん？同じだろ？
426…最後の/で判断するよ派
428・429…最後の/で判断しないよ派
これであってる？
428・429…最後の/で判断しないよ派
これであってる？
ってか
フレームワークのルータに/hoge/moge/index.htmlが渡ることって考えにくいな
素のリソースはmod_rewriteの設定で直接アクセスされるだろ
フレームワークのルータに/hoge/moge/index.htmlが渡ることって考えにくいな
素のリソースはmod_rewriteの設定で直接アクセスされるだろ
/foo/barへのアクセスは
1./foo/barがファイルであるか確認
2./foo/bar/へリダイレクト（301 Moved Permanently）
が正しい動作のはず。
1./foo/barがファイルであるか確認
2./foo/bar/へリダイレクト（301 Moved Permanently）
が正しい動作のはず。
何を基準にした「正しい」動作なの?
俺もｵﾓﾀ。いったい何を基準に正しい・正しくないを議論しているのか…
独自アプリのルーティングの話で index.html がどうとかﾜｹﾜｶﾗﾝ
静的ファイルを表示するための httpd を書いていて
mod_dir に酷似した挙動をさせたいということならわからなくもないが、
>>416が聞きたいのはそういうことなのか?
独自アプリのルーティングの話で index.html がどうとかﾜｹﾜｶﾗﾝ
静的ファイルを表示するための httpd を書いていて
mod_dir に酷似した挙動をさせたいということならわからなくもないが、
>>416が聞きたいのはそういうことなのか?
パスが変わるのでしないべき
妥協点はスラ付きへリダイレクト
が正解
妥協点はスラ付きへリダイレクト
が正解
>>438に賛同。
SEO/SBO という面で考えれば、/ ありと / 無しをアプリ側で同一と見なすべきではない。
ただし、ユーザビリティを考慮すれば、/ 無しを / ありに 301 で転送 (またはその逆) をすることをするとなお良い。
参考 → http://pmakino.jp/tdiary/20061105.html#p01
SEO/SBO という面で考えれば、/ ありと / 無しをアプリ側で同一と見なすべきではない。
ただし、ユーザビリティを考慮すれば、/ 無しを / ありに 301 で転送 (またはその逆) をすることをするとなお良い。
参考 → http://pmakino.jp/tdiary/20061105.html#p01
なるほど
たしかにSEO的にリダイレクトする方がいいな
㌧㌧
たしかにSEO的にリダイレクトする方がいいな
㌧㌧
>>441
日本語が読みきれん。どっち？
テーブルと1:1に対応することを前提としないモデルクラスを作ってる
テーブルと1:1に対応する、内部の構造が隠蔽されていないから必ずしもモデルとは呼べない、モデルクラスを作ってる
前者だろうとは思うけど、一応。
日本語が読みきれん。どっち？
テーブルと1:1に対応することを前提としないモデルクラスを作ってる
テーブルと1:1に対応する、内部の構造が隠蔽されていないから必ずしもモデルとは呼べない、モデルクラスを作ってる
前者だろうとは思うけど、一応。
はぁ。テーブルと一対一にならなくても
モデルはモデルだろ。
モデルはモデルだろ。
むしろ、テーブルと1:1になることを前提にするのは、内部構造に対する抽象化が制約されるという意味で、
モデリングとして不適切だと思ってる。
だから自分的には >>443 は自明。
ただ、>>441 の言葉の意味が取りきれなかっただけ。
モデリングとして不適切だと思ってる。
だから自分的には >>443 は自明。
ただ、>>441 の言葉の意味が取りきれなかっただけ。
クラスで使う例外って
クラスと同じファイルに書く？別にする？
例外クラスを1クラス1ファイル方式にすると
ファイルがとっちらかるよなぁ
クラスと同じファイルに書く？別にする？
例外クラスを1クラス1ファイル方式にすると
ファイルがとっちらかるよなぁ
特定のフレームワーク上でのお作法の話ならずれてるかも知れんが、
自分の場合、自作の例外クラスって、せいぜい2個ぐらい (ユーザ操作系、システム異常系) しか作らない。
どんな例外であれ、rollbackしてエラーメッセージ出して終わりってのがほとんどだから、
クラス分けせずにエラーコードで区別してる。
自分の場合、自作の例外クラスって、せいぜい2個ぐらい (ユーザ操作系、システム異常系) しか作らない。
どんな例外であれ、rollbackしてエラーメッセージ出して終わりってのがほとんどだから、
クラス分けせずにエラーコードで区別してる。
俺はタイプヒンティング使ってcatchするのに結構使うな
というかPHPのtry catchはゴミすぎて使う気になれませんよｗ
結局catch ～～ で分岐するか、instanseof で分岐するか、
$e->getCode(), $e->getMessage() で分岐するか、の違い
しかないとか思っちゃうんだが、わかってないってことだと
自分でも思う
$e->getCode(), $e->getMessage() で分岐するか、の違い
しかないとか思っちゃうんだが、わかってないってことだと
自分でも思う
MVC要らんな。
長い目で見たら実は激しく開発効率が落ちるよな。
みんなとっくに気付いてるだろ。
もうMVCなんて発掘された化石にしがみつくのはやめようぜ。
テンプレートに全部書くに限る。
冗談抜きで、コピペでいい。
変更は該当ファイルを変更。
追加は新規作成。
そもそもPHPはこの形で爆発的に伸びてきた。
ものすごい速さで「ページ」を量産できてきたわけだ。
PHPと比較してはるかにHTMLを苦手とする他の言語の実装にすりよる必要なんてない。
コードが醜悪で結構。
メンテし難い？
いやいや、HTML部分はどんな初心者でも理解可能だからさっさと読み飛ばすわけだ。
そして残ったPHP処理部分がMVCを捨ててページ単位で完結して書いてある。
完結しているのだから、追っていくだけで全容が分かるわけだ。
汚い素のPHPファイルが開発効率に優れている理由はここにある。
何かを試験的に作るとき、さっさとPHPというテンプレートで書いちゃうだろ。
たぶん、数時間あれば、第三者に見せられる程度の単機能ページを作れるだろ。
その試作品でいいんだよ。
一週間かけたものと何も変わんねえから。
つまりその試作品で50万くらい請求できるわけだ。
あるいは、10万に値下げできるわけだ。
頭冷やそうぜ。
PHPそのものが実利の塊なんだから、無理して加工すんなって。無駄な汗を流すなよ。
どうしても加工してPHPらしくない別フレームワークを作りたければ、C++で本気で作れ。PHPでやるな馬鹿外人。
長い目で見たら実は激しく開発効率が落ちるよな。
みんなとっくに気付いてるだろ。
もうMVCなんて発掘された化石にしがみつくのはやめようぜ。
テンプレートに全部書くに限る。
冗談抜きで、コピペでいい。
変更は該当ファイルを変更。
追加は新規作成。
そもそもPHPはこの形で爆発的に伸びてきた。
ものすごい速さで「ページ」を量産できてきたわけだ。
PHPと比較してはるかにHTMLを苦手とする他の言語の実装にすりよる必要なんてない。
コードが醜悪で結構。
メンテし難い？
いやいや、HTML部分はどんな初心者でも理解可能だからさっさと読み飛ばすわけだ。
そして残ったPHP処理部分がMVCを捨ててページ単位で完結して書いてある。
完結しているのだから、追っていくだけで全容が分かるわけだ。
汚い素のPHPファイルが開発効率に優れている理由はここにある。
何かを試験的に作るとき、さっさとPHPというテンプレートで書いちゃうだろ。
たぶん、数時間あれば、第三者に見せられる程度の単機能ページを作れるだろ。
その試作品でいいんだよ。
一週間かけたものと何も変わんねえから。
つまりその試作品で50万くらい請求できるわけだ。
あるいは、10万に値下げできるわけだ。
頭冷やそうぜ。
PHPそのものが実利の塊なんだから、無理して加工すんなって。無駄な汗を流すなよ。
どうしても加工してPHPらしくない別フレームワークを作りたければ、C++で本気で作れ。PHPでやるな馬鹿外人。
>>454
修正が体力勝負になるから嫌気がさすっていうのもあるんだよｗ
ポリシーと一貫性があるならいいが、どうせ修正がかさむにつれ
AとA'とA''とABとA''Bみたいなソースが量産されてくるんだろ
一字一句変えずにコピペできる所なんてそう無い。大概コピペ先で
修正されてdiffとったりしたら目を覆うような作業量になる
それでも、「可能」かどうかをいうなら、修正は可能だし、８割くらいの
作業が速く済む、っていうのはうなずけなくもないけど
修正が体力勝負になるから嫌気がさすっていうのもあるんだよｗ
ポリシーと一貫性があるならいいが、どうせ修正がかさむにつれ
AとA'とA''とABとA''Bみたいなソースが量産されてくるんだろ
一字一句変えずにコピペできる所なんてそう無い。大概コピペ先で
修正されてdiffとったりしたら目を覆うような作業量になる
それでも、「可能」かどうかをいうなら、修正は可能だし、８割くらいの
作業が速く済む、っていうのはうなずけなくもないけど
PHPの場合、try catchの例外処理機構が駄目なんじゃ無くって、組み込み関数がエラーで例外吐かないのが糞。
俺もPHP使ってるけど確かにそういうことを考えたりする。
>>454はちょっと乱暴な文体だけど言いたいことはわかる。
これは何もスパゲティなコード書けということではなくて
もちろんメンテしやすいように努力はするのだけれど
そのために果たしてMVCやオブジェクト指向が必要かどうかといえば
必ずしも必要ではないかもしれない。
我々は何もPHPしか使えないわけではないのだから
PHPを使う時は割り切ってページ単位でディレクトリ階層もわかりやすく
作っても良いのかもしれない。
正直、最近PHPフレームワークについて興味があったんだが、
再度PHPの良さについて考えてみよう。
>>454はちょっと乱暴な文体だけど言いたいことはわかる。
これは何もスパゲティなコード書けということではなくて
もちろんメンテしやすいように努力はするのだけれど
そのために果たしてMVCやオブジェクト指向が必要かどうかといえば
必ずしも必要ではないかもしれない。
我々は何もPHPしか使えないわけではないのだから
PHPを使う時は割り切ってページ単位でディレクトリ階層もわかりやすく
作っても良いのかもしれない。
正直、最近PHPフレームワークについて興味があったんだが、
再度PHPの良さについて考えてみよう。
テストのしやすさとか
開発効率とか
安定性を求めれば
結局MVCに戻ってくることになる。
おつかれさんｗ
開発効率とか
安定性を求めれば
結局MVCに戻ってくることになる。
おつかれさんｗ
実利を求めたらオブジェクト指向に落ち着くだろ
どうだろうね。プログラマは確保できるけど能力的には怪しいっていう環境なんかだと、
エレガントな設計はむしろ罪悪じゃないかと思うし、残念ながらそういう環境は多い。
逆に言えば >>454 は、人海戦術で対応可能な仕事でないと成立しないんじゃないかとも思うが、
エレガントさをあきらめれば、人海戦術で対応できない仕事なんてそうないし。
エレガントな設計はむしろ罪悪じゃないかと思うし、残念ながらそういう環境は多い。
逆に言えば >>454 は、人海戦術で対応可能な仕事でないと成立しないんじゃないかとも思うが、
エレガントさをあきらめれば、人海戦術で対応できない仕事なんてそうないし。
PHPの特徴はPHPとHTMLが混在できるということだよな。
この混在をViewが分離してないので悪と捉えるならば、
PHPの特徴も悪ということになる。
それでそのPHPの特徴を無くしたMVCなフレームワークを使うことになるんだが、
それじゃPHPを使ってる意味とは何なんだろうか。
別の言語のMVCフレームワークでも良いという結論になってしまうんじゃないか。
別にMVCなフレームワークが悪いと言ってるんじゃない。
ただ、PHPの特徴を活かした使い方があるんじゃないだろうか。
昔ながらのロジックとビューをファイルの上下で分割するような次のような使い方でも。
-------------
<?php
//設定や共通関数のinclude
//PHPによる処理
$a = 1;
?>
<html>
...
<?php echo $a; ?>
</html>
この混在をViewが分離してないので悪と捉えるならば、
PHPの特徴も悪ということになる。
それでそのPHPの特徴を無くしたMVCなフレームワークを使うことになるんだが、
それじゃPHPを使ってる意味とは何なんだろうか。
別の言語のMVCフレームワークでも良いという結論になってしまうんじゃないか。
別にMVCなフレームワークが悪いと言ってるんじゃない。
ただ、PHPの特徴を活かした使い方があるんじゃないだろうか。
昔ながらのロジックとビューをファイルの上下で分割するような次のような使い方でも。
-------------
<?php
//設定や共通関数のinclude
//PHPによる処理
$a = 1;
?>
<html>
...
<?php echo $a; ?>
</html>
> 別の言語のMVCフレームワークでも良いという結論になってしまうんじゃないか。
そのとおりだよ。
ただ、フレームワークも込みで、どこのレンタルサーバーで動くようなものはPHPしかない。
Rubyは言語辞退は一定な買ったりバージョンが古いし、
Perlはフレームワークや、必要なライブラリをインストールするのに
Shellやある程度の権限がいる。
PHPとPHP製フレームワーク・ライブラリは、ほとんどが
ファイル配置ですむからね。
あぁ、これがPHPを使っている意味かｗ
そのとおりだよ。
ただ、フレームワークも込みで、どこのレンタルサーバーで動くようなものはPHPしかない。
Rubyは言語辞退は一定な買ったりバージョンが古いし、
Perlはフレームワークや、必要なライブラリをインストールするのに
Shellやある程度の権限がいる。
PHPとPHP製フレームワーク・ライブラリは、ほとんどが
ファイル配置ですむからね。
あぁ、これがPHPを使っている意味かｗ
Rubyは言語自体入ってなかったりバージョンが古いし、
>>464
そうなんだよ、現実を考えるとPHPを使いたいというよりは
PHPを使わざるを得ない、という感じなんだよ。
そして使わざるを得ないPHPでPHPの特徴を消すようなフレームワークを使う。
このジレンマというかもやもやしたものが俺の中に常にある。
>Rubyは言語辞退は一定な買ったりバージョンが古いし、
>Perlはフレームワークや、必要なライブラリをインストールするのに
>Shellやある程度の権限がいる
これはレンタルサーバ屋によるというか、PHPも最新バージョンを使いたい
（特にセキュリティホール絡みで）時は、結局自分で最新版をコンパイルすることになって
権限やShellが必要になるので、ほんと、レンタルサーバ屋によるとしか言えないな。
そうなんだよ、現実を考えるとPHPを使いたいというよりは
PHPを使わざるを得ない、という感じなんだよ。
そして使わざるを得ないPHPでPHPの特徴を消すようなフレームワークを使う。
このジレンマというかもやもやしたものが俺の中に常にある。
>Rubyは言語辞退は一定な買ったりバージョンが古いし、
>Perlはフレームワークや、必要なライブラリをインストールするのに
>Shellやある程度の権限がいる
これはレンタルサーバ屋によるというか、PHPも最新バージョンを使いたい
（特にセキュリティホール絡みで）時は、結局自分で最新版をコンパイルすることになって
権限やShellが必要になるので、ほんと、レンタルサーバ屋によるとしか言えないな。
ベタ書き＝PHP＋XREA
MVC＝Python＋Google App Engine
がいいかな？
MVC＝Python＋Google App Engine
がいいかな？
悪くないんじゃね。適材適所？
GoogleAppEngineは本サービスの内容次第だけど
GoogleAppEngineは本サービスの内容次第だけど
FWと独立したORMがもっとでてこねーかな
好きなFWに好きなORMを組み合わせるみたいな使い方が一般的になればいいのに
好きなFWに好きなORMを組み合わせるみたいな使い方が一般的になればいいのに
直SQLで十分。
ﾃｨﾝﾎﾟﾆｰの新しいヘルパって
クラスメソッドになったんだっけ？
<?php echo HogeHelper::url_for('default/poge')?>
みたいな風に書くの？長くね？
クラスメソッドになったんだっけ？
<?php echo HogeHelper::url_for('default/poge')?>
みたいな風に書くの？長くね？
いけてないPHP？
綺麗事抜きでドラスティックに行きましょうや
ベタ書き＋直SQL ＝ PHP＋XREA
MVC＋ORM ＝ Python＋Google App Engine
簡単にできることを複雑にやる必要はない
Python、Java等と使い分けて適材適所で
綺麗事抜きでドラスティックに行きましょうや
ベタ書き＋直SQL ＝ PHP＋XREA
MVC＋ORM ＝ Python＋Google App Engine
簡単にできることを複雑にやる必要はない
Python、Java等と使い分けて適材適所で
開発言語なんて自由に選べるものでもないし、
サーバーサイドで複数の言語が混在したシステムなんて考えたくもない。
ただ、PHPの言語仕様がさほど特徴的とも思わない。
自分は標準ライブラリが整備されてて、メジャーだからPHP使ってる。
サーバーサイドで複数の言語が混在したシステムなんて考えたくもない。
ただ、PHPの言語仕様がさほど特徴的とも思わない。
自分は標準ライブラリが整備されてて、メジャーだからPHP使ってる。
>>473
まず、君は何の為にデザインとロジックの分離という
考え方が存在するのか、なぜORMというものが存在するのか、
その理由を知ったほうがいい。
話はそれからだ。
（そのあとで、なぜPHPにはそれが当てはまらないというんだ？と聞く予定）
ついでに、なぜテンプレートを使えば、
RubyやPythonでも、PHPと同じようにHTMLの中にロジックを
書くことが出来るわけだが、なぜその方法を使わないのか。
君はこっちのほうが簡単だ。といいたいんだろう？
まず、君は何の為にデザインとロジックの分離という
考え方が存在するのか、なぜORMというものが存在するのか、
その理由を知ったほうがいい。
話はそれからだ。
（そのあとで、なぜPHPにはそれが当てはまらないというんだ？と聞く予定）
ついでに、なぜテンプレートを使えば、
RubyやPythonでも、PHPと同じようにHTMLの中にロジックを
書くことが出来るわけだが、なぜその方法を使わないのか。
君はこっちのほうが簡単だ。といいたいんだろう？
>>475
で、どれがデザインとロジックの分離できてるわけ?
Rails? JSF? Django? どれもできてないじゃん。
実際できるのがあったとして、それはメジャーなん? 使い物になるだけの速さでるの?
できてもない『デザインとロジックの分離』という幻想を抱いて死んでくれ。
おれは断然>>454支持するぜ。
で、どれがデザインとロジックの分離できてるわけ?
Rails? JSF? Django? どれもできてないじゃん。
実際できるのがあったとして、それはメジャーなん? 使い物になるだけの速さでるの?
できてもない『デザインとロジックの分離』という幻想を抱いて死んでくれ。
おれは断然>>454支持するぜ。
まあ極端にならんと。
どっちの利点も判らんでもないけど、中庸ってのも考えなきゃ
妥協点ともいうか
たとえ幻想でも雑魚をまとめる旗印にはなるしw
どっちの利点も判らんでもないけど、中庸ってのも考えなきゃ
妥協点ともいうか
たとえ幻想でも雑魚をまとめる旗印にはなるしw
自分が楽な作り方を選べばいいじゃん。
一人でちっさなツール作るなら、べたに書けばいいんじゃね？
中規模以上のものを作るにはMVCが作りやすいがね。
一人でちっさなツール作るなら、べたに書けばいいんじゃね？
中規模以上のものを作るにはMVCが作りやすいがね。
プログラムとは一言でいえば「データ＋処理」
それ以上でもなければ、それ以外でもない
WEBアプリ＝DBラッパー
DOA→ベタ書き＋直SQLで充分
OOA→MVC＋ORMで楽できる
フレームワークは他人の知恵を借用して楽できるツール＝使わなきゃ損
普段フレームワークを使っていれば、逆にフレームワークを使うまでもない状況かどうか判断できるはずだよね？
お問合せメールフォーム１ページ作るのにsymfony使ってますとかは漫才ｗｗｗ
それ以上でもなければ、それ以外でもない
WEBアプリ＝DBラッパー
DOA→ベタ書き＋直SQLで充分
OOA→MVC＋ORMで楽できる
フレームワークは他人の知恵を借用して楽できるツール＝使わなきゃ損
普段フレームワークを使っていれば、逆にフレームワークを使うまでもない状況かどうか判断できるはずだよね？
お問合せメールフォーム１ページ作るのにsymfony使ってますとかは漫才ｗｗｗ
インプットチェックで異常があったらフォームを再表示みたく、処理結果によって表示するページが
異なったり、複数の処理結果に対して同じページを表示したいことがあるのは普通だから、
ビューを分離するのは良いんだけど、DBアクセスは、同じ処理をしたいことは多くないし、
無理にまとめるとパフォーマンスが劣化するから、モデルとしてまとめることに利点があるのかは疑問。
コントロールも、自分の場合トランザクション前の処理、トランザクション中の処理、トランザクション後の処理、
次のページ取得を呼び出すクラス作って継承する程度で十分間にあってる。
ビューについては、そもそもがベタ書きみたいなもんだし。
フレームワークは、特定のフレームワークが業界内において支配的な立場になり、
その上で動作する使い勝手が良いパーツが流通しなければ、大してメリットなんかないと思ってる。
ソースコードの可読性は考慮すべきだけど、フレームワークを導入しただけで可読性がよくなる
わけじゃないし、フレームワークを導入しただけで大きなメリットがあるわけでもないなら、
フレームワーク使うべきって論はどうかなぁって思う。
異なったり、複数の処理結果に対して同じページを表示したいことがあるのは普通だから、
ビューを分離するのは良いんだけど、DBアクセスは、同じ処理をしたいことは多くないし、
無理にまとめるとパフォーマンスが劣化するから、モデルとしてまとめることに利点があるのかは疑問。
コントロールも、自分の場合トランザクション前の処理、トランザクション中の処理、トランザクション後の処理、
次のページ取得を呼び出すクラス作って継承する程度で十分間にあってる。
ビューについては、そもそもがベタ書きみたいなもんだし。
フレームワークは、特定のフレームワークが業界内において支配的な立場になり、
その上で動作する使い勝手が良いパーツが流通しなければ、大してメリットなんかないと思ってる。
ソースコードの可読性は考慮すべきだけど、フレームワークを導入しただけで可読性がよくなる
わけじゃないし、フレームワークを導入しただけで大きなメリットがあるわけでもないなら、
フレームワーク使うべきって論はどうかなぁって思う。
フレームワーク使うべきかどうかってそういう次元の話じゃなくて、
単にフレームワークを使ったほうが楽だから使うだけだよ。
> DBアクセスは、同じ処理をしたいことは多くないし、
同じ処理あるよ。検索処理や、検索結果を扱いやすいように
構造化されたハッシュ・配列に入れる処理。
JOINしたときとか、二次元の表よりも階層化された
配列に入ってくれたほうが楽だよね。
> その上で動作する使い勝手が良いパーツが流通しなければ、大してメリットなんかないと思ってる。
意味がわからん。PEARライブラリとか普通に使えるだろ。
フレームワーク専用のパーツなら、普通に使い勝手が良いパーツが組み込まれている。
だからこそ便利であり、使うんだが。
> フレームワークを導入しただけで可読性がよくなるわけじゃないし
良くある言い方だね。銀の弾丸じゃないならメリットがないとする極端な考え方。
銀の弾丸なんて存在しない。だけど普通の弾丸なら存在する。
弾丸が効かない敵がいたって、効く敵もいるんだから弾丸はあったほうがいいだろ。
フレームワークを導入すると、可読性が良くなる場合もあるし
少しでもメリットがあるのなら、あったほうがいいだろ。
単にフレームワークを使ったほうが楽だから使うだけだよ。
> DBアクセスは、同じ処理をしたいことは多くないし、
同じ処理あるよ。検索処理や、検索結果を扱いやすいように
構造化されたハッシュ・配列に入れる処理。
JOINしたときとか、二次元の表よりも階層化された
配列に入ってくれたほうが楽だよね。
> その上で動作する使い勝手が良いパーツが流通しなければ、大してメリットなんかないと思ってる。
意味がわからん。PEARライブラリとか普通に使えるだろ。
フレームワーク専用のパーツなら、普通に使い勝手が良いパーツが組み込まれている。
だからこそ便利であり、使うんだが。
> フレームワークを導入しただけで可読性がよくなるわけじゃないし
良くある言い方だね。銀の弾丸じゃないならメリットがないとする極端な考え方。
銀の弾丸なんて存在しない。だけど普通の弾丸なら存在する。
弾丸が効かない敵がいたって、効く敵もいるんだから弾丸はあったほうがいいだろ。
フレームワークを導入すると、可読性が良くなる場合もあるし
少しでもメリットがあるのなら、あったほうがいいだろ。
>>475
>まず、君は何の為にデザインとロジックの分離という
>考え方が存在するのか、なぜORMというものが存在するのか、
>その理由を知ったほうがいい。
>
>話はそれからだ。
なにこのえらそうなバカ。おまえはデザインとロジックの分離ができてるの?
こんだけえらそうに語ってるんだから、きっと完全な分離ができるんだろう。
で、どれを使ったらできるの? Symfony? Cake?
教えて、コーマンチキな475さん
>まず、君は何の為にデザインとロジックの分離という
>考え方が存在するのか、なぜORMというものが存在するのか、
>その理由を知ったほうがいい。
>
>話はそれからだ。
なにこのえらそうなバカ。おまえはデザインとロジックの分離ができてるの?
こんだけえらそうに語ってるんだから、きっと完全な分離ができるんだろう。
で、どれを使ったらできるの? Symfony? Cake?
教えて、コーマンチキな475さん
「話はそれからだ」ってのは「理由は聞かないで下さいっ >_<」って意味なんだから、そっとしといてやれよ。
484 ：nobodyさん：2008/05/09(金) 23:11:23 ID:a3XtheQg
>>484
あんな糞なもん使ったって何の自慢にもならねーよｗ
まあ、sfSmartyPlugin（だっけか）の品質の問題はともかく、
デザインにもロジックはあるのだよ。
ORMはおかしいよな。テーブルとモデルが一対一になってる。
おかしいのはPropelだけなのかもしんないけど。
そんなの変だよ、当たり前じゃないか、みたいなレスを貰ったのでほっとした。
あんな糞なもん使ったって何の自慢にもならねーよｗ
まあ、sfSmartyPlugin（だっけか）の品質の問題はともかく、
デザインにもロジックはあるのだよ。
ORMはおかしいよな。テーブルとモデルが一対一になってる。
おかしいのはPropelだけなのかもしんないけど。
そんなの変だよ、当たり前じゃないか、みたいなレスを貰ったのでほっとした。
>>485
>>デザインにもロジックはあるのだよ。
それ言ったらjspも(ry
>>ORMはおかしいよな。テーブルとモデルが一対一になってる。
いや別に。
漏れがどうにかしてほしいと思っているのはpropelの使い方だけ。
doctrineもpropelもSQL文直打ちしていた人からしたら使いづらいと思うんだよね。
executeQuery()使えばいいんだけど、それだとO/Rマッパーの意味ないしな。
>>そんなの変だよ、当たり前じゃないか、みたいなレスを貰ったのでほっとした。
フレームワーク反対派に賛同したつもりはないんだが・・・・・。
ある程度規模でかくなればクラス分割してlib配下に設置してあげるだけでオートロードしてくれたりするから再利用も行いやすい。
フレームワークは結構便利だと思う。
でもそこまででかくならないんだったら別にいらないよなーって感じじゃね。
symfonyぐらいのフレームワーク使うんだったらメリットでかいと思うけどCakePHPやPiece Frameworkレベルだと別になくても良い様な希ガス。
>>デザインにもロジックはあるのだよ。
それ言ったらjspも(ry
>>ORMはおかしいよな。テーブルとモデルが一対一になってる。
いや別に。
漏れがどうにかしてほしいと思っているのはpropelの使い方だけ。
doctrineもpropelもSQL文直打ちしていた人からしたら使いづらいと思うんだよね。
executeQuery()使えばいいんだけど、それだとO/Rマッパーの意味ないしな。
>>そんなの変だよ、当たり前じゃないか、みたいなレスを貰ったのでほっとした。
フレームワーク反対派に賛同したつもりはないんだが・・・・・。
ある程度規模でかくなればクラス分割してlib配下に設置してあげるだけでオートロードしてくれたりするから再利用も行いやすい。
フレームワークは結構便利だと思う。
でもそこまででかくならないんだったら別にいらないよなーって感じじゃね。
symfonyぐらいのフレームワーク使うんだったらメリットでかいと思うけどCakePHPやPiece Frameworkレベルだと別になくても良い様な希ガス。
小さいのを作るにはフレームワークを使わなくても出来るけど、
大きいのを作るにはフレームワークを使ったほうが便利。
便利な方法と、不便な方法。どちらを選ぶかは
考えるまでも無い。
大きいのを作るにはフレームワークを使ったほうが便利。
便利な方法と、不便な方法。どちらを選ぶかは
考えるまでも無い。
>>485
> デザインにもロジックはあるのだよ。
そうだね。でどうしろと？
どうせデザインにロジックがあるのだから、
各自勝手に作れといわんだろ？
あんた極端なんだよ。完璧じゃなければ必要ないとか考えてるだろ。
もう少しバランス感覚養ったほうがいいんじゃないのか？
1か0じゃなくて、どちらのほうが優れているかで話をしろ。
> デザインにもロジックはあるのだよ。
そうだね。でどうしろと？
どうせデザインにロジックがあるのだから、
各自勝手に作れといわんだろ？
あんた極端なんだよ。完璧じゃなければ必要ないとか考えてるだろ。
もう少しバランス感覚養ったほうがいいんじゃないのか？
1か0じゃなくて、どちらのほうが優れているかで話をしろ。
JavaのApache Wicketというフレームワークは
テンプレートにHTMLを使う。
JSPみたいな独自タグや{hoge}みたいな独自識別子を使わない。
現状のWicketが完璧とは言わないけど（メジャーとは言い難いし）、
その方向性はいいなと思える。
ViewはHTMLのテンプレートを使って
ロジックはどの言語でもいい、みたいなもの（Viewテンプレートとロジックのブリッジみたいなもの？）ができれば
言語やフレームワークごとにViewの独自タグや独自識別子を使い分けなくてよくなると思うんだけどな。
テンプレートにHTMLを使う。
JSPみたいな独自タグや{hoge}みたいな独自識別子を使わない。
現状のWicketが完璧とは言わないけど（メジャーとは言い難いし）、
その方向性はいいなと思える。
ViewはHTMLのテンプレートを使って
ロジックはどの言語でもいい、みたいなもの（Viewテンプレートとロジックのブリッジみたいなもの？）ができれば
言語やフレームワークごとにViewの独自タグや独自識別子を使い分けなくてよくなると思うんだけどな。
即席で作るだけなら生書きの方が速いことも多いが
保守を考えるとフレームワーク使わないときついだろ
保守を考えるとフレームワーク使わないときついだろ
SQLって単体のテーブルごとにアクセスするものではないからだと思う。
パフォーマンスを考慮したSQLとの相性は悪いんじゃなかろうか。
パフォーマンスを考慮したSQLとの相性は悪いんじゃなかろうか。
>>492
結合する処理をモデルに実装するから、そうでもないよ。
例えばユーザを結合したコメント一覧を取得するアクセスロジックをコメントモデルに持たせるとか。
ORMがアソシエーション機能を提供してたりもするし(あまり好きではないけど)。
Someモデルはsomeテーブル以外を知ってはならないということはないと思う。特にActiveRecordでは。
結合する処理をモデルに実装するから、そうでもないよ。
例えばユーザを結合したコメント一覧を取得するアクセスロジックをコメントモデルに持たせるとか。
ORMがアソシエーション機能を提供してたりもするし(あまり好きではないけど)。
Someモデルはsomeテーブル以外を知ってはならないということはないと思う。特にActiveRecordでは。
runkitでaopみたいなことしたかったけど
セッションハンドラに登録したメソッド書き換えたら
segmantation fault出るようになった
やっぱまだ不安定なんだな・・・面白い拡張なんだが
セッションハンドラに登録したメソッド書き換えたら
segmantation fault出るようになった
やっぱまだ不安定なんだな・・・面白い拡張なんだが
俺485。おまいらレスありがとう。
でも書いてもらった日本語がよくわからない。
俺もいいかげんな発言してたので、真面目に書き直しておく。
>>486
お前は本当にsfSmartyViewPluginを使ったのか？
sfSmartyViewPluginを使わないでsymfonyで開発した事があるか？
sfSmartyViewPluginがビューとロジックの分離における有効策と考えてるなら、
それはあまりにもロジックを排除する事に対して神経質になりすぎだと思う。
symfonyは標準ではPHPの構文をテンプレートファイルに記述する。
確かにこの書き方だとHTML内にロジックが書けてしまうので束縛が無い事が嫌かも知れないが、
ビューにはビューを成立させるためのロジックがあっても良いと俺は考える。
でも書いてもらった日本語がよくわからない。
俺もいいかげんな発言してたので、真面目に書き直しておく。
>>486
お前は本当にsfSmartyViewPluginを使ったのか？
sfSmartyViewPluginを使わないでsymfonyで開発した事があるか？
sfSmartyViewPluginがビューとロジックの分離における有効策と考えてるなら、
それはあまりにもロジックを排除する事に対して神経質になりすぎだと思う。
symfonyは標準ではPHPの構文をテンプレートファイルに記述する。
確かにこの書き方だとHTML内にロジックが書けてしまうので束縛が無い事が嫌かも知れないが、
ビューにはビューを成立させるためのロジックがあっても良いと俺は考える。
俺は485なんだけど441でもある。
>>485の後半に書いた事は>>484に言ったというより、過去のレスへの返答だった。
>>442
前者です。
>>443-444
自明だよな。その書き込みを見てほっとしたぜ。
ってことだった。
>>485の後半に書いた事は>>484に言ったというより、過去のレスへの返答だった。
>>442
前者です。
>>443-444
自明だよな。その書き込みを見てほっとしたぜ。
ってことだった。
つーか休まないと日本語処理能力が低下しまくっていかんな。
>>488
sfSmartyViewPluginよりもsymfony標準のテンプレート書式の方が優れている。
というか、sfSmartyViewPluginは完璧に使い物にならないと心底思う。
sfSmartyViewPluginは足かせにこそなれ、利便性は何も齎してくれない。
反論はあるだろうけど、ビューに制約を課す事とMVCを考慮する事は全く別だと思う。
>>491
結合とはある単一のテーブルが行う処理ではないから。
>>488
sfSmartyViewPluginよりもsymfony標準のテンプレート書式の方が優れている。
というか、sfSmartyViewPluginは完璧に使い物にならないと心底思う。
sfSmartyViewPluginは足かせにこそなれ、利便性は何も齎してくれない。
反論はあるだろうけど、ビューに制約を課す事とMVCを考慮する事は全く別だと思う。
>>491
結合とはある単一のテーブルが行う処理ではないから。
一対一でマッピングされてるからって
そのテーブルに対して「のみ」のモデルじゃない
そのテーブルに対して「のみ」のモデルじゃない
いまだにsmartyとか言ってる意味がわからん
検討にすら値しないだろ
検討にすら値しないだろ
結局viewヘルパってどれがいいんだろうな？
・関数
・クラスメソッド
・$this(viewクラスあるいはcontrollerクラスのインスタンス）のメソッド
・$this以外の、view空間にassignされたオブジェクトのメソッド
個人的には最後のものに可能性を感じるが・・・
状態を持ちやすい、動的に変化させやすいという意味で。
複数のクラスのメソッドを集めるmixin的な機能が要りそう。
そこがキレイにできれば・・
・関数
・クラスメソッド
・$this(viewクラスあるいはcontrollerクラスのインスタンス）のメソッド
・$this以外の、view空間にassignされたオブジェクトのメソッド
個人的には最後のものに可能性を感じるが・・・
状態を持ちやすい、動的に変化させやすいという意味で。
複数のクラスのメソッドを集めるmixin的な機能が要りそう。
そこがキレイにできれば・・
>>495
>>お前は本当にsfSmartyViewPluginを使ったのか？
>>sfSmartyViewPluginを使わないでsymfonyで開発した事があるか？
当たり前
>>それはあまりにもロジックを排除する事に対して神経質になりすぎだと思う。
おまい日曜プログラマ？プロジェクト内にテンプレート側にがちごりでロジック書くウンコいたらどうすんの？
デザイン変更したい～なんてお客さんから要望あったらデザイナーにテンプレート渡すだろ？
テンプレート側にロジックかかれたら・・・・・後はわかるよな。
使わなくていいんだったら漏れもつかわねーよ。プラグイン入れるのﾏﾝﾄﾞｸｾ
>>お前は本当にsfSmartyViewPluginを使ったのか？
>>sfSmartyViewPluginを使わないでsymfonyで開発した事があるか？
当たり前
>>それはあまりにもロジックを排除する事に対して神経質になりすぎだと思う。
おまい日曜プログラマ？プロジェクト内にテンプレート側にがちごりでロジック書くウンコいたらどうすんの？
デザイン変更したい～なんてお客さんから要望あったらデザイナーにテンプレート渡すだろ？
テンプレート側にロジックかかれたら・・・・・後はわかるよな。
使わなくていいんだったら漏れもつかわねーよ。プラグイン入れるのﾏﾝﾄﾞｸｾ
>>484
>symfony+smarty使ったことあるかい？
smartyで「デザインとロジックの分離」が実現できるとでも思ってるの? バカ?
>>485
> デザインにもロジックはあるのだよ。
そのとーり。WicketやMayaaやTapestryでは確かに「デザインとロジックの分離」ができるけど、smartyなんかじゃ全然できない。
>>488
> そうだね。でどうしろと？
おまえはなにもするな。smartyごときで「デザインとロジックの分離」とか偉そうに語るな。
> あんた極端なんだよ。完璧じゃなければ必要ないとか考えてるだろ。
完璧にほど遠いものをさも完璧なように語るおまえがバカなだけ。
PHPにはWicketもMayaaもないんだから、デザインの分離なんか考えるだけ無駄。
> もう少しバランス感覚養ったほうがいいんじゃないのか？
> 1か0じゃなくて、どちらのほうが優れているかで話をしろ。
他人の言葉をうのみにしているおまえこそ、もっと現実をみたほうがいい。
実現できてもないことに、1も0もないだろ。バッカじゃない?
>symfony+smarty使ったことあるかい？
smartyで「デザインとロジックの分離」が実現できるとでも思ってるの? バカ?
>>485
> デザインにもロジックはあるのだよ。
そのとーり。WicketやMayaaやTapestryでは確かに「デザインとロジックの分離」ができるけど、smartyなんかじゃ全然できない。
>>488
> そうだね。でどうしろと？
おまえはなにもするな。smartyごときで「デザインとロジックの分離」とか偉そうに語るな。
> あんた極端なんだよ。完璧じゃなければ必要ないとか考えてるだろ。
完璧にほど遠いものをさも完璧なように語るおまえがバカなだけ。
PHPにはWicketもMayaaもないんだから、デザインの分離なんか考えるだけ無駄。
> もう少しバランス感覚養ったほうがいいんじゃないのか？
> 1か0じゃなくて、どちらのほうが優れているかで話をしろ。
他人の言葉をうのみにしているおまえこそ、もっと現実をみたほうがいい。
実現できてもないことに、1も0もないだろ。バッカじゃない?
>>498
そういう解釈をいれないといけないあたり、相性が悪いんじゃないかと。
出来ないって話はしてないつもり。
そもそもモデリングってのは本質的ではないものを隠蔽したり相殺したりして
扱いやすくするものだと理解してるんだが、パフォーマンス的なことを考えると
SQLはそれ自体が本質的で、隠蔽されるべき対象ではないと思う。
機能的なことだけ考えれば良いのなら、SQLを隠蔽するのは正しいだろうけど、
それは贅沢だなぁって思う。
そういう解釈をいれないといけないあたり、相性が悪いんじゃないかと。
出来ないって話はしてないつもり。
そもそもモデリングってのは本質的ではないものを隠蔽したり相殺したりして
扱いやすくするものだと理解してるんだが、パフォーマンス的なことを考えると
SQLはそれ自体が本質的で、隠蔽されるべき対象ではないと思う。
機能的なことだけ考えれば良いのなら、SQLを隠蔽するのは正しいだろうけど、
それは贅沢だなぁって思う。
モデリングの時点でオブジェクト間の関連は定義されるんだから相性が悪いということはないと思うけどな。
設計(仕様)上、記事テーブルがユーザテーブルに依存するなら、記事モデルがユーザモデル(テーブル)を知っていていいし、依存してもいい。
ただ、今までORMレイヤをリリースしてきた人達が「SQLを書かなくていいよ！楽チンだよ！」ってところを押しすぎたのは良くない。
複雑なフェッチが必要な場合はSQLを発行して結果を返すメソッドをモデルに持たせればいいのに、
「(極端に言えば)SQLを書いちゃいけない」という固定観念のもと、SQL以上に複雑な手続きによるフェッチだったり、
複数回SQLが発行されることを厭わない実装がある。
バランスとれればいいんじゃないかな。多くの部分ではSQL書かずに楽するし、SQLが必要なら(モデル内に)SQLを書く。
SQL書いたらORMが謳う「簡単なデータベースの切り替え」ができなくなるって？
大丈夫。開発中にデータベースが変更になることはまずないし、「ついで」程度の機能でしかない。
設計(仕様)上、記事テーブルがユーザテーブルに依存するなら、記事モデルがユーザモデル(テーブル)を知っていていいし、依存してもいい。
ただ、今までORMレイヤをリリースしてきた人達が「SQLを書かなくていいよ！楽チンだよ！」ってところを押しすぎたのは良くない。
複雑なフェッチが必要な場合はSQLを発行して結果を返すメソッドをモデルに持たせればいいのに、
「(極端に言えば)SQLを書いちゃいけない」という固定観念のもと、SQL以上に複雑な手続きによるフェッチだったり、
複数回SQLが発行されることを厭わない実装がある。
バランスとれればいいんじゃないかな。多くの部分ではSQL書かずに楽するし、SQLが必要なら(モデル内に)SQLを書く。
SQL書いたらORMが謳う「簡単なデータベースの切り替え」ができなくなるって？
大丈夫。開発中にデータベースが変更になることはまずないし、「ついで」程度の機能でしかない。
オープンソースのフレームワーク開発ってどういうビジネスモデルなんだろ？
symfonyとかciは企業が作ってるけど
どこで利益あげてるのかな？
知名度を上げて受注を増やす形？
symfonyとかciは企業が作ってるけど
どこで利益あげてるのかな？
知名度を上げて受注を増やす形？
ひょっとしてそれはギャグで（ｒｙ
いやギャグじゃないよ
どこからか金が環流しないと時間と労力投入できないじゃん
どこからか金が環流しないと時間と労力投入できないじゃん
>>502
お前の言うデザインとロジックの分離っていうものはいったいどれぐらいのレベルを言ってるんだ
それにしてもヒステリックなやつだな
もうちょっと落ち着けよ
お前みたいな趣味でやっているやつにはMVCはいらないと思うけど現場では実際に必要とされてるんだよ
お前の言うデザインとロジックの分離っていうものはいったいどれぐらいのレベルを言ってるんだ
それにしてもヒステリックなやつだな
もうちょっと落ち着けよ
お前みたいな趣味でやっているやつにはMVCはいらないと思うけど現場では実際に必要とされてるんだよ
デザインとロジックの無意味な議論うぜぇ
>>508
>>502じゃないが、デザインとロジックの分離のレベルは
WicketやMayaaレベルを言ってるんだろう。
俺も分離するならそのレベルが妥当だと思う。
逆にそのレベルで分離できないなら、
開発者には必要とされてもデザイナには使いにくいことに変わりないと思う。
>>502じゃないが、デザインとロジックの分離のレベルは
WicketやMayaaレベルを言ってるんだろう。
俺も分離するならそのレベルが妥当だと思う。
逆にそのレベルで分離できないなら、
開発者には必要とされてもデザイナには使いにくいことに変わりないと思う。
>>510
んなこたーない。ロジックが書かれたphpファイルより全然いいだろ。
.htmlファイルを直接テンプレートとして使えるし部分的にロジックが入るようであればそこはプログラマが修正してあげればいい。
そもそも一番のメリットは上に書いたがテンプレートにロジック書くようなｳﾝｺ野郎を排除するところだし。
んなこたーない。ロジックが書かれたphpファイルより全然いいだろ。
.htmlファイルを直接テンプレートとして使えるし部分的にロジックが入るようであればそこはプログラマが修正してあげればいい。
そもそも一番のメリットは上に書いたがテンプレートにロジック書くようなｳﾝｺ野郎を排除するところだし。
>>511
>んなこたーない。ロジックが書かれたphpファイルより全然いいだろ。
>.htmlファイルを直接テンプレートとして使えるし部分的にロジックが入るようであればそこはプログラマが修正してあげればいい。
すまんが主語は何だ。smartyが、か？
WicketやMayaaはテンプレートがHTMLなので（独自タグや{if}等が無い）、
HTMLしかしらないデザイナも扱いやすいし、
HTML編集ソフトでテンプレートを読み込んで修正しやすいのがメリットなんだが、
そんなメリットは必要ないってことか？
>んなこたーない。ロジックが書かれたphpファイルより全然いいだろ。
>.htmlファイルを直接テンプレートとして使えるし部分的にロジックが入るようであればそこはプログラマが修正してあげればいい。
すまんが主語は何だ。smartyが、か？
WicketやMayaaはテンプレートがHTMLなので（独自タグや{if}等が無い）、
HTMLしかしらないデザイナも扱いやすいし、
HTML編集ソフトでテンプレートを読み込んで修正しやすいのがメリットなんだが、
そんなメリットは必要ないってことか？
RDB使ってる時点でSQL便利は自明
SQLイヤならOODB使うしかない
SQLイヤならOODB使うしかない
Javaのテンプレートには、PHPのSmartyよりも優れたものがあるんですね。
参考になります。
ついでにPHPにも移植してください。
Wicket
http://www.wicket-ja.org/
Mayaa
http://mayaa.seasar.org/
参考になります。
ついでにPHPにも移植してください。
Wicket
http://www.wicket-ja.org/
Mayaa
http://mayaa.seasar.org/
>>513
そう、SQLってかなり完成度高いんだよね。
SQLで拾った値でインスタンス作っても作らなくてもいいんだけど、
拾うためにインスタンス作るのに何のメリットがあるのか。
SQLをラップするのって、正規表現が分からない人向けに正規表現エンジンをラップして
簡単なテキスト検索エンジンを作ってるような気持ち悪さを感じる。で、正規表現をつかう
抜け道も用意してありますみたいな。
そう、SQLってかなり完成度高いんだよね。
SQLで拾った値でインスタンス作っても作らなくてもいいんだけど、
拾うためにインスタンス作るのに何のメリットがあるのか。
SQLをラップするのって、正規表現が分からない人向けに正規表現エンジンをラップして
簡単なテキスト検索エンジンを作ってるような気持ち悪さを感じる。で、正規表現をつかう
抜け道も用意してありますみたいな。
516 ：nobodyさん：2008/05/11(日) 17:42:48 ID:tIr1XyIc
sage忘れちゃったよ
ごめんね
ごめんね
SMTPのプロトコルが分からない人向けにその部分をラップして
簡単にメールを送信するmail()関数がある。で、プロトコルしゃべる
抜け道も用意してある。
SQLラップするのも正規表現ラップするのも同じ。ライブラリとはそういうもの。
簡単にメールを送信するmail()関数がある。で、プロトコルしゃべる
抜け道も用意してある。
SQLラップするのも正規表現ラップするのも同じ。ライブラリとはそういうもの。
SMTPはプロトコルとしての完成度高く無いじゃん。ただの規格。
>>519
ん？完成度が高いものはラップする必要なく、低いものはラップして当たり前ということ？
ん？完成度が高いものはラップする必要なく、低いものはラップして当たり前ということ？
ラップの必要性の比較で言えばいうまでもなくそうだろ
まぁ抜け道が前提のラッパーを見て、何も感じないなら、それはそれで才能だと思う。
PG/SIerとしては、そっちのほうが幸せかもしれん。
PG/SIerとしては、そっちのほうが幸せかもしれん。
>>501
> プロジェクト内にテンプレート側にがちごりでロジック書くウンコいたらどうすんの？
クビにするべきだろう。
> デザイン変更したい～なんてお客さんから要望あったらデザイナーにテンプレート渡すだろ？
テンプレートを渡すという事は、責任を渡すという事と同義だよ。
> 使わなくていいんだったら漏れもつかわねーよ。プラグイン入れるのﾏﾝﾄﾞｸｾ
こう言ってるって事は、理不尽さを感じながら妥協をしていて、それを愚痴ってるんだと思うんだが、
たぶんプログラムに制限を課すより、体制を考えなおしたほうがいいと思うぞ。
たとえば、ウンコ書くプログラマが居る可能性がある時に、
そのプログラマが極力コードを書けないように制限する事は困難だと思う。
制限を課す事に手間を割くくらいなら、生産性のある作業に注力した方が良いんでないかい。
> プロジェクト内にテンプレート側にがちごりでロジック書くウンコいたらどうすんの？
クビにするべきだろう。
> デザイン変更したい～なんてお客さんから要望あったらデザイナーにテンプレート渡すだろ？
テンプレートを渡すという事は、責任を渡すという事と同義だよ。
> 使わなくていいんだったら漏れもつかわねーよ。プラグイン入れるのﾏﾝﾄﾞｸｾ
こう言ってるって事は、理不尽さを感じながら妥協をしていて、それを愚痴ってるんだと思うんだが、
たぶんプログラムに制限を課すより、体制を考えなおしたほうがいいと思うぞ。
たとえば、ウンコ書くプログラマが居る可能性がある時に、
そのプログラマが極力コードを書けないように制限する事は困難だと思う。
制限を課す事に手間を割くくらいなら、生産性のある作業に注力した方が良いんでないかい。
>>524
本当にプログラマ？
すぐクビにするとかテンプレート渡す＝責任を渡すとか
到底社会人の発想とは思えないんだが。
サンデープログラマや、開発者とデザイナが分かれてない業務しかやったことないのを否定はしないが、
分業化されてるプロジェクトの場合も想像できないと、この話を進めるのは無理だと思う。
本当にプログラマ？
すぐクビにするとかテンプレート渡す＝責任を渡すとか
到底社会人の発想とは思えないんだが。
サンデープログラマや、開発者とデザイナが分かれてない業務しかやったことないのを否定はしないが、
分業化されてるプロジェクトの場合も想像できないと、この話を進めるのは無理だと思う。
RubyでもWicketの仕組みを実装する動きがあるみたいだな…
SQLが便利ってマンセーしてる人って、文字列およびプログラム内のデータ管理に
自信のある人なんだなーって素直に感心してる俺ｗ
とりあえず、外部からの入力値を元にしたSQLの動的な組み立てを自分でする気には
あんまりならないんだが、モデルってそういう所の面倒をみるってことはそんなに重視
されてないの？
まあ「MVCのモデル」ってレベルではなく、DBIインターフェイスレベルの話ではあるん
だけどｗ
自信のある人なんだなーって素直に感心してる俺ｗ
とりあえず、外部からの入力値を元にしたSQLの動的な組み立てを自分でする気には
あんまりならないんだが、モデルってそういう所の面倒をみるってことはそんなに重視
されてないの？
まあ「MVCのモデル」ってレベルではなく、DBIインターフェイスレベルの話ではあるん
だけどｗ
SQLを一切書かずORMだけでRDB使えてますか？
SQLより速くてインピーダンスミスマッチのないORMがあったら教えて！＞＜
分類 / 基礎となる計算モデル / 例
1. 手続型言語 / チューリングマシン / C, Java
2. 問合せ言語 / 関係モデル / SQL
3. 関数型言語 / ラムダ計算 / Lisp, Haskell
4. 論理型言語 / 一階述語言語 / Prolog
（2～4は、非手続型言語）
↑1～4のどれでも使えるようにしておいた方がいいよ
＝RDBを使ってる人はSQLも必須スキル
つhttp://www.amazon.co.jp/dp/4798115169/
SQLより速くてインピーダンスミスマッチのないORMがあったら教えて！＞＜
分類 / 基礎となる計算モデル / 例
1. 手続型言語 / チューリングマシン / C, Java
2. 問合せ言語 / 関係モデル / SQL
3. 関数型言語 / ラムダ計算 / Lisp, Haskell
4. 論理型言語 / 一階述語言語 / Prolog
（2～4は、非手続型言語）
↑1～4のどれでも使えるようにしておいた方がいいよ
＝RDBを使ってる人はSQLも必須スキル
つhttp://www.amazon.co.jp/dp/4798115169/
うーんなんだろ。全然違う部分で話しちゃってるのは自覚してる
「SQL」って言っちゃうと、結局最終的に「文字列」に落とし込まなきゃいけないのが
違和感があるのかも
メソッドの引数とかオブジェクトのプロパティとかなら抵抗ないのに・・・
PerlやRubyで /\A"[^"]+"\z/ みたいなリテラルで書くことの出来る正規表現を、
文字列として "/\\A\"[^\"]\"\\z$/" って書かなきゃいけない歯がゆさみたいなｗ
だから、変数的な部分をプレースホルダにしたprepare(), execute() インターフェイスが
あれば、それで良いのか。それなら、変数的な部分以外はけっこうソリッドに組み立て
られる、と考えて・・・でも、やっぱりパラメータの数が変わったらプレースホルダの数も
変わるし・・・
いかに簡単にSQLを組み立てるかっていうツールとしてのモデルの効能が、あんまり
問題になっていないから書いてみたっていうだけ。低レベルだとは思うけど
「SQL」って言っちゃうと、結局最終的に「文字列」に落とし込まなきゃいけないのが
違和感があるのかも
メソッドの引数とかオブジェクトのプロパティとかなら抵抗ないのに・・・
PerlやRubyで /\A"[^"]+"\z/ みたいなリテラルで書くことの出来る正規表現を、
文字列として "/\\A\"[^\"]\"\\z$/" って書かなきゃいけない歯がゆさみたいなｗ
だから、変数的な部分をプレースホルダにしたprepare(), execute() インターフェイスが
あれば、それで良いのか。それなら、変数的な部分以外はけっこうソリッドに組み立て
られる、と考えて・・・でも、やっぱりパラメータの数が変わったらプレースホルダの数も
変わるし・・・
いかに簡単にSQLを組み立てるかっていうツールとしてのモデルの効能が、あんまり
問題になっていないから書いてみたっていうだけ。低レベルだとは思うけど
いいだろ文字列で。どうせ大したもん作ってねぇくせにぐだぐだ言うな
ORマッパーが流行った理由は2つあると思う。
1つはJOINを駆使したりサブクエリーを使うような、（比較的）高度なSQLを書ける人が少なかった。（複雑な処理はホスト言語で処理する。）
もう1つはORマッパー＝オブジェクト指向を連想させ、オブジェクト指向って言葉だけをやたらもてはやすような風潮に乗っかった。
1つはJOINを駆使したりサブクエリーを使うような、（比較的）高度なSQLを書ける人が少なかった。（複雑な処理はホスト言語で処理する。）
もう1つはORマッパー＝オブジェクト指向を連想させ、オブジェクト指向って言葉だけをやたらもてはやすような風潮に乗っかった。
O/Rマッパーで書けるような簡単な処理は
SQLで書いてもすぐ書ける罠
SQLで書いてもすぐ書ける罠
結局、O/Rマッパーは、SQLに慣れてる人なら
あまり意味ないってことでいい？
あまり意味ないってことでいい？
なんだかんだ言って、Java的な発想なんだろ？＞ ORマッパ
ActiveRecordとかはシンプルでいいと思うけど、やりすぎ感っての？あるんじゃね？
APIが全てで、文字列としてのSQLを流し込むっていう感覚があんまり無いって感じで。
（C#とかの.net系でもO/Rマッパって使うのならごめん）
でも、PHPになじむかどうかは別問題なんだろうとは思う
ActiveRecordとかはシンプルでいいと思うけど、やりすぎ感っての？あるんじゃね？
APIが全てで、文字列としてのSQLを流し込むっていう感覚があんまり無いって感じで。
（C#とかの.net系でもO/Rマッパって使うのならごめん）
でも、PHPになじむかどうかは別問題なんだろうとは思う
DBとベタベタにしないためにラッパー書くのは無駄じゃないと思うけどね
>>532
私見だけど、メモリ中のオブジェクトをそのまま永続化させて使用するための
手段として RDBへの格納するのが良いのではないかっていう考え方があって、
でも現実には永続化よりもデータベース的な検索のほうが重要なことがはっきりして、
結局ラッパーとしてだけ生き残ったって感じではないかと思う。
まぁ、そうした抜け殻のようなツールとし出来上がった後、現場では >>532みたいなな
流れで流行ったんじゃないかと。
私見だけど、メモリ中のオブジェクトをそのまま永続化させて使用するための
手段として RDBへの格納するのが良いのではないかっていう考え方があって、
でも現実には永続化よりもデータベース的な検索のほうが重要なことがはっきりして、
結局ラッパーとしてだけ生き残ったって感じではないかと思う。
まぁ、そうした抜け殻のようなツールとし出来上がった後、現場では >>532みたいなな
流れで流行ったんじゃないかと。
>>528
>とりあえず、外部からの入力値を元にしたSQLの動的な組み立てを自分でする気には
>あんまりならないんだが、モデルってそういう所の面倒をみるってことはそんなに重視
>されてないの？
思うに、「フレームワークのパワーを生かした」開発においては、そういう小難しいことは、
基本的にやらない、もしくは極力避けるんじゃないかね。
フレームワークが力を発揮するのは、単機能な画面が多数あるようなシステムだと思う。
そうした前提においては、動的なSQLを嫌ったとしても、それは普通な判断だと思うし。
>とりあえず、外部からの入力値を元にしたSQLの動的な組み立てを自分でする気には
>あんまりならないんだが、モデルってそういう所の面倒をみるってことはそんなに重視
>されてないの？
思うに、「フレームワークのパワーを生かした」開発においては、そういう小難しいことは、
基本的にやらない、もしくは極力避けるんじゃないかね。
フレームワークが力を発揮するのは、単機能な画面が多数あるようなシステムだと思う。
そうした前提においては、動的なSQLを嫌ったとしても、それは普通な判断だと思うし。
PHPTALというのがあってだな。
http://tracfort.jp/projects/symfony-phptal
http://tracfort.jp/projects/symfony-phptal
>>525
いや、sfSmartyViewPluginは間違いなくsymfonyにとって改悪だと思うわ。
>>526
権限と責任が乖離している時点で、体制を考え直すべきだよ。
仮に、よほど信用出来なくて悪意があってとても偉いデザイナーと仕事をしてるとしても、
MVCやORMという概念や、symfonyやsmartyという実装は、
プログラマーとデザイナーの「責任の所在」を明らかにするための方法論では無いと思う。
>>528
俺はORMには否定的だけど、SQLを抽象化する事には肯定的。
いや、sfSmartyViewPluginは間違いなくsymfonyにとって改悪だと思うわ。
>>526
権限と責任が乖離している時点で、体制を考え直すべきだよ。
仮に、よほど信用出来なくて悪意があってとても偉いデザイナーと仕事をしてるとしても、
MVCやORMという概念や、symfonyやsmartyという実装は、
プログラマーとデザイナーの「責任の所在」を明らかにするための方法論では無いと思う。
>>528
俺はORMには否定的だけど、SQLを抽象化する事には肯定的。
自分がsmarty使うかと言えば使わないが
因習的に使い続けてるところもあるだろ
そういうところのために出来ただけじゃねーの>smartyplugin
いちいち目くじら立てるようなものでもない思うが
因習的に使い続けてるところもあるだろ
そういうところのために出来ただけじゃねーの>smartyplugin
いちいち目くじら立てるようなものでもない思うが
>>541
うん。>>484が偉そうにsymfony+smartyが完璧だと言ってたので、
そりゃねーよ、って反論してるだけだ。
よく考えればスレ違いな主張に相手してる気がするので、smartyに構うのは以後控えるわ。
うん。>>484が偉そうにsymfony+smartyが完璧だと言ってたので、
そりゃねーよ、って反論してるだけだ。
よく考えればスレ違いな主張に相手してる気がするので、smartyに構うのは以後控えるわ。
>>524
>> プロジェクト内にテンプレート側にがちごりでロジック書くウンコいたらどうすんの？
>
>クビにするべきだろう。
大賛成。お金をもらう仕事に、なんでウンコな人間を混ぜなきゃいけないの?
>たぶんプログラムに制限を課すより、体制を考えなおしたほうがいいと思うぞ。
そうそう。それができない環境はプロとして仕事すべきじゃない。
>>526
> 本当にプログラマ？
> すぐクビにするとかテンプレート渡す＝責任を渡すとか
> 到底社会人の発想とは思えないんだが。
なんで? 使えない人間は教育し、それでも使えなければクビでいいじゃん。あんたどこの公務員よ?
> サンデープログラマや、開発者とデザイナが分かれてない業務しかやったことないのを否定はしないが、
> 分業化されてるプロジェクトの場合も想像できないと、この話を進めるのは無理だと思う。
分業することと、ウンコを混ぜる話は別だろ。それをいっしょくたにしているおまえがウンコ。
>> プロジェクト内にテンプレート側にがちごりでロジック書くウンコいたらどうすんの？
>
>クビにするべきだろう。
大賛成。お金をもらう仕事に、なんでウンコな人間を混ぜなきゃいけないの?
>たぶんプログラムに制限を課すより、体制を考えなおしたほうがいいと思うぞ。
そうそう。それができない環境はプロとして仕事すべきじゃない。
>>526
> 本当にプログラマ？
> すぐクビにするとかテンプレート渡す＝責任を渡すとか
> 到底社会人の発想とは思えないんだが。
なんで? 使えない人間は教育し、それでも使えなければクビでいいじゃん。あんたどこの公務員よ?
> サンデープログラマや、開発者とデザイナが分かれてない業務しかやったことないのを否定はしないが、
> 分業化されてるプロジェクトの場合も想像できないと、この話を進めるのは無理だと思う。
分業することと、ウンコを混ぜる話は別だろ。それをいっしょくたにしているおまえがウンコ。
ORマッパーが流行った理由は3つあると思う。
1つはJOINを駆使したりサブクエリーを使うようなSQLから生成されるデータを扱うにはハッシュの配列では使いにくかった。
SQLには方言があり簡単な文でさえダブルクォーテーションとクォーテーションの意味が違うなど複数のDBMSに対応しづらかった。
もう1つはORマッパー＝オブジェクト指向であり、ただのデータの出し入れに過ぎないSQLに様々な付加価値をつけることが出来た
（たとえばバリエーションなど）
1つはJOINを駆使したりサブクエリーを使うようなSQLから生成されるデータを扱うにはハッシュの配列では使いにくかった。
SQLには方言があり簡単な文でさえダブルクォーテーションとクォーテーションの意味が違うなど複数のDBMSに対応しづらかった。
もう1つはORマッパー＝オブジェクト指向であり、ただのデータの出し入れに過ぎないSQLに様々な付加価値をつけることが出来た
（たとえばバリエーションなど）
>>543
厨房乙。
厨房乙。
>>545
あまり恥ずかしい書き込みをするなよ。
>>544
それは全部PDOの利点でもあると思う。
PDO != ORMなので、ORMの利点だとは言えないと思う。
CreoleとPropelの違いを理解した上で、
Propelの機能として好ましいと感じる部分は、
propel-generate-modelとBasePeerのクエリ生成部分かな。
BasePeerははっきり言って複雑なSQLは全く書けないけど、
でもまあ、そのあたりの機能だけ流行れば良かったのに、と思うよ。
あまり恥ずかしい書き込みをするなよ。
>>544
それは全部PDOの利点でもあると思う。
PDO != ORMなので、ORMの利点だとは言えないと思う。
CreoleとPropelの違いを理解した上で、
Propelの機能として好ましいと感じる部分は、
propel-generate-modelとBasePeerのクエリ生成部分かな。
BasePeerははっきり言って複雑なSQLは全く書けないけど、
でもまあ、そのあたりの機能だけ流行れば良かったのに、と思うよ。
さくさく人材切る大量と度量があるのはいいことだが
首にできる権限がある奴に限って現場見てねえんだよなぁ
首にできる権限がある奴に限って現場見てねえんだよなぁ
俺俺form処理クラス書いてるが
フォーム要素が多次元配列になる時のバリデーションが
きれいに書けないよう・・・
値はコンポジットパターンになるのに
errorはchildだけじゃなくて親も持つとか複雑過ぎ
フォーム要素が多次元配列になる時のバリデーションが
きれいに書けないよう・・・
値はコンポジットパターンになるのに
errorはchildだけじゃなくて親も持つとか複雑過ぎ
>>546
544はPDOの利点ではない。PDOはフェッチしたデータの加工をしないし、SQLの方言の抽象化もしない。
544はPDOの利点ではない。PDOはフェッチしたデータの加工をしないし、SQLの方言の抽象化もしない。
SQLの結果セットは2次元の表にしかなり得ない。連想配列ですべて解決する。
Rubyは引数が一つの時()を省略できるのに
PHPは省略できないんですかぁ？
ださーい
PHPは省略できないんですかぁ？
ださーい
Rubyでもできますよーだ
VBなんて中二みたいの名前の言語使いませんよぉ
ださーい
VBなんて中二みたいの名前の言語使いませんよぉ
ださーい
>>550
返ってくるデータが二次元の表だけって面倒だよね。
たとえばアドレス帳があったとして、電話番号を複数登録できるようにしたい。
まあ、普通は正規化する。んで、それを取得すると
ID, 名前, 電話番号ID, 電話番号
1, 山田, 1, 090-0000-0000
1, 山田, 2, 090-0000-0001
1, 山田, 3, 090-0000-0002
2, 佐藤, 4, 090-0001-0000
2, 佐藤, 5, 090-0001-0001
2, 佐藤, 6, 090-0001-0002
こうなる。階層的に取得できたらどんなに使いやすいか。
返ってくるデータが二次元の表だけって面倒だよね。
たとえばアドレス帳があったとして、電話番号を複数登録できるようにしたい。
まあ、普通は正規化する。んで、それを取得すると
ID, 名前, 電話番号ID, 電話番号
1, 山田, 1, 090-0000-0000
1, 山田, 2, 090-0000-0001
1, 山田, 3, 090-0000-0002
2, 佐藤, 4, 090-0001-0000
2, 佐藤, 5, 090-0001-0001
2, 佐藤, 6, 090-0001-0002
こうなる。階層的に取得できたらどんなに使いやすいか。
()が省略できる言語は
ダサいって流れじゃないのか？ｗ
VBやRubyはダサい。
ダサいって流れじゃないのか？ｗ
VBやRubyはダサい。
できるかどうかならできた方が当然良い
関数と変数の区別をはっきりつけたいから使おうとは思わないけど
関数と変数の区別をはっきりつけたいから使おうとは思わないけど
きっちりルール決めて統一してくれたほうがいい、って意見もあると思うぜ
その辺はコーディング規約でやるべきじゃないの？
いろんな人がいるだろうし
いろんな人がいるだろうし
>>554
PDO使えばできる
PDO使えばできる
あれは賛否両論だろ。
引数省略に付随する問題も一緒に抱えるのに
手放しで喜ぶ馬鹿は死んだほうがいい
引数省略に付随する問題も一緒に抱えるのに
手放しで喜ぶ馬鹿は死んだほうがいい
>>559
できねーよ
できねーよ
>>561
できるーよ
できるーよ
>>554
それがリレーショナルDBだから。
オブジェクトで扱いたいなら、ORMじゃなくって、OODBを使えばいいんだよ。誰も使ってないけど。
もっともその例って、単なる配列のデータ構造を表してるだけで、オブジェクトとは関係ないと思うけど。
それがリレーショナルDBだから。
オブジェクトで扱いたいなら、ORMじゃなくって、OODBを使えばいいんだよ。誰も使ってないけど。
もっともその例って、単なる配列のデータ構造を表してるだけで、オブジェクトとは関係ないと思うけど。
>>563
そりゃ、元のレスが
> 連想配列ですべて解決する。
だからだろうね。
RDBの結果なら連想配列で全て表すことができるっていうだけの書き込みに対して、
それが便利なのか？っていうつっこみなんだろうと思った。
>>554が例に挙げてる様なデータなら、多次元の配列で処理する人も多いだろうし
O/Rマッパとはまた違う次元の話の様な気もするｗ
そりゃ、元のレスが
> 連想配列ですべて解決する。
だからだろうね。
RDBの結果なら連想配列で全て表すことができるっていうだけの書き込みに対して、
それが便利なのか？っていうつっこみなんだろうと思った。
>>554が例に挙げてる様なデータなら、多次元の配列で処理する人も多いだろうし
O/Rマッパとはまた違う次元の話の様な気もするｗ
というか、そんな陳腐な工夫を語れるような小さくて整ったデータベースしか扱ってないんだな、おまえら。
PHPですよ？しかも（主に配布されてる）フレームワークのスレ。
そんなに複雑でビジネスロジックとその他もろもろの制約によって
アドホックばりばりのシステムの話なんてするところじゃないじゃ無いか
そんなに複雑でビジネスロジックとその他もろもろの制約によって
アドホックばりばりのシステムの話なんてするところじゃないじゃ無いか
PHPでビジネスロジックや「そのたもろもろ」の制約を必要とするよーな設計するか？
そういう制約が意味あるのって、DB専門班とぎっちぎちに分業するようなケースだしなあ。
null拒否くらいならデバッグの意味はあると思うけど
PHPみたいな上層で使うモンなら正規形も凝らんでそ
制約意識するくらいなら処理ロジックや自前キャッシュ手法に凝った方が百倍マシ
PHPが生かせるケースじゃない
なんか元コメ辿ると、bindやprepare使えば十分だろ的な思惑も感じるけど
そういう制約が意味あるのって、DB専門班とぎっちぎちに分業するようなケースだしなあ。
null拒否くらいならデバッグの意味はあると思うけど
PHPみたいな上層で使うモンなら正規形も凝らんでそ
制約意識するくらいなら処理ロジックや自前キャッシュ手法に凝った方が百倍マシ
PHPが生かせるケースじゃない
なんか元コメ辿ると、bindやprepare使えば十分だろ的な思惑も感じるけど
言語で設計が決まるわけじゃない
むずかしいことばのかいせつ
アドホック - Wikipedia
http://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%89%E3%83%9B%E3%83%83%E3%82%AF
アドホック（ad hoc)は、「特定の目的のための」「限定目的の」などといった意味のラテン語の語句である。
ヨーロッパ諸語では様々な語句と組み合わせて用いられている。
ad hoc quering アドホック・クエリ
情報科学分野の用語。
アドホック・クエリを使えば、カスタマイズされたクエリを簡単に作成することが可能になる。
通常、データベースの原理やSQL 文を深く理解していなくても、GUIを使って行うことができる環境が提供されている。
ただし、このような方式のクエリが多用されるとデータベース システム全体のパフォーマンスにも影響が出かねないため、直接に"生"のデータベースを対象とするのではなく、"生"のデータベースを定期的に複製したものを対象にクエリを作成する、というようなことも行われる。
そのような複製は「データウェアハウス」などと呼ばれることもある。
アドホック - Wikipedia
http://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%89%E3%83%9B%E3%83%83%E3%82%AF
アドホック（ad hoc)は、「特定の目的のための」「限定目的の」などといった意味のラテン語の語句である。
ヨーロッパ諸語では様々な語句と組み合わせて用いられている。
ad hoc quering アドホック・クエリ
情報科学分野の用語。
アドホック・クエリを使えば、カスタマイズされたクエリを簡単に作成することが可能になる。
通常、データベースの原理やSQL 文を深く理解していなくても、GUIを使って行うことができる環境が提供されている。
ただし、このような方式のクエリが多用されるとデータベース システム全体のパフォーマンスにも影響が出かねないため、直接に"生"のデータベースを対象とするのではなく、"生"のデータベースを定期的に複製したものを対象にクエリを作成する、というようなことも行われる。
そのような複製は「データウェアハウス」などと呼ばれることもある。
アドホックとは - はてなダイアリー
http://d.hatena.ne.jp/keyword/%A5%A2%A5%C9%A5%DB%A5%C3%A5%AF
アドホック あどほっく
【ad hoc(羅)】取ってつけたようであるさま。
この意味より，「恒久的でない」とか「反復的でない」ような形容に使われる
http://d.hatena.ne.jp/keyword/%A5%A2%A5%C9%A5%DB%A5%C3%A5%AF
アドホック あどほっく
【ad hoc(羅)】取ってつけたようであるさま。
この意味より，「恒久的でない」とか「反復的でない」ような形容に使われる
>>562
どうやって？サンプルコード示して。
どうやって？サンプルコード示して。
マニュアル読めーよ
ま、そーやって逃げるのは分かってたからいいけど
低脳おーつ
お前、ほんと残念なやつだな
しょーもない煽りあいｗｗｗ
反応するおまえもだよｗ
PEAR使う時ってラップしたクラス書く？
そのまま使う？
そのまま使う？
時と場合によーる
PDOで階層構造表現できるの？まじ？
マジ。ただし、O/Rマッパーが必要
O/Rマッパー最高！！！
という流れですね。わかります。
O/Rマッパー最高！！！
という流れですね。わかります。
>>549
そうだね。
「ハッシュの配列では扱いにくい」と言ってるってことは、
PDOが連想配列で返すのを不便だと感じているという事だもんね。
俺は>>550と同意見だった。
オブジェクトが返ってくる事自体にまったく利点を感じないのだ。
データベースエンジンの差異を吸収するのはORMの副産物だと思うし、
それをやってくれるORMじゃないライブラリは好きなので、
やっぱり俺は世にあるORMにはあまり意義を感じていないのかも知れない。
バリエーションって何？
そうだね。
「ハッシュの配列では扱いにくい」と言ってるってことは、
PDOが連想配列で返すのを不便だと感じているという事だもんね。
俺は>>550と同意見だった。
オブジェクトが返ってくる事自体にまったく利点を感じないのだ。
データベースエンジンの差異を吸収するのはORMの副産物だと思うし、
それをやってくれるORMじゃないライブラリは好きなので、
やっぱり俺は世にあるORMにはあまり意義を感じていないのかも知れない。
バリエーションって何？
オブジェクト指向で分析→設計→実装するとき、オブジェクト指向プログラミングの形とマッチしますね。
http://itpro.nikkeibp.co.jp/article/lecture/20070419/268987/
モデリングの過程がオブジェクト指向じゃないと、あまり劇的に便利という実感は湧かないかな？
http://itpro.nikkeibp.co.jp/article/lecture/20070419/268987/
モデリングの過程がオブジェクト指向じゃないと、あまり劇的に便利という実感は湧かないかな？
>>583
RailsのARとか使ったことあるの？
RailsのARとか使ったことあるの？
公開されたキモゲータウンのフレームワークがPerlで作られててPHP脂肪ｗｗｗ
むしろ歓喜しているように見える
ひさびさに脂肪ネタ来たｗ
CSSもDRYを求められるよな
単にデザインセンスだけでなくプログラマ的な素養が必要
お前らのデザイナはDRYでびゅーちふるなCSSを書けるの？
それともお前らが手直しするの？
単にデザインセンスだけでなくプログラマ的な素養が必要
お前らのデザイナはDRYでびゅーちふるなCSSを書けるの？
それともお前らが手直しするの？
なんでそれをこのスレで聞くん？
>>590
因みに俺のところでは手直しも指導も回答も全部俺がやっている。
つうか、エディタを使う作業は、たいがい俺に回ってくる。
一度も書いたことがないASをいきなり書けたら天才呼ばわりされた。
ほとんど使わないエクセルでマクロをいきなり書いたときもそうだった。
冗談じゃない、感心するなら金くれと言いたい。
うぇぶでざいなー（笑）の100倍は貰って当然だろ、本気で。
因みに俺のところでは手直しも指導も回答も全部俺がやっている。
つうか、エディタを使う作業は、たいがい俺に回ってくる。
一度も書いたことがないASをいきなり書けたら天才呼ばわりされた。
ほとんど使わないエクセルでマクロをいきなり書いたときもそうだった。
冗談じゃない、感心するなら金くれと言いたい。
うぇぶでざいなー（笑）の100倍は貰って当然だろ、本気で。
DBの結果セットをそのままクラスにするなんてJava屋の発想だな。もしくはアカデミックな人の発想だ。実戦的じゃない。
ウェブアプリって、一覧画面なら連想配列の配列、詳細画面なら連想配列でDBから情報を取得して、HTMLという静的な状態に移す、ほとんどはそれで済む話。
複雑なロジックを伴うクラスが必要な場合だけクラスにすればいい。そういうクラスはDBからだけで構成されるわけじゃない。ORMからさらにDAOと2重にラップする必要はない。
ウェブアプリって、一覧画面なら連想配列の配列、詳細画面なら連想配列でDBから情報を取得して、HTMLという静的な状態に移す、ほとんどはそれで済む話。
複雑なロジックを伴うクラスが必要な場合だけクラスにすればいい。そういうクラスはDBからだけで構成されるわけじゃない。ORMからさらにDAOと2重にラップする必要はない。
まあぶっちゃけJavaには連想配列はないから、どうやったってオブジェクトにはなるんだけどな
それをモデルとして便利にする方向はある意味自然か
それをモデルとして便利にする方向はある意味自然か
Zendが身売り準備開始してPHPリアルに脂肪ｗ
これか、
http://jp.techcrunch.com/archives/20080519job-cuts-at-php-startup-zend-could-be-aimed-with-an-eye-towards-a-sale/
PHPそのものはともかく、ZendFrameworkとかは影響うけるかもね。
http://jp.techcrunch.com/archives/20080519job-cuts-at-php-startup-zend-could-be-aimed-with-an-eye-towards-a-sale/
PHPそのものはともかく、ZendFrameworkとかは影響うけるかもね。
買収先「ZendFrameworkぅ？なんだこの糞FWは！？捨てろ！
ってなるに500ペリカ
ZFなんかを使っていた先見の明ない奴ら涙目ｗｗｗ
ってなるに500ペリカ
ZFなんかを使っていた先見の明ない奴ら涙目ｗｗｗ
もしPHPが有料の製品になったらどうする？
俺は捨てるｗｗｗ
俺は捨てるｗｗｗ
なるわけねえだろ。さすがに。
Microsoftが買収したら、なにやらワケが判らぬフレームワークが前提になって、
そのフレームワークの機能はIISでしか動かないみたいなのはあるかもよ。
あぁ、想像しただけで嫌だ。
そのフレームワークの機能はIISでしか動かないみたいなのはあるかもよ。
あぁ、想像しただけで嫌だ。
MSにはASP.NETという洗練されたフレームワーク、VisualStudioという高機能なIDEがある。ガキのおもちゃのようなPHPと一緒にするな。
ASP.NETってどこで使われてるの？
GoogleとかYahooとかAmazonとか楽天とかMixi見たいな大手で。
もちろんMicrosoftのサイトは除いて。
直感だけど、MSのフレームワークが前提になったらPHPは確実に死ぬと思う。
GoogleとかYahooとかAmazonとか楽天とかMixi見たいな大手で。
もちろんMicrosoftのサイトは除いて。
直感だけど、MSのフレームワークが前提になったらPHPは確実に死ぬと思う。
>ASP.NETってどこで使われてるの？
うちJavaに次いで.net/レガシーASP案件が多いよ
でもASPはイントラ用途での案件ばっかりだな
IISに.netにMSSQLにPowerShellにVSSと、MSモノで固めた場合は
けっこういい環境だと思うんだけどねー。
MSモノだけやる訳じゃないせいか、誰もVisual Studio使ってないけどw
つまり、MSモノで固められるケースが限られるのが問題なんだろう。
レン鯖とかでも（Javaともども）機能制限しにくい故にユーザに提供しにくいしな。
その隙間をPHP需要が埋めているんじゃないかい。
うちJavaに次いで.net/レガシーASP案件が多いよ
でもASPはイントラ用途での案件ばっかりだな
IISに.netにMSSQLにPowerShellにVSSと、MSモノで固めた場合は
けっこういい環境だと思うんだけどねー。
MSモノだけやる訳じゃないせいか、誰もVisual Studio使ってないけどw
つまり、MSモノで固められるケースが限られるのが問題なんだろう。
レン鯖とかでも（Javaともども）機能制限しにくい故にユーザに提供しにくいしな。
その隙間をPHP需要が埋めているんじゃないかい。
ASP.NET → PHP.NET
まさかのM$大逆転
まさかのM$大逆転
>>603
結局さ、ASP.NETが良いのってSIerにとってでしかないと思うんよ。
小さく使われる、汎用性がないプログラムとしてと言うか。
そういう前提がなければ PHPなりPythonの方が有用だから、大手のサイトでは
ＰＨＰやPythonなんかが使われてるじゃかなろうかと思ってる。
仮にＭＳに買収されたら、PHPはPHPらしさを残せるかのかなぁ。かなり不安。
結局さ、ASP.NETが良いのってSIerにとってでしかないと思うんよ。
小さく使われる、汎用性がないプログラムとしてと言うか。
そういう前提がなければ PHPなりPythonの方が有用だから、大手のサイトでは
ＰＨＰやPythonなんかが使われてるじゃかなろうかと思ってる。
仮にＭＳに買収されたら、PHPはPHPらしさを残せるかのかなぁ。かなり不安。
VisualBasicの後継はVisualPHPで
どうVisual・・
っていうかDreamWeaverとかじゃねえのそれ
っていうかDreamWeaverとかじゃねえのそれ
ASP.NETくらい作りこまれたフレームワークはない。コミュニティベースのフレームワークとは出来が違う。VisualStudioもそうだけど。
ただ、イントラ以外の、一般のウェブサイトの場合、結局凝ったデザインを実現するための泥臭い部分に多くの労力を割かれるので、ASP.NETのメリットは薄れる。
後は、LAMPみたいに全部無料ではないので、中小規模の場合、LAMPを選択することが増えるだろうな。
ただ、イントラ以外の、一般のウェブサイトの場合、結局凝ったデザインを実現するための泥臭い部分に多くの労力を割かれるので、ASP.NETのメリットは薄れる。
後は、LAMPみたいに全部無料ではないので、中小規模の場合、LAMPを選択することが増えるだろうな。
実際、WEBアプリ業界って言ったら、Windowsサーバに抵抗感があるというか触ったことのない
会社・技術者も多いんだけどね。特にCGI等の設置運用あたりからぽこぽこ出来た会社はｗ
会社・技術者も多いんだけどね。特にCGI等の設置運用あたりからぽこぽこ出来た会社はｗ
泥臭い部分で真価を発揮できない作りこまれたFWとかｗ
そういう仕事を片付けるためのFWじゃねーのかよ
コミュニティベースかそうじゃないかで
出来が云々とかいかにもMSのバカ顧客らしい発想だ
その作りこまれたFWとやらで死ぬまで
綺麗で泥のないアプリを作りつづけてろ
そういう仕事を片付けるためのFWじゃねーのかよ
コミュニティベースかそうじゃないかで
出来が云々とかいかにもMSのバカ顧客らしい発想だ
その作りこまれたFWとやらで死ぬまで
綺麗で泥のないアプリを作りつづけてろ
>>608
想像だけど、 確実にMS は Yahoo みたいな超大規模なところには、ほとんど無料で使えるような
営業をかけてると思う。仮に Yahooのサイトが ASP.NETで運用されれば、広告効果大きいし。
だから、ASP.NETが PHPとかPythonより大規模なサイト構築に向いていれば、使ってないはずがない。
パフォーマンスの問題か、セキュリティに対する透明性の問題か、生産性の問題化は判らんが、
大規模なサイトにおいては ASP.NETは PHPとかPython以下という評価がされているだけだと思う。
中規模なところには普通にしか販売しないだろうから、ASP.NETはイントラみたいな小規模なところでしか
使われない気がする。SIerとしては、そっちのほうがマーケットが広いだろうから、そんなに悪い話でもないけど。
想像だけど、 確実にMS は Yahoo みたいな超大規模なところには、ほとんど無料で使えるような
営業をかけてると思う。仮に Yahooのサイトが ASP.NETで運用されれば、広告効果大きいし。
だから、ASP.NETが PHPとかPythonより大規模なサイト構築に向いていれば、使ってないはずがない。
パフォーマンスの問題か、セキュリティに対する透明性の問題か、生産性の問題化は判らんが、
大規模なサイトにおいては ASP.NETは PHPとかPython以下という評価がされているだけだと思う。
中規模なところには普通にしか販売しないだろうから、ASP.NETはイントラみたいな小規模なところでしか
使われない気がする。SIerとしては、そっちのほうがマーケットが広いだろうから、そんなに悪い話でもないけど。
MS製品はしょっちゅうトロイとか埋め込まれてる印象
いや、大企業ほどIISの比率が高いから。金がかけられるところはJavaやASPが多い。
Apacheが強いのは予算のないところとか、２ちゃんみたいにひたすらウェブサーバの数を増やしたい大規模なサイト。
Apacheが強いのは予算のないところとか、２ちゃんみたいにひたすらウェブサーバの数を増やしたい大規模なサイト。
補足しておくけど、大規模なサイトと予算の大きなサイトは別物だから。
でも結局ネットでビジネスやってるようなシステム運用に詳しくて、大規模なトラフックがあるところは
あんまりASP.NETを使用してないんでしょ？やっぱ本質的な問題があるんじゃないの。
事例見ても、イマイチぱっとしないし。
http://www.microsoft.com/japan/msdn/asp.net/technologyinfo/showcase/
あんまりASP.NETを使用してないんでしょ？やっぱ本質的な問題があるんじゃないの。
事例見ても、イマイチぱっとしないし。
http://www.microsoft.com/japan/msdn/asp.net/technologyinfo/showcase/
実際MSを全面的に信用してる奴は少ないと思うよ。
本質的な問題、とやらがあるのかどうかは判らんけど、
「ソースが公開されてていざとなれば力技が効く」世界とは180度方向性が違うからねえ。
その事例のリード文で処理規模謳ってるのはセガダイレクトくらいか
「.aspx」で終わるURLぐぐるといろいろ出て来るけど、大規模サービスって感じのはないなー。
リネ2のwebとかJR東の運行情報とかパンヤのwebとか地図閲覧サービスとか
まあそれなりに規模あって安定性が望まれるサービスも垣間見れるね。
致命的な弱点があるようには見えないな
オープンソースじゃない事、ってのは一つの理由になると思う。
本質的な問題、とやらがあるのかどうかは判らんけど、
「ソースが公開されてていざとなれば力技が効く」世界とは180度方向性が違うからねえ。
その事例のリード文で処理規模謳ってるのはセガダイレクトくらいか
「.aspx」で終わるURLぐぐるといろいろ出て来るけど、大規模サービスって感じのはないなー。
リネ2のwebとかJR東の運行情報とかパンヤのwebとか地図閲覧サービスとか
まあそれなりに規模あって安定性が望まれるサービスも垣間見れるね。
致命的な弱点があるようには見えないな
オープンソースじゃない事、ってのは一つの理由になると思う。
htmlエスケープどういう方針でしてる？
俺は文字列と、文字列が入った配列を再帰的にエスケープして、
オブジェクトはそのままviewに渡してるけど
俺は文字列と、文字列が入った配列を再帰的にエスケープして、
オブジェクトはそのままviewに渡してるけど
>>617
本質的にはhtmlを生成するときにその場でコンテキストにあわせてエスケープするのが適当だよ。
htmlに入れ込むといってもテキスト要素として入れ込む場合と属性値としてクオートの中に入れるばあいなんかに分かれるから。
本質的にはhtmlを生成するときにその場でコンテキストにあわせてエスケープするのが適当だよ。
htmlに入れ込むといってもテキスト要素として入れ込む場合と属性値としてクオートの中に入れるばあいなんかに分かれるから。
日本はApacheのシェアが高い。
日本は今でもApacheしか対応してないレンタルサーバ屋が多いけど、アメリカは昔からレンタルサーバ屋がIISとApache両方対応してた。
Fortune1000を対象にしたシェア調査が少し前に話題になったけど、大企業のコーポレートサイトなど、予算のかけられるところはJavaやASPが強い。
PHPで名もないウェブサイトしか作ってないと、そういう実感はないだろうけど。
日本は今でもApacheしか対応してないレンタルサーバ屋が多いけど、アメリカは昔からレンタルサーバ屋がIISとApache両方対応してた。
Fortune1000を対象にしたシェア調査が少し前に話題になったけど、大企業のコーポレートサイトなど、予算のかけられるところはJavaやASPが強い。
PHPで名もないウェブサイトしか作ってないと、そういう実感はないだろうけど。
ApacheやLinuxのカーネルハックできる人材なんて、その辺のウェブ屋にはまずいないから。オープンソースか否かなんて関係ない。
誰もWebServerとしてIISが劣るとは言ってないんだが、何を言ってるんだろ。
それにしても2回に分けて書くのは芸風か。
それにしても2回に分けて書くのは芸風か。
>PHPで名もないウェブサイトしか作ってないと、そういう実感はないだろうけど。
↑俺のことですねｗ
Webアプリは、PHPとJavaしか使ってない★
ASP.NETじゃないと実現できない機能は今のところ無し(・∀・)
どうしてもASP.NETじゃないと無理なら手を出しますが、他の実現方法を探すかな？
…というかMS製品しか使っていない客には当たったことないです（ラッキー！？）
↑俺のことですねｗ
Webアプリは、PHPとJavaしか使ってない★
ASP.NETじゃないと実現できない機能は今のところ無し(・∀・)
どうしてもASP.NETじゃないと無理なら手を出しますが、他の実現方法を探すかな？
…というかMS製品しか使っていない客には当たったことないです（ラッキー！？）
大手のSIerではPHPを使う案件はやってないんですか？
大手＝PHPを使わない企業という定義でOKですか？
そんなわけねーだろｗｗｗｗｗｗ
大手＝PHPを使わない企業という定義でOKですか？
そんなわけねーだろｗｗｗｗｗｗ
PHP→名もないウェブサイト→人生負組みのツールでもいいじゃん
自分が便利だと思ったら使えばいい
他人の判断、他人の価値観を気にして、他人に認められたいと思う演技を続ける人生は、勝ち組じゃない
奴隷じゃないなら、最後は自分の判断で決めろ
…俺はRuby、Pythonの準備をしときますｗ
自分が便利だと思ったら使えばいい
他人の判断、他人の価値観を気にして、他人に認められたいと思う演技を続ける人生は、勝ち組じゃない
奴隷じゃないなら、最後は自分の判断で決めろ
…俺はRuby、Pythonの準備をしときますｗ
>>623
Javaなんかだと顧客側が動作環境を WebsphereとかWeblogicに限定してるところ
は多いでしょ。SI案件だとフリーの環境は一切使いたくないってのは普通だし、
そういう客のほうがカネ払いもいいだろうし。
ただ、そういうのは技術的な判断じゃないから、これをもって技術的にも良いはずって
言うのは愚かしいと思う。
Javaなんかだと顧客側が動作環境を WebsphereとかWeblogicに限定してるところ
は多いでしょ。SI案件だとフリーの環境は一切使いたくないってのは普通だし、
そういう客のほうがカネ払いもいいだろうし。
ただ、そういうのは技術的な判断じゃないから、これをもって技術的にも良いはずって
言うのは愚かしいと思う。
>>618
よくいるよな、おまえみたいな無知ｗ
属性値はいわばRCDATAなのでHTMLエスケープに関してはPCDATAと全く違いなし。
現在のほぼ100%のUAが、属性値もエスケープされていることを見込んでパースしている。
よくいるよな、おまえみたいな無知ｗ
属性値はいわばRCDATAなのでHTMLエスケープに関してはPCDATAと全く違いなし。
現在のほぼ100%のUAが、属性値もエスケープされていることを見込んでパースしている。
>>626
618じゃないけど
RCDATA、PCDATAという用語は初めて知った。
参考になったよ、ありがとう
データ形式一覧
http://bakera.jp/ref/html/dataformat
#PCDATA (構文解析対象文字データ) の解説
http://bakera.jp/ref/html/dataformat/pcdata
PCDATA は Parsed Character Data の略で、「構文解析対象文字データ」です。
RCDATA (置換可能文字データ) の解説
http://bakera.jp/ref/html/dataformat/rcdata
Replaceable Character Data、「置換可能文字データ」です。
618じゃないけど
RCDATA、PCDATAという用語は初めて知った。
参考になったよ、ありがとう
データ形式一覧
http://bakera.jp/ref/html/dataformat
#PCDATA (構文解析対象文字データ) の解説
http://bakera.jp/ref/html/dataformat/pcdata
PCDATA は Parsed Character Data の略で、「構文解析対象文字データ」です。
RCDATA (置換可能文字データ) の解説
http://bakera.jp/ref/html/dataformat/rcdata
Replaceable Character Data、「置換可能文字データ」です。
まるごと Ruby! 発売でPHP斜陽の感ありありｗｗｗ
YahooとMicrosoftの仲人はPHP？
PHP on IIS - MicrosoftがPHPをフルサポート
http://www.microsoft.com/japan/opensource/php/default.mspx
【Special Seminar】 PHP on IIS - あなたの可能性を広げる、Windows 環境へ -
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032377878&Culture=ja-JP
PHP on IIS - MicrosoftがPHPをフルサポート
http://www.microsoft.com/japan/opensource/php/default.mspx
【Special Seminar】 PHP on IIS - あなたの可能性を広げる、Windows 環境へ -
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032377878&Culture=ja-JP
P++
>>633
どう違うの
どう違うの
>>634
>>635
http://www.google.co.jp/search?hl=ja&q=javascript+%E3%82%A8%E3%82%B9%E3%82%B1%E3%83%BC%E3%83%97+%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88%E3%83%8F%E3%83%B3%E3%83%89%E3%83%A9&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=
>>635
http://www.google.co.jp/search?hl=ja&q=javascript+%E3%82%A8%E3%82%B9%E3%82%B1%E3%83%BC%E3%83%97+%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88%E3%83%8F%E3%83%B3%E3%83%89%E3%83%A9&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=
テンプレートでデフォルトでhtmlspecialcharsされるようにしてる。
ユーザ入力でタグの中に何かを出力する場合(ほとんど無いけど)は、
ホワイトリスト方式。
ユーザ入力でタグの中に何かを出力する場合(ほとんど無いけど)は、
ホワイトリスト方式。
フレームワークのせいで後々のメンテの度に長時間取られる。
PHPなんて、なーんも考えずに工夫せずにコピペ最強でサクっと済ませられる「フレームワーク」なんだがな。
PHPなんて、なーんも考えずに工夫せずにコピペ最強でサクっと済ませられる「フレームワーク」なんだがな。
規模によるって
話を単純化し過ぎ
話を単純化し過ぎ
そうだよなぁ。
規模がでかいと、謎エラーの出所が分かんない場合あるよね。
何回も呼んでるフレームワークの関数で、止まる時とかさ。
大概人的ミスだから、CVSとかで誰がやったか、すぐにばれるんだがな。
そんな時はブーブー文句垂れるおｗ
規模がでかいと、謎エラーの出所が分かんない場合あるよね。
何回も呼んでるフレームワークの関数で、止まる時とかさ。
大概人的ミスだから、CVSとかで誰がやったか、すぐにばれるんだがな。
そんな時はブーブー文句垂れるおｗ
FW使うとメモリ喰うから
apacheのプロセス数が増えるとメモリが圧迫されてmemcacheが消えるね
一台の鯖で稼働できるプロセス数かなり減らね？
apacheのプロセス数が増えるとメモリが圧迫されてmemcacheが消えるね
一台の鯖で稼働できるプロセス数かなり減らね？
一番メモリ食わない言語って何？
やっぱPerl?
やっぱPerl?
アセンブラ
今時アセンブラでウェブアプリ書いてる奴いるわけねーだろ
はてなもPerlだし、やっぱPerlなのかな？
はてなもPerlだし、やっぱPerlなのかな？
軽いと言われるciですら、現在メモリ700KB
1リクエスト毎にドラクエ4の全容量以上のメモリを食うって一体…
1リクエスト毎にドラクエ4の全容量以上のメモリを食うって一体…
perlも良いフレームワークがあればもっと流行るんじゃない？
まぁ、続きは向こうで。
【Perlフレームワーク】Catalystを語る人
http://pc11.2ch.net/test/read.cgi/php/1168406385/
まぁ、続きは向こうで。
【Perlフレームワーク】Catalystを語る人
http://pc11.2ch.net/test/read.cgi/php/1168406385/
PHPの場合、ウェブフレームワークがすべてのモジュールを内蔵していて、外部に独立してるのはせいぜいSmartyくらいだけど、
Perlの場合、Catalyst含めて、独立したモジュールが集合して構成されるので、PHPのようなウェブフレームワークとは意味が違ってくる。
Perlの場合、Catalyst含めて、独立したモジュールが集合して構成されるので、PHPのようなウェブフレームワークとは意味が違ってくる。
Perlでライブラリとして提供されてるものが
PHPでは関数やエクステンションで提供されてるだけの話で
本質的にはたいして変わりなくね？
PHPでは関数やエクステンションで提供されてるだけの話で
本質的にはたいして変わりなくね？
PHPはテンプレートエンジンもORMも、フレームワークごとにバラバラだから。
なんでSmartyもしくはFlexyを敬遠するのかな、とは思ったことがある。
大体だれかが野良クラスで対応するじゃない。
パフォーマンスにしたって、それ以外の部分でがっつり重いFWも結構あるし。
もうViewクラスを作るのはほぼ共通なんだから、Zendがなんか作ってくれ
ないかな。if と foreach と変数展開（オブジェクトのメソッド呼び出し含む）と、
スクリプトでregisterしたヘルパメソッドのみが使えるとかいう感じで。
PDOみたいに組み込みクラスで速ければ、とりあえず俺は多分それを使う
大体だれかが野良クラスで対応するじゃない。
パフォーマンスにしたって、それ以外の部分でがっつり重いFWも結構あるし。
もうViewクラスを作るのはほぼ共通なんだから、Zendがなんか作ってくれ
ないかな。if と foreach と変数展開（オブジェクトのメソッド呼び出し含む）と、
スクリプトでregisterしたヘルパメソッドのみが使えるとかいう感じで。
PDOみたいに組み込みクラスで速ければ、とりあえず俺は多分それを使う
651 ：nobodyさん：2008/06/08(日) 13:31:14 ID:oe9fgjbi
そこでPECLですよ
一番速いテンプレートエンジンはPHPそのものに決まってるだろ。
PHPそのものだと、構文がテンプレートっぽくない。
BlitzはPHP拡張として作られているから、PHPそのものといえる。
SmartyもPHPそのものに変換されるから、PHPそのものといえる。
BlitzはPHP拡張として作られているから、PHPそのものといえる。
SmartyもPHPそのものに変換されるから、PHPそのものといえる。
ところでPieceFrameworkはフロー定義を書き換えるたびにクッキー消さなきゃならんというガッカリな仕様は直ったのかな？
テンプレートエンジン派ってデザイナにテンプレート書かせてるんだよな？
それ以外にテンプレートエンジン使ってる奴がいたとしたら救いようがないうつけ者だな
それ以外にテンプレートエンジン使ってる奴がいたとしたら救いようがないうつけ者だな
>SmartyもPHPそのものに変換されるから、PHPそのものといえる。
これは違うだろ。うぇぶでざいなあが作る段階でPHPじゃないのだから。
これは違うだろ。うぇぶでざいなあが作る段階でPHPじゃないのだから。
658 ：nobodyさん：2008/06/10(火) 00:15:51 ID:00QPcxQH
よく知らんのだが、「PHPそのもの」って言ってるやつのFWでも、それはあくまで記法だけで、
スコープを確保するためにファイルを読み込んでeval()してそうな気もするんだが、違うのかな。
それとも、グローバルにオブジェクト（や関数）を置いて、それを参照するのを前提にrequireなの？
スコープを確保するためにファイルを読み込んでeval()してそうな気もするんだが、違うのかな。
それとも、グローバルにオブジェクト（や関数）を置いて、それを参照するのを前提にrequireなの？
requireすると、呼び出し場所のローカルスコープで
実行されるので、別にeval()する必要は無かろう。
っていうか、そんなPHPフレームワークあるの?
RoRはerbでevalしてるが。
実行されるので、別にeval()する必要は無かろう。
っていうか、そんなPHPフレームワークあるの?
RoRはerbでevalしてるが。
ZF勉強していて思った。
MVCはいいけど、そのためにいろんな「専用の」クラスの使い方
を覚えなければいけないし、覚えてもZFのみってことは、
別のFWに変更するときや、ZF自体が消滅（ありえない？）するときには、
その資産がチャラになっちまうんじゃないの？
大規模開発に向いている、プログラミングの標準化ができるってのが
ウリだと思うけど、FW乗り換えなんかを考えるとデメリットも大きいよな。
そんなんだったら、自分のシステムに必要なクラスを自分で作って
充実させていったほうがいいのかな．．．．とも思う。
まあ、その維持管理が大変といえば大変だが、資産が消滅することや
方針変更で別のものに作り変えるときでも、ノウハウが残るから、
長期的なスパンでみるとメリットがあるんじゃないのかなあ。
特にシステム開発環境を選択している人、そういう問題点ってどう考えている？
MVCはいいけど、そのためにいろんな「専用の」クラスの使い方
を覚えなければいけないし、覚えてもZFのみってことは、
別のFWに変更するときや、ZF自体が消滅（ありえない？）するときには、
その資産がチャラになっちまうんじゃないの？
大規模開発に向いている、プログラミングの標準化ができるってのが
ウリだと思うけど、FW乗り換えなんかを考えるとデメリットも大きいよな。
そんなんだったら、自分のシステムに必要なクラスを自分で作って
充実させていったほうがいいのかな．．．．とも思う。
まあ、その維持管理が大変といえば大変だが、資産が消滅することや
方針変更で別のものに作り変えるときでも、ノウハウが残るから、
長期的なスパンでみるとメリットがあるんじゃないのかなあ。
特にシステム開発環境を選択している人、そういう問題点ってどう考えている？
>>661
俺俺FWは、俺しか使えない。
他人が使うと、学習コストがかかる。
ましてや、俺と仕事するときにしか使えない。
その点、ZF等のFWは既に学んでいる人々がいる。
その人たちと共同で仕事ができる。
独りでできるもんっ♪なら俺俺でFA
既に学習した人たちのTips等を利用したり、
共同で作業したいなら、
既存のFWでいいんじゃね？
俺俺FWは、俺しか使えない。
他人が使うと、学習コストがかかる。
ましてや、俺と仕事するときにしか使えない。
その点、ZF等のFWは既に学んでいる人々がいる。
その人たちと共同で仕事ができる。
独りでできるもんっ♪なら俺俺でFA
既に学習した人たちのTips等を利用したり、
共同で作業したいなら、
既存のFWでいいんじゃね？
ZFが無くなったときの心配は、ZFが無くなってからすればいいんじゃないか?
大体、オープンソースなんだからZF自体が消えてもコード資産はまるまる残るだろう。
まぁノウハウって奴を蓄積したいのならべつにどうぞ
大体、オープンソースなんだからZF自体が消えてもコード資産はまるまる残るだろう。
まぁノウハウって奴を蓄積したいのならべつにどうぞ
俺俺ラッパー書いてそこからZFなり呼び出すようにしたら
ZFが死んでもなんとかなるじゃん
ZFが死んでもなんとかなるじゃん
>>662
確かに俺俺FWは俺しか使えないけど、共通処理をクラス化したときに、
その内容を整理して文書にすればいいんじゃないのかな。
それ以外は素PHPでいいわけだから、ZFのようにいろいろな制約が
無い分だけPHPを使える人は多いし、知らない人もちょいと学習すれば
使えるようになる。
>>663
ZFが消滅してもオープンソースだから残るだろう。
でもセキュリティホールや新しい技術は一切入ってこないよねえ。
>>664
ラッパーという手はあるが、実際簡単にいく？
確かに俺俺FWは俺しか使えないけど、共通処理をクラス化したときに、
その内容を整理して文書にすればいいんじゃないのかな。
それ以外は素PHPでいいわけだから、ZFのようにいろいろな制約が
無い分だけPHPを使える人は多いし、知らない人もちょいと学習すれば
使えるようになる。
>>663
ZFが消滅してもオープンソースだから残るだろう。
でもセキュリティホールや新しい技術は一切入ってこないよねえ。
>>664
ラッパーという手はあるが、実際簡単にいく？
> でもセキュリティホールや新しい技術は一切入ってこないよねえ。
だからさ、その心配はZFが無くなってからすればいいってこと。
そんなもん心配していまから俺フレームワーク作るわっていうのなら、
セキュリホールだのなんだのはどっちみち全部自分で面倒みるんだろう?
だからさ、その心配はZFが無くなってからすればいいってこと。
そんなもん心配していまから俺フレームワーク作るわっていうのなら、
セキュリホールだのなんだのはどっちみち全部自分で面倒みるんだろう?
> 確かに俺俺FWは俺しか使えないけど、共通処理をクラス化したときに、
> その内容を整理して文書にすればいいんじゃないのかな。
その文章を読まないといけないだろ？
初めて会った人が、あんたが書いたオレオレ文書を
すでに読んでいるなんてことはまずありえない。
その点ZFなら読んでいることはありえる。
> それ以外は素PHPでいいわけだから、ZFのようにいろいろな制約が
オレオレFWの制約を受けるだろう。
何の制約もないフレームワークがあったとしたら、それは
フレームワークじゃなくて、ただのライブラリだ。
> 知らない人もちょいと学習すれば 使えるようになる。
使えるということと、開発の早さ・楽さは別の話。
> でもセキュリティホールや新しい技術は一切入ってこないよねえ。
オレオレFWは、すでにセキュリティホールや新しい技術は一切入ってこないよねえ。
> その内容を整理して文書にすればいいんじゃないのかな。
その文章を読まないといけないだろ？
初めて会った人が、あんたが書いたオレオレ文書を
すでに読んでいるなんてことはまずありえない。
その点ZFなら読んでいることはありえる。
> それ以外は素PHPでいいわけだから、ZFのようにいろいろな制約が
オレオレFWの制約を受けるだろう。
何の制約もないフレームワークがあったとしたら、それは
フレームワークじゃなくて、ただのライブラリだ。
> 知らない人もちょいと学習すれば 使えるようになる。
使えるということと、開発の早さ・楽さは別の話。
> でもセキュリティホールや新しい技術は一切入ってこないよねえ。
オレオレFWは、すでにセキュリティホールや新しい技術は一切入ってこないよねえ。
FW乗り換えたら全てチャラっていう前提がおかしな話
WEBアプリのFW全般に対するノウハウってのもあるし
現に今のFWはほとんどMVCベースなわけで
基本的なコンセプトが大きく変わるわけじゃない
個人的なFWを作って使うのも別に悪くはないと思うけど、
オープンソースで開発されているFWが
どれだけレビューされてテストされた上で
リリースされているかよく考えてみるべき
乗り換えたら全部チャラだし俺俺FWの方がいい、
と安易に考える奴は自惚れてるとしか思えない
FWが変わったら覚えた事が全て無駄になる、ってのは
結局表面的な部分でしかFWを扱えてないわけで
FWに「使われている」プログラマでしかないよ
WEBアプリのFW全般に対するノウハウってのもあるし
現に今のFWはほとんどMVCベースなわけで
基本的なコンセプトが大きく変わるわけじゃない
個人的なFWを作って使うのも別に悪くはないと思うけど、
オープンソースで開発されているFWが
どれだけレビューされてテストされた上で
リリースされているかよく考えてみるべき
乗り換えたら全部チャラだし俺俺FWの方がいい、
と安易に考える奴は自惚れてるとしか思えない
FWが変わったら覚えた事が全て無駄になる、ってのは
結局表面的な部分でしかFWを扱えてないわけで
FWに「使われている」プログラマでしかないよ
いきなり俺俺は無謀だな
一回メジャーなFW使ってみてから手を出すならともかく
一回メジャーなFW使ってみてから手を出すならともかく
オレオレFWを公開して普及させようと言うならともかく、自分に必要な仕組みだけ
自分で作るのが、そんなに悪い選択とは思わないけど。
自分で作るのが、そんなに悪い選択とは思わないけど。
単純にZF死んだら困るから自分で作るよ!っていう理由に納得できないだけだろう。
>>669
FW乗り換えでも、MVCの考え方やノウハウは残るが、
現実的にアプリはすべて書き換え。
数十本ならそうでもないが、1000本単位なら相当な手間。
「FWに使われているプログラマ」はいいけど、現実的に手間を
掛けられないというところをわかってないのは問題。
同じFWに縛られ続けていくのはいいが、消滅しちゃったとき
どうやって資産をメンテしていくのか。
そういう意味でチャラって書いた。
だから >>665 が書いたようにオープンソースであること
を考えると、そういった問題が解決できそうだ。
また多くの人が使ってこなれている面はメリットだよな。
それで、実際どれだけのモンがFWで構築されてんだろ。
cakePHPなんかも有名だが、ZFが出て乗り換えを考える
人もいるだろうし、どうするんだろ。
FW乗り換えでも、MVCの考え方やノウハウは残るが、
現実的にアプリはすべて書き換え。
数十本ならそうでもないが、1000本単位なら相当な手間。
「FWに使われているプログラマ」はいいけど、現実的に手間を
掛けられないというところをわかってないのは問題。
同じFWに縛られ続けていくのはいいが、消滅しちゃったとき
どうやって資産をメンテしていくのか。
そういう意味でチャラって書いた。
だから >>665 が書いたようにオープンソースであること
を考えると、そういった問題が解決できそうだ。
また多くの人が使ってこなれている面はメリットだよな。
それで、実際どれだけのモンがFWで構築されてんだろ。
cakePHPなんかも有名だが、ZFが出て乗り換えを考える
人もいるだろうし、どうするんだろ。
zfに乗り換える人なんていないでしょ
ショボfwじゃん
ショボfwじゃん
どうやって資産をメンテしていくっていうか、
それは普通にソースツリーをフォークしてメンテするだけだろう?
自分でゼロから作るよりは随分と楽だと思うが。
それは普通にソースツリーをフォークしてメンテするだけだろう?
自分でゼロから作るよりは随分と楽だと思うが。
>>673
採用しているFWが変わったからって
既に出来上がってるアプリをそのFWに
全て書き換えるケースなんてそうそう無いだろ
完全な自社コンテンツでアクティブなものか
コンテンツ自体を総リニューアル時に合わせて移行、くらいなもんで
元から運用してるものは普通そのままメンテだろ？
千本単位とかそれこそ非現実的じゃないか？
採用しているFWが変わったからって
既に出来上がってるアプリをそのFWに
全て書き換えるケースなんてそうそう無いだろ
完全な自社コンテンツでアクティブなものか
コンテンツ自体を総リニューアル時に合わせて移行、くらいなもんで
元から運用してるものは普通そのままメンテだろ？
千本単位とかそれこそ非現実的じゃないか？
たとえばsymfony作られたサイト
世界全体でも1000もないだろｗ
世界全体でも1000もないだろｗ
とりあえずDISる
↓
少し釣れる
↓
ツンデレ教えて君
こうするとggrksと言われないんですねわかります
↓
少し釣れる
↓
ツンデレ教えて君
こうするとggrksと言われないんですねわかります
数字おおげさに言い過ぎる
↓
突っ込まれる
↓
雲隠れですねわかります
↓
突っ込まれる
↓
雲隠れですねわかります
>>676
なるほど、すべて書き換えないケースもあるな．．．．
しかし、千本単位が非現実的なら、「大規模開発」って
謳っているのはどのくらいの規模なんだろうか。
>>677が書いたように、事実上PHPのFWはまだまだ
浸透していない、PHPでの開発は結局小規模なもののみ
ってことなんかな。
なるほど、すべて書き換えないケースもあるな．．．．
しかし、千本単位が非現実的なら、「大規模開発」って
謳っているのはどのくらいの規模なんだろうか。
>>677が書いたように、事実上PHPのFWはまだまだ
浸透していない、PHPでの開発は結局小規模なもののみ
ってことなんかな。
>>680
大規模開発って、ふつうプロジェクト数のことじゃなくて、
ユーザ数とか、高信頼性を確保するために大きいシステムを組むってことだろう?
そんなものは、当然一件ごとに何年もかかることがままあるから、
大規模なプロジェクトを千なんてオーダーで抱えてるとこなんてありえないよ。
ていうか、自分が抱えてもいない数のプロジェクトの事と、
(まだつぶれていない)ZFが潰れることを心配して
自分で作った方がいいと思ったの???
大規模開発って、ふつうプロジェクト数のことじゃなくて、
ユーザ数とか、高信頼性を確保するために大きいシステムを組むってことだろう?
そんなものは、当然一件ごとに何年もかかることがままあるから、
大規模なプロジェクトを千なんてオーダーで抱えてるとこなんてありえないよ。
ていうか、自分が抱えてもいない数のプロジェクトの事と、
(まだつぶれていない)ZFが潰れることを心配して
自分で作った方がいいと思ったの???
どれもこれも、今となっては、PHP4で書き続ける理由に説得力が伴っていないわな。
もうとっくに殆どの環境はPHP5に移行している。
lib/php内やフレームワークのコードだけがPHP4。
自分で書く時、例えば、varなんて使う機会が無い。
そのせいで、細かく曖昧さを指摘する目に見えないエラーがリクエスト毎に何10何100と出ている。
もうとっくに殆どの環境はPHP5に移行している。
lib/php内やフレームワークのコードだけがPHP4。
自分で書く時、例えば、varなんて使う機会が無い。
そのせいで、細かく曖昧さを指摘する目に見えないエラーがリクエスト毎に何10何100と出ている。
>>681
>>661 ではないけど、大規模開発って言ったら、コード量をイメージするなぁ。
大規模サイトだと、ユーザ数が多いって意味なのかなぁって感じもするけど。
外部のフレームワークの適用については、例えばバグとかセキュリティホールが
あるからバージョンアップしてくださいって言われても、影響範囲が読めないと
二の足踏むし、かといってそのままってのも気持ち悪いし、自作しても知れてる
程度の使い方しかしないのなら、使いたくないってのは良く分かる。
>>661 ではないけど、大規模開発って言ったら、コード量をイメージするなぁ。
大規模サイトだと、ユーザ数が多いって意味なのかなぁって感じもするけど。
外部のフレームワークの適用については、例えばバグとかセキュリティホールが
あるからバージョンアップしてくださいって言われても、影響範囲が読めないと
二の足踏むし、かといってそのままってのも気持ち悪いし、自作しても知れてる
程度の使い方しかしないのなら、使いたくないってのは良く分かる。
S2Container.PHP5 を勉強しようとセットアップのページ読んでるんですが、解りづらくないですか？
一番初めに書いてあるS2Container.version.tgzを落としてきたら拡張子が.tgになってるし、
＞S2Container.php と S2ContainerSplAutoLoad.php を require して下さい
って何のファイルに書けばいいのか書いてないし・・・。
一番初めに書いてあるS2Container.version.tgzを落としてきたら拡張子が.tgになってるし、
＞S2Container.php と S2ContainerSplAutoLoad.php を require して下さい
って何のファイルに書けばいいのか書いてないし・・・。
>>684
pear installコマンドって、ダウンロードした後、勝手にセットアップまでしてくれんじゃないの？
で、PEARのディレクトリってPHP5を入れた時点でパス通ってて、
ソレを、これから加工と思ってる空のPHPにrequire_onceで例に書いてあるとおりに書けばいいんじゃないの？
違うの？
pear installコマンドって、ダウンロードした後、勝手にセットアップまでしてくれんじゃないの？
で、PEARのディレクトリってPHP5を入れた時点でパス通ってて、
ソレを、これから加工と思ってる空のPHPにrequire_onceで例に書いてあるとおりに書けばいいんじゃないの？
違うの？
>>685
個人的に、pearコマンドを使わないインストール方法をきちんと書いてくれないFWは信用できない。
S2Containerは触ったこと無いけど。
最初からPEAR必須ライブラリも把握できるし、必要最低限の設定等がわかっていれば、環境を
変えるときも対処しやすいと思う
個人的に、pearコマンドを使わないインストール方法をきちんと書いてくれないFWは信用できない。
S2Containerは触ったこと無いけど。
最初からPEAR必須ライブラリも把握できるし、必要最低限の設定等がわかっていれば、環境を
変えるときも対処しやすいと思う
>>683
つまり、アップデートのパッチを調べる労力 > 自分で書く+メンテする労力
ならば自分で書いてもいいってことね。で、コード量が少ないなら
書くのもメンテするのもたいした労力はいらないからそれもあり、と。
まぁそういう理由なら納得できる。
個人的にはFWを導入した時点で自分で書く+メンテしてもいいと思える
コード量を越える気がするけど、そこはまぁヒトそれぞれ。
大規模開発ってやつについては、言うとおりコード量もあると思う。
なんていうか、大規模開発っていうのはプロジェクト一件あたりの
必要な金、期間や人力がデカいっていうことで。
つまり、アップデートのパッチを調べる労力 > 自分で書く+メンテする労力
ならば自分で書いてもいいってことね。で、コード量が少ないなら
書くのもメンテするのもたいした労力はいらないからそれもあり、と。
まぁそういう理由なら納得できる。
個人的にはFWを導入した時点で自分で書く+メンテしてもいいと思える
コード量を越える気がするけど、そこはまぁヒトそれぞれ。
大規模開発ってやつについては、言うとおりコード量もあると思う。
なんていうか、大規模開発っていうのはプロジェクト一件あたりの
必要な金、期間や人力がデカいっていうことで。
688 ：nobodyさん：2008/06/12(木) 13:50:39 ID:5LtH7vFx
JavaもどきのFW使うなら、素直にJava使えばいいと思う
Seaserは簡易版のTeedaに期待
Seaserは簡易版のTeedaに期待
Webのページ上でボタン押したり、何かした時の処理は、
全部 Ajax 経由でいいと思う。
何かする度に、フォームの全ての値がサーバに送られて
画面全体がリロードされるのって変すぎる。
で、Ajaxと一体になってるフレームワークって何かありませんか？
全部 Ajax 経由でいいと思う。
何かする度に、フォームの全ての値がサーバに送られて
画面全体がリロードされるのって変すぎる。
で、Ajaxと一体になってるフレームワークって何かありませんか？
>>689
極端な意見ｷﾀｰ
っていうかそれならもうMS製品で作っちゃえよ・・・
その方向で少し間違えると、キーを押したりマウスを動かしたりするたびにリクエストの発生する
糞サイトになるぞｗ
で、そんなFWはこれから大流行するだろうから、しばらくのんびり待ってたら？AIRとかもあるしね
極端な意見ｷﾀｰ
っていうかそれならもうMS製品で作っちゃえよ・・・
その方向で少し間違えると、キーを押したりマウスを動かしたりするたびにリクエストの発生する
糞サイトになるぞｗ
で、そんなFWはこれから大流行するだろうから、しばらくのんびり待ってたら？AIRとかもあるしね
>>690
作ってて違和感あるんだよね。なんだかばかばかしい。
.NETって言われるだろうなと思ったけど、MSに閉じた技術ってのがね。
Ajaxから戻ってきたデータによって、JavaScriptで画面上の
変化部分を更新するとか、ある程度自動でできる仕組みがあると嬉しい。
更新したデータは、セッション変数で保持してればいい。
かと言って、ブラウザにプラグインが必要になるような技術もいやだな。
今のWebと親和性をなるべく保ちながら、より自然な開発がしたい。
もうちょっと真剣に探してみるかな。
作ってて違和感あるんだよね。なんだかばかばかしい。
.NETって言われるだろうなと思ったけど、MSに閉じた技術ってのがね。
Ajaxから戻ってきたデータによって、JavaScriptで画面上の
変化部分を更新するとか、ある程度自動でできる仕組みがあると嬉しい。
更新したデータは、セッション変数で保持してればいい。
かと言って、ブラウザにプラグインが必要になるような技術もいやだな。
今のWebと親和性をなるべく保ちながら、より自然な開発がしたい。
もうちょっと真剣に探してみるかな。
>>690
>AIRとかもあるしね
あれは勧めちゃいかんわさ。MSの.net以上の勘違い製品。
どうしてもその手の処理が必要な時は
「ユーザに断ってから」Applet立ち上げれば今時でさえ通じるもんだ
他不要
>AIRとかもあるしね
あれは勧めちゃいかんわさ。MSの.net以上の勘違い製品。
どうしてもその手の処理が必要な時は
「ユーザに断ってから」Applet立ち上げれば今時でさえ通じるもんだ
他不要
>>691が感じている違和感がどの辺にあるのかよくわからないけど
サーバサイドはPHPで、クライアントはJavaScriptなりFlash(ActionScript)なりっていうのが
面倒ってこと？
>>691で書いているくらいやりたいことが決まっていれば、例えばW3CとECMAScript標準に
完全準拠の理想フレームワークなら、作ろうと思えば作れるかもね
どのみちデザインのためにHTMLで小細工しなくちゃいけないなら、それがやりにくい様なフォー
ムデータの扱いを強要するFWは結局流行らないだろうと思う
Ajaxを含むJavaScriptやFlashの技術は、まさにクライアント依存の妥協案というか手法というか、
っていう部分なんだから、それをサーバ側の組み方と違うと言って敬遠していては現状何も作れ
ない、とみんなそう思ってるんじゃないかなあ
だから、俺は今日もしこしこ正しいかどうか解らないJavaScriptを書きますよ、と。
サーバサイドはPHPで、クライアントはJavaScriptなりFlash(ActionScript)なりっていうのが
面倒ってこと？
>>691で書いているくらいやりたいことが決まっていれば、例えばW3CとECMAScript標準に
完全準拠の理想フレームワークなら、作ろうと思えば作れるかもね
どのみちデザインのためにHTMLで小細工しなくちゃいけないなら、それがやりにくい様なフォー
ムデータの扱いを強要するFWは結局流行らないだろうと思う
Ajaxを含むJavaScriptやFlashの技術は、まさにクライアント依存の妥協案というか手法というか、
っていう部分なんだから、それをサーバ側の組み方と違うと言って敬遠していては現状何も作れ
ない、とみんなそう思ってるんじゃないかなあ
だから、俺は今日もしこしこ正しいかどうか解らないJavaScriptを書きますよ、と。
>>693
違和感ってのは、>>689に書いた内容です。
画面の一部を変更したい時でも、画面全体に影響があるので、
プログラムがそれを考慮した構造になり、分かりにくいものになってしまいます。
GETとPOSTを分けたりすると、更に分かりにくくなります。
WindowsのGUIプログラミングのような開発ができたらいいなと。
イベントドリブンで感じで。
サーバサイド言語 + JavaScript (Ajax含む) でそういう仕組み
になってるフレームワークがないかなと思ったんですよね。
今の自分の作り方が悪いだけかもしれませんが。
違和感ってのは、>>689に書いた内容です。
画面の一部を変更したい時でも、画面全体に影響があるので、
プログラムがそれを考慮した構造になり、分かりにくいものになってしまいます。
GETとPOSTを分けたりすると、更に分かりにくくなります。
WindowsのGUIプログラミングのような開発ができたらいいなと。
イベントドリブンで感じで。
サーバサイド言語 + JavaScript (Ajax含む) でそういう仕組み
になってるフレームワークがないかなと思ったんですよね。
今の自分の作り方が悪いだけかもしれませんが。
>>694
イベントドリブンって言葉だけに反応すると、
PRADOとか、PHPのフレームワークはイベントドリブンらしいよ。
後、Ajaxだと、AjaxCoreとかってフレームワークがあるみたいだけど、ここら辺組み合わせたらなんかできるのかな。
イベントドリブンって言葉だけに反応すると、
PRADOとか、PHPのフレームワークはイベントドリブンらしいよ。
後、Ajaxだと、AjaxCoreとかってフレームワークがあるみたいだけど、ここら辺組み合わせたらなんかできるのかな。
まあ、HTTPやHTMLはビジネスアプリケーションを実装するために考えられたものじゃないからな。
Windowsフォームのアプリケーションと同じことをウェブに求めるのは無理がある。
凝ったウェブデザイン（というか、普通のエンドユーザ向けウェブサイトで求められるデザイン）を、DOMによるCSSの操作だけでデザイン対応するのは相当無理がある。
そこまで機能性を求められるアプリなら、.ウェブアプリじゃなくてNETのアプリにするのが妥当と思うし、マルチプラットフォームにしたいならJavaでも使えばいいと思う。
Windowsフォームのアプリケーションと同じことをウェブに求めるのは無理がある。
凝ったウェブデザイン（というか、普通のエンドユーザ向けウェブサイトで求められるデザイン）を、DOMによるCSSの操作だけでデザイン対応するのは相当無理がある。
そこまで機能性を求められるアプリなら、.ウェブアプリじゃなくてNETのアプリにするのが妥当と思うし、マルチプラットフォームにしたいならJavaでも使えばいいと思う。
向かってねー与。
googleやadobeの動向も知らないのか？
PhotoShopがFirefoxのプラグ印になるといいね。
>>699
kwsk
運用上でも昨今のAjaxライブラリの伏魔殿具合見ても、
けっこ前に壁にぶちあたったきり進歩がないしな。
javascript1.7以上が普及してくれれば、スコープ汚しまくりで
setTimeout地獄な糞Ajaxの現状を打破できるのかもしれないが。
air入れてる奴もsilverlight入れてる奴も見ないしな
Ajaxは割り切って使うに限る。
GoogleはFlashも使ってる。必要に応じて適用してるだけじゃないのかね
kwsk
運用上でも昨今のAjaxライブラリの伏魔殿具合見ても、
けっこ前に壁にぶちあたったきり進歩がないしな。
javascript1.7以上が普及してくれれば、スコープ汚しまくりで
setTimeout地獄な糞Ajaxの現状を打破できるのかもしれないが。
air入れてる奴もsilverlight入れてる奴も見ないしな
Ajaxは割り切って使うに限る。
GoogleはFlashも使ってる。必要に応じて適用してるだけじゃないのかね
muninのグラフ見てたらiowaitで埋まってる時間があるんだけど原因がわからんちん
mysqlのスロークエリみたいに
処理速度が遅ければログ取る機構とか付けてる？
てかそんなのフレームワークの標準機能で付けとけよ
mysqlのスロークエリみたいに
処理速度が遅ければログ取る機構とか付けてる？
てかそんなのフレームワークの標準機能で付けとけよ
HD壊れかけ？
704 ：nobodyさん：2008/06/18(水) 02:05:34 ID:ZYTHmHR0
データが飛んで初めて分かる、バックアップの重要性＞＜
バックアップ？ああ、そういやPHPやってる雑魚どもはSVN使わんな。どいつもこいつもWindowsでeclipseを使いつつ、subclipseを入れてないｗ
何この頭の悪そうな書き込み
お手軽にCVS使って、時々圧縮・暗号化したのをYahooブリーフケースにおいてる。
svnって開発時には使うけど稼働時に使うか？
何この頭悪そうな話題のずれて行き方
PRADOわかる人いる？
712 ：nobodyさん：2008/06/23(月) 10:47:52 ID:isKyS0yI
以前、使ってみた（というか実験してみた）ことある。
以下、個人の感想だが、設計は面白いが、web用のフレームワークとして間違った方向に行ってる気がしたので、実践では使ってない。
フレームワークの勉強をするにはいいとは思うよ。
以下、個人の感想だが、設計は面白いが、web用のフレームワークとして間違った方向に行ってる気がしたので、実践では使ってない。
フレームワークの勉強をするにはいいとは思うよ。
>>712の言うweb用のフレームワークとして間違った方向とか正しい方向とかは意味不明だが、
PRADOは構築ルール縛りをするには良いとおもう。
開発効率は生だとものすごく悪いので、Radを待つか自前でつくるなりしないと使い物にならん。
PRADOは構築ルール縛りをするには良いとおもう。
開発効率は生だとものすごく悪いので、Radを待つか自前でつくるなりしないと使い物にならん。
そういや、Kohanaって話題になったことある？
CIからforkして、PHP5 Strictと安定性・堅牢性を進めると聞いてるけど。
ググっても日本語サイト少ない・・・
CIからforkして、PHP5 Strictと安定性・堅牢性を進めると聞いてるけど。
ググっても日本語サイト少ない・・・
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が無いとか、どうしても実装に何か無理がありそうな気がしてしまう、というのが感想な訳だ。
# バリバリに使ってる人の感想を聞いてみたい所かも？
詳しく書かないでｽﾏﾝ。
自分の感じた事を伝えようと思って、昔実験したサンプルを見ながら今書いてるんで現在のバージョンとは違うかもしれんけど
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が無いとか、どうしても実装に何か無理がありそうな気がしてしまう、というのが感想な訳だ。
# バリバリに使ってる人の感想を聞いてみたい所かも？
Webアプリ、しかもPHPでDelphi丸出しは厳しいものがあるよね
突然すんません。
いまいち『フレームワーク』ってのがわからないんです。
ググって調べたりしてるんだけど、『？』な感じなんです。
すご～くカンタンでいいんで説明してくれる方いませんでしょうか？
あと、こんなオレにおすすめの本あったら紹介して下さい。
プログラムは一応、データベースとか使って基本的なCMSとかつくれます。
今度、作ろうと思ってるサイトがあるんですが、『フレームワーク』ってのを
使った方がいいような感じがしてここへきました。
よろしくお願いします。
いまいち『フレームワーク』ってのがわからないんです。
ググって調べたりしてるんだけど、『？』な感じなんです。
すご～くカンタンでいいんで説明してくれる方いませんでしょうか？
あと、こんなオレにおすすめの本あったら紹介して下さい。
プログラムは一応、データベースとか使って基本的なCMSとかつくれます。
今度、作ろうと思ってるサイトがあるんですが、『フレームワーク』ってのを
使った方がいいような感じがしてここへきました。
よろしくお願いします。
ググれ
>>719
framework
【名】
1. 骨組み｛ほねぐみ｝、フレームワーク、枠組み｛わくぐみ｝、下部構造｛かぶ こうぞう｝、骨格｛こっかく｝
なんか作るときに土台が出来てると楽だろ？
でもその土台に制限されてしまうこともある。
framework
【名】
1. 骨組み｛ほねぐみ｝、フレームワーク、枠組み｛わくぐみ｝、下部構造｛かぶ こうぞう｝、骨格｛こっかく｝
なんか作るときに土台が出来てると楽だろ？
でもその土台に制限されてしまうこともある。
>>721
ありがとうございます。
ググってました。
『車』で例えるとしたら、
”キーを回すとエンジンがかかる”とかの仕組みができていて
一から作らなくてもいいってことなんでしょうか？
『いろんな仕組みのセットがあって、ボタンひとつで簡単に組み込める』
みないな感じですかね…？
ありがとうございます。
ググってました。
『車』で例えるとしたら、
”キーを回すとエンジンがかかる”とかの仕組みができていて
一から作らなくてもいいってことなんでしょうか？
『いろんな仕組みのセットがあって、ボタンひとつで簡単に組み込める』
みないな感じですかね…？
>>722
家を建てるに当たって、その骨組みが出来ているって感じ。
で、その骨組みに合わせて作っていくので、やりやすいよと。
>>722の車の例えだと、PEARとか見たいなライブラリだね。フレームワークではない。
家を建てるに当たって、その骨組みが出来ているって感じ。
で、その骨組みに合わせて作っていくので、やりやすいよと。
>>722の車の例えだと、PEARとか見たいなライブラリだね。フレームワークではない。
>>723
ありがとうございます。
ってことは、一戸建ての骨組みができている状態からスタートして
中身の部屋とかキッチンとかを入れて（？）いく。ような感じ？
フレームワークの違いってのは、その『骨組み』がマンションだったり一戸建て
だったりするってことなんでしょうか？
今、悩んでいるのは、フレームワークを使った方がいいのか、今までのように
普通（？）に作るのがいいのか。という所なんです。
ありがとうございます。
ってことは、一戸建ての骨組みができている状態からスタートして
中身の部屋とかキッチンとかを入れて（？）いく。ような感じ？
フレームワークの違いってのは、その『骨組み』がマンションだったり一戸建て
だったりするってことなんでしょうか？
今、悩んでいるのは、フレームワークを使った方がいいのか、今までのように
普通（？）に作るのがいいのか。という所なんです。
725 ：nobodyさん：2008/06/25(水) 20:34:00 ID:gyu7FUKS
直訳すると枠組み、だと思うんだが、骨組みの方が俺的にもしっくり来るね。
PHPを粘土と例えて、像を作ってみよう、という事になった時の事を考えてみると
いきなり粘土で像を作る事はできると思うが、やっぱり、予め骨組みあった方が作りやすいだろ？
でも、骨組みが、犬の骨組みだとしたら、人間の像を作るのは却って難しいと思う。
>>716
なるほど。という事は現在は大分変わってるのか。
そのうち、また見てみる事にするよ。
PHPを粘土と例えて、像を作ってみよう、という事になった時の事を考えてみると
いきなり粘土で像を作る事はできると思うが、やっぱり、予め骨組みあった方が作りやすいだろ？
でも、骨組みが、犬の骨組みだとしたら、人間の像を作るのは却って難しいと思う。
>>716
なるほど。という事は現在は大分変わってるのか。
そのうち、また見てみる事にするよ。
>>724
そういうところで悩む人は、多分人のソースなんかあんまり読まない様なタイプの
人だろうから、いっぺん使ってみるのは勉強になるんではないかと偏見だけど思う。
まあ業務に使うかどうかは置いておいて、PHPでお仕事しているんなら触って損は
無いかと思う。
そういうところで悩む人は、多分人のソースなんかあんまり読まない様なタイプの
人だろうから、いっぺん使ってみるのは勉強になるんではないかと偏見だけど思う。
まあ業務に使うかどうかは置いておいて、PHPでお仕事しているんなら触って損は
無いかと思う。
こんな抽象的な話を聞いて何が分かるんだろうｗ
>>724
ページの遷移部分だとか、データの検証(バリデーション)部分だとかが簡単に出来たり、
フレームワーク自身が持っているライブラリが便利だったりとか。
データベースへのアクセスに関しては各フレームワーク共に工夫されてて凄く使いやすいです。
＞フレームワークの違いってのは、その『骨組み』がマンションだったり一戸建て
だったりするってことなんでしょうか？
そうですね。「ちいたん」見たいなライトウェイトなフレームワークは一戸建てな感じで、
synfonyやEthnaやCakePHPなんかはマンションみたいな巨大なプロジェクトの開発に向いてるかと。
＞今、悩んでいるのは、フレームワークを使った方がいいのか、今までのように
普通（？）に作るのがいいのか。という所なんです。
フレームワークは、できるなら使ってみたほうがいいと思います。
開発の規模や趣味趣向によって合う合わないってのはあると思いますが、
プログラムを組む上での手法として、勉強になる部分は大きいですし。
とりあえず、賛否両論歩けど、CodeIgniterなんかを触ってみてはいかがでしょう。
日本語のマニュアルが充実しているのと、割かしライトウェイトなので、扱いやすいのではないでしょうか。
ページの遷移部分だとか、データの検証(バリデーション)部分だとかが簡単に出来たり、
フレームワーク自身が持っているライブラリが便利だったりとか。
データベースへのアクセスに関しては各フレームワーク共に工夫されてて凄く使いやすいです。
＞フレームワークの違いってのは、その『骨組み』がマンションだったり一戸建て
だったりするってことなんでしょうか？
そうですね。「ちいたん」見たいなライトウェイトなフレームワークは一戸建てな感じで、
synfonyやEthnaやCakePHPなんかはマンションみたいな巨大なプロジェクトの開発に向いてるかと。
＞今、悩んでいるのは、フレームワークを使った方がいいのか、今までのように
普通（？）に作るのがいいのか。という所なんです。
フレームワークは、できるなら使ってみたほうがいいと思います。
開発の規模や趣味趣向によって合う合わないってのはあると思いますが、
プログラムを組む上での手法として、勉強になる部分は大きいですし。
とりあえず、賛否両論歩けど、CodeIgniterなんかを触ってみてはいかがでしょう。
日本語のマニュアルが充実しているのと、割かしライトウェイトなので、扱いやすいのではないでしょうか。
>>725
ありがとうございます。
>>でも、骨組みが、犬の骨組みだとしたら、人間の像を作るのは却って難しいと思う。
これ気になります…
>>726
ありがとうございます。
自分はまだ、人のソースをじっくり見て分かる所まで行ってないと思います。
なんか、好きなようにしたくて。ソースはかなり変かもしれません。
今『CakePHP』の関連サイトを見てました。
CakePHPってどうでしょうか？
明日、ジュンク堂とか行って関連本探してこようと思います。
ありがとうございます。
>>でも、骨組みが、犬の骨組みだとしたら、人間の像を作るのは却って難しいと思う。
これ気になります…
>>726
ありがとうございます。
自分はまだ、人のソースをじっくり見て分かる所まで行ってないと思います。
なんか、好きなようにしたくて。ソースはかなり変かもしれません。
今『CakePHP』の関連サイトを見てました。
CakePHPってどうでしょうか？
明日、ジュンク堂とか行って関連本探してこようと思います。
730 ：nobodyさん：2008/06/25(水) 20:46:21 ID:gyu7FUKS
下げ忘れた（汗）
>今、悩んでいるのは、フレームワークを使った方がいいのか、今までのように
>普通（？）に作るのがいいのか。という所なんです。
なるほど。フレームワークを学習するのには、コストがかかるからそういう風に悩むのは正しい姿勢だと思うよ。
で、まずは、どれだけの時間があるか？という所をはっきりさせるべきだと思うね。今書いたように「コストがかかる」から。
フレームワークを使わないでもできない事はないレベル & 時間が無い（半年以下）なら、たぶん今まで通り作った方がいいと思う。
（半年、というの人によるかな。でも、最低1ヶ月は学習する時間が欲しい。）
かなり大きなアプリになる予定（設計がまだ未定。先が見えない）& 時間がある、というのなら、なにかフレームワークを使う事を考えた方がいい。
後で付け足す事になったとしても、フレームワークで作ってあると、部品を付け足せるように設計されている（事が多い）からね。
・・・実際のお客様というのは、かなーり想定外の要求してくるから、それでも吸収できないくらいの事を言ってくる事もあるんだがな・・・
>今、悩んでいるのは、フレームワークを使った方がいいのか、今までのように
>普通（？）に作るのがいいのか。という所なんです。
なるほど。フレームワークを学習するのには、コストがかかるからそういう風に悩むのは正しい姿勢だと思うよ。
で、まずは、どれだけの時間があるか？という所をはっきりさせるべきだと思うね。今書いたように「コストがかかる」から。
フレームワークを使わないでもできない事はないレベル & 時間が無い（半年以下）なら、たぶん今まで通り作った方がいいと思う。
（半年、というの人によるかな。でも、最低1ヶ月は学習する時間が欲しい。）
かなり大きなアプリになる予定（設計がまだ未定。先が見えない）& 時間がある、というのなら、なにかフレームワークを使う事を考えた方がいい。
後で付け足す事になったとしても、フレームワークで作ってあると、部品を付け足せるように設計されている（事が多い）からね。
・・・実際のお客様というのは、かなーり想定外の要求してくるから、それでも吸収できないくらいの事を言ってくる事もあるんだがな・・・
もうすでに無駄なコストかかってるんでは
また忘れた（汗）
ってか、みんなレス早いな。
>>でも、骨組みが、犬の骨組みだとしたら
実際には、webアプリの骨組みだから、あまり気にしないで大丈夫だと思う。
まぁ、時間あるならいくつかいじってみて、そのフレームワークの癖を見ておくのもいい勉強になるはず。
（あぁ。結構勉強してそうだからこんな事言っちまったが・・・たぶん、PEARを使いこなせる・・・使えるくらいの力量あるよね？もし無かったとしたら、まずは、ライブラリを使いこなせるようになってから、がいいと思う。）
# Cakeについては、使ってないので他の方に
ってか、みんなレス早いな。
>>でも、骨組みが、犬の骨組みだとしたら
実際には、webアプリの骨組みだから、あまり気にしないで大丈夫だと思う。
まぁ、時間あるならいくつかいじってみて、そのフレームワークの癖を見ておくのもいい勉強になるはず。
（あぁ。結構勉強してそうだからこんな事言っちまったが・・・たぶん、PEARを使いこなせる・・・使えるくらいの力量あるよね？もし無かったとしたら、まずは、ライブラリを使いこなせるようになってから、がいいと思う。）
# Cakeについては、使ってないので他の方に
>>729
CakePHPで一回チュートリアルとか「10分で作る～」とかを見て、一回作っていいかもしれない。
普通にプログラム作ってるだけだったりすると、なんでこんな動きするのか分からないような動きする。
今後、フレームワークを使わないプログラムを書くにしても、凄く勉強になるよ。
CakePHPで一回チュートリアルとか「10分で作る～」とかを見て、一回作っていいかもしれない。
普通にプログラム作ってるだけだったりすると、なんでこんな動きするのか分からないような動きする。
今後、フレームワークを使わないプログラムを書くにしても、凄く勉強になるよ。
>>728
ありがとうございます。
CodeIgniterってのは聞いたことがなかったのでちょっと
見てきます。
>>730
ありがとうございます。
メインはデザイン仕事でやっているので、時間はそれなりに
とれそうです。
自分としても勉強したい部分もあります。
ライブラリに関しては…”使いこなしてる”とまでは…
>>733
ありがとうございます。
>CakePHPで一回チュートリアルとか「10分で作る～」とかを見て、
やっぱりそれが一番かもしれませんね。
>普通にプログラム作ってるだけだったりすると、
なんかコワイですね。
明日本屋行ってきます！
皆さん、いきなりなのに本当にいろいろありがとうございました！
ありがとうございます。
CodeIgniterってのは聞いたことがなかったのでちょっと
見てきます。
>>730
ありがとうございます。
メインはデザイン仕事でやっているので、時間はそれなりに
とれそうです。
自分としても勉強したい部分もあります。
ライブラリに関しては…”使いこなしてる”とまでは…
>>733
ありがとうございます。
>CakePHPで一回チュートリアルとか「10分で作る～」とかを見て、
やっぱりそれが一番かもしれませんね。
>普通にプログラム作ってるだけだったりすると、
なんかコワイですね。
明日本屋行ってきます！
皆さん、いきなりなのに本当にいろいろありがとうございました！
「フレームワークを使えば、アプリケーションを効率よく開発できます」
っていう言葉は、誤解を招く売り文句だと思う。
現実には、フレームワークの内部動作を調べて、
中で何をやってるかだいたい分かるレベルになって初めて
効率よく安全なアプリを自信を持って作れるようになる。
と思うけどな。
っていう言葉は、誤解を招く売り文句だと思う。
現実には、フレームワークの内部動作を調べて、
中で何をやってるかだいたい分かるレベルになって初めて
効率よく安全なアプリを自信を持って作れるようになる。
と思うけどな。
>>735
正しい動作がしないとか、問題が出たときに見ればいいんじゃないのかね。
そのためにチュートリアルとか、マニュアルサイトとかあるわけだし。
PHPやるのに、PHPの関数のソースコードまで読まないでしょ？
正しい動作がしないとか、問題が出たときに見ればいいんじゃないのかね。
そのためにチュートリアルとか、マニュアルサイトとかあるわけだし。
PHPやるのに、PHPの関数のソースコードまで読まないでしょ？
>>736
それはその通りなんだけどね
世の中には、想像を絶するような要求をしてくる人がいたりして、そういう要求を満たす為には・・・という事なんじゃないかな。
普通は、チュートリアルをこなせば（一応）使えるようなレベルにはなるはず。
とはいえ、そのレベルだと、そのフレームワーク臭さ（？）が抜けないアプリしか出来ないけど。
あぁ。現在のPHPのフレームワークはRAD機能がついているのばっかりだから、そういう奴で標準的なアプリを作って試してみるといいんだな。
で、そのフレームワークらしさが気に入ったら使えばいいと。
それはその通りなんだけどね
世の中には、想像を絶するような要求をしてくる人がいたりして、そういう要求を満たす為には・・・という事なんじゃないかな。
普通は、チュートリアルをこなせば（一応）使えるようなレベルにはなるはず。
とはいえ、そのレベルだと、そのフレームワーク臭さ（？）が抜けないアプリしか出来ないけど。
あぁ。現在のPHPのフレームワークはRAD機能がついているのばっかりだから、そういう奴で標準的なアプリを作って試してみるといいんだな。
で、そのフレームワークらしさが気に入ったら使えばいいと。
>>737
ちょっと話題とずれるけど、
http://d.hatena.ne.jp/sotarok/20080422/php_framework_fight
最近、こんなの見つけた。
各フレームワークで同一アプリケーションを作成して、その使いやすさだとか、コーディング量が少ないのがどれか
とかを決めるような大会みたい。
ちょっと話題とずれるけど、
http://d.hatena.ne.jp/sotarok/20080422/php_framework_fight
最近、こんなの見つけた。
各フレームワークで同一アプリケーションを作成して、その使いやすさだとか、コーディング量が少ないのがどれか
とかを決めるような大会みたい。
>>736
PHPのソースコード（C++?）は読まないけど、マニュアルは死ぬほど読む
ヴァージョンの差異もでかいしorz
んで、フレームワークでソースコードを読むのは、PHP程ドキュメントが整備されて
いないから、っていうのが一番大きい気がする。「正しい動作」とか「使い方」が、実は
サンプルを含めてソースを読まなきゃわからない、みたいな。
だから「問題が出たとき」だけソースを読めばいいとは思わない。
というか、それで現行のフレームワークが使える気がしない俺がいる
PHPのソースコード（C++?）は読まないけど、マニュアルは死ぬほど読む
ヴァージョンの差異もでかいしorz
んで、フレームワークでソースコードを読むのは、PHP程ドキュメントが整備されて
いないから、っていうのが一番大きい気がする。「正しい動作」とか「使い方」が、実は
サンプルを含めてソースを読まなきゃわからない、みたいな。
だから「問題が出たとき」だけソースを読めばいいとは思わない。
というか、それで現行のフレームワークが使える気がしない俺がいる
>>736
たまにPHPのソースコード(Cだよ)も読むよ
>>738
そうそう
苦労量保存の法則
でも、覚えてしまえば、品質を保ったままで開発スピード
を上げられるから、やればやるほど楽して儲けられるはず。
たまにPHPのソースコード(Cだよ)も読むよ
>>738
そうそう
苦労量保存の法則
でも、覚えてしまえば、品質を保ったままで開発スピード
を上げられるから、やればやるほど楽して儲けられるはず。
>>740,>>741
なるほど～。
フレームワークってちょろっと眺めてちょっと使ってみる、ぐらいしかしたこと無いわけだけど、
確かに理解しきるのは困難極めそう。
実際、Webで結構出てるPHPフレームワークって、日本の企業さんとかはつかってるところあるのかな？
なるほど～。
フレームワークってちょろっと眺めてちょっと使ってみる、ぐらいしかしたこと無いわけだけど、
確かに理解しきるのは困難極めそう。
実際、Webで結構出てるPHPフレームワークって、日本の企業さんとかはつかってるところあるのかな？
そんなの使いまくりにきまってるやん
企業が使わずしてどこで使うの
企業が使わずしてどこで使うの
大きめの企業でなら、Ethnaとか一時期多かったんじゃない？
さすがにCakePHPやちいたんを使うようなイメージは持ちにくい
まあベンチャーというか中小業者なら、担当者の趣味で半年
単位で採用フレームワークが変わってても驚かない
それをもって企業が使っていると言うのは、抵抗があるけど
さすがにCakePHPやちいたんを使うようなイメージは持ちにくい
まあベンチャーというか中小業者なら、担当者の趣味で半年
単位で採用フレームワークが変わってても驚かない
それをもって企業が使っていると言うのは、抵抗があるけど
フレームワークを使ってない企業の方が少ないだろ
日本で作られたフレームワークは使う気がしない。
やっぱり世界規模で進んでいるものの方が安心だよね。
やっぱり世界規模で進んでいるものの方が安心だよね。
>>746
そーでもない。マルチバイトって何？おいしいの？っていう開発者？も
英米圏にはてんこ盛りだということを忘れてはいけない
だからといって国産が使いやすいわけでも無いけど、日本はそれなりに
良い線いってるんじゃ無いかとも思う。
世界規模にならないのは、コミュニティやドキュメントが英語ベースじゃ
ないからだけじゃね？
そーでもない。マルチバイトって何？おいしいの？っていう開発者？も
英米圏にはてんこ盛りだということを忘れてはいけない
だからといって国産が使いやすいわけでも無いけど、日本はそれなりに
良い線いってるんじゃ無いかとも思う。
世界規模にならないのは、コミュニティやドキュメントが英語ベースじゃ
ないからだけじゃね？
今時UTF8対応じゃないフレームワークは、使う気がしない。
そんなのあるか？
まあメールライブラリはそのまま使えると思わない方が無難
Validationや文字数カウントが入る部分も微妙
UTF-8に限定すれば問題は少ないだろうけどね・・・。
コメントのコピーライト部分のラテン文字が必ず文字化けして
いるのは多分仕様です。・・・奴らはUTF-8使ってるのか？
Validationや文字数カウントが入る部分も微妙
UTF-8に限定すれば問題は少ないだろうけどね・・・。
コメントのコピーライト部分のラテン文字が必ず文字化けして
いるのは多分仕様です。・・・奴らはUTF-8使ってるのか？
ひと昔前までの印象としては欧州産はまだマシで、米国産はI18NとかM17Nとかいう発想が無いのが多かった気がする
752 ：nobodyさん：2008/06/26(木) 19:00:58 ID:0xtx7Zko
ethnaがとっつきやすくてよかった。
必要最小限の機能でやりたい事は全部やれた。
必要最小限の機能でやりたい事は全部やれた。
これからSmartyの仕事にかかる。本当に馬鹿らしい。もうこれでPHPの仕事を最後にしたい。
なるほど。Ethnaとかは使われてるんだね。
自社開発のクローズなフレームワーク使ってるっていう例も多いの？
自社開発のクローズなフレームワーク使ってるっていう例も多いの？
俺はもうPHPを捨てたぜ！
もう醜いのはうんざりだ
これからはRubyたんとちゅっちゅするんだ
もう醜いのはうんざりだ
これからはRubyたんとちゅっちゅするんだ
醜いのにうんざりしたと言いながら、よりにもよってRubyかいな
ありゃ便利だけど、あくまでbetter perlであって綺麗な世界ではないぜ
まだJavaScriptの方が一貫性と綺麗な世界、シンプルさ保っててる
醜いこと嫌ってweb用となら、pythonも併せて検討した方がいいかもね
Rubyが気になるようなら、もしかしたら君は醜いモノもある程度必要としている方の人かもしれん
もし醜くないことだけが評価されるなら、CのCGIはもっと普及していることだろうw
ありゃ便利だけど、あくまでbetter perlであって綺麗な世界ではないぜ
まだJavaScriptの方が一貫性と綺麗な世界、シンプルさ保っててる
醜いこと嫌ってweb用となら、pythonも併せて検討した方がいいかもね
Rubyが気になるようなら、もしかしたら君は醜いモノもある程度必要としている方の人かもしれん
もし醜くないことだけが評価されるなら、CのCGIはもっと普及していることだろうw
PythonよりRubyの方が美しく書けるだろJK
PythonのOOは後付で一貫してない部分があるし
OOPと手続き型の混在感がある
JSは悪くはないが、まじめなだけが取り柄でおもしろみに欠ける
PythonのOOは後付で一貫してない部分があるし
OOPと手続き型の混在感がある
JSは悪くはないが、まじめなだけが取り柄でおもしろみに欠ける
醜く書き散らせてこそLL
汚く書きたくなきゃ制約の多い言語で十分だ
PHPに不満ある奴は、もっと泥に塗れられる言語を求めてるんだぜ
QIQとか、自由度と混沌を一緒に提案してくれてるんだ
本家にマージされてほしいぜ
あとJSはまじめどころか変態だぜw
汚く書きたくなきゃ制約の多い言語で十分だ
PHPに不満ある奴は、もっと泥に塗れられる言語を求めてるんだぜ
QIQとか、自由度と混沌を一緒に提案してくれてるんだ
本家にマージされてほしいぜ
あとJSはまじめどころか変態だぜw
うむ。JSはPythonもC++0xも取り込もうとしている変態言語（褒め言葉）
あいかわらずレベル低いやつらしかいないな。
RubyはPerlをオブジェクト指向風に作り直したような感じだもんな。
760みたいなこと書く奴が最もカス
非phpのfwを見て回ったが
CGIを高速に運用する環境で決定打を持つものがないな
どれも不安定っぽい
そう考えるとmod_phpの安定感は偉大だった
CGIを高速に運用する環境で決定打を持つものがないな
どれも不安定っぽい
そう考えるとmod_phpの安定感は偉大だった
>>764に補足
素のPHPに不満足な人間がすなわちフレームワークに関心を持つんだと俺は思ってる
素のPHPに不満足な人間がすなわちフレームワークに関心を持つんだと俺は思ってる
>>763 に対してもうちょっと書いてみる
多分、競合相手は「CGI」ではなく、例えばTomcatベースのJavaプラットフォームだったり
asp含む.NetのWindowsサーバだったり。
あなたの持ち出した基準では、そういうプラットフォームのお話であって。
そういうレベルでは（良くも悪くも）このスレの関心の範囲外だと言ってみる
多分、競合相手は「CGI」ではなく、例えばTomcatベースのJavaプラットフォームだったり
asp含む.NetのWindowsサーバだったり。
あなたの持ち出した基準では、そういうプラットフォームのお話であって。
そういうレベルでは（良くも悪くも）このスレの関心の範囲外だと言ってみる
そして人は皆、perl+mod_perlに戻るのだ
768 ：nobodyさん：2008/06/29(日) 19:31:13 ID:k12JEG0L
PHP版Railsという意味ではSymfonyとCakePHPとどっちが
本命なんでしょうかね？
本命なんでしょうかね？
答えはどっちも否
PHPにRailsは馴染まなかったってこと？
蛙の子は蛙
鵞鳥は白鳥にはなられへんねん！
鵞鳥は白鳥にはなられへんねん！
関西弁は嫌い
鵞鳥が読めずにググった俺涙目
PHP版RailsってまんまAkelosじゃん
あひるって最近は、公園に行ってもいそうでいないからなあ。
>>774
Akelosがどんなのか見てきたけど、こりゃ完全コピーだなｗ
Akelosがどんなのか見てきたけど、こりゃ完全コピーだなｗ
Port of Ruby on Rails development framework and designed to work for PHP4 and PHP5.
と書いてあるだろ。
むしろPHP4に対応しちゃっている部分を問題視しろ。
と書いてあるだろ。
むしろPHP4に対応しちゃっている部分を問題視しろ。
お前らそろそろPHP4対応じゃないと、とか言わないよね？
PHPのsingletonって意味ねーよな
リクエストからレスポンスまでしかオブジェクトが存在しないのに
singletonだろうが何だろうがたいして意味ねーよ
リクエストからレスポンスまでしかオブジェクトが存在しないのに
singletonだろうが何だろうがたいして意味ねーよ
>>779
そーなんだ！
そーなんだ！
>>780
分かってないみたいだが、そうだよ。define()でいい。
分かってないみたいだが、そうだよ。define()でいい。
スレッドセーフ的には使えんて事？
スレッドは関係ないだろ
PHP自体スレッドセーフじゃない
>>781
全然良くねーよ。定数にできるのはスカラーのみ。オブジェクトは不可。
PHPでシングルトンパターンは専らグローバル変数を使わずに
共通のインスタンスを使い回すのに使われる。
Javaでの使われ方とは違うけど、意味がないわけではない。
あとPHPでスレッドプログラミングはできないけど、ZTSを有効にしてビルドされた
PHPはApache2のworker MPMみたいなマルチスレッドサーバ上でスレッドセーフに動作する。
リンクされているライブラリやサードパーティ製拡張モジュールに関しては保証されないけど。
全然良くねーよ。定数にできるのはスカラーのみ。オブジェクトは不可。
PHPでシングルトンパターンは専らグローバル変数を使わずに
共通のインスタンスを使い回すのに使われる。
Javaでの使われ方とは違うけど、意味がないわけではない。
あとPHPでスレッドプログラミングはできないけど、ZTSを有効にしてビルドされた
PHPはApache2のworker MPMみたいなマルチスレッドサーバ上でスレッドセーフに動作する。
リンクされているライブラリやサードパーティ製拡張モジュールに関しては保証されないけど。
確かになんでdefine?と思った
>>785
> PHPでシングルトンパターンは専らグローバル変数を使わずに
> 共通のインスタンスを使い回すのに使われる。
まあPHP4でのシングルトン実装は、みんな$GLOBALSへの放り込みだったけどなｗ
シングルトンのつもりで設計したのに & を付け忘れてオブジェクトコピーしまくってたり。
過去の話になってくれて、本当にめでたい。
> PHPでシングルトンパターンは専らグローバル変数を使わずに
> 共通のインスタンスを使い回すのに使われる。
まあPHP4でのシングルトン実装は、みんな$GLOBALSへの放り込みだったけどなｗ
シングルトンのつもりで設計したのに & を付け忘れてオブジェクトコピーしまくってたり。
過去の話になってくれて、本当にめでたい。
>>787
そういえばPEARで $GLOBALS['_クラス名']['instances'] = array(); とかあったｗ（ていうか今でもある）
今は↓みたいなのが多いね。ものによっては__construct()をprivate/protectedにしてたり。
public static function getInstance() {
static $obj = null;
if ($obj === null) { /* 初期化 */ }
return $obj;
}
そういえばPEARで $GLOBALS['_クラス名']['instances'] = array(); とかあったｗ（ていうか今でもある）
今は↓みたいなのが多いね。ものによっては__construct()をprivate/protectedにしてたり。
public static function getInstance() {
static $obj = null;
if ($obj === null) { /* 初期化 */ }
return $obj;
}
static $obj = null;
if ($obj === null) { /* 初期化 */ }
return $obj;
}
↑なんだそりゃｗ
if ($obj === null) { /* 初期化 */ }
return $obj;
}
↑なんだそりゃｗ
>>788ってごく普通の書き方だと思うが。PHP4でもほぼ一緒。
あほか、php4だってstaticくらいあるだ
4でも関数のstatic変数はあり。5だとクラスのstatic変数に突っ込んだりはするね。
知らんかった。勉強になった。
んじゃ、むしろ>>788の書き方は（関数宣言を除けば） PHP4、5共用の書き方ってこと？
PHP5なら、クラス変数にした方がわかりやすいじゃん？って思ってしまうが、この書き方の
メリットってある？
んじゃ、むしろ>>788の書き方は（関数宣言を除けば） PHP4、5共用の書き方ってこと？
PHP5なら、クラス変数にした方がわかりやすいじゃん？って思ってしまうが、この書き方の
メリットってある？
PHP5の場合普通クラス変数に入れる
PHP4が苦渋の策だっただけ
PHP4が苦渋の策だっただけ
一応、メソッド内のstaticだと、自クラスの他メソッドからも直接さわれない、
超private変数にはなる、のかなｗ ・・・メリット？
超private変数にはなる、のかなｗ ・・・メリット？
もうphp4は許してやれよ
static変数の場合スコープがそのメソッドのみになるから
singletonという意味ではそうしないと意味がないような
クラスプロパティだと書き換えられる
singletonという意味ではそうしないと意味がないような
クラスプロパティだと書き換えられる
>>794
5だとstaticを付けなきゃいけないとか、4だと関数名の前に & を付けて、
呼び出し時も & が必要とか、微妙な違いがある。しかも内部的に等価じゃないし。
5だとクラス変数にしたほうがいいね。
5だとstaticを付けなきゃいけないとか、4だと関数名の前に & を付けて、
呼び出し時も & が必要とか、微妙な違いがある。しかも内部的に等価じゃないし。
5だとクラス変数にしたほうがいいね。
で、そのSingletonとやらをどう有効に使えるのかね？ｗ
PHPだぞ、これ。Javaじゃない。
ふっつーにグローバル変数で何の問題も起きない。起こしたら本格的に痴呆だ。
PHPだぞ、これ。Javaじゃない。
ふっつーにグローバル変数で何の問題も起きない。起こしたら本格的に痴呆だ。
まあそうね
PHPSDLとかイロモノ出て来てるの見ると、色々考えちまうがw
PHPSDLとかイロモノ出て来てるの見ると、色々考えちまうがw
>>801
ライブラリやフレームワークでの記述の統一が無視できないと思う。
あんたの書いたライブラリで$GLOBALS['hogehoge']['pagepage']['instance']とか、
誰が使うかｗ
Hogehoge::getInstance() の方が憶えやすいし、見通しがいいに決まってるじゃないか。
ただの$_SESSIONアクセサ+アルファで、別にそれほど目立った特色のないSession
クラスや同様のCookieクラスが一部で存在する意味もそれだろ。
こういった要素を軽視する人間と一緒に作業できそうな気はあまりしない
ライブラリやフレームワークでの記述の統一が無視できないと思う。
あんたの書いたライブラリで$GLOBALS['hogehoge']['pagepage']['instance']とか、
誰が使うかｗ
Hogehoge::getInstance() の方が憶えやすいし、見通しがいいに決まってるじゃないか。
ただの$_SESSIONアクセサ+アルファで、別にそれほど目立った特色のないSession
クラスや同様のCookieクラスが一部で存在する意味もそれだろ。
こういった要素を軽視する人間と一緒に作業できそうな気はあまりしない
>>803
>>801はフレームワーク不要とか言ってる人と同一人物じゃないかな？
趣味プログラマだと思うから、状況が違うんでしょう。
おそらくJavaで仕事したこともないからこその発言に見えるね。
なので議論は（フレームワーク不要論と同様に）平行線になるね。
>>801はフレームワーク不要とか言ってる人と同一人物じゃないかな？
趣味プログラマだと思うから、状況が違うんでしょう。
おそらくJavaで仕事したこともないからこその発言に見えるね。
なので議論は（フレームワーク不要論と同様に）平行線になるね。
まともなJava屋から「グローバル変数で何の問題も起きない」なんて発言が出るわけないもんな。
>>801
>>803とは違うことだけど、安全性の問題かな
このファイルをincludeすると、$なんとか っていうグローバル変数が
定義されますっていうのはちょっと・・・。
グローバル変数への格納・利用が、同一人物が同時期に書いたソース
のみで起こるんならまだいいんだけどね。
Xoopsも結構良くできてたけど、プラグインを作るときにこの辺が物凄く
引っかかった。クラスベースでも、覚えたりソース読んだりするのは同じ
なんだけど、少なくとも汚染されていない保証っていうのかな、そういう
ものが大事だと俺は感じた。
>>803とは違うことだけど、安全性の問題かな
このファイルをincludeすると、$なんとか っていうグローバル変数が
定義されますっていうのはちょっと・・・。
グローバル変数への格納・利用が、同一人物が同時期に書いたソース
のみで起こるんならまだいいんだけどね。
Xoopsも結構良くできてたけど、プラグインを作るときにこの辺が物凄く
引っかかった。クラスベースでも、覚えたりソース読んだりするのは同じ
なんだけど、少なくとも汚染されていない保証っていうのかな、そういう
ものが大事だと俺は感じた。
あまりむやみにグローバル変数を作るのはよくないけれど、限定された使い方ならいいと思う。
どうせシングルトンの対象になるのって、DBコネクションとか限られてるんだから。
どうせシングルトンの対象になるのって、DBコネクションとか限られてるんだから。
Singletonだと継承した時、Singleton部分を再実装しないといけない
どうせSingletonの意味は薄いんだから、クラスは普通に書いて
Factoryで管理した方がいいかもね
どうせSingletonの意味は薄いんだから、クラスは普通に書いて
Factoryで管理した方がいいかもね
>>808
意味がわからない。kwsk plz
意味がわからない。kwsk plz
>>808
agaviはContextクラスがAgaviModelの派生クラスのファクトリーになってて、
IAgaviSingleModelインターフェイスを実装している場合はSingletonになるようにしてる。
agaviはContextクラスがAgaviModelの派生クラスのファクトリーになってて、
IAgaviSingleModelインターフェイスを実装している場合はSingletonになるようにしてる。
>>808
想定しているのはこういうのじゃなくて？
＃ これなら継承しても特に問題なさそうなんだけど・・・
class A
{
protected static $obj;
public static function singleton()
{
if(!isset(self::$obj)){
self::$obj = new stdClass();
}
return self::$obj;
}
}
class B extends A{}
var_dump(B::singleton());
想定しているのはこういうのじゃなくて？
＃ これなら継承しても特に問題なさそうなんだけど・・・
class A
{
protected static $obj;
public static function singleton()
{
if(!isset(self::$obj)){
self::$obj = new stdClass();
}
return self::$obj;
}
}
class B extends A{}
var_dump(B::singleton());
ああ。なんとなくここまで流れで見えてきたポイントがある。
>>811 での Bクラスの singleton() では、例えば Aクラスを継承した
Cクラス・Dクラス・・・でも、「同じ」インスタンスが返ってくるなｗ
class B extends A{}
+ class C extends A{}
var_dump(B::singleton());
+ var_dump(C:::singleton());
んで、ぐーーーーっと戻るが、>>788 での記述でAクラスが書かれて
いたとすると、結果が変わる。
BクラスとCクラスでは、戻ってくるインスタンスが違う。
結局、こういうことなのかな？
詳しい人、解説頼む
>>811 での Bクラスの singleton() では、例えば Aクラスを継承した
Cクラス・Dクラス・・・でも、「同じ」インスタンスが返ってくるなｗ
class B extends A{}
+ class C extends A{}
var_dump(B::singleton());
+ var_dump(C:::singleton());
んで、ぐーーーーっと戻るが、>>788 での記述でAクラスが書かれて
いたとすると、結果が変わる。
BクラスとCクラスでは、戻ってくるインスタンスが違う。
結局、こういうことなのかな？
詳しい人、解説頼む
シングルトンは初期化のタイミング気にしなくて良いのも大きいやん
>>813
シングルトンは昔からあるデザインパターンの一つだよ。
シングルトンは昔からあるデザインパターンの一つだよ。
DIコンテナがあればシングルトンパターンなんて使わねーから。
そんなことより、JavaもPerlもRubyもMVCフレームワークって
ほぼ１択なのにPHPは乱立してんの？
決定版が出てこない時点で終わってるな。
そんなことより、JavaもPerlもRubyもMVCフレームワークって
ほぼ１択なのにPHPは乱立してんの？
決定版が出てこない時点で終わってるな。
>>816
ある意味、PHPの敷居の低さかな。もともとWEBフレームワークみたいなものだから、
基本機能（CookieだとかHTTP周りとか、出力とかサーバへのデプロイとかもろもろ）を
スキップしていきなり構築出来るし、書いてみれば結構できちゃった、みたいな感じじゃね？
ある意味、PHPの敷居の低さかな。もともとWEBフレームワークみたいなものだから、
基本機能（CookieだとかHTTP周りとか、出力とかサーバへのデプロイとかもろもろ）を
スキップしていきなり構築出来るし、書いてみれば結構できちゃった、みたいな感じじゃね？
>>816
DIコンテナ何使ってる？
DIコンテナ何使ってる？
・DIコンテナって何？その用途・利点は？
・DIコンテナとsingletonの関連は？
・DIコンテナを使ったPHPフレームワークってある？その得意とするケースは？
初心者が、ここでこれくらい聞いてもいい？
・DIコンテナとsingletonの関連は？
・DIコンテナを使ったPHPフレームワークってある？その得意とするケースは？
初心者が、ここでこれくらい聞いてもいい？
だーめっ☆
>>819
ググれカス
ググれカス
話についていけない！
Javaを勉強しないといけませんか？＾＾
Javaを勉強しないといけませんか？＾＾
>>823
やさしいJAVA
やさしいJAVA
>>824
いやいやｗ それデザパタとかないしｗ
まずは、DIコンテナが有効なのかどうか、その辺の話が出来ないのか？
ググっても古い情報しかないのは、もう廃れたのか、常識的に使われている
からなのか、どうなんだ
基本的に、手法がXML等の外部設定ファイルだろ？PHPに馴染むとは思えん。
俺を含めて、本格的に使ったことの無い奴が多いんだろうとは思うが。
いやいやｗ それデザパタとかないしｗ
まずは、DIコンテナが有効なのかどうか、その辺の話が出来ないのか？
ググっても古い情報しかないのは、もう廃れたのか、常識的に使われている
からなのか、どうなんだ
基本的に、手法がXML等の外部設定ファイルだろ？PHPに馴染むとは思えん。
俺を含めて、本格的に使ったことの無い奴が多いんだろうとは思うが。
PHPになじむかどうか以前に、
XMLなどの外部設定ファイルで設定するのって
大変だよ。
XMLなどの外部設定ファイルで設定するのって
大変だよ。
>>816
Javaのフレームワークがほぼ一択だと思ってるなら、無知すぎ。
Rubyは開発者が少なすぎの過疎言語だったから。
Perlも廃れた言語だから。
Pythonも多い。
PHPも、乱立っても紹介が多いだけで、実際使われてるフレームワークは
限られてる
Javaのフレームワークがほぼ一択だと思ってるなら、無知すぎ。
Rubyは開発者が少なすぎの過疎言語だったから。
Perlも廃れた言語だから。
Pythonも多い。
PHPも、乱立っても紹介が多いだけで、実際使われてるフレームワークは
限られてる
PHPって、まともなクラスライブラリがないから、それぞれ独自でフレームワークを実装し出すんだよ。
DIコンテナ=XMLの設定ファイル使う、じゃないでしょ。
yamlの奴とかもあるよ
yamlの奴とかもあるよ
ZendFrameworkに関しては、使える部分はあるんだけどね。
ともすればRouterやControllerあたりに目を奪われて、ライブラリ
部分の評価がおざなりになってしまったりする。
例えばCIに持ち込むとかすればいいし、双方ともそれが簡単に
出来るように作ってはあるんだけど、その時に何というか気持ち悪い
何故かと考えたが、クラス・変数・関数・ファイル名等の命名規則が、
分散しすぎているせいもあるなあというのが最近の実感。
異質な気持ち悪さがあるのは、きっと命名規則等も分散して
ともすればRouterやControllerあたりに目を奪われて、ライブラリ
部分の評価がおざなりになってしまったりする。
例えばCIに持ち込むとかすればいいし、双方ともそれが簡単に
出来るように作ってはあるんだけど、その時に何というか気持ち悪い
何故かと考えたが、クラス・変数・関数・ファイル名等の命名規則が、
分散しすぎているせいもあるなあというのが最近の実感。
異質な気持ち悪さがあるのは、きっと命名規則等も分散して
>>832
最後の行はゴミｗ 消したい
最後の行はゴミｗ 消したい
5.3の名前空間使えるようになったら少しはマシになるかな
3と4と5で文法や仕様が大きく変わって、全部に対応するライブラリやフレームワークを構築するのが困難。
3とかあり得ないし、4に対応するものを新しく書く必要もない、と思うけどね
4はそれこそ、今までの遺産でがんばれば良いじゃない
4はそれこそ、今までの遺産でがんばれば良いじゃない
838 ：nobodyさん：2008/07/08(火) 22:09:17 ID:PfgpRR5R
>>832
CodeIgniterにZendFrameworkのライブラリを引っ張ってくる＝いいとこ取りで、楽ができますか？
ＭＶＣならルーティングとか、コアになる部分は、どのフレームワーク使ってもに似たような処理になっているでしょうか？＾＾
CodeIgniterにZendFrameworkのライブラリを引っ張ってくる＝いいとこ取りで、楽ができますか？
ＭＶＣならルーティングとか、コアになる部分は、どのフレームワーク使ってもに似たような処理になっているでしょうか？＾＾
幕の内弁当のようにいろいろな具が詰まったフレームワークを、いったんバラバラの具に分解して
自由に組み合わせて食べられるとウマー？
時間があったら、フレームワークのコードを読んでみるか…。
自由に組み合わせて食べられるとウマー？
時間があったら、フレームワークのコードを読んでみるか…。
Perl5.0が1994年、Perl5.6でさえ2000年にリリースされてる。これが圧倒的なボリュームのCPANがあるPerlと、Pearが尻すぼみに終わり、Zendが始まりもしなかったPHPの違い。
>>838
別にそんなに難しくないし、メリットはあるとおもう。例えばZend_Pdfとか持って来たり。
lib/Zend 以下をごっそりvendor/とかにコピーしてinclude_pathを通すのが一番楽だけど、
依存に注意しながら必要なものだけを持ってくるのでも、それほど難しくない。
例外が２系統投げられるので、その辺が気になるなら対処して。
CIの場合はそれほどコアに密着したライブラリって無いので、例えばSessionとかDbとか
も、好きなものを使おうと思えば使える。Registryとか、なんでCIにないのかなって思ったし。
＃ そうすると、CIの機能をいくらか無視することにもなるかもだけど、それで幸せになれるならおｋ
で、問題はそれをやると、ソースがカオスになると。メソッドの命名規則なんか、CIはZFの
対局にいると言っても過言ではないとおもうし。
＃ クラスにprefixつけない、CamelCase嫌い、クラスファイル名でもCamelCase式と
＃ lowercase-underscore式の、独自ルールによる混在、もろもろ・・・
そこに上乗せする俺のソースはどっちで書けばすっきりするんだああ、となるよ。
別にそんなに難しくないし、メリットはあるとおもう。例えばZend_Pdfとか持って来たり。
lib/Zend 以下をごっそりvendor/とかにコピーしてinclude_pathを通すのが一番楽だけど、
依存に注意しながら必要なものだけを持ってくるのでも、それほど難しくない。
例外が２系統投げられるので、その辺が気になるなら対処して。
CIの場合はそれほどコアに密着したライブラリって無いので、例えばSessionとかDbとか
も、好きなものを使おうと思えば使える。Registryとか、なんでCIにないのかなって思ったし。
＃ そうすると、CIの機能をいくらか無視することにもなるかもだけど、それで幸せになれるならおｋ
で、問題はそれをやると、ソースがカオスになると。メソッドの命名規則なんか、CIはZFの
対局にいると言っても過言ではないとおもうし。
＃ クラスにprefixつけない、CamelCase嫌い、クラスファイル名でもCamelCase式と
＃ lowercase-underscore式の、独自ルールによる混在、もろもろ・・・
そこに上乗せする俺のソースはどっちで書けばすっきりするんだああ、となるよ。
DIの設定がXML地獄てSpring2.5とか使ったことないのか？
ここのアホ住人は。
今は、XMLにはほとんど記述せずにアノテーションでお手軽に記述できるんだよ。
ここのアホ住人は。
今は、XMLにはほとんど記述せずにアノテーションでお手軽に記述できるんだよ。
>>842
そうやって、どんどんJava風を進めて行くわけですね。＞アノテーション
出来れば、そのメリット・デメリットを絡めたレスが欲しいなぁ。
なんでJavaで一般的なものがPHPで一般的でないか、それを、
「遅れている」等としか捉えられないのなら、少しおかしいと思っていいよｗ
そうやって、どんどんJava風を進めて行くわけですね。＞アノテーション
出来れば、そのメリット・デメリットを絡めたレスが欲しいなぁ。
なんでJavaで一般的なものがPHPで一般的でないか、それを、
「遅れている」等としか捉えられないのなら、少しおかしいと思っていいよｗ
>>843
842は設定ファイル云々に突っ込んでるだけでしょ
842は設定ファイル云々に突っ込んでるだけでしょ
>>844
それを言うなら、XML言い出した大本の>>825では自嘲している
> 俺を含めて、本格的に使ったことの無い奴が多いんだろうとは思うが。
むしろ、DI派の具体的な書き込みが無いから発展しないんだろうが。
それを言うなら、XML言い出した大本の>>825では自嘲している
> 俺を含めて、本格的に使ったことの無い奴が多いんだろうとは思うが。
むしろ、DI派の具体的な書き込みが無いから発展しないんだろうが。
本当に、PHPでDIとかDaoとか、「これはいい！」と思って使ってる人っているの？
そもそもPHPやRubyのような動的言語には、DIみたいな回りくどい書き方は不要。
静的言語の融通の効かなさを誤魔化すために生み出されたものだし。
静的言語の融通の効かなさを誤魔化すために生み出されたものだし。
Tomcatの再起動とか面倒だったりするもんな。
849 ：nobodyさん：2008/07/09(水) 12:00:32 ID:QmvziGkH
自分のプログラム技術が上手なことに気付いた
アルゴリズム能力は知識で補えない、もって生まれた能力
アルゴリズム能力は知識で補えない、もって生まれた能力
850 ：nobodyさん：2008/07/09(水) 20:19:04 ID:My9jWWGd
>>849
オリジナルの式を組めるなら凄いな
オリジナルの式を組めるなら凄いな
ゆがんだ車輪を再発明しまくってる悪寒
アルゴリズムってか、ロジックレベルで言ってるんでは無かろうかとも思う
ってか、何これ。コピペ？
アルゴリズムってか、ロジックレベルで言ってるんでは無かろうかとも思う
ってか、何これ。コピペ？
>>849
世界ＩＴコンテスト、慶大生が３位入賞
世界の学生がＩＴ（情報技術）の開発力を競う「イマジンカップ」（米マイクロソフト主催）の第6回世界大会が
8日までパリで開かれ、「アルゴリズム部門」で、慶応大の高橋直大さん（20）が3位に入賞した。
日本人の3位以内の入賞は初めて。アルゴリズムはコンピューターソフトの基礎となる計算手法で、
高橋さんのアルゴリズムの独創性などが評価された。
アルゴリズム部門のコンテストは数学パズルのような9問の課題を24時間の制限時間内に
コンピューターを駆使して解法を考案する。高橋さんは「好きな算数や数学の考え方をいかした。
2、3分しか寝なかった」と話した。
パリの大会には100カ国以上から124チームが参加した。予選を含めた総参加人数は20万人を超える。（パリ支局）(11:01)
http://www.nikkei.co.jp/news/shakai/20080709AT1G0900609072008.html
世界ＩＴコンテスト、慶大生が３位入賞
世界の学生がＩＴ（情報技術）の開発力を競う「イマジンカップ」（米マイクロソフト主催）の第6回世界大会が
8日までパリで開かれ、「アルゴリズム部門」で、慶応大の高橋直大さん（20）が3位に入賞した。
日本人の3位以内の入賞は初めて。アルゴリズムはコンピューターソフトの基礎となる計算手法で、
高橋さんのアルゴリズムの独創性などが評価された。
アルゴリズム部門のコンテストは数学パズルのような9問の課題を24時間の制限時間内に
コンピューターを駆使して解法を考案する。高橋さんは「好きな算数や数学の考え方をいかした。
2、3分しか寝なかった」と話した。
パリの大会には100カ国以上から124チームが参加した。予選を含めた総参加人数は20万人を超える。（パリ支局）(11:01)
http://www.nikkei.co.jp/news/shakai/20080709AT1G0900609072008.html
何このきもい流れ
「自分のプログラム技術が上手なことに気付いた」の方に決まってんじゃん
なんで卑怯者？？？
なんで卑怯者？？？
ネタが無いんだよｗ
857 ：nobodyさん：2008/07/10(木) 10:37:59 ID:R+kirKl3
で、ここでPHPフレームワークの話をしよう！
ってなると、話がピタッと止まるから面白いｗ
ってなると、話がピタッと止まるから面白いｗ
あぁ、Java厨が嵐に来ているだけだからね。
PHPフレームワークの話題は規模が大きくなったので、
各フレームワーク専用スレに移行しております。
各フレームワーク専用スレに移行しております。
どんなふうにしてクラスを作ればいいのか？
クラス作成の適切な方法を調べています。
分析（モデリング）→設計の流れにおいて、
・構造化プログラミングだとDFD
・オブジェクト指向プログラミングだとUML
ユースケースドリブン＝ユースケース図→ロバストネス分析→クラス図を作成する？
アーキテクチャセントリック＝アーキテクチャ（基盤）としてのフレームワークを選定→フレームワークの流儀に従って機能（クラス等）をどんどん追加していく？
…ということでしょうか？
本やサイトを調べると、Javaの事例がたくさん出てきました。
クラス作成の適切な方法を調べています。
分析（モデリング）→設計の流れにおいて、
・構造化プログラミングだとDFD
・オブジェクト指向プログラミングだとUML
ユースケースドリブン＝ユースケース図→ロバストネス分析→クラス図を作成する？
アーキテクチャセントリック＝アーキテクチャ（基盤）としてのフレームワークを選定→フレームワークの流儀に従って機能（クラス等）をどんどん追加していく？
…ということでしょうか？
本やサイトを調べると、Javaの事例がたくさん出てきました。
なら死ぬ気でJavaやれよ。俺はJavaを書くと慢性的に薄い血尿が出てた頃を思い出すからコリゴリだけどな。
javaのコードをphpに置き換えりゃいいじゃねえか・・・
そうして行数や文字密度ばかりでかい、可読性最低のソースが量産されるのですね
Javaは勉強しました。
＝簡単なアプレットを作れます。
オブジェクト指向分析→設計って、言語の仕様に依存しないで使えますよね？
クラス作成は、適当でも動くものは作れるけど、先人が体得してきた上手いやり方を知りたいです。
デザインパターンは、これから勉強してみます。
＝簡単なアプレットを作れます。
オブジェクト指向分析→設計って、言語の仕様に依存しないで使えますよね？
クラス作成は、適当でも動くものは作れるけど、先人が体得してきた上手いやり方を知りたいです。
デザインパターンは、これから勉強してみます。
構造化プログラミングの設計は、わかりやすいと思います。
文書を作成する場合も、フローチャート図やDFD図を書けば、人に説明できる。
データベース設計もER図で書ける。
オブジェクト指向設計はこれから勉強しますが、体当たりで試行錯誤するより、典型的な勉強方法を知りたいです。
文書を作成する場合も、フローチャート図やDFD図を書けば、人に説明できる。
データベース設計もER図で書ける。
オブジェクト指向設計はこれから勉強しますが、体当たりで試行錯誤するより、典型的な勉強方法を知りたいです。
近道して楽しようと思わないことかな
867 ：nobodyさん：2008/07/11(金) 23:37:05 ID:3Q95O5fB
オブジェクト指向設計は、まだ方法論が確立されていないのですか？
群雄割拠＞＜
群雄割拠＞＜
>>866
それは、自分で私は低脳プログラマですって言ってるようなものだぞ。
それは、自分で私は低脳プログラマですって言ってるようなものだぞ。
869 ：nobodyさん：2008/07/12(土) 09:41:14 ID:jBMGyyJi
オブジェクトはな・・・Cの構造体を勉強してみると感じが分かるやもしれぬ。
が、そもそもCの勉強コスト自体が高いかね。
でも、勉強しておくと、後々効いてくる。
が、そもそもCの勉強コスト自体が高いかね。
でも、勉強しておくと、後々効いてくる。
オブジェクト指向を学習したいならPHPなんてしない方がいい
関連書籍のレベルも低いし
関連書籍のレベルも低いし
オブジェクト指向なんて難しい事を考えずに、
関数の寄せ集めって考えれば、すごく楽なのに。
関数の寄せ集めって考えれば、すごく楽なのに。
関数の寄せ集めとは違うぞ。
より便利に関数・・・というか、プログラミングを、と考えていくとオブジェクト指向につながっては行くけどな。
より便利に関数・・・というか、プログラミングを、と考えていくとオブジェクト指向につながっては行くけどな。
>>868
なんで？
なんで？
関数と変数の寄せ集めじゃない？
>>873
楽したがる人の方が優秀っていうのは定説
楽したがる人の方が優秀っていうのは定説
>>875
根拠を詳しく
根拠を詳しく
>>876
どうせ「ソースは自分」だろうからほっとけ。
オブジェクト指向はOOPだけ見てると、どうしても小手先的な話が多くなりがちだから
OODも勉強したほうが良いとは思う。ただ、これに関して自分が呼んだ範囲でよかったと
思える本は、Booch先生の「Booch法：オブジェクト指向分析と設計」ぐらい。
しかもこれはもう絶版で再版はされないだろうから、中々に難しい。
どうせ「ソースは自分」だろうからほっとけ。
オブジェクト指向はOOPだけ見てると、どうしても小手先的な話が多くなりがちだから
OODも勉強したほうが良いとは思う。ただ、これに関して自分が呼んだ範囲でよかったと
思える本は、Booch先生の「Booch法：オブジェクト指向分析と設計」ぐらい。
しかもこれはもう絶版で再版はされないだろうから、中々に難しい。
>>876
少しはぐぐれ
少しはぐぐれ
>>877
じゃあ、自分の言葉で、「OODも勉強したほうが良い」と思われることを一つでもよろしく
例えば設計手法としてドメインモデルに基づいた「名前」の抽出とか、そう言った具体的な
ものは、"OOではなく"普通に有効なものだと思う。
何がOOのエッセンスか、その辺がよくわからない。
例えば新しい手法が出てきたとして、それがある場面で有効であっても、付帯する、
例えばJavaを前提としたUMLの書式であったりJavaの文脈であったり、そういった
ものはあまり普遍的ではないように感じる。
例： Beanとかなんとか書いてある本を、PHPで実際に参考にするのは非常に難しい。
じゃあ、自分の言葉で、「OODも勉強したほうが良い」と思われることを一つでもよろしく
例えば設計手法としてドメインモデルに基づいた「名前」の抽出とか、そう言った具体的な
ものは、"OOではなく"普通に有効なものだと思う。
何がOOのエッセンスか、その辺がよくわからない。
例えば新しい手法が出てきたとして、それがある場面で有効であっても、付帯する、
例えばJavaを前提としたUMLの書式であったりJavaの文脈であったり、そういった
ものはあまり普遍的ではないように感じる。
例： Beanとかなんとか書いてある本を、PHPで実際に参考にするのは非常に難しい。
>>879
> "OOではなく"普通に有効なものだと思う。
色々あるだろうけど、それはその通りだと思うよ。
ただ、例えばモジュール化とかの方法論は、機能単位に分解することを前提にしてたり、
して、モデリングの方法論としては使用されていなかったというだけの話で。
OO言語が流行るまで、個々のエンジニアレベルでOO的な思考がされていなかったのかと
言えば、そんなことはないでしょ。ただ、共通的なモデルとしては語られなかっただけで。
でも、それが出来るようになったのは、それなりに大きい。
後半は何言ってるかわからんから、コメントは控える。
> "OOではなく"普通に有効なものだと思う。
色々あるだろうけど、それはその通りだと思うよ。
ただ、例えばモジュール化とかの方法論は、機能単位に分解することを前提にしてたり、
して、モデリングの方法論としては使用されていなかったというだけの話で。
OO言語が流行るまで、個々のエンジニアレベルでOO的な思考がされていなかったのかと
言えば、そんなことはないでしょ。ただ、共通的なモデルとしては語られなかっただけで。
でも、それが出来るようになったのは、それなりに大きい。
後半は何言ってるかわからんから、コメントは控える。
881 ：nobodyさん：2008/07/12(土) 15:09:10 ID:2oBRlMWN
モデル駆動型アーキテクチャ - Wikipedia
http://ja.wikipedia.org/wiki/%E3%83%A2%E3%83%87%E3%83%AB%E9%A7%86%E5%8B%95%E5%9E%8B%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3
>フォレスターリサーチは2006年に MDA は死に体（D.O.A.）であるとした
OOA/OOD業界には、SIerが儲けるためのバスワードが混ざっているんでしょうか？
http://ja.wikipedia.org/wiki/%E3%83%A2%E3%83%87%E3%83%AB%E9%A7%86%E5%8B%95%E5%9E%8B%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3
>フォレスターリサーチは2006年に MDA は死に体（D.O.A.）であるとした
OOA/OOD業界には、SIerが儲けるためのバスワードが混ざっているんでしょうか？
882 ：nobodyさん：2008/07/12(土) 15:11:44 ID:2oBRlMWN
× バスワード
○ バズワード
バズワード - 【buzzword】(特にビジネスの世界における)流行語。
バズワード(buzzword)とは一見専門用語のように見えるがそうではない、明確な合意や定義のない用語のことである。
○ バズワード
バズワード - 【buzzword】(特にビジネスの世界における)流行語。
バズワード(buzzword)とは一見専門用語のように見えるがそうではない、明確な合意や定義のない用語のことである。
OOA/OOD業界って何？って話があるけど、そもそもOOをまともに語れるSIerなんてそんなに居ないと思う。
昔、IBMでさえ、「VBはOO言語だから、VBで作ったシステムはオブジェクト指向技術で作られているんだ」なんて
意味の無いことを主張してたし。
ただ、近いところだと、SOAなんかはバズだなぁって思う。
昔、IBMでさえ、「VBはOO言語だから、VBで作ったシステムはオブジェクト指向技術で作られているんだ」なんて
意味の無いことを主張してたし。
ただ、近いところだと、SOAなんかはバズだなぁって思う。
いや意味なくはないだろw
具体的に何が気に障ったのか判らんが
具体的に何が気に障ったのか判らんが
885 ：nobodyさん：2008/07/12(土) 17:54:21 ID:bJKqKB86
ethnaみたいなシンプルなFWで十分
MVCとヴァアリデートだけできればいいし
MVCとヴァアリデートだけできればいいし
> MVCとヴァアリデートだけできればいいし
逆に、それ以外で要らないものって何だ？
逆に、それ以外で要らないものって何だ？
MVCが広すぎて何とも言えないが、独自セッションライブラリとかO/Rマッパとか
やたらと柔軟なrouterとか、使いやすいConfig、Repositoryクラスとか、そんなもの
のことかも
でも、ぶっちゃけヴァリデートはテンプレートライブラリと同程度にフレームワーク
からの独立性や選択肢が欲しいな。
一時期HTML_QuickFormが流行ったのは、独立したヴァリデーションライブラリの
側面もあったからだと俺は思ってる
やたらと柔軟なrouterとか、使いやすいConfig、Repositoryクラスとか、そんなもの
のことかも
でも、ぶっちゃけヴァリデートはテンプレートライブラリと同程度にフレームワーク
からの独立性や選択肢が欲しいな。
一時期HTML_QuickFormが流行ったのは、独立したヴァリデーションライブラリの
側面もあったからだと俺は思ってる
>>887
> MVCが広すぎて何とも言えないが、独自セッションライブラリとかO/Rマッパとか
> やたらと柔軟なrouterとか、使いやすいConfig、Repositoryクラスとか、そんなもの
> のことかも
俺もそれのことだろうとは思ったのよ。
でも、本当にそんな便利なものをいらないと
言っているのかと疑問になってね。
> MVCが広すぎて何とも言えないが、独自セッションライブラリとかO/Rマッパとか
> やたらと柔軟なrouterとか、使いやすいConfig、Repositoryクラスとか、そんなもの
> のことかも
俺もそれのことだろうとは思ったのよ。
でも、本当にそんな便利なものをいらないと
言っているのかと疑問になってね。
今時PHPてどこの乞食だよｗｗｗ
891 ：nobodyさん：2008/07/12(土) 22:05:04 ID:yMqg6CvP
九大病院 IBM オブジェクト指向 に一致する日本語のページ 約 320 件
http://bizboard.nikkeibp.co.jp/kijiken/summary/19980817/NC0450H_416091a.html
日経コンピュータ 1998/08/17号
大規模オブジェクト指向開発が破綻 早期稼働を狙いVisual Basicへ変更
九州大学医学部附属病院は98年5月，医師や看護婦のあらゆる業務を支援する「新医療情報システム」を予定より1年以上遅れて全面稼働させた。
当初は97年1月から順次稼働させる予定だったが，システム・インテグレータとして開発を担当した日本アイ・ビー・エムのプロジェクト管理の甘さなどが原因で，開発が大幅に遅れてしまった。
最初smalltalkを使って、頓挫してVisualBasicに変更＝オブジェクト指向プログラミングを捨てて、構造化プログラミングでデスマーチに対処したんですね？
http://bizboard.nikkeibp.co.jp/kijiken/summary/19980817/NC0450H_416091a.html
日経コンピュータ 1998/08/17号
大規模オブジェクト指向開発が破綻 早期稼働を狙いVisual Basicへ変更
九州大学医学部附属病院は98年5月，医師や看護婦のあらゆる業務を支援する「新医療情報システム」を予定より1年以上遅れて全面稼働させた。
当初は97年1月から順次稼働させる予定だったが，システム・インテグレータとして開発を担当した日本アイ・ビー・エムのプロジェクト管理の甘さなどが原因で，開発が大幅に遅れてしまった。
最初smalltalkを使って、頓挫してVisualBasicに変更＝オブジェクト指向プログラミングを捨てて、構造化プログラミングでデスマーチに対処したんですね？
http://itpro.nikkeibp.co.jp/article/NEWS/20080306/295561/
スルガ銀行は2008年3月6日、日本IBMに111億700万円の損害賠償を求める訴訟を東京地方裁判所に提起したと発表した。
「新経営システム」の開発を委託したが、「IBMの債務不履行により開発を中止せざるを得なくなった」（広報）ことにより被った損害や逸失利益などの賠償を求めたもの。
スルガ銀が導入を目指していたのは、IBMのオープン勘定系パッケージ「NEFSS/Corebank」。
2004年9月にプロジェクトを開始していた。
当初は2008年1月の稼働を目指していたが、開発遅れにより、延期していた。
俺なら111億円も弁償できないよ＞＜
PHPで月100万円儲けられれば十分です(^^)v
スルガ銀行は2008年3月6日、日本IBMに111億700万円の損害賠償を求める訴訟を東京地方裁判所に提起したと発表した。
「新経営システム」の開発を委託したが、「IBMの債務不履行により開発を中止せざるを得なくなった」（広報）ことにより被った損害や逸失利益などの賠償を求めたもの。
スルガ銀が導入を目指していたのは、IBMのオープン勘定系パッケージ「NEFSS/Corebank」。
2004年9月にプロジェクトを開始していた。
当初は2008年1月の稼働を目指していたが、開発遅れにより、延期していた。
俺なら111億円も弁償できないよ＞＜
PHPで月100万円儲けられれば十分です(^^)v
>>888
結構古い話なのね
肝心の97年のnikkeiBPの記事がリンク切れなのでぐぐっても良く判らないな。
http://bizboard.nikkeibp.co.jp/kijiken/summary/19980817/NC0450H_416091a.html
有料記事化してたこいつかな（SMLのML漁った方が早いのかな）
ともあれあの当時のVBでOO云々っていう事なら
俺も無理ある話だと同感ましたわ。
2006/7にも受注してんのな
ttp://www-06.ibm.com/jp/press/20060719001.html
こっちの話題はいまんところ見当たんない感じ
結構古い話なのね
肝心の97年のnikkeiBPの記事がリンク切れなのでぐぐっても良く判らないな。
http://bizboard.nikkeibp.co.jp/kijiken/summary/19980817/NC0450H_416091a.html
有料記事化してたこいつかな（SMLのML漁った方が早いのかな）
ともあれあの当時のVBでOO云々っていう事なら
俺も無理ある話だと同感ましたわ。
2006/7にも受注してんのな
ttp://www-06.ibm.com/jp/press/20060719001.html
こっちの話題はいまんところ見当たんない感じ
>>887
その発想はいいかもね！
PHPのフレームワークが乱立しているけど、いいとこ取りで自分で組み合わせて使うのがスマートだと思う。
＝大きすぎず小さすぎず、必要十分条件を満たすように使い分けられる時代が来るかな？
その発想はいいかもね！
PHPのフレームワークが乱立しているけど、いいとこ取りで自分で組み合わせて使うのがスマートだと思う。
＝大きすぎず小さすぎず、必要十分条件を満たすように使い分けられる時代が来るかな？
>>891
被ったよ。失礼
被ったよ。失礼
>>891
それだけじゃなくて、名前は忘れたけど九大病院にシステム好きなセンセイが居て、
システムの要件としてオブジェクト指向技術をつかったシームレスなシステム化っのが
あったらしい。
で、IBMはVBだってOOPLなんだから、これもOOだって言い張ってた。
結局どうなったかは知らんけど。
スレと関係なくなってるから、ここまでにしておくね。
それだけじゃなくて、名前は忘れたけど九大病院にシステム好きなセンセイが居て、
システムの要件としてオブジェクト指向技術をつかったシームレスなシステム化っのが
あったらしい。
で、IBMはVBだってOOPLなんだから、これもOOだって言い張ってた。
結局どうなったかは知らんけど。
スレと関係なくなってるから、ここまでにしておくね。
98年というと、Vistual Basic 6.0が発売されたとしか。
どうだろうね。
VB6なら、クラスもインターフェースもあるし、
オブジェクト指向として必要最低限の機能はあるんじゃね？
どうだろうね。
VB6なら、クラスもインターフェースもあるし、
オブジェクト指向として必要最低限の機能はあるんじゃね？
オブジェクト指向って、厳密な定義が難しいよね。
ttp://d.hatena.ne.jp/sumim/20040525/p1
ttp://d.hatena.ne.jp/sumim/20040525/p1
まぁ、別にCでだってOOPしてるプログラムとかAPIはいくらもある訳で。
当たり前だが使ってる言語だけでOOとか非OOとか言うことはできんわな
902 ：nobodyさん：2008/07/17(木) 01:56:21 ID:r8Tb5l59
外国語ではフランス語が一番オブジェクト指向に近い
名詞に性がある言語はOpen Close Principleに反していると思う。反論は認める。
きょうのむずかしいことば「Open Close Principle」
Open Close Principle に一致する日本語のページ 約 55,700 件
http://www.morijp.com/masarl/homepage3.nifty.com/masarl/article/dp-ocp.html
Gang of Fourのデザインパターンは，全部で23個ものパターンがあります．
オブジェクト指向には，カプセル化，継承，ポリモルフィズムといった数少ない道具しかありません．
では，なぜ23個もの多くのパターンになってしまったのでしょうか？
このことは，デザインパターンの中に何かかくされた原理というべきものが存在するということを暗示しています．
それが今回紹介するOpen-Closed Principleです．
Bertrand Meyerによれば，Open-Closed Principleとは次のことを意味します．
「モジュールは拡張性について開いて（Open）おり，修正について閉じて（Closed）いなければならない」
このOpen-Closed Principle -- 「結んでひらいての法則」は，オブジェクト指向設計を考える際，その設計が正しいかどうかの指針を与えてくれるもっとも重要な原理です．
>>903
ネタThanksですｗ
参考になりました(^^)v
Open Close Principle に一致する日本語のページ 約 55,700 件
http://www.morijp.com/masarl/homepage3.nifty.com/masarl/article/dp-ocp.html
Gang of Fourのデザインパターンは，全部で23個ものパターンがあります．
オブジェクト指向には，カプセル化，継承，ポリモルフィズムといった数少ない道具しかありません．
では，なぜ23個もの多くのパターンになってしまったのでしょうか？
このことは，デザインパターンの中に何かかくされた原理というべきものが存在するということを暗示しています．
それが今回紹介するOpen-Closed Principleです．
Bertrand Meyerによれば，Open-Closed Principleとは次のことを意味します．
「モジュールは拡張性について開いて（Open）おり，修正について閉じて（Closed）いなければならない」
このOpen-Closed Principle -- 「結んでひらいての法則」は，オブジェクト指向設計を考える際，その設計が正しいかどうかの指針を与えてくれるもっとも重要な原理です．
>>903
ネタThanksですｗ
参考になりました(^^)v
理解できたようで理解できていないのがオブジェクト指向
オブジェクト指向すら理解できてない乞食は
コンピュータ学園HALでも通っとけ
コンピュータ学園HALでも通っとけ
>>904
> オブジェクト指向には，カプセル化，継承，ポリモルフィズムといった数少ない道具しかありません．
> では，なぜ23個もの多くのパターンになってしまったのでしょうか？
数字はたった10個しかないのに、
ものすごくたくさんの数値パターンがあるのと同じ。
文字はたった26文字（アルファベット）しかないのに、
いろんな小説が作られたのと同じ。
人間は少ないもので、数多くのパターンを表現できるように・・・ではなく、
数多くのパターンを、少ない物で表現可能にしてきたのだよ。進化とともにね。
> オブジェクト指向には，カプセル化，継承，ポリモルフィズムといった数少ない道具しかありません．
> では，なぜ23個もの多くのパターンになってしまったのでしょうか？
数字はたった10個しかないのに、
ものすごくたくさんの数値パターンがあるのと同じ。
文字はたった26文字（アルファベット）しかないのに、
いろんな小説が作られたのと同じ。
人間は少ないもので、数多くのパターンを表現できるように・・・ではなく、
数多くのパターンを、少ない物で表現可能にしてきたのだよ。進化とともにね。
GoFのパターンがデザインパターンのすべてではないしね。
代表的なものであるのはまちがいないけど。
デザインパターンの重要な点は、有能なプログラマなら意識的
あるいは無意識にやっている、まっとうな設計に名前をつけたこと。
名前が付けられることで方法論が共有でき、会話やグループプログラミングがスムーズになるから。
代表的なものであるのはまちがいないけど。
デザインパターンの重要な点は、有能なプログラマなら意識的
あるいは無意識にやっている、まっとうな設計に名前をつけたこと。
名前が付けられることで方法論が共有でき、会話やグループプログラミングがスムーズになるから。
実際理解できてない奴大杉
910 ：nobodyさん：2008/07/18(金) 02:20:52 ID:VtO/mWcS
GoFというネーミングセンスに痛さを感じてしまう。
と思ってたらこれが元ネタ？
http://ja.wikipedia.org/wiki/%E3%82%AE%E3%83%A3%E3%83%B3%E3%82%B0%E3%83%BB%E3%82%AA%E3%83%96%E3%83%BB%E3%83%95%E3%82%A9%E3%83%BC_(%E3%83%90%E3%83%B3%E3%83%89)
と思ってたらこれが元ネタ？
http://ja.wikipedia.org/wiki/%E3%82%AE%E3%83%A3%E3%83%B3%E3%82%B0%E3%83%BB%E3%82%AA%E3%83%96%E3%83%BB%E3%83%95%E3%82%A9%E3%83%BC_(%E3%83%90%E3%83%B3%E3%83%89)
その程度で痛いとか言ってたらdankogaiなんてどうなるの？
PHPのフレームワークはpradoが圧倒的に人気みたいですね
http://q.hatena.ne.jp/1210442237
http://q.hatena.ne.jp/1210442237
Pradoってなんだよｗｗｗｗ
これはひどいｗｗｗｗ
pradoはかなり特殊だから信者がこぞって入れたんだろうな
潔くPHP5だというだけで特殊扱いか。SAXが流行ってた頃を思い出すし、Pradoを俺は嫌いじゃないよ。
いや、PHP5とか好きとか嫌い以前にね。
そのアンケート結果不自然すぎでしょｗ
フレームワーク自体の問題じゃなくて
認知度の問題から、その結果はありえないの。
そのアンケート結果不自然すぎでしょｗ
フレームワーク自体の問題じゃなくて
認知度の問題から、その結果はありえないの。
いやPRADOの特殊性はPHP5縛りとかそんなチャチなものじゃなくて
もっと恐ろしいというか、どう見てもDelphiですな所。
不作為であの結果はありえないっしょ。
もっと恐ろしいというか、どう見てもDelphiですな所。
不作為であの結果はありえないっしょ。
919 ：nobodyさん：2008/07/18(金) 23:40:48 ID:w/EYto11
汎用性ではETHNAでしょ
>Mapleは存在をしりませんでした。T-T。これ日本でつくられているのかな。
ワロタｗ
ワロタｗ
http://radar.oreilly.com/2008/07/perl-on-app-engine.html
GAEにPerlが載ってPHP静かに脂肪ｗｗｗ
GAEにPerlが載ってPHP静かに脂肪ｗｗｗ
脂肪ネタ、実は好きですｗ
Rails の migration のように、データベースのテーブル定義を複数人で同期させる仕組みって PHP にありますか。
なんかよさそうなライブラリやツールがあれば教えてください。
なんかよさそうなライブラリやツールがあれば教えてください。
>>923
俺も知りたいな。
うちでは、Excelのテーブル定義書とテストデータ（や初期データ）ファイルから、
誰かが書いたVBAマクロでSQLをテキストファイルにしている。
テーブル定義やデータが変更されたら、データベースごとドロップして再度流し込み。
この辺をフォローしているフレームワークやライブラリってあるのかな？
まあ上記のやり方で、わかりやすくてしかもPHP以外でも使えるのであんまり必要は
感じていないのも事実だけどｗ
俺も知りたいな。
うちでは、Excelのテーブル定義書とテストデータ（や初期データ）ファイルから、
誰かが書いたVBAマクロでSQLをテキストファイルにしている。
テーブル定義やデータが変更されたら、データベースごとドロップして再度流し込み。
この辺をフォローしているフレームワークやライブラリってあるのかな？
まあ上記のやり方で、わかりやすくてしかもPHP以外でも使えるのであんまり必要は
感じていないのも事実だけどｗ
924じゃないけど、そんなの先にダンプしとけばいいんじゃないの？
カラム名変わってたらちょっと手を入れるけど、
追加とかなら大抵平気だろ。
つか、そもそもそんなにrailsが好きならrailsのmigration使って管理しろよ。
開発環境なんだし、PHPであるひつようなんてないだろ、どうせ。
カラム名変わってたらちょっと手を入れるけど、
追加とかなら大抵平気だろ。
つか、そもそもそんなにrailsが好きならrailsのmigration使って管理しろよ。
開発環境なんだし、PHPであるひつようなんてないだろ、どうせ。
>>925
共通で使うデータ（テストデータ・初期データ）はデータファイルとして
これもExcelにしておく。INSERT文には自動変換。
データのファイルを作るのが結構手間だけど、alterなんちゃらでテーブル
定義を変更し続けて、開発者間での整合が取れなくなるのが一番嫌だから、
あくまでドキュメントベースでやってる。
ただのテスト用データなら、>>926が言うようにそれぞれが勝手にダンプ
すればいいし。
共通で使うデータ（テストデータ・初期データ）はデータファイルとして
これもExcelにしておく。INSERT文には自動変換。
データのファイルを作るのが結構手間だけど、alterなんちゃらでテーブル
定義を変更し続けて、開発者間での整合が取れなくなるのが一番嫌だから、
あくまでドキュメントベースでやってる。
ただのテスト用データなら、>>926が言うようにそれぞれが勝手にダンプ
すればいいし。
>>926
>924じゃないけど、そんなの先にダンプしとけばいいんじゃないの？
>カラム名変わってたらちょっと手を入れるけど、
>追加とかなら大抵平気だろ。
それを、スキーマが変更されるたびに、手作業で、開発者全員がやらないといけないの?
>つか、そもそもそんなにrailsが好きならrailsのmigration使って管理しろよ。
>開発環境なんだし、PHPであるひつようなんてないだろ、どうせ。
別にRailsが好きなんて書いてないんだけど。
Railsのmigrationはよく出来ていると思ったから、PHPではどうしたらいいかを聞いただけ。
なんかRailsに引け目でもあるわけ? >926
>924じゃないけど、そんなの先にダンプしとけばいいんじゃないの？
>カラム名変わってたらちょっと手を入れるけど、
>追加とかなら大抵平気だろ。
それを、スキーマが変更されるたびに、手作業で、開発者全員がやらないといけないの?
>つか、そもそもそんなにrailsが好きならrailsのmigration使って管理しろよ。
>開発環境なんだし、PHPであるひつようなんてないだろ、どうせ。
別にRailsが好きなんて書いてないんだけど。
Railsのmigrationはよく出来ていると思ったから、PHPではどうしたらいいかを聞いただけ。
なんかRailsに引け目でもあるわけ? >926
スキーマーの変更なんて、そんなに頻繁にするもんじゃないと思うけど。
つーか、RailsってORマッパーなしじゃ使えないのかな。ORマッパーって業務でウェブアプリ作るレベルだと意味無いというか、100%害悪だと思うんだけど。
つーか、RailsってORマッパーなしじゃ使えないのかな。ORマッパーって業務でウェブアプリ作るレベルだと意味無いというか、100%害悪だと思うんだけど。
＞それを、スキーマが変更されるたびに、手作業で、開発者全員がやらないといけないの?
スキーマ変更が多いなら、たしかに自動化できた方が良いねえ。
でもrailsのmigrationも万能じゃないって言うか、
気をつけて書かないと全ての開発者の手元で動くmigrationにならなかったりもするので
あまりコスト的には変わらない気もするが、、、どうなんだろう。
＞なんかRailsに引け目でもあるわけ? >926
なんで引け目？ 別にないけど。
＞ORマッパーって業務でウェブアプリ作るレベルだと意味無いというか、100%害悪だと思うんだけど。
スキーマ煩雑に変わるような状況だと、それなりにORマッパーは便利。
でも仕様が固まったあとSQLに置きかえないとやばい。
あと、railsだってORマッパー無視して最初から普通にSQL書いて投げられるよ。
それともそういう話ではない？
スキーマ変更が多いなら、たしかに自動化できた方が良いねえ。
でもrailsのmigrationも万能じゃないって言うか、
気をつけて書かないと全ての開発者の手元で動くmigrationにならなかったりもするので
あまりコスト的には変わらない気もするが、、、どうなんだろう。
＞なんかRailsに引け目でもあるわけ? >926
なんで引け目？ 別にないけど。
＞ORマッパーって業務でウェブアプリ作るレベルだと意味無いというか、100%害悪だと思うんだけど。
スキーマ煩雑に変わるような状況だと、それなりにORマッパーは便利。
でも仕様が固まったあとSQLに置きかえないとやばい。
あと、railsだってORマッパー無視して最初から普通にSQL書いて投げられるよ。
それともそういう話ではない？
>>930
>なんで引け目？ 別にないけど。
だったら最初から
>>つか、そもそもそんなにrailsが好きならrailsのmigration使って管理しろよ。
とか書くなよ。
単に、PHPではどうしたらいいかを聞いているのに、"そんなにrailsが好きなら" とか "Rails使え" とか、ばかじゃねーの
ほんと役立たずな926
>なんで引け目？ 別にないけど。
だったら最初から
>>つか、そもそもそんなにrailsが好きならrailsのmigration使って管理しろよ。
とか書くなよ。
単に、PHPではどうしたらいいかを聞いているのに、"そんなにrailsが好きなら" とか "Rails使え" とか、ばかじゃねーの
ほんと役立たずな926
どうでもいい
>どうでもいい
君の存在が、ですね
君の存在が、ですね
それでいい
っDoctrine
936 ：nobodyさん：2008/08/03(日) 00:58:46 ID:kbqBMR/t
>>924
http://www.asahi-net.or.jp/~ef2o-inue/download/sub09_010_070.html
こんなかんじのVBAマクロ組んでいるんですか？
Excelでテーブル定義表を作って、VBAでテーブル作成のSQL文に変換する方法は、ドキュメント作りの際には便利そうですね。
http://www.asahi-net.or.jp/~ef2o-inue/download/sub09_010_070.html
こんなかんじのVBAマクロ組んでいるんですか？
Excelでテーブル定義表を作って、VBAでテーブル作成のSQL文に変換する方法は、ドキュメント作りの際には便利そうですね。
937 ：nobodyさん：2008/08/10(日) 23:58:17 ID:56GPwW3r
んで、結局どれを使えばいいのカナ？＞フレームワーク
・・・あいやしばらく。
「んなモン、『用途と用件による』に決まってんだろjk」
いや、おっしゃるとおりそのとおり。
でも、向き不向きの議論って、このスレの議論でも結構散発的だったでしょ？
○×△の一覧表なんかあると一応の目安にはなるかなと。
cakeもSymfonyも新しいバージョンになってまだ間もないので、そのあたりもコミでエラい人のご意見をいただければってコトで。
・・・あいやしばらく。
「んなモン、『用途と用件による』に決まってんだろjk」
いや、おっしゃるとおりそのとおり。
でも、向き不向きの議論って、このスレの議論でも結構散発的だったでしょ？
○×△の一覧表なんかあると一応の目安にはなるかなと。
cakeもSymfonyも新しいバージョンになってまだ間もないので、そのあたりもコミでエラい人のご意見をいただければってコトで。
情報源の多いやつを使え。
その過多は各人の環境による。
その過多は各人の環境による。
939 ：nobodyさん：2008/08/11(月) 10:39:03 ID:jwJ3rV7r
cakePHPもSymfonyも、最新Ver.のヤツは情報皆無っす。
cakeは1.2、Symfonyは1.1だよね？
特にSymfonyはかなり変わったっていうし
cakeは1.2、Symfonyは1.1だよね？
特にSymfonyはかなり変わったっていうし
>>938
多寡だろｗｗｗｗどんだけ低学歴なのよPHPユーザｗｗｗｗｗｗ
多寡だろｗｗｗｗどんだけ低学歴なのよPHPユーザｗｗｗｗｗｗ
たか ―くわ 1 【多寡】
多いことと少ないこと。多いか少ないか。
「金額の―を問わない」
多いことと少ないこと。多いか少ないか。
「金額の―を問わない」
>>939
公式の日本語訳まであるのに、お前は一体なにをやってるんだ
公式の日本語訳まであるのに、お前は一体なにをやってるんだ
>>943
ちょっと違う
ちょっと違う
PEAR+Smartyに慣れてるんだが、
それらもサポートしてるフレームワークってあるー？
それらもサポートしてるフレームワークってあるー？
946 ：nobodyさん：2008/08/19(火) 18:48:16 ID:/CvuB95r
ethna
>>945
使えないFWって逆にあるの？
使えないFWって逆にあるの？
ethnaで自作クラスからPEAR呼び出そうとして苦労したあげくFW使うのやめた。
FWのどこでPEAR呼び出しが制限されるんだよｗ
”自作”ってところが鍵になっていると思うよ。
952 ：nobodyさん：2008/08/20(水) 18:09:39 ID:0kYAgOqk
Zendってどう？
途中で消えたりしない？
途中で消えたりしない？
zendが消える≒phpが消える
zendは消えないけど
zfは亡き者に・・・
zfは亡き者に・・・
ゼンド多難
Zendって身売り間近じゃなかったっけ。
オープンソースなPHPやZFの方が寿命長そう。
オープンソースなPHPやZFの方が寿命長そう。
5.3で名前空間が実装された今、ZFはフェードアウトか、
少なくとも大幅な仕様変更があるだろうな。
少なくとも大幅な仕様変更があるだろうな。
ZFに時間と労力突っ込んじゃった奴涙目ｗｗｗ
俺はZFしか触ったことないけど、>>958は他のフレームワークは関係しないの？
phpの親方であるzendが名前空間無視したフレームワークなんて信じられな～～い
ってことでだろ
他のは仕方ないとしても
ってことでだろ
他のは仕方ないとしても
>>960
他はPEARコーディング規約に則したクラス命名してるの少ないからな。
さすがにZendFrameworkは公式なだけあって名前空間使ってくるだろ。
今までも大胆な仕様変更をガンガンしてきた例から見ても間違いなく…
他はPEARコーディング規約に則したクラス命名してるの少ないからな。
さすがにZendFrameworkは公式なだけあって名前空間使ってくるだろ。
今までも大胆な仕様変更をガンガンしてきた例から見ても間違いなく…
ということでZFバージョン３まで待ちましょう
お約束です
お約束です
PEARコーディング規約に即した命名規則ならちょっとした変換スクリプト使えば容易に名前空間対応できるけどな
PHP 6.0
966 ：nobodyさん：2008/08/23(土) 13:37:02 ID:g0UpHeXO
何時出るんだよ。てーかZFのsnapshotもいつの間にか止まってるのか？
967 ：nobodyさん：2008/08/23(土) 20:50:54 ID:R46pd30T
ソースが汚い汚いと言われてたcakePHPが流行ったのって何で？
ソースが美しいzendはなんでこんなにも流行らないの？
初心者でも ほほいのほい ってデータベース構築できないかなぁ
>>970
構築した後どうするの？
結局RDBMSを知ってるか、それを使うアプリ(PHPでのシステムを含む)を
いじれるか、何か出来ないとどうにもならないんじゃない？
こういうデータがあります、これをデータベースｗで管理したいです、っていう
要件には必ずそれなりの知識が必要になります。構築すればいいってもん
じゃない
Ruby on Rails は極力データベースを隠したけど、それでもRailsの約束ごとも
SQLもわからないんじゃどうしようもない、そう言う感じでよろしくと切に願います
構築した後どうするの？
結局RDBMSを知ってるか、それを使うアプリ(PHPでのシステムを含む)を
いじれるか、何か出来ないとどうにもならないんじゃない？
こういうデータがあります、これをデータベースｗで管理したいです、っていう
要件には必ずそれなりの知識が必要になります。構築すればいいってもん
じゃない
Ruby on Rails は極力データベースを隠したけど、それでもRailsの約束ごとも
SQLもわからないんじゃどうしようもない、そう言う感じでよろしくと切に願います
>>969
ちゃんとしたコーディング規約に添って書かれていて、機能も豊富で、
なにげにドキュメントもちゃんとしてたりするけど、
そもそもの目的が「フレームワークを作る」ことにあって実際の現場で
叩き上げられてできたものじゃないのが大きい気がする。
Webアプリケーションフレームワークとして使いたいとは思わないけど、
ライブラリとしてつまみ食いするにはとても良い。
ちゃんとしたコーディング規約に添って書かれていて、機能も豊富で、
なにげにドキュメントもちゃんとしてたりするけど、
そもそもの目的が「フレームワークを作る」ことにあって実際の現場で
叩き上げられてできたものじゃないのが大きい気がする。
Webアプリケーションフレームワークとして使いたいとは思わないけど、
ライブラリとしてつまみ食いするにはとても良い。
PHP4で動くからだろ。
>>972
Cakeやsymfonyが「現場で叩き上げられてできたもの」かどうかはさておいて、ね
どのフレームワークもはじめは頭でっかちだと思うよ
Zendの場合はその頭は筋がよい頭だと普通に思う
筋がよいといっておかしければ、PHPのアップグレードの方向性に沿っているというか
多分、言いたいことはそれが使う上で使いやすくこなれているかどうかってことだと
思うんだけど、なんでZendはそうならなかったのかっていうのは興味がある
無粋すぎたのかな？
Cakeやsymfonyが「現場で叩き上げられてできたもの」かどうかはさておいて、ね
どのフレームワークもはじめは頭でっかちだと思うよ
Zendの場合はその頭は筋がよい頭だと普通に思う
筋がよいといっておかしければ、PHPのアップグレードの方向性に沿っているというか
多分、言いたいことはそれが使う上で使いやすくこなれているかどうかってことだと
思うんだけど、なんでZendはそうならなかったのかっていうのは興味がある
無粋すぎたのかな？
Zend_Formとかすごいと思うよ
吐き出すHTMLが綺麗なこと
吐き出すHTMLが綺麗なこと
ZendFrameworkはPEARの代替だと思っていた私は異端ですか？
というかそれでいいからぜひ開発、進歩を続けてほしいと今でも
思うんだが
サンプルコードとして、一つの指針としての価値は思いっきりあると
思うんだが、「できる」人たちには必要のないものなのかな？
というかそれでいいからぜひ開発、進歩を続けてほしいと今でも
思うんだが
サンプルコードとして、一つの指針としての価値は思いっきりあると
思うんだが、「できる」人たちには必要のないものなのかな？
ZFはPHP5の機能、PHP5的なコーディングのショーケースといった側面も強いように思う。
PEARさえいつまでたってもPHP4な状況に業を煮やして作られたような。
だからPHP5.3がリリースされたら名前空間や遅延的束縛、無名関数を使った
ZF2.0にシフトするんじゃないかと予想している。
閑話休題。
PHP6で搭載予定だった機能のうちUnicodeを除いたほとんどが5.3にも搭載されているのは
嬉しいことだけど、そうなると6がいらない子になってしまいそうで...
PEARさえいつまでたってもPHP4な状況に業を煮やして作られたような。
だからPHP5.3がリリースされたら名前空間や遅延的束縛、無名関数を使った
ZF2.0にシフトするんじゃないかと予想している。
閑話休題。
PHP6で搭載予定だった機能のうちUnicodeを除いたほとんどが5.3にも搭載されているのは
嬉しいことだけど、そうなると6がいらない子になってしまいそうで...
>>978
ああ、なんとなくわかる
結局みんな5.3で、6.xが普及するまでまた３年ほどかかるんじゃ
ないかっていうｗ
もうPHPの宿病だとは思うが
いまだに4.xで動かさなきゃいけないとかいう現実をみると
ああ、なんとなくわかる
結局みんな5.3で、6.xが普及するまでまた３年ほどかかるんじゃ
ないかっていうｗ
もうPHPの宿病だとは思うが
いまだに4.xで動かさなきゃいけないとかいう現実をみると
5が出たのいつだっけ？
3年で済むかな・・
3年で済むかな・・
PHP5.3の無名関数って、あれちょっと違うよな。create_function()がかきやすくなったに過ぎない。
Javaとかの無名関数だって内部的な挙動を考えれば結局あんなもんじゃないかと・・・
書きやすいというのは大事。というかcreate_function()の書きにくさは異常。
クロージャの構文はもっと頭をひねってほしかったと言わざるを得ない。
クロージャの構文はもっと頭をひねってほしかったと言わざるを得ない。
でも、それだけやっても
あまり使い道はない。
あまり使い道はない。
array()の代わりに[]で配列を初期化できる機能は取り込まれないわけ？こっちの方がよっぽど価値高いと思うんだが。
array(array(array()),array(array()))←こういうのがウザイから。こういうふうに書かないといけない主要な言語はphpだけ。
RubyやPerlで複数行コメントが使いにくいので/* */的な記法が
欲しいとかいう感じのものよりは価値が低そうだ
無いものねだりとか隣の芝生とかいったりするかも
欲しいとかいう感じのものよりは価値が低そうだ
無いものねだりとか隣の芝生とかいったりするかも
>>989
それでもエディタが教えてくれるなら別にいいと思うが。普通はインデントとかして
分かりやすくするよな。じゃarray()なら分かりやすいかっていうと、逆にウザいだけだ。
[ 'validators' : [ 'inArray', 'mailaddress'] ]とかすっきりしていいよ。
functionて書くのすらウザいもの。
それでもエディタが教えてくれるなら別にいいと思うが。普通はインデントとかして
分かりやすくするよな。じゃarray()なら分かりやすいかっていうと、逆にウザいだけだ。
[ 'validators' : [ 'inArray', 'mailaddress'] ]とかすっきりしていいよ。
functionて書くのすらウザいもの。
確かにarrayはうざい
>>991
そういう設定系なら、むしろもうテキストで読み込んでパースしたら？
それなら言語関係なく使えるじゃん
その為のJSON、YAML等なんだから
で、そういった「設定」以外でネストしたarray記述を書く部分って、
思ったより少ないよ
そういう設定系なら、むしろもうテキストで読み込んでパースしたら？
それなら言語関係なく使えるじゃん
その為のJSON、YAML等なんだから
で、そういった「設定」以外でネストしたarray記述を書く部分って、
思ったより少ないよ
配列のショートカットがないのはPHPだけだから。
その時点でおかしいってことに気付けよ。
しかし、実装が難しいっていうなら仕方ないけど、もう出来てるんだろ。
何でリリースに取り込まないわけ？
その時点でおかしいってことに気付けよ。
しかし、実装が難しいっていうなら仕方ないけど、もう出来てるんだろ。
何でリリースに取り込まないわけ？
数多くの修正・追加の中で、優先度が低いとされているから、だろ
結構前からずーっと要望している人もいるみたいだけど、うざがら
れている可能性もある。
ある意味Ruby信者みたいな感じに、とかｗ
結構前からずーっと要望している人もいるみたいだけど、うざがら
れている可能性もある。
ある意味Ruby信者みたいな感じに、とかｗ
次スレ立ててみた、が、いきなりスレタイ失敗した。ごめんなさい・・・
【PHP】フレームワークについて語るスレ10【総合】 ← ※本当は11
http://pc11.2ch.net/test/read.cgi/php/1219581817/
【PHP】フレームワークについて語るスレ10【総合】 ← ※本当は11
http://pc11.2ch.net/test/read.cgi/php/1219581817/
配列を宣言する構文がarray()なのは、PHP/FIくらいの時代にはarray()が関数だった名残
・・・と、妄想してみる。PHP/FIを使ったこともソース読んだこともないけどｗ
・・・と、妄想してみる。PHP/FIを使ったこともソース読んだこともないけどｗ
(-_-)/~~~ピシー!ピシー!>>996
arrayがうざくないっていう人うざいよ
もし短い書き方が導入されたらそっち使うでしょ？
もし短い書き方が導入されたらそっち使うでしょ？
1000ならPHP脂肪ｗｗｗ
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
もう書けないので、新しいスレッドを立ててくださいです。。。