搜尋之後發現有人說可以用 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

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

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

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

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 家

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

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

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

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

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

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

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

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

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

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

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

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

• ASIN:B001GU01BG
• ASIN:B0C5X5CWT2

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

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

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

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

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 的應該都知道大會方只有提供場地，不過我當時在開車也沒辦法馬上幫忙回，總之就有其他朋友幫忙回了，四貓作為工作人員也在幫忙釐清對方的需求，當時大概就是有位社群朋友回文時多了一句：

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

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

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

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