如何成為Scrum專家 - 極簡計畫書

Scrum是推進團隊進度，合作專案的敏捷方法論之一。在過去幾年來從資訊產業，金融業，甚至學校教育，都有不少人在倡導這個簡單而且踏實的方式。因為Scrum有很多優勢，例如減低壓力，具有務實的彈性，容易評估現況，易於控制品質。這些優勢，可以用在大部分的企業環境中。因此，成為Scrum專家對職業生涯很有幫助。

學習Scrum並不困難，在各企業巫醫的網路資料中，早就擁有看不完的資料。請參考這篇。

對職業生涯有幫助的不僅是「學會什麼是Scrum」，更重要是成為Scrum專家。或者，至少成為在他人眼中的Scrum專家。專家的定義，請參考註1。

或許你在職場有2-4年的工作經驗，作為一個團隊成員，在專案領導人的帶領下，參與以Scrum為基礎的專案。然而，這不會讓你變成Scrum的專家，因為你只是「照著做」而已。

在此提供一個極簡計畫，可以在很短的時間內讓自己變成Scrum專家。

如果懶得看說明的長篇大論，可直接到這個網頁下載計畫書

開始之前的條件

這份一頁極簡計畫書有使用上的條件：

(a) 必須要有還不錯的英文閱讀能力，TOEIC750以上。如果你的英文能力自認不夠，請參考這裡。

(b) 必須要有2-3年以上的實務工作經驗。而且在工作環境中，至少聽過Agile/Scrum。

(c) 必須打從心裡認為有效使用Scrum是有好處的。換言之，不能是因為「有人叫我要學Scrum」而學Scrum。因為，此極簡計畫書本身執行的方式也是Scrum！


如何成為Scrum專家極簡計畫書的使用步驟如下：

(1) 確認目標的實質意義

此極簡計畫是要在2個月內，讓執行計畫的你變成「Scrum專家」。而何謂Scrum專家的實質意義就是在此極簡計畫中三個sprint的「實質產出」。

Sprint-1 知識：讀完2本Scrum書籍，以及2份網路資料

Sprint-2 證照：取得Scrum證照

Sprint-3 研討會：舉辦公司組織內Scrum研討會或分享會

這三個實質產出的組合意義，目的就會讓你成為Scrum專家。即便不是Scrum大師，至少也是被大部分人承認的專業人士。

這三個Sprint各有已經設定好的任務(Task)，所有任務完成後，就表示該Sprint完成了。而每個任務本身的描述都是有簡單清晰的「完成條件」definition of done。

(2) 分配每個Sprint的時間

計畫書中，每個Sprint各有數個任務，每個任務都有估計的時間。時間是以小時為單位。加總起來，會有要完成Sprint所需要的總時數。

一般軟體專案Scrum估計都可能會有錯，在Sprint過程中，要能實際反映團隊實際的「速率」，因此前1-3個Sprint的燃盡圖很重要，可以讓團隊知道實際的效率。所以每個Sprint都是固定時間，大約4-6週，sprint時間到就結束了，只會看做完哪些Story，在下一個Sprint才調整要完成的story數量。

然而，個人Scrum做法會略有不同。整體概念仍然一樣，但因為Product Owner也是「你自己」，因此Sprint時間可以變動。換言之，可能第一個Sprint是4週，第二個Sprint是5週。

請在極簡計畫書中，每個Sprint任務表格上方，填寫預計的Sprint開始的日期，和結束的日期。Scrum是要反應實際狀況，因此，也許整個sprint需要5小時，但因為你有本來的工作要做，因此可能要花2個月才能有5小時的空閒。

(3) 每日工作

當有超過30分鐘空閒的時候，就可以把那張極簡計畫書拿出來，在這個Sprint選一個任務(Task)開始「執行」，或者，繼續上次未完成的任務。這些Task都是大約設計成30-40分鐘完成，但是根據Scrum的精神，每個人的績效不同，因此也有可能會花的時間多或者少，但無論如何，在還沒完成已經做一半的任務之前，不要換任務！

當然，如果該日沒空，自然就不需要拿出極簡計劃書來執行。

每個任務，都有完成條件，確定滿足完成條件後就可以塗黑空格，並且在右邊簡單的紀錄所花費時間，和大約日期。時間不用太精確，以半小時為單位即可。有些任務很簡單短暫，也許10分鐘就完成，但也以半小時紀錄就好。

如果沒辦法在0.5小時內完成一個任務，那要請自己休息一下，再決定要繼續完成該任務，也可以決定今天就先到此為止。

不能有某任務做到一半，就「先拿了」下一個任務，也不能有這個Sprint還沒完成，就先開始做下個Sprint的某個任務。當然Sprint中的任務，有些是沒有前後關聯，因此Sprint中的任務不需要按順序。只是，一旦開始做，就一定要做完為止。

某些任務需要下載檔案，請參考註2的各個下載網址，可以一次下載完成。

在計畫書中的任務描述都很簡單清楚，但如果真有問題，也歡迎來信詢問

(3) Sprint 結束自我檢討和下個Sprint的開始

完成Sprint中所有任務之後，表示這個Sprint完成。要花15分鐘時間，先自我檢討一下Sprint過程中有哪些阻礙，而自己應該怎麼改善阻礙。

接下來就要開始下一個Sprint。實際上，本來Sprint的開始是需要先討論Story和Task的選擇。然而，極簡計畫書希望你不要花時間在研究這些Task重不重要，而是先努力的花時間搞定它。畢竟這些任務所需要的時間都不多，實務上也對你有莫大的幫助。

不過，或許有些任務你早就已經完成，那就可以看一下完成的條件(DoD)，已經達到就可以自動塗黑。

(4) 計畫書完成？專案結束了嗎？

三個Sprint完成之後，這個極簡計畫書就達到它的功能。但就個人專案的角度來說，專案不見得要結束。只是這時候你已經有足夠的能力和經驗，可以決定要不要繼續以Scrum的方式來學習Scrum。

(5) 3個Sprint結束後的彩蛋！

很簡單，當你完成這個極簡計畫書，實質上你自己完成了一個Personal Scrum。

彩蛋要靠自己完成。請在計畫書背面以三個Sprint的各任務所花的時間，「手工」繪製燃盡圖。

這件事的意義在於，你有確切證據證明你能有效運用Scrum在非工作事項上。也證明你有自我學習的能力。它可以用在未來履歷表，面試，或者說服同事Scrum不如想像中困難，只需要一點點毅力去執行。


在此下載計畫書

常見問題：

Q1：這個極簡計畫書，很多地方跟我在工作上用的Scrum都不一樣啊？

Ans：當然不一樣，因為他屬於Personal Scrum。但是它的最基本精神是一樣的。請參考這裡，了解Scrum哪些最基本精神比較重要。

Q2：我不就是自己的Product Owner？為什麼我一定要用這三個產出來達到「變成Scrum專家」。

Ans：你當然可以自我決定產出和任務，也有機會變成Scrum專家。極簡計畫書，是在如果你還沒有好的定義時，可以透過過去人的經驗，減少時間浪費，讓你專注在精進自己。

Q3：為什麼要取得Scrum認證，這樣就會變成專家嗎？

Ans：有些人可能會以「取得相關證照」，作為專家的標準。這的確是個參考標準，但也只是參考而已，因為Scrum並沒有所謂官方證照，所以市面上各種證照到底哪一個比較適合？請參考這篇「Scrum認證！不要再浪費錢了」。在此採用的是Scrum-Institute的低成本證照。

---

註1：即職場上的專門行業，指具備專業化知識及技能的職業人士。通常，專業技能須符合科學原理，經過長時間的學習及訓練，並有經專業認證的考試獲得的合格證書或執照，擁有自我約束行為的職業操守（或道德）及可量化的專業標準等。...定義細節請參考這裡。


註2：各種需要下載的資料

(a) 任務 1.4 的2個pdf教材
* https://www.scrumstudy.com/SBOK/SCRUMstudy-SBOK-Guide-2016.pdf
* https://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf

(b) 任務1.7的wiki頁
* https://zh.wikipedia.org/wiki/Scrum

(c) 任務2.1的pdf
* http://www.scrum-institute.org/Scrum_Books_International_Scrum_Institute.php

(d) 任務3.1與任務3.3的材料

* http://www.eduscrum.com/

* https://www.crisp.se/gratis-material-och-guider/scrum-checklist

如何學好工作英文 - 極簡計畫書

在台灣職場上，英文能力是工作能力重要的一環。英文能力不好，並非職業生涯就會失敗，也不是就不能賺很多錢，只是會「受到各種限制」。有正確足夠的英語文能力，會讓職業生涯有「更多選擇」。

除了在自己的職位上，有需要以英文讀寫和對跨國組織的溝通之外。還有兩件極為重要的
其是：

(I) 擴大其他知識學習的能力。當你可以順暢地閱讀聽取英文資訊時，你路上的知識來源，就遠比只會中文多了數倍。

(II) 擴大資源取得的範圍。當你可以流暢的使用英文，就可以把想做的事情，透過網際網路外包給其他國家。


就和其他計劃一樣，執行力永遠比計畫詳盡來得重要。而執行力是透過「限定時間」的「分階段」採用「正確方式」達成。


如果你目前還沒有自己的方法，或者，曾經試過自己的方法只是不太成功。那麼請考慮這個極簡一頁計畫書。

到此下載計畫書。

這個計畫乃是參考(註1)的做法，與實務驗證改善而來。此極簡計畫適用於TOEIC 695分以下的上班族。


「如何學好工作英文 - 極簡計畫書」的使用步驟如下：

(1) 找到原因，定義目標

第一個，也是最重要的步驟是「坦白原因，定義目標」

每個人真正想學好工作英文的原因都不同。而真正的原因才是讓個人努力的動力。

找到自己想學好工作英文的真正原因。可以用消滅法，判斷這個原因是不是最重要原因。在計畫書中，將最重要原因填在80%欄，次要和第三原因填在16%欄與4%欄。將80%欄遮起來，想像一下，當這個原因消失之後，自己是否就不想精進工作英文了。如果這個原因消失，但是自己還是很想精進工作英文，表示不是真正原因，或者描述的不正確。

請填寫找到真正原因填寫於左上角。

目標是在未來一段時間(14週)預計取得的成長。

極簡計畫有兩個既定目標：

(a) TOEIC 800以上 
(b) 能以英文簡報10分鐘關於現在的工作進展 

另外，可以去掉目標(b)，也可以自己制定目標(c)。但是，沒有特別原因的話，必須要留著TOEIC 800的目標。

在右下角的目標準備，就是為了確保自己已經報名TOEIC。

(2) 學習材料準備

極簡計畫學習教材都是不用錢，而且對工作英文來說效果很好！

「起床後15分鐘」的教材是BBC網站，需要電腦或者手機才能使用。

「空閒的10分鐘」教材是一本英文書。

(a) 聽/說教材

聽和說請用BBC網站教材。這些課程都是以影音方式大約3-7分鐘。
請先設定好書籤於瀏覽器中，或者用手機也可以。實際學習方式請看: (3) 執行 

BBC英文學習課程：有用！簡單！又不花錢！

BBC English You Need
http://www.bbc.co.uk/learningenglish/english/course/english-you-need

BBC English At Work
http://www.bbc.co.uk/learningenglish/english/features/english-at-work

(b) 空閒時間的純閱讀：How to Read a book。

建議直接列印出來。目標是看完第一，第二部分。約138頁，每天10分鐘閱讀一頁半左右。

(3) 時間分配

太長時間等於是挑戰自己的意志力，但是每天工作很累的人的意志力是有限的(註2)。

這個計畫是以3個月(14週)為目標時間，每週6天，每天僅25分鐘。這25分鐘，分成早上起床後15分鐘，和空閒10分鐘。

早上起床後15分鐘

早上一起床，要花15分鐘學習英文。如果你平常是9點起床，就改成8:45，如果是8點起床，就改成7:45，如果是7:30起床，就改成7:15。無論如何，一定是起床後的第一段15分鐘是在學習英文。早點起床學英文，絕對比晚點睡學英文的效果強太多太多！

空閒的10分鐘

在每天空閒的時候：坐捷運，上廁所，上班休息時間等等，花10分鐘閱讀。強烈不建議在睡覺前閱讀。這10分鐘最好是連續的10分鐘。

實際作法請看(3)執行。

在計畫書中央有個6x14的表格。在表格上有開始日期，下方有結束日期。直接填好開始日期以及14週之後的結束日期。

時間耗費其實很少，所以要確切執行，其實不會是時間問題，也大概不會是意志力問題。恐怕只是「習慣」與「執行技巧」的問題。

14周之後，無論如何，時間到就結束，並且以實際方式檢討結果。

(3) 執行！

當極簡計畫準備完成，接下來當然就是執行極簡學習計畫。
計畫執行非常非常簡單，所花費時間也非常非常少。

執行是每天，或者說每星期至少六天，做三件事情：
(a) 早上起床學習15分鐘以上
(b) 空閒時間閱讀10分鐘以上
(c) 把計畫書上的進度表格塗黑，並且自我檢查是不是有按照計畫進行

(a) 首先是起早學習15分鐘

所要做的事情是到BBC網站上，在BBC English You Need或者BBC English At Work選擇一個課程來「聽」。只聽不看，有聽不懂的暫時不理會。BBC的課程很短，大約5分鐘而已，聽完之後，在看上面的英文說明，還有不懂再查字典。

經過3-4天，如果你認為太簡單，BBC也有進階教材：

http://www.bbc.co.uk/learningenglish/english/course/towards-advanced

但是對於簡單的教材必須熟悉到「輕而易舉的理解」，才能進展到進階教材。而坦白說，倘若你的TOEIC成績不到850分，進階教材可能不太適用。

(c) 其次是每天空閒閱讀10分鐘：

找空閒10分鐘閱讀

教材是How to read a book。閱讀方法是印出來，在每天空閒的時候：坐捷運，上廁所，上班休息時間...等等，任何空閒的10分鐘都行，連續10分鐘閱讀。強烈不建議在睡覺前閱讀。


閱讀方式是，直接看完，中間看不懂的字先圈起來，如果可以的話，猜測一下不懂的字的意思。讀完一個段落，約1.5頁，閉起眼睛回想一下這一頁的意思，然後，再去查字典。切勿背單字，應該去了解整個句子的意義。

How to read a book是本經過設計的老教科書，用到的單字有限，其目的是在教學生「如何閱讀英文書」所以，當你看完這本書就可以一舉兩得，確保可以你的英文閱讀能力，真正往前進。

(d) 每天檢討：把計畫書上的進度表格塗黑，並且自我檢查是不是有按照計畫進行。

這個部分最重要的是，不要欺騙自己。請參考下一段(4)過程檢討。

(4) 過程檢討

極簡計畫書中央有個6x14的表格表格。每個格子代表一天，每天當你完成「早上起床15分鐘」和「空閒10分鐘」的學習之後，就可以把它塗黑。只完成一項就塗一半，都沒做就留空。

必須要把這個計畫放在每天都一定會看到的地方，例如辦公桌的某個小角落。表格上面只有開始日期跟結束日期，中間並沒有日期，但請不要趕進度，每天最多也塗黑一格！

如果有不預期的情況發生：例如連續兩天沒有按照進度進行。不要試著去彌補它！不要在某一天連續趕兩三天的進度，而是要找到一個方式，讓這不預期的事情，「以後」不要再發生。不彌補是因為過去的事情本就「已經過去」，和彌補錯誤比較起來，在極簡計畫中，更重要的事不讓錯誤再發生！

(5) 計畫結束

極簡計畫的概念是，無論如何，結束時間一到，計畫就結束了。

這時候必須要知道和原定目標有多少差距，如果TOEIC考了815就表示達成，考了790就表示沒達成。如果可以輕鬆地用英文解釋現在的工作狀態，就表示達成了。

然而，因為是你自己自定的目標，其實在計畫結束後，可以很清楚的看到過去14週以來的成果，即便沒有達到目標，應該會有大幅進展。也不見得要對自己太嚴厲。

重點在於結束之後，可以再次啟動下一階段的工作英文學習計畫。把握原來的極簡計畫的關鍵：限制時間，清楚目標，過程執行，檢討結果，並且不要花太多時間，當然就可以讓自己的下一次計畫效果更好。

到此下載計畫書

問題與解答：

Q1：可否修改計畫書？

Ans：極小幅度更動當然可以，例如把14週變成12週或者15週，把每天25分鐘改成30分鐘。但強烈不建議進行大幅更動。因為此計畫是經過設計與驗證，對絕大部分上班族是最能在耗費最短達到最大的工作英文進步。

Q2：我沒辦法早起學英文。

Ans：無論你現在做的是什麼樣的艱難工作，早起15分鐘通常是可接受的範圍。如果你沒辦法早起學英文，大概就表示你不太想或者不需要精進工作英文。

Q3：這計畫對我來說太簡單？

Ans：此計劃是用於大學研究所畢業後開始工作2-3年的上班族。如果你英文已經很好了(例如，TOEIC已經850分以上）當然就不適用此計畫。

Q4：此計畫對我來說太難？

Ans：如果你已經大學或研究所畢業，然而仍然覺得很難使用英文聽說讀寫，這計畫可能是有點難，但絕對不是做不到，只看你有沒有決心而已。

Q5：為什麼一定要去考TOEIC？

Ans：TOEIC是目前為止，比較有公信力的商用英文測驗，它並不困難，很適合「不準備」的情況下完全按照實力去應考。當然應考前還是要看一下題型，考試方式，跟考試用具。

---

參考：

* 註1：在義務教育的語言學習，大部分的人都認為沒效率而且也不實用，不僅只是台灣而已，而是放眼世界皆然。有本書可以參考一下: Fluent in 3 Months。這本書有中文版。

* 註2：意志力的研究有很多矛盾的地方，請參考這裡。

工作3年後 - 如何主動換個好工作

工作3年後 - 如何主動換個好工作

畢業開始工作2到3年後，是個轉捩點。許多專業工作者(例如工程師)都在剛畢業後2-3年就會主動考慮換工作。

要隨便換個工作不難，但是要換個「好工作」其實非常非常難。

最踏實的作法是對「換好工作」這件事情有具體的目標和可行的作法。雖然這和每個人的職業和背景的不同，而有差距，不過計畫的步驟其實差不多。

想要跳過說明，可在此取得「TS 換個好工作 計劃表」。

有很多原因，會讓工作2-3年的人想主動換工作(註1)，以下是幾個常見原因：

(一) 未來發展：覺得現在組織沒辦法讓自己升遷，增加責任範圍，學不到技術等等。

(二) 生活品質：薪水不夠，加薪幅度不夠，工作時間過長等等。

(三) 組織狀況：大組織內政治因素過大，小公司極端不穩定，產業外移等等。

(四) 興趣：現在工作內容沒有興趣，感到厭倦無聊，或者發掘自己的興趣在一個截然不同的產業等等。

(五) 想創業：這不在本文討論範圍之內。(註2)


除了以上原因之外，「最爛情況」也可能是換工作的原因。所謂最爛的情況，是指「非理性行為」：年輕人畢竟容易血氣方剛，容易產生各種憤怒：「對微妙小事看不順眼而憤怒」，「因為覺得老闆好爛而憤怒」「覺得不被重視而憤怒」，甚至，「我的老闆沒被大老闆重視」也可能是原因。

但其實，企業組織只要沒有違反法律，這些爛原因，絕大多數都是無聊而且不必要的。因此也不在討論的範圍之內(註3)

要找工作很容易，要找到好工作很難

再次強調，換工作很簡單，但是要換到好工作很難。對於困難的事情必須要有計畫的完成它。

計畫如下：

(1) 了解自我原因

了解自己為什麼想主動換工作的原因，是最基本，但是卻最容易被自我扭曲誤解的第一步。

有個簡單的方式可以讓自己對自己「誠實一點」：將自己為什麼要換工作的三個最主要原因，依優先順序寫下來。根據80/20法則，第一個原因約佔80%，第二個原因是16%，第三個原因最多是4%。舉例如下：

80%：因為學不到新技術
16%：因為加薪幅度不到10%
4%：覺得厭倦無聊

先把80%的原因遮起來，模擬假設解決了80%的原因，只剩下另外兩個原因，還很想主動換工作嗎？如果不太想換了，才表示你誠實的面對了自己。如果還很想換，就表示那80%的原因根本不是主要原因，請換個主要原因再試一次。這步驟是要迫使自己誠實面對自己，了解自己真正想換工作的原因。當然，想要換工作的原因可能更複雜，但一定要先認知問題的存在。

因為「解決問題的第一步是認知問題的存在」。而如果不先了解自己真正想換工作的原因，那就很難了解自己認為「好工作」的定義。

當然在這個時候，很有可能會覺得不想換工作，或者想創業為自己工作，那也很好，重點在於找到自己心裡真正的原因。

(2) 足夠計劃實施時間

在台灣，知識類型的工作者，最好要有3到5個月的準備時間。以下的計畫就是以3個月的準備時間為準。

3個月看起來是個冗長的時間，但如果你只有2-3年工作經驗，只準備了3個月就換到適合自己的好工作，其實是極端快速的。要達到極端快速，需要妥善計劃。

如同精實創業和敏捷開發的「時間控制」原則，這3-5個月時間是固定的，如果期限內沒達到效果，應該重新檢討，重頭開始。

(3) 定義目標

當準備換工作，目標必須是要換個好工作。而定義「好工作」就顯得很重要。每個人的好工作定義都不同，但該目標必須要「解決當初最重要的換工作原因」。

目標的需求描述，可以是4至8個項目。描述的內容要和換工作的三大原因有所關連，但不見得要一比一對應。也可以加入額外條件，像是地點之類。最後，描述的目標一定要有幾個「參考公司名稱」，因為畢竟換工作，最終還是換到某個公司，目標公司並非表示你非他不可，而是有個顯著的參考值。

例如：

 * 要學到比較完整的軟體開發流程
 * 透過轉職加薪，要比現在多15%
 * 工作內容聽起來要有趣
 * 工作地點在大台北地區
 * 加班頻率不高
 * 有國外出差的機會
 * 目標公司：四零四科技，趨勢科技，LINE台灣

(4) 瞭解與目標的距離

了解與目標的差距，最簡單的做法就是「馬上去面試一次看看」。但這樣做是有點風險，因為許多外商，通常在拒絕應徵者之後，可能3-6個月都不太會讓這個應徵者再來面試一次。

其次，花半天的時間，上網搜尋相關資料，特別是在104, linkedin上的公開資訊。可以看出這些公司最近需要的人才的技術能力為何。通常比較大公司很容易找得到「面試經驗談」可作為參考：要記得只是參考而已。

另外，也可以透過linkedin找到該公司的HR或者主管，虛心請教哪些技術能力及程度，是必備條件。有兩點要稍微注意的是：(I) 目標應該放在知識與技術能力，暫時先不要考慮「軟技能」像是人際關係之類的。(II) 英語能力是屬於技術能力的一種，並非軟技能

列出此時此刻，自己和目標最大的3-5項差距：

 * 對比較嚴謹的開發流程沒經驗
 * 對Linux不熟悉
 * 英文溝通能力不太好
 * 線上程式測驗比較難 
 * 沒有大數據相關工作經驗


注意！如果在這個階段，你認為沒有差距了，就勇敢地去面試。一旦被綠取，那麼你也已經達到計畫的目的。然而，要是沒被錄取，就表示「實際上」的確有差距，必須要回憶面試過程，找到其中差距，然後用下一段(5)行動，來補足差距。

Action speaks louder than words

(5) 行動

計畫最重要的部分就是行動，沒有行動的計畫是死的。不過，好計畫也是行動的關鍵。不知道怎麼行動比較好？可在此免費取得通用版本的「TS 換個好工作 計劃表」作為參考。

換個好工作的主要行動有五項：

(A) 急速提升目前工作績效

快速且大幅提升目前工作的產出效率和在組織內評價，是縮短與好工作距離的「最佳做法」。絕大部分的用人主管與人資主管，判斷應徵者的未來潛力，是透過他「過去工作績效」。

換言之，要換個好工作，關鍵成功因素是把現在的工作做到最好！而且是「以別人的角度」認為你做得最好，而非從自己的角度。

實際做法是：

首先，列出三項在1-2個月內可以達到的「額外」工作目標。並確定達到之後，現在的主管「鐵定」會非常滿意。可以主動和現在主管確認，這些額外的目標確實有很大意義。當然在這個時刻，不需要跟他說你有換工作的打算。

接下來，用盡「所有能力」，去達成這些目標。所有能力包含以下各種可能：

 * 厚著臉皮請教同事應該怎麼做比較快
 * 快速學習新技能以達成目標 (參考下一段)
 * 在做的過程中虛心向老闆求教
 * 每天提早40分鐘抵達辦公室做這三項額外目標
 * 用80/20法則，找到目標的關鍵任務先行完成

絕大部分的人，無論是什麼樣的工作，都能透過這個方式，在1-2個月內，展示出「大幅提升績效」的結果。並且是會獲得「外界肯定」，而非自我感覺良好，自覺大幅提升。

(B) 急速學習技能 

在瞭解與目標差距中，已經列出數個技術差距，而每個技術差距，都應該可以用學習技能來補足。

快速學習的本身，也有一定技術可依循，請參考這篇：快速學習解決職場困境。

每個技術差距該做的事情都不一樣。不管列出幾項差距，最好是「一項一項」逐一解決，盡可能不要同時解決。考慮現實，3-5個月最多也只能增加3個技能。而每個要解決的技能，必須有極為明確的目標。這也是極速學習的關鍵：清楚定義目標，在大目標下逐一達成每個小目標。例如：

 * 對Linux不熟悉：熟悉LPI-201, LPI-202，通過線上測驗。
 * 英文溝通能力不太好：考TOEIC目標成績850
 * 線上程式測驗比較難：每天花10分鐘，到Leetcode或topcoder上找中難度的題目練習

(C) 急速打造通路

通路(Channel)是在商務上，將產品送至客戶面前的方式。

對於知識工作者來說，「你自己」就是產品。而企業組織，就是客戶，企業組織雇用員工也是一個「市場」，而市場，常常是被通路所控制。既然你是產品，就應該要妥善處理你的通路，而非讓客戶來決定通路。

最基本的通路，可能也是最差的，是所謂求職網站104, 1111之類，當然，有3年工作經驗，也可以用求職網站。但它恐怕不是最好的方式。

另一種通路是linkedin，和求職網站稍有不同，linkedin需要更大的主動性去維護 履歷表。

再者是獵人頭公司(headhunter)，大部分的情況下，獵人頭公司對3年工作經驗者不會有興趣，當你只有三年工作經驗，獵人頭可能只會對你的聯絡方式有興趣，等你「長大一點」再跟你聯繫還不遲。然而，有些做法可以讓獵人頭提早對你有興趣。其中一個做法就是透過業界導師推薦。

最佳的通路是「內部推薦」。如果剛好有認識的同學朋友在該公司內部，那你的運氣就實在太好。但是如果沒有任何認識的人？創造認識的人就是最好的方式。

如何創造認識的人？透過linkedin或者其他社群網站了解內部員工都參加哪些活動，或者研討會。主動參加那些活動和研討會，就會自動認識內部的人。稍微熟悉一點之後，就可以厚著臉皮懇求幫忙送履歷表。幫忙送履歷通常不是問題，問題在於「是否真心推薦」才是重點。技術類型的工作，參與相關的研討會，參與比賽，參與開源開發專案等等，絕對是能獲得真心推薦的方式。

(D) 應徵/面試

當準備到一個程度的時候，就應該去應徵面試。何謂「到一個程度」，只要你按照原定計畫，2-3的月就一定會到某個程度。你就應該「驗收」努力的成果，而非覺得「不夠完美」所以想持續學習。

不夠完美是一定的，因為人不可能完美。持續學習也是一定的，因為學無止盡，但時間是會流失的，這也是為什麼一開始需要鎖定一段時間，無論好與壞，每一段時間一定要能驗收檢討成果。

應徵和面試的技巧，網路上各企業巫醫專家實在太多，就在此省略。

(E) 檢查是否朝向目標

要給自己固定一小段時間，檢查自己所作所為是否朝著計畫前進。最好是定在每週一上午9:00~9:15 (這時間有特殊意義存在，盡量不要改變它) 

要檢查三件事情：

 * 過去一週的行動，有沒有確實提升工作績效
 * 過去一週的行動，有沒有縮短與目標距離
 * 有沒有浪費時間在其他地方

(6) 最終結果與選擇

如果在時間內，確實被錄取「目標好工作」。那麼就應該作出選擇，決定要不要去。因為也許3個月後，由於你的工作績效大幅提升，原本一定要換工作的原因已經不存在，當然就可以選擇要不要換。

如果在時間內，並沒有被錄取「目標好工作」。那麼就應該從第一步開始，檢討哪邊出了問題。並且重新再做一次3個月計畫，然後，確實再實施計畫。即便第一次計畫失敗，也會讓下一次計劃成功。

＊＊＊＊＊＊＊

每個人都有適合自己的方式。但如果你沒有好方式來換個更好的工作，參考並實行這個計畫一定能獲得好結果。


＊＊＊＊＊＊＊

---

註1：也有一些種情況是被動或者被迫換工作。 最糟糕的情況是因為績效不佳而遭到資遣，其他情況像是：公司倒閉，公司裁員，組織重整，健康因素，家庭因素等等。被動換工作的通常是「措手不及」的，因此要採取略微不同的方式。請參考這裡。

註2：工作了2-3年，應該可以知道，創業和換工作截然不同。創業的成功關鍵請參考這裡。

註3：不過，人類有各種認知偏誤，合理化既定決定，無論決定合不合理，都有可能被自己合理化。

快速學習技能 - 解決職場困境

快速學習工作上需要的技能，而技能與知識同時成長，是在職場上能空出時間，進而控制時間的最好方式。

在這世界裡，「在N小時內學會XXX」的書籍研討會不在少數。這些都很有參考價值，然而，學習是非常「個人化」的事情。例如：國高中花很多時間在補習班的學生不在少數，但真能夠發揮補習的目的 - 也就是考上最好的學校 - 卻僅有少數。

有些書籍，宣稱找到共通的方式可以在N小時內，學習「任何」技能。並且當然以自己過去一年學習到的技能，作為鐵 證 (參考文末的註1)。不過，共通的方法都僅能參考，每個人終究都還是需要找到自己的方式 - 只要是真的想學。

在職場工作，會遇到的困境很多，有很大一部分是「人」的問題。但無論哪種問題，如果你是個「技術上的狠角色」，你就有很大的機會撇除人的問題。即使無法排除，擁有更多技能，就表示有更多選擇 - 大不了就是離開現在的環境。

技能的快速學習，首要之務，應該是找到自己的方法。

在還沒找到之前，或者，自己現有的方法似乎有所侷限。倒是可以考慮以低成本的方式，嘗試一下各個企業巫醫所提供的方式。

重點在於：有方法遠比沒方法好！

以下是幾個常見共通步驟與確切花費時間：

(1) 原因與目標確立

不知為何而戰，當然容易半途而廢。

有些原因很清楚，例如：目前會寫java，而現在因為工作需要學習Scala。有些是個人喜好，例如：常喜歡去日本旅行，想學基本對話比較方便。有些則是好奇性質，例如：聽說Big Data大數據分析很紅？不知道到底是那是什麼。有些技術是「執照類型」：例如開怪手，駕駛遊艇。

無論是哪種原因，需要一個簡單的目標，例如：學會Scala，了解Big Data，學會日文會話，學開船等等

不應該花太多時間在目標確立，最多0.5小時。

(2) 階段性成果確立

長期預測是很難，而且接近不可能。因此，快速而踏實的方式是計畫階段性成果。

階段性成果指的是一個「可以衡量的」，「有意義的」，「可展現的」，「務實的」極短期目標。

所謂極短期，是指20小時之內：也就是禮拜一到禮拜五，每天2小時，連續兩週。

這並不是指，超過20小時就是太多，也非20小時就能夠變成專家。而是必須要讓自己在20小時內「有所成果」。

舉一些例子如下：

Scala：撰寫網路爬蟲程式，可針對wiki做特定字串資料檢索和統計。

日文會話：用日文會話辦理飯店check-in，詢問餐廳資訊和找路。

Big Data大數據：選擇並且看完三本大數據的科普書籍。

學開船：考取動力小船執照。


階段性成果的確立，其實和每個人對該技能瞭解程度的不同而有所有不同。了解的越淺，就會訂出越模糊的階段性成果。但其實無妨。因為這只是第一階段的成果而已。

其實，要能確立階段性成果，某種程度已經完成一個小型計畫。計劃本身是死的，「做計劃」這件事情才是重點。這個階段應該花費3-4小時的時間。

(3) 找到練習與取得知識的方式

取得知識和練習的方式非常重要。這方式必須要同時符合「階段性成果」和「目標」。

要快速學習知識和技能，必須「專心花一點時間」得先找確切練習方式，取得知識材料，和額外獲得協助的地方。

取得知識最踏實而且快速的方式，其實還是圖書館。先考慮，或者試用一下圖書館堆書法(參考這裡)。

然而，許多技能是需要練習的。例如：寫程式，學日文，Linux操作等等，就需要找到最適合自己的練習方式。

以學會寫Scala程式而言：即便只是做個簡單的網路爬蟲，仍要再細分小階段，先準備環境，簡單了解語法，知道怎麼使用Scala來執行http get...等等。每個練習的動作，都是為了達到階段目標。

以學日文會話而言：最好而且便宜的方式應該是「馬上去找」語言交換。其次則是去借幾本基本會話的書，再加上幾個app/網站。(註2)

當然，有些技能最簡要的方式，還是花錢受訓，例如「動力小船駕駛」。這反倒是最簡單的，只要有決心即可。

除了花錢受訓之外，這階段恐怕需要額外的時間，預計6小時是合理的。


步驟(1)到(3)，最好是不要花超過8小時，也就是一個假日的時間。

(4) 練習與取得知識

這一階段的重點在於「專注」。如果計畫是兩個星期，共計20小時，則這時候，就該專注於自己決定的方式，無論如何，都要在兩星期/20小時之後來檢視成果。

這也是為什麼，設定階段性成果時間不能太長(註3)。

如果的目標過於抽象，例如要「瞭解什麼是Big Data」，在這段練習與取得知識的過程，就會變得更加含糊不清。以因此，階段性目標才會設定成「看完三本科普書籍」，這樣才能檢視成果。

要讓自己專注的方式有很多：短時間專注可用番茄工作法。長時間則需要計畫與經驗，而目前你在看的這篇文章，實務上就是在解釋，如何將學習技能知識時間專注於學習。

在這個階段，根據計畫的不同有不同的時間。但是切記「越短越好」。如果不確定時間長短，那就以10個小時，每天2小時為準。

(5) 自我評量

必須要有客觀方式自我評量。

因為是自我評量，當然一定要確實。

以學習Scale的第一階段：完成網路爬蟲為例，如果在20小時內完成，那麼就可以有信心的說學習Scale已經前進很多。

以學習日文會話來說：如果可以和日本人測試對談飯店用語，那就表示階段性成功。

再次強調：快速學習技能的階段性成果，必須要以務實為主。許多人在學日文一開始是以背熟50音為第一階段。但這其實不太務實。因為死背永遠是無聊的，而且即便你可以把50因背得滾瓜爛熟，在日文能力 - 特別是會話 - 的務實進展也等於零。

(6) 收成：前進或者換目標

達到目標後，請隨意犒賞自己。

而接下來，就是要決定往下一個階段前進，或者更換目標。

這時候的更換目標，並不是半途而廢，畢竟你已經前進了一段務實的路。這和達不到目的而放棄，無論在心態上，還是事實上都有很大的不同。

往前進的時候，記得也是重複設定一個「短期可達到」的務實目標。

例如：

學習scala，已經完成網路爬蟲程式，接下來的目標是在Spark中，以scala撰寫一個可分析http log的分散式程式。

瞭解Big Data大數據：已經看了三本書，接下來的目標是找一個有意義的主題，寫一篇部落格文章。

這樣的快速學習，真的能解決困境嗎？

快速學習能讓你在職場上，取得更多的「選擇性」，讓你對事物有所掌控。這才是針對困境的真正解決之道。

或者也可以跟我們聯繫取得困境的快速協助。

---

註1: 有幾個例子

   * Fluent in 3 Months: 三個月內可以流利的學會任何語言。作者甚至示範了中文學習，對外國人來說，學非拼音文字真的難為了他們。

   * The First 20 Hours: How to Learn Anything FAST. 作者示範了如何快速學會各類不一樣的技能：瑜伽，寫程式，風帆板，圍棋...但個人覺得比較難以置信的還是「新鍵盤佈置：colemak 」

   * The 4-hours 系列：作者Tim Ferriss寫的幾本書。內容從健身到創業都有，其中都會涵蓋快速學習的方式。

註2: 請參考Fluent in 3 Months 一書

註3: 當然如果你是想考動力小船執照，由於上課時間是固定，當然沒辦法「更快」。

不玩一樣的遊戲 - 準備面試的真正技術

程式設計師如何在面試中展現真正價值：最好的方式當然是不要跟其他人玩一樣的遊戲，也就是在面試中，找出幾個能突顯自己技術能力的要點。針對這些要點，做延伸性的準備。

不管什麼原因，當一個軟體工程師下定決心要換工作時(註1 )，面試通常是免不了的。

作為軟體工程師，鐵定會上網搜尋各種「面試技巧」文章。

例如：常見面試問題的最佳回答：這篇或者這篇。也有些人會說，面試除了回答問題，更重要的還是會問對問題，例如這篇。

但是，人資與主管，通常比面試者更知道這些所謂「標準問題」。也很清楚面試者可能會去找的「標準答案」。這些面試技巧文章只是一再重複大家都知道的常識，多複習這些常識是有很大的好處，至少可以避免緊張或者不必要的誤解。

但常識不會是關鍵。


在面試的時候，除了回答標準問題之外，最重要的是「確實展示自己的價值」才是關鍵。

軟體工程師/程式設計師的價值展現，其實第一時間點是在「看履歷表」的時候。短暫的面試時間是在「檢查履歷的正確性」。假設面試者的履歷寫的中規中矩，沒有什麼誇大，也沒有過度謙虛(註2)，會讓你進入面試階段，就表示在履歷表上展示的技術能力是公司願意接受的。

面試展示自己的價值，通常是在幾個關鍵點。而這些關鍵點，都是「面試之前」可以先做好準備的。

(1) 應答技術問題
(2) 解釋過去做的事跡
(3) 詢問技術相關的問題

(1)  應答技術問題

大部份的軟體工程師工作，通常都會有程式考試題目。只要你在Leetcode, topcoder之類的網站，用你本來就熟悉的程式語言，多練習幾次，應該就不會太離譜。事實上，技術問題不可能考得過於艱澀 - 因為公司組織通常沒這麼多閒功夫在一個面試者身上。

其他的技術問題應該要根據你在履歷表上的專長做「延伸性」的準備。延伸性準備，才是展現價值的最好方式。

例如，倘若履歷表上你的專長是WebUI，那麼你就得延伸準備到HTTP：至少了解一些重要的header。如果你的專長上有寫Linux，那麼就必須準備回答曾經使用linux做過什麼事情？

如果曾經在linux上架設web server (nginx, apache...)，至少也得知道設定檔在哪裡，如何開始停止服務，如何列出執行的行程(process)，如何在不得已的時候強迫結束服務。當然，如果你會回答kill -9，最好確實知道為什麼是-9。

應答技術問題的不僅只是「防禦性」告訴面試者你的能力。而透過簡要地回答，「順便」展示自己對技術能力掌握的額外價值。就以上述kill -9為例，以筆者過去15年，面試超過400個人經驗，在履歷表上寫「熟linux」的起碼也有150人。這些面試者，八成都知道kill指令。然而，僅有不到10個人，知道為什麼要用kill -9，並能說明kill預設single 15是比較好的選擇。

在回答簡要技術問題，只要能有正確延伸性的回答，就能展現與他人不同的價值。而這絕對事是先可以準備的。

(2) 解釋過去做的事蹟

只要有2-3年工作經驗，面試時，一定會被詢問過去做了什麼。

因為，要了解未來一個人在組織的貢獻，最好的方式是看他「過去貢獻了什麼」。以下是一些解釋過去事蹟的要點。

＊＊ 妥善呈現事實而非感受。

當你已經離職時，過去的事蹟就已經成為「歷史」，而你可以準備的是「妥善呈現歷史的事實」，切勿扭曲或用「感受」呈現。

例如：「在那個專案裡面，幾乎事情都是我在做」。這其實是你的個人感受而非事實。事實必須要用無可扭曲的方式呈現。

又例如：「這個專案扣除html/css之外，前端javascript在git上大約有3萬行左右，其中兩萬五千行是我commit而且到專案結束也都是我負責維護」。這只是說明在程式碼上的「事實」，你並沒有貶低別人的貢獻，因為也許那其他5千行極端重要也說不定，但你也呈現了以code base而言，你的貢獻在事實上絕對不低。

＊＊過去事蹟，絕對可以，而且也絕對需要在面試前妥善準備。

因為，你對過去自己真實貢獻越了解，就越能掌握過去事實。越能掌握過去的事實，就越能表示自己在技術上更有未來潛力。

例如，假設你是IT部門員工，過去都是協助內部系統上線，這些系統其實也是外包商提供。在面試時，被詢問做的內容，如果只是簡短回答「將公司委外開發的系統上線」當然也是可以。

但如果你在事實上，也會做「自動化檢測系統」「建構上線風險評估」「上線後的使用分析」「成本分析」以及「有沒有達到預期目的評估」，這些才是IT真正產生價值，並且與眾不同的地方。

最好的情況會是，公司之前並沒有此做法，而是你主動完成這些有價值的事，讓公司變得更好。可是，如果你已經離職，來不及產生事實 (當然也不可能去捏造說謊)。那麼，至少還是可以說「當時其實應做自動化檢測系統」，雖然那時候沒有完成，但你也可以在面試前自己做一個小規模的自動化檢測系統，而在面試的時候就可以大大方方的說，當時雖然沒做，但是自己覺得應該要做，所以主動在事後做了。

當然這表示你需要在面試前付出時間準備。這樣的付出不會是沒有代價的。即便這次面試沒用到，你所做的事情是不會消失不見，只要是你做的「技術上正確」的事情，未來一定會對你的職業生涯有所助益。

(3) 詢問確實的問題

通常面試的最後，都會給面試者問問題的機會。

許多文章中，的確會說明問問題的重要，例如這篇。有上網查過的面試者，也了解不該問一些瑣碎小事，上下班時間，或者公司基本福利，因為這些問題只是等於打發時間。雖然沒有害處，但是也沒有價值。

軟體工程師最適合的就是詢問有價值的技術相關問題(註3) 。而這些問題也可以讓你稍微判斷此公司的狀況。

基本問題

一些很基本的問題，可以簡單展示你對軟體專案成熟度，也可以讓你了解這個公司的狀況：

* 請問目前是用什麼樣的版本控制系統，管理程式碼？

    該組織用什麼樣的版本控制系統不重要，無論是git, svn, cvs, p4...都可以。重點在於，的確還有些組織連版本控制系統都沒有。

* 請問目前組織是使用哪種專案管理方式？

    最近幾年是流行Agile/Scrum，

* 假如我有幸錄取，前三個月你希望我能完成哪些事情？

    這個問題代表自己的積極程度。主官如果對這個問題講得過於籠統抽象，很有可能該面試官(主管)並非實際的技術管理者。

* 團隊最近一次做code review是什麼時候？
* 團隊的bug追蹤流程目前大概是怎麼做的？
* 目前自動化測試的涵蓋率大約是多少？

    這些問題是展現自己對軟體開發的成熟度。特別注意的是，如果這些問題被籠統的回答，也不需要追根究底找別人麻煩。


進階問題

可能會引發進一步討論，也可能被反問，所以要事先準備被反問時的技術回答。

例如：

* 就現在的資料和面試的情況，您個人覺得會錄取我嗎？

* 最近一次在團隊裡面遇到最大的技術困難是什麼？

* 組織如何判斷成員的技術產出？

高級問題，

很有可能被認為是反過來刁難面試主管的問題。必須斟酌採用。例如： 

* 目前軟體專案程式碼的entropy有多高？

* 目前自動化建構和測試是採用哪些工具，涵蓋率有多高？

* 就您個人而言，最近在組織內學到新的技術是什麼樣的技術？新的程式語言或者新的工具？

面試是可以事先作準備地，軟體工程師的面試準備，應該花時間以事實展現價值作為準備方向，而非準備一些大家都知道的常識或者花時間準備外在行頭口語表達...等等。當成功地完成許多面試，就可以在工作機會上有所「選擇」。

---

參考文章：
(1) Scrum認證！不要再浪費你的時間了
(2) 如何充實自己
(3) 畢業前六個月 建構職業生涯
(4) 年底才績效評估或考慮轉職 已經太遲了
(5) 因為沒挑戰想轉換跑道，先檢討自己吧

---

註1：要轉職換工作區分成「主動」與「不得已」兩種。不得已：例如公司倒閉之類，當然就不用討論。但是如果是「主動」，就要先想清楚「真正的原因」。因為這個原因，可能不會因為你換工作而消失。

註2：剛畢業的學生可能是怕履歷表太空洞，通常都有誇大的傾向。而在業界打滾數十年的老鳥，有時候會有過度謙虛的可能。

註3：當然不應該「窺探機密」，因此可以在一開始的時候先說「如果這個問題不小心牽涉到公司機密，請告訴我，在這個時間點我無意探究貴公司的機密」

快速且極低成本之AWS臉孔比對 - 利用AWS Lambda

AWS在2016年底釋出的圖片辨識服務(Rekognition)其實是非常非常昂貴。除了前5000次影像辨識不收費之外，接下來每一千次影像處理會收1美金。

乍看之下不多，但實務上，公開使用的影像辨識，通常無意中就暴增。

以之前LINE聊天機器人影像辨識為例，由於會當辨識到女性的照片時，會特別額外辨識內建的臉孔比對(40個亞洲女星照片)。等於是每收到一個女性照片，會進行42次臉孔辨識：40次照片比對+1次特徵比對+一次名人資料庫比對。就LINE聊天機器人數百的好友而言，該功能開放不到7天，就已經超過四萬次比對，換算價格約35美金。

35美金其實足以開啟維持t2.medium (EC2 VM)一整個月。這個VM甚至還有4G的記憶體。這樣的VM絕對能支撐每秒2-5次的臉孔比對，換言之，一整個月可以比對超過7百萬次。而這7百萬次也才略高於35美金。

然而，不應該因為成本的增加，就直接使用EC2 VM。而是應該考慮在符合serverless的架構下，如何解決這個問題。畢竟，當使用了VM，未來在擴增(scale-out)上也會有些麻煩。其實，我們目的很簡單清楚：只是要比對兩張臉孔的相似度。因此，應該使用輕量化Lambda即可。

原本做法

當使用者透過LINE上傳照片給聊天機器人之後，後端系統會執行下列事情：

(1) 先利用AWS Rekognition (detect)查詢基本臉孔資料，例如性別，年紀等等。

(2) 假如判斷是女性，就到AWS S3上選取所有要比對的臉孔，進行比對分析。在這裡，如果有40張臉孔，表示每一次上傳圖片，都要在這個階段額外送出40次分析。即便AWS允許先行儲存圖片特徵，但在比對階段仍然是看次數。

參考程式節錄如下：

    
    rclient = boto3.client('rekognition')
    s3 = boto3.resource('s3')
    bucket = s3.Bucket('sandyifamousface')

    for o in bucket.objects.all():

        #print(o.key)
        response = rclient.compare_faces(
            SourceImage={
                'Bytes': byteArray
        },
            TargetImage={
        
                'S3Object': {
                'Bucket': 'sandyifamousface',
                'Name': o.key,
            }
        },
            SimilarityThreshold = 60
        )
        if len(response['FaceMatches'] ) > 0:
            # DO things if match..

(3) 最後把判斷之後的結果，送回給LINE

改良做法

先將40張圖做臉孔分析，並且把特徵值Landmarks挑出來，儲存在檔案中。未來數量大的話當然可以存在dynamodb。

在這個範例是儲存於json文字檔中。

(1) 與上一段相同

(2) 在Lambda被載入 時，就先讀取文字檔，成為python的dictionary。原本要利用Rekognition做比對，改為使用自己寫的比對函數。在範例中，這個函數是利用landmark的相對距離變化，來判對臉孔相似與否。當然這樣的比對其實很粗糙，而且也沒有考慮臉孔的前側傾角度。不過，和aws本身所附帶的臉孔比對的結果其實已經很接近。

參考程式節錄如下：

def compareLandMark(landmarkList1, landmarkList2):
    distList = []
    compareList = [
                   ('eyeRight','nose') ,
                   ('eyeLeft','nose'),
                   ('mouthLeft','nose'),
                   ('mouthRight','nose'),
                   ('mouthUp','mouthDown'),
                   ('mouthLeft','mouthDown'),
                   ('mouthRight','mouthDown'),
                   ('noseRight','eyeRight'),
                   ('leftPupil','rightPupil'),
                   ('nose','rightPupil'),
                   ('leftPupil','nose'),
                   ('noseRight','noseLeft'),
                   ('eyeRight','eyeLeft') ,
                   ('mouthRight','mouthLeft') ,
                   ('mouthRight','eyeRight') ,
                   ('mouthLeft','eyeRight') ,
                   ('mouthRight','eyeLeft') ,
                  ]

    for (m1,m2) in compareList:
        d1 = getDistanceFromType(landmarkList1, m1, m2)
        d2 = getDistanceFromType(landmarkList2, m1, m2)
        distance = (abs(d1-d2)/d1)
        distList.append(distance)


    lenD = len(distList)
    mD = statistics.mean(distList)
    # stdev and variance could be used in the future.
    mStd = statistics.stdev(distList)
    mV = statistics.variance(distList)
    conf = (1-mD)**2
    return conf*100

(3) 最後把判斷之後的結果，送回給LINE

結果：

在Lambda自行撰寫比對程式，但是其實是利用AWS Rekognition 所給出的landmark (特徵)，會讓比對變得簡單而且成本很低。

缺點是，這樣的比對準確度和如何計算特徵有很大的關係。

---

* 關於LINE聊天機器人，請參考這篇
* 專案程式碼放在這裡。
* google的vision api其實價格更貴，請參考這裡。

聊天機器人 - 快速製作在LINE上的人臉辨識應用

名人以及圖片分析 在和LINE聊天機器人之對話中

 聊天機器人(chatbot)作為人機介面，提供人類各種整合性服務是最容易產生的應用。而人臉辨識，一直都是人工智慧與數據分析的整合課題。因此，把LINE聊天機器人加上照片或人臉辨識的功能，似乎也很有趣。

用LINE QR 加小姍為好友 可以測試人臉辨識

以前，在做關於影像的實驗性質的程式時，通常會先考慮opencv。雖然opencv確實是個好工具，但是如果你的目標不是改善演算法，或甚至做出更先進的人臉辨識方式，那麼opencv會過於複雜。

在2016年底，AWS發表另一個雲端服務：Rekognition。這個服務提供了API用以辨識影像，並順便提供了幾個在應用上的api：「比較人臉」「辨別名人」「識別限制級圖案」。(文件請參考這裡)

這些api要運用的最簡單方式之一，就是使用AWS Lambda來驅動AWS內自己的API，再透過API Gateway跟外界 - 也就是chatbot整合。換言之，這仍然符合公有雲廠商(無論是AWS, google還是azure)的所謂serverless的未來方向。雖然這些公有雲廠商，其實只是為了讓客戶更難離開公有雲環境，但不可否認的是，這些api的確有用而且在初期成本也不高。

快速製作在LINE上的人臉辨識，需要幾個步驟：

(1) 對serverless的設計概念有些瞭解

請參考這裡及這裡。

(2) 對Line聊天機器人申請和製作，以及對AWS Lambda先有基本的瞭解。

可參考這裡和這裡。

(3) 在LINE webhook的event中處理image id。

在webhook的lambda程式中，特別挑出image的id。LINE的訊息傳遞給chatbot時，有分不同的type，要處理的是image type。LINE並不會真的傳圖片檔案到webhook中，他傳遞的是圖片id，透過這個id，可以用一個URL拿到圖片：

https://api.line.me/v2/bot/message/<id>/content

要取得這個圖片，當然要有Line token

(4) 讀取圖片URL並且以取得bytes

以python為例，首先以requests讀取URL，記得stream必須設為True，因為接下來需要將資料(影像的byte)直接讀取成bytearray。參考程式如下

    imageUrl = 'https://api.line.me/v2/bot/message/{}/content'.format(imageId)

    r = requests.get(imageUrl, headers=headers, stream=True)

    bArray = None

    with r.raw as data:

        f = data.read()

        bArray = bytearray(f)

(5) 使用各種AWS的Rekognition服務。

取得bytearray之後，剩下的事情就很簡單了。

以python為例，可以使用boto3 (最好是1.4.4版本)。先取得rekognition的client物件，直接使用裡面的方法(例如以下範例)。將Image參數都設定成{ 'Bytes': your_byte_array} 就可以取得分析的結果。

    rclient = boto3.client('rekognition')

    response = rclient.recognize_celebrities(

        Image = { 'Bytes':bArray }

    )

要注意的是，分析結果response是一個含有各種標籤與技術數值(例如信心程度)的dictionary物件，所有的標籤都還是英文，必須得自己轉換成中文才行。

範例中的「名人辨識」(celebrities)所查到的名字都是英文。可以利用wiki 英文api搜尋這個英文字，找到對應的中文網頁，在取得中文字。

wiki的英文api可參考這裡。

(6) 存取S3之考量

如果看過AWS document應該會發現，使用recognize都可以設定image來源是S3。那麼範例為何不存取S3？ 

事實上，的確可以將LINE的影像，先存在S3，然後再進行分析。然而，這樣會多了「存入」S3和取出S3的時間。並且，S3也是要收費的！影像如果只「分析一次」，那麼存在S3其實很不划算，存在Rekognition裡面更是貴。如果會反覆利用，那麼恐怕還是得存在S3中。

目前結果分享

用LINE將小姍加入好友，就可以試用一下目前LINE與AWS人臉辨識整合。

加小姍為好友 ID-> @opn2514f

加小姍為好友

下圖是辨識川普不同的表情，會被辨識出不同的年紀，和不同的心情。

二氧化碳監測與Raspberry PI

Raspberry PI 或稱樹莓派，是最近幾年蠻有名的微型單版機電腦。最新版本(RPi 3)仍然是約略名片大小，但擁有1G RAM 加上 64bit ARMv8使它能做的事情已經和一般的PC沒有太大的不同。

這對純軟體工程師來說，是一個很容易介入IOT硬體的開始。早期，需要嵌入式系統（Embedded System）或者對各類硬體輸出入有一定了解，才能做一些有趣的應用，而現在由於RPi的關係，讓這些應用的門檻降的非常低。

因為RPi已經可以運行各類Linux Distribution，FreeBSD 甚至Windows10。讓軟體工程師可以直接撰寫有趣的應用程式，降低考慮硬體的問題。

不過，「降低」並不代表完全不需要考慮硬體問題。實際上很多市面上的硬體零件，其規格和輸出入方式各有不同，還是得有基本了解或者「取得範例」，才能達到想要的效果。

以市面上容易買到的「攀藤CO2模組」為例，它的文件相當的「精簡」，也沒有任何範例程式，因此需要自己想像一下官方文件到底在說什麼。

想跳過以下冗長說明的，可以直接看這個python範例。

官方文件提及這個模組式需要用標準序列埠Serial Port連結。因此可以想像就是把Raspberry TX/RX 和這個硬體的 RX/TX對接，並且硬體需要5v的電，也要接到Raspberry的5V輸出以及接地，因此就是4, 6, 8, 10這四個pin腳。

接上之後，需要送出指令，這個模組才會運作。根據中文官方文件，你需要知道指令，以及把指令組合成7個bytes然後送出。

但是其實，這個裝置也只有一個指令，也就是0xe3，上面述的DATAH, DATAL其實是填0，而不是如同文件上「打X」。由於只有一個指令，所以校正數字當然就一定也只有一個可能。簡單的說，其實只要（而且也只能）送出以下資料到serial port即可：

[ 0x42, 0x4d, 0xe3, 0x00, 0x00, 1, 114]
#python 範例程式節錄 送出serial port
ser = serial.Serial("/dev/ttyAMA0", 9600)
init_cmd =[ 0x42, 0x4d, 0xe3, 0x00, 0x00, 1, 114]
for c in init_cmd:
     ser.write(chr(c))



上述程式在RPi中會預設serial port已經不作為TTY (終端機)使用，因此才能直接對/dev/ttyAMA0執行輸出入。由於RPi預設serial port(8,10)式作為終端機使用，因此請記得disable它，並且重開機。

接下來，根據文件的內容，需要接收(讀取)一個12個bytes的資料，資料內容也都是固定，真正有意義的是第五和第六個byte，這兩個byte應該組合成一個數字。這個裝置最好的地方在於，它的數字已經是CO2的PPM值，這比某些其他公司的裝置還需要用各種方式換算方便許多。

兩個bytes組成一個數字的方式很多，例如可以把第一個位數利用 << 位移8，然後加上第二的位數。當然也可以把第一個位數*256加上第二個位數。

#python 範例程式部分節錄
 while True:
     count = ser.inWaiting()
     if count >= 12:
         recv = ser.read(count)
         h8 = recv[4]
         l8 = recv[5]
         print(str(ord(h8)*256 + ord(l8))+" PPM,")


最終結果就是，會有個Raspberry PI可以監視並且告知附近環境的CO2含量。
在辦公室監視一整天的結果非常明顯，上班前的CO2含量比較低，人越多的時候CO2含量會快速增加。連續兩日，都是在每日下午5點到達最高峰，接下來逐漸下降至隔天開始上班為止。

Serverless design for IoT - An example leverage AWS and GrovePi

AWS announced IOT service in about 2015 and gradually release other relative service (for example: IoT Button) for those who need to tackle with the problem on huge amount of increasing response of "The Things". And it is of course the area which cloud provider what to provide a optional solution.

To demonstrate the benefits of leveraging the serverless design and also utilize the power of AWS cloud. I build an example project combines Serverless design, AWS IoT, Respberry Pi, Grove Sensor system and GrovePI. It will provide in door air quality (office) for me if I want to know that before entering office. So that I can have an excuse to work from somewhere else? :)

In this example, a GrovePi mounts in Raspberry Pi (B+) to control Grove's Air Quality Sensor, HCHO sensor and dust sensor. As a software engineer, I assembled all these inside a paper box. See picture below.

RPi and GrovePi are inside the box. 3 sensors are out there.

Reminder: to use AWS service, the most important things is to read official document. AWS has many different services and there are too many out-of-date articles in somebody's blog. It doesn't mean that authors were wrong, it is just out-of-date. Of course, it is the same in Raspberry Pi and all other 3rd party open source library, try to read official document (or official wiki/blog) to have overall view.

The full implementation and design concerns 

(please check all the project detail in github)

(1) Grove's 3 sensors + GrovePi + Raspberry Pi

   The hardware parts. Check GrovePi's official web site to know how to put them together.

    GrovePi might be the easiest way to program Grove's system from Raspberry Pi, if you have more then 2 device in a machine. However, if you have only one sensor, then just use RPi's GPIO.

(2) AWS IoT service

   Although we didn't program anything in side the hardware, we still need to setup things in AWS IoT service. And of course, it will be better to read at least the tutorial.

Screenshot of AWS IoT Tutorial

   AWS IoT pricing model is counting by message (512bytes). At this moment, about $5 per million message. Which means about $5 per 500MB! This is much more expensive than own a EC2 service to serve device message. However, if you don't need to keep all monitoring data transit in AWS every few seconds and you need only monitoring state changes (maybe a few times per day) then a "Device Shadows" is the best for you.

   In this example, we register a "Thing" named: InDoorSensor1 and the most important thing is to have default Shadow Object as below:

{
  "desired": {
    "welcome": "aws-iot",
    "air quality": 43,
    "action": "wait"
  },
  "reported": {
    "welcome": "aws-iot",
    "action": "wait",
    "air quality": 43
  }
}

   The device will keep sync the Shadow in AWS and if the desired state change to "do", it will (a) do a one time air sensor data collection and then (b) update air quality in Shadow object (c) change to "wait" state. In sort, the Shadow and Device will sync the state (wait or do) and the state's sync is the major function provide from AWS.

(3) AWS IoT Python SDK + GrovePi Python library

AWS provides a few SDK for device, in this project, we use Python to do AWS Cloud access (no matter notification or change Shadow state)

In the Raspberry PI B+, you need to:

    (a) install AWSIoTPythonSDK
    # pip install AWSIoTPythonSDK  (also see here)

    (b) consider the protocol (MQTT vs Websocket). In some environment, the MQTT port might be block. AWS SDK provides MQTT via WebSocket which of course allow broker use port 443.

    (c) certificates: please do read AWS IoT Certificate document if you didn't have experience before

If you use Raspberry PI version B+ 2 or 3, then it will be easy to install nodejs/npm and all other fancy stuff.

(4) IoT Shadow

    The Shadow means an identify object of IoT device. This allows client to change the state of a object and then sync to IoT device. In certain scenario, it allows programmer no need to take care of network error handling or any off line case. However, you still need to fully understand what means exactly the "desired" and "reported" state.
   It is possible to edit Shadow state from AWS admin console direct for testing purpose. (you won't want to do so if you have thousands IoT device).

(5) Lambda, API Gateway

    Supposedly, an application will NOT access specific IoT device, it normally access a service and that service provides information or allow meaningful user actions.
    In this case, a lambda service is simple a python program which can (1) retrieve current state and also current air quality value (2) update state to "do". And as always, the Lambda is behind an API Gateway and which means, potentially, all other application could use this API to access necessary (filtered) information.

see the activity hand draw:

Next Project

Hopefully, I can have more budget to purchase Raspberry PI 3 and also CO2 sensor and then also gather data to draw graphic in D3. Also, I am thinking to use LINE to send air quality information to my colleague or neighborhood.