[心得] - Final Project 實作心得


Posted by krebikshaw on 2020-12-28

摘要

首先我要認真的感謝跟我一同協作這份專案的組員 Nicolas、ruofan、small-leaf 以及老師,沒有你們就沒有這份專案(客套話不可少哈哈)。本篇文章當中,記錄了這份專案從發想到實作的過程,以及我認為可以給予新手讀者的建議。若是有專案相關問題,可能要看你找不找得到我。(開玩笑的啦~有問題都可以詢問組員,他們會很樂意回答喲!

我把專案從發想到實作出成果,按照時間的先後順序整理成一個故事,並把它分成下面幾個階段:

~ 2020.10.18 題目發想 (約 2 個月)

  • 確認主題、決定需求、初步規格書

一開始在訂定題目的時候,一直很難決定要做什麼,上網查了很多的資料,想知道對於面試而言,怎麼樣的專案才能讓自己達成加分的效果,像是餐廳網站、社群網站、購物網站、論壇系統、部落格...等等。各有各的優缺點,會接觸到的範圍也都有所不同。

還記得在第一次實體聚會的時候,為了「專題要做什麼」特地跑去問了 Minw 助教,當時助教給了我兩個很重要的方向,奠定我決定專案主題的基礎:

  1. 專案主題本身並不重要,重要的是你想要呈現出怎麼樣的自己,如果希望讓面試官覺得自己很善於研究跟學習,可以做一個技術性論壇,放上自己長時間研究的資料,可能是筆記也可能是自己撰寫的文章,利用類似論壇或部落格的網站,呈現出自己善於研究跟分析的特點; 那如果是希望讓面試覺得自己很猛很厲害,就直接一條龍幹到底,從專案規劃到前後端實作,所有技術自己上網學,所有東西通通自己生出來,自己部署再自己維護。

  2. 不要想說要做出完美的專案,因為身為一個新手,面試官本來就知道你就是爛,所以專案裡面的爛 code 什麼的都非常正常。不要自認為一定要做到完美,所以不用掙扎自己的專案主題是不是夠厲害,或者難度是不是夠高,這些都不重要,不要去拘泥於專案主題夠不夠厲害。

思考過助教給的寶貴建議,我想要呈現給面試官,一個能夠自行尋找答案,及能夠善於團隊合作的特點。我決定製作一個較為大型的網站,能夠學習各種不同的功能,也能夠讓多人一起協作,我想來想去,覺得購物網站比較大型,購物車、訂單、金流等功能感覺也很實用,很想要學習看看。但是我發現購物網站對我而言又太過於大型,我並不想把複雜的促銷活動,折扣運算...這些很容易出錯的功能加入專案當中,我希望網站是乾乾淨淨的。於是我最後想到的答案是「二手交易網站」。主打著不接受推促銷,不能夠搞活動,只能簡單的放上自己想出售的商品,及購買別人刊登的商品。功能單純,也能夠實作我希望嘗試的新功能。

於是我寫了一份專案的草圖,跟初步的需求規劃:https://mtr04-note.coderbridge.io/2020/10/19/prd/

2020.10.19 ~ 2020.10.20 招募組員 (約 1 天)

  • 小組成立,團隊成員共 4 位同學

一開始在招募的時候,我第一個面臨的問題,就是到底要招募幾個人?如果人太少,網站可能做不出來,人如果太多,可能不好去分配跟管理。少一點人彼此之間會比較熟悉,多一點人了大家就會變得疏離,一但疏離就可能產生反正人那麼多,我少做一點應該沒差的心態,這我是相當不樂見的。所以我最後決定把人數定在 4 人,其實 4 個人有點偏少,但是基於我希望組員能凝聚的心情,我決定是這個數字。

第二個問題是,招募的條件怎麼定?我希望這份專案不僅僅是合作,我還希望能藉此提前熟悉工作上的流程,所以組員必須能夠順利跟上開發的節奏,且學習要維持在進度之上。如果條件定太低,怕組員無法負荷開發跟學習的壓力,但是條件定太高,我怕我自己就要招募不到組員了。所以在招募組員的時候,我把之後合作的細節都寫的很清楚,告訴大家我的專案主題是什麼,我的要求是什麼,也特別強調我會採取敏捷配上 git flow 的開發流程,每一次的分配實作大約會定在 2 週的時間。我希望來報名的人,都是清楚規則且認為能夠身任才來報名的。

順利的是,我大概在 po 出招募文之後過了半天的時間,我就招募完 3 個組員了。既符合我的要求,又對我的專案有興趣,而且大家對自己的要求都很高。我覺得招募組員的環節,也是造就專案成功的基本要素,人數定得不對,或者組員之間不容易配合,都可能導致結果不如預期。

2020.10.22 ~ 2020.11.11 專案規劃(約 3 週)

  • 畫 wireframe、畫 userflow、規劃資料庫、規劃 API、撰寫 Spec

這邊大概是整份專案最有趣的部分了,「初期規劃」讓大家按照一開始寫好的 Final Project 大綱,利用 XD 畫出我們專案的 wireframe。看到我們的專案開始有了畫面,瞬間整個感覺都不一樣了。大家很開心開始在頁面上討論怎麼改會更好看,哪裡要加上什麼按鈕,哪裡可以多出更多功能。(這邊打個岔)

第一版本的專案,應該要 focus 在必要的需求上面,比如說我們的專案,必要需求就是:會員登入註冊功能、商品刊登購買功能、購物車訂單功能...等等。其他的像是,買家賣家聊天系統、網站幫助聊天機器人,這些是我們想做,但是並非必要的需求,就不該在第一版出現。

這個環節很重要,因為大家一看到畫面,就會聯想出很多其他網站會怎麼做,會有什麼其他功能,我們可以怎麼跟著做,這類型的想法。這個時候,大家一定要記住,收斂專案的需求,不可以讓需求不斷膨脹或放大。至少要有一個人,可以擔任類似 Product Owner 的角色,他要去分析到底要不要讓這些需求加進專案,加進來對專案來講是加分,還是對開發造成困難。

(回到故事之中)
我們在這個階段除了畫出頁面之外,還有規劃 userflow 跟規劃 db,這兩個流程也花了非常多的時間討論及修改,因為大家都沒有規劃大型網站的經驗,所以自然也不曉得到底哪些細節需要去注意,我們用 dbdiagram 來畫出資料庫的架構,再用 whimsical 來建立 userflow 的邏輯圖。還加上了手機版的版本(雖然最後沒有實作出手機版)

在基本的頁面跟資料邏輯都完成後,大家開始著手撰寫文件。利用 HackMD 撰寫專案的 API 文件,及規格書。把整個網站的路由跟資料的串接都建立起來,哪個功能要呼叫哪支 API,哪支 API 又該回傳哪些資料,把所有規格跟欄位都統一起來。

我們的專案進度,也依照老師的建議,用了 GitHub Project 來做管理,可以在看板上新增 Todo 分配任務給每個組員,再去追蹤大家執行的進度。

最後在專案規劃上,我們總共建立了 6 份文件:產品規格書、路由規劃、db 規劃、API 文件、wireframe、userflow。

現在回頭審視當初所撰寫的文件,發覺一開始在訂定的專案規劃,一定不可能完整。開發上發現問題,都需要再回來對文件進行校正,我們專案在開發時,也回來改過好幾次 API 文件。都是一改再改才有了最終的版本。所以釐清專案的需求很重要,每次開發跟文件發生衝突,都要回頭審視專案的需求,來決定哪邊是要修正哪邊是要保留的。

2020.11.12 ~ 2020.11.30 後端開發(約 2 週半)

  • 建立專案、任務分配、進行開發

我先提一下為什麼我們是先開發後端再開發前端:
因為我們當下的時間點剛好位於 week22 左右,而課程 week23 ~ week24 會讓我們把 React Redux 學完,課程就結束了。我將後端的開發定在 week23 ~ week24,在後端完成後,大家剛好把 React 通通學完,就能銜接前端的專案開發了。

(故事繼續)
後端開發,第一個面臨到的問題,就是要怎麼把專案建立起來,讓大家在開發的時候不會產生衝突?要考慮的點不光是程式碼,還有資料庫的建立。每個人的路由、邏輯、資料,要能夠清楚的切割開來,讓大家不會修改到同一份檔案。所以在專案建立的時候,我花了比較多的時間,把專案當中可以區分的功能都先區分開來:使用者相關、商品相關、購物車相關、訂單相關、其他相關,這些不同的功能把它用資料夾分開,讓每個人只需要在自己的資料夾底下做事。例如說:我是做使用者相關的功能,我就只要把我的路由寫在 userRoutes 底下,我的邏輯就通通寫在 userController 裡面。這樣就不會去跟其他組員的程式發生衝突。另外資料庫的部分,因為考慮到怕讓大家自己建立自己的 table 欄位,到時候整併會發生欄位不一致的情形,關聯上也會發生問題。像製作購物車的人,也要同時有商品的欄位,如果要跟製作商品的人複製欄位過來用也很奇怪。所以我最後乾脆直接把整份專案的 migrations 先寫好,大家在本地端只要直接利用 migration 建立好資料庫就可以了,每個人都會有全部的 table,且每個人的 table 一定是相同的,不用擔心最後整併會發生問題。

專案建立起來後,分配工作就比較容易了。只要確保彼此程式不會有衝突,大家就能放心的去開發功能。我們小組選擇的任務分配方式:是採取「自薦+隨機制」意思是先讓有想要自薦的組員發表自己很希望能做哪個功能,很希望分配到哪個工作項目,讓其他組員去表決看看那位組員有沒有誠意,要不要同意讓他做他想做的功能。等到自薦結束後,再讓其他組員去抽籤將剩下來的任務分配完成。至於最後的分配結果是如何我就不在這邊提了(蠻好玩的就是了)。

後端開工之後,我們採取每三天一次會議,讓大家在線上直接討論彼此遇到的問題,討論是否有需要彼此協調的部分。例如:商品放入購物車,到底是要給商品負責人做,還是要給購物車負責人做...等等。

我覺得後端開發最大的問題,在於大家對於購物車以及訂單系統的生疏。當我們把功能細分之後,會發現其實這兩個功能非常難做(在這邊向兩位負責人說聲辛苦了)。像是成立訂單的部分,它不單單是在訂單的 table 加入一筆資料而已,要先拿到購物車裡的資料跟數量,先對 products 的商品數量做試算,看看數量是否足以成立這筆訂單,核對賣家跟商品,把訂單成立之後,要在 Order_Items 裡頭寫入一份對應的明細。最後再依照對應的商品去將 products 的數量扣除。重點是中間的錯誤處理很複雜,商品又是一筆一筆的,在 controller 底下寫迴圈也要很小心。也因為要處理這些相較麻煩的邏輯,學會更進階的寫法:async、await、transaction、promise.all...等等。這些都是成長,都是在專案實作中的精進。

大家在驗收前,好幾個晚上都是熬夜在線上討論,為了能看到功能成功實作出來。

2020.12.01 ~ 2020.12.03 後端驗收(約 2 天)

  • 檢驗功能、修正問題

這次的後端驗收,基本上都沒什麼問題,幾個小地方有些 bug,額外花了大概兩天左右的時間做修正,最後也一起把 seeders 整理起來。在後端都完成的當下,正好是我們課程 24 週的結束。訂定這個時程,就是為了要讓大家在學完 React Redux,記憶正深刻,作業還剛寫完的這個 moment,進行我們的前端開發,無縫接軌。

2020.12.04 ~ 2020.12.14 前端開發(約 2 週半)

  • 建立專案、任務分配、進行開發

前端的專案建立,苦惱了我非常久的時間,我想破頭都想不到,該如何像後端一樣去區分資料夾讓大家在開發時不會發生衝突。其實最主要的原因,還是因為對 React 不夠熟,在 week24 的當下,要架設一個購物網站的前端 React 專案,比起後端的 Express 還要複雜太多太多了。後端只有 Migration、Routes、Controller 這三個重點要顧。可是前端呢?光是 Pages 底下的 Component 要怎麼分就已經很複雜了,是要從 Pages 做到 Component,還是要從 Component 做回來 Pages?Custom Hooks 要怎麼切?幫大家先切好,還是給每的組員自行處理?Reducer 跟 Action 還有 API 呢?哪些部分我要訂定好規格,哪些部分我要確保大家日後好維護?如果其中有些地方需要共用那要怎麼辦?我們的主題跟色調也要有一份規格出來,怎麼寫?寫在哪?按鈕的樣式呢?

在建立專案的這個當下,突然心裡冒出了一個念頭,怎麼感覺前端比後端複雜好多?是不是選錯方向了(應該要改走後端?喂~)開玩笑的!

回想起當初自己為何要做這份專案?不就是為了要呈現出能夠面對挑戰突破自我的一面嗎,想著想著,原本要睡了,突然腦海中閃過一陣靈感,啊!我想到了~我突然有感覺要怎麼分配了。趕緊跳下床,再次劃破寒冷的夜空來到我的電腦前面,拿起筆來畫出自己想像到的畫面。問我為什麼明明在電腦前還要用手繪嗎?因為覺得手繪就是比較好把腦子裡的東西畫出來。畫著畫著越畫越清晰,整個前端的輪廓就默默地畫出來了

雖然我現在已經想不起來,當初畫這個到底是什麼意思?(當下的自己才看得懂自己在畫什麼~)

總之前端專案的架構是想好了,剩下的就是把 React 真的架設起來。事不宜遲,我趕緊在群組裡面號招組員,一起約出來討論協作。因為比較臨時,只有 Nicolas 有辦法出來討論。於是在當週的星期六下午,我們兩個人頭一次約出來討論專案,一起將前端的專案架設起來,把開工前該訂定的規格,按鈕、輸入欄位、連結樣式、主題色碼...等等的內容都定好,準備迎來後天的前端開工日。

在分配任務的當天會議開始後,我信誓旦旦的將前端專案如何運行、如何開發、如何分配、開發順序、親自示範,全部都向組員展示了一遍,心想太棒了這樣分工肯定沒問題了。(其實事後回想,當天啪拉啪拉講了一大堆,中間都沒什麼問問大家意見,不曉得組員聽得是什麼樣的心情,好奇的打 +1)分配任務完成後,先是放下了心中一塊大石,既然專案架設起來了,剩下的就是按照訂定的程序去實作了。

前端開工後,大家依然按照每三天一次會議來進行開發進度的同步(這是大家協調出來一個最舒服的討論步調),每每在會議之後,都會一起討論如何修復 bug 討論到三更半夜。其中遇到了一次比較嚴重的問題,因為我實作的是會員系統,剛好我要跟商品系統負責人一同協作「賣家後台」的功能。當時要先同步商品系統的部分程式過來我才能接續,我用的是 rebase 指令,因為會議當下已經檢查過商品系統當下的程式是沒問題的,所以我就很安心的直接同步過來了。結果同步過來之後才發現,商品系統在我的本地端看會跑版,因為我的螢幕比對方小,所以對方在開發時沒有遇到問題,到了我的電腦上看才出現了跑版的狀況。臨時趕緊讓對方先修正版面跑版的問題,再發了一版更新給我。好不容易修好後,我再次使用了 rebase 這個指令,把新版本同步過來,說時遲那時快,電腦瞬間噴出滿滿的 Conflict。因為上一次 rebase 的內容跟新的版本發生了大量的衝突,但是最重要的部分是,商品系統的程式碼在某些地方也跟會員系統的程式碼發生衝突了。結果我一個沒修好,原本只是要修復好商品系統的衝突,竟然不小心把我自己的會員系統正常的功能也修壞了!而且因為我很信任同步過來的程式,所以在同步以前並沒有事先備份自己的 branch。結果把自己的程式改壞之後,最麻煩的就是如何將壞掉的部分重新復原。當時從大概半夜 12 點修到大概 4 點多才把我這邊的會員系統給修好。

修復流程:利用 git reflog 跟 git log --oneline 找到第一次 rebase 之前的版本,利用 git reset <版本號> --hard 回覆之前自己做的東西是好的,再直接在自己的紀錄上 rebase 最新的版本。
參考資料:https://dotblogs.com.tw/kinanson/2018/01/20/134721

修復完成後,趕緊在群組發一條緊急公告,讓其他組員不要去 rebase 那個新的版本。一定要先退回去舊版,在沒有 rebase 第一版的狀態項去更新新的版本。後來老師也有提醒我們,如果使用 rebase 的 conflict 太多,可以直接使用 merge 就好。

經歷了這次修復程式修到天亮的浩劫之後,我正式感受到備份 branch 的重要性。(並不是說 git 沒辦法回到先前的版本,而是要花時間回去找版本,不如事先做備份更方便)。
另外一個教訓是,commit message 超級重要!如果把 commit message 寫好,可以一目瞭然,如果寫得不好,有寫跟沒寫一樣,以前覺得這只是一個簡單的紀錄,不用太認真。現在發覺 commit message 是你要尋找版本的重要救星啊!

這次前端的開發,彼此協作的部分變多了,首頁、購物車系統、會員系統、訂單系統都會用到商品系統的 component。畢竟是一個購物網站,整個商品系統的重用性相當的高。這也造就了彼此協作上需要不斷的協調配合。包含後端的 API 也是!後台管理系統需要有分頁功能,所以商品後端的 API 資料要配合修改。要怎麼改?才能繼讓後台管理系統能夠使用,又不會讓商品系統原本寫好的功能壞掉?這些都是以前沒有遇過的問題。更讓我們在專案製作上學到了,前端工程師跟後端工程師要如何去溝通需求。讓別人知道你需要什麼,別人也能告訴你他能做到什麼。

此時的我深刻的體會到,還好老師有教我們如何寫後端,我們才能知道哪些問題是後端的責任(問題比較好推卸?喂~)

我們的前端開發,在驗收日以前,更是天天在熬夜討論如何修復 bug,提前體驗爆肝的職場生活。

2020.12.14 ~ 2020.12.20 前端驗收(約 1 週)

  • 檢驗功能、修正問題

前端的開發,比預期的要慢了一些,原先訂定 2 週的開發時間,老實說真的很硬!但是我希望把時間逼緊一點,因為目標訂太高,就算達不到,最後的結果也不會距離目標太遠。所以驗收日當天,雖然只有兩個人達成進度需求,不過在大家的努力下,專案的前端快要成形了,大家都很期待整合功能之後的成果。我們利用了額外 1 週的時間,才真正把前端的專案完成。下一步,就是把專案整合功能之後做總驗收

2020.12.21 ~ 2020.12.24 專案驗收(約 3 天)

  • 請老師審查、重構程式碼

此時此刻的我們,其實一直在思考著一個問題,就是我們第一版的專案完成了,那我們第二版要怎麼辦?我們還有那麼多的需求要做:串金流、支援第三方登入、買家賣家聊天系統...等等。後來這個問題還是請老師來協助了,老師給的建議是,將目前我們所擁有的功能都呈現完整,現在還有許多跑起來卡卡的功能,讓他先跑起來順暢,讓每個頁面的切換能通順,讓看起來空洞的頁面用東西填滿,還有最重要的是,把資料變得真實!真實的賣家、真實的商品,放上之後網站看起來就會看起來完全不一樣了。

於是我們將目前頁面上有瑕疵的部分都先修復,再手動製作了 240 多個商品資料,及 20 個擬真的賣家資料,讓整個網站的資料看起來真實。再把程式碼做一次大型的重構,將 Custom Hooks 的精神沿用進來,把畫面跟邏輯做完整的切分。把現階段的作品再做一次美化。

2020.12.25 ~ 2020.12.27 專案部署(約 3 天)

  • 前端部署在 GitHub Page、後端部署在 EC2

部署這個流程,意料之中的困難重重!本來就知道是道難關,跨進去還真是花了翻功夫才能過關。

後端的部署,有 week14、week17 的部署經驗後,其實還算有些概念。找回了以前部署時的筆記把部署的步驟複習一次,將我們的程式上傳到 EC2,開好一個要使用的 port,把機器跟 AWS 的防火牆打開,再利用 pm2 在背景執行程式,然後......啟動,一切相當的完美。

前端的部署,有 week21~week24 的部署經驗後,按照相同的概念,把我們的專案利用 GitHub Page 部署起來,在連到對應的網址,好像沒什麼毛病?才怪!

前端 GitHub Page 跑起來後,看到 console.log 出現了 Mixed Content 的問題(如圖)

大致上是說,前端是 https 但是後端是 http,所以前端的 request 被瀏覽器 blocked 掉了,前端拿不到後端的資料。什麼?我前端後端都架起來了結果兩邊資料不能溝通?

趕緊來找解決方法,上網查過很多資料,看是要改前端,讓瀏覽器不要阻擋,或者改後端將後端改成 https ...等等。心裡急著想要看到專案執行的成果,希望找出最快能成功的辦法,但後來想想,應該要考慮到整體專案的完整性!我應該要找出最合適的辦法,而不是最快看到成果的方法,詢問過老師的意見之後,最後選擇了將後端改成 https。整個改動過程也是一團迷霧,利用從老師那邊獲得的兩個關鍵字「reverse proxy」、「cloudflare」,查詢了網路上能用的資料來學習如何將自己的 Server 設定成 https。主要參考資料

好不容易將後端改成 https 了,趕緊前端跑起來看看問題是否解決了!
打開網頁一看,商品資料有了,但是其他 Component 都壞掉了!(這邊因為太心寒了就忘記截圖了),這問題我也是茫了,在本地端開發從來沒遇過這種問題。component 壞掉?

後來跟組員討論過後,我們猜測問題點是出在「路由」。因為當初在開發的時候,都是用 / 作為根目錄,我們所有網站的連結都是以 / 為路徑,現在部署到 GitHub Page 之後,由於 URL 會變成 krebikshaw.github.io/give-plus-plus,根目錄就跑掉了,現在根目錄變成了 give-plus-plus,導致前端所有的連結都會壞掉,很多 Component 也都沒辦法 render。

但是路由壞掉怎麼修?去把程式碼裡面所有用到連結的地方都改掉?整份專案有多少連結?我的天QQ,這會修到天荒地老吧,而且也不能保證會不會把正常的功能給不小心修壞了。再次搬出老師來協助,獲得關鍵字(怎麼感覺在玩什麼闖關遊戲),這次的關鍵字是 「設定 sub domain」,趕快來查詢資料,才知道原來 GitHub Page 其實可以讓我們自訂想要的 Domain。只要去註冊一個想要的域名,再把這個域名的 IP 導向這個網站的 Page,就可以成功轉移成我們想要的 Domain。

說來很容易,設定起來卻很麻煩,麻煩的原因不是說明看不懂,而是你不知道自己設定到底有沒有成功,因為設定完成後要等一段時間才會好,然後我就卡在一個,我不知道是自己沒設定好?還是時間還沒到?的一個窘境之中。然後吃不下也睡不著(太誇張囉~),一直刷那個重新整理,希望看到它顯示成功的訊息。等到凌晨 3 點,好不容易,它~成~功~啦~頁面真的出來了,而且 Component 沒有壞掉!這次沒有壞掉了!

只能說,那一刻,太感人啦(又睡不著了)
半夜發一個部署成功的公告到群組,群組裡有兩個人還沒睡,一同在第一時間分享喜悅!

2020.12.28 部署後修正(約 1 天)

  • 部署完成後 bug 修正

部署完以後就天下太平了嗎?才怪!
才部署完成,馬上又遇到一大堆 bug,而且都是本地端開發時沒遇到過的問題。還不只這樣,更離奇的還在後頭,這次大家明明是連到的是同一台 Server,打開的是同一個網站,但是出現的,卻是不同的 bug!

後來經過老師的建議,我們在後端 Server 對每支功能都加上 log,讓後端的機器上能保留操作上的紀錄。
加完 log 之後才發現到原來機器上面用的資料庫跟本地端有差異,導致相同的 SQL query 跑在本地端跟跑在 EC2 結果會不同。
大家在線上討論,釐清出問題以後,修復起來就快很多了。

我們最終將程式部署在兩個不同的地方,GitHub Page + EC2 跟 Heroku App,會部署在兩個地方的原因,一方面是想練習將網站架設在不同的平台看看,另一方面呢...不好說!(想知道的可以問去組員XD)

最後附上我們網站的介紹影片:https://www.youtube.com/watch?v=o4nH5tC_XKk&feature=youtu.be

此份專案,是「程式導師計畫第四期」的課程期末專案!不考慮題目發想的那兩個月時間,從確認需求開始,到最後完成專案開發,總共花費時間為:2 個月又 2 天。

再次感謝大家! (2020.12.28)

以下是其他組員的心得:
ruofan: https://px732amgo81sp8.medium.com/final-project-%E5%AF%A6%E4%BD%9C%E5%BF%83%E5%BE%97-d633fb1934c3

nicolas: https://nicolakacha.medium.com/%E7%A8%8B%E5%BC%8F%E5%B0%8E%E5%B8%AB%E8%A8%88%E7%95%AB%E7%AC%AC%E5%9B%9B%E6%9C%9F-final-project-%E5%BF%83%E5%BE%97-c89ff0c290f

小葉:https://smallleaf.medium.com/project-small-and-big-things-945bf8d92575


#Final-Project







Related Posts

D3v4 工作坊 - 製作 D3 plugin 來繪製草圖風格長條圖

D3v4 工作坊 - 製作 D3 plugin 來繪製草圖風格長條圖

使用 Docker 建立 nginx 伺服器入門教學

使用 Docker 建立 nginx 伺服器入門教學

[Day 07]: Dockerfile 初探

[Day 07]: Dockerfile 初探


Comments