Backlinko 分享了在 2019 年的 SEO 指南，用淺顯易懂的方式介紹了 Google 的 RankBrain：一個根據使用者行為來學習的搜尋結果排名方式。另外 Google 也提出了 Dwell Time 的概念──瀏覽者在搜尋的目的頁面待了多久的時間，來幫助 Machine Learning 的 Model 更加完善搜尋結果的排名。
另外值得一提的點是，Voice Search（就是 Google Home / Alexa）等，可能是未來在 SEO 領域會越來越重視的地方。當 FAANG 這些大廠商在智慧家電領域投資越來越多的時候，人機的交互介面可能從傳統的鍵盤滑鼠螢幕，轉換到影像聲音。目前智慧音箱仍然沒有特別的殺手級應用，並不像智慧手機十年前剛出現的時候迅速的改變世界；另外智慧音箱仍有隱私的爭議，這些問題仍然是未來智慧家電必須要一個一個解決的。
最後，傳統的SEO觀念，包含連入連結、原創內容，以及喊了很久的 Mobile First 策略，仍然是 2019 年 SEO 觀念中很重要且不可或缺的要點。基本功仍然要紮實，才有可能在其他的 Add-on 脫穎而出。
新聞說台灣年底前會開放 Apple Pay、Android Pay 跟 Samsung Pay，但是 HCE 手機信用卡已經先開放使用了（需安裝 tWallet+）。目前支援的銀行（台銀、華南、永豐等…）都不是發卡量最大的幾家，而且只支援 Master 卡，但整體來說使用上還蠻方便的。
之前就申請了 HCE 信用卡，但一直沒機會測試，今天到了遠百剛好有機會可以試試看。
首先要先輸入密碼：
店員看到還以為是 Friday 錢包…XD 我直接跟店員說用信用卡模式就刷過了，一次 OK。
刷卡後馬上就能查到消費紀錄：
目前只支援 Master 卡，希望能儘快支援 JCB…
我猜 Apple Pay 跟 Android Pay 初期也只會支援發卡量大的銀行（中信、國泰）的卡，但目前我的主力卡都不是這幾家啊…XD
在 Velocity 2016 裡面，GitHub 分享了如何用 Slack 為平台，建立機器人來輔助開發流程（如 CI、Deployment、Monitor等等）。
對於開發者來說，可以一邊討論就一邊把事情完成，整合了 README 等文件撰寫的工作；對於 Operator 來說，由於討論的過程在 Slack 上，也可以設計一個流程，當有事件發生時就 Alert OP，這樣可以讓 OP 在開發過程中也被告知，獲得必要資訊。
缺點就是資訊流通太快了，可能開完一個一小時會議之後，事情跟前一個小時差距就變得很大 XD 這點是需要團隊成員適應的地方。
昨天花了一個多小時的時間，申請了 Let’s Encrypt 的憑證並更新上去，並且升級到 Apache 2.4.17 來安裝 HTTP/2 Module。
Let’s Encrypt 使用的 ACME Client 程式，目前有實驗性的支援 FreeBSD，基本上按照信件中的說明安裝即可。如果是 FreeBSD 9.x 的話，需要按照這個 GitHub Issue 的方式，自行編譯 trunk 版本的 pyca/cryptography，即可完成 ACME Client 的安裝。
安裝完成後，可以指定 webroot 當作認證檔案存放的位置，來給 Let’s Encrypt 驗證這個網域確實是申請人所有：
./letsencrypt-auto --agree-dev-preview --server https://acme-v01.api.letsencrypt.org/directory -a webroot --webroot-path /home/data/websites/jnlin.org/webroot certonly
簽好的憑證會放在 /etc/letsencrypt/ 裡面，效期 90 天。官方建議每 60 天 renew 一次。我自己打算先手動 renew 一次，沒問題的話就丟到 cron 裡面，兩個月自動 renew 一次。
安裝 Apache 2.4 + HTTP/2 Module 就沒什麼特別的，直接 ports 安裝，結束之後，把憑證設定上去，即可打開 HTTP/2 的功能。反倒是解決 WordPress 的 mixed content 問題花了比較多時間 XD
雖然 Google Tag Manager 有支援很多代碼，但沒有支援的代碼，一樣可以用自訂的方式設定上去。
自訂代碼分為兩種：HTML 與圖片代碼。當觸發條件被滿足時，指定的 HTML 或圖片代碼會被載入到頁面上。
在代碼中，可以用 {{ 變數名稱 }} 來帶入變數的值。
設定好之後，使用的方法跟套用 Google Analytics 一樣。
如果要利用 Google Tag Manager 來套用 Mixpanel 追蹤的話，可以參考這篇 Mixpanel 分享的說明。
上一篇文章中，我們建立了簡單的事件。但除了 PV 之外，我們還要追蹤網站上元素的點擊，或是其他特殊的事件。Google Tag Manager 已經有內建一些變數，可以指定條件，讓我們不需要寫程式就能追蹤部份的事件。
我們必須到「變數」這個 Tab 去啟用這些內建的變數。
目前支援的變數列表如下：
以下我們以「當使用者點擊頁面上 id 為 “to-be-clicked” 的物件」為例，建立一個事件：
1. 首先到「變數」，啟用「Click ID」這個變數。
2. 新增一個「觸發條件」，事件類型為「點擊」，觸發條件為「所有元素」，啟動時機為「部分點擊」。接著在啟動時機內設定條件為「Click ID 等於 “to-be-clicked”」。
3. 新增一個「代碼」，指定該「觸發條件」要發出的 Event 內容與要記錄到的 Google Analytics ID。
如果我們想設定的變數不在預設列表中，也可以用程式自訂一個變數。作法如下：
1. 新增一個「使用者定義的變數」，類型選擇「自訂 javascript」。
2. 輸入一個 javascript 函式，傳回值為變數值。例如：
function () {return $('body').data('state'); }
表示傳回 <body> 的 state 這個 data attribute。
另外，我們也可以在程式裡面觸發 Tag Manager 的自訂事件。首先先建立一個觸發條件，選擇「自訂事件」：
接著在程式內觸發此事件：
dataLayer.push({"event": "custom-event"});
為了收集使用者資料與行為，現代的 Web App 或 Mobile App 都會埋很多 Tracking Code，例如 Google Analytics、Mixpanel 或是 Flurry 之類的。當埋的 Tracking Code 或需要追蹤的事件開始變多的時候，管理就會變的越來越複雜。另外，隨著分工越來越細，工程師們會常常接收到來自產品、數據或營運部門的資料紀錄需求。當資料需求越來愈多的時候，紀錄事件這件事情就變得很瑣碎。尤其，面對的是 Mobile App 時，由於每次要收集新的紀錄時，就必須將 App 重新送審，比起 Web App 來說會花費更多時間。
Google Tag Manager 提供一個「簡單滿足紀錄需求」的介面，讓紀錄事件這件事變得不一定要工程師寫程式來達成。不過需要對寫程式邏輯有一定的熟悉度，對於一般「企劃人員」可能還是有些門檻在。
在 Web 使用 Google Tag Manager 的方式很簡單，直接申請之後，會給你一串 HTML：
接著要到 Google Tag Manager 的頁面中建立要記錄到的服務。在 Google Tag Manager 介面中選擇「新增代碼」，可看到除了 Google Analytics 以外，還有以下的 Tracking Code 可以選擇：
設定完並存檔之後，我們就有一個代碼用來紀錄 Page View 了。接著在「觸發條件」這裡，設定想要追蹤的事件類型：
例如，建立一個「計時器」觸發條件，當網頁載入後超過 1 秒鐘，送出 timer1s 事件：
然後回到「代碼」這裡，再建立一個 GA 代碼，但這次「追蹤類型」要選擇「事件」，並且將剛剛建立的觸發條件設定為「啟動時機」：
這樣我們就順利建立了一個事件。最後，要記得要按下右上角的「發布」，剛剛設定的條件才會被佈署到正式的平台上，事件也才會被記錄到 Google Analytics 中：
下一篇文章，將會介紹「自訂事件」與「變數」的設定方式。
這次去日本，總算去了一直想去的宮島（嚴島神社）
因為是一人旅，在規劃行程的時候本來想住廣島然後搭首發電車上島看漲潮的大鳥居的。
不過在 jalan 上看到 錦水館 的一人旅方案，含早晚餐跟溫泉，於是就決定在島上住一晚了。
宮島是日本「三景」之一，另外兩個分別是京都的天橋立還有宮城縣的松島。
旅館有免費的碼頭接送服務，但我沒有預約，一個人拉著行李慢慢走到旅館門口。路上有很多群非常兇的鹿，會咬人手上的紙類物品，甚至連塑膠袋都會被咬走…
如果有經過這條路的話，盡量還是不要再手上拿塑膠袋或紙袋比較好。
一到了旅館，在外面打掃的飯店的女服務生一知道我是住宿的客人，就馬上放下手上的工作幫我搬行李。
在旅館前台有一個小的咖啡廳，CHECK-IN 也是在這裡進行。CHECK-IN 時會先問預計用晚餐的時間。
客人坐著，由服務生一對一的服務，因為長途旅行而緊繃的精神感覺一下子放鬆下來。
鑰匙做成宮島名產「杓」的樣子。
服務生幫忙把我的行李拿到了五樓的單人房。房間面對商店街，所以看不到瀨戶內海。
不過整體來說很舒服很好睡。浴室很小，不過都來溫泉旅館了，應該沒人會在房間浴室洗澡吧 XD
旅館玄關的樣子：
雖然是百年的旅館，但外觀經過整修過，也還蠻有現代感的。
旅館在電梯旁提供浴衣，除了比較樸素的旅館版本外，還有各種花樣的版本，男女皆有，可以選一件自己喜歡的到房間換。大概男女各七八種款式，顏色比較淡一些。
另外玄關有提供外出用拖鞋，如果要穿浴衣外出，記得不要把室內拖鞋直接穿出去。
晚餐前先去泡個湯。說實在是有點小失望啦，男湯不大，大概跟 ドーミーイン 的差不多，而且因為在地下室所以也沒有景觀可看。
不過晚餐就超出我預料之外了。
一到了餐廳，馬上就在桌上看到我的名字，以及超豐盛的餐點。
女服務生也馬上過來詢問要喝些什麼。我點了照片中的廣島地酒 Set，三杯共 1300 円。
到了廣島當然要吃牡蠣。除了炸牡蠣外，還有牡蠣釜飯可吃。
豐盛又好吃，酒也好喝，一整個滿足～
晚餐後，服務生會來詢問隔天早上的早餐時間，並送上名片。
吃太飽了，出去散個步，看一下晚上的大鳥居～
外面超冷，走了半小時就趕緊回房間睡覺了 XD
早上七點起來，先去看一下漲潮的大鳥居，然後又跑去泡了湯。
八點半的早餐也是豐盛到吃不完。一到餐廳，日式的早餐也是擺在桌上一整份，另外外加自助式的生菜沙拉。
由於實在太飽就沒拍照了
總評：
服務：五顆星，服務給人的感覺非常舒服，如果聽得懂日文，服務生會熱情跟你介紹旅館服務還有菜色。
溫泉：三顆星，普普。
食物：四顆半星，缺的半顆星是因為沒旅伴（喂）
房間：四顆星，單人房不錯，下次會想預約面海的和室。
先說重點：
在開始刷機之前，你需要：
刷機的方法：
11111111 (supercid)。< fastboot oem writecid GOOGL001，才能進行 OTA。其他資訊，可以找 xda 論壇，有許多相關文章可以參考 🙂
先說重點：我覺得面試的題目要準備夠充分，而且要從簡單到困難，循序漸進，直到求職者答不出來為止。這樣可以了解求職者的能力範圍。有好的能力，給的薪水也會比較高，作的事情也會比較難。但我問完之後，會跟他說明答不出來不代表不會錄取，只會作參考。
我會先把求職者分成兩個類型：新鮮人（完全沒有工作經驗）與轉職者。
對於新鮮人，如果是相關科系出身，我會比較期待他還記得比較多理論的東西，所以我會看他的成績單，修過什麼課程，然後拿該課程的內容來問。舉例來說，一般的資工系都有修過資料結構與演算法，我會問他 Stack, Queue, Hash 的用法，或是 Quick Sort, Bubble Sort，然後請他說明這些課程中，他印象最深刻的內容，再根據他的內容來繼續問下去。
通常後來被我刷掉的人，有很多是上課渾渾噩噩，所以根本就不知道上課內容是啥的。之前遇過一個求職者，問他對哪個課程最有印象，他的回答是都沒有印象 ~_~
如果他有作品（或專題），或是在外面有打工，就會問實作的東西，例如問作品的哪個部分是他做的，與其他人如何合作，還有對於作品的哪個部分印象最深刻，覺得哪裡最難，後來怎麼解決（解決未知問題的能力）。通常實作強的人，對於這個問題都能很快回答出來。如果作品他做的部分很少，就很容易支支吾吾。
接下來，會給一個實際的問題，請求職者用他最熟悉的程式語言現場說明解決方法，主要觀察的地方是解決問題的過程。之前有問過用 C 寫 string replace 的題目，基本上這個有寫過程式應該都回答的出來。
接著會給一篇英文技術文章，或是給一個技術文件，請求職者閱讀後，大致說明內容，並且講一下可以怎麼應用。通常前面沒問題，後面會死一堆新鮮人。
再來，會問求職者是否有用過常用的工具（版本控制、MVC、Framework），GitHub，以及有沒有參加 Open Source Conference 的經驗等等。這個部分主要是想了解他對 Open Source 的熟悉度，對於未來工作尋找資源上會有幫助。
最後，會問為什麼會來應徵這份工作，對於公司了解多少，有沒有用過公司的產品，舉出公司產品的優缺點。從這個問題可以了解這個人是不是有自己的想法，還是老闆說了就照做的人。
新鮮人的人格特質，只要是誠實、對自己負責的人，基本上就很 OK 了。公司裡面需要有想法的人，也需要老闆說了就照做的人，並不會因為沒有想法就被刷掉，除非是渾渾噩噩不思進取的特質。
轉職者的部份下次（會有嗎？）再來談吧。