「技術者の自己満足ではいけない」と「SE は技術オタクである必要はない」を混同してはいけない

「ウチは SE を育てますから、技術オタクにするつもりはありません」

春から秋にかけては新人研修の講師をすることも多い私ですが。

いまだに、こんなトンデモナイ勘違い発言をする SIer の人事・研修担当の方がたくさんいます。


技術者の自己満足ではいけない
これは正しいです。

お客様にとっては、どんなシステムができるのか？が重要でどんな技術を使っているのか？は重要ではない
表面的・直接的には正しいですが、あまり正確ではありません。
どんな技術が使われるのかは重要です。信頼できる技術・ノウハウが蓄積された技術・生産性の高い技術・保守性の高い技術が使われることは開発時や後のメンテナンス時のコストに影響しますから。

SE は技術オタクである必要はない
大間違いです。SE はシステムの専門家としてお金を稼いでいる以上、技術オタクであるべきです。お客様も周囲もそれを期待して専門家ならではの視点や考え方を求めます。自分が売っているものに対する製品知識は必要です。大事なのは技術オタクをそのままお客様に押しつけてはいけないということです。
建築に例えるなら、最新の設計手法・工法に興味が無く、最新技術に精通していない建築士を信頼できますか？常に最新の情報収集・最新技術の研究に努め、使える技術を採り入れる建築士とどちらを信頼できますか？
答えは自ずと見えてくるでしょう。


根本的に、技術者に向いている人・IT業界に向いている人は新しもの好きです。常に最新の情報にアンテナを張っている人です。そして、エンジニアとしてワクワクさせてくれるような技術を使ってみたい！と思っています。
実際の開発でも、ある技術を採用する理由として「エンジニアとして楽しそうだから・面白そうだから・使ってみたいから」という理由は、私はアリだと思っています。（※ もちろん、その技術がシステムに対する要件を満たしていることは大前提ですが。）
根本的に新しもの好きであるエンジニアがワクワクしながらやる気満々で取り組んだ仕事と、技術オタクな視点を完全に無視され、ルーティンと化した手法しか使わないで取り組んだ仕事。どちらが高い品質を期待できるでしょうか？

私は、ひがさんがよくおっしゃる「開発を楽しく」に非常に共感できます。

SpringSource Application Suite Enterprise Edition

L.A.にお住まいの方から日本Springユーザ会のMLに情報提供の投稿がありました。
SpringSource主催のトレーニングコースに参加した際に得た情報だそうです。

http://groups.google.co.jp/group/jsug/browse_thread/thread/98e78742e3bffdb6?hl=ja

この中で私の興味を引いたのは、SpringSource Application Suite Enterprise Edition に関する情報です。

• 今月末頃に Tomcat + Spring をベースにしたアプリケーションサーバをリリース。クローズドなコードが含まれている。
• 商用と GPL のデュアルライセンス
• 商用ライセンスはサブクリプションベースのサポート付き

・・・クローズドなコードを含んだものって GPL で公開できましたっけ？

SpringSource社がCovalent社を買収したときに、こういう展開になるのではないかという声はありました。

Hibernate.org のブログエントリを読むと、JBoss 対 Spring という構図がより明確になっています。
http://blog.hibernate.org/Bloggers/SpringSourcesStrategy
ここでは Tomcat + Spring には機能が足りないことに言及していますが、Rod Johnson は、そういう観点で勝負する気は無いでしょう。

このMLの投稿でも「JBossの対抗馬」とされていますが、真っ向対立したいのであればJavaEE完全準拠のアプリケーションサーバを作ると思います。

Tomcat + Spring は今でも十分に支持されています。Rod Johnsonが考えているのは、今までの Tomcat + Spring というアプローチの延長線上のアーキテクチャでしょう。今の SpringSource社は VC から資金調達しているので利益を出さなければならないという事情があるようですが、この Tomcat + Spring スタイルでオフィシャルにサポート提供するのなら顧客は獲得できるのではないでしょうか。

今まで、Glassfish でもなく JBoss でもなく、Tomcat + Spring を選択してきたユーザには大歓迎ですね。

Javaの難しさ

Javaの難しさと一口に言ってもいろいろな側面がありますが、今日は製品選定の難しさに焦点を当てたいと思います。

Javaで開発を行う場合、開発環境、実行環境（アプリケーションサーバ）、ライブラリ、フレームワーク等々、各ベンダやOSSコミュニティが似たような機能を持った製品をリリースしていて、どれを使ったらよいのか開発者はいつも頭を悩ませています。
さらに、各ベンダやOSSコミュニティからは絶え間なく新製品や新バージョンがリリースされ続けているため、開発者は常に情報収集・調査・評価・検証を行い、そこに莫大なコストをかけています。・・・まぁ、だからこそ私のような仕事も成り立つのですが・・・
各製品個別の評価検証だけではなく、異なるベンダやOSSコミュニティからソフトウェアを入手した製品を組み合わせて動作確認するのも開発者の仕事です。その際に間接的に利用するライブラリ（依存ライブラリ）のバージョン違いによる競合が起こることも珍しくありません。

選択肢は多い方が良い、という理屈もあります。ベンダ間・OSSコミュニティ間の競争・競合が各製品の質を高める効果を生み出しているのもまた事実です。
しかし、今のJavaプラットフォームでの開発では、その選択肢の多さによるコスト増が勝っているような気がします。
そういう意味で、Javaプラットフォームでの開発よりも.NETプラットフォームでの開発のほうが余計なことに煩わされずに済んでいるのが現状なのではないでしょうか？

重要なのは、どんな技術を使ったか？や、どんなソフトウェアを使ったか？ではなくて、どんなシステム（アプリケーション）を作った（作る）のか？ですから。
率直なところ、開発の現場では「与えられたものを使っていればOK」な人が大半なような気もしますし・・・

Google App Engine が公開されました

Google App Engine が公開されました。

http://code.google.com/appengine/

Googleが提供するインフラ上に自作のWebアプリを乗せられ、データベースまで利用できるというモノです。

しかも、初期費用無料で。

私自身このニュースを見たとたん「来たっ！」と思いましたが、
マスコミの反響も大きいようです。

Googleのインフラでアプリを動かせる「Google App Engine」(ITmedia)
http://www.itmedia.co.jp/enterprise/articles/0804/08/news056.html

グーグル、「App Engine」を発表--オンラインアプリケーション開発用にインフラ提供 (CNET Japan)
http://japan.cnet.com/news/media/story/0,2000056023,20370974,00.htm

クラウドサービスに参入【詳報】「Google App Engine」ってなんだ (@IT)
http://www.atmarkit.co.jp/news/200804/08/appengine.html

「Google App Engine」発表、Googleのインフラ上でWebアプリ構築 (マイコミジャーナル)
http://journal.mycom.co.jp/news/2008/04/09/002/index.html

技術系ブログでも大盛況ですね。
Google ブログ検索の結果

Google App Engine は、Amazon の EC2/S3/SimpleDB や、Salesforce.com の force.com と競合するサービスになり得ますね。

Amazon や Salesforce.com がこれらのサービスを始めたときよりも反響が大きい印象です。改めて Google の影響や注目の大きさを感じます。

Salesforce.com に転職した後輩が、「Google が始めたとしても、Salesforce.com はもう8年もやっている実績がありますから」と言ってました。

Salesforce.com の force.com は、既存の高機能なCRMシステムを持っていて連携できるのが強みでしょうか。さらにリッチな GUI 開発環境を SaaS 形式で提供しているのが特徴です。アプリケーションのコードは Apex という、Java によく似た独自言語で記述します。

Goole App Engine は、背後に GoogleのBigTable、GFSという基盤を持っているのが強みだと思います。これは非常にスケーラビリティの高いシステムを構築できる可能性を持っていることを意味します。
mixi のような大規模 SNS もホスティングできたら、これはすごいことになりますね。世の中のインターネットサービスやエンタープライズシステムのあり方を一変させる可能性を秘めています。自らインフラを持たずとも初期投資ほぼ0からスタートして、大規模エンタープライズシステムやmixi のような規模を持つコンシューマサービスを運営できることになるのです。
多くのサービスやエンタープライズシステムが、自社サーバではなく Amazon や Google のクラウド上に移行するということがさらに現実味を帯びてきた感があります。Google のことですから、それぐらいの野望は持っているでしょう。

Web 上で Service を提供する SaaS から、プラットフォームを提供する PaaS (Platform as a Service) 時代へシフトする未来が見えてきた感があります。

Goole App Engine の正式サービス開始時の料金体系がまだ発表になっていませんが、Google の大容量ストレージを格安で利用できるメリットを打ち出してきそうな予感がします。

プログラム言語としては、現在は Python のみのサポートですが、将来的には他言語にも対応予定とのこと。Salesforce.com の force.com が独自開発言語と SaaS 形式のリッチな GUI 開発環境を提供するというアプローチに対して、Google App Engine は多言語対応で、開発環境は「自分の好きなものを使ってね」的なアプローチです。

	Salesforce force.com	Google App Engine
開発言語	Apex	Python 他言語もサポート予定
開発環境	専用GUI環境(SaaSで提供)	SDK提供 統合開発環境は無し。 開発者が好きなものを利用。
インフラ	Salesforce.com (恐らく市販商用サーバ + 商用DB)	GFS + Google BigTable
最低限の 初期投資	0円	0円
他サービス との連携	強力・高機能なCRMシステム	Googleアカウントを利用した 認証等
独自ドメイン の利用	不可	可

Yahoo! や MS はこの流れに追従するのでしょうか？MS はやりそうな気がしていますが・・・

まあ、Google と SalesForce.com ではターゲットとするユーザ・アプリが違う気もしますが・・・
平たく言うと Web2.0 的コンシューマサービスをゲリラ的に立ち上げやすい Google と、あくまで企業ユーザをターゲットにした SalesForce.com という感はあります。



ともあれ、Getting Started Guide に従って少しいじってみました。
（Windows XP Professional 環境です。）

トップページ http://code.google.com/appengine/ から、サインアップし、SDK をダウンロードします



msi 形式の Windows インストーラが用意されているので、それをダウンロードしました。

さて、インストール・・・

と思いインストーラを起動したら、Python2.5 が必要なので、まずはそっちをインストールしなさい・・・と怒られました。



Mac OS X 10.5 Leopard ならデフォルトで入っているんですけどね。

というわけで、Python をインストールしてから、GoogleAppEngine SDKのインストール。



インストール作業は、ライセンス同意と、インストールディレクトリの選択のみのシンプルな構成。「I Agree」とか「Next」を押しているだけで特に問題なく終了しました。
インストール時に、インストーディレクトリに PATH を通すかどうかのチェックボックスがありますが、チェックを入れておくとサーバの起動やアプリケーションのアップロードの時にコマンドをフルパス指定しなくて済みます。というだけです。

開発環境（SDK）には、開発用アプリケーションサーバ、ローカル環境専用データベースが含まれています。

Getting Started Guide に従って、最も簡単な Hello World アプリケーションを作ってみました。

まず、適当な場所にhelloworldディレクトリを作成し、その中にテキストベースで helloworld.py という名前のファイルを作成します。
ファイルの中はこんな感じ。

print 'Content-Type: text/plain'
print ''
print 'Hello, world!'

Google App Engine では、app.yaml という名前の設定ファイルが必要なので、同じディレクトリ内に作成します。

application: helloworld
version: 1
runtime: python
api_version: 1

handlers:
- url: /.*
script: helloworld.py

application: App Engine がアプリケーションを識別するためのユニークな名前を付けます。

• version: アプリケーションのバージョン番号。アップロードする前にバージョン番号を編集する必要があるそうです。App Engine はバージョン番号を認識しているので、管理コンソールで前のバージョンに戻したりできるらしいです。
• runtime: と api_version: エントリは、現在は python、1 で固定です。将来別の言語を使えるような計画もあるので、その際に拡張されるみたいです。
• handlers: 上記の設定は、すべてのリクエストに対して helloworld.py スクリプトが動作するということを意味します。スクリプトの他にも、ディレクトリを指定したり、指定したURIは管理者のみがログイン可を指定したりが可能です。

YAMLのリファレンスはこちら。
http://code.google.com/appengine/docs/configuringanapp.html


これで準備完了です。

コマンドラインから Google App Engine のサーバを起動します。その際にスペース区切りでアプリケーションの配備ディレクトリを指定します。

dev_appserver.py アプリケーションのディレクトリパス

あとは、ブラウザから http://localhost:8080/ にアクセスすると・・・



これを、Google App Engine のサーバにアップロードすれば公開できます。

アップロードするには、まず http://appengine.google.com/start/createapp からアプリケーションを作成します。



このとき、Application Identifier の項目は app.yaml の application エントリに登録した文字列と合わせておく必要があります。
この文字列はアプリケーションの識別子となるのですが、ユニークであるスコープはユーザ単位ではなく、Google App Engine サーバ全体です。つまり、同一のアプリケーション名を他人に使われていたら使えません。
というわけで、helloworld が（当然のように）使われていたので、ここでは「liebejudith-helloworld」に変更しました。app.yaml の application エントリもこれに合わせて修正しています。

そして、アップロード。Web 管理インタフェースからアップロードするのかと思いきや、Google App Engine ではコマンドラインから appcfg.py コマンドを実行してアプリケーションをアップロードします。

appcfg.py --email=登録メールアドレス update アプリケーション配備ディレクトリ

これで完了。ブラウザから次のURLにアクセスします。

http://アプリケーション名.appspot.com/

Google App Engine は、Pure Python アプリも動作しますし、アプリケーションと一緒にアップロードすれば多くのフレームワークを動作させることができます。

SDKに同梱されているのは、Django v0.96.1 と、オリジナルのWebアプリケーションフレームワーク "webapp" です。

webappフレームワークには、下記のような機能が含まれています。

• Google アカウントと連動したユーザ認証API
• データストアAPI。データ操作には、SQLによく似たクエリ言語"GQL"を利用
• Webページ作成のためのテンプレートエンジン
• Mail API

私は Java しか知らない人間なので Python はほとんど触ったことはないのですが、Google App Engine アプリを作るために Python を覚えてもいいかな？という気にさせてくれます。


次回は、Getting Started Guide で紹介されているゲストブックアプリケーションを参考にして、掲示板アプリでも作成してみたいと思います。

Spring Framework 2.5.3 リリースされました

Spring Framework 2.5.3 がリリースされました。

http://www.springframework.org/node/622

すべての2.5.xユーザにアップグレードが推奨されています。

主な変更点はこんな感じです。

• @Autowiredアノテーション、@Requiredアノテーションの動作の変更。
• @Autowiredアノテーションが付けられたメソッドがサブクラスでオーバーライドされているとき、@Autowiredアノテーションの動作はオーバーライドされたメソッドには継承されないように変更になった。（2.5.2までは、@Autowiredアノテーションがついたメソッドがサブクラスでオーバーライドされた場合は、サブクラスのオーバーライドされたメソッドにも暗黙的に@Autowiredアノテーションがついていることになっていた）
• @Requiredアノテーションは、XMLでのBean定義をしなくても@Autowiredアノテーションと組み合わせて利用できるようになった。
• @Controllerアノテーションが付いたBeanがデフォルトで検索されるようになった
• <jee:...要素を使ったjndiルックアップはresource-ref="true"がデフォルトになった
• JMSセッションとプロデューサプーリング用の新しいCachingConnectionFactoryクラス
• DB2/390とDB2/400のための新しいDB2MainframeSequenceMaxValueIncrementerクラス
• リファレンスドキュメントがJSF1.2、Struts2.0対応になった
• PropertyPlaceholderConfigurerで、${db.${environment}}のようにネストしたプレイスホルダーキーをサポート
• その他

詳細はChangelogを参照してください。
http://static.springframework.org/spring/docs/2.5.x/changelog.txt


すべての2.5.xユーザにアップグレードを推奨すると言ってますが・・・。メソッドがオーバーライドされたときの@Autowiredアノテーションの振る舞いの変更は、ソースコードの修正が発生しそうですね。setterをオーバーライドすることはあまり無さそうですが、コンストラクタインジェクションを使っている場合はオーバーライドしているケースが結構多いのではないでしょうか？

@Requiredアノテーションについては、2.5.2 までは@Requiredアノテーションを使う場合はXMLでのBean定義が必須でしたが、2.5.3 では@Autowiredアノテーションと組み合わせて利用できるようになったのが便利ですね。
・・・まぁ、@Autowired(required=true) とあまり変わりませんが・・・