關於 #心得 的內容

不知不覺工作已經四年左右了，如果是從開始接觸程式語言計算的話似乎快要二十年。這幾年也開始擔任公司負責面試的主管，也看到越來越多工程師培訓班的出現以及更多的人挑戰轉職工程師。在這樣的狀況下，每次跟同事交流，我總是覺得我們不夠專業。

這也一直讓我在思考，作為一個「專業」的工程師應該要滿足什麼條件？

距離上一篇文章已經好幾個月了，手邊還有一些有趣的東西想寫不過實在太忙。每年參加完研討會都會寫一篇心得來記錄一下，不過我後面幾個月可能還要準備日本的 RubyKaigi（線上版）、鐵人賽跟在等投稿結果的 JSDC、MOPCON 等，應該是暫時沒辦法跟大家分享這幾個月找到的有趣技術。

在 TGONext 期間我們基本上有 4 ~ 5 次的聚會，而這次算是表定上的最後一次聚會。在可能是最後一次的聚會，我們先討論了幾個原本沒有要討論的主題。

這次聚會中，我們會討論關於日誌追蹤跟如何處理技術債。

當我們的 Rails 專案邊複雜的時候，Form Object 算是一個常見的方法。不過網路上的教學似乎大多都沒有能夠相容 Rails 的 Form Helper 的版本。

所以我就開始思考，有沒有辦法法在比較少的修改下去支援 Form Helper 呢？

這次在開始討論關於架構的主題之前，我們的倒是讓我們提出一些問題。

剛好在兩次聚會的期間，我的客戶因為一些錯誤的計畫讓 Migration 失敗了，所以我提出了關於在不停機的狀況下做 Migration 的規劃問題。

這次聚會我們先簡單的回顧一下上一次的討論，然後就切換到了下一個主題。基於前一次聚會高併發的討論，我們模擬一個簡單的架構然後開始演進。

因為時間的關係錯過了實體課程，不過利用 228 連假把工作上用得到的函數式程式設計這門課補完。

在 Functional Programming（函數式程式設計）裡面有許多概念是可以提取出來應用的，如果你使用的語言有支援一定程度的特性的話，就能更做出更多的變化。

大概一年前左右，我開始製作一個 Ansible 的 Playbook 來幫五倍紅寶石的客戶安裝環境。

不過當我們的客戶增加之後，其實開始有點變的很難透過 Fork 的機制來管理不同客戶的 Playbook。

這表示我必須先更新主要的 Playbook 然後再同步到每一個客戶的版本上，也因此我決定去把這些通用的部分拆成單獨的 Role 專案。

昨天是 TGONext 的第一次聚會，在這個活動中我們會向台灣的一些高階主管學習。在開場結束後我們的導師 Ant 讓我們投票選出幾個想在這半年的時間內討論的題目。基本上我們預定討論四個主題，而「高併發」是我們的第一個主題。

包括我自己在內，寫測試有時候是一個非常不想面對的工作。也有很多剛入門的工程師覺得很難去分辨該怎麼去寫測試，在今天跟同事說明完一些技巧後就決定來寫一下這篇分享一下我自己的經驗。