プログラミングのジャンルと難易度(および Web プログラミング批判)というエントリが人気のようですね。
ざっくりした概要は「Web プログラミングの世界ってのは、全体的に程度が低いからだ。」の一文で表現されてしまいます。
JavaのServlet技術を用いた業務システムをさんざんやってきた私ですが、この感覚というのはよくわかる。
Webシステムのサーバサイドの仕事の8割は経験3ヵ月の新人でやれてしまう。
ただ、Webシステムは技術がまるでいらないかというと、そういうわけではなくて、物凄く幅広い知識が必要とされる側面があります。
しかし、そうした技能を持ったアーキテクトがチームにひとりいれば、大抵の問題は解決できるぐらいに、
大半は専門的な技術を必要としない。
こうしたWebシステムの側面は、経済的な面で非常に有利であり、あんなにも使いにくいUIになるにも関わらず、
多くのLAN内部で使われる社内の業務システムがWebサービスとして作られることになりました。
(アプリケーションの配布の手間がないという側面も大きく評価されたのだと思いますけども)
HTMLによるGUI作成
Webの、というよりHTMLによるGUIの作成は、VisualBasicよりもある意味では易しい。
というのは、画面サイズ固定であればVBによる画面作成は煩雑ではないものの、HTMLのような自動レイアウトが容易ではないからです。
ウィンドウサイズを可変にして、サイズの変更に際してスペースを割り付けするとか考えたらやってられなくなる。
固定レイアウトであればVBが楽、可変のレイアウトであればHTMLが楽だと思います。
そしてこのレイアウト、および出力データが一体となって、HTMLという文字列で扱うことができます。
古典的にperlのCGIを作る場合はこの出力HTMLを動的に書きだす文字列操作に終始しますし、
JavaだとJSPなどのテンプレートエンジンの類、つまるところ、HTMLの可変データ部分だけ虫食い状態にしたものを用意して、
そこにデータを埋め込むという方式を用いることになります。(実際には表を出力したりする場合の繰り返し処理などもある)
これらの処理は、複雑な論理演算を伴わないので、アルゴリズムを考えるという技能があまりなくとも一応形になるものを作れる。
この敷居の低さは確かで、経験3ヵ月の新人でもできるというのは本当です。
Webシステムはことさら初級者に仕事をさせてシステムを作ると言うことがされているように思います。
静的オブジェクト指向は設計者が苦労を背負込むシステムで挙げた
「Javaの静的オブジェクト指向というのは将軍の力でもって、初心者の大隊を常勝させるための技術」というのは
特にこうしたWebシステムの開発現場では身に染みて思うところです。
まともなGUIプログラミングとかだと初級者にやらせられる仕事なんて本当に少ない。
熟練するには幅広い知識が必要とされる
大規模なWebシステムというのは、とりあえず仕事をさせるとした場合のボーダーとなる技能は低いのですが、
熟練するためには非常に幅広い知識が要求されます。
- HTMLの構造
- CSSの知識
- UIデザイン論
- JSPなどのテンプレートエンジンの動作原理
- タグライブラリ・EL式の知識
- JavaScriptの技能
- AJAXの動作原理
- HTTPのプロトコルについての知識
- Cookieを用いたセッション管理の仕組み
- SSLによる暗号化通信の仕組み
- Strutsなどのフレームワークを用いる場合はその動作原理
- O/Rマッピング
- DIコンテナ
- RDBMSの知識
- バックアップなど運用についての考慮
- ロードバランサなどの理解
- システムの多重化についての知識
- セキュリティに対する知識(XSSやSQLインジェクションなどのアタックへの対処など)
うーん。きりがない。
このように個々の専門知識は相応に深く、しかもフロントエンドからバックエンドまで非常に幅広い技術が要求されるので
全体統括をするためには知識の深さと広さを兼ね備える必要がある。
とりあえず作業をすると言う時の敷居の低さに対して、熟練するためのギャップが凄まじいんですね。
このあたり、慢性的な人材不足の構造的な理由かもしれません。
ポストWebシステム
Webシステムの開発をしていれば、こんなやり方はいつまでも使えるもんじゃないというのは感じていることでしょう。
ブラウザ戦争の頃の不発弾のようなデファクトスタンダードなHTMLの仕様といい、
文字コードなんぞ考慮されていないHTTPの古めかしい仕様といい、
Webシステムに精通すればするほど、不安定な土台に乗せられた危ういシステムということが見えてくる。
世紀が変わった頃にはリッチクライアントと言うことが盛んに言われ始めて、
Webシステムのプアなユーザビリティはどうにかしないといけないという問題意識が高まっていきました。
しかし、そもそもがブラウザというものはPCへの標準搭載がほぼ100%という土壌があります。
新しいプラットホームを作るにあたって、この壁は大きな壁となります。
SunがJavaFXロードマップ発表というニュースが出ていましたが、ここにきてリッチクライアントの
プラットホームはAIR、Silverlight、JavaFXという3者に絞られてきた感があります。
AdobeのAIRはFlushなどの技術がベースにあります。Flushの普及率は高く、
当blogのGoogle Analyticsでの解析を見ると97%ほどになります。
Silverlightのサポート環境は調べる手立てが思いつかないのですが、当blogのGoogle Analyticsでの解析では
OS | ブラウザ | % | Silverlight |
Windows | Internet Explorer | 50.34% | ○ |
Windows | Firefox | 33.94% | ○ |
Windows | Opera | 4.06% | × |
Macintosh | Firefox | 3.54% | ○ |
Macintosh | Safari | 3.45% | ○ |
Linux | Firefox | 1.87% | × |
となっていますから、サポートされる環境の91.27%より少ない程度がSilverlightが動作する可能性があります。
…。というか、この数字えらく偏っていませんか?いくら技術系のblogだからってFirefoxのシェアが40%あるってどうなんだ。
OSもWindowsが89.41%でMacintoshが7.19%もあるし…。なんかあまり信用できる数字ではないですね…。
母集団が凄く偏っているような気がする。
JavaFXは当然Javaベースの技術です。当blogのGoogle Analyticsでの解析ではJavaのサポートが95.41%となっています。
これからいくらか割り引いた程度が動作環境と考えられますね。
ポストWebシステムに求められるもの
前述のようにデータは怪しいものの、3者はかなりの割合で動作することが見込まれます。
移行の為の下地は整いつつあると言えるでしょう。
機能的には古典的なHTMLによるWebシステムと違い、非同期通信がサポートされますし、アニメーションを伴う
かなり高度なUIを用いることができることがウリです。かなりのユーザビリティ向上が望めます。
そして、これらのより高機能で複雑になったシステムを、より簡単に開発できる必要性があります。
開発費が高沸してシステム開発の敷居が上がるなんてことでは、普及は難しいでしょう。
私は最近Flex/AIRのシステムを作っていたりするのですが、高度なUIが容易に作成できるようにとの
工夫が随所に見られます。このあたりの感触からも、そろそろリッチクライアント時代が来るな、という手ごたえを感じます。
投稿日時 : 2008年5月21日 1:07