Monthly Archives: February 2019

與其前後端分離,不如單體多模

承續之前寫的〈在 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 另外搞一份前端實作,這樣追求「實用」與「練新功夫」就都顧及了。

在 Web 上使用 Material Design 元件

前幾天忍不住碎嘴起 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) 時,我更是興奮!但是在激情過後,我發現,他們截自目前實際上公開可用的元件很少,對我來說實在不夠用,於是我不得不放棄。

< mwc-icon/> is a 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 來,搞不好過個幾天,我又會發表說有什麼意外的坑,也說不定。就先記錄到這裡吧。

思考自己接下來在 IT 圈的發展路線

其實這個問題我一直在思考,也不斷在修改想法,「君子立志恆,小人恆立志」看來我就是個不折不扣的小人。

小時候(其實是大學畢業前啦)我想做個遊戲製作人,因為那時候(約 2000 年前後)遇到日本遊戲業界的大震盪,即使在經營困難下,不少公司、製作人仍舊出了很多有如藝術品(唸作:叫好不叫座)的遊戲。回頭看看,那段期間的煎熬,讓現在還存活的一些日本遊戲公司結出了豐盛的果實。

那個時候,我很嚮往「榨乾系統的能力,創造優秀的遊戲聲光、互動體驗,帶給玩家感動」這件事,也嚮往遊戲公司從頭(晶片)打造平台,充分掌握軟硬體這種「硬派」的作風。不過後來的發展卻是,遊戲公司沒人自己在搞處理器了,還願意自己打造遊戲引擎就該拍手稱許了,不管軟體硬體,相當程度已經轉為從外部找資源。我並不是說這樣的發展不好,因為系統發展的愈趨複雜,這樣專業分工是不可免的。

扯遠了…總之後來我並沒有走上這條路。後來我的工作多是做 Web 開發與打雜,在這段時期,可以說一直到今天,我想做的是「親朋好友在日常生活裡會用到的軟體」、「對社會有益的軟體」,這就是我為什麼去過中研院臺史所、中研院生物多樣性研究中心、曾有過圖書搜尋引擎產品的某公司、做活動報名與售票系統的那間公司。我一直希望自己能夠「益於世」。雖然我的三腳貓功夫還能勉強做這行,可是身體狀態的負荷,以及感受到隨時都會被年輕一輩(以十年為一世代的話,不只一輩,應該還有二輩、三輩…)取代的壓力,讓我又開始思考,自己還能做什麼?有什麼是在應用層面上更往中介軟體、核心元件走、不容易輕易就被嫩肝取代的?

回顧自己的本科所學,其實我知道那答案再清楚不過,就是「資料庫」與「搜尋引擎」。但是這兩門學問的坑都很深,在 Library and Information Studies 裡,會用稍微進階的 SQL 與 Boolean 檢索就算不錯了,遑論還要往理論與實作鑽,現在才說要踏進來,也許旁人看來可說是有勇無謀,貽笑大方,我自己也明白,所以就只挑了其中一個來專注研究。

我希望幾年之後,我在搜尋引擎這方面,可以提供專業服務。

重新檢討自己的技術選型

我現在的狀況是這樣:幾乎只能工作大約半個工作日(約四至五小時),手臂跟背部就開始抗議了,有時覺得那一天狀況奇佳,可以衝了快十小時,隔天就又被討回來。

於是我覺得我該重新檢討自己的技術選型。再不然,我就得考慮盡早轉行。

誠實地說,以往我因為自己的學歷出身,長期在這個圈子裡覺得很自卑,喜歡電腦科學、軟體工程,但是幾乎沒有用過比較貼近系統底層的語言,遑論做相關開發,這種無法往 “bare-metal” 靠、「榨乾、徹底且有效發揮硬體能力」的歷程,讓我覺得自己始終低人一等。

以前我讀朱邦復的組合語言教材《組合語言的藝術》,他錙銖必較於「少用幾個指令,卻做到相同的功能」那種情懷,很讓我嚮往,雖然我知道現在很多編譯器產品做的最佳化,已經很聰明了,往往只要你的程式寫法不要寫得太爛,效能表現其實都不會太差,反之,如果你的程式爛到原本就用很差的算法去叫電腦做事,用再怎麼貼近底層的程式語言,編譯器可能還是會編出同樣也是在繞很多路來做事情的機器碼,這樣並沒有比較高明。

但是我一直以來都在用相對「軟式」的 scripting language 做開發,常常還是會想「哪天我也可以做點比較『硬底子』、更貼近系統底層的東西」,如果可以這樣,自己是不是就可以更往 “bare-metal” 靠、更 rock 一點?

不過以我現在的狀況,我想了想,我必須選擇那些更能讓我表現 “intent” 的程式語言與工具,也就是那些雖然可能還是很「軟式」,卻可以一眼望去,就立即知道這段程式碼想要處理、解決什麼問題的程式語言與工具。

當然,scripting language 不盡然都可以很不反人類地表達 intent(為了怕傷感情,我就不多舉例了…),貼近系統底層的語言也不盡然就寫不出「高 Intent 表達力」的程式。所以我說的是,我接下來的技術選型,可以讓我更能表現 “intent”,粗糙一點來說,就是「同樣行數,卻更能涵蓋問題解法,且不管你資淺資深、本科非本科,有基本程式觀念的人都容易讀懂」的程式。

一來是因為我必須很容易找到人一起跟我共事,做出解決方案,二來,考慮我的生產力整個打折,我必須用更少時間,做出原來在正常工作日該有的產能。

再來就是,就算我沒能做出什麼揚名立萬、揚眉吐氣、超硬底子、超貼近系統底層的東西,只要我在這行,還能有點用處,解決一些其他人覺得很煩、很痛的問題,其實,就很好了。

補充:這篇網誌寫完後的晚間,我恰巧讀到〈尤雨溪回应:Vue与TypeScript为什么相性特别差?〉一文,其中提到 “intuition based design”,即符合我上面講的「表現 “intent”」這件事。我書讀的少,不知道有這麼一個現成的好詞可以表達我的意思,真是笑話了。

離開 InfuseAI

去年七月進來這家公司,但是最近身體狀況又變差,難以負荷工作,就在一月底決定離開。

其實多多少少還是有人在猜測背後有沒有什麼隱情之類的八卦,沒有,真的沒有。把在 Twitter 上寫的再貼來講一遍:公司沒有什麼問題,老闆是出社會以來遇過最好的,同事也都是極為優秀的人才,產品也解決了很多企業亟需導入 AI 時的基礎建設痛點。

而且很可惜的是,之前在 KKTIX 共事很愉快、從他那邊也學到很多東西的 Ash 後來也加入這間公司,再度當同事,但是我不得不先離開,不然還會再從他那邊偷學到更多東西。

真要說有什麼問題的話,就是我自覺給團隊惹的麻煩比貢獻多,非常抱歉。