Top 5
大多數時候，我們在討論壓力測試通常會先想到 ab 這個工具，然而這個工具會一次性的發送請求，有時候不一定符合現實的使用情況，同時也會受限於運行測試機器的限制（例如：Thread 上限）因此可能會得到不太精確的結果，在測試一定請求等級的瞬間壓力是有用的。
同事開始問我「你有買哪些加密貨幣嗎？」這類問題，因為他表示想退休，正在尋找可以讓他退休的加密貨幣。
實際上，我雖然對加密貨幣有些興趣，然而一直都是用蠻保守的方式買。完全沒有發現所謂的「財富密碼」倒是對技術的部分有很多興趣，因此也只能向同事分享一些有趣的專案。
在雲端的時代中，我們可以利用 Auto Scaling（自動規模化）的方式來自動的增加或者減少伺服器的數量。也因此很多人會認為這是一個針對「大流量」的機制，也會把它當作一個解決「突發狀況」的解決方案，然而實際上真的是這樣嗎？
有時候我們在執行專案的時候會遇到一個狀況，工程師實作的東西跟預期的不一致，因此能夠正確傳達需求是一個重要的技巧。原本我認為應該就是規格說明清楚就沒問題了，實際上事情卻沒有這麼單純。
大多數時候，我們在討論壓力測試通常會先想到 ab 這個工具，然而這個工具會一次性的發送請求，有時候不一定符合現實的使用情況，同時也會受限於運行測試機器的限制（例如：Thread 上限）因此可能會得到不太精確的結果，在測試一定請求等級的瞬間壓力是有用的。
同事開始問我「你有買哪些加密貨幣嗎？」這類問題，因為他表示想退休，正在尋找可以讓他退休的加密貨幣。
實際上，我雖然對加密貨幣有些興趣，然而一直都是用蠻保守的方式買。完全沒有發現所謂的「財富密碼」倒是對技術的部分有很多興趣，因此也只能向同事分享一些有趣的專案。
在雲端的時代中，我們可以利用 Auto Scaling（自動規模化）的方式來自動的增加或者減少伺服器的數量。也因此很多人會認為這是一個針對「大流量」的機制，也會把它當作一個解決「突發狀況」的解決方案，然而實際上真的是這樣嗎？
有時候我們在執行專案的時候會遇到一個狀況，工程師實作的東西跟預期的不一致，因此能夠正確傳達需求是一個重要的技巧。原本我認為應該就是規格說明清楚就沒問題了，實際上事情卻沒有這麼單純。
因為經常有面試人的機會，然而在不同的面試條件中有一個「Problem Solving」的項目讓我一直在思考代表怎樣的意義，剛好在 LeSS in Action 的課程中有了一些想法。
雖然這系列的課程是設計給工程師的，然而在學習敏捷開發（Scrum 為主）的過程中，我們是從如何做「產品」的角度去做切入，也因此在課程接近尾聲的時候我們再次討論了產品跟專案的差異，也是這一週課程中各種安排的理由所在。
我們已經了解到了驗收驅動開發、持續整合以及壞味道這幾個概念，要減少技術債的方式就是重構，然而在實踐重構的時候並非我們所想像的必須「安排時間」重構，而是在開發的過程中不斷的進行。
當我們使用主幹開發（Trunk-based Development）、以及驗收測試驅動開發（A-TDD）之後，所撰寫的程式碼會逐漸的變多，也因此我們會開始注意到程式碼有壞味道（Code Smell）的出現。
不同於我們大多數討論持續整合（Continuous Integration）是以工具為主的議題，在敏捷開發中持續整合更接近於團隊之間協作的議題。這是因為我們希望能夠快速迭代，也因此必須持續的將團隊的產出整合在一起。
當我們能夠通過一個驗收測試後，就是時候將程式碼推送到遠端的服務中。跟基於分支的開發方式不同，我們是以 Trunk-based Development（主幹開發）的方式進行，也就是只有 main 一條分支，並且所有人都會提交進去。
完成對功能的了解之後，我們就要開始進入實現功能的開發階段。跟以往的開發流程不同的是，我們在敏捷開發中注重的是製作有價值的東西。也就是在計畫中，我們獲取的資訊都是對使用者有用、可以被看見以及操作和跨團隊協作的性質。
因為經常有面試人的機會，然而在不同的面試條件中有一個「Problem Solving」的項目讓我一直在思考代表怎樣的意義，剛好在 LeSS in Action 的課程中有了一些想法。
雖然這系列的課程是設計給工程師的，然而在學習敏捷開發（Scrum 為主）的過程中，我們是從如何做「產品」的角度去做切入，也因此在課程接近尾聲的時候我們再次討論了產品跟專案的差異，也是這一週課程中各種安排的理由所在。
我們已經了解到了驗收驅動開發、持續整合以及壞味道這幾個概念，要減少技術債的方式就是重構，然而在實踐重構的時候並非我們所想像的必須「安排時間」重構，而是在開發的過程中不斷的進行。
當我們使用主幹開發（Trunk-based Development）、以及驗收測試驅動開發（A-TDD）之後，所撰寫的程式碼會逐漸的變多，也因此我們會開始注意到程式碼有壞味道（Code Smell）的出現。
不同於我們大多數討論持續整合（Continuous Integration）是以工具為主的議題，在敏捷開發中持續整合更接近於團隊之間協作的議題。這是因為我們希望能夠快速迭代，也因此必須持續的將團隊的產出整合在一起。
當我們能夠通過一個驗收測試後，就是時候將程式碼推送到遠端的服務中。跟基於分支的開發方式不同，我們是以 Trunk-based Development（主幹開發）的方式進行，也就是只有 main 一條分支，並且所有人都會提交進去。
完成對功能的了解之後，我們就要開始進入實現功能的開發階段。跟以往的開發流程不同的是，我們在敏捷開發中注重的是製作有價值的東西。也就是在計畫中，我們獲取的資訊都是對使用者有用、可以被看見以及操作和跨團隊協作的性質。
執行力低下的宅宅們想要去奇美博物館總是需要鼓起很大的勇氣，在一年後我們終於下定決心出發去台南。然而，因為疫情的爆發加上確診，原本應該在涼爽的春夏交錯之時抵達，一直延後到了即將迎來鬼怪狂歡的盛夏。
執行力低下的宅宅們想要去奇美博物館總是需要鼓起很大的勇氣，在一年後我們終於下定決心出發去台南。然而，因為疫情的爆發加上確診，原本應該在涼爽的春夏交錯之時抵達，一直延後到了即將迎來鬼怪狂歡的盛夏。
