每本書，都是一扇任意門。

3 個電子書閱讀器選購重點，建立你的掌上圖書館！

Sat, 13 May 2023 18:37:53 +0000

如果你是一個喜歡閱讀的人，那麼你遲早要面對以下問題：

該不該投資一台閱讀器、在哪個平台買書、以及買哪一款閱讀器呢？

不管你有多麽喜歡紙本書，新書的氣味、翻頁時紙頁摩擦的聲音、捧在手裡閱讀的真實感。在你的書櫃再也放不下多一本書的時候，你不得不重新審視自己對於紙本書的浪漫情懷和執著。在你準備出國工作時，紙本書的重量與存在感，在行李箱有限的空間中顯得過份強烈。

於是你想到了電子書閱讀器。這個看似完美的解決方案，不僅方便攜帶、螢幕不傷眼，還能裝得下幾百本書。

但是搜尋了一下就會發現，電子書的平台很多，閱讀器也很多，有不同的尺寸和封閉式/開放式的差別。剛想轉型電子書，就深陷電子化的難題。

本篇文章將從以下 3 個方向探討，來拆解對於紙本書的浪漫情懷，以及電子化難題所帶來的矛盾。總結出我自己買書、以及閱讀器的策略。

紙本書與電子書的優缺點比較
電子書平台選擇
電子書閱讀器選擇

紙本書與電子書的比較：

首先，我們來比較一下紙本書和電子書的差別，以及各自的優缺點，作為是否該購買電子書的考量因素。

優點

紙本書

傳統的閱讀體驗、有收藏感、可以快速翻閱、有機會找到絕版的書。

電子書

易於攜帶、不佔空間、多本書切換閱讀、可跨裝置閱讀。

閱讀電子書 5 年多，我覺得紙本書無法被電子書取代的優點是「可以快速翻閱」和「有機會找到絕版的書」。

關於可以快速翻閱這一點，我在第一次閱讀一本書的時候，會先看封面、封底、作者、譯者的資訊，了解這本書想解決的問題、想表達的觀點。接著看作者序和目錄，從目錄中挑出感興趣的章節來回翻閱，這樣可以很快知道自己是不是需要這本書。拿起一本長時間沒有看的書時，也可以用同樣的方式快速撿回記憶。

在閱讀時常常會讀到作者推薦的書單，或是受到哪本書啟發之類的內容。有時候這些書太舊了，電子書平台沒有上架，紙本書也絕版了。這時候就可以去「TAAZE讀冊生活」或是圖書館，找到這些酷書！

而電子書的優點，真的就是把「方便」這一點做到極致。即使每天閱讀，一個禮拜也只需要為閱讀器充一次電。在這個出門要帶行動電源的時代，「一個禮拜充一次電」的電子產品，真的像是坐時光機回來的產物。

缺點

紙本書

佔空間、不易攜帶、須注意保存環境。

電子書

不適合有彩圖的書、翻頁卡頓、頁數是相對的、購買的電子書數量多，優點才會明顯。

紙本書的缺點，跟它的優點是一體兩面的存在。而電子書的缺點比較需要說明一下。因為電子紙的特性和成本考量，目前的閱讀器翻頁時需要刷新時間，在讀者看起來就是卡頓，彩色的電子紙的色階也無法顯示令人滿意的彩圖。

因為電子書的字體大小、橫排直排可以自由調整，所以頁數是相對的，同一個章節，在大尺寸的閱讀器上是 10 頁，在小尺寸的閱讀器上，可能是 30 頁。剛轉換到電子書的時候，需要習慣一下。

如果要有掌上圖書館的感覺，帶著所有想看的書到處走，同時緩解書櫃空間，需要在電子書的數量大到一定程度之後，效果才會明顯。

適合的書籍特性

紙本書

有大量圖片、需經常查閱的工具書（e.g. 程式書籍）。

電子書

流式電子書、較不適合版式電子書。

流式電子書指的是文字大小、橫排直排可以自由調整的電子書格式。版式電子書則是像 PDF 檔案那樣，每一頁像是固定的圖片，文字和排版無法自由調整的電子書，多用於圖片很多的書籍如雜誌、漫畫、電腦書。由於版式電子書無法調整字體和畫面大小，因此建議在大尺寸的閱讀器上閱讀。

閱讀體驗

紙本書

有研究顯示文字固定位置有助於記憶。（我也覺得有一點）

電子書

調整直／橫排、行距、字體、畫線、搜尋等功能、app 化的閱讀體驗。

關於買書

紙本書

確認內容符合預期再購買，不易踩雷。

電子書

購買前無法翻閱，易踩雷、容易買太多、可購買外文書。

逛實體書店會有種尋寶的感覺，可能會遇見你平常不會涉略的知識和觀點。雖然書籍的陳列，是基於書店想主打哪些書，但是注意書架的最上層與最下層，還是能避開一些「別人幫你選書」的影響。現場翻閱確認書中的內容是自己需要的再購買，也比較不容易踩雷。

而在電子書平台的網站上買書，就完全是在演算法的支配下行動了。不過還是可以善用搜尋功能，直奔你確定要買的那本書。如果是在網站上看過書籍簡介就出手，踩雷的機率偏高，也容易一次買太多本書。

如果有 Kindle 的話，Amazon 電子書提供了我們接觸英文世界第一手資訊的機會，有些書要出中譯本不知道還要盼望多久。

二手轉賣

紙本書

可以。

電子書

不可以。

因為你購買的電子書，是綁定你的電子書平台帳號的，所以無法將電子書轉賣二手。如果有將書籍轉賣二手的習慣的話，需要審慎考慮這一點。

一句話總結

紙本書

傳統之最。

電子書

相見恨晚。

我在 2017 年的時候，入手了第一台電子書閱讀器，讀墨初代的 MooInk。那時候第一份工作派駐到深圳工作，正在煩惱要怎麼帶書去看的時候，剛好台灣第一家電子書平台 Readmoo 讀墨出現了。我真的是喜出望外，馬上開始了電子化之旅。而閱讀也成為了我當時的避難所，在一開始還不會網路翻牆的時候，有一個和自由中文世界的通道。

後來有想看的書我一律買電子書，如果看完之後很喜歡，再買紙本書收藏。除非是需要反覆翻閱，或有很多彩圖的書籍才買紙本書。這是我在對於紙本書的浪漫情懷和電子化的難題中，找到的平衡點。

書籍購買策略

結論是：有電子書就買電子書，需要反覆翻閱、或有大量彩圖的書買紙本書。如果看完電子書很喜歡，再買紙本書收藏。

將書本視為資訊的載體，區分實用價值與收藏價值。

如果說閱讀是為了獲得新知、建立知識體系。那藉由使用電子書，我們就有了強大的能力像是：調整直／橫排、行距、字體、畫線、搜尋等功能，來建立自己的私人掌上圖書館。

如果說一本書吸引人之處，除了文字內容本身還包含了封面、封底設計、文字排版，精美的印刷和裝幀。那購買紙本書，才能夠體驗到它完整的價值。

電子書是為了補足紙本書無法提供的閱讀體驗而生的，紙本書和電子書各自擅長處理的體驗本來就不一樣。所以該買紙本書還是電子書，最終還是回歸到讀者自身的需求。

以我來說，我主要是想要從書本中獲得資訊，因此我選擇的做法是：有電子書就買電子書，需要反覆翻閱、或有大量彩圖的書買紙本書。如果看完電子書很喜歡，再買紙本書收藏。

電子書閱讀器選購重點

平台

選購電子書閱讀器，和買房子一樣有三個重點（買房子是地點 * 3）

平台！！平台！！平台！！

因為你所購買的電子書，是綁定你在電子書平台的帳號之下的，所以集中在同一個平台買書，是比較合理的選擇。因此，選擇有最多你會看的書的平台！

我的選擇是在 Readmoo 讀墨上購買中文書，因為它是繁體中文書籍最齊全的電子書平台，也是一個獨立的電子書平台。

Readmoo 專注於開發好用的 App 和網站，同時也推出自己的電子書閱讀器，做到完美的軟硬體整合。我覺得他們的網站和 App 介面好看又好用，常常會採納讀者的建議加入新功能或是修改 Bug。

英文的書籍則毫無懸念地是在 Amazon 上購買 Kindle 電子書，考量到閱讀英文書籍是一項長期投資，所以我也入手了一台 Kindle 閱讀器。

在一開始做選擇的時候，雖然有把樂天 Kobo 列入考量，因為它同時有中文、英文、日文的書籍，但是因為各項語言的書都不是最齊全的，可能會面臨想看的書明明在讀墨或是在 Amazon 上都有，但就是 Kobo 上面沒有的窘境。因此我很快就把 Kobo 排除，選擇投資在個別語言書籍最齊全的平台上。

封閉式、開放式閱讀器

由各家電子書平台自行推出的閱讀器，稱為封閉式閱讀器，因為只能在該平台的書城購買和閱讀電子書。

而可以藉由安裝各家電子書平台 App 來閱讀的閱讀器稱為開放式閱讀器。你可以把它想成一台搭載電子紙的 Android 平板，上面還可以裝瀏覽器、LINE 等等其他的 App。

我會建議第一台閱讀器買封閉式的，因為跟自家平台整合，閱讀體驗一定是最好的，不會有像是在滑一個卡卡的 App 的感覺，甚至是跑版的情況。當然如果想要一台閱讀器可以看所有的平台（e.g. 讀墨 + Kindle），也是可以買開放式的閱讀器。

尺寸

閱讀器尺寸可以概略分為小尺寸和大尺寸兩種。

小尺寸（6～8吋）：優點是方便攜帶，適合外出、通勤時閱讀。缺點是螢幕小需要頻繁翻頁（會感受到卡頓），或是要把字體調小一點。

大尺寸（10～13吋）：優點是螢幕大閱讀體驗舒適，不用頻繁翻頁。大多有結合筆記功能。缺點是不方便攜帶。

我覺得閱讀器尺寸的選擇，非常看重使用情境。以我為例，當初入手第一台閱讀器，是希望可以在出國工作時、搭飛機、搭車時都可以閱讀，因此選擇了小尺寸的閱讀器。

而現在在台灣，在家時會使用大尺寸的閱讀器來閱讀，外出時會隨身攜帶一台小尺寸的閱讀器。

解析度

主流的解析度是 300 dpi，文字顯示非常細膩，再怎麼近看也像是印刷在紙上一般，完全看不到鋸齒。有一些主打低價的閱讀器，會犧牲一些解析度到 150 dpi 左右，雖然不影響閱讀。但是看過 300 dpi 就會發現，沒比較沒有傷害，真心建議一開始就買 300 dpi 以上的機型，不然可能會後悔。

另外，彩色的電子紙，為了做 RGB 的 cell，會降低解析度到 150 dpi 左右，但是彩色的畫面看起來，還是比黑白的 150 dpi 新潮太多了啊。

黑白、彩色

彩色看起來是很新潮，但絕對達不到令人滿意的標準。因此建議第二台閱讀器開始，想嚐鮮再買彩色的吧。

彩色的電子紙看起來像這樣：

閱讀燈

最後一個閱讀器選購重點，閱讀燈！我覺得超重要的！在光線不足的地方，像是沒開檯燈的房間，或是星巴克角落的座位，閱讀燈會拯救你的眼壓！

小尺寸的閱讀器，可能因為使用情境本來就是外出，所以都配有閱讀燈。需要注意的是大尺寸的閱讀器，使用情境是在家裡，為了輕薄的外型，有時候會沒有閱讀燈，需要注意！

另外，閱讀燈又分為冷光（白光）與暖光（黃光）。建議是買兩種都有的，比較可以自己調整到最舒適的狀態。

我的主力閱讀器

Readmoo 10.3 吋 mooInk Pro

讀墨在 2022 年初推出的中大尺寸的閱讀器，重點是它是白色的，所以我就馬上就買了。mooInk Pro 是我的第一台大尺寸的閱讀器，現在在家中都使用它來看書。

必需大力稱讚的是讀墨的開發團隊真的很細心，mooInk Pro 的開/關機鍵、Home 鍵，都設計在不會誤觸，但又很好按的位置。

反觀 2019 年版的 Kindle 的開機鍵，還是在機身下方，而且是凸起的設計，超容易誤觸的！Amazon 做閱讀器都 10 幾年了耶······。

Boox 6 吋 Poke4 Lite

我換過好幾台外出用的閱讀器，終於在 2023 年初，遇見了我心目中理想的閱讀器了！超小台，放得進我的外出小包，開放式，可以看讀墨和 Kindle。而且它是白色的！唯一美中不足的是它的解析度只有 212 dpi。

雖然我一直很認同毛姆的這句話，不過在使用了電子閱讀器這麼久之後，我看見了我的避難所是白色的！😂☝🏻

閱讀是一座隨身攜帶的避難所 — 毛姆

電子化的浪潮席捲而來，每個人都無法置身事外。選擇讀墨帶你在文字之海中乘風破浪吧！點擊以下連結註冊讀墨會員，30 天內首購享 79 折，60 天內單筆訂單滿額再送 $100 購書金！

立即註冊 👉 http://moo.im/i/DbsBO

6 吋 mooInk S 電子書閱讀器－硯墨黑

售價：NT$4,288

定價：~~NT$ 5,390~~

專屬推薦網址 👉 https://moo.im/a/58ioDS

7.8 吋 mooInk Plus 2C 電子書閱讀器

售價：NT$9,999

定價：~~NT$ 10,999~~

專屬推薦網址 👉 https://moo.im/a/19yMUZ

10.3 吋 mooInk Pro 2 電子書平板

售價：NT$15,099

定價：~~NT$ 17,800~~

專屬推薦網址 👉 https://moo.im/a/blBJKO

2025 時光飛逝的一年

Wed, 31 Dec 2025 17:17:23 +0000

今年一整年保持著一週健身 3 天，有氧 1 小時的好習慣。規律運動、吃健康的食物真的會感受到原始的快樂！

腦內啡釋放和身體變得輕盈的感覺真的超好！怪不得大家都說體態是最好的名片，因為運動真的很花時間。🤣

10 月第一次在國外自駕之旅，去了矽谷找朋友，體驗了美國時間、美國生活。雖然花了很多特休跟錢，但我覺得超值得，因為回憶是會複利的！

我一直認為時間有美化回憶的能力，時間為苦澀的回憶加上濾鏡，為開心的回憶按下快門。

我能夠鮮明地感受到 10 年前第一次身在東京的興奮，也確定很久以後，能夠重溫這趟美國之旅的快樂。

從去年發現 indie hacking 這個領域之後，我嘗試獨立開發一年多了。在今年 8 月發佈了我的第一個產品，一個用 markdown 寫和弦譜的工具《和弦島》。但是太 niche 了，沒什麼人用。

我沒有能讓產品持續曝光的 distribution channel，只在發佈的那一個禮拜激起一陣漣漪，隔週 GA4 的線圖又恢復平靜了。

不過在做使用者訪談時，認識了厲害的吉他手（可以 cover Marcin 曲子的等級）也是很棒的收穫！

獨立開發就和學習任何事情一樣，有前人的經驗可以參考是一回事，事實上總是要自己走過一次、陷進同樣的坑裡才能真的學會一些事情。我想這就是知識和經驗之間的關係吧。

為了補足開發以外的技能，我攝取了好些英文書：My Indie Book, Snow Leopard, Obviously Awesome, The SaaS Playbook, The Cold Start Problem。之後的產品如果有相關的心得再寫文章分享吧！實作要緊！

今年也開始跟仰慕很久的吉他老師上課，課堂上經常發現一些平時自己不會注意到的小細節，其實都埋藏著很多學問。六條弦和手臂大小的桶身裡，真的藏著一個宇宙！

每當這種時候總是能深刻感受到現場教學的價值。雖然現在靠 YouTube 和 AI，沒有什麼東西是不能自學的，但是經驗和「發現自己不知道什麼」的能力，還是需要老師。

這種時候也會覺得，辛苦上班賺錢終於有意義了，可以付學費學想學的東西。

2026 年的新年新希望跟往年一樣：希望每年都可以不要許同樣的願望。

所以就這樣吧～💪🏻

美西之旅 🇺🇸 Las Vegas

Fri, 07 Nov 2025 01:19:57 +0000

美西之旅的第二站，我們來到了罪惡的 Las Vegas。

不管從什麼意義來說 Las Vegas 都是一座 Sin City。

花太多錢的罪惡、輸太多錢的罪惡、吃太多高熱量食物的罪惡，以前還有黑幫、性交易產業的罪惡。

Las Vegas 是一座特別的城市，這座城市打從一開始就只為了旅人建立，如今只為觀光服務。

它的名字是西班牙語「水邊的窪地」的意思。一開始是美國中部通往加州途中的綠洲補給站。

在經過黑幫勢力控制、美國政府介入，將賭博產業合法化之後，現在 Las Vegas 已被改造成一座由金錢推動的遊樂園。

來 Las Vegas 的人只有兩種目的，花錢或者賺錢。

人們在假日來到這裡，發生的一切也只留在這裡。

當夜晚過後，新的一週開始，人們又出現在辦公室裡，繼續原本的生活。永不停歇的音樂只在這座不夜城，不在大部分人的生活裡。

雖然我們在平日來到這裡（因為假日住宿太貴了），但是錢也留在這裡了。🥸

// 城市介紹結束，以下是旅行記錄：

我們吃了百樂宮的 Gelato 冰淇淋買一送一！超濃郁超濃稠超好吃！（在這座不夜城裡 Gelato 居然 18:00 就關了，因為冰淇淋是小孩的食物嗎！反觀披薩開到凌晨 4:00🤣）

我還玩了 New York New York 飯店的雲霄飛車，因為旁邊的保加利亞人很害怕，所以我跟他搭話聊天。

以上都是 @barbara__0209 出發前狂刷手遊免費換的，大感謝！

Las Vegas 主要的街道 Strip 上面的飯店，大多都以世界主要城市為主題，用浮誇的地標建築，滿足旅客的幻想。有紐約、巴黎、威尼斯、羅馬、埃及金字塔等等，我好希望有一個東京，但是沒有。

然後威尼斯人跟澳門的幾乎一模一樣（其實就是同一家），原來我在多年前已經去過了！🤣

吃到最好吃的食物是 Secret Pizza！它連招牌都沒有，隱身在高級餐廳旁邊的小走道裡，不說還以為是廁所。（我懷疑是因為旁邊的高級餐廳，不想讓他們掛上披薩的招牌破壞一致性，所以他們索性把店名取作 Secret Pizza 🍕）

好吃到第二天特地為了它走 40 分鐘去吃！

Las Vegas Strip 大道上幾乎沒有斑馬線，人行道是飯店設計的一部分，飯店之間有天橋連接，想要到馬路對面都要經過飯店內部。

原理其實跟在百貨公司搭手扶梯上下樓，都要繞過半邊樓層一樣。只是 Las Vegas 做得更徹底，直線距離 1 分鐘的路程硬是要你走 10 分鐘，在過程中增加你手滑花錢的機會。

來到賭城，我們當然也去試了試手氣。結果 $50 USD 15 分鐘就玩完了。我們上牌桌玩了 21 點，一次下注要 $10 USD 所以很快就用完預算了。

在牌桌上我們遇到了一位加拿大的護士阿姨，她人很好知道我們是第一次玩，就教我們規則跟策略。我們很快花光預算之後就離開了，下次再經過時，那位阿姨還在同一桌，看來不是運氣好，就是預算很多。💸

我們一開始輸，然後很快的小贏，最後輸光。我覺得荷官好像可以某種程度控制自己的牌運耶。因為他突然連續幾局牌變超好。這樣才能維持讓人一直賭的黃金公式（小贏然後輸光）、維持（賭客）負的期望值。

總之，我覺得 Pizza 很好吃、冰淇淋也很好吃、上賭桌的經驗很新鮮、治安很好，只是物價有點不適合我～

I wanna be a billionaire so fucking bad ~~~ 🙇🏻

銀杏城市 🍁

Sun, 08 Dec 2024 03:51:38 +0000

突如其來的韓國行 - 銀杏城市。🌆 🍁

在 @barbara__0209 換工作的空檔，匆忙地去了一趟首爾。這座城市被秋天染上了楓紅與金黃，人行道上鋪滿了扇形花紋的地毯，好美喔！

第一天搭機場快線時，錯搭直達首爾站的列車，也買不到氣候卡（地鐵卡），索性叫 Uber 去住的地方。

在轎車後座看著這座陌生的城市，我突然想起了在機場看到的 Uber 廣告標語：

Different city, same uber.

心裡不禁覺得佩服！Uber 竟然能準確抓到消費者的心聲，並且作為廣告標語！

第一印象 👀

Uber 司機有點暴躁。
Wowpass card 很方便，但是容易忘記拔。
弘大的街頭藝人都不用看譜就能完成演出。
延南洞很美，都是獨棟，有點半地下的建築。
弘大與延南洞一帶榮登我心目中在韓國最喜歡的地方。
街道、地鐵跟日本很像，電車感覺是跟日本採購的。
地鐵中文廣播的站名竟然是講韓文，誰聽得懂呢？

拍攝形象照 📷

在與弘大一站之隔的合井站，有一家拍攝形象照的專業攝影棚 📍Sihyunhada Hongdae Space！可以拍出最好看版本的自己！

一開始掃 QRCODE 填寫表單，選擇自己喜歡的背景色與 3 個風格關鍵字，接著等攝影師把你領走去拍照。

雖然攝影師不太會講英文，但是她們會用簡單的單字跟肢體語言指導你擺 pose 簡直是姿勢指揮家。

拍照大概不到 3 分鐘，接著花 15 ～ 20 分鐘修圖。觸控筆跟按快捷鍵的聲音響不停，螢幕畫面流暢地在 Adobe 系列軟體間流暢切換。修到一個段落時，攝影師會用 Papago（韓國版的 Google Translate）與你溝通細節。

然後照片就完成了！✅

店家會用 email 將照片的電子檔寄給你，讓你速速發文！🤣

我們是看一隻阿圓的影片來的，她今年 6 月來的時候還是填寫紙本表單，現在已經電子化了。

這讓我想到 2011 年矽谷的一句話：

Software is eating the world.

那時候 Facebook、YouTube、Netflix 正要開始顛覆世人的生活方式，而現在換成許多小眾的軟體在服務更細緻的需求！

即使攝影師不太會講英文，也可以用翻譯軟體與顧客溝通、即使網頁表單的中文翻譯很彆扭，但仍可以中規中矩地將顧客的需求傳達給攝影師。

只要核心服務能夠 meet 顧客的需求，分段使用軟體工具將工作流程串起來，就能讓整個 business 順利運轉！

拍照的小觀察。👀

咖啡廳 heod 🍽️

在合井站吃到一家很讚的咖啡廳📍heod，它有賣簡餐，招牌是粉紅醬義大利麵（沒拍到）與鬆餅。

我想它的英文菜單是想翻譯成 "Pink Rose sauce" 但是它寫 "Pig Rose sauce"，在韓國很多給觀光客看的翻譯，一看就知道是用翻譯軟體翻完複製貼上的。

但是有什麼關係呢？大家也看得懂意思，也需要它們的產品 / 服務。我想韓國人可能是這麼想的吧，我也是這麼想的。🤔

另外還發現韓國的咖啡廳，會與所屬的公寓共用廁所。所以廁所不在店內，要走到隔壁的公寓一樓。

店員很好心，知道我是外國人就跟我說 follow me！然後帶我去，因為在店外大家都可以去，所以廁所的門有密碼。heod 的密碼是 8282* ！

戰爭紀念館 🫡

每到一個國家，我都會去看看它們的博物館。一來可以增廣見聞，二來可以知道這個國家的人在意什麼，紀念什麼，想傳承什麼。

韓國為了韓戰專門設立了一間偌大的博物館。在參觀的時候，看到小學生來戶外教學。我想說在小三小四的年紀，就要了解韓戰的種種，韓國人真是有憂患意識。

再轉一個角落，看到有些將軍的銅旁邊有獻花。原本以為是博物館方放的，但並不是每一個銅像都有，所以應該是民眾自發獻的花（？）韓國人真的很重視韓戰。

看著看著，我都想說因為韓戰而獲得喘息與生機的台灣，是否才是更該了解、紀念韓戰呢？🤔

2024 伍伍慧台北演奏會。

Tue, 01 Oct 2024 16:14:47 +0000

2024/09/29 伍伍慧台北演奏會。

伍伍慧越來越幽默了！用簡單的英文讓大家嘴角失守。

: 2 years ago, I wrote this song in my studio. There was a big window in my studio and outside the window was a ...

Secret garden, yeah, a secret garden.

Suddenly, it started raining and the garden was getting wet.

The scene was so beautiful that I came up with the melody and completed this song that afternoon.

But the garden is not mine.

It's my neighbor's so I appreciate my neighbor so much! Please enjoy the next song - rain, thank you!

註：伍伍慧 2023 年發行的專輯名稱就叫做 Secret garden。

總之就是很認真地在 talking 但又不是那麼認真的感覺。

自從第一次聽到《約束の海》，就覺得太神了！旋律超級有畫面感超好聽，演奏技巧細膩到自己嘗試完全練不起來。旋律、和聲跟節奏彷彿手錶機芯一般完美咬合，表面上平靜優美地運轉，實際上難度炸裂。

今天聽到《Rain》的前奏又是雞皮疙瘩掉滿地，簡單的幾個音加上一些留白，完美地捕捉到了那天午後陣雨的畫面。當琴弦的震動靜止時，我彷彿可以聞到土壤的氣味！

Fingerstyle 吉他手們各自有不同的風格，而把旋律這件事情做到極致的，我想應該非伍伍慧莫屬了！

初識太空時代 Space Age，一段人類共同的回憶與期待！

Sun, 21 Jul 2024 10:01:00 +0000

Space Age！👩🏻‍🚀

7 月中在平日請了兩天的假，和朋友去台中拜訪朋友，是為叛逆之旅。因為在平日請兩天假，已經是身為上班族最大的叛逆了。🤫

這次台中之旅最大的收穫是認識了「太空時代」這段迷人的歷史。

這次和 @gilbert_c_16 來台中拜訪了 2019 年在紐約認識的朋友 @hua_fang_lee，他回來台灣後在台中美術館附近開了一家古物店 - 橘豆 @do.bookbinding 。他帶我們認識了 Space Age 這個璀璨的時代。

橘豆店裡收藏的 Braun audio L46 俐落簡約的設計引起我的注意，我想說以前的音響居然做得有無印良品的風格，一問之下才發現它其實是 1960 年代初期的產品！

原來簡約風、扁平化設計這些近年來蔚為風潮的概念，其實在 1960 年代時就首次出現了！

L46 由 Dieter Rams 設計，超好看！連賈伯斯也是 Dieter Rams 的忠實粉絲！第一代的 iPods 設計，就是仿照 Braun 個人收音機的形狀與比例！

所以說現在的 Apple 產品設計，其實是太空時代的文藝復興產物（？）

自從 1957-10-04 蘇聯將史普尼克一號送入衛星軌道後，人類正式進入了太空時代。在恐懼被共產主義吞噬的冷戰背景下，美國的太空科技發展一日千里。

在 1970～1980 年代裡，技術的革新引爆了工程師與設計師對於未來的想像，催生出許多仍影響至今的前衛概念。在設計上使用大膽的配色（橘色為代表）、金屬球體（模仿史普尼克一號的外型），材料上則選用大量的金屬與塑膠（不會降解的超不環保塑膠，可是因為設計得好看又好用，所以可以世代相傳，所以也不太好說哪一種比較環保）。

在這個時期，人類的工業產品從溫馨復古的木材與皮革，過渡到前衛的金屬與塑膠，彷彿是太空艙裡的各種裝置與儀器，就像是人類上了一堂外星人的課，將科技的果實包上相稱的包裝。

不過或許是冷戰的結束，又或許是網際網路的普及，人們不再關注太空發展，轉而熱衷於在網路上看影片、交朋友以及購物。璀璨的太空時代逐漸離我們遠去，取而代之的是 Windows 的開機聲音與藍色畫面 :(

即使黃金年代已經離我們遠去，但是當時的設計放到現在仍然不會感到過時。也許太空的本質就是可以對抗時間的影響吧！

很高興這次台中之旅能夠認識這個人類歷史上最有創造力的時代，發現日常生活中許多太空時代的痕跡，好喜歡這種發現設計元素彼此相關的過程！好有文化感！

👩🏻‍🚀✌🏻 @do.bookbinding

優雅地與 Laravel 共舞，4 個實作步驟與 1 個具體範例，寫出可讀性與維護性俱佳的程式碼！

Sun, 24 Mar 2024 07:58:40 +0000

2023 年末，我參與了公司的新產品開發，一個由前輩規劃，我來實作的 API 專案，也是我第一個從零開始開發的後端系統。在每次的 Code Review 中才發現原來 Laravel 的 Query Builder 可以做得很細緻，在方便地取得資料的同時也能兼顧效能。本篇文章重點筆記使用 Laravel 開發時能做到的事，以及需要注意的事。

Disclaimer：本文所有的程式碼皆為保留重要觀念後，依照新的情境重寫的程式碼，非公司產品相關的程式碼。（貼文封面圖為我自己的專案）

實作 API 時的觀念與優化方向總結

在實作一支 API 時，幾乎是沒有辦法在一開始就一次到位，考慮到程式碼的效能、可讀性與維護性等所有的面向。雖然在第一版的時候可能只有需求（功能）可以符合標準，但是我們可以藉由一些通用的原則，確保後續只需要做局部的優化，而不需要做大幅度的改動。

這些原則依序是：

實作前先瀏覽 Laravel 文件，知道有哪些框架提供的功能可以使用。
依照需求規劃 API 從 Request 到 Response 之間的流程。並且思考所需的資料要如何取得，以及在哪裡取得。
實作 API 確保流程正確達成需求。在實作時要去看 Laravel 的底層，依照框架的實作來決定要如何使用這些 method。並且隨時印出 DB Query Log，查看是否有冗余的 Query。
思考如何優化。

在實作前先完整瀏覽過 Laravel 的官方文件，知道框架的基本的功能如何使用，以及有哪些進階的功能可以方便地達到需求是很重要的事情。在了解了框架提供的功能之後，在下一步的流程規劃階段，才有辦法流暢地銜接各個流程，在合理的環節取得所需的資料。

規劃 API 的流程是所有步驟中最重要的一步了。這支 API 要取得/操作的資料主體是什麼？流程要如合整合進 Laravel 的架構之中？要在哪些環節取得所需的資料？在實作前先想清楚以上問題，會讓實作的過程順利許多，之後需求增加或改變時，也可以快速修改回應。

我第一個接觸的後端框架 CodeIgniter 3 是一款基本的 MVC 框架，沒有像 Laravel 提供這麼豐富的功能（e.g. middleware、relationships 等等）。雖然接觸 Laravel 也有一兩年了，但是很多商業邏輯我都還是習慣寫在 Service 處理，沒有思考如何將流程整合進 Laravel 提供的功能中。在取得資料的時候，也沒有善用 Laravel Eloquent Relationships 與 Query Builder，一次取出所有需要的資料。（在 CodeIgniter 3 之中沒有 relationships，常常需要分次取得所需的資料，這個習慣也延續到了使用 Laravel 的開發上）

在經歷這次新產品的開發後，我整理了 Code Review 後形成的常用流程如下，可以當作是開發 API 時思考流程的起點。

Middleware

↓

Routing

↓

and so on ...

↓

FormRequest ---> 權限檢查與參數驗證，可以使用 Relationships 一次取出後面流程需要用到的資料，除了減少 DB Query 次數以外，也將不合法的請求擋下，不會進到後面的流程。

↓

Controller ---> 控制流程。呼叫各種 Service 達成需求，並且接收 Service 回傳的結果，使用 Resource 回傳 API Response。

↓

Service ---> Service 基本上是對 Model 做 CRUD。參數的驗證與檢查在 FormRequest 就做掉了，需要其他資料也可以透過呼叫其他的 Service 取得。在 Model 也可以搭配使用 Observer, Events, Queue and so on ...

↓

Resource ---> 整理 API Response 的資料，也可以拉取其他 Model 關聯。

接下來，在實作 API 時要記得常常去看 Laravel 的底層實作，除了決定要如何使用框架提供的方法之外，也可以覆寫它們來達到需求。在這一份工作與上一份工作中，我發現厲害的同事們，不約而同地都有看 Laravel 框架底層實作的習慣。可能是因為 Laravel 本身將設計模式融合得很好，而且對開發工具理解得越深，也越能夠寫出渾然天成的程式碼吧！

以下是我有遇過的實際情境：

在取出某張表的分頁資料（paginate() 的結果）時，因為需要的部分必要資訊存在 Elasticsearch 上，所以需要將 Elasticsearch 的資料整理後加入分頁資料中。我找到了 getCollection() 方法取出分頁資料的 item 部分，又因為 item 的部分是分頁資料的一個屬性，所以可以直接修改它的值，最後分頁資料呈現出來就會是加入了 Elasticsearch 資料的分頁資料。

use App\Models\Sushi;

public function __construct(protected Sushi $model) {}

public function getSushiPagination()
{
    $pagination = $this->model->paginate(15);

    // 取得分頁資料的 item property
    $sushis = $pagination->getCollection();

	foreach ($sushis as $sushi) {
    // 修改 item property
		$sushi->topping = ['wasabi', 'shouyu'];
	}

    // 每筆 sushi 資料上都加上了 "topping" key 對應芥末與醬油的 value
    return SushiResource::collection($pagination);
}

新產品預設的時區是 "Asia/Taipei"，而舊專案是 "UTC"，在新產品的 Model 中，為了讓舊專案資料表預設的時區都是 "UTC"，可以覆寫 getCreatedAtAttribute() 方法來做到。

/**
 * @param $value
 * @return string
 */
protected function getCreatedAtAttribute($value)
{
  return Carbon::parse($value)->setTimezone("UTC")->toDateTimeString();
}

在實作的過程中，另一件一定要做的事情是印出 DB Query Log 查看是否有冗余的 Query 可以改善，同時也避免 N + 1 Query 的問題。Eager Loading & N + 1 query problem。

印出 DB Query Log 的方法：

使用 enableQueryLog 與 getQueryLog 包住想查看的 Model 操作，適合在修改局部 Query 時反覆查看使用。

use Illuminate\Support\Facades\DB;

DB::connection()->enableQueryLog();

Model::query()->find(1); // 操作 Model

dd(DB::getQueryLog());

DB::connection()->disableQueryLog();

在 app/Providers/AppServiceProvider.php 中監聽 DB Query，適合確認從 Request 進來到 Response 回應，這整段過程中的所有 DB Query，有沒有沒有冗余、重複 Query 的情況發生。

/**
 * Bootstrap any application services.
 */
public function boot(): void
{
    DB::listen(function (QueryExecuted $query) {
        Log::info(str_replace_array('?', $query->bindings, $query->sql));

        Log::info($query->time);
    });
}

DB Query 優化重點：

減少 Query 次數（避免 N + 1 問題）。
篩選 Select 欄位，只取出 PK 與需要用到的欄位。
where 條件的順序，有 index 的欄位先做。
- e.g. PK id, sn 優先於 status 這種只有幾種可能的欄位，最後是 name, title 這些比對字串的欄位（但後來查好像不會，MySQL 會自動最佳化） Does the order of conditions in a WHERE clause affect MySQL performance?

以下是在一個 Service 中，取得員工分頁資料的範例：

使用 when() 實作條件篩選，篩選員工是否為管理職。
使用 whereHas() 確認關聯是否存在，實際上會使用 EXISTS SQL 運算子。
使用 with() Eager Loading 取出今天的休假的資料。
使用 withCount() 計算今年休假的次數總計。
在 Query Builder 中，使用 select(['id']) 篩選 Select 欄位，只取出 PK 與需要用到的欄位。

綜合以上 getPaginate() function 一共使用 3 條 SQL 就可以取出「今日員工請假的事由與時數的列表，以及今年的請假次數，並可以篩選是否為管理職」的資料。

/**
 * @param int $perPage
 * @param int $page
 * @param array $filter
 * @return LengthAwarePaginator
 */
public function getPaginate(int $perPage = 10, int $page = 1, array $filter = []): LengthAwarePaginator
{
    $today = Carbon::now();

    return $this->employeeModel
        ->newQuery()
        ->when(
            Arr::exists($filter, 'is_manager'),
            fn(Builder $query) => $query
                ->select(['id'])
                ->whereHas( // 確認關聯是否存在
                    'role',
                    fn(Builder $query) => $query
                        ->select(['id']) // 篩選欄位
                        ->where('name', Role::MANAGER)
                )
        )
        ->with( // 拉取關聯資料
            [
                'leaveRequest' => fn(Relation $query) => $query
                    ->select(['id', 'memo', 'hours_count'])
                    ->whereDate('created_at', $today->copy()->toDateTimeString())
            ]
        )
        ->withCount( // 計算關聯數量
            [
                'leaveRequest' => fn(Builder $query) => $query
                    ->where('leave_type', LeaveRequest::TYPE_VACATION) // withCount 永遠都是 COUNT(*), 無法篩選欄位
                    ->whereBetween('created_at', [$today->copy()->startOfYear()->toDateTimeString(), $today->copy()->endOfYear()->toDateTimeString()])
            ]
        )
        ->paginate( // 製作分頁資料
            $perPage,
            ['id', 'name', 'title'],
            'page',
            $page
        );
}

實作時的注意事項與使用 Laravel 框架實作的範例

Coding Style：

超過 180 字要換行，以及要符合其他 PSR1,2 規範。
遇到分號就換行。（易讀性）
常數定義在 Model 中，名稱語意化，值為 integer or string。DB 中存 tinyint
- e.g. const STATUS_ENABLED = 1;
變數以資料主體命名，比較簡潔。
- e.g. $user 而不是 $userWithCompanyId。
寫 PHPDoc Comment 以便 IDE 追蹤分析。
操作 Model 時都要寫 query() 以便 IDE 追蹤分析。

/** @var User|Admin $user */
$user = $this->user();

$user = User::query()->find(1);

將 config、語系檔拆成 composer 套件引入。

DB 相關：

減少 DB Query 次數。
找關聯：whereHas()。拉關聯資料：with([‘PK’, ‘FK’])。關聯數量：withCount()。Resource 內使用：whenHas()、whenLoaded()。
DB Query 要從 Request 進來到回應出去都印出來檢查，避免在意想不到的地方多做 Query。
將資料先使用 eager loading 取出，避免 N + 1 問題。e.g. 進 foreach()、Resource 之前先抓出所有資料、先用 paginate() 取出所需資料，而不是資料處理完再做分頁。（避免方法：印出 DB Queries）
篩選欄位減少資料量，可以搭配 SQL 子查詢 selectSub()、COUNT、SUM 等函數取出需要的資料。
where 條件的順序，將可以縮小範圍的 Query 優先查詢。 e.g. 下 where 條件時 PK 優先 > status > name, title。
whereIn() 第二個參數傳 query object 可以變成子查詢。
- Additional Where Clauses
Nested with eager loading 要 select PK, FK。
使用 whereHas() 尋找關聯，資料存不存在可以使用 exists() 或是後續需要使用到計數資料時可以用 withCount() 來確認。
看 Laravel 提供的 function 的底層，來決定如何使用。例如資料驗證的 Rule::exists() 跑迴圈，下查詢條件的話可能會有 N + 1 query 問題。
Schema 設計：將資料表拆小，減少每次取出的資料量，缺點是需要關聯多層。
相似的資料可以做多型（morph）。
要統計自身 Model 數量時可以 withCount(hasMany(自己的 Model))

// in Reservation.php
/**
 * @return HasMany
 */
public function reservations(): HasMany
{
    return $this->hasMany(
        Reservation::class,
        'table_id',
        'table_id'
    );
}

// in ReservationService.php
Reservation::query()
    ->withCount(
        [
            'reservations as reservations_count' => fn(Builder $query) => $query
                ->where('reservation_status', Reservation::RESERVATION_STATUS_RESERVING)
                ->when(Arr::exists($filter, 'restaurant_id'), fn(Builder $query) => $query
                    ->whereHas(
                        'customer',
                        fn(Builder $query) => $query
                            ->select(['id'])
                            ->where('restaurant_id', Arr::get($filter, 'restaurant_id'))
                    )
                ),
        ]
    )
    ->get();

流程設計思考：

思考操作的資料主體是什麼。e.g. morph 單筆資料 or 中介表資料。在 route 的設計上可以參考 shallow controller。
- Shallow Nesting
跑迴圈取得需要的資料後，應剔除該筆資料，以減少下一次迴圈的次數。
思考未來如何擴充。e.g. Url 路徑收 model or id。
共用的部分可以抽出為 service。
在每個主資料的 service 寫 CRUD，其他 controller or service 可以引用。
- e.g. 在 UserController 可以用 $this->RoleService->create()。
在可能有 race condition 的地方，更新資料庫之前要先查寫的 DB，使用 useWritePdo() 查詢，確認資料正確性再更新 DB。
有做讀寫分離的話，在 Update 之前要 useWritePdo() 檢查資料正確性，Update 之後要 useWritePdo() 顯示最新的資料。
將流程適當地分配到 Laravel 提供的 Class 中。
- FormRequest（權限判斷、資料驗證，將原本要在 service 確認的資料先拉出來驗證，不合法在此回應 422 Unprocessable Entity，通過則將已經取出來的資料給 service 使用。在 prepareForValidation()、validationData() 函數中可以搭配 $this->merge() 來準備資料）
Controller（流程控制，可以呼叫 service、傳資料給 Resource、abort() 中斷流程等等）
Event / Listener / Queue（有多個地方需要做事情可以使用 event or observer，花時間的事情可以丟到 queue 做背景處理）
Service（主要的商業邏輯，裡面的 function 盡量簡單，專注於一件事情，不然不好寫測試。例如資料驗證在 FormRequert 做，Service 單純使用處理好的資料做 CRUD）
Resource（整理回應資料格式，也可以做 Collection 條件篩選等判斷。需注意 relation 會主動去拉取資料，要避免 N + 1 query 可使用 fn() => $this->relation 避免主動拉取資料）


     */
    public function toArray(Request $request): array
    {
        return [
            // 包在 function 內可以避免 Laravel 主動去 DB 取資料
            'customer' => $this->whenLoaded('customer', fn() => new CustomerResource($this->customer)),
        ];
    }
}

錯誤預防與處理：

function params、變數、回應都要寫預設值，且使用適當型別。
- e.g. id = 0 而不是 null。
在 switch()、match() 內比較的變數型別要統一，包含 default 值，這樣 output 的資料型別才會一致。
Try Catch 的目的是讓流程繼續，Catch 要報錯或是做相對應的處理，則依情境、流程而定。

try {
    DB::beginTransaction();

    // 預約座位
    /** @var RestaurantReservation $reservation */
    $reservation = $this->model
        ->newQuery()
        ->create(
            [
                ‘seat_id’ => $seat->id,
                ‘user_id’ => $user->id,
                ‘reservation_status’ => RestaurantReservation::RESERVATION_STATUS_RESERVING,
            ]
        );

    DB::commit();
} catch (Exception $e) {
    DB::rollBack();

    throw $e;
}

一段 Laravel FormRequest Sample Code 解說

"Talk is cheap. Show me the code." - Linus Torvalds

以下情境假設我們來到一間超高級的板前壽司店，而這家板前壽司店採用 web based 的電子化點餐系統。🍣

以下範例程式碼將驗證我們送出的一則壽司預訂請求。這支 FormRequest 示範了如合配合 Laravel 提供的方法，減少 DB Query 的數量取出所需的資料。

user(); // 從請求中取得使用者

        /** @var Sushi $sushi */
        $sushi = $this->route()->parameter(‘sushi’); // 從請求中取得壽司品項

        $sushi
            ->load([‘restaurant:id,reservation_limit’]) // 拉取餐廳關聯，取得預訂數量上限
            ->loadCount(
                [
                    ‘restaurant as restaurant_count’ => fn(Builder $query) => $query
                        ->where(‘status’, Restaurant::STATUS_ENABLE_TRUE), // 取得已啟用的餐廳數量
                    ‘loyaltyPrograms as loyalty_programs_count’ => fn(Builder $query) => $query
                        ->where(‘loyalty_programs.status’, LoyaltyProgram::STATUS_ENABLE_TRUE), // 取得此壽司品項是否有開啟酬賓方案
                    ‘loyaltyPrograms as intersect_loyalty_programs_count’ => fn(Builder $query) => $query
                        ->where(‘loyalty_programs.status’, LoyaltyProgram::STATUS_ENABLE_TRUE)
                        ->whereIn(
                            ‘loyalty_programs.id’,
                            // IDs of First Class, Business Class, Premium Class, Economy Class
                            $user->loyaltyPrograms()->select([‘loyalty_programs.id’]) // 取得顧客的酬賓資格
                        ), // 取得壽司的酬賓方案與顧客的酬賓資格交集
                    ‘reservations as reservations_count’ => fn(Builder $query) => $query
                        ->where(‘user_id’, $user->id)
                        ->where(‘reservation_status’, Reservation::RESERVATION_STATUS_RESERVING), // 取得此壽司已被預訂的數量
                ]
            );

        if ($sushi->restaurant_count == 0) {
            return false; // 餐廳未啟用
        }

        if ($sushi->loyalty_programs_count > 0 && $sushi->intersect_loyalty_programs_count == 0) {
            return false; // 該壽司有開啟酬賓方案, 但顧客未符合資格
        }

        $this->user = $user;

        $this->sushi = $sushi;

        return true;
    }

    /**
     * 整理待驗證的參數 `$this->all()` 可以取得請求傳入的參數
     * @return array
     */
    public function validationData(): array
    {
        $this->user
            ->loadCount(
                [
                    ‘reservations as reservations_count’ => fn(Builder $query) => $query
                        ->where(
                            ‘reservation_status’,
                            Reservation::RESERVATION_STATUS_RESERVING
                        ), // 取得此顧客已預訂的壽司數量
                ]
            );

        return array_merge(
            $this->all(), // 為了下方的 `rules()` 方法可以抓到資料做驗證，在此合併參數
            [
                ‘status’ => $this->sushi->status,
                ‘reservation_limit’ => $this->sushi->restaurant->reservation_limit,
                ‘existing_reservations_count’ => $this->sushi->reservations_count,
                ‘reservations_count’ => $this->user->reservations_count,
            ]
        );
    }

    /**
     * 參數驗證 `rules()` 方法驗證失敗 API 會回應 422 Unprocessable Entity
     * @return array
     */
    public function rules(): array
    {
        return [
            ‘status’ => [ // 驗證此壽司品項已啟用
                function (string $attribute, mixed $value, Closure $fail) {
                    if ($value !== Sushi::STATUS_ENABLE_TRUE) {
                        $fail(‘壽司未啟用，無法預訂！’);
                    }
                },
            ],
            ‘existing_reservations_count’ => [ // 驗證顧客是否重複預訂此壽司品項
                ‘integer’,
                function (string $attribute, mixed $value, Closure $fail) {
                    if ($value > 0) {
                        $fail(‘您已預定了此壽司！’);
                    }
                }
            ],
            ‘reservations_count’ => [ // 驗證顧客是否已超過預訂的數量上限
                ‘integer’,
                function (string $attribute, mixed $value, Closure $fail) {
                    if ($value >= $this->sushi->restaurant->reservation_limit) {
                        $fail(‘您已超過本餐廳的壽司預訂數量上限！’);
                    }
                }
            ],
        ];
    }
}

只要在每天的開發日常中，時時注意以上提到的方法與原則，一定可以寫出易讀性與維護性更好的程式碼吧！加油加油！👨‍💻

微軟第一個抓住工程師的心的產品 VSCode！「實用套件」與「快捷鍵」全記錄。

Thu, 03 Aug 2023 08:27:48 +0000

從三年多前學習寫程式開始，我一直使用 VSCode 編輯器開發。因為它是免費的編輯器中，功能最豐富的。

不僅可以靠著安裝套件，擴充自己想要的功能，還整合了 Termial 在編輯器之中。讓工程師可以只開一個視窗，就搞定所有的事情，看起來既帥氣又專業。

VSCode 是少數微軟出品，卻能獲得使用 Mac 的工程師喜愛的產品。一次滿足開發者所有願望的 VSCode，牢牢地抓住了我的心。

許多我喜歡的技術 YouTuber e.g. Fireship 也都使用 VSCode 來錄製影片，看起來既帥氣又親切。

在三年左右的開發日常中，我找到了一些實用的套件、發掘常用的快捷鍵、以及發展出自己慣用的方法，來加快爬 code 的效率與開發的速度。

雖然現在使用 VSCode 開發還算是非常順手，但是隨著開發範圍與難度的擴大。僅僅依靠使用快捷鍵的巧思，在處理專案重構與撰寫單元測試上，還是會漸漸感到吃力以及不方便。

上一份工作的組長是 PHPStorm 的愛用者。他是一位喜歡嘗試新工具與方法，提升開發效率與品質的工程師。

他提倡將一切繁瑣的操作交給開發工具或是想辦法自動化。一方面減少人為失誤，另一方面也將大腦有限的注意力保留給更重要的事情，解決真正重要的問題。

在一次的單元測試撰寫分享會上，組長說明了要先將 Legacy code 改寫成依賴注入的方式，才能撰寫單元測試的概念。

接著他使用了 PHPStorm 的功能重構了部分的程式碼，撰寫單元測試並且實際跑 test script。

具體來說是 PHPStorm 可以將一段 code 選取起來，按右鍵選擇「Extract method」PHPStorm 會自動將這段 code 抽出成一個 function，並且原本的 code block 會自動改寫，調用抽出的 function。

PHPStorm 還有像是修改方法的名稱時，IDE 會自動檢查其他有用到的地方並且一併改名、跑 test script 的時候可以單獨跑某支 function 等等超多神奇又方便的功能。

後來看了《 The Effective Engineer》這本書，書中強烈建議工程師要投資能夠減少重複作業的工具，才能將工作效率最大化。而新工作中有一位同事，買了 JetBrains 所有的產品，強力推坑團隊的大家也可以跟進。

於是我也買了 PHPStorm。即將告別用了 3 年多的編輯器 VSCode，轉身投入 IDE 的懷抱！

在這篇文章中，將會分享我使用 VSCode 的一些實用套件與我常用的快捷鍵。一方面作為記錄，一方面作為轉換到 PHPStorm 時的對照，找到我常用的功能對應的快捷鍵，盡量減少不熟悉開發工具帶來的效率下降。

VSCode Set Up for Web Development

Plugins：（套件縮圖以及 Nord 主題可以參考貼文代表圖）

GitLens:

在每一行程式碼後方顯示誰在什麼時間修改了這行 code 以及 commit 訊息，跟對檔案使用 git blame 的效果一樣。

indent-rainbow:

將縮排的空白依照層級，使用彩虹的顏色填滿。方便檢視括號有沒有對齊或缺少。也可以一眼看出多餘的空格，將其刪除。

PHP Intelephense:

此套件可以解析 PHP code，在 function 或是 Class name 上按 F12 就可以跳到該 function、Class 的定義。

Tailwind CSS IntelliSense:

Tailwind CSS 的提示與自動完成套件。將滑鼠 hover 到 HTML class 上方，即可檢視該 class 名稱的 CSS 屬性。

Theme：

Nord:

我很喜歡的佈景主題 Nord。原本使用 Dracula Official 但是後來覺得顏色有點太鮮豔刺眼了。Nord 主題可以參考貼文代表圖唷。

Shortcuts：

最後是快捷鍵的部分，也是整篇貼文的重點精華。以下列出一些我常用的快捷鍵以及搭配的使用情境。

圖例：

⌘ Command

⇧ Shift

⌃ Control

↩ Enter/Return

⌥ Option / Alt

游標與選取系列：

將游標跳至新的一行：⌘ + ↩

當游標停在程式碼的中間的時後，可以按下 ⌘ + ↩ 將游標跳至新的一行。這樣可以省去將游標移至行尾再按 enter 的麻煩，超實用！

將游標回到前一個位置：⌘ + U

按下 command + U 可以將游標回到上一動，就像當兵的時候置板凳，可以一直回到上一動。

這在爬 code 的時候搭配 F12 很好用。先按 F12 跳至定義，理解 function 的邏輯之後，再按 ⌘ + U 回到主流程繼續往下看。

全選並且將游標移動到每一行的結尾：⌥ + ⇧ + I

在整理 .csv 檔案內容的時候超級好用！e.g. 將 .csv 檔案的內容複製下來，將每一行的前後加上引號與逗點，組合成 array 的元素或是 JSON 資料的時候超好用！

選取下一個同名稱的內容：⌘ + D

先選取一個變數或一段文字，按下 command + D 可以選取下一個同名稱的內容。

將游標所在的整行程式碼上下搬移：⌥ + arrow keys

收合所有的 function 大括號：⌘ + K + 0 / ⌘ + K + 2

在爬 code 的時候先收合 Class 內所有的方法，需要的再展開來看，可以大幅減少眼花撩亂的程度。

數字可以決定收合的層級，其中屬 ⌘ + K + 2 收合 function 最為實用！

展開所有的 function 大括號：⌘ + K + J

複製相同內容到下一行：⌘ + C, ⌘ + V

增加 array 內的元素時很好用。

刪除游標所在的那一行：⌘ + ⇧ + K

以「單字」為單位移動游標：⌥ + arrow keys

按住 alt + 左右方向鍵，可以以「單字」為單位移動游標。

將游標移動至行首、行尾、檔案頂端、檔案底端：⌘ + arrow keys

按住 ⌘ + 左右方向鍵，可以將游標移動至行首、行尾。按住 ⌘ + 上下方向鍵，可以將游標移動至檔案頂端、檔案底端。

讓游標在多行的同一個地方出現：⌘ + ⇧ + arrow keys

按住 command + shift + 上下方向鍵，可以讓游標在上下行的同一個地方出現，方便在相同格式的資料中添加字元。

e.g. 在 .csv 檔案中爲每筆資料都加上引號，或是刪除某些部分。

分頁、選單系列：

關閉分頁：⌘ + W

切換分頁：⌘ + ⌥ + arrow keys

開啟 / 收合左方選單：⌘ + B

跳至專案資料夾選單：⌘ + ⇧ + E

跳至全站搜尋選單：⌘ + ⇧ + F

Terminal 系列：

開啟 Terminal：⌃ + ~

搜尋系列：

單一檔案內搜尋：⌘ + F

單一檔案內搜尋與取代：⌘ + ⌥ + F

下一搜尋結果：↩

上一搜尋結果：⇧ + ↩

全站檔案內容搜尋：⌘ + ⇧ + F

如果要搜尋某個 function 的定義的時候，我會使用 n 去搜尋。藉由讓前面那個 n 去比對到 function keyword 的 n 來搜尋出定義的地方。

e.g. 比對到 function getLoggedInUser( 。

搜尋檔案名稱：⌘ + P

command + P 在知道檔案名稱，但是不確定檔案位置的時候很好用。

e.g. 以 Class name 或檔名搜尋 model, view, controller, etc.

Emmet 語法：

Emmet 幾乎是所有編輯器的標配了。在寫 HTML 的時候使用 elementName.className + tab 展開成完整的 HTML。如果元素名稱是 div 的話可以省略不寫。

User Snippets

在 VSCode 裡可以定義自己的程式碼片段縮寫，在左下角的齒輪 -> user snippets -> 選擇想要加入 snippets 的語言即可設定。

我設定了 JavaScript 的 console.log(); 為 clg、PHP 的 var_dump();die; 為 vd。

我在 snippets 的後方加入了 // TODO to be deleted 的註解。這樣只要在發 PR 前全站搜尋 TODO、del 等等的關鍵字，就可以找到忘記拔除的中斷點，並且刪除它們。

A Cool command：

最後的最後，一定要學會如何在 Terminal 之中下 Command code . 使用 VSCode 開啟專案，因為超帥的！

以下是設定步驟，可以參考這篇文章：macOS - How to open Visual Studio Code from the command line on OSX? - Stack Overflow

⌘ + P
輸入「shell command」找到「Shell Command: Install ‘code’ command in PATH」並且點擊執行
完成！

之後只要在 Terminal 之中 cd 到專案資料夾，輸入 code . + enter 就可以用 VSCode 開啟專案囉！

以上是我使用 VSCode 的總整理，希望可以在兩個禮拜內使用 PHPStorm 熟悉相同的功能與操作。👨🏻‍💻

下一篇來整理 PHPStorm 的快捷鍵，不過文章應該無法那麼快完成。⚠️

每次面試都是微小的迭代，把自己打造成公司願意買單的產品。我的日本就職活動 Part 2！

Sat, 15 Jul 2023 11:28:44 +0000

上一篇即使人在台灣，也能錄取海外工作！《普通人的海外求職指南》我的東京工程師就職活動 Part 1！講了我在台灣找到東京工程師的工作，但是後來決定留在台灣工作的故事。這一篇 Part 2 則是要來講如何準備每一次的面試，以及面試了十幾間日本公司的一些發現與心得。

一開始先前情提要一下。我參考了《普通人的海外求職指南：不必留學，也能讓國際工作主動找上你》這本書的概念，把求職這件事看作是一場「精實創業」書中提供了每一個平凡人都能馬上採取行動，出國工作的實際方法。

立即購買《普通人的海外求職指南：不必留學，也能讓國際工作主動找上你》踏上海外工作的航道 👉 https://moo.im/a/68flCI

如何獲得面試機會

首先我們要經營 LinkedIn，把所在地設為出國工作的目標地點。接著，為自己寫一份精簡扼要，又能凸顯經驗與強項的英文履歷，作為行銷漏斗的最外層。它能讓獵頭發現我們，為我們帶來源源不絕的面試機會。之後藉由每一次的面試，來迭代我們自己這個「產品」，直到獲得 Offer。

獵頭在 LinkedIn 上密我們之後，會先進行簡單的面談，確認求職者的日文能力和過往的工作經驗。接著請我們提供找日本工作都會需要的「履歴書」與「職務経歴書」。

履歴書和台灣人認知中的履歷表差不多，需要填寫基本資料、學經歷以及工作經驗。比較特別的是學歷大多需要從高中開始填寫，工作經歷只需要填寫公司名稱和任職的時間區間。

職務経歴書則是需要詳細列出你在每一份工作的工作內容，一篇關於自己職涯的 Summary，還有「自己 PR」，也就是 Promote 自己的強項，說明自己的能力可以為公司貢獻什麼價值。

點此可以下載「履歴書」與「職務経歴書」模板！

獵頭會根據我們的工作經驗和需求，提供求人票（職缺 JD）給我們選擇。若有意願應徵，就將我們推薦給公司。待公司書面審查通過後，就獲得了面試機會。

我當時跟獵頭說我傾向找「自社開發」（In-house 開發產品）的公司，避免找接案公司。原因是自社開發的公司，會以把產品迭代得更完美為目標，而非以交付時程為主要目標。除了可以使用新技術、新作法來優化產品以外，也可以學習到產業的 Know-how。開發模式也大多是跑 Scrum 而非 Waterfall。

台日面試大不同

面試了約 15 間的日本公司之後，我覺得和面試台灣公司最大的不同是：面試前需要填寫繁瑣的文件和測驗，以及面試的順序是先人事後技術這兩點。

面試前測驗

面試前的測驗可能是性向測驗、技術測驗或是日文能力測驗。技術測驗通常是針對特定語言、框架的語法或特性的選擇題。不是像 LeetCode 那種演算法和資料結構的考題。

我覺得技術測驗考得滿細節的，很多東西平常開發時根本不會用到，或是偶爾需要用到的時候再去 Google 就好。例如我有做過一個前端的測驗，考了一些根本沒看過的 HTML tag 的用法，還要寫出使用 float 排版的 CSS。

因爲測驗進行時，規定不能離開當下的全螢幕視窗，所以沒辦法搜尋答案，只能憑印象寫。不過我都有通過測驗，進到面試階段，因此我覺得太細節的問題答錯也不會影響太大。

日文測驗則是很像 JLPT 日檢考試的聽力部分，不過滿著重在「助詞」和「濁音」的分辨的。因為考題很多都是日常生活用語，所以很多時候根本不用聽到聲音，就可以選出答案了。但是相對的，只要不小心錯個兩三題，你的分數在總測驗人數的排名就會掉到很後面。

面試的順序

日本公司的第一關面試一定都是人事部門的面試官，第二關才會是技術相關的人，跟台灣先確認技術能力再進到人資的關卡剛好反過來。

在第一關的時候，人事部門的面試官會先介紹公司。而且是準備詳盡的簡報，一次講個 10~15 分鐘。把公司的事業內容、沿革、使命與強項、待遇、升遷方式等你能想到的東西都介紹一輪。接著才是求職者自我介紹，而面試官會從你過往的學經歷，特別是工作轉換之間的動機切入來問問題。

在第一關，面試官主要要確認的有兩個重點：「日文能力」與「求職動機」。

關於日文能力，最基本的是一定要 100% 聽懂問題再回答。如果只有理解 6~7 成的問題內容就回答，讓面試官覺得文不對題的話，對方可能會覺得我們聽不懂他在講什麼而被嚴重扣分。

在視訊面試時，常會有訊號不穩定的情況，導致問題中斷沒有聽到，或是面試官講話糊在一起沒聽清楚。這時候就可以說：「すみません、電波が悪いので、もう一度言っていただけますか？」請面試官重複一次問題，比只理解部分問題就回答要好得多。

關於求職動機，面試官一定會問的問題是「為什麼想來日本工作？」這是一個很根本的問題，也是最難回答的一個問題。有些面試官可以接受喜歡日本文化等等，直接而真實的答案，不過還是稍微包裝一下比較好。

求職動機的第二題是「為什麼想來應徵我們公司？」。這一題需要有充足的事前準備，才能回答得好。大概要花一到兩天，研讀公司的官網，甚至是 CEO 過往的受訪內容。接著，結合自己過往的人生經驗和公司的 Mission，想一個合適的說法。

例如我面試上的企業通訊軟體公司，它的 Mission 是：「すべての人が自信を持って幸せに働ける世界をつくる」（創造一個所有人都可以滿懷自信地工作的世界）。我想到上一份工作，因為是 Fully Remote 的工作模式。On board 後好一段時間，都只能隔著螢幕，藉由聲音來認識同事的經驗。

所以我說在這個疫情時代，通訊軟體就好像是我們的替身一樣。因為有上一份工作的經驗，所以覺得打造能讓人更自在、有自信地溝通的通訊軟體是很重要的事情云云。

為了一場日本的面試，需要花超多時間做功課準備。不過相對的，面試後都會收到面試官的 Feedback，知道下次如何改進，或是對方認可自己哪些能力。比較少收到無聲卡，我覺得這一點蠻好的。

如何讓下一次的面試更進步

在這個科技的果實唾手可得的時代，我們如果懂的善用科技，就可以大幅提升進步的速度！以下列舉幾個我在這次就職活動期間，經常使用的的工具。

ChatGPT

人類從 2022 年底，正式迎來了生成式 AI 大爆發的新紀元。用它來修改履歷、面試台詞，甚至是回覆獵頭的 Email 內容，真的是非常高品質又有效率！

我通常會寫一段中文或是日文的初稿，請 ChatGPT 幫我翻譯成通順的日文或是英文。接著我再順過一次，確認語意和用字遣詞的正式程度適中，就可以當作成品使用了。

其中意外的收穫是，可以學到日文的 IT 領域專有名詞或常用說法。有時候直接 Google 搜尋某個詞彙對應的日文，得到的並不是最常用的詞彙。但是只要把順序反過來，先打一句中文請 ChatGPT 翻譯，再用 Google 搜尋確認該詞彙是正確且廣泛使用的。這樣會有效率很多！

Google Translation

接著是 Google 翻譯，重點是它的發音功能。我會把上一步做出的台詞丟到 Google 翻譯，請它幫我唸出來。這樣有兩個好處，一個是可以確認正確的發音，另一個是把 Google 唸出來的結果錄音下來，反覆聆聽增加記憶。因為比起視覺，聽覺對於記憶更有幫助。

有時候有些漢字不確定念法，或是一大堆片假名的句子。實際聽 Google 唸一次，勝過自己苦讀好幾次。

語音備忘錄

由於在台灣面試日本公司一定都是視訊面試，因此我都會把每次的面談、面試過程錄下來。在下次面試前反覆聆聽，確認自己有哪些地方會卡住、可以講得更好。獵頭或是面試官講的日文，有哪些我可以借來用，使用更簡單的單字和句型，但是表達得更清楚。

隨著面試的經驗增加，被問的問題邊界也逐漸收斂。這時候相關的面試台詞都已經修改得言簡意賅、清晰扼要，成為了不會失分的守備範圍。

雖然面試前還是會很緊張，但是從這個時候開始，每次面試結束，取代一直被拒絕的挫折感的是強烈的成就感，一種自己已經可以掌控基本表現的成就感。

接下來，只要繼續鞏固守備範圍、加入新的面試台詞。持續面試，等到適合自己的公司到來，就可以獲得 Offer 了！

另一個很實用的面試技巧是「STAR 原則」。它可以讓你在被問到一個開放性的問題時，能夠很有條理、結構清晰地回答面試官。

STAR 原則

STAR 原則是「情境」、「任務」、「行動」、「結果」的開頭縮寫。

Situation: 先設立一個情境範例，並且提供必要的詳細資訊。

Task: 描述你在此情境中的責任與目標。

Action: 解釋要使用什麼步驟達成目標。

Result: 分享最終達成的結果。

一些觀察與心得

在面試了十幾間日本的公司之後，我有了一些觀察與心得。以下就來分享一下我實際的感受吧！

日文要好到跟日本人一樣

雖然我自認在面試中沒有誤解面試官的問題，也都可以把想法完整表達出來，只是口說沒有那麼流利。在開始面試一個多月之後，還是每次面試都被刷掉，原因全部都是日文能力不夠。

這讓我深刻理解到，即使是工程師要在日本工作，技術不一定要非常頂尖（技術面試問的問題都偏基本），但是日文一定要很好，而且要跟日本人一樣好。

另外還有一點是，接案公司對於日文的要求，會比自社開發的公司再嚴格一些。原因可能是接案公司的工程師，不僅要開發網頁或 App，也需要負責和客戶討論需求、文件撰寫等工作。

日本公司不缺喜歡日本到想要去工作的人

在面試最後的「逆質問」（求職者問面試官問題）的環節，我都會好奇地問開發團隊有沒有外國籍工程師？有哪些國家來的人？

韓國人和台灣人是大宗，畢竟韓文文法跟日文很相近，而台灣使用中文，天生就會漢字不用特別學習。令我感到驚訝的是，幾乎每間公司都有歐美人士，北美、法國、比利時、烏克蘭等等國家的人都有。這些國家的人要把日文學到跟日本人一樣好，需要花多少時間跟心力呀！

想到這我不禁感嘆日本的文化輸出力量有多強大。每年都有無數的外國人前仆後繼地想去日本工作，但是只有同時具備技術能力，而且日文跟日本人一樣好的人才能夠通過篩選，踏上日本的土地。

表裏難辨的日本人

日本文化中有很明確的「界線」的概念。界限之外的叫做「表」，界線以內的叫做「裏」。例如：鳥居是人間和神界的界線，鳥居外的參拜道路叫做「表參道」繁華而熱鬧 ; 鳥居內的參拜道路叫做「裏參道」，莊嚴而肅穆。

不只物理上有界線的概念，日本人的人際關係中，界線的概念更是無處不在。在「心」這道牆之外的話語稱作「建前」也就是場面話、客套話 ; 而內心的話則稱作「本音」也就是真心話。

在這次就職活動中，我感受最深的建前就是「你的日文在哪裡學的呀？好厲害！」一開始聽到的時候以為是稱讚，畢竟自學到 N1 是令我滿驕傲的事情。不過通常有問這個問題的面試，結果都是被刷掉。因此，我想這應該是委婉地表達對於我的日文能力有疑慮的場面話吧。

不過也有獵頭在問完這句話之後，補充說明他會這樣問的原因是，好奇我有沒有日本人朋友。他想說我平常可能有用日文跟日本人朋友聊天之類的。

所以一句話是建前還是本音，只有界線的主人內心才知道。在面試的場合，一切就都先當成建前吧！

東京產業多元，軟體的舞台片地開花

最後一個感想是，東京不愧為世界三大都會，有好多台灣沒有的產業，好多公司都在嘗試用軟體解決不同的問題！

有從製造業轉型，使用製造業 Know-how 打造自動化軟體測試工具的公司。

有自動偵測負評或酸民的留言，讓其能見度變低，防止客戶被炎上的公司。這個產業專門處理「風評被害」，他們把負評或謠言比喻為「Digital Tattoo」，蠻傳神的！

有使用 Flash Sale（限時搶購）的方式，消化名牌精品庫存品的公司，表面上是服飾電商，但實際上是提供庫存管理解決方案的公司。

有自動掃描公司文件、信件往來紀錄，自動偵測不法行為的公司。產品的 Dashboard 以人際關係網路圖，視覺化地呈現人物關係，和不法行為的文件證據。看起來很像 Neo4j 的介面。這家公司的 CEO 同時兼任 CTO，持有會計師執照，同時也是工程師，而且好像才 30 出頭歲，太強了吧！

最後就是我面試上的企業即時通訊軟體的公司。由於日本法律規定，企業有義務在地震發生後，第一時間確認員工的安全狀況。所以他們在 311 大地震後，開發了有地震預警和安全狀況確認功能的通訊軟體，目前已經被一萬家日本企業採用。

總結

在面試了這麼多家日本的公司之後，我漸漸了解到面試海外工作是和自己的對話。

雖然有進步，但程度還不足以拿下 Offer 時，是否能夠不被負面情緒影響，持續做該做的事情，直到取得 Offer 那天的到來呢？

在面的過程中「為什麼想到日本工作？」這個問題，不只面試官問我，連我每天都在問自己，我能給出一個非常 Solid 的答案嗎？

出國工作不只需要克服許多技術性的困難，還要有足夠的信念與覺悟支撐才能走下去。

非常感謝前人試錯找出的方法，讓我在面試這關能夠順利一點。真的是滿滿的 Respect！雖然我已經決定留在台灣工作，但還是寫了這一篇心得文，希望留下一些足跡，給之後想要去日本工作的人參考。

立即註冊 👉 http://moo.im/i/DbsBO

立即購買《普通人的海外求職指南：不必留學，也能讓國際工作主動找上你》 👉 https://moo.im/a/68flCI

即使人在台灣，也能錄取海外工作！《普通人的海外求職指南》我的東京工程師就職活動 Part 1！

Sun, 09 Jul 2023 15:02:55 +0000

今年初從前公司離職後，原本想要挑戰去日本工作。But！我發現我很喜歡的電子書平台在徵人。於是火速投履歷面試，結果幸運地錄取了！

雖然日本的職缺也順利地面試上了。但是身為工程師，能夠參與開發自己心目中的夢幻產品，實在太難得。最後我婉拒了日本的機會，決定留在台灣工作。

這篇文章重點整理，我這次東京工程師就職活動的準備過程和心得。希望對同樣在找日本工作的人有幫助，也做一個短暫追夢的紀錄。

我在遇到難題的時候，總是習慣從書中尋找答案。這次準備東京就活，參考了這本書《普通人的海外求職指南：不必留學，也能讓國際工作主動找上你》這是一本面向台灣讀者的全方位海外求職攻略。作者沒有留學背景，僅靠著 2 年台灣工作經驗，就開啟了海外職涯。

我覺得這本書最厲害的地方是，它的實用性和親近感。因為學歷和工作經歷不如海歸的人漂亮，所以作者在一開始就採取了非常務實的態度來面對海外求職。最後他發展出了我們一般人都可以複製的有效方法—「LIST 原則」。

除了馬上可以實際應用的方法，作者在心態和觀念上也著墨甚多。那些求職不順時會有的自我懷疑、求職者和面試官想法的不同之處，作者都在書中以自己的實際經驗幫我們預告了一輪。

立即購買《普通人的海外求職指南：不必留學，也能讓國際工作主動找上你》踏上海外工作的航道 👉 https://moo.im/a/68flCI

《普通人的海外求職指南》有別於一般的留學就職攻略。讓較晚財規劃出國工作的人，現在就可以採取行動，有效率地朝著自己的目標邁進。

LIST 原則的核心思想是，把求職看作一種精實創業，最終目的是要賣出「你」這個產品給公司。最小可行性產品（Minimum Viable Product）就是你的履歷和面試表現，而整個求職的流程要套用行銷漏斗的概念。創造一個夠大且被動的 Input（recruiter 傳的訊息、面試機會）面試的量夠大，才有辦法練習與改進，進而有機會得到 Output，也就是 Offer。

LIST 是以下 4 個動詞的開頭縮寫，持續採取這些行動，最終一定可以獲得結果。

Localize 融入當地，讓自己像個本地人。

決定地點：你想去哪裡？從比較願意接受外國人的城市起步
克服身分：在留學和結婚之外，還有哪些特殊簽證？
掌握外語：以多益的金色證書為目標是一個好策略嗎？

比較容易接受外國人的城市可能指歐美的城市如倫敦、柏林，也可以是工程師需求非常強烈的國家，如日本東京。

獵頭可能並不在意你的多益成績，如果要確認你的英文程度，直接和你通電話或者視訊面談是最有效的做法。日本求職的話， JLPT N2 或 N1 是必須的，日檢證書是一張門票，但是更具決定性的因素，還是面試當下的口說表現。

Internationalize 跨出國際，讓自己被世界看見。

撰寫履歷：丟掉自傳，為自己寫一份通行世界的一頁式履歷
經營領英：讓獵頭聯絡你之前，得想辦法先讓對方找得到你

獵頭通常沒有時間好好看你的履歷，甚至有些大公司是「機器」在看你的履歷。大公司通常會先用 AI 掃過履歷，抓出符合關鍵字的履歷，通過機器掃描的履歷，才會被真人閱讀。因此，以英文撰寫側重工作經驗和技能關鍵字的一頁式履歷，是你進入人力市場的第一步。

全世界的獵頭在為職缺找面試者的時候，LinkedIn 是他們唯一的選擇。因此，打理好自己的 LinkedIn 頁面，是求職過程中投資報酬率最高的一件事。

Strengthen 強化專業，給雇主一個用你的理由。

培養專業：從職缺關鍵字開始，找到能跨越國際的硬實力
表現自己：怎麼從現職培養國際級的軟實力？心態、溝通、行動
面試技巧：重要的不是每一關都拿到滿分，而是釋放足夠的訊號

在面試中，重要的不是完成一場 100 分的面試，而是在面試官在意的點上，獲得足夠的肯定，成為他們要找的人。

Test 不斷測試，從人力市場的回饋，選擇出擊時機。

被動檢核：以收到第一封獵頭的信為目標，持續優化自己
主動出擊：建立自己專屬的夢幻職缺清單，用求職漏斗規畫時程
以戰養戰：別怕失敗！重要的不是通過面試，而是拿到籌碼

每次面試獲得的 feedback 都是下一次面試的籌碼，當你感覺到每次面試都比上一次更進步的時候，你的起跑點又離終點更近了一些。

在開始執行 LIST 原則之前，要先好好審視自己出國工作的動機，確認自己到底想要什麼。因為這是在求職過程中，以及真的到海外工作生活時，支撐著你的根本基礎。

我會想去日本工作，是因為真的很喜歡日本，喜歡到還沒去過日本以前就自學考到日檢 N2 了。另一點則是，想實現當初轉職時，對於軟體工程師可以不受地域限制，去想去的國家工作的期待。

從海外找日本的工作，都要透過獵頭或仲介，由他們擔任你和公司之間的溝通橋樑。他們會先向你介紹職缺，再向公司推薦你。只有在面試的時候，才會和公司的人有接觸。

我參考書中的方法，把 LinkedIn 的地點改為我的目的地—東京。接著就收到很多 recruiter 的訊息。簡單面談後，他們推薦我許多職缺，於是就有源源不絕的面試機會。

因為我的日文口說只有在去旅行的時候才會用到，所以其實對於用日文面試，實在很沒把握。開始面試一個多月後，還是常常因為日文口說，在第一關就被刷掉。

不過就像書中說的，每次和 recruiter 的面談，都是免費的練習機會。而且如果你順利錄取，他們大約可以拿到相當於你第一個月薪水的獎金。因此 recruiter 基本上是站在你這一邊，你可以多詢問公司以及工作內容的細節，一方面準備面試，一方面也練習日文口說。

也因為面試時被問的問題都是類似的，回答也講過好幾遍，用字遣詞都修正得更好了。開始面試一個月後左右，開始得到面試官說我日文能夠流暢溝通的 feedback。

雖然每次面試前還是很緊張，但結束面試時，都感受到自己明顯比上一次進步，心中滿盈成就感。

這讓我有足夠的理由相信，只要重複 run 這一整個流程，遲早可以拿到 Offer。我給自己設定的目標是三個月，三個月後還沒獲得內定的話就放棄去日本工作。

面試了整整兩個月之後，我終於拿到了一間公司的內定。公司總部位於東京，產品是企業用的即時通訊軟體，像是日本版的 Slack。

雖然我沒有日本留學或是工作的經驗，甚至求職時人還在台灣，但是只要用對方法，還是可以錄取日本的工作。即使最後我選擇留在台灣，之後可能也不會去日本工作了。但是經過這次就職活動，我確認了自己有被東京的公司錄取的實力，心中的遺憾也就減少了許多。

既然已經做出選擇，那就頭也不回地往前跑吧！

努力在台灣工作，存錢存假常常去日本玩！下一篇 Part 2 紀錄日本就活的細節和心得。介紹我怎麼準備每一次的面試，還有在面試中發現的一些小趣事。不想錯過的話，記得使用 RSS 訂閱我唷！

立即註冊 👉 http://moo.im/i/DbsBO

立即購買《普通人的海外求職指南：不必留學，也能讓國際工作主動找上你》 👉 https://moo.im/a/68flCI

與自己的內在對話，弓道初體驗！

Sat, 01 Jul 2023 12:18:46 +0000

今天應大學同學的邀請，來體驗射箭。其實原本是想體驗日本弓道的，但是台灣弓道協會並沒有提供體驗課程，於是我們就來南港運動中心射個箭假裝一下。

日本弓道追求的目標是「正射必中」。意思是，只要將身體的動作與協調性練習臻至完美。即使射箭時不刻意瞄準，也可以射中靶心。簡單來說就是刻意練習一套 Best Practice，並且在賽場上穩定地發揮。

在射箭場上雙臂拉滿了弓、右眼凝視著準星，世界便安靜得只剩下我和自己兩個人了。如何和自己的內在對話，完整做出腦中明確知道該做到的樣子，實在不是一件簡單的事。

我們能夠控制的終究只有我們自己，但我們也只要和自己比較，便可以贏得勝利。弓道把射箭的本質，也就是射箭是和自己的比賽這件事凸顯出來，讓我覺得弓道實在是太有哲理、太有魅力了！

《 The Effective Engineer》作者 Edmond Lau 導讀，增加 impact！！矽谷工程師都在做的事。

Thu, 11 May 2023 12:46:47 +0000

在傍晚吃飯時間，看著 VSCode 上抽象再抽象的程式碼、Terminal 上惱人的錯誤訊息，這時 Slack 又跳出通知，有緊急的 Bug 票需要解決。螢幕右上角的時鐘，不知道什麼時候已經又過了一小時。明明下班時間都已經到了，今天的進度卻才剛開始沒多久。這時候你不禁感嘆，上班就和爬山一樣，下班路比上班難。

你是否有過這樣的時期，上班的時候事情永遠做不完，今天的進度一直往後堆積，每到禮拜五總是加班到接近12點。內心開始自我懷疑，是不是技術能力不足、效率太差，還是工作真的太多了。

最近發現幾個技術部落格都推薦了《 The Effective Engineer》這本書，說非常受用，於是我決心來好好研讀一番，期許未來自己也能夠成為一位 effective engineer。

我先看了作者在 Talks at Google 的演講，這場演講涵蓋了《 The Effective Engineer》的主要內容。本篇文章會重點摘要演講的內容，書的內容等我看完之後再另外寫文章發表。

作者 Edmond Lau 在許多知名的矽谷大公司（e.g. Google）和新創公司（e.g. Quora）工作過。他曾經連續 2 年每週工作 80 小時以上，並且又花了 2 年，全職研究如合成為一個 effective engineer。

藉由訪問 20 幾家矽谷科技巨頭以及新創公司（e.g. Facebook, Instagram, Dropbox, Etsy 等等）的 CTO 和技術大神，問他們以下 3 個問題：

What separates the most effective engineers you have worked with from everyone else?（什麼事情造就了有效率的工程師，使他們有別於普通的工程師？）
What is the most valuable lesson you have learned in the past year?（你過去一年之中，學到最寶貴的教訓是什麼？）
What investment you have made for your team has paid off the highest returns?（什麼投資給你的團隊帶來了最高的回報？）

總結出每個軟體工程師都可以學習的效率工作法。作者稱之為 leverage framework。

這本書裡不會有任何一行 code，書中所闡述的，是作為一名軟體工程師，如何藉由執行 high-leverage activities 來最大化自己的 impact，槓桿出自己的價值與影響力。

作者要我們了解一個殘酷的事實：

effort === impact // False

努力不等於影響力與貢獻

一位 staff engineer 的產出貢獻，可能是一位 junior engineer 的 10 倍，但是前者的工時，不可能也是 10 倍。

作者在此給出了本書的核心概念「leverage」，它是一個放大器，可以將你的努力轉換成巨大的產值和影響力，同時也是突破日常開發瑣事的施力點。以下是 leverage 的計算公式：

leverage = impactProduced / timeInvested

工程師的開發日常，也符合 80 / 20 法則。20% 的任務創造了 80% 的價值和影響，而 80% 的任務，只帶來了 20% 的成效。

作者要我們辨識那些花最少時間，卻能創造最大價值和影響力的事情，並且優先去執行它，這些影響至關重大的事情叫做 high-leverage activities。

在演講中，作者提及了以下 5 種 high-leverage activity ，就讓我們一一來了解吧！

Optimize for learning

第一個 high-leverage activity 是最大化自己學習能力。因為，學習是有複利效果的！所以越早開始進步的幅度越大，學習能力越好，進步得越快。

Learning compounds!

因為學習具有複利效果，所以能力的成長曲線呈指數增長，一開始緩緩上升，幾乎是平的，但過了某一個臨界點之後，會近乎垂直地向上攀升。

這也滿符合事實，當要攻克一個難題時，需要累積不同面向的知識，當知識點連成線之後，就能夠兜出解法解決問題了。

作者舉了一個老生常談的例子，每天進步 1%，一年後，會進步 37 倍！

要努力學習這個大家都知道，但困難的地方是，我們常常被淹沒在日常的開發瑣事、隕石一般的 bug 轟炸之中。每天要做的事情都做不完了，要怎麼騰出時間來學習呢？

在書中，作者舉了一個 Google 的例子，為了提升員工的生產力與創造力，Google 實行了 20% Time，每週空出一天做自己本職工作以外的事情，研究新的技術、做自己有興趣的專案等等。例如 Gmail 就是從 20% Time 中誕生的。

但是身為一般公司的員工，不可能每個禮拜空出一天。於是作者建議，我們可以每天預留 1 小時的工時，來實行自己的 20% Time。

關於學習的最後一點，作者建議我們可以從自己感興趣，或是工作上面臨的問題著手研究，因為動機永遠是持續一項行動最重要的元素。

Invest in iteration speed

第二個 high-leverage activity 是加速處理重複事務的速度。這和決定是否要將一段 code 寫成一個 function 的判斷方式一樣，當一件事情重複做第二次的時候，你就應該想辦法讓第三次作業能夠自動化地進行。

在作者問了每個 CTO，什麼事情造就了有效率的工程師，使他們有別於普通的工程師的時候，他們回答：「會投資時間自己寫一些自動化小工具的工程師，往往效率都是最高的。」

這裡說的小工具，小到 shell script，大到整個 CI/CD 的自動化基礎建設，都包含在內。

作者舉例，之前他在 Quora 工作時，每天平均會部署 40～50 次，可以想見如果沒有 CI/CD 的自動化流程，會花費多麼龐大的時間。

許多矽谷的大公司都有專門的 team 在打造內部開發工具，像是 facebook 開發了 React.js。作者說：「我們都很想成為某個新潮 framework 的作者，但其實，從每天的開發日常，就可以開始了！」

Validate your ideas aggressively and iteratively

第三個 high-leverage activity 是盡量在進到實作的階段之前，就先驗證 feature 的可行性，避免浪費不必要的時間以及人力。

舉例來說，Etsy 把產品搜尋結果頁面改成可以無限捲動。在上線之前，他們做了 A/B test，發現點擊率和轉換率各自下跌了 10% 和 25%。因此，這個功能最後根本無法上線，白白浪費了幾個月的時間和人力。

有了這次的經驗，Esty 在修改產品內容頁面的時候，採取漸進式的做法，先將想做的 feature 拆解成幾個可以驗證的前提假設，確認對產品有幫助之後，才真的開始開發。

作者說，在一個專案裡，越是不確定、有風險的事情，越要在第一時間執行，避免後續做白工。

Minimize operational burden

第四個 high-leverage activity 是要盡量降低日常維護的成本，作者在演講中著重在複雜度 complexity 的討論上。

當 Instagram 被 facebook 收購的時候，服務著 4000 萬的使用者，員工卻只有 13 人，其中只有 5 位是工程師。無論從什麼角度來看，他們絕對是一個超級有效率的團隊。

作者訪問他們的 CTO，是什麼造就了這一切？CTO 的回答是：「我們只採取最簡單的做法來解決問題。工程師們互相詰問，確認不會增加後續維護的成本之後，才會進行開發。」

作者說複雜度的影響，從小至大都可能存在。

code complexity -> system complexity -> product complexity -> organization complexity。

複雜的 code 會增加工程師的理解和互相溝通的成本、系統的複雜度會增加維護的成本、產品功能的複雜度越高，會讓未來開發的功能的難度增加、甚至是組織上的複雜度，都會影響到開發團隊的效率。

作者有一次在夏威夷休假，但是剛好有一個只有他懂的系統出問題，而火山上面沒有網路可以處理 bug，於是他就直接變成 single point of failure 了⋯⋯

於是作者開始重視 mentorship，製作詳盡的 on boarding 文件和流程。原本入職三個月的工程師還在理解 code base，現在剛入職的工程師，在第一個禮拜就可以開始貢獻 production。這真的是非常巨大的效率改善！

Building a great engineering culture

第五個 high-leverage activity 是建立良好的開發團隊文化。工程師們都想在聊好的環境中工作，專注於 leverage activities，會成為一個正向循環，讓效率推進越來越順手。

最後是一些 Q&A：

Q: 寫測試雖然必要，但是很花時間，有沒有更有效率的寫測試方法？

A: 可以先確保重要的環節都有測試覆蓋，在頻繁的改動下不會出錯為目標。

整個系統不一定要有 100% 的 test coverage，在很少用到的地方寫測試，有時候可能是一種浪費。

Q: 你提到的例子都是新創公司或規模不大的公司，關於減低複雜度，有沒有在大公司也適用的方法呢？

A: 新創公司的好處是大家容易直接溝通，但大公司也有它的優點，例如容易取得歷史數據。

以 Google 來說，它是一間非常 Data-driven 的公司，所以可以讓數據說話，影響決策者做出 leverage activities。

這篇文章是我和耶宣聯名合作的文章，我們各自對於「如合在職場展現自己的價值」發表一篇文章講述我們的看法。

歡迎點此連結，閱讀他的文章唷！以及追蹤他的 IG 倪耶宣「懶人如何打造複利人生」？ @goodyesyuan 唷！

最後，也別忘了追蹤🚪每本書，都是一扇任意門的 IG 唷！@page.turner.weekly

翻開下一本書，我們會身在哪兒呢？🚪

如何在 Next.js 13 中嵌入 GA4 追蹤碼？

Sat, 06 May 2023 19:04:30 +0000

在 2022 年末，Vercel 釋出了 Next.js 13。

v13 版和之前版本最大的不同是，每個頁面的檔案放在 app 資料夾中，並且預設是 Server Component。

也就是說，頁面是在後端的 Node 環境渲染的，不是在瀏覽器裡。因此，無法使用 BOM 以及 DOM 物件，所以像是以下的 GA4 嵌入碼中使用到 window 物件，就一定會壞掉。

那我們要怎麼在標籤渲染當下的 Node 環境，還能嵌入 Client Side 的 GA4 追蹤碼呢？

註：本站於 2023/02 使用 Next.js v13.1.6 開發，2023/05 v13.4.1 發佈，已棄用 head.jsx，改用 generateMetadata API 來做 SEO。

解法大概是以下兩個步驟：

使用 nextjs-google-analytics 這個套件，將 GA4 嵌入碼做成 Component。

自己定義一個 Component，在 JSX 檔案最上方加上 ‘use client’ Directive 把它變成一個 Client Component，再引入套件的 Component。接著就可以藉由引入自定義的 Component 來嵌入套件的 Component（GA4 嵌入碼）到標籤之中了！

在 Next.js 13 中，可以在 Component 的 JSX 檔案最上方加上 ‘use client’ Directive 把它變成一個 Client Component。

這樣子 Next.js 在做 Server Side Render 的時候，就不會執行這個 Component，而是到瀏覽器中才會執行 Client Component 的渲染。

因此，具體的做法如下：

1.安裝 nextjs-google-analytics 套件。

npm install --save nextjs-google-analytics

2.在 .env 檔案中，定義 NEXT_PUBLIC_GA_MEASUREMENT_ID 環境變數。

NEXT_PUBLIC_GA_MEASUREMENT_ID=G-XXXXXX

3.新增 src/components/GA4.tsx Component，加上 ‘use client’ Directive 把它變成一個 Client Component。

'use client'

import { GoogleAnalytics } from "nextjs-google-analytics"

export default GoogleAnalytics

4.在 src/app/head.tsx 之中，藉由引入自定義的 Component（GA4）嵌入套件的 Component（GoogleAnalytics）到標籤之中。

import GoogleAnalytics from '@/components/GA4'

export default function Head() {
  return (
    <>
      每本書，都是一扇任意門！
      
      
      
      
    
  )
}

如此，就大功告成了！

部署之後，來回點擊頁面幾次。就可以到 Google Analytics 的後台左側選單的「報表」頁籤，確認資料搜集的情況囉！

在車水馬龍的網路世界上，蓋一戶自己的家。

Fri, 31 Mar 2023 13:07:58 +0000

轉職之後一直在寫後端的東西，但其實我一直很想學一個前端框架。

於是最近花了一些時間學了 Next.js，搭配 Tailwind CSS，做了一個 Twitter 風格的部落格，接上後端 API，掛上自己的網域。在車水馬龍的網路世界，蓋起自己的家，擁有了一個可以堆砌文字的所在。

連結在個人檔案，網域也很好記：ivanhsu.space

寫了 React 之後有點理解為什麼前端框架會一個接著一個出現，因為大家都想改善 React，實在是太難寫了 >__<

決定使用 React 開發，除了它是元件化開發的始祖之一以外，以 JS 邏輯思考的 JSX 語法，也被之後的一些前端框架採用，算是前端框架的基礎吧。

最重要的是 React 的生態系很完整，遇到問題都 Google 得到解法（ChatGPT 回答得也很好XD），想做的功能也找得到套件支援。

搭配 Next.js 實作 Routing 和 SSR、ISR 之後，直接部署到 Vercel 上面超方便，還提供免費 SSL，真是太開心了！

切版的部分使用 Tailwind CSS，真的是 mind-blowing 的切版體驗。

在保持高度易用性與客製化彈性的情況下，還可以切出高度一致性的版面。還有超潮的 dark mode 可以設定。這一切都要感謝 utility class 的設計，好帥！

Tailwind CSS 讓切版變成這個專案中，花費時間最少的一個環節。而且我也只有用鉛筆大概勾勒一下元件的位置而已，根本沒有 UI 設計圖。

後端 API 使用熟悉的 Laravel 開發，沒遇到什麼困難。只是在部署到 GCP 之後，發現貴得要死，嚇得趕緊把機器都關掉。

後來找到一個免費的部署平台 fly.io，真的大推！使用 3 Gb 以內的儲存空間都免費。還有支援 Laravel，連 Dockerfile 都會自動產出來，太強了吧！

在功能設計方面，遵循一切從簡的原則，然後一定要有軟體工程師最愛的 dark mode！只要有 dark mode 好感度直接先加 20 分！

管理者可以新增貼文、修改貼文的單元、對貼文做編輯、置頂、隱藏、刪除等等操作。當然，貼文也是以工程師最愛的 markdown 語法撰寫！

讀者使用 Google 登入後，可以按讚、留言，或是將貼文加入書籤收藏。

雖然還有許多其他想做的功能、以及需要改善的地方，但是既然最核心的部分已經完成了就先上線吧！之後再慢慢迭代出更完整的版本。

基礎建設做好之後，難能可貴的就是持續發表文章了。希望我可以做到穩定更新，就從蓋出這個家的過程中遇到的困難開始寫吧！

東京散步｜両国篇

Fri, 17 Mar 2023 09:11:02 +0000

一直以來最喜歡的北齋浮世繪作品都是《神奈川沖浪裏》

因為那開出萬千白花的浪尖，生動得彷彿是許多小手想將單薄的小船攫走。

這彷彿讓我看見，北齋畫了一輩子，終於在年老時遇見了普魯士藍，得以在畫布上自由揮灑江戶的海與天空的狂喜。

但今天在北齋美術館，看到了《山下白雨》這幅作品。一下子也躍升為我最喜歡的北齋作品。

在《山下白雨》中，山腳下烏雲密佈、雷電交加，而富士山山頂卻穿越雲雨，聳立在晴朗的天空中。

在有限的畫布上，北齋為了表現出富士山的雄偉，用了天氣作為對比，襯托出立體的高度。

在好的作品中，這種巧思好像無處不在。文學、攝影、繪畫、音樂，都有各自的方式。

我想，能將心中的想像，用手邊的工具實現的人。放在什麼時代，都是最厲害的吧！

TeamLab Planets Tokyo 不只是拍拍照片的網美展！

Thu, 16 Mar 2023 08:18:36 +0000

今天搭乘百合海鷗號來到新豐洲看 teamLab 和 DMM.com 合辦的展覽 teamLab Planets TOKYO。

原本以為只是拍拍照片的網美展，但看到廖文強的貼文說很值得一看，就馬上加入行程之中了。

看完的感想是，這果然是日本人想出來的展覽。在顛覆傳統的做法之中，同時保留嚴謹的程序，維持良好的觀展體驗。

整個展覽必須赤腳走過每個展間。隨著每個展間的地板材質不同，觀展除了是視覺的震撼以外，也是觸覺的饗宴。

赤腳踩在地上的感覺，彷彿整座展館都是自己熟悉的場域，拉近了觀眾與展品之間的距離。

在入口處有一條光之瀑布道路，其創作靈感是來自四國深山裡的瀑布。

但是撲鼻而來的漂白水味，透露了這其實是一道洗腳的程序。瀑布之道的盡頭，附上了擦腳的毛巾，優雅地解除了赤腳的衛生疑慮。

最後的展間是一池溫泉，從屋頂往下投影出躍動的彩色鯉魚。逛完整個展覽後，腳底滑滑的很舒服，比看展前多了一份身心舒暢的感覺。

在顧客想到之前，就解除他們的疑慮，並且以最舒服的狀態收尾。嗯，果然是日本人想出來的展覽。

孩子們的南陽街與大人們的補習班

Sun, 05 Sep 2021 18:53:53 +0000

「接下來的大學四年，將會是你們人生中過最爽的日子。」

Wayne 老師堅定的語氣，與其說是在向我們預告，更像是在回憶。「你們會發現，高中時期曾經覺得很厲害的大型成發、深刻的戀愛，原來是那麼地小兒科。在大學裡，永遠有更令你興奮的事情可以去做。你們要非常珍惜這段時光。因為，人生最爽、最無憂無慮的時候，可能真的就是大學這四年了。」

這是我高三的這一年中，在劉毅英文記憶最深刻的一句話。大我們 10 歲的 Wayne 老師，對高中生來說，不是一個長輩，而是同儕般的存在。他在課堂間偶爾閒談起的回憶，是我們在書堆中仰望的未來。升上大學以後，就是個大人了。自由彷彿唾手可得，那會是什麼樣的感覺呢?

《孩子們的南陽街與大人們的補習班》是一本記錄高中生們的青春歲月、也報導大人們的補習班事業的回憶錄。最初，我是在台下聽講的學生。本書出版後，我是該開始 ( 但拖延 ) 思考未來的大三生。再次閱讀，我已工作兩年並且轉職到理想跑到的上班族。每次閱讀本書都有不同的體驗，有種少年聽雨的感覺。

最大的不同，是初次閱讀時，我完全把焦點放在學生的部分，覺得這個學生好奇特、這個學生的煩惱我也有等等。而再次閱讀時，我則不由自主地關注 Wayne 老師在補習班的經歷，周旋於管理階層之間的為難。

同時也意識到了，當年滿心期待的每週三晚上，讓我感到能夠窺見大人自由世界的模考班解題時間，其實是扎扎實實地，經歷了許多苦練、苦澀，甚至是自我懷疑，才得以展現在我們面前。出社會工作了以後，才注意到光鮮亮麗背後的辛苦付出。

本書的作者蔡世偉 @waynetsai1984 為補習班老師、知名英文譯者。曾經翻譯過的書籍有：《原子習慣》、《我是GaryVee》、《麥可喬丹傳》、《曼巴精神》、《每一天的覺醒》等等。

本書一共分為三個部分，分別是「那些學生教我的事」、「補習班的那些事」以及隱藏版內容「課間閒談」。

「那些學生教我的事」是 Wayne 老師在補習班中所教到的奇葩學生，有母管嚴的森哥、熱愛山本五十六的軍事迷、考試與烘焙都臻至頂尖的北一女甜點師。每一位被提及的高中生，在努力符合學測、指考這個品管標準的，高中教育標準化製造流程下，都顯得特別的突出。突出的原因可能是有特別熱愛的興趣、特別擅長的技能，甚至是特別地聽話、不反抗。看完這部分後，不禁想到 Pink Floyd 樂團的 Another Brick In The Wall。教育究竟是讓我們變得更好，還是一種篩選機制呢?

「補習班的那些事」紀錄了 Wayne 老師在劉毅英文中的經歷與遭遇。從入行到成為補習班王牌老師。從光鮮亮麗的講台到下課的備課時間、再到與補習班管理層間的周旋等等。其中讓我印象最深刻的是補習班老闆劉毅曾經對 Wayne 老師說：「我討厭你！」。即便如此，Wayne 老師還是在書中表示他自己非常尊敬劉毅老師。其中最大的原因是，他被劉毅教英文的熱情所感動。劉毅曾經在講台上說過：「萬一我突然死掉了也沒有關係，我已經把講義都編好了，會有老師代替我上下去。」

我自己在高中補習的時候，每學期都會拿到劉毅出版社新編的單字書、文法書、句型書。雖然實際上沒有多少人看，但這種對於自己在乎的事情，展現捨我其誰的態度去做的精神，也深刻地感動到了我。

「課間閒談」節錄了十幾句 Wayne 老師在閱讀中深獲啟發的文字，並且加上他的人生經驗作為印證，是本書中我最喜歡的部分。日本出版社幻冬社的老闆見城徹曾經說過「重要的不是書中寫了什麼，而是自己如何感受。」在讀課間閒談時，我的腦中突然浮現了這句話。

Wayne 老師熱愛閱讀，並且藉由自己的人生經驗和作者們對話。閱讀《孩子們的南陽街與大人們的補習班》可以看見那些走在我們人生前面的人，反覆思索的問題與回答。同時也能知道，不是只有我一個人有這些煩惱。雖然我們必須靠自己過好自己的人生，但是我們並不孤獨。😉

The reading of all good books is like conversation with the finest men of past centuries. - René Descartes 閱讀好書，如同與過往世代的人傑們對話。 - 勒內·笛卡兒

立即註冊 👉 http://moo.im/i/DbsBO

立即購買《孩子們的南陽街與大人們的補習班》喚起那些憧憬大人世界的夏日回憶 👉 https://moo.im/a/3fglvC

日本人的縮小意識

Sun, 04 Jul 2021 05:15:59 +0000

なにもなにも、ちひさきものはみなうつくし。無論何物，凡小小者總是可愛《枕草子》

今天要介紹的這本書，雖然成書於遙遠的 1982 年，但其觀點在今天看來依舊非常新穎。《日本人的縮小意識》和露絲潘乃德的《菊與刀》齊名，被譽為戰後研究日本的兩大經典之作。

本書的作者李御寧，除了是梨花女子大學的名譽教授以外，也是韓國第一任的文化部長。在日本從戰後的廢墟中爬起，成為經濟巨人的 1980 年代，研究日本文化的書籍如雨後春筍般地湧出，但多數作品的視角片面且有許多盲點，並未道出日本文化獨有的特性。

李教授於此書中提出日本文化的核心在於，日本人有深植於基因中的強烈「縮小」意識。此一觀點的解釋力甚佳，涵蓋了自然、社會、語言、生活習慣等層面。

綜觀歷史，日本人的縮小意識古今皆然，是日本文化獨有的特性，並非東北亞或者漢字文化圈共享的文化。或許正因為這個看法極為簡單，所以是最真實的，讓這本書作為眾多日本論的書籍中，少數流傳至今的作品。

日本文化的原生特性是具有「縮小」的意識。 — 李御寧

書中首先列舉了六種日本人「縮小意識」的型態，例如套盒型、折扇型、便當盒型等等不同的縮小形式。並且舉了許多傳統俳句、寓言故事、生活習慣等實例來證明「縮小意識」確實存在，且是日本文化獨有的特性。其舉例涵蓋了語言、文學、建築、社會、生活習慣、歷史、外交等等面向，非常推薦實際閱讀，感受作者寬廣的知識邊界和其「縮小意識」的解釋力深度。

在此總結如下幾點：

例如將壯麗的山川縮小成庭院裡的枯山水、高大的樹木縮小成小巧的盆栽、滿桌的佳餚縮小成遠足攜帶的便當。🍱
現代則將電晶體縮小，做出隨身聽、數位相機等更輕更薄的電子產品。📻
除了實體的物品，在人際關係上也縮小到了一個榻榻米大小，僅能容納主與客兩人的關係，稱之為「座」。💺
除了茶室裡的主人與賓客，壽司師傅與饕客、開發者與使用者、作業員與產品。社會的許多環節，都形成了「座」的關係，是日本製商品獲得細心與高品質評價的源頭。🍵
若將擴張的文化輸出視為教導，那麼學習就可以被視為縮小。古代從中國、近代從歐洲、戰後從美國，日本史就是一部學習史。日本將外國的文化不斷壓縮進日本文化之中。👨‍🏫
歐美文化渴望創新與發現，日本文化則著眼於吸收與改良。19 世紀日本人在長崎的港邊，被譽為最優秀的學生，但20 世紀在廣大的太平洋中，卻成為了最絕望的迷途羔羊。🐑

本書令我感受最深刻的是第四章「表現於人與社會的縮小意識」。其中提到，日本人對居住空間的意識是使用榻榻米的面積去計算的，一張榻榻米的大小體現了一個生活在世界上所需的最小空間。從前，即使有寬廣主屋的人家，會客仍然是在四疊半榻榻米大小的茶室進行，是為了要體會剛剛好地和這個世界連結的感覺。

2016 年的冬天，我在德國當交換學生獨自旅行，入住青年旅館的時候，非常深刻地有這種體會。只需要一張床位的空間，便可以安穩地活下去。

我需要的，只是一個小小的空間，還有我自己。或許再加上一雙永遠保持好奇的眼睛。🧐

立即註冊 👉 http://moo.im/i/DbsBO

立即購買《日本人的「縮小」意識》一窺日本人內心的奧秘 👉 https://moo.im/a/7ioyBY

每本書，都是一扇任意門。

3 個電子書閱讀器選購重點，建立你的掌上圖書館！

紙本書與電子書的比較：

優點

紙本書

電子書

缺點

紙本書

電子書

適合的書籍特性

紙本書

電子書

閱讀體驗

紙本書

電子書

關於買書

紙本書

電子書

二手轉賣

紙本書

電子書

一句話總結

紙本書

電子書

書籍購買策略

電子書閱讀器選購重點

平台

封閉式、開放式閱讀器

尺寸

解析度

黑白、彩色

閱讀燈

我的主力閱讀器

售價：NT$4,288

售價：NT$9,999

售價：NT$15,099

2025 時光飛逝的一年

美西之旅 🇺🇸 Las Vegas

銀杏城市 🍁

第一印象 👀

拍攝形象照 📷

咖啡廳 heod 🍽️

戰爭紀念館 🫡

2024 伍伍慧台北演奏會。

初識太空時代 Space Age，一段人類共同的回憶與期待！

推薦書單第一彈！資訊職場、自我成長、商業、社會學、小說實作 and many more！

資訊相關：

《普林斯頓最熱門的電腦通識課》

《改變世界的九大演算法》

生涯規劃：

《大人學選擇》（暢銷增訂版）

《斜槓青年》【實踐版】

《只工作、不上班的自主人生》（暢銷增訂版）

《別輸在只知道努力》

商業、社會學、自我成長：

《品牌的技術和藝術》（暢銷慶祝版）

《我是一個媽媽，我需要柏金包！》（暢銷新裝版）

《專注，是一種資產》

真實故事（小說？）

《一千零一個點子之後》

寫作技巧：

《只要出問題，小說都能搞定》

《小說家之路》

《寫作革命》——散文、小說、文案、社群貼文輕鬆進階的40道練習題

售價：NT$4,288

售價：NT$9,999

售價：NT$15,099

優雅地與 Laravel 共舞，4 個實作步驟與 1 個具體範例，寫出可讀性與維護性俱佳的程式碼！

目錄：

實作 API 時的觀念與優化方向總結

DB Query 優化重點：

實作時的注意事項與使用 Laravel 框架實作的範例

Coding Style：

DB 相關：

流程設計思考：

錯誤預防與處理：

一段 Laravel FormRequest Sample Code 解說

微軟第一個抓住工程師的心的產品 VSCode！「實用套件」與「快捷鍵」全記錄。

VSCode Set Up for Web Development

Plugins：（套件縮圖以及 Nord 主題可以參考貼文代表圖）

《 The Effective Engineer》作者 Edmond Lau 導讀，增加 impact！！矽谷工程師都在做的事。