GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
ブックマークされました!
ブックマークがエラーになりました。もう一度お願いします。
作者 Jean-Jacques Dubray , 翻訳者 八角研究所 投稿日 2007年12月7日
John Raynolds 氏は最近疑問を投げかけた。なぜ Java 開発者は BPM を嫌うのか(source)?
彼は、彼自身や他の人たちの経験から次のような結論を出した。
BPM スイートはあなたの創造性を奪い、どのようにアプリケーションを開発するかを命令する。そしてプログラミングを退屈なものにするうえに、あなたがプロセスダイアグラムをデザインするのにポイント・アンド・クリック、ドラッグ・アンド・ドロップツール、データモデルとフォームを使うことを強制する。
更に悪いことに、BPM スイートはビジネスに携わる人々に自分たちでプロセスをモデリングし、フォームを設計するように仕向ける。
彼は次のことを主張している。
一般の Java 開発者達は BPM スイートの制約を押し付けられるよりも、むしろ Struts や Spring のようなフレームワークを使うだろう。Spring または Strutsでほとんどのものを構築することができる(すでにあなたが Java の複雑さを習得しているなら)。Spring や Struts は軽くてアジャイルだし、業務経歴としても魅力的だ。
私たちは Java の知識があること自体の重要性を薄くするツールを構築するために Java を利用してきた。そしてそれが Java を学ぶのに時間をかけなかった人達との競争をもたらした。
私たちは自身の成功の犠牲者であり、それは私たちの負担になる。
だから Java 開発者は BPM を嫌うのだ。
読者は様々に違った理由を述べている。例えばこの読者は以下の理由から BPM を嫌っている。
BPM が物事を処理するのに実用的なツールになり得るとは本当に思えないんだ。NetBeans にはフリーの BPM ツールがあるが、単純な Web サービス自動化ツールのように見える。これは私が出くわすビジネスの要求や関心事には全く役に立たない。更に凝ったツールでさえ、たいした価値を提供しないハイレベルのプロセススクリプティングツールのようだ。これらのすぐれた BPM スイートが全く自由に開発者の手に入らないから試用が困難になっている。金額的に高いから私の上司は買ってくれない。
成功した導入事例はどこにあるのか? このテクノロジを使った実際のアプリケーションがあるのであれば、是非とも教えて欲しい。
別の読者は次のようなことを述べている。
私たちは使うべきではないから BPM を嫌ってるんだ。BPM のアイディアは、ビジネスに携わる人々がモデリングタスクを行うというものだが、彼らが使っていないという事実があるから、私たちは結果的にそうしてるんだ。
この読者はたびたび宣伝される、"ポイント・アンド・クリック・アンド・ラン" の見せかけのシンプルさに賛同していない。
プロセスの最もシンプルな部分を考えても、実際にはコンピュータ上で実行されるのが現実だ。それにコンピュータは私が意味することではなく、私が言うことしか理解しない。
ダイアグラムのワイヤフレームが何を言うかに関係なく、互いにワイヤでつながれたこれらの小さいブロックが表現する現実を根本的に理解していなくてはならない。"請求書送付後" というボックス内に含まれる微妙なディティールはたくさんあり、どんなに私たちが頑張ってもこれらの微妙さは現れてきて周りのプロセスに影響を与える。
結局、これらのダイアグラムを記述する必要のある人達はコンピュータとコンピューティングを理解する必要がある。こういった人達はプログラマで、プログラミングは技術的な知識だけではなく特定の物の見方を要求する。
だから、ダイアグラムで単一のボックスとなって現れるかもしれない一方で、これらの 100 行もの J2EE コードで何が起こっているのかを理解するべきである。小さいボックスの色や形を問わず、そこにはまだ複雑さがある。
開発者として、いつ私のシステムが、このインフラの塊を導入する価値があるほど十分に大きくなるのだろうかと頭を抱えてしまう(私のシステムにはスクリプト言語のインタープリタとシステム自身のためだけに 1GB の RAM を要するランタイムが必要だ)。
明らかに、抽象化は時間を経て、長期的に私たちの開発環境をより良いものにしてきた。バイナリコードからアセンブラニーモニック、C 言語、Java に至るまで。1 行の Java コードは 100 ものマシン語インストラクションを表現する 10 の Java バイトコードを表現する。しかし、優れた Java プログラマはこれらの 100 ものマシン語インストラクションが何を行っているかをよく理解している。そして、駆け出しのプログラマは無知ゆえに時折痛い目にあう。
BPM ツールを使った開発経験をもつ Robert Perkins 氏は BPM スートを好まない理由を以下のように述べている。
あなたの製品の次のリリースを VISIO のようなツール内でフローチャートとして書いてもらうように技術者に頼むといい。彼らは JavaScript の使用を制限されるだろう。自動化された回帰テストシステムを利用する術も失うだろう。彼らがこれまで頼っていた Eclipse や IntelliJ IDEA の機能も一切使えなくなる。ビルドやデプロイ用のスクリプトもないので、デプロイには手作業によるファイルのコピーが必要になってくる。あとそれに彼らはバージョンコントロールの手段も持たないだろう。
開発者がビジネスにとって最も大きな価値を生み出すツールや製品よりもこれらのツールを使いたがるのは自分勝手な理由からだと、あなたは言うかもしれない。
それにはいくつか真実がある。多くの技術的でないビジネスは、開発者とビジネスサイドの間に不信を生み出して、この主張を信じるようになったと思う。私の前の会社がこの問題を抱えていたのを知っているし、たくさんのベンダとセールスチームがこの主張を利用していることは想像が付く。
私がサクセスストーリーにどれだけの信念を注いできたかはわからない。私の会社は成功例として数えられるようになった。だが実際にはプロジェクトはひどいもので、エンドユーザは憤慨していた。そして3月の時点で開発チーム全体が現場を去った。
「問題は単に BPM だけの話ではなくもっと一般的だ」いくつかのビジネスロジックやプレゼンテーションロジックをパーソナライズするために、ビジネスが最高のポジションに着ける場所はたくさんある。最近 Mark Proctor 氏は、多くのプロセス定義はルールエンジンの表現力を要求し、そのルールはプロセスエンジンの状態管理能力から恩恵を受けることができると述べ、統合されたルールとプロセスエンジンの利点について疑問を投げかけた(source)。Mark 氏は次のように付け加えた。
統合されたモデリング環境の利点の一つは、あなたがどのように物事をモデリングするかを選べるようになることだ。
Dave Wright 氏はすべてが密接につながっていると見ている。
データモデルや用語と意味のモデルを考慮すると、ルールとデータはルールとプロセスより強固につながっていると言われている。あなたがプロセスとルールプラットフォームを切り離したくないのはわかるが、離れたデータプラットフォームも同様に取り除きたいだろか?
これは Agility Chain Management Systems ( ACMS ) (サイト・英語)の Pierre Bonnet 氏の分析によって確認されている。ACMS は MDM と BRMS と BPM の間に強い結びつきを見ている。
- マスタデータ管理(MDM). 参照データとパラメータの管理を合理化し、サービス設定モデルの実装が実行を状況に適応させることを可能にする。
- ビジネスルール管理システム(BRMS). ルールは参照データとパラメータに依存する。組織的サービスの事前条件と事後条件はルール管理システムに置かれる。
- ビジネスプロセス管理(BPM). プロセスは様々なステージの活動を推進するためにルールを利用する。編成されたサービスは MDM と BRMS によって状況に適応させられる。
Peter Evans-Greenwood 氏はアプリケーションのセマンティックスを定義するために新しいアプローチについて述べている(source)。
ルールとプロセスの分離は、技術がそうあってほしいことによる結果ではなく、技術が必要とされる背景があって、そこから生まれたものだ。分離されたルールとプロセスのエンジンを持っていることは膨大な量の不要なオーバーヘッドをもたらすことになる。
より実り多いアプローチは逆方向から問題に取り組むことかもしれない。トップダウン方式で行こう。どのようにして人々がプロセスのビジネスロジックを理解するかを徹底的に調査して、私たちのアプローチを形にしたツールと技術を作り出そう。
原文はこちらです:http://www.infoq.com/news/2007/11/developers-hate-bpm
【豆蔵】大好評のため、Jenkins講座を追加開催致します!Jenkins作者の川口氏が講師です。
世界の先進エンジニアが集結 - QCon TOKYO 2012 早期割引実施中!
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。
Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。
GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式
本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。
前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。
Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。
スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。
No comments
スレッド表示 返信