GUI app on Kobo Clara HD (05)

之前發現開發 GUI App 會因為電子紙特性而有螢幕閃爍的問題，中午順手查了一下 KOReader 是如何避免這個問題的？

只是匆匆一瞥，但貌似 KOReader 在更新時是將資料寫至 framebuffer，並透過 ioctl 下不同的參數而達到部份更新的功能？

神秘數字 10 30 5 5 6 8

一大早就被住家附近的下水道工程低頻聲吵醒，雖然我無法證明就是他們搞出來的，但對比該工程之前的行為，我猜兇手八九不離十就是他們。

早已打定主意早上要買咖啡，無奈早上小七排隊人潮有點多，目測約有 9 個人要結帳，實在不想浪費時間，故便改往公司樓下新開幕 3 天的 cama 購買咖啡。

開幕第一天時在對面等過馬路觀察就發現結帳速度很慢，但今天已是第 3 天，再加上下班經過時發現他們有做類似檢討會議的動作？我想情況應該是有所改善才對，雖然今天也有排隊人馬 5 組，想想還是給他們一個機會，就是這個念頭害我晚了 18 分鐘才刷上班卡。

該來揭曉神秘數字 10 30 5 5 6 8 了！

光輪到我結帳就花了 10 分鐘，我直接拿剛好的零錢，結帳也花了快 30 秒。

在我前面有 5 組人馬，櫃台員工也有 5 人。

結完帳過了約 6 分鐘時，居然還問現場是否有 358 號？而我就是那個苦主 358 號，雖然我目測他們也是才剛做完前面的點餐，但印出來的單子當然是有人，怎麼會問這種天兵問題？

又過了 2 分鐘，總共是 8 分鐘後，我終於拿到我的拿鐵，結束了這個驚奇之旅。

雖然我沒開過咖啡店，也沒做過老闆，但我直覺絕對是員工訓練或是工作流程出了問題。

首先，面對客人詢問時，不管是結帳的還是機動人員，明顯可以感覺出來不熟悉，故還需要詢問看起來是店長的人。

再來看其他人員配置，一個人負責飲料，一個人負責餐點，雖然感覺有點少，但我不認為櫃台空間還可以再塞下額外 2 人，頂多就是再配置 1 人機動 2 邊幫忙。

最後則是看起來像店長的人，除了剛進來時，看到他在調整加入會員優惠的小看板外，我還真感覺不出來他還做了什麼事？也許是我沒有一直觀察櫃台的緣故吧。

當店面裝潢好後，我寧願延後開幕，照樣請員工上班，讓員工可以熟悉整個流程，甚至可以分兩組人馬互相做角色扮演訓練，等到大家都上手後再開幕也不遲，以時薪 300 來算，5 x 300 x 4 x 5 = 3 萬（練習 5 天，一天 4 小時），雖然感覺有點多，但攤在整個營業期間來看，真的不算什麼？

也許以上都是沒有開過店的我的異想天開？

但以我分不出咖啡有比較好喝的情況下，為了速度我應該是不會考慮再進去一次。

GUI app on Kobo Clara HD (04)

還是不想浪費 Golang 跨平台的能力，再加上不想花費太多時間，故想嘗試 HTML Golang GUI 的解決方式。

這次選擇的是 gowut 這個專案，無奈在 Clara HD 實機上測試時，還是無法正常執行。

第一個問題是它無法自動帶出瀏覽器視窗，這個尚屬合理。

第二個問題是即使自己開啟瀏覽器輸入網址，還是無法連上 gowut Server。

第三個問題是我改用 gowut 自己提供的測試網址，雖然看起來 GUI 元件有正常運作，但一來速度太慢，二來是多操作幾下就會整個無回應，三來是畫面會因為重繪而閃爍（電子紙特性）。

目前看來 HTML GUI 解決方式不是正解，光畫面會閃爍就無法讓人接受，不過這也延伸出另外一個問題，即使我使用 Qt 撰寫 GUI App，我一樣會遭遇畫面閃爍的問題，除非 Kobo 本身有提供 SDK 讓使用者呼叫暫時停止重繪，好避免畫面閃爍。

感覺 GUI App 這個問題快走入死胡同了？

《七龍珠彩色漫畫》

最近無意間在讀墨網站發現，居然有《七龍珠彩色漫畫》的電子書，對於一年前才狠下心買完《七龍珠完全版》的我來說，內心真的是陷入天人交戰。

試算了一下，如果全出的話共有 32 本，一本 105 元，總共要 3,360 元，如果是趁著 3 本 75 折買則是要 2,520 元。

樂天的價錢也是 105 元，Google Play 圖書則是只要 87 元，不過 Google Play 圖書無法下載檔案，再加上價差不大，應該是不用考慮。

以前買完全版時，共花了 150 x 34 = 5,100 元，因為讀墨分兩次上架，故我也記不清那批是打折時購買，我想至少也是花了四千多塊有。

不知道在書展期間是否有機會全部上架？也許到時候還是會衝一波。

GUI app on Kobo Clara HD (03)

KoboCloud 雖然看起來很簡單！但其實裡面的 script 是有技術含量的，以 Google Drive 來說，它至少要先知道使用 HTTP Get 資料夾連結後的回傳內容是什麼？還有如何取得所有的檔案名稱以及個別的下載連結。

舉例來說，假設我們設的公開連結為：

https://drive.google.com/drive/folders/XXXXXXX-YYYYYYYYYYYY

response 回來的內容需利用正規表示法來找到相關資訊，可能是我只會簡單的 Re，我取到的會因為貪婪法而無法拆解成一本一本的資料，故只好再用字串分割做 2 次加工。

底下是我目前用的 sample code，其中 base_url 就是 XXXXXXX-YYYYYYYYYYYY。

而每本書的下載路徑就是 https://drive.google.com/uc?id=file_code&export=download，下載時會經過幾次重導向。

import re

import requests

url = 'https://drive.google.com/drive/folders/XXXXXXX-YYYYYYYYYYYY'
response = requests.get(url)
s = response.text

pattern = '\\\\x5b\\\\x22(?P<file_code>.*)\\\\x22,\\\\x5b\\\\x22(?P<base_url>.*)\\\\x22\\\\x5d\\\\n,\\\\x22(?P<file_name>.*)\\\\x22,\\\\x22'

res = re.search(pattern, s)
all = res.group(0)

items = all.split('application')
for item in items:
    res = re.search(pattern, item)
    print(res.group('file_code'), res.group('base_url'), res.group('file_name'))

有空還是把人家寫好的 script 裡的 RE pattern 看懂，也許可以再精簡 code。

GUI app on Kobo Clara HD (02)

Fyne 缺少的 libGL.so.1 確定是無法靜態連結了，至少就我目前看到的資料是如此。

在不考慮 GUI app 的情況下，其實寫個 Golang app 是最快的，在 Wi-Fi 開啟時就自動同步 Google Drive，就像 Kindle 同步個人文檔一樣，第一次時也是全部下載，並沒有讓使用者選擇，只是之後還是可以任意刪除再下載，甚至回過頭來刪除 Kindle Server 的個人文檔。

我想像中的行為大概是這樣：

1. 每一次同步後就更新資料庫，在不被 Google 拒絕的情況下，分次把書下載下來。
2. 下次同步會檢查是否有下載過，已下載過的不會再重新下載。

3. 使用者從 Google Drive 刪除檔案，同步後 Local 的資料庫也會刪除，只要再把書放回 Google Drive，下次同步就會視為未同步過的檔案，便可以再下載一次。

在沒有 GUI 的情況下也只能這樣做了，雖然我還不清楚 Google 阻擋的頻率，但感覺這整套流程應該是可行的。

就把這選項當成 plan B 吧。

專業的小 7 店員

最近又下雨下到令人阿雜，古人說的什麼「沾衣欲濕杏花雨」都只是騙人的玩意。不論是毛毛細雨還是又濕又冷的冬雨，讓人一點都不想上班。

因為下雨的緣故，買咖啡變得不方便，故購買頻率也跟著減少，雖然我不知道是不是只有我是這樣？在只有一隻手是乾淨的狀態下，又要拿傘又要拿咖啡，真的是無解。當然會有人想用提袋裝咖啡，但對於下雨就懶得帶包包出門的我來說，實在是生不出外套空間擺提袋。難怪《原子習慣》才會強調建立環境對習慣養成的重要性，因為人是很懶惰的生物。

總之，今天一反常態的進去小 7 買咖啡，還是在已知一堆人等咖啡的情況下，人心真是讓人猜不透呀！目測在我結完帳後，在我前面連我還有 6 組人在等咖啡，約莫在消化了一半的時候，排在我前前面的人突然抱怨說，為什麼在她後面的已經拿到咖啡（我前面一位）？事情的真相是她們兩人算是同時結帳，但因為抱怨的人還要報手機使用會員結帳，故實際的順位往後排了一位。雖然店員跟她來回對話時有隱含一絲絲火氣，但雙方總算還是有控制住情緒。

厲害的事來了，中間還有差插另外一組人也是在抱怨咖啡速度，他們的對話也是有些小火氣，在他們拿完 3 杯咖啡後，小 7 店員還是在百忙之中發現錯誤，急忙追出去修正，我不知道標籤機是否有提示同一批結帳？如果沒有的話，店員要如何得知這個是同一組人的咖啡？畢竟做咖啡的和結帳的不是同一位店員居多，特別是生意好的店，如果沒有這個功能應該要加上才會方便。畢竟，可以靠機器解決的就不要靠人力。

接下來就是我的咖啡了，店員還不忘跟我說聲抱歉久等了，讓我不禁讚嘆小 7 店員的情緒控制能力，如果沒有一套訓練機制，實在是很難提供這樣的服務？

雖然，超商有分直營店跟加盟店，還有我也不在固定的超商消費，再加上我本身也不喜歡統一這家公司，但就我個人曾有的消費感覺來說，小 7 店員的專業度絕對是第一名當之無愧。

GUI app on Kobo Clara HD (01)

昨天下班前終於開始了我計劃的第一步，首先便是嘗試 Fyne 這個 Golang 專案在跨平台編譯後是否能順利的跑在 Clara HD 上。

一開始便照著指引在 Linux 上準備 docker 環境，只要使用 go get github.com/fyne-io/fyne-cross，便可以自動下載 docker 所需要的環境，當然系統還是要先有 docker 本體。

回家後使用手機的 OTG 功能，修改我的 Kobo 翻頁器 script，直接啟動編譯好的執行檔。很可惜的是，無法順利啟動，從 log 中看到是缺少了 libGL.so.1 這個函式庫。

接下來便是研究是否可以使用靜態連結解決？也許這條路行不通也說不一定？

一天五蔬果

昨天大概是用最多程式語言的一天吧？

早上先使用 UEFI Shell script 幫同事準備自動測試的工具，完了後再使用 C 幫同事在我之前的 UEFI application 中增加新功能，接著是用 Node.js 在我的 Web Server 中開發新功能，然後是用 Python 幫同事開發小程式的新功能，最後則是在下班前用 Golang 準備 Kobo GUI app 的雛型測試。

只有 Golang 不是自己寫的，其他的每個都需要稍微花腦力，對我來說也是個特別的一天。

2021 第一篇文章

昨天下午突然來了一堆臨時需求，再加上天氣寒冷，回家就懶得再把我的筆電拿出來，故原本要發的一些感想也就這樣無疾而終。

今天是 2021 年的第一天，又買了幾本書，希望今年能夠有個好的開始。

這幾天一直在想如何寫個 GUI App 跑在 Kobo Clara HD 上，以解決 KoboCloud 書本數量一多在 Google 雲端硬碟同步失敗的痛點，很想用比較簡單的方式來解決，但暫時還沒有有想法，希望在我的 Kindle Paperwhite 3 掛掉前，我能順利的找到解決方式。

另外，最近一直在觀察最大同性交友網站（Github）上面討論的一個專案，該專案是想要解決某個不能說的秘密！但對於已經搞定的我來說，看著他們想用正規的方式來突破遇到困難，卻又不能給他們任何提示，感覺就像看到兩個月前的我一樣，那種不得其門而入的感覺就是阿雜。

接下來，我想說一個故事。在《獵人10》中，小傑跟奇犽被信長捉住，後來還是多虧小傑想到仙派告訴他們有關贗品的技巧中找到逃跑的方法，而這個方法就是「從旁掉包」。

還有上星期時，實測了一下在只簡單準備 2 樣菜，炒吻仔魚和炒空心菜，從料理、用餐以及洗碗跟清潔善後總共花費的時間，結果居然要 110 分鐘？真是不統計不知道，如果家裡是另外一半負責廚房的，真的是要對他或她好一點。

目前光讀墨就還有 127 本書未讀，撇開只是當工具書用的，應該也還有百來本要看吧？幸好現在繁體中文書對我越來越沒有什麼吸引力，我一定要在今年把它通通結束。