Tag: merge

Automattic 買下 Beeper

沒想到後續消息居然會是這個，在 Hacker News 上看到 Automattic 買下 Beeper 的消息：「Beeper acquired by Automattic (WordPress) (beeper.com)」，原文在「Beeper is joining Automattic」這邊。

先前因為弄出與 iMessage 相通的工具而知名，當時還追過這個新聞：

看起來之前就有投資的關係了：

Matt, Automattic’s CEO, and I have known each other for years. He was an early user, supporter and investor in Beeper.

不確定買下來能做什麼，新聞稿上講得是很冠冕堂皇... 但對 Beeper 的創辦人這邊大概就是順利脫手？當時 Apple 的態度讓 iMessage 相容性這條路走到 dead end；對 Automattic 這邊大概就是希望這群人做 IM project？

不過當時已經買了 Texts.com (參考當時的新聞「WordPress.com owner buys all-in-one messaging app Texts.com for $50M」)，原來這組人是有什麼狀況嗎...？

Adobe 與 Figma 併購破局

剛剛打開 Hacker News 看到這篇掛在 top 1，Figma 官方宣佈終止與 Adobe 合併的計畫：「Figma and Adobe are abandoning our proposed merger (figma.com)」，原文「Figma and Adobe are abandoning our proposed merger」。

翻了一下維基百科，與壟斷相關的報導有兩個，一個是美國在去年十一月報導的：「DOJ takes aim at Adobe’s $20 billion deal」，另外一個是歐盟在今年二月報導的：「EU regulators to assess Adobe’s $20bn acquisition of Figma」，但這些消息在這種併購案還蠻常見的，這個結果頗意外的...

這樣的話 Figma 會打算上市嗎？

原來 Waterfox 早就被廣告公司收購了...

看到「Waterfox G4.1.0 update reduces requirement to SSE 4.1, sets Startpage as the default search engine for Private Tabs」這篇才發現 Waterfox 在 2019 年年底的時候早就被廣告公司 System1 收購：「Waterfox web browser sold to System1」，過了兩個多月被 Ghacks 寫成新聞後才發表對應的公告：「Waterfox has joined System1」。

先前研究 Google Chrome 的替代品時有列到清單裡找機會測，看起來可以跳過了...

而這次的報導則是題到了 Waterfox 將 Private Tabs 的預設搜尋引擎改成 Startpage，關於 Startpage 之前在「Startpage 被廣告公司收購」這邊也提過了...

JavaScript 的 sort 變成 stable

看到「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 外，還可以保證最差的情境下的時間複雜度是 O(n*log(n))：

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.

被動靈氣加成：用 git rerere 解決同樣的 conflict 問題

Git 上一個很好用的設定，不需要改變原來的工作模式，有種「被動靈氣」的感覺 XD

在 Twitter 上看到這則推：

裡面提到了 git rerere 這個指令，投影片裡面雖然有給方法，不過一時間沒看懂... (oops)

找了一下官方文件與其他文件後發現其實意外的簡單，就是在 .gitconfig 設定檔內開啟個 flag 後就沒事了，其他的動作照以前的方式走。Git 的被動技能就是在每次遇到 conflict 以及解決的時候就會記錄下來，當下次遇到同樣的情況就自動幫你解。

先開起來再說，之後來看看有什麼副作用再來抱怨 XDDD

Mark Callaghan 花五分鐘介紹 LSM trees

實做 MyRocks 的 Mark Callaghan 花五分鐘在 CIDR 2019 上介紹 LSM tree：「Geek code for LSM trees」。翻了一下發現 CIDR 是兩年辦一次，跟之前遇過的 conference 不太一樣...

投影片在「Diversity of LSM tree shapes」這邊可以看到，在五分鐘內講完的前提下規劃出的重點...

合併 RRD 資料的工具

昨天把跑在 Raspberry Pi 上的 SmokePing 資料改用統一版本 (我在 GitHub 上公開的 smokeping-config.d 這個)，但有些節點的 naming 改變了，所以會需要將資料整在一起。

在透過 Google 搜尋後，用的工具是「A very simple script to merge multiple RRD files, since none of those available seem to work.」這個，是一隻 Python 的程式。另外可以從程式碼裡面看到他使用了 rrdtool 這個 CLI 工具 (SmokePing 用了 RRD 格式儲存資料)，所以使用這隻程式前需要先安裝 rrdtool 這個套件：

$ sudo apt install rrdtool

接下來就是照說明來轉換。由於 rrdtool 這隻程式沒有對 filename 做特殊處理 (i.e. 把 - 當作 stdin)，所以會使用到 /dev/stdin 這種特殊方式來當作 input：

./simple-rrd-merge.py input-a.rrd input-b.rrd | rrdtool restore /dev/stdin output.rrd

當然，要記得先把 SmokePing 停掉再跑會比較好 XD

生出的 RRD 檔案再覆蓋回去 (我是先備份起來，以免有意外...)，然後再把 SmokePing 跑起來就可以了。

GitHub 引入 Code Owner 的概念

GitHub 推出了 Code Owner 的概念：「Introducing code owners」。也很直接說這個能是向 Chromium「致敬」出來的：

The code owners feature was inspired by Chromium's use of OWNERS files.

檔案名稱是 CODEOWNERS，可以放在根目錄或是 .github/ 下，可以針對不同的目錄設不同的人：

To specify code owners, create a file named CODEOWNERS in the repository's root directory (or in .github/ if you prefer) with the following format[.]

這樣一來，在 pull request 的時候就會跳出來：

另外也可以設定需要 code owner 同意才能 merge：

Percona 宣佈支援 MyRocks (MySQL 上的 RocksDB engine)

RocksDB 是 Facebook 從 Google 放出的 LevelDB 改出來，然後被更多人接受並且投注資源的 library... (看兩邊的 GitHub 應該就會有感覺了)

而 Facebook 的人在改進後又花了不少力氣 porting 到 MySQL 上...

之前 Twitter 上就有看到不少消息，這次算是在 Percona 官方的 blog 上正式公佈要支援 MyRocks 的消息：「Announcing MyRocks in Percona Server for MySQL」。

依照目前的計畫次在明年 2017 的 Q1 放出 experimental build，依照 Percona 的品質慣例，應該是可以拿來在測試環境下跑的順順的 (在還沒有 heavy loading 的前提下)：

We will provide the experimental builds of MyRocks in Percona Server in Q1 2017, and we encourage you to start testing and experimenting so we can quickly release a solid GA version.

文章下面的 comment 剛好有人提到 Percona 另外一個產品線 TokuDB，這兩個產品線重複的問題：

MyRocks seems pretty similar to TokuDB. They are both write-optimized. MyRocks uses LSM tree while TokuDB uses fractal tree.

How do the 2 compare? Which one would you recommend using?

之前被 Percona 買下的 TokuDB 跟 Facebook 所發展出來的 MyRocks 的產品重複性頗高 (都是為了寫入的部分最佳化)。應該還是因為 fractal tree 與 LSM tree 成熟度造成的效能差異還是太明顯吧 (當然另外也跟後面公司投入的資源有關)，讓 Percona 決定還是要支援 MyRocks，而不是全力推動自家買下的 TokuDB... (唔，變成阿斗了？)

不知道成熟後有沒有機會變成 InnoDB replacement...