2018.03.30 這天，我離開了 KKTIX。

舊曆年前，慣例要有年度的 1 on 1 考核面談，02.07 面談的尾聲，我被主管通知 KKTIX 團隊要「暫停」遠端工作型態，要搬進原 KKTOWN 租用、現今的華娛辦公室，要拚「短期衝刺雪恥計畫」，主管還表示，體恤我與另外一位一樣住的遠的同事，所以提早跟我們透露這件事，但是希望我（們）先保密。

那時候，我的身體狀態已經因為痼疾有好一陣子很不舒服了。舊曆年前，又是華人職場一個很微妙的時間點，那時候，我想，既然這樣，原本打算再撐一陣子（才辭職）的，但是在這微妙的時間點有著微妙的調動，別的都不講，光是這樣每天通勤，我的身體只會更加感覺不適，算了吧，就到此為止。

02.14 我公開在 Twitter 表示即將請辭，選擇在 SNS 先講，不是為了耍什麼技倆，只是既然已經和家人討論好，我就接著想跟朋友分享我這個決定，而我最多技術圈朋友在用的 SNS，就是 Twitter。同一天，主管也和其他同事 1 on 1 告知這項決策。附帶一提，這天是除夕前一天。

02.21 舊曆年後第一天上班，我正式向主管提出辭職。但是當一天和尚，敲一天鐘，自爆之後，我還是繼續和同事一起打包，準備搬辦公室。

03.01 ~ 03.30 搬進華娛辦公室幾乎一整個月，我都不知道要「衝刺」什麼，怎麼「雪恥」，所謂的「計畫」在哪裡？雖然同事被取消 remote，沒有一個人是高興的，但是大家都還是恪守本分，上頭說要進辦公室，我們就進辦公室，我也拖著疼痛無比的背部與手臂，每天通勤，且通勤與午餐的支出立即狂失血。大家延續年前的進度，該修的東西就修，該做的功能就做，只是，計畫到底在哪裡？

言盡於此。

幾天前的公告：[Android Developers Blog: Introducing Android KTX: Even Sweeter Kotlin Development for Android]

一卡車的人都在說 Kotlin 是 Android 底下的 Swift，不過我覺得這句話應該是直到 Android KTX 這個「增補套件」出現之後才算比較中肯些，讓 Kotlin 在 Android 底下的程式寫起來更精簡、更不囉唆。

也因為看到這東西出現，讓我眼睛為之一亮，沉睡好久好久的 Android App 開發魂又甦醒過來。

除了官方公告列的幾個範例，還可以參考 [Exploring KTX for Android – Exploring Android – Medium] 這篇，挖出了更多目前 Android KTX 能夠做到更方便的事。

當然這套東西還在很早期的階段，不過我想假以時日，它肯定會被扶正。

我打算把我 Android 專案中的「主要、原創」程式原始碼都宣告為採用 GPLv3 授權，所以：

1. [File] -> [Settings] -> [Editor] -> [Copyright] -> [Copyright Profiles] 新增一組名為 GPLv3 的 profile，Copyright text 當然就複製自 GPLv3，再自己簽署一下後存檔。這邊有個地方要記得，就是 Default project copyright 要維持 “No copyright”，不然 Android Studio 自動生成的有些檔案，像是 SVG 格式的圖示，我覺得授權上有些灰色地帶，如果不小心無差別都套上了 GPLv3，應該會成為潛在地雷與日後的相罵本…。
2. [File] -> [Settings] -> [Appearance & Behavior] -> [Scopes] 新增一組名為 Codes 的 scope，針對 Project 遞迴選擇 (Include Recursively) “src/androidTest/java”, “src/main/java”, “src/main/res/values”, “src/main/res/xml”, “src/test/java” 底下的檔案。
3. [File] -> [Settings] -> [Editor] -> [Copyright] 針對 Codes scope 套用 GPLv3 copyright （應該說是 copyleft 比較正確？)
4. [Code] -> [Update Copyright] 套用授權。

在 Arch Linux 底下遇到太多次，神煩，今天索性找出雖不是終極、但至少是中級不低級的解。

主因其實是 Android emulator 與系統裡的 libstdc++ 版本打架，解法參考 [Start the Emulator from the Command Line | Android Studio] 有二：

• 用 command line 啟動 emulator，後面補上 ‘-use-system-libs’ 參數
• 設定環境變數 ‘ANDROID_EMULATOR_USE_SYSTEM_LIBS=1’

第二種方法比較不反人類，不過還是要記得放對地方，如果從 desktop environment 啟動 Android Studio，這個時候吃的環境變數設定是從 ~/.xprofile 這邊載入（假設圖形環境使用的是 X Window System），如果是從 terminal 下的 command line 啟動，就是 ~/.zshrc 之類。

搞定之後就不用跟 command line 搏鬥了…。

這篇是爬了 Mobile01 某棟懷爐耐久賽大樓後，自己也買了兩組回來使用＆惡搞的心得：

1. 千萬不要用酒精（乙醇），不然氣味不只是酒味而已，可能還會有醋酸菌發酵產生的酸臭味！國中理化其實就有講過，酒在空氣中放久了就會變成醋。
2. 酒精含的水分會留在內膽棉花裡，很麻煩，我最後只好把棉花挖出來用微波爐烘乾。
3. 使用酒精造成白金觸媒損害也是真的，不過主因是懷爐因為酒精揮發性低，遠比環保去漬油難點著，所以打火機在火口上烘烤的時間也變長，造成燃燒不全的黑色積碳，變相讓觸媒折壽。
4. 那些耐久測試數據，我覺得是這樣啦，實驗組、對照組、控制變因沒幾個交代清楚，今天突破幾小時，明天又突然降到剩幾小時的，還是看看就好。
5. 把油氣揮發口徑改小，「不見得」就會延長懷爐工作時間，但是「某種程度上」會改善油氣揮發的嗆鼻味。懷爐工作時間取決於「火口效能」、「供氧量」與「供油氣量」，其中給的氧氣多，導致燃燒的作用快，就會縮短工作時間，今天你改了油氣揮發口徑得到很漂亮的工作時間數據，明天卻不盡然如此，就是因為你的實驗沒有控制「供氧量」這個因素，而實務上你會把懷爐拿去各種不同場合使用，「供氧量」會不斷變化，所以…。
6. 把可能有漏氣的地方補起來，「某種程度上」會改善油氣揮發的嗆鼻味，這點也是對的，但是能否延長懷爐工作時間？根據前項，我還是覺得這無從斬釘截鐵地認定，但是理論上來說，減少油氣從不該揮發的地方揮發掉，就能相對增加能源利用效率，這點我是可以肯定的。
7. 承上，我主要是補上爐體側邊兩處那有點大的縫，曾經用過鋁箔膠帶，但是太厚，會導致上蓋蓋不上。接著用美工材料「超輕土」也不是很順利。最後想到了「石膏」這種耐熱材料，在文具店買一包只要 13 元，調一點石膏漿，用水彩筆輕輕抹上去，等它乾燥後，就補得很密合了。順道一提，石膏在油漆行也有賣，雖然油漆工程用的與美術用的石膏成份不太一樣，不過在這個只是填補縫隙的場合，應該都適用。
8. 我沒有用過那棟大樓提的一些舶來品與外國品牌懷爐，所以無從比較，不過 Lamp 真的如某些人揶揄的那麼不堪嗎？我也不覺得，主要是它的加油口設計就是可以讓你很順手的延長懷爐工作時間，而且我這幾次試用，它再怎麼不濟，都能有四小時，如果在你活動範圍內，油料添加對你不是問題，那買 Lamp 來用就是經濟實惠的選擇。