Tag: best

實做 RSS/Atom feed 的最佳實踐

前陣子看到的文章，在講實做 RSS/Atom feed 的 best practice：「RSS Feed Best Practises」。

最簡單的當然還是丟個 Atom feed 就好，接下來就是一些延伸出來可以多做的事情。

首先有提到 discovery，可以讓 crawler 在抓到 HTML 頁面的時候知道 feed 在哪裡，這對於 user experience 來說蠻重要的，大多數的 feed reader 都可以透過這個方式抓到真正的 feed 位置。舉個例子來說，我丟 https://blog.gslin.org/ 進 feed reader，可以透過 discovery 的方式告訴 feed reader 我的 feed 位置在 https://blog.gslin.org/feed/：

<link rel="alternate" type="application/rss+xml" title="Gea-Suan Lin&#039;s BLOG &raquo; Feed" href="https://blog.gslin.org/feed/" />

另外是常見的 cache 問題，這個設起來不算太難，主要是細節很多 XD

後面提到的 WebSub，以前叫做 PubSubHubbub，是一個在 feed 更新後主動通知讓 crawler 來抓的機制。不做的話也還好，現在的 crawler 現在都還蠻聰明的，會針對更新比較頻繁的 feed 常常去確認，但這樣總是會有一些時間差。

不過裡面好像沒提到 Update Services，這是比較早期的方法，走 XML-RPC，雖然也不知道現在有什麼用途了，大概就是這樣所以沒提...

Simon Willison 提出來的 PAGNIs

Simon Willison 提出來「PAGNIs: Probably Are Gonna Need Its」，整理一下裡面提到的功能。

第一個是 kill switch，在 API 設計上一開始納入強制升級的傳回值，文章裡面有提到一些情境。

第二與第三剛好就是 Test + CI + CD，常常是 best practice，除了文章裡面提到的東西，在其他人的文章裡面應該也都有類似的討論。

第四是 API 的分頁，這個部份只講了要分頁，沒講到分頁時資料庫的效率問題，這部份可以參考「API pagination best practices」這邊的討論，key-based 的 pagination 效能會比較好，也可以避免對資料庫的 DoS 攻擊。

第五是 API 的 log，作者的建議是一開始什麼都存起來，等量大的時候再拔掉，會對於初期開發與除錯很有幫助。我是會掛 Sentry 這類的東西，有錯誤的時候會記錄起來。

第六看不懂他想要幹什麼，先跳過去。第七是在講要盡早實做這些 practice，等專案都推出去後再回過來實做都很花時間。

有些可以練手一下...

Shell Script 裡面 [ "x$var" = "xval" ] 的歷史

看到「What exactly was the point of [ “x$var” = “xval” ]?」這篇，在講為什麼不直接寫 [ "$var" = "val" ] 而是會加上 x 而寫成 [ "x$var" = "xval" ]，被稱為 x-hack 的 workaround... (其實已經變成 best practice 了)

最常被拿出來講的是 - 開頭的字串，不過文章作者找到更多奇怪的 bug report，像是 ( 與 ) 之類的問題 XD

雖然作者提到大概在 2010 (或是 2015) 都修完了，但我應該還是會繼續這樣寫 (算是 best practice 了)，可以避免在遇到老系統上遇到問題...

Bash Script 的好習慣

這篇給了一份 bash script 用的 tempalte，但更重要的反而是裡面提到的 best practice：「Minimal safe Bash script template」。

首先是不要寫 /bin/bash 這件事情，因為有些系統是沒有 /bin/bash 的，像是 FreeBSD。

如果程式是可以用 POSIX sh 語法的話，應該優先考慮 /bin/sh，如果用到非 POSIX 標準的語法的話，用 env 帶出來會少一些問題：

#!/usr/bin/env bash

再來是 fail 時就趕快停止，不要再往下執行，這點算是老生常談了，文章作者也有給一個範例說明：

set -Eeuo pipefail

再來另外一個還蠻有用的事情是攔下常見的 signal 處理「後事」：

trap cleanup SIGINT SIGTERM ERR EXIT

cleanup() {
  trap - SIGINT SIGTERM ERR EXIT
  # script cleanup here
}

其他的可以看一看，但未必要全盤收下...

RFC 裡面的 MUST/SHOULD/MAY

讀 RFC 文件時常看到會使用這組定義，甚至有些非 RFC 文件也會使用：

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

這邊提到的 RFC 2119 就是 1997 年訂的「Key words for use in RFCs to Indicate Requirement Levels」這篇，以 2020 年的現在來說，這組定義已經被人熟知，用這組定義可以讓閱讀的人很輕鬆的了解條件的強制性。

剛剛在讀新的文件時發現這段文字有更新，往回查發現是針對大小寫的差異提出更新：「Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words」，主要是這兩條：

  • The words have the meanings specified herein only when they are in all capitals.
  • When these words are not capitalized, they have their normal English meanings and are not affected by this document.

然後也更新了引用的部份：

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

不過就算是 2017 年之前應該也是這樣讀就是了...

PostgreSQL 的 Don't Do This

在 Hacker News Daily 上看到的資料，整理了 PostgreSQL 上不要使用的功能：「Don't Do This」，而且是放在官方網域 wiki.postgresql.org 上。

裡面這些想法不知道出處是哪邊... 有不少功能算是 PostgreSQL 特有的功能 (以 open source RDBMS 這個領域來看)，而且大概也還想的到用的場景，你卻在上面叫大家不要用，再寫的時候大概是吸了一批很純的，已經不知道要從哪邊開始吐槽...

要看的話連同 Hacker News 上的留言一起看會比較有前因後果：「https://news.ycombinator.com/item?id=19817531」。

Percona 分析在 AWS 上跑 Percona XtraDB Cluster 的效能 (I/O bound)

Percona 的人分析了在 Amazon EC2 上跑 Percona XtraDB Cluster (PXC) 效能 (I/O bound)：「Best Practices for Percona XtraDB Cluster on AWS」。

先看他們做出來的圖：

直接跳到結論的地方。如果資料可以掉，用 i3 本地 storage 的效能是最好的，如果要資料不能掉，用 EBS 的 Provisioned IOPS SSD (io1) 的效能會比 General Purpose (gp2) 好很多。

另外 instance type 的選擇上，避免用 {i3,r4}.large，因為測試出來發現 {i3,r4}.xlarge 的效能好不只一倍。

不過 Aurora 的 Multi-master 已經在 Preview 了啊，如果 Percona 的人拿到帳號的話，應該會有單位成本的效能比較可以看...

Facebook 在 MySQL 裡存時間的型態

在 MySQL at Facebook 的這邊說明提到了，Facebook 內部是使用 INT UNSIGNED 儲存時間：

Which gets us to the point that it is no different than storing INT (hello 2038?) or UNSIGNED INT (a bit later) or BIGINT (till the end of time) and possibly passing binary values in efficient protocols eventually.

If you got that far of this post, your likes in Facebook graph are stored with 'INT UNSIGNED' time field.

順道一提，INT 是 2038 年問題，INT UNSIGNED 是 2106 年問題。

而 Facebook 在 MySQL 上會選擇不使用 DATETIME 與 TIMESTAMP 的原因其實跟技術搭不上太多關係，主因是因為 MySQL 根本沒打算修 XDDD

It is my favorite MySQL bug, simply because it forces any reasonable mind not to use TIMESTAMP, and MySQL is never going to fix it (nor will ever understand time). I lost my temper a bit on that bug: https://bugs.mysql.com/bug.php?id=38455

我的猜測是已經爛成一團了，而且大家都有 workaround (呃，其實就是 Facebook 推薦用 INT UNSIGNED 的方法)，再考慮到有一票現有程式，在上面狂用 side effect 讓執行結果正確，不如就不要修這種吃力不討好的東西了 XDDD

另外一方面 timezone 資訊其實常常變化，常常需要更新 MySQL 的 timezone database (而這對於維運來說不是什麼開心的事情)：

There're few ways around that. One of them is side-load and maintain timezone data inside MySQL itself - it has support for internal timezone database and tracks obscure time shifts like ones for "Pacific War Time" and "Pacific Peace Time". That is operationally feasible (you have to remind yourself to update the database whenever time rules change, and they do change a lot, if you consider every timezone in the world), but has limited value.

這就是為什麼大家遇到 MySQL 時都會推薦用 INT UNSIGNED 了...

另外可以參考三年前的文章「MySQL 裡儲存時間的方式...」，裡面引用了 Baron Schwartz 的說明：

All date and time columns shall be INT UNSIGNED NOT NULL, and shall store a Unix timestamp in UTC.

其實這已經是個 best practice 了...

vm.swappiness 設成 1 或是 0 的差異

在「MongoDB System Tuning Best Practices」這份投影片裡面看到：

To avoid disk-based swap: 1 (not zero!)

以及：

‘0’ can cause unpredicted behaviour

在 kernel 的說明文件是這樣描述，設成 0 時表示只有在避免 oom 時才會 swap：

This control is used to define how aggressive the kernel will swap memory pages. Higher values will increase agressiveness, lower values decrease the amount of swap. A value of 0 instructs the kernel not to initiate swap until the amount of free and file-backed pages is less than the high water mark in a zone.

設成 1 的想法頗有趣的，來看看在 MySQL 上是不是也有同樣的情況要注意...

PHP 康莊大道

前陣子看到的「PHP The Right Way.」網站。網站的開頭就先提到這並不是說明 PHP 怎麼寫才是對的，而是告訴你許多前人經驗所得到的建議：(血淚史 XD)

Disclaimer

There is no canonical way to use PHP. However, this website is a humble display of best practices, available options, and good information. It aims to introduce new PHP developers and to rethink seasoned pros with fresh ideas.

這個網站是導讀性質，告訴你現在 PHP 大約有哪些新東西需要看。

最近比較常提出來的幾個是：

  • PSR-0 規範 (還有 PSR-1 與 PSR-2)。
  • 很多新的 SPL 出現，如果可以用就應該儘量用現成的，不需要自己造輪子。
  • 針對資料庫的操作儘量用 PDO，不要用 mysql_*。