幹壞事是進步最大的原動力
先前提到 JavaScript Errors Notifier 裡有 FairShare 的問題：「改用沒有 FairShare 版本的 JavaScript Errors Notifier」。
剛剛在 Urgent: Make javascript-errors-notifiers less invasive 這邊看到作者已經從 Google Web Store 上面的版本拿掉 FairShare 了：
And yes, it was completely removed.
另外也得到一些數字：
This decision is about -$5000 of my yearly income, but, anyway, it makes me feel better :)
在「Chrome Extensions – AKA Total Absence of Privacy」這邊討論了 Google Chrome 官方的 Web Store 上有很多應用程式為了賺錢在追蹤個人行為：
We’ve seen some indications on Chrome Extension-forums that it’s around $0.04 per user/month.
而且因為是 extension，可以直接穿越 Ghostery 之類的防護網，於是就變得無法 opt-out。你可以利用「In order to continuously improve and maintain this software we work with」這樣的字串去找，會以發現有不少 extension 用了 Fairshare 的方案來賺錢。
文章作者呼籲 Google 要提出方案來制止這類行為，不過我覺得 Google 應該是不會做...
看到微軟推出的 CodePush，針對 Cordova 或 React Native 類透過 WebView 跑的程式提出的方案。原因是 Apple 的 App Store 審核都要很久，透過 CodePush 可以直接更新程式：
CodePush is a cloud service that enables Cordova and React Native developers to deploy mobile app updates directly to their users’ devices. It works by acting as a central repository that developers can publish certain updates to (e.g. JS, HTML, CSS and image changes), and that apps can query for updates from (using our provided client SDKs). This allows you to have a more deterministic and direct engagement model with your end-users, while addressing bugs and/or adding small features that don’t require you to re-build a binary and/or re-distribute it through any public app stores.
FAQ 文件裡提到了這點：(Frequently Asked Questions · CodePush)
Does the Apple App Store allow developers to perform these types of updates?
According to section 3.3.2 of Apple’s developer agreement, as long as you are using the CodePush service to release bug fixes and improvements/features that maintain the app’s original/presented purpose (i.e. don’t CodePush a calculator into a first-person shooter), then you will be fine, and your users will be happy. In order to provide a tangible example, our team published a (pretty cheesy!) CodePush-ified game to the Google Play Store and Apple App Store, and had no problems getting it through the review process.
Because Cordova apps are executed within a WebView, and React Native apps are executed within JavaScriptCore, from a technology perspective, these runtimes are unique in their ability to leverage dynamic code downloads according to the aforementioned Apple developer agreement.
同樣的想法如果真的可行，應該會有其他更開放的 open source 方案可以用 (而非綁定性的服務，而是可以掛到自己的 CDN 上下載更新)，先觀察一陣子...
在滿滿都是 NoSQL 的世代中，意外在「Berkeley DB: Architecture」這邊看到 Berkeley DB 的介紹...
2006 年 Berkeley DB 的公司 Sleepycat 被 Oracle 收購。在收購後 Oracle 改變了 open source 授權部份，從之前的 Sleepycat License 改成了 AGPLv3。
Berkeley DB 算是早期功能很完整的 database library，由於 page level locking、crash-safe 加上有 transaction，也曾經被 MySQL 拿去當作 engine，不過在 MySQL 5.1 被拔掉：「14.5 The BDB (BerkeleyDB) Storage Engine」。
文章裡講了很多底層設計上的想法 (而非單純只說明「做了什麼」)，以四個面向來討論。Buffer、Lock、Log 以及 Transaction，並且圍繞著 ACID 需求討論。
算是懷念的考古文？Google 弄出來的 LevelDB 與 Facebook 接著改善的 RocksDB 的走向也不太一樣了，現在大家對 ACID 需求因為 NoSQL 盛行的關係又重新在檢視...
翻文章時翻到的：「Dashboards」。
在 Dashboards 裡的數據是出自 14 天內有連到 Google Play Store 上面的數據：
Beginning in April, 2013, these charts are now built using data collected from each device when the user visits the Google Play Store.
這個數據比實際出貨的版本有意義，因為這代表了會用 Store 的人的比率。而使用者不會連到 Store 的話，開發者也比較不用管支援度的問題...
2.3.3 (API 10) 之後累積起來是 95.1%，然後幾乎所有機器都支援 OpenGL ES 2...