搜尋之後發現有人說可以用 mitmoroxy，是開源的不像其他 proxy 除錯工具一樣需要付費，稍微測試了一下，發現這東西很好安裝和使用啊，所以花了一點時間研究看看是不是能達到目標，大概步驟如下：

• 安裝 brew install mitmproxy
• 然後開 iOS 模擬器
• 安裝 mitmoroxy 的 cert 到模擬器裡面

xcrun simctl keychain booted add-root-cert ~/.mitmproxy/mitmproxy-ca-cert.pem

• 啟動 mitmproxy
• 然後設定你的 MacOS 網路來使用這個 proxy（預設是 http://localhost:8080），因為 iOS 模擬器和 host OS 是共用網路的

就這麼簡單，不過這方法還是有些限制，像是如果有用 HTTPS pinning 的話，那就還要其它設定；然後 mitmproxy 本身的操作很好上手，這邊就不多花時間說明了。

然後回到一開始的問題，到底 304 有沒有用呢？我這邊是用 React Native 內的 fetch，然後結論就是有，在 mitmproxy 確實是看的到 304，不過在 RN 的 context 內就會變成 200 了，其實後來想想也覺得合理，因為應用程式層本來就不應該去處理 HTTP 層的 cache 問題，這樣大大的簡化了複雜度。

參考：

• Using mitmproxy with the iOS simulator

其實一直以來都有點好奇，像 Intl 這種可以根據語系格式化輸出數字、貨幣數值或是日期等資料的工具函數，它的資料集到底是哪裡來的？會很好奇是因為這其實是一個多對多的組合，不同的語言地區配上不同的貨幣，算起來每種資料格式都要維護一組數量不小的組合，例如我想要用法文或英文顯示 10000 新台幣要用怎麼顯示呢：

// zh-Hant
$10,000.00
// fr
10 000,00 TWD
// en-US
NT$10,000.00

// zh-Hant
€10,000.00
// fr
10 000,00 €
// en-US
€10,000.00

可以明顯看到，相同的語系顯示不同的貨幣數值，也有不一樣的格式設定，證實了它確實是一個多對多的關係，現在 ISO-639 有規範到的語言有 183 個，ISO-3166 的國家則是 271 個，相乘起來將近五萬種組合的資料是怎樣維護的呢？結果，其實這些資料的定義和管理都是在 Unicode 的 CLDR 專案，CLDR 是 Common Locale Data Repository 的縮寫，收集整理了各種因為地區不同而有差異的資料格式，除了上面提到的貨幣、數字之外，還有像是日期、時間、度量衡、數字、姓名（姓前面還名前面、有沒有中間名等）等的格式，然後還有像是國家、貨幣、時區、單位甚至是 emoji 的翻譯。

CLDR 網站上可以直接看到這些資料，拿繁體中文為例，網頁位置在 charts 下，下面的圖是第 44 版的，最新的版本其實是 48，以下請見截圖介紹，最右邊都有值的那欄就是 zh-Hant 繁體中文的翻譯和格式(pattern)。

國家名稱（這邊用的單字其實是 territory，翻譯通常是領土、疆域）、語言和時區：

日期時間格式：

也有特定國家用的系統，像是中國的天干地支和二十四節氣：

日本的年號：

這篇所提到的數字格式和貨幣顯示方式：

貨幣名稱：

可以看到以上這些資訊都有繁體中文的文字翻譯，所以其實這都可以當成正式的譯名了。

這些資料的原始格式都是用 XML 維護的，東西放在 GitHub 上，例如我們上面舉例的 zh-Hant 的檔案就在這，有興趣的可以看看檔案結構長怎樣，去上一層目錄則可以看到所有目前有存在的地區語言組合(語系、locale)，目前有在維護的是 1127 種，超過一千個檔案所以其實在 GitHub 的網站上也不會全部列出來，而這一千多種語系其實遠大於我一開始提到的 ISO-639 規範到的一百多個語言，所以實際有在維護的資料數量比我一開始隨手估計的還要大上六七倍。

回到檔案內容，有兩個字元想要特別介紹的，這種用字元表示特別意義的方法在其他地方蠻少見，真不愧是 Unicode 專案：第一個是 ↑↑↑，可以在很多地方看到，這三個字元出現的話，就是代表請找 fallback 值，一般而言就是把語系的值拆分扣掉最後面那一段，如果在查找的時候收到的語系是 zh-Hant-TW，那第一次 fallback 就會發生在找不到該檔案，改成找 zh-Hant 的檔案，也就是上面範例那個檔案，找到檔案後，查找該檔案內的指定的定義，結果定義是 ↑↑↑ 時，就改成去找 zh 的檔案內的定義，如果一直都找不到就會去 root.xml 找。

第二個要介紹的則是 ¤ 字元，這是我第一次注意到這個字元，本來以為是比較新的定義，不過其實它是很古老的字元，根據 Wikipedia，它在電腦領域最早出現是在 1972，7 bit 編碼時就有了，比我還老，一開始就是作為貨幣符號的占位符號使用，不代表任一特定的貨幣，那這個符號在 CLDR 這邊是怎樣用的呢？在 zh-Hant.xml 檔案內直接搜尋該字元，就可以看到這段定義：

<currencyFormat type="accounting">
	<pattern>¤#,##0.00</pattern>
	<pattern alt="alphaNextToNumber">↑↑↑</pattern>
	<pattern alt="noCurrency">↑↑↑</pattern>
</currencyFormat>

其中的 <pattern> 內的值就是 CLDR 自己定義的數字、貨幣的顯示格式的 pattern（格式），詳細可以參考官網的介紹，每個字元都有其定義，而不是真的用那個字元顯示，例如 0 代表一定要出現的位數，但是數字系統可以換，所以最後輸出不一定是阿拉伯數字；, 代表的是千位數分隔符號的位置，實際上要用哪個字元作為分隔符號，則是看該語系的定義；同理，¤ 字元的用途就是在這個 pattern 當中，貨幣符號的放置位置，而要顯示怎樣的貨幣符號，則是還要看語系和設定，例如新台幣在 zh-Hant 中的定義就有以下幾種：

<currency type="TWD">
	<displayName>新台幣</displayName>
	<displayName count="other">↑↑↑</displayName>
	<symbol>$</symbol>
	<symbol alt="formal">NT$</symbol>
	<symbol alt="narrow">↑↑↑</symbol>
</currency>

然後在其他語系可能還有直接使用 currency code 的，所以至少就有四種，而根據 LDML（這份 zh-Hant.xml 文件的格式），其實可以根據這個 ¤ 字元重複的次數，來決定要如何顯示該貨幣符號，詳見下表：

不過其實在 zh-Hant.xml 當中，搜尋到的所有的貨幣數值的 pattern，都只有一個 ¤，所以理論上應該都是一樣的用 standard currency symbol，但是實務上似乎比較少真的直接用到這特性，而是透過設定更改的比較多，在 JavaScript 的 Intl.NumberFormat 的 style option 中有一個 currencyDisplay 的設定可以用來改變貨幣符號的顯示方式，有 code、symbol、narrowSymbol、name 這四種，並沒有用到不同數量的 ¤ 的 pattern。深究其原理，其實 Intl.NumberFormat 底層就是 Unicode 官方的 ICU，而 ICU 則是透過 Unit Width 這個選項來調整，實作似乎是在替換時根據不同的 unit width 選用不同的值，而不是修改 pattern。而 Intl.NumberFormat 也就是透過設定 Unit Width 來達成的，結果就是，如果沒有直接使用 ICU 手動設定 pattern，似乎是不會真的用到多個 ¤ 的模式，不過這其實也太細節了，我也不是非常熟悉，所以只能說個大概。

最後想介紹的，就是 CLDR 其實還提供了不少的補充資料(supplemental)，舉幾個比較有趣的：

• 領土 to 貨幣 的對照表；
• 同上一頁的第二章表則是各個貨幣的小數點後位數 （這我記得 ISO 也有一份）；
• 各個領土的資訊，例如使用的日曆系統、每週是星期幾開始、人口、GDP 等；
• 各個語言的範例字母，像中文就是「字」、日文是「か」、韓文是「가」。

接前篇，第九天天氣不太好，一早雨就不小，一時忘了確認本來安排好的行程，結果就漏掉本來要去的甜點店き花の杜 壺屋，不知道還有沒有機會再去旭川啊，真是扼腕。

美瑛有展示全部的えぞみくじ，這邊的是米袋：

美瑛神社：

美瑛神社的祈福烏鴉：

然後就到處打發時間，去了美瑛車站、富良野チーズ工房、Furano Marche 和四季彩之丘，不過花季還沒到就是。

跑來跑去的途中可以看到遠遠的十勝岳很漂亮，不過這是天氣剛好讓山形更明顯，不然後面沒被雲霧遮住的時候沒這麼樣的三角形，前幾天的十勝川溫泉的十勝川就是這邊流下去的，山上其實也有十勝岳溫泉。

晚餐是臨時找的 MASAJIN 富良野店，不過因為沒有預約老闆說可以幫我們約下一批，所以就先跑去王子飯店旁邊的ニングルテラス(Ningle Terrace、精靈露台)，這邊的 Ningle 雖然翻譯為精靈，不過其實不是起源於西方的故事，而是日本作家倉本聰的小說，想知道長怎樣的可以看他們以前出的 photo story。

晚餐挑 MASAJIN 就是為了成吉思漢燒肉啦，旭川沒吃到大黑屋還好這邊有吃到，很好吃。

超好吃的馬鈴薯，中間黑黑的似乎是鹽昆布：

第九天晚上住的是小木屋 Log Cotage Himawari，是這趟唯一的民宿，上面拍到狐狸的地方也在這附近（而且我還拍到狐狸怎麼叫），內部空間還蠻夠的，不過相機不太好拍就是，整體而言也還不差，而且有附早餐，又離富田農場超近。

第十天第一個景點就是富田農場啦，主打就是薰衣草，因為住的近很早就到，明明是還沒開門時間停車場就一堆車了，而且後來人還越來越多，不過這邊還是蠻不錯的，比起四季彩之森，我更喜歡這邊，也買了不少薰衣草產品。

午餐去 Furano Burger，然後飯後繞去錦山天満宮買えぞみくじ，這邊很特別是要操作吊車抓的：

然後還逛了旁邊的...俗又大碗的超市「産直生鮮市場」

之後就去三井 Outlet 購物，晚上則是住薄野的 VESSEL HOTEL，為的就是有名的早餐，不過會挑這間其實是因為中島公園的沒空房了，直接講結論，有點後悔，主要是因為這邊的空間太小人很多，用餐用的不太舒服，應該不強求要吃 VESSEL HOTEL 的早餐的，不過千金難買早知道。

然後接下來的第十天，因為還有車子可以用，所以就想排個近郊的景點，本來是安排北海道神宮然後去吃 Chocolatier Masále 本店，結果旅途中發現有個定山溪溫泉也很近而且可以划船，好像是當天早上才打電話預約，剛好接電話（多語服務）的還是台灣人，所以還蠻順利，總之就改成跑去那邊了，要是早這樣安排就會改成住定山溪會更好。

午餐隨便找了間點心店吃，然後就準備回程，不過為了讓小孩睡覺我還先開去札幌湖才繞回去札幌市，札幌湖是好像是因為蓋了定山溪水壩才形成的，開車過去的路還穿過水壩正上方，蠻特別的，在水壩的正中間還有一個定山溪水壩堤頂展望台，不過這段沒有地方可以停車，觀光客要到這個地方要去水壩下游那邊有個園區有個停車場，然後爬樓梯上來，有機會的話蠻想來挑戰的，不過就算沒這樣跑，沿主要道路走札幌湖也有五個展望台，我這次照片主要其實是在第一個拍的，這邊才看得到水壩，湖景也是很美的，回來研究的時候有看到有人拍到秋天湖面很平靜都是倒影的，更加漂亮。

之後終於再次往札幌前進，接下來幾天就都住在札幌市內，旅館是狸小路商店街中間的 Via Inn，位置很方便而且也不貴，最後一天就是直接拉行李去大通公園搭巴士去機場，走路的路程也還好，蠻推的。

接下來幾天就是札幌市區了，比較沒特別行程，跑了 Pokemon Center、狸小路商店街從頭到尾、走到札幌車站來回、島村樂器、根室花丸壽司、DONGURI 麵包店、藻岩山 山頂展望台等。

其中狸小路商店街，一共有七段，這是我第一次從頭走到尾，最後的７丁目真的很特別，風格遽變，看起來窮很多，其他區的天棚甚至還是可以打開的：

然後這趟也有特別找一家パフェ(parfait)吃，選的店家是パフェ、珈琲、酒、佐藤，不過當初在規劃的時候看同個地址的地標變成佐藤堂，去現場才搞清楚，佐藤堂是他們新開的甜點品牌，現在這個地址一樓是佐藤堂，要內用吃パフェ要到樓上。

最後一天一早就去大通公園等巴士，事前就有先來勘查過，其實選機場巴士去機場就是會很怕沒位子就慘了，不過這站是蠻前面的站所以還好，結果巴士也沒坐滿，總之如果順利的話搭機場巴士去機場是會比搭火車地鐵輕鬆的，不用辛苦搬行李找地方放和換車等。

順利的到達最後一天的景點：新千歲機場，飛機是下午六七點，我們早上十點多就到機場了，結論就是時間不夠！我們去集印章、逛一個小博物館、看雪初音展覽、買一些商品（熱門商店隊伍很長都放棄）、然後去拿完美行的商品，還忙到商店區都沒拍照，結果最後還是很接近時間才到登機門，最後有一個通道上的專門店像是小叮噹、ROYCE 等幾乎都是快速走過沒辦法停下來看，還有下次的話我要前一天晚上先來機場住！

最後的最後就放上一張這次拍到的一張我很喜歡的照片吧。

接前篇，第五天一早就是先去地獄谷周遊一下：

然後就出發前往今天的目標帶廣了，有點概念的就知道這距離很遠，這一天也是我這趟要開最久的一天，所以是午餐前就出發了，午餐是中途下高速高路找的一間在荒野中的拉麵店：MACHIHAZURE T&F」，評分還不差而且真的也還不錯吃，位置其實比較靠近新千歲，因為繼續往東前進就會好一大片都是未開發的地方了。

到帶廣後的第一站就是六花亭本店了，特別來就是為了去二樓的咖啡廳吃甜點。

六花亭本店的商品超級多，拍了一大堆之前沒看過的東西，像是洋芋片，冷藏商品，還有很好笑的紀念品等：

第五天晚上住的是離市區十分距離的十勝川温泉 観月苑，一泊二食加上各室溫泉，泉質我很喜歡（美人湯、弱鹼性、水呈黑色、泡完滑滑的），面十勝川的風景也不錯，加上餐點也蠻好吃的，而且還有煎過的干貝，在北海道要吃到有調理過的干貝真的是太難了！總之這天的住宿體驗是非常好的。

第六天早上就是去帶廣神社和車站附近逛逛加午餐，在帶廣神社才發現他們北海道有神社的聯合籤叫えぞみくじ（蝦夷御籤），每個神社都有他不同造型的籤可以代回家作紀念，帶廣的是「魔鮭福鱒」！

午餐則是吃車站附近有名的豚丼：豚丼のぶたはげ

飯後就開始繼續往東了，這一天的目標是阿寒湖，不過半路開始天氣就變差了，接下來幾天也都不再是藍天白雲的好天氣了。

阿寒湖溫泉街那邊就開始會看到野生動物了，這一天就看到兩次：

晚餐也是找街道上的餐廳，分數還不錯的 味心，運氣不錯坐到最後一桌，後面還有客人老闆就說滿席了，然後才發現這些比較小的日本餐廳好像不太會說還要等多久，而是直接說沒位子了

晚飯後去了 KAMUY LUMINA，很特別的體驗，但是環境是超級低光所以沒什麼照片，有機會的話值得參加一次：

隔天早上一早就去搭遊湖的船，然後逛了下愛奴文化傳承創造館，在阿寒湖アイヌコタン的商店買了紀念品後，就離開繼續往東移動，這一天的目標是這次旅程的最東端：摩周湖，看到照片的時候就超級想來的，結果天數夠就安排下去，午餐是先到摩周車站前的食堂と喫茶 poppotei，是小有名氣的店，餐點也都蠻好吃的，在這邊我們還有遇到台灣來騎腳踏車的團客，有保母車還有預約餐廳這樣，之前比較沒接觸過，不過好像蠻多人會去日本這樣騎行挑戰的。

飯後，終於要前往此行中我最期待的摩周湖了，真的像是在夢中一樣：

大概和我十多年前去到千圓鈔票拍攝的地點一樣夢幻吧...

總之，就只能繼續行程，往北去網走了，網走真的是氣溫特別低，這一天線跑去網走神社買えぞみくじ，這邊的是可愛的雪天使：

這天晚餐也是沒安排，本來想說去超市買東西吃就好，結果走著走著經過一間網走啤酒的燒肉店好像超吸引人，可是完全沒位子，真是可惜，有安排來網走的人可以考慮定個位。

隔天早上的行程就是定番的博物館網走監獄了，我當然是因為黃金神威的關係，不過來之前就聽說小朋友會很喜歡，結果，沒想到，是真的！！！我到現在還是不理解。

逃獄王白鳥由榮

離開監獄博物館後，就要開始往西回札幌方向了，往西回程的第一站是旭川，這一天也是要開車很久，不過還特別有繞去北見神社買えぞみくじ，到旭川後先跑去 BigBan 二手店逛一下，超大，照片都看不到另外一頭了。

還有很多漫畫二手書，可惜我現在實體書買很少了：

然後第八天晚上是住旭川JR酒店，這間也是很方便，一樓就是 AEON 超市，只是我那天沒注意到有超市，而且因為 AEON 商場營業到晚上九點的關係就急著隨便吃了晚餐，但是其實一樓的 AEON 超市有到晚上十點，如果有先搞清楚就會直接去超市就會改變一下行程了，不過可能變成兩餐都吃超市。

超市蠻好逛的，整面的果醬：

有經過本店但是沒進去的柳月（不過有在小樽的店光顧吃冰）：

第九天開始請見 [Part 3][part-3]

[part-3]"https://blog.othree.net/log/2025/12/06/2024-hokkaido-3/

去年安排了一趟北海道的旅行，主要的目標是吃吃，沒有特別想獨立抽出來的分享的部分，所以就分幾篇貼照片加流水帳紀錄一下吧。行程一開始的規劃大致上如下：

Day # Trip 
16  1 小樽
17  2 小樽
18  3 洞爺湖
19  4 登別
20  5 十勝川温泉
21  6 阿寒湖
22  7 網走
23  8 旭川
24  9 富良野
25 10 札幌
26 11 札幌
27 12 札幌
28 13 札幌
29 14 家

第一天到新千歲機場後，稍事整理之後，就去搭乘函館本線直奔小樽，過札幌之後火車路線基本上是很靠近海邊的，中間還經過一個朝里站，車站本身古色古香之外，海景也很不錯，而且我還發現有些日本人特別在這站下車，回來查了一下，果然是個小有名氣的車站，冬天看起來很漂亮，不過我們搬著行李也不可能跑下去，所以我就是特別拍下車站名稱而已：

然後之後就到達小樽了，其實我上次大約十年前來北海道時，就有來小樽，當時是和我媽跟團，雖然停留時間沒很久但是就已經很喜歡這邊了，所以這次特別安排在這邊住兩天，還住比較貴的 Nord 小樽酒店運河側房間。照片的小樽車站是晚上拍的，到達時天還沒黑：

運河旁的 Nord 酒店，很顯眼：

Nord 小樽酒店位置很好，車站走的到的位置，又在運河出名那一個區段的其中一邊的大路口，不過河加海景沒有讓人很驚艷到，加上這幾天的活動路線都會在晚上跑去車站對面的唐吉訶德，後來覺得其實住在車站對面的 Dormy Inn 似乎也不錯。

第一天沒去有名的堺町通り商店街，就是附近簡單繞繞，去找晚餐而已，晚餐就吃有名的若鶏時代 なると 本店：

食物還不差，可以體驗看看，小可惜是當時不知道他們有自己的可樂，好像也是名物。飯後就去唐吉訶德逛了一下然後回飯店睡覺，接著隔天早餐，其實應該說這兩天的早餐都在 Komeda 咖啡解決的：

在店內還翻到一本雜誌介紹了東京迪士尼樂園的票價變化：

吃完早餐後就去旁邊從倉庫改成的小樽市総合博物館 運河館參觀，這博物館的主題很明確，就是介紹小樽市的歷史和週邊的生態，參觀後才知道其實小樽是北海道開發初期時重要的港口，運河就是當時為了運貨而修建的，可以看到很多歷史資料、地圖、文物等：

博物館外觀，靠近這一半邊現在沒使用，中間紅磚的是商店，博物館是比較遠的那一半：

還有就是在北海道真的很容易看到黃金神威的海報：

接著就去運河和小樽堺町通り商店街了：

堺町通是我上次就非常喜歡的點，只是那時候跟團，時間很短，根本無法好好逛，只有逛了六花亭、音樂盒和北一硝子，這次終於可以慢慢的從頭走到尾了，非常開心。

這次沒吃到的雪印パーラー：

午餐的万次郎：

各個漂亮的建築：

之後走回旅館休息一陣子後，晚餐出去覓食，途中不小心經過北海道毛巾株式會社，一下子就買了好幾千日幣：

晚餐吃屋台村紅磚橫丁的炭す Grill：

然後一樣亂逛，去唐吉珂德後就回旅館了：

地方的動漫畫專門店：

第三天早上就要去租車開始移動了，本日目標是早上去余市酒廠、然後下午去洞爺湖那邊，晚上就是住在洞爺湖，余市酒廠因為沒有預約到參觀導覽，所以只能去後面的商店和博物館，結果因為不熟跑去正門，找停車位時發現旁邊旁邊有余市宇宙紀念館，剛好也在他們的休息站旁邊，這個休息站超小的名稱很特別叫： 道の駅 スペース・アップルよいち （太空蘋果）。

小孩看到宇宙自然就不受控制，結果花了一個多小時在裡面，展品沒特別亮眼，但是打發小孩是蠻不錯的，會在這邊有一個宇宙紀念館，其實是因為日本第一次上太空的太空人之一的毛利衛是余市出身的，所以比較像是地方的資金營運的，很多展品是手工製作的，一年還有三次特別的紙模型製作教學活動。

參觀完宇宙紀念館，因為已經中午就先跑去吃午餐了，吃的是柿崎商店 海鮮工房的海膽，可以看到我那碗要 4320+580JPY，其實單價還是不低，只是在台灣要吃到這樣的只會更貴，甚至是吃不到，所以還是吃下去了。

飯後在樓下商店逛一逛，然後就到余市酒廠的博物館和商店，買了些工廠限定的商品和酒回去當伴手禮：

接著就往第三天的目標洞爺湖前進了，途中特別小繞去「羊蹄のふきだし湧水」裝了些水。

這一天住的是在山上的 Hotel COCOA，風景很好但是一定要自駕才到的了，從溫泉街開上來大概要十五分，不過是全山路，我們有先跑去溫泉街那邊晚餐還有散步，太陽下山了才移動回來，日本的山路幾乎都沒路燈，雖然不是第一次開日本郊區的路，但還是真的蠻可怕，奉勸大家日本自駕要盡量避免晚上在郊區移動。

洞爺湖溫泉街那邊勉強找到一間有營業的餐廳，然後看夕陽看湖，之後逛了乃之風的開放區域（商店很大），之後就摸黑開車回旅館，到房間還剛好可以看到煙火。

隔天早上天氣超好，去了 Lake Hill Farm 吃吃買買和休息，這個地點可以看到超大的羊蹄山，沒錯，就是羊蹄山戰鬼裡面的那座。

之後去搭有珠山纜車，可以看到昭和新山的上面，從下面看很漂亮的山形，到上面一看就漏氣了：

我沒去找到可以拍完整洞爺湖的位置，不過去另外一邊可以看到隔海對面的景色也是很棒：

之後回了洞爺湖邊的 HLAHAL 吃湯咖哩，這間風景好而且食物又好吃，大推！

飯後就出發前往第四天住的登別了，我們住的是登別第一滝本館，除了多種溫泉之外，還有游泳池可以讓小孩玩得很開心，而且裡面很大，到處逛逛也很有趣，後來晚餐也是在館內解決，其實本來是要吃溫泉街上的餐廳，但是只有一兩間而且剛好公休。

第五天開始請見 Part 2 (WIP)

不知不覺就要將近一年沒有發文章了，其實我自我認知是我進入了一個有點長的鬱期，加上還有很多其他事務把我的空閒時間都用掉了，結果就都沒花心思在這塊，連帶的去年和今年的兩趟日本的遊記都沒寫完，第二趟的照片連整理都沒有，技術文章也是一些題目都放著沒進展，其實我這些狀況還沒改變，但是今天還是鼓起動力寫了文章，因為最近有朋友驟逝。

其實這一年身邊一直有些和死亡有牽連的消息和體驗，先是有一位朋友死門關前走了一遭，不過還好恢復很順利，不過我知道已經是事後了，而且他人不在台灣所以真的還沒什麼實感；接著在我暑假帶小孩出遊時，突然聽到在 HTC 時的前同事 Bingo 過世的消息，當下也是很震驚，我還記得共事時期他給人的形象是很健康開朗的陽光男孩，還是個會去衝浪的人，特別有印象的是有次我去日本買到了豐天商店的衣服，結果他看到超喜歡，後來自己去日本買了超多件，幾乎每天都穿不同款上班。

接著我自己健檢的時候因為要作腸鏡胃鏡，結果我脹氣加退麻醉痛苦了兩三天，我是屬於退麻醉會非常不舒服的人，不舒服到連滑手機都沒辦法，滑一下頭就痛起來；然後脹氣不舒服這件事，我覺得很多人可能沒體會過，其實是可以不舒服到讓人生不如死的，我就曾經一次脹氣整天不舒服到去急診，後來打針強迫腸胃蠕動，這次則是知道原因但是只能等時間過去，只是時間很長，這兩三天的時間我大概有點體會到那種重病末期痛苦無法緩解想要求死解脫的心情，只是因為我知道我還會恢復，所以還能撐下去。

順便宣導一下，千萬不要對嘴巴或肛門灌氣，真的很容易會死人的，新聞很多。

然後就是最近的孩雅多學長過世的消息了，其實週一消息傳開當天我有點忙碌，不過還是看到兩位社團學長發了不知所以然的文，直到我當天忙的差不多才看到朋友轉貼 lordmi 的 plurk 文才知道，當下也是不敢相信，因為週末前我才回他的文，然後過了一個週末就跟我說他已經過世了...

接下來兩天，我大概就是只要閒下來就會想到這件事情，然後過幾天就找找看手上有沒有以前拍到他的照片，結果意外的少，一個原因是因為他也是會拿著相機到處跑的人，而我和他共同會拿相機出現的場合其實不多，我算是他畢業後才開始有相機玩，而且那時我還不太會想到要幫攝影師拍照（後來在研討會擔任攝影紀錄時我就會加減幫其他攝影師或是工作人員拍照），最後挑了第一張照片出來。

因為他是在我認識的人當中，對遊戲的熱情最高的人，畢業後去遊戲公司，甚至在大學時他並不是程式人，但是現在卻已經可以擔任遊戲程式了，而且一直都很關注遊戲業界的發展，我一直都有在看他轉貼的遊戲新聞，所以這幾天到現在，只要有牽扯到遊戲，不管是新作上市，有趣的新聞，甚至是自己要開遊戲來玩，都會覺得無限惋惜。

剛好在那幾天，我在看縱使星辰殞落，妳仍在歌唱 這本小說，很巧也是講到死亡的事情，其實我以前是不太能理解為何有些人會想要在死前，在世界上留下自己的痕跡，經過這一年的洗禮下來我或許比較能體會了，至少我目前的想法是，因為死亡不可避免（扣除在追求永生的那些人），所以會想讓自己的存在以其他形式留存，不過認真說真的很難，人只要不在了，就算能在歷史上留名，那名字也不太會對正在活上是上的人們產生什麼影響力，甚至是親近的人也必須為了在世上活著而不斷的做著每天的工作，無法只沉浸在緬懷故人，其實就算扣除內容是牽扯到死亡這件事之外，其實這本書另外一個主軸我覺得他也會有興趣，算是個我有想推薦給他的小說，真的是太讓人惋惜了。

最後想說的是，其實是想給還不到 40 歲的人看的，不過不知道讀者群裡面有多少比例就是，總之，就是如果有人跟你說「過 40 開始身體會明顯變差，身邊有人會開始離開。」他們說的是真的！把握時光！保持健康！

最近在研究九州行程，然後去翻以前去過的照片，看到十年前（2015）年時去九州順便從 Amazon 買的：鳥部製作所的廚房剪刀，這隻剪刀其實我現在還在用，品質很好，以前好像推薦過一次，現在十週年了值得再推薦一次，也順便又研究了一下現在到底該怎樣買。

鳥部製作所其實是以金屬加工出名的燕三条地方的工廠之一，產品品項不多，其中這隻廚房剪刀一直以來評價都很高，設計簡單俐落，而我當初挑選的條件其中一個就是要可以拆開來清洗，然後加上看起來很好看，就買下去了，結果真的不負期待，品質極佳，用到現在十年過去也沒感覺到有什麼老化跡象，當然，我每次使用後都會拆開清潔。

現在鳥部製作所網站上的定價雖然是寫 ¥5500，不過在 Amazon 上是找不到這個價位的（在樂天也是），不確定是產地價和通路價差異，還是這兩年貨幣貶值加上通膨已經調價了但是網站沒更新，然後現在在 Amazon JP 上找到我判斷比較可靠的有兩個：

• ASIN:B001GU01BG
• ASIN:B0C5X5CWT2

第一個賣 ¥7700 是標準版本，第二個賣 ¥8800 則是拋光過變亮面的版本，兩個賣家不一樣，第一個是村の鍛冶屋、第二個則是 NAGAO，兩家都是燕三条地方的公司經營的，看起來商譽都還 ok，至於我十年前買的時候，應該是 Amazon 自己的貨的樣子，價格則只有兩千多日圓，後悔當時沒多買幾把啊 🥲。

（圖是日本的四個季節不同版本的封面）

可能會捏到的感想！上市一陣子了，本來是想要找個好日子幫書拍照後才發表，不過實在拖的有點久了，剛好又找到上面那張圖，就決定拿來用了。

總之還是多一行警告一下XD！

然後仔細研究一下發現日版是一年前出版的了，所以最近常見日本的印刷出版品利用這特性或許就是這本書帶起的風潮。

回到閱讀體驗這件事上，其實在我意識到這件事情之後，我聯想起作者另外一本我剛好前陣子才在看的輕小說「樂園 NOISE」，在第一集第一段就有提到女主角當時追求的是現實上不可能存在的無雜音的音樂，男主角後來用電腦生成無雜音的音源讓女主角實際有機會聽到自己演奏出的無雜音的音樂，要知道作者描寫音樂的文字是評價很高的，但是這邊卻完全沒有無雜音音樂的形容（一部分是因為用耳機主角自己沒聽到），但是其實也給讀者一個懸念，好想聽聽看比比看所謂無雜音的音樂啊。

或許只是想太多，不過或許，世界上最透明的故事 那個奧妙的緣起其實就從樂園 NOISE 提到的那個無雜音音樂，只是他用不是音樂的方式傳達給讀者了。

最後想談談這本書本身，「光是能出版，就稱得上是奇蹟了。」這件事，要我形容的話，這本書就像是我們現在看的一些文藝復興時代的藝術品，在工藝上達到一個時代登峰造極之下的產物，未來的人看到只會覺得「太精緻，做的太巧妙了吧，難以想像用現在的人力要做出一樣的東西」一般這樣，足以作為代表紙書時代的一本書。

補一些連結：

• 編輯的介紹文，當時我是因為看到這篇才下單的，順便補了幾本放購物車內好久的書，剛好在缺貨前下單完成
• 譯者的介紹文

最後列上人名 作者：杉井光 譯者：簡捷 責編：菜承歡

突然想到漏了一件事，這就一定要看過才知道了，就是那個最後那個詞，我以為是謝謝你來到這個世上之類的溫馨想法，結果看到有人說是謝謝你給我這個點子，思考一番後覺得後者比較對，因為對兩個人來說都是成立的想法，不過就比較冷血一點就是。

btw 作者收到中文版，還有確定要出續集了。

世界でいちばん透きとおった物語、台湾版の見本誌をいただきました。
完璧な形で作っていただいたこと、ただただ感謝と敬服です。 pic.twitter.com/PD2GP2eq6j

-- 杉井光 (@hikarus225) October 10, 2024

『世界でいちばん透きとおった物語2』、来年の1月末発売です。続編は今年中に出す、と各所で言っておきながら原稿が遅れまくって今年中に間に合いませんでした。申し訳ない......https://t.co/Xq3E1CJsOJ

-- 杉井光 (@hikarus225) November 25, 2024

mariadb-dump: Got error: 1932: "Table 'blog.mt_asset' doesn't exist in engine" when using LOCK TABLES

而且因為我的 shell script 太簡單，沒檢查結果，這錯誤還把我的本地備份覆蓋掉了😂，總之搜尋研究一陣子之後，發現這問題是因為 mt_asset 資料表是用 InnoDB，然後 InnoDB 有些資訊是集中在 ibdata1 的，不能只靠資料庫目錄下的 mt_asset.* 檔案來還原，結果我的作法就是把備份的 ibdata1 還原回來，試著在 my.cnf 裡加上:

[mysql]
innodb_force_recovery = 1

如果用 service 的話就要放到 [mysqld] 區段內，數值從 1 試到 6，然後 su 到 mysql 這個帳號下手動執行 mariadbd 指令來啟動資料庫，其實第一次嘗試是失敗的，到第二次試到 6 時才成功，然後趕快跑 mysqldump，結果有成功跑完，不過因為之前 mt_asset 有出過錯誤，我就認真檢查了一下 dump 出來的資料，結果果然， mt_asset 只有結構沒有資料，於是又檢查其它的 InnoDB 資料表的 dump 的輸出，結果是有的有資料有的沒有，不過由於資料本身應該還在，所以我接著嘗試用 mariadb 命令列模式進去 DB 手動 SELECT mt_asset 的資料，發現真的都還在，不知道為何 dump 會失敗，不過總之我就試試看死馬當活馬醫，用 mysqldump 匯出單一個資料表的資料：

mariadb-dump -u user_name -p db_name mt_asset > blog.mt_asset.sql

結果，竟然成功匯出了，於是就手工把每個有問題的 InnoDB 匯出，然後手工整合回去全資料庫的 dump 出來的 sql 檔案，有些資料表還是沒資料，不確定是不是本來就沒有的，不過看起來也不是重要資料，不影響 MovableType 運作，所以就不管。

然後因為我好像用不太到 InnoDB 的優點，加上發生過一次這種事情，冷備份比較簡單的 MyISAM 還是比較適合我，就順手都改成 MyISAM 資料表；同時，又想到因為我的 CHARSET 還是用 utf8，所以一直都還不能用 emoji，之前也有想過要換到 utf8mb4，只是一直沒動手，就趁機一起手工改了 mt_entry 表下的幾個相關的欄位：

`entry_title` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`entry_excerpt` text CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`entry_text` text CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`entry_text_more` text CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT NULL,

這樣大致上就把 sql 檔案準備好了，回到這次發生問題的原因，我推測是用 pacman 更新套件時，更新到 MariaDB 後，不知道為何造成 ibdata1 檔案損毀，一開始的錯誤訊息試有看到說某個檔案是 MariaDB 10.4.8 建立的，所以我是先退回 10.4.8 然後才進行上述的修正，還好上次已經操作過一次了，之後為了避免再次有太久沒更新出事，就決定也要把 MariaDB 更新一下，所以其實是先更新最後才把 sql 檔案匯入的。

更新完把 /var/lib/mysql 目錄下的 ibdata1、ib_logfile0、ib_logfile1 都砍掉，重新建立資料庫後才匯入，還好一切順利，詳細的說明其實在 MariaDB 的 Knowledge Base 也都有，最後就補上兩個我覺得很有幫助的文件：

• Cold Backup: 一樣是 MariaDB 的 Knowledge Base 的官方文件，有提到 InnoDB 要冷備份時要備份哪些檔案；
• Tag: InnoDB: Error: tablespace id in file: 一篇說明如果這時候要直接還原 InnoDB 資料表的話要怎樣弄，非常麻煩（網站已死，所以是 Internet Archive 的）。

另外補充，如果要在 MovableType 4.x 使用 emoji，除了資料庫欄位的設定外，還需要修改一點程式碼，詳見我的修改紀錄 🥳。

在現在這個網路標準橫行的時代，要遇到還沒廣泛標準化的東西其實是越來越難了，不過我最近還是遇到了一個，那就是 autofill 的偵測。

首先要說的是，autofill（自動填入）和 autocomplete（自動補完）嚴格定義下是不一樣的，雖然都可以透過 autocomplete 來控制相關的行為，但是 autocomplete 其實只能算是 autofill 的一種，而我遇到的就是非 autocomplete 的，信用卡資料的自動填入，那問題在哪呢？

問題就是這種 autofill 發生時，瀏覽器不一定會觸發 change/input 事件，如果表單設計成自動檢查表單輸入，然後輸入都正確才讓人送出的話就會有使用體驗的問題發生，因為這種設計的欄位檢查通常就是綁在 <input> 的 change/input 事件上，結果就是如果瀏覽器自動填入，然後又沒觸發 change/input 事件，於是就不會執行到欄位檢查，表單也就會一直維持在無法送出的狀態，產生的副作用就是使用者體驗反而比按下送出按鈕才作表單檢查還要來的差。

那麼在 Web 標準中，change 事件應該何時觸發的定義是為何呢？在 HTML 4.01 是這樣寫的：

The onchange event occurs when a control loses the input focus and its value has been modified since gaining focus. This attribute applies to the following elements: INPUT, SELECT, and TEXTAREA.

按照古時候網路標準的規範，autofill 不是使用者和 DOM 之間的互動，沒有經過 focus blur，所以沒有觸發 change 事件也是合理，事實上也就是現在部分瀏覽器的行為；不過在現在的 HTML Living Standard 是這樣寫的：

The change event fires when the value is committed, if that makes sense for the control, or else when the control loses focus.

觸發的時機除了失去 focus 時之外，還多了資料 commit（提交）時，變成兩種時機，而這邊的提交主要指的是像 type=color 或是 type=date 那種，瀏覽器有支援，有提供另外頁面內的小工具讓使用者方便挑選值的時候，使用者選好，瀏覽器更新值進入 <input> 的 value 的動作，那 autofill 更新值該算是 commit 嗎？其實文件內也是有講到的，就在同個章節的後面：

When the user agent is to change an input element's value on behalf of the user (e.g. as part of a form prefilling feature), the user agent must queue an element task on the user interaction task source given the input element to first update the value accordingly, then fire an event named input at the input element, with the bubbles and composed attributes initialized to true, then fire an event named change at the input element, with the bubbles attribute initialized to true.

這段就是說當瀏覽器代表使用者改變 input 的值時，也是要發一個 input 一個 change 事件，這段文字的重點在於 "on behalf of the user"，就是「代表使用者做事」，後面舉的例是 prefill 時，prefill 通常發生在 帳號/密碼 欄位，發生時間點又不太一樣，可能是在 render DOM 時就發生；不過根據文字解釋其實 autofill 應該也符合 "on behalf of the user"。

雖然 HTML 標準有規範了，但是現實世界總是不會這麼美好，不然也不會有這篇文章了，那麼現實世界是怎樣呢？我遇到的狀況就是有些瀏覽器是照著舊的規範，完全沒有事件，發現問題後我就上網搜尋一番之後發現，這問題其實已經很久了，早在 2010 年，@avernet 就寫了一篇 Autocomplete and JavaScript Change Event，紀錄了當年的這個問題，根據不同欄位、不同瀏覽器會有不同的行為，即使到了今天，也還是同樣情形，文章最後建議的解法也是很無奈的：

1. 關掉相關功能 autocomplete=off
2. 定時檢查

總之就是讓人不喜歡的解法，那麼時至今日，有沒有比較好的方法呢？其實還真的有，而且蠻聰明的，Klarna 的 Tommy Brunn 在 2016 年寫了 Detecting autofilled fields in Javascript 一文介紹了這種方法，透過 CSS pseudo-class :autofill 和 CSS animation 配上 animationStart 事件，首先 CSS 這樣：

input:autofill {  
  animation-name: autofill;
  animation-duration: 500ms;
  animation-fill-mode: both;
}

@keyframes autofill {
  from {
    background: var(--color1);
  }
  to {
    background: var(--color2);
  }
}

然後 JS 監聽事件並確定動畫名稱沒錯，就可以做事了：

inputNode.addEventListener('animationstart', (event) => {  
  const { currentTarget, animationName } = event;
  
  if (animationName === 'autofill') {
    // do what ever you want, or
    // trigger `change` event
    currentTarget.dispatchEvent(new Event('change'));
    // trigger custom event
    currentTarget.dispatchEvent(new Event('autofill'));
  }  
}, false);

完全成為真的 event based，不用定時檢查了，不過缺點是要 CSS 搭配，不是純 JS 的方案，維護上比較麻煩一些，另外就是 Tommy Brunn 文章內用的是 :--webkit-autofill，但是現在完全可以用沒有 prefix 的 pseudo class 了。

以上的程式碼範例就可以處理好瀏覽器內建的自動填入事件，不過現實世界除了瀏覽器內建的自動填入，還有很多的第三方工具支援，像是各種 password manager: 1Password, LastPass, Dashlane 等，這些工具自動填入的行為又不太一樣，我確實有發現有其中一兩家的行為也是 value 會改變，但是不會有 input 和 change 事件，幸好這些工具都會加上各自自訂的 attribute，所以可以另外透過 observer 監看 attribute 的變化來判斷是否有相關的事件，目前我所知道有以下的 attributeName 可以檢查：

• data-dashlane-autofilled Dashlane 的
• data-com-onepassword-filled 1Password 的
• chrome-autofilled iOS Chrome，超容易漏掉

至於 LastPass 目前測試結果是不會有自訂的 attribute，但是會有 change 事件，所以也可以照常運作（不過相對的就完全沒有提供給使用者的視覺提示好像怪怪的）。

這篇內容大概就到這邊，雖然沒有提供很完整的程式碼，不過這些資訊應該很夠幫助其他人完成 autofill 事件的偵測了，其實這次弄信用卡資訊的輸入欄位真是費了不少心力，很多細節可以弄，也很多 domain knowledge（都靠 lib 搞定就是），真是想不到只是信用卡欄位也這麼多眉角。

因為一些搜尋讓我今天才了解 oklch 這個色彩格式（或是色彩空間）的使用方法。這個色彩格式在 2023 年納入了幾乎所有現代瀏覽器，好奇查詢之下發現了作者的 blog 有寫為什麼要製作 Oklab 的原因與研究過程，以及詳細的討論過去 HSV 或 HSL 系的色彩空間到底有什麼問題，收穫滿滿。...

# -- 勞哥 maylogger (@may_logger) July 13, 2024

在介紹 Oklab 前，先來介紹以前提到的 Lab 吧，其實它是國際照明委員會(International Commission on Illumination，簡稱 CIE)在 1976 年提出的色彩空間定義，全名是 CIELAB color space，或是簡寫為 L*a*b*，多加 * 為了避免混淆，Lab 其實是不正確的縮寫，不過這三個字母其實就是該顏色空間的三個軸：L 代表亮度、a 代表紅色到綠色間的位置、b 代表藍色到黃色間的位置，也就是 opponent color theory（又稱對比色理論或色覺對向論）的顏色組成，這個色彩空間的重點在它的座標比較符合人類對色彩的感知。

那 Oklab 又是什麼呢？它是 Björn Ottosson 在 2020 年底發表的一個新的色彩空間定義，他在文章內有詳細的說明為什麼會想要定義一個新的色彩空間，文內也列舉了現存的色彩空間的主要問題，其中 CIELAB 的問題就是在 predict hue （預測色相）有些問題，尤其是藍色附近，其實我一開始對於這個 predict 感到很疑惑，想說到底是什麼意思，後來看到另外一篇文章 An interactive review of Oklab，文章一開始放的互動工具預設的漸層設定就是藍色到白色，然後一看就很明顯， CIELAB 的漸層色相跑一下就歪掉了變成偏紫色去了（random 按鈕可以按按看看其他色相都沒這樣嚴重），才了解到因為 CIELAB 是屬於人類感知的色彩空間，意思就是它的依歸其實是人類的感覺，所以需要從三維座標去推測人類實際上看到感覺到的顏色，數值上一樣的話就應該讓人感覺一致，而 Oklab 則是結構和 CIELAB 一樣，但是透過新的資料集來調整並解決前面提到的問題，而後在 2023，Oklab 進了 CSS Color Level 4 的草稿，主流瀏覽器現在也都已經支援。

進 CSS Color 代表什麼意思呢？第一個當然就是可以用 oklab() 函數來定義顏色了：

oklab(40.1% 0.1143 0.045);
oklab(59.69% 0.1007 0.1191);
oklab(59.69% 0.1007 0.1191 / 0.5);

除了直接定義顏色之外，現在 CSS 也支援相對顏色（relative color）了：

/* Relative values */
oklab(from green l a b / 0.5)
oklab(from #0000FF calc(l + 0.1) a b / calc(alpha * 0.9))
oklab(from hsl(180 100% 50%) calc(l - 0.1) a b)

這樣要只調整色相或是亮度都變得很簡單，或是也可以用 oklch()，這樣色相（Hue）就更好挑選。

然後就是漸層了，現在的 CSS 漸層也支援使用不同的顏色內差方式，也就是用不同色彩空間來算中間的顏色變化：

linear-gradient(in oklab, blue, red)
linear-gradient(in lab to right, #44C, #795)

在最前面加上 in <color-space> 就可以，支援的色彩空間其實不少，如果是線性漸層，那支援 srgb、srgb-linear、display-p3、a98-rgb、prophoto-rgb、rec2020、lab、oklab、xyz、xyz-d50、xyz-d65，如果是 polar 漸層，那支援 hsl、hwb、lch、oklch，其實相當夠用，而這段語法其實是叫 color-interpolate（顏色內插），除了漸層之外，會用到的地方還包括 filter、animation、transition 和 color-mix() 函數等。

前面也已經提到，現在主流瀏覽器都已經支援了，不過還是來看一下 caniuse 上的細節，Chrome 是 2022 就支援了，但是 Firefox 是到去年的 2023 才支援，如果要抓兩年的時間的話就還要再等等，當然現在也還是可以直接用，多加一組 fallback 就可以。

除了瀏覽器原生支援外，其實也不少其它開發相關的工具支援，也有不少文章在介紹，像是 Smashing Magazine 的 Falling For Oklch: A Love Story Of Color Spaces, Gamuts, And CSS 和 Evil Martians 的 OKLCH in CSS: why we moved from RGB and HSL，兩篇文章就介紹了不少工具和一些延伸的文章，工具部分像是 Figma 的 plugin OkColor 和 npm 上的 convert-to-oklch，Evil Martians 還做了一個 oklch.com ，是針對 Oklch 的 color picker 還蠻厲害的。

照片是常滑招財貓大道的「除憂解難」。

沒想到這週這麼熱鬧，前後兩天分別發生兩件和溝通有關的熱烈討論（網路對罵？），第一件事情比較少人知道，是發生在 COSCUP 的 telegram 社群，雖然是公開社群但是因為沒有直接的公開網址所以我就不寫網路 id 了。有社群朋友（後面用 A 代稱）想要辦 BoF 需要一些硬體設備，但是因為今年的 BoF 公告還沒出來，所以他想知道大會方是不是有機會能協助（幫忙借用設備），可以的話就會提出申請，其實如果熟悉 BoF 的應該都知道大會方只有提供場地，不過我當時在開車也沒辦法馬上幫忙回，總之就有其他朋友幫忙回了，四貓作為工作人員也在幫忙釐清對方的需求，當時大概就是有位社群朋友回文時多了一句：

但如果認為大會方該要提供的話，你們預期大會方能從哪搞到這個資源呀

其實這件事有點讓我聯想到「精製動畫坊（HGA）」，非常早期就在台灣經營動畫模型領域的商品，年過四十小時候就有接觸動畫的人可能多少都會聽過 HGA 的大名，黃老闆其實人很好，然後店內也有一群熟客，其實很多人都在圈子內有點名氣，不過就是這群熟客其實也某種程度製造了一個 AT 力場，會讓不在圈子內的人想要進去有阻力，其實我在光顧 HGA 的幾次經驗也沒真的實際接觸到黃老闆以外的那些人，但是我還是要說那個氛圍確實是存在的，有朋友就說是「成也熟客、敗也熟客」。

當然我不是在說 A 的發言都沒錯，A 後來的幾則發言我都覺得這我也很難幫忙緩和了，所以要我說的話，在那個時間點這或許已經是一場無可挽回的難過事件了，不過我還是想說，非當事人的幫忙有時候真的是沒幫上忙啊。

然後隔天發生的另一件事，則是在推特上的「最困難的就是和工程師溝通了！有夠固執不懂變通！」炎上事件了：

這也是位年薪百萬的學員喔！恭喜恭喜！

她說，她現在不只要跨部門討論專案，還得跨國溝通，公司裡什麼樣的同事都有。

「最困難的就是和工程師溝通了！有夠固執不懂變通！」

這是第 N 位跟我抱怨工程師有夠難溝通的學員了。
（我也這麼覺得！）https://t.co/s7jjdgJ4I4

-- Akane Lee (@akane_lee) May 14, 2024

然後推特上一堆工程師就受不了了，紛紛分享出他們遇過的很瞎的溝通經驗或是他們的看法，當然也是有一些比較沒意義的酸文，不過其實有一些蠻值得一讀的，像是海總理的這串（共九則，請點過去看完整文串）：

覺得對方難溝通，大多是因為

「你只想得到你想要的，不想聽你不懂的」

-- 海總理 (@tzangms) May 16, 2024

其實這個炎上事件我覺得是屬於用詞不精確所引發的，因為 Akane 一開始的文字直接使用「工程師」，沒有加上「部分」或是「一些」之類的修飾，就直接被當成是貼標籤，其實她也有提到他有合作過很好溝通的工程師，更何況她的課程也不是溝通課，文章的受眾也不是工程師，這也讓我想到我在研究所寫論文時，有一個眉角就是不能用什麼「最好」、「全部」這種太過絕對的形容，而是要用「最好的之一」、「大部分」等比較相對一點的，因為你永遠不知道你的最好，是不是真的「最好」，或是更直接的利害關係，口試前你永遠不知道口試委員有沒有知道你沒查到的資料；當然，或許就算一開始的文字就有修飾過，也無法完全避免這件事情生，Ash 是這樣說的：

看大家討論這麼熱烈，大家在職場上真的都是傷痕累累呢。我們都是帶著過去的傷痕去跟下一段新的職涯邂逅。

有時候你覺得同事很尖銳，但他針對的可能並不是你，而是整個環境或者他的過去。

-- Ash Wu (@hSATAC) May 15, 2024

然後我才發現原來這已經是工程師的集體創傷了嗎？難怪大家反應這麼大，後來還有說到「男性說教（mansplaining）」這我就覺得不太行，不過她還提到收到的回饋是女性工程師普遍比較好溝通，所以我也實在很難說到底是什麼狀況，畢竟我不是當事人，不過確實在這個圈子要說完全沒有性別差異/問題也是不可能，只是這到底算不算是「男性說教」，我就真的很存疑了，畢竟這也沒有客觀的計量方式來判斷，畢竟我才發生過跟親近的人解釋一些事情，之後發現他完全沒聽進去，然後才了解到：「啊，我剛剛被認為是在男性說教。」

最後還是來分享點比較有趣的東西吧，Huli 趁機也重貼了一個老影片「The Expert」：

這影片其實我也很久以前就看過了，只是沒想到下面 Tzeng Yuxio 貼了另一個真正的專家完美達成上面的需求的過程：

十年前的解答我今天才看到！

同場加映：剛好昨天在 FB 的「陳名珉」粉絲專頁有這麼一篇文章，是在講傳統市場的變化，其實追根究底也是溝通的需求在哪一端的問題（海總理的那串）。

週末帶小孩去松山菸廠意外發現到「SEE DIFFERENT 看見不同的學習風景」這個展覽，心中實在是有些想法和感觸想分享，首先先來介紹一下這個展覽吧：這個展覽其實是「第二屆教科圖書設計獎」的得獎作品，沒錯，是教科書，國中國小的教科書的設計展！而且不只是視覺上的設計，評選的範圍也包含內容的設計，展場展出的就是本屆得獎的教科書們，有一整區是可以翻閱的，只能說現在的教科書和我接觸過的三十年前左右的真的是差很多，除了更加活潑有質感的設計，還有各種清晰的圖表輔助，甚至連內文都變得很好閱讀，很像是在看科普書而不是教科書，深入了解之後，才知道這一切其實要從十年前，也就是 2014 年在 FlyingV 上的「美感細胞的教科書改造計畫」開始，其實我當年也有看到，不過我是沒什麼參與，覺得就是很理想但是很難進入體制內，沒想到，美感細胞默默耕耘十年，加上教育部推動美感教育，還真的推展開來了，教科圖書設計獎都辦到了第二屆，而美感細胞在其中的角色，除了在 FlyingV 上三季的募資計畫，後來還成立社團法人，承接一些政府合作案之外，也持續進行相關研究，發佈了不少的設計報告和參考資料，另外還有一個很重要的角色，就是作為教科書出版社和設計師之間的媒合橋樑，其實教科書的出版不是那麼容易，和一般書籍比起來限制較多，除了內容要送審之外，教育部還有印製規定。

我確實以前也是認為台灣的美感素養真的差很多，而這在各種層面上展現，從平面設計開始像是文宣、廣告設計、然後一些政府機關的公文、表單的排版字體（看過數年前香港的報稅表單，排版和字體真的是比台灣好很多）等等，更進一步到店面、商場設計（像是台北車站站前地下街 K 區的前後對比：誠品 vs 東森）、道路規劃、建築設計、年末的燈飾、街景、古蹟打燈（像是以前台北郵局）等等。台灣一來普遍不重視美感和設計，二來是設計人材也少，尤其是公部門相關的東西更是慘烈，最常被人拿出來講的大概就是國慶典禮的主視覺設計了吧，這幾年的改變確實有目共睹，終於能夠脫離千篇一律的設計風格，然後我才慢慢了解到台灣其實不是沒有設計人材，而是主政者和業主不重視，甚至可能是根據種種不能直說的原因來挑選廠商，當然這也造成了惡性循環，業主不重視、設計師沒案子、願意投入設計領域的人就少；美感細胞的三位創辦人張柏韋、林宗諺和陳慕天在十年前的教科書改造計畫第一季其實就有見到這個問題，見到這個問題的人其實應該不少，但是真的有想面對它處理它的人就少之又少，更何況三人還不是設計相關領域、還在體制之外、當時也還只是大學畢業生，實在相當讓人佩服。

另一個感觸則是體制外到體制內這件事，沒想到在這幾年內可以看到兩件事情真的這樣發生，真的是要感謝現在的主政者願意沒事找事作，這邊提到的教科書質的改變是一個，當然這只是一個手段，真正想要改變的是整體國民的美學素養，這還需要很長時間的發酵；另外一個體制外到體制內的改變，則是報稅軟體，相信這就是大家都有目共睹的了，最早是設計師卓致遠在 Join 平台上提出的，財政部注意到這個問題後也非常重視且積極，才推動了報稅軟體整個大改變，提案人卓致遠當然也不是起個頭就跑走，他也是很積極的參與協助設計改善，一些過程可以參考雨蒼在 2018 年寫的「新版報稅網站是怎麼煉成的？」，唐鳳也在其中出了些力協助溝通，當年她還是政務委員，數位發展部是到 2022 年才成立的，當然數發部的貢獻在基礎建設，所以一些新的認證方式應該也是有其貢獻才得以實現。

然後另外想提的是，美感細胞的那些研究報告內容其實都蠻不錯的，像我主業是前端工程師，但是也一直對平面設計、字體、文字排版等有些興趣，所以這些報告當中的教育字體應用指南、敎科書印製規格提議報吿、易讀設計指南 Guidebook和教材通用色彩應用指南四份我都有看過一遍，內容都蠻不錯的，都從問題和背景開始就做了很詳細的介紹，報告本身的編排和一些輔助的圖表也都弄的很清楚，可以看得出來花了不少心力要讓報告本身可以自證其述（self-hosting?）；另外還有一本在會場有展出的「翻開下一頁➝NEXT PAGE教科書風格創新趨勢研究探討」，則是以教科書近年來的變化為主題，還介紹了第一屆的教科圖書設計獎的得獎作品，這本的出版則是台灣設計研究院，也就是展覽的主辦單位，不想下載的話其實以上這幾本也都有放到 issuu 平台上，可以參考以下連結：

• 美感細胞
• TDRI 台灣設計研究院

最後補一個 中央社 文化+ 的專題報導「聽說課本不一樣」，還有這次展覽我最喜歡的教科書封面：

在 blog 這詞最為蓬勃之時，很流行在自己的網站上放各式各樣的 banner，這些 banner 種類用途很多，像是顯示你網站使用了甚麼技術、你想幫忙宣傳的東西、網站連結、甚至是一些自我的主張表現或是可以稱為無用小廢物（像是日本放置協会，又簡寫為 NHK）的都有，我以前也放了不少，不過最後留下來的就只有兩個，第一個是 MDN 的推廣貼紙，第二個則是「時間のないサイト運営者リング」，沒時間的站長串連，這張 banner 我看到的第一眼就很喜歡，有很符合個人狀況所以我放了很久，從 2007 年五月開始就一直放著，也有連結回去，直到前陣子整理網站的時候才發現，當初連回的串連網站已經死掉了！然後我就花了些時間尋找替代方案。

考古研究了一下，時間のないサイト運営者リング的網址也變動過不少次，後來可能是為了一勞永逸，所以轉移到 Google Site，當時網址是：

https://sites.google.com/site/happybusy/

只是沒想到在 Google Site 2023 年二三月之間的一次版本整合之後，網站就不見了，然後根據 internet archive 上的資料，找到當初原作者是一位筆名叫「すか」的繪師兼漫畫家，不過商業連載不多，同人社團叫「しろくま屋」（白熊屋），在 melonbook 也還有賣東西，然後還發現以前還有賣周邊，然後在推特上也找到另外一個站，路徑不一樣：

https://sites.google.com/view/happy-busy/

雖然在すか的推上沒有承認也沒有否認，不過應該是原作弄的，最有參考性的是這串推文：

時間のないサイト運営者リングサイトのドメイン
happy-busyは私が考えました（笑

-- すか@えりまき (@skysuka) September 19, 2023

大概就是他畫了新的圖，然後還挑了 happy-busy 這個名字，發文時間是 2023 年九月，當時新站也已經上線了一陣子了，只不過到今天新圖也沒擺上去就是。總之，雖然沒有很直接的承認，加上新站也沒也什麼詭異的跡象，我就還是把連結改過去了。

文章最後，還是想來感嘆一下日本真的很多閒人（稱讚的意味），各種古老冷門數位資料的收集整理非常多，連這些網站 banner 都有人整理，而且資料還留存到現在，像是這份「消滅した主張系同盟ウェブサイトリングの一覧」就列出了一堆已經消失了的個人主張系網站串連（Web ring）。

{
	"properties": {
		"id": { "type": "string" },
		"createdAt": { "type": "timestamp" },
		"karma": { "type": "int32" },
		"isAdmin": { "type": "boolean" }
	 }
}

JSON Typedef 的作者是 Ulysse Carion，當時在 segment.com 工作，不過在講到他之前，要先來提另外一位在 AWS 工作的 Tim Bray，他常常要處理 AWS 服務間的事件，這些事件都是 JSON 資料，然後有很多種事件，整體而言是 discriminated union(tagged union)，中文有翻譯為可辨識聯合或是標簽聯合，那這是什麼東西呢？簡單舉例，在 DOM 裡面的事件，滑鼠 click 事件會有點擊的座標，鍵盤 keydown 事件則會有按下的按鍵，這兩個事件都有一個 type 屬性，簡單的 TypeScript 定義長這樣：

type ClickEvent {
  type: 'click';
  offsetX: number;
  offsetY: number;
}

type KeydownEvent {
  type: 'keydown';
  keyCode: number;
}

然後 Event 則是兩種的聯集：

type Event = ClickEvent | KeydownEvent;

這時，如果有支援的工具就可以透過判斷 type 屬性的值來知道該物件應該是長什麼樣子，但是就是沒有，當然也不用說更進一步用 schema 驗證收到的事件資料，他也在 2018 年九月寫了一篇 JSON Scheming 講到這件事情，也說明了為什麼無法用 JSON Schema，除了不支援 discriminated union 這個主因之外，還有錯誤訊息不好和沒有 code generation 可用。

之後，Carion 在 2019 年四月，在 IETF 的 json mailing list 發了一封信，想要找人一起協作開發一個 JSON 的 schema 語言，他遇到的問題是他常常用 JSON-RPC，然後這些 RPC 協定的 request/response 本身也和 AWS 團隊要處理的那些 events 一樣是 discriminated union，然後一樣檯面上沒有好用的工具和語言可以用來作資料檢查，Carion 那封信件後面的回應有些人提了一些 prior arts，像是我從來沒聽過的 JSON Content Rules（網站已死），還有 JSON 的二進位版超集：CBOR 和用來描述 CBOR 資料的 CDDL，CDDL 也可以用在 JSON 資料結構上，也已經是 RFC 標準了，不過 CDDL 是一個完全不同的語言，要使用它要從 parser 開始導入，會困難並且慢很多，隨便找一個 CDDL 範例：

PersonalData = {
  ? displayName: tstr,
  NameComponents,
  ? age: uint,
  * tstr => any
}

然後五月的時候 Carion 提交了第一版的 Internet-Draft 到 IETF 了，當時使用的名稱叫 JSON Schema Language，不過因為會和 JSON Schema 混淆，所以後來就改名成 JSON Data Definition Format（簡稱：JDDF），然後等到正式發布時則又改名為現在的名稱：JSON Type Definition，至於為何會是 Independent Submission 呢？其實是因為 IETF 的 JSON-WG 早早就已經關閉了，只是 mailing-list 還一直開著，可以讓人討論，但是已經不能透過 JSON-WG 發佈新文件了，這時不是走獨立提交，那就是要另外找一個或開一個 WG，就會有一些行政流程要跑，其實現在很多的 JSON 相關的 RFC 文件，都是有各自的 WG 來處理，像是 JSONPath 就有開一個 jsonpath WG

最後正式版的 JSON Typedef 達成了 Carion 一開始的目標，支援 discriminated union（到這個時間點 JSON Schema 還沒法這樣簡單的支援）以及很容易就可以做出 code generation 的特性，Carion 還自己實作了數個語言的支援，例如 JavaScript 生態系就是可以生成 TypeScript type definition，例如以下的 schema：

{
    "discriminator": "eventType",
    "mapping": {
        "USER_CREATED": {
            "properties": {
                "id": { "type": "string" }
            }
        },
        "USER_PAYMENT_PLAN_CHANGED": {
            "properties": {
                "id": { "type": "string" },
                "plan": { "enum": ["FREE", "PAID"]}
            }
        },
        "USER_DELETED": {
            "properties": {
                "id": { "type": "string" },
                "softDelete": { "type": "boolean" }
            }
        }
    }
}

可以自動轉成：

// Code generated by jtd-codegen for TypeScript v0.2.1

export type Event = EventUserCreated | EventUserDeleted | EventUserPaymentPlanChanged;

export interface EventUserCreated {
  eventType: "USER_CREATED";
  id: string;
}

export interface EventUserDeleted {
  eventType: "USER_DELETED";
  id: string;
  softDelete: boolean;
}

export enum EventUserPaymentPlanChangedPlan {
  Free = "FREE",
  Paid = "PAID",
}

export interface EventUserPaymentPlanChanged {
  eventType: "USER_PAYMENT_PLAN_CHANGED";
  id: string;
  plan: EventUserPaymentPlanChangedPlan;
}

然後 TypeScript 也支援這樣定義的語法，我最近特別喜歡用 switch 來處理這種東西，TypeScript 都會幫你判斷好變數的型別：

switch (event.eventType) {
  case 'USER_CREATED':
    // event type is EventUserCreated
    break;
  case 'USER_DELETED':
    // event type is EventUserDeleted
    break;
  default:
    // blah blah
}

當然 JTD 也可以用來驗證資料，除了 Carion 自己實作的之外，另外還有一套 ajv 支援 JSON Typedef，不過如果是表單驗證，我自己是沒那麼推薦，我目前表單通常會是用 react-hook-form 和 Zod，一個原因是 JTD 不太有擴充性，而且也沒有太多什麼奇妙的型別，都是很基本的型別，所以沒有 email、ip、url 那種 pattern 形式的驗證，至於我推薦表單檢查用 Zod 除了它比較容易擴充自訂的檢查之外，還有其他原因，其一是它也支援 discriminated union：

const myUnion = z.discriminatedUnion("status", [
  z.object({ status: z.literal("success"), data: z.string() }),
  z.object({ status: z.literal("failed"), error: z.instanceof(Error) }),
]);

另一個原因就是 ow 的作者 @sindresorhus 也推薦用 Zod 了XD。

回到 JSON Typedef，其實使用起來還是有一點隱憂的，主要的隱憂就是怕之後就沒人用了，一來使用族群不大，二來是 Carion 那些套件都很久沒更新了，他本人後來也跑去創業了，大概也沒時間來故這些東西了吧，所以要不要用 JTD 也只能自己承擔後果了吧，不過都做為正式 RFC 文件發佈了，我覺得應該是不會慘到哪去啦。