pretty code

2026年11月7日 星期六

重大決定

應該不會把《劍來》看完吧?

一來 Kobo 買的簡體中文校訂版沒有包含全部章節,二來後面越寫越誇張,人物層出不窮,很多時候感覺都是無病呻吟?

可惜了前面的精采章節,最近中午邊跑測試邊重看了一遍,跟後面劇情完全不是同個檔次?

個人覺得看到主角送小孩子到大隋書院求學就可以停止了,最多看到老龍城與鄭大風聯手退敵,因為接下來就是最無聊的書簡湖了!

剛好這一段都還有繁體中文電子書可以購買,就不用像我現在看得如此克難,還要準備簡轉繁字型。

不過,前面章節也不能說是毫無缺點,把儒家門派寫得好像在演宮鬥劇,讀書人間相互勾心鬥角,一點也不幫忙維護齊聖人,導致齊聖人只能捨身成仁!對比後面劍氣長城篇的儒家運籌帷幄勇抗妖族大軍,我真懷疑我看得是不是同一本書?

總之,該開始決定下一本書要看啥了。

2026年11月4日 星期三

CrossMosa 試用心得

我這個人就是反骨,不是拿 X3 國際版來刷第三方韌體,而是使用 X3 一般版。

果不其然,使用 SD 卡順利刷機成功,可惜的是,忘記先記住機器序號,總之是10/16 在熊老闆那購買的,顯示晶片是 UC8253。

介面看起來還不錯,又可以 Wi-Fi 傳檔,不過對我來說,有兩個致命缺點:

1. 不能關機,只能休眠,可能要翻一下說明書。
2. 以橫列來說,差不多大小的字型,目前只能顯示 8 列,比原生的少一列。

最重要的是下面會多出一列空白,這樣上下沒有對稱,看起來就不開心。


另外,如果是在閱讀畫面進入休眠狀態,有機會底色會變很髒。

我自己是覺得原生的閱讀起來比較順。

CrossMosa 比原生好的地方

01. 介面看起來不錯。
02. 有 Wi-Fi 傳檔。
03. 作者已經提供不同大小的字型檔案可以直接使用。
04. 閱讀頁面底部顯示資訊比較豐富。
05. 開源,隨時可以自行修改。 
06. 註腳可以隨時跳躍並返回。
07. 直排書就是直排顯示。

有機會應該會再刷回原廠韌體。

2026/11/05 更新

如果沒有下面的問題,個人覺得一般人如果不排斥刷機,使用 CrossMosa 是個不錯的選擇。因為它忠實反映了書本的原始樣式。

直排書就是直排書,橫排書就是橫排書。

無奈,我發現我放進 SD 卡的書,目前除了《人月神話》外,看沒 10 分鐘,就會像下面截圖一樣變得很髒,感覺跟之前待機畫面的問題有關?

等我《人月神話》看完,再請 AI 來修復?


2026/11/06 更新

上面問題,懷疑跟「設定-顯示-日照淡化修正」打開有關?關掉後除了待機畫面外,其他似乎都已恢復正常。

下面是目前用的字型設定。


2026/11/07 更新

使用 CrossPoint 官方的字型產生器,這次 Kindle 的圓體就可以順利轉檔成功,跟 CrossMosa 提供的比起來,文字看起來較黑,故字距感覺也變少了。

左邊是 CrossMosa 提供的,右邊是 Kindle App 自帶的圓體,不知道為啥遇到直排的標點符號會亂碼?可能要加上額外的 Custom Range?


嘗試了下面這些區段,看起來沒有幫助。


總之,截至目前為止,自己使用 CrossMosa 的感覺,作者說這個韌體是適合用來看中文書的,我確實是百分百同意的。

2026年11月1日 星期日

關於 PTT 最近更新

最近 PTT 似乎有些改版,各家 PTT App 多少都有些問題。

今天想要使用 Pubook Mobile 來上 PTT,才想起需要更新,但是居然在 Google 商店看到不支援此裝置?

還好剛才想到今年剛買時是使用手動安裝 APK 的方式安裝 BePTT,重新順了一下原本的 script,之後才不會忘記這件事。


ptt.sh 第 11 行註解寫錯了,應該是加上 pull command 從正常手機抓出所有的 APK。

2026年10月31日 星期六

另外一家嘿嘿工具又失敗了

應該是該家工具偷偷改版的緣故?

印象中今年都還有嘗試備份書檔?

解決方式也很簡單,請出我們的 WireShark 即可。

由於之前的工具是用 Node.js 寫的,但這次需要修改 http get 的參數,不知道是大家現在都用 AI 還是怎樣的關係,居然搜尋結果前幾個的程式碼都不能直接拿來用,害我只好直接去看官方文件。

我從以前就對這家的文件沒轍,可能跟我沒有好好學過 Javascript 有關,不是很懂基礎概念,導致我看文件有時都會很出戲?


總之,官方文件描述可以將 url 和 options 分開傳遞,果然順利解決。

可惜的是嘿嘿工具尚無法自動化,因為我無法知道官方工具將我需要的那個東東藏在哪裡?算了,看在目前很少買書的份上,有需要再開啟 WireShark 即可。

終於,我可以來看我的人月神話了,沒想到居然還不是版式書籍?這樣才是一本好的電子書,希望約耳談軟體也可以出電子書。

果然是老人懷古呀XD

2026/11/01 更新

這個東東約一個小時內會更新一次,我印象中 WireShark 有 API 可供呼叫,直接請 AI 寫?

2026年10月28日 星期三

寸步難進

大概幾個星期,就要被 simulation 跑不過搞一次!

即使已經經過快 10 個月的洗禮,現在還是很難快速定位到真正出錯的地方?

我也搞不懂是我跟那個環境不熟還是怎樣,內心還是覺得 GTKWave 才好用,至少可以快速找到訊號,搜尋速度也很快,有編譯 db 的 EDA 工具搜尋居然如此難用?

雖然上班這兩天需分心搞定模擬(嚴格來說,只有一天,今天都還沒開始呢),放假後兩天身體不舒服也沒法思考,早上還是順利找到原因,但不是我原本想的 3 個地方,只要處理 1 個地方就能 pass 基本的 pattern。

那為啥我看圖會覺得是這兩個地方 unknown 造成?是啥原因造成我誤判?還是哪邊我搞錯了,到現在還是想不通?

套句《劍來》的術語,原來我已達到飛升境圓滿而不自知XD

想要再進一步,我只能往十四境邁進了?

好像會了一點東西,又好像什麼都不會?

這就是在浮沙逐塔的壞處呀!

不如醉裡挑燈看 Code 來得自在?

2026年10月24日 星期六

沒完沒了的更新

我的 KoboExpense 已經掛了一陣子,之前怎樣看都看不出來正規表示法跟現在的網頁有啥不同?

我覺得當初應該不是我眼睛脫窗?

至少今天再次嘗試,已經把他修正完畢,結果這次只是沒有加雙引號以及句尾多了空格。

Kobo 的工程師如果整天只會搞這些旁枝末節,我真懷疑他們的能力何在?


去年有買灌籃高手及滅活法,今年則是購買神龍之謎整套。


同場加映讀墨網站,當初我將 ReadmooExpense 開發完畢後,針對購買資訊部分就沒更新過了,5, 6 年都過了,還是沒啥大問題。

雖說讀墨網站的呈現,工程師是以 API 的方式,來取得購買資訊,但至少人家的介面一直保持不變。

2026年10月22日 星期四

舊愛還是最美

昨天終於有時間來觀察客戶自行設計的記憶體修復流程。

話雖如此,真正的實作是客戶請我跟 AI 討論後設計出來的。

客戶要修復的記憶體不算太多,但要透過 GUI 一個一個訊號拉出來觀察也是有些沒勁?

還好上個星期已經有寫一個簡單的 Tcl,將要觀察的訊號轉成 Tcl 餵入 Simvision 軟體。

但最困難的還是這個無中生有的訊號如何定義?都怪那該死的 Escaped Identifier Verilog 語法,我實在無法簡單的從 RTL 轉成最後網表看到的訊號名稱?再加上有些訊號是 for loop gen 出來的,也大大的增加我轉換難度!

這次不像上星期可以從 error log 中 parse 出我要的 instance,沒辦法,只好先找到一個 instance,再用其他程式語言組合出訊號名稱,然後餵進我的 Tcl(理論上應該在 Tcl 直接用 3 層迴圈,但懶得找語法了XD)。

沒想到 Python f string 要跳脫 Escaped Identifier 不是那樣直觀?試了 Google 前面幾篇文章的辦法還是不成功?

C 語言就沒那樣奇奇怪怪的講究,還好客戶工作站還是有 gcc,3 層迴圈,蛋糕一塊,重點是我根本不需要 Google 都還記得住語法!

果然是我學軟體以來用得最多的程式語言,小孩愛吃已回購。

2026/10/23 更新

靠,原來是被錯誤訊息誤導,大括弧要用大括弧跳脫,只有反斜線要用反斜線跳脫。

但我覺得 Python 這個設計也不好,都用反斜線跳脫不就好了?程式語言設計應該要有一致的行為模式才對。