北海道苫小牧市出身の初老PGが書くブログ

永遠のプログラマを夢見る、苫小牧市出身のおじさんのちらしの裏

java-ja 第7回 実況メモ

出席してるので、実況兼レポートです。ustreamでも流してるそうです。


とりあえず、会場つくまでに有り得ないほど迷いましたorz。でも、開始が遅れたようで遅刻になりませんでした。ラッキー。

羽生さん 第一部(14:30-16:25)

  • エンドユーザ出身←4年間オペレータとして、ユーザの立場にいた
  • コード書いて気持ちよくなっていたら負け
  • ウォーターフォールをしっかり学んだ
  • Oracleのサポートやっていた
    • きちんとした設計が大事→データ中心アプローチ
  • 事業計画アプリを作り、ビジネスモデルを学んだ
  • 羽生さんはGeekではない
    • Geekなら、羽生さんができることは出来て当たり前
  • お金は自然に湧いて来ない←対価
  • みんなつながっている→お客様の知り合いは身内かも→お客様が一番大事
  • PC、光熱費、人件費等が必要
    • 人件費→売るのには、営業費用も必要
  • お金を集めるには?←自腹(自己資本)、他人から(自己資本他人資本(負債))、お客様の売上
  • 売上≠利益(残高試算表、賃借対照表、損益計算書)
  • "お金"の話は、ビジネスプロセスをモニタリングするためのメーター
    • "お金"=欲深い、ではない。"円"はリットルやメートルと一緒。
    • メーターを見て、運転しているということ
  • デスマの凄さ→お金が「いくらでも注ぎ込まれる」
    • スーパーマーケットでは無理。公共事業なら・・・
  • 勘定科目を見ると、ビジネスプロセスが見える
  • 利益=売上-費用、ではなく、0-費用+お買上=利益
  • 利益を増やす4つの方法
    • 販売数を増やす、原価を下げる、単価を上げる、回転率を上げる
    • コントロール可能なのは、原価を下げる、のみ
    • 高付加価値≠高価格、高付加価値=高利益率
  • 販売個数、回数を10%改善するより、価格や原価を10%改善する方が効果が高い
  • 契約は、借金を背負うような物(納品義務が生じる)
    • 納金までにかかる費用は、納品確率を高めているだけ
  • 30人が年収1千万になるには?←1人月100万のような計算では、不可能*1
    • 1人あたり年間2500万円売り上げる*2
  • 売る側の「商品」≠買う側の「期待」
    • 「はい、タケコプター」≠「空を自由に飛びたいな」
  • お客様の納得を得るには?→差別性、メリット、実績
  • AIDMA(attention,internet,desire,memory,action)
  • システム開発 VS 派遣1名
  • 羽生さんが自社を「スタロジ」と呼ぶのは、名前を使いやすくしてもらうため
  • プロの一押し→左脳+右脳(論理的な説明+熱い情熱)
  • ビジネスプロセスを設計し、インプリメント(運用)する
    • プログラミングと違い、生身の人間だから難しい
  • 業務システム開発の問題点
    • ビジネスプロセスを全てコードにコンパイルBURIへ!
    • データモデルとコードが依存*3
      • ドキュメントも役に立たん*4

羽生さん第二部(16:40-17:10)

  • Buri(Business Unit Routing Integration)は"ワークステートエンジン"
    • ワークフローエンジンに必要な、管理ツール、監視ツールがない
  • アクティビティ(箱)、トランジション(矢印)、プロセス
  • 必要な概念→状態、アクティビティ、ルーティング
  • 必要な技術→S2Container、S2Dao、OGNL、XPSL
  • BuriはXPDLを読み込んで実行
    • WfMCによる定義。解釈が自由なので互換性は低い
  • データは、アクティビティ(箱)によって状態(フラグ)が変わる
  • ルーティングパターン→(XORかAND) + (JoinかSplit)
  • Splitの種類→condition, otherwise, exception, default exception(Buriでは非対応)
  • Activityの動作タイプ→Auto、Manual
  • プロセスにおいて、扱うデータ(テーブル)は一つ
  • Teedaなど+Buri+SeDao。Buriの情報は1つの管理テーブル。
  • S2Container的には、Buriが一つのコンポーネントPOJOの一つ。
  • JavaからBuriを利用するには?→Bao or Invoke
    • BaoはBusiness(logic Access Object)。Interfaceとして定義
  • Buriを使った開発手順
    • 対象プロセスを決める
    • DB設計+Dao作成
    • XPDLを作成し、Daoを割当
    • Baoを書き、プレゼン層からBaoを利用
  • Buriの利点
    • 更新年月日、更新ユーザなどのカラムはBuriテーブルが管理してくれる
    • フラグ(状態)も、全てBuriテーブルが管理
    • よって、DB設計の難易度が劇的に下がる*5
  • プロセスを定義するのには、マジカを使うとよい

まこたん(17:10-17:50)

  • Buriの名前の由来→ぶり大根*6
  • Buriを作った理由→IF文が嫌い
    • try, for, Stateパターン, SQL where も全部嫌い
    • カバレッジ的には、IF自体が存在すべきじゃない
    • ある程度には必要
  • IF文の種類。ほんとは3つにわかれる
    • 要件としてのIF
    • 設計で作られるIF
    • 実装で作られるIF
  • DBのフラグと連携するIFが一番嫌い。DBのフラグはグローバル変数
    • これを作っているのは、"設計"している人
  • Buriで解決できないIF
    • 区分の導出、運賃の計算、複雑な条件→これらはEbi(Excel)で管理
  • Buri入門・・・は、時間がないので流し
  • えび→ぶりの中のハリセンから派生
  • ぶりの今後→BugFix+クリーニング。機能拡張の予定は皆無。
ブリの内部
  • 内部データアクセスモジュール、ぶりコアモジュール、エンジンAPI、Processor+Bao
  • ぶりコアモジュール(XPDLを実行する)
  • packageとprocessはclass、activityはメソッド
  • XPDLコーダ→コンパイラ→内部表現+Object
  • BuriProcessの種類
    • AbstBuriExecProcess(ワカナゴエンジン)
    • AbstBuriExeProcessDataAccess(ぶりのエンジンの本体)*7
  • ぶりAPI → ProcessとActivityはルールベースで選択
    • buri.engine.selectorの中がルール
    • エンジンのdiconでどれを使うかを決める
    • 自分で拡張可能
  • 内部データアクセス→CUD
  • 権限管理→APIだけ提供。
    • Standardタイプはこれが必須
    • 普通のアプリにはいらない*8
  • 支援モジュール→タイマー実行とsignal
  • Processor→アプリケーションから呼びやすくするための物。buriSignalはこの仲間
  • Bao→aoシリーズに合わせた。XPDLから生成できるんじゃないか?
  • DB構造
    • ☆BuriPath→package,process,activityを文字列で保持。
    • ☆BuriData→ぶり外部のDtoを管理
    • ☆BuriState→PathIdとDataIdをマッピング
    • BuriUser
    • BuriBranch
    • BuriStateuser
  • ぶりのView
    • BuriPathData→PathName,pkeyNum,dataType,tableName
    • BuriPathDataUser
    • BuriPathHistoryPath
    • BuriPathHistoryUser
  • DB構造がシンプルなので、状態の検索はSQLで行う

質疑応答(17:50-18:10)

  • Q. ビフォアアフターが見たい。文字だけだとありがたみがちょっと。
  • まこたん: ない。ビフォア書くと発狂する。
  • 羽生さん: ぶりを使うと、設計の方針自体が変わってくるので、ビフォアができない
  • 羽生さん: 1.0にしないのは、広まり過ぎるのを防ぐため。
  • Q. 状態は、組み込みの物と同じイメージ?
  • 羽生さん: ActivityをAutoにできるので、通過すると処理として扱われる。ステートチャートともフローチャートとも似てるけどちょっと違う。同列に並べるイメージ。
  • Q. よくあるフローは伝票のイメージ。それでいいのか。
  • まこたん: それで構わない。
  • 羽生さん: デモを作ると、ぶり以外の昨日が目立ってしまう。マジカとかプロセスデザインとか他の技術の実装とか。
  • まこたん: ぶり祭りで質問の時に一人だけ暇だった
  • Q. フローを動いてみせれるといいのでは?
  • 羽生さん: ぶり祭りでのウケはよくなかった。birds eyeは、実際に運用する人には求められてない。IF文が多くて困るのは開発者だけで、お客さんは全く興味がない。お客さんの要求に、はいはい、と答えられるツールを目指している。ぶりのベンダーとなってぶりを売るだけならこのようなデモは必要だが、本質ではないでしょう。
  • 羽生さん: ぶりはOSSなので、有志がぶりのベンダーとなるのは構わない。

LT(18:10-18:30)

*1:人月100万だと、最高でも1200万。1000万の壁

*2:普通の企業の平均では、2000万〜5000万

*3:フラグ追加は怖い。つーか無理w

*4:「ここを変えても安全」、と書いてあるドキュメント以外無意味

*5:実装上出てくる余分な項目が必要ない

*6:Enhydra Shark(サメ)+S2Container(大根)だとまずいから

*7:ここにブレークポイントをしかけると、全てがわかるらしい

*8:画面のアクセス制御と、完全に被るから