REVOPOINT MINI 入手

網路購物確實是比較方便，下單四天內就已到貨，比我一個一個打電話去問展示店家是否有銷售快。

只可惜我的白雪公主演唱會票夾掃不出來，應該是因為平面無特徵點緣故？

在手動刪除多幀只保留單幀後，我的土炮結構光系統與消費型機種單看 3D 點數確實沒有那麼大差異！不過這只是很初步的嘗試，等到假日有時間再來研究。

我大概能理解消費型機種設計，他們是將 3D 掃描與點雲配準綁在一起，預期使用者是要掃瞄一個整體物件，故他直接偵測待掃瞄物體是否有特徵點可供辨識，這就是為什麼我的票夾無法被他接受，解決辦法便是貼上配件裡的小圓點貼紙。

不過我購買這台機器最主要的目標是要知道點數差異，對我來說如果能有所謂原始單幀的操作模式，我在做比較時就會更方便，我猜是沒有這樣的功能，但回頭還是把說明書或操作軟體說明書看過一遍。

2023/11/30 更新

試著將美國隊長放遠，距離約 25 ~ 27 cm，軟體介面上顯示位在較遠的範圍，這次單幀點數只剩 2 萬 7 左右。

2023/12/01 更新

將兩個點雲同時用 CloudCompare 開啟，MINI 的 Z 座標是負的，且似乎跟我的土炮系統是上下顛倒？

將我的土炮點雲對 Z 軸做 translation 彼此拉近好一起放大比較，我的點雲確實是比較疏鬆。

雖然我的土炮結構光系統到消費型機種這條路還是有很多軟硬體整合步驟要做，要學習點雲配準以及其他未知補強，但整體感覺並沒有我想像的困難，哈。

晚上拿出 turntable，讓它自動轉 2 圈，使用預設一鍵處理的情況下，點雲數約為 31 萬。

一些操作小技巧：

左上角曝光視窗盡量不要有紅色跟藍色，Red is overexposed，Blue is underexposed。

非彩色模式下，綠色表示現在被 scanner 看到的部分，藍色則表示之前掃描過的部分。

2023/12/02 更新

即使旋轉盤上有小圓點，票卡夾還是無法被辨識到，不想貼上貼紙的情況下所有的測試也在此告一段落。

有時候真想不通，我的土炮結構光第一次嘗試時，校正做得並不好，投影機解析度也只有 640 x 480，反光手機表面卻還能依稀看到妹子？是因為背景用全黑嗎？至少 MINI 一樣對反光面沒轍！

有了對照組 MINI 後，之後如果又想玩結構光，大概知道努力的方向了。

有沒有人想花兩萬接手近全新 REVOPOINT MINI 呀？

2023/12/04 更新

昨天晚上總覺得哪邊怪怪的？後來才想到拼接模式應該要選標記點拼接，可惜時間太晚無法驗證，早上起來試了一下，勉強可以配合旋轉盤掃出點雲，但在多轉了幾圈後，因為標記點確實過少（MINI 掃瞄範圍過小，標記點被物體擋住，單幀最多沒有超過 8 個標記點），追蹤就出現問題了，最後在拿掉後面的幀數後，點雲總點數約為 31 萬 5 千（雙面），我的土炮結構光系統只掃一次的情況下，點雲點數約為 9 萬 5 千（單面）。

2023/12/11 更新

拿出原始照片計算一下，票卡物件約在圖片座標 (580, 289) ~ (1102, 486) 這個區間，換算 pixel 應該約為 523 x 198 = 103,554 個點，有效 3D 點數比例約為 91.74 %。

換句話說，那個座標範圍內的 pixel 我幾乎都可以轉成有效點。

將 mask 中，black_image 比 white_image 亮的地方顯示為綠色，整個投影機投射的範圍內有效點數數量確實還不錯。

美國隊長相較之下就差了一點。

Java interface instance

下午部門另外一個主管問了我一個問題，是關於 Java interface instance，我們在一個 open source 的專案中看到一個 Java interface，但卻找不到那個實體位在哪裡？

因為我不是寫 Java 的，故我一時也看不出來！

但我覺得應該是 Spring Boot 自動產生的或是在這個框架中被自動注入的，明天來問我同學部門的人好了，我想對他來說應該是很簡單的。

2023/11/28 更新

他也沒用過 Spring Boot，但跟我的想法一樣，應該要有 xml 或什麼設定檔可以看到才對，但似乎不是這樣，感覺 Spring Boot 處理掉了？

本想直接 register，但似乎要有指紋辨識器且目前只有 Ubuntu 的 Firefox 可以支援，至少我的手機跟桌機都會報錯 Error: ReferenceError: PublicKeyCredential is not defined。

試著直接將 object 印出來再重包 docker image 測試，是自動產生（注入）的沒錯？

有些東西沒有碰過就是不知道，這是我這次最大的感想XD

後記：

https://docs.spring.io/spring-data/jpa/reference/repositories/definition.html

從上面網頁可以知道使用 @Entity 表示要用 JPA，而 JPA implementation 就是 SimpleJpaRepository。

2023/11/29 更新

昨天下午回信做了些補充，之後便是看了前面那個網頁，雖然不到整條線串起來，但一定是比前天下午多懂了一些XD

本想繼續回信再做些補充，但畢竟不是寫 Java 的，況且寫 Java 的人也不一定會碰 Spring，故就不班門弄斧了。

將一些關鍵字留在這裡好了。

01. Spring 是一套 full-stack 框架，需要一些 XML 檔幫助設定，Spring Boot 是基於 Spring 開發，目的是快速搭建一套 Spring 應用程式，故不再需要 XML 而可以直接使用 Java 組態（Annotation）。

02. 資料庫連接最早是使用 JDBC 來操作資料庫，只要有各家 DB JDBC driver，便不用煩惱如何使用不同的資料庫，但因為要自己處理連接等操作，故後期便使用 ORM 框架來處理資料物件與資料庫之間的對映，Hibernate 就是一個 ORM 框架。

又因為建立資料庫連線很花資源，故想要像 Thread Pool 一樣可以重複使用，便有了 Connection Pool 的概念，Hikari CP 便是其中一套很出色的第三方套件。

03. Spring JPA 中，Entity 和 Repository 是成套的，故只要 interface method 名字與參數有符合規範，Spring 框架就可以自動長出這些實作，甚至要用 AND、OR 條件都沒問題。

2023/12/01 更新

此專案用到 Lombok 函式庫，他會自動在編譯時期幫你補上 getter、setter 的實作。

全新的開始

https://github.com/T-head-Semi/wujian100_open 是阿里平頭哥在 2019 年開源的一個專案，內容是關於 RISC-V 晶片開發平臺 wujian100，這就是傳說中進入偉大航道的起點嗎XD

心有餘而力不足

趁著洗澡前無聊巡一下田水，兩個開發過的 Chrome Extension 都宣告陣亡，其實應該是 3 個，但我不想面對了XD

Kobo Expense 好一點，程式居然可以提醒網頁改版？我都忘了我怎樣判斷的！

Readmoo Expense 就有點糟糕，不管怎樣都只抓到第 1 頁資料，應該是判斷總頁數的地方需因應 HTML 改版重抓？

網頁爬蟲相關的 code 就是這樣討厭，每次改版都要跟著因應！

先知道這件事就好，放張小老婆的圖好記得回來追蹤XD

有沒有這麼可愛（被老婆毆飛中…）

2023/11/25 更新

星期六還是輕鬆一下好了，花了快 2 個小時改好 regex 並上傳到 Chrome Store 等待審查，我終於又可以知道購書金額了。

Kobo Expense

Readmoo Expense

晚上 8 點半左右就收到審查通過的電子郵件，速度還蠻快的，看起來還不用 5 個小時。

雖然這次更改還算快，那是因為之前 Kobo Expense 上架時正逢 Manifest v3 更動，權限與新 API 呼叫已經跟著修改，故這次只要專注在 regex 本身即可，但難保下次還要很久之後才會再有需求回過頭來修改，到時可能連 Chrome Extension 架構都忘光了？

最近在補交接文件，連自己寫過的文件都忘了有這回事，人的記憶力確實很不可靠，趁此機會將這兩個 Chrome Extension 的架構留下記錄。

js/popup.js 是按下按鈕後會出現的統計報表主體用的 js，裡面也是負責觸發 js/gethtml.js 去詢問網頁的地方，另外，popup.js 裡的 chrome.runtime.onMessage.addListener 負責接收 gethtml.js 傳過來的訊息，gethtml.js 則是透過 chrome.runtime.sendMessage 來傳遞兩種訊息，一個是 action: getSource，另一個則是 action: progress。

getSource：

1. HTML 格式正確，parsing 到需要的資料，回傳的會是一個 array，裡面元素是一個 object，結構模擬 Readmoo 原本 API 的回傳資料結構，故 popup.js 裡面不管是 Readmoo Expense 或是 Kobo Expense 的 code 都長得一樣，因為當初 Kobo Expense 就是拿 Readmoo Expense 來改的，故花費心力很少。

obj = {

        purchase_date: "2018-12-28",

        price: 123

}; 

2. parsing HTML 失敗，回傳的就是錯誤訊息。

progress：

顯示目前處理了幾頁，例如 1 / 3、2 / 3、3 / 3。

另外，Regex 需要考量的無非是一頁有幾個項目，總共有幾頁要拜訪，還有購書日期，購書金額如何透過正規表示法取得，這個只要 review gethtml.js 就可得知，但因為兩家書商網站寫法不同，故只能各自處理。 

Readmoo：

Readmoo 購書金額明細頁面是 API，回傳格式是 JSON，只要結構不變，這裡不用特別管它，我們只要知道總共有幾頁即可。

Kobo：

Kobo 購書金額明細頁面是 HTML，且購書金額跟日期都不是寫在一行，故需要兩個 regex 分別抓取。另外 Kobo 可以決定一頁顯示幾個項目，需要知道這個資訊以及對應這個資訊下共有幾個頁面，故這裡也需要兩個 regex 來處理。最後則是要組成購書金額明細頁面的 URL，這個似乎每次改版變動都很大，直接在第 x 頁的連結上按複製網址來研究即可。

有內鬼，停止交易

沒想到老婆大人居然沒聽過這句臺詞，看來我們有代溝？

前天主管突然告知某部門想要和我跟我同事聊聊，看看是否有機會過去幫忙，我們都覺得聊聊也不錯，便在今天跟該部門主管聊了一下。

初步感覺要做的事還蠻有趣的，應該也是我擅長的，便表達有意願過去試試，當然前期免不了要多學一些新的東西，但與純數學比起來確實有趣多了，最主要還是做的事對公司有幫助，畢竟我還蠻喜歡這家公司，我想該主管一定覺得奇怪幹嘛問了好幾次對公司有沒有幫助XD

總之，目前就看該部門最後意願，上不上都不錯。

假設最後過去，手上想做的事要做些安排才行。

簡易管委會財報系統原本預期花 2 天簡單學 Vue.js，3 天時間開發，再留 2 天跑一下 use case，確認這樣的設計對委員們有幫助，畢竟做事還是要有意義，去的話這些事可能就要分段進行，最糟情況在過年放假時完成所有事項？

3D scanner 雖然已經決定買 Pop3，之前問了兩家代理商都沒有現貨，還是改採網路下單排預購？

還是想讓 KOReader 離開後藍牙可以正常，這個應該只能趁假日零碎時間來應用，就讓水到自然渠成吧。

假設最後沒過去，就照之前順序完成相關事項並順便放大假，但中間還想多完成一個 Kobo EInkBro，畢竟 GCP VM 都還沒砍，每月一直燒錢也不是辦法（目前來到歷史新高 NT $170 / per month）XD

退職所得

昨天跟一個前同事吃午餐，剛好他最近也開獎了，不過因為他呆在外商，故領了一筆很不錯的資遣費，跟他聊天的過程中知道一些很多我沒注意過的事，順便記錄一下長知識。

《所得稅法》第 14 條，第 1 項中敘述了個人綜合所得稅中的十類所得，其中第九類為退職所得，法條如下：

退職所得：凡個人領取之退休金、資遣費、退職金、離職金、終身俸、非屬保險給付之養老金及依勞工退休金條例規定辦理年金保險之保險給付等所得。但個人歷年自薪資收入中自行繳付之儲金或依勞工退休金條例規定提繳之年金保險費，於提繳年度已計入薪資收入課稅部分及其孳息，不在此限：

一、一次領取者，其所得額之計算方式如下：

（一）一次領取總額在十五萬元乘以退職服務年資之金額以下者，所得額為零。

（二）超過十五萬元乘以退職服務年資之金額，未達三十萬元乘以退職服務年資之金額部分，以其半數為所得額。

（三）超過三十萬元乘以退職服務年資之金額部分，全數為所得額。

退職服務年資之尾數未滿六個月者，以半年計；滿六個月者，以一年計。

二、分期領取者，以全年領取總額，減除六十五萬元後之餘額為所得額。

三、兼領一次退職所得及分期退職所得者，前二款規定可減除之金額，應依其領取一次及分期退職所得之比例分別計算之。

從法條可得知，資遣費不屬於薪資所得而是退職所得，故不是全額都需要併入所得總額繳稅，另外上述的十五萬不是一個定額，需看當年度財政部公告，以 112 年來說，此金額為 188,000 元。

當我們有領到所謂的退職所得扣繳憑單，這金額已是扣除免稅額後的，故不能再重覆以上面規則計算一次，這是很多人的誤區。

因為同事講到關鍵字 18 萬，害我一直想到全年所得不到 18 萬的人不用繳稅（沒有薪資所得，扣除免稅額等後大概就為 0，這個 case 應該也是很久以前的數字吧），這個金額也是變動的，故不一定是 18 萬。

另外，健保需依附在配偶那，不能再像單身一樣去區公所。

交接專案待釐清事項

Go module

go.mod 裡面的 module 是 local path，故重拉一個新的 git 下來時，需執行 go mod download、go get local module\pkg\xxxxx 等、go get local module\cmd，三年前開發時的做法是否是對的？

Node.js npm mongodb

N 年前開發時使用的是 3.1.6 版本，package.json 寫法是 "^3.1.6"，此寫法表示是相容該指定版本，此時此刻在我電腦重新拉 git，npm 會安裝 3.7.4 版本，如果執行自動測試，connect MongoDB 便會有問題，錯誤是無法連接，在 package.json 拿掉 ^，再 npm install 一次，強制使用 3.1.6 版本就正常，應該是跟 driver 安全政策有關，待驗證。

更正：不是跟安全性政策有關，單純只是從 Node.js 18 開始，解析 DNS 時，某些環境會導致 localhost 被解析為 IPv6 address，請詳此處。 

其實錯誤訊息也可以看出被解析為 IPv6 address，昨天忙著寫文件沒有時間去解決問題，今天還是順利的找到原因了XD

有時候一個問題要不要修複，其實考量的點很多，絕對不是選擇一條最快解決的路就好。以我例子來說，這是個內部專案不會對外，故沒有安全性問題；同事依照我的文件是否可以正常執行沒有副作用？Yes（當然有極小可能性會有問題，畢竟其他 modules 不一定跟我當初版本一樣，就跟這個問題的發生原因一樣）。

故我昨天強制指定版本就是最快也是對我最方便的解決方式，當然沒有時間順便修掉 warning 也是有點小遺憾，就看之後時間允不允許囉？

2023/11/21 下午更新

早上還不覺得怎樣？下午越想越不對勁！如果說是因為 Node.js 實作的改變，mongodb 本身應該也有用到一些 Node.js 相關呼叫，否則無法解釋指定 3.1.6 版本就沒有問題的事實？

總之，這個問題解法真多，還有不改 code 直接帶參數給 node.exe 的解法！

2023/12/03 更新

版本真的是一個大問題！尤其專案是 N 年前開發的！陸續在其他交接專案都有遇到不能執行的問題，不論是我離職同事寫的 Server 還是我的 Device simulator，還好 N 年前開發時的資料夾還沒砍掉，順利找到當初使用的版本，只是虛驚一場。

這告訴我們一件事，package.json 版本千萬不要使用星號？

七夕生蛋

昨天是個特別的日子，本想趁放假把 Daily Money issue 搞定，沒想到已提早做完，本來打算去 HOLA 幫怕冷的老婆換件冬被，開車途中一時興起就問老婆是否要去淡水走走XD

全台灣的人可能星期五下午都不用上班？沿途有點小塞，一到捷運站也是人山人海，光停車左轉可能就等了快 7 或 8 個號誌有。

上完廁所慢慢散步到漁人碼頭，曬著溫暖的陽光就是舒服，除了陽光斜射無法好好欣賞美景。本想走到福容飯店坐公車回來，到輕軌站上完廁所後就臨時起意搭輕軌，反正我們兩個也都沒搭過XD

沒料到這是個錯誤的決定，速度慢不說，椅子也不好坐，還好路經我母校時，看到一個是我菜的學妹？馬上指給老婆看，沒辦法誰叫我就是馬尾控！

老婆一直說反方向不會塞車，結果也是一路塞到八里上橋段才開始順暢，到了下州美又開始車多，不過還是在晚上 7 點前回到台北，沿路都在聽小老婆的歌，聽到《不想有遺憾》時，我倆對一句歌詞不太確定，老婆查了一下，歌詞居然是「七夕聖誕」，難怪我會一直聽到「七夕生蛋」，也讓老婆趁機虧了幾句小老婆咬字不清，女生的嫉妒心真是可怕呀XD

可能是這樣的緣故，點餐時也不幫我選擇不要芹菜，還一直說我沒有說，真是無言以對…

吃飽後，順便去天地會繳了一下規費，這是這一年買書中第一次沒有半本跟數學有關，想想就是開心XD

慢慢喜歡上小老婆的歌是因為數學，一旦生活中不再有數學，會不會也會跟小老婆漸行漸遠呢？

挑了一本 Vue.js 的書，那是因為想到 OpenBMC Web-UI 也是用 Vue.js，我在開發簡易社區財報查詢系統時如果也是用 Vue.js，就可以一魚二吃了！

回家洗澡才突然想到，UI 三大框架都標榜著 Data Binding 的方便性，但如果沒有後台的幫忙，我能用在像是 Github Page 這樣的環境嗎？會不會很多功能都無法執行？不過只要是純 Javascript 的東西又不需要往後台打 API，我認為應該是沒問題才對？又或者真的需要打 API，但我不要真的發 API 出去而是在本機 query JSON or SQLite db，應該也是可以無痛接軌才對？比較麻煩的應該是 local storage 的安全存取機制才對？

外牆蜘蛛人詢價備忘

2023/10/11 聯絡到廠商

2023/10/12 補上完整案場資料

2023/11/04 現場場勘

2023/11/13 拿到報價

目前等廠商回覆問題，報價單有點簡陋，如果 2023/11/30 廠商沒有回應，再傳訊一次，再不行便匯款給廠商當車馬費，買賣不成仁義在。

坦白說價錢比我想的便宜多了，只是不太喜歡台灣廠商的報價方式，什麼都是簡單一式帶過，細節都沒寫。

2023/11/23 更新

廠商已在今天回覆，內容看起來沒什麼大問題，唯一有問題的就是我還是覺得危險，希望一天多給一千請他找人來顧繩索，畢竟安全第一，另外要記得買個伴手禮跟樓上打聲招呼。

2023/12/01 更新

前天廠商回覆並希望趁今天下雨清洗外牆，時間有點倉卒，昨天下班趕快到星巴克買個簡單小伴手禮，但只來得及跟樓上樓下知會一聲，直到今天才跟一樓鄰居打好招呼。

第一次嘗試此工法還是有點擔心安全，晚上都沒睡好，還好廠商也很順利的清洗完畢，除了我必須要從自己家拉水管到一樓導致我很麻煩外，其他都算順暢。沒辦法，願意拿出兩千塊支付公共水電沒人理我，社區就少收到額外收入囉。不只這樣，昨天本還想找水電幫忙改造水龍頭，無奈不知是中午休息時間還是跟接電話的人不對盤，最後因為時間不能配合作罷。

昨晚下班前 google 了一下，原來自己 DIY 就可以，因為這是個很普遍的需求，只要金額 NT $38，安裝不用 2 分鐘。不用時記得換回來，少了原本的起泡器（起波器），同樣的水量一開啟都濺灑到浴盆外了。

另外，這種都是內外牙通用，內牙指的是螺牙在內部，外牙就是在外部，如果是外牙，拆掉原本的白色套件即可。

今天前置作業大概就要一個小時多，真正沖洗有兩個房間的一面牆，高度一層樓半大概費時 30 分鐘，拍張照記錄一下。

2023/12/11 更新

今天天氣狀況不錯再加上廠商前晚才通知要施工，故就相信廠商的專業不請假了。

總共漆三道透明漆，不太清楚做完時是幾點？

隔幾天後從正面看的樣子。

又是油漆工演算法發威的一日

嚴格來說，約耳當初提到油漆工演算法時，指的是原本應該是線性成長的時間，因為程式哪邊做了錯誤的處理而導致不合理的時間增加！

但我總覺得線性成長就很嚴重了XD

最近又遇到兩件線性成長的事了，一個是統計了 9 年多社區月報表的 Excel 檔案存檔開始超過 5 秒了（只有 6 年半時都還沒那麼誇張）；另一個則是我的 Daily Money Android 記帳軟體目前已經不能用了（嚴格來說是點信用卡明細時，無法在 Android 預設的回應時間內跑完）。

第一件事暫時可以不管，反正之後應該會開發簡易系統解決。

第二件事對我來說就有點嚴重了，到現在都還不能對帳！

昨天嘗試清空資料後再重新 import CSV 備份檔，看來並不如我想像的可以重整 SQLite db？想想也是，SQLite 開發作者也是個大神，怎麼可能會有問題！

記得不知道那個版本的 Android 開始，SQLite db 好像有加密了，不能像以前一樣，拿回電腦下指令查詢？這點還要再確認一次（確認我用舊 SDK 版本重 build 的 apk，db 還是可以打開） 。

整個問題的本質就是：雖然 Daily Money 是一個很優秀的開源記帳軟體，但他並沒有會計年度結帳概念，故針對資產負債科目餘額都是從初始值計算每筆記錄得來。

在不換軟體的情況下，目前應該有兩個解法：

01. 針對我的信用卡科目建 index。

02. 在資產負債表明細查詢功能中限定只查過去一年。

但我目前就是沒時間改 code 呀…

2023/11/15 更新

晚上再忙也要抽出時間改 code，能少一件事就是一件事。剛好 Daily Money 也是舊 Android 專案，這個打通了，我的某一個交接項目應該也會沒問題。

可能自己不是專門寫 Android App 的，新的 Android Studio 雖然可以順利匯入舊專案，但一直無法成功編譯，錯誤訊息也看不出所以然？還是睡覺比較實在XD

今早熊熊想到，唯一的一顆外接備份硬碟也許會有舊環境，吃完早餐馬上打開電腦尋找，果然舊愛還是最美！

順便記錄一下我最後修改的版本號碼，因為舊環境居然還不是最新的？

Daily Money - 20140920

中午吃完飯散步時想了一下，Android Studio 這個問題還是得解決，不然我其中一個交接項目鐵定會出問題，雖然不是我寫的，但我印象用了一堆第三方 jar 檔，如果這麼簡單的 Daily Money 都無法編譯，我無法想像那個交接項目會怎樣？

在搞定問題前，趁休息時間還沒結束先快速 review Daily Money 架構，發現我對 code 已經沒有印象，沒辦法了，只好從 logcat 下手，反正我只是要讓我可以繼續對帳，不需要花太多時間在這上面。

E ActivityManager: ANR in com.bottleworks.dailymoney (com.bottleworks.dailymoney/.ui.AccountDetailListActivity)

E ActivityManager: PID: 26594

E ActivityManager: Reason: Input dispatching timed out (90e066a com.bottleworks.dailymoney/com.bottleworks.dailymoney.ui.AccountDetailListActivity (server) is not responding. Waited 5005ms for FocusEvent(hasFocus=true))

E ActivityManager: Parent: com.bottleworks.dailymoney/.ui.AccountDetailListActivity

E ActivityManager: ErrorId: 0cf06345-57c2-401b-a26b-17a7bf27a91b

E ActivityManager: Frozen: false

E ActivityManager: Load: 0.06 / 0.64 / 0.5

E ActivityManager: ----- Output from /proc/pressure/memory -----

E ActivityManager: some avg10=0.09 avg60=0.66 avg300=2.13 total=160417487

E ActivityManager: full avg10=0.02 avg60=0.21 avg300=0.64 total=66706336

E ActivityManager: ----- End output from /proc/pressure/memory -----

原來出問題的是 AccountDetailListActivity 這個 view，我從這裡往回推找地方改 startDay 即可，晚上回家再繼續吧…

凡事還是要做最壞打算，如果花一個下午還是不能解決 Android Studio 問題，我決定把我的舊 Eclipse 環境打包帶來公司，印象中我剛來公司碰這個交接專案時用的 Eclipse 比較新，但我認為不會有太大問題，再怎樣問題一定是比用 Android Studio 來得少，就多花半天時間試試吧，今天原本預計要準備開發環境的另一個交接項目就先 delay 半天囉。

折騰了一下午，目前只能順利編譯，但執行時還是會出現權限錯誤，大概知道是因為 Android 權限政策改變，故需要在 runtime 時賦予，這就不得不改 code 了。

撇開這個不提，下午也是需要做一些修改才能 build 出 apk，大概記錄一下！

01. Gradle 裡面 xxx.pom 找不到無法下載，要多加一個 google() 才可以。

02. Gradle 裡面設定版本用 33，不知為啥 34 不行。

03. Gradle compile 選項需改成 implementation，另外，Daily Money 架構如下：

Daily Money                  ui, library, third-library (lib\xxx.jar)

Daily Money - surface   empty main ?

雖然在 surface 裡面的設定檔有 implementation Daily Money，但在 import third-party Activity 時會報錯，如果複製一份 xxx.jar 並在 Daily Money - surface gradle 再 implementation 一次，會有類似 C 語言重覆定義錯誤，後來是在 surface 裡改用 implementation (..\DailyMoney\lib\xxx.jar)。

04. activity 宣告要全名，不能類似 .ui.DetailActivity。

以上都只是概念，我並沒有記下真正名字細節，但意思到了就好。

晚上回家試了一下 Eclipse，雖然可以 build apk，但會說版本太低無法安裝，可能跟我更新了 adb 有關，因為不更新 deivce 會一直顯示 offline，晚點再把備份的 SDK 覆蓋回來，看是否還會 offline？

這也不行，那也不行，這個 gap 還真有點寬，原本就是寫 Android App 的人，因為會一直隨著 Android 更新版本遇到問題，故不太會像我一樣有那樣寬的海溝要過！

這也是為什麼 daily-build 很重要，且要有自動測試的機制。

過了一陣子後，在外包版看到有人說這確實是大工程。

2023/11/16 更新

確定 device offline 是因為 adb 版本過舊（手機 Android 13），目前用了一個 workaround 方式來解決：

01. 保留舊環境及 Android SDK 不動好 build apk。

02. 使用 new adb tool 安裝 apk 及 logcat。

03. 從資產負債表過來的科目明細起始日參數從 null 改成年度起始日。

此次修改過後，行為如下，原本損益表來的會有值，資產負債表來的被我改過後第 2 次也會有值，應該跟值沒被 cleanup 清空有關，這個行為剛好也是我要的，避免重新計算。

資產負債表及損益表都是使用 BalanceActivity，按下任一科目則是進入 AccountDetailListActivity，桌面的日週月年明細表則是 DetailListActivity。

可以使用 logcat daily-money:D *:S 只看 tag 是 daily-money 的訊息。

目前最新版本 Daily Money - 20231116，會計分錄共有 20,179 筆，資料期間為 2007/01/01 ~ 2023/11/16，以我常用信用卡為例，11 個月多一點大概有快 600 筆 Entry。

截個圖避免以後忘記。

終於可以對帳了，開心。

TODO: 

01. Remove tag debug msg, it is an object, no debug meaning - 不做事，target 很特別，有時會是上層科目名稱而不是 object，先知道就好。

02. Update code to git - Done.

dm_det table（最早資料從 2007/01/01 開始，應該是之前手動結帳過一次或是從 Palm PMT 軟體移植過來的已不可考？另外，貌似 dt_ 精度只記錄到天？）

如何手動結帳：找某一天當基準日開啟資產負債表，抄下當時科目餘額填上 accout 初始值，並用 PC 任何 SQLite tool 下 SQL 砍掉含基準日已前的所有交易，再將 db 放回手機；另外一個方法則是先 Export CSV，將查到的餘額填上 account CSV 初始值欄位，並將 entry CSV 砍掉基準日之前的列，最後再重新 Import 即可。

SQL query

快速找 code 技巧：不知道哪個畫面是哪個 Activity 就使用 logcat，注意 initial 及 cleanup 就知道是哪個 Activity。

才下眉頭，卻上心頭

昨天在回父母家前終於把上上星期打好的管委會舊資料電子檔再核對一次，只有兩年半的資料也花了我了六日不少時間，雖說在打舊資料時就會核對一次，也趁使用 Python tool 填上分析總表時自動重新計算一下每月活存餘額作檢查，但沒有再核對一次，心裡總覺得不踏實，畢竟資料正確性才是第一重要， 目前總算是搞定了一件事。

因為一直把這件事放在心上，導致其他想到的事情都只能先用頭腦當暫存區，再加上本週已經開獎，因為沒時間原本已經想放棄了，後來還是覺得有點可惜，記錄一下自己的思路避免以後再次回想。

01. 退出 KOReader 後，bluetooth 無法使用問題。

我能理解開發團隊為什麼要 kill bluetoothd，一來可以省電，二來希望回去 Kobo Nickel 時可以讓 bluetooth 正常，無奈這招行不通。

我想以那團隊的能力 review chip spec 功力一定是不在話下，連他們都沒想到的事代表真的不可行嗎，還是只是純粹對藍牙翻頁器沒有興趣？畢竟會看電子書的人分為兩派，一派很喜歡用翻頁器，另一派卻對翻頁器嗤之以鼻XD

首先，需先釐清問題所在，假設是硬體問題，想辦法 reset chip 再 init 一次應該就可以了？

如果只是 bluetooth status 不同，導致 Nickel 認為有問題而不使用藍牙，是否可以去 /etc/rule.d 看開機時對藍牙做了什麼事，只要再呼叫一次該 script 即可？

02. 點雲點數的差異是如何而來。

雖然還未購買 3D scanner，但我內心總隱隱覺得我的土砲結構光系統跟幾萬塊的消費型機種應該沒有到 100 倍的差距？

回想一下，點雲起手式是什麼，不就是從 pixel cord decode projector cord，故 1 個 pixel 只要是 valid，就會作三角測量產生 1 點才對。

換句話說，1920 x 1080 的 camera resolution，假設 valid mask 是 60%，則一次的總點數就是 1920 x 1080 x 0.6 = 1,244,160。

KEYENCE 這樣厲害的廠商一定是重覆拍照拼接或是做額外插值才能得到那麼豐富的點雲資訊？（印象中 33 mm size chip 似乎就拍了 10 幾張？用有 1000 多顆錫球那面來看，點雲點數約為 551 萬）

以後如果請廠商 demo 還是得先有基礎知識才不會霧裡看花，什麼重點都沒看到。

將來的事將來再說

鄭伊健和張柏芝主演的《蜀山傳》中，徒弟問了師父一個問題，師父只是淡淡的回了一句：將來的事將來再說…

話雖如此，但這將來也是有點久，即使我上星期五就知道答案，但拖到昨天才有非正式通知，也害我多看了沒用的數學 4 天？

這 1Q 的數學深不得我心，可能跟我本來的屬性不合，前 3Q 的至少是偏應用，還可以用學到的知識來土砲結構光系統，但這 1Q 的是純演算法跟數學，又不是要發頂會論文，坦白說我也還未入流，只是在浪費生命罷了。

站在管理的角度來說，這樣很不可取，浪費公司跟我的時間在一個沒有未來的學習，拿去多學一些對公司有用的不是很好，雖說也跟主管稍微提到這樣不行，無奈主管對我很好，我也只能欣然接受。

在這家公司 9 年多了，我對公司只有滿滿的感激，沒賺錢還有幾個月的年中加年終可拿，補班也不用我們上班，年底還有聖誕節可放！

衷心希望公司可以再起一波，只可惜以後沒有益生菌可購買了XD

------------------

上星期五就已經想好接下來要做什麼了！先簡短記錄，晚點再補細節。

01. 開發社區簡易財報查詢系統。

這一個多月假日除了土砲結構光系統外，有空都在補歷年財報電子檔資料，補到現在也才補了 9 年，算是一件吃力不討好的事，重點是也沒有人要求！責任心還是不要那麼重比較好。

超過 7 年的紙本資料都發霉了，就回朔到 103 年 6 月就好，勢不可去盡…

犧牲了自己假日時間，總算也是有點收穫，追回了一筆兩萬多塊的重覆付款，只能說這個永大很爛！

坦白說開發這個系統對我也沒什麼幫助，過去有建檔的資料都已經在我腦袋中，就當替 10 年後的我買個保險，以免 10 年後還住這個社區XD

這個簡易系統有 3 個方向可實作，分別是 UI 三大框架選一個，Excel VBA，Google Sheet Action Script。

UI 三大框架就是要配 Github Page，資料也不知會不會有隱私問題，但我認為漏水或修繕本就是應揭露事項，我是不覺得有任何問題，本人也不會笨到去揭露社區名稱，好吧，我承認我住新竹XD

VBA 或是 Action Sheet 好處是跟著檔案走，比較不用顧慮 UI 設計，但以目前已經有 120 多個 sheet 的 Excel 檔案來說，存檔都需要好幾秒，長久下去不是辦法，我猜跟 Excel 檔案本質就是一堆 XML 的組成有關，故效能會隨資料越多而越差，應該是線性成長？去去去，油漆工演算法不要來搗亂XD

目前在補舊資料時，是透過 Python 將新增資料填上分析總表以及各別科目 sheet，坦白說已經很好用了，比第一次從頭到尾建電子檔節省了不少人力，當然每月新增的資料還是免不了人力介入。

我們社區就是沒錢，難怪沒人主動要當管理委員？目前活存來到接近歷史新低。編號 13 的那筆資料剛好也是某次的調漲管理費用起始點，希望能像那次一樣，可以逐漸往上成長還能夠有餘額轉定存！

02. 購買消費性 3D 掃瞄儀來確定土砲結構光系統差距。

原本想購買 REVOPOINT POP3，但在 Reddit 看到前一代的評論，只能說慘不忍睹。

另外在同討論串看到推薦 EinScan-SE 這台，但價差多了 3 萬，總共要 5 萬塊，確實是有點買不下手。在 YouTube 看到一個影片，這台搭配轉盤，一個面速力達母寬度的小物件，看起來會轉 8 次，轉一次約會有 17,000 左右的點，感覺我的土砲結構光系統跟他並沒有到 100 倍以上的差距？

還是多看一些 YouTube 的影片再做決定？

03. Review 世界未來趨勢。

進入賺錢的產業或公司才是最重要的！你會什麼程式語言根本不是重點，結論還是鞏固基礎能力就好，正所謂萬變不離其宗。

退一步則是找自己有興趣的，有興趣才能持久。

千萬別為了工作而工作！

04. 多陪爸爸媽媽。

把買的那幾本相關書看一看。

05. Kobo（找到之前找我面試的 email）、Readmoo、HyRead 選一家投履歷。

一直有印象 Kobo 之前有找我面試？但遍尋 Gmail 卻一無所獲？目前只看到蝦皮的 email？

Magic symbol - _ZN6google15ErrnoLogMessageC1EPKciimMNS_10LogMessageEFvvE

同事最近在搞 Vitis-AI 的板子，過程中遇到一些問題，花了一天多的時間幫忙釐清並解決編譯問題，還是稍微記錄一下好了XD

這個 magic string 就是所謂的 name mangling，請看這裡。

環境介紹：同事沒有使用 PetaLinux 而是使用 Ubuntu 22.04。

同事在執行下面這支 script 時發生問題，一開始就跑不起來，看了 code 後發現，並沒有人去呼叫 main function，故需要改成先帶 main 再帶 target board 型號的方式來執行此 script。（後來才發現 Xilinx 文件是錯的，4.3.2 有錯，但 4.3 有稍微提到 run_all_target.sh 這支 script，裡面就可以看到正確呼叫 run_all_cifar10_target.sh 的參數傳法）

Vitis-AI-Tutorials/Tutorials/RESNET18/files/target/run_all_cifar10_target.sh

再來還是跟執行 run_all_cifar10_target.sh 有關的錯誤。

01.  missing symbol - _ZN6google15ErrnoLogMessageC1EPKciimMNS_10LogMessageEFvvE

這個名稱是 gcc 在編譯函數等 object 時所定義的 symbol name，gcc 是 follow 這個文件，我們也可以把這串名字丟到此網站，我們就可以看到此 symbol 的原型宣告如下：

google::ErrnoLogMessage::ErrnoLogMessage(char const*, int, int, unsigned long, void (google::LogMessage::*)())

同事的問題就是在安裝的 glog 中找不到同樣名稱的函數，嚴格說起來是差在第 4 個參數，我們跟這串文字差了一個 m，而這個 m 就表示參數是 unsigned long。

同事還蠻幸運的，在降版本到第二個版本後，就順利編譯出有一樣 symbol 的 so 檔。

02. missing symbol - xclIPSetReadRange

這個問題跟上面類似，也是版本相關的 issue，後來在 review XRT 版本後，確定某些版本以前的 code 確實缺少了這個函數（XRT/src/runtime_src/core/pcie/linux/shim.cpp），後來便決定使用 202220.2.14.354。

底下是自己編譯此版本會遇到的問題。

首先在 sudo <XRT>/src/runtime_src/tools/scripts/xrtdeps.sh 時，會看到類似沒有安裝 gcc 8 的訊息，因為環境已經有 gcc 11 了。

接著執行 build.sh 發現很快就結束了，原因是 script 中，gcc 版本是 hard code 寫死，直接改成對應的版本即可，接下來就是一連串的 sudo apt-get install 地獄XD

此 script 會先執行 configure 相關工作，反正遇到什麼錯誤就 google 一下，安裝對應的 xxx-dev 版本即可，印象中有 4 ~ 5 個要裝。

最麻煩的是在 runtime_src/xdp/CMakeLists.txt:427 會報找不到 xdp_hw_emu_device_offload_plugin 錯誤，但這個東西如果我沒搞錯應該是編譯時才會編譯，懷疑是 CMakeLists.txt 沒寫好，可能跟相容 cross-compile 有關？

想了一下，直接註解 427 及 428 行即可。

接下來是一連串的 build error，最糟糕的都是直到編譯某支檔案時才會報找不到 header file 的錯誤，此時也只能一個一個 apt-get 安裝，印象編譯到 40 幾趴還會有錯誤，大概也是有 4 ~ 5 個要安裝，之後便可以順利編譯出 Debug 和 Release 版本了。

接著使用 objdump -T xxx_core.so | grep xclIPSetReadRange 確認一下，這次就可以順利看到 symbol。

由於 Release 版本還在編譯，簡單使用 export LD_LIBRARY_PATH=/XXX/Debug 來讓執行時可以找到 xxx_core.so 的 xclIPSetReadRange symbol 來驗證是否有順利解決問題。

花了一天多幫同事搞定這個問題，最後還是沒能在 target board 跑出想要的結果，但這又是另一個故事了XD

2023/11/24 更新

為了寫技術文件，從零亂的計算紙中找到蛛絲馬跡，凡走過必留下痕跡。

fix configure error

sudo apt-get install libdrm-dev

sudo apt-get install ocl-icd-opencl-dev

sudo apt-get install libncurses5-dev

sudo apt-get install libssl-dev

sudo apt-get install rapidjson-dev

-------------

CMake Error at runtime_src/xdp/CMakeLists.txt:427 (add_dependencies):

  The dependency target "xrt_hwemu" of target

  "xdp_hw_emu_device_offload_plugin" does not exist.

https://github.com/Xilinx/XRT/issues/6942

fix it

comment runtime_src/xdp/CMakeLists.txt line427, line428

-------------------------------------------------------------------

fix build error

sudo apt-get install uuid-dev

sudo apt-get install ocl-icd-dev

sudo apt-get install libcurl-dev

sudo apt-get install libudev-dev