Google 在南韓開放 app 裡面使用其他付款機制了

先前在「南韓對 Apple 與 Google 的 In-App 付款機制的提案」這邊提到南韓的法案將會強迫 AppleGoogle 開放 IAP 的通路,前幾天 Google 正式發出公告會支援其他通路了:「Enabling alternative billing systems for users in South Korea」。

不免俗的,還是會放話說一些 FUD

Alternative billing systems may not offer the same protections or payment options and features of Google Play's billing system—such as parental controls, family payment methods, subscription management, Google Play gift cards, and Play Points.

然後拖一下時間,說正在開發這些功能中:

In the coming weeks and months, we will share implementation details for developers, including instructions for submitting security and customer service verifications and a set of user experience guidelines so users can make an informed choice.

但這應該是第一個強制開放的市場?來等後續 payment gateway 給的數字...

繞過 Web 上「防機器人」機制的資料

這兩天的 Hacker News 冒出一些討論在講 Web 上「防機器人」機制要怎麼繞過:

第一篇主要是從各種面向都一起討論,從大方向的分類討論 (「Where to begin building undetectable bot?」),另外介紹目前有哪些產品 (在「List of anti-bot software providers」這邊)。

在文章裡有提到一個有意思的工具「puppeteer-extra-plugin-stealth」,主要是在 Node.js 類的環境,查了一下在 Python 上也有 pyppeteer-stealth,不過 Python 版本直接講了不完美 XDDD

Transplanted from puppeteer-extra-plugin-stealth, Not perfect.

第二篇文章在開頭就提到他不是很愛 Proxy,因為 Proxy 很容易偵測。在文章最後面則是提到了兩個方案,第一個是用大量便宜的 Android 手機加上 Data SIM 來跑,另外一個是直接用 Android 模擬器加上 4G 網卡跑。

依照這些想法,好像可以來改善一下手上的 RSS 工具...

開 S3 bucket 與 IAM 帳號的工具

看到 Simon Willison 的「s3-credentials: a tool for creating credentials for S3 buckets」這篇,裡面講到了幾件事情。

AWS 上比較好的安全設計是,不同專案之間都有自己的 S3 bucket,然後建立對應的 IAM user,每個 IAM user 只能存取自己的 S3 bucket。

但這個建立過程很煩:

Creating those credentials is surprisingly difficult!

整個建立的過程包括了四個步驟:

  1. 建立 S3 bucket。
  2. 建立 IAM user。
  3. 將 IAM user 掛上對應的 S3 權限。
  4. 建立 IAM user 的 access key。

讓人煩的主要是第三個,那個 JSON format 每次都要翻資料 XD

所以他寫了 s3-credentials 這個套件讓大家用,可以透過 pip 直接安裝起來用。

不過我是偏好用 awscli 的,直接把指令放在 wiki page 上面:「awscli」,需要的時候就 copy & paste 過來執行就可以了。在公司的 wiki 上還有直接把 EC2 instance 生到對應的 subnet 指令可以用...

這東西大概不會簡化,只能大家自己找出路 XD

MangoDB:拿 PostgreSQL 當作後端的 MongoDB 相容層

Hacker News Daily 上看到「A truly Open Source MongoDB alternative」這個東西,在「MangoDB: An open-source MongoDB alternative (mangodb.io)」的討論也可以翻一翻。

MongoDB 最主要的問題就是 4.0 以及以後的版本變成 SSPL 後就不是 open source license 了。

而 MangoDB 是個 Proxy service,前端提供 MongoDB 的協定,後端則是 PostgreSQL

GitHub 上的「MangoDB-io/MangoDB」這邊可以看到 MangoDB 主要是用 Golang 寫的,軟體授權則是 Apache License 2.0

The core of our solution is a stateless proxy, which converts MongoDB protocol queries to SQL, and uses PostgreSQL as a database engine. This will be compatible with MongoDB drivers, and should work as a drop-in replacement to MongoDB in many cases.

這對於只有提供 MongoDB 當儲存層的軟體來說會是個替代方案。不過如果是自己開發的話,這其實也證明了可以直接用 PostgreSQL,基本上 MongoDB 的功能都可以在 PostgreSQL 上找到方案。

話說這個讓我想到 2019 年 AWS 推出 Amazon DocumentDB 的時候,大家都一直在猜 Amazon DocumentDB 是不是拿 PostgreSQL 前面加上一些東西 (參考「大家在猜 Amazon DocumentDB 的底層是不是 PostgreSQL...」),後來也有人發現再更早之前就有人 PoC 過了:「A proof of concept MongoDB clone built on Postgres (github.com/jerrysievert)」,現在一般的公認應該就是,只是 AWS 沒有 open source 出來。

目前 MangoDB 還在早期的階段,但看起來這波應該會有一些能量進去幫忙...

看起來這個月 HiNet 連外大概會不怎麼順...

Twitter 上看到這則障礙資料:

APG (Asia Pacific Gateway) 在 2016 年啟用,還算是新的海纜,看起來會有不少頻寬受到影響... 這點在 HiNet 上用 SmokePing 監控對 dynamodb.ap-southeast-1.amazonaws.com 的 packet loss 就很明顯的可以看出來了:

連過去封包掉的亂七八糟的,然後公司做東南亞生意,操作起來苦哈哈... 不過其他 ISP 看起來還行,應該有機會先繞過去。

Babelfish:讓 PostgreSQL 可以吃 Microsoft SQL Server 的協定

看到「Goodbye Microsoft SQL Server, Hello Babelfish」這篇,AWSAurora (PostgreSQL) 推出了可以吃 Microsoft SQL Server 協定的 Babelfish

Today, we are making Babelfish for Aurora PostgreSQL available. Babelfish allows Amazon Aurora PostgreSQL-Compatible Edition to understand the SQL Server wire protocol.

查了一下資料發現是去年年底的時候發表的:「Want more PostgreSQL? You just might like Babelfish」,不過當時沒注意到這東西,大概是因為是 preview 的關係:

We are open sourcing Babelfish in 2021. Until then, you can use Babelfish on Amazon Aurora in a preview to see how it works and to get a sense for whether this is the right approach for you.

用起來不知道怎樣,但感覺很值得注意,目前雖然沒用到 Microsoft SQL Server 的東西,但以後遇到可以考慮看看...

除了在 AWS 上用以外,也可以自己到 GitHub 上拉 patch 回來上:「babelfish-for-postgresql」。

話說回來,PostgreSQL 被 AWS 拿來用在好多地方啊,先前大家也猜是 DocumentDB 後面是 PostgreSQL (參考「大家在猜 Amazon DocumentDB 的底層是不是 PostgreSQL...」這篇),不知道之後會不會想要跟 Oracle 的律師打架...