這篇可能不會講到太多直接跟技術相關的東西,

如果你對這個東西怎麼寫出來比較有興趣的話,

可以看這篇:Clairvoyance 是怎麼開發的

主要是希望這次從開發到現在較多人使用,

中間受到許多幫助和指點的經驗,能夠被記錄下來,

假如以後有人遇到一樣的事情能從中借鏡。

當然,這也是對自己的一個反省。

首先還是得先講一下求職天~眼通是什麼。

它其實就是個 chrome 的 extension,

裝了它以後,能在人力銀行的職缺下方給評論,以及看到其他人給的評論,

載點在這裡:

pic

其他說明的話 ptt 上的文章會清楚得多。

目錄

Jean Grey and Cyclops from Entertainment Weekly

Jean Grey and Cyclops from Entertainment Weekly

求職天~眼通要做的事情很單純,

就是像前面說的把留言功能加上去而已,

不過其實就像我們平常在做一件事情一樣,用想的都很簡單。

但總歸其實只會遇到三個問題:

  1. 真正做的時候會遇到問題

  2. 做出來之後有沒有人用會是一個問題

  3. 有太多人用之後又會是一個問題

下面來說一下從端午連假到今天為止的這一段故事,

寫程式是這個故事很重要的一部份,

不過其實還有很多其他眉眉角角可以跟大家分享。

在開始動手寫程式之前

在開發前,首要的認知就是知道:

自己擅長什麼、手上有什麼資源,如果前兩者還不夠還要再準備什麼。

其實有這個發想是在端午節之前,

我平常是一個網頁前端工程師。

雖然也寫寫後端以及對系統感興趣,

但我知道 full stack 是一個被濫用的職稱。

這年頭多的是 Database 操作只會 CRUD 的前端工程師稱自己為 full stack,

或是只會套 bootstrap 的後端工程師稱自己為 full stack。

最常用的語言剛好就是 JavaScript ,可以直接拿來寫 Chrome 的插件,

但這還不夠,我還需要一個存放資料的 back-end。

下面這個基本上就是我畫在紙上的草圖:

pic

本來打算直接在 AWS 上開一個 EC2+RDS 放著,

後來發現只是單純留言,也沒有要真正 render 一個網頁。

這個 back-end 需要能達到兩件事情:

  1. 計算的能力

  2. 資料的持久性

首先是單純的運算能力,最終看上了 AWS 的另一個服務 AWS lambda,

它是以 function 為單位,不會需要我去維護整台機器(serverless),

而且當運算量變大時,我大 amazon 會自己幫我 scale-out。

於是稍微研究了一下 serverless 這套 framework,

也寫了一份筆記在這裡:

再來則是資料的持久性,我選擇了 DynamoDB,

是個跟 lambda 搭配很常見的選擇。

儘管它看起來就是簡單易用,

但為了這個選擇其實下了不少功夫,

一開始是因為對「最終一致性」有疑慮,所以去看了 CAP 理論:

後來再看了這本簡介分散式運算的書:

總歸對系統的架構有個理解後,才開始安心使用,

儘管現在回頭看這兩份文本都可以跳過,

但要做能 scale-out 的系統,

對分散式運算如果一無所知的話,會沒有那個 sense,

身為一個軟體人就不該對未知的東西姑息或害怕去學它。

接著一切就緒後,我突然發現我少了一位設計師夥伴,

基於不想在假日麻煩人,我上了 codepen 去看他們的 license:

codepen 是一個讓前端工程師放作品的地方,上面有蠻多好玩的設計以及如何實做的原始碼。

有人會問跟 pinterest 有什麼差別?

簡言之 pinterest 是比較偏向純設計師的。

簡單說一句話,就是 public pen 都是 MIT license 的,

要使用的話,只要包含了他們原本的 license,就可以自由使用。

雖然最後幾乎都只是參考概念,並沒有真正援用哪個 pen 上的東西,

但身為一個軟體開發者,就應該遵守這些基本的規定,

畢竟當真的有人要找你麻煩時,沒有不知者不罪這種事情。

如果對於這些法規方面以及技術有興趣的人,

可以去 follow Muzik Online 首席工程師 Ant 的臉書,

上面有許多能讓技術人有一些法規 sense 的文章,

而且對於 Database 和系統架構,上面也很多東西可以看。

好了,現在我有:

  • 前端開發能力

  • back-end

  • codepen 上參考的 UI

再來只是需要時間就能把東西做出來了。

發布 Beta 版本

大家看到的版本,其實是有滿滿 bug 的 beta 版本,

我只有讓身邊幾個朋友測試過,就先 po 在 soft_job 板上。

讓開發者以外的人先測過這一步至關重要,

因為自己開發的東西一定會有盲點。

會這樣做的原因是因為我想知道這東西是不是真的有需求,

當時 po 完文章就去睡覺,早上看到有三十推就覺得蠻開心,

結果幾個小時候 TonyQ 將它轉到八卦版去,直接一個爆衝。

但結局讓我又開心又害怕:

  • 開心的是這東西真的有需求,而且很有需求。

  • 害怕的是我覺得這東西還不夠成熟,怕一開始太難用就直接被拋棄。

令我意外的是, aws lambda 和 DynamoDB 完全撐住了流量,

當初把這些東西交到雲端託管有了成效,

後來去看 log 發現沒辦法留言,都是原本 code 裡面有 bug,

跟 AWS 一點關係都沒有 XD

不過後續就一直修到昨天晚上為止,留言功能才算正式穩定下來。

收到回饋之後

接著除了大量的 bug 回報之外,

也收到許多跟功能上有關的回饋。

其實大部分的回饋我都認為做了功能絕對會更完善,

但時間並不允許這樣做,

所以問題並不在於「現在要做什麼」,而是「現在不做什麼」。

這裡感謝 TonyQ 以及榮尼王給我的許多建議。

因為背負著很多人的期待,我並不能想做什麼就亂做什麼,

必須訂下一個明確開發的方向,

就現階段而言,讓這個 extension 活下去是至關緊要的事情,

因為已經有了第一批用戶(已註冊目前大概約四千多人),

剩下的只是繼續累積。

太激進、會讓人力銀行對這個 extension 採取行動的事情,

都不該去做,因為目前還玩不起這個槓桿。

不過 github 上面有許多人提了一些有辦法解決的方法,

總之,沒有「絕對不做」的事情,只有「現階段不做」而已,

有興趣的人也可以去看看,集思廣益:

Issue 討論區

商業化的迷思以及贊助管道

有蠻多人在提到這件事情要商業化,

也有人覺得只要「不商業化」就先把你貼上「傻傻、不懂事」的標籤。

但其實我一點都不排斥商業化,我只是單純的覺得這件事不適合,

或者現在沒想到適合的方式。

像是如果要在上面硬是建立一個什麼商業模式,(像是廣告什麼的)

這東西最後看起來只會是一個擾民的垃圾。

而且當以獲利角度來做這些事情,

我就不能單純站在勞工的角度去思考了。

至於要永續經營,後續等真正穩定下來後,

會放上小額捐款的連結,

這件事會在擬定如何公布經費的使用以及規劃後才做,

不在現在就先急著募錢的原因很簡單,

因為我想讓捐錢的人真正弄清楚他們的錢為何所用,

畢竟群眾募資不是大乞討,懂?

未來方向

這裡不談功能,最終的希望就是所有的勞方都會是天眼通的用戶。

因為大家並不是一年四季都在找工作,

但大家卻是一年四季都能上去做評論,

有時候並不是說一定要面試過或怎樣才能做評論,

短期內,可以揭露一些根本沒必要去的職缺,

長期下來,經驗的分享才是這個 extension 最難發揮價值的地方,

「老馬識途」這種事情,在職場上也是適用的,

總之,如何吸引大家去做這件事,就會是接下來的主要課題。

一個軟體工作者的反思

終於寫到這裡了,前幾天看到了 Codetengu 上分享了這篇文章:

我也想到前陣子 Alpha Go 很夯時,阮一峰所寫的文章:

身為一個軟體開發者,能了解電腦能做到的就是大量自動化、去中介化,

去取代掉那些機器可以取代的員工,

企業為了達成這件事情,自然要雇用一堆軟體工程師來幫忙,

所以軟體工作者也變成一個搶手的職業。

所謂技術帶來的平等,是指「資訊上」的平等,

我們的資訊流通因為網路和軟體越來越快,

舉例像是:歐巴馬總統和我們一樣都能用 google 快速查東西。

這年頭不知道還有沒有人記得百科全書這東西

但在財富上卻不盡然,我們拿到越來越多薪水時,也讓越來越多的人失業,

當此同時,除了繳了多一點點的稅,

我們大多數人並沒有負起什麼社會責任。

儘管軟體開發者理應是最有辦法讓想法付諸實現的人才對,

畢竟軟體能夠運行在電腦這個已經稱霸全球的載體上,

更別說我們還有了 Internet 這樣鋪天蓋地的通路,

寫程式這件事雖然有時候我也會因為智商不夠用覺得好難,

但是比起動不動要砸大錢的製造業,寫程式真的容易實現多了。

寫程式是世界的潮流沒錯,

只是許多台灣創業家提到寫程式就很喜歡強調矽谷如何、如何,

忽略了許多在本質上就有顯著差異的事情。

統計學裡面告訴我們:有顯著差異是要拒絕虛無假設的,這句話現在看來蠻有哲理。

我不會說面對國際市場是一件錯誤的事情,

在商言商總是有許多額外的考量,

畢竟連話說的不好聽,要怎麼讓人掏錢投資勒?

只是很多問題,其實台灣有其因應的解決方式,

而工程師本來就該是提出 solution 的人,而不是負責說空話的人,

所以更應該要虛心學習用一個台灣人的角度來看向世界以及台灣,

才能真正解決台灣的問題。

舉例來說:這個插件就是解決台灣特有的問題 XD,

因為國外的求職平台沒有像台灣這樣被壟斷。

中國那邊的招募平台也幾乎都有開放留言討論這個功能,

資方跟勞方是積極在爭論對話的。

所以這插件只有在這樣子的台灣才會有需求XD

題外話是其實台灣也有蠻多新的求職平台,

像是 sudo

或是 yourator

都相當不錯,而且在資訊上也相對傳統的人力銀行透明很多,

不過都是比較以新創或工程師為主。

特別講到 sudo 是因為他們的留言功能更完整,

(正因為以前就在那裡工作才更了解這些事情)

裡面的就職顧問雖然是講話很愛中英交雜的 AIESECer,

但絕對是真心要幫助工程師求職的:D

再來雖然現代人生活離不開電腦,

但其實對於軟體相關的事務都是有疏離和懼怕感的,

很多時候是因為身為人與機器的 Proxy 的我們沒有做好事情讓其他人有感。

身為一個在軟體產業工作的人,

這件事可能會蠻常見的,就是你有時候很難跟不寫程式的人敘述你到底完成了一些什麼 XD

舉例:

  1. 把什麼東西做了 cache 讓它更快

  2. 或是用了什麼 Design Pattern 提高了維護性

別人聽一聽常常是:「喔⋯⋯這樣啊⋯⋯」。

但生活中到處都是我們能夠付出專業能力去改變的地方,

工作之餘,還要有生活,生活之餘,

我們還能改善其他人的生活啊 :D

當認為有正確的事情該做,

就該運用系統化的角度去設計和解決,

因為假如做出來不小心規模化,你的系統又扛得住的話,

那可能就不小心改變世界了。

題外話是天眼通本來是個我跟別人講,

別人只會說:「喔~聽起來還不錯啊」的 Project。XDD

再說我們身在這個年代,

有各種雲端服務幫你搞定基礎建設(IaaS、SaaS、PaaS),

還有各種框架幫你搞定 UI。

基本上你只要有想法、計畫,再加上一段時間穩紮穩打的學習、練習,

幾乎就能解開各種 Issue 了,

不覺得很讚嗎?

讚讚讚!

也期許自己未來是真正的 RD 工程師,

而不是出現 bug 只會 XD 的 XD 工程師:

XD

References