接下來讓我們來看設計模式這本書裡的23個模式
這23個設計模式可以依設計觀點來分類
創建模式
結構模式
行為模式
事實上用這三個維度來切分
只是就解決問題的角度去劃分
而實際的實現還是綜合之前所述的原則去設計
今天就讓我用通俗的方式
簡單一次把它們全部介紹出場吧

相信開發NodeJS的人
一定用過NPM這個套件管理工具
它是不錯用
但是有許多地方被人詬病
諸如：
效率問題
套件版本控制機制問題
最近剛好成為苦主
就來分享一下處理心得
(所以現在有不少人跳槽到Yarn陣營…)

這裡不談效率問題
我想NPM團隊應該會逐漸去改善
聽說5.X以上的版本有不錯的改進
至於版本控制問題
其實NPM設計出發點是沒問題的
前提是你必須遵照semver的版本號規則
若是你不依循就會造成別人編譯錯誤…
這邊簡單介紹如何避免或解決這些問題

今天來介紹一個反射的應用
若有用過Hibernate的人應該會知道
@PrePersist @PreUpdate這兩個註解
可以方便的做到
新增跟修改前處理一些事情
但是這兩個註解有一個限制
就是必須用在一個類上
並不能做細粒度的劃分與復用
例如：在@Embedded的物件中就無法用
以下為解決的方法

google doodle今天主題是
慶祝兒童程式50年
這兒童程式叫做“LOGO”是用LISP做的
其主要就是向前走、向左右走及重複執行
可見外國的朋友早在50年前就在重視小孩學習程式語言
然而google把這些指令做成了這小遊戲
還頗有教育意義呢
大家都可以來玩玩喔

今天簡單介紹一個UML小工具PlantUML
印象以前在學著畫UML圖時真的很”搞剛“
常常需要對齊排版
尤其是在畫流程圖的時候
又碰到流程的調整時更為複雜
但如今有PlantUML這對UML的領域特定語言(DSL)+自動產圖
絕對是更據表現力來實踐UML的方法
配合VS Code這一款優秀的編輯器
相信整合起來一定會不錯使用

上一篇談到五大設計原則
今天再來補充一下兩個常用到的概念(姑且讓我這樣稱呼)
一個叫做*“迪米特法則”*
另一個是*“組合/聚合復用原則”*
為什麼要介紹這兩個設計概念呢？
賣個關子最後再做說明吧

Long long long … years ago~
記得有把玩過設計模式的書
當時只看了一兩章就看不下去了…
後來發現對於一個沒有什麼開發經驗的人來說
根本就是無字天書
時過境遷，我想應該有足夠的知識將這些書看過
因此就將“大話設計模式”放入我的閱讀書單
並花了幾週的時間將它讀過
想藉這機會把讀過後的心得記錄下來
因為設計模式博大精深
以下的分享大多是經過自己的領會並不會照本宣科
所以若有錯誤的地方歡迎指正喔～

VS Code是個相當優異的編輯器
它不僅輕巧，且外掛豐富，又出生豪門（Microsoft）
在VS Code中常會使用到terminal
但是預設的terminal不夠colorful
其實我想很多人用Mac寫程式都會使用iTerm+Zsh來美化
但在VS Code裡不能呼叫iTerm
所以只好使用原生的終端機
在此教教大家如何用Zsh美化自己VS Code的terminal吧～

現在服務彼此之間溝通大多使用JSON這種數據格式來表示
但若物件中的物件中有些是空值時就很麻煩…
當傳到其他服務主機上還需再做判斷且會增加網路傳輸
處理不當甚至會影發奇怪問題
有鑑於此
傳輸一個乾淨的JSON為開發一個API基本且“道德”的指標

本文介紹在開發JAVA時如何將它變得清爽且乾淨

因為近年來空污問題日漸嚴重
尤其當人聽聞PM2.5這詞往往聞之色變
所以不知會不會有人看到PM2
以為是不是又有一種2微米(μm)以下之粒狀污染物出現…
在此只是為博君一笑
開一個冷冷的場子（氣溫最近屢屢創新高好像滿需要的）
言歸正傳，今天是要介紹一個守護進程的好用工具（PM2）
當初是在開發NodeJS的時候知悉
只不過因為當初想快速一點將產品上線測試
於是就先選擇非常陽春的守護進程的工具–forever
由於最近要上到生產環境
為了系統的健壯 日誌的規劃 監控 效能的提升
當然要選用PM2摟
使用過後真的建議大家快快換掉forever吧～