眺望台北盆地＠大棟山 位於桃園龜山的大棟山，為台北盆地西邊一等三角點所在。第一次造訪時，山頂周圍都是被樹所包圍視野並不好，只有桃園方向的視野稍微好些。幾年前山頂放置了解說牌、建立了涼亭、停單車的設備，也把周圍的樹林做了整理，頓時就有了一等三角點應有的視野。 不經想起之前造訪 獅仔頭山隘勇線登山步道賞金毛杜鵑 。這條路線上會經過南方的一等三角點-獅仔頭山，不過，山頂上的視野也受到周遭高大樹木的影響。 台北近郊的五個一等三角點，還是以北方的七星山、和位於東北角的燦光寮山的視野最好。之前造訪 無耳茶壺山、半平山、燦光寮山 時遇到好天氣，燦光寮山山頂上360度的視野，真是令人懷念。 這次的行程，由多福步道，大同山北側登山口出發，上到光明產業道路，經過三角埔頂山、大同山青龍嶺、由大棟山第二登山口往大棟山。回程，改往關公嶺北天公方向，經基北步道、大棟山自然生態步道、北天宮，循產業道路回到青龍嶺、最後回到多福步道登山口。

三貂嶺瀑布群-有彩虹的合谷瀑布 好久沒走三貂嶺瀑布群了，趁者夏季即將結束的好天氣，由三貂嶺火車站出發，經三貂嶺瀑布群（合谷瀑布、摩天瀑布、琵琶洞瀑布 ），後接中坑古道、柴寮古道，最後到猴硐火車站坐火車。 離開三貂嶺火車站，忽然發現鐵軌旁已經架起了鐵網。不知是不是太多人直接穿越鐵道？不過，說真的…旁邊剛好是三貂嶺隧道，快車又不停靠三貂嶺站。穿越時遇到快車由隧道呼嘯而出，真的很危險。還是走地下道穿越吧！

大溝溪生態公園遠眺碧山巖 右前方山頭為鯉魚山 原本打算於九月初打算和大家走 候硐越嶺三貂嶺 這條路線。沒想到，遇到了颱風。當時看了天氣預報，決定延後一週。沒想到…颱風行進速度變慢，原訂日期當天卻是個非常適合爬山的好天氣… 颱風過後，又連續下了幾天的雨。顧及 候硐越嶺三貂嶺 有幾處攀岩，及沿途要跨過三次小溪，最後改去內湖的親山步道走走～ 大溝溪溪畔步道算是一條適合全家大小親子一起走的路線。由捷運大湖公園（一號出口）出發，循大湖山莊街一直走即可到達大溝溪親水公園。

今年農曆年後，親戚說他的Nexus 7壞了，狀況是只要關機後，就無法開機。他嘗試很久後，在無法開機的情況下，最後就淘汰它了… 原以為是他運氣不好（他買了兩台，只壞了一台），沒想到… 兩個月後我的Nexus 7的也出現類似的狀況。一旦關機或重開機，就可能開不了機。剛出現這狀況時，也許按電源鍵久一點，還是會開機。但…… 之後就越來越嚴重… 按電源鍵的時間、或嘗試次數變多… 知道這狀況後，當然就是要避免關機的狀況。但是… 要避免重開機就比較困難了。因為google不時會有Nexus 7的系統更新，一旦更新，無法避免的就是要重開機。 因此，在某天早晨更新 4.4.3 後，我的Nexus 7就無法開機了，無論我電源鍵按下多久… :( Nexus 7 android 4.4.3更新中

有些GPS應用的APP，可以讓我們自行設定GPS紀錄參數，來影響記錄的數量、精準度數量。當然，也不是每一套APP都有，以我常使用的幾個GPS軟體來說，這套GPS APP - SportyPal （ 之前介紹SportyPal的文章 ）就沒有提供。但，其實他是會依照我們選擇的運動種類，去調整紀錄GPS軌跡的設定。 設定GPS參數，有什麼影響嗎？ 一般來說，記錄的point越多，GPS軌跡檔會越大，但軌跡會越精準。然而，精準又有何用途？ 以我來說，有時會去造訪一些從未造訪過的山區。如果沒人帶路，自己會先準備前人的GPS軌跡，作為導航之用。以這次 經菜公坑瀑布上小觀音山西峰欣賞火山口 來說，可能是因為這條路比較少人走，由菜公坑瀑布轉往小觀音山西峰的路非常不明顯。所幸，之前所取得的GPS軌跡是屬於比較精準的，跟者軌跡走，就找到路了…

最近準備調整一些舊程式，於是在 Subversion 上新增四個版本庫(repository)，並設定了post-commit這個hook。當commit程式時，自動做到以下動作 程式update到 /codepath 這目錄 將目錄 /codepath ，同步到另一台主機 這四個版本庫的hook設定可說是完全一樣（程式路徑當然不同）。沒想到，居然遇到一個奇怪的狀況。這四個版本庫中，兩個hook完全如預期的正常運作。另外兩個，雖然會做第二步驟的同步，第一步驟的update卻沒執行。 重新查看一遍所有設定，確認除了目錄不同，其他設定都一樣。增加了SVN的log來追查問題，看來hook也有執行。到底發生了什麼問題？真是令人百思不得其解。 最後，同事使用了一種語法去取得錯誤的資訊來debug，終於找到了問題。特別記錄一下… 他於hook中，使用 2>&1 。將shell script的執行結果，無論是成功、或失敗的訊息，都導向指定的log中。範例如下… /usr/local/bin/svn update /codepath > /tmp/hook_test.log 2 >&1 /path/synccode.sh 看到錯誤的log，就知道問題所在。原來，有問題的那兩個版本庫，裡面含有中文檔名、或中文目錄名。這些檔案是採用big5編碼。因此，調整如下就恢復正常了。 export LC_CTYPE = "zh_TW.Big5" /usr/local/bin/svn update /codepath > /tmp/hook_test.log 2 >&1 /path/synccode.sh

同事提到一個問題，他的程式到memcache取資料時，都會出現如下的錯誤訊息… Memcached::get(): could not uncompress value 當下的第一個反應，先查看產生資料塞到memcache的程式，是否有開啟壓縮功能？ 查過後，確認程式有設定 Memcached::OPT_COMPRESSION 參數，關閉壓縮資料的功能（關掉壓縮功能，是為了和其他不能升級的系統相容 :(） 這就神奇了…明明有設定不壓縮，卻還是出現和壓縮有關的錯誤？ 抽絲剝繭後，不經懷疑是不是新版的memcache還是會自動壓縮？（ memcached 2.0 開始，有不少異動。有興趣可以參考 Changelog for memcached ）