普及的行動設備會演變成為一個人擁有多個設備, 但不連線(不連續)就會造成的問題。Dropbox 解決了檔案問題, 讓檔案同步因此大受歡迎。而雲端運算到後面各個服務的連結也會造成不連續, 簡單舉例: 金流可連續完成, 但物流就不可能。
從結果來推論需求, 如果生產, 金流, 物流都上雲端了, 那在手上(設備)要掌握什麼資訊?
(嗯 … 產品的規劃設計是另一件事。)
要掌握的資訊, 可能人人不同, 也可能隨客戶的客戶而不同(B2B)。
雖然流行的腳本語言(Scripting)能因應快速的變更, 大部分時候在程式碼與資料間是有清楚的界線。這個界線是 … 使用者(或客戶)非常在意資料, 而程式員則關注程式碼。即便可選擇的開發工具很多, 也都很強大, 但幾乎是建立 MVC 下, 類似 rails 模式, 或者是說與資料庫關係密切, 這些都屬於連線(連續)的形式。
最好能夠做到『碼即資料, 資料即碼』(code is data, data is code), 由使用者在掌握資料即能驅動後頭的雲端, 即使不連接也可讓服務運作下去。
不論如何, 資料還是需要載體(Container), 最好的載體應該是試算表。它除了能放置資料, 還能兼顧人們視覺操作的慣性, 可將資料的顯示位置, 存在與否, 還有排列做調整。如果沒有應用程式, 這種方式應該是首屈一指的資料載體。
主角都現身, 可想像一下: 透過試算表來連接各種後端的服務(雲端)。資訊服務業能透過試算表輸入資料(例如使用者需求), 再批次進入報價服務, 每月產生報價單寄送給客戶。至於損溢, 現金流量, 庫存也可定時同步到試算表 … 並竟不是每個人都每秒十萬上下。
基於這樣的出發點, 建立了 Tabledown 專案。簡單來說, 是能夠讓試算表與集合資料(lists, hashes)做雙向資料交換, 透過一個對映集合設定(mapping collections configuration, MCC)來轉換。
已完成的是概念雛形的驗證, 就是在 google code 頁面的範例。陸續會做一些修正, 使用雲端試算表, 以及與 ERP, BPM 連接。
Tabledown 目前是組 Python 的程式庫, 希望有機會改頭換面成為一般工具。而 Tabledown 命名的點子是從 Markdown 而來。
參考
- TIOBE 索引排名
- Code is data, and data is code
- Tabledown: @pypi @googlecode
