GitHub 藉著 open source 函式庫，說明了目前還在 beta 的 GitHub Actions 是什麼：「An open source parser for GitHub Actions」。
GitHub Actions 是 GitHub 規劃將自動化設定包裝成設定檔的服務，以往是透過 GitHub 網站上設定，現在則是把這些設定放到 git repository 內。
重點在於 Actions 其實是透過 HCL (HashiCorp Configuration Language) 語法定義：
All Actions workflow files are valid HCL, but not all HCL files are valid workflows.
去年 11 月的時候 AWS 宣佈了要自己維護 OpenJDK 套件的計畫 Amazon Corretto：「AWS 決定花力氣支援 OpenJDK (Corretto 計畫)」，現在這個計畫的 OpenJDK 8 進入 GA (General Availability)：「Amazon Corretto 8 Now Generally Available」。
之前有提到進入 GA 其中一個重點是提供 .rpm 與 .deb 套件安裝，目前可以看到文件已經提供了，不過目前還只能手動下載安裝並更新：「Amazon Corretto 8 Installation instructions for Debian-based and RPM-based Linux distributions」。
與其他版本的差異可以在「Change Log for Amazon Corretto 8」這邊看到 AWS 修改的內容。
剛剛才注意到 PHP 5.6 在 2019 年還有新的版本：「PHP 5.6.40 Released」。
在「Supported Versions」可以看到 PHP 5.6 應該是在 2018 年年底就終止更新，看起來是 5.6.39 在 2018/12/06 出之後，把剩下的一包都累積起來，「原則上」後面不會有更新：
Please note that according to the PHP version support timelines, PHP 5.6.40 is the last scheduled release of PHP 5.6 branch. There may be additional release if we discover important security issues that warrant it, otherwise this release will be the final one in the PHP 5.6 branch.
不過看起來官方的態度是「儘量幫」，如果有太嚴重的漏洞還是會補... :o
算是補充之前看過，但一直沒研究的東西...
看到 Simon Willison 的「Exploring search relevance algorithms with SQLite」這篇才花些時間看了一下 SQLite 的搜尋功能。
看起來不論是 FTS4 或是 FTS5 都沒有處理 CJK 文字的功能，可能要當作 unigram 之類的方式處理 (參考「Unicode support for non-English characters with Sqlite Full Text Search in Android」這篇)，不過排名的部份有支援 BM25，整體看起來應該是還算堪用。
看到「jjkaufman/wiv.js」這個專案，然後點開他的 Demo Site「The web site of coughdrop」後笑出來，這把 2000 年網站的特色做到極致了... XD
看程式碼可以看到主體是在 canvas 上操作，然後用 requestAnimationFrame 產生。
看到 Facebook 在 Presto 裡增加使用 HyperLogLog 計算數量的能力，突然想到常常忘記這兩個拿準確度換速度的資料結構：「HyperLogLog in Presto: A significantly faster way to handle cardinality estimation」。
HyperLogLog (HLL) 是解決 Count-distinct problem 的資料結構，用很少的記憶體就可以給出一個誤差不大的值 (用 1.5KB 的空間處理十億等級的資料，誤差大約在 2%)，所以 Presto 利用這個資料結構引進了 APPROX_DISTINCT() 以及其他的函數，就很容易在 L2/L3 cache 裡運算，藉此大幅提昇速度。
Depending upon the problem at hand, we can achieve speed improvements of anywhere from 7x to 1,000x.
先前也提過 Reddit 也用 HLL 統計資料：「Reddit 在處理 Page View 的方式」。
Bloom Filter 也是在處理大量資料的問題，但這個資料結構的功能不太一樣，是給出「有沒有存在」，使用空間與誤差大約是 10 bits per key (1% false positive)，另外先前也有提到一些變形，可以提供其他功能。像是「Quotient filter」與「Cuckoo Filter：比 Bloom Filter 多了 Delete」。
AWS 把推薦演算法包成服務拿來來賣，叫做 Amazon Personalize：「Amazon Personalize – Real-Time Personalization and Recommendation for Everyone」。
把後面的演算法隱藏起來，只要給使用者的評價資料就可以了，像是文章裡的範例：
userId,movieId,rating,timestamp 1,2,3.5,1112486027 1,29,3.5,1112484676 1,32,3.5,1112484819 1,47,3.5,1112484727 1,50,3.5,1112484580
可以看出來這個使用者對 2,29,32,47,50 這些 movieId 在不同的時間點都給了 3.5 分的評分。
然後經過一連串的 API 操作 (有些參數可以調整，但主要是叫 AWS 運算，並且建立 real-time 的服務)，就可以看到推薦哪些其他的 item 了：
$ aws personalize-rec get-recommendations --campaign-arn $CAMPAIGN_ARN --user-id $USER_ID --query "itemList[*].itemId" ["1210", "260", "2571", "110", "296", "1193", ...]
而從 Pricing 的頁面可以看到支援 real-time data 與 batch data：
DATA INGESTION
You are charged per GB of data uploaded to Amazon Personalize. This includes real-time data streamed to Amazon Personalize and batch data uploaded via Amazon S3.
這其實是很多網站都很需要的功能...
AWS 這次對 Lambda 還發表了不少功能，除了前面提到透過 Layout 支援其他語言以外 (e.g. Ruby)，這邊要再提到另外一個重要的功能。
這次是 ALB 可以直接呼叫 lambda function 了：「Lambda functions as targets for Application Load Balancers」。
以前還得靠 API Gateway 整半天 (因為版本設定)，現在直接用 ALB 接就可以了？而且 ALB 這邊有規劃對應的 quota：
There is no change to the hourly price of ALB. The load balancer capacity units (LCUs) of ALB now include 0.4 GB per hour of data processing to AWS Lambda targets.
這樣就更接近 serverless 了...
AWS 宣佈 Lambda 支援 Ruby 2.5：「AWS Lambda Supports Ruby」。
另外宣佈可以透過 Layer 的方式讓任何程式語言在上面跑 (前面提到的 Ruby 看起來就是用這個方式支援的)：「New for AWS Lambda – Use Any Programming Language and Share Common Components」。
The Runtime API is the future of how we’ll support new languages in Lambda. For example, this is how we built support for the Ruby language.
看到 Percona 的 blog 上寫了一篇 MySQL 遇到 replication lag 時要怎麼解決：「MySQL High Availability: Stale Reads and How to Fix Them」，另外在留言也有人提到 Booking.com 的解法：「How Booking.com avoids and deals with replication lag」。
在業務成長到單台 MySQL server 不夠用的情況下，最簡單的擴充方式是架設 slave server，然後把應用程式裡讀取的部份導到 slave 上 (也就是 R/W split)，但因為 MySQL 的 replication 是非同步的，所以有可能會發生在 master 寫入資料後 slave 還讀不到剛剛寫的資料，也就是 replication lag。
這就大概有幾種作法，一種是當發現 lag 時就回 master 讀，但通常這都會造成 master 過載... 所以另外一種改善的作法是發現 lag 時就換其他 slave 看看，但這個方法就不保證讀的到東西，因為有可能所有的 slave 都 lag。
以前遇到的時候是拆情境，預設還是 R/W split，但敏感性的資料處理以及金流相關的資料就全部都走 master。
不過文章裡的解法更一般性，在寫入時多寫一份資料，然後在 slave 等這組資料出現。唯一的缺點就是要 GC 把多寫的資料清掉...
同樣的想法，其實可以讓 MySQL 在 commit 時直接提供給 binlog 或 GTID 的資訊，然後在 slave 等待這組 binlog 或 GTID 被執行。
看起來算是很不錯的解法，不知道各家 framework 對這些方式的支援度如何...