相信大家都知道 Select 可以用來處理多個 Channel，但是大家有沒有想過一個情境，如果是 for 搭配 select 時，肯定會用一個 Timer 或 context 來處理 Timeout 或手動 Cancel，假設如果跟其他 Channel 同時到達時，官方說法是 Select 會隨機選擇一個狀況來執行，如果並非選到我們所要的 case 那就會造成情境或流程上的錯誤，而本影片就是講解該如何解決此問題，請大家務必詳細了解業務的需求，來決定程式碼架構該如何寫。

演講投影片

底下是 2020 的 Cloud Summit 演講投影片，歡迎大家參考看看

最近看到一篇文章討論的非常熱烈，就是『concurrency is still not easy』這篇文章甚至上了 Hack News，大家有興趣可以點進去看看，而本篇會用一個實際案例介紹為什麼作者會說寫 Concurrency 不是這麼容易。大家都知道在 Go 語言內，要寫 Concurrency 只要透過一個關鍵字 go 就可以輕易寫出，而多個 Goroutine 要溝通就是需要透過 Channel 方式，而網路上有一堆 Concurrency Pattern 提供給各位開發者，但是官方 Go 的標準庫內並沒有包含這些 Pattern，所以實作之後，說實在很難看出問題。文章內提到 gops 實作 Limit Concurrency 遇到系統整個 hang 住的問題？什麼是 Limit Concurrency，就是當系統有多個工作需要同時執行，但是需要限制 Concurrency 數量，避免整個資源都被吃光。底下來介紹文章內遇到的問題。

相信大家踏入 Go 語言的世界，肯定是被強大的 Concurrency 所吸引，Go 語言用最簡單的關鍵字 go 就可以將任務丟到背景處理，但是怎麼有效率的控制 Concurrency，這是入門 Go 語言必學的項目，本篇會介紹三種方式來帶大家認識 Concurrency，而這三種方式分別對應到三個不同的名詞: WaitGroup, Channel, 及 Context，底下用簡單的範例帶大家了解。

以現在開發網站流程，前後端分離已經不稀奇了。前端使用 React.js 或 Vue.js，後端使用 Golang，是我現在擅長的合作模式。其實後端在開發上面不太需要將前端的開發流程放在自己的電腦上，也就是後端只需要專注開發後端，跟前端的溝通都會是透過 GraphQL 的 Schema 當作討論。目前團隊各自維護專案的部署流程會是最好的方式，前端有兩種方式部署，一種是透過打包靜態檔案方式丟到遠端伺服器，另一種就是打包成 Docker Image，再連線到遠端伺服器更新，兩者都有人使用，本篇會教大家如何將前端網站打包成 Docker Image，用 Image 來部署會是最方便的。

這應該算是一個蠻簡單的情境，公司都需要去紀錄每位員工上下班紀錄，或者是紀錄每天刷卡補助餐點，在一定的時間內刷卡才會進行公司補助，非在約定的時間點刷卡則不補助，底下看看公司可能會想要的表格紀錄。在後台頁面會進行時間區域的選擇。

起始日期: 2020-06-01 結束日期: 2020-06-30 早上時間: 08:00 ~ 09:00 晚上時間: 18:00 ~ 19:00

時常用到 Postgres 轉換資料的功能，來即時協助 PM 了解目前使用者實際狀況，底下紀錄常用的指令。首先安裝 Postgres 環境，這邊其實就是用 Docker 方式來啟動一個全新的 Postgres DB。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

  db:
    image: postgres:12
    restart: always
    volumes:
      - pg-data:/var/lib/postgresql/data
    logging:
      options:
        max-size: "100k"
        max-file: "3"
    environment:
      POSTGRES_USER: db
      POSTGRES_DB: db
      POSTGRES_PASSWORD: db

上面的 environment 參數可以自由調整，接著透過 docker-compose up -d 來啟動資料庫進行 App 串接。

身為網站工程師，您不能不知道什麼是 GraphQL，這是一個前端跟後端溝通的 API Query 語法，大幅改善了前後端的合作模式，這篇會跟大家介紹為什麼麼要學 GraphQL，以及整理出三大 GraphQL 優勢，讓大家了解跟傳統 RESTful API 有什麼不同。當然不是叫開發者捨棄 RESTful API，而是根據專案的不同，來決定不同的技術 Stack。像是服務跟服務之前您說要用 GraphQL，肯定被打槍，而是要用更輕量的 RESTful API 或 gRPC。好了，底下來說明三點 GraphQL 的優勢。

相信各位開發者在寫 Go 語言專案，現在肯定都是使用 Go module 了，而 Go Module 檔案預設寫在 /go/pkg/mod 目錄內，要串 CI/CD 流程時，由於不在專案路徑底下，所以每一個 Container 無法共用 /go/pkg/mod 路徑，造成重複下載第三方套件，其實跨容器的解決方式可以透過 Drone 的 Temporary Volumes 方式解決，但是最終希望跑完編譯流程時，可以將最後的 mod 目錄打包留到下次的 CI/CD 部署流程使用，這時候如果可以改變 /go/pkg/mod 路徑，就可以動態調整目錄結構了。底下是針對 Drone 這套部署工具進行解說。

Go 語言除了內建強大的測試工具 (go test) 之外，也提供了效能評估的工具 (go tool pprof)，整個生態鏈非常完整，這也是我推薦大家使用 Go 語言的最大原因，這篇會介紹如何使用 pprof 來找出效能瓶頸的地方。假設開發者在寫任何邏輯功能時，發現跑出來的速度不是想像的這麼快，或者是在串接服務流程時，整個回覆時間特別久，這時候可以透過 benchmark 先找出原因。

1

go test -bench=. -benchtime=3s ./lexer/