我的雲端生活網 - Life+

Wednesday, December 30, 2009

我要公開感謝你們,你們才是最棒的~~

Dear ALL:

這話其實很八股,但;如果沒有各位的努力微程式無法躲過客戶
無情的砲火,無法打好在商業場上的戰爭,而我沒辦法在各主管
面前臉上有光,這一切只因為你們努力而有所收穫,你們犧牲自
己無價的光陰 聰慧的大腦...成就團體的榮耀,我為大家這一年
的辛勞,感謝大家

我們在未來的一年,會有新的挑戰等著試煉各位灼熱的熱情,
體部在新的一年來臨會有一些改變,我希望有機會協助各位打
造更好的工作環境而努力,記得~~別忘了留一點(呼)呼聲給我,
不管是掌聲或噓聲我都樂於接受,也預祝新年佳節愉快,衷心真
誠的感激各位...這裡當然也包含了imoo團隊裡的夥伴與摯友

Luke.

???我有好多疑問???是思考?還是想太多 ?

最近在讀Peopleware 腦力密集產業的人才管理之道;這本書籍,裡面有蠻
多有趣觀點,值得一讀;不過總是會思考文中提到的一些問題有些疑惑

文中提到 一些粗略的數據,<簡單的描述我的疑問>---文章有一章節(在空
間上省錢) 他們證明表現好的員工通常有較大的工作空間,透過競賽(可能
是不同公司),之後蒐集每個人的相關環境數據(使用空間 環境噪音 電話的
因素...) , 最後得到的結論是 表現最好的前1/4 通常有比較大的使用空間,
工作的干擾因素通常也是最低的...

這樣的結論有點怪; 因為我們可以反過來思考; 有沒有可能因為這些工作
者因為特別努力,所以通常會得到公司比較多的資源與自主(有獨立的辦事
室 可以選擇隱蔽的空間...)? 通常表現較優的工作者,對於工作的投入也比
較熱情專注,所以;對於那些干擾因素的容忍度比較高? 而且這個結果本身
有點自相矛盾,如果這個結論是對的,所有優秀前1/4 的員工會集中再某個
特定的公司,因為給員工較大的空間如果是統一的公司政策,那麼同一公司
參賽的人工作空間一定都很大,所以結果一定不會是表現好的前1/4分散在
不同的公司,不是嗎?

我不知道是不是學科學的人都對 不同觀點得到不同的結論,這樣的結果覺
得科學?簡單的說一直不太懂管理這們學問 科學嗎? 量化? 量化的意義是
什麼? 如果量化無法反應抽離 不同觀點 所造成 的不同結果,量化的意義是
什麼?


Monday, December 28, 2009

預祝各位在即將到來的2010年新年快樂

這一年大家辛苦囉~
預祝各位在即將到來的2010年新年快樂!
 
 

Erlang 叫用外部程式很簡單

多行程程式是 Erlang 語言的一項重要特色。而許多時候需要叫用外部程式, Erlang 的程式寫法也表現得很優秀。

由於標榜 Concurrency-Oriented Programming , Erlang 讓開發者將每一個函數視為行程。行程要與其他行程溝通,必須藉由拋接訊息來表示請求或回應。 Erlang 程式的訊息介面與 ! (send) 和 receive 兩個關鍵字有關。而外部程式的訊息介面,則稱為 port 。 Erlang 對 port 送訊息給外部程式,也從 port 接收外部程式來的訊息。 Erlang 的 open_port/2 提供了外部程式叫用的功能,並且提供了外部程式的 port 設定方式。例如:

Port1 = open_port( {spawn, simple_work}, [in, out, use_stdio] )

以上 port 的選項, in 容許 simple_work 外部程式可以從 port 接受輸入訊息, out 容許外部程式可以從 port 輸出訊息, use_stdio 指定外部程式的標準輸入和輸出分別對應為 port 輸入和 port 輸出。 simple_work 可能是以下 perl 程式:

#!/usr/bin/perl -w
# simple_work program
my $buffer;
$buffer = readline STDIN;
print $buffer

Erlang port_command/2 可以指定 port 並送訊息。例如:

port_command(Port1, "hello!\n")

simple_work 送出 port 的訊息, Erlang 程式要用 receive 接受訊息,收到的訊息格式依 open_port/2 的選項決定。

參考資料

Sunday, December 27, 2009

劍客其實不擅長刀法

在這個 blog 應該是不太適合談msn機器人以外的事務 ,不過這幾天我
有感而發,突然想講一個故事 ,不管你認不認識我 ,不管你是不是跟我一
起努力打拼的夥伴 ,不管你喜不喜歡我說故事風格,不管你是不是想給我
一些噓聲或掌聲 ,也許你會嗤之以鼻 ,也許你會會心一笑 ,總之不管如
何 ,這個故事正要開始

以前一個朋友問我一個問題,他問,你喜歡刀還是劍? 這問題讓我思考了很
久 ,我在想; 刀與劍哪裡不同? 想了很久沒有答案(你可以上網找到類似
這類的圖片http://blog.sina.com.cn/s/blog_4a1b8858010005i8.html)
,這讓我想起了另一個故事 ,一群劍客裡有一個劍法精湛的劍客 ,在相同
資歷的劍客裡他總是能輕易的擊敗對手 ,很多高手名流遇到他總是甘拜下風
,但這個劍客有一個習慣,他總是喜歡跟其他的劍客聊到刀客的刀法 ,說那
個刀客的刀法過慢 說這個刀客遇事只攻不守 ,成不了大氣,尤其是他喜歡
問他的劍客友人 ,某個刀客對他的評論是不是公平...,一天 ;他與自己劍
友聊到類似的事情 ,這個同好恰好有事無法久留,但 ;給了一個建議 ,約好
明天一早上山與某位高僧一起繼續這個話題

第二天 ;劍客依約上山找了老和尚 ,老和尚第一句話就說; 久聞施主是一
個毫無自信之人 ,劍客大驚 ;連忙詢問 ,何以見得? 老和尚端坐一旁不急
不徐的說; 眾知施主的劍藝高超, 但卻常評斷刀客刀法拙劣, 正是尋求外
援以解自我空虛之徵 ,探尋其他刀客對自己的評論是否公平 ,正是自信不
足之兆;劍客下山後從此不再向外尋求解答 ;勤鍊刀法 ,往後10年成為一
代宗師

這故事應該有一些啟示 ;顯而易見的是;他思考過這個老和尚說話的意思 ,
而不執著於刀與劍的關係,因為如果下山後再去問朋友自己是不是常常在意
外人對自己的評論? 恰好正中下懷 ,所以及時反求諸己 ,然而真實的世界
裡 ,我們很少思考一件事的全貌 ,劍客應該勤鍊劍法 ,刀法的優劣與劍客
無關 ,但如果要向另一個層次突圍 ,需要熟悉刀法的優點勤練刀法 ,如此
才能融合多方優點成為一代宗師 ,能夠把別人的武器運用自如 ,劍客就會
變成刀客最後變成宗師 ,不管是故事裡故事外道理都是相通的 ;這故事本
身也許是一種武器 ,但要看拿在誰的手裡 ,巧妙各不同 ;而說故事總要有
一些啟發作用 ,至於是不是有啟發的效果 ,可能還需要多一點思考的空間
與慧根了

Sunday, December 13, 2009

WebGL規格草稿釋出

很久以前網頁上做3D就是VRML了。最近有WebGL釋出,是OpenGL管理社群與瀏覽器開發組織的協議產物。WebGL規格書(https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/WebGL-spec.html) 可見到一些程式介面。WebGL容許開發者用JavaScript在網頁上畫圖了嗎?

我的第一個疑問是,用JavaScript在網頁上畫圖,是否會讓一些繪圖程式無法不公開?或者,為了讓繪圖程式不公開,要做更多程式混亂工程(code obscurity)?不過通常不要太依賴弄亂程式碼來確保一些安全比較好,這種安全是不穩定的,可見相關討論: http://www.owasp.org/index.php/Avoid_security_by_obscurity

Monday, December 7, 2009

自然語言處理

資料統計方式的文件翻譯

2009年三月 Google 的 Alon Halevy 等人放出一篇通俗的文章,題名為 The Unreasonable Effectiveness of Data ,說明了用資料統計方法處理文章翻譯的好處。

他們提到,即使 Eugene 撰文 The Unreasonable Effectiveness of Mathematics in the Natural Sciences 說明物理學學者怎麼都愛用數學式做優雅的表達,但是碰到英文翻譯就不一定都有好處,好比經濟學家用數學也不好處理人文社會的情況。 Google 處理大量的網頁資料,他們的資料庫 (corpus) 特別沒有規矩,存在許多拼字錯誤、用法錯誤、甚至有造假文字。但是他們能用統計方法,處理這些網頁資料,得到他們要的翻譯。

所謂翻譯,是指處理文件及資料。翻譯是自然語言處理的其中一種應用,其他有語源分析、資訊萃取等等。翻譯文件是人們大量使用的應用方式,所以在網路上有各種文件的各種語言版本,不需要多少人力處理。而專用於傳統語言處理的語料庫 (corpus) 則需要相當大量的人力,做語法、語意的定義工作。所以,傳統自然語言處理方法的語料整理工夫已消耗太多人力。然而,考慮到文件翻譯,網路上已經存在許多可用的語料庫了,應絯善用這些網路資料。

在網路文件的錯誤方面,雖然在百萬級 (million) 資料量中,文件中存在的錯誤可能有影響,但是當語料庫數量達到十億級 (billion) 甚至兆級 (trillion) 數量,文件錯誤佔了相對更少的比例。使用統計式的自然語言處理可以收到自然的正確結果。 MapReduce 恰好非常適用於統計式翻譯。

統計式翻譯方法的缺點是,無法糾正來源的語料庫存在的錯誤,也不容易對抗一些造假的事實。不過,翻譯工作只需要把一個文件變成另一種語言版本,而不是要做推理。

語言的組合性

在語言學中,自然語意的解釋,是指有用一種後設語言 (meta-language) 處理某一種目標語言 (object-language) 的句子意思。例如,用英文解釋波蘭文句子的意思,波蘭文是目標語言,英文則是後設語言。按照這種思維,電腦程式語言是哪個層次的語言呢?

回到語言理論,Allan Keith的書 Natural Language Semantics 提到傳統語言處理。語言是由許多單字組成,而單字的意義是可以組合的。句子或片語的意思可以由所構成單字的意思組成。 Allan James 的書 Natural language understanding 也提到,語言處理在應用上可分為幾個類型,其中一種是將語言應用系統做為問答系統,另一種是將語言系統做為用語言發送指令。我想,採用複雜事件處理的概念,或許可以將一個句子的每個單字當做是各別到達的事件,我們對句子做複雜事件的偵測,把一些關鍵詞的意思抓出來,根據每個關鍵詞的前後順序決定這個句子對應成什麼意思、代表什麼指令,然後對系統發出指令。

自然語言句子做為指令的系統,實作上的基本優勢是:雖然自然語言理論上有無窮數量的語料庫,但電腦系統接受的指令是有限的,所以自然語言對應到電腦的句子語料庫少了很多。至少這是可慶幸的。

Thursday, December 3, 2009

程式風格與系統實作

有個著名的99題程式問題集中有二件基本問題:
  1. 反轉一列資料。
  2. 檢查一列資料是不是回文。
用 Erlang 寫,程式如下:

reverse( [ ] ) -> [ ] ;
reverse( [ X | Y ] ) -> reverse( Y ) ++ [ X ] .

palindrome( Xs ) -> reverse( Xs ) == Xs.

這些問題主要是在考邏輯程式語言或函數程式語言解決問題的方法,用 Erlang 寫非常自然。至於考慮到用指令式程式語言,程式會怎麼寫呢?先想想 C 程式。
void reverse(char *x, int xn, char *y, int yn) {
    int i;
    yn = xn;
    for(i=0; i<xn/2+1; i++) {
        y[i] = x[xn-1-i];
        y[yn-1-i] = x[i];
    }
}

main() {
    char a[] = {'a', 'b', 'c', 'd', 'e'};
    char b[] = {'1', '1', '1', '1', '1'};
    reverse(a, 5, b, 5);
}
以上程式是反轉一列資料。至於檢查是不是回文,與反轉一列資料有相當的程式結構。所以,照著反轉程式結構可以改出檢查回文的程式。

/* void reverse */ int is_palindrome(char *x, int xn /* , char *y, int yn */ ) {
    int i;
    // yn = xn;
    int result = TRUE;
    for(i=0; i<xn/2+1; i++) {
        // y[i] = x[xn-1-i];
        result &= (x[i] == x[xn-1-i]);
        // y[yn-1-i] = x[i];
    }
    return result;
}

Erlang 程式和 C 程式各自從掌握的不同邏輯意思解決問題。對 Erlang 程式來說,一列資料是回文隱含了將這一列資料反轉會和原資料相同。對 C 程式來說,是考慮到一列資料若是回文,資料每一項在前半段位置的,會和在後半段鏡射位置的資料相同。所以,用 C 寫以上程式,一定要把以上二個程式寫成一樣的結構,因為它們的順序邏輯一樣。但是用 Erlang 寫程式,則可以說是反轉資料問題是檢查回文問題的子問題。不同的語言有各自解決問題的能力。用 C 的程式風格思考, Erlang 真不好寫;並且用 Erlang 的程式風格思考, C 也不好寫。不過,只要用 Erlang 的方式寫 Erlang 程式,用 C 的方式寫 C 程式,都是做對事情了。

所以,本篇文題回到系統實作方面:本來我有個系統是用 Perl 規則持續讀檔案,用檔案時間判斷是否有新的 RFID reader 讀數出現。系統中存在大量這種類型的 Perl 規則,並且反覆判讀檔案消耗大量時間。我可以用 MapReduce 來節省工作時間嗎? MapReduce 本身就是前車之鑑。

在有大量資料需要處理的分散系統上,要直接寫程式,不管是什麼檔案鎖定、程序鎖定、或是信號的控制機制,最後都是普通的程式處理方式:把大量資料塞進一個迴圈裏。 MapReduce 是個漂亮的程式作法,它的思考方向是程式有多少等級的數量,程式也產生出多少等級數量的程序,讓每個程序分配到相當少量的工作,許多程序一起做!所以,前後二種處理方法,在程式的寫法上相當不同。直接的程式,想法依然直接。但是,實作 MapReduce 是先做一個計算框架,框架中有二種空位存放 map 和 reduce 二種類型的程式;而中樞設計不要思考 map 和 reduce 程式可能怎麼寫,而是只思考把一些程序分配去執行 map 程式、另一些程序分配去執行 reduce 程式,並且這些程序如果中斷但沒做完工作,就再分配一次同樣的工作。於是,剩下的工作是 map 和 reduce 程式都比較好寫,而且寫完並套進 MapReduce 架構之後,就可以處理大量的資料。同樣的問題處理,可以用不同的程式方法解決問題。

依我看,現有系統的規則,只有檢查新 reader 讀數的規則可以保留,直接寫成 map 程式。

rfid_read ( File, Reads ) :
    for each (Tag_ID, Reader_ID, Time) in Recent(Reads)
        emit( (observation, (Tag_ID, Reader_ID, Time)) )

然後交給其他的 reduce 程式處理。至於其他類型的規則,則要按照 MapReduce 的思維改寫成適當的 map 程式或 reduce 程式比較好。

Blog Archive