2012/12/09

PDF Forms

近來關注著表單的相關方案, 除了 Web(眾多框架, backbone-forms), XML(XForms, InfoPath, XUL) … 前陣子逛軟體商店, 才發現有處理 PDF 表單這類 App。

搜尋相關資源, 整理一下 …

雖然系出 Adobe, 卻也不一定需要 Adobe 官方指定工具, 就能從頭到尾、從建立到處理, 完成所有工作。

特點

和 Web, XML 方案要一整個系統最大的差別, 在於 PDF 的表單只要單檔就可運作。

1. 方便移動

PDF 表單除了只要單檔, 和 PDF 一樣, 不論行動設備或各種常見的作業系統都通行。

在 OS X 上的 Preview 可直接填寫。

另一個觀點是能離線作業 … 得以各別填妥表單再傳送處理。

2. 容易讀取

不論對人與電腦都方便。

PDF 可輸出的樣式彈性很大, 幾乎是報表方案的代名詞。好讀自然不再話下, 只要有適當的設計規劃。再加上一些欄位就成為 PDF Forms, 立即讓人填寫。

讀取表單內容, 可利用 pdftk 直接讀出資料, 毋須寫程式也可使用 … 在下一段介紹用法。

實作

很多介紹, 是以寫程式來產生 PDF 表單, 後續處理表單資料也要額外程式 … 其實不一定需要, 這些工作不寫程式也能達成。

1. 建立表單 PDF Forms

在 OS X 有 PDFpenPro, PDFClerk Pro, PDF Nomad 可替 PDF 加上表單欄位。

開放源碼 OpenOffice(使用版本 3.4.1), 則可在各平台直接建立 PDF 表單。步驟大致如下:

a. 新增 XML 表單

11 New XML Form

b. 建立表單項目

在下面的範例, 塞一張圖檔、加一些欄位, 額外使用淡紅色標示欄位名稱

12 Construct Form

建妥表單, 再到下一步。

c. 輸出 PDF 表單

13 Export PDF

d. PDF 表單選項

14 Export PDF Options

e. PDF 表單檔名

15 Export PDF Filename

完成以上步驟, 應該能順利產生 PDF 表單: fruit_order.pdf 檔案。

下載: fruit_order.odt(無法預覽, 請選擇下載), fruit_order.pdf(線上看有點怪, 下載後 ok)。

2. 取出資料

a. 填寫表單資料

使用 Preview 按上面 PDF 表單給定欄位, 填入各項資料。

21 Fill PDF

填入的資料會存入該 pdf 檔案中。

b. 讀取表單資料

使用 pdftk, 如果檔案放在 ~/Desktop/fruit_order.pdf, 執行如下指令:

$ pdftk ~/Desktop/fruit_order.pdf dump_data_fields_utf8 output -

就可將表單資料輸出到 stdout, 或把 - 改為檔名, 選擇輸出到特定檔案。

22 Use pdftk

和先前 b. 建立表單項目 步驟比較, 可看出 欄位名稱 (FieldName) 和 填寫資料 (FieldValue) … 很容易對上。

3. 佈置 PDF 表單

從上面的介紹, 瞭解 PDF 表單 建立, 填寫, 讀取 方式, 接下來看看怎麼安置這些 PDF 表單檔案。

a. 電子郵件

PDF 放在網站上提供下載, 或以電子郵件傳給需要填表單的人。

在 PDF 表單裡頭標注, 填寫完寄給 foo@jia-side.org … 即可完成表單發送、接收的程序。

只是收到 PDF 檔案後會怎樣被處理, 全取決於經辦人員。

b. 檔案分享

適合組織內區域網路中檔案共享, 或使用網際網路檔案服務的方式 … 也就是特定群組內的檔案分享。

在檔案相關系統中, 安排 PDF 表格處理方式的各種目錄。例如: 所有表單的 樣板目錄, 處理中目錄, 完成目錄, 以及最後流入按年份分門別類的 庫存目錄, …

使用大部份人都熟悉的方式, 不同工作在不同目錄間流動, 即可完成許多原先紙本的工作。

c. 內容管理 + 流程系統

基本上, 是前個項目 b. 檔案分享 的進階版 … 概念相同, 但所有動作自動化。

  • 樣板目錄 中, 各表單的版本由內容管理區分。
  • 新填表單送入 收件目錄, 由流程系統分派給經辦人員。
  • 表單處理的特定過程, 皆由流程系統安排。(可考慮資料檢核)
  • 處理完成, 按流程安排的步驟放入 完成目錄 中, 供相關人員瀏覽。
  • 老舊檔案的時間屆存檔年份, 內容管理負責移到 庫存目錄 備查。

用途

表單是許多組織行動的基礎, 單純表單的角色, 卻常被使用系統人力資源所左右。

複雜的系統, 其本身往往就需要很多專業人士來維持。

從頭打造的應用系統, 建立/維護也是個問題, 總不成每每來個衝刺。

使用 PDF 表單, 有機會突破這些罩門。

  • 能操作文書軟體, 就能建立/維護表單。
  • 不需 Web 專業, 也可在表單中盡量放入必要訊息。(參考高鐵轉乘服務的PDF檔)
  • 讀取表單內輸入項目的資料, 只要工具, 不用寫程式。

使用方面 PDF 表單也近似紙本表單, 能高亮(Highlight)標示、張貼備忘(Note) …

31 Preview PDF Note

再者, 若打通檔案的流通, 透過智慧手機、平板設備處理 PDF 表單, 會更接近真實填寫表單, 包括簽名

2012/09/18

PyHUG 2012/09

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

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

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

在討論的過程中, 有人對客製強化功能有興趣, Plone 也提供很方便的工具, 我過去也是 跟著既定的脈絡走。但最近使用 SharePointInfoPath 執行一個中大型屬於 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 功能)。

2012/09/11

嘗試 Require + LiveScript + Backbone

最近想利用 Backbone 的某個套件來做東西, 於是開始摸索 Web 前端。

原先打算用 CoffeeScript 撰寫 Backbone 相關程式碼, 只是 半路 看到更加 有趣的 LiveScript … 馬上改弦易徹。

對 LiveScript 新手, 最初的挑戰 … 不確定寫的是對還是錯。 LiveScript 有個方式是 轉成 JavaScript 來確認 … 雖然有 LiveScript.tmbundle 可為 TextMate/Sublime Text 加持, 由於挺偏好 CoffeeScript-Sublime-Plugin 透過 Command Palette … 選擇 CoffeeScript: Run JavaScript 的方式, 把 CoffeeScript 轉成 JavaScript。於是 混合 LiveScript.tmbundle 和 CoffeeScript-Sublime-Plugin 建立 LiveScript-sublime 專案, 加強 Sublime Text 對 LiveScript 的支援。

接下來是程式碼模組化, CoffeeScript 有 require-cs 擴充 Require 載入 CoffeeScript 能力, 但 LiveScript 沒有。因此參考 require-cs 建立 require-ls, 方便 LiveScript 切分模組。

最後試著把這些組合起來, 以 Backbone 原本的 範例 改寫 為 LiveScript 加上 Require 的版本 … 建立一個 require-ls-backbone 專案記錄這些嘗試。

2012/08/13

集中/聚眾/集眾開發

一直從事軟體開發工作, 其中不論參與產業, 各類技術, 團隊規模, 時間長短, 雖有各有不同, 皆是解決客戶問題為主, 也都是專案的型態 … 而專案執行方式也各有不同, 從古早到近年流行的, 或多或少都參與過。總的來說, 都是由外而內的驅使著開發者, 必須針對客戶的需求做處理, 做回應。

從剛開始是廠商, 標準, 或方法的傳聲筒, 到現在能夠提出各式各樣的嘴砲意見。這是 … 馬齒徒長!!??

由外而內的改變, 雖然邊拉距邊有進展, 但聽說真正的成長是由內而外。因此, 開始思考在執行專案時, 發生衝突到最後調和的事件。嗯, 這篇不是談技術, 因為技術最好的歸宿就是被消滅; 也不是談業務, 因世代更迭的業務, 總是來來去去。目標是整理一下開發大環境的差別, 及相關的影響。最後歸納為, 開發者正經歷集中開發(Central), 聚眾開發(Clustered), 與集眾開發(Crowded)的不同世代。



把紅點視為一開發單位, 紅點散落位置區分了不同的方式:
  • 集中開發: 紅點集中在一起, 為共同目標而努力。
  • 聚眾開發: 紅點聚落各有長處, 分工聚落各有發揮, 但聚落合作才能完成目標。
  • 集眾開發: 當群體進展到某個程度, 個別單位縱使降低對資源的要求, 還是能達成目標。



從硬體, 軟體, Java 舉例來說:
  • 硬體: 古早到現在 IBM 的角色, 毋庸置疑; 台灣著名的就是電腦組件聚落; 蘋果則近年來讓電腦取代寵物的地位方面功績卓著。
  • 軟體: Oracle 專長打造資料的家; MS 建立的聚落嚴有許多 … 作業系統, 企業應用, 遊戲; SF 雖然漸漸被取代, 但卻是讓大眾發表分享源碼, 方便交流的起點。
  • Java: Sun 早先前集中資源打造出跨世紀的 JVM, JDK; Apache 以 Web, Services 甚至雲端著名, 近來常做撫養托孤業務; Hadoop 是 Apache 其中一個聚落, 但更能表現集眾開發, 為此獨立出來。
先看 Apache 與 Sourceforge, A 和 S 都是開放源碼的重鎮, 但 A 是會員制, S 則隨開隨用。Apache 能到頂層(top level)的專案, 幾乎都可視為一個聚落, 聚集著對專案有興趣的公司或個人。開始先在論壇, 事例追蹤上參與, 被認同後才賦予擔負工作的身份。A 要去瞭解, 要去參與, 而 S 只要名稱不同, 很快就能開個專案, 我還是我。在早期 S 能聚集的是本身具備吸引力的專案, A 透過組織方式更能推動發展。

發展到一個階段, 開發不只著重開發者的角色。以社群類處理的使用者數量來說, 是早先集中式商業公司嘗試以高規格軟硬解決而失敗的題目。流行的方式是將問題分解, 個別強化, 捨棄不需要的部份, 組合成因應需求的系統。例如, 連線數量(MINA), 訊息處理(Camel), 計算能力(Hadoop), 資料存取(Cassandra), 內容管理(Jackrabbit), … 全部都可以分解, 組合, 不需要一個全能的應用伺服器(Application Server)。

更重要的是, 個別專案都經過不斷使用的驗證, 也持續被使用。例如: A 賣場, F 聯誼社, G 廣告商參與的 Hadoop, Cassandra, … 要集中資源或指定聚落開發類似的功能, 都難以負荷。但從滿足大眾市場, 回頭灌溉成的專案, 就能因此受惠。

所以集眾開發必須加上, 個別經營大眾的觀點:



在以上前題成立的狀況, 個別開發也成為可能:



回頭看過去執行專案使用新技術, 會不斷被勸阻, 因為總是增加風險。但最後化險為夷, 是這些新技術總是進展到一個難以預估的地步, 不論是功能或穩定方面, 這些都不是古早開源專案可以想像的。唔, 大約十年前。最後的結果 … 除了組員肯定, 也被客戶讚許(多次廠商競賽, 都協助客戶拔得頭籌) :-)

那些都是隨波逐流的好處, 卻也可能遇到 … 使用協力的專案被腰斬, 功能不如預期, 整合障礙, …。竊認為是技術問題, 調和正正負負的項次, 就不在這裡細細討論。

最後記下一個開放問題: Scrum 方法用在何種開發情境(集中, 聚眾, 集眾)合宜?