第一次開發選服就烙賽

Intro

自從邱威傑市民服務網站上線後，一直想要完成這篇，紀錄一下這一個月多月開發以來的心得感想，但因為專案完成，本身也剛換工作，無預警進入了懈怠期，不知不覺就拖到現在了

晚上和呱吉跟他的政治團隊吃飯，回家後提醒自己寫下紀錄，今天大概就能算是一個圓滿的結束點吧～

18.12.07 確定接下案子

在這之前，第一次和負責的團隊成員——很年輕的法律系學生 @Eddy 見面，一開始當然不知道呱吉會打算怎麼做這個系統，原本以為會有前輩主導開發，去參與討論或插花即可，但實際上是最多找2-3個人做；也以為是要做能讓多個議員註冊、使用的平台，但需求聽起來卻像呱吉個人的宣傳式網站

我認知到一件事，那就是 Eddy 沒辦法準確評估我的技術水準，只知道我有做過網站。令人訝異的是，當天握手之後就直接把任務交給我了。當然，這是風險評估出了問題呢，還是完全信任夥伴？我選擇相信後者。（團隊的風氣感覺是年輕人放手去做就對了，烙賽沒關係？）

專案需求雖然很簡單：使用者填寫表單、送出後可以在後台編輯。但我還是一樣超沒信心，因為認知到：

• 我希望這是一個開源專案，如果要開源，會有資安上須考量的風險，加上呱吉是公眾人物，容易成為箭靶
• 短期會有高流量，分散式部署是必要的；自己沒有實際維運過分散系統，大概知道是怎麼做，但沒把握
• 重點是前端視覺與使用者體驗，但自己頂多做後端，前端雖然會寫，但根本在標準之下

18.12.08 臨時抱佛腳

因為擔心烙賽，最初的想法就是找個前輩進來坦。於是寫信問了貢獻多個 g0v 開源專案、同樣寫 Django 、投票指南的開發者駱勁成，詢問他有無興趣來主導開發。駱大因為在忙別的，沒辦法加入，但給了一些超級專業的建議：

臺北市議員也有建議款可使用。如果能將此款項擴大公民參與，因為是實在的錢和在地建設，相信人民會很有感，以紐約之前的參與式預算為例，他們讓使用者假設自己有一百萬美元，要他們分配在網路上分配這些錢（要實際標上地點和目標對象），台灣目前有辦過幾場以里民活動中心大小規模的參與式預算，我相信這中間是有機會結合的，例如網路上連署過某一標準的，要搭配實體在地活動中的多少支持，以解決人多欺負人少地區，或線上線下差距過大等問題。 另外各議會都有人民請願案，但一般人民沒有管道根本不太可能使用，所以常見到都是些前議員或大組織在提案，如果能結合上述的提案系統讓大眾認識人民請願案是真的有議員可幫他們發聲、管理追蹤，較困難也是挑戰的點是如何協助一般沒太多時間的民眾提案和議會冗長提案流程，應該是個不錯的切入點，也是循目前議會工作流程。

因為對如何 run 一個開源專案很不熟悉，臨時抱佛腳去參加了蜂蜜檸檬 g0v 大松，但大家對這個主題好像沒什麼興趣（跪，大概是我自己也不了解整個概念，解釋得很籠統，也不吸引人，所以大多人會有這樣的疑問：

• 為什麼不用 Google Sheet 就好？
• 議員去做選民服務，不太對吧？

總之，這兩天的結論是，伸手牌討教是很難的，最終還是要靠自己阿～～～

18.12.22 釐清想法誤區

由於大家想法落差滿大的，開會跟團隊工作人員釐清了一些各自對專案的理解，也提出自己擔心的點：

• 由於團隊對開發流程、成本比較沒概念，可能無法準確預估人力、能力是否有辦法達到最終想要的效果
• 當然很多事其實可以先做了再說，但這樣做出來的成品可能會跟團隊預期上有落差，技術水準不夠和開發時程過短，很可能導致這個落差產生
• 感覺比較像是需求方提功能，工程師只要照著做，可能做完就掰掰，長期參與或主導的可能性低
• 為什麼不直接找廠商做？實際上其實有詢問其他廠商，但行情開發就要80+，而這個案子能用的預算就只有12+，且開發時間短，簡單來說就是 Cost Down

就我所知，並非是呱吉想要這樣宣傳式的網站呈現，而是他沒有去限制任何事，而是全權交給團隊處理，而礙於開發時間短及許多經驗不足（包含如何完整構思與設計一套好用的系統），開發方向自然從一開始就被限縮了

不過我們還是有討論出的幾個共識：

• 短期: 做出團隊想要的網站
• 中期: 把這個專案帶到 g0v 提案，汲取更多經驗與意見
• 長期: 更多人的加入參與、調整，專案能擴大應用

接下來就是動工啦

前端的部份，團隊有合作工程師 Kai 加入開發，我另外找了大學同學 Matt 進來支援，初步確認出使用的框架及工具：

• 前端: Vue.js
• 後端: Django
• 架構: Docker
• 環境: Google Cloud Platform

專案初始化

自己剛學 Docker 沒多久，前端的開發夥伴則是沒用過 Docker ，如果要用 Docker 開發，最有可能的方案是自己搞出一個前後分離的專案架構，讓前後端能在同一個基礎上開發。但自己對 Nginx 很不熟，只能參考其他資源來設定，先前也沒有前後分離的開發經驗，所幸找到一個好物 cookiecutter-django-vue ，從此拯救了整個專案的生命

開發應該要有一個 workflow ，因為大家都不挑，自己就設定了非常簡易的 github flow + Travis CI 的開發流程，確保任何人上任何程式，專案至少要 build 得起來

後台與案件的編輯流程

對需求來說一個簡單的功能：案件能夠在後台編輯就好——感覺好像沒什麼，但如果只是一個能編輯的表單，沒有流程是會很悲劇的，例如完全沒處理過，就寄信告訴使用者已經結案這種事。案件是會有機狀態的，在狀態到狀態之間的轉換應該要做一些事前檢查，並事先定義要做哪些事，如發email、壓時間及檢查等。

一樣是拜 OpenSource 之賜，找了一個套件 django-fsm 來做，後台則是有搭配的 django-fsm-admin 來幫你加上一顆按鈕

寄信

最初的想法是盡量不要自己刻 email ，會有很多響應式的麻煩，參考了一些第三方寄信服務，最終選擇了 Sendgrid ，因為它提供了滿方便的 Template API ，能在網站上刻好模板，再帶參數進去，由於我們處理進度是用編輯器 django-ckeditor ， Sendgrid 的模板也能傳值為 HTML 的參數

另外一個好處是 GCP 有搭配的 Sendgrid 方案，一個月能免費寄12000封信

檔案

django-ckeditor 有支援上傳檔案，也有支援上傳至雲端，但僅限 AWS S3， 所以我們一開始是選擇用 S3 。設定完後，發現 ckeditor 對雲端的支援有個難用的限制，就是檔案只能傳到 bucket 底下的單一資料夾，而我們理想檔案存放方式卻是這樣：

另外很多人覺得黑人問號的地方是：既然都用 GCP 了，幹麻不用 GS？ 於是最後還是摸摸鼻子改回 GS ，上傳就不透過 ckeditor 了，改採 django.contrib.admin.TabularInline 來單獨上傳。

前端進度大延宕

後台功能大致上完成七成，但悲劇發生了。前端在預計測試的期限前只刻出了幾個超級陽春的畫面，這讓有強迫症的我相當崩潰，開會當天吐了一些不滿的點：

1. 認為需求端與開發端溝通嚴重不良，也沒按表執行和確認進度
2. 團隊根本沒給 mockup
3. 前端不知道畫面長怎樣，但有拖延心態，也沒去追
4. 團隊想要有動畫、有亮點視覺，但我不認為前端能在時間內端出來好的東西，以當下的產出來看，讓人有點不信任

解決方式：

1. 團隊趕緊派出賣肝平面設計師@東燁，加班好幾天出了圖，並在確認能力可及後，前端部份才終於能正常發揮
2. 請呱吉公開發文，在系統上線前請託一些前輩來幫 Review

討救兵

我在雲端部署上的經驗很菜，架構部份決定用自己熟悉度較高的 Swarm ，這在測試階段還算堪用，但一直很擔心上線會出現服務掛掉，自己沒辦法即時掌握、處理。就在這時候——救星出現了——某個國外的駭客，在我們的 Swarm 叢集內塞了一個挖礦服務，導致 CPU 使用率暴增，最終被 Google 判斷是挖礦行為，把整個機器關掉

當下真的是囧。對自己能力也是懷疑到爆。當時以為是 GCP 的權限沒設好，可能某個服務帳戶被登入，再進 VM 去起這個服務。後來才發現很有可能是資源沒有限制好的關係， 不只機器的 IP 都是直接對外， Port 也沒設定好，導致 Exposed Docker hosts can be exploited for cryptojacking attacks 這種情形發生

拜這個事件之賜，覺得真的不能再自己亂搞，請教了幾位前輩點解，尤其是在 g0v 裡貢獻許多的工程師 @Yutin Liu 熱情地拔刀相助：

約個一天的時間，我一步一步告訴你怎麼做

於是1月30日前往集界科技討教，花了大概4個小時的時間學習改用 k8s 架構，從私人叢集、 Pod 到建立前後端服務，回家後自己再補讀了文件，把 Ingress 和相關 Health Check 的設定完成。自己的心得是 k8s 不見得比 Swarm 好用，好壞因需求而異，但不得不說 k8s 設定上會比較省力，另外像是能把 .env 檔案存成 Secret，透過 envFrom Mount 進容器裡，以及 node 的 autoscaling，都是 Swarm 沒有的功能。

也真的萬分感謝 @Yutin Liu 和幾位前輩在開發期間不斷詢問及關心我們的開發狀況。（跪

19.02.19 反饋及擴大應用

系統上線了，第一週的使用者就破2萬，慶幸至今都沒有什麼重大傷病，之後幾個 Release 也順順的。試用了還在 beta 的 Stackdriver 來做監控，可以針對 downtime 或自定義觸發事件來寄發通知

使用者的評價普遍正面，雖然我覺得最後的視覺跟界面真的有點陽春，甚至很多能做的基本功能都不完善（例如案件底下沒有辦法留言討論），但可能是使用者同溫層或大多為呱粉的關係吧，大家都滿手下留情的。也收到幾個改善建議：

• 音樂太吵
• 分享竟然沒預覽
• 分類搜尋

到目前為止，收到且合併了 1 個 PR

另外也去了3月的大松提案，希望有興趣的人能加入或主導未來如何擴大應用。聽團隊的成員說，其實滿多新一代的議員有類似的需求，也希望能把他們任內做的事公開出來

結語

1. 雖然自己能力很有限，但如果跳到鱷魚池裡，最終還是能學到不少東西
2. 拜託來跳一下鱷魚池
3. 所以，議員到底該做什麼？

截至現在，使用者掉了不少，可能是團隊處理案件的人力只有2位，實際上能處理的案件也其實不多，或是有些回覆沒辦法滿足使用者；總之，我覺得大家都還在摸索這個問題的答案，包含呱吉團隊和我自己

---

最後附上一張合照：

最後，如果你喜歡這篇文章，請記得按讚加分享，也順便幫我點擊右下角的鈴鐺…

幹，差點忘了我又不是Youtuber