Archive for the ‘Uncategorized’ Category
JavaScript 物件中快速檢查屬性
JavaScript 物件中快速檢查屬性
在我們一般使用 function 或者呼叫某些 api 的時候特別需要去驗證，某些值是否已經存在，或者使用者有沒有忘記傳入哪些數值進來。
為了要做這件事情，通常我們會寫一堆 if 去判斷每個值有沒有出現問題。
if(!formData.name){
return reject("Parameter 'name' is required");
}
if(!formData.size){
return reject("Parameter 'size' is required");
}
if(!formData.sizeUnit){
return reject("Parameter 'sizeUnit' is required");
}
if(!formData.width){
return reject("Parameter 'width' is required");
}實際上透過 lodash 可以讓這件事情非常快速完成。
let _ = import 'lodash';
let result = _.has(object, ['name', 'size', 'sizeUnit', 'width']);
if (result)
return reject("Parameter is not correct");後記
雖然說並不是太困難的程式，但是透過套件真的可以讓程式碼短少一點，讓我們程式透過 import / require 將模組載入，讓程式碼更短。
short code is best codeExpress.js 的黑歷史及 Express 未來
Express.js 的黑歷史及 Express 未來
4/5 更新， 根據讀者回饋，目前 IBM 已將 Express 及相關所有權轉移到 Node.js 基金會手中，讓 Node.js 社群能夠投入資源。
https://nodejs.org/en/blog/announcements/foundation-express-news/
Express.js （以下簡稱為 Express）相信如果有在開發 node.js 程式的人肯定不陌生，幾乎是開發 Web 應用上手的第一堂課程，而 Express 至今已經四年左右的時間，幾乎是從 Node.js 0.4 版本時期就開始有（憑藉著印象，如果有錯請大家指正），當然這當中必定要讚嘆一下，神人 – TJ （拱手作揖）。
而在 Node.js 與 io.js 的戰爭時期， TJ 也宣布將 express 釋出，最後是轉換到 StrongLoop 公司底下，全權交給 StrongLoop （包含網域名稱， Express.js 以及 github reps 的所有權），當然這中間 TJ 肯定有協調些什麼，以及與其他 contributor 。
使用 Express 不可不知的人物， Douglas Wilson ，他是在 TJ 離開 Express 幾乎所有 reivew, issue, merge 都會經過 Doug 的手中
但是燃火線在於 Express.js 4 -> 5 的這段時間， StrongLoop 被 IBM 買走，但是也因為 Express 是一個很龐大的生態系統，以及對於 node.js web 開發是一個影響許多的 open source project ，而在這段時間中， Douglas Wilson 因為某些事情憤而離開 Express 組織中。
這才真正引爆了大家對於 StrongLoop, 及 IBM 的不滿。
黑歷史重點回顧
- TJ 將 Express 名字及所有內容轉移到 StrongLoop
- StrongLoop 並沒有指定或者對於 Express 有任何大量持續性維護
- 只有 Douglas Wilson 及其他志願者持續維持整個 Express 專案的進度
- StrongLoop 在這之後宣稱自己有所有權管理 Express ，但實際上沒有任何作為
- StrongLoop 被 IBM 收購
- 收購後， IBM 連同 StrongLoop 持續沒有任何作為
後續推測是在整個 issue 中，IBM 的人們開始介入流程中，並且對於前期貢獻許多得開發者，及開發流程開始進行干涉，但是實際上對於 Express 的整體發展都是無效益的。
當然這嚴重的影響到 Express5 的發展，也的確開始走向當時的 io.js & node.js 的分裂狀況，為了避免這狀況再度發生，幾乎很多 node.js web 開發的大大都進入到 express issue 當和事佬（？）當然這當中還是要讚揚一下 Doug 的持續支持才有辦法成就 Express 到現在。
後續發展
進度還是持續中，不過很緩慢，但是在 issue 裡面，看的出來 IBM 也知道事情的嚴重性，稍微派了一些開發者進入到 Express 中開始投入資源進行開發。
目前 IBM 已經將 express.js 整個專案及相關所有權轉移到 node foundation，全權由 Node 基金會投入人力，資源進行維護，開發的工作。
但是身為一個旁觀者，我必須說，這就是『自我願意』，和『不願意』的差別。
後記
軟體開發就是人為的藝術。我們雖然口口聲聲都說自己是在對著電腦進行溝通，但只要產品牽扯到團隊，營運，推廣，勢必就會有人的問題發生。
對於開發技術來說真的是有趣的一件事情，不論今天是 inhouse 或者是 open source 的專案，只要扯到人，就會開始有許多問題。
IBM 到底後續會如何看待 Express, 雖然 Express 是 open source 專案，實際上目前的所有權的確就是在 IBM 手中，雖然他是 MIT license ，但是 IBM 本來就不是吃素的。
文中省略了 TJ 將 Express 整包轉讓的議題，畢竟很多人是認為 open source 是神聖不可侵犯的，但實際上 open source 專案要持續營運下去，都是靠著小部分的人持續努力貢獻著，最後如果要專心將這個模組做完整還是要靠錢與資源下去運轉，勢必後期的長期維運，需要仰賴公司支撐，或者是金援才有辦法持續茁壯，這是一件很現實的事情，這蠻值得思考的。
帶出幾個有趣的議題？
- Express 的未來到底會如何？ 是否有潛在的商業技術問題？
- 身為 node.js 開發者，我們是否該轉向，捨棄 Express, 朝向 hapi / Koa2 的懷抱？
- open source 到底是不是一個好的 business ?
這幾個問題就丟給大家仔細品味思考。
Ref
百度座標系統反查
百度座標系統，
正式產品開發，技術框架的選擇
每次面對新的專案開始，對於開發者來說總是充滿了許多驚喜及幻象，總是幻想著該如何使用最新的架構在開發流程上，將這次的新開發專案，視為是一次的挑戰，一個可以讓開發者試刀的競技場。
對於技術的熱情及憧憬，總是無法避免，技術本位的我們，心中總是充滿了熱情及想法，看到許多好的框架，酷炫的套件庫總是會希望來上一回，但是火砲洋槍一開始使用時搞不清楚，不僅傷身，還會搞的自己灰頭土臉，更不用說實際上要用在動手殺敵上。
火砲洋槍，中華武術，那個好？
每次看到許多火力展示，洋槍大砲的面前展示，偶而來個酷炫的『成果展示』，總是讓我們底下看的目眩神迷，長官們看的拍手叫好，就只差一個起立敬禮。
但是對於實際要開發產品，這些 F-999， 阿趴器等新世代的武器到底是不適合我們？ 這到底要怎麼評估！？
火砲洋槍炫技拆解
在激情過後，目眩神迷之後，我們關起門來，靜下心，重新旁敲側擊一下到底這火砲是怎麼跑得，這洋槍會不會傷身，畢竟中華武術五千多年，都是先講求不傷身在追求成效，否則頭緒沒有釐清，就成了七傷拳，傷人七分，傷己三分，這就不妙了。
炫技之餘，總是會有跡可尋，從開源專案來看，我們可以從大多數的 Readme 略知一二，到底這到底是什麼咚咚，以 react 我們就可以從開宗明義瞭解，
A JAVASCRIPT LIBRARY FOR BUILDING USER INTERFACES以及底下的段落可以略知， react 並不是一個框架來著，而是稱呼為 library ，同時也能夠和目前的專案整合使用，採用了所謂的 VIRTUAL DOM, one-way data flow 的概念。
當我們有了一些瞭解，也開始抓到一些 神秘的字眼。
解開神秘的面紗
當抓到某些字眼，以及神秘的詞語時，再度將這些字串前往求尋 google, wiki 大神的幫助，讓我們再接下來閱讀文件時，這名詞的定義是什麼。
這時就可以瞭解，這洋槍到底是一把小手槍，還是一把火箭筒來著，至少定義上我們可以明確，也比較能夠瞭解，對於專案的導入是否適用。
文件及測試
我們可以視為前面的動作稱為『快速導覽』，接下來就是是否要採用套件的關鍵，從裡面文件是否充足，有哪些實際案例，範例展示。
如果是一個開源專案，從技術性上可以
- test code 是否充足，能否執行
- google , stackoverflow 是否有許多人討論
- github 程式開發進度狀態
- open source license 規範
等方向來瞭解是否符合專案需求，否則使用到一個 GPL 的專案，一旦被發現，就會知道 google 為什麼會有兩個 g。
POC (Prototype of concept)
最後，使用新技術，抓到核心應用，建立一個簡單的 POC ，透過實際的動手整合才會瞭解到底會有哪些窒礙難行之處。
這火箭筒到底是單兵操作即可，是否還要搭配一個強力支架才能運行，還是說已經有許多擴充元件可以搭配使用，這都必須要透過 POC 才能有個初步的評估及瞭解。
結論
對於炫技，神器總是會希望有朝一日拿在手上，揮舞一番，最好是能夠帶到場上殺敵打仗。但是很多時候等級不足，瞭解不夠，帶著神兵力器，最後殺敵也殺己，雖然成為了英雄，但是團隊的成員在這一路上，沒有戰死也半殘。
使用在正式服務的技術評估上，很多時候並不是炫為主，趨勢考量，而是綜觀希望成果，實際局面，技術成本，團隊成員等是需要綜合考量，也需要提供資源（時間，人力，研發，犯錯）的成本在其中。
資訊投資有賺有賠，開發前請詳閱 open source 說明書。
Wysiwyg Editor 分享 2015
wysiwyg 現在已經有了許多不同的轉換，雖然大多都是以類似 wordpress 後台風格進行編輯，事實上已經有許多東西可以提供參考，並且提供了許多不同版型可以讓開發者自由編輯。
有許多可以進行前台套件支持的 online editor ，目前覺得有越來越豐富的趨勢，提供參考，
基本款式
頁面上可以嵌入形式
整頁模式，
以上資訊提供參考。希望大家有哪些可以參考的套件，也歡迎提供，一起進行討論。
[簡報] 從失敗中學習打造技術團隊 – Webconf 2015, modernweb.tw
從失敗中學習打造技術團隊
從資淺到資深，透過不同時空背景，透過經歷不同開發流程中，經歷許多不同失敗經驗的累積，打造出團隊共同經驗，以及團隊建構出開發環境與流程。
相信大家都有走過一段又一段，艱辛刻苦的日子，web 開發這條路上大家並不孤單。
我想成功的案例大家已經聽了許多，也許採用反面的方式，我們來看看是否能夠找到更多可能性。
程式開發是一種很有趣的議題，也是一種很有趣的事情，對於自己這也會是一輩子的事情。
一個人到一群人
可是從一個人開發，到一群人開發是完全不一樣的兩件事情，從一個人開發，我們可以很隨意很灑脫，反正髒髒寫，髒髒做，可以執行就好。
可是當這件事情轉移到『一群人』的時候，其實就沒有這麼輕鬆，有許多需求規格就要明確，有許多前置作業需要說明，有許多開發流程需要定義。
（只是要開發搞這麼麻煩幹嘛！）
其實就希望一群人，跟一個人寫出來的程式都可以完全一樣，不論經過多少手。這件事情，很難也很不簡單，可是要做到這件事情，其實是有難度，而且需要持續學習，並且適當的學習，如何放手
相信自己的夥伴
每個夥伴都有不同特長，都有不同的特性，有人謹慎有人粗心，有人天生就有領導風格。在團隊下每個人都會有不同面相及不同特質或者是潛值。
如果能夠挖出對方的特質，特長，相信就可以讓團隊朝向另外一種層次的提昇，讓整體體質都向上成長。
對於網站開發
一個人開發，很爽。
一群人開發很煩，但是也可以很爽。
取決於主事者要怎麼決定，主事要要怎麼執行，產品本來就會有責任，就會有歸屬，也會有每個人的分工執行步驟要訂定。
很多時候我們覺得自己只是在寫簡單的腳本語言，簡單的程式語言，可是透過團隊力量，透過產品的誕生，之後，這將是眾人的結晶，眾人的晶華，大家可以發現另外一種工程藝術，以及工程之美。
CSS4 next generation of CSS
CSS 一直以來都並不是很被看好，也被視為是一種很簡單的裝飾性，腳本式裝飾語法（連語言都稱不上），但是對於前端開發人員來說 CSS 一直都是一門很博大精深，且需要經歷數個專案以上才有辦法體會的學問。
CSS3 從發展到目前為止，已經被許多瀏覽器應用於實務上，很多廠商也開始支援，大家盡量避免不使用 CSS3 語法，有時候僅止於需要適用於舊型瀏覽器（就是在說你，對 IE）。而到了現在使用者漸漸朝向 mobile ，因此我們可以不重視跨瀏覽器一致性問題，而可以做到跨瀏覽器，跨裝置兼容性問題的處理。
許多人會開始使用 SASS, LESS, Stylus 等基礎於 CSS 之上的語言開始展開。主要是根據 CSS 無法使用變數，調整上無法如動態語言般容易使用，容易擴展。
這也是為什麼要講到今天的主題 CSS4 ，
W3C 目前已經將 CSS4 進入草案階段，裡面也有很多根據不同發展語言所調適出來的範圍進行修正，例如 Variable，Mixin ，condition 等這些大家最常使用到的部分，讓原生 CSS 開發就儼然成為另外一種程式腳本。
CSS4 更多的是模組化的觀念，將許多原本延伸 CSS 語言的特性歸納近來，開發起來更接近模組化的程度，提供了很高的客製化。
CSSNext
CSSNext 就如同 ES6to5 一般，屬於讓現在讓現在你就開始體會到 CSS4 的優點，直接使用 CSS4 的語法開始進行開發。
除了最棒的效能成果之外，另外也提供了 postCSS 這類相關的 js plugin 可以使用在自己原有的 front end compile 設定中。
後記
當然這一切都還只是草案，不過非常值得關注的是以這 W3C Spec 為基礎開發出來的相關性模組，就如同 ES6 的轉換一般，CSS4 的推動肯定也會引發許多延伸性模組及框架。
當然對於長期開發 CSS 的前端人員來說是一大福音，大家可以多多討論關於 CSS4, postCSS 相關的使用方式，讓原有的開發流程可以無縫銜接到下一個世代。
修正
文中所提到 CSS4 事實上此名詞並不存在，主要在於 CSS3 + CSS future (支援變數, condition, mixin 等）及 CSS Selectors Level 4 新功能，特此說明此名詞定義。
Ref
從技術到管理，第一次管理就措手不及
從技術到管理，第一次管理就措手不及
這中間轉換過程，會很掙扎，也很不踏實。但是如果想要朝向技術管理職，朝向帶人，這段過程看再多書籍遠不如自己親身體驗。
從自己也將技術職位轉換到管理職也有一段時間，這中間經歷過許多不同階段，取得到階段性的挫敗，這些過程記錄下來，轉成片段回憶記錄提供給未來的自己，也給大家參考。
當然這一路走來並不順心，也不如意，在過程中更多的是迷惘，與自己單兵作戰的方式截然不同。
但是要說的，回歸到結論，與當初在 combo 8 活動裡面所做的簡報結論呼應。
『一個人強，不強。一群人強，超強』
在許多經歷中，自己遇到的心境以及遭遇到的問題，部分摘要如下，提供給各位從技術到帶人，管理，提供給各位參考，
工作上需要捨棄的東西
從技術轉換到管理，開始逐漸會感覺到，寫程式的時間越來越少，碰技術的時間也越來越少，大部分的工作時間，幾乎是在開會，討論，詢問，帶領新手，解決團隊問題等。
在這段過程，突然發現自己不再是一個人獨立作業，而是跟一群人（至少一到兩個人以上）共同開發，共同運作某些項目，資深的人自然容易被拔擢兼任管理其他人進度，開發項目的人選。
當自己欣然接受這樣的挑戰之後，迎接而來的是，需要捨棄的東西，從現在開始，目標不再只是把事情做好，而是帶領團隊去做對的事情，對的方向。
在這段過程裡面，目標僅只有一個，如何讓所有人協助你完成你所決定出來『對的事情』。
這個目標說來簡單，實際上卻很難，從今天開始沒有單打獨鬥的『英雄模式』，所要做的事情是，讓所有的舵手將船開往正確的方向。
這中間最弔詭的就是，以前的獨善其身已經不再適用，現在首要目標將是，你當初眼中的『弱雞』，都要讓他變成『洛基』，讓他們每一位都可攻可守的狂戰士。
而身為管理的你，不再只是自己扎馬步，念心經，變禪師，而是要每天帶領大家照表操課，安排適當進度，針對成員不同步伐調整，練就出屬於『大家的十八銅人陣』。
正確的當一個夾心餅
別以為管好團隊就沒有事情，身為管理的你，不只是管理下屬如何變強，變壯，更需要花時間與主管，長官，老闆溝通，讓他們知道你的成員如何變強，成長多少，能夠為公司，組織帶來更多產值。
當然老闆有時候想法會是有許多的天馬行空，跳躍境界，而身為管理的你，另外一件重要的事情就是將外太空的長官，拉回到凡間，至少離地面近一點，多了解凡塵世俗的憂愁，困惑。
對於團隊成員，要他們漸漸往上當神仙，另一方面又要把天上的神仙拉近凡塵，這就是你的無奈，但也是你的責任，管理就是這麼尷尬，每天，每月，每個週期只要在管理職位的一天，就會不斷的在這中間被拉扯，中間的權衡，只有更好，沒有最好。
不論做出什麼決策，總是會有人不開心，但是身為管理一定要在這中間做出仲裁，而你就是這樣的夾心餅。
決策事情輕重緩急
在這位置的一天，就會發現不再只是對於技術的實現，更多的是處理人性的問題，不論對上及對下，都會有不同課題，這麼多種不同議題的平行處理，就端看管理者自己的個性適合什麼樣的方法。
市面上的管理書籍眾多，就讓大家多去揣測屬於自己的最佳運作模式。
很多事情也從技術職的自己親手下去做，到指派團隊成員共同協作，在接觸到管理最初的時候，總是容易讓自己心力疲乏，因為又要寫程式，同時又要管理，同時還要開會協調，終究會發現自己根本沒有時間去處理寫程式的細節，可是漸漸的也發現，自己的涉入其實更容易拖慢團隊的進度。
擔任管理後，目標就是打造完美團隊，而不在於個人成就，所以更多時間點，是需要在旁觀火，透過觀察的角度，適當的調度人手，適時的向上反應現況，決定所有的團隊步調進行。
記住，你的決策，會決定團隊的成敗，這件事情，只有管理者能夠處理。
扛起資源調整責任
聽到隔岸觀火似乎對於有些人來說會覺得是個甜頭，不用再自己動手下去實作，只要出一張嘴就可以搞定所有的一切，似乎離『第五代程式語言』越來越接近了。
但是請記住了，團隊的成員都看在眼裡，你的答應，你的承諾，都會變成大家的記憶，中間資源短缺，沒有人手，設備不足等問題，都需要你來進行協調，來跟老闆溝通。
而你必須根據每次的正確決策，錯誤判斷綜合出應該讓團隊成員執行方向，練功策略等，同時也要準備資料，讓長官看到團隊的努力，讓成員的汗水，辛苦的成果能夠讓長官看到。
這件事情你必須一肩扛起，因為你是管理。
事情並沒有想像中的這麼容易。
適當讓團隊嘗試失敗
對於工程師最難過的，這階段，就是眼爭爭看著事情爆炸，雖然小心但是要讓事情在可以控制範圍內，嘗試著讓事情發生，進入到失敗的環節中，從每次可控制的錯誤中知道每個人可以達到的極限，以及團隊的可能性。
在這自身成為工程師的時候，所無法容許的事情，但是你必須要做這件事情，以及適當狀況下指導棋。
保持團隊目標
維持團隊應該有的一貫風格，與其說保持團隊目標，更貼切的是保持團隊開發步調，在沒有節奏的狀況下，找到適合自己，也適合團隊的開發節奏，讓事情跟著步驟走。
所以身為管理，需要有團隊的協助，加上判斷能力，保持對人的敏銳，才能維持住團隊目標，保持團隊節奏。
帶人帶心
而從以上的這些過程中慢慢判斷，哪些人可以幫助你，哪些人目前適合在什麼位置，感覺有點像是下象棋，但是不同的是，沒有人會跟你說他是 車 還是 士 甚至隊友裡是可以當任將的角色，都會從中慢慢發現，讓隊友進行嘗試，對於每個人特質找到適合位置。
而這中間就會發生有人聚合，有人離開，也同時協助隊友轉介到更強大的團隊中持續成長。
對於人的敏銳度，需要持續保持，不論從課程，書籍，直覺上，經驗上，都是相輔相成。
小心技術陷阱
最後還是要提醒，當進入技術管理中，最難的就是要眼看著執行細節而不去處理，看到許多有趣的新技術，好玩的新玩具，卻不能像以往一個工程師般直接跳下去，埋頭下去執行去進行測試。
再次提醒在這段時間，最難的就是 放手 ，放下對工程師，對工作技術上的執著，看的是人，是團隊，是合作，是整體產品進展，是對上對下的資訊通透，只有多給予自己空間，及時間才有辦法釐清這一切，只有給予時間及空間，才有辦法協助團隊騰出這成長的時間。
技術多強不再是首要關鍵，能夠如何保護隊友，讓團隊前進，讓每個人朝向自己目標邁進，則是接下來要迎接的課題。
繼續技術之路
這段時間，發現自己寫程式越來越少，的確也讓自己在實作上沒有像以前如此快速，更多的是如何讓團隊更好，如何爭取更多空間及時間，讓隊友有機會成長。
也許對，也許錯，但是人力管理真的要自己親身多嘗試幾次錯誤，多經過許多次失敗以後，才有辦法了解箇中滋味，最終還是要說，
『有團隊的感覺，真好』
現在最開心的時光，就是夜深人靜，寫著自己的小 Project ，看著文章，嘗試一些沒有壓力的 example ，這種悠然的感覺，實在暢快，這也是持續會在技術上努力的一條線，也是不會放棄的線。
這一路上獲得許多朋友，貴人，長輩相助，才能有機會持續讓自己對於管理這件事情逐漸明瞭到底『管理』是怎麼一回事，希望透過自己的紀錄，能夠讓技術轉換到管理職的工程師們，能夠有個參考。
關於活動的那些事兒
許多活動背後的事情 …
如果有一起合作過的夥伴應該知道我在閒聊些什麼，
JSDC 其實到現在已經三年多的時間，每一年都有不同的聲音，也有不同的爭議，也有不同的問題，在這麼多的時間裡面，只有每一次成果出來，隨著時間過去，我們才能漸漸了解大家需要什麼，我們需要什麼，這個產業需要的是什麼。
而這中間四年多的時間大家都是利用工作之餘時間舉辦 JSDC ，要同時肩負工作責任，以及活動內容，其實都是一種苦差事，對於參與其中的過程中，中間的痛苦，淚水，熬夜，失眠都是參與 JSDC 的過往雲煙。
如果可以讓事情更好！？
其實這是一件有趣的事情，因為事實就是我們只有 24 小時，而這 24 小時之中，工作沒做好，就是會挨罵，活動事情沒有處理好，就是會撻伐，其實苦比樂多。
為什麼持續下去！？
也許這就是人性，一種看到光芒，想要探到底，希望看到光到底長什麼樣子，也許最後是一另一個黑洞，也許最後是神聖的希望。（天曉得）
而這幾年，這幾段時間，每次的每次都會掙扎也會疲累，但是回頭過去看看，並不覺得累，那就是一段過程，一段自己的經驗，美好的體驗。
而就如前年 (2014) 所說，當年的活動是我自己想參與的一場活動，也是最後一場活動，因為對於我 JSDC 夢已經達到，我不後悔。
JSDC 需要新血
這段過程中，經過許多合作來來往往，悠悠晃晃，在這段過程中，將所有活動放掉，將所有事情結束掉，而中間遇到許多請益舉辦活動的人不在少數。
而這過程中， Simon 讓我看到了，真正的實踐，真正的團隊，從持續堅持的 Node.js Party, Node.js 讀書會， Taiwan Hackthon 活動等，都讓我看到新一代的堅持。
堅持
辦活動沒有訣竅，要把事情做好，做到完美，就只有『堅持』兩個字，唯有這樣才能將自己希望的事情貫徹，做到盡善盡美。
希望透過堅持的人，試著創新，創造另一個可能性，創造新可能，創造新契機。
JSDC 2015 將會由 Simon 擔任總召集人角色，創造另外一波不一樣的 JSDC。
持續支持
曾經身為 JSDC 共同創辦群的一員，將會持續用行動，資源支持 JSDC 活動，就算今天已經不是自己在其中，但是持續會繼續支持這個活動。
如果你有希望舉辦任何公益性活動，我也願意無償提供過往經驗，與大家一起分享，走向更美好的未來。
fixed freeze issue of android 5.0 use facebook messager
fixed freeze issue of android 5.0 use facebook messager (HTC M8)
開啟 facebook messager ，設定，把音效項目都關掉。
接下來神奇的事情就發生了，程式可以正常執行。
solution, disable mute of facebook messager. then it works
樂活達康 