Elasticsearch 的 CJK Bigram 設定

Elasticsearch 應該是目前大家搜尋引擎的首選了。而且預設的搜尋法不像以前的搜尋引擎,以前的搜尋引擎會把所有的中文字串當作一個 term,基本上是搜不到東西的。

不過偶而還是會出現一些問題,像是這樣:(這是在求職天眼通搜尋「訊力科技股份有限公司」的結果)

會發現出現了「104人力銀行_一零四資訊科技股份有限公司」,這是因為預設的搜尋演算法把中文字一個一個拆開,後面的「科技股份有限公司」八個字也都有出現,前面的「訊」與「力」也都有出現,於是就被拉出來了...

這種方式被歸類為 unigram 類的方式,像是「波音737 MAX」這一段就會被切成「波」、「音」、「737」與「MAX」。這個切法還算不錯,但有不少機會會遇到問題。

如果限制在 Elasticsearch 內建的功能,其實有更好的設定可以用,也就是對 CJK 文字改用 bigram 方式切:「CJK Bigram Token Filter」。

遇到英文數字還是照原來的切法,但遇到中文字 (更正確的說應該是 CJK) 會用 bigram 的方式切,像是搜尋詞「訊力科技股份有限公司」就會被切成「訊力」、「力科」、「科技」、「技股」、「股份」、「份有」、「有限」、「限公」與「公司」,而本來的「104人力銀行_一零四資訊科技股份有限公司」裡面就不會出現「訊力」、「力科」,於是就不會抓錯...

當然還是有更好的演算法,不過大多就需要另外安裝了,而 Elasticsearch 的升級又很容易跟這些另外裝的套件卡住,所以在考慮維護成本下,CJK Bigram Token Filter 應該是首選...

用 jiracli 做一些基本常見的操作

公司用 Jira 在管理事情,但眾所皆知的是 Jira 的速度實在太慢 (而且沒改善過),只好找些工具來避免使用 web interface...

翻了 GitHub 後看到 toabctl/jiracli 這個用 Python 開發的軟體,可以在 command line 上對 Jira 做些簡單常見的操作 (對我最主要是 issue 與 comment 的操作),另外工具也支援使用 JQL 搜尋,所以可以透過工具拉下來後再用 grep 或是 awk 過濾...

比較需要注意的是,在第一次執行需要設定的三個參數中,password 的部分其實應該使用 API token (我這邊是 Google SSO,所以不確定一般帳號能不能用自己的密碼登入),這個部分可以在個人設定頁面裡面產生 API token。

設定檔會在 ~/.jiracli.ini 裡面,程式應該會設為 0600,不過可以檢查一下就是了...

Tails 3.13 把注音輸入法的 bugfix 放進去了

在「Tails 裡的注音輸入法終於修好了...」這邊有提到 Tails 的注音輸入法爛掉很久的問題,以及對應的 bugfix 測的差不多了,不過當時一直還沒確定會不會在這個版本修正。

剛剛在「Tails 3.13 is out」這邊的公告裡看到把這個 bugfix 納入 Tails 3.13 了:

Add support for the Bopomofo input method for Chinese using the Chewing library and improve support for the Pinyin input method. (#11292)

後續要再來測操作順暢性的問題了...

Cloudflare 試著分析哪些 HTTPS 連線被攔胡過濾

這邊講的應該是在 client 端裝了 root certificate 後,網路上的 middle box 就有能力解開 HTTPS 連線看內容,再 proxy 連出去的方式:「Monsters in the Middleboxes: Introducing Two New Tools for Detecting HTTPS Interception」,對於有設定 Pinning 的 HTTPS 應該會因為偵測到 certificate 被換掉而不會被監聽,但大多數的應用程式應該沒做這個保護。

對應的公開網站是 MALCOLM,為「Measuring Active Listeners, Connection Observers, and Legitimate Monitors」的縮寫。

Cloudflare 用了幾個方法去分析,像是 User-agent 與 OS 跟支援的 cipher 對不起來的情況就可以猜測是 middle box 的監聽。另外也可以看到 Cloudflare 分析了 middle box 的廠牌,可以看到 Blue Coat 應該是目前的大品牌 (但這邊有統計偏差,限制在可以被偵測出來的品牌)。

其實整體看起來不算低耶... 光是可以確認的部分,整個 Cloudflare 網路上有 10%~20% 的流量其實是有被過濾的?

在 Terminal 看資料的 VisiData

在「VisiData」這篇看到的專案,專案的頁面在「A Swiss Army Chainsaw for Data」這邊,從 screenshot 可以看出來是 terminal 的檢視工具:

會注意到是因為支援 .xls

explore new datasets effortlessly, no matter the format: vd foo.json bar.csv baz.xls

SUPPORTED SOURCES 這邊可以看到完整的支援清單,居然連 pcap 也支援,不知道看起來如何 :o

Tails 裡的注音輸入法終於修好了...

Tails 是一個獨立的 Debian 作業系統,強調匿名性,裡面有很多環境的預設值是為了避免 IP 位置以及其他資訊洩漏而設計。另外因為是獨立完整的作業系統,可以找台電腦用 USB 開機直接跑起來,避免 OS 被埋木馬的問題 (當然如果硬體有問題的話還是沒辦法)。

大多數人用 Tails 的人應該還是拿來跑 Tor Browser,不過我在用的時候發現注音輸入法有問題 (大約三年前?),就跑去開了一張 bug ticket 回報:「Bopomofo input for Chinese is not working」,從裡面的討論可以看到中間有 ping 我,但是我忘記回應了... 直到最近動了起來剛好有看到,就抓了 snapshot ISO 幫忙測了一下,畢竟沒幾個用注音的人在上面可以確認 :o

目前看起來輸入法本身的問題修差不多了,而且有機會在下個版本看到 (或是下下個版本,要看會不會進這次的 merge window)。

想要測試的人,除了要抓這個版本的 snapshot ISO 外 (在 bug ticket 裡有連結),在 Tails 開機時,要記得要在 Language 的地方選擇台灣:

開進去後就可以看到注音輸入法了,用 Super + Space 可以切換輸入法:(Super 通常指的是微軟鍵,或是 Mac 右邊的 Command 鍵,因為左邊的 Command 可能被當 Host key 了)

還有一些小 bug 要另外再處理 (像是切換輸入法的 input focus 會跑掉),不過比以前完全不能用好多了...

PagerDuty 向 SEC 遞出 S-1 了 (IPO)

在「pagerdutys-1.htm」這邊可以看到 PagerDuty 遞出 Form S-1 了,翻了一下 TechCrunch 也有報導:「PagerDuty just filed its S-1」。

PagerDuty 主要的服務是監控服務回報狀況後的後續流程,在組織大一點的公司會拿來用,不過不怎麼便宜... 印象中服務品質沒有拉開差距,而同質性的服務低他不少價錢。

有幾個數字可以看,先是估值:

PagerDuty was valued at $1.3 billion last fall when it closed on $90 million in Series D funding led by T. Rowe Price Associates and Wellington Management. Earlier backers Accel, Andreessen Horowitz and Bessemer Venture Partners also joined the round, which brought the company’s total funding to $173 million.

然後 VC 持股 55%:

According to the S-1, venture investors currently own about 55 percent of the company. Andreessen Horowitz owns the biggest stake, with 18.4 percent of its shares sailing into the IPO. Accel meanwhile owns 12.3 recent, Bessemer owns 12.2 percent, Baseline Ventures owns 6.7 percent, and Harrison Metal owns 5.3 percent.

以及獲利問題:

PagerDuty, which employed 500 employees as of last fall, has never been profitable according to its filing, which says it generated a net loss of $38.1 million for the fiscal year ended January 31, 2018. (It saw revenue of $79.6 million during the same period.)

S-1 文件裡有張圖裡也有相關的營運數字:

AWS 的 OpenJDK 11 (Amazon Corretto 11) 推出 General Availability 版

先前在「AWS 決定花力氣支援 OpenJDK (Corretto 計畫)」與「Amazon 版的 OpenJDK 8 進入 GA」後的下一步,就是對 OpenJDK 11 也推出對應的 Amazon Corretto 11:「Amazon Corretto 11 is Now Generally Available」。

這個版本將至少支援到 2024 年 8 月,也就是五年的支援期:

Long-term support (LTS) for Corretto includes performance enhancements and security updates for Corretto 8 until at least June 2023 at no cost. Updates are planned to be released quarterly. Amazon will provide LTS for Corretto 11 with quarterly updates until at least August 2024.

不過先前有些軟體測試時發現 OpenJDK 11 上不能跑,這些軟體還是得暫時用 OpenJDK 8 的版本來養...

RFC8482 廢掉 DNS 查詢的 ANY query 了...

看到 Cloudflare 的「RFC8482 - Saying goodbye to ANY」這篇,裡面提到 RFC8482 廢掉了 ANY 查詢:「Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY」。

The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". The operator of an authoritative DNS server might choose not to respond to such queries for reasons of local policy, motivated by security, performance, or other reasons.

對 Cloudflare 的痛點主要在於營運上的困難,因為 ANY 回應的 UDP packet size 很大,很容易造成放大攻擊:

把拒絕 ANY 查詢變成標準後,讓 DNS provider 手上多了一把武器可以用。

把 MySQL 的 binlog 功能再拆出來的 mysql-ripple

看到 Percona 的「MySQL Ripple: The First Impression of a MySQL Binlog Server」這篇提到了 Google 放出來的專案 mysql-ripple

這個軟體的情境是針對有很多 replica (slave) 時的情境,要解決每一個 replica 都會對 master server 產生壓力,算是 binlog 的 cache layer。

MySQL Ripple 抓了 binlog 下來後就可以模擬成 mysql server (但是只能提供 binlog 服務) 讓 replica 接,在 replica 很多的情境下就可以橫向擴充,而且因為軟體只支援 GTID 模式,所以比較好做 HA 架構 (相對於 filename + position 模式)。

大概可以歸納出是 write 很多 (所以 binlog 量很大),但又有大量 replica 需求的情境... 目前好像想不出來有什麼情境可以拿出來用 :o