概念驗證 (Proof of Concepts)
我們開發軟體會透過Jira來記錄細節，像是新增功能或修正錯誤，甚至還有概念驗證 (Proof of Concepts)。
概念驗證（英語：Proof of concept，簡稱POC）是對某些想法的一個較短而不完整的實現，以證明其可行性，示範其原理，其目的是為了驗證一些概念或理論。
廣告
Archive for the ‘研究’ Category
關於耶穌之死的關鍵原因
過去只知道耶穌是被猶大背叛而死，就僅止於此。12/16寫完程式後的週日晚，天雲老師提到彼拉多這號人物，好奇地去查詢網路文獻，看來他是幫兇的第三位，若這位握有重權的彼拉多能「臨崖勒馬」，耶穌應該就不會因此受難⋯⋯
- 一是死於叛徒猶大的出賣；
- 二是死於當時因嫉恨發狂的猶太祭司和長老們，以及被他們影響，煽動的希律和民眾們；
- 三是死於彼拉多因私心、膽怯和懦弱而對邪惡的順從。
這三個關鍵原因，無一不是出自「私心」，這讓我想起2018年12月在網路很廣傳卻沒有被主流媒體報導的「誰摔死李新」。偉大的救世主耶穌都因此喪命，僅只是個議員的李新，甚至在地球上任何一個人，都可能因為「不能說的秘密」而死的不明不白（可能被冠名為自殺），好在21世紀的今日，民主和網路已非常盛行，終於可以減少被一手遮天的機率⋯⋯
112歲老中醫臨終前揭秘自家祖傳的100種養生秘方
現在內容農場盛行，想要分享篇有「意思」的文章都要考慮再三，因為深怕分享錯誤的知識內容，那可能會禍害遺千年！
難得有篇文章：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・迴響