AWS CodeDeploy 支援單機測試模式

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

Amazon 的多變數最佳化

在「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.),你用本來的方式反而會測不出來。

用 Machine Learning 調校資料庫

AWS AI Blog 在月初上放出來的消息:「Tuning Your DBMS Automatically with Machine Learning」。

Carnegie Mellon Database Group 做的研究,除了預設值以外,另外跟四種不同的參數做比較,分別是 OtterTune (也就是這次的研究)、Tuning script (對於不熟資料庫的人,常用的 open source 工具)、DBA 手動調整,以及 RDS

MySQL

PostgreSQL

比較明顯的結論是:

  • Default 值在所有的 case 下都是最差的 (無論是 MySQL 與 PostgreSQL 平台,以及包括 99% 的 Latency 與 QPS,這樣二乘二的四個結果)。而且 Default 跑出來的數字與其他的差距都很明顯。
  • OtterTune 在所有 case 下跑出來都比 Tuning script 的好。這也是合理的結果,本來就是想要取代其他機器跑出來的結果。

至於有些討論 DBA 會失業的事情,我是樂見其成啦... 這些繁瑣的事情可以自動化就想交給自動化吧 XD

AWS Device Farm 可以遠端操作

AWS 又推出新的功能,這次 AWS Device Farm 讓使用者可以遠端互動跟機器操作:「AWS Device Farm Update – Remote Access to Devices for Interactive Testing」。

在「Test Devices List」這邊可以找到很多舊版本的機器可以互動操作 (尤其是 iOS 系列的機器),就可以拿來測各種舊版本的 bug report 了...

自適應演算法與 A/B Testing

Hacker News Daily 上看到三年前的舊文章,講自適應演算法取代常見的 A/B testing:「20 lines of code that will beat A/B testing every time」。

就拿原文裡面的例子來說明,我想要測試 "Buy Now!" 這個按鈕的顏色來得知哪個顏色的 click rate 最高,而我有 Orange、Green 以及 White 三種顏色為候選。

一開始我初始值都設為「展示了 1 次,被點擊了 1 次」,所以每個點擊率都是 100%:

OrangeGreenWhite
1/1 = 100%1/1=100%1/1=100%

然後你的網站上只要展示「點擊率最高的那個顏色」,並且記錄下來展示次數與點擊率就好,而整個過程會是自適應而被自動被淘汰掉,最後可能會變成這樣,就會固定是綠色的了:

OrangeGreenWhite
114/4071 = 2.8%205/6385=3.2%59/2264=2.6%

而這樣做的好處是節省人力成本:你不需要 A/B Testing 完後再人工介入修改。

對於更複雜的例子,雖然原文沒有提到,但你可以直接展開來做,舉例來說,你假設顏色與地區兩個變數所帶出來的 click rate 不是 i.i.d.,那麼你可以針對每個 Color + Region 都存數值去比較。

當然還是有他的問題 (comment 有提到),不過可以架出一些全自動的 workaround 來解決,比起要兩階段人工介入省了不少人力。

另外可以想像在大的產品上會遇到效能問題 (因為對同樣資料大量的 read + write),但這個數字不需要太即時,只要量大就會準確,所以技術上也可以解決...

AWS 推出的 Device Farm

AWS Device Farm 正式啟用了,可以測 AndroidAmazonFire OS 手機:「AWS Device Farm – Test Mobile Apps on Real Devices」。

有支援各種測試框架:

也可以設定手機的狀態:

然後各種 screenshot:

以及測試時的資源使用狀態:

價錢就如同之前提到的,USD$0.17/min 或是單隻包月 USD$250 (大約是測一整天的價錢):

Pricing is in units of device minutes, basically the duration of a single test run on a particular device. You get 250 minutes at no charge as part of a Free Trial; after that you pay $0.17 per device minute. You can also opt in to our unmetered testing plan; you can perform unlimited testing on any supported Android or FireOS device for a flat monthly fee of $250.

AWS 推出 Device Farm (行動裝置測試平台)

AWS 最近動作很多,預定在 2015/07/13 推出 AWS Device Farm,可以讓使用者直接租機器測試,價錢則是 USD$0.17/minute,或是租用一整個月 USD$250/month (一個裝置):

Pricing is based on device minutes, which are determined by the number of devices you use and the duration of your tests. AWS Device Farm comes with a free tier of 250 device minutes. After that you are charged $0.17 per device minute. As your testing needs grow, you can opt for our unmetered testing plan, which allows unlimited testing for a flat monthly fee of $250 per device.

等推出了之後再來研究看看,另外問問看公司內的同事來安排測試好了?

用 BrowserSync 測試多個平台...

BrowserSync 是用 node.js 寫的工具,可以同時測試一堆 device,修改後不用按 reload,印象中已經有套件可以做類似的事情?

一般用 npm 裝就可以了:

npm install browser-sync

最簡單的方法是直接執行 browser-sync,執行後會出現像這樣的訊息:

<script src='//192.168.1.1:3000/socket.io/socket.io.js'></script>
<script>var ___socket___ = io.connect('http://192.168.1.1:3000');</script>
<script src='//192.168.1.1:3001/client/browser-sync-client.0.6.0.js'></script>

把這段程式碼貼到 body 的最後面就可以了,當 BrowerSync 偵測到檔案有更新時會透過 server push 機制重刷頁面。

另外,也可以產生 bs-config.js 修改設定:

browser-sync --init

更完整的說明可以從「Options」這頁找到。

改善網頁的態度問題

看到 Local maxima 這個詞還真懷念:「Local maxima and the perils of data-driven design」。

這篇文章在講改善網頁時的態度。你可以用科學方法 (像是 A/B testing) 測試不同的小細節以達到 local maxima,但如果要有更重大的突破則必須靠結構性的改變。然後拿了 Facebook 在 2007 與 2008 年的網頁當作失敗案例...

雖然概念很久前就有,但用「Local Maxima」這個詞彙來表示是以前沒想過的,現在看到倒是覺得相當適合 XD