愛車:マツダアテンザ
Webを中心とした、ビジネス&テクノロジーに関する思いつき
by F-shin
[ このサイトについて ] [ F-shinについて ] [ トップ ]
iPhoneアプリ
author:えふしん
photo_20.jpg
藤川真一について


初代モバツイ開発者
想創社再創業 / KMD博士課程
著書〜100万人から教わったウェブサービスの極意―「モバツイ」開発1268日の知恵と視点 [Kindle版]
お求めやすい夏休み特価!
このカテゴリ[Web系]の最新30件
本ブログは移転しました インターネットの遊び方を身につけよう ネットでの選挙活動と投票率 Web2.0がうまくいかなかったワケ WebにおけるMVCアーキテクチャの勃興と変遷 何故、PCはブラウザ、スマホはアプリなのか。 言っとくけどスマホは退化でもあるからな。 アイコン5000円とか、Web受注(発注)価格について。 残念なWeb論の骨子 HTMLってホントよく出来てるな。 「やまもといちろう×イケダハヤト対談イベント」のログを読んで ネットサービスの成功者は「とりあえず受託」という言葉使うのやめません? 全収集型RSSリーダーの終焉とソーシャル化するWeb 頑張ると報われるプログラマーの社会とは。 Perlが○○な話 アメリカ製品のすごさと不思議とワイヤフレーム どの人件費を考えても絶対にお得!利用規約ナイトがきっかけの本が出ます。 クラウドやモバイルを、もっと仕事で活用したいけど、どうやって会社を説得したら良いかわからない! スマホアプリらしいUXとは。 インターネットの変化に対して起こるモヤモヤすることを考え、整理する活動 Facebookは見なくてもいい情報が出てくるSNS 「あなたは影響力があるから、そんなことを言っちゃいけません」の問題点 Facebookに時間を取られすぎる対策 Paypalの本人確認がむかつく件 ネット系イベントがとても主催しやすくなった件 モバイルファーストが失敗なハズはないが、今はまだ時期尚早 やりがいはソートできない…非情なデータベース社会 2012年までのふりかえりと2013年へ ブラウザという平面の限界 ブログ記事の流通の難しさ
[このカテゴリをもっと見る]
Powered by
Movable Type

January 03, 2008

スポンサーリンク

やっぱり、PHP・・・・かな

1週間暇ができたのでWEBプログラミングを勉強したいと思います。
〜略〜
・今後プログラミングしていくにあたり有用な、使える言語である
・1週間後掲示板が作れる
・以後まとまった時間がとれず、たとえば1時間単位でも積み上げていけるような基礎(土台)を
 修得できる
以上が条件です。
〜略〜

という、はてなの質問が結構興味深かった。

候補としては、以下のものがあがっていた。
・PHP
・Ruby on Rails
・cake PHP
・Python
・Ruby(CGI)
・Java

本当は途中までレスを書いてたんだけど、肝心のオススメする本がなくて書けなかった。

PHPは、オライリーのはじめてのPHP5は読んだけど、あれは他の言語経験者が読む本なので初心者向けじゃないし、僕の場合は、会社での他人のソースコードと、php.netのリファレンスが僕にとっての情報源なので、あまり人にオススメする情報がない。

そんな前提で何を書いていたか?というと、ポイントとしては以下の3つか。

ポイント: 今知るべき知識は何か?
ポイント:RubyとPHPの言語仕様の違い
ポイント:ネット上の情報について。

■今知るべき知識は何か?
今、この人が知るべき知識は、HTMLとWebサーバとの連携について。GETやPOST、クライアントサイドとサーバサイドの違いを整理すること。

本当は、ここを知るならPerlが一番良いんだろうが、PHPは、Webアプリを作るための言語なのでGET、POSTのデータ処理が標準で内蔵されていて簡単だ。

そして何よりレンタルサーバですぐ動くのは大きいね。

この段階でWebのGETだのPOSTだの以外のプログラミング言語の習得コストは低いに超したことない。


また、ここで知るべきはAjaxでもなければ、O/RマッピングでSQLを書かないでDB連携することでもないし、MVCのアーキテクチャでもないので、Ruby on RailsやCake PHPなどのフレームワークはまだ早い。

というかフレームワークは、面倒くさいところを一通り書けるようになった人が、面倒くさいところが自動化、隠蔽化されている恩恵を受けるべきで、Webでのデータのやりとり方法もわかってないのに、フレームワークの規約を覚えるってのは無理があるだろう。それにRuby on Railsをモノにするには3ヶ月はかかるという話もある。

こういうので混乱するから、Ruby on Railsが10分でWebアプリができた!的な話はあまり好きではない。フレームワークは、まだ行間を読めない初心者が簡単にWebアプリを作るためのものではない。フレームを理解し恩恵を得るためにベタな経験が必要だと僕は思う。


■RubyとPHPの言語仕様の違い
Rubyは、僕の感覚だが結構、情報系の大学を経験してきた人に支持されているという感覚が強い。

つまり、C言語あたりの知識を持った人がやっている言語という感覚。

そういう人は勉強できるし、コンピュータリテラシーも高いので、どんな言語でも使えるんだけど、そんな中で、行間を省略できる言語として、あえてRubyを選んでいる、という印象。

今後、Rubyが注目され、学校や人材育成機関で取り上げられて、「そういう人ではない人」がRubyを使い出すと、これ、VBみたいになるんじゃないか?という印象がある。

つまり、そういう人が「Rubyしか使えないプログラマ」になってしまうんじゃないか、と。ちょっと文法が特殊だからね。悪い意味じゃなくて、ポジティブに。

一番の理由が、文の切れ目がセミコロンじゃない言語ということなんだけど。(Rubyは使ってもいいんだろうけど、使わないよね。)


それに、
a=1
b=2
c=a==b
p c

こんなのが動く。多分、やっちゃいけないし、もっとエレガントな書き方がある。

結果は、falseが出力される。

ちなみに、VBでは、

a=1
b=2
c=a=b
debug.print c

と書けば同じ結果が返ってくるんじゃなかったかな。
if〜then〜end ifを省略するために、フリップフロップとして使うこともあった。さらにビット演算と組み合わせたり。

もちろんVBのそれと、Rubyのそれは意味が全然違う。VBは、「a=b」と書いたものがtrue , falseを返すという仕様があるだけなんだけど、Rubyは、「==」という関数になっていて、関数は左辺に必ず結果を返す、という原則で動いていて、この世界がRubyの世界の広さを特徴づける。(という説明で良いんだよね?)

いずれにせよ、ものすごいお気軽感があるんだけど、こういうのが当たり前になってしまって良いのかは、まだちょっと悩ましい。

(追記:上記意見は内容が今ひとつなので削除

はてブコメントに、PHPでも同じ記述できると書いてあったけど、PHPで同じ事をやると、falseの出力が「空白」になります。trueは1です。そういう値を使ってOn/Offスイッチのような処理を書く気には、僕はならないので、決してPHPではこういうことをしません。Perlも同様のようです。しかし、Javaでは上記記述は可能です。しかしJavaは僕の固定観念として、冗長でも良いからわかりやすく書くという世界だと思っていたので、Javaではやっぱり、こういう記述はしないのですが、可能は可能なので、話が曖昧になると思って削除します。僕はRubyでのメンタリティは、自分がVBを使っていた頃のスタイルに感覚が似ているので、懐古していただけかもしれません。)


僕の意見としては、まだ、とりあえずレガシーなプログラミングを知ってからでも良いんじゃないだろうか。意見はわかれると思うけど。

なんだろ、Perlもそうかもしれないけど、PHPはハッシュテーブル志向という印象がある。PHPのプログラミングとは、要は如何にハッシュを持ち回すか、ハッシュを如何に制御するか、データ突っ込んだりするか?みたいな部分と言えば良いのかな。

PHPの場合、クラスを使っても、外部データとしてのハッシュテーブルを如何に流通させるか?みたいなところに使われてるんじゃなかろうか。DBから引っ張ってきたデータをアクセサメソッドで出し入れするなんてPHPっぽくないと僕は思うし。


そしてPHPはシンプルだと思う。Rubyというかオブジェクト指向は、ブロックがまさにそうだけど、オブジェクトという自分にデータを内包する内向きの世界、そこに機能を作り込むって言う高度な概念。

PHPは、シンプルなハッシュテーブルというデータを持ち回して、データ出し入れして、echoする。

そして習得が容易で、php.netに書いてあるリファレンス以外に知る必要がないという部分。

僕はPHPの関数を覚えるのは苦手なんだけど、なんにもincludeせず、一行ベタに書いて、引数渡せばなんか返ってくる関数が沢山用意されているのはやっぱり簡単だと思う。


■ ネット上の情報について。
phpに関する情報はいい加減なコードが落ちていたり、セキュリティホールが沢山あるという指摘はあろう。

でも同様にPHPのそういうコードのダメなところを指摘する記事も多数ある。

適切に情報を得て、適切なコードを書くには十分な勉強材料があると考えるべきなんじゃないかな。

不安だったら、コレ買っとくと良いよ。

PHPサイバーテロの技法―攻撃と防御の実際
GIJOE
ソシム (2005/11)
売り上げランキング: 49379
おすすめ度の平均: 4.5
5 すべてのPHPプログラマに!
5 すばらしい
1 古い


■まとめ
Rubyがイケてるんじゃないの?と言いつつも、PHPを使う機会は多いし、それが、そんな簡単に変わることはないだろう。

PHPはWebアプリ作成言語として性能も高く扱いやすい。どんなレンタルサーバーでも動かせるし、そういう情報も多い。

ベンチマークで見たり、詳しい人が指摘するダメなところは沢山あるんだろうけど、「けど好き」と思う人はいる。もしくは「仕事に何も問題なく使える」、と思っている人も沢山いるのだ。ネットには出てこないけど。

これから始めるならRubyと言う言葉も聞くが、これから始めたって仕事でPHPのコードをいじることはあると思う。PHPが書けて信頼できるプログラマーってのは重宝すると思う。

以上から2008年初頭においても一番最初に学ぶなら、PHPが良いのではないでしょうか?という見解です。来年は変わってるかな?変わらんか。


僕は今、家でRubyをいじってるけど、仕事ではPHPです。WebのビジネスならPHPを使うことは、全く問題がないと思っている一人です。
Webプログラミング歴は7年です。それまでは制御系のエンジニアでした。


ー余談ー
Flashは、MovieClipそのものがオブジェクト指向なのでタイムラインプログラミングで全然OKで、クラスプログラミングをすることがFlash OOPではないと思っていたんだけど、Rubyを見てると、そういう考えは間違ってないと思うんだけどなー、と書いてて思った。

スポンサーリンク
■同じカテゴリ[Web系]のエントリー
<<前の記事 Web屋、雑感。
>>次の記事 モバツイッターのユニークユーザーが1万人に到達
■このblogの書き込み最新3件
本ブログは移転しました インターネットの遊び方を身につけよう トトロが陽なら、『風立ちぬ』は陰?〜『風立ちぬ』の感想
この記事への提案、提言一覧

>PHPが書けて信頼できるプログラマーってのは重宝すると思う。

重宝はされるかもしれないけれど、でもギャラは同じという罠。

2008/01/04 03:36 名無しさん

> 今、この人が知るべき知識は、HTMLとWebサーバとの連携に> ついて。GETやPOST、クライアントサイドとサーバサイドの> 違いを整理すること。

> 本当は、ここを知るならPerlが一番良いんだろうが、PHP

この一言に尽きるかと。
この辺知らずに、Webアプリ作れますといわれても仕事的には役立たず。
でも、趣味ならPHPがそれなりに簡単でいいかも。画面動かないと楽しくないし、続かないし。

私も、フレームワーク(andデザインパターン)は苦労してから触らないと意味がないと思う。

逆に、他言語を知っているならPHPよりもPerl、Rubyだと思う。CならPerlを、JavaならRubyがお勧め。
理由は、似ているところが多いから。

初めて職場にくるメンバーは下記の順で教育中
1.HTML
2.CSS(リファレンス片手に読める程度。かけなくてもよい)
3.JavaScript(こういうものがあるよっていう程度)
4.Apacheの構築、コンフィグレーション
  ここで、HTTPの仕組みをお勉強。
5.Perl(コマンドライン)
6.掲示板系Webアプリ(Get,Post)
7.画像などダウンロードさせるCGI
8.ファイルアップロード
9.セッション管理手法
うんぬん。で最後に
10.PHP

どうでしょう。

2008/01/04 08:14 名無しさん2

はじめまして。元記事で、RoRを薦めた者です。

>今、この人が知るべき知識は、HTMLとWebサーバとの連携について。GETやPOST、クライアントサイドとサーバサイドの違いを整理すること。

私は、この人がプログラミング初心者という事、Webサービスの本質は何かを考えると、HTTPやGETとPOSTの違いなどという瑣末な点を覚える必要は無いのではないか、と思いました。

もちろん、今後この人が本業でPHPを仕事にする事を考えていらっしゃるのでしたら、セキュリティホールの無いWebサービスを作る必要があると考えられますので、そのような情報を覚える必要があるかもしれません。
しかし、この人がそこまで必要としているようには思えませんでしたし、そこまで含めると1週間では終わらないのではないかと思います。

>なんだろ、Perlもそうかもしれないけど、PHPはハッシュテーブル志向という印象がある。

UNIX流のデータの流れを重んじるプログラミング手法が重要であるのは分ります。
それは、Perl,PHPでも、MVC構造のRailsでも同じだと思います。
しかし、単一の処理をするパイプ相手のプログラミングに比べ、複数の機能を合わせ持つWebサービスの場合はMVC構造という決まった構造を持つ方がわかりやすく、学習しやすいのではないでしょうか?

余談にツッコミ
>Flashは、MovieClipそのものがオブジェクト指向なのでタイムラインプログラミングで全然OKで、クラスプログラミングをすることが Flash OOPではないと思っていたんだけど、Rubyを見てると、そういう考えは間違ってないと思うんだけどなー、と書いてて思った。

まず、タイムラインプログラミングという物がどういう物か知りませんが(Googleでもこのサイトぐらいしか出ない)、
現在のFlashで使われているのはオブジェクト指向プログラミング言語であるECMAスクプトです。
Rubyを見て、Flashに感想を持たれたというのは興味があります。どのような感想を持たれたのか御教えいただければと思います。

2008/01/04 20:48 IKeJI

>1の名無しさん
多分、適切なPHPを書ける自信が持てる人は、PHP以外の言語や環境もやってると思うので、それが価値を生むか否かってのは大事でしょうね。

>2の名無しさん
教育プロセスとしては良いと思います。multipartなどを肌で実感するのはPHPでは、なかなかないと思うので、そういうのはPerlでやった方がヨサゲですね。

でもPerlを書けるようにできるなら、そのままRubyに行ってもいいんじゃないでしょうか?RubyはPerlの置き換えを意識しているそうですし。

そういえば昔、お客さんところの新入社員の教育をしてくれと言われたときにカリキュラムを作ったのですが、最初にHTML勉強した後に、JavaScriptで電卓を作る課題を出しました。

>IKeJIさん
僕もRailsなどと比べる時に、高速道路論と重ねてみたんですね。フレームワークだけを知ってたら、ちゃんと成り立つだろうか・・・と。

でも、やっぱりRails程度の隠蔽度では、GET、POSTの理屈わかってないとキツイなと思いました。例えば、POST先が動かないときに、JavaScriptが間違っててて送られてないのか、URLが間違っているのか、サーバが止まってるのか、500エラーが出てるのか、はたまたLANケーブルが外れてるのか?なんて時に、適切な確認方法がわからない、なんてのはやっぱりいただけないなと思うし。

VBぐらい隠蔽されてれば良いんですけどね。VBでWindowsメッセージのやりとりを捕捉しなきゃ解決できない問題なんてそうないでしょうし。


またMVCですが、MVCをMVCとして整理してうれしい、というのは、その必要性が理解できて初めてうれしいものだと思います。

少なくとも処理を分けるという行為は、何をどう分けるべきなのかを知ってる人だけができることで、それがわからない人には処理を分けるってのは難しいですよ。


ちなみに、ServletでWebアプリに初めてMVCという概念が適用された時には、JavaBeans、JSP、Servletという複数の役割分担を整理したという意味で画期的だったと思うんですね。Servletだけで、良いWebアプリは作れませんし。

ところが、例えばPHPの場合ですが、ちっともMVCをわける意味がない。PHPは、どこでロジックを書いてもDB呼び出しても、文字を出力しても構いません。パッケージも継承も気にする必要はない。どこでもPEARモジュールを呼び出せるし。

なにせPHP自体がテンプレートプロセッサですから。

そんなことよりも、SQLインジェクションとか、ディレクトリトラバーサルとか、ちょっとした文字の処理で起こりうる重大なトラブルを防いで欲しいです。

そういうのさえちゃんと把握できていれば、HTMLコー
ドのど真ん中で、必要に応じてSQLを呼び出すコードを書いたってちっとも構わないと思います。

って、それはちょっとだけ極論ですが、自分が表現したいものを表現する道具としては全然アリだと思います。

>Rubyを見て、Flashに感想を持たれたというのは
>興味があります。どのような感想を持たれたのか
>御教えいただければと思います。

Rubyってオブジェクトを使うプログラムが、必ずしもクラスになっているわけじゃないじゃないですか。Javaは全てのコードが必ずクラスに属していますが。

Flashには、1/15秒とか1/30秒という時間軸毎に制御可能なコマを持っています。このコマの羅列をタイムラインと呼んで、タイムライン上に絵を自由に配置し、スクリプトを記述することで自由にアニメーションを作成することができます。さらにサーバと通信して動的に制御することも。

このタイムラインが直感的だったところがFlashが多くの人に受け入れられた理由です。

しかし、ActionScriptの方は、OOPらしい発展をする中で、FlashコンテンツそのものをJavaのように必ずクラスが存在する、という風に発展しています。その際にタイムラインは隠蔽してしまったのです。

確かにFlashを使ったフォームアプリであれば、1フレームしかないケースもありますから、エンジニアを取り込みたいのであれば、確かに自然です。

しかし、これが従来のFlash使い人が、新しいAction Script3へ苦手意識を持ってしまった最大の理由です。

まぁ、それはそれで仕方ないんですが、タイムライン上にプログラムコードを書いていく手法が決してOOPではないとは思わない、ということです。

旧来のFlashは、MovieClipという単位でオブジェクトが整理されています。アニメーションもMovieClip、ボタンもMovieClipです。インスタンス化されていないMovieClipは「クラス」で、本当に「インスタンス名」という名前でMovieClipを識別しています。

しかも、GUI上でクラスをドラッグして名前をつけるという行為でインスタンス化していて、VBよりも多くの属性の人に使えるという意味で、非常に高度なオブジェクト指向の仕組みである、というのがFlashの実体と言えます。

MovieClipは、Stageと呼ばれるメインの時間軸とは別に、MovieClipにも独自の時間軸を持っています。あたかもステージ上の役者さんが、それぞれの台詞や役割を持っているのと同じように。

このMovieclipの中にあるタイムライン上に制御コードを書く、という考え方はクロージャの概念そのものだと思うし。ものすごく実感しやすいオブジェクト指向の例がMovieClipだったと思うので、いやまぁそれを捨てたのは勿体ないなぁと。

そこをもっとうまく生かすようにバージョンアップしてれば、多くの人が、ActionScript2とか3のことをOOPと呼び、同時に苦手意識を持つ必要はなかったハズです。

2008/01/05 04:54 f-shin

>でも、やっぱりRails程度の隠蔽度では、GET、POSTの理屈わかってないとキツイなと思いました。
>VBぐらい隠蔽されてれば良いんですけどね。VBでWindowsメッセージのやりとりを捕捉しなきゃ解決できない問題なんてそうないでしょうし。

私はRailsもVBもちょっとだけ使った事がありますが、この2つに下層の隠蔽度に差があるようには思えませんでした。
RailsではGET、POSTを受ける処理には大きな差があるようには思えませんし、htmlを自動生成させる時も同様です。
VBでも、ちょっと難しい事をやろうとすると(例えば、タスクトレイに入れて、ポップアップを出す、マウスオーバーを監視する)、すぐサブクラス可が必須で、しかも開発環境ごと落ちるという劣悪な状態だと思います。
この差は主観の差程度で、どちらも、フレームワークの範囲内であれば同じように簡単に作業ができると思います(むしろRails、Rubyの方が言語としての一貫性が高く初心者にもわかりやすいと思えます)。逆に、用意された範囲から出るのに必要な労力は桁違いであると思いますが。

>ところが、例えばPHPの場合ですが、ちっともMVCをわける意味がない。PHPは、どこでロジックを書いてもDB呼び出しても、文字を出力しても構いません。パッケージも継承も気にする必要はない。どこでもPEARモジュールを呼び出せるし。

私は逆にMVCをやらない意味がない。と思っています。
MVCに分けず、クラスがスパゲティのようにこんがらがったコードはメンテナンスに大変苦労する物です。
また、そのようなコードは書きたくありません。
更に初心者にとっては、数千行の構造化、カプセル化されていないコードを書けるとは思えません。
そのようなスパゲティコードは、プログラミング言語が使いこなせるようになってからでないと読めないと思います。(もちろん、使いこなせるようになってからでも読みたくないですが。)

短かい、テスト用でメンテナンスする気がないコードでしたら、構造化されていないようなコードでも良いとは思います。しかし、初心者の人は普通のプログラマより読めるコード行数が短かい物ではないでしょうか?
そのような初心者プログラマこそ、短かくコードを分け、構造化し、オブジェクトにカプセル化すべきだと思います。

しかし、初心者にオブジェクトを作れー。カプセル化しろー。と号令をかけた所で、何も見ずにそれができるようになるとは思えません。
そこで、MVCというクラス分けのパターンを提示し、自然とオブジェクトに分けられるようにするために、MVCに分けるのが自然なフレームワークを使うのが良いのではないでしょうか?

-- FlashとRubyについて
ちょっと良くわからなかったので更に質問させてください。

まとめると、
Flashの古いバージョンにはMovieClipを使ったタイムラインプログラミングという他には見られないすばらしい手法があった。
今のバージョンはそれがないので誰も使わなくなった。

であってますか?

#上の文を読むと、逆の意味にも取れます。

現在のバージョンのフラッシュにもMovieClipあるみたいですが、 flash.display.MovieClip
http://livedocs.adobe.com/flex/2_jp/langref/flash/display/MovieClip.html

これは以前のバージョンと違う物なのでしょうか?
上のマニュアルには、
>ActionScript 1.0 および 2.0 の MovieClip クラスのプロパティおよびメソッドの多くは、ActionScript 3.0 では MovieClip クラスのプロパティおよびメソッドとして提供されています。

と書かれているのですが。。。。

そしてこのクラスのプロパティを見る限り、旧来のFlashにあったような、フレームごとにイベントをハンドリングする事はできると思うのですが、それ以外の点(名前空間 記法 etc)について違いがあるという事でしょうか?

>このMovieclipの中にあるタイムライン上に制御コードを書く、という考え方はクロージャの概念そのものだと思うし。ものすごく実感しやすいオブジェクト指向の例がMovieClipだったと思うので、いやまぁそれを捨てたのは勿体ないなぁと。

ここは、特によくわからないのですが、クロージャーはCloseするものだからClosureなんだと思うんですが、MovieClipは何をCloseしてるんでしょう?

それとも、Rubyで使われているクロージャーとは違う用語がFlashにはあるのでしょうか?

2008/01/05 07:47 IKeJI

>VBでも、ちょっと難しい事をやろうとすると
>(例えば、タスクトレイに入れて、ポップアップ
>を出す、マウスオーバーを監視する)

こういうのはVBの仕様範囲外と考えるべきでしょうね。
何故対応してないのかはよくわかりませんが、スレッドモデルなどが関係するんでしょうか??

結局、VB.netまではスルーされちゃいましたね。


>私はRailsもVBもちょっとだけ使った事がありますが、
>この2つに下層の隠蔽度に差があるようには思えませんでした。

うーん。VBと比較するなら、ASP.net並にフォームをオーサリングするぐらい隠蔽してくれるツールが欲しいです。

例えばform_tagなどのフォーム要素生成系はformというHTML生成を自動化するだけのものですが、柔軟性を確保するために、HTMLの属性値の設定は、はかなり自由度が高いですよね。

ただ、それって文法の置き換えレベルでしかなく、コードを書くのに属性値の役割と名前は知っている必要があるわけです。つまり完成されるHTMLのイメージは持ってないと書けません。

だったら自分でHTMLを書いた方が良いじゃん、と思うこともあります。

もちろんSelect要素などは自動処理しないと面倒なことになるのもあるので、ありがたく使っていますが。

ちなみに、フレームワークには、「HTMLやJavaScriptを知らない人が使うもの」と、「知ってる人が使うもの」の2種類があると思うんですが、railsは僕の感覚では、HTMLを知らない人が使うには中途半端です。

ASP.netは「HTMLやJavaScriptを知らない人が使うもの」ですが。

VBは無論、Win32apiを知らない人が使うものですよね。フォーム操作、ファイル操作、DB操作がうまくできていたと思います。一番用途として人気が高かった、クラサバのクライアントには、やっぱり最適な言語だと思うし。


>MVCに分けず、クラスがスパゲティのように
>こんがらがったコードはメンテナンスに大変苦労する物です。

しかし、Webのコードは死ぬほど長くなるソースって少ないですよ。ステートレスですから、どうせ分断するし。

includeされて半端に構造化されるよりは、できるだけ上から下に流れるだけのソースとして書かれると、これが意外とメンテは楽です。

まぁ几帳面な人が書けばかもしれませんけど。

あえて言うなら、M+C+utilityでしょうね。もちろんPHPのMはハッシュです。

ちなみに、もちろん僕もMVCを使ってますよ。

僕は、それを否定するつもりはないのですが、でも、あまり重要ではないとも思っています。

PHPのオープンソースを見てると、MVCになっていないものが結構あります。読みづらいんですケドね、確かに。

ただPHPの場合、MVCにするということは、少なくともオーバーヘッドが伴うので、管理性とのトレードオフというのは多少ともあります。railsもそうですね。

何より、レンタルサーバのCGIに向かないってのは、ちょっとなぁとは思います。


>そこで、MVCというクラス分けのパターンを
>提示し、自然とオブジェクトに分けられるように
>するために、MVCに分けるのが自然なフレーム
>ワークを使うのが良いのではないでしょうか?

目の前で指導可能なら、特に異論無く賛成です。

僕ならまずはMだけのコードを書いてもらいます。

最初MVCをチームに取り入れた時は、コマンドラインで値の検証をするようなプログラムをセットで作っていました。テストファーストみたいなもんですかね。僕もSQL書くの嫌だったんで、active recordのシンプル版みたいなO/Rマッパなクラス作って。最初にJavaいじって、意気揚々と作ってみたのは、SQLを文字列レベルで書かなくて済む!というところでした。

その代わり、こういうのは設計が必須なんですよね。
(今の仕事では、こういう設計は一切しないです。)


Flashの方は、感覚的な話なので、あまり細かいところツッコミは勘弁してくだせぇ。

おっしゃるとおり、事実としてないがしろにされてるわけじゃないのですが、世界が広くなったのと、プログラミングモデルが変わってしまったので、ついていけなくなった人が沢山出てしまったというあたりなので。

これ、何故かというとエンジニアを取り込むために、Flashが「普通のOOP」になる必要があったからなのですが、それまでの個性的で直感的なタイムラインで全てを語るという概念は、どことなく否定されてしまった感がある、というような話です。その代わり、はてなワールドが出ました、というところでAdobe的にはOKだと思います。

プログラマーにはタイムラインが批判されていたのは間違いないので、まぁそんなもんですということで。PHPでインラインに関数を書いていくのと同じような話です。

2008/01/05 11:32 f-shin
この記事への提案、提言









あなたの情報を保存しますか?