幾天前在網站上看到Edinman寫的一篇新竹縣 羅馬公路 + 石門水庫，覺得這樣的行程蠻不錯的，且其中的路口指標亦標示的相當清楚，所以就利用今天休假的時間，偕同姊夫來一趟勇闖羅馬公路的旅程。

整個旅程由0930從Edinman推薦的停車場出發，到1600騎回出發點，總計約騎了73.5公里。騎乘的過程相當順利，唯一的憾事是忘了在「羅馬公路」入口出拍一張以玆證明的照片，不過還好的是至少在羅、馬兩個村落都還有證明照，不然別人還以為這次的網誌是呼巄的。

整個行程花的時間及里程與上次的單車北宜公路一日遊相差不多，但我覺得北宜比較硬，因為羅馬公路比較多的上、下起伏，不像北宜幾乎都是上上上。

行進方向的小撇步：
  1. 從出發點開始沿著118縣道走
  2. 「羅馬公路」走完後至羅浮後，朝著大溪方向前進
  3. 百吉隧道口左轉往石門水庫方向
  4. 進入水庫區後，記得往右邊的龍珠灣方向，就是往大壩方向。這裡我差一點走錯，走錯就完了，因為走錯多少，就要回頭走多少!!
  5. 進入大壩後，下滑出大壩往關西方向
羅馬公路簡介：
-
羅馬公路東起桃園縣羅浮，西至新竹縣馬武督，全長35.7公里，俗稱「羅馬公路」。在單車界裏，這條公路算是經典級路線。

從錦山到羅浮路段，建築可見到原住民與客家人融合的景象，是因為從前客家人與原住民在這裡爭地生存的關係，所以這一段公路的景點也富有多樣風情，有新興的綠光小學、金鳥海族樂園、統一健康世界等，除了可以夜遊之外也很適合全家做為周休二日渡假的好去處。

沿著羅馬公路直行，可以抵達羅浮，在此處的景點以山區風景為主，有石門水庫、小烏來瀑布、三民蝙蝠洞、復興吊橋等。因為這條路線並沒有得到完全的開發，所以天然景觀方面還未遭到人為的破壞，而人文方面，至今還保留著頗為原始的風貌，客家人好客，山地人純樸，在這裡都讓您感受。
-


這次行程的路線圖

阿舍



今天在商周看到一個「黑天鵝理論」的詞，仔細找了網路才知道他的理論為何。
--
以前的歐洲只有白天鵝，所以歐洲人沒有見過黑天鵝，「所有的天鵝都是白的」就成了一個沒有人懷疑的事實，一直到人們在澳大利亞發現黑天鵝，歐洲人的想法因此一百八十度翻轉，黑天鵝也變成了不吉利的象徵，像是我們所說的烏鴉一樣。
這種翻轉，會造成人們心理很劇烈的震盪，因為「所有的天鵝都是白的」有數萬隻的白天鵝作證，但是要推翻它，只需要一隻黑天鵝就足夠了。也就是說，人們所習慣相信的信念、所樂觀看待的事件，有可能是錯的，而我們從未思考過「
它是錯的」所造成的後果，我們期待的破滅，竟是如此之輕易。

一般人總是只相信他所想要的、他所預期的發展，以致於忽略了世界往往不按照我們的期待走，等到發生了一出乎意料的重大事件，我們原本賴以支撐的假設，便一夕之間全部崩潰。

按讚分享本篇內容給更多的朋友：

按讚加入「阿舍的精彩生活」Facebook粉絲團：

阿舍

問題：open方法的第一個參數不論寫"GET"或是"POST"，在Process裡都是調用的doPost方法？為什麼不調用doGet方法？
答案：按照哪種方式提交不是由open()方法的第一個參數完全決定的，還與send()方法有關。

一、當open()方法裡指定的是GET，並且
1、send()方法的參數是""或者null，跟踪代碼可以知道調用了Servlet中的doGet方法
2、send()方法的參數是地址重寫的方式，或者就是一個字符串，都調用doPost方法，例如：
xmlHttp.open("GET", "ProcessServlet?choose="+document.getElementById("choosejsfile").value, true);//open裡調用GET方法。
xmlHttp.send("aaa=dd"); //a
xmlHttp.send("paramTest"); //b
xmlHttp.send(" "); //c
xmlHttp.send(null); //d
xmlHttp.send(""); //e
對於a、b、c、d、e五中send()函數，只有d和e會調用doGet方法，a、b、c三種方式均調用doPost方法。

二、當open()方法裡指定的是POST，則對於以上5種send()函數，服務器均會調用doPost方法。
所以使用哪種方式提交是由open方法和send方法共同決定的。

xmlhttp:open方法創建一個新的http請求，並指定此請求的方法、URL以及驗證信息語法
oXMLHttpRequest.open(bstrMethod, bstrUrl, varAsync, bstrUser, bstrPassword); oXMLHttpRequest.open(bstrMethod,bstrUrl,varAsync,bstrUser,bstrPassword);
參數
bstrMethod
http方法，例如：POST、GET、PUT及PROPFIND。 http方法，例如：POST、GET、PUT及PROPFIND。大小寫不敏感。
/*****
POST：用"POST"方式發送數據,可以大到4MB
GET：用"GET"方式發送數據,只能256KB
如果請求帶有參數的化實用POST方式，POST方式將參數放置在頁面的隱藏控件內沒有參數使用GET方式對於請求的頁面在中途可能發生更改的，也最好用POST方式用GET方式可能會拿不到最新的信息
*****/
bstrUrl
請求的URL地址，可以為絕對地址也可以為相對地址。
varAsync[可選]
布爾型，指定此請求是否為異步方式，默認為true。如果為真，當狀態改變時會調用onreadystatechange屬性指定的回調函數。
bstrUser[可選]
如果服務器需要驗證，此處指定用戶名，如果未指定，當服務器需要驗證時，會彈出驗證窗口。
bstrPassword[可選]
驗證信息中的密碼部分，如果用戶名為空，則此值將被忽略。

阿舍

何謂TraceMonkey
TraceMonkey的名稱來自於Mozilla的JavaScript解析引擎－SpiderMonkey與加州大學教授Andreas Gal等人所提供的技術－tracing。Gal目前為TraceMonkey的專案領導人。

簡單來說，TraceMonkey是一套「即時編譯器」，可將程式語言即時編譯成機器語言丟給電腦執行。多數的桌面端程式均是屬於事先編譯好的二元機器碼(binary code)，但JavaScript是一種程序語言，通常是逐條執行，因此效能低落。

而即時編譯器(just-in-time compiler)則是當使用者瀏覽新網頁時，將網站傳送來的JavaScript碼編譯成二元機器碼，但TraceMonkey並非編譯所有送來的JavaScript碼，而在追蹤與記錄JavaScript程式執行後，TraceMonkey將會找出容易耗費大量執行時間的程式迴圈，然後再將這些迴圈編譯成可執行碼。

傳統的編譯器(compiler)設計用來編譯整支程式，將所有的程式動作全部編譯成可執行碼，因此編譯工作相當耗時耗力。而Tracing技術將會根據實際的程式執行動作，只編譯實際耗用電腦運算資源的程式碼。

透過濃縮(Concentration)特點，TraceMonkey不需要大量記憶體或是載入速度慢的外掛程式，因此也適合行動裝置使用，這也是未來Moziila的重要開發項目之一。

當然，改善Web應用程式還有許多空間，Mozilla下一步要改善DOM，這是瀏覽器用來描繪與處理網頁用的文件物件模組元件。

阿舍

Flash起於圖像概念而發展，Silverlight則起於程式概念而發展。
對程式設計師來說，Silverlight會比Flash來的容易上手，未來一旦Silverlight填補了圖像工具及增加中文輸入、網路能力，那麼其將成為新一代的RIA Web Application開發標準。

Silverlight 2.0不需要.NET Framework 3.0，她內建的SLR約4.6MB，完全提供了.NET Language所需要的功能，其雖繼承了WPF複雜度偏高的缺點，但可於瀏覽器上直接執行的優點，可以完全Cover掉這個缺陷。

Silverlight 2.0能做什麼是Flash做不到，或是AIR做不到的呢？
用Silverlight 2.0可以做出一套於IE上執行的進銷存、會計、人事薪資，而且UI介面的方便性可與Windows Forms比擬，而且對.NET程式設計師而言，操控Silverlight比起操控AIR來得輕鬆。而且最近的Silverlight Toolkit推出，證明了Silverlight在元件/控件上的架構，足以讓許多3rd Party廠商生產出很多簡單易用的控件。

阿舍

如果用 OpenID ，當你瀏覽的網站有支援 OpenID 的話，那你就不必再產生一組帳號密碼，直接用你的 OpenID 進行驗證登入。

OpenID 有幾個主要的角色：分別為 Provider, Consumer, 及 Server。

OpenID 的運作模式如下：

假設今天網站A是一個支援 OpenID 驗證的網站，那麼網站A算是一個「OpenID consumer」；而 Yahoo! 的帳號可以生成一個 OpenID，使用者可以拿著這個生成的 OpenID 到 OpenID consumer 去作驗證登入的動作，這樣 Yahoo! 就算是一個「OpenID provider」；但對 consumer 來說，使用者輸入的 OpenID 不一定長成什麼樣子（往往是 URL 形式），更沒辦法單靠這個字串判斷要把使用者導向何處（理論上是 provider 的登入畫面）作帳號密碼的驗證動作，所以 consumer 必須透過某個協定向「Server 」來問這樣的 OpenID 是否合法，以及要導向的網址。

像一個知名的圖片分享網站 — Zooomr 就是一個支援 OpenID 的網站（當然就是 consumer），當你試圖要登入 Zooomr 時，可以選擇以 OpenID 的方式登入，這時 Zooomr 會把你導向你的 OpenID provider 去作驗證（帳號密碼的輸入動作），如果驗證成功，那 Zooomr 就會信任這個驗證，開始讓你使用 Zooomr 的服務。

當然，即便 OpenID provider 愈來愈多，它們的會員帳號都成為 OpenID，但並不代表這些 OpenID 是相同的，簡而言之，由不同 provider 提供的 OpenID 就會被視為不同的 id，只不過它們有遵循 OpenID 的規格而已。但是對 consumer 而言，只要是遵守 OpenID 規格的 id 都可以進行驗證。

阿舍