每個人在年底,都該更新整理一下自己的履歷表。藉這個機會,回顧過去一年來做了哪些值得一提的事、有哪些學習收穫。
就像公司作帳一樣,要有兩本帳簿,外帳是給外面看的,內帳是給自己看的。履歷表也有兩份,「外履」給外面看,「內履」給自己看。
在內履中,多了一些項目,說明自己做過哪些壞事,遭遇過哪些挫折失敗,這些讓你懊悔的事情是怎麼造成的,你要如何避免以後再次發生。如果你識人不明,你更是必須將原委記錄下來,用紅色的粗體字標示,好提醒你,來年不要再犯這種錯誤。
如果在整理「內履」的時候發現,今年讓你絆倒的石頭,過去曾經出現過,那麼你應該狠狠地賞自己一個巴掌,對著鏡子痛斥自己:『你怎麼能讓這樣的事發生兩次?你為什麼沒有學到教訓?』
然後你將內履檔案用AES加密,放在某個隱匿的檔案夾內,再將外履加到某個草稿郵件的附件中。你希望不需要很快寄出這份郵件!
2008年12月30日星期二
為什麼要學程式設計?
曾經有一個人這麼問過我,當時我怔住了,答不出來。回家後好好思考,歸納出這樣的答案。
簡單地回答:「因為你值得!」
複雜的回答:請看下面這篇文章…
家家戶戶都有電腦,我們越來越依賴電腦,用電腦處理許多事。你可以用別人開發好的軟體來做這些事,但是如果你想做某件事,卻找不到適合的程式時,該怎麼辦?
就自己寫一個呀!
其實只要挑對編程語言,編寫程式一點都不難,而且寫程式的過程可以帶來樂趣、培養邏輯能力、當程式大功告成時,則會有很強烈的成就感。這就是我喜歡寫程式,而且從來不厭倦的原因。
【小朋友學程式設計】
當我讀小學時,我就開始寫程式了,至今約27年了。小朋友是最適合學習程式設計的。
古代的小朋友寫書法,來磨練耐心和定力;現代的小朋友則是寫程式來達到一樣的效果。而且寫程式還比寫書法多了訓練邏輯能力的功效。現在就扔掉毛筆,拿起滑鼠!
【男人學程式設計】
好吧!我承認,大人想透過學習程式設計,來鍛鍊邏輯能力的效果,其實不佳,因為這部分的腦袋已經定型了,所以無法利用寫程式來避免被政治人物邏輯不通的言詞所蠱惑、擺佈。
那麼,男人為何要學程式設計?
因為可以「強精補血」。如果不寫程式,就會去花天酒地傷身又浪費錢,看電視吃洋芋片又會讓原本大腦就不發達的男人大腦更加萎縮,學美國男人在後院DIY家具或修理機械又太花力氣。還是寫程式比較好,可以減少身體受傷害。
【女人學程式設計】
我很想說,「寫程式可以美容養顏」之類的話,但是我看過一些女性程式設計師的皮膚,「顯然都黯淡蠟黃得厲害」,證實寫程式並無美容養顏的功效。
但是沒人規定你不可能一邊寫程式一邊用面膜敷臉。上次我就在上海回北京的飛機上看到一個女士利用搭飛機的時間旁若無人地敷臉,台灣也出過一則新聞,一個女生在騎機車時敷臉。
就別再扯敷臉的事了,言歸正傳。為什麼女人要學程式設計?因為沒有明顯的壞處。其實,寫程式的圈子向來陽盛陰衰,女生的比例可能不到十分之一,我希望能多一些女生加入。
【老人學程式設計】
很多人在退休之後,老化得快,特別是大腦。專家證實,多用腦可以避免阿茲海默症(老人癡呆症)。阿茲海默症主要原因是大腦皮質神經原細胞退化所造成,罹患此症的病人大都是老人,且女性多於男性。醫師建議「多用腦」,可以預防阿茲海默症。
一般醫生對於這裡所謂的「多用腦」,都是建議打麻將、橋牌、下棋等活動。我認為寫程式是更好的方法,而且可以一個人完成,不需要有牌友,也不會也輸錢的壓力。
『為什麼要學程式設計?』下次要是有人再問起我這個問題,我想我知道該怎麼回答了。
簡單地回答:「因為你值得!」
複雜的回答:請看下面這篇文章…
家家戶戶都有電腦,我們越來越依賴電腦,用電腦處理許多事。你可以用別人開發好的軟體來做這些事,但是如果你想做某件事,卻找不到適合的程式時,該怎麼辦?
就自己寫一個呀!
其實只要挑對編程語言,編寫程式一點都不難,而且寫程式的過程可以帶來樂趣、培養邏輯能力、當程式大功告成時,則會有很強烈的成就感。這就是我喜歡寫程式,而且從來不厭倦的原因。
【小朋友學程式設計】
當我讀小學時,我就開始寫程式了,至今約27年了。小朋友是最適合學習程式設計的。
古代的小朋友寫書法,來磨練耐心和定力;現代的小朋友則是寫程式來達到一樣的效果。而且寫程式還比寫書法多了訓練邏輯能力的功效。現在就扔掉毛筆,拿起滑鼠!
【男人學程式設計】
好吧!我承認,大人想透過學習程式設計,來鍛鍊邏輯能力的效果,其實不佳,因為這部分的腦袋已經定型了,所以無法利用寫程式來避免被政治人物邏輯不通的言詞所蠱惑、擺佈。
那麼,男人為何要學程式設計?
因為可以「強精補血」。如果不寫程式,就會去花天酒地傷身又浪費錢,看電視吃洋芋片又會讓原本大腦就不發達的男人大腦更加萎縮,學美國男人在後院DIY家具或修理機械又太花力氣。還是寫程式比較好,可以減少身體受傷害。
【女人學程式設計】
我很想說,「寫程式可以美容養顏」之類的話,但是我看過一些女性程式設計師的皮膚,「顯然都黯淡蠟黃得厲害」,證實寫程式並無美容養顏的功效。
但是沒人規定你不可能一邊寫程式一邊用面膜敷臉。上次我就在上海回北京的飛機上看到一個女士利用搭飛機的時間旁若無人地敷臉,台灣也出過一則新聞,一個女生在騎機車時敷臉。
就別再扯敷臉的事了,言歸正傳。為什麼女人要學程式設計?因為沒有明顯的壞處。其實,寫程式的圈子向來陽盛陰衰,女生的比例可能不到十分之一,我希望能多一些女生加入。
【老人學程式設計】
很多人在退休之後,老化得快,特別是大腦。專家證實,多用腦可以避免阿茲海默症(老人癡呆症)。阿茲海默症主要原因是大腦皮質神經原細胞退化所造成,罹患此症的病人大都是老人,且女性多於男性。醫師建議「多用腦」,可以預防阿茲海默症。
一般醫生對於這裡所謂的「多用腦」,都是建議打麻將、橋牌、下棋等活動。我認為寫程式是更好的方法,而且可以一個人完成,不需要有牌友,也不會也輸錢的壓力。
『為什麼要學程式設計?』下次要是有人再問起我這個問題,我想我知道該怎麼回答了。
Code Review
最近因為工作需要,寫了一個編譯器(Compiler)。由於輸出格式是二進位的(binary),且檔案內部相互關連與參考,所以很複雜。我寫出來的這個程式有嚴重的bug。
這個程式是用「腳本語言」(scripting language)所編寫的,而腳本語言的debug難度本來就比較高,加上我所使用的腳本語言(REBOL)沒有IDE(Integrated Development Environment),所以我只能用很克難的方式進行debug。大多數的時候,我是在進行Code Review。
我花了很久的時間,只有找到一小部分的錯誤,我發現:程序的作者本人進行Code Review,效益很差,應該由其他人進行Code Review(Offline Pair Programming?),這樣才比較容易找出癥結。昨天我將我的程式解釋給其他人聽,然後很快就又陸續找出一些問題,今天我一一對這些問題進行修正。
如果寫程式遇到瓶頸,且一段時間之後還走不出瓶頸時,應該去休息放鬆一下,或者找其他人幫你進行Code Review,問題或許就可以解決。
這個程式是用「腳本語言」(scripting language)所編寫的,而腳本語言的debug難度本來就比較高,加上我所使用的腳本語言(REBOL)沒有IDE(Integrated Development Environment),所以我只能用很克難的方式進行debug。大多數的時候,我是在進行Code Review。
我花了很久的時間,只有找到一小部分的錯誤,我發現:程序的作者本人進行Code Review,效益很差,應該由其他人進行Code Review(Offline Pair Programming?),這樣才比較容易找出癥結。昨天我將我的程式解釋給其他人聽,然後很快就又陸續找出一些問題,今天我一一對這些問題進行修正。
如果寫程式遇到瓶頸,且一段時間之後還走不出瓶頸時,應該去休息放鬆一下,或者找其他人幫你進行Code Review,問題或許就可以解決。
2008年12月29日星期一
小鏞的北京故事(一)
忠秧電視台「人與社會」欄目,今天播出的是:小鏞的北京故事(一)
《旁白》
當記者第一次發現小鏞的時候,正值北京十二月底的寒冬。他正蜷縮在街角的一隅,一頁一頁地撕著世界文學名著《Java夜未眠》,扔進火爐中燃燒取暖,就像安徒生童話中賣火柴的小女孩一樣。記者靠近他時,他的眼神露出一絲恐懼。
《╱旁白》
記者:『這位先生,你怎麼這麼冷還在街頭?』
小鏞:『...』
記者:『你有家可以回嗎?』
小鏞:『...』
《旁白》
不管記者怎麼追問,他就是不說話,但從他細嫩的皮膚與玉米鬚的時尚髮型中,記者判斷,他絕非長期流浪街頭的人。他的背後到底有著什麼樣的故事呢?經過記者鍥而不捨的努力,我們終於知道他的身世之謎。
《╱旁白》
《旁白》
原來,他是《Java夜未眠》這本書的作者,也是一個程式高手,半年前從台灣到北京的一家軟件公司上班,位居要職。生活雖然有一些小問題,但大致上仍然平順,直到一個星期前…
《╱旁白》
(辦公室場景)
小鏞:「這邊要這樣子作,那邊要那樣子作」
屬下:「好的!是的!英明!高見!」
《旁白》
這時忽然傳來一陣爭執聲,小鏞和下屬不約而同地把目光投向會議室。大家的心中有著同樣的疑問:倒底發生了什麼事呢?
《╱旁白》
《旁白》
當記者第一次發現小鏞的時候,正值北京十二月底的寒冬。他正蜷縮在街角的一隅,一頁一頁地撕著世界文學名著《Java夜未眠》,扔進火爐中燃燒取暖,就像安徒生童話中賣火柴的小女孩一樣。記者靠近他時,他的眼神露出一絲恐懼。
《╱旁白》
記者:『這位先生,你怎麼這麼冷還在街頭?』
小鏞:『...』
記者:『你有家可以回嗎?』
小鏞:『...』
《旁白》
不管記者怎麼追問,他就是不說話,但從他細嫩的皮膚與玉米鬚的時尚髮型中,記者判斷,他絕非長期流浪街頭的人。他的背後到底有著什麼樣的故事呢?經過記者鍥而不捨的努力,我們終於知道他的身世之謎。
《╱旁白》
《旁白》
原來,他是《Java夜未眠》這本書的作者,也是一個程式高手,半年前從台灣到北京的一家軟件公司上班,位居要職。生活雖然有一些小問題,但大致上仍然平順,直到一個星期前…
《╱旁白》
(辦公室場景)
小鏞:「這邊要這樣子作,那邊要那樣子作」
屬下:「好的!是的!英明!高見!」
《旁白》
這時忽然傳來一陣爭執聲,小鏞和下屬不約而同地把目光投向會議室。大家的心中有著同樣的疑問:倒底發生了什麼事呢?
《╱旁白》
內與外
有些東西,外表看起來很好,骨子裡卻不見得是這麼一回事,你會不想知道它們是如何被製造出來的。例如香腸和法律。
香腸我就不說了,就談談法律吧!法律和政府的施政,表面上冠冕堂皇,其實內在卻可能是官商勾結,圖利自肥,利益交換的結果,甚至可能是在燈紅酒綠、杯杛交錯、鶯鶯燕燕的環境中協商出來的。看看咱們台灣的「二次金改」,我們現在才終於明白,原來當時的理由都是謊話,一切只是為了私自的利益。
除了香腸和法律,許多程序也是一樣內外有別。外表畫面整齊,內在架構凌亂;外表配色鮮豔,內在變數名稱亂取,沒有內縮對齊;外表寫了豐富的使用手冊,內在找不到任何註解。
我擔任過好一陣子的IT講師,我相當講究程式碼的美觀,所以如果我看到亂七八糟的程式碼,我就會把寫這個程式的人數落一頓。被我數落的程式員難過地問我:「你是不是覺得我的變數名稱都取得很差?」我反過來安慰他:「不會呀!你的迴圈變數用i,我覺得i取得很不錯」…但這顯然沒有安慰的效果。
看過一篇文章,一個女性平時外在都打扮得相當好看,但是卻不注重內衣。有一天她終於和男友在情不自禁的時機想做一件事的時候,忽然想起今天穿的是泛黃、有破洞、且彈性不佳而鬆垮垮的內衣,於是頓時貞潔了起來,不肯脫掉外衣。
總之,「內與外是兩回事」,當你看到美好的外在,不要假設它也有美好的內在;同樣地,醜陋的外在並不代表就是醜陋的內在。你瞧,外在柔弱的吳淑珍多剽悍呀!我每次看到新聞報導說她揚言要殺了誰,我就會冷不防地打個哆嗦。
香腸我就不說了,就談談法律吧!法律和政府的施政,表面上冠冕堂皇,其實內在卻可能是官商勾結,圖利自肥,利益交換的結果,甚至可能是在燈紅酒綠、杯杛交錯、鶯鶯燕燕的環境中協商出來的。看看咱們台灣的「二次金改」,我們現在才終於明白,原來當時的理由都是謊話,一切只是為了私自的利益。
除了香腸和法律,許多程序也是一樣內外有別。外表畫面整齊,內在架構凌亂;外表配色鮮豔,內在變數名稱亂取,沒有內縮對齊;外表寫了豐富的使用手冊,內在找不到任何註解。
我擔任過好一陣子的IT講師,我相當講究程式碼的美觀,所以如果我看到亂七八糟的程式碼,我就會把寫這個程式的人數落一頓。被我數落的程式員難過地問我:「你是不是覺得我的變數名稱都取得很差?」我反過來安慰他:「不會呀!你的迴圈變數用i,我覺得i取得很不錯」…但這顯然沒有安慰的效果。
看過一篇文章,一個女性平時外在都打扮得相當好看,但是卻不注重內衣。有一天她終於和男友在情不自禁的時機想做一件事的時候,忽然想起今天穿的是泛黃、有破洞、且彈性不佳而鬆垮垮的內衣,於是頓時貞潔了起來,不肯脫掉外衣。
總之,「內與外是兩回事」,當你看到美好的外在,不要假設它也有美好的內在;同樣地,醜陋的外在並不代表就是醜陋的內在。你瞧,外在柔弱的吳淑珍多剽悍呀!我每次看到新聞報導說她揚言要殺了誰,我就會冷不防地打個哆嗦。
2008年12月28日星期日
投名狀
星期天凌晨1點至3點,我看了CCTV-6播出的「投名狀」,這部電影播出的時間實在太巧,讓我產生太多的感觸,因為就在36小時前,我公司發生了類似投名狀劇情的事件。
由於我在公司的層級很低,所以我沒有在此事件中扮演任何角色,我只是一個旁觀者。從旁觀者的角度來看,不正可以客觀地判斷這一切,就像是在欣賞電影投名狀一般,你可以很清楚地知道誰是好人,誰是壞人。但是在真實的事件中,我卻像是在電影演出一半時才摸黑進場,許多事情的來龍去脈只能單憑臆測,以致於事情的真相,我也說不清。
我弄不明白事情的真相,這倒還是其次,最重要的是,我不喜歡我的生活中出現太過於複雜的事物,那會嚴重影響到我的生活情緒,所以我最近在評估換公司(Anyone wants to hire me?),或許回台灣求職(但台灣現在很不景氣),甚至回台南老家休息一陣子。其實事情的演變已經由不得我的控制,說不定連我想留都留不下來。
真是可惜了,我已經開始習慣北京的生活,而且我很喜歡我現在的工作內容,這是我進入社會至今最喜歡的工作,在這個工作中,我能做出貢獻,我能學習成長,我能帶領別人學習成長 … 可不是每一份工作都能這樣接近完美的。
但是有些事情是由不得自己的。認清現狀,投名狀已經播出到接近尾聲的地方,那些兄弟鬩牆的戲碼已經開始,如果我是戲中的一個小兵,這個時候我應該要解甲歸田,手持爆米花的觀眾已經傳來竊竊私語:「你早就該這麼做了!」
人永遠是最複雜的。程式的debug,容易;人的debug,難!程式的相容性,容易;人的相容性,難!程式的升級容易,人的升級難。
由於我在公司的層級很低,所以我沒有在此事件中扮演任何角色,我只是一個旁觀者。從旁觀者的角度來看,不正可以客觀地判斷這一切,就像是在欣賞電影投名狀一般,你可以很清楚地知道誰是好人,誰是壞人。但是在真實的事件中,我卻像是在電影演出一半時才摸黑進場,許多事情的來龍去脈只能單憑臆測,以致於事情的真相,我也說不清。
我弄不明白事情的真相,這倒還是其次,最重要的是,我不喜歡我的生活中出現太過於複雜的事物,那會嚴重影響到我的生活情緒,所以我最近在評估換公司(Anyone wants to hire me?),或許回台灣求職(但台灣現在很不景氣),甚至回台南老家休息一陣子。其實事情的演變已經由不得我的控制,說不定連我想留都留不下來。
真是可惜了,我已經開始習慣北京的生活,而且我很喜歡我現在的工作內容,這是我進入社會至今最喜歡的工作,在這個工作中,我能做出貢獻,我能學習成長,我能帶領別人學習成長 … 可不是每一份工作都能這樣接近完美的。
但是有些事情是由不得自己的。認清現狀,投名狀已經播出到接近尾聲的地方,那些兄弟鬩牆的戲碼已經開始,如果我是戲中的一個小兵,這個時候我應該要解甲歸田,手持爆米花的觀眾已經傳來竊竊私語:「你早就該這麼做了!」
人永遠是最複雜的。程式的debug,容易;人的debug,難!程式的相容性,容易;人的相容性,難!程式的升級容易,人的升級難。
2008年12月18日星期四
生日適合跳出迴圈
每天都要吃飯,每天都要上班,每天都要睡覺…這就像是活在一個無窮迴圈中。有時候實在活得很不耐煩,想用關鍵字break跳出迴圈,或者用throw間接跳出迴圈,或者用return跳出函數,甚至想用quit結束程式。
我不鼓勵自殺,但萬一有任何人(including me)要自殺的話,生日當天無疑是最適合的日子。和朋友聚會吃大餐,收禮物,然後去K歌,最後回到家結束一切。
目前我還沒這麼激進,我想今年就先break好了。
REBOL [ ]
; . . .
if now/date = my-birthday [
break
; suicide ; not this year
]
2008年12月12日星期五
我的C++ Parser
我最近在寫一個C++ Parser,原本採用Top-Down且無記憶的Parser算法,結果效率超差,甚至堆疊(stack)會爆掉。最後我只好乖乖地採用先Tokenizing,再採有記憶的Bottom-Up方式剖析(Bottom-Up Parsing With Chart)。忽然想到,幾年前寫過的一個NLP(Natural Language Processing)英文句子Parser,剛好可以拿來用。這個程式連英文句子都可以剖析,區區C++的剖析有什麼難的!
所以很快地我就將英文文法剖析程式改成一個C++剖析器,但目前還有Bug。這個Parser完全遵照2003的C++標準語法,你看上面的圖,光一個「int a = 3 + 5 ;」,就可以產生如此複雜的樹,整個完整的C++程式被剖析之後,產生的樹一定超級大棵。
所以很快地我就將英文文法剖析程式改成一個C++剖析器,但目前還有Bug。這個Parser完全遵照2003的C++標準語法,你看上面的圖,光一個「int a = 3 + 5 ;」,就可以產生如此複雜的樹,整個完整的C++程式被剖析之後,產生的樹一定超級大棵。
2008年12月10日星期三
大陸的工程師都這麼拼命嗎?
我發現我們公司的工程師都很拼命,加班是家常便飯的事,熬夜也經常發生,好幾天不回家更是司空見慣(今天早上聽同事說,我們的測試工程師已經四天沒回家了),所以可以在很短的時間內,把項目完成。最近我們接到一個項目的合同,時間相當趕,但我們的工程師居然可以在短短的時間內做出相當不錯的成品,實在是讓我相當佩服。
2008年12月8日星期一
你愛用你們家的IT產品嗎?
我喜歡看到窩裡反的新聞,例如今天晚報的標題:「垃圾郵件氾濫,毛治國不用Hinet信箱」,就讓我相當高興。我希望有一天還能看到下面的窩裡反新聞:
「太耗費資源,比爾降級使用XP」
「速食傷害健康,麥當勞叔叔私底下都吃素」
「螢幕小很傷眼,瞇瞇眼施不用自家生產的E批西」
自家人不愛用自家的商品,這樣的消息一傳開,殺傷力很大的。連自家人都不捧場,怎麼說服外人購買這樣的產品呢?身在IT界的你,愛用你們自家的軟體產品嗎?
我家開麵包店,小時候有一次我正在吃麵包,我爸爸抓住機會跟顧客說:「這是我的兒子,你看他這麼愛吃我們自己的麵包,這證明了我們生產的麵包健康、衛生…」。當時我還真是愣住了,佩服爸爸「這也能大作文章」。不過想想,這對顧客來說,還真的很有說服力。
來到北京之後,我們正在努力打造一個連我們自己都會想用的軟體,一步一步地實現這樣的願望。如果自己都愛用,那麼要說服顧客就不會太困難了。
「太耗費資源,比爾降級使用XP」
「速食傷害健康,麥當勞叔叔私底下都吃素」
「螢幕小很傷眼,瞇瞇眼施不用自家生產的E批西」
自家人不愛用自家的商品,這樣的消息一傳開,殺傷力很大的。連自家人都不捧場,怎麼說服外人購買這樣的產品呢?身在IT界的你,愛用你們自家的軟體產品嗎?
我家開麵包店,小時候有一次我正在吃麵包,我爸爸抓住機會跟顧客說:「這是我的兒子,你看他這麼愛吃我們自己的麵包,這證明了我們生產的麵包健康、衛生…」。當時我還真是愣住了,佩服爸爸「這也能大作文章」。不過想想,這對顧客來說,還真的很有說服力。
來到北京之後,我們正在努力打造一個連我們自己都會想用的軟體,一步一步地實現這樣的願望。如果自己都愛用,那麼要說服顧客就不會太困難了。
2008年12月2日星期二
漫談雲端運算
文 / 蔡學鏞
★ 這是舊文章的改版
雲(Cloud)是網路的象徵,所以雲端運算(Cloud Computing),最廣義的解釋就是「網路運算」。這恐怕是目前大家對於雲端運算的最大公約數,在這之外,大家對於雲端運算的理解和定義,都不太一樣。這篇文章試圖用最淺顯的方式,向大家說明我所知道的雲端運算。
【雲端的組成與架構】
網路是由許多伺服器所組成,雲端運算的基礎是大量的伺服器。如果只用一部超級電腦當伺服器,一樣可以提供相當大的運算威力,這樣可以算是雲端嗎?恐怕不行,因為雲端運算強調的是許多伺服器聯合起來提供強大的運算能力。只有一部超級電腦或少數幾部電腦,恐怕太薄弱,無法形成雲,充其量是「水蒸氣」。
良好的雲端運算架構方式,必須具備規模彈性、容錯、平衡負載:
1 當運算規模增加,雲端要可以彈性變大,只要加上新的節點就可以了,這樣的能力稱為水準擴充(horizontal scalability)。
2 資料重複(redundancy)存放在不同位置,確保資料安全。
3 讓伺服器之間的負載盡量平衡,免得某些伺服器太忙,某些卻太悠閒。
【雲端的前世今生】
既然雲端運算是將許多電腦聯合起來提供運算能力,那麼就會用到網格運算(grid computing)。比較知名的網格運算應該是SETI(尋找外星人)計畫,幾年前SETI流行時,許多人的電腦都下載安裝了SETI程式,奉獻出電腦多餘的運算能力,為尋找外星人這種無聊之舉貢獻心力。
以往的網格運算似乎是供專家使用居多,著重在需要複雜運算的「單一任務」,例如基因定序、核爆模擬。但雲端運算則比較偏大眾應用,相當高比例的大眾應用其實不需要進行複雜的運算,但是由於「大眾」相當多,所以累積起來的運算需求也相當可觀。所以在應用上,雲端運算可以被視為平民化的網格運算。
除了上述的差別,雲端運算和網格運算的差別還有兩點。第一,為了方便管理,並充分運用伺服器的效能,雲端運算也經常會使用到「虛擬化」技術。第二,以往的網格運算通常也只使用專屬的應用協定和資料格式,但雲端運算則受到近年Web潮流的影響很深。
【雲端的操作介面】
雲端運算的願景是以Web為前端,資料全都放在後端,不放在使用者手上。如此一來使用者可以不用擔心不同裝置上資料同步化的問題,也可以隨時取用資料(如果網路沒斷線的話)。既然資料都放在雲端,運算都在雲端進行也就理所當然。因為這樣的效率最好,可以減少資料在使用者和雲端之間的傳輸。
至於Web前端,微軟和Adobe等公司會希望你使用他們各自的RIA技術,但IBM、Google、Apple等沒有RIA技術的廠商,則會希望你使用Web瀏覽器(JavaScript/CSS/HTML),以免被(其他)廠商綁死。
操作介面的程式碼透過Web Browser動態地送到客戶端執行,重要的邏輯部分放在Web伺服器上。這樣的運作方式,其實就是SaaS。所以雲端運算和SaaS是相輔相成的技術概念。
除了Web瀏覽器和RIA之外,許多標準的應用也會隨著雲端運算的興起,開始支援從雲端開啟文件,或寫入文件到雲端,這些讀寫的動作會透過標準的HTTP協定、FTP協定、或WebDAV來達成。說不定以後軟體在「File」選單中,除了「Save」、「Save As」之外,還會多出一個「Save To Cloud」。
【雲端的隱憂】
但是雲端畢竟是在遠方,資料的存取速度自然遠比不上自己電腦上的硬碟。所以除非客戶端連線到雲端的速度夠快,否則這會成為推廣雲端運算的障礙。更不用提萬一像Google App Engine來個大斷線、或者太平洋海底光纖斷線,頓時白雲變烏雲,你可就求救無門了。
在雲端的廠商會將服務列在網頁上,讓你選擇要執行的程式。這些雲端上的程式都可以設定參數,以記錄你的名稱、喜好,以提供更好的服務。甚至過去的一舉一動,也會被記錄下來,你的隱私資料成為廠商的資產。如果公司利用雲端處理ERP/CRM等資料,那麼公司的運作機密以及客戶資料也都會被雲端的廠商知道。是的,雲端廠商都會強調他們重視顧客的權益,這就看你信不信了。
除了可以使用廠商原本就提供的雲端程式,利用參數設定來符合自己需求之外,你也可以上傳程式到雲端。Google App Engine允許你將程式上傳到雲端,在雲端執行。使用Google App Engine,可以省去你建置與管理伺服器的困擾。上傳程式一樣有暴露機密的可能,如果你是一家搜尋引擎的公司,你發明瞭比Google更準確的搜尋演算法,你敢把這樣的服務放到Google的雲端上,只是為了省去「建置與管理伺服器的困擾」嗎?
【雲端對軟體開發者的影響】
你想用什麼方式實踐你的雲端系統,會受到雲端供應商(Cloud Provider)的平台限制。
雲端供應商提供這類的服務,都會限定所使用的語言和框架。Google目前只支援Python和相關的Web框架。以後才會支援其他語言和框架。Python是最適合雲端的語言嗎?恐怕不是,但應該已經符合大眾的需求。
你的Python程式會被Google複製到不同的伺服器上各自執行,這樣的程式無法協同完成一件複雜的任務(例如基因定序)。比較適合雲端的語言其實是函數式語言,例如Erlang。而微軟預計會以F#當作雲端運算的語言。
另外,最厲害的雲端運算設計方式,甚至會向Mobile Agent技術借鏡,讓程式碼可以流動。我認為能結合Mobile Agent的雲端,才是真正先進的雲端。
【雲端的商業模式】
雲端運算會讓軟體產業由原本的「銷售套裝軟體」改成「銷售服務與租賃軟體」。在這樣的商業模式之下,牽涉到的業者包括了ISP(Internet Service Provider)、ASP(Application Service Procider)、DSP(Data Service Provider)、以及Cloud Provider,形成一個緊密的產業結構,由ISP提供網路(例如ADSL)、ASP提供軟件、DSP提供資料、Cloud Provider提供運算能力。
【為何雲端紅了】
雲端運算「這個名詞」在這兩年會這麼紅,主要是因為Web的興起所帶動的。近年Web化的趨勢是將資料都放在伺服器上,既然資料都在伺服器上,運算最好要在接近資料的地方進行,所以運算也在伺服器上才是比較好的作法。運算完成之後,將運算後的結果傳遞到客戶端即可。伺服器需要龐大的運算能力才能應付眾多使用者所提出的運算需求,所以需要將許多伺服器串接起來。
剛剛提到,運算必須要是在伺服器上進行,而不是在客戶端進行。把所有的資料都送到客戶端,然後才在客戶端進行處理,這是不合理的,因為:
1. 資料量相當大,傳輸的速度會相當慢
2. 客戶端的電腦不見得有運行此程式的能力
3. 有資料保密和程式邏輯保密的風險。
從這個角度來看,雲端運算勢在必行,要紅是遲早的事。儘管目前雲端運算有一點渾沌不明,但我不認為雲端運算會是曇花一現。
【雲端何時成熟】
儘管雲端運算不會只是曇花一現,但是要多久的時間才能成熟,就相當難以估計。我個人認為目前雲端運算還只是在萌發時期,要到達成熟還有很長的一段時間,雲端運算需要企業做出相當多改變,加上目前的國際經濟局勢相當糟糕,可能會持續好幾年的時間,在這段時間內,多數企業會保守因應新技術和新市場,所以沒有幾年以上的時間,我們很難看到雲端運算的實際成績。
綜觀目前的狀況,雲端運算正在一團雲霧之中,渾沌未明。雲端運算目前充滿不確定因素,太多事情的發展很難預料。我認為,妄想漫步在雲端,而太早踏入,小心你一腳踩空。
當經濟局勢穩定,且提倡雲端運算的這些廠商能夠彼此坐下來談,定義出一套雲端運算的標準時(Protocol、API…),或許才是大多數的企業應該投入雲端運算的時候。
★ 這是舊文章的改版
雲(Cloud)是網路的象徵,所以雲端運算(Cloud Computing),最廣義的解釋就是「網路運算」。這恐怕是目前大家對於雲端運算的最大公約數,在這之外,大家對於雲端運算的理解和定義,都不太一樣。這篇文章試圖用最淺顯的方式,向大家說明我所知道的雲端運算。
【雲端的組成與架構】
網路是由許多伺服器所組成,雲端運算的基礎是大量的伺服器。如果只用一部超級電腦當伺服器,一樣可以提供相當大的運算威力,這樣可以算是雲端嗎?恐怕不行,因為雲端運算強調的是許多伺服器聯合起來提供強大的運算能力。只有一部超級電腦或少數幾部電腦,恐怕太薄弱,無法形成雲,充其量是「水蒸氣」。
良好的雲端運算架構方式,必須具備規模彈性、容錯、平衡負載:
1 當運算規模增加,雲端要可以彈性變大,只要加上新的節點就可以了,這樣的能力稱為水準擴充(horizontal scalability)。
2 資料重複(redundancy)存放在不同位置,確保資料安全。
3 讓伺服器之間的負載盡量平衡,免得某些伺服器太忙,某些卻太悠閒。
【雲端的前世今生】
既然雲端運算是將許多電腦聯合起來提供運算能力,那麼就會用到網格運算(grid computing)。比較知名的網格運算應該是SETI(尋找外星人)計畫,幾年前SETI流行時,許多人的電腦都下載安裝了SETI程式,奉獻出電腦多餘的運算能力,為尋找外星人這種無聊之舉貢獻心力。
以往的網格運算似乎是供專家使用居多,著重在需要複雜運算的「單一任務」,例如基因定序、核爆模擬。但雲端運算則比較偏大眾應用,相當高比例的大眾應用其實不需要進行複雜的運算,但是由於「大眾」相當多,所以累積起來的運算需求也相當可觀。所以在應用上,雲端運算可以被視為平民化的網格運算。
除了上述的差別,雲端運算和網格運算的差別還有兩點。第一,為了方便管理,並充分運用伺服器的效能,雲端運算也經常會使用到「虛擬化」技術。第二,以往的網格運算通常也只使用專屬的應用協定和資料格式,但雲端運算則受到近年Web潮流的影響很深。
【雲端的操作介面】
雲端運算的願景是以Web為前端,資料全都放在後端,不放在使用者手上。如此一來使用者可以不用擔心不同裝置上資料同步化的問題,也可以隨時取用資料(如果網路沒斷線的話)。既然資料都放在雲端,運算都在雲端進行也就理所當然。因為這樣的效率最好,可以減少資料在使用者和雲端之間的傳輸。
至於Web前端,微軟和Adobe等公司會希望你使用他們各自的RIA技術,但IBM、Google、Apple等沒有RIA技術的廠商,則會希望你使用Web瀏覽器(JavaScript/CSS/HTML),以免被(其他)廠商綁死。
操作介面的程式碼透過Web Browser動態地送到客戶端執行,重要的邏輯部分放在Web伺服器上。這樣的運作方式,其實就是SaaS。所以雲端運算和SaaS是相輔相成的技術概念。
除了Web瀏覽器和RIA之外,許多標準的應用也會隨著雲端運算的興起,開始支援從雲端開啟文件,或寫入文件到雲端,這些讀寫的動作會透過標準的HTTP協定、FTP協定、或WebDAV來達成。說不定以後軟體在「File」選單中,除了「Save」、「Save As」之外,還會多出一個「Save To Cloud」。
【雲端的隱憂】
但是雲端畢竟是在遠方,資料的存取速度自然遠比不上自己電腦上的硬碟。所以除非客戶端連線到雲端的速度夠快,否則這會成為推廣雲端運算的障礙。更不用提萬一像Google App Engine來個大斷線、或者太平洋海底光纖斷線,頓時白雲變烏雲,你可就求救無門了。
在雲端的廠商會將服務列在網頁上,讓你選擇要執行的程式。這些雲端上的程式都可以設定參數,以記錄你的名稱、喜好,以提供更好的服務。甚至過去的一舉一動,也會被記錄下來,你的隱私資料成為廠商的資產。如果公司利用雲端處理ERP/CRM等資料,那麼公司的運作機密以及客戶資料也都會被雲端的廠商知道。是的,雲端廠商都會強調他們重視顧客的權益,這就看你信不信了。
除了可以使用廠商原本就提供的雲端程式,利用參數設定來符合自己需求之外,你也可以上傳程式到雲端。Google App Engine允許你將程式上傳到雲端,在雲端執行。使用Google App Engine,可以省去你建置與管理伺服器的困擾。上傳程式一樣有暴露機密的可能,如果你是一家搜尋引擎的公司,你發明瞭比Google更準確的搜尋演算法,你敢把這樣的服務放到Google的雲端上,只是為了省去「建置與管理伺服器的困擾」嗎?
【雲端對軟體開發者的影響】
你想用什麼方式實踐你的雲端系統,會受到雲端供應商(Cloud Provider)的平台限制。
雲端供應商提供這類的服務,都會限定所使用的語言和框架。Google目前只支援Python和相關的Web框架。以後才會支援其他語言和框架。Python是最適合雲端的語言嗎?恐怕不是,但應該已經符合大眾的需求。
你的Python程式會被Google複製到不同的伺服器上各自執行,這樣的程式無法協同完成一件複雜的任務(例如基因定序)。比較適合雲端的語言其實是函數式語言,例如Erlang。而微軟預計會以F#當作雲端運算的語言。
另外,最厲害的雲端運算設計方式,甚至會向Mobile Agent技術借鏡,讓程式碼可以流動。我認為能結合Mobile Agent的雲端,才是真正先進的雲端。
【雲端的商業模式】
雲端運算會讓軟體產業由原本的「銷售套裝軟體」改成「銷售服務與租賃軟體」。在這樣的商業模式之下,牽涉到的業者包括了ISP(Internet Service Provider)、ASP(Application Service Procider)、DSP(Data Service Provider)、以及Cloud Provider,形成一個緊密的產業結構,由ISP提供網路(例如ADSL)、ASP提供軟件、DSP提供資料、Cloud Provider提供運算能力。
【為何雲端紅了】
雲端運算「這個名詞」在這兩年會這麼紅,主要是因為Web的興起所帶動的。近年Web化的趨勢是將資料都放在伺服器上,既然資料都在伺服器上,運算最好要在接近資料的地方進行,所以運算也在伺服器上才是比較好的作法。運算完成之後,將運算後的結果傳遞到客戶端即可。伺服器需要龐大的運算能力才能應付眾多使用者所提出的運算需求,所以需要將許多伺服器串接起來。
剛剛提到,運算必須要是在伺服器上進行,而不是在客戶端進行。把所有的資料都送到客戶端,然後才在客戶端進行處理,這是不合理的,因為:
1. 資料量相當大,傳輸的速度會相當慢
2. 客戶端的電腦不見得有運行此程式的能力
3. 有資料保密和程式邏輯保密的風險。
從這個角度來看,雲端運算勢在必行,要紅是遲早的事。儘管目前雲端運算有一點渾沌不明,但我不認為雲端運算會是曇花一現。
【雲端何時成熟】
儘管雲端運算不會只是曇花一現,但是要多久的時間才能成熟,就相當難以估計。我個人認為目前雲端運算還只是在萌發時期,要到達成熟還有很長的一段時間,雲端運算需要企業做出相當多改變,加上目前的國際經濟局勢相當糟糕,可能會持續好幾年的時間,在這段時間內,多數企業會保守因應新技術和新市場,所以沒有幾年以上的時間,我們很難看到雲端運算的實際成績。
綜觀目前的狀況,雲端運算正在一團雲霧之中,渾沌未明。雲端運算目前充滿不確定因素,太多事情的發展很難預料。我認為,妄想漫步在雲端,而太早踏入,小心你一腳踩空。
當經濟局勢穩定,且提倡雲端運算的這些廠商能夠彼此坐下來談,定義出一套雲端運算的標準時(Protocol、API…),或許才是大多數的企業應該投入雲端運算的時候。
唉!連社論的品質都差到不能看了
我喜歡看報社的社論,尤其是聯合報的社論,用詞優美精確,論點一針見血。例如,聯合報約十年前在李登輝時期的「修憲不可以毀憲」系列社論,精彩絕倫,相當經典。
但是聯合報這幾年的品質江河日下,報導品質越來越低劣不說,連社論都出問題了。今天聯合報系的經濟日報,社論為「聽掌聲點將就對了!」,用一堆成語堆砌出內容與口氣極端狂妄可笑的文章。看完這篇莫名其妙的社論,我只能哀悼一個時代的結束。我說聯合報呀!如果你們沒有好的論點和文筆,不如不論。不要出來丟人現眼。
但是聯合報這幾年的品質江河日下,報導品質越來越低劣不說,連社論都出問題了。今天聯合報系的經濟日報,社論為「聽掌聲點將就對了!」,用一堆成語堆砌出內容與口氣極端狂妄可笑的文章。看完這篇莫名其妙的社論,我只能哀悼一個時代的結束。我說聯合報呀!如果你們沒有好的論點和文筆,不如不論。不要出來丟人現眼。
訂閱:
文章 (Atom)
