我寫了一個 chrome 的插件,


能夠讓求職者在人力銀行的職缺下面留言討論。


聽起來是很平常的需求,不過各大人力銀行就是不做這個功能,


所以我想看看假如有這個功能會不會對求職有正向的幫助。


下載的連結在這裡: Clairvoyance - 求職天眼通


目前還在 beta 階段,可能會有些 bug,


可以到粉絲頁留言,


或是在 github 上直接發 issue。


下面就來筆記一下為什麼要做這件事,以及怎麼做到的。


用的技術就是以下列的這些



  • front-end: reactjs、redux、redux-saga



  • back-end: aws-lambda, dynamodb, serverless-framework





目前只支援 104 和 1111,至於 yes123,後面會再提到為什麼暫時沒做。



下面來簡介一下是怎麼做出來、以及為什麼要做。


clv intro



Introduction

為什麼要做這件事情?


其實我比較想問的問題是:為什麼不要做這件事情呢?


我們買商品的時候,在拍賣網站上就可以看到買家對店家的評價、對商品的評價,


而求職的時候,卻一定要到其他討論區、其他網站,


才能看到其他人對於該職缺或公司的評價,


這其實是一件很不自然的事情,


再說種種擔心對手黑函還是求職者亂抹黑什麼的,


嗯⋯⋯電商其實也會遇到這樣的事情,


總之想不到一個很合理的解釋,


唯一能想得到的解釋就是「盈利模式」


目前我們在人力銀行上找工作,其實是不用付錢的,


但是企業卻是要付費用才能張貼職缺。


合理的推斷,


其實我們這些求職方就是人力銀行的商品,


真正的使用者是那些企業用戶(資方),


而讓使用者能夠留言討論的功能,


可能會讓部分企業用戶不想使用。



看看各大人力銀行上,許多職缺都喜歡「面議」


就知道資訊不對稱對於資方來說是一件多麼正常的事情


我不會認為敘薪是簡單的,


但給個底價,避免浪費彼此時間這件事,


真心不應該難道哪裡去。


否則騙人去面試的行為,其實跟詐騙集團一樣可恥



無論背後的動機是什麼,


既然人力銀行有其考量不做這件事、我又認為有需要的話,


那與其動嘴巴抱怨台灣的求職平台不好用,


不如自己來做做看,看能不能為台灣險峻的就業環境帶來一些幫助。



在做這個 side project 之前,


其實我自己找工作從來都沒有用過各大人力銀行,


這次還花蠻多時間在探究自己到底為什麼不用這些平台,


以及他們到底缺少了什麼。



What is clairvoyance

為什麼是這個名字?


命名一直是蠻困難的一件事情,


本來有想過要叫什麼 job-bar in in der。


不過後來還是靈光一現跑出這個單字:


Clairvoyance。


為什麼要取這個名字有兩個版本的故事:


高級版本

Clairvoyance,可以翻作洞察力或是透視,


主要是希望透過求職者彼此分享經驗,


來透視一個職缺的好壞,或是否適合他。


真實版本

其實就是 google 天眼通,


翻譯的第一個單字就是 Clairvoyance,


然後我蠻喜歡周星馳的賭聖,所以就這樣命名了。


Why is Clairvoyance

其實會做這個 project ,


有一部分是因為自己最近開始接觸分散式運算,


開始了解去中心化的想法,


我認為與其把所有對平台上職缺的評論給「集中」起來,


不如將它分散到各自原本的職缺下方,


然後再將相同職缺的評論同步。(Consistency)


這樣的做法是更合理,而且使用起來更有效率的。


Architecture


假如說一開始我知道會這麼搞剛的話,


應該就會放棄了⋯⋯



整個 project 主要分成三塊:



  • gui:Chrome extension 的 UI



  • serverless-clv-backend



    • 處理後端的資料



  • serverless-clv-auth



    • 問題:chrome 的插件是明碼的,假如要在上面做認證,就要在 chrome 上面直接放 secret key,這樣做一點都不 secret



    • 解法:開了一個 serverless 的 api 專門來做這件事情,在 repo 的 README 裡面蠻詳細的紀錄如何做到,所以這篇裡面不會贅述這一點。






這裡畫了個很粗略的圖,看一下會比較有概念:



clv = clairvoyance



clv arc


其實 backend 就是處理留言、工作、使用者,


而我並不想自己維護一台機器做這些事情,


所以我用了 serverless 的方式去解決,


想要瞭解更多關於 serverless 基礎的人,


可以看一下這篇舊文:淺析 serverless 架構


是我剛學習 serverless 時做的筆記,


同時也是繁體中文裡面最詳細的新手教學。



就算簡體中文其實也是啦



前端的話,有一些比較討厭的部分就是非同步的處理,


但這裡 saga 很簡單的幫我 handle 處理好了,


而且還給了相當好的測試性,


這點非常非常重要,


測試省掉了我不少 debug 的時間。



中間大概重構了一兩次



Back-end

首先就是要先訂好 schema,以及各個資料相互的關聯性,


這裡有用到 GSI 來建立查詢的 index,


雖然我們會用公司名稱以及職缺名稱來查詢,


但這兩樣東西都不適合拿來當作 Primary Key,


我覺得看完這篇官方的最佳實踐


就已經差不多能掌握怎樣去設計一個拿 dynamodb 當作資料庫服務的心法,


剩下的只是把資料長怎樣想清楚而已。



使用 DyanmoDB 時,會考慮到資料一致性的問題。


但畢竟這不是一個非常要求即時性的服務,


所以我對於最終一致性這件事情是有相當高的容忍度的 :D


什麼是最終一致性呢?


就是我們不保證每個節點讀取資料時,資料都會是相同的,(強一致性)


但隨著時間過去,每個節點上的數據會回歸一致。


這只是很粗略的說法,接下來幾個禮拜可能會寫一些和分散式有關的,


就會提到這一點。因為一致性對於分散式運算來說一直是一個很頭痛的問題。



Front-end

我選擇使用 React 及 Redux 的原因蠻單純的,


因為我最近常在工作上用到它們。



  • Reactjs+ CSS Module



    • CSS 的命名一直是一個很難解的問題,這裡我的想法是無論再怎麼有效的規範,都是軟性的,CSS 的特性讓全域污染這件事情變得難以避免。但 CSS Module 卻可以讓所有的 class 都變成 local 的,


    • React 以 component 為主的開發模式,跟 CSS Module 搭配起來相當不錯





  • Redux Saga



    • 處理非同步的資料流(像是從 backend fetch 資料)



    • 有些 UI 上的 transaction 都可以在 saga 處理



    • 使用 saga 的重點是「測試」,effect 的概念讓測試變得簡單很多,少了各種 mock







其實這裡本來想用 Rx 搞定,但工作上真的用了太多 Saga,現在有點回不去了⋯⋯


假如你未曾瞭解過 saga,可以看一下我的這篇文章 Saga Pattern 在前端的應用 



UX

這裡不是要說有著多精美的 UI,


是自己開發時,總覺得我開發的東西,真他媽怎麼用怎麼順手啊!


實際上別人一看到時,卻常常完全不是這麼一回事。


最好的方法就是請朋友幫忙用一下,


然後什麼都不要跟他說,也不要有任何預先的假設。



沒錯,就算你有說明書,User 就是死都不會看(我也是)



很常發生的事情就是 User 完全不知道你想幹什麼,


留言區塊那邊一開始就是這麼一回事,


所以如果有人說你做的東西「太工程師」、「太 geek」,


大概就是這個樣子。



感謝我的幾個被我巴著幫忙測試的朋友。 m (_ _) m



Conclusion

目前只支援 1111 以及 104,


yes123 的 url,有那麼一點難以預測⋯⋯


不過也是因為這個 Project ,可以感覺到各個求職平台是否用心,


未來要加入的功能應該有以下幾項:



  • 個人留言職缺的追蹤



  • Facebook 粉絲頁的機器人



    • 幫忙發布熱門討論的職缺



  • 重構



    • 比較有問題的應該是建立職缺那裡的 code 很醜 XD




其實我知道這個 beta 版本還有許多可以更好的地方,


不過我更想瞭解這個插件是不是真的能解決一些問題,


所以就先釋出這個 beta 版了!


假如有什麼想問的問題也可以留言、發 issue 或直接跟問我,


對我來說,不只是想 build 一個小小的插件,


我想造出一個對求職者來說真正透明友善的環境,


我知道一定會有蠻多人覺得這真是 too young, too naive 的想法,


不過不試試看,怎麼會知道結果怎樣勒?