本來本周是想寫跟最近工作有關的 library vs. framework，不過前幾日中午休息時間時，在 FB 上看到一個開發者在某個社團分享他開發的 library，並想了解大家對於用這來設計 Restful API 的想法，我並沒有直接留言…
唸研究所開始當助教，偶而會有學弟妹問：怎樣寫好程式？老實說，這是個大哉問，連我學開發軟體這麼久，我也只能回答他們：多培養自己釐清問題、拆解問題、解決問題與抽象化的能力。但他們通常只會一臉狐疑看著我，感覺我說的話好抽象。事實上，這也不是我第一個這樣說的，有句軟體工程諺語是…
本文源起於前陣子，前同事在 FB Messenger 問起：為什麼 BeanGoException (是的，沒錯，就是最近發表的 BeanGo!，過去三年的青春都在開發這個產品) 是繼承 RuntimeException 而不是 Exception？這是一種設計選擇，但這樣的選擇是好是壞就可以討論了。
BeanGoException
RuntimeException
Exception
在設計軟體架構時，常常被忽略的就是例外或錯誤的處理，原因不外乎在設計時並不會知道會拋出什麼例外或以什麼形式回報錯誤，特別是還未決定或熟悉第三方套件前，因此，當真正遇到第三方套件例外拋出時，常會受限於既有的介面規範 (method signature)…
看到標題是否覺得很奇怪？休息時間，如果改成 REST time 有沒有一種突然豁然開朗的感覺呢？每次看到 REST 就讓我想起以前念研究所和老師一起想論文題目時，曾提過國外常會玩這種文字遊戲，像是將 Representational State Transfer 變成一個很簡單的單字 REST，但我的東西不管怎麼想，卻想不出什麼有趣的東西 Orz
會想寫 REST，是過去在第一間公司工作時，曾聽到當時的架構師對著團隊說：『不要以為用了 JAX-RS 就是 Restful Web Services，你們 URL…
因為組織調整，我又變成 architect 了，早期對 architect 有很多憧憬，面對問題，心中總有一張設計圖，但實際當 architect…
目前閒談軟體設計系列，每一篇大概都需要 1x 小時，包含構思、收集資料、撰寫與修稿，每個禮拜一篇已經是極限了，還好有龐大的 architecture pattern…
今年 (2016) 因為轉職，特休歸零了，一年一度跟家人的國外旅遊也就暫緩，只有安排短短的宜蘭兩天一夜的小旅行，宜蘭雖然去過不少次，但這次幾個點都蠻不錯的，算是有個小小的充電，但…總覺得少了些什麼？
過去寫閒談軟體設計文章時，並沒有特別注意文章的長度，能寫多少就寫多少 (謎之音：實話是能掰多少是多少？) 在友人的提醒下，有些文章有點太長，不過，我只能說盡量，能找到合適的切割點且還要有適合的標題，有時候蠻難的。接下來想聊聊…
上一篇《閒談軟體設計：友善的距離》意外在 Facebook 上引起不少人的回應 (是的，我不但偷偷加了副標，還擴充了些內容)，不過首先要澄清一下，接下來一系列文章…
