Skip to main content

28 docs tagged with "13th鐵人賽"

View All Tags

Go Generate & Makefile-番外篇

因為接下來如果要進行測試,勢必得在建立每個interface的時候都要新增一次mock interface,而且未來如果這個interface要擴增的時候,又得再重新輸入一次指令,所以在gomock官網中有提到,如果想要批次建立mock file,可以透過

Golang快速入門-2

那就接續著昨天的內容,今天提到的也是大家常用的function及slice

使用程式來管理資料庫(DB Migrate)

在這個之前的程式,都是先到資料庫那邊下語法建好表,然後再到程式這邊新增需要的屬性,但這個會有個問題是,如果有一天你需要到新的環境將你的程式部署起來,或是你需要兩個月前的資料庫型態,這時候就會發生你不知道之前執行了什麼樣的sql語法,不曉得兩個月前的資料庫長得怎麼樣(在你資料庫沒有定期備份的情況下)

在程式中建立關聯

在上一篇文章中,已經把資料表都建好了,接下來就要來將程式中的內容也建立起來

建立第一個RESTful api server(番外篇)-postman使用

在實作RESTful api時,會需要模擬實際用戶使用你的api的情境,這時候postman就派得上用場了,而且除此之外,還可以透過postman來讓用戶知道你的api是要如何使用,所以也可以把postman的文件當成你的api的文件,是個很好用的工具,他還有很多其他的功能,之後有機會再帶大家來操作,這次就先以他最基本使用到的模擬用戶使用的功能為主軸吧

建立第一個RESTful api server(設定環境變數篇)

在上篇的內容中,我們將資料庫的連線字串放進程式碼中,並寫死在裡面,但在常規的程式開發中,這樣是非常不安全,因為你不會知道你的程式會被誰看到,因此需要將這個連線的內容放到環境變數中,讓程式碼中不要出現這類的帳號密碼

建立表與表之間的關聯

在之前的過程中,已經建立了request以及command,而預計的規劃是可以透過一個command來觸發多個request的功能,而且多個command可以觸發同一個request,而觸發的順序可以自己定義,那要完成這個需求,預計要多開一張表,名為commands_requests,而這張表的主要目的是要將commands跟requests建立起關聯,因此目前規劃的欄位有

撰寫http request 的測試

大致的api都開設完成了,在這次的專案中,目前預計會實作的測試為實際的request是否可以完整執行,因為這麼實作,就可以把測試案例寫在程式中頻繁地進行測試,來做到向下兼容的部分

資料庫介紹

在上一篇內容中提到一個伺服器需要以怎麼樣的規格跟方式來跟用戶溝通,來讓他們找尋/新增他們需要的服務,但接下來的問題是,那我們該把用戶需要的資料放到哪裡呢?

資料驗證(golang)

在網頁的後端,除了要能正常地給存取資料,另一個重要的功能就是要有驗證資料是不是正確的功能,當使用者提供了一個不符合我們需求的資料時,就需要我們主動體醒使用者你哪邊有問題,應該往什麼方向去改

重構原本的內容(golang)

此次主要修正內容是將在定義資料庫的內容移動到pq的schema中,以及將兩個model都套用之前的設計概念,以及將error放入middleware中,以統一error message