幹壞事是進步最大的原動力
Percona 老大 Peter Zaitsev 在「MySQL – A Series of Bad Design Decisions」這篇裡提到了他認為 MySQL 設計上的問題，不過裡面也提到了不少有用的指令，平常可以先熟悉一下輸出，等真的有狀況的時候才會想起來可以用這些指令。
首先是最經典的 SHOW ENGINE INNODB STATUS，算是很多文件上面都會提到的指令。可以看 InnoDB 當下的情況，藉以猜測內部現在是怎麼卡住...
另外一個是 SHOW ENGINE INNODB MUTEX，就如同 Peter Zaitsev 所提到的，這個指令想辦法抓出最重要的資訊，但不要像 SHOW ENGINE INNODB STATUS 給了那麼多。
另外當然就是 INFORMATION_SCHEMA，他甚至希望 SHOW ENGINE INNODB 系列的指令應該要被整合進去，這樣才能用 SELECT 相關的指令整理... (因為 ORDER BY 以及蠻多的指令沒辦法在 SHOW ... 上面用)
AWS 推出了具有語意分析的能力，可以直接丟自然語言進去搜尋的 Amazon Kendra：「Announcing Amazon Kendra: Reinventing Enterprise Search with Machine Learning」。
之前 Google 有推出過 Google Search Appliance 也是做企業內資料的整合 (2016 年收掉了)，但應該沒有到可以用自然語言搜尋？
Amazon Kendra 的費用不算便宜，Enterprise Edition 提供 150GB 的容量與 50 萬筆文件，然後提供大約 40k query/day，這樣要 USD$7/hr，一個月大約是 USD$5,040，不過對於企業來說應該是很有用...
另外有提到這邊 query 收費的部份是估算，會依照 query 問題的難易度而不同：
Actual queries per day will vary based on query complexity, which greatly varies from customer to customer. Less complex queries (e.g. “leave policy”) consume less resources to run, and more complex queries (e.g. “What’s the daily parking allowance in Seattle?”) consume more resources to run. The total number of queries you can run with your allocated resources will depend on your mix of queries. The max queries per day provided above is an estimate, assuming 80% less complex queries and 20% more complex queries.
這樣頗有趣的，感覺可以處理簡單的分析了？
Amazon Elasticsearch Service 的新功能，使用 Amazon S3 當作第二級儲存空間 (UltraWarm)：「Announcing UltraWarm (Preview) for Amazon Elasticsearch Service」。
UltraWarm 需要不同的機器 (跑不同版本？)，機器的規格 (vCPU 與記憶體的比率) 接近 Memory Optimized 的版本，但是貴了不少，所以需要夠大的資料量才會打平回來...
拿 us-east-1 來看，SSD EBS 的空間成本就是 USD$0.135/GB，而傳統磁性硬碟是 USD$0.067/GB (不知道收不收 I/O 費用？)，但 storage 的價錢是 USD$0.024/GB。這邊值得一提的是 Amazon S3 是 USD$0.023/GB，看起來是直接包括了 API 的呼叫費用？
從 Hacker News 上看到 Reddit 上的消息 (看起來有陣子了)：「Startpage is now owned by an advertising company」。
Startpage 算是之前有在用的 default search engine，但發現有很多 bug 後就不太用了。目前還是先設 DuckDuckGo，然後在需要的時候用之前寫的 press-g-to-google-duckduckgo 切到 Google 去找...
DuckDuckGo 還是有搜尋品質的問題...
hiQ 之前爬 LinkedIn 的公開資料而被 LinkedIn 告 (可以參考 2017 時的「hiQ prevails / LinkedIn must allow scraping / Of your page info」)，這場官司一路打官司打到第九巡迴庭，最後的判決確認了 LinkedIn 完全敗訴。判決書在「HIQ LABS V. LINKEDIN」這邊可以看到。
這次的判決書有提到當初地方法院有下令 LinkedIn 不得用任何方式設限抓取公開資料：
The district court granted hiQ’s motion. It ordered LinkedIn to withdraw its cease-and-desist letter, to remove any existing technical barriers to hiQ’s access to public profiles, and to refrain from putting in place any legal or technical measures with the effect of blocking hiQ’s access to public profiles. LinkedIn timely appealed.
而在判決書裡其他地方也可以看到巡迴庭不斷確認地方法院當時的判決是合理的，並且否定 LinkedIn 的辯解：(這邊只拉了兩段，裡面還有提到很多次)
In short, the district court did not abuse its discretion in concluding on the preliminary injunction record that hiQ currently has no viable way to remain in business other than using LinkedIn public profile data for its Keeper and Skill Mapper services, and that HiQ therefore has demonstrated a likelihood of irreparable harm absent a preliminary injunction.
We conclude that the district court’s determination that the balance of hardships tips sharply in hiQ’s favor is not “illogical, implausible, or without support in the record.” Kelly, 878 F.3d at 713.
到巡迴庭差不多是確定的判決了，沒有其他特別的流程的話...
剛剛看到 Trac 出了 1.4 的消息，雖然還是在用 Python 2：「Release Notes for Trac 1.4 Jinja Release」。
其中一個比較大的改變是 template engine 換掉了，從 Edgewall 自家的 Genshi 換到 Jinja2 上，目前看起來兩者都可以用，但可以預期現有的 template 要找時間換過去：「5 times speed-up when rendering query results, thanks to the migration from Genshi to Jinja2.」。
其他的改變應該還好，找個週末來把自己的 Trac 備份起來測試好了...
收到信件通知，本來在 GCE 上使用的 Public IP address 是免費的，2020 年開始變成要收 USD$0.004/hr (Standard，約 USD$2.88/month) 或是 USD$0.002/hr (Preemptible，約 USD$1.44/month)：
First, we’re increasing the price for Google Compute Engine (GCE) VMs that use external IP addresses. Beginning January 1, 2020, a standard GCE instance using an external IP address will cost an additional $0.004/hr and a preemptible GCE instance using an external IP address will cost an additional $0.002/hr.
從 2020 年一月開始生效，但是前三個月會用 100% discount 的方式呈現在帳單上 (所以還是免費)，這樣你會知道你的 IP address 費用會吃多少錢：
We will fully discount any external IP usage for the first 3 months to help you quantify the impact of these pricing changes. Please take note of the following dates:
January 1, 2020: Although your invoice will show your calculated external IP-related charges, these will be fully discounted and you will not need to pay these.
April 1, 2020: You will need to pay for any incurred external IP-related charges shown on your invoice.
其實整體成本應該是還好，但看到漲價總是不開心... XD
Facebook 提供了一個對 React Native 最佳化的 JS engine：「Hermes: An open source JavaScript engine optimized for mobile apps, starting with React Native」。
裡面有提到兩個比較重要的的部份是 No JIT 與 Garbage collector strategy，針對行動裝置的特性而設計：避免 JIT 產生的 overhead，以及降低記憶體使用量。
官方給的改善主要也都是偏這兩塊：
不過沒有提到 CPU usage 會上升多少，只是帶過去：
Notably, our primary metrics are relatively insensitive to the engine’s CPU usage when executing JavaScript code.
對於 Facebook 也許是可以接受的數量，但對於其他人就沒概念了... 要入坑的人自己衡量這部份的風險 XD
Fabrice Bellard 跑去寫了一套 JavaScript engine 出來：「QuickJS」。
以 ES2019 當底實做的 JS engine：
Almost complete ES2019 support including modules, asynchronous generators and full Annex B support (legacy web compatibility).
測試的部份也過了：
Passes 100% of the ECMAScript Test Suite.
在大小的部份，比起其他的 engine (與 package) 來說的確是小很多，不過 190KB 這個大小對於 embedded system 來說還是有點微妙 (但對於想要包 JS engine 進去用的人應該是頗開心的)：
Small and easily embeddable: just a few C files, no external dependency, 190 KiB of x86 code for a simple hello world program.
看到「Stable Array.prototype.sort」這篇在講 JavaScript 規格書裡的 sort...
本來 JavaScript 的規格書裡，各種 sort 都沒有保證 stable，而在「[Normative] Make Array.prototype.sort stable #1340」與「[Normative] Make %TypedArray%.prototype.sort stable #1433」這兩個地方則有了變化，提案在規格裡加入 stable 的要求，可以減少開發者因為不知道 unstable 而造成的問題...
Firefox 則是很久前就決定使用 Merge sort 了 (看了一下，當時還在從 Firebird 轉換名稱到 Firefox 的時期)：「Array.sort isn't a stable sort (switch to MergeSort)」。
另外這篇也剛好提到了 V8 使用 Timsort 當作 stable sorting algorithm，之前就有看到但發現沒在 blog 上提過...
Timsort 是 1993 年發明出來的演算法，與 Merge sort 的情況類似，除了 stable 外，還可以保證最差的情境下的時間複雜度是 
Timsort is a hybrid stable sorting algorithm, derived from merge sort and insertion sort, designed to perform well on many kinds of real-world data.
這個演算法的重點是善用已經排好的子序列，藉此降低記憶體操作次數而提昇效能，符合真實環境裡常見到的資料：
The algorithm finds subsequences of the data that are already ordered, and uses that knowledge to sort the remainder more efficiently.
除了 V8 採用這個演算法以外，其他常見的包括了 Python 與 Android 上的 Java SE：
Timsort has been Python's standard sorting algorithm since version 2.3. It is also used to sort arrays of non-primitive type in Java SE 7, on the Android platform, in GNU Octave, and Google Chrome.