Gunbuster 觀後感

 Gunbuster 是 1988 年的老動畫，之所以認識這部動畫，是因為追動漫鋼琴時偶然追到了 Pianeet 的 Gunbuster Fantasy 組曲。因為曲子好聽去追原動畫 XD


這部動漫的監督是新世紀福音戰士的庵野秀明。本作的本意是彌補製作「王立宇宙軍」造成的巨大虧損。動畫刻意集合了各種「宅」要素力求打開市場，結果「王立宇宙軍」沒紅，這部為了彌補虧損而做的作品反而大紅了。

前三集是真實系開局，天真活潑 or 傻白甜女主經歷艱辛登上宇宙。後來經過各種挫折，特別是在戰場上無能導致坑死自己初戀後，逐漸成長為獨當一面的 Gunbuster 駕駛員。

本作對人物和感情刻劃非常深刻，因為反覆在接近光速的情形下執行任務，與地球上的朋友無可避免出現「時間差」。姊姊與教練的悲戀。為了挽救人類，兩人選擇自我犧牲選擇進入 Buster Machine 3 號，容格乘著量產機陪同赴死被勸回，歷經萬年漂流返回地球，地球亮出「歡迎回家」伴隨著音樂全劇落幕。聲優真摯的演技和悲壯的音樂更把整部作品盤活。

神作。

全文連結

成人鋼琴班愉快學琴中， 老師教新曲子，趁這首還沒忘之前留影紀念。這已經是錯音、漏音、糊掉最少的版本。

從「自我檢查」的角度來說，錄音錄影其實比單純錄音就好，搭配影像還可以回憶當時用力的情形。

總而言之，不漏音好難，控制手速避免不自主飆車好難。彈到後面手軟掉變成不曉得什麼東西 XD

全文連結

李宏毅老師 youtube 深度學習課程：attention、transformer、BERT

【機器學習2021】Transformer (上)
【機器學習2021】Transformer (下)
【機器學習2021】自注意力機制 (Self-attention) (上)
【機器學習2021】自注意力機制 (Self-attention) (下)
【機器學習2021】自督導式學習 (Self-supervised Learning) (二) – BERT簡介
【機器學習2021】自督導式學習 (Self-supervised Learning) (三) – BERT的奇聞軼事 

為了研究 BERT 能否解決 negation detection 決定線上進修，剛好找到李宏毅老師的課。

之前上過吳恩達老師在 deeplearning.ai 的深度學習課程。兩位老師的課都非常的深入淺出，吳老師的課有作業，李老師的課程內容比較新，技術細節講的比較深細。

看了幾堂 attention、transformer 和 BERT 的簡介有相見恨晚的感覺。 暫時沒時間寫濃縮筆記，先發文佔樓，以後想更再更吧。這個清單還沒放上李老師對 BERT variant 的簡介，有看再放上來。

全文連結

「超速學習」閱讀心得

 

一直對「如何學習」很有興趣，這本讀完感覺不錯，決定用它寫心得，寫心得的同時也是運用其中的技巧，鞏固內化書本上的知識，也方便未來的自己提取技巧不用整本重讀。

這本書重要概念大概如下：

後設學習

確定「為什麼、做什麼、及怎麼做」，「怎麼做」可以切分成「概念、事實、程序」。後設學習可以佔整體計畫的 10% 時間。後設學習可避免學習毫無目的性，在無限的知識中沒有效率的「漫遊」

專心致志

講拖延症、專心的重要性和專心的技巧。

實質上我認為最好的技巧，也是書本沒有講的，是每天花時間冥想。冥想可以實際上改造大腦。變得可以忍受工作和學習中的難受、沉悶和從根本上控制住分心（掉舉）。

直截了當

用「最短路徑」去達成學習目標，例如學語言，就直接去需要該語言的生活環境，學工作技能就從做中學。

反覆操練

其實覺得這個名字不完整，因為書中的例子還包含很多「分而治之」（divide and conquer）的技巧，例如學音樂把譜分段，並針對不會的困難段落反覆練習。

提取記憶

用測驗、回想...來鞏固記憶，不是學完就算了。

意見回饋

我想這是自學者最欠缺的。其實有人潑冷水比自己「十年磨一劍」好的多。

我學專業技能之所以能有進度，很大是因為學長姐，臨床同仁甚至病人會給「回饋」。做了錯誤的判斷就會從回饋得到「重拳」，就會一直進步。

但「重拳」太重也可能把人擊垮，可能必須在「不痛不癢的回饋」和「太重的重拳」中間拿一個度。

保留記憶

書中提出了幾種技巧來克服「遺忘曲線」的問題。淺見比較有用的方法是「過度學習：超越完美的練習」和「記憶法」。考專科的時候不自覺的用了這些技巧。

培養直覺

覺得翻譯為「技能直覺化」比較好。將學到的技能內化為直覺。

個人經驗上這是個水磨功夫，只有不斷反覆熟悉技能、接受回饋，試著簡化提取要點才能題取出技能的「神髓」才能內化為直覺。

例如當年自學軟體重構的相關知識，書都會教「何時該重構」，但實質上我不是用背的，而是很多次栽在充滿壞味道上的坑以後，對坑的感知因為大量經驗內化形成直覺，跟本不用背，也不會忘記，甚至書本講的「何時該重構」也只是印證了我的經驗而已。

勇於實驗

書中提到各種實驗技巧，在不會太痛苦的前提下，擴展現有的技能樹使之更全面，跨出舒適圈。


看完這本書以後，覺得最無腦的技能入門方式其實是去上針對性、有提供測驗的線上課。線上課除了最後兩步（培養直覺、勇於實驗）外幾乎都涉獵到了。至於後兩者也只能技能稍微入門後再自己反覆錘鍊、內化和擴展了。

全文連結

Linux 監控 CPU 使用率腳本

Linode 寄信提示 CPU 異常使用率，超過 90% 使用率，一次好幾小時。根據網路拼湊、修改出腳本來定期監控 CPU 使用率。原則上五分鐘監控一次，使用率超過 70% 觸發 log，log 寫在監控腳本同目錄下。

cpuuse=$(cat /proc/loadavg | awk '{print $3}'|cut -f 1 -d ".")
if [ "$cpuuse" -ge 70 ]; then
MESSAGE=$(date +%s).log
  echo "CPU current usage is: $cpuuse%" >> $MESSAGE
  echo "" >> $MESSAGE
  echo "+------------------------------------------------------------------+" >> $MESSAGE
  echo "Top 20 processes which consuming high CPU" >> $MESSAGE
  echo "+------------------------------------------------------------------+" >> $MESSAGE
  echo "$(top -bn1 | head -20)" >> $MESSAGE
  echo "" >> $MESSAGE
  echo "+------------------------------------------------------------------+" >> $MESSAGE
  echo "Top 10 Processes which consuming high CPU using the ps command" >> $MESSAGE
  echo "+------------------------------------------------------------------+" >> $MESSAGE
  echo "$(ps -eo pcpu,pid,user,args | sort -k 1 -r | head -10)" >> $MESSAGE

else
  echo "CPU usage OK"
fi

腳本存好，chmod +x 以後下 crontab

crontab -e
*/10 * * * * /bin/bash /opt/scripts/cpu-alert.sh

以目前使用者身份執行腳本一次（不一定跟 cron 同使用者！），確認腳本沒問題

crontab -l | grep -v '^#' | cut -f 6- -d ' ' | while read CMD; do eval $CMD; done

全文連結

QNAP docker 建置 nginx reverse proxy

問題背景：我開發的關鍵服務建置在公司內虛擬機（VM），虛擬機放實體 NAS（ QNAP）。基於未知原因，公司內某些網段的電腦無法直連 VM，tracert 顯示路由到 default gateway 就掉。

Bug 還在協商溝通，暫時解不掉，只能先想辦法繞過。因關鍵服務大多利用 HTTP，所以決定用 nginx 建立 reverse proxy 解決。

整件事最大困難：QNAP 系統高度自製，很多資料找不到。很多工具沒有裝（例如 apt-get）。

本來考慮用 QNAP 軟體市集找 nginx，失敗，改用 container station 上。用 nginx container，以 docker volume 覆蓋設定檔。

然後發現 container station GUI 並不友好。例如 exposed port、volume 等參數每次建立 container 都要重新指定，非常麻煩。docker volume 還只能指定一整個目錄，無法只覆蓋目錄下的單一檔案，所以萬一 config 檔同目錄還有其他檔案就不好處理。

後來解法是 ssh，command line 用 docker 指令就好。container station 的 GUI 只是套殼，其實沒必要用。docker 指令操作結果也會反映在 container station 的介面上。File Station 看到的 Public 資料夾在 /share/Public。文字編輯可以用 Text Editor 就不必用沒調整過的 vi，還支援瀏覽器貼上！

QNAP 上 docker 操作 nginx 我用的指令如下：

docker run --rm -p 9080:9080 -p 8888:8888 -p 9090:9090 --name nginx -v ${PWD}/minimal.conf:/etc/nginx/nginx.conf:ro -d nginx

nginx.conf 設定檔長這樣

events {}

http {
    client_max_body_size 0;

    server {
        listen       9080;
        server_name  <QNAP 內網 IP>:9080;
	proxy_set_header Host <QNAP 內網 IP>:9080;

        location / {
            proxy_pass   http://<VM IP>:80;
        }
    }

    server {
        listen       9090;
        server_name  <QNAP 內網 IP>:9090;
	proxy_set_header Host <QNAP 內網 IP>:9090;

        location / {
            proxy_pass   http://<VM IP>:808;
        }
    }

    server {
        listen       8888;
        server_name  <QNAP 內網 IP>:8888;

        location / {
            proxy_pass   http://<VM IP>:8888;
        }
    }
}

port 9080 和 9090 分別對應不同 Laravel 服務。port 8888 給 jupyter-notebook 用。

jupyter-notebook 必須修改 NotebookApp.allow_origin 允許 cross origin API 不然修改會無法存檔。

nginx 設定 client_max_body_size 是避免用 notebook 上傳檔案的時候因檔案太大導致上傳失敗，設定 proxy_set_header Host 可避免 Laravel 的 redirection 錯誤導向到 VM IP。

Laravel app 也必須修改，包括：
.env

PROXY_URL = <QNAP 內網 IP>:port
PROXY_SCHEMA = http

app/Http/Middleware\TrustProxies.php

protected $proxies = [
    '**'
];

routes/web.php

$proxy_schema = env('PROXY_SCHEMA');
if (!empty($proxy_url)) {
    URL::forceRootUrl($proxy_url);
}
 
if (!empty($proxy_schema)) {
    URL::forceScheme($proxy_schema);
}

設定好後需重啟 Laravel
其他工具也可以透過 docker 使用。例如使用 git docker container 把 working directory 掛載進去做 commit。就可以繞過 QNAP 一堆東西都沒裝，偏偏還不好修改的問題。
全文連結

好站：小狐狸事務所

 連結

舊的站台書籤隨著換樣板全不見了 XDDD

閒逛發現的好站，部落格文章種類非常多，投資理財，大數據、深度學習、區塊練...都涉獵了。

重點是文章產量大且穩定，同樣是寫了 10+ 年的部落格，我就做不到持續產出。

其實寫筆記也是確保學習效果的好方法，單純看過可能很容易就忘，也可以留下自己曾經做過得紀錄，該勉勵自己了

全文連結

有趣的網路 bug

 幫公司做的土炮搜尋引擎和某些服務放在某虛擬機，稱 VirtA
VirtA 放在實體 NAS 上，稱為 NasA

公司內某些 PC，可以連 NasA 但連不到 VirtA，所有 port 都不通。tracert 顯示封包到 default gateway 就掉包。公司內不同網段的 PC  則完全正常，但產生連線問題的 PC 逐漸增加。

聯絡了資訊單位和科內真資訊大佬，做了各種諮詢和推論。最後被科內大老依照經驗找到問題，原來是 NasA 的實體網卡！讓虛擬機從不同網卡出去，bug 就不見了。

原本懷疑 routing 和 default gateway router 的問題，結果不是，真是活久見 XD

話說，我不是甲方嗎？ 

---

結果空歡喜一場，問題還是在 route...

全文連結

生命中第一次開刀 X 勞累

11 月單位換新機器以來，臨時增加的 loading，包含下班後線上進修，趁工程師在的時候學 workstation 、陪伴長官測試 etc 產生骨牌效應，工作狀態爆炸，進入做不完導致加班更累，加班更累導致更做不完的惡性循環，甚至可以電腦前發愣一小時但就是什麼都沒辦法做。

經過連續工作 non-stop 2x 天後（11 月份的四個六日分別是：連續加班、值班、上台北 *2），工時和業務累積量逐漸正常，然後換身體炸掉。本來一年沒發的 biliary colic 三天發了兩次。11/26 日 5 AM 痛到掛急診，打了四針（止痛 *2 IV lock *1 溶血重抽血 *1），榮幸被急診長官探視慰問，還幫忙聯絡了 intern 同梯的優秀外科醫生，直接約時間安排外科治療。

為了隔天來台北學習，離開急診後沒有留一口氣回家，而是黑咖啡撐著繼續清工作。結果本來嚴重疲累時偶發性的眩暈升級成 nausea + vomiting。趕業務趕到一半，看著影像猛地一陣噁心，直衝廁所抱著馬桶準備吐，還好情緒平穩後沒吐出來，不然真成了「打報告打到吐出來」的第一人。這種情況不知道是腹痛引發的嚴重失眠導致的，Tramadol 的 side effect，焦慮引起的，還是兼而有之難以查考了。

後來一心三用，邊恍神邊工作邊補眠把住院工作清完了。還有些業務不想弄也沒力氣弄了。好在已跟科內長官請了假，六日上課、散心後，回台南做一點必要的業務和報告後，就直接住院準備開刀，請假期間大多業務分出去也不用管了，趁病假的中間設法休息。
深深覺得，我知道自己不是事情最多的，但我可以肯定自己身體特別差，這波好了後有點想跟上頭談談了 =.=

----

第一次麻醉感覺蠻奇妙的，麻醉科醫師一邊跟我哈拉一邊 IV push。藥推進來的時候感覺的到刺痛，忽然間覺得腦袋轉不過來，眼前的畫面卡格，然後人就在恢復室了。

這次的 LC 復原蠻快，上週三上午開刀，週五就順利出院。今天就順利拆線。除了遵照醫囑不敢去健身房或做劇烈運動外，行動幾乎照常了。

暈眩的問題也去看神內了，初步看起來像週邊型暈眩，用藥控制症狀，做了腦部誘發電位，下週看結果。作為醬料系吊車尾神內耳鼻喉的知識早全忘了（沒想到這句話也可以說的如此坦然、如此自信、如此風采）就看醫師怎麼診斷了。

----

Gallstone 圖...就不附了，偷看病理報告已經 chronic cholecystitis 了。

 

 

全文連結

串流平台母湯亂做

 

串流平台亂做真的很母湯

這陣子接了新業務，為了避免業務品質貽笑後人，去買了線上課程溫故知新。課程本身是 online video streaming 的方式授課，中間有簡單的 quiz。

 

課程本身品質不錯，但程式出了問題。

 

有天沒事按 Ctrl-U 看源碼，發現純靜態網頁，完全沒混淆，影片網址明文放在 iframe 裡指向外部 video hosting platform。然後 platform 只檢查 referer（驚）

 

然後花不到兩小時就試出對課程內容時間轉移(time shifting)的可行方式。網站唯一小亮點是登入有 reCaptcha，可是手動匯出 cookie 就能繞過哪怕我換了 IP （驚喜）。整個過程 python 土炮 multiprocessing + request 就可以搞定，連 headless browser 都逼不出來。

 

平台看起來是專業醫師團隊架的，強烈懷疑是不是欠了外包商錢搞成這種方式 orz

全文連結

土炮、搜尋引擎、血淚

 用自己做的搜尋引擎幫自己查資料真的很有感

一切從念研究所開始，唸研究所時希望「一魚多吃」，最好弄一套題目又可以畢業又可可以實際使用，那時公司需要搜尋引擎和 GIS，不過只有「GIS 和搜尋引擎」沒有研究所該有的水準，所以改成「GIS、搜尋引擎搭配大數據架構」，從架構規劃就加了複雜度，CodeIgniter/PHP 其實只是前端，收到 search term 後寫到 Apache Kafka，再 dispatch 到 Apache Spark ，做完平行處理再合併結果。

然後一連串慘劇就來了。所方因為各種原因無法幫忙，人力方面只剩 0.5 人還是個外行（我），project 因為加了各種「賣點」無論架構和程式碼都嚴重肥大、失控，遠超 0.5 外行人可以吃下的程度，但我已經在高層們面前開了支票做這件事情。

公司方爭取資料也遇到嚴重瓶頸，業務資料具備敏感性，走正規流程詢問過公司專業法律人士確認法律上可以做，層層取得同意。同意後還是在資訊單位排單約「一年」才得到拋轉程式，資訊單位真的很忙。

畢業後痛定思痛，程式大規模重構。這次純從實用、好寫出發，不考量「研究賣點」也不考慮其他 team member 維護（反正也沒有 team member），程式碼全砍，放棄了 CodeIgniter 用 Laravel 重寫，Kafka、Spark 也砍掉了。

程式重構和拿到資料後，Project 起死回生。重生的系統本質是套殼的 Elasticsearch，前端用快樂的 Jquery 搭 Bootstrap（攤手），後端 Laravel/PHP，搜尋核心業務邏輯用 Python。系統規模約三至四萬行，加上 JSON 和 CSV 則一百萬行（驚喜）。PHP 和 Python 的手寫 code 有作到 100% 測試涵蓋，linting、CI/CD 沒上，總之程式會動就好 orz

搜尋採用批次處理。Laravel/PHP 接到 search term 送到 message queue （DB 用資料表模擬）後馬上返回，後端 python 批次做完查詢後保存結果。使用者送出查詢後可關掉頁面隨時回來「讀檔」。資料拋轉則是用神奇的 Autohotkey！（因為公司提供的拋轉程式是 VB.Net Windows form 應用程式 :D）


今日新系統今天迎來第一個真正的搜尋業務，就是幫我週二的 morning meeting 找案例 XD。輸入複雜的 search criteria 後看系統載入、返回結果，覺得系統該死的難用的同時也有恍惚感和滄桑感。


前面的路還有很長，系統還只有分公司資料，當初答應的 GIS 也還沒重構完成，未來再慢慢補齊功能，並爭取匯入完整資料，期待有一天正式上線吧。

這應該是我做過規模最大、最坑的 side project 了（吐血）

全文連結

GUNBUSTER FANTASY (Kohei Tanaka / Pianeet) - ガンバスター幻想曲

 

Duke of Pianeet 的 Gunbuster 改編曲。動畫是庵野秀明監督的作品，暫時還沒看，但不妨礙欣賞好聽的動漫歌。

改編者 Duke of Pianeet 的產量、聲量好像小於 Animenz，但技術實力強勁，這首應該算改編到走火入魔了，第一次看到 ACG 鋼琴曲把李斯特超技摻進去的...

全文連結

墾丁旅遊

 工作狀況不理想，趁國慶和公司設備維修期間短暫請假休息。翻網誌上次來墾丁已經是九年前了。旅遊前兩天剛好遇到颱風，整天下雨和刮風就飽了，只能玩飯店內設施（哭哭）。風雨改善後去玩了海生館還有計程車包車。

凱撒大飯店大部分設施還是沒變，熟悉的場景 XD

西餐廳（2021）

西餐廳（2012）

遺憾的是地下一樓娛樂場所設備精簡掉了，2012 年還有大型電玩機台，這次去就看不到了 雖然補了新機器，但還是大型機台能引起回憶啊 >"<

地下一樓（2021）

地下一樓（2012）

 

二樓自助餐廳

歐風自助式早餐
飯店的歐風自助式早餐品質不錯，不過不是當地特色料理，價格也高，就吃一次 XD

海角七號阿嘉的家

計程車包車去的，當年應該沒玩到 XD

大飯店海景，海灘封閉了，錄影的時候風雨已經減少很多但海浪還是看得出大風。

今天玩完回家，休息下準備下週上班 QQ

全文連結

部落格 16 年了！

 部落格 2005 年開張，到現在（2021 年）已經 16 年了耶！！！

人也從懵懂少年快變成中年大叔。

回頭看自己寫的文章，包含當年在醫學生時期的掙扎，各種腦洞的嘴泡，以現在的眼光來看忽然有種羞恥感，但也產生了玄妙的感覺，好像變成長輩，隔著 16 年的時光長河，和過去身為少年的自己對話。少年跳脫頑皮的訴說，慈祥的長輩靜靜傾聽。只是遺憾長輩說什麼過去那個少年都沒辦法聽到。

最近工作感覺困頓，再回來整理充滿回憶的部落格。清了壞掉的超連結，無法運作的 widget 等過期元素。再來版面大修，現在對 HTML/JS 的理解遠超當年的少年時期（當然絕對不能跟職業人士比 XD），按自己喜歡的樣式套背景圖、改版面、套香香的 Google Font 中文字型，再加了半自動播放的 Youtube playlist，終於讓網誌成功復活！

邊整理部落格邊看過去文章，看到十多歲的自己可以 3AM 睡隔天若無其事，二十多歲的自己可以三天一班但睡一覺就復活，可以熬夜趕線上活動 code 再做 meeting 投影片熬到 5AM 人還是沒事，現在變成11PM 不睡隔天就廢掉的 35 歲超齡大叔，光陰如梭，無限感慨。

全文連結

換新手機了！

 舊手機 LG V20 陪伴我四年還五年，換過 N 次電池（這是最後一隻允許直接換電池的安卓旗艦），過保不知多久。

去年五月 3.5 耳機孔模組故障時就想換，但靠著淘寶買來的零件，親身施展天魔手殘維修大法，弄壞一顆主相機後，終於把原本故障的，和被我弄壞的零件全替換好，繼續用到了現在 XD

但卡頓情形還是無法完全改善。最後掃個實聯制 QR code 都會過熱當機，又剛好要出門玩乾脆換機升級。

我是 LG 愛用者（LG Gpro2 -> LG V20），但 LG 手機部門倒掉的情況下也只好換家了。跳槽到三星，14K 買了 S20FE

新手機升級感非常強。CPU 升級到 S865 ，6G RAM、全新儲存元件，操作如絲般滑順，沒比較不知道舊手機已經卡成狗啊....相機提昇也非常明顯，無愧 DxoMark 30 分的差距

資料轉移完畢後，LG V20 直接重設原廠狀態，關機收起來當備品，再拿出來的機會應該很少了，感謝陪了我四五年，再見了 V20。

全文連結

人生第一個深度學習應用

成功弄出第一個自己的深度學習應用 XD

問題起源於幾年前唸書時期的研究計畫，得弄一個能從大量（去識別後，連匿名 ID 都沒有的）free typing 地址中分析出區、里的程式。

難點在於地址是 free typing，不一定會填區里，有也不一定對。特別是「里」的資料還經過行政區域調整（舊里合併、消失，新里出現），還有亂碼（特殊造字），通用字（鹽塩曹[石曹]𥕢...）等問題，甚至官方資料也不保證乾淨（曾經從政府門牌查詢網頁查詢出填色方塊字██...）。

資料品質多慘？約 20% 資料連 Google 都分析不出區里，剩下 80% 很多判讀結果也有明顯錯誤（例如台南地址判讀成高雄的）。最重要的是，未來如果上線對接真實資料做分析，就不方便採用 Google Map Platform 等線上服務。

原本做法是應用工人智慧，寫個土炮 parser 硬讀，搭配大量特殊規則和自製資料清潔 pipeline 應對各種坑，但效果並不好（「區」「里」正確率約 6x%、50%），本來差不多放棄了，但最近研究 ML/DL 忽然想到這問題其實類似中文文本分類問題，也許可以 ML/DL 解決？經過大量搜尋後發現也許可以用 TextCNN 解決這問題。

最初版本是依據好心人 CSDN 分享的「中文新聞分類」代碼依樣畫葫蘆。文本資料轉簡體，Jieba 斷詞，用簡中新聞訓練出來的 pretrained word2vec vector 做 embedding，結果分類正確率只有 4X%，而CSDN 上新聞分類範例的正確率是 90%。

研究後發現 training data 可解釋部份問題，jieba 斷詞用在地址並不理想，檢視後發現很多不合理的斷詞。個人也懷疑用新聞訓練的 word2vec 和斷詞也不適用於地址（例如博愛、仁愛語意近似，但仁愛路和博愛路就完全不同）。於是換了土炮斷詞法，改了 stopwords，用 gensim 拿公開門牌資料重新訓練 word2vec，再搭配土炮 parser 的資料清潔 pipeline，調了下少數個人看得懂的參數。model 正確率拉到 60%（里，600+ 個分類）和 88%(區、37 個分類)。土炮 parser 也不用扔，拿來做 ensemble，混合雙打正確率就拉到 65%（里）和 90%（區）了。

弄好後復盤，才注意到這是第一個親手寫出來的 deep learning 應用，雖然核心 model 代碼借（ㄔㄠ）鑒（ㄒㄧˊ）了公開代碼，不過 data cleaning、找出 accuracy 低下（部份）原因並改善、部份參數最佳化、做 ensemble、還有把一切從 jupyter notebook 打包成完整的 pipeline 都是自己完成的。成功踏入 deep learning 調包俠境界，並且有生之年應該有機率進階調參俠 XD

可改善的地方還有很多，也許可以換更好的模型（往 Hierarchical classification 去找？），進一步參數探索，土炮 parser 也可繼續打磨，改善 ensemble 的整體效能。不過作為非資訊專業人員作到「證明問題可以用 deep learning解決」，應該夠交差了，請公司內專業 AI 人士改善模型我再套回 pipeline 也許是比較好的做法，我可以去做別的事。

最後，pytorch 真是美！

全文連結

Onedrive 停用自動更新

原本用 Google Drive 放個人資料，買 Office 365 有附 Onedrive 空間就開始使用 Onedrive。Onedrive 用起來什麼都好，就是會自動更新到新版，然後新版永遠無法啟動（默），於是每次 Onedrive 自動更新後就得重裝。

為了這件事，爬了大量網路文章，網路上提到的方法大多是工作排程器停用 Onedrive standalone update task。微軟官方網頁也是這樣寫的。但事實上 task 停用以後，Onedrive 還是會偷偷自動更新（Windows update 直呼內行！）

今天換思路，直接進 Onedrive 的程式目錄（%localappdata%\Microsoft\OneDrive），找 Update 和 StandaloneUpdater 兩個子目錄（沒有這些目錄則手動創造空白子目錄），右鍵內容 -> 安全性把 System 群組在內所有權限全部勾「拒絕」，並實驗確認目錄無法修改。

設好之後故意打開 Onedrive standalone update task，結果 Onedrive 無法更新，停留在穩定的舊版。討厭的新版再見～再也不用無限重裝舊版了 XD
全文連結

Vast.ai 發現

最近想試試 TextCNN 看能不能解一個問題，把塵封許久，裡面還有 $8 credit 的 vast.ai 請出來。

原本以為 vast.ai 的 container 只能 SSH 或 jupyter notebook 二選一，可我想兩個都要。為此還花了幾小時自製 docker image 用 supervisord 啟動同時執行 jupyter notebook 和 sshd，結果在本機端成功啟動但在 vast.ai 無法使用。

繞了大圈才注意到，vast.ai 給的 ssh 連接指令是：

ssh -p 12345 root@ssh4.vast.ai -L 8080:localhost:8080

如果單純只要 ssh，何必多開 port 8080 做 SSH tunneling 呢？去查文獻才發現，這個 port 8080 是讓你在 ssh 裡面開 notebook 用的。

jupyter notebook -ip=127.0.0.1 --port=8080 --allow-root

在 Windows 本機，putty 打開 SSH tunneling 連上後，在 bash 啟動 jupyter notebook 時指定 port 8080，本機瀏覽器開 localhost:8080 就能進 notebook 。自己土炮的 docker image 用這個方法就可以同時開 ssh tmux 和 jupyter notebook

不得不說 vast.ai 的 documentation 不夠清楚，雖然 RTX 3090 $0.561/hr 的價格真香 XD
全文連結

自炊電子書經驗

家裡書越來越多，很多技術性的書籍，讀過一遍以後通常只會拿來查，很少完整重看第二遍，放在家中佔地方，工作出差又不好帶，所以就動了自炊的想法。後來剛好看到夠便宜且夠用的掃描器，Microtek ArtixScan DI 2125c，一台不到 2500，支援 A4 彩色雙面掃描 600dpi 有 20 張的自動進紙，低廉的價格作為實驗品足夠好。折騰了一兩天終於弄出了自己的 pipeline 

找影印店裁書，掃描存圖檔 

圖檔要檢視有沒有跳頁或是嚴重扭曲，有的話重掃並且設定好檔名，使檔名 lexicological order 和紙本頁面順序一致。 

重排檔名，和依照檔名順序重設修改時間

避免檔名或修改時間的順序紊亂，導致匯入其他 App 後順序順序錯亂，以下 powershell 腳本「-whatif」要拿掉才會真正改檔名，否則只是預覽。

依原本檔名順序批次重新命名

(Dir *.jpg) | sort name | ForEach { $count=1 } {
	$scount=([string]$count).PadLeft(4,'0')
	rename-item $_ -NewName ngimg-$scount.jpg -whatif; $count++ 
}

依檔名重排修改時間

$dirs = (Dir *.jpg) | sort name
ForEach($d in $dirs) {
	$file = Get-Item $d
	$file.LastWriteTime=(Get-Date)
}

圖檔轉檔為 PNG

不用 jpg 是怕反覆修改存檔越來越失真。後面的步驟每次使用 mogrify 前都建議複製圖檔目錄做備份，因為 mogrify 會原本修改原本圖檔造成不可逆變化。

magick mogrify -format png *.jpg

去背景

magick mogrify *.png -transparent white -fuzz 50%

fuzz 網路教學設 90%，我保險一點設 50%

Imagemagick 切黑邊，傾斜校正（deskew）然後再切黑邊 

切除黑邊

magick mogrify -fuzz 30% -define trim:percent-background=10% -background black -trim +repage *.png 

個人測試的結果，percent-background 不設成 0 可避免去黑邊的時候吃掉太多正常內容，切完後周圍會有很細微黑邊但個人可接受。書中有大量黑底的，可把 percent-background 拉高或把 fuzz 壓低，try and error 根據最終效果做調整

傾斜校正（deskew）

magick mogrify -deskew 80% *.png

個人使用體驗，deskew 設 80% 會比網路上普遍的 40% 好些，至少對我的掃描器是如此。如果先做傾斜校正，圖檔四周可能多出不同色，和原本黑邊混雜，造成後續去黑邊困難。所以先去黑邊再傾斜校正，再去一次黑邊去除掉傾斜校正造成的額外黑邊。 

影像銳化

magick mogrify *.png -sharpen 0x1.5 -modulate 100,130,100

modulate 三個參數分別代表亮度、對比和 hue。100 代表原值。個人選擇調高對比。sharpen 0x1.5 是網路建議，測試後肉眼可接受。 

圖片檔案批次匯入，做 OCR，存成 pdf 

我用掃描器附的  Finereader 解決

建立 PDF 目錄（table of content）

網路上找了一堆免費或試用軟體，後來發現 k2pdfopt 可用。

k2pdfopt -mode copy -n -toclist 目錄檔.txt 輸入pdf.pdf -o 輸出pdf.pdf

其中目錄檔的格式如下，前面的數字代表對應 pdf 的頁數，+ 號代表縮排

20 Chapter 1 大章節
+21 1.1 小章節1
+26 1.2 小章節2

弄好後可用免費的 PDF-Xchange editor 把目錄中不小心插入的空白項目等移掉，PDF-Xchange editor 若只是刪除現有目錄中的項目是不會加浮水印的。 

到這步自炊電子書 pdf 就完成了。原本的書看是要膠裝保留還是丟掉。附上自炊的電腦叢書抓圖。Pdf 有目錄，文字沒有歪斜且清楚。旁邊很醜的字是個人閱讀用鉛筆做的筆記，300dpi 下（我自己）還是能看懂寫什麼。 

除了文中方法，我也試了不少 App，包含中國製 Camscanner 掃描全能王，Adobe scan、Microsoft Lens 等但各有各的問題。

Camscanner 最好用，但有浮水印，電腦版還要你把資料傳上雲端，之前好像還爆發過資安疑慮，MS Lens 發現 Android App 不能一次匯入大於一百張就放棄了。

花了一兩天，發現其實以裁書後用掃描器掃描的圖片品質，用 Imagemagick 搭 pipeline 做後處理就很夠用了。影像來源才是決定電子書品質的關鍵，影像來源太差，例如用手機搭自拍支架拍照片，照片還有手指，不管後續用什麼軟體，得到的結果都是歪七扭八又模糊。

當然買好點的機器也是解法，網路一致推薦的自炊神器富士通 Scansnap ix1500 除了掃描速度更快，機器軟硬體好像還附贈更好的校正功能，說不定就不用自己土炮後處理 pipeline 了？但那台機器對只想「試試看」自炊的我太貴了，後來就算了。

全文連結

第一次用 Rust 寫程式成功

程式背景是需要用 Chromium embedded framework 寫 client 做 overlay UI 去「注入」某報表軟體，幫軟體增加原生 UI 沒有的功能（關鍵字變色）。原來用 python 搭 cefpython 被我嫌慢，改用 native C++ client + Rust 做。

初步使用結果，語言加入的新機制幫忙不小，如 Ownership 和 lifetime 替我抓出「把 stack 的 local variable 直接 pass reference 給另外一個 thread」這種蠢錯誤。除此外 Rust 「安全」的設計還有很多，例如  function 不直接回傳「結果」，而是把結果值包在特殊物件（Result）裡，不寫 error handling 的 code 就不能把撈出來用等等，compiler 盡了努力確保 error handling 完整，不完整甚至不給 compile。

缺點就是 learning curve 很陡。例如指針裸奔不能用，物件要非常清楚考慮 life cycle 的問題，我為了把一個 TCP socket object 給兩個 thread 用搞了半天才說服 compiler。大量的 Error handling 讓 code 膨脹，Rust 給了語法糖來緩解膨脹但也增加了 learning curve。Rust 的某些設計，如完全沒有 object inheritance 而是用 Trait 做 duck typing 等等也讓我花了時間上手。

但 Rust 的「好處」也體驗的到。這次寫 multithreading 完全沒遇見 segmentation fault 或任何 memory-related error。即使是 Panic （我偷懶用 panic 做 error handling）也在 Rust 的管理之下，至少報錯非常清楚，這次完全沒用 debugger 或看 stack dump。

Rust 的套件管理也很好用，cargo.toml 寫好 dependency，剩下的 cargo 自動處理。不需要搞定 lib compile、linking 或各種環境設定鳥問題，舒適度堪比 Docker pull XD

整體而言，至少在我的 use case 裡，Rust 確實做到用語言設計，在 compile time 抓了大量會在 runtime 炸掉的問題。但 learning curve 陡峭，寫程式也很難「想到哪寫到哪」，也許在完成 prototyping 或業務邏輯固定後用 Rust 來重構 bottleneck 是不錯的用法 XD 全文連結