我家產品HappyStyle開發到尾聲，需求上的功能已全數完成，接下來的時間可以來優化各個功能。若想要讓使用者體驗 (User Experience)變得更優，那麼勢必要提升App運作的流暢度。
像是在滑內容清單，若能無「卡頓」現象會是優良的體驗，那麼如何來減少卡頓狀況？我們可以利用Xcode內建的工具Time Profiler (時間分析器)，顧名思義就是利用它來分析各個方法 (Method)或函式 (Function)，所執行的時間狀況會在界面上清楚呈現，除了可以觀察自訂的也能探索內建的。
2018年12月22日週六是冬至也是補班日，我特地起了個大早先去四號公園，挽起袖子開心捐血，豈料血流速度異常緩慢，天氣也沒特別寒冷，到底是怎樣的原因讓我的血流速度緩慢？最後我歸咎前一個月以來鮮少運動所致。打算等右手肘瘀青消除後，再來「踢館」討戰～
儘管捐血鎩羽而歸，捐血十數次難得失敗，這個經驗還不賴啦⋯⋯該補充營養的儘管吃，我也已先拿兩條紅色紀念毛巾。跟著蘇妃雅在休息室享用餅乾和飲料，離開前還多拿些。走向出口，可愛護士還跟我們說不好意思呢！
隔年1月26日週六，因為收到簡訊說1/25-26捐血送西堤愛心券，趁著這一天沒有開偉大會議，冒著14度低溫來到四號公園。出發前吃完奶昔再灌約1000CC的水，在等待蘇妃雅的時候還跑了兩次圖書館上廁所，並且在公園稍微小跑步暖和身子，為的就是要促進血液循環，好讓我在捐血車中順利捐血呀～
我的愛車似乎每一年內都會有機車零件要做更換，去年(2018年)一月差不多這時候換了第二次的高壓線圈，今年(2019年)一月換了第一次整流器和第二次電瓶，恰巧里程數剛超過20007公里，2017年2月才做里程數一萬公里保養，約兩年後終於又再次滿一萬公里。😛
1/20週日要趕去板橋車站拍片，在板南路和中正路口綠燈催油門時熄火，我以為還能像往常那樣發動，可惜情況不同而再也無法發動⋯⋯這下子真尷尬，我還沒意識過來，後方的公車叭了我一聲，只好趕緊把機車挪到路邊。
註：參考文章修理機車。
想繼續看下去的話，先來了解一下機車的基本規格與狀況：
以上可供類似狀態的朋友參考喔～
配戴Apple Watch Series 3已經滿一年，上一個公司是做健康科技產品，老闆想以智慧穿戴裝置起家，從手環過渡到手錶，而我就是那個關鍵開發者。很高興我的工作能跟生活結合，於是茶餘飯後我可以跟親友聊我的工作是多麼有趣，自己開發的App自己也會想用，人要生活就要動，目前最方便偵測人體活動的莫過於手錶，我可以一整天配戴Apple Watch查看我的活動紀錄。
由於這些紀錄目前只能在儲存裝置上，無法上雲端保存，於是我只好截圖來紀念這一年來不間斷的活動紀錄！其實我從1代到3代都有配戴過，只是都沒有留下畫面紀錄呀～
可以看到2018年1月23日我開始配戴Apple Watch。
我們開發軟體會透過Jira來記錄細節，像是新增功能或修正錯誤，甚至還有概念驗證 (Proof of Concepts)。
概念驗證（英語：Proof of concept，簡稱POC）是對某些想法的一個較短而不完整的實現，以證明其可行性，示範其原理，其目的是為了驗證一些概念或理論。
現在內容農場盛行，想要分享篇有「意思」的文章都要考慮再三，因為深怕分享錯誤的知識內容，那可能會禍害遺千年！
難得有篇文章：112歲老中醫臨終前揭秘自家祖傳的100種養生秘方，讓我五年之後想要再回首閱讀，也因當時看到的時候「有些感覺」，覺的他說的是對的，但我當時尚無法親身做到，直到現在終於做到些「指導」，於是今日變得「很有感覺」就想分享！
也許是因為修行後，逐漸領悟到人生來世上真正的目的，由迷轉悟而豁然開朗，許多事情的答案不在外面，就是在我心裡頭，只要我扒開層層包住的「烏雲」，我將會活得更像自己：）～
今日是2018年最後一個上班日，正當我要聚精會神在工作上，我的同事Parry來跟我閒聊，其中一個議題是我哪時候要發佈新文章ＸＤ～說來慚愧，今年寫作時間不多，好想回到研究所時代，每天出產一篇「認真生活（學習、工作）」的文章呀！
被Parry催稿真不好意思，首先來回顧2018年2月11日我早已打好，放在Evernote中的一篇草稿「刪除手機遊戲」。神奇的是，當我寫完這篇草稿，不到一個月我的愛機iPhone6被強制更新，而且還「更新」失敗，使得我必須「還原」，這個動作代表我存在手機裡的資料檔案都要化為烏有⋯⋯
也許是件好事，讓我不用猶豫到底要不要刪，除了每天記錄所拍的相片，其餘的資料大多已存在雲端，而手機只不過是個載具，約莫隔4年就要換一支手機，我便不用再擔心手機出事或遺失。
身為一個喜歡嚐鮮的科技人，在住家附近南勢角捷運站附近，興南路上有家大潤發迷你站，騎車經過時偌大紅色的招牌吸引我，便想在空暇時間前往查看，12月某週日天氣晴朗，在麥當勞享用買一送一的明太子海陸雙星堡後，就到對面的大潤發迷你站初體驗！
去年還在健康科技公司上班時看到這張圖解軟體工程師離職後，還覺得是個開玩笑的狀況，沒想到終於被我遇到啦⋯⋯
曾經有聽說過，某新創公司的產品是由超強老闆寫出來，上線營運後發現市場接受度相當高，有意擴張規模而雇用幾個工程師來承接他之前寫的產品，這是我朋友吉米的前公司做博弈軟體的故事。
產品創始人把心中的想法迅速時做出來，透過雛形來測試市場接受度有多高，開發軟體過程想必不會寫得很有彈性，因為「彈性」是需要大規模超仔細地想各種可能發生的情況。比如若我當初只想要搞定80%的狀況，大概一個月就能做出來；若我要再觸及剩下的20%，可能要再多花兩個月才能完工。於是乎我會選擇前者！
當驗證市場可行後，接下來就來補剩下的20%。然而儘管只是20%，想要在既有的架構上可就不太容易擴展，而老闆僱用來的工程師肯定不可能全盤了解當初寫的架構與流程，因為裡頭包含各種Features、Bugs、User Cases、Work Flows、Workarounds等。加上老闆所展現的Coding Style和Logic，與雇用來的工程師所使用的並不一致，導致剩下的20%由老闆來寫只要兩個月，而若讓雇用來的工程師來寫的話就高達半年⋯⋯
回想我還在健康科技公司時，是如此呼風喚雨，iOS App由我一個人獨自從無打造出來，後進來的Android工程師都要仿照我的方式來實現，畢竟小而美的創業公司資源不多，要盡可能使用最少資源來達成目標。對比現在港商的工作狀況，產品已經由資深同事開發10個月，架構是由他建立起來的「樂高系統」，MVC架構非常分明，就好比我當初使用MVP架構寫HiLife App，然而相對的所花費的時間變多。
過去一個大功能我能在一天內完工，現在一個小功能我可能一天內還無法安心動手，落差非常大啊⋯⋯有時候真的想要不管既有架構，把可運行的Code塞進去，馬上就可以有正確的效果，只是長久來看，只會不斷增加「技術債」，這我在圖解理想與實際的軟體架構有提過。
想起我偉大的前同事德叔說：
要Refactor他人寫的Code需要很大的氣度。
我在下方回答笑說：
我寧願寫Code給別人Refactor，也不要別人寫Code給我Refactor！
對我來說，加入新創公司就是想快速成長，要像個成長駭客一樣跟著產品進化，來盡可能獲得較多的成就感！最終實現自我～
於是乎，之後若要我選擇的話，我肯定會選擇從「無」開始打造產品，因為我可以根據當時的規格（畫面、功能、流程等）來決定架構，可以很快就把既定的藍圖實現出來。
我心中有好多Idea要實現啊⋯⋯
逍遙文工作室 
HappyMan・迴響