軟體主廚的程式料理廚房

上一篇文章大致地了解了 SQL Server 登入及使用者之間的關係，登入只是個開始而已，只是能進到 SQL Server 而已，這時候還不能存取任何資料庫物件，還需要得到授權，要在 SQL Server 授權存取資料庫物件，就不得不提到「使用者（User）」及「角色（Role）」。

當我們建立了一個 SQL Server 實例之後，在開始處理資料之前，如果是對資安意識相對高一點的開發者，應該會有一個步驟是為我們的應用程式建立帳號，並且授予相對應的權限，而不會用 sa 走天下，當我們建立了一個登入時，通常會去使用者對應的頁面勾選對應的資料庫，此時，SQL Server 也會幫我們建立一個與登入名稱一樣的使用者，我們可能沒有感覺，但是 SQL Server 的登入及使用者其實是拆開來的。

之前有寫過一篇在 IIS 用 URL Rewrite 解決 SEO 要求網址全小寫及有無斜線結尾的問題，到了 ASP.NET Core 雖然沒有 URL Rewrite 擴充套件可以安裝，但是有一個 URL Rewriting Middleware 可以來幫助我們做到一樣的事情。

實行敏捷開發的團隊大部分都會用 User Story 來梳理使用者的需求，依照團隊的情況，每個團隊實行的方式也不盡相同，看起來差不多，可是細節卻有差。

User Story 看似簡單，操作起來卻有很多地方需要注意，一不小心很容易成為災難一場，不僅徒勞無功，又累死三軍，下面記錄我最近一次使用 User Story 的經驗，過程多少有一些操作得不是很好的地方，把它寫下來後，希望可以做為我未來調整及修正的方向。