BazQux 提供 theme、font 的調整功能,與 image proxy

BazQux 是個付費的 RSS/Feed Reader,用了好幾年,難得有個久違的改版...

如同標題所寫的,前面兩個改變還好 (可以自己透過套件插 CSS 進去修改),這次主要是多了 image proxy 讓使用者選擇:「Themes, typography and image proxy」。

還是先回到前面兩個改變:theme 與 font 有不少可以調整的,我是把兩個與字型大小的設定都調到最小,然後把文字寬度調到最大,其他的就看順眼就好 :o

這次提供的 image proxy 對於隱私比較好,但目前的缺點是 img.bazqux.com 的主機在德國,有些圖檔讀起來就比直接連慢很多,這邊的 trade off 也讓使用者可以自己決定。

這次提供的設定是依照 per browser 而非 per account,對我來說這樣子的設計讓我在 UbuntuMac 的機器上可以用不同的設定:

All appearance settings are saved per browser.

這次的改版頗不賴...

補上 nginx 對 favicon 的壓縮...

從「Compressed favicons are 70% smaller but 75% of them are served uncompressed」這邊看到的,他們發現大約有 73.5% 的網站沒有壓縮 favicon.ico 檔:

The HTTP Archive dataset of favicons from 4 million websites crawled from desktop devices on May 2019 shows that 73,5 % of all favicons are offered without any compression with an average file size of 10,5 kiB, 21,5 % are offered with Gzip compression at an average file size of 4 kiB, and 5 % offer Brotli compression at an average file size of 3 kiB.

我自己的也沒加... 補上 gzip 相關的設定後,favicon.ico 的傳輸量從 4.2KB 降到 1.2KB。

我是使用 nginx,在 Ubuntu 上 nginx 的 nginx.conf 內 gzip 預設已經有開,所以只要增加一些設定讓他知道要處理 ico 檔案就可以了。

方法是在 /etc/nginx/conf.d/gzip.conf 裡面放:

gzip_comp_level 9;
gzip_types image/vnd.microsoft.icon image/x-icon;
gzip_vary on;

跟文章裡面提到的多了兩個設定,一個是 gzip_comp_level 改成 9 (預設是 1),另外有 gzip 時應該要在 Vary 表示,避免 cache 出錯。

用 CleanTalk 擋論壇的廣告...

看到 Hacker News 上「You probably don’t need ReCAPTCHA (kevv.net)」這篇在討論 reCAPTCHA (原始文章在「You (probably) don’t need ReCAPTCHA」這篇),裡面除了認為 reCAPTCHA harmful 的觀點還 ok 外,其他的觀點我覺得都無法讓人認同...

因為看到 reCAPTCHA 而想到已經用了 CleanTalk 一陣子,效果還不錯,所以寫一篇講一下...

起因是維護「FJC 華語社群」這個站台,這是一個使用 phpBB 架設的站台,為了方便,我透過 RSS + IFTTT,當論壇上有新文章時就會自動貼到 Line 群組上面...

為了避免論壇上面有 spam,我有針對註冊開 reCAPTCHA,但發現還是有不少「全人工註冊」的帳號會貼文,所以就得找更精準的服務來用... 後來在 phpBB 網站上翻到 CleanTalk 這個服務,對於在「CleanTalk Anti-Spam Installation Manuals」這頁看到支援的軟體只要 USD$8/year/site,從一月用到現在超過五個月了,就沒遇到 spam 了...

機制上他會透過 client database 分析他們自己的 spam 資料庫,另外在發文時他也會分析文章內容是不是 spam,所以裝上去之後兩關都有過濾機制...

類似的服務還有 Akismet,不過畢竟是知名品牌,費用相較起來貴不少...

Firefox Premium

Firefox 打算要推出 Firefox Premium:「Mozilla will reportedly launch a paid version of Firefox this fall」。

現有的功能仍然會維持免費,所以目前猜測 Firefox Premium 應該是把附加服務包起來變成月費包裝:

So, what we want to clarify is that there is no plan to charge money for things that are now free. So we will roll out a subscription service and offer a premium level. And the plan is to introduce the first one this year, towards fall. We aim for October.

目前有提到的是 VPN,先前 Mozilla 有跟 ProtonVPN 合作,有可能會在接下來的 Firefox Premium 也一起合作...

Hacker News 上的討論「Mozilla will reportedly launch a paid version of Firefox this fall (thenextweb.com)」有些值得看一下...

其中一個討論的主題是,既然以 Firefox 當作招牌打包,那麼本來免費時的某些行為大家還可以「忍受」,到了付費版的時候就不是這樣了...

既然目標是十月,先放著吧... 後續應該會有其他的新聞。

自產生程式的 HTML 版:看到的頁面就是 HTML 程式碼

自產生程式,或是更常用的英文名 Quine 指的是「程式輸出的結果」與「程式碼本身」相同的程式,算是一種趣味性的程式...

Hacker News 上看到「Show HN: This page is a truly naked, brutalist HTML quine (secretgeek.github.io)」這個連結,裡面是 HTML 版的 Quine,原始網頁在「This page is a truly naked, brutalist html quine.」,頁面長這樣 (取前面的部份):

你在網頁上看到的所有文字,就是程式碼本身 (有一個小地方例外,可以直接看原始碼確認),而且這個 HTML 還說明怎麼做到這件事情。

裡面是一層一層解,第一個提到的是 * { display:block; },這使得所有的元素都會顯示出來,包括了像是 <title> 這樣本來放在 <head> 裡的元素。

唯一的例外是 <style> 本身避不開:

The only other style that is special is "style" itself, which has to include an escape character to avoid being taken literally.

翻了一下 Hacker News 裡的討論,大家都還蠻欣賞的,主要是有些感嘆很有趣,像是說這個網站的可讀性反而比其他新聞站台好很多:

This is more readable than many news websites I've come across

話說回來,我對新聞類的網站還蠻喜歡關掉 javascript 的,通常效果都很好...

所以 Google 要對 ad blocker 全面宣戰了...

一月的時候 Google 就提出了「Manifest V3」,打算閹掉 extension 透過 webRequest 攔截連線的能力,而這個功能就是 uBlock Origin 這類 ad blocker 的基礎。

當時 Google 宣稱 webRequest 嚴重影響瀏覽器效能,但 Ghostery 的團隊則做了實驗證明影響極小:「Ad blocker performance study in response to Manifest V3 finds that Ghostery's ad blocker beats the competition」、「Google遭證據打臉,廣告封鎖程式幾乎不影響Chrome效能」。

All content-blockers except DuckDuckGo have sub-millisecond median decision time per request.

另外在 Alphabet (Google 母公司) 遞交給美國證管會的資料 (FORM 10-K) 可以看到他們把 ad blocker 視為威脅:「goog10-kq42018.htm」。

New and existing technologies could affect our ability to customize ads and/or could block ads online, which would harm our business.

Technologies have been developed to make customizable ads more difficult or to block the display of ads altogether and some providers of online services have integrated technologies that could potentially impair the core functionality of third-party digital advertising. Most of our Google revenues are derived from fees paid to us in connection with the display of ads online. As a result, such technologies and tools could adversely affect our operating results.

所以後續的行為就很清楚了,他們決定 Manifest V3 還是會閹掉 webRequest (以有效抑制 ad blocker 的能力,反正繼續堅持效能問題,當作沒聽到),只開放企業版本使用:「Google to restrict modern ad blocking Chrome extensions to enterprise users」。

Mozilla 愈來愈不成氣候的情況下,現在要看的戲應該是 Google 是否會因此受到 anti-trust 的挑戰呢...

Salesforce 弄了一個新的玩意出來...

然後在 Hacker News 上被酸爆了:「Open-sourcing the Lightning Web Components framework (salesforce.com)」。引用的原文在「Introducing Lightning Web Components Open Source」這邊。

主要還是大家已經厭倦前端一直丟東西出來,但是速度一直都沒什麼改善... 用傳統的 server rendering 反而省了不少 client 端的 CPU resource。

話說回來,前幾天的伺服器爆炸好像沒看到什麼後續新聞... (參考「Salesforce enables modify all in all user profiles」、「Salesforce系統更新意外造成權限擴張,用戶服務被迫中斷」)。

Cloudflare 改善了同時下載同一個檔案的效率...

在「Live video just got more live: Introducing Concurrent Streaming Acceleration」這邊 Cloudflare 說明他們改善了同時下載同一個 cache-miss 檔案時的效率。

本來的架構在 cache-miss 時,CDN 這端會先取得 exclusive lock,然後到 origin server 抓檔案。如果這時候有其他人也要抓同一個檔案,就會先卡住,避免同時間對 origin server 產生大量連線:

這個架構在一般的情況下其實還 ok,就算是 Windows Update 這種等級的量,畢竟就是一次性的情況而已。但對於現代愈來愈普及的 HTTP(S) streaming 技術來說,因為檔案一直產生,這就會是常常遇到的問題了。

由於 lock 機制增加了不少延遲,所以在使用者端就需要多抓一些緩衝時間才能確保品質,這增加了直播的互動延遲,所以 Cloudflare 改善了這個部分,讓所有人都可以同時下載,而非等到發起的使用者下載完才能下載:

沒有太多意外的,從 Cloudflare 內部數字可以看出來這讓 lock 時間大幅下降,對於使用者來說也大幅降低了 TTFB (time to first byte):

不確定其他家的情況...

在 DOM 操作時的 insertAdjacentElement

看到「Why I'm still using jQuery in 2019」這篇,裡面提到了 jQuery 很多操作上相較於 vanilla javascript 簡單很多,其中一個例子提到了 DOM 操作的 insertAdjacentElement()

el.insertAdjacentElement('afterend', other) undoubtedly works, but $(el).after(other) is actually palatable.

其實我不知道 insertAdjacentElement() 這個功能,我知道的操作都是透過 parentElementfirstChild 在移動位置,然後用 appendChild()insertBefore() 放進去。

跑去 MDN 上查了「Element.insertAdjacentElement() - Web APIs | MDN」後才發現有這個好用的東西:

targetElement.insertAdjacentElement(position, element);

position 的四個變化減少了以前組積木組多了會頭暈的情況。

接下來是研究支援度的問題,才發現可能是因為 Firefox 一直到 48 才支援 (從「Firefox version history」可以看到 48 是 2016 年八月釋出),所以網路上大多數的文章都還是用組積木的方式在介紹 DOM 操作,以避免相容性的問題:

Firefox 48 was released on August 2, 2016 for both desktop and Android.

另外還看到 insert​Adjacent​HTML()insert​Adjacent​Text() 可以用,其中讓我注意到 MDN 上面提到 insert​Adjacent​HTML() 居然是 Firefox 8+?本來以為是 48+ 的誤植,但從 Mozilla 的記錄「Implement insertAdjacentHTML」這邊可以看到,應該是在 Firefox 8 的時候實作的,這樣的話可以當作 insertAdjacentElement() 的替代品 (如果考慮到古早的相容性),只是這邊需要輸入 html string,跟其他操作是是用 element 不太一致...

意外的學到不少歷史故事... @_@

測試 GFW 變成一個服務了...

針對分析在 GFW 牆內的情況,看到「GFWaaS - GFW as a Service」這樣的服務出現了,依據價位提供兩個不同等級的功能:

  • $49/month 是 HAR Logs + Screencasts
  • $199/month 則是再加上 Browser VNC

對於人不在中國,但需要照顧中國市場的開發團隊應該會有些幫助?