今年讀完的第一本書《神明要我住嘉義》，看完之後覺得能把試著寫下來的東西貼出來。
特別喜歡嘉義異鄉人提到神明、廟宇與自己的記憶、情感連結時，她回憶小時候在臺北，跟著母親到廟中拜拜，也會特別觀察廟中的許多裝飾，總讓我有一種熟悉的感覺，細細回想後，才發現到自己也有類似的經驗。
繼續閱讀 “《神明要我住嘉義》讀後感想與我的回憶"《神明要我住嘉義》讀後感想與我的回憶
島內散步家將的家將工作坊
小時候鎮上廟會遊庄，時常會見到家將在長長的神明隊伍中，臉上畫著氣勢的臉譜、獨特的步伐與移動發出的響亮叮叮噹噹聲，都讓我印象深刻。
在 5 月多看到島內散步要舉辦有關家將的活動，後來就報名週末參加了島內散步的活動「搞懂家將工作坊」。家將主要是包含了「八家將」與「什家將」，他們是神旁邊的將領，簡單形容家將如同是神明出巡中的隨扈，成員也不一定是 8 個，老師分享了從家將由中國進到臺灣演變，分成不同地方的派別，產生出不同的特色與文化。
在上課前，先搬了家將的服飾、帽子、配件、草鞋等到上課教室排好，我當時手中謹慎的拿著廟會祭典上家將戴著的帽子，並可以近距離仔細端詳帽子上華麗的裝飾，在課程起初就這樣體驗家將文化，感到好雀躍。家將從一開始的準備到出巡都有很嚴謹的紀律，這些家將的東西擺放也有一套規定，每個人聽從老師的指示小心翼翼的把家將東西擺放在桌子、椅子上。
繼續閱讀 “島內散步家將的家將工作坊"加強 DNS 隱私
用了一段時間的 DNSCrypt，在前幾個月 DNSCrypt Proxy 的專案開發維護者－Frank Denis，忽然（其實也不是忽然，他在 Twitter 上也有事先貼文，只是沒有比專案直接不見鬧得大 😂）把 Github 專案移除後，在 Reddit 上也有需多討論，這中間經過有公司願意接手，但是過了幾天後，Frank Denis 開了新的 dnscrypt-proxy 專案，也就是第二版。
在這些日子，越來越多公司/組織也提供 DNS 加密的服務協定，從之前支持 DNSCrypt 專案的 OpenDNS 及 OpenNIC 專案中志願者提供的 DNSCrypt 服務外，還有 Google Public DNS 蠻早也支援 DNS-Over-HTTPS，到去年（2017 年）11 月 IBM 推出的 Quad9 支援 DNS-Over-TLS、12 月 Tenta 發表 Tenta DNS 支援 DNS-Over-TLS，也將 DNS 伺服器專案的程式碼開源，到了今年（2018 年），Cloudflare 也在 04/01 發布他們也提供 DNS 服務，並支援 DNS-Over-HTTPS 與 DNS-Over-TLS 兩個協定。
家人生病時，對社會福利/救助的想法
這篇文章我有先張貼在 PTT 社工（ 板，注意：有點長，分成幾個部分，小心閱讀（誤），自己也很少在網路上分享家裡的生活，會想寫出這篇，是因為在經歷這一連串的事情，及了解社會褔利/救助後有些看法，想分享出來，下面的內容跟在 PTT 上的貼文會有些修改，像是加上連結等。
（正文開始 ）
近期外公生病住院，由於外公家裡的原因，只有媽媽自己一個在照顧外公，媽媽每天都在煩惱錢不夠，與外公出院照顧後的照顧與費用不知道該怎麼辦。外公家裡生活也不好，他有領身心障礙手冊，出院之後應該會暫時在機構照顧。
社會福利資源取得方式
在過程中，了解是不是能協助外公申請政府的社會救助/福利，從一開始鄉公所的社會科（態度沒很喜歡）、村辦公室（很熱心）、醫院社工（謝謝社工幫助我們，也很有耐心跟媽媽多次說明、解釋許多事情，媽媽很常有聽沒懂）、1957 社會福利專線（很專業的專線，而且能協助我們解決許多疑問）、縣政府社會處（謝謝你們，一直幫我轉接給負責人 XD）、家庭照顧者關懷總會（網站有很多資訊，也感謝幫我們提供長照專線的資源）、1966 長照專線（很熱心的協助我們諮詢）、衛福部、台中市衛生局（幫我們解決喘息照顧跨縣市的問題）等等的。
你我正在被追蹤？
這陣子（2018/03）Facebook、 Cambridge Analytica 與前次美國總統大選川普的的事件，在網路上，幾乎每天都有新的新聞，一早打開 Hacker News 都能看到相關事件的文章都是排名在前面，這件事情在 2017 年就好像已經被報導，在 3 月份，有吹哨者站出來後事件開始引起越多人討論、注意。之後開始陸續有知名的公司、組織、名人站出來，像是 Elon Musk 刪除了 SpaceX、Tesla 的粉絲頁面、Mozilla 停止在 Facebook 上投放廣告，也有人從 Facebook 下載自己的資料時，發現 Facebook 竟然蒐集了這麼多關於自己的資料，像是手機上撥出、接收電話的記錄。
下面分享一下自己的想法，這個事件上，自已也沒有很認真地爬許多文章，有些看了也是掃一掃內容。
Facebook 中的第三方應用程式
Facebook 與 Cambridge Analytica 的關係就目前看起來是 Cambridge Analytica 在這之前，透過一款心理測驗的應用程式來取得使用者的資料，而當時 Facebook 使用的 Graph API，除了可以讓應用程式取得允許的使用者資料外，還包括了他的朋友，所以導致 Cambridge Analytica 在一次可以取得多人的資料，這讓人想到，常常在 Facebook 上看到蠻多人會使用一些應用程式，像是可能"有趣的互動"…
在使用這個應用程式前，你可能會需要透過你的 Facebook 帳號來登入，就像是：
應該蠻多人會直接點下很明顯的「以 XX 的身份繼續」亮藍色按鈕，因為這樣才能繼續使用這個應用程式，不過，當按下「以 XX 的身份繼續」後，就表示應用程式可以從 Facebook 取得你所同意的資料，以這個例子，Vonvon 應用程式能取得你的姓名、大頭貼照、年齡、性別跟你所公開的資訊，另外還包括在 Facebook 中上傳以及被標註的照片、電子郵件。
到 Vonvon 的網站會看到有許多各式各樣的應用程式，為什麼 VonVon 要開發這些所謂有趣的應用程式？這應該可以從 VonVon 關於頁面 https://tw.vonvon.me/about 得知是做分析資料販售的，至於是不是會把可以識別出個人（也就是知道是你是誰）的資料售出？在他們的隱私權政策的第 5 點有提到是不會 “Otherwise, we will never sell or disclose user data to a third party in a personally identifiable way.“，當然，這也希望 Vonvon 能夠守信用 XDD，只不過在這次 Facebook 與 Cambridge Analytica 的事件後，使用這類型的應用程式能更再思考幾秒，真的要把你的資料授權給第三方使用嗎？ 繼續閱讀 “你我正在被追蹤？"
阻擋廣告與被追蹤
目前網路上，充滿許多廣告，從網頁（Web）到行動裝置的應用程式（App），可能當你上了某個購物或商店的網站瀏覽商品後，再進入一些放置廣告的網站瀏覽時，會出現剛剛瀏覽過或是同類型的產品。除了很討厭見到廣告內容外，在行動裝置上更是會使用到可觀的行動網路流量，更重要的是，讓廣告商們能夠追蹤自己的瀏覽記錄與喜好等。Chrome 在今年（2018 年）二月加入了廣告過濾（AD Filtering），Google 在 Chrome 瀏覽器中，加入廣告過濾主要並不是想要保護使用者的隱私，因為使用者看不到廣告，與使用者不被追蹤是兩回事，沒看到廣告不表示你沒被追蹤。
下面會分享，自己目前或使用過的阻擋廣告、追蹤的方式與軟體（皆是開源的），主要分成瀏覽器、行動裝置端與其他。
瀏覽器端
在瀏覽器上瀏覽網頁，是透過 JavaScript 載入執行的程式，來顯示廣告或追蹤你點擊、瀏覽過的網頁，常見防止廣告與第三方追蹤的方式是阻擋特定的 JavaScript 檔案或特定的域名，來避免瀏覽器執行這些 JavaScript，或向特定域名送出 HTTP/HTTPS 請求。
uBlock Origin
uBlock Origin 廣泛來說，並不是完全來阻擋廣告與被追蹤的工具，它提供了多種阻擋規則，包含了請求類型、主機名稱、網址、HTML DOM 等，也能利用正規表示式（regular expression）等來撰寫阻擋規則。（注意：uBlock Origin 與 uBlock 是不同的，可以從 logo 圖案來區分）
uBlock Origin 專案原始碼：https://github.com/gorhill/uBlock
如果你是 Firefox 瀏覽器使用者，請從 Firefox Add-on 安裝；如果你是 Chromium/Chrome 瀏覽器使用者請從 Chrome 線上應用程式商店安裝。
uBlock Origin 支援許多瀏覽器，像是 Firefox、Chrome、Safari 等，只要在瀏覽器內，安裝 uBlock Origin 擴充套件後就能使用，uBlock Origin 中也包含了許多的阻擋清單，讓你依照自己的需求，如阻擋的類型，或依照國家內常見的廣告與追蹤來阻擋。
uBlock logo 取自 Raymond Hill (@gorhill) https://github.com/gorhill/uBlock/blob/master/doc/img/ublock-16.svg，以公眾領域（CC0）釋出
Drupal 與 Laravel
在爬文章的時候看到一則是討論 Drupal 8 與 Laravel－Drupal Vs. Laravel，看到當天晚上就把一些想法發表回應到文章下面，可是作者遲遲還沒有允許張貼，這幾天一樣跑去看那篇文章看，還是沒被公開發佈，就先把回應寫在自己的部落格上。（現在，作者已經公布了）
以下是我回應給作者的內容（有改了一些拼字、文法錯誤…）
Berfore starting to build and develop Drupal sites for over 1 year, I use Laravel framework. I think in some website types, eg. media and content, Drupal is more suitable. Because, in Drupal 7/8, the ImageStyle is powerful, it can process different image size for different device screens. Especially, in Drupal 8, the cache system allows to control the cache of page easily and flexible.
In the beginning of developing Drupal 7, I cannot accept and realize the configurations are in database. Although, the features module can help export the configs into code. Sometimes, when deploying into production or stage site, the exported features may break or encounter the different tid. In Laravel, all configs are in code. When deploying, developers only pull the branch and set the config values into environment variables.
Sometimes, I hate to take much time to work on the customized displays or modifying forms in Drupal, since in Laravel or others development, I only need to change HTML or blade. In Drupal, I should implement hook functions to alter rener array or Form API.
BTW, I prefer Drupal 8, due to OO design, new config management, service container, plugins system, event listener, routing and so on. They provides more structural ways to maintain and develop.
The Effective Engineer 儘早、經常的驗證想法
最近時常想到 The Effective Engineer 裡面有一章提到的－Validate Your Ideas Early and Often（隨便翻：儘早、經常的驗證想法），介紹的第一個例子是曾經有一家可能被視為 Google 搜尋引擎競爭者的公司 Cuil，當時宣稱有超過 12 億的網頁被索引，是 Google 的 3 倍多，Cuil 也是花了幾年的時間在開發爬蟲、索引，因為當時（約 2008 年）沒有普遍的雲端主機服務像 AWS，所以也自己利用硬體資源建立幾千台的伺服器 infrastructure。但是他們在發表之後遭受許多知名媒體的批評，像是 PC Magazine 用了 “buggy”, “slow", “pathetic" 的字來形容，在上線的時候，Cuil 的服務遇到了多次當機，最後，Cuil 失敗了。
書中提到幾點 Cuil 失敗的原因：
- 沒有雇用 alpha 測試者來試用產品
- 因為當時 Cuil 擔心發表的內容會被洩漏出去，所以他們也沒有像公司外面取得 feedback 來指出搜尋結果的問題
- 與 Google 相比，Google 花了很多心力在處理為了高搜尋排名的垃圾網站（按：現在卻一堆內容農場…），但是 Cuil 沒有任何人在處理這個部分
看到 Cuil 的經歷與書中提到的幾點問題，簡單來說有一點是他們沒有在開發產品時盡快的驗證產品的做法是不是有問題，需要調整的地方。
之前的工作，其中有一個專案是開發管理志工的系統，自己花了很多力氣在系統開發，默默地寫了實作程式、測試程式、建立自動化的腳本，把開發流程跟 CI 結合，完成後，老闆才發現需要修改與實作的功能不是他們想要的。回想那段時間，當每週開會，老闆問到專案進度，只是告訴老闆完成了哪些部分，或正在開發、快完成了，到接近預計時間，才把自己認為完成的成果給老闆或同事看，在那個時候，才發現在實做出來的功能或做法，跟其他人原本認爲的完全不一樣。過一陣子回想起來，在每週開會的時候，要向老闆 demo 開發的功能，來確認實作的功能是不是走在正確的軌道上，也能夠讓老闆對完成後的系統有更清楚的了解。
中國上海四天三夜
3 月中的時候到上海待了四天三夜，來紀錄一下這幾天的感受。推薦行程在網路上應該可以查到很多，所以不細寫行程，會紀錄發生的一些事情跟感想。
食物
先分享上海的食物，在網路上搜尋的話，應該會發現很多小籠包、煎包之類的店，這幾天吃過了幾家分別有：
南翔饅頭店
在豫園附近的南翔饅頭店，可以「打包」（臺灣用語：外帶）與內用，當天排隊很長，我們選擇外帶，在點餐的時候，有分結帳、取餐的窗口，結帳的店員會敲打窗戶旁邊，感覺會像是叫客人快點餐、付錢，感受蠻差的。
點了蟹黃灌湯包、鮮肉小籠，自己比較喜歡第一個蟹黃灌湯包，是吸管插在包子內，吸裡面的湯汁，第二個沒那麼喜歡是因為，在上海吃包子蠻多人會加醋，完全沒辦法接受當地醋的味道。 繼續閱讀 “中國上海四天三夜"
開源的 IndicatorBarView-Android UI 元件
專案網址：https://github.com/ymhuang0808/IndicatorBarView-Android
授權：Apache License Version 2.0
為什麼開發？
這是自己的第一個 Android 開源專案，會建立這一個專案是因為自己的另外一個開源專案要用到數值指針的 UI component (謎之音：那個專案還躺在電腦中…)，簡單說有點像溫度計，但是，沒有找到合適的 component。想了之後，先把這個 UI component 先開源出來好了，不過，還有蠻多事情還沒完成的 (請看 TODO)，只是開源出來，能逼自己快點把這個專案弄得更成熟，或許也有更厲害的人能貢獻，這樣就自己不用寫太多了 (誤)
躺了超久的專案
如果去看 commit log 的話，會發現從 2016 年 08 月底就在動了，過了半年才有個雛形 (都已經從 Android 7.0 到 7.1.1 了)。
記得大學時候的專題，還一度想自己寫 Android 的 custom view，但是當初對 Android、Java 的熟捻程度還不夠，一直沒踏出第一步。寫 custom view 自己覺得還蠻苦的 XDD，尤其是 debug 的時候，經常遇到 Canvas, Paint 有執行，但是在 App 中就是沒出現，後來才發現，經常是 Canvas 指定的 x, y 值超出螢幕視線外，還有是 Paint 的顏色是白色 (因為背景是白的呀… 倒)。
BTW，如果有興趣開發 Android custom view 的開發者，推薦可以去觀看 Droidcon NYC 2016 – Measure, Layout, Draw, Repeat: Custom Views and ViewGroups，影片中提到蠻多開發 custom view 需要注意到的事項，會讓自己對 custom view 有更多的認識。
FunMing 基地 