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 脫穎而出。
昨天花了一個多小時的時間，申請了 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 中：
下一篇文章，將會介紹「自訂事件」與「變數」的設定方式。
PHP 的 Imagick 有 memory leak 的情形，當用 PHP-CGI 跑動態縮圖服務的時候，這個問題更加的嚴重。查了一下資料，可以設定參數限制使用的記憶體大小：
// set pixel cache max size to 256MB
IMagick::setResourceLimit(imagick::RESOURCETYPE_MEMORY, 256 * 1024 * 1024);
// maximum amount of memory map to allocate for the pixel cache
IMagick::setResourceLimit(imagick::RESOURCETYPE_MAP, 256 * 1024 * 1024);
單位是 Bytes。如果進行圖片處理時，所需的記憶體超過指定值時，會在 /tmp 寫入暫存檔案。可以使用 MAGICK_TMPDIR 這個環境變數來指定暫存目錄：
putenv('MAGICK_TMPDIR=/tmp/imagick');
Galera 3.x 為了多機房間的 Replication，設計了 gmcast.segment 這個參數。前陣子 Percona 的人出來介紹了這個參數背後的機制：Automatic replication relaying in Galera 3.x (available with PXC 5.6)。大致摘錄如下：
如果沒有設定 gmcast.segment 參數的話，同樣是三個 Node，會耗用兩倍的頻寬：
Image from: Automatic replication relaying in Galera 3.x (available with PXC 5.6)
原文中另外有對作了 segment 與不作 segment 的 commit latency 進行比較，結果作了 segment 的 commit latency 並沒有比較高。如果有跨機房需求，應該要設定 gmcast.segment。
MySQL 5.6 以前的 Multi-column Index，當位於 index 中間的 column（如下例的 j）需要進行 range query 的時候，只能利用到部分的 index，需要另外讀取資料列的內容來進行判斷。舉例來說，如果有一個 Table 結構是這樣：
CREATE TABLE mytable (
id int not null auto_increment primary key,
i int(11) NOT NULL,
j int(11) NOT NULL,
k int(11) NOT NULL,
val char(10) NOT NULL,
KEY ijk (i,j,k)
) ENGINE=InnoDB;
在 MySQL 5.6 之前，SQL Query 「SELECT sum(length(val)) FROM T WHERE i=1 AND j<100 AND k=100」 會把所有 i=1 的資料列拉出來，逐一比較 j 與 k 的值。MySQL 5.6 的 Index Condition Pushdown (ICP) 功能，把這個動作改為比較 Index tuple 而非資料列內容，可避免拉出整個資料列，降低磁碟 IO（因為資料列通常比 Index 大）。
詳細的說明可以看 MySQL 的官方文件：Index Condition Pushdown Optimization 與 Percona 的測試：Multiple column index vs multiple indexes with MySQL 5.6。
上週的新聞，Gmail 會將 Email 內嵌的圖片，透過 Proxy 處理之後顯示出來。除了改進使用者體驗外，也可以避免惡意圖片攻擊使用者的電腦。
ThreatPost 上有人測試了這個功能，發現 Gmail 會在使用者開啟信件的時候，才會去抓取圖片並且進行處理，所以目前使用的開信追蹤技術，只要指定獨一無二的追蹤網址給每個用戶，還是可以正常運作。不確定 Google 是否有打算處理隱私問題？另外這篇文章也提到有可能可以利用 Google 的 Image Proxy 來作 DDoS…
也是一個值得繼續觀察的項目 XD
uProxy/ (( 由 University of Washington 與 Brave New Software 開發，Google 贊助。 ))是一個 Firefox 和 Chrome 的擴充套件，安裝之後，可以讓透過同樣安裝了 uProxy 的朋友電腦瀏覽網站。自己與朋友中間的連線是加密的。只要你信任朋友不會偷聽你的資料，就可以避免在公共場所使用 WiFi 的安全性問題。
不過在我看來，uProxy 會大大的降低 Proxy 架設與使用門檻。以後只需要在家中的電腦安裝 uProxy，在外面就能夠使用加密的連線，透過家中網路上網。就算不信任朋友不會惡搞你，自己在家裡放電腦（或是到 AWS 上開一台 Windows 跑瀏覽器 XD）就可以增強使用公共場所 WiFi 的安全性，避免被竊聽。
另外，如果在中國需要翻牆，或是某些日本限定的網站，也可以很簡單的透過這個套件來規避限制了。
最後我覺得這個專案的挑戰是，怎麼讓 uProxy 在行動裝置（智慧型手機、平板之類的）上面可以簡單的安裝與使用。我不確定 Firefox 的情形，但是 Chrome 與 Safari 都沒有擴充套件的機制…… 另外蘋果的 Walled Garden 也增加了很多不確定性，說不定連上架都會被拒絕。
目前這個專案還在 Closed Beta 階段，就等之後的發展了。