OpenID，一套合作的協議

本來以為OpenID是讓用戶在網上有一個通用的識別項，但根據http://openid.net/等網頁的簡要說明，告知顯然我誤會了。顧名思義就是要open，一個登入行遍天下，不過，這「一個」登入似乎不是只登入一次的意思，而且一個「登入」也似乎不是一個帳號的意思。

規格書的認證部份，OpenID Authentication 2.0開宗名義指出：認證是證明用戶操作這個識別項。而識別項就延用網址URI形式，可說是「節能省碳」，重覆使用既有的設計。認證這個話題是很多人都喜歡談的。如果學校收發室要為學生轉寄郵件製作資料庫，就要考慮「誰寄給哪位同學」的問題，學生的識別項很好找，但左邊那個「誰」的識別項不容易設計。既然目前OpenID還不考慮到通用識別項(universal identifier)的情況，盼望將來通訊協議有更好的發展。只是，人與資訊完全密切整合，會是《全民公敵》或《駭克任務》的社會情況嗎？如果是，我不樂見這種未來情況。

Paul and Technometria的OpenID示意圖和Leancode的OpenID示意圖給我們一些不同的觀察點，前者採通訊資料流觀點，後者採認證層次觀點。Paul and Technometria的圖告訴我們，哪些資料或訊息的傳遞是一組的，並且為了維持OpenID的運作，各服務方都要表現出適當的行為。Leancode的圖顯示出在認證的訊息傳達之前，須要來往傳遞一些未認證的準備訊息。用戶的目的訊息，是借OpenID提供方的識別項，請求其他的服務方提供服務。而OpenID提供方與其他服務方在下層則必須交換session訊息，這個行為和client-server環境的服務方內部運作相同。

我覺得設計分散式合作協議的人很厲害也夠聰明。低層次的電腦協議是彼此傳遞一組資料，則根據收到的資料符號格式，判讀為哪一種行為。高層次的通訊協議卻可以用比較抽象和淺顯的講法描述各方該傳什麼資料或提供什麼表單，或者表現什麼行為。

OpenID看起來是網路應用的必要過程，從任何網站都只對自己的帳號提供服務，轉變成任何網站都順便對其他網站的帳號提供服務。對微程式資訊自家產品Single Sign-On的參考用處，目前可能是檢查各系統元件、各伺服器，在互動和通訊行為，起碼在自己系統環境中是否足夠open；順便為了未來對其他公司和其他系統的聯外整合做預備。

Open WYSIWYG 網頁編輯器配置小技巧

OpenWYSIWYG, http://www.openwebware.com/ , 是很好的網頁程式元件. 除了是全JavaScript寫作的, 也是跨平台適用的.

我有段網頁程式是:

<p>
內容：
<textarea id="content" name="content" style="width: 100%;" rows="6"></textarea>
說明：
<textarea id="content1" name="content1" style="width: 100%;" rows="7"></textarea>
</p>

按照 OpenWYSIWYG 的說明書, 在開頭加上 <script language="JavaScript" type="text/javascript" src="script/wysiwyg.js"></script> <script language="JavaScript" type="text/javascript" src="script/wysiwyg-settings.js"></script> , 文件尾端加上:

<script language="javascript1.2">
var mySettings = new WYSIWYG.Settings();
mySettings.ImagesDir = 'image/';
WYSIWYG.attach('content', mySettings);
</script>

, 所有 script, style 和影像檔都放對位置, 網頁在 FireFox 成功顯示, 卻在 IE 6 出現錯誤:

行: 809
字元: 6
錯誤: 原始 HTML 對這個操作無效
程式碼: 0
URL: ...

翻出 wysiwyg.js 808 行是 textarea.insertAdjacentHTML("afterEnd", editor);
MSDN對insertAdjacentHTML的註解是:網頁正載入時不可做這個操作.
不過, 經過一些檢測, 上述錯誤不是由這個原因發生.

想來想去, 覺得是網頁文件結構不對吧 (non-well-formatted) ... 後來把文件改成:

<p>
<div>內容：
<textarea id="content" name="content" style="width: 100%;" rows="6"></textarea>
</div>
說明：
<textarea id="content1" name="content1" style="width: 100%;" rows="7"></textarea>
</p>

在 IE 就完成了. 我想 OpenWYSIWYG 對網頁結構是敏感的.

微程式資訊技術研討會 - 函數程式語言簡介

投影片在此:

mpfi20080910

View SlideShare presentation or Upload your own.

講義另日擺上.

如何成為一位傑出的工程師一文讀後感

這篇文章值得一讀,但是;讀完後我們要怎麼再思考咀嚼成為自己的血肉? 我覺得 why很重要,而why not也很重要,文中提到:



成就傑出表現的原因並不在他們擁有什麼 ，而在於他們如何應用他們所擁有的特質。傑出表現之謎其實在於如何將他們的天分轉換成生產力：就好像將位能轉換成動能一樣。我們的結論是：傑出的表現是努力得來的，與天份無關。(Stars are made, not born.)



那麼這句話自相矛盾的嚴重！沒有天份,就無法將天份轉換成生產力,所以;傑出表現的原因在他需要先擁有天份,才能轉換/應用 特質,結論應該是;傑出的表現是因為有了天份,才能靠後天努力得來,那麼就與天份有關,不是嗎?



這篇文章反應的只是一些特例,也就是說他的研究對象是那些已經在這個領域有充足天份的人,以這些人為基礎來做這個研究,成員結構與一般的公司大相逕庭,所以他的結論應該是;如果你對xx領域已有天份,還需要靠後天的努力才能成為傑出的工程師,於是乎那種天生的宿命論仍然主導一個工程師的傑出不傑出,不是嗎?







--- 電子發票系統建置 http://rd-program.blogspot.com/2012/03/blog-post.html ---

(規範閱覽筆記) 電子產品碼資訊系統架構

架構

EPCglobal 架構包含相關硬體、軟體、資料規範以及一些核心服務，可供 EPCglobal 和他們的委派者使用。透過電子產品碼(EPC)的使用，達成商流與電腦應用的加強。

受惠者

EPCglobal 的用戶，包括

1. 純用戶：將 EPCglobal 規範與核心服務使用在商務運作中的機構。


2. 發展者：參與 EPCglobal 規範研發過程的機構。
   


3. 方案提供者：根據規範與核心服務，實作用戶系統的機構。
   


4. 其他方案提供者。
   

由 EPCglobal 客戶使用本架構的各項目彼此溝通所造成的綜合效果，俗稱為 EPCglobal Network 。

架構概觀

EPCglobal 架構與三種活動對應，包括 EPC 實物交換規範、 EPC 資料交換規範和 EPC 基礎架構規範。

1. EPC 實物交換規範：定義貼附實體產品的電子產品碼，用以保證當 EPC 用戶從別的用戶收取所傳送的實物時，能夠判讀實物的電子產品碼。
   
2. EPC 資料交換規範：提供用戶在特定的使用群或與公眾分享資料的方法，也提供存取 EPCglobal 核心服務或其他分享服務使資料交換變容易。
   
3. EPC 基礎架構規範：定義用以收集和記錄 EPC 資料的介面規範，做為基礎架構元件以提供用戶內部系統的建置。
   

EPCglobal 架構的目標 (1)

EPCglobal 架構中各份規範的角色如下：

1. 使交易伙伴的資訊與物資交換變得容易：交易雙方必須先行議定所交換資料的結構與意義和交換機制；也必須先行議定所交換的實物上如何用可了解的方式貼附電子產品碼。


2. 為系統元件培養競爭市場區位：EPCglobal 規範定義系統元件的介面，使不同廠商製作的元件能夠互通，進而提供用戶一些選擇。


3. 鼓勵創新：EPCglobal 規範只規定介面，不規定實作。鼓勵實作者在產品與系統能創新，而介面規範能保證系統的互操作性。

[1] F. Armenio, H. Barthel, L. Burstein, J. Duker, J. Garrett, B. Hogan, O. Ryaboy, S. Sarma, J. Schmidt, K.K. Suen, K. Traub, and J. Williams, The EPCglobal Architecture Framework: EPCglobal final version 1.2 approved 10 september 2007 [Online].

(待續)

抱歉！我並不希望你們假日來公司加班

親愛的夥伴,我最敬愛的摯友;我不知道你們多久會來看我的Blog;或是根本不會來,但是我還是想說一些心裡的話,今天我到公司看到大家認真加班,每個人不求加薪在星期假日到公司來趕工作,那種熱情;我本該由衷感激,不過;抱歉!我必須說:我並不希望你們假日來公司加班,因為加班只是效率不佳與無法準確估算時程最佳寫照,雖然;我不是你們每個人的主管,不過我必須跟你們說:這類的加班是錯誤的,不管對公司對個人來說,都損耗了最大的成本,而且;個人也不相信趕工出來的東西;品質能夠得到任何的保障

不過我應該更精確的說明我的想法,我所指的是沒有按照計畫行事而因為要交付客戶產品時程趕不及所需要的加班,這一連兩個禮拜,我看到這種狀況真的是搖頭連連,如果我自己知道;我所要購買的產品不是按部就班完成,而是透過加班的手段來達成目標,那我會毫不遲疑的退貨,理由無他;因為工作沒有按照例行計畫施行來完成,在每個流程裡的工作者都無法確實估算他的工作流程所需時間;且無法提出保證,這代表了生產品質也面臨相同的問題->不夠精確且無法提出證明,那麼;我們該為這種例外管理上的趕工喝采嗎? 值得商榷...真正有效的管理計畫,應該要包含很多變異的因素,所以計畫本身就要包含變化,才能將不確定的因素降到最低,如此才能使經營成本得到精確的估算,保障企業經營的穩定成長,如果我們遇到的每個問題都是不確定的,那我們要如何保障股東與客戶的權益,替他們提供確實可行的願景?

公司假日仍在公司的比率,我應該數一數二,且每天從事工作相關的事務直到am 1:00,但是我絕對不願意把絲毫的時間浪費在這種無法保證自己工作效率的事務上,我寧願假日到公司心情輕鬆自在的讀我想讀的技術文件,我情願熬夜去探討怎麼寫程式會比較好或怎麼把程式更有效率的完成且如何兼顧避免錯誤的發生,如果興趣就是programming,如果因為興趣而工作需要不停的工作,那是個人選擇,除此之外;抱歉！我只能說,這種補償過錯式的加班,不值得稱許

如果;你們認同我的想法,應該深自思考甚至開會檢討,這兩個星期我們是為什麼加班? 沒準時的理由是什麼? 該怎麼改善這些缺點? 是誰沒準時把東西交出來? 是誰說哪天要給而沒給? 是不是要提早先把工作完成? 我有沒有事先提醒我的夥伴該完成那些工作? 在遇到問題時我有積極向上反應嗎? 該不該獎勵 把準時 把品質 當成第一要務的夥伴? 這樣才真的有把問題解決,否則;我只能說要靠加班趕工來彌補事前無法按部就班所犯下的錯誤,我非常不能認同,尤其是;這本來是可以提前完成的事,為何要這樣浪費資源?

寫parser多簡單?

為了處理 Jabber/XMPP 的實作，勢必要考慮到 parser。

根據 Wikipedia 的說明，parser是指將一串輸入文字建立為 parse tree 的功能。根據文法，字串無法剖析為 parse tree 代表剖析錯誤。

用 Haskell 寫 parser 似乎比較簡單。 (?)

Parse tree

一般來說，(binary) tree 是指：

1. 「空無」情況是 tree ，或是


2. 以一項物件為基礎，擁有左子項和右子項，二個子項也是 tree 。

在 Haskell 定義 tree 資料結構為

data Tree = A | B | Bin (Tree, Tree)
deriving Show

看起來已經滿足一個 parse tree 的構成。

Parser

Parser 是一個函數，其輸入為一串資料，並輸出一些可能的 parse tree 和剩餘未 parsed 的資料。因此宣告 parser 的資料型態為：

type Parser a b = [a] -> [(b, [a])]

其中， a 是輸入資料的型態， b 是 parse tree 的型態。

根據 Parser a b 的型態規範，可以定義各式各樣的 parser 。例如：

永遠 parsed 的 parser 叫做 succeed

succeed :: Parser a ()
succeed xs = [((), xs)]

永遠 false-parsed 的 parser 叫做 fail

fail :: Parser a b
fail xs = []

讀取指定字元的 parser 叫做 lit (literal parser)

lit :: Eq a => a -> Parser a a
lit x (y:xs) | x == y = [(y, xs)]
lit x _ = []

執行情況：

lit 對字串 "Babcd" 要 parse 一個 `B' 字元，就得到一個 parsed `B'，並剩下 "abcd" 字串。

lit 對字串 "Aabcd" 要 parse 一個 `B' 字元， parse 失敗，於是得到一個 empty list [] 代表 false-parsed 。

(待續)