灰色後門

前陣子有個需求是開發數字轉文字的功能 有來自中文使用者的客戶，也有來自其他外語客戶提出 問了法國人同事，法國裡面也有這樣的使用概念 所以應該是商業流程裡面有少部分場景需要此用法

最近做功能時，發現有個已經廣泛被支援的 CSS 選擇器  :empty 滿好用的 :empty 符合的是沒有任何子節點的元素 只要裡面有空白、換行符號等就不符合 :empty selector comment 則是唯一不影響比對規則的內容 這個選擇器非常適合拿來做預設外觀，或是相對的用途

雖然 Java 現在已經有很強大的 GC (特別是Java 11後的 ZGC) Memory leak 依然是個 Java 開發者得了解的議題 Memory leak 並不只在寫出持續無法被回收的物件 若是段落內的流程正確，但設計時的尖峰使用量估計錯誤，也可能讓 JVM 運行時碰到 OOM 了解記憶體分析的流程才能將架構調整得更合適

使用 SourceTree 時為了方便性 基本上大家都會儲存連線主機的 host key 認證、使用者密碼 這樣才不會每次 commit 都要再輸入這些資訊 不過如果當 自架 git server 上的使用者密碼變更了，該怎麼處理呢?

去年幫一台 server 從 JDK6 升上 JDK 8 後，發現那台 server 的多數 hash 比對失效了 查了原因，發現問題出在那台的服務使用的一段處理 hash 的 legacy code

不知道大家現在還有沒有接到民國年轉換的需求 滿久以前偶爾會接到客戶寫信來問能不能做民國年的日期輸出或輸入 不過畢竟以前在處理上比較麻煩 最簡單的方式是請客戶分開資料欄位 分別產出民國跟西元年的資料，輸出時再依照需求組合出最終的字串 寫成常見Q&A之後就不大有需求信寄過來了

幾個月前碰過一次架來做內部 git server 的 VM 連不進去的問題 不只是 git 指令無法連線，連同 GCP 的網頁上的轉移至 SSH 也是無法使用 查詢網路資料後，可以看到 Google 寫了一篇文章，記錄此問題的常見原因 https://cloud.google.com/compute/docs/ssh-in-browser#ssherror 大概有些底後，透過啟用序列埠連線，我們還是能在 SSH 進不去的狀況下進到 console 台 結果一進去就看到了訊息  ...git-server-tw kernel: ... [UFW BLOCK] ... 下了指令解開防火牆  sudo ufw allow ssh 還好這次的狀況很簡單的就處理掉了 根據 Google 那篇文章，在記憶體/硬碟空間用完也可能碰到這狀況 處理流程： 用序列埠連線進入，針對可能的狀況查詢後排除

從仙台城跡望外的景色 最後一天的行程就在仙台內慢慢逛，晚上搭飛機回台灣 這趟東北行很幸運，10天的時間基本上天候都很好，旅遊要這樣是可遇不可求了

松島●楓開始紅的時節是11月初，所以在10月底來的時候還是綠的 就算綠色也是滿足的一天

Day8 是緊密的行程的一天，也是這趟最後一次會這樣玩的一天 為了在一次旅程中收集完東北的100名城，考慮過後決定這天衝完三城

山形的這天的行程，因為我的貪心，所以是行程上比較密集的一天

完成北東北的行程之後要開始往南跑剩餘的縣，規劃的目標接著是山形縣 話雖如此，當初想著秋田緊鄰著山形，接下來應該可以直接往南走吧 查了鐵道支線地圖後才發現，JR東日本並沒有這樣直接的路線 東北的JR建設是以仙台為中心延展的，所以得先走一趟往仙台的行程 這一天的行程就決定是前往仙台過程中，會經過的有數個世界遺產的平泉

從弘前前往秋田的交通時間比較長 所以為了盡量有比較長的日間觀光時間 這天一早搭乘奧羽本線，6:25弘前出發，8:43到達秋田的車次

這天預定的行程就是為了蔦沼而做好了彈性選擇 不過老實說這天要出發前還是一直在猶豫😅 天氣預報顯示良好，但這季節早上4點多的時候天色還是一片漆黑 而且起床時賴床也是人之常情..咳，想到要走6公里多還是有些發懶 不過既然都到這玩了，未來也不見得有多少次能有比這次更好的狀況來看蔦沼朝燒 有時候旅行還是得有些衝動跟決心才能夠玩得更開心，最後還是決定拿出毅力出發了

這天的行程是這趟少數跟城一點都沒關係的一天 拜旅遊節目跟日旅風氣旺盛，奧入瀨溪現在在台灣已經是頗有名氣 豐富的自然與豐沛的水量讓這個地方的景觀獨樹一格 四季都有不同變化的奧入瀨溪在秋季更是知名的賞紅葉景點 火紅的世界裡夾雜陣陣激起的水花，美麗的景色讓人著迷

這天要由南往北共走遍3座城，做好準備就衝了 首先一早就到櫃台將行李配送到第三天入住的奧入瀨的旅館 這個考量原因是東北廣大，點跟點的距離長 當然原因也是我是刻意要在一趟行程中用 JR 走遍日本東北各縣的名城 如果沒有這樣的企圖，集中在想玩的縣也是一個選擇 (或是開車也不用煩惱行李攜帶)

這趟旅行因為一些原因，時間只能在這附近選擇 左看右看大約是日本東北比較有機會碰到當地的精采季節，楓葉季 於是就迅速決定目的地了 另外加入了個人興趣的日本名城探索，工程師就是要攻城啊(亂講 因為是一人旅，所以有些行程安排能排得比較勉強，會是跟團體旅行不同走向的內容

用完早餐後先來逛有名的函館朝市啦

這天我們還沒有要這麼快告別登別 登別除了地獄谷跟泡湯外，還有熊牧場、海洋公園跟這天要去的伊達時代村

從這天開始要回程往函館方向走了 接著到登別這個北海道有名的溫泉鄉玩

這天是旭川雪祭的最後一天 另外是平常下午結束就關園的旭川動物園也會配合旭川雪祭在晚上進行點燈 一年裡只有這一段時間會舉行的活動  "雪あかりの動物園" 會開放到晚上 在雪祭期間也很適合拉行程到旭川一趟喔

這天上半天繼續在札幌看雪祭 先貼上 Xi...阿不是 是小熊維尼的雪雕照片

這天開始就要往札幌跑雪祭行程

這趟旅程是搭乘虎航來回函館並參觀雪祭的行程 雖然冬季的北海道雖然多半屬淡季，不過碰上雪祭期間就不同了 作為世界知名的冬季節慶，從各地湧入北海道的遊客眾多 以及雪祭舉辦期間也很常碰上華人的年假期間，總之就是人暴多 趁著目前家族到雪地遊玩還沒太大擔憂 以及想體驗世界知名節慶跟下雪 整體規劃跟成行約在前一年的8月中後決定的

去年 2018 過年想有些新意 所以跟家人安排了一趟北海道過年自助旅行 雖然前年也有過跟家人一起到北海道自助旅行 不過跟夏季的經驗是截然不同的，相同點只有都是美好的經驗 對台灣日常生活難得體驗雪國日常的我們，也有了很多不同的準備跟體會

相信很多 Web 開發人員在 local 的開發環境用的設定跟產品一樣是 HTTPS 不過畢竟 production 用的 TLS  certificate 不是簽給 localhost 用的 所以若沒調整則在瀏覽器會看到 Your connection is not private 的訊息 Chrome 的網址列也會顯示連線不安全 這個當然不是什麼問題，點個忽略警告大家還是可以照常開發 不過開發人員也可以選擇在 local 產生一張簽給 localhost 的 self-signed certificate 調整過後可以從此不需要再去點忽視警告 然後開發時看到的瀏覽器網址列的提示也會是安全連線，視覺爽度加分 這篇說明怎麼在 Windows 環境生效，以下開始步驟

現在 HTTPS 已經是網站的標準要求了 如果不想花錢買付費憑證，那麼免費的 Let's Encrypt 是個很好的選擇 以下紀錄如何在 Linux 完成憑證申請，並且套用自動更新

這是偶然間看到的一篇文章 The Hidden Dangers You Have Never Noticed: target = "_blank" and "opener" 並進而找到討論這篇文章的 reddit 討論串 我一開始以為是英文閱讀，所以讓我沒有完全了解原文的感覺 不過看了 reddit 串也是很多人覺得作者的表達能力不好 XD 所以我覺得直接看 reddit 串中的其他人的討論跟摘要會更直接 簡單來說，可能導致的風險是讓使用者導入到偽造的釣魚網站 因為瀏覽器的跨網域保護政策 所以連結網頁中的 window.opener 只有受限的操作權力 目前的主流瀏覽器已經在這方面提供夠好的保護力 只不過在這有限的操作範圍中， opener 可以調用 location object 並操作 惡意的連結網頁藉此把原網頁跳轉到相似度極高的惡意釣魚網站 使用者關掉連結網頁後，很有可能沒注意到他回頭看的已經不是原本網頁而受害 所以如果開發者允許用戶用 target = _blank  的方式到外部連結 最好得加上防範措施免得夜長夢多 原文跟 reddit 串有不少考量的理由的說明，以下直接講建議方式 <a href="https://an.evil.site" target=" _blank " rel=" noopener noreferrer nofollow ">... 如果要用 JavaScript 開啟的話則是 var newTab = window.open(); newTab.opener = null; newTab.location = url;

Chrome Dev tool 隨著開發演進也增加了很多方便的功能 overrides 是最近發現好用的功能之一 官方說明 https://developers.google.com/web/updates/2018/01/devtools#overrides 有時候會一些網頁錯誤的原因可能是網路因素 如果這錯誤是網頁一載進來就會發生 而且又不好在 local 重現，那麼在過去還真是不好處理 過去的常見做法可能是我們撰寫用 setTimeout 模擬延遲的程式 只是缺點是： 1. 用猜測的參數撰寫的模擬並不能完全表示出實際狀況，所以不一定能解決實際問題 2. 撰寫模擬的 code 有可能會很多且複雜 Chrome 在 65 版後加入這個功能 讓我們可以在實際的線上環境中套用自己的修改測試問題 直接面對實際狀況比過去的方式好用多了 啟用步驟可以直接看Google文章的說明 在 Google dev tool 的 source 頁籤裡的子頁籤的 Page / FileSystem 那邊多了一個子頁籤 overrides 選擇並給予 Chrome 權限能存取並建立修改紀錄在指定的 local 檔案 記得把 Enable Local Overrides 打勾後就能正式啟用 source 裡能修改，完成後按 ctrl + s 儲存變更 之後即使頁面重新整理，Chrome也會使用編輯後的 code 替代原始內容 如此就能用來驗證錯誤的原因跟找出合適的處理方法了