後端工程師，談論各種軟體開發與設計的大小事。更多資訊可見左上角「About」。
JavaScript
試著想像一個情境，你是一名工程師，需要跟他人分享你的創意，你希望雙方認知建立在相同的基礎上，當說到「狗」時，聽眾明白你指的是拉不拉多，而不是吉娃娃。投影片是個簡單有效的同步工具，但 Windows 的 PowerPoint 有幾個惱人的問題： * 僅具備簡單畫面編輯工具 * 版型固定 * 沒有 Quote * 沒有 Code Section * 沒有 Syntax Highlight 投影片應該要像攝影機，講者使用它來專注說故事。而 PowerPoint 設計的目標，是讓不具備程式能力的人，也能將畫面放上電腦。它有基礎的視覺設計能力，但並不足以應付進階應用。 reveal.js 是以 HTML 為基礎的簡報框架，藉由 CSS 跟 HTML 分離，講者可以更專注在內容，將設計交由第三方庫來處理。由於本質上是由 HTML、CSS 跟
Go
用函數式編程(Functional Programming)的風格寫程式時，會常常重複使用一些通用函式，舉個例子，假設有個 array，開發者需要從該 array 中篩選符合條件的元素，重新組成新的 array。合理的情況是，如果有個 filter 函式，只需要設定條件，剩下的事情都能交給語言處理。 Golang 的 append 有點這味道，類似 JavaScript 的 push，能新增 slice 中的元素，但 Golang 畢竟不是徹底的函數式語言，內建函式庫中沒有 filter、map、reduce 等等 array 常用的函式。如果想要自行實現，語言的強型別系統會要求開發者在使用前告知對象型別，這等於是對不同的型別都要實現幾乎相同的函式，可想而知不切實際。 同樣是強型別語言，C++ 或 C# 在面對這問題時，是靠著泛型(
Node.js
在 HTTP 設計之初，網路應用主要是交換文件，因此當提交訊息或更新訊息時，需要刷新整個頁面，這也導致大量 HTML 被重複傳輸，浪費使用頻寬。後來 AJAX 被提出，讓 HTTP 可以只取得想要的伺服端訊息，同時在沒有重新導向的情況下更新頁面，讓 HTTP 更符合現代網路應用情境。 但是對需要互動的應用，像是聊天室、遊戲、即時狀態監控等等來說，如果使用 HTTP 傳遞訊息，則需要客戶端頻繁向伺服端輪詢(Polling)，有點像客戶端三不五時跟伺服端問說：「你有沒有新資料需要更新的啊？」可想而知會造成客戶端跟伺服端很大的負擔。比較理想的情況是，應該存在一個事件驅動模型，當伺服端有事件發生時，它會主動通知訂閱的客戶端，客戶端再進行更新，而這就是 WebSocket 這套通訊協定誕生的原因。 Websocket 沒有限定語言，但為了簡化操作，後端可以用 node.js，好跟前端的 JavaScript 共用一套函式庫。本文中會使用
Go
接續前面，繼續來討論資料庫議題吧。 在商務初期，追求的是驗證市場，這時資料庫往往只有相對簡單的版本，各種欄位也還不是很齊全。隨著商業模式逐漸成熟，資料庫會需要負擔更多的營運功能，也會需要在原有表格中加入新欄位。資料庫的版本管理問題就出現了。 我們通常稱呼資料庫版本遷移為 Migration，在 Laravel 或 RoR 中都有整合好的 Migration 工具，而 Golang 目前仍需要仰賴自己動手，golang-migrate 是現在比較成熟的專案。本文會講解如何使用 golang-migrate 的 CLI 跟函式庫，來建立資料庫 Migration。 Introduction 既然說版本遷移是 Migration，為什麼不直接稱呼 Version 就好，它跟 Version 有什麼不同？兩者的區別可以看看下圖 簡單來說，Version 指的是資料庫的狀態，而 Migration 指的是狀態到狀態之間的改變。因為後端程式會使用到資料庫，如果用到資料庫沒有的欄位，就會出現問題。
Go
這幾年隨著物聯網(IoT)越喊越熱，MQTT 這套通訊協定也越來越常聽人提起。物聯網的核心精神是將終端數據傳輸到網路，網路中的運算單元在分析這些數據後，可以將它轉化為使用者想要的應用。在網路中，數據是用通訊協定來交換，而常見的通訊協定 HTTP 結構相對複雜，傳輸成本較高，也更要求終端裝置的效能，而且 HTTP 採用輪詢(Polling)機制來取得資料，需要客戶端頻繁跟裝置拉取訊息，不適合 IoT 的應用；相對的，MQTT 輕量、採用發佈/訂閱模式，更適合 IoT 的傳輸需求。 最常見的 MQTT 工具是由 Eclipse Foundation 維護的 mosquitto，相關工具也都有開源。本文會講解如何使用 Golang 的 mqtt 套件，搭配 mosquitto 的中間人 Broker 服務，
Go
進行後端開發時，少不了要使用資料庫，由於資料庫的設計與使用方式偏向函數思維，跟主流的物件導向習慣不同，因此很多語言都有對應的 ORM 套件，用來將資料庫轉為物件，方便開發者使用。 Golang 同樣有許多第三方的 ORM 套件，例如 lib/pq、go-pg、gorm、pgx，其中 gorm 是 GitHub 上星星數較多的專案，而且能對應到不同類型的資料庫，在 Golang 中常被使用。本文會講解如何使用 gorm 來操作 Postgres，順帶走一次後端資料庫開發的基本流程。 Establish Database 既然要使用 ORM 來開發資料庫，當然要先有資料庫啦。Postgres 是常用到的關聯式資料，它是 web based，支援高併發，相對傳統的 SQLite 等 file based
Go
Observer Pattern 是物件導向常用的架構，例如多個 Chart 與單一 Data Source 的互動，就可以使用 Observer Pattern 設計，好避免資料不同步的問題。而且 Observer Pattern 可以切開 Subject 跟 Observer，讓個別模組的功能更明確，修改副作用更小。 Golang 的哲學是簡單，語言上更強調小元件的延展與復用，例如使用組合取代繼承，使用 Goroutine 取代 Thread 等。本文會講解怎麼使用 channel 來實現 Observer Pattern，或者更現代的說法，實現 Publish/Subscribe 的架構，來建構彼此獨立的模組。 Introduce Observer Pattern 先來對 Observer Pattern 做個解說。
Web
Protocol buffers，簡稱 Protobuf，是由 Google 設計的結構化序列化資料技術。對網路應用來講，常常需要在不同的伺服端、客戶端之間交換資料，這些資料格式有 XML、JSON 等等之類。XML 特點是完整，便於記載更多的 meta data，但格式複雜，需要更強的效能來解析，傳輸時也需要更多頻寬；而 JSON 是 JavaScript 用於表示物件的語法，相對 XML 來得簡潔，隨著 JavaScript 普及，也變成現在常用的輕量級資料交換格式。 儘管 XML 跟 JSON 在當前網路應用中已經相當常見，但用不同語言開發的伺服端程式，都需要分別實現自己語言的 XML 或 JSON 解析，同時，這些格式定義也是團隊協作的痛點。假設 A 團隊開發某支應用，
Go
進行後端程式開發時，常會使用到 Golang 的 http 標準庫。例如要對某個 URL 進行處理時，會用到 http.Handle("/foo", fooHandler) 可以想像，如果沒有 http 庫，就需要使用大量的 if else 來對 URL 判斷，大幅降低程式碼可讀性。http 庫對 URL 進行 function 註冊的設計模式，不僅可以使用在後端開發，也能應用於更普遍的情境。對於要對同類型資訊進行不同處理的例子，都可以使用這個設計模式。 本文會用 Golang 來開發一個類似 http middleware 的程式，處理自訂的訊息格式，藉由這過程，也順便走一次 http 庫的路由設計原理。 Build a
Go
最初是在社群活動時接觸到 Golang，前陣子換工作後，新的產品團隊也是使用 Golang 來開發產品，在接觸新語言時覺得有些地方很有意思，好像能看到某種程式語言的變遷，或者說開發方向之類？跟常見的物件導向語言不同，Golang 不強調物件，而且帶有一些函式編程的特色，如果說 C++ 是替 C 補上物件導向的環節，那 Golang 更像是 C 語言的現代版。 本篇會簡單介紹如何使用 Golang 來開發一個簡單的命令行工具。我們可以假設一個微服務開發的情境，開發者需要頻繁在開發環境中啟動或關閉微服務，這時它會需要一個工具，能依照需求啟動各個微服務，通常在 Linux，我們會使用 shell script 來做這件事；如果是 Windows，則會使用 power shell 或 batch file；更正式的生產環境，可能會採用容器調度工具。Golang 由於具有跨平台的特性，也可以用在這個情境中。 Install
C/C++
開發 C++ 程式時，套件管理會是個困擾開發者的問題，C++ 不像 Python 有 pip；node.js 有 npm；lua 有 rock；C# 有 Nuget。它就只是沒有。沒有套件管理，當不同開發環境的使用者要開發程式時，不僅需要手動將相關的檔案塞進 repository 中，還會遇到相容性的問題，例如小明使用 paho-c 1.3.0 開發，開發到一半時，另一位開發者小華引用了小明放在 repo 中 include 資料夾下的 header file，卻使用了自己的 1.3.1 shared library，這使得兩個人的版本不相容，要花很多時間除錯。 此外，當需要更新
Cross Platform
當我們將軟體的價值視為服務時，跨平台就會越來越重要，因為它代表軟體能跨越限制，降低客戶使用成本，進而更快創造價值。工程師可能很難想像，當客戶拿到新軟體時，他需要面對一堆設定問題，還需要建置平台，這會是一件多讓人厭世的事。 常見的跨平台是指，軟體可在三大主流平台上運作，也就是支援 Windows、Linux、Mac；也有些跨平台指硬體平台，像是 x86 或 arm。本文會用 cmake 這個跨平台建置工具，分別建置可於 Windows 與 Linux 上執行的應用程式。 Prerequisite 對於 Windows 的開發者，建議用 MinGW 來建置，這個工具讓 Windows 上有跟 Linux 相同的操作經驗，可以避免二次學習。Windows 10 有很便利的 Package Management Chocolatey，類似 Ubuntu