Showing posts with label pyhug. Show all posts
Showing posts with label pyhug. Show all posts

2012/09/18

PyHUG 2012/09

PyHUG 九月份主題是 BBS Crawler(bsdconv) 和 Plone。

bsdconv 在萬碼奔騰的年代, 處理多種 codecs 和多樣 encodings 是很好的方案。

marr 帶來 Plone 這個 CMS 的簡介和近況。早先我學習 Python 是想用 Plone, 它是一個有感情基礎的 CMS XD

在討論的過程中, 有人對客製強化功能有興趣, Plone 也提供很方便的工具, 我過去也是 跟著既定的脈絡走。但最近使用 SharePoint 和 InfoPath 執行一個中大型屬於 CMS 的案子, 所以有其它想法。

首先, 在資料規劃上 … 大量, 多欄, 關聯的資料, 最好的歸宿還是資料庫。CMS 適合擺放目錄式, 多樣(圖檔, pdf, xls, doc, …), 和多版本(v1, v2 的 doc) 的資料。

概念上, 前者適合應用程式(Application), 後者配合流程(Process)。

應用程式處理資料的方式千變萬化, 通用的資料庫仍舊是好選擇。特別是商用資料, 對資料有各種使用方式, 避免瞻前顧後的話, 資料就放在成熟的方案裡頭。

如果說資料庫中表格(Table)的上位是 ERD, CMS 中內容(Content)的上位就是內容型態 (Content Type, CT)。不論 Plone, SharePoint, 或 Jackrabbit 都有相同的概念。通常在 CMS 以檔案系統的概念來做高階規劃 … 建立目錄結構, 接下來就是在目錄下分配使用 CT。一個目錄可使用多個 CT, 也就是先前提到的 多樣性, 而 CT 有不同版本對應不同 Content, 即多版本也順利在 CMS 中成立。 拿程式語言來比擬, CT 像是 Class, Content 是 Object, Folder 是 Collection。

再加上 CMS 對 CT, Folder, Content 有良好權限管理 (Plone 強項, 可類比成 檔案系統的權限設定)。基本上放在 CMS 的資料, 不會被不相干的人取得, 竊認為這是 和資料庫最大區別。

試想 … 流程有多樣電子資料要附帶著, CMS 就是一個很好的載體, 要區分存取權限 也容易。流程若有調整, 造成電子資料的差異, CT 多版本能順利解決這類問題。

應用程式當然也可以做, 但中間規劃, 設計, 與元件 … 太多是重複問題。有些框架有元件, 先不論功能適用, 能像 marr 所言: 最新的 Plone 4 最新版還照顧到 7,8 年前的 Content 就是個門檻了 XD

而許多事務流程系統, 重視流程的彈性, 卻忽略實際工作的要務 … 讓整合困難重重。

說到這裡, 有個題目是 … 表單 (Form) 適合資料庫, 還是 CMS?

不用說很多 MVC 以資料庫為主, 很多 View 概念上就是表單, 甚至 HTML 都有 form 標籤。 考慮實際流程發生的安全問題, 檔案管理, 流程變更要兼容並蓄(新/舊版本), 雖然有各式 各樣的解決方案, 但這些問題放在 CMS … 很自然就被解決掉了。

但在 CMS 裡頭做表單, 問題是 … 簡單的很快, 複雜的費工又很痛(會的人不多)。

我忽略 CMS 的角色有一段時間, 直到用過 InfoPath …

簡單來說 InfoPath 可直覺且快速完成複雜的表單(免除魔術師養成), 然後在 SharePoint 做為一個 CT。安排在特定目錄下, 表單資料存成一個純 XML 檔案, 取得也是一個 XML 檔案。

這種方法接下來的問題是, 要把資料放在資料庫 … 現在資料庫處理 XML/Json 都很強大, 都可以直接吃 XML, 或輸出 XML … 省卻中間的 App Server 或魔術師用的框架, 只要有 SQL 經驗, 輔以一些 XML 的操作就可上手。

整個過程大致是: 

基本上, 在 CMS 的加持下, 免除了表單與資料庫千絲萬縷的關係, 變成有必要才做。

而 OSS 在這方面 … 目前看到的方案還是與資料庫緊密結合 orz

除了一些以 JavaScript 加重瀏覽器負荷的專案, 例如 Backbone-form … 這也是最近嘗試瞭解的題目。

以上是從 Plone 這 CMS 角色延伸想到的 ... 整理下來。從服務式架構的角度, 各組合的角色要清楚, 避免把太多東西塞到某個元件裡。很多時候, 應用開發沒有問題, 畢竟很多功能的差異都可透過努力去彌補, 但清楚的角色有助於系統維護, 另一方面考慮元件的生命週期, 要升級/替代也才能較順利的進行。

另外, 會後聊到 Gmail 保密問題, 我有時會用 GnuPG 套件 … 如果收信人願意的話 XD

組合是 Postbox + Enigmail, Postbox 對 Gmail 的支援良好, 又吃 Mozilla based 的 add-ons (Enimail 提供 GnuPG 功能)。

2011/12/14

OFBiz Go

App 很紅, 主要在行動設備上, 上下游都很火紅。要談的 App 是現在不太紅的 Ent App (Enterprise Applications), 或是說已經紅過了, 但仍然是每個公司, 組織都會用到的。

App 多是產品, 而 Ent App 是種社會(Social), 俗名是江湖, 充滿交流與妥協, 大多以專案形式進行。就算從產品開始, 後面也會帶專案, 常見區分出軟體, 硬體, 開發, 維護, … 各個階段。

由於 Ent App 牽涉層面通常既廣又深, 以技術角度來看, 擴散方式(銷售, 安裝)一直沒太大改變。現在雖然服務導向, 雲端喊得震天嘎響, 但除了網路基礎服務(信件,檔案), Web應用或特殊應用, 要把 Ent App 放上去, 應該還有些東西要準備好。用雲端的榜樣電與水比擬, 水除了自來水, 還有各式來源; 電除了公共設施, 也有可移動型的, 或私人備援。因此資料的移動能力要具備, 否則還是有些不足。

開放源碼讓技術普及, 加上硬體設備的大幅提升, 過去得詳加規劃, 才能執行的 Ent App, 現在只要在雲端或筆電開個 VM (虛擬機器) 就行開工。再者, 小公司不需要 24 小時運轉的系統, 功能有的話, 需要時再開啟。甚至中型單位, 只要合宜的環境及配套規劃, 也能朝這方面努力。

首先, 要面對的問題是 … 怎麼去開始?

在 OFBiz 下載頁面中, 寫明只要有 JDK(Java 1.6 SDK), 下載 zip 後解開壓縮檔, 執行指令就可以開始。

似乎還算容易?

但每個平台準備 JDK 其實都不太一樣, 更不用說如果發生衝突的話要怎麼辦, 例如在 Linux 上用 OpenJDK。這些說明字句雖少, 看起來簡單, 毫無疑問是寫給工程人員看的。再加上 Ent App 的社會屬性是有機成長, 如果要修改, 要調整, 按照慣例就得靠自學, 或找人助拳。

以整個過程來看, 愈到後面, 障礙愈高, 的確是不太容易推動。

之前在一種應用源碼管理的實作討論過 可短小, 可長久, 可分享 的客製化方式。路雖然通了一小段, 但想想, 比原來 OFBiz 官方的安裝方式還要複雜, 素人要開始, 會有不小的障礙。

因此做了 OFBiz Go 用一個步驟完成 所有 繁瑣的準備工作。

準備工作有:

  1. 下載必須的 JDK, Python, Subversion, Mercurial 以及相關工具(patch, diff, cURL, 或 Wget), Windows 要再加 MinGW。
  2. 安裝妥上面這些東西, 做好設定 … 例如系統變數, Mercurial 的設定, 與 virtualenv 的環境。

當然如果機器上已經有的軟體項目, 就略過不下載, 也不安裝。

寫上一篇的時候, 略過這些步驟。對熟悉這些工具的人, 早就備妥; 但不熟悉的人, 繁瑣且容易漏東漏西的過程, 反而造成困擾。即使自己做, 將這些裝到 Linux, 也碰上不少問題。

想做個 VM 來用, 但每次要把數 GB 的東西搬來搬去, 還得搬進雲裡頭, 舉重若輕恐怕也不太容易辦到。

在支援 Windows 前提下, 也考慮 Puppet, Chef, 或老牌 CFEngine 這類 組態管理 工具。但即便輕如 CFEngine 都必須做額外的安裝設定, 所以這工具還是留給 應用系統, 做為其中的組件。

剩下可用的大概就是系統腳本語言(Shell Script)。

OFBiz Go 是先在 OS X 上寫個 .sh 做完上述工作。然後找到 Windows 2008 用 Powershell 寫個 .ps1。最後用 VMWare 開啟 Ubuntu 11.10, 原本認為 OS X 小改就可以用, 但還是改了不少。

比較特別是 Powershell 挺有 Power 的 … 要正確合法下載 JDK, 需使用者同意。Powershell 可控制 IE 瀏覽器帶出正確下載網頁, 當使用者點選同意後, 繼續腳本的工作。

目前在 OS X 10.6, Windows 2008R2 / 7, 還有 Ubuntu 11.10 測試過。OS X 可能會不太行, 因為環境不乾淨。;-)

只要腳本的下載, 安裝, 驗證的工作做完, 就可和 應用程式源碼溝通。把繁瑣的過程, 劃分成兩個階段, 方便入門者, 也方便自己。

由於大部份工具和 Python 相關(Fabric, MQ), 下週三(2011/12/21) 晚上 19:30 在新竹的 PyHUG 會描述 配置方式 與 應用客製 兩階段的安排, 及運作細節。除了 Ent App, 很多類似的狀況, 也可用相同方式處理。歡迎參加, 和我們一起討論。