幹壞事是進步最大的原動力
在 Hacker News 上看到「Running C unit tests with Pytest (p403n1x87.github.io)」這串討論，就如同標題所寫的，拿 pytest 測 C 的程式：「Running C unit tests with pytest」。
拿既有還蠻成熟的 testing framework 來用，而且看他的範例裡，C 的部份只要 symbol 有 expose (non-static) 就可以測，看起來不需要用到 Python 特殊的資料結構...
之後如果有機會也可以用看看...
看了「Catching CSS Regressions and Visual Bugs in Continuous Integration」這篇，原來這個叫做 visual regression testing，可以拿來檢查視覺上的差異：
這種 pixel-by-pixel 的測試也可以包在 CI 裡面，至少記錄起來可以在之後查。
看起來有不少 open source 工具與付費的服務可以用，不過機器的記憶體都會需要大一點 (需要瀏覽器的 rendering engine)。
Hacker News Daily 上看到這個，在講 Travis CI 終止對 open source 專案的服務：「Travis CI is no longer providing CI minutes for open source projects」。
有不少專案已經改用其他 CI 服務的 free tier 做，像是 GitHub Actions 與 CircleCI 都有提供。
看了一下 Hacker News 上的討論，不少人是可以理解不會有永遠免費的午餐，只是這次 Travis CI 的處理讓大家覺得比較討厭的是，一方面官方一直跟 open source community 說我們很願意支援 open source community (前幾個禮拜官方 blog 還有發文重申這件事情)，另外一方面是一直在朝著關閉服務走：從限制 10K credits 開始，到現在不會再提供 credit 給 open source 專案。
有人整理了對應的時間軸：
? 2018: Travis CI announces they are starting the process of merging travis-ci.org, which provided free builds for OSS projects, into travis-ci.com, which until then was only for paying customers. They promise OSS builds will continue to be free.
? 2020: Travis CI announces they are shutting down travis-ci.org at the end of the year and all projects have to move to travis-ci.com. They promise OSS builds will continue to be free.
Early November 2020: travis-ci.com switches from providing unlimited builds for OSS to only providing 10k one-time credits by default. Projects that meet certain guidelines (e.g. no one paid to work on them) can apply for recurring credits.
Later in November 2020: CI for many OSS projects that had migrated to travis-ci.com starts to fail, as they've exhausted their 10K credits.
Dec 2020: If what is reported here is accurate, Travis CI stop providing any recurring OSS credits. CI breaks for the remaining OSS projects on travis-ci.com.
Jan 2021: travis-ci.org shuts down. CI will be broken for all projects using it. They'll have the option of migrating to travis-ci.com, but will soon break again as they exhaust their 10k credits.
這種服務非常吃 CPU resource，大型專案如果每個 push 或是每個 pull request 都跑一輪完整的測試，成本應該不低，大概可以理解為什麼 Travis CI 會這樣決定，不過態度就...
其他家有提供 free tier 的 CI 最近應該會湧入不少人，這幾個月可以看看其他家會不會也跟進，另外一方面應該也會有人開始自架？
這幾天在 Hacker News 上看到 Load Impact 推出的 k6 壓測程式，結合了 Golang 的執行效率與 JavaScript 的操作語法，讓使用者可以很簡單的進行壓力測試，在 Hacker News 上也有蠻正向的反應：「K6: Like unit testing, for performance (github.com/loadimpact)」，我唯一會在意的應該是 AGPLv3 的部份...
先看了一下資訊，看起來「Load Impact」是公司名稱，「LoadImpact」則是產品名稱，然後現在要改名變成「k6」與「k6 Cloud」：
Load Impact is now k6
Due to the success and rapid growth of the k6 open source load testing tool we decided to rebrand the LoadImpact product as k6 Cloud!
k6 裡面設計了 VU (Virtual User) 的概念，如同字面上的意義，VU 是虛擬的使用者，就技術上來說，每個 VU 都是在獨立的 JavaScript runtime 裡跑：
Each virtual user (VU) executes your script in a completely separate JavaScript runtime, parallel to all of the other running VUs.
然後他們居然把 JavaScript 裡面最「經典」的 async 架構給拔了，所以就不需要一堆 callback & promise 架構，用起來就爽很多：
For simplicity, unlike many other JavaScript runtimes, a lot of the operations in k6 are synchronous. That means that, for example, the let response = http.get("https://test-api.k6.io/") call from the Running k6 example script will block the VU execution until the HTTP request is completed, save the response information in the response variable and only then continue executing the rest of the script - no callbacks and promises needed.
翻了一下 Hacker News 上的討論與程式碼，看起來 JavaScript runtime 這部份是用 Golang 寫的 goja。
文件裡面給了不少範例，像是在「Running k6」這邊有直接給出怎麼壓測，10 個 VU 跑 30 秒：
k6 run --vus 10 --duration 30s script.js
另外在 repository 裡面，「samples」這個目錄下有不少範例，可以直接先看過一次從裡面學到不少功能，之後再回去翻一次 manual，應該就會更熟悉...
隨便測了一下還蠻容易上手的，加上有 apt repository 可以直接納入系統管理，看起來應該會放著跑，之後找機會用看看，也許打 API 之類的...
Rasmus Lerdorf 整理的資料 (就是生出 PHP 的那個 @rasmus)，關於平價 VPS 的測試：「Low-Cost VPS Testing」。
因為是 PHP 的大頭，所以把編 PHP 當作是 benchmark 的項目之一也不算太意外。另外還是有比較常見的 dd 與 iperf3 測試資料可以看。
算是一個挖掘的點，之後也可以租幾台測試看看...
AWS 推出了 Amazon DynamoDB 的相容 Docker Image，讓開發者可以在本地端測試 DynamoDB 的 API：「Use Amazon DynamoDB Local More Easily with the New Docker Image」，在 amazon/dynamodb-local 這邊可以拉到，裡面其實是包 Java：
DynamoDB local is now available to download as a self-contained Docker image or a .jar file that can run on Microsoft Windows, Linux, macOS, and other platforms that support Java.
這樣在 Continuous Integration (CI) 的過程裡面也可以拉起 service 測試...
AWS CodeDeploy 本來是個 client-server 服務架構，但現在讓你方便在本機測試，支援直接在本機下指令 deploy (不需要 server) 看看發生什麼狀況：「AWS CodeDeploy Supports Local Testing and Debugging」。
Previously, if you wanted to test and debug your deployment, you had to fully configure AWS CodeDeploy. This includes installing the agent on the target host, creating a CodeDeploy Application, and creating a CodeDeploy Deployment Group.
Now, you can execute a deployment directly on a local machine or instance where the CodeDeploy agent is installed. If your deployment has errors, you can easily find and view the error logs by accessing the agent with your terminal. This makes it faster and easier to find and fix bugs before configuring CodeDeploy for production.
是有很多人一直中獎然後跟 AWS 反應嗎... XD
在「An efficient bandit algorithm for real-time multivariate optimization」這邊提到了 Amazon 不是走傳統的 A/B testing，而是同時進行多變數的最佳化：
Consider the problem of trying to find a near-optimal version of a promotional message such as this one, which has 5 variable parts and 48 different combinations in total.
在這樣的測試數量下，作者預估需要 66 天才能夠得到有效的結果，而這也表示當變數更多的時候問題就更大了：
Based on the Amazon success rate and traffic size, the authors calculated it would take 66 days to conduct a 48 treatment randomized experiment. Often this isn’t practical.
也就是開頭提到的，如何一個禮拜就提昇 21% conversion rate：
Aka, “How Amazon improved conversion by 21% in a single week!”
作者也提到了這個方法其實打臉了他先前提到的另外一篇論文，在 2014 年提出測試應該要盡可能簡單 XDDD：
Yesterday we saw the hard-won wisdom on display in ‘seven myths‘ recommending that experiments be kept simple and only test one thing at a time, otherwise interpreting the results can get really complicated.
只能說狀況愈來愈複雜，導致需要新方法解決問題。而且這些電商會遇到在測試時不同的 factor 之間有可能會有相依性 (也就是說這些 factor 不是 i.i.d.)，你用本來的方式反而會測不出來。
AWS AI Blog 在月初上放出來的消息：「Tuning Your DBMS Automatically with Machine Learning」。
Carnegie Mellon Database Group 做的研究，除了預設值以外，另外跟四種不同的參數做比較，分別是 OtterTune (也就是這次的研究)、Tuning script (對於不熟資料庫的人，常用的 open source 工具)、DBA 手動調整，以及 RDS：
比較明顯的結論是：
至於有些討論 DBA 會失業的事情，我是樂見其成啦... 這些繁瑣的事情可以自動化就想交給自動化吧 XD
AWS 又推出新的功能，這次 AWS Device Farm 讓使用者可以遠端互動跟機器操作：「AWS Device Farm Update – Remote Access to Devices for Interactive Testing」。
在「Test Devices List」這邊可以找到很多舊版本的機器可以互動操作 (尤其是 iOS 系列的機器)，就可以拿來測各種舊版本的 bug report 了...
