jBPMのハンドラにパラメータを渡す
こんばんは、平田です。
jBPMでタスクを担当者にアサインするには、AssignmentHandlerを実装する必要があります。
このハンドラオブジェクトに、JPDLからパラメータを渡してみます。
2009年9月17日 by 平田
Tags: Java, jBPM, 平田メモ
Posted in jBPM | Comments (0)
jBPMタスクのフィードを配信する
こんにちは、平田です。
jBPMにはメール送信機能が統合されており、例えば担当者宛にタスクが追加された旨のメールを送信することが簡単にできます。
これをRSSのようなフィードとして配信してみます。
続きを読む »
2009年9月08日 by 平田
Tags: Java, jBPM, ROME, 平田メモ
Posted in jBPM | Comments (0)
jBPMでタスクを途中で削除する
19:30ともなると、そろそろ会社に一人ぼっちになりそうな平田です。
連投最後のネタは、フロー実行中にタスクを削除する方法です。
2009年8月28日 by 平田
Tags: Java, jBPM, 平田メモ
Posted in jBPM | Comments (0)
jBPMでタスクを途中で追加する
またまた平田です。
前回はjBPMでタスクを動的に生成しましたが、今回はフロー実行中にタスクを追加する方法です。
続きを読む »
2009年8月28日 by 平田
Tags: Java, jBPM, 平田メモ
Posted in jBPM | Comments (0)
jBPMでタスクを動的に生成する
こんにちは、平田です。
技術ブログのトップ記事がいつまでも恨み節では縁起が悪いので、現在調査中のjBPMについて、メモ代わりに公開します。
今回調査したのはjBPMでタスクを動的に生成する方法です。
続きを読む »
2009年8月28日 by 平田
Tags: Java, jBPM, 平田メモ
Posted in jBPM | Comments (0)
Niji 第1話――怨み節
＜error desu.＞
画面にはそれだけが表示されていた。
この日だけで128回みたエラーメッセージだった。
byte型の変数ではカウントしきれない数だな。
私はキーボードを遠投したくなる衝動を必死で抑えた。
当時、常駐先で、あるWebサイトの裏方システムを開発していた。
典型的なデスマーチ・プロジェクトだった。
「ふざけやがって。またフレームワークのデバッグをしなければならない」
向かいのデスクにいた男が膝で机を蹴り上げながら言った。
私と同じエラーメッセージを拝んでいるのだろう。
「何が原因かわからない。全く無意味なエラーメッセージですね。
『error desu』でググって(Google検索して)も、何の情報もない」
「そりゃそうだ。このプロジェクトでしか使われていないフレームワークだから。
――単純な機能を開発するだけなら悪くないフレームワークだが、
そういう機能がシステム全体にどのくらいある？
ほとんどの時間をフレームワークのソースコード解析に費やしている。
本来の開発が全く進まねぇ」
＜error desu.＞は、フレームワークが出力したエラーメッセージだった。
フレームワークはシステムにとって枠組みとなるプログラムである。
そのできがよいほど、開発者の負担は減り、開発コストが抑えられる。
例えば、ショッピングサイト、オークションサイト、映画館の予約サイトには、
Web上で動くシステムに共通の処理・制御がある。
リクエストからユーザの入力値を抽出し、それを然るべきプログラムに処理させ、
適切な画面に遷移させるといったことだ。
フレームワークは、こういった共通の処理・制御を担当してくれる。
従って、フレームワークの導入により、共通部の開発を省き、
開発対象のシステムに固有の仕様（画面デザイン、決済までの手順、決済処理自体等）に
集中して開発できる。
当初の計画では、このプロジェクトの為に開発されたフレームワークが、
従来の開発の8割を吸収してくるはずだった。
しかし、実際に開発が始まってみると、こういう具合だった。
確かに、システム全体の2割の機能については、
従来の開発の8割をフレームワークが吸収してくれた。
残りの8割の機能については、従来の開発以上に余計なコストが発生した。
納期は当初の前提のまま動かなかった――動かせなかった。
「フレームワークの構造上、入力から出力まで全てを実装しないと動作確認できない。
やっと動作確認できた段階になって、＜error desu.＞しか出力されない」
どこにどんなバグ（不具合）があっても、フレームワークはこのメッセージしか出さなかった。
一つの機能は、画面表示・デザインを制御するプログラム、画面遷移を制御するプログラム、
業務ロジックが記述されたプログラム等によって構成される。
それぞれのプログラムを単体で動作確認できる場合と、
全てを連携させないと動作確認できない場合では、
不具合が発生した時にどちらの方が早く原因を特定できるだろうか。
当然、前者の方が早く特定できる。その方が不具合の改修も楽だ。
東京ドーム1,000個分の島に10頭の羊がいたとして、
東京ドーム1個分の土地ごとに仕切りがある場合と、ない場合では、
前者の方がより早く全ての羊を捕獲できるという話に近い。
そのフレームワークは他案件への導入実績がなく、十分なテストがされていなかった為、
多くの不具合を抱えていた。
原因が、自分の担当したプログラムにあるのか、フレームワークにあるのかを切り分ける為に、
膨大な時間を割く必要があった。
「たかが一項目を表示する為に、13時間はまっている。○○さんがいればなぁ」
○○さんとは、ただ一人でフレームワークの開発を担当していた他社の技術者のことだ。
その彼が会社を辞めて3ヶ月が経過していた。
だが、誰も彼のことを怨んでいなかった。怨みの対象は納期だけだった。
納期まであと72時間――1泊3日。
＜END＞
※ ※ ※
前置きが長くて申し訳ありません。半分はフィクションです。
この経験を生かして開発した自社フレームワーク『Niji』について、これから書いていきます。
よろしくお願い致します。
p.s. 上の話は続きません。あしからず。
2009年8月06日 by 渡邊
Tags: Niji, フレームワーク, 渡邊
Posted in 自社開発フレームワーク『Niji』 | Comments (0)