Kayako Language Engine and Caching System

先前處理 Kayako email 發送的多國語系問題時，採用新建 LanguageEngine instance，透過 LanguageEngine instance 抓取所需詞彙的方式完成。後來發現，這樣的解法會影響其他信件的發送，例如：ticket auto-close 時的通知信件，會因無法抓到所需詞彙而失敗，追根究柢後發現：無論產生多少新的 LanguageEngine instances，底層實際載入與儲存詞彙都使用相同一塊空間，無法避免動態切換語系時交互影響。

上圖是 LanguageEngine 與 SWIFT caching system 之間的關係。

1. 首先 LanguageEngine 在載入詞彙時會提供 Laod() 或 LoadQueue() 供外部呼叫，最終都落到 SWIFT 的 caching system，使用 SWIFT_CacheStore->LoadQueue()。
2. SWIFT_CacheStore 裡頭涉及 2 內部變數：CacheMemory (SWIFT_CacheMemcache) 與 Registry (SWIFT_Registry)；因為目前系統並未設定 MEMCACHE_HOST，因此這邊只會使用 Registry 作為實際儲存位置。
3. SWIFT_Registry 內部的 storage 分為兩層，level 1 的是 in-memory 的 _registryCache，level 2 是 database 的 swregistry table。

這邊要注意：SWIFT_Registry instance 是在 SWIFT 中生成，因此無論每次執行無論處理過多少張 tickets 都會使用相同的 SWIFT_Registry instance，且單一 SWIFT_Registry instance 中，每一個 key 值只會對應到一個 value。

為了避免語系切換時，汙染 SWIFT_Registry instance 中的語言詞彙，因此決定改採直接 SQL query 的方式載入所需語言。

ps. 這邊的 caching system 指的是 data cache，Kayako 在 4.0 剛推出時並沒有針對 Memcached 整合的功能；倒是官方推薦使用針對 code cache 的 XCache [1]。相較於新版 PHP (>5.5) 更被推崇的 code caching system 是 opCache [2]。

see also:
[1] Kayako Forum: V4 Very Slow!
[2] StackExchange: PHP 7 opCache v PHP 5.6 XCache

.NET Standard 2.0

先前 [1] 分別從 framework 與 virtual machine 兩個面向聊過 .NET framework 的角色，其中提及 Common Language Infrastructure (CLI) 的三大組成：Common Intermediate Language (CIL), standard libraries (BCL and FCL), 與 Common Language Runtime (CLR)。

最近因為 .NET Core 2.0 的正式發佈，越來越多人開始回頭看原本 .NET framework 的組成，以及各種實作與標準之間的關係；這兩天剛好看了 InfoQ 上的一篇文章 [2]；再繼續之前，首先要抓準一個概念：現行的 .NET 平台實作不只 .NET framework 一家，還有 .NET Core, Mono, Xamarin 等等，而各家實作在跨平台的特性與實現方法上也不盡相同，根本原因在於一開始的 CLI standard library 以大鍋菜的方式設計，雖然有 BCL 與 FCL 之分，但 BCL 並未很好地把 Windows dependent 的功能剝離出去，導致後續跨平台 runtime 實作困難。

以下是順手整理的心得：

• .NET Standard 重新定義了 BCL 的標準，讓各家 (.NET Framework, Xamarin, and .NET Core) 實作的 BCL 趨於一致。

• 針對 BCL 之上的 application models，.NET Core 捨棄 Windows Forms 與 Windows Presentation Foundation (WPF)，僅保留 Console，並實作 APS.NET Core [3]。

簡單來說，.NET Standard 是未來跨平台元件或應用程式開發時的必要 (但非充要) 條件，畢竟一個可以正常運作於 .NET Standard 實作上的元件，仍可能依賴該實作的特定函式庫。

至於 Portable Class Libraries (PCL) 則是針對既有 .NET 平台實作所提的暫時方案；透過 Visual Studio 與 PCL 的幫助，Visual Studio 可自動將程式中 dependency 對應到各家實作的函式，免去開發人員額外偵測與判斷的痛苦。有關 PCL，個人認為 InfoQ 文章中參照的 [4] 寫得比較完整。

附帶一提：當微軟在 2017/8/13 發佈 .NET Standard 文件 [5] 時，裡頭的對應表可能讓人誤以為 .NET framework 4.6.1 就已經實作 .NET Standard 2.0；實際上，在 .NET framework 4.6.1 尚須加裝 .NET Core 2.0 SDK 才能支援，否則會缺少 200 多個 API 實作。因此真正的完整支援要到 .NET framework 4.7.1 才算完成 [7]。

see also:
[1] .NET: Framework or Virtual Machine
[2] InfoQ: .NET Core and .NET Standard: What Is the Difference?
[3] .NET Standard - Demystifying .NET Core and .NET Standard
[4] Understanding .NET Core, .NET Standard, .NET Core applications and ASP.NET Core
[5] Microsoft Docs: .NET Standard
[6] Microsoft .NET Blog: Announcing the .NET Framework 4.7.1

Salesforce SOSL, SOQL, and Tokenization

Salesforce 在登入後的畫面頂端提供了一個搜尋框，提供使用者搜尋各式資訊，例如：Account, Contact, Opportunity, Contract 等。

但由於預設的搜尋行為使用其內部的斷詞系統，因此針對一些專有名詞搜尋時，可能就不那麼盡如人意；例如：當資料為東京都時，可以用東京或完整的東京都搜尋到，但是無法用京都搜尋到該筆資料，或許這在很多時候是好用的，尤其當大家公認東京都跟京都是完全不同的 entity，但有時候當使用者只知道公司部分名稱時，就容易造成困擾。以下是 Salesforce 搜尋框的兩個主要限制：

• 預設行為為 start with：一如前例，系統搜尋行為會找出以京都為起始字串的資料，如果想找到東京都，搜尋時必須輸入「*京都」。

• 底層以 morphological tokenization 為基礎的索引：換言之，當專有名詞不常見時，可能因斷詞系統無法正確辨識而找不到。

上述兩個問題在斷詞系統剛從 bigram 轉換為 morphological [1] 時備受批評，但在 2017 年 4 月 [2] 跟 6 月 [3] 有修正得更精細些，例如：「横浜市中区」已經可以使用「中区」找到，關鍵不只是 start-with 的問題，更在於斷詞系統能識別「中区」一詞；然而對於廣大可能的中文專由名詞來說，這樣的解法仍然不夠。

其實英文也不見得就完全沒事，因為有時候在專有名詞欄位，使用者可能只輸入縮寫，甚至是自創的縮寫，這時候 morphological 一樣無法正確辨識並提供搜尋時所需的索引。

想要徹底解決，自己動手寫點程式可能免不了，就 Salesforce 提供的 SOSL 與 SOQL 而言，前者仍然以斷詞系統為基礎 [4]，因此只能選用 SOQL 的 like-anywhere 完成，但相對效能上難免吃重些。

see also:
[1] Salesforce Release Notes (Winter'15): Users Searching in Chinese, Japanese, Korean, and Thai Find Optimized Results
[2] Salesforce Community Known Issues: New morphology tokenization for Japanese characters after new search framework can cause unexpected morphological tokenization result
[3] Salesforce Community Known Issues: Chinese - Morphology tokenization improvement for mainly proper name noun
[4] Force.com SOQL and SOSL Reference: Introduction to SOQL and SOSL
[5] Salesforce Community Known Issue: Wrong results for Japanese OR search for file content
[6] ROSETTE.com: Why Tokenization Matters

Unit Test for Kayako

接手 Kayako Fusion 這套系統超過一年了，一直沒有作單元測試，主要原因有以下兩個：

1. License 驗證：幾乎所有測試需求都跟底層的 SWIFT framework 有關，而要載入這個 framework instance 的前提是 license 被驗證為有效。
2. 缺乏文件：雖然它們家的 SWIFT_TestCase 也是繼承自 PHPUnit_Framework_TestCase，但不知如何執行。

然而直接在 UI 端作 acceptance testing 就不用煩惱這個問題，只要修改 client 端的 host 設定，將 license 中的 domain name 綁定測試機 IP。這時候即使測試機上設定其它 hostname，只要 client 端瀏覽器使用 license 的 domain name 連道測試機，就可以正常執行。

最近因為修改的東西愈趨複雜，很多問題無法單純在測試機上透過 acceptance testing 讓問題浮現，往往都是 patch 上正式機才爆出，因此需要回頭徹底解決，步驟上大致如下：

1. 安裝 PHPUnit；因為 PHP 版本還在 5.4 系列；只能安裝 PHPUnit 4.8.36 [1] [2] [3]。
2. 修改 $KAYAKO_HOME/tests/index.php；因為 license 檢驗，會比對 license 中的 domains 與 $_SERVER['HTTP_HOST']，而在 UI 端作 acceptance testing 時，$_SERVER['HTTP_HOST'] 來自 HTTP request header 中的設定 [4] [5]，改執行 unit testing 時缺少真正的 request header，因此要在 index.php 中自行設定，並作為執行時的 bootstrap script。
3. 執行範例如下：/usr/local/bin/phpunit.phar --bootstrap ./index.php ./__swift/library/Date/class.SWIFT_DateTest.php

官方預帶了一些 test cases，分別針對 KQL, KQL2, Cron, Date，可以針對需求仿造。

後續可能要再看一下 mock object 與相關 inject testing database 的方法，這樣就可以把單元測試這塊補上。

see also:
[1] PHPUnit
[2] PHPUnit Download
[3] PHPUnit 4.8 Manual (PDF)
[4] PHP.NET: $_SERVER
[5] StackOverflow: $_SERVER['HTTP_HOST'] not set
[6] Kayako Classic User Guide
[7] Kayako Developer Resources