近未來 IT 程式開發

今年初(2009)看到 InfoQ 上匯集 2008 年度文章, 其中一篇 JRuby 開發者之一 Ola Bini 先生的相關文章 "Programming languages in future systems" , 將應用系統用到的語言類型分為三層, 印象很深刻 ... 因為幾乎花整個 2008 年的時間打造這樣的系統 ... 在讀到文章之前, 做起來不盡相同。在案子完成之際, 借用相似標題記錄一下這個過程。

大多數 IT 相關系統, 都是處理資料 ... 絕大部分的人都會同意這是領域(domain)主導, 不是技術主導。在一些廠商強力運作下, 開發人員近乎被催眠在執行一些固定工作 ... 選用主流技術(沒人喜歡意外), 然後踏上規劃, 分析, 設計, 實作, 測試, ... 的履帶。

在專案執行之前, 有 IT 主要廠商已下海幾年宣告失敗 ... 就不得不審視一些基本問題:

1. 這是一個財務資訊系統 (AIS, Accouting Information System) 主要得完成 "成本系統" ... 屬資料市集 (Data Mart) 規模, 資料變異不大但資料量大。


2. 使用者都全天候使用, 需求經常性改變 ... 使用角色的人數約開發者的 5 倍。


3. 之前系統是 dbase 系, 因為原廠不支持, 決定換 Java。要接手的 IT 部門沒人有經驗 ...

審視第一點 ... 之前也習慣用 ORM, 但時薪較我日薪還高的廠商都搞不定的資料量 ... 立馬決定透過 SQL 把資料處理的問題都丟給資料庫, 捨棄物件導向方式。

關於第二點 ... 全天候使用, 帶給系統更大的壓力。而需求改變, 更是許多系統不穩定的致命一擊。但揉合這兩個問題, 使用腳本(Scripting)語言達成快速變更, 測試就交給使用者(與開發人員關係良好) ... 原則上是這樣, 還有一些方式, 下段再述。

而最末一點 ... 要從頭學習 Java, 並好好發揮不是每個人都辦得到。但主要是匯入/匯出、維護/查找資料、檢核、計算、報表、傳票 ... 這幾件事，大致就是 SQL 加上個別功能就收工。後來都是 SQL 測試完成後, 再用樣板(template)套入功能 ... 大約可完成八、九成工作。

以技術拆解來看是: SQL + 腳本語言 + 功能模組樣板 ... 有人認為 Java 可達成, 的確也是。但 Java 的問題在於, 直接放 SQL 勢必會分段(SQL 都是長得誇張), 再加上變數會更亂; 而做成獨立檔案(iBatis 做法), 或 Stored Procedure 或 View, 造成非功能性分割, 竊認為是修改應用程式不易的禍首。

使用腳本語言就一個功能一個檔, 很直覺, 清清處處 ... 開發過程曾有 SQL 部份算式要改, 還是使用者(只會 SQL 查資料)直接指出哪邊要改。

專案開始(2007年中), 就決定使用Groovy, 即便用過 jython, 當時也較成熟; 而 jruby 如日中天 ... 但偏好 Groovy 補 Java 不足的角度, 特別是支援類似 python 三引號(triple-quotes)的樣板字串(template string), 可直接寫 SQL 再加上需要的變數、函式都很容易 ... 除了 Groovy 本身支援的 SQL, 後來也嵌入EBNF 的語法描述, 再來做 DSL 處理也很方便。

回頭看打造的系統與 Ola Bini 先生宣告三層類型的對應:

1. 穩定層(Stable layer): 沒與應用太多相關, 以靜態語言打造 ... Groovy 程式的載入、執行都是用 Java 寫的。


2. 動態層(Dynamic layer): 與應用相關, 以動態語言打造 ... 功能模組樣板(匯入/匯出, 檢核, 計算, ...), 都是用 Groovy 寫的 ... 像報表小計方式百百種, 都一一解決。


3. 領域層(Domain layer): 與應用相關, 以領域語言打造 ... 使用 SQL + Groovy 方式, 大抵 SQL 能動就了結。

其文中提到的 Drools 也有用到, 因為決策表格(Decision Table)對使用者更容易使用 ... 也在此做證言 :-)

OmniOutliner to Blogger

OOblogger 沿自 Helpify, 讓 OmniOutliner 的文章轉成 Blogger 可收的格式。

自從把網誌搬來 Blogger, 遇到一些撰寫障礙 ... 雖然原本產量就很低 ...

只是要寫有圖、連接的文章, 即便 Blogger 線上編輯器功能完備。但放在別人家裡, 沒什麼安全感。試了一些方式:

1. 網誌專用編輯器 ... 寫條列式, 轉到 blogger 都會變得很糟, 多幾階就全亂了。
2. 書寫工具轉 HTML 檔 ... 大多附 CSS 或轉成復雜的 HTML, 放到 blogger 也是不太合。
3. 用 Markdown 撰寫 ... 人工管理文、圖蠻辛苦的 ... 得做蠻多額外工作。

期間看到 Github Pages 是很贊的做法, 但太技客式 ... 現在大多用 VoodooPad, OmniOutliner, NoteTaker 之類的, 要轉換還是太費工。

前幾天在 www.omnigroup.com 網站逛, 看到 OO3 的 Extras區有個 Helpify 能將 OO3 格式檔案轉成蘋果的輔助檔。而 OmniOutliner 用來寫長、短文都適宜, 感覺很合用, 動手將 Helpify 改成 Blogger 能吃的格式。

Helpify 有兩個特點:

1. 轉換來源(OO3 文章)和結果(HTML, CSS, Images 檔案)無關, 大部分能輸出 Web 的書寫工具都儘可能複製原先的風格, 適合單獨存在, 很難塞入 Blogger 能接受的 HTML 格式中。使用 OO3 寫不同類文, 多會設定些不同風格, 透過 Helpify 轉換, 只有內容, 結構, 圖檔, 連結會轉換成 Web (還蠻多的)。
2. 使用 Helpify 還能加一些特定的處理邏輯, 這是之前用 XSLT (OO3 的 Export 擴充標準)比較難做到的。以 Helpify 本身來說, 會將每個項目區塊轉成獨立檔案。

放上這篇文章在 OO3 的快照比較一下:

修改後的 OOblogger 放在 Github。現在還要手工剪貼到 Blogger, 再找時間做上傳 ...

OFBiz 概覽

功能特色

1. 主要功能
   
   • 財務: 應收/付、發票、帳戶、稅務(貨品)、總帳。
   • 進銷存: 庫存、採購/銷貨、進/出貨。
   • 生產: BOM(數量)、途程(時間)、製造流程、生產計畫。
   • 其他:客戶管理、產品、人事、專案、電子商務網站、POS、BI。
2. 特點
   
   • 跨 OS, DB
   • Web 化
     
     UI 介面眾多(硬體/OS/規格), 而 web 最普遍 ... 近來 web 更接近 GUI (參考 OFBiz POS, 庫存)。
     ERP 主要在表單、報表, web 挺合適。
     在安全狀況下，隨時隨地都能掌握公司狀況。
   • 功能串接
     
     不僅提供功能項目。
     財務聯繫: 各項作業拋轉傳票。
     資訊聯繫:
     a. 從產品查詢相關訂單、存貨、銷售、生產結構。
     b. 從客戶查詢相關合約、交易、款項。
3. 使用概況
   
   • 國別 (多語言、多幣別)
     美、義、法、英、德、中、日、泰、...
     南台灣(?)
   • 專案 (擴展中)
     
     相對於許多開源 ERP 專案由特定公司掌握。
     Data Model: 有人用新技術做不同版本(Grails/ORM)。
     從 OFBiz 衍申不同專案: JIRA(開發追蹤)、Mvelopes(個人財務)、opentaps(財務)、SourceTap(客戶關係)、Neogia(製造)、...。
   
   

商業產品 vs. 開放源碼

1. 費用
   
   • 商業產品: 產品、導入(客製)、維護。
   • 開放源碼: 導入(客製)、維護(選擇性)。
2. 文件、支援
   
   • 開發方面
     
     商業產品這方面佔有優勢，不論原廠手冊、官方網站參考資料、熱門產品還有更多作者推出書籍。而較專業的在支援也採取認證措施、甚至建立跨國支援網路。
     開放源碼的資源除了提供服務廠商、網際網路(社群、佛心文件)、重要的還是源碼本身。
   • 使用方面
     
     由於 ERP 高度客製、與資料相關的特性，通常由關鍵使用者與廠商打通功能，關鍵使用者再整理出使用方法 ...
     通常僅有幾個步驟、畫面。
3. 整合一條鞭
   
   基於商務、資訊流的頻繁，將有更多功能與整合的需求。
   商業產品多是選擇其策略廠商產品、或客製化專案解決。
   由於開放源碼普及，過去關鍵技術通常都有解決方案。(CORBA)
   諸如供應鏈、規則引擎、工作流程、商業智能、... 等。

導入建議

1. 概要
   
   體驗取代按部就班。
   
2. 前置準備
   
   • 關鍵使用者(單位)
     
     考量最前面『主要功能』列表，依職權指定關鍵使用者。
     從關鍵作業出發、瞭解系統運作。
     思考按原有程式處理、或規劃調整方式。
   • 運作協調(組織)
     
     評估原有跨部門作業是否合乎需求?
     釐清部門間作業、勾稽。
     確定作業程序。
3. 階段施行模組 (製造業)
   
   • 產品、客戶、財務。
   • 進銷存、生產。
   • 其他。
   
   

小結

1. IT 系統，資料至為重要
   
   OFBiz 以資料模型為重。
   
2. Web 最為普遍的使用者介面
   
   效益保障 ... 使用者習慣、新舊機器/不同OS皆可使用。
   有 ERP 的 Web 版是另外收費的模組。
   許多 Web 版的 ERP 功能偏重特定類別(i.e. 電子商務)。
3. 導入 OFBiz 比較像擁有 ERP 的 IP 元件
   
   是可以運作的元件。
   許多 ERP 元件修改不易, OFBiz 在資料模型、Java 功能完成前提下。所有皆可透過普通編輯器修改、即時改變。
   需類似『IC 設計』的角色把元件組合成更好用。