取標題時我斟酌了一下，不曉得該從眾一點，用 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 則是看了我在他賣場下的採購清單，隱約察覺到我是想組整把鍵盤，很好心地提醒我不應該用「平衡桿＆龍船龍豆組」而是該用「衛星平衡軸」才對。這兩位業者的服務都很棒，真心推薦給大家。
我就這麼前前後後買了這些零組件，把這把鍵盤組起來：
焊接的時候，雖然有定位板的輔助，鍵軸排列不至於太過歪七扭八，但是實務上，還是不免會偏差一點，雖然這可能不到 1mm 的偏差，乍看沒什麼、不怎麼嚴重，但是卻會導致最後安上鍵帽後，看起來會很明顯，我的建議是遵循網上有人提供的作法，用直尺之類的工具輔助，確認沒有焊歪，且先確實整齊焊上四角的鍵軸，再一排一排地、每焊一顆都要再三確認是否焊接整齊地，把鍵軸焊上電路板。
再者就是，電路板與鍵軸、平衡軸組好之後，先接上電腦，測試每顆按鍵都有正常運作，沒問題的話，在鎖上底殼前，再次確認「平衡軸」有沒有確實安裝好，這個零件很容易在手持電路板的時候誤把卡榫鬆脫，導致依賴平衡軸的按鍵無法正常回彈。
這類基於 GH60 的自組鍵盤，就硬體面來說，可以完全自訂想用的鍵軸與鍵帽，所以如果想要「混軸」，取得最符合自己想要的觸擊體驗，也是輕鬆簡單就能做到；就軟體面來說，可以透過修改韌體原始碼，完全自訂想要的鍵盤配置，符合自己想要的鍵盤輸入方式，更是我之所以想要組一把這類鍵盤的最大理由。
我目前就將這把鍵盤的配置，幾乎 1:1 對照 HHKB，哪天我想再調整，甚至弄成 Dvorak 還是 JIS 配置，都只要改我自己維護的配置程式碼就好。
承續之前寫的〈在 Web 上使用 Material Design 元件〉，在撞牆一天多之後，找到原因，總算順利讓 Vuetify 動起來，不過這個強制包裹 <v-app/> 的要求，與我希望在專案漸進導入 Vue 的打算有所衝突，所以我可能會退回使用其他方案。
在這過程之中，我不免又再思考起我這個專案的初衷與基本要求：
基於以上種種，我今天得到的想法是，這個專案的設計應該是「與其追求前後端分離，不如單體多模」。
我指的「前後端分離」前端是那種 fat client 式的前端，地位等同於 App，也就是很簡單就可以化身為 PWA 的那種前端，而不是為了 SEO 搞的 SSR 那種夾在中間，角色尷尬的前端。看到 SSR 享受不到 token authentication 的優點，我就覺得一整個阿雜，雖然顧及了 SEO friendly，卻很難喜歡這樣在我看來疊床架屋的架構。這樣做的好處只剩下「前後端開發者各司其職」，就只是這樣而已，我覺得。
如果要這樣，不如取法 Redmine, WordPress 這些專案「單體多模」的設計，可獨立運作，也提供 API 給其他「泛前端」使用。
或許專業的前端開發者在這樣的架構下很難（用喜歡的、慣用的前端框架）做事，但是這個專案截自目前就只是我一個人的 side project，根本也不存在什麼「專業的前端開發者」與我共事，所以不用想太多，又或者，我在用「單體統包」設計的同時，也提供 API 另外搞一份前端實作，這樣追求「實用」與「練新功夫」就都顧及了。
前幾天忍不住碎嘴起 Bootstrap 與 jQuery，覺得它們就算至今還是很好用，而且有些地方，所謂「新的」、「正規的」解決方案，也不見得做的比較漂亮，對於有些人三不五時開嘲諷「你怎麼還在用這個？」很不是滋味。
但是我也明白「有些地方，不見得做的比較漂亮」的另一面就是「有些地方，它們確實做的比較漂亮」既然如此，趁最近養傷休息，放下一些不必要的我執，認識那些我這幾年來沒仔細關注的新 ECMAScript, CSS3, HTML5 特性，也不是壞事。
請相信我，我真的不想變成那種，我也敬謝不敏、敬而遠之的，某些堅持用土砲、過時且低效方法做東西的「業界前輩」。
於是我想透過「試著把這些『新的』、『正規的』解決方案，套用在我的 side project 裡」的方式來好好學習。具體的想法則是：「如何在我的作品採用 Material Design」，我的初始想法是，Material Design 問世有一段時間了，一定已經存在著某些採用『新的』、『正規的』解決方案來實作 Material Design 的工具與實踐。
今天我一開始嘗試的是 [material-components/material-components-web-components]，其實我很久很久以前就很想玩 Web Components 了，於是就先拿這個來用，這是我頭一次玩 Web Components，照著範例做，瀏覽器如預期秀出 <mwc-icon/> 時我真的很高興，再看到開發工具裡顯示 “custom…” 表示這是自訂元件 (Custom Element) 時，我更是興奮！但是在激情過後，我發現，他們截自目前實際上公開可用的元件很少，對我來說實在不夠用，於是我不得不放棄。
再來我看的是 [material-components/material-components-web]，雖然和前面的 material-components-web-components 都掛在同個 GitHub 組織下，名稱也很像，但是它的實作手法比較像是 Bootstrap，把既有的 HTML 元素「打扮」成帶有 Material Design 的風味，這樣的封裝雖不如 material-components-web-components 漂亮，但是這個專案的可用元件數量卻很完整。兩者可說是各有千秋，只是我還是很希望有朝一日，material-components-web-components 可以提供完整的元件，讓我用漂亮的封裝來堆介面。
所以，今天最後我的打量是採用 Vuetify（爆），一來我的 side project 採用的前端框架是 Vue，二來 Vuetify 提供的 Material Design 元件數量夠多，用起來也還算接近 Custom Element，算是取得了一個還不錯的折衷。只是我還沒有真的用起 Vuetify 來，搞不好過個幾天，我又會發表說有什麼意外的坑，也說不定。就先記錄到這裡吧。
其實這個問題我一直在思考，也不斷在修改想法，「君子立志恆，小人恆立志」看來我就是個不折不扣的小人。
小時候（其實是大學畢業前啦）我想做個遊戲製作人，因為那時候（約 2000 年前後）遇到日本遊戲業界的大震盪，即使在經營困難下，不少公司、製作人仍舊出了很多有如藝術品（唸作：叫好不叫座）的遊戲。回頭看看，那段期間的煎熬，讓現在還存活的一些日本遊戲公司結出了豐盛的果實。
那個時候，我很嚮往「榨乾系統的能力，創造優秀的遊戲聲光、互動體驗，帶給玩家感動」這件事，也嚮往遊戲公司從頭（晶片）打造平台，充分掌握軟硬體這種「硬派」的作風。不過後來的發展卻是，遊戲公司沒人自己在搞處理器了，還願意自己打造遊戲引擎就該拍手稱許了，不管軟體硬體，相當程度已經轉為從外部找資源。我並不是說這樣的發展不好，因為系統發展的愈趨複雜，這樣專業分工是不可免的。
扯遠了…總之後來我並沒有走上這條路。後來我的工作多是做 Web 開發與打雜，在這段時期，可以說一直到今天，我想做的是「親朋好友在日常生活裡會用到的軟體」、「對社會有益的軟體」，這就是我為什麼去過中研院臺史所、中研院生物多樣性研究中心、曾有過圖書搜尋引擎產品的某公司、做活動報名與售票系統的那間公司。我一直希望自己能夠「益於世」。雖然我的三腳貓功夫還能勉強做這行，可是身體狀態的負荷，以及感受到隨時都會被年輕一輩（以十年為一世代的話，不只一輩，應該還有二輩、三輩…）取代的壓力，讓我又開始思考，自己還能做什麼？有什麼是在應用層面上更往中介軟體、核心元件走、不容易輕易就被嫩肝取代的？
回顧自己的本科所學，其實我知道那答案再清楚不過，就是「資料庫」與「搜尋引擎」。但是這兩門學問的坑都很深，在 Library and Information Studies 裡，會用稍微進階的 SQL 與 Boolean 檢索就算不錯了，遑論還要往理論與實作鑽，現在才說要踏進來，也許旁人看來可說是有勇無謀，貽笑大方，我自己也明白，所以就只挑了其中一個來專注研究。
我希望幾年之後，我在搜尋引擎這方面，可以提供專業服務。