前陣子買了一本電子書，沒想到 epub 檔只不過是紙本的圖檔打包而已。充斥白邊在紙上或許有某種美感，但是在閱讀器上實在有點惱人，所以我就用 PIL 做了適當的剪裁，然後再用 ebooklib 重新打包 epub。因為對 ebooklib 不那麼熟，花了一點點時間才搞定，程式碼放在這裡給其他有類似需求的人參考。

這裡要說明一下，一般來說圖檔打包成 cbz 已經足夠了，但我這本是文字書，還是希望有個完善的目錄。雖然 Calibre 可以直接將 cbz 轉成 epub，但是還是有些不盡理想的地方，首先是圖片自動縮放的問題，再來是目錄的問題。當然還有一個因素是我忍不住愛折騰。

本程式會為每一張圖檔生成對應的 xhtml，例如 005.jpg 對應 005_p.xhtml，然後把 xhtml 加到 spine 裡面。

主要使用的技巧是包一層 svg，用 viewBox 屬性自動縮放影像大小，這點必須仰賴閱讀器支援 svg。必須提醒一下， ebooklib 會擅自把 viewBox 屬性名稱改成全小寫的 viewbox，以致於在某些閱讀器上失效 ，所以生成 epub 檔之後還是得解開然後用全域搜尋工具把大小寫改回來，算是比較鳥的地方。

由於只是隨用即丟程式碼，細節就不太講究，有需要的人自己動手改吧。

雖然以前大致上知道西歐緯度比中國東北略高一點，不過前幾天才發現羅馬和伊斯坦堡比北京更靠北，緯度已經接近於北海道。出於好奇，我寫了個小程式從維基百科抓取幾個北半球城市的經緯度，做成了下圖。

這裡的城市是憑感覺隨意挑選的，不是用人口、面積之類的客觀條件篩選，所以並沒有特別的意義。另外要注意本圖是直接把經緯度標記在卡氏座標上，並且橫向大幅壓縮，圖面上的距離和真實的地理距離可能會非常不同，特別是高緯度的部份。

威尼斯的緯度和哈爾濱、蒙特婁差不多，甚至比北海道多數地方更靠北，可能與大眾印象非常不同。

由圖可以看出歐洲緯度確實比亞洲高出許多，緯度畢竟和日照高度相關，歐洲人演化出白皮膚自然有其道理。

剛看完一系列用瓦楞紙製作的橡皮筋動力槍，由衷佩服工藝高手的巧思與巧手，不但外型仿真，而且還真的可以裝彈、發射。

Blackfish 的作品

MP5 - 這好像是最原始的作品，清楚的展示槍機以及供彈系統的概念 https://www.youtube.com/watch?v=wXCiSmlWomU

Glock 19 https://www.youtube.com/watch?v=bOj_d8I_U1o

AK-47 https://www.youtube.com/watch?v=OfK-Onv6Wag

由於某網友讓我翻舊照片，結果發現了之前拍的這幾張，原始作品大概早就被丟到廢紙回收了吧。

其實是川崎玫瑰的核心，做完不收尾，連續一直摺滿整張紙。

對了，這是即興創作品，所以沒有摺法圖。

正面：

背面：

中醫分科

古中醫的分科：

徐氏《醫統》云︰古醫十四科，中有脾胃科，而今亡之矣。《道藏經》中頗有是說。宋元以來止用十三科。考醫政，其一為風科，次傷寒科，次大方脈科，次小方脈科，次婦人胎產科，次針灸科，次眼科，次咽喉口齒科，次瘡瘍科（即今外科），次正骨科，次金鏃科，次養生科（即今修養家導引按摩咽納是也），次祝由科（經曰︰移精變氣者可祝由而已，即今符咒禳禱道教是也）。國朝亦惟取十三科而已，其脾胃一科終莫之續。《類經》云︰醫術十三科，曰大方脈，曰婦人，曰傷寒，曰瘡瘍，曰針灸，曰眼，曰口齒，曰咽喉，曰接骨，曰金鏃，曰按摩，曰祝由。今按摩、祝由失其傳。二說微不同。而太醫院所設十三科，則與《類經》之說同，詳見《明史》。余按︰近有專業耳科者，是又在諸科之外矣。

宋朝官醫開始分為九科，後來擴充到十三、十四科，到了清同治整併成五科。隨時代推移有些專科會合併或獨立，民間與官方也未必相同。其中大方脈科相當於成年人內科，小方脈則是小兒科，風科和傷寒科特定類型的外感疾病（但不完全等於現在的傳染病），祝由、書禁則是儀式咒語之類的。從文學作品也可以看出古代行醫者分科執業的情形，《笑林廣記．術業部》就有幾則和醫療專科有關的笑話，如「外科鋸箭竿」、「大方脈打小兒科」（這則我看很久才看懂）等。

陸以湉也認為「醫貴專門」，他並引用《易簡良方》的勸行醫說：

《冷廬醫話》的作者是清朝陸以湉（1802年－1865年），道光十六年進士。作者飽讀醫書，也常和同時代的儒醫交流，這本書紀錄的他在醫學方面的見聞，有些引用自醫書，有些來自臨床經驗。

我第一次知道《冷廬醫話》這本書，是在中研院史語所研究員祝平一的〈藥醫不死病，佛度有緣人〉文裡，其實我連書名都沒記住，只是對「吳有性治施幼聲醫案」留下印象。前陣子 在推特上看到網友引用《冷廬醫話》片段 ，才發現這本書蠻有意思的。因為我只是按照自己感興趣的主題摘錄，所以很多引文沒有考慮原始脈絡，有興趣的讀者請自行找原文閱讀。

推薦一部 James Randi 的紀錄片：《An Honest Liar》
https://www.bilibili.com/video/av2795660/

（如果不喜歡彈幕，播放器右下角有關閉的選項）

這部紀錄片重心放在 James Randi 心路歷程，而非介紹那些被揭穿的把戲，影片只舉幾個最具代表性的案例帶過。而且編導大概是遵守魔術師傳統，沒有揭露任何魔術手法，所以不要抱著看魔術秀的期待來看本片。

亞當曾經透漏，在 RFID 那一集有些牽涉到資安的部份被德州儀器施壓而沒有播出。最近我又看到亞當講了另一則從來都沒有播出過的流言，影片發布日期已經是好幾年前了：

https://youtu.be/ziQWDnFSPt8

這則流言的主角是那種除了甜之外沒什麼營養的早餐穀片，有些家庭主婦會對小孩說：「連包裝紙盒的營養價值都比裡面的穀片高」。

他們的實驗設計就是找了一堆老鼠，其中一籠餵正常老鼠飼料，一籠餵又甜又沒營養的穀片，最後一籠餵切碎的厚紙板。

到了第了五天，前兩籠都很正常，只是厚紙板組行為看起來有點怪怪的。然後過了週末他們再去看時，厚紙板組的三隻老鼠變成了一隻胖老鼠，另外兩隻老鼠只剩下四散的殘骸。

最近讀了這篇文章《中西醫第一次大對決》，隨手寫些心得。

1910 年中國東北爆發鼠疫，清廷派留學劍橋的醫學博士伍連德前往主持防疫適宜，同時也募集各類醫療人員隨行協助。當時中國西醫極為稀少，中醫則相當普遍，然而前往疫區的幾乎都是西醫學校師生。雖然中醫名家不願前往，倒是樂於在後方報紙大打筆仗，有位從疫區長春逃到天津的中醫張聰彝看不下去了，發言道：「試問鼠疫致死一霎那之頃，以吾國醫藥之迂緩，而謂能立刻奏效乎？如曰能也，二三君子何不束裝赴奉一試其技，而乃於此間饒舌乎？」京城名醫之一的丁子良憤而應戰：「三五日內商議妥恰，即可見諸實行。」但最後也沒成行。

伍連德在這場瘟疫最獨到的洞見在於，他透過解剖遺體以及研究感染歷程，確定病原體是鼠疫桿菌，但和以往所知的鼠疫有許多不同之處。這次疫情其實與老鼠無關，最初是由旱獺傳染給毛皮獵人，之後隨著飛沫在人與人之間感染。當時外國醫師都不相信中國的科學能力，日本、俄羅斯醫師根據過去控制鼠疫的經驗，認為全面滅鼠就能控制，而且不覺得鼠疫有必要使用口罩，就連清廷派往支援的外國醫師也不信任伍連德的判斷。然而當事實逐漸呈現，大家很快都承認伍連德的看法是對的。伍連德就地取材製作成本低廉的口罩供應給工作人員和平民，中醫因不具備這方面的知識而不願使用，以至於留在當地沒有逃出的中醫師死亡率則非常高：

據中國醫生全紹清的統計，在傅家甸抗擊鼠疫的工作人員共有2943人，死亡297人，死亡率10.1%。其中死亡率最高的是運送病人的工人，150人死69人，46%；其次就是中醫9人死4人，44%；作為對比，西醫和醫學生49人，僅死2人，4.1%。這些中醫之所以死亡，是因為他們不願意戴口罩，他們不相信鼠疫是由於呼吸道傳播的鼠疫桿菌引起的。對這個數據，後來在「奉天國際鼠疫會議」上，英國鼠疫專家細菌學家醫學博士皮特里認為，暴露於感染的中醫的數字應該遠遠不止9人，如果全部計算的話，死亡率可能是90%，而不是44%。

在《奉天國際鼠疫會議報告》中記載有外籍醫師的調查，河間府某地有2個村莊，因為一個鼠疫病人路過而慘遭滅絕。村裡有一名老中醫，他為病人望聞問切後即和他的病人一起死去。這樣的例子應該是大量存在的，堙沒在無數的死亡里。

在十八世紀的時候，歐洲的冶金技術和精密機械突飛猛進，齒輪、彈簧、輪軸等零件越做越小，使得鐘錶匠能構思相當複雜的作品。其中最具開創性的成就之一，就是發展出後世稱為「可程式」的概念。機械的動作可以被保存在某種「記憶體」中，例如凸輪、打孔帶，然後透過槓桿讀取指令並轉換成機械動作。

這個寫字機器人由瑞士鐘錶匠 Jaquet Droz 在 1770 年代製作，也就是說大約跟美國一樣老。和當時的機械鐘錶一樣，這些自動機完全是用發條驅動的。
https://www.youtube.com/watch?v=bY_wfKVjuJM
https://youtu.be/WofWNcMHcl0?t=5m10s

分享一個前幾天幫忙排除問題的趣事，事後看覺得再明顯不過，發生當時卻讓人困惑了一下。前幾天要下班時，發現同事還在奮戰，所以就過去湊一下熱鬧。原來是他正在為某個平台建立 cross-compile 環境時碰到麻煩。

這裡說明一下，我們團隊的「cross-compile 環境」其實就是一個個 chroot，預先裝好了目標平台的 cross-toolchain、程式庫，並設定好環境變數。通常這些 cross-compile 都是由熟悉 Linux 環境的人事先打包好，新加入者只要按照產品型號下載對應的編譯環境，就可以立即上手建置專案。當硬體廠商更新驅動程式、或者程式庫 推出安全性修正時，負責的同事必須要更新編譯環境，有時候重大的調整會需要整個砍掉重頭建起。

同事在這方面相當有經驗，按標準流程很快就建好了一個理論上可以用的環境，可是試編譯某個大型專案卻老是編不過，CMake 一直抱怨「找不到 pthread.h」。由於我對 CMake 比較有經驗，所以就留下來幫忙診斷問題。

雖說 cross-compile 有時候就是會有一堆奇奇怪怪的路徑、環境變數問題，以至於工具跑到錯誤的地方去找東西，但是像 pthread 這種基本的東西實在沒理由出錯。同事已經把 pthread 相關的套件重裝好幾次，檢查路徑也看不出問題出在哪裡。用最簡單的 Makefile 直接建小程式並沒有問題，所以他強烈懷疑是 CMake 的 bug，但是換過了幾個 CMake 2.8.x 子版本還是沒有解決。

我就是在這個時候介入的。因為他拿來試編譯的專案頗複雜，我建議他寫一個極簡的 CMakeLists 來測試，只要 find_package(Threads REQUIRED) 就好，其他的事情都不要做，結果確實找得到 pthread.h。所以很明顯 CMake 程式本身是沒有問題的，而是這個專案不知道改動了什麼東西，所以才找不到 pthread.h。

前幾天有網友回覆 四則運算解析器 那篇，回頭瞄了一下舊程式碼剛好讓我得到了一個靈感，所以寫了這篇「函數解析器」。

我過去曾用 C++03 實作過一些小型語言的編譯器、直譯器，使用都是比較傳統的方法，也就是設計一個 AST 節點的基礎類別，再特化出各種不同類型的 AST 節點。這個寫法非常的囉唆，許多程式碼都是為了滿足靜態型別語言的規範，而不是實現真正的功能，相較之下 python、javascript 之類的語言可以用精簡許多的程式碼完成同樣的事情。

我最初的想法是，既然 C++11 有了 std::function，那麼就不需要透過基礎類別來提供共同界面，接著我又想到了可以用 std::bind 來連結子節點。最後靈光乍現，只要有 lambda，根本就沒有必要用 std::bind。對了，這個程式使用了 std::regex，最好使用最新的編譯器，已知在 GCC 4.8 會有錯誤，至於 GCC 5 以後和近幾版的 clang 應該都沒問題。

這個函數解析器的特點：

• 可以處理運算子優現順序和括號。