因為時間點很接近我從九州旅遊回來，所以可能會有人誤會我是去日本爆買，不過一來這台免治馬桶座是我阿爹之前還在工作時，公司不知以什麼名義送的，其實堆在我家角落已經很多年了，二來我現在根本沒有錢可以爆買、揮霍，連這次旅費都是老婆拿之前的家用基金幫我墊付的。

（大膽不怕羞的廣告字幕：我在找工作，希望靠近台北市內三間客運轉運站（南港、市府、台北），或是可以遠距上班，請參考我的 LinkedIn profile。）

總之就是，因為老婆表示免治馬桶座真的很方便，所以我就把它拿出來裝了。

安裝過程其實不是很順利，因為套件裡頭只有附上使用說明書，沒有安裝說明，所以摸索了好一陣子。配管尤其折騰了一下，為了把附的銅管截出合適的長度，我還動用到線鋸與銼刀。總之最後還是裝好了。

然後我終於解開了多次去日本旅遊時遇到的一個謎題：廁所裡總有一股我無法分辨的味道，之前我以為是臭氧除臭設備之類的產物，裝好這個免治馬桶座，我才發現原來這味道是馬桶座本身材質發出來的。

免治馬桶座真的是很方便啊！除了比較衛生，附帶效應是省衛生紙，因為在洗淨之後，衛生紙主要的功用就只是擦乾而已，所以原本也許要用多次份量的衛生紙，現在通常只需要一份就夠了，此外加溫的馬桶座，在天冷時候如廁更是覺得舒適。

很推薦大家都來安裝。

取標題時我斟酌了一下，不曉得該從眾一點，用 authentication，還是根據實際機制，用 authorization。這兩者負責的是不一樣的事情。

前幾天看到 [JWTs Suck] 這份簡報，絕大部分提到的我都認同，因為這陣子在無業之中刻自己的專案，似乎不該叫做 side project，可是又不太想稱為 toy project，當中就花了很多工夫在理解並刻出 JWT 的發券與核對的程式，可是後來我愈來愈覺得 JWT 實務上並沒有如宣傳講的那麼便利，偷工省下來的一些優點，在需要更多彈性時，反而綁手綁腳。

但是無論如何，考量到除了 Web 以外，我的專案還會有 mobile app 等場合需要呼叫 API，token 在這樣的場景下，比 session coookie 方便多了，是不爭的事實。所以雖然我決定棄用 JWT，但是我還是想要繼續採用 token，譬如說，Phoenix 本身內建的 Phoenix.Token。

前幾天，把我在家的主力鍵盤 FILCO Majestouch 2 Ninja Cherry MX 黑軸改成 Gateron 白軸，原因是我覺得 Cherry MX 黑軸對現在的我來說，觸發力道 (60g) 負擔稍微重了點，我想要換更輕一點的，一不做二不休，乾脆選了 Gateron 白軸，這款只有 35g 的觸發力道，應該是目前市面上量產 MX 相容鍵軸當中最輕的一款。

解焊的過程…雖然我的 Ninja 是 87 鍵款，比起全尺寸的 104 鍵少，但是還是吃足了苦頭，幾乎用完了一綑吸錫線，一直要到很後面我才掌握到解焊鍵軸的訣竅：先在焊點補一點「新鮮」銲錫，讓銲錫上的松香輔助，使焊點上的銲錫加熱到適合吸錫器的工作溫度，把絕大部分的銲錫吸走，剩餘卡在接腳與電路板銅箔間的微量銲錫，再用吸錫線處理。不這樣做的話，單用吸錫線處理，太浪費了，也不見得方便。

焊上新的 Gateron 白軸後，第一印象非常滿意，打字起來非常輕鬆，但是…有些地方卻輕過頭了，很容易誤觸發，所以這幾天用下來後，我剛剛又把空白鍵與 Enter 鍵換成 Gateron 黑軸，效果讓我很滿意。會這樣再微幅調整的主因就是，我會習慣（甚至我覺得大部分人應該也是這樣）把拇指靠在空白鍵上，有點像是手掌在鍵盤上的支點，所以這裡配 Gateron 白軸對我而言太軟了。至於 Enter 鍵則是很「關鍵」，我也不希望稍不注意就誤送出一堆錯誤的資料，也一併改了。

另外有一點要特別講的，就是因為 Gateron 白軸真的太輕了，反而很容易敲到定位鐵板，整體聲響比原先的 Cherry MX 黑軸還大，想要依樣畫葫蘆改軸的人，如果噪音是個考量，可能要考慮一下連同鍵帽也加裝 O-Ring，權充鍵帽與定位鐵板間的緩衝。

之所以會組這把 60% 鍵盤，起因是我在上一份工作中，為了 MacBook Pro Retina 難用到出名的鍵盤，而另外準備的「便攜式外接鍵盤解決方案」 ：不能像之前在 K 社那樣，沒有固定的辦公室可以擺鍵鼠組，只好改而講求更方便攜帶的外接鍵盤。

但是更早之前，其實我就考慮過自己組一把這種小尺寸的機械式鍵盤了，那時候還是出於純粹為了趣味的動機，所以去了中國知名的電商網站上淘了 XD64 電路板與相關零組件，無奈因為店家原本的美意，附上了一隻組裝過程中很可能會用到的工具——鑷子——反而在運輸過程中被當成違禁品而退回，聯繫過程中，貨運業者、店家的皮球踢來踢去，貨運業者的線上客服介面甚至還刻意阻擋臺灣來的連線，我在日本開了一台 VPS 架 VPN 方能連上（然後繼續與客服人員鬼打牆…），這次經驗讓我非常不高興，也因此滅了興致。

那時候我還不知道我不需要如此捨近求遠，其實在臺灣就可以買到基於 GH60 的這類自組機械式鍵盤電路板。後來自己再做了功課，才知道「改裝軍團」有 AMJ60、「Play Keyboard 玩鍵盤」有 PK60 可購買，且「改裝軍團」的 Tina 姐、「Play Keyboard 玩鍵盤」的 Barry Huang 人都很好，Tina 姐不厭其煩地回答了我不少問題，雖然後來我應該是因為材料的緣故選擇在「Play Keyboard 玩鍵盤」一次購足，但是之後遇到有人有採購、客製鍵盤的需求，我還是會推薦他們「改裝軍團」；而 Barry Huang 則是看了我在他賣場下的採購清單，隱約察覺到我是想組整把鍵盤，很好心地提醒我不應該用「平衡桿＆龍船龍豆組」而是該用「衛星平衡軸」才對。這兩位業者的服務都很棒，真心推薦給大家。

我就這麼前前後後買了這些零組件，把這把鍵盤組起來：

• 60% 陽極鋁定位板
• Play Keyboard60 DIY 60%鍵盤 PCB 電路板
• 台灣太豪 Tai-Hao ABS 104-key 黑同刻 ＆ 1.75U Shift + 1U @R1 Blank 增補鍵（後來我才知道，其實以我組 60% 的鍵盤，不需要買到完整的 104 顆鍵帽，買 61 顆主鍵位區的就可以了，反而是「1.75U Shift」與「1U @R1 Blank」這兩顆增補鍵更是建議買足，多一個切換功能的 Fn 鍵，用起來方便多了。）
• Gateron機械軸 黑軸
• 衛星平衡軸（PCB mounted專用）
• 60% PCB 塑膠外殼

焊接的時候，雖然有定位板的輔助，鍵軸排列不至於太過歪七扭八，但是實務上，還是不免會偏差一點，雖然這可能不到 1mm 的偏差，乍看沒什麼、不怎麼嚴重，但是卻會導致最後安上鍵帽後，看起來會很明顯，我的建議是遵循網上有人提供的作法，用直尺之類的工具輔助，確認沒有焊歪，且先確實整齊焊上四角的鍵軸，再一排一排地、每焊一顆都要再三確認是否焊接整齊地，把鍵軸焊上電路板。

再者就是，電路板與鍵軸、平衡軸組好之後，先接上電腦，測試每顆按鍵都有正常運作，沒問題的話，在鎖上底殼前，再次確認「平衡軸」有沒有確實安裝好，這個零件很容易在手持電路板的時候誤把卡榫鬆脫，導致依賴平衡軸的按鍵無法正常回彈。

這類基於 GH60 的自組鍵盤，就硬體面來說，可以完全自訂想用的鍵軸與鍵帽，所以如果想要「混軸」，取得最符合自己想要的觸擊體驗，也是輕鬆簡單就能做到；就軟體面來說，可以透過修改韌體原始碼，完全自訂想要的鍵盤配置，符合自己想要的鍵盤輸入方式，更是我之所以想要組一把這類鍵盤的最大理由。

我目前就將這把鍵盤的配置，幾乎 1:1 對照 HHKB，哪天我想再調整，甚至弄成 Dvorak 還是 JIS 配置，都只要改我自己維護的配置程式碼就好。

承續之前寫的〈在 Web 上使用 Material Design 元件〉，在撞牆一天多之後，找到原因，總算順利讓 Vuetify 動起來，不過這個強制包裹 <v-app/> 的要求，與我希望在專案漸進導入 Vue 的打算有所衝突，所以我可能會退回使用其他方案。

在這過程之中，我不免又再思考起我這個專案的初衷與基本要求：

1. 我希望這個網站的內容是 SEO friendly, Web crawler friendly 的，我希望兼顧 SNS 元素，同時希望上頭的資訊不會被關在 crawler 爬不到（或很難爬到）的黑洞、黑盒子裡。
2. 我希望這個網站的操作是 keyboard friendly 的，行有餘力，再追求 touchscreen friendly。
3. 我希望這個網站有一定程度的資訊即時更新能力，但是這也是行有餘力再追求的 nice to have。
4. 我希望這個網站的搜尋能力比 Twitter, PTT 好，這就不是 nice to have 了，而是 essential。
5. 我希望這個網站的設計風格給人溫暖的感受。

基於以上種種，我今天得到的想法是，這個專案的設計應該是「與其追求前後端分離，不如單體多模」。

我指的「前後端分離」前端是那種 fat client 式的前端，地位等同於 App，也就是很簡單就可以化身為 PWA 的那種前端，而不是為了 SEO 搞的 SSR 那種夾在中間，角色尷尬的前端。看到 SSR 享受不到 token authentication 的優點，我就覺得一整個阿雜，雖然顧及了 SEO friendly，卻很難喜歡這樣在我看來疊床架屋的架構。這樣做的好處只剩下「前後端開發者各司其職」，就只是這樣而已，我覺得。

如果要這樣，不如取法 Redmine, WordPress 這些專案「單體多模」的設計，可獨立運作，也提供 API 給其他「泛前端」使用。

或許專業的前端開發者在這樣的架構下很難（用喜歡的、慣用的前端框架）做事，但是這個專案截自目前就只是我一個人的 side project，根本也不存在什麼「專業的前端開發者」與我共事，所以不用想太多，又或者，我在用「單體統包」設計的同時，也提供 API 另外搞一份前端實作，這樣追求「實用」與「練新功夫」就都顧及了。