解决 FizzBuzz 的详细思路
这次我透过一步一步拆解解题路径来描述如何解题。从基本解到分离资料与逻辑、保持 immutable 以及边缘案例还有文件编写都有涵盖。打印出 1 到 100 的数字、假如数字是 3 的倍数，则打印 Fizz、假如数字是 5 的倍数，则打印 Buzz、假如数字是 3 和 5 的公倍数，则打印 FizzBuzz。
这次我透过一步一步拆解解题路径来描述如何解题。从基本解到分离资料与逻辑、保持 immutable 以及边缘案例还有文件编写都有涵盖。打印出 1 到 100 的数字、假如数字是 3 的倍数，则打印 Fizz、假如数字是 5 的倍数，则打印 Buzz、假如数字是 3 和 5 的公倍数，则打印 FizzBuzz。
This time, I describe how to solve the problem by breaking down the FizzBuzz. It covers everything from basic solutions to advance you might need to aware.
這次我透過一步一步拆解解題路徑來描述如何解題。從基本解到分離資料與邏輯、保持 immutable 以及邊緣案例還有文件編寫都有涵蓋。打印出 1 到 100 的數字、假如數字是 3 的倍數，則打印 Fizz、假如數字是 5 的倍數，則打印 Buzz、假如數字是 3 和 5 的公倍數，則打印 FizzBuzz。
無論如何都不輕易相信用戶請求即能最大程度防範 CSRF。最近在碰一些資安的東東，發現自己對於這一塊知識都比較薄弱，身為前端工程師資安通常並不是首要關注的職責，但一但有漏洞保證後果不堪設想，於是近期來補足一下這方面的知識。
總結是無論如何都不輕易相信用戶輸入即能最大程度防範 XSS。最近在碰一些資安的東東，發現自己對於這一塊知識都比較薄弱，身為前端工程師資安通常並不是首要關注的職責，但一但有漏洞保證後果不堪設想，於是近期來補足一下這方面的知識。現代齊全的工具與文件幫助下意外執行用戶提供的惡意腳本的機率已經大幅降低。
會想調查這個主題是因為目前所在的團隊大量地使用到這樣的模式，但 Vite 並不會在開發中進行 Tree Shake 就導致每一次開發環境都有大量的無用代碼被打包進去，嚴重影響到開發體驗。因此研究一下這種方法的理念與優缺點以架構更好的專案。
前面寫了一篇文章關於 ES6 JavaScript 當中的內建資料結構： Map，這次來談談 WeakMap，它又與 Map 有什麼不同呢？會發現 WeakMap 相較 `Map` 少了非常多可用的方法，這是因為它們的根本處理資料的方式不同，Map 是強引用，而 WeakMap 是弱引用。
从很早以前就大致知道浏览器开始推出 Web Components 相关 API 与标准，但一直没有机会在实战中使用这项技术。想撰写这篇文章记录是因为随着时间推移发现 Web Components 的应用范围越来越广，因此趁着有空也来了解一下相关知识，并且分析它与现有的解决方案有什么不同。
Browsers began to introduce Web Components related APIs and standards, but I never had the chance to use this technology in practice.
從很早以前就大致知道瀏覽器開始推出 Web Components 相關 API 與標準，但一直沒有機會在實戰中使用這項技術。想撰寫這篇文章記錄是因為隨著時間推移發現 Web Components 的應用範疇越來越廣，因此趁著有空也來了解一下相關知識，並且分析它與現有的解決方案有什麼不同。
近期我對自己看待撰寫程式這件事有更高的期許，除了最基本的效能、閱讀性、擴充性……之外還有一個非常重要的領域就是：測試。不過程式好端端的能動就代表測試沒有必要了嗎？在我剛工作時實際上做了一段時間的自動化 QA 工程一段時間，不過那時候的我其實也並不明白寫測試的原因，就是有程式就拿來自動化測試，並沒有想太多。
JavaScript ES6 中有一個用法與物件近似的資料結構我一直不是很清楚用途。 —— Map，這篇文章會主要拿熟知常見的物件與 Map 來做比較以分辨出 Map 的特性與使用時機。總結來說可以把 Map 當作是用來頻繁讀寫的物件，它具備更好的性能、更明確的語法。
發現身為初階打工人其實通常只是看見問題並拼命解決它，但換個角度思考：「如果現在手上專案燒起來，主管定個超乎預期的時程但你也沒有自己一套說法，要如何交代？」，最貼近實作的人其實是最能開出真實預估的人。參考：The work is never just “the work” - Dave Stewart 文章。
近期執行的專案在進行翻新包含了整體的視覺設計，因此前端也面臨要如何同步管理產品視覺的問題。先說痛點，先前專案並沒有具體的規範應該如何定義 UI 當中的數值，導致魔法數字（沒有規範與描述的值）流竄於整個產品當中，造成了非常大的的困擾。我會解釋得盡量具體明白如果要重新設計一款數位產品會怎麼管理其中的數值。