Travis CI 推出 20.04 的環境了

看到 Travis CI 推出 Ubuntu 20.04 的測試環境公告,嚇了一跳:「Ubuntu 20.04 (Focal Fossa) build environment is available!」。

要知道當年是在 2017 年七月才支援 Ubuntu 14.04 (參考「Travis CI 總算要把 Trusty 當作預設環境了...」這篇),在 2018 年十一月才支援 Ubuntu 16.04 (參考「Travis CI 居然記得要支援 16.04 了...」這篇),然後 18.04 上線乾脆不公告了 (翻了一下社群的討論「Ubuntu 18.04.1 LTS (Bionic Beaver)」,是在 2019 年的七月左右支援的)...

這次 20.04 出來還不到半年居然支援了!

uBlock Origin 的開發版 (Dev) 被 Chrome Web Store 拒絕的事件...

uBlock Origin 是一個在瀏覽器上擋廣告的軟體,以前在推廣的時候都只提到可以過濾掉網站上的廣告,大家興趣其實都不太高 (還會有「留口飯讓別人吃」之類的 XDDD),但最近跟同事推廣的時候改用「可以擋 YouTube 的影音廣告喔」,大家接受度意外的爆高,不過這有點扯遠了,回到原來的主題上...

先介紹一下 uBlock Origin 的開發模式,除了一般的 stable 版本外 (「uBlock Origin」這組),另外會有另外一個 dev 版本上傳到 Chrome Web Store (CWS) 上 (「uBlock Origin development build」這組),這樣讓使用者比較容易安裝與測試,這個方式也可以在 Tampermonkey 上看到。

這次主要維護者 Raymond Hill (gorhill) 在 1.22.5rc1 版上傳到 CWS 上後收到被拒絕上架的通知:「Dev build 1.22.5rc1 "REJECTED" from Chrome Web Store」。

拒絕的原因是 CWS 要求要有套件必須符合「目的單一性」,也就是不能把目的不同的東西強迫使用者綁在一起使用:

Your item did not comply with the following section of our policy: An extension should have a single purpose that is clear to users. Do not create an extension that requires users to accept bundles of unrelated functionality, such as an email notifier and a news headline aggregator. If two pieces of functionality are clearly separate, they should be put into two different extensions, and users should have the ability to install and uninstall them separately. For example, an extension that provides a broad array of functionalities on the New Tab Page/ Start-up Page but also changes the default search are better delivered as separate extensions, so that users can select the services they want. For more information on the new Chrome extensions quality policy, please refer to the FAQ: https://developer.chrome.com/extensions/single_purpose

後續的 1.22.5rc2 也被拒絕,然後他回信詢問了 CWS 官方,得到的仍然是罐頭回應,然後他就決定丟著 (而這個作法還蠻聰明的),接著這件事情就被丟著變成 PR 事件上了一些媒體,然後昨天就突然解了...

Google 最近的動作愈來愈多了,一方面在嘗試避免觸動反托拉斯法的情況,儘可能打壓這些擋廣告的套件...

Dropbox 的 non-ext4 支援回鍋

Dropbox 去年的時候拔掉非 ext4 檔案系統的支援,被罵翻也不鳥 (參考「Linux 版的 Dropbox 在十一月後將只支援 ext4...」),結果現在又回來支援了:「Dropbox Brings Back Support For ZFS, XFS, Btrfs And eCryptFS On Linux」。

出自 beta 版的說明「Beta Build 77.3.127」這邊:

Add support for zfs (on 64-bit systems only), eCryptFS, xfs (on 64-bit systems only), and btrfs filesystems in Linux.

不過我不是因為這個而搬走 (因為我用 ext4),反而是在對免費版限制時跳走:「Dropbox 免費版限制三個裝置更新...」。

當初用 X-attrs 當理由,看起來是有人離職了所以就加回來...

Percona 要推出 Percona Server 8.0 了...

MySQL 8.0 從四月推出到現在也快半年了,Percona 總算是要推出對應的 Percona Server 8.0 了。目前提供 alpha 版本讓大家測試:「Announcement: Alpha Build of Percona Server 8.0」。

要把現在的 patch 都轉移到 8.0 上應該是個超級大工程,可以預期系統不會很穩定... 要用來做事的最好還是先維持 5.7,可以省掉很多麻煩。

Debian 對 Reproducible Build 的討論

Debian 在討論 package 的可重製性:「debian-policy: Packages should be reproducible」。本來的討論其實還好,在 2017/08/12 的 DebConf17 後,看起來有一些人取得共識,於是討論熱了起來... 有興趣的人可以從 Message #107 開始看。

Debian 社群想做的事情是「給足夠的資訊以及 source code,就能產生出一模一樣的 binary package」,這樣就不需要盲目信任 Debian 官方。

Debian 官方的 Wiki 上有「ReproducibleBuilds Howto」可以參考,然後也看到「reproducible-builds.org」這個站。

Stripe 的 Increment 雜誌

Stripe 推出了 Increment 雜誌,講團隊合作時的各種議題:「Introducing Increment」。

And so we've decided to start Increment, a software engineering magazine dedicated to providing practical and useful insight into what effective teams are doing so that the rest of us can learn from them more quickly.

雜誌網站上也有類似的描述:

A digital magazine about how teams build and operate software systems at scale.

Increment is dedicated to covering how teams build and operate software systems at scale, one issue at a time.

可以看一看 Stripe 對團隊合作的想法...

用 npm 取代 Build Tools (像是 gulp 或 grunt)

這篇「How to Use npm as a Build Tool」教你如何用 package.jsonscripts 取代 gulp 或是 grunt 這類 Build Tools。

文章裡面可以看到各種奇技淫巧都出現了,dependency 的部份用 recursive 解決 (npm 內部自己再呼叫 npm 執行),stream 的部份用 pipe 解決 (這個到是很自然),然後用外部程式掛進來處理 watch 與 livereload,甚至還出現可以自己寫 js 檔案呼叫的方法... XDDD

無所不用其極!反正我就是不要用 gulp 與 grunt... XD

可以欣賞一下怎麼做的...

推薦《Build APIs You Won't Hate》這本書

7/26 就買了,算一算到現在也快四個禮拜,剛剛總算是讀完了,所以可以跟大家推薦《Build APIs You Won't Hate》這本書。

作者 Phil SturgeonPHP 的資深開發者,同時也是 PHP-FIG 的投票成員。

這本書講了很多 API 設計時會遇到的問題。作者不是直接講「用什麼方法是對的」,而是提出每一種方法的缺點,然後再下結論。

尤其是缺點的部份,呼應主題的「You won't hate」,如果你因為總總原因而無法設計出完美的 API,你至少要避免設計出你自己看了就討厭的 API。

裡面也給了很多程式範例 (大多都是 PHP),甚至告訴你寫 API 文件的重點。

推薦這本書給所有需要設計或實做 API 的人。

Firefox 將可以在 CSS 內使用變數...

Firefox 將在 29 版支援 CSS 變數 (現在是 26 版):「CSS Variables in Firefox Nightly」。標準是出自 W3C 的「CSS Custom Properties for Cascading Variables Module Level 1」(在寫這篇文章時還是 draft)。

程式碼會長這樣:(直接引用比較複雜的程式碼)

:root {
  var-companyblue: #369;
  var-lighterblue: powderblue;
  var-largemargin: 20px;  
  var-smallmargin: calc(var(largemargin) / 2);
  var-borderstyle: 5px solid #000;
  var-headersize: 24px;
}
.partnerbadge {
  var-companyblue: #036;
  var-lighterblue: #369;
  var-headersize: calc(var(headersize)/2);
  transition: 0.5s;
}
 
@media (max-width: 400px) {
  .partnerbadge {
     var-borderstyle: none;  
     background: #eee;
  }
}
 
/* Applying the variables */
body {font-family: 'open sans', sans-serif;}
 
h1 {
  color: var(companyblue);
  margin: var(largemargin) 0;
  font-size: var(headersize);
}
h2 {
  color: var(lighterblue);
  margin: var(smallmargin) 0;
  font-size: calc(var(headersize) - 5px);
}
 
.partnerbadge {
  padding: var(smallmargin) 10px;
  border: var(borderstyle);
}

本來用 Sass/SCSS 做的事情就可以把計算這部份推到 browser 上處理...