我的雲端生活網 - Life+

Monday, May 25, 2009

什麼是情境感知

以下翻譯 Jakob E. Bardram 在一篇文章 The Java Context Awareness Framework (JCAF) - A Service Infrastructure and Programming Framework for Context-Aware Applications 中,對「情境感知」所下的解釋。

JCAF 是在 2005 年發表這篇文章所介紹的情境感知基礎架構,用 Java 語言做開發及支援。本文介紹 JCAF 的設計原理、執行架構、程式介面。 API 包含了服務環境的組織、情境和情境集合的模型、情境事件的定義、以及情境的起動、監看、和轉換等等課題。 JCAF 已經應用於好幾種專案中。

以下翻譯的文章段落是
引用文獻



(自訂標題) 情境感知的定義

「情境感知式電腦運算」的概念是早先一些在「普遍運算」研究方面引介的概念之一。 (參考 20, 19, 及 8 號文獻) 並這些概念從那時就受限於既存在的其他研究。「情境」是談到電腦運算裝置所嵌入的實體或社會的處境。情境感知運算是要取得和運用與一架機器有關的這種情境,以提供適合特定環境的服務。例如,如果手機可以擁有關於它自己存在的位置、和參與活動方面的知識,當出席在音樂會裡,手機都會採震動方式。 (參考 16 號文獻)

Saturday, May 23, 2009

(翻譯) 寫程式:從「如何」到「什麼」

本文翻譯 C. J. Date 的 What Not How: The Business Rules Approach to Application Development 第一章,從 5 到 7 頁。原文參見: Google Book 條目

讀到本書這一段時,感覺非常特別:一方面是這個「搞資料庫的」作者在本書中好多地方,用特別的講法切中程式設計的中心概念,相當引人反思:例如,他說:「如果用 C 和 Java 這種 procedural 語言寫程式,是叫使用者幫忙把事情做好,而 declarative 語言則是叫系統幫自己做事情 (SQL 也算是 declarative 語言,但這一般是指像 Prolog 的邏輯風格的語言,或是像 LISP 和 CLIPS 這種函數風格的語言) 。程序就是安排使用者去走哪些他們該走的流程。宣告式語言則是只把自己的函數寫好並擺著,等使用者他們需要的時候過來呼叫,系統就會動起來。另一方面,這本在 2000 年出版的書籍,主題是 Business Rule ,內容卻提到要將過去寫程式的思考方式做一層翻新。書中又隱約透露出,在電腦程式設計中, declarative 風格的語言向來不佔一席之地,而許多數學家和電腦理論家都努力推動這種程式語言,以及推動它們的實務工作。


(自訂標題) 寫程式:從「如何」到「什麼」

於是,一以貫之,歷史的走向全然遠離程序式、而趨於宣告式,也就是從「如何」到「什麼」。「如何」就是逐步說明該如何做工作;「什麼」就是說明該做什麼工作。那麼,為什麼這種趨勢是個大好消息?答案是:宣告式 (什麼) 意思就是要系統做事;程序式 (如何) 意思則是要使用者進行工作。用一句話解釋,就是:

宣告式比程序式更好!

所以,如果我們能把全部我們的程式工作都用程序式的,不是很好嗎?這樣的需求已經很多很多年前就是大家的目標了。 (如果時間沒更早,大家已經遠從 1970 年開始談論關於「完全可編譯並可執行的規範書」了。) 換句話說,如果我們能簡單地明確規定我們的程式,並讓系統把這些規格編譯成可執行碼呢,不是很棒嗎?

好,我們往下走,如以下所見。

那好處非常明顯:當然是生產力。工作更容易也更簡單地完成了。而且跟著有許多附帶的利益,特別包含了各種的獨立性。有一種令人熟悉的獨立性是「資料獨立性」,它使我們改變 (舉例是為了效率因素而改變) 資料實際儲存在磁碟的方式,而不必做哪些對應的動作,改變用到這些資料的程式。也有許多其他種類的獨立性,其中有些,在本書後段還會看到。所有獨立性的好處是,那使程式對某種改變免疫,特別是對某種商務上的改變更是這樣。這是好事,因為,如果們所知:生命中惟有一件恆定的事,就是改變。

但是,程式到底是什麼?很顯然,程式是某件商務功能的實現:例如,「添入一項訂購物品資料」、「刪除一項訂購物品資料」、「修改某項料件的庫存數目」。一般是程式都牽涉到三種元件:
  1. 展現方面的元件
  2. 資料庫方面的元件
  3. 由商務功能本身定義出來的元件
展現方面的元件是必須處理終端使用者介面的元件,包括工作有幫使用者顯示表單、從使用者接收所填的資料、顯示錯誤訊息、產生列印的輸出等等。資料庫方面的元件應該做粹取和更新資料庫的資料,以因應使用者的請求,以及因應使用者在表單的填入資料 (那些表單是與資料庫 server 互動的部份,又稱為 DBMS 、資料庫管理系統) 。最後,稱為「由商務功能本身定義出來的元件」可能要想成是專屬於應用程式的;那些是指定做真正處理的程式,被做出來要實現商務函數,或是,換句話說是有效地實作商務策略和實行的程式。

現在,這三項之中,前二項已經在某些重要時刻大量地自動化了。程式開發人員不再寫細微的程式碼來處理螢幕繪圖,或找到螢幕上的表單修改之處──只是呼叫內建的展現服務來搞定那些工作。同樣地,他們也不必寫細瑣的程式碼來管理磁碟裡的資料。他們只是呼叫某些資料庫服務來做好那些工作。但是第三個元件呢,由商務功能本身定義出來的元件,那些東西還是大部份用手工做到,意味了有人還是照樣寫一大堆程序式的程式。而且,當然啦,那就是個毛病了 ...... 是把第三元件自動化的時刻了!而那真的就是全部與「商務規則」相關的事:把商務處理工作自動化。

接下來的做個像在信封背面做分析那樣的粗略計算,可能對提供我們所談論的重點的一些想法有所幫助。典型的資料表可能需要五頁相關的程序式程式;標準資料庫 (不大的資料庫) 可能包含 100 張資料表;好的程式刻工手可能每天可以產生一頁程式碼。淨額是: 500 人日 (譯註:人日是單位詞。《人月神話》也提到這樣的單位,將人力數目和工作時間的乘積當做計量單位。) 造就一套手工系統。相反地,簡單地規範定義同樣的系統,是五到六週的工作;而如果這些規範都可以執行,我們就有效地把開發時間減少一個級數 (譯註:級數, order of magnitude ,簡單說,是二個指數乘冪數值的差距:例如, 1000 比 100 多一個級數,因為 1000 是 10 自乘三次,而 100 是 10 自乘二次。)  。

Tuesday, May 19, 2009

imoo msn機器人即將支援 傳遞客製化表情符號

imoo msn機器人傳遞客製化msn表情符號測試是成功了,不過;真的要做進產品,也許;還需要考慮其他的部份 比如:怎麼做可以方便機器人的發送… 畢竟測試的版本要進產品還需要一些時間,但這星期確定會釋出這個功能

Thursday, May 14, 2009

在企業組織裡設計的挑戰

本文翻譯 Contextual Design 一書 (Amazon 記錄) 第 10 頁到第 16 頁 (Google Books 預覽): The Challenge For Design in Organizations 。

在書中,「設計」一詞幾乎都是指「開發資訊系統」。

標色文字是我的註解。


在企業組織裡設計的挑戰

誰能說一套系統將能做什麼?真是行銷部門或系統分析師說:「搞出這個」,就能教開發團隊只跟隨規格做事嗎?或者,行銷人員或分析師真的只要說:「弄出『這一類的』東西」,開發團隊其實決定做他們想要做的以及決定系統該是哪個樣子?事實上,兩方人馬都要擔任說明新系統是什麼長相的角色──在企業組織裡,建立一套系統是他們這些人合作的結果?

下層的問題無可逃避。今日的系統太大,很難教一個人做完。所以企業組織把規定和建立系統的流程分為幾個部份,把每個部份指派給一小群人。每群人又特定他們負責的部份,與其他處理其餘部份的人失去聯係。在開發系統的事情上,有四個問題該答,這些問題傾向於將開發流程自然分割。所以很容易指定一群人回答一個問題。問題有這些:「工作中有哪些事項」──該認定工作的哪幾個方面;「該如何應對」──團隊該用什麼系統做應對;「系統該如何架構」──到底有什麼功能、功能的規劃、以及系統架構,能適合工作的需要;以及「我們做得怎麼樣」──所設計的系統真的能為客戶服務嗎?

(「工作中有哪些事項」──該認定工作的哪幾個方面 )

頭一個問題 (「有哪些?」) 是問,有哪些客戶的工作活動是新系統該認定的,有哪些提議或問題該克服、有哪些角色和工作項目有必要支援。指定回答這個問題的那群人是行銷人員或商務分析人員。在管理工作會改變企業組織的時候,他們常下指令定義企業資訊系統有哪些是要項。他們說:「採購的費用太多了。給每個部門一張信用卡,只有授權才准使用」、或說「咱們的化學資料庫是咱們的命脈。把所有資料庫跟公司綁在一起。」或者,行銷部們可能會告誡工程團隊說:「設計一項產品支援公司的計劃。」或「讓產品放到網路上。」這些指令說了好多高層次的工作方面的事項,要系統能夠幫忙,卻沒有實際定義系統。把產品放到網路上,影響工作的哪方面呢?把資料庫都綁在一起,意思是一個資料庫呢、重複的資料庫呢、還是一種搜索許多資料庫的方法?在那些設定方向的觀點上,上述問題則是細節,他們不必回答這些小問題。

(「該如何應對」──團隊該用什麼系統做應對 )

回答這些小問題,意味要說要應付些什麼:公司將要如何回應這些有關系統設計、流程、服務、以及發行策略的議題。行銷人員可能是定義回應方式的參與者,但除了公司都是技術導向之外。需求分析人員可能也是參與者,但除了這些人真的太不懂技術了,就要是開發人員來做了之外。客戶自己應該要涉入內部系統,因為系統定義了他們要怎麼工作。行銷人員和分析人員可能要得到正式許可「發展系統規格」,但是依照經驗,他們不在必須寫程式的層面中定義系統的行為。「他們丟了一份規格給我,」開發人員都這樣對我們說。接著,「但是老是有太多我們要決定的事情,而他們通常只問我們那些不夠實際的事情。所以這個叫做交換意見。」

(「系統該如何架構」──到底有什麼功能、功能的規劃、以及系統架構,能適合工作的需要 )

決定要怎麼架構系統,意味要具體決定要納入什麼功能,具體上系統怎麼動,還有系統會怎麼顯現視窗、選單或畫面。這幾乎都是開發人員做的事,也表示他們要了解使用系統的工作環境。要不然他們不能做什麼對客戶好的決定。開發團隊無法從行銷人員或分析師手中拿到客戶資料。做出詳細的系統架構仰賴於額外一層的客戶資料,開發人員要自己拿到──或者是,自己做出感覺對的系統。有些公司又走得很遠,把開發團隊擺在與他們客戶和分析師有差別的地位,創造了一群專精在他們設計工作中的人力。但那只是弄得需要更多溝通,而且如果缺少車馬費,就造成更嚴重的孤立。

(「我們做得怎麼樣」──所設計的系統真的能為客戶服務嗎 )

最後一個設計的問題,說,「我們做得怎麼樣?」這個問題是和客戶核對系統的進度,確認它還是個對的系統,而且在細節層次改動程式不會讓系統變得不能用。這個問題經常分割出去給一組可用度研究團隊或品質保障團隊做測試。回答這個問題,是檢查系統本身 (看看 bug 和是否符合規格) 以及跟使用者一起測試系統。但無論哪方面,處理檢查結果都是開發者的工作。所以,他們必須接收回報訊息,還要了解它並相信它──那表示他們要買進取得回報訊息的程序,並且信任收集回報訊息的人。並且經常是,到目前為止都沒有真的取得實際資料做設計,在這個時候發現的缺陷都是很基本,他們在開發階段很難確實找到的。

這些定義系統該如何的不同部份,若系統設計程序要啟動,就要一起做。界定應對方案的人要能答覆真實的問題;建立系統的人要建構他們認同的應對方案。但是,要保持每個問題都分別由指定的人來處理,會造就組織之間的溝通難題。開發的正式文件掌握擬定的設計方案,也要盡力控制各群人馬之間的溝通和歧見。「你們簽了協議。表示你們承諾了。」「是,不過我們已經了解並且真的不需要。」或「是的,但是我們與這位重要客戶談過,若我們沒有碰上需要,就沒有必要出貨。」或「是,但是依現有的技術我們真的沒能力實作。」

組織裡的設計,與在各群人之間發展同一凝聚的方向有關:符合他們打算交付的公司應對方式。並不是永不改變,而是在改變時,整個企業組織在各種功能上可以適當地回應,而不是將改變轉換為兩方人馬的叫囂。反過來說,同一凝聚的願景仰賴於在公司應對方向的發展之間多加考慮不同的觀點。行銷和分析人員需要科技方面的展望,看見新系統種類的契機。開發人員需要行銷觀點來看清為什麼有些走向造就好產品,有些卻不能。又需要分析師的看法,看到他們要處理的工作要點。資訊科技團隊需要客戶的看法,確定自己提議的工作流程變更很合理而且可採用。在他們發展出公司的應對方式之後,他們可以同時有效地做事,並且不會迷失方向。但是,在突出的設計上,跨功能團隊做得最好。

實際環境中的工作團隊

建立跨功能團隊來做一同的設計會執行出真實企業組織裡某些意外的問題。想想一個基本問題:這樣的團隊要符合什麼期待?快速檢視大部份組織的實際結構,就發現他們都做到讓人們分開。最常見的開發工作環境是小方塊,是一塊夠大的一人空間,可以舒服地做事,有電腦和桌子。但是那個區域沒有大到可以讓幾個人一起舒服地工作,也沒有一塊大的隔牆空間讓一支團隊工作。當然另外有會議室,但會議室的特色就是只能預約並共用幾個小時。因為預約時間有限,能提供的工作只是短時間完成的事情,不超過半天。以超過標準的方式預約這個房間,同事的樣子會讓你擺臭臉。畢竟是在浪費一塊公用空間。不但如此,因為房間是共用的,你不能擺太多東西。每次對談要從頭開始,每次會議要重新攤開設計圖。

所以會議室支援的工作是在能短時間做好,而不需要實體支援的類型──不要硬體、不要圖表,沒有你不能捲起來帶著走的東西。也許有網路線,但要接上哪個區域網路呢?網路品質還不錯吧?接上筆記型電腦怎麼樣呢?有這些限制,會不會有開發人員和工程師覺得開會浪費時間呢?有標準規模的公司的實體架構明白地說,真正的工程都在小方塊裡做成的,而人都來到會議室則是他們沒有真在做事。企業的普通結構,沒有可以支援面對面溝通而能啟動系統設計的。

管理面對面的設計

一同有效地工作,意思是擁有在其中能真正工作的場所,讓許多人面對面地完成工作。也意味了賦與人們人際能力和流程,使他們的聚集比較有效。有一位部門主管指出一件棘手的問題,是在當地旅店訂房間讓五位資深架構師待著,並告訴他們,如果不在一週內提出解決方案,就要辭退他們。他得到結果,而我們發現如果人們有合理的工作過程,通常會比較快樂、有創造力,並且更快產生結果。對程序的典型回應是「感謝你,我現在終於知道該做什麼。」即使痛恨程序的人也會這麼說。

一起工作是一種新技能。是學校沒教的事,也是工作很少教的事。一起有效地工作,意味要懂得怎麼時常維持設計方面的對話,要怎麼用心到工作要項而不是其他事情上,要怎麼掌控每個人的特質,還有要怎麼發現並指出歧見的根本原因。如果團隊不這樣做,他們的工作就會因為人們處理歧見的模式與保持他們愉快的工作凝聚力之間的取決,而遭受損失。

人們處理歧見的一種主要的模式是政治交易:「我覺得你弄錯了。但是,如果你給我一些對我來說比較重要的東西,我就容得了你。」政治交易帶出一套以拼湊為主的系統,缺少具備向心力的主題。而且政治交易讓團隊的每個人都減少對設計工作投注心力,因為每一位都至少要認同一個人的決定,而他認為那個決定是錯的。

也有其他處理歧見的方法,但是大都不夠好。有一種方法是妥協,說:「你說我們要把什麼都做成對話方塊,但我覺得應該要做成按鈕才對。所以,兩種都做,我們誰都高興了。」誰都高興了,不過使用者不高興。他們有一打達到功能的辦法,但是沒有好的理由說明哪個辦法比較好。或者,會有教師式的歧見處理方式,說:「大師最聰明,而且什麼都懂。我們要跟著做大師所說的。」這很好,但除了在科技環境、圖形使用者介面設計、使用者實際工作、行銷、專案規劃、以及其他能力方面,這些絕對不錯的大師們所佔的人口數少到幾乎沒有。

情境設計 (Contextual Design) 規定一種發展系統的過程,可以帶出人際技能的價值。規定了根據資料來取捨各種開發選項,所參考的資料不包括爭議和政治交易。情境設計規定了人該扮演的角色,能在設計的過程中一直保持討論。不但要讓設計的過程比較有效率,還要因為人們爭議並沒有進展而將系統暫時擱到一邊。

前端系統設計讓我們著眼於人際的課題,因為設計程序的這一部份會帶來由面對面影響得很深的不一樣的功能。傳統的設計較不帶出著重在一起工作的技能。致力於保持客戶工作的凝聚力,而排除團隊中不同的看法和不同的能力,會使認知到如何一起工作變得很重要。我們發現,在人們該進行明確的流程、扮演明確的角色時,那時他們會對個人風格很敏感,使他們在房間裡起衝突。而當他們有具體的資料可以根據以設定決策,就會跨過隔籬,一起有效地工作。

這就是以客戶為中心的意義:不只做到客戶導向的設計,還要讓設計流程將系統帶往能讓客戶的工作──從開始到實作──能凝聚在系統中。對情境設計的挑戰是內建在方法中,要瞭解一同工作的要點,還要提供有效工作的辦法。

Wednesday, May 13, 2009

MSN換暱稱 相關行銷活動資訊

<AION封測。與你相約>將您的 MSN 暱稱更改為 "是我唯一的選擇!", 就有機會得到 CB 帳號哦!!
http://buboo.tw/msg/00a05b01a85d24c.html

王品msn步步大串連活動
http://www.wangsteak.com.tw/event/09_walk/fight_2_MSNatt.aspx

msn友達大募集
http://www.9inthebox.com.tw/campaign/event/200904/mem/index.php

設計的挑戰──在與客戶保持聯係方面

本文翻譯 Contextual Design 一書 (Amazon 記錄) 第 9 頁 (Google Books 預覽): The Challenge For Design - Keeping in Touch with the Customer 。

文中有下列角色:
設計團隊: design team ,就是開發人員。
開發人員: developers ,就是設計團隊或設計者。
企業: business ,就是客戶、提出需求和出資的公司。
資訊科技部門: IT department ,就是今日名上有「資訊」、「科技」等字眼的公司。
角色: role ,就是在資訊科技部門或企業中,有各種不同的職稱、做不同工作的人。


設計的挑戰──在與客戶保持聯係方面

如果從密切瞭解客戶方面出發、來做設計,是最基本的事,為什麼那麼難做到呢?產品開發公司發起的時候,他們創造了讓設計者與客戶分隔的組織方式。剛開始是要設計者由與潛在的客人對談,以幫助銷售。但是當公司成長了,就發展出銷售部門做應對客戶的介面;安插了操作代表 (account representative) 控制業務部門;安差了行銷和產品管理部門。這些走向使設計者甚至和銷售人員分隔了。剛開始是把設計者擺在客戶服務線上。但是當公司成長了,有一個完整部門搞定客戶服務任務,還有正規的介面對開發工作提出回饋意見。開發者被孤立,無法直接接到客戶回報他們工作的好壞。我們跟一些開發人員談過,他們與客戶之間真是孤立;在另一方面感到無力的是,因為覺得自己無法修正客戶發現的問題,他們甚至不想跟客戶談談。

資訊科技部門有一個不同的理由對駐留在客戶那邊感到有困難。在公司成長時,他們也是動輒與客戶分隔,但可行的不同方式都伴隨著問題而來。他們創造新角色──商務、系統、或需求分析人員──在客戶和開發者之間做翻譯,卻發現客戶仍相信資訊科技部門不了解他們的東西。其他的角色則不和客戶創造有密切工作關係,也不為了開發人員創造無阻礙的不干涉局面。

為了控制變動的需求,資訊科技部門做了收尾舉動,但是客戶的優先順序和需求還在改變。因此他們把開發人員安排在所服務支援的企業人員身邊,就可以就近影響企業的工作。他們弄好了客戶關係,卻意味了資訊科技部們不能分享資源和專業,也不能做為看穿整個企業資訊系統的關鍵角色。所以,他們決定他們太沒組織了,就把人都再拉回來,並重新導出了孤立的問題。

在資訊科技部門,這種震盪是個典型,但是終究錯失重點。任何對人的安排都跟著伴隨著問題,所以唯一的解決辦法是瞭解問題並加以處理。資訊科技部門需要和客戶保持一些距離,以看清不同部門之間造成的衝突,並規劃系統將企業視為整理來處理問題 (連同對系統出資的方式)。同時,他們需要讓他們和客戶保持密切夥同關係的機制。

以上就是情境設計 (Contextual Design) 的挑戰:要讓設計團隊明瞭他們的客戶,要給他們足夠的距離能以整體觀──能看透企業或看透一個市場──來看工作的實務。這個過程同時還要讓設計團隊徹底以「什麼是對客戶較實在」的知識做為基礎。

Tuesday, May 12, 2009

Erlang gen_server 行為解析

本文為翻譯 gen_server behaviour in Erlang (http://geeklair.net/~pratzsch/blog/2008/04/gen-server-behaviour-in-erlang.html)一篇.

授權聲明:本篇是由 Phil Ratzsch 發表於個人 blog 「你不愛讀的東西」(You dont't want to read this. http://geeklair.net/~pratzsch/blog/) ,文章發表於 2008 年 4 月 30 日晚間。我已透過電子郵件徵求取得作者許可,在此張貼翻譯版本。非常感謝 Philip Ratzsch 閣下。
Claim: This article by Phil Raztsch is posted in his blog "You dont' want to read this" in the evening at April 30, 2008. I've got the author's permission that allows me to post my translated version. I would like to convey thanks to Mr. Philip Ratzsch.

標色文字是我的註解。


Erlang gen_server 行為解析

本文由 Phil Ratzsch 於 2008 年 4 月 30 日晚間發表

你們有些自己在家玩些什麼 (我說:宅男嗎?) 的人都知道我有點喜歡 Erlang 全部的東西。對啊!你們一些在家玩自己的 (還有任性的衝浪人,也是) 、與歐洲的戶外隔離的人,可能想知道為什麼 behaviour 字裡躲著一個煩人的 u 字母。 Erlang 來自 Ericsson 公司 (他們公開否認 Erlang 和 Ericsson Language 一詞的關係,而說 Erlang 跟著一位同名數學家的名字定名) 而且 Ericsson 正好位於 Scandanavia 地區。 (據查:Scandanavia 是北歐包含丹麥、瑞典和挪威三國的區域)

語言家的理論說可以隨他們喜好、用 u 代替「 o 中間劃一線」字母。 (我說:那是一個丹麥文字母 Ф ,做母音有時音同 bird 或 hurt 、有時音同 sister 的 i 音。) 或是可能他們想表現出多麼愛那個空集合符號。不管這個,我們跳進 gen_server 話題吧。

gen_server 是 OTP ──「公開電傳平台」(Open Telecom Platform) ── 的一項元件。 OTP 可說是 Erlang 的一種應用程式架構。像 Python (蟒蛇) 有 Pylons (高壓電線架) ,以及 Ruby (寶石) 有 Rails (軌道或扶手) ,還有 Windows 有「當機的毛病」。 OTP 有強大威力,令人喜不自禁;而身為相當新手的我,只開始領會它有多強。引述 Joe Armstrong 寫的 "Programming Erlang" 書中字句:
OTP 的能力來自於一些特性,諸如容錯、可延伸能力、以及動態碼的更新等等,都由它的行為提供。也就是說,寫 callback 的程式人不用煩這些事情了,因為 OTP 行為會提供這些能力。
好的,菲利普,「行為」是指什麼呢?一件行為,就是像它聽起來像是的東西 ── 像一個桶子裝了一種系統或平台的全部普通行為。 (我說:這到底是什麼樣的直覺?)

舉一個很傳統的人為範例,假想一家錄影帶店只讓你一次買一部片。程式碼可能看起來像下列我收錄的。像上次一樣,先來個程式,再來個說明。我無限地感謝執行 CouchDB 專案的主持人 Jan Lehnardt 的幫助、耐心指導和友誼。將來不久,他也會貼一筆同樣主題的 plok 記錄,所以請務必去看一下,而且要給他錢。 (我說: plok 是很像 blog 的東西。)

-module(movie_store).
-behaviour(gen_server).

-export([init/1, handle_call/3, handle_cast/2, handle_info/2, terminate/2, code_change/3]).

-export([checkout/2, lookup/1, start_link/0]).

start_link() -> gen_server:start_link({local, ?MODULE}, ?MODULE, [], []).
checkout(Customer, Movie) -> gen_server:call(?MODULE, {checkout, Customer, Movie}).
lookup(Customer) -> gen_server:call(?MODULE, {lookup, Customer}).

init([]) ->
Tab = ets:new(?MODULE, []),
{ok, Tab}.

handle_call({checkout, Customer, Movie}, _From, Tab) ->
Response = case ets:lookup(Tab, Customer) of
[] ->
ets:insert(Tab, {Customer, Movie}),
{ok, Movie};
[{Customer, OtherMovie}] ->
{already_checked_out, OtherMovie}
end,
{reply, Response, Tab};

handle_call({lookup, Customer}, _From, Tab) ->
Reply = case ets:lookup(Tab, Customer) of
[{Customer, Movie}] ->
Movie;
[] ->
none
end,
{reply, Reply, Tab}.

handle_cast(_Msg, State) -> {noreply, State}.
handle_info(_Msg, State) -> {noreply, State}.
terminate(_Reason, _State) -> ok.
code_change(_OldVersion, State, _Extra) -> {ok, State}.

好,看起來很龐大 (順便地說,也是 Erlang 的超級威力) 但其實不是。第一行宣告了模組名稱 (而且 movie_store.erl 必須是檔名),這是 Erlang 每個程式都有的標準格式。

-behaviour(gen_server). 可想成是宣告我們程式裡用什麼「模版」。 gen_server 的行為要求我們要定義列在第一組匯出 (exports) 的函數。

-export([init/1, handle_call/3, handle_cast/2, handle_info/2, terminate/2, code_change/3]). 是 gen_server 匯出並尋找的函數 (,而且如果缺了他們,可會抱怨得很大聲喔) 。下篇文章我會探究它們、深入到細節 (我說:但他的下一篇文章,我不見得會譯完。) ,恰如這會是一篇長篇大作。現在,要曉得,就算這些函數都不做事情,也要定義這些函數全部。如你所見,尾端一些程式像 handle_cast/2 、 handle_info/2 、 terminate/2 、 code_change/3 ,都不做事情。

-export([checkout/2, lookup/1, start_link/0]). 製做自訂的函數,讓 server 可使用它們於外界。這些函數列在另一個 -export 敘述中,以資區別,或者也可以與前面的 -export 合併。

start_link() -> gen_server:start_link({local, ?MODULE}, ?MODULE, [], []).

程式的起點。如你所見,這個函數是 server 運作命令的包裝。{local, ?MODULE} 顯示 server 會以區域方式執行,並不會讓叢集系統的其他 Erlang 節點存取。 ?MODULE 是現有程式的替身,指示我們該用什麼東西參考這個 server 。第二個 ?MODULE 告訴 server 往哪裡找到 callback (在此例是同一個檔案) 。其他選項容許開啟除錯功能、做檔案記錄、以及其他未列入此例的項目。

checkout(Customer, Movie) -> gen_server:call(?MODULE, {checkout, Customer, Movie}).
lookup(Customer) -> gen_server:call(?MODULE, {lookup, Customer}).

這幾行聯繫自訂函數,告訴 gen_server 當 movie_store:checkout(...) 和 movie_store:lookup(...) 函數呼叫時能做什麼。 ?MODULE 指定函數所在的檔案和模組,而 {some_name, Arg1, Arg2, ...} 提供函數名稱和傳入的參數。
init([]) ->
Tab = ets:new(?MODULE, []),
{ok, Tab}.
用 ets 建立資料表並傳回。 ets 是內建的記憶體資料庫。在部署的程式中,這或許有時有些 ... 耐久。 gen_server 的關鍵元件是程式狀態。在本例中,你將看到 Tab 被丟來丟去,丟到每一樣程式單元中,表達現有的錄影帶店狀態 (誰購買了什麼片) 。
handle_call({checkout, Customer, Movie}, _From, Tab) ->
Response = case ets:lookup(Tab, Customer) of
[] ->
ets:insert(Tab, {Customer, Movie}),
{ok, Movie};
[{Customer, OtherMovie}] ->
{already_checked_out, OtherMovie}
end,
{reply, Response, Tab};
記得之前說的一點 gen_server:call(...) 嗎?這是 gen_server 呼叫的東西。你們可能想知道為什麼 handle_call 定義了二個函數,而且引用相同數量的參數 (參數數量表達為 /x ,如 "functioname/2" 裡面的 /2 ) 。看它第一個參數,是有三項的一列記錄。再看看

checkout(Customer, Movie) -> gen_server:call(?MODULE, {checkout, Customer, Movie}).

第一個項目符合樣式 (我說:指 {checkout, Customer, Movie} ) ,這是 gen_server 知道如何處理 handle_call 呼叫 ... 那個 ... 呼叫。嗯,最後一截用太多「處理」和「呼叫」的字眼了。重點是就像其他許多 Erlang 的東西一樣,以符合樣式為基礎。

注意一下, Tab 表格也傳入了。我們就進到一個 case/of 段落,檢查客戶在表格中有沒有購買了影片。如果沒找到記錄 ([] -> ...) ,片子就賣給他們,在此段落傳回 {ok, 影片名稱} 。如果已經有記錄,則傳回 {already_checked_out, 另一影片名稱} 並拒絕客人購買片子。 (注意,本例沒有讓客人退貨的辦法。這個留給讀者你自己練習。)

本段落任何一個情況都將傳回值塞進一列記錄,發射回給呼叫這個函數的人。在往下一個 handle_call(...) 走去之前,看一下最後一行: {reply, Response, Tab}; 。你可能期待有個句點而不是分號。 handle_call(...) 句子是用分號結尾,而且如果是改用像其他函數一樣的結尾。我好不容易才找到它的道理。 (我說:分號表示同一函數的兩套不同的定義之間的分界。)
handle_call({lookup, Customer}, _From, Tab) ->
Reply = case ets:lookup(Tab, Customer) of
[{Customer, Movie}] ->
Movie;
[] ->
none
end,
{reply, Reply, Tab}.
這個 handle_call/3 定義一個函數檢查看看客人有沒有購買了影片。如果有,傳回一筆記錄包含了客人和電影的名字。如果沒有,則傳回 none 。 (我說:重講一次,應該說是找得到一筆記錄符合 {Customer, Movie} 就傳回電影名稱,否則,如果找不到就傳回 none 。) 我不要講這個太多,因為以正在講的 handle_call/3 來說,這個東西太細。

handle_cast(_Msg, State) -> {noreply, State}.
handle_info(_Msg, State) -> {noreply, State}.
terminate(_Reason, _State) -> ok.
code_change(_OldVersion, State, _Extra) -> {ok, State}.

這段程式要擺在那邊,使 gen_server 能動;但這次我們沒用到它們。下一篇導引文章我會多談談。但我簡短說明: code_change/3 超酷,它讓 server 還在服務的時候可以將程式內容做熱抽換。要知道,想要改換程式何必麻煩讓 server 停掉呢,是吧?

最後,這是如何執行的示範:
2> c(movie_store).
{ok,movie_store}
3> movie_store:start_link().
{ok,<0.42.0>}
4> movie_store:checkout(phil, "Sneakers").
{ok,"Sneakers"}
5> movie_store:lookup(phil).
"Sneakers"
6> movie_store:checkout(phil, "Koyaanisqatsi").
{already_checked_out, "Sneakers"}
7> movie_store:lookup(phil).
"Sneakers"

(我說: 2 號命令是編譯 move_store.erl 。 3 號命令呼叫 movie_store:start_link(...) ,它轉呼叫 gen_server:start_link(...) 得到 {ok, <0.42.0>} ,表示命令完成,<0.42.0> 是 server 的程序代號。 Koyaanisqatsi (印地安語,意思是 life out of balance ,失衡的人生) 是一部藝術片,參考 IMDB 條目 (http://www.imdb.com/title/tt0085809/) 和 Wikipedia 條目 (http://en.wikipedia.org/wiki/Koyaanisqatsi) 可知道更多資訊。)

有個問題是程式在你試著選購 Koyaanisqatsi 時不會對你恭維幾句。嗯,我已經太煩人一整天了,至少希望你感興趣。如果你們要改就全都改,或者無論如何務必讓我知道。



建言:

Ulf Wiger 在 2008 年 5 月 1 日上午,說:

丹麥人和挪威人才用 o 中間砍一線,而瑞典人沒有這樣做。咱們都用 Ö 和 Ä ,很像德國人用的,但又多了很美的字母 Å 。對丹麥數學家致敬不代表分擔了使用 Ø 的原罪。 Erlang /OTP 團隊充斥著英國人,英文 behaviour 的拼字法可能源於那邊 ...

但不全沒有。若要建立自訂的行為, linter 接受 -behaviour() 和 -behavior() 兩種,還有 -behaviour_info() 和 -behavior_info() 。

還有,我聽說 Joe Armstrong (英格蘭人) 、 Mike Willams (威爾斯人) 、 Robert Virding 以前住在澳大利亞。

Harishi Mallipeddi 在 2008 年 5 月 2 日近午,說:

OTP Design Principles 一篇提供很有用 (至少對我來說) 的學習方法,學會用 OTP 的東西,包括 gen_server 、 gen_fsm 、其他等等。 Joe 的書可沒好好解釋 OTP 。

http://www.erlang.org/doc/design_principles/part_frame.html

Monday, May 11, 2009

(msn機器人)當RFID 遇見 愛慕MSN機器人

imoo msn機器人

詳細文章可見 http://www.ithome.com.tw/itadm/article.php?c=54654

IMOO MSN/GTALK 機器人研發團隊 針對企業及醫療產業提供優質的RFID整合MSN機器人加值應用解決方案,架構於綿密的產業網路脈絡上,分佈於複雜的產業供應鏈中,幫助各大產業快速整合現有IT系統資源,有效降低營運成本、徹底提昇管理效能,讓RFID系統整合加值應用為產業帶來真正簡單、實用、安全的智慧科技。
RFID企業應用解決方案-「全球化IP身份辨識管理」系統採用網際網路TCP/IP架構,支援全球化Web Service應用,透過與總部ERP/HIS等後端系統連接,整合MSN訊息通知平台,將相關事件通知隨著使用者服務到全球,並配合智慧型PDA手機達成遠端控管及通知。全系統採用集權分層式管理,簡單又快速的將人、卡、設備的權限管理彙整於同一套系統中,透過網路進行無國界線上即時管理,快速整合後台(門禁/差勤/視訊對講/影印列印漫遊/電子錢包…等)其他應用需求,讓「人」的管理變的很簡單。

Blog Archive