很高興看著一堆熱血佛心的好友們把第一屆的 DDD 年會搞了起來,至少凝聚了台灣對 DDD 有興趣、用 DDD 來解決問題的人們,從原本多個單點,到社群的由點成線,再到整個年會幾個不同面向的呈現交流。
台灣還是需要很多這樣的人,幫軟體業注入一些活水,持續成長、持續改善產品、改善團隊協作方式。
在架構規劃之餘,也不要忘了團隊的基本功培養,就像 agile/devops/scrum 是好東西,但團隊的 CI/build server, CD/feature flags/trunk-based/auto testing, code review/pair programming/refactoring/specification by examples 這些如果沒扎根,那些層次更高的 DDD/CQRS/Event Sourcing/micro services, TDD/ATDD/BDD, agile/devops/scrum/LeSS 一不小心會把原本的小苗碾死的。
該學的都該在用之前就學習,你不會知道那一天因為實務上的一個火花就能讓你融會貫通,但看清領域限制、資源限制、團隊限制、技術限制,是一位合格的 architect 必備的基本條件。
DDD 我還很菜,希望有機會可以跟很多夥伴們一起學習交流。(話說 Odd-e 泰國團隊對 DDD 很熟稔就是了 XD)
xd examples 在 Alexander Wang 王梓沅英文 Facebook 的精選貼文
#學習講義 #千萬點閱網紅的Oreo說話術
【故事 1 】
昨天下課後,留下來跟教寫作和筆譯多年的 Sonny 老師閒聊生活和教學。還記得聊到「改寫作」這件事情時,他說:「我這麼多年改下來,最常需要給學生的 comment 就是。。。」他還沒講完,我搶著第一時間想要猜測他給的評語:
Sonny: 「vague.」
我: 「unclear.」
也太有默契,我心裡想。但後來想想,應該不是默契,只是問題的顯著性太高。
【故事 2】
昨天晚上回外婆家跟親戚們共同慶祝母親節,也見了好久不見的表妹。她從美國的大學畢業回來,吃飯時便跟從前一樣,開始聊一些「年輕人的話題」。
還記得她問到我某一個問題時,我超級簡短的回應了「有啊。」她笑笑地回我說:"Please elaborate."
(當然,刻意不給太多細節也是一種狀況 XD)
從上述這 2 個小故事,我們可以看到特別是英文這個線性 (Linear) 表達語言,非常重視 clarity (清晰) 和 specificity (確切性) 這 2 個面向。
的確,從前在大學、研究所經常聽到教授們掛在嘴上的便是:
"What do you mean by ____?"
"Can you be more specific about _____?"
"If I understand you correctly, basically what you're saying is.....right?"
等等幫助學生在這改善 clarity 和 specificity 的問題。
【你可以這樣觀察】
為了備「恆毅力英文」這堂線上課,花了好多時間研究美國「知識型網紅」的講話結構和用字。例如,我將恆毅力作者 Angela Duckworth 在網路上超過 30 個各式各樣的訪談和 Podcast 都做過 speech analysis。
如果你也這樣做,你會發現,不管是怎樣的知識型網紅,說話通常符合「Oreo 說話術」。上上下的餅乾是論點、觀點 (idea、point),夾心是 (reason、examples)。這樣的Oreo 說話術,讓他們講話可以 clear and specific.
在夾心裡頭,為了 "elaborate" 論點,可能還會用一些 expressions,像是:
Let me give you a concrete example.
More specifically,....
In other words, ...
So, what does the example tell us?
【痛點、練習下手處】
1️⃣ 很多時候我們忘了下面的那片餅乾,忘了收尾。
2️⃣ 更多時候我們給了跟餅乾不相關的夾心(離題)。
3️⃣ 大多時候我們忘了清楚交代「夾心跟餅乾的確切關係」,期待聽者自己「意會」。
【學習方法】
藉由 shadowing、窄式學習、或是做演講內容的架構分析、刻意練習、使用具體 tasks 輔助,都是學習 oreo 術、提高意識的好方法。
【學習資源】
1️⃣ 請 tag 一個朋友,並在下面留言「我要學習 OREO 英語說話術」,我將會內信給你 / 妳有具體例子的學習講義喔!
(5/18 開始內信寄出講義)
2️⃣ 全台第一個窄式學習課程、內容集眾多西方知識型網紅理論、講話語塊的募資課程 (已超過1000人參與) 65折要結束了,一起加入我們學習!(可以分期付款)
• 窄式學習線上課:https://bit.ly/2QLPhus
xd examples 在 Kewang 的資訊進化論 Facebook 的最佳貼文
前兩篇分享了 Autocomplete 的實作方式及開發細節,算是少數大家迴響比較多的文章 XDD,下面就來整理一下大家的迴響好了。
---
## 1. 減少傳輸量可以使用 msgpack
小編有聽過 msgpack 但還沒實際了解這是如何運作的。剛查了一下資料 (https://msgpack.org),說是比 JSON 更省資料大小,基本上聽過的語言都有支援。
在前公司也用過 Avro 這類的格式,主打的也是省資料大小。但現在應該還不會考慮改用這類要另外做 serialize 的格式。
主要是基於後端是以 Node.js 為主開發,JSON 已經是原生支援,再引入一種資料格式會增加前後端維護的複雜度。另外就是開發人力,新創小公司要儘量減少工作,目前可以順暢運作就好,還有其他更重要的事要做,等之後用量大了再改也不遲。
---
## 2. 減少傳輸量可以使用 HTTP server 的壓縮機制
這真的是忽略了,忘了 expressjs 只是一套 web framework,在上面對資料做壓縮其實會影響到效率。讓如 nginx 之類的 HTTP server 做壓縮應該才是更好的作法。
不過因為現在的 infra 是建在 heroku 上面,heroku 並沒有原生 nginx 的支援。等量大撐不住的時候,倒是可以優先考慮使用 heroku 的 buildpack 把 nginx 架上去試試 (https://github.com/heroku/heroku-buildpack-nginx)。
另外也有提到用 CDN 做動態壓縮,這就真的沒做過了,也是可以研究的方向之一。
---
## 3. 減少使用者打 server 的次數,加上 debounce time
這大家都主推使用 debounce 方式,前端沒玩很深的小編第一次碰到這個名詞是高職的時候。記得那時上課在教 8051,老師說按按鈕時要加上 15 - 20ms 的 debounce time,避免重複送外部中斷。小編對單晶片實在不在行,但大概記得是這個意思。
剛查了一下資料 (https://css-tricks.com/debouncing-throttling-explained-examples),前端的 debounce time 大概也是類似的意思。在輸入文字後,會 delay n 秒再送出,若是在 n 秒內又有打其他內容的時候,就把之前的 request 從 queue 裡面丟棄,只關注最後一次的 request 就好。
這個應該也是有效減少 request 量的作法了。
---
## 4. 減少使用者打 request 的次數,將已經送出的 request 取消掉
這也是一個不錯的作法,若 A request 已經送出去,但還沒回 response 時又送了 B request 的話,此時可以把 A request 取消。
但要注意就是 A request 目前正在執行的步驟是去 DB 拿資料,或是在 server 本身處理一些基本計算。之前在使用 Java (grizzly + jersey) 開發的時候,若有這種情況發生會常在 log 裡面看到 IOException。
原因是 server 已經準備好資料要回傳給 client,但發現 A request 已經取消,不知道要怎麼回傳時就會發生這個狀況。但也有可能是小編自己沒控制好收發的關係啦 XD
---
關於 Autocomplete 的三篇大概就到這篇為止啦,等上線之後做了哪些調整再來分享給大家知道一下。
#funliday #autocomplete #msgpack #debounce #nginx