Category: CMS

實做 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，雖然也不知道現在有什麼用途了，大概就是這樣所以沒提...

維基基金會 (包括維基百科) 的官方服務狀態頁

看到「Announcing www.wikimediastatus.net」這個，維基基金會相關服務的官方狀態頁：「www.wikimediastatus.net」。

從頁面下面的「Powered by Atlassian Statuspage」這邊可以看出來是使用 Statuspage 這個服務。

看起來當 server error 狂噴的時候這邊應該有機會看到 (剛好前陣子好像有發生)，另外 Total request volume 這個指標也透漏了目前整個維基基金會服務尖峰會有 150Kreqs/sec 的量，可以預期大多數應該都是維基百科相關的服務...

不過大多數的量應該都是從 cache server 吐出去，不知道有沒有後端 PHP loading 的數字...

維基基金會對中國大陸維基人用戶組的行動 (WMCUG)

在『維基媒體基金會出手清除多名「中國大陸維基人用戶組」成員。包括封禁其在全球所有維基媒體基金會項目的帳號，或是拔除在中文維基百科的管理員權限。』這邊看到的消息，看起來目前都還在進行中，所以這幾天還可以繼續等看看消息。

中文版維基百科的管理群裡面被中國政府以及共青團伸手進來的事情是眾所皆知，只是先前維基基金會一直都是抱持沒有確切證據不處理的態度。

這次官方的正式聲明是由 Maggie Dennis 署名 (法務部門 VP)，可以參考「Office actions/September 2021 statement」(英文版) 與「基金會行動/2021年9月聲明」(中文翻譯版本)。

相關的拔權記錄可以在「Special:Log/WMFOffice」這邊看到，這邊的時間應該是 UTC，可以看到還有陸陸續續在拔。另外在「Wikipedia:2021年基金會針對中文維基百科的行動」這邊也有一些記錄。

看到連 Outlookxp 都被拔了，總算是出手了啊...

另外補充一下在 mailing list 上看到的資料，原始的 Twitter 已經刪除，但 Internet Archive 上面還有備份：

https://web.archive.org/web/20210914024812/https://twitter.com/Philip_Tzou/status/1437543054043275265

Wikimedia Commons 發現的印度異常流量

在 Hacker News Daily 上看到「Investigate unusual media traffic pattern for AsterNovi-belgii-flower-1mb.jpg on Commons」這個，維基百科拿來存放各種多媒體檔案的 Wikimedia Commons 發現有大量的印度流量都打進了 https://upload.wikimedia.org/wikipedia/commons/thumb/1/16/AsterNovi-belgii-flower-1mb.jpg/1280px-AsterNovi-belgii-flower-1mb.jpg 這張圖片，而這佔了 EQSIN (新加坡伺服器的代碼) 中 20% 的流量：

由於 User-Agent 與 Referer 都沒有資訊，可以確認這不是瀏覽器造成的流量，但也因為沒有有用的資訊，變得很難查。

接下來有使用者提到時間點可能跟 TikTok 在印度被 ban 有關，因為在被 ban 後有很多使用者會去找替代的服務，而開發者有可能就直接拿這張圖來當啟動畫面或是背景畫面。

所以他們把熱門的替代服務都看了一輪，也都沒看到這張圖。後來他們猜測有可能是抓了但沒顯示在畫面上，所以開始交叉測試：在開 app 後就去 Hive 掃 HTTP log，然後找到一個 app。

後來為了要確認是不是這個 app，他們架了一組 DNS server 記錄查詢的網域名稱，看看 app 會不會觸發查詢 upload.wikimedia.org 這個網域名稱，而不出所料的確認了，而且真的就是在啟動時有抓，但是沒有顯示在畫面上。

接下來就是想辦法聯絡開發團隊，而目前 Wikimedia Commons 這邊先以 User-Agent 擋掉這些需求了。

另外在 Hacker News 上的討論「20% of requests for Wikimedia Commons are for one image of a flower (wikimedia.org)」也很有趣，有其他事件的苦主在當年遇到 MSN 直接用他網站上的圖片導致他的伺服器快掛，而且反應了很多次都沒用，然後他就把圖片換成「Netscape Now」，然後十五分鐘內就被解決了：

At the height of the browser wars I once woke up to Microsoft hotlinking a small button for downloading our software from the MSN homepage. I tried to reach someone there for hours but nobody cared enough to do something about it. The image was small (no more than a few K), but the millions of requests that page got were enough to totally kill our server.

Finally, I replaced the image on there with a 'Netscape Now' button. Within 15 minutes the matter was resolved.

找了一下圖片，看起來應該是類似這種的圖：

要直接反擊讓人會痛... XD

維基基金會的 Git Server 從 Gerrit 換到 GitLab

這兩天受到注意的消息，維基基金會決定把 Git Server 從本來的 Gerrit 轉換到自建的 GitLab 上：「GitLab consultation」，在 Hacker News 上也有不少討論 (i.e. 戰文)：「Wikimedia is moving to Gitlab (mediawiki.org)」。

先從官方的說法開始看，主要是 Gerrit 的運作方式與目前業界與社群的常用方式不同，也導致了 usability 不怎麼好，這使得社群與基金會的員工的學習成本偏高：

While Gerrit’s workflow is in many respects best-in-class, its interface suffers from usability deficits, and its workflow differs from mainstream industry practices. This creates barriers to entry for the community and slows onboarding for WMF technical staff.

另外也發現內部很多人會直接用外部的 Git 服務，了解後主要列出三個原因：

  • lower friction to create new repositories
  • easier setup and self-service of Continuous Integration configuration
  • more familiarity with pull-request style workflows

再來就是尋找與選擇的過程了，但其實市場上也沒什麼可以選的，從說明的 FAQ 部份可以看到 GitHub 與 GitLab，另外因為基金會的特性有強烈偏好 open source self-hosting 方案，基本上就是 GitLab 了...

不過如果是因為 code review 而決定換過去的話，我猜不完全是工具的問題，內部應該有不少政治上的問題，只是外面這次看不出來而已。

在 Hacker News 上的討論還蠻有趣的，有些前員工的發言點出了在 code review 時遇到的問題看起來不是這次換成 GitLab 可以解的。

Atlassian 將消滅 Server 版本

在 Hacker News Daily 上看到 Atlassian 打算消滅 server 版本：「Moving to a cloud future, together」。

話說回來，之前工作時用 Jira 的時候 (雲端版本)，所有人都抱怨 Jira 慢到爆炸的問題不知道解了沒，當時記得每個按鍵都要 10+ 秒才會反應，不管是在台灣還是在香港都很慢，然後在公司反應了十個月也都沒什麼改善 XD

至於官方說要推 cloud 版本的理由聽聽就好，Hacker News 上有些討論反而還蠻有趣的，像是講到裡面同時在維護 Cloud 與 Server 版本時遇到的問題，看起來團隊沒有足夠的能量處理這些東西：「Atlassian moving to cloud-only, will stop selling server licenses (atlassian.com)」。

另外一個是討論裡面提到的替代方案，看起來也不算很好的替代方案啊，出現 MediaWiki 作為 Confluence 的替代品，少了 WYSIWYG 其實門檻高不少耶...

來看看這波反應會有多大 XD

Wikimedia 弄了自己的 Mattermost

Wikimedia (維基百科後面的基金會) 又多了一個溝通工具：「Introducing Wikimedia Chat!」。

最傳統的方式是在 wiki 的 Talk 頁上溝通 (現在看起來還是有些正式的投票討論需要走這個方式)，但那個界面用起來真的頗痛苦... 一般的社群討論還是會在其他工具上進行。

先前有晃進去看過的平台應該是 IRC 與 Telegram 群組，不過後來因為量太大就閃出來了，另外這邊有提到 Slack、Discord 與 Facebook：

You can now see Wikimedia-related discussion groups in Slack, Discord, Telegram, Facebook, and many more.

這些平台都還是放在外部，就會有很多隱私上的考量：

Besides being scattered and inaccessible to people who don’t have accounts in those platforms (for privacy reasons for example), these platforms use proprietary and closed-source software, are outside Wikimedia infrastructure and some harvest our personal data for profit.

freenode 上面的 IRC 算是相對起來比較開放，但還是少了不少功能，所以就自己架了 Mattermost 出來：

IRC on freenode.net is a good alternative but it lacks basic functionalities of a modern chat platform. So we created Wikimedia Chat, a Mattermost instance hosted in Wikimedia Cloud.

比較特別的是超過 90 天的記錄會被砍掉？不太懂這邊的邏輯...

As a Wikimedia Cloud project, all of discussions, private and public are covered by Code of conduct in technical spaces and due to Wikimedia Cloud privacy policy all discussions older than ninety days will be deleted.

用事實查核中心的 RSS feed 加上 IFTTT 自動通知到 Line/Telegram/... 內

事實查核中心的澄清內容其實很有趣，可以看到有哪些假消息在流傳，所以想找找看有沒有比較簡單的方法可以設通知...

事實查核中心的官網用的是 netiCRM 這個平台 (看起來底層是 Drupal)，而在 HTML 頁面的開頭可以看到 RSS 1.0 的 xmlns 宣告：

  xmlns:content="http://purl.org/rss/1.0/modules/content/"

本來想說直接用 feed 接到 IFTTT 就好了，不過 HTML 頁面上沒有放 feed entry 讓閱讀器可以直接找到 feed 本身，也就是像這樣的標籤資訊：

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

找了一下 Drupal 的設定慣例，發現 feed 可能會放在 /rss.xml 這個位置，測了一下發現順利在 https://tfc-taiwan.org.tw/rss.xml 這邊看到 feed，接下來就可以加進 IFTTT 了：

給有興趣想要用 feed 做些事情的人參考看看，像是加到 Line 或是 Telegram 的群組裡面，或是放到 Slack channel 裡面 (Slack 裡應該可以直接在某個 channel 裡用 /feed add https://tfc-taiwan.org.tw/rss.xml 把這個 feed 加進去)。

在 Unix 環境裡各種奇怪名稱的原因說明

在 Hacker News Daily 上看到的，Debian 的 Wiki 上有一頁整理了很多「比較特別的」軟體或是指令的名稱由來：「WhyTheName」。

像是 Git：

git
(distributed VCS) semi-arbitrary short word

不過這邊不像維基百科會要求「可供查證」，裡面大多都沒有引用來源，真的要引用前最好還是去其他地方確認過...