Backblaze B2 的 Copy File API 終於開放

BackblazeB2 算是我還蠻愛用來丟一些東西的地方 (配合他們與 Cloudflare 合作的免費頻寬)。

先前 B2 一直沒有複製檔案的功能,如果要有同樣檔案,變成得自己再上傳一次,這對於網路沒有很快的使用者會很痛苦,現在總算是提供 API 可以直接複製了:「B2 Copy File is Now Public」。

這個功能主要的文件在「b2_copy_file」。

另外這次也推出了「b2_copy_part」,針對檔案的合併所提供的 API。

GitHub 推出自己的 CI/CD 方案

GitHub 推出自家的 CI/CD 方案:「GitHub Actions now supports CI/CD, free for public repositories」。

這個功能是搭在 GitHub Actions 下面的功能,目前支援的語言還是以熱門的為主:

GitHub Actions now makes it easier to automate how you build, test, and deploy your projects on any platform, including Linux, macOS, and Windows. Run your workflows in a container or in a virtual machine. Actions also supports more languages and frameworks than ever, including Node.js, Python, Java, PHP, Ruby, C/C++, .NET, Android, and iOS. Testing multi-container apps? You can now test your web service and its database together by simply adding some docker-compose to your workflow file.

公開的 Repository 可以直接用,私人的 Repository 則是每個月有 2000 分鐘 (Free)、3000 分鐘 (Pro)、10000 分鐘 (Team) 以及 50000 分鐘 (Enterprise) 的額度可以用,另外超過的部份則是另外以分計費,換算成小時的話是 USD$0.48/hr (Linux)、USD$0.96/hr (Windows) 與 USD$4.8/hr (Mac)。

不過還是得等:

We’re excited to make this new version of Actions available. Learn more and sign up for the beta, which is free now until we make Actions generally available at GitHub Universe on November 13.

CD 的部份主要因為會跟架構有關,衝擊應該還好,但可以預期現有一堆 CI 服務應該會很辛苦了...

JSON Canonicalization

這篇是講 JSON object 上的簽名,但實際上就是在討論 JSON Canonicalization 的前因後果:「How (not) to sign a JSON object」。

在處理 JSON 資料時,「判斷兩個 JSON object 是否相同」是一個不怎麼簡單的問題,其中一個想法是找一個機制可以把意義相同的 JSON object 都轉成相同的 (byte)string representative,這也就是 JSON Canonicalization。當你可以確保意義相同的 JSON Canonicalization 後,你就可以對 string 本身簽名。

這件事情其實在 XML 就有過同樣的歷史故事 (yeah,總是有人愛在某種資料格式上面疊上簽名),也就是「XML Signature」這個方式。

在 XML 這邊不幸的是,還不少標準選用 XML Signature,像是當年為了實做 Google Apps (現在叫做 G Suite) 的 SSO,而需要接 SAML...

回到原來的 JSON Canonicalization,可以馬上想到的變化包括了空白與 object 裡 key 的順序,也就是這兩個:

{"a":1,"b":2}
{
  "b": 2,
  "a": 1
}

但不幸的是,還有 Unicode 來一起亂,也就是下面這個跟上面有相同的意思:

{
  "\u0062": 2,
  "\u0061": 1
}

另外還有其他的地雷是平常不會想到的,如果你因為複雜而決定用 library 來做,那也代表 library 必須面對這些複雜的情境,未必沒有 bug...

所以文章作者在最後面才會請大家不要再來亂了 XDDD

Maybe you don’t need request signing? A bearer token header is fine, or HMAC(k, timestamp) if you’re feeling fancy, or mTLS if you really care.

Canonicalization is fiendishly difficult.

Add a signature on the outside of the request body, make sure the request body is complete, and don’t worry about “signing what is said versus what is meant” – it’s OK to sign the exact byte sequence.

AWS Cloud 的用法

Hacker News Daily 上看到這則,分享了 AWS (他的前東家,超過八年) 的使用經驗:

除了可以在 Twitter 上看以外,也可以用 Thread reader 直接讀整條 thread,應該也還算清楚:「This is how I use the good parts of @awscloud, while filtering out all the distracting hype.」。

這邊的經驗談主要是在 web 與 app 相關的服務這塊:

有講到 AWS 的業務其實圍繞在 scalability 上發展,但這對 startup 可能反而是扣分,因為暴力法解反而可以大幅簡化架構換得 agile (而讓 startup 存活下來)。

另外從團隊的開發成本來看,這些 scale 的技術增加了開發成本,產生了很多開發上的限制,這些觀點也有點帶到「Premature optimization is the root of all evil」在講的事情:

最後的結論可以看到一些列表:

除了 DynamoDB 的意見不同外 (這邊提到的 DDB),其他的我都可以接受...

Google 公告了 Chrome Extension 對於權限的新規範

是收到信件通知 (因為之前有開發一些 extension),裡面提到的重點主要是出自「Developer Program Policies」裡的兩項。

第一項是要求權限最小化:

Request access to the narrowest permissions necessary to implement your Product’s features or services. If more than one permission could be used to implement a feature, you must request those with the least access to data or functionality.

第二個是你現在沒有實做的功能就不能要權限:

Don't attempt to "future proof" your Product by requesting a permission that might benefit services or features that have not yet been implemented.

這些新條文將會在 2019/10/15 生效:

Your extensions must be compliant with this policy by October 15th, 2019. You can learn more about these changes and how they may apply to you in our User Data FAQ.

拿 Git 記錄分析知名開發者的活動時間...

看到拿 git log 分析知名開發者的活動時間:「At what time of day do famous programmers work?」。

從列出來的人可以看出 Chris Lattner (LLVMSwift) 是個夜貓子,其他人大多都是正常的作息... 也看得出來有些人堅持睡覺時間不碰這些東西 XD

Facebook 推出了 Hermes,為了 React Native 而生的 JS Engine

Facebook 提供了一個對 React Native 最佳化的 JS engine:「Hermes: An open source JavaScript engine optimized for mobile apps, starting with React Native」。

裡面有提到兩個比較重要的的部份是 No JIT 與 Garbage collector strategy,針對行動裝置的特性而設計:避免 JIT 產生的 overhead,以及降低記憶體使用量。

官方給的改善主要也都是偏這兩塊:

不過沒有提到 CPU usage 會上升多少,只是帶過去:

Notably, our primary metrics are relatively insensitive to the engine’s CPU usage when executing JavaScript code.

對於 Facebook 也許是可以接受的數量,但對於其他人就沒概念了... 要入坑的人自己衡量這部份的風險 XD

Fabrice Bellard 的 QuickJS

Fabrice Bellard 跑去寫了一套 JavaScript engine 出來:「QuickJS」。

以 ES2019 當底實做的 JS engine:

Almost complete ES2019 support including modules, asynchronous generators and full Annex B support (legacy web compatibility).

測試的部份也過了:

Passes 100% of the ECMAScript Test Suite.

在大小的部份,比起其他的 engine (與 package) 來說的確是小很多,不過 190KB 這個大小對於 embedded system 來說還是有點微妙 (但對於想要包 JS engine 進去用的人應該是頗開心的):

Small and easily embeddable: just a few C files, no external dependency, 190 KiB of x86 code for a simple hello world program.

不愧是 Fabrice Bellard,搞出了 LZEXEFFmpegQEMU 後跑來搞 JS...

Idempotent Bash Script

看到「How to write idempotent Bash scripts」這篇,重點在講 Idempotence,這個詞是從數學上借來的,講重複操作的不動性:

An element x of a magma (M, •) is said to be idempotent if:

x • x = x.

If all elements are idempotent with respect to •, then • is called idempotent. The formula ∀x, x • x = x is called the idempotency law for •.

在 CS 領域也是一樣的概念:

Idempotence (UK: /ˌɪdɛmˈpoʊtəns/, US: /ˌaɪdəm-/) is the property of certain operations in mathematics and computer science whereby they can be applied multiple times without changing the result beyond the initial application.

而這篇講的是 Bash 上有些常見的行為要怎麼改成 Idempotence:

It happens a lot, you write a bash script and half way it exits due an error. You fix the error in your system and run the script again. But half of the steps in your scripts fail immediately because they were already applied to your system. To build resilient systems you need to write software that is idempotent.

一個常見的例子是 cron job 是否可以重複執行的問題。

如果 cron job 裡的程式都是 idempotent,那麼就不需要擔心重跑會因為前一隻 script 產生的環境而失敗,導致無限循環而需要人介入...

另外一個更進階的是同時有兩個 process 在執行同一個 script (可能在不同機器上),這也是要考慮的問題,不過這個問題在大多數情況下有各種 lock 系統可以協助避免,應該不是太大的問題...

為線上環境而最佳化的 Ruby:Fullstaq Ruby

最近看到的「Fullstaq Ruby」,專為線上環境最佳化的 Ruby

Fullstaq Ruby is an MRI-based Ruby distribution that's optimized for server production use cases.

目前主要是使用 jemalloc (超萬用) 以及 malloc_trim patch:

It is compiled with the Jemalloc and malloc_trim patches, allowing lower memory usage and higher performance.

其中看了一下 malloc_trim patch 的介紹還蠻有趣的:「What causes Ruby memory bloat?」,這篇主要是在討論記憶體用量的問題,以及目前常見的 workaround。

這個 patch 是針對 Ruby 在 full mark GC 的情境後,增加呼叫 malloc_trim(0); 以釋放記憶體,作者發現這樣可以省下了大量的記憶體空間:

然後作者預期效能應該會有影響 (畢竟多做了一些事情),所以找了有在做 Rails benchmark 的人幫忙測試,結果發現反而變快了:

這樣看起來有可能官方會考慮把這個 patch 直接包進去?不過這看起來是在使用 jemalloc 的前提下?不知道如果使用標準的 glibc 會怎麼樣...