在 Fly.io 上面跑 PHP

Heroku 把 free tier 拔的差不多後 (「Heroku 公佈了廢止免費方案的時間表」、「Heroku 的替代方案」),大家手上的小專案都往其他的服務跑,目前看起來做的比較有規模的就是 Fly.io 了,一個人可以建很多個 organization,而每個 organization 都有 free quota 可以用...

Fly.io 官方的文件 FLy.io Docs 裡面可以看到說明,介紹怎麼把 Laravel 站台跑起來,不過沒介紹怎麼跑純 PHP 站台,所以就看了文件研究看看,發現可以用 Docker container 跑,那就簡單了。

專案放在 GitHubgslin/fly-vanilla-php 上面。

一開始我的 Fly App 用的是 V1 的版本,是跑起來了,但後來還是換到 V2 跑,雖然兩者用起來沒有太大區別 (參考「Fly Apps」這邊的說明),但畢竟官方打算都把 V1 掛上 legacy 了,新的專案就儘量別用了...

另外一開始用 buildpacks 編 Docker image,但發現太慢了,就還是去 Docker Hub 上找個大戶人家包好的 image 來用。

首先是 fly.toml 這個檔案,這邊就直接指定用 Dockerfile 來編。

然後是 Dockerfile 這個檔案,這邊用的 image 是 richarvey/nginx-php-fpm 這包,預設會開在 port 80,所以 fly.toml 裡面就把 internal_port 指定在 80

另外就是指定了 WEBROOT,我把 root 放在 public/ 下面。

跑起來以後就可以用他提供的網址測試了,我這個專案在 https://hidden-river-325.fly.dev/ 這邊可以看到,另外我有設定自己的 domain,在 https://test-fly.gslin.com/ 也可以看到一樣的 phpinfo(); 資訊。

這邊有個小插曲,我想要掛自己的 domain 上去跑 HTTPS,但如果機器沒有掛 IPv6 address 的話,Fly.io 的系統不會認定設定已經完成,也就不會往下去申請 Let's Encrypt 的憑證,我放了一天覺得奇怪,摸了辦天才發現這個 "feature"。

修改 booking.com 的 dark pattern

Hacker News Daily 上看到修改 booking.comdark pattern 的套件:「De-Stressing Booking.com (alexcharlton.co)」,原文連結到「De-stressing Booking.com」,這是 2019 的文章,在介紹他寫的套件。

裡面講的是像這樣的東西:

這個例子裡面是故意用有壓力的顏色 (這邊是紅色) 去推動使用者趕快下單,算是蠻經典的 dark pattern,作者有舉個 Airbnb 的類似例子,比較起來就好很多:

在 comment 也有人提到其他種類的 dark pattern,故意把一些飯店標成已經售出,製造你不趕快訂就會釘不到的假象。不過下面有人提到,在有些法律制度比較完整的國家裡面,這會牽扯到不實宣傳之類的行為:

After browsing hotels for some time I've seen booking.com show several hotels start to sell out of rooms. That usually causes me to hurry up and book, but after several hotels showed full at once I got suspicious and checked my partners phone. The hotels still showed as available there. Dark stuff. Their website is otherwise pretty good though and I still use them.

在「Online hotel booking」這邊有英國對這些線上訂房網站的調查與裁罰。

然後在 Hacker News 上的 comment 有看到一個有趣的方法,是 PresidentObama 提到的方法 (這 id XDDD),用 uBlock Origin 來擋:

From the last time booking.com was discussed I picked up some ublock origin filters that make the website more bearable.

You can copy and paste them directly in your ublock config (ublock options -> My filters)

  ! https://news.ycombinator.com/item?id=21860328
  booking.com##.soldout_property
  booking.com##.sr_rooms_left_wrap.only_x_left
  booking.com##.lastbooking
  booking.com##.sr--x-times-booked
  booking.com##.in-high-demand-not-scarce
  booking.com##.top_scarcity
  booking.com##.hp-rt-just-booked
  booking.com##.cheapest_banner_content > *
  booking.com##.hp-social_proof
  booking.com##.fe_banner__red.fe_banner__w-icon.fe_banner__scale_small.fe_banner
  booking.com##.urgency_message_x_people.urgency_message_red
  booking.com##.rackrate
  booking.com##.urgency_message_red.altHotels_most_recent_booking
  booking.com##.fe_banner__w-icon-large.fe_banner__w-icon.fe_banner
  booking.com##.smaller-low-av-msg_wrapper
  booking.com##.small_warning.wxp-sr-banner.js-wxp-sr-banner
  booking.com##.lock-price-banner--no-button.lock-price-banner.bui-u-bleed\@small.bui-alert--large.bui-alert--success.bui-alert

另外還有擋一些追蹤的 url parameter:

Apart from these, I use some additional ublock filters to block some of their tracking that I am not ok with.

$removeparam=/^(error_url|ac_suggestion_theme_list_length|ac_suggestion_list_length|search_pageview_id|ac_click_type|ac_langcode|ac_position|ss_raw|from_sf|is_ski_area|src|sb_lp|sb|search_selected|srpvid|click_from_logo|ss|ssne|ssne_untouched|b_h4u_keep_filters|aid|label|all_sr_blocks|highlighted_blocks|ucfs|arphpl|hpos|hapos|matching_block_id|from|tpi_r|sr_order|srepoch|sr_pri_blocks|atlas_src|place_types)/,domain=booking.com
  $removeparam=/sid=.\*;BBOX/,domain=booking.com
  ||www.booking.com/c360/v1/track
  ||www.booking.com/fl/exposed
  ||booking.com/personalisationinfra/track_behaviour_property
  ||booking.com/has_seen_review_list

不過好像很少用 booking.com 了...

Kagi 開發的 Universal Summarizer

在「Universal Summarizer (kagi.com)」這邊看到的新服務,可以給出某個網址的 summary。服務的本體則是在「Kagi - Universal Summarizer」這邊,從網址可以猜測是 Kagi 的實驗項目。

像是 CNN 的「Biden’s dramatic warning to China」這篇,他抓出對應的 summary 看起來沒什麼問題:

President Joe Biden delivered a dramatic warning to China in his State of the Union address, vowing to protect America's sovereignty if China threatens it. He specifically named President Xi Jinping, saying "Name me a world leader who'd change places with Xi Jinping. Name me one!" This marked a stark escalation in the US-Chinese relationship, which has been strained by a balloon surveillance program and other issues. Biden also addressed Russia, calling their invasion of Ukraine a test for America and the world. His speech highlighted the unified opposition to China in US politics, with House Speaker Kevin McCarthy having convened a bipartisan House committee to examine the perceived threat from the Chinese Communist Party. Biden's comments also served as an important milestone in the increasingly tumultuous competition between the US and China, as the US shifts to talking about establishing guardrails for the relationship and protecting the Western-led rules-based international system.

這個功能可以用 GPT-3.5 或是 ChatGPT 串,但不確定 Kagi 是串上去還自己搞?我猜有蠻大的機會是串的...

然後他的網址設計因為是 url 傳遞的方式,可以包裝成 bookmarklet 形式放在快速列上面用:「Kagi Universal Summarizer」。

另外在 HN 的討論裡面看到很厲害的用法,把 https://bellard.org/quickjs/pi_bigdecimal.js 這段 javascript code 的 url 丟進去,然後居然出現了程式碼的說明,居然還正確判斷出是 Chudnovsky algorithm

This code uses the QuickJS bigdecimal type to calculate the value of pi to a given precision. It does this by using the Chudnovsky algorithm, which is a series of calculations that can be used to approximate pi. The code is written in Javascript and uses BigInt and BigDecimal to perform the calculations. It is interesting to note that the code also takes into account the possibility of bad rounding for the last digits, and adds extra digits to reduce the probability of this happening.

既然包了一個 bookmarklet,最近應該會常常拿出來用...

把所有在 CSS 裡面「有名字」的顏色都呈現出來

前幾天在 Hacker News Daily 上看到「Show HN: A color picker for named web colors (arantius.github.io)」這個作品,把 CSS 裡面有名字的顏色都呈現出來:「Named Colors Wheel」。

移動上去可以看到每個顏色在 CSS 被定義的名稱與色碼,另外從 html code 裡面可以看到他參考了「<named-color>」這份資料。

另外在 Hacker News 上的這則留言也讓我笑的蠻開心的,greenyellow (在黃色 yellow 的左邊) 與 yellowgreen (在 greenyellow 的右上) 的差異:

Also: Finally, a tool to help me decide between greenyellow and yellowgreen.

另外看到這種圖會讓我想到四色定理 (Four color theorem),不過跟這個主題沒什麼關係就是了...

網頁大小 14KB 與 15KB 的速度差異

Hacker News 上看到「Why your website should be under 14kB in size」這篇,對應的討論在「A 14kb page can load much faster than a 15kb page (endtimes.dev)」,在講網頁大小 14KB/15KB 的速度差異比 15KB/16KB 大很多的問題:

What is surprising is that a 14kB page can load much faster than a 15kB page — maybe 612ms faster — while the difference between a 15kB and a 16kB page is trivial.

原因是 TCP slow start 造成的:

This is because of the TCP slow start algorithm.

而網頁這邊 TCP slow start 目前大多數的實做都是 10 packets 後發動:

Most web servers TCP slow start algorithm starts by sending 10 TCP packets.

然後再組合 1500 bytes/packet 以及 overhead,就差不多是 14KB 了:

The maximum size of a TCP packet is 1500 bytes.

This this maximum is not set by the TCP specification, it comes from the ethernet standard

Each TCP packet uses 40 bytes in its header — 16 bytes for IP and an additional 24 bytes for TCP

That leaves 1460 bytes per TCP packet. 10 x 1460 = 14600 bytes or roughly 14kB!

然後 HTTP/3 也可以看到類似的設計 (出自「QUIC Loss Detection and Congestion Control」:

Sending multiple packets into the network without any delay between them creates a packet burst that might cause short-term congestion and losses. Implementations MUST either use pacing or limit such bursts to the initial congestion window, which is recommended to be the minimum of 10 * max_datagram_size and max(2* max_datagram_size, 14720)), where max_datagram_size is the current maximum size of a datagram for the connection, not including UDP or IP overhead.

算是一個小知識... 但對於現在肥滋滋的網頁效果來說就沒辦法了,而且考慮到大一點的網站會在一個 TCP 連線裡面可能會傳很多 request,其實早就超過 TCP slow start 的門檻了。

CSS 的 :has() 有新進展了

在「Using :has() as a CSS Parent Selector and much more」這邊看到 Safari 宣佈對 :has() 的支援,查了一下 Can I use... 上面的資料「:has() CSS relational pseudo-class」,看起來是從 15.4 (2022/05/14) 支援的。

隔壁 Google Chrome 將在下一個版本 105 (目前 stable channel 是 104) 支援 :has(),沒意外的話 Microsoft Edge 應該也會跟上去,看起來只剩下 Firefox 要開了。

先前在「Chromium 的 :has() 實做進展」這邊有翻一下進度,看起來 Chromium 這邊要進入收尾階段了。

等普及後一些延伸套件裡的寫法也可以用 :has() 來處理了,就不用自己在 javascript 裡面檢查半天...

南韓最高法院也對 Web Scraping 給出了類似美國的判例

也是上個禮拜在 Hacker News 上看到的新聞,南韓最高法院對於 web scraping 也做出了類似美國 HiQ Labs v. LinkedIn 案的判例:「Korean Supreme Court Provides Clarity on Web Scraping and Violation of the Relevant Korean Laws, including the Copyright Act and Information Protection Act (Supreme Court, 2021Do1533, May 12, 2022)」,原文似乎已經被 paywall,但可以從 Internet Archive 的「這邊」與 archive.today 的「這邊」讀到原全文。另外在 Hacker News 上的討論「The Supreme Korean court says that scraping publicly available data is legal (lexology.com)」。

hiQ 的案子之前有寫過,可以參考「hiQ 爬 LinkedIn 資料的無罪判決」這邊。

南韓最高法院認為這次的抓取公開資料不違反南韓的法令:

On May 12, 2022, the Korean Supreme Court held in Case No. 2021Do1533 that scraping publicly available data from a competitor’s website does not violate the asserted laws, including the Copyright Act and the Act on Promotion of Information and Communications Network Utilization and Information Protection (“Information Protection Act”).

比較特別的是在講刑事責任的第三點提到了 read only,不確定是不是反駁原告的立論:

The Supreme Court also found Defendants not guilty of violating the Criminal Code in light of the following findings: (i) the Defendants’ act of scraping did not interfere with information processing on Yanolja’s API server; (ii) the Defendants’ act of scraping did not interfere with Yanolja’s booking business; (iii) the Defendants did not interfere with Yanolja’s business, because its scraping did not modify data within Yanolja’s API server; and (iv) the Defendants lacked mens rea for criminal interference with business, as the Defendants merely intended to collect accommodation information from Yanolja’s API server.

整體看起來是被告的大獲全勝?

HTTP 標準的翻新

HTTP 的標準之前都是用新的 RFC 補充與修正舊的標準,所以整體讀起來會比較累,對於開始了解 HTTP 的人會需要交叉讀才能理解。

而這次 RFC 9110~9114 算是一次性的把文件全部重新整理出來,可以看到蠻多人 (以及團體) 都有丟出來對應的看法,這邊丟這兩篇:「A New Definition of HTTP」與「HTTP RFCs have evolved: A Cloudflare view of HTTP usage trends」。

而這五個 RFC,從名稱列出來就可以看出來命名簡單粗暴,把核心概念先拆出來講,然後再講不同 protocol 的部份:

Cloudflare 這邊提供了一些資料,可以看到三個 protocol 使用率都算高,而目前最高的是 HTTP/2:

另外比較特別的是 Safari 在 HTTP/3 的趨勢居然有倒縮的情況:

然後 bot 的部份幾乎大家都支援 HTTP/2 了,目前還沒看到太多 HTTP/3 的蹤跡,倒是 LinkedIn 的 bot 有個奇怪的 adoption 然後全部 rollback 的情況,而最近又開始少量導入了:

這次看起來淘汰了 (obsolete) 很多之前的文件,以後要引用得往這五份來引...

GOV.UK 拔掉網頁上的 jQuery

英國政府的網站拔掉 jQuery 了:「GOV.UK drops jQuery from their front end.」,Hacker News 上的討論也可以看一下:「Gov.uk drops jQuery from their front end (web.dev)」。

當年會選擇用 jQuery 大概有幾個原因,第一個是當年 (很舊的 browser 版本) 對 DOM 的操作非常的混亂,像是:

而 jQuery 在那個年代就已經把這堆 DOM operation 都窮舉支援了 (可以直接看「Category: DOM Insertion, Around」、「Category: DOM Insertion, Inside」、「Category: DOM Insertion, Outside」這三個大分類),可以注意 jQuery 1.0 就已經把基本界面都弄出來了,而 jQuery 1.0 是 2006 年八月出的,另外 IE7 是在 2006 年十月出,也就是說在 IE6 的年代就提供一整套完整的方案。

另外 jQuery 幫忙處理了早期 IE 與 W3C 標準的不一致行為,像是經典的 attachEvent (出自 DOM events):

Microsoft Internet Explorer prior to version 8 does not follow the W3C model, as its own model was created prior to the ratification of the W3C standard. Internet Explorer 9 follows DOM level 3 events, and Internet Explorer 11 deletes its support for Microsoft-specific model.

就功能面上來說,jQuery 提供的 Sizzle engine 也提供了 CSS selector 的能力,這在早期還沒有 querySelectorAll() (IE9+) 的時候方便不少,而且就算有了 querySelectorAll(),Sizzle 支援的 CSS selector 更完整。

上面提到的解決 browser 早期的各種亂象,jQuery 其實也帶入了不少好用的 pattern,其中一個是 fluent interface 讓人寫起來很舒服:(這個範例只是要介紹 fluent interface,不要管實際上在亂搞什麼 XD)

$('#foo').html('<p>bar</p>').css('width: 100px;');

另外就是不需要對 null object 做太多處理:

$('#foo').css('width: 100px;');

與這樣比較:

let elem = document.querySelector('#foo');
if (elem) {
    // ...
}

不過在這些年,負面的部份已經大幅改善了,所以也陸陸續續可以看到很多人在討論要怎麼拔掉 jQuery。而這次英國的 GOV.UK 拔掉 jQuery 有看到一些效果:

  • Less front end processing time overall.
  • 11% less blocking time at the 75th percentile.
  • 10% less blocking time for users at the 95th percentile. These are users who experience seriously adverse network and device conditions, and every performance gain matters especially for them.

但說實話,~10% 左右的 performance 改變比預期中少很多耶?可以看出來 John Resig 當年在上面為了效能花了多少功夫...

這次的結果反倒是讓我在思考,如果可以用 jQuery 降低開發的瓶頸,我還蠻偏好就拿 jQuery 進來用...