從兩個角度出發，通常開發者需要驗證自己的邏輯是否正確，撰寫 unit test 為其中一個重要的環節
| About | Archive |
喜歡在地上滾的工程師
從兩個角度出發，通常開發者需要驗證自己的邏輯是否正確，撰寫 unit test 為其中一個重要的環節
在開發上會遇到 code 對 database 處理 concurrency 所帶來的問題，而這些問題隨著商業邏輯逐漸壯大會更容易遇到。
如果可以透過一個誰都能看的表單，來清楚知道開發進度及資訊，會不會有效加速資訊的流通？
這樣用熱情和衝勁，透過假日及下班做的 Side project 經過 365 天後到底有什麼實質的收穫及遇到的挑戰？
最近做影片有感，這裡把我自己的流程和心得記錄下來，認真剪三支以上影片，就會獲得進步，每次都要有不同的目標，目的是一次比一次的質感還要提升。
這幾天在處理公司的第三方 API 介接，其中有一個部分是將 token 放在 HTTP header 裡面當作彼此驗證的方式，雖然這不是什麼特別的方式，但我在用 Ruby 處理時卻掉進了坑。
在這裡我會建議，可讀性優於技巧的展現，有些工程師會為了展現對程式語言的嫻熟度，在程式中使用比較冷門的語法或技巧，這通常很容易會降低程式碼的可讀性，也容易讓其他人犯錯。
因為能夠提升可讀性的方法族繁不及被載，所以也不會有全部的方法，我整理了一些我自己平常開發比較常使用的一些心法和技巧與你分享。
有沒有遇過一種情況是，即使需求不是這麼急迫，團隊之中總有習慣了問題來隨手就解的隊友，那個神來一筆的 commit 也跟著埋下了考古的鑰匙。
在 Ruby 中常量(constant)其實是可以變更的，不管在那個程式語言上，有很多時後會造成記憶體洩漏（Memory leak）的部分，通常都是在分配（allocate）後，就算 GC 收走後還是發生記憶體碎片化所造成的效能問題
useEffect 會在 component 渲染完成後執行，類似 callback function
在維護一陣子的 Rails 專案上，難免會看到各處擺放的 JavaScript function 或是 jQuery 各種直接操作 DOM 之類的作法。
隨著武漢肺炎疫情延燒，同時看著鄰近的地點被標上危險區域，似乎連假日出門都變成一種風險，工程師這個進可進公司退可退 Remote 的職位到底在這個時候能做些什麼呢？
經歷過在團隊中使用 Gitea 後發現實在太難用了，除了速度快以外實在感受不到什麼優點，所以決定來換個自架 Gitlab
本篇文章主要是從我累積一些面試經驗後，從各種面試中自己主觀提取我所認為好的面試過程，進而整理成自己的面試風格