能高越嶺道-於南華山眺望對面的能高主峰、與雲海 今年朋友邀約，又再度造訪能高越嶺道。有鑑於去年選假日造訪時，早上七點多屯原登山口就已經車滿為患、車位難求。大夥怕難停車、最後決定選擇非假日造訪，並於前一晚先住在廬山一帶的溫泉，以便於隔天可以早點到屯原登山口。 出發前台北還下者雨、到廬山住宿處時，老闆說廬山當天下午才開始飄雨，聽到此不經擔心這次的天氣…… 老闆知道我們是來登山的，還特別交代廚房早早就準備早餐。於是，我們一早吃完早餐後就朝屯原登山口出發。雖然是非假日，停車場內的空位已經不多。 只能說，選擇非假日造訪能高越嶺道登奇萊南峰、與南華山，有兩個好處，就是車子好停、天池山莊也好抽。

雪山369山莊前欣賞日出 今年再度造訪雪山，原訂的行程依舊如 去年 所安排。第一天到雪山登山口，晚上住七卡山莊。第二天到三六九山莊。第三天凌晨出發登頂，在雪山主峰看日出、然後下山、回家。 這樣的行程，第二天有點鬆散。去年下午一點多就到了三六九山莊，整個下午就只能待在山屋、打發時間。但第三天就有點累。特別是下山後負責開車的人…因為由早上兩點起床後，都無法休息，走完15公里山路後，還要繼續開車… 這次在七卡山莊準備晚餐時，聽到旁邊一位帶者兩位女兒爬雪山的爸爸在說明行程。一旁聽到他所安排的行程非常的好，於是臨時和同行者討論，變更行程照他所述的規劃走。他是這樣安排的… 第一天，下午到雪山登山口，趁天黑前抵達七卡山莊。吃晚餐 第二天，清晨兩點起床、吃早餐，就直接攻頂。途經三六九山莊時放下重裝。夜宿三六九山莊 第三天，睡到自然醒、下山 這樣安排行程，雖然第二天稍微累一些，但是第三天可以睡到自然醒，少了凌晨登頂也就可以提早下山。早點回到登山口，開車的人也比較不辛苦。還有時間在經過宜蘭礁溪時順便泡泡溫泉～ :D

對於 Google 代碼管理工具 （Google Tag Manager，簡稱GTM）這套工具，原本以為只是一個各種追蹤系統程式碼的管理工具，用於降低每次需要於網頁、APP增加追蹤碼時的處理成本。直到今年九月，花了幾個小時看了一下 GTM官方文件 ，才瞭解 GTM 並非如此簡單，而是個個功能強大、神奇的工具。 舉個例子，以往於各網頁中所撰寫GoogleAnalytcis event的javascript，改成 GTM 後，居然只需要簡單的設定即可完成。『幾乎』可以不需在到網頁中寫GA的javascript。當然，複雜的運用，如 電子商務追蹤 還是躲不掉寫javascrip。但和傳統作法相比，還是簡單很多～ 當時想找個範例來練習一下 GTM 。有鑑於這個blog的流量來源幾乎以organic search為大宗，且跳出率很高。於是，想瞭解訪客是真的看完文章才離開？還是進入後馬上就離開？於是就用此疑惑作為練習～ 當時採用了 GTM 中的timer配合trigger方式處理，藉此得到訪客於文章的停留時間，作為評斷是否有看文章的依據。這樣做法產生的數據、event比預期中多了太多，不利分析。（卻也發現，有人就是不關電腦，難怪現在電力越來越吃緊，還是無法避免核四，大家應該隨手節約能源呀） 於是找了一下替代方案，改用 Scroll Depth 這個Google Analytics plugin。他的使用方式很簡單，可以參考這篇文章- Track Scroll Depth Using Google Tag Manager 。

軍艦岩，遠方為文化大學 想找個交通便利的郊山走走，何謂交通便利？想了想還是選擇台北捷運沿線的登山步道。最後選了很有名氣，卻一直都沒去過的軍艦岩親山步道。 這次的路線，預計由捷運石牌站出發，穿越陽明大學校區，先到到唭哩岸山、後到軍艦岩、照明寺、弘法大師紀念碑、再經丹鳳山、陳濟棠將軍之墓、終點到北投捷運站。 說也奇怪，也曾多次進出捷運石牌站，卻從未注意過立在進出口處的漢番界碑，直到行前尋找資料規劃路線時才注意到。 石牌 碑文內容為「奉憲分府曾批斷東勢田南勢园歸番管業界」 漢番界碑在台灣還蠻多的，去年去屏東 涼山瀑布步道 ，途經老埤，就有一個封禁古令埔界碑。不難想像當時的原住民生活範圍一直被當年"努力"開墾的漢人所壓縮………

之前一直注意到有個系統的錯誤log中斷斷續續出現如下的錯誤資訊。由錯誤研判，應該是放進memcache的內容有使用 Igbinary 。但是取出時，卻沒做對應的處理。 Severity: Warning --> Memcached::get(): could not unserialize value, no igbinary support /xxx/xxx.php 曾請當時負責維護的苦主同事查看，得到的答案是程式中並沒有使用 igbinary 。 最近在協助查另一個問題時，卻間接找到這個問題發生原因……

去年導入一個新專案時，因考量需要比key:value更複雜的模式，最後捨棄常用的memcache改用redis這套nosql。 和memcache相比，redis無論是功能、相關設定與需要注意的事項都複雜很多。 當初導入redis時，就曾考慮是否需要啟用其認證機制。但只要多花點時間瞭解redis的架構，不經讓人覺得redis的認證機制有點雞肋而暫時不啟用。 畢竟redis是單執行緒(Redis is single threaded)，因此無法做延遲的處理。加上redis號稱每秒可處理500k的request，如果有心人士利用暴力法，應該不難打出密碼。 設定的重點，應該是啟動服務時不使用root，並設定好網路環境，避免外部可直接存取、及變更重要指令的名子等等…。 雖然說覺得redis認證機制雞肋，但最後考量能多層保護就多一層保護，最近還是調整設定、與程式，啟用了認證機制。 沒想到，cacti就無法正常取得redis的狀態了……

夢幻湖雪景 林宗聖 先生的著作 陽明山十大傳奇 中，傳奇之四為寒冬山雪。裡面的照片，無論是竹子山、竹子湖、七星公園、大屯鞍部觀測所、夢幻湖、冷水坑、七股山都是一片雪白。 雖然將近20年前，也曾經因為下雪特別去過一次大屯山。那次的記憶，其實只有塞車…由山下塞到山上、由山上塞到山下。雪呢？記得當時積雪幾乎沒有了，可能都被先前下山的遊客挖到車上變成了雪人吧～ 畢竟，那時下山的車，車頂上都會有個小雪人～ 陽明山十大傳奇 書中照片的場景，我從未見過… 這20年來，科技的發達、工業的進步，人類讓這地球是越來越溫暖，天氣是一年比一年熱…現在的冬天，似乎也沒小時候記憶中的冷了…陽明山下雪？似乎很少發生了…這些年，如果想在大台北地區賞雪，都是趁強烈寒流時，跑去 北插天山 ，才有機會看到。