查理工程記

目的 主要介紹Map中的新方法，包含如下 forEach() getOrDefault() putIfAbsent() remove() replace() replaceAll() merge() 有些是Lambda有些則是我覺得比以前使用Map更方便而介紹 forEach Map的forEach方法與List不大依樣，因為Map主要的迭代方法是以Entry為主，所以需要Key-Value Pair去迭代 原始碼解說 可以看到forEach的傳入參數BiConsumer介面，必須傳入Key與Val，裡面的實作就如同我們使用Java8版本以前的寫法，需要使用for迴圈去迭代抓出每個Value 原始碼 default void forEach(BiConsumer<? super K, ? super V> action) { Objects.requireNonNull(action); for (Map.Entry<K, V> entry : entrySet()) { K k; V v; try { k = entry.getKey(); v = entry.getValue(); } catch(IllegalStateException ise) { // this usually means the entry is no longer in the map. throw new ConcurrentModificationException(ise); } action.accept(k, v); } } 範例 private void forEachExample() { Map<Integer, String> map = new HashMap<>(); map.put(1, "test1"); map.put(2, "test2"); m...

目的 透過這篇文章理解JWT(JSON Web Token)與Session的差異，以及為何現在大家都用JWT而不是用傳統的Session儲存使用者的資訊，本篇文章的案例都透過登入行為做解說。 緣由 這篇文章主要針對兩者的差異，其實我一直以來只用過session做過使用者狀態傳輸，但是因為工作使用到了Jhisper框架開始嘗試JWT，不過因為這套框架已經將JWT都完整包好直接使用就好，所以不是非常了解，直到有天需要自己寫Spring Security後才發現JWT的奧妙，但是在嘗試的過程中一直不知道為啥不使用Session就好，就開始展開兩者VS的冒險，也有了這篇文章。 Cookie & Session 如果要討論Session的話首先我們必須先理解Cookie是甚麼。 Cookie 我們可以從Wiki上得知 因為HTTP協定是無狀態的，即伺服器不知道用戶上一次做了什麼，這嚴重阻礙了互動式Web應用程式的實現。在典型的網路購物場景中，用戶瀏覽了幾個頁面，買了一盒餅乾和兩瓶飲料。最後結帳時，由於HTTP的無狀態性，不通過額外的手段，伺服器並不知道用戶到底買了什麼，所以Cookie就是用來繞開HTTP的無狀態性的「額外手段」之一。伺服器可以設定或讀取Cookies中包含資訊，藉此維護用戶跟伺服器對談中的狀態。 但是使用Cookie會有以下的缺陷 辨識不精確 如果在同一台機器上使用多個瀏覽器，每個瀏覽器在不同的儲存位置儲存 Cookie，因此，Cookie 並不能定位到一個具體的人，而是用戶,電腦和瀏覽器的組合。 不準確的狀態 如果用戶在取得了一個 Cookie 之後,點擊了瀏覽器的"回退"按鍵,則瀏覽器的狀態和取得Cookie 的狀態就出現了不一致.例如, 如果網站基於 Cookie 技術實現了購物車的應用,當用戶添加了物品後點擊了"回退"按鍵, 購物車的物品狀態可能並沒有發生變化. 隱私、安全和廣告 Cookie 是沒有加密的 案例 Cookies在某種程度上說已經嚴重危及用戶的隱私和安全。其中的一種方法是：一些公司的高層人員為了某種目的（譬如市場調研）而存取了從未去過的網站（通過搜尋引擎查到的），而這些網站包含了一種叫做網頁臭蟲的圖片，該圖片透明，且只有一個像素大小（以便隱藏），...

Total Productive Maintenance, TPM (全面生產維護) 在過往日本泡沫前就是依照了TPM的概念讓工廠的產能大幅領先美國，而為什麼我們要提到TPM呢? 在過往的工廠都是有訂單就趕快用土法煉鋼的方式改裝目前的產線與機器為了能產出客戶需要的產品。在這樣的情況下，整個工廠的運作機制其實已經變成渾沌狀態，因為頻繁改變的情形下當產線掛掉停擺時要花許多時間去找到原因，而日本提出了TPM的概念後將工廠變得井然有序進而超越了美國，所以才有豐田生產管理等等專們以日本企業命名的工廠管理方法出現。 而現在的軟體設計其實也是一樣的道理，軟體迭代速度越來越快，如果開發人員只顧著往前衝刺不斷地改變，如果缺乏了有效的管理以及人員的紀律，那就可能像是滾雪球一般造成雪崩也說不定。相同類型的故事也可以透過鳳凰專案這本書一窺究竟。 回歸正題，Clean Code裡面提到的概念與方法其實就是TPM中的5S原則 5S (日語) Seiri (整理) - 好好地整理每個方法和class的命名，這樣才能讓每個團隊成員明確的知道問題在哪 Seiton (整頓) - 一段程式碼他應該出現在你所期待他出現的地方，如果不是那就是要重構了 Seiso (清掃) - 刪除那些根本沒意義的註解還有程式碼吧，讓程式碼們更好閱讀 Seiketsu (清潔) - 每天都要讓自己的工作環境標準化更清潔，讓每個成員的程式碼都用上check style吧 Shutsuke (身美) - 這也是最重要的一點，其實就是自律與反省，好好誠實的面對以前自己寫的程式碼吧 若是每次工作時都有好好遵從這5S原則，那未來產品業務大爆發或是要開發更前衛的功能時，你偷偷藏起來的雪球才不會造成雪崩讓產品一夕崩潰。 那接下來就會是我一系列的Clean Code文章(讀書心得)，其實這本書我已經看過兩次，一次是碩士還在讀書時一次是工作第一年的時候，第一次看的時候其實可以說是完全看不懂(哈哈)，內心想的都是為什麼要搞那麼麻煩?而第二次看的時候開始有感覺了，因為自己寫的程式碼也開始要接受挑戰已經被其他同事的程式碼挑戰，但是還是有些不得要領的地方，而這一次我決定要改變讀書行為，每到一個段落就記錄與分享，希望自己可以到另一個境界。

目的 介紹ACID，並且針對其中的C(Consisitency)一致性提出常見的問題與解決問題的Lock用法 ACID 資料庫的ACID基本上就是四個字首的縮寫分別是 ATOMICITY CONSISTENCY ISOLATION DURABILITY 在開始進入文章前需要先講解一個概念Transaction(交易/事務)，Transaction代表著你的程式在這個過程中對資料庫做的操作 舉例: 今天會員購買了這個產品，則程式會對資料庫做一系列的操作包含 新增訂單資料 新增會員與訂單的關聯資料 更新商品銷售資料 則這系列的操作可稱為一個Transaction 若是以Java Spring中的Annotation來講解的話，若在method上標記Transaction則Spring會幫助你判斷此method中對資料庫的操作都為一個Transaction。 ATOMICITY (原子性) 一個Transaction中的全部操作被視為不可分割，代表要就全部完成或是全部取消。若是其中一個環節失敗則會全部回滾(Rollback)到此資料庫Transaction前的狀態。 原子性確保了資料庫的可使用性，當然當資料不再準確時資料庫基本上也不可以使用了 CONSISTENCY (一致性) 其實目前我對於網路上一致性的解釋上有些許混亂，網路上有兩種說法可能是與CAP理論的C一起解釋了，如何選擇就由客官們判斷了 資料庫在Transaction執行後資料都必須符合schema的規範，例如要執行Trigger或是constraint(Not null/Unique) 資料庫每個Transaction讀取一個數據的解果都是一樣的 第二個說法的補充 當資料滿足了原子性與隔離性，那在同步進行Transaction時，就算其中一個Transaction 提前完成，那資料也是可以滿足一致性的 ISOLATION (隔離性) Transaction在確定提交以前，是看不到其他Transaction對這個資料的操作。 DURABILITY (持久性) 一但Transaction提交後，其作的修改將會永遠存在Database之中不能遺失 常見的一致性問題 現在各語言框架通常都已經將資料庫操作包裝好都符合ACID原則，開發者只要呼叫API即可使用，...