Google Docs 裡 Grammar Correction 的 bug

剛剛在 Hacker News 上看到有趣的 bug,在 Google Docs 上輸入 And. And. And. And. And. 會觸發 error:「Including “And. And. And. And. And.” in a Google doc causes it to crash (」,原始的 bug report 在「Including "And. And. And. And. And." in a Google doc causes it to crash.」這邊,錯誤訊息像是這樣:

Hacker News 上的討論有提到這需要開 grammar check 的功能,然後看起來只要有相同的五個字開頭都大寫就會發生,像是 Also, Therefore, And, Anyway, But, Who, Why. 這些:

Also, Therefore, And, Anyway, But, Who, Why.

Each in caps 5 times with the same word with a period and space after each word and newline at the end is what I have found so far.

Can anyone find others?

Edit: added words that work found in other comments

很有趣的 bug XDDD 然後目前在 Hacker News 首頁的第一名...

Cloudflare 推出 Workers Durable Objects

這幾天 Cloudflare 丟出蠻多東西的,挑一些比較想寫下來的來寫,其中一個是他們的 serverless platform 又提供另外一種 database 了:「Workers Durable Objects Beta: A New Approach to Stateful Serverless」。

先前的產品是 eventually-consistent database (放掉 CAP theorem 裡面的 C),也就是 Workers KV,這次提供的是 strong consisteny 版本的 database,叫做 Workers Durable Objects。

目前還沒看到文件,網站上的 Products 裡只放了 Workers KV 的,目前只能就敘述上猜。

以 blog 文章的敘述看起來是保護了 C 的部份,但不知道是放掉 AP 裡面哪個,也許是 A 的部份,因為文章裡一直都沒提到 high availability。


Google 的 Cloud Spanner

GoogleCloud Spanner 這個服務拿出來賣了:「Introducing Cloud Spanner: a global database service for mission-critical applications」,以及說明的「Inside Cloud Spanner and the CAP Theorem」。

Cloud Spanner 的規劃上是希望有 RDBMS 的能力 (像是 ACID 特性),又有強大的擴充能力 (scalability) 與可用性 (availability):

Today, we’re excited to announce the public beta for Cloud Spanner, a globally distributed relational database service that lets customers have their cake and eat it too: ACID transactions and SQL semantics, without giving up horizontal scaling and high availability.

在說明裡有提到 Cloud Spanner 是做到 CAP theorem 裡面的 CP:

The purist answer is “no” because partitions can happen and in fact have happened at Google, and during some partitions, Spanner chooses C and forfeits A. It is technically a CP system.

然後把 A 拉高到使用者不會在意 downtime 的程度:

However, no system provides 100% availability, so the pragmatic question is whether or not Spanner delivers availability that is so high that most users don't worry about its outages.

當然,比較讓人爭議的是 Twitter 上 Google Cloud 官方帳號的 tweet,直接講同時解決了 CAP 三個條件:


Comcast 的 300GB/month 限制

Comcast 的 300GB/month 限制在 Comcast 的內部文件表示對於解決網路壅塞問題無關,只是商業考量 (或者說「找個理由想收更多的錢」):「Leaked Comcast docs prove 300GB data cap has nothing to do with network congestion」。


Don’t Say: “The program is about congestion management.” (It is not.)

這讓我想到 2000 年的時候,計中對交大宿舍網路做的每日流量限制,反而造成整體流量不斷上升,因為大家都覺得沒用完浪費掉了,雖然把本來 bandwidth distribution 的右半段砍掉,但左半段全部爬上來,結果積分起來整體流量增加超多 XDDD

從那時候第一次在實戰驗證,在某些情境下,假性的公平上反而會造成整體成本的提昇... 相關的討論還是可以用 Google Groups 在 或是 tw.bbs.campus.nctu 上找到。



「分散式系統」(Distributed System) 是個老詞彙,但跟最近當紅詞彙「雲」、「NoSQL」常常相關。也因此「雲」與「NoSQL」常常遇到的都是分散式系統遇到 (並且討論過) 的問題...

而「Notes on Distributed Systems for Young Bloods」這篇寫的好血淚 XDDD 除了講理論面的東西以外,也把實務面會遇到的問題拿出來講...

首先要先知道「Fallacies of Distributed Computing」,在分散式系統裡,能假設的事情實在太少,要處理的事情太多。而「CAP theorem」也是個必讀的主題,從 Amazon 丟出「Dynamo: Amazon's Highly Available Key-value Store」這篇經典的 paper 後讓更多人知道這個理論。

熟悉上面兩個主題後,接下來就是血淚史... XD

garbage collection pauses make masters “disappear”

啊,GC 讓 master 不見... (NameNode... XDDD)

Writing robust distributed systems costs more than writing robust single-machine systems.

Robust, open source distributed systems are much less common than robust, single-machine systems.

這兩條... XD

Oh, and Paxos really is very hard to implement

Paxos... XD

If you can fit your problem in memory, it’s probably trivial.


“It’s slow” is the hardest problem you’ll ever debug.

連問題都找不到嗎... XD

撇開這些碎碎念的部份,就算對 distributed system 沒那麼熟,這篇文章也提到了很多「解決的方向」以及「關鍵字」讓你找資料,對於實際操作時會有很大的幫助。