l

2013年5月5日 星期日

2013馬祖考察之旅Day1-B北竿北海坑道

May 4 09:10~09:53

在北竿租機車一天500元,真的是一天喔,因為是計算24小時。

螢幕快照 2013-05-04 上午9.03.14

 

民宿老闆告知可以先來北竿的北海坑道參觀,時間接近中午12點,這時候剛好是退潮,可以走入坑道內參觀。

螢幕快照 2013-05-04 上午9.16.54

 

海邊的風景真漂亮。

螢幕快照 2013-05-04 上午9.17.36

螢幕快照 2013-05-04 上午9.17.59

坑道上方好像是軍營,不知道現在是否還有阿兵哥駐守。

螢幕快照 2013-05-04 上午9.25.14

 

坑道入口。民國57年,因為反攻大陸與物資運補需要軍方開始了「北海計畫」,在馬祖開鑿了好幾個坑道,作為登陸小艇停泊之用。當初計畫分別在南竿、北竿、莒光開鑿可供50、40、10艘登陸小艇停泊的坑道。北竿的坑道因為颱風的關係廢棄不用,南竿的坑道因為潮汐計算錯誤,漲潮的時候登陸小艇的指揮塔會卡在「天花板」。總之最後白忙一場,北海坑道並沒有發揮原本計畫中的功能。

螢幕快照 2013-05-04 上午9.18.18

螢幕快照 2013-05-04 上午9.18.53

 

馬祖的地質主要為花崗岩,質地非常堅硬。當時挖掘坑道並沒有像現在有重機械設備可以使用,除了在岩壁上鑿洞用炸藥爆破外,全靠國軍用人力一鑿一斧挖掘而成,施工過程非常辛苦,有不少官兵因而犧牲。

螢幕快照 2013-05-04 上午9.19.09

螢幕快照 2013-05-04 上午9.24.38

 

來到坑道另外一頭,上方就是北竿的「水庫」。

螢幕快照 2013-05-04 上午9.20.21

螢幕快照 2013-05-04 上午9.20.34

 

螢幕快照 2013-05-04 上午9.20.56

螢幕快照 2013-05-04 上午9.21.18

 

來參觀北竿的北海坑道記得要配合潮汐,才能入內參觀,漲潮的時候步道可是會被海水給淹沒的。

螢幕快照 2013-05-04 上午9.21.58

 

在馬祖海邊可以發現很多岩石上面都布滿了玻璃酒瓶碎片,當年是為了防止對岸「水鬼」(蛙人)上岸摸哨。這些玻璃碎片很多都已被清除,但還是可看出它們曾經存在的「遺跡」。

螢幕快照 2013-05-04 上午9.23.51

下集待續。

***

友藏內心獨白:要到現場才能體會坑道的壯觀。

2013年5月4日 星期六

2013馬祖考察之旅Day1-A到達北竿芹壁25號民宿

May. 3 23:22~23:59

今年四月和Kay到馬祖考察離島開放博弈之後的商機挑眉質疑,嗯嗯,第一天從台北松山機場搭立榮航空飛到馬祖北竿機場。由於Teddy有辦花旗銀行與長榮航空聯名卡,所以可以使用立榮(長榮)的貴賓室。偌大的貴賓室一共只有三個人,Teddy、Kay、和一位服務人員不要告訴別人。

螢幕快照 2013-05-03 下午11.26.58

螢幕快照 2013-05-03 下午11.27.08

 

在貴賓室休息約20分鐘左右就準備到候機室候機了,飛馬祖的是下圖中這種螺旋槳小飛機。Teddy已經有好幾年沒搭過這種小飛機了,重溫舊夢一下。

螢幕快照 2013-05-03 下午11.28.04

 

50分鐘後順利降落在馬祖北竿機場。

螢幕快照 2013-05-03 下午11.28.37

 

北竿機場比Teddy想像中還要新穎。

螢幕快照 2013-05-03 下午11.37.34

螢幕快照 2013-05-03 下午11.37.25

螢幕快照 2013-05-03 下午11.37.01

 

出機場之後搭上民宿派來的車輛,幾分鐘的車程就來到位於芹壁的民宿:「芹壁25號」。

螢幕快照 2013-05-03 下午11.40.01

 

就是這一間。

螢幕快照 2013-05-03 下午11.40.13

 

隔一條馬路就是沙灘和大海。

螢幕快照 2013-05-09 下午11.30.58

螢幕快照 2013-05-03 下午11.40.20

 

以及一個稱為「龜島」的小島,還真的挺像烏龜的說。

螢幕快照 2013-05-03 下午11.40.28

 

到達民宿的時間是早上9:25,把行李借放在店內之後先在這附近逛逛。

螢幕快照 2013-05-09 下午11.31.48

螢幕快照 2013-05-03 下午11.40.51

螢幕快照 2013-05-03 下午11.41.07

 

馬祖都是山地,雖然不高,但爬上來也是有點小累嚎啕大哭。

螢幕快照 2013-05-03 下午11.47.52

螢幕快照 2013-05-03 下午11.48.03

 

軍事要地不要告訴別人。

螢幕快照 2013-05-03 下午11.48.21

 

北竿馬路的平整度比台北的路平專案效果還要好很棒。

螢幕快照 2013-05-03 下午11.48.48

螢幕快照 2013-05-03 下午11.49.05

螢幕快照 2013-05-03 下午11.49.35

螢幕快照 2013-05-03 下午11.50.01

 

累了,走回民宿休息一下。

螢幕快照 2013-05-03 下午11.50.37

 

民宿主人如果沒猜錯的話是一位女性同胞,店內有賣飲料。Teddy到的時候小小的店內已被6~7位阿兵哥佔據了2/3的座位挑眉質疑。點了杯飲料跟一個繼光餅,休息一下等一下準備租機車遊北竿。

螢幕快照 2013-05-03 下午11.51.07

螢幕快照 2013-05-09 下午11.32.36

***

友藏內心獨白:芹壁還滿漂亮的很棒。

2013年5月3日 星期五

為什麼例外處理那麼難(4):工具支援觀點

Apr. 29 22:40~23:18

image

 

Tool-Support View(工具支援觀點)

工具支援觀點從開發環境支援例外處理的角度來探討為什麼例外處理哪麼難這個問題。從工具支援觀點來比較Java語言與C#語言,Java編譯器對checked exception會遵循handle-or-declare rule(請參考《C. C. Agile 聚會Sprint 6 精華報導》),因此在開發階段編譯器會提醒使用者有哪些「應該被處裡的例外沒有被關注到」。C#則沒有區分checked或是unchecked例外,因為針對未被捕捉的例外,編譯器並不會提供特別的提醒。

螢幕快照 2013-04-29 下午10.47.57

***

但是,Java語言的Tool-Support也造成兩個嚴重的後遺症:

  • Interface evolution problem   
  • Ignored checked exception

這兩個問題Teddy在部落格中談過很多次,就不再贅述了。

***

為了提高軟體的強健度,開發人員需要一個提醒機制,告知那些操作有可能產生例外,否則開發人員更容易忽略例外處理,只能等runtime發生錯誤時再回頭修補(還需要遇到有良心的開發人員才會回頭修補挑眉質疑)。至於這個提醒機制,是否需要像是Java語言的做法,強制區分checked與unchecked例外,Teddy認為並非重點。但很可惜的是,在只支援unchecked例外的語言與開發環境中,對於「那些操作有可能產生例外」的提醒支援實在是太少了、實在是太少了、實在是太少了。

***

友藏內心獨白:這一集內容雖短,但含意深遠啊。

2013年5月2日 星期四

為什麼例外處理那麼難(3):處理觀點

Apr. 29 21:14~22:26

image

 

Handling View(處理觀點)

從第2集的「設計觀點」鄉民可以得知一個元件是否會丟出例外(declared或是undeclared例外),再利用第1集的「使用觀點」來判斷這個例外是否真的代表failure或只是狀態通知。如果是代表failure,就可以準備著手來設計處理例外的方法。

處理觀點關注下列兩個因素:

  • Recoverability (可恢復性)
    • recoverable或unrecoverable(irrecoverable)
  • Exception handling constructs in languages and utilities
    • Roles, responsibilities, and collaborations (e.g., try, catch, finally in Java)

先談談recoverability。一個例外狀況可不可修、要不要修,要同時考量callee與caller的情況(callee的狀態是否正確,caller是否有足夠的context來處理)。回顧一下Teddy在第1集裡面提到的例子,InterruptedException要怎麼處理?首先,這個例外的本質是一種狀態通知,並非代表failure。其次,在sleepMillisecond()這個context底下,當InterruptedException發生時,還是代表狀態通知,而且系統中沒有什麼狀態需要被恢復,所以針對這個例外的處理方法就是捕捉到例外之後直接離開這個method就功德圓滿了。

螢幕快照 2013-04-29 下午9.50.32

***

接下來討論一下exception handling constructs in languages and utilities。既然談到設計觀點,最後就必須要考慮設計要如何被實作的問題,此時就牽扯到程式語言對於例外處理的支援,以及是否有例外處理utilities可以使用。

不同的程式語言有著不同的例外處理構件,鄉民們必須要充分理解,才不會設計出錯誤的例外處理程式(很多系統的bug其實是發生在例外處理程式碼之中挑眉質疑)。

螢幕快照 2013-04-29 下午10.06.28

鄉民甲:這個簡單啊,我Java用了那麼多年了,try-catch-finally熟的很。

Teddy:既然你那麼熟,可以談一下catch的責任嗎?

鄉民甲:catch就是把例外抓起來啊,然後作例外處理。

Teddy:可以說的再精確一點嗎?

鄉民甲:已經很精確了啊,不然你是要怎樣啦!

Teddy:看一下下面這張投影片,思考一下你對於try-catch-finally的理解和Teddy的理解是否一樣。

螢幕快照 2013-04-29 下午10.17.33

***

要判斷一個例外是否為一個可修復的狀況,是例外「處理」的第一個步驟,但是這個判斷並不是一件容易的事。確定了例外的recoverability之後,接著可利用程式語言構件與軟體元件的協助來實作例外處理程式碼。

***

友藏內心獨白:用力讀,讀懂就賺到了。

2013年5月1日 星期三

為什麼例外處理那麼難(2):設計觀點

Apr. 29 16:40~17:42

image

上一集提到例外使用觀點,今天介紹例外處理的設計觀點。

***

Design View(設計觀點)

今天早上看到一則新聞,大意是說對岸駭客可能會將入侵目標轉向台灣,對台灣國防、政治、經濟安全造成危害。記者電話訪問了某警察單位…

記者:對於對岸駭客可能會入侵台灣一事警察單位有什麼因應之道?

警察:我們主要還是要看有沒有人報案,有人報案我們就會處理。

Teddy內心獨白:靠…過一來點…「有人報案我們就會處理」這是哪招,會不會太消極了一點?

***

專案經理:對於我們產品品質不佳,bug很多一事團隊有何因應之道?

程式設計師:我們主要還是要看有沒有人報案回報bug,有人回報我們就會處理。

Teddy內心獨白:以上對話好像在那裡聽過挑眉質疑。

***

以上對話和例外處理有何關係?對於例外處理的看法,其實開發人員和警察杯杯的想法很像:「只要有人報案,我們就會處理」。在程式中要如何「報案」?很簡單,就是回報一個例外。從設計(compile-time)的角度來看,例外的回報有以下兩種形式:

  • Declared:
    • 例外有宣告在元件的介面規範中
    • 又稱為anticipated或expected例外
    • 代表component fault
  • Undeclared:
    • 例外沒有宣告在元件的介面規範中
    • 又稱為unanticipated或unexpected例外
    • 代表design fault

看一個例子Java程式例子。IllegalArgumentException在下圖上方的程式碼中是屬於undeclared exception,因為它沒有被宣告在deposit()介面上面。反之,下方程式碼的IllegalArgumentException是屬於declared exception,理由當然是它有被宣告在deposit()介面上。

螢幕快照 2013-04-29 下午5.22.44

***

就好像如果沒有人報案警察不知如何因應是一樣的道理,唯有將例外宣告在介面上(或以某種形式存在程式或文件中),在設計階段程式設計師才有機會知道要如何來因應可能會遭遇到的異常狀況。嚴格來講,要求開發人員去處理undeclared例外,已非例外處理的範疇,而是屬於「容錯設計」的議題,這比例外處理要困難許多。

***

友藏內心獨白:區分例外處理和容錯設計是有意義的。