O3noBLOG
BlogBlog.Club 名單自動收錄·資料來源與計算方式 ⓘ
- 收錄文章
- 15篇
最新收錄
本頁 15 篇
Unicode CLDR 與貨幣數值格式
其實一直以來都有點好奇，像 Intl 這種可以根據語系格式化輸出數字、貨幣數值或是日期等資料的工具函數，它的資料集到底是哪裡來的？會很好奇是因為這其實是一個多對多的組合，不同的語言地區配上不同的貨幣，算起來每種資料格式都要維護一組數量不小的組合，例如我想要用法文或英文顯示 10000 新台幣要用怎麼顯示呢： // zh-Hant $10,000.00 // fr 10 000,00 TWD // en-US NT$10,000.00 可以看到有很多點不一樣，首先數字格式的部分，可以看到小數點符號、千位數的分隔符號都不一樣；然後是貨幣符號，可能放前面可能放後面，中間可能會有空白（而且是 NBSP），然後根據不同組合可能會用短的貨幣符號，也可能用長的或是完整的貨幣代碼。作為比較，同樣的三組語系，如果改成顯示歐元則是： // zh-Hant €10,000.00 // fr 10 000,00 € // en-US €10,000.00 可以明顯看到，相同的語系顯示不同的貨幣數值，也有不一樣的格式設定，證實了它確實是一個多對多的關係，現在 ISO-639 有規範到的語言有 183 個，ISO
2024 北海道 Part 3
接前篇，第九天天氣不太好，一早雨就不小，一時忘了確認本來安排好的行程，結果就漏掉本來要去的甜點店き花の杜 壺屋，不知道還有沒有機會再去旭川啊，真是扼腕。 總之接下來就往南要經由美瑛富良野去札幌了，首先第一站因為下雨就直接跑去旭川神社買えぞみくじ，然後再去美瑛神社買。 美瑛有展示全部的えぞみくじ，這邊的是米袋： 美瑛神社： 美瑛神社的祈福烏鴉： 然後就到處打發時間，去了美瑛車站、富良野チーズ工房、Furano Marche 和四季彩之丘，不過花季還沒到就是。 跑來跑去的途中可以看到遠遠的十勝岳很漂亮，不過這是天氣剛好讓山形更明顯，不然後面沒被雲霧遮住的時候沒這麼樣的三角形，前幾天的十勝川溫泉的十勝川就是這邊流下去的，山上其實也有十勝岳溫泉。 晚餐是臨時找的 MASAJIN 富良野店，不過因為沒有預約老闆說可以幫我們約下一批，所以就先跑去王子飯店旁邊的ニングルテラス(Ningle Terrace、精靈露台)，這邊的 Ningle 雖然翻譯為精靈，不過其實不是起源於西方的故事，而是日本作家倉本聰的小說，想知道長怎樣的可以看他們以前出的 photo story。 晚餐挑 MASAJIN 就是為
2024 北海道 Part 2
接前篇，第五天一早就是先去地獄谷周遊一下： 然後就出發前往今天的目標帶廣了，有點概念的就知道這距離很遠，這一天也是我這趟要開最久的一天，所以是午餐前就出發了，午餐是中途下高速高路找的一間在荒野中的拉麵店：MACHIHAZURE T&F」，評分還不差而且真的也還不錯吃，位置其實比較靠近新千歲，因為繼續往東前進就會好一大片都是未開發的地方了。 到帶廣後的第一站就是六花亭本店了，特別來就是為了去二樓的咖啡廳吃甜點。 六花亭本店的商品超級多，拍了一大堆之前沒看過的東西，像是洋芋片，冷藏商品，還有很好笑的紀念品等： 第五天晚上住的是離市區十分距離的十勝川温泉 観月苑，一泊二食加上各室溫泉，泉質我很喜歡（美人湯、弱鹼性、水呈黑色、泡完滑滑的），面十勝川的風景也不錯，加上餐點也蠻好吃的，而且還有煎過的干貝，在北海道要吃到有調理過的干貝真的是太難了！總之這天的住宿體驗是非常好的。 第六天早上就是去帶廣神社和車站附近逛逛加午餐，在帶廣神社才發現他們北海道有神社的聯合籤叫えぞみくじ（蝦夷御籤），每個神社都有他不同造型的籤可以代回家作紀念，帶廣的是「魔鮭福鱒」！ 午餐則是吃車站附近有名的豚丼：豚丼のぶたはげ
2024 北海道 Part 1
去年安排了一趟北海道的旅行，主要的目標是吃吃，沒有特別想獨立抽出來的分享的部分，所以就分幾篇貼照片加流水帳紀錄一下吧。行程一開始的規劃大致上如下： 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 家 基本流程就是新千歲進出，第一天到機場後直接火車搭到小樽，然後在那邊住兩晚後租車開始繞一圈，最後回到札幌還車，然後三四天市區行程，最後一天就去機場。接下來就來介紹這趟旅程吧： 第一天到新千歲機場後，稍事整理之後，就去搭乘函館本線直奔小樽，過札幌之後火車路線基本上是很靠近海邊的，中間還經過一個朝里站，車站本身古色古香之外，海景也很不錯，而且我還發現有些日本人特別在這站下車，回來查了一下，果然是個小有名氣的車站，冬天看起來很漂亮，不過我們搬著行李也不可能跑下去，所以我就是特別拍下車站名稱而已： 然後之後就到達小樽了，其實我上次大約十年前來北海道時，就有來小樽，當時是和我媽跟團，雖然停留
HayatoS
不知不覺就要將近一年沒有發文章了，其實我自我認知是我進入了一個有點長的鬱期，加上還有很多其他事務把我的空閒時間都用掉了，結果就都沒花心思在這塊，連帶的去年和今年的兩趟日本的遊記都沒寫完，第二趟的照片連整理都沒有，技術文章也是一些題目都放著沒進展，其實我這些狀況還沒改變，但是今天還是鼓起動力寫了文章，因為最近有朋友驟逝。 其實這一年身邊一直有些和死亡有牽連的消息和體驗，先是有一位朋友死門關前走了一遭，不過還好恢復很順利，不過我知道已經是事後了，而且他人不在台灣所以真的還沒什麼實感；接著在我暑假帶小孩出遊時，突然聽到在 HTC 時的前同事 Bingo 過世的消息，當下也是很震驚，我還記得共事時期他給人的形象是很健康開朗的陽光男孩，還是個會去衝浪的人，特別有印象的是有次我去日本買到了豐天商店的衣服，結果他看到超喜歡，後來自己去日本買了超多件，幾乎每天都穿不同款上班。 接著我自己健檢的時候因為要作腸鏡胃鏡，結果我脹氣加退麻醉痛苦了兩三天，我是屬於退麻醉會非常不舒服的人，不舒服到連滑手機都沒辦法，滑一下頭就痛起來；然後脹氣不舒服這件事，我覺得很多人可能沒體會過，其實是可以不舒服到讓人生不如死的，
鳥部製作所 廚房剪刀
最近在研究九州行程，然後去翻以前去過的照片，看到十年前（2015）年時去九州順便從 Amazon 買的：鳥部製作所的廚房剪刀，這隻剪刀其實我現在還在用，品質很好，以前好像推薦過一次，現在十週年了值得再推薦一次，也順便又研究了一下現在到底該怎樣買。 鳥部製作所其實是以金屬加工出名的燕三条地方的工廠之一，產品品項不多，其中這隻廚房剪刀一直以來評價都很高，設計簡單俐落，而我當初挑選的條件其中一個就是要可以拆開來清洗，然後加上看起來很好看，就買下去了，結果真的不負期待，品質極佳，用到現在十年過去也沒感覺到有什麼老化跡象，當然，我每次使用後都會拆開清潔。 現在鳥部製作所網站上的定價雖然是寫 ¥5500，不過在 Amazon 上是找不到這個價位的（在樂天也是），不確定是產地價和通路價差異，還是這兩年貨幣貶值加上通膨已經調價了但是網站沒更新，然後現在在 Amazon JP 上找到我判斷比較可靠的有兩個： ASIN:B001GU01BG ASIN:B0C5X5CWT2 第一個賣 ¥7700 是標準版本，第二個賣 ¥8800 則是拋光過變亮面的版本，兩個賣家不一樣，第一個是村の鍛冶屋、第二個則是 NAG
世界上最透明的故事
（圖是日本的四個季節不同版本的封面） 可能會捏到的感想！上市一陣子了，本來是想要找個好日子幫書拍照後才發表，不過實在拖的有點久了，剛好又找到上面那張圖，就決定拿來用了。 總之還是多一行警告一下XD！ 其實因為宣傳關鍵字的關係，加上最近有不少日本印刷品有用到這特性（像是獵人、還有報紙廣告），我一拿到書就發現其中奧妙了，不過其實這個奧妙讓我閱讀時的體驗，也確確實實的和其他紙書不一樣，簡單的形容，就是視野內的畫面特別乾淨、明亮，不過這些形容又太過強烈，思考了一陣子，確實用「透明」來形容非常適合，甚至我覺的作者杉井光在撰寫時，文句的挑選可能也有為了呼應「透明」而下了不少功夫，結果就是這個「透明」的主軸其實延伸到各個地方：故事主軸、文章風格、出版形式、閱讀體驗都有，要稱為世界上最透明確實當之無愧。 然後仔細研究一下發現日版是一年前出版的了，所以最近常見日本的印刷出版品利用這特性或許就是這本書帶起的風潮。 回到閱讀體驗這件事上，其實在我意識到這件事情之後，我聯想起作者另外一本我剛好前陣子才在看的輕小說「樂園 NOISE」，在第一集第一段就有提到女主角當時追求的是現實上不可能存在的無雜音的音樂，男主
InnoDB 修復紀錄
前兩天意外發現 blog 的資料庫（MariaDB）死掉起不來了，加上我剛好沒有新的備份，所以這兩天就花了些時間慢慢修復，總之首先，我根據一開始的錯誤訊息大概搜尋了一下，發現說可以把 /var/lib/mysql 目錄下的 ibdata1、ib_logfile0、ib_logfile1、aria_log_control 等檔案砍掉試試看（當時完全不知道是什麼），於是我簡單備份後就砍掉重啟試試看，結果 MariaDB 真的就復活了，只是我接著要跑 mysqldump 時就出現其他的錯誤： 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.* 檔案來還原，結果我的
onAutofill
在現在這個網路標準橫行的時代，要遇到還沒廣泛標準化的東西其實是越來越難了，不過我最近還是遇到了一個，那就是 autofill 的偵測。 首先要說的是，autofill（自動填入）和 autocomplete（自動補完）嚴格定義下是不一樣的，雖然都可以透過 autocomplete 來控制相關的行為，但是 autocomplete 其實只能算是 autofill 的一種，而我遇到的就是非 autocomplete 的，信用卡資料的自動填入，那問題在哪呢？ 問題就是這種 autofill 發生時，瀏覽器不一定會觸發 change/input 事件，如果表單設計成自動檢查表單輸入，然後輸入都正確才讓人送出的話就會有使用體驗的問題發生，因為這種設計的欄位檢查通常就是綁在 的 change/input 事件上，結果就是如果瀏覽器自動填入，然後又沒觸發 change/input 事件，於是就不會執行到欄位檢查，表單也就會一直維持在無法送出的狀態，產生的副作用就是使用者體驗反而比按下送出按鈕才作表單檢查還要來的差。 那麼在 Web 標準中，change 事件應該何時觸發的定義是為何呢
Oklab Color Space
2019 年的時候，寫過一篇文章介紹了 Lab Gradient，然後就沒特別關注相關發展，直到前幾天看到勞哥的推文提到 Oklab 這個色彩空間，而且瀏覽器已經原生支援了，我才發現原來網路標準的發展有跟上來，我也趁機多惡補了一些相關的知識。 因為一些搜尋讓我今天才了解 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 其實是不正確的縮寫，不過這三個字母其實就是該顏
溝通
照片是常滑招財貓大道的「除憂解難」。 沒想到這週這麼熱鬧，前後兩天分別發生兩件和溝通有關的熱烈討論（網路對罵？），第一件事情比較少人知道，是發生在 COSCUP 的 telegram 社群，雖然是公開社群但是因為沒有直接的公開網址所以我就不寫網路 id 了。有社群朋友（後面用 A 代稱）想要辦 BoF 需要一些硬體設備，但是因為今年的 BoF 公告還沒出來，所以他想知道大會方是不是有機會能協助（幫忙借用設備），可以的話就會提出申請，其實如果熟悉 BoF 的應該都知道大會方只有提供場地，不過我當時在開車也沒辦法馬上幫忙回，總之就有其他朋友幫忙回了，四貓作為工作人員也在幫忙釐清對方的需求，當時大概就是有位社群朋友回文時多了一句： 但如果認為大會方該要提供的話，你們預期大會方能從哪搞到這個資源呀 其實我覺得 A 一開始的文字並沒有這樣的意思，但總之結果這段文字就激起 A 的情緒了，然後就口氣變差，出現了一些情緒回文，接著就變成 A 和一些其他社群朋友開始互吵，其中心穎四貓和我其實都有想要幫忙緩和一下，不過雙邊都沒想要暫停一下，所以就一發不可收拾吵了整個下午，總之直到最後都還是有些情緒文字。
看見不同的學習風景
週末帶小孩去松山菸廠意外發現到「SEE DIFFERENT 看見不同的學習風景」這個展覽，心中實在是有些想法和感觸想分享，首先先來介紹一下這個展覽吧：這個展覽其實是「第二屆教科圖書設計獎」的得獎作品，沒錯，是教科書，國中國小的教科書的設計展！而且不只是視覺上的設計，評選的範圍也包含內容的設計，展場展出的就是本屆得獎的教科書們，有一整區是可以翻閱的，只能說現在的教科書和我接觸過的三十年前左右的真的是差很多，除了更加活潑有質感的設計，還有各種清晰的圖表輔助，甚至連內文都變得很好閱讀，很像是在看科普書而不是教科書，深入了解之後，才知道這一切其實要從十年前，也就是 2014 年在 FlyingV 上的「美感細胞的教科書改造計畫」開始，其實我當年也有看到，不過我是沒什麼參與，覺得就是很理想但是很難進入體制內，沒想到，美感細胞默默耕耘十年，加上教育部推動美感教育，還真的推展開來了，教科圖書設計獎都辦到了第二屆，而美感細胞在其中的角色，除了在 FlyingV 上三季的募資計畫，後來還成立社團法人，承接一些政府合作案之外，也持續進行相關研究，發佈了不少的設計報告和參考資料，另外還有一個很重要的角色，就
時間ねぇ
在 blog 這詞最為蓬勃之時，很流行在自己的網站上放各式各樣的 banner，這些 banner 種類用途很多，像是顯示你網站使用了甚麼技術、你想幫忙宣傳的東西、網站連結、甚至是一些自我的主張表現或是可以稱為無用小廢物（像是日本放置協会，又簡寫為 NHK）的都有，我以前也放了不少，不過最後留下來的就只有兩個，第一個是 MDN 的推廣貼紙，第二個則是「時間のないサイト運営者リング」，沒時間的站長串連，這張 banner 我看到的第一眼就很喜歡，有很符合個人狀況所以我放了很久，從 2007 年五月開始就一直放著，也有連結回去，直到前陣子整理網站的時候才發現，當初連回的串連網站已經死掉了！然後我就花了些時間尋找替代方案。 考古研究了一下，時間のないサイト運営者リング的網址也變動過不少次，後來可能是為了一勞永逸，所以轉移到 Google Site，當時網址是： https://sites.google.com/site/happybusy/ 只是沒想到在 Google Site 2023 年二三月之間的一次版本整合之後，網站就不見了，然後根據 internet archive 上的資料，找到
JSON Type Definition
之前工作上需要，想要一個簡單的可以檢查 JSON 資料結構的工具，研究了一陣子，發現到了 JSON Type Definition（簡稱 JSON Typedef 或是 JTD） 這個 RFC 標準，相較於發展已經很久的 JSON Schema，JSON Typedef 的語法簡潔不少： { "properties": { "id": { "type": "string" }, "createdAt": { "type": "timestamp" }, "karma": { "type": "int32" }, "isAdmin": { "type": "boolean" } } } 光是看不到 $ 那種 meta 屬性的前綴就覺得簡潔不少，然後官網上也提供了幾個常見程式語言的實作，接著我在看 RFC 文件的時候，發現到文件的分類是 Independent Submission，這就讓我好奇了起來，於是就花了不少時間了解前因後果。 JSON Typedef 的作者是 Ulysse Carion，當時在 segment.com 工作，不過在講到他之前，要先來提另外一位在 AWS 工作的