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

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

[前50を表示]
600:nobodyさん
08/05/21 15:48:10
Microsoftが買収したら、なにやらワケが判らぬフレームワークが前提になって、
そのフレームワークの機能はIISでしか動かないみたいなのはあるかもよ。

あぁ、想像しただけで嫌だ。

601:nobodyさん
08/05/21 22:30:45
MSにはASP.NETという洗練されたフレームワーク、VisualStudioという高機能なIDEがある。ガキのおもちゃのようなPHPと一緒にするな。

602:nobodyさん
08/05/21 23:44:23
ASP.NETってどこで使われてるの？
GoogleとかYahooとかAmazonとか楽天とかMixi見たいな大手で。
もちろんMicrosoftのサイトは除いて。

直感だけど、MSのフレームワークが前提になったらPHPは確実に死ぬと思う。

603:nobodyさん
08/05/22 00:36:44
>ASP.NETってどこで使われてるの？
うちJavaに次いで.net/レガシーASP案件が多いよ
でもASPはイントラ用途での案件ばっかりだな
IISに.netにMSSQLにPowerShellにVSSと、MSモノで固めた場合は
けっこういい環境だと思うんだけどねー。
MSモノだけやる訳じゃないせいか、誰もVisual Studio使ってないけどw

つまり、MSモノで固められるケースが限られるのが問題なんだろう。
レン鯖とかでも（Javaともども）機能制限しにくい故にユーザに提供しにくいしな。
その隙間をPHP需要が埋めているんじゃないかい。

604:nobodyさん
08/05/22 01:06:04
ASP.NET → PHP.NET

まさかのM$大逆転

605:nobodyさん
08/05/22 01:06:57
>>603
結局さ、ASP.NETが良いのってSIerにとってでしかないと思うんよ。
小さく使われる、汎用性がないプログラムとしてと言うか。

そういう前提がなければ PHPなりPythonの方が有用だから、大手のサイトでは
ＰＨＰやPythonなんかが使われてるじゃかなろうかと思ってる。

仮にＭＳに買収されたら、PHPはPHPらしさを残せるかのかなぁ。かなり不安。

606:nobodyさん
08/05/22 01:11:58
VisualBasicの後継はVisualPHPで

607:nobodyさん
08/05/22 01:22:14
どうVisual・・

っていうかDreamWeaverとかじゃねえのそれ

608:nobodyさん
08/05/22 13:40:13
ASP.NETくらい作りこまれたフレームワークはない。コミュニティベースのフレームワークとは出来が違う。VisualStudioもそうだけど。
ただ、イントラ以外の、一般のウェブサイトの場合、結局凝ったデザインを実現するための泥臭い部分に多くの労力を割かれるので、ASP.NETのメリットは薄れる。
後は、LAMPみたいに全部無料ではないので、中小規模の場合、LAMPを選択することが増えるだろうな。

609:nobodyさん
08/05/22 15:06:08
実際、WEBアプリ業界って言ったら、Windowsサーバに抵抗感があるというか触ったことのない
会社・技術者も多いんだけどね。特にCGI等の設置運用あたりからぽこぽこ出来た会社はｗ

610:nobodyさん
08/05/22 15:43:18
泥臭い部分で真価を発揮できない作りこまれたFWとかｗ
そういう仕事を片付けるためのFWじゃねーのかよ

コミュニティベースかそうじゃないかで
出来が云々とかいかにもMSのバカ顧客らしい発想だ
その作りこまれたFWとやらで死ぬまで
綺麗で泥のないアプリを作りつづけてろ

611:nobodyさん
08/05/22 16:11:39
>>608
想像だけど、確実にMS　は　Yahoo みたいな超大規模なところには、ほとんど無料で使えるような
営業をかけてると思う。仮に　Yahooのサイトが ASP.NETで運用されれば、広告効果大きいし。

だから、ASP.NETが PHPとかPythonより大規模なサイト構築に向いていれば、使ってないはずがない。

パフォーマンスの問題か、セキュリティに対する透明性の問題か、生産性の問題化は判らんが、
大規模なサイトにおいては ASP.NETは　PHPとかPython以下という評価がされているだけだと思う。

中規模なところには普通にしか販売しないだろうから、ASP.NETはイントラみたいな小規模なところでしか
使われない気がする。SIerとしては、そっちのほうがマーケットが広いだろうから、そんなに悪い話でもないけど。

612:nobodyさん
08/05/22 17:50:15
MS製品はしょっちゅうトロイとか埋め込まれてる印象

613:nobodyさん
08/05/22 23:15:21
いや、大企業ほどIISの比率が高いから。金がかけられるところはJavaやASPが多い。
Apacheが強いのは予算のないところとか、２ちゃんみたいにひたすらウェブサーバの数を増やしたい大規模なサイト。

614:nobodyさん
08/05/22 23:18:13
補足しておくけど、大規模なサイトと予算の大きなサイトは別物だから。

615:nobodyさん
08/05/23 00:01:10
でも結局ネットでビジネスやってるようなシステム運用に詳しくて、大規模なトラフックがあるところは
あんまりASP.NETを使用してないんでしょ？やっぱ本質的な問題があるんじゃないの。

事例見ても、イマイチぱっとしないし。
URLﾘﾝｸ(www.microsoft.com)

616:nobodyさん
08/05/23 00:55:23
実際MSを全面的に信用してる奴は少ないと思うよ。
本質的な問題、とやらがあるのかどうかは判らんけど、
「ソースが公開されてていざとなれば力技が効く」世界とは180度方向性が違うからねえ。

その事例のリード文で処理規模謳ってるのはセガダイレクトくらいか
「.aspx」で終わるURLぐぐるといろいろ出て来るけど、大規模サービスって感じのはないなー。
リネ2のwebとかJR東の運行情報とかパンヤのwebとか地図閲覧サービスとか
まあそれなりに規模あって安定性が望まれるサービスも垣間見れるね。

致命的な弱点があるようには見えないな
オープンソースじゃない事、ってのは一つの理由になると思う。

617:nobodyさん
08/05/23 01:25:55
htmlエスケープどういう方針でしてる？
俺は文字列と、文字列が入った配列を再帰的にエスケープして、
オブジェクトはそのままviewに渡してるけど

618:nobodyさん
08/05/23 06:55:54
>>617
本質的にはhtmlを生成するときにその場でコンテキストにあわせてエスケープするのが適当だよ。
htmlに入れ込むといってもテキスト要素として入れ込む場合と属性値としてクオートの中に入れるばあいなんかに分かれるから。

619:nobodyさん
08/05/23 10:28:17
日本はApacheのシェアが高い。
日本は今でもApacheしか対応してないレンタルサーバ屋が多いけど、アメリカは昔からレンタルサーバ屋がIISとApache両方対応してた。
Fortune1000を対象にしたシェア調査が少し前に話題になったけど、大企業のコーポレートサイトなど、予算のかけられるところはJavaやASPが強い。
PHPで名もないウェブサイトしか作ってないと、そういう実感はないだろうけど。

620:nobodyさん
08/05/23 10:29:53
ApacheやLinuxのカーネルハックできる人材なんて、その辺のウェブ屋にはまずいないから。オープンソースか否かなんて関係ない。

621:nobodyさん
08/05/23 10:52:28
誰もWebServerとしてIISが劣るとは言ってないんだが、何を言ってるんだろ。
それにしても2回に分けて書くのは芸風か。

622:nobodyさん
08/05/23 13:01:37
>PHPで名もないウェブサイトしか作ってないと、そういう実感はないだろうけど。
↑俺のことですねｗ

Webアプリは、PHPとJavaしか使ってない★
ASP.NETじゃないと実現できない機能は今のところ無し(・∀・)
どうしてもASP.NETじゃないと無理なら手を出しますが、他の実現方法を探すかな？
…というかMS製品しか使っていない客には当たったことないです（ラッキー！？）

623:nobodyさん
08/05/23 13:04:32
大手のSIerではPHPを使う案件はやってないんですか？
大手＝PHPを使わない企業という定義でOKですか？
そんなわけねーだろｗｗｗｗｗｗ

624:nobodyさん
08/05/23 13:14:15
PHP→名もないウェブサイト→人生負組みのツールでもいいじゃん
自分が便利だと思ったら使えばいい

他人の判断、他人の価値観を気にして、他人に認められたいと思う演技を続ける人生は、勝ち組じゃない
奴隷じゃないなら、最後は自分の判断で決めろ

…俺はRuby、Pythonの準備をしときますｗ

625:nobodyさん
08/05/23 13:28:14
>>623
Javaなんかだと顧客側が動作環境を WebsphereとかWeblogicに限定してるところ
は多いでしょ。SI案件だとフリーの環境は一切使いたくないってのは普通だし、
そういう客のほうがカネ払いもいいだろうし。

ただ、そういうのは技術的な判断じゃないから、これをもって技術的にも良いはずって
言うのは愚かしいと思う。

626:nobodyさん
08/05/23 17:03:53
>>618
よくいるよな、おまえみたいな無知ｗ
属性値はいわばRCDATAなのでHTMLエスケープに関してはPCDATAと全く違いなし。
現在のほぼ100%のUAが、属性値もエスケープされていることを見込んでパースしている。

627:nobodyさん
08/05/23 21:22:09
>>626
618じゃないけど
RCDATA、PCDATAという用語は初めて知った。
参考になったよ、ありがとう

データ形式一覧
URLﾘﾝｸ(bakera.jp)

#PCDATA (構文解析対象文字データ) の解説
URLﾘﾝｸ(bakera.jp)
PCDATA は Parsed Character Data の略で、「構文解析対象文字データ」です。

RCDATA (置換可能文字データ) の解説
URLﾘﾝｸ(bakera.jp)
Replaceable Character Data、「置換可能文字データ」です。

628:nobodyさん
08/05/24 00:03:21
>>626
じゃあ、その上で、
どの時点でどのような処理をしてエスケープすればよいかを具体的に教えて。

629:nobodyさん
08/05/24 22:02:37
>>626
RCDATA言いたかっただけなんですね、
ええ、わかります。

630:nobodyさん
08/05/24 22:37:13
まるごと Ruby! 発売でPHP斜陽の感ありありｗｗｗ

631:nobodyさん
08/05/25 11:29:57
YahooとMicrosoftの仲人はPHP？

PHP on IIS - MicrosoftがPHPをフルサポート
URLﾘﾝｸ(www.microsoft.com)

【Special Seminar】 PHP on IIS - あなたの可能性を広げる、Windows 環境へ -
URLﾘﾝｸ(msevents.microsoft.com)

632:nobodyさん
08/05/25 13:35:47
P++

633:nobodyさん
08/05/25 16:38:21
>>626
javascriptのエスケープはコンテキストによって、
ブラウザによって必要とされるものは違うでしょ。

「HTMLエスケープ」っていう言葉が悪い気はするけど。

634:nobodyさん
08/05/25 22:06:40
>>633
どう違うの

635:nobodyさん
08/05/26 04:04:46
>>633
遠回しに言ってんじゃねーぞハゲ
HTMLエスケープはHTMLエスケープであって
それ以上でも以下でもない

636:nobodyさん
08/05/26 09:16:56
>>634
>>635
URLﾘﾝｸ(www.google.co.jp)

637:nobodyさん
08/05/26 09:25:06
テンプレートでデフォルトでhtmlspecialcharsされるようにしてる。
ユーザ入力でタグの中に何かを出力する場合(ほとんど無いけど)は、
ホワイトリスト方式。

638:nobodyさん
08/05/27 23:55:46
フレームワークのせいで後々のメンテの度に長時間取られる。
PHPなんて、なーんも考えずに工夫せずにコピペ最強でサクっと済ませられる「フレームワーク」なんだがな。

639:nobodyさん
08/05/28 01:02:34
規模によるって
話を単純化し過ぎ

640:nobodyさん
08/05/28 01:55:54
そうだよなぁ。
規模がでかいと、謎エラーの出所が分かんない場合あるよね。
何回も呼んでるフレームワークの関数で、止まる時とかさ。

大概人的ミスだから、CVSとかで誰がやったか、すぐにばれるんだがな。
そんな時はブーブー文句垂れるおｗ

641:nobodyさん
08/06/06 02:37:05
FW使うとメモリ喰うから
apacheのプロセス数が増えるとメモリが圧迫されてmemcacheが消えるね
一台の鯖で稼働できるプロセス数かなり減らね？

642:nobodyさん
08/06/06 07:32:19
一番メモリ食わない言語って何？
やっぱPerl?

643:nobodyさん
08/06/06 08:14:24
アセンブラ

644:nobodyさん
08/06/06 08:18:17
今時アセンブラでウェブアプリ書いてる奴いるわけねーだろ
はてなもPerlだし、やっぱPerlなのかな？

645:nobodyさん
08/06/06 08:56:45
軽いと言われるciですら、現在メモリ700KB
1リクエスト毎にドラクエ4の全容量以上のメモリを食うって一体…

646:nobodyさん
08/06/06 08:57:39
perlも良いフレームワークがあればもっと流行るんじゃない？
まぁ、続きは向こうで。

【Perlフレームワーク】Catalystを語る人
ｽﾚﾘﾝｸ(php板)

647:nobodyさん
08/06/07 08:06:42
PHPの場合、ウェブフレームワークがすべてのモジュールを内蔵していて、外部に独立してるのはせいぜいSmartyくらいだけど、
Perlの場合、Catalyst含めて、独立したモジュールが集合して構成されるので、PHPのようなウェブフレームワークとは意味が違ってくる。

648:nobodyさん
08/06/07 12:29:05
Perlでライブラリとして提供されてるものが
PHPでは関数やエクステンションで提供されてるだけの話で
本質的にはたいして変わりなくね？

649:nobodyさん
08/06/07 19:46:49
PHPはテンプレートエンジンもORMも、フレームワークごとにバラバラだから。

650:nobodyさん
08/06/07 21:25:56
なんでSmartyもしくはFlexyを敬遠するのかな、とは思ったことがある。
大体だれかが野良クラスで対応するじゃない。
パフォーマンスにしたって、それ以外の部分でがっつり重いFWも結構あるし。

もうViewクラスを作るのはほぼ共通なんだから、Zendがなんか作ってくれ
ないかな。if と foreach と変数展開（オブジェクトのメソッド呼び出し含む）と、
スクリプトでregisterしたヘルパメソッドのみが使えるとかいう感じで。

PDOみたいに組み込みクラスで速ければ、とりあえず俺は多分それを使う

651:nobodyさん
08/06/08 13:31:14 oe9fgjbi
そこでPECLですよ

652:nobodyさん
08/06/08 23:13:03
一番速いテンプレートエンジン - Blitz - Do You PHP はてな
URLﾘﾝｸ(d.hatena.ne.jp)

653:nobodyさん
08/06/09 02:02:29
一番速いテンプレートエンジンはPHPそのものに決まってるだろ。

654:nobodyさん
08/06/09 13:52:03
PHPそのものだと、構文がテンプレートっぽくない。

BlitzはPHP拡張として作られているから、PHPそのものといえる。
SmartyもPHPそのものに変換されるから、PHPそのものといえる。

655:nobodyさん
08/06/09 14:03:38
ところでPieceFrameworkはフロー定義を書き換えるたびにクッキー消さなきゃならんというガッカリな仕様は直ったのかな？

656:nobodyさん
08/06/09 14:28:34
テンプレートエンジン派ってデザイナにテンプレート書かせてるんだよな？
それ以外にテンプレートエンジン使ってる奴がいたとしたら救いようがないうつけ者だな

657:nobodyさん
08/06/09 17:37:34
>SmartyもPHPそのものに変換されるから、PHPそのものといえる。
これは違うだろ。うぇぶでざいなあが作る段階でPHPじゃないのだから。

658:nobodyさん
08/06/10 00:15:51 00QPcxQH
>>656
WEBデザイナー兼WEBプログラマーな私はSmartyを使っておりました。
最近はテンプレートは生PHPで充分ということに気付き、原点回帰しました！

659:nobodyさん
08/06/10 05:28:42
よく知らんのだが、「PHPそのもの」って言ってるやつのFWでも、それはあくまで記法だけで、
スコープを確保するためにファイルを読み込んでeval()してそうな気もするんだが、違うのかな。

それとも、グローバルにオブジェクト（や関数）を置いて、それを参照するのを前提にrequireなの？

660:nobodyさん
08/06/10 09:31:44
requireすると、呼び出し場所のローカルスコープで
実行されるので、別にeval()する必要は無かろう。

っていうか、そんなPHPフレームワークあるの?
RoRはerbでevalしてるが。

661:nobodyさん
08/06/10 11:18:10
ZF勉強していて思った。
MVCはいいけど、そのためにいろんな「専用の」クラスの使い方
を覚えなければいけないし、覚えてもZFのみってことは、
別のFWに変更するときや、ZF自体が消滅（ありえない？）するときには、
その資産がチャラになっちまうんじゃないの？
大規模開発に向いている、プログラミングの標準化ができるってのが
ウリだと思うけど、FW乗り換えなんかを考えるとデメリットも大きいよな。
そんなんだったら、自分のシステムに必要なクラスを自分で作って
充実させていったほうがいいのかな．．．．とも思う。
まあ、その維持管理が大変といえば大変だが、資産が消滅することや
方針変更で別のものに作り変えるときでも、ノウハウが残るから、
長期的なスパンでみるとメリットがあるんじゃないのかなあ。

特にシステム開発環境を選択している人、そういう問題点ってどう考えている？

662:nobodyさん
08/06/10 12:12:38
>>661
俺俺FWは、俺しか使えない。
他人が使うと、学習コストがかかる。
ましてや、俺と仕事するときにしか使えない。

その点、ZF等のFWは既に学んでいる人々がいる。
その人たちと共同で仕事ができる。

独りでできるもんっ♪なら俺俺でFA
既に学習した人たちのTips等を利用したり、
共同で作業したいなら、
既存のFWでいいんじゃね？

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

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

664:nobodyさん
08/06/10 12:27:28
俺俺ラッパー書いてそこからZFなり呼び出すようにしたら
ZFが死んでもなんとかなるじゃん

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

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

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

666:nobodyさん
08/06/10 13:13:11
>>665
なんかもう>>661の中で結論決まってる予感。

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

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

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

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

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

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

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

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

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

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

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

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

670:nobodyさん
08/06/10 15:11:29
いきなり俺俺は無謀だな
一回メジャーなFW使ってみてから手を出すならともかく

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

672:nobodyさん
08/06/10 17:28:40
単純にZF死んだら困るから自分で作るよ!っていう理由に納得できないだけだろう。

673:661
08/06/10 17:29:20
>>669

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

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

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

674:nobodyさん
08/06/10 17:32:43
zfに乗り換える人なんていないでしょ
ショボfwじゃん

675:nobodyさん
08/06/10 17:35:53
どうやって資産をメンテしていくっていうか、
それは普通にソースツリーをフォークしてメンテするだけだろう?

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

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

677:nobodyさん
08/06/10 19:46:40
たとえばsymfony作られたサイト
世界全体でも1000もないだろｗ

678:nobodyさん
08/06/10 21:11:39
とりあえずDISる
↓
少し釣れる
↓
ツンデレ教えて君

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

679:nobodyさん
08/06/10 21:26:00
数字おおげさに言い過ぎる
↓
突っ込まれる
↓
雲隠れですねわかります

680:661
08/06/11 09:37:45
>>676
なるほど、すべて書き換えないケースもあるな．．．．
しかし、千本単位が非現実的なら、「大規模開発」って
謳っているのはどのくらいの規模なんだろうか。

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

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

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

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

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

683:nobodyさん
08/06/11 23:37:36
>>681

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

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

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

685:nobodyさん
08/06/12 00:18:48
>>684
pear installコマンドって、ダウンロードした後、勝手にセットアップまでしてくれんじゃないの？

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

違うの？

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

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

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

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

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

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

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

690:nobodyさん
08/06/12 23:17:19
>>689
極端な意見ｷﾀｰ
っていうかそれならもうMS製品で作っちゃえよ・・・
その方向で少し間違えると、キーを押したりマウスを動かしたりするたびにリクエストの発生する
糞サイトになるぞｗ

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

691:689
08/06/12 23:58:39
>>690
作ってて違和感あるんだよね。なんだかばかばかしい。
.NETって言われるだろうなと思ったけど、MSに閉じた技術ってのがね。

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

692:nobodyさん
08/06/13 00:15:02
>>690
>AIRとかもあるしね
あれは勧めちゃいかんわさ。MSの.net以上の勘違い製品。

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

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

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

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

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

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

695:nobodyさん
08/06/13 02:12:02
>>694
イベントドリブンって言葉だけに反応すると、
PRADOとか、PHPのフレームワークはイベントドリブンらしいよ。

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

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

697:nobodyさん
08/06/13 20:10:11
>>696
だが不可能ではない。
そして確実に流れはそちらに向かっている。

698:nobodyさん
08/06/13 23:34:10
向かってねー与。

699:nobodyさん
08/06/13 23:43:31
googleやadobeの動向も知らないのか？

700:nobodyさん
08/06/14 00:22:27
PhotoShopがFirefoxのプラグ印になるといいね。

701:nobodyさん
08/06/14 00:27:33
>>699
kwsk

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

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

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

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

703:nobodyさん
08/06/16 12:59:18
HD壊れかけ？

704:nobodyさん
08/06/18 02:05:34 ZYTHmHR0
データが飛んで初めて分かる、バックアップの重要性＞＜

705:nobodyさん
08/06/19 21:58:18
バックアップ？ああ、そういやPHPやってる雑魚どもはSVN使わんな。どいつもこいつもWindowsでeclipseを使いつつ、subclipseを入れてないｗ

706:nobodyさん
08/06/19 22:29:31
何この頭の悪そうな書き込み

707:nobodyさん
08/06/20 00:37:33
お手軽にCVS使って、時々圧縮・暗号化したのをYahooブリーフケースにおいてる。

708:nobodyさん
08/06/20 00:41:52
svnって開発時には使うけど稼働時に使うか？

709:nobodyさん
08/06/20 01:08:36
>>708
稼動時でもバグが見つかれば更新しないといけないから
稼働環境でもマージ作業せなあかんやろ

710:nobodyさん
08/06/20 02:15:40
何この頭悪そうな話題のずれて行き方

711:nobodyさん
08/06/20 12:38:43
PRADOわかる人いる？

712:nobodyさん
08/06/23 10:47:52 isKyS0yI
以前、使ってみた（というか実験してみた）ことある。

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

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

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

715:nobodyさん
08/06/25 01:09:00
Kohana使ってるよ。
日本語情報どころか英語の情報もあまりない。

716:nobodyさん
08/06/25 11:12:53 2TehNRcN
>>713
詳しく書かないでｽﾏﾝ。

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

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

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

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

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

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

717:nobodyさん
08/06/25 13:22:19
Webアプリ、しかもPHPでDelphi丸出しは厳しいものがあるよね

718:nobodyさん
08/06/25 17:48:03
>>716
なるほど。２．０の仕様だな。

719:nobodyさん
08/06/25 19:18:36
突然すんません。

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

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

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

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

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

よろしくお願いします。

720:nobodyさん
08/06/25 19:20:21
ググれ

721:nobodyさん
08/06/25 19:39:02
>>719
framework
【名】
1. 骨組み｛ほねぐみ｝、フレームワーク、枠組み｛わくぐみ｝、下部構造｛かぶこうぞう｝、骨格｛こっかく｝

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

722:nobodyさん
08/06/25 19:49:30
>>721
ありがとうございます。

ググってました。

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

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

723:nobodyさん
08/06/25 20:15:21
>>722
家を建てるに当たって、その骨組みが出来ているって感じ。
で、その骨組みに合わせて作っていくので、やりやすいよと。

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

724:nobodyさん
08/06/25 20:27:52
>>723
ありがとうございます。

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

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

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

725:nobodyさん
08/06/25 20:34:00 gyu7FUKS
直訳すると枠組み、だと思うんだが、骨組みの方が俺的にもしっくり来るね。

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

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

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

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

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

727:nobodyさん
08/06/25 20:40:00
こんな抽象的な話を聞いて何が分かるんだろうｗ

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

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

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

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

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

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

729:nobodyさん
08/06/25 20:43:00
>>725
ありがとうございます。

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

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

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

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

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

730:nobodyさん
08/06/25 20:46:21 gyu7FUKS
下げ忘れた（汗）

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

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

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

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

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

731:nobodyさん
08/06/25 20:47:14
もうすでに無駄なコストかかってるんでは

732:nobodyさん
08/06/25 20:53:37
また忘れた（汗）
ってか、みんなレス早いな。

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

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

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

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

734:nobodyさん
08/06/25 21:03:51
>>728
ありがとうございます。

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

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

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

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

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

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

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

明日本屋行ってきます！

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

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

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

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

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

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

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

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

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

739:nobodyさん
08/06/25 23:42:13
>>737
ちょっと話題とずれるけど、
URLﾘﾝｸ(d.hatena.ne.jp)
最近、こんなの見つけた。

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

740:nobodyさん
08/06/26 00:01:32
>>736
PHPのソースコード（C++?）は読まないけど、マニュアルは死ぬほど読む
ヴァージョンの差異もでかいしorz

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

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

741:nobodyさん
08/06/26 00:06:30
>>736
たまにPHPのソースコード(Cだよ)も読むよ

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

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

742:nobodyさん
08/06/26 00:40:00
>>740,>>741
なるほど～。

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

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

743:nobodyさん
08/06/26 05:27:45
そんなの使いまくりにきまってるやん
企業が使わずしてどこで使うの

744:nobodyさん
08/06/26 07:21:25
大きめの企業でなら、Ethnaとか一時期多かったんじゃない？
さすがにCakePHPやちいたんを使うようなイメージは持ちにくい

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

745:nobodyさん
08/06/26 07:26:20
フレームワークを使ってない企業の方が少ないだろ

746:nobodyさん
08/06/26 14:03:08
日本で作られたフレームワークは使う気がしない。

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

747:nobodyさん
08/06/26 14:07:52
>>746
そーでもない。マルチバイトって何？おいしいの？っていう開発者？も
英米圏にはてんこ盛りだということを忘れてはいけない

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

748:nobodyさん
08/06/26 14:16:13
今時UTF8対応じゃないフレームワークは、使う気がしない。

749:nobodyさん
08/06/26 14:18:26
そんなのあるか？

750:nobodyさん
08/06/26 14:25:59
まあメールライブラリはそのまま使えると思わない方が無難
Validationや文字数カウントが入る部分も微妙

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

751:nobodyさん
08/06/26 14:41:05
ひと昔前までの印象としては欧州産はまだマシで、米国産はI18NとかM17Nとかいう発想が無いのが多かった気がする

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

753:nobodyさん
08/06/26 22:54:59
これからSmartyの仕事にかかる。本当に馬鹿らしい。もうこれでPHPの仕事を最後にしたい。

754:nobodyさん
08/06/27 00:09:22
なるほど。Ethnaとかは使われてるんだね。

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

755:nobodyさん
08/06/27 00:25:40
俺はもうPHPを捨てたぜ！
もう醜いのはうんざりだ
これからはRubyたんとちゅっちゅするんだ

756:nobodyさん
08/06/27 01:10:55
醜いのにうんざりしたと言いながら、よりにもよってRubyかいな

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

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

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

次ページ