最近又重新發現新的問題
就是自己的腦部同時進行訊息輸出跟彙整的過程中，會有闡述完概念，忘記目的的問題。
原因一方面是腦部運轉速度變慢了，另一方面也是其他感官單位時間內能獲取的資訊量比以往更多所致。但不知道哪個變因的影響比較大。
- 12月 30 週四 202114:04
團隊溝通除了手段，還有其他問題
- 7月 29 週六 201711:18
直播輔助服務
直撥崛起，除了常見的打賞形式服務以外，在社群內的經營者，也逐漸開始嘗試透過直播跟客戶互動，但是由於資源有限，往往要一人同時處理多件事情。
未來應該會需要一種，協助業者直播的服務，可能包括AI或BOT，以及一些基本的投票，訂購等服務。
- 7月 29 週六 201711:10
緊張鬧鐘
一個簡單的App，緊張鬧鐘
打開後註冊相關人員連絡方式。然後設定每天幾點起床。
相關資料會紀錄在伺服器上，鬧鐘響時如果沒有在一定時間內按掉，伺服器就會根據設定的內容發通知給指定人員。
應用方式：
- 狀況一：普通應用
設定
如果沒準時起床就發信請假：「我身體不舒服，會晚點到」 - 狀況二：遲到職人
設定
如果沒準時請床就自動發出辭職信，每天要起來攔截辭職信，應該沒人敢睡過頭 - 狀況三：話在心口難開
想表白？真心話？沒有勇氣講，如果不起床攔截就會自動發出去給對方... XD - 狀況四：獨居老人
如果發生意外，沒有正常起床，趕緊通知家屬 - 狀況五：甜蜜懲罰
老婆幫忙設定好想買的名貴包(最好五萬以上)，如果早上沒及時起來攔截，就自動刷卡買回來...
鬧鐘觸發後要開甚麼，應該只要整合線上的一些API服務就能做到不少事情了... XD
費用的部分，不如就一律免費，但是遲到一次自動刷一千給服務供應商，30%給Apple抽，30%做公益，剩下40%用來維運主機...
-- update
緊張鬧鐘的邏輯不難寫，但是代替User Po文告白或者幫刷卡買禮物等機制剛好都是臉書及代收付公司不允許的交易方式，因此有實現的困難。
- 5月 19 週五 201710:40
關於開會
[筆記下心得]
許多人習慣離開會議桌後再來整理會議中討論到的待辦事項。但離開後很容易被其他事情中斷而忘了做安排，之前因為要對付銀行客戶的關係，習慣會議中馬上確認，除了較有效率外，也能避免事後反覆確認的困擾。
--
會議結尾應達成的工作
1. 所有討論的項目都該有個結果
2. 沒有結果的結果，就是待辦事項
3. 明確委任負責人
4. 待辦事項一律壓時間
5. 無法確認執行時間，可壓下次檢查時間
昨天PM找我討論預計有新工作要加進排程，我說：「那我們來排工作吧！」
結果PM說：「喔，我想等我確認清楚再來排，現在很多事情都還不確定。」
- 4月 27 週四 201715:47
GET 與 POST 的豆知識
早年寫網頁時，資深工程師會笑新進工程師連GET跟POST都分不清楚，但這麼多年來，大家都真的清楚嗎？
近年來由於各種RESTful API的發展，跟各種工具的普及，在單一URI下，透過識別Http Request Method來判斷客戶端的目的上，越來越趨於統一。另一方面也另人感嘆，從1999年就更新的HTTP/1.1協定中就考慮到的各種應用情境，直到多年後，才逐漸地了解他在應用面的價值。
這兩天遇到兩個小問題:
1. GET是否容許用 Body 來帶參數呢？是否如我們的印象，GET就是不能有Request Body的呢？
2. 如果用來操作資料的話，應該如何區分PUT跟POST的差異呢？ PUT代表新增，而POST代表更新嗎？還是相反呢？能否讓POST同時具備新增與更新的能力呢？
- 4月 12 週三 201712:09
Dependency Injection of React?
[不知理解是否正確，先記錄]
https://medium.com/@maxheiber/no-need-for-dependency-injection-in-react-components-641182760aaa
恩... Angular 說他的重點就是 Dependency Injection，React則說你根本不需要DI... @@
Angular的範例，DI主要用途在於將Component中的Dependencyt抽離，優點主要有反應需求變更跟便於測試。大部分用途有以下三種：
1. 抽離商業邏輯
- 10月 28 週五 201601:33
反省與自得
好吧，今天發現自己做了很多錯誤的決定，但最後，總算也發現有件對的事，能夠少許療慰一下。
儘管我試著避免犯過去犯過的過錯，但用的方式仍不對。過去強者我同學Miller及小明一直告誡我的：
1. 授權、信任團隊成員
- 8月 05 週三 201518:22
明明接設計案，結果卻在幫客戶開規格...
做產品設計一定要試著去了解產品的定位、目的、對象需求、發展、一些Domain Know How等，然後為了說服客人不要浪費我時間作一些沒用的東西，所以必須把他的產品定位搞清楚，才好跟他說哪些要做，哪些可以不作，到最後就是直接開規格了。
最近工作量好像有點升級，除了介面，API，甚至到韌體還有晶片的能耐都要考慮。
- 1月 23 週五 201503:40
不知所云的一篇抱怨文...
2008年開始，做UI都習慣考慮手指觸控操作，直到IPAD出現前都還沒有人特別覺得這是趨勢。後來App流行時，我已經懶得做UI設計了...
2010年，認為交易平台的建立是數位商務必然的趨勢，當時跟投資人說：「未來GPS普及，出門買東西都是線上交易，到時候需要一個平台，所以我要先做好準備。」
今年雖然還停留在老梗的O2O跟行動交易框架內，不過不出幾年應該會有新名詞來說明這件事情了。我已經懶得搞這飛機了，才一堆人找我做行動POS，但還是沒一個看出該做交易API平台而不是行動商務... = =
我也懶得提案了...
- 1月 21 週三 201502:14
不是一定要動起來，才有使用者體驗
剛好聊到系統設計想到，對很多開發人員的經驗而言，防呆是很重要的事情，把使用者當笨蛋，確保系統只接收到控制範圍內的輸入。而我的做法恰恰是反其道而行。
每個界面開發人員都認為自己在開發「好的使用體驗」，但是大部份人在設計使用體驗的時候，都是無差別式的設計，也就是，不管做什麼界面，都是以 0 ~ 100 歲的任何人一開到就會用做標準。或至少是 9 歲 到 40 歲。這種設計理念我實在無法苟同，不止影響開發產出效率，同時也限制系統的發展。
我認為好的「使用體驗」，是要根據系統的目標族群，讓新手有足夠的資訊完成工作，老手有足夠的彈性加速工作，更甚者，使用者還能發明意想不到的用法。
在有限制對象的情況下，有時候最簡單的設計反而最好用