我覺得 premake 做對的事

premake 是一個用途如同 cmake、meson 之類，幫忙你「產出指定編譯工具的專案檔」的自動工具。

假設你有一個自行開發的跨平台軟體專案，需要能被 Windows MSVC / Linux Make / MacOSX XCode 三個編譯平台所編譯。最直覺的作法就是分別建立三個編譯工台的專案檔，也就是 MSVC 的 solution 檔案、Makefile、以及 XCode 用的 workspace 檔案。這個作法在維護上會有一個大問題 -- 每當你新增了原始碼檔案、或是變更了某個編譯設定，你必須要記得同時去更新另外兩個平台的專案檔，否則下次有人在另一個平台上工作時就會氣急敗壞地嚷嚷著編譯失敗。

而 premake / cmake / meson (以及其它族繁不及備載) 這類工具，就是試圖解決這個問題。通常它們的作法是: 你必須改按照它們的方式來編寫專案設定檔，然後透過這份專案設定檔來一次生成所有目標編譯工具 (MSVC / XCode / Make ...) 的專案檔。

簡易台股過濾器 - 初試 Google Cloud AppEngine、Datastore

起念是想在「不負擔任何費用」的前提之下，建立能有動態內容、提供可互動 WEB API 的網頁伺服環境，即 Server 端必需能支援 CGI。在各大雲端平台上一陣走馬看花之後，最後看上了 Google Cloud AppEngine、以及用作 Database 的 Google Cloud Datastore。兩者皆有常態性地低用量免費方案，只要用量不超過某限額，是不用付錢的，很適合作為個人練兵場、或驗證一些概念性的想法。

於是乎我把自己平時為了方便選擇存股目標而寫的台股過濾器，移植到 AppEngine 中，提供了簡易的網頁前端以方便操作。

台灣上市股票過濾器

原始碼部分
台股歷年股利、最近成交價爬蟲 (爬出數據塞進 Datastore 中)

置於 AppEngine 中的部分 (含網頁前端內容、後端 WEB API 實作)

在網頁上測試 C++11 Regex -- 初試 emscripten

最近在摸熟 C++11 導入的 Regex 函式庫中使用的 regular expression 語法。C++11 Regex 預設是採用 ECMAScript (也就是 JavaScript) 中定義的 regular expression 規格 (詳見 spec)，而該語法並不完全相容於我比較熟悉的 awk/egrep 中所使用的 regular expression 語法。

最快摸熟的方式當然是實際去試試看。最先是很快地寫一個簡單的 C++ 命令列程式，反覆餵它一些資料然後觀察運作結果。幾次後發現這樣的土法煉鋼法，最好還是配合 GUI 程式比較
便於操作。正準備要動工時，腦袋中突然閃過前陣子在 SlideShare 上看到的一個簡介 emscripten 的投影片。透過 emscripten 的協助，我大可直接把原本那個 C++ 命令列程式轉譯成 asm.js 嵌入網頁中，再小改一下輸入輸出的部分，最終得到一個網頁 GUI 的版本。

C/C++ 如何實現 coroutine (fiber)?

近幾年不論在 Lua 、或 Unity C# 中，都能看到大量 coroutine 的應用範例。一旦了解 coroutine 的工作原理，很難不愛上它。C/C++ 中其實也可以實現 coroutine，但不知為何很少看到大規模應用，也或許是因為 multi-threading 的提倡而被冷落。結果反倒是在 Lua、Unity 等等以 single thread 應用為主的場合才又重新獲得關注。

C/C++ 伺服器藉由 FastCGI 快速提供 RESTful Web API

我負責的遊戲伺服器是以 C/C++ 開發的。而現今這年頭無論是跟哪家營運商合作，無可避免要提供 RESTful Web API 方便讓營運後台對伺服器進行動態的設定或提取即時資訊。我原本對 Web 後端技術所知不算多，不過整個流程摸索過一次之後，發現也沒想像中那麼複雜。以下說說心得。

首先你要知道 CGI 跟 FastCGI 是什麼東西。

說說 C/C++ 網路伺服器使用的各種多工器 (Multiplexer)

若想單單只靠作業系統提供的 API 來實作 C/C++ 網路伺服器程序，首先面臨的問題就是該怎麼設計連線的多工處理 -- 同時間與伺服器建立的連線可能成千上萬，怎麼有效地查覺誰送了資料過來需要回應? 在通訊和資訊網路的領域裡，像這樣「把眾多輸入訊號合併匯集後循序處理」的過程稱為「多工」(Multiplexing，大陸譯為「多路復用」)。因此，由作業系統提供，判斷現有連線中是否有待處理事件的 API ，即稱為「多工器」(Multiplexer)。

我在學校裡只學到一種最基本的多工器，就是 select()。踏入業界幾經歷練，才又陸續接觸到 poll(), epoll(), kqueue(), IOCP 等等的多工器。麻煩的地方在於每個作業系統支援的多工器種類都不一致。就算是以現今 2017 年來看，也只有最古老的 select() 幾乎能保證被各作業系統支援。因此，如果跨平台運行是伺服器的一個主要考量點，那麼伺服器端通常都還要自行開發一層網路事件分派層來統整各平台上多工器的使用差異，或著直接利用現用的第三方函式庫如 boost.asio 或 ACE 等。

我雖能力一般水平有限，但對於想一窺全貌但不知何處入門的同好們，提供一點走馬看花式的導覽，還是可勝任的。

大量運行 Unity Headless Player 遭遇的坑

Unity 支援將專案輸出為 Linux 平台上以 Headless 模式運行的 Player。Headless 指的是沒有圖形環境 (Ex: 沒有執行 X-Server)、甚至沒有接螢幕的電腦。通常放在機房中代管的伺服器、或是雲端平台上租用的虛擬主機都是以 Headless 的方式來運行。Headless Player 在應用上除了可利用來製作簡單 Server 程式之外，也可以用來製作「特殊的」客戶端版本，例如開發線上陪玩的 BOT 機器人、或是功能測試機器人等等，這麼做的考量點通常是想最大程度地共用既有的客戶端程式碼。

當我試著要在一台 Linux 機器上大量跑 Headless Player 時，總會發現運行到 170 ~ 180 隻後，系統就會開始出現無法 fork 的錯誤訊息，甚至整個系統都被癱瘓無法做事。就算是空的 Unity 專案也會有這個現象，因此懷疑一部分的原因出在 Unity 本身。