2009年12月21日

[看電影] 阿凡達

話說這個月開始,斗六的中華影城也有3D數位廳,距離上次到中華影城看電影,已經是七、八年前的事了,只記得那裡的放映廳有點小,其他沒什麼印象。剛好趁著這次的《阿凡達》首映,再次到中華影城體驗一下新設備,在斗六就僅此一家電影院,消費者別無選擇的情況下,能夠升級設備算是有心在經營啦,但票價給它貴了點,而且沒有官方自己的網站,唯一查得到放映場次的網頁,是掛在我家附近的一間小工作室維護的網站下。

《阿凡達》片中用上大量的3D效果,劇中的人物、動物、飛行器、…,都用上大量的3D拍攝效果,呈現出立體的實境感,這為3D電影樹立了新標竿,要看這部片一定要到有提供3D數位版的放映聽,才能體驗導演製作這部片想要帶給觀眾的感官享受。

雖然片長兩小時又四十分鐘,但劇情緊湊並不會讓人覺得漫長,藉由主角帶觀眾進入冒險的國度,充滿許多科幻情節的奇異鳥獸。故事中人類扮演著侵略外星球的角色,引發觀眾反思我們是不是正以同樣的方式在侵害自己居住的地球。

2009年12月12日

ONLINE 38% 週末賞楓之旅

退伍令下載: 38%已完成

平時過著與世隔絕的日子,有放假當然就是往人多的地方跑。話說這一次的放假雖然是例休,但在營待了八天才放假,每天乖乖聽話才換來1800提早假,但放假前一小時遇到汰舊換新大搬家,不斷上上下下來回搬了十幾趟重乎乎的鋼製內務櫃,直到1900才能順利回到人間。

前幾天在上哨前偷閒翻閱一下水果日報,發現賞楓的季節已經到了,今年的氣候還真是怪異,已經是12月的冬天,山頭才開始換上秋裝,但不管是什麼時候楓葉才開始轉紅,每年賞楓的人潮都很可觀,幾個熱門景點在週末應該都是滿滿的人車吧。水果日報推薦的地點包括大雪山、梨山、福壽山,大雪山太常去沒有度假的感覺,所以首選就是中橫的梨山、福壽山沿線啦。

從台中市開車到梨山,整整花掉四個小時路程,不過,本來就是想趁放假讓老CORONA運動一下,除了霧社到清境塞車外,其餘路段都開得很盡興啦!雖然梨山就位在台中縣,原本從谷關過去很快就會到達,但自從921震災後中橫德基坍塌不通,就必須繞道翻山越嶺,向東走台14甲過埔里、霧社、清境,過了最高點的武嶺,在向西走台8到梨山,要繞這麼一大圈山路,遊客的流失讓梨山這個過去中橫最熱門的景點沒落許多。但是媒體的力量相當驚人,賞楓的旅遊報導讓許多遊客願意冒著寒風刺骨、大老遠跑來看楓葉,從台中出發一趟來回就接近兩百公里路程。

不管天氣多冷,往武嶺的山路還是出現不少單車客,誰說單車熱在今年就會退散?!

到福壽山的時間剛好趕上日落山頭,看了幾眼夕陽就要開始為夜宿想想著落,看著一車又一車的遊覽車,要住宿想必是一房難求。索性跑到露營區一探究竟,發現福壽山的營地規劃挺不賴,有提供廁所及淋浴間,停車位就在營地旁邊,也有烤肉區、高架帳篷及小木屋。在這個賞楓季節也有不少露營的遊客,所以晚上還蠻熱鬧。

在福壽山遊客服務中心的一旁,有間周圍種滿楓樹的木屋,就是新聞報導的特色景點,但十二月中只剩下幾株接近凋零的楓樹,推算大概十一月中旬左右比較美。

楓葉並沒有想像中的漂亮,但意外發現夜晚的星空很棒,很不巧的是隔天12/13~12/14的流星雨很無緣地擦身而過。

2009年12月3日

[程式設計] 建築防禦工事

好的programmer寫作的程式碼,必定是條理分明、敘述清晰、邏輯清楚。

一份好的程式碼,本身就已經清楚說明目的和用法。

兩個都懂某程式語言的人,就像兩個都懂英文的人,能夠透過語言本身清楚地溝通。然而,我們若講或寫出一段別人聽不懂或看不懂英文時,我們會清楚知道是自己的問題。但許多寫程式的人卻因為寫出別人看不懂的程式碼而沾沾自喜,真是一件怪事!?

當然,溝通的基礎是建立在雙方都懂這個語言,並且知道慣用的標準為何。

多數的programmer都知道,debug很花時間,許多專案都浪費大把的時間在debug,好不容易找到問題,修改好了,卻又因為忽略某些情況再次出問題,修修補補的程式碼既難看又造成更多問題。

防禦工事就是在撰寫程式碼的當下,就盡可能一次把事情做到定位,因為只有當下最清楚哪些問題可能發生,若因為拿時間有限當藉口而偷懶,省下撰寫預防用途的程式碼,日後將會付出更大的代價,也就是無謂地增加開發成本,更可能造成專案因此延宕。

舉例來說,一個小程式接受使用者輸入兩個數字,並且相除。

這個程式很快就能寫好交差。

a = get_user_input();
b = get_user_input();

print a/b;

假設這個程式碼可以運作,但那一定只有在限定的狀況下。

也就是使用者輸入的第二個數字不得為零。

我們可以偷懶而將問題視而不見,反正老闆/客戶可能永遠不會發現,就算到時候被發現了,再回頭修改不就好了,這世界上哪有不會出錯的程式呢?看看微軟的BSOD,不就是經典中的經典嘛。

但想想看,當程式碼變成幾千行、幾萬行,甚至幾十萬行的時候,這個小錯誤要找出來會花掉多少時間人力阿。

在撰寫程式的當下做好防禦工事,其實很容易。

只要加上些假設條件的判斷。

a = get_user_input();
b = get_user_input();

if (b <> 0) {
print a/b;
}
else {
print "error: devide by zero";
}

當然還可以再想得更周到,讓使用者可以重新輸入。

改寫如下。

a = get_user_input();

b = get_user_input();
while (b == 0) {
print "warning: input must be non-zero value";
b = get_user_input();
}

assert(b <> 0);

print a/b;

因為使用者輸入0的時候,程式會要求重新輸入,所以我們在印出a/b的時候省略一次if判斷。但是為保險起見,加入assert的語法,以免前面的程式碼在某次的修改之後失靈,又再度發生錯誤。

assert再不同的程式語言的編譯器會有不同的實作,這個機制讓我們可以撰寫一些限制條件的驗證,在development階段可以方便debug發現問題並及早修正;而在production的階段,某些程式語言的編譯器允許選擇性地除掉這些驗證,以減少不必要的效能支出。

哪些情況的防禦可以用assert呢?

一個簡單的判別就是,當一個限制條件的判斷,在程式正式發行時就可以忽略不管,那麼就可以考慮用assert,否則要用if-else或其他方式作永久性地檢查。

* 了解一個語法適用的時機及意義,不要濫用及錯用。
* 避免使用非語言標準的語法、函式庫。
* 盡可能考慮周詳並在程式碼清楚表達出來。
* 寫出其他人能夠直接看懂、不必猜測的程式碼。
* 不要讓使用者有機會發生可以預知的錯誤,雖然錯誤的發生可能是在很愚蠢的狀況下,但現實就是真的有人會那麼蠢。

在撰寫程式碼的同時,需要多思考這段程式碼的防禦工事是否足夠,那些情況下會被攻破,在當下就盡可能做好準備工作。寫出日後更容易維護、更少出現問題的程式碼,才是合格programmer應具備的能力。


參考文獻
- Code Craft: The Practice of Writing Excellent Code

2009年12月2日

科技詞彙的小測驗 from CNN

這個小測驗提供十個題目,測驗你是否看懂最近新聞常出現的科技詞彙。

Test your techno-jargon!

其中「Augmented Reality」是第一次看到,在Google查一下才發現不管中英文網誌或影片都有介紹,這東西在電影的科幻情結很常看到,如果可以在生活中實際應用,那將會是很酷的一件事。
lyhcode by lyhcode
歡迎轉載,請務必註明出處!