本文以辛辣反諷的筆觸，討論了一個AWS用戶如何因為配置失誤而面臨巨額賬單的悲劇。文章深入分析了因默認設置過於開放而導致的安全風險，以及AWS在事件中扮演的角色。通過這個案例，我們探討了雲服務用戶在使用過程中應注意的安全和成本控制問題，並提出了增強安全性的具體建議，如隨機後綴的重要…

沒有最正確的軟體架構，通常都需要隨著時間和發展階段進行修正和修改。系統最終會變成怎樣往往也和公司的管理方式及運作模式密切相關。在過去的幾年裡，為應對需求，公司的軟體架構走向了 JAMSTACK 的風格。這裡分享一些關於這種架構的感受和經驗。

作為程式開發者，每次聽到「加個 flag 就好」或者「開個變數存起來」這種話總是會心頭一驚。理由也很正常，就是像這樣子的 workaround 並沒有真正解決問題，只是徒留技術債，以後怎麼爆炸的都不知道。workaround 聽起來真的是十惡不赦，不是嗎？

「為什麼要維護？有 bug 你們就要負責啊，你們怎麼可以給我們有 bug 的東西！」一瞬間我也是愣了一下，還差點被說服（？）

ChatGPT Prompt: 只要慬問, 任何人也可學習到程式與開發程式

一旦甲乙方進到零和賽局，情感上開始對抗之後，兩敗俱傷就是必然的結局了。既然是這樣，合約的撰寫及執行不妨看作是合作誠意的具象表態。

「幫我做的跟 Facebook 一樣單純就好」「嗯 … ?」

一個SaaS軟體公司的長期成長，要奠基於每一個產品的「客戶成功」，然後有節奏地推出更多產品，累積成「產品線」，並在有限資源下，精準的「資源控盤」，依據整個「產品發展地圖」的戰略方向，高效率的推進產品發展。

這講述了軟體工程師邁向管理層的經歷，不同崗位會遇到的問題以及自身的經驗，從開發到當指導員，小至技術負責人，大至管理公司團隊，如何應對各階段的問題情況。

人月神話一書中提到軟體工程的任務有兩種性質：本質性與附屬性。後者可能會隨著工具改良(如更好的程式語言及 IDE)而逐步改善，但前者才是真正複雜且難以攻克的困難點。而系統串接亦然，其本身很常同時參雜著這兩種問題。或許在我們一切任務開展之前都順著這兩個大類對子分項做規劃會是個不錯的思路方向。

以甜點作為品味生活的點綴，這對很多人來說是再直覺不過的事情了。隨著技術的進步，各行各業都在以技術協助本業提升，講數位轉型有時候過於沈重，從數位化及數位優化開始是個好的選擇。

這篇文章我們擷取了 2021 年 7 月 22 日晚上「React Native 使用分享 — 五年小回顧」一部分的講座內容，算是個小小的紀錄

最近公司剛好有些客戶遇到ERP系統的問題，特地來諮詢應用跟整合的可能性🧐 事實上ERP的角色以往只有在中大型企業才會導入，以IT成本來說是非常高的，隨著技術成熟與產業精緻化、電商化，ERP也漸漸出現符合中小企業使用的雲端版本，使得進入的門檻也大大降低。

這篇文章我們暫且放下溝通及流程規劃的議題，聚焦來看看軟體開發純粹領域差異造成的困難以及該怎麼面對。

「過早的優化是萬惡的根源」，在不存在效能瓶頸時就做優化，結果適得其反。比起效能，應該以可讀性優先。

聚合思考簡單快速，發散思考慢又複雜。