7/31/2017

快速且極低成本之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其實價格更貴,請參考這裡




7/26/2017

聊天機器人 - 快速製作在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

加小姍為好友 Add Friend


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




7/18/2017

二氧化碳監測與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點到達最高峰,接下來逐漸下降至隔天開始上班為止。





7/12/2017

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. 



7/08/2017

企業巫醫 - 得罪老闆怎麼辦 (人際關係的過度重視)



得罪老闆(直屬主管)怎麼辦?

眾多企業巫醫都有不同的說法:

某一類型的企業巫醫以案例和經驗強調「如何不得罪老闆」,試圖就源頭解決問題。然而,大部分的作法,都是為了造就謹言慎行的員工。例如「得罪老闆的六宗罪」「別惹十種人」「與主管相處之道」「職場人緣學七招」。這些說的都沒錯,然而 - 除非是在超大型組織或者公家機關 - 職業生涯的發展,大部分還是取決於能力與實質貢獻,有效溝通與人際關係是其中重要的一環,而非全部。

有很多企業巫醫都會引用這段不實謠言「卡內基美隆大學曾針對畢業的 200 位傑出校友進行一份問卷調查,結果發現,成功的重要因素裡,其中85%來自一個人的態度包括自信、熱忱、領導、溝通以及人際關係的能力,另外的15%才是專業知識。」作為開場白,似乎再再強調人際關係的重要。更隱含著,只要有好的人際關係,就解決了85%的問題。

隨意引用未經實證的事情,是企業巫醫的共同特徵。就如同在部落驅邪一樣,告訴群眾,根據某某以前的巫醫說法,現在就是獻祭品用樹枝鞭打驅邪治病的好時機。

大概也是這個問題太典型,可是真實研究內容又和各企業巫醫所引用的有所出入。因而,卡內基大學的官方Q&A只列出問題,但是並沒有直接說明答案,只說這是1918年某期刊登載之研究,但是太久之前了,請自己去圖書館找(參考這裡)。

在此特別感謝google的paper search 學術搜尋,很快的根據年份跟名稱,找到該研究發表的地方(參考這裡,請直接看106至108頁) 


實際情況是:



(1) 該研究並非針對200個傑出校友,甚至根本也不是針對特定學校的校友。研究對象為美國工程師,實際樣本超過7000人。

(2) 該研究,是以問卷形式,將因素是工程師升遷的重要條件分成六組(Character, Judgment, Efficiency, Understanding of Men, Knowledge, Technique)。結果,認為Character人格特質那組條件,是升遷第一重要依據的人數,是其他組的七倍。 眾多企業巫醫所引用85%,應該引用此依據,再經過時間以訛傳訛的結果。

(3) 該研究開宗明義的指出在1900前後,美國的工程師教育問題,認為過於著重技術教育,而在工程教育體系缺乏對人格特質的強化。然而!該研究的人格特質定義乃是指

common sense, integrity, resourcefulness, initiative, tact, thoroughness, accuracy, efficiency, and understanding of men 」(註1)

光看字眼,也能夠體會到1918年 - 畢竟已經快100年前 - 和今日一般企業巫醫所指的「人際關係」有很大差異。例如:完整,正確,有效率,在現代社會通常是技術的一環,而較少列入人格特質的一環。

過度強調「職場成功85%要靠人際關係」就會讓「得罪老闆該怎麼辦」變成落在自己身上最痛苦的事情。因為,得罪老闆之後就會有「已經失敗了85%」的不實感受。

那麼,已經得罪老闆之後該怎麼辦?和處理問題的基本「事實三步驟」一樣:


(1) 確立事實



(a) 你的市場價值有多少?

必須要取得客觀的事實,而非自己心裡的感想。每個人都認為自己對組織可以產生很多價值,但事實上可能不然。最簡單的方式就是「試著去面試找工作」。在此m,並非鼓勵以換工作解決問題,而是以「測試自己的市場價值」來決定個人價值。如果在3-4個月內,無法找到比現在工作整體薪資高出10%的工作,那麼其實你現在在組織內部的價值是被高估。


其實不管有沒有得罪老闆,只要你受僱者,不是自己開公司當老闆,就應該要確定自己的市場價值。這是最重要最重要最重要,需要知道的事實。也是最大唯一根據。

(b) 得罪的原因是做了錯事,還是只是個性不合接連產生誤解,還是遇到一個糟糕的老闆?

也很有可能你永遠無法知道原因,不過如果有機會知道會比較好。

(c) 職業生涯的目標

(d) 對老闆的依賴程度

(e)...還有很多其他事實






(2) 建立選項


得罪老闆既然為既定事實,就要考慮「應該怎麼做」的選項。在完全被動情況下,人會有無限的壓力,選擇的權力讓有掌控感(不過太多選項也是壓力,參考 註2)。

無論如何,至少給自己產生3個應變選項,以下是一些選項參考。了解或者建立選項,並非一定要做,而是要給自己「清楚可見」的選擇機會。


(a) 不動作


每人都有機會得罪老闆,你不見得是唯一,也不見得是最重要的。不動作指的是不把它當一回事,繼續做好你該做的工作,繼續學習成長。


(b) 大幅提昇績效


如果你的工作績效清楚可見:要注意的是,清楚可見是指「其他人清楚可見」而非自己認為。那麼得罪老闆也並不是很重要的事情,因為你對組織的貢獻的本身,並不會得罪任何人。大幅提昇績效是可行的選項,不過前提是你「做得到才行」。既然你已經看到這篇文章,大概就隱含著這個選項短時間做不到。


(c) 組織內換部門


很多時候,你只是和老闆個性不合八字不合,在大組織內換個部門並非壞事。


(d) 換工作

換工作和內部轉移不太一樣。你必須把換工作當做「自己的選項」而非被動的選項。並且,不要欺騙自己。

有些人是在沒其他選擇的情況下,自己欺騙自己說「其實是我想換做工作」,這容易去找到一個勉強而不見得是自己喜歡的工作。換工作的選項在於,先確定自我價值,知道自己換工作可能犧牲的成本代價,然後視為眾多選項之一。當最後真的執行換工作選項時,在時間上和心態上就有很大的差距。



(e) 建立新技能範圍


自己開公司也屬於這個範圍。換言之,在維持現有工作績效的情況下,額外花時間開創可能性。

以資訊科技來說,主動舉辦workshop,參與opensource專案都可能是建立新技能範圍。然而,那怕是去取得水匠電工丙級執照也都是建立新技能範圍。(不建議直銷保險之類的工作)


(3) 執行選項


即便「不動作」,也是需要認知與執行。執行上有一些要件。

(a) 速度:除了不動作之外,其他的選項在「已經得罪老闆」的情況下,應該是要越快建立越好

越快能建立選項,表示自己掌握了「時間」。不掌握時間的人,就容易被動的被時間掌握。當你覺得每天忙碌不堪,似乎被事情追著跑的時候,表示你需要先改善自己的時間掌握能力。

(b) 建立回饋方式:任何要執行的事項,必須要有自我檢查的方式確定執行的結果是否和預期一樣。因為執行結果有差異的時候,應該「儘速修正」。

(c) 符合最終目的:當得罪老闆這件事發生的時候,你的目的到底是什麼?

你希望「已經獲得老闆原諒了?」
還是「得罪這個老闆已經沒關係了?」
還是「得罪老闆所產生的後果已經最小化」
還是「....」

執行任何解決方式,必須要符合你本來的目的。這目的當然只有你需要知道,而不需讓那些無法幫你解決任何事情的巫醫當作他的「研究個案」或者「參考範例」使用。



參考文章:換工作的面試-軟體工程師如何展現價值


註1 :節錄原文描述人格特質的「項目」,徵求比較好的翻譯
註2:然而,有許多研究顯示太多選擇也反而造成壓力,請參考這裡

6/20/2017

Serverless design for LINE AI Chatbot


Chatbot is one of the interesting application in AI area, it creates opportunities for enterprise to serve customers only with very low cost or even generate new revenue.
In past few years, major Instant Messaging providers allow developers to hook their service. Means as long as you have existing simple message process and response system, you can quickly interact with all kind of message channel.

Normally, a software developer will start from build a system in a server box, no matter Linux or Windows. Recently, the server might be a VM in public cloud, no matter AWS, Azure, Linode or DigitalOcean. However, a serverless design model might be a better choice.

Why Serverless?


Firstly, a serverless system will be easy to scale in/out. It doesn't mean you can't scale in/out in traditional VM in public cloud or your own datacenter. It just means that all the Lambda, no matter which provider, is actually decouple from it development environment. Supposedly, you start from one Lambda function to a few thousands same Lambda function without consider "traditional question", for example: should I shutdown VM when not in peak our, should I do some script to check if current VMs are closed to overloading?

Secondly, a serverless system will be easy to plug-in which means during the design phase, developer will be forced to think de-couple functions in small modules (bricks). Developer will also be forced NOT to rely on specific environment, even though docker is one of the solution but purely Lambda function will create much better environment-free structure.

Furthermore, it will also help to define boundary of sub system and help the future maintenance.

The Design Concerns

(1) IM independent

LINE occupies a huge market in Taiwan, about more than 90% of mobile user has LINE account. The most incredible thing is many elder people who never touch Internet before have LINE accounts! However, this design won't use any LINE specific methods. We've try the same engine in Yahoo Messenger and it also works.

(2) AWS Lambda

-- (2.1) try NOT to use context

AWS Lambda has a standard invoke parameter (event, context), The event is actually the user input when invoke Lambda function. The context is what developer might need to understand the 'environment context'. The major design concern here is try NOT to use context when possible. Because this will make you hard to move out your lambda to other public cloud environment. If you really need to have ARN or identity, try to limit environment in just one Lambda.

-- (2.2) async invoke

AWS Lambda could be invoked in 3 types: Event, RequestResponse, DryRun. The "Event" is actually asynchronous call. For any IM message receiver Lambda, you should  keep that Lambda as simple as possible to response IM webhook. Put other things via "Event" Lambda. Because most of IM provider (LINE, fb) ask a very short timeout in IM webhook. DO NOT just put http webhook and response to IM a synchronous call stack

Of course, see detail from AWS document: here.

-- (2.3) timeout/memory

AWS lambda allow to config timeout and memory size. AWS CloudWatch could see a Lambda's resource consuming. It is fine to use larger memory or setup a longer running time but developer should know WHY.

-- (2.4) quick testing

It is necessary to have your own developer server for test your Lambda function and trigger a deployment script to upload to AWS. If you didn't actually use "context", it will be very simple to have a quick test in every Lambda handler.

# in the end of your Lambda python script.
if __name__ == '__main__':

    event = {'param1':test'}
    lambda_handler(event,None)


Of course developers need other framework (unittest).

-- (2.5) deployment

As always, from a developer should have a semi-automatic way to do deployment. This is a very simple deployment script to (a) zip python files (b) upload to S3 (c) create lambda function (d) config function using S3 zip file.

(a) zip lottery.zip -r lambda_lottery.py lottery60.py
(b) aws --profile ailine s3 cp lottery.zip s3://bucket/
(c) aws --profile ailine lambda create-function --function-name lottery --runtime py
thon3.6 --role "arn:aws:" --handler lambda_lott
ery.lambda_handler --timeout 10 --code "S3Bucket=bucket,S3Key=lottery.zip"
(d) aws --profile ailine lambda update-function-code --function-name lottery --s3-bu
cket bucket --s3-key lottery.zip

-- (2.6) scheduled (cron) Lambda

Chatbot might need to do scheduled task to response to user, maybe send a regular morning call. To trigger a scheduled Lambda might be one of the major cloud-provider-dependent thing we have in Chatbot design.


(3) AWS API Gateway

AWS API Gateway is another major cloud-provider-dependent things, however, it is not hard to use other provider or have our own lab testing environment. The major concerns of API Gateway are (a) should convert IM provider's http request to a given format: which becomes a Lambda input. (b) security concerns: how to make sure only IM provider's system could access this API Gateway

(4) AWS dynamodb

Chatbot uses dynamodb to store use information and also message log. It is also pretty easy to use local JSON formate nosql.

(5) AWS elasticsearch

Chatbot leverages AWS elasticsearch to store knowledge base. It is easy to setup a developer's elasticsearch server to do lab test before deployment. The real concerns in public cloud might be the future budget:)

(6) AWS S3

Chatbot still need some static content (html or js) and S3 is the most easy way to provide public static content. It is also the place to upload latest Lambda code.


The Implementation


See: github repository 

Take a look?

This chatbot could understand and speak only Tradition Chinese, since she is a Taiwanese robot:). You need to have LINE account to chat with her.

聊天機器人小姍的Line QR 
加小姍為好友 Add Friend 









5/25/2017

非核能零碳排放智慧型供電站


2015年某學者說要全台灣鋪滿太陽能板,才能取代台灣現有的核電廠,原新聞出自聯合報,暫時找不到link,次級資料可以參看這裡,或這裡。這兩年來已經開始有打臉文,例如:這裡

當然,要實事求是的話,簡單的從公開資料中,計算真實的數字才是工程師腳踏實地的精神。

以下計算,使用2017/5/25台電的公開資料(誠如上圖):

(1) 太陽能 0.66 平方公尺約 100W,  為了簡化計算,大概1平方公尺100W。所以每1MW(百萬瓦) = 1,000,000  / 100 = 需要10,000平方公尺

(2) 核電廠的目前供電量請參考這裡(誠如上圖)

假如台灣目前所有核電廠全速運轉,其發電量可達5144百萬瓦。不過以當日情況來說,由於維修關係,只有1393.7百萬瓦,而就2017/5/25當天而言,實際上也沒限電。
  
(3) 以計算當日而言,所需面積為1393.7*10,000= 13,937,000 ~= 14 平方公里。而以最大運轉計算為5144 * 10,000平方公尺 = 51,440,000平方公尺  ~= 51.4平方公里

(4) 台灣總面積為36,000平方公里,以當日用電計算,14/36,000 = 0.000388 佔了僅不到萬分之四。而以最大運轉計算,51.4/36,000=0.00142 佔了僅不到千分之二。當然這樣的計算只有白天,如果要儲存晚上可用電量,表示白天起碼要儲存一半以上用電,也就是將數字乘以2。然而,即便把這個數字乘以10,也離「鋪滿全台灣」很遠很遠。


那麼何謂「非核能零碳排放智慧型供電」?


非常簡單 - 而且也有點無聊 - 只是買一個50W太陽能板,透過太陽能控制器,裝上機車用電池(6AH),隨便擺在辦公室窗戶旁邊,就可以幫你和另外兩位同事的智慧型手機充電。

非核能零碳排放智慧型供電站 提供2個5V2A USB插座

很明顯,這個組合是「非核能」,而且在發電過程是「零碳排放」,提供給「智慧型」手機「供電」。


是否能節省辦公室用電成本?能節省的金額其實少得可憐。粗估最佳狀態,每天能節省0.3度電,一年頂多也省365*0.3 = 108度電,以每度2.53NTD計算,約省273 NTD。



大樓外觀,太陽能板放在玻璃內,其實功率會降低。


5/22/2017

企業巫醫 - 講重點!




在許多企業巫醫的書籍文章演講中,都繪聲繪影的描述「講重點」是極端重要。但也僅只是說它很重要,卻擺明著忽略這件事的真正重點:「關鍵重點難以找到」,或者更直接的「怎樣找到重點」。


就只是像提醒健康很重要的提醒「講重點」的文章像是:這裡這裡

另一些文章,表面上提出一些找到重點的方式,但是壓根也是一堆廢話。例如:從對方觀點找到真正價值。聽起來很有道理,但就像部落巫醫說:「得罪了祖靈,所以你生病了」,看似有理,但是到底做了什麼得罪了祖靈才是重點吧。「如何」知道對方的觀點,才是找到重點的重點。這類型的文章例如:這裡這裡這裡

只而更有些文章,提出了似乎務實的步驟,但都是太過一般化的案例,不是類似秘書處理好老闆的行程,就是與別人討論時的對話重點。這些在技術為主體的組織裡也根本派不上用場,例如:這裡這裡


絕大部分的人在工作上,並非不講重點,而是講不出來或找不到。而很遺憾的是,複雜環境(參考Cynefin架構)下的關鍵重點,並沒有簡單的三步驟,也沒有五個必備SOP之類的方式就可以取得。

關鍵因素的掌握,需要知識與經驗的累積。

知識的累積會堆積成智慧,經驗的累積會變成靈感,而智慧與靈感綜合起來,就能在複雜事物上以很短的時間將其抽象簡化,而抽象簡化的事物就容易看出重點。

雖然沒有捷徑,但就像是健身減肥一樣,從任何時間開始都不嫌晚。而且從任何時間點開始,都可以在比自己想像的時間內還早獲得效果。

知識的累積


只要抱著開放的心態,多閱讀,多請益,大概就很容易做到知識的累積。(知識快速累積可參考這裡)

值得注意的是,知識也有分軟硬兩種類型(註1)。

軟知識:談判技巧,溝通技巧,專案管理,人際關係,等等都屬於軟知識。換言之,軟知識可能會隨著文化背景改變而有截然不同的結果。

軟知識,容易落入「嘴砲唬爛」的範圍。軟知識的累積因為太多太多地方可取得,就不在這裡討論。要稍微注意的是,無論是什麼樣的人對「軟知識」都有自己的一套煞有其事的說法,要注意不要落入「純唬爛嘴砲」的範圍之中。

硬知識:數學,工程,程式設計,等等都屬於知識。換言之,硬知識不會隨環境的改變而改變,但它會隨時代的進步而進步,容易站在巨人的肩膀上前進。

硬知識,容易變得「極端」,不是容易被忽略,就是容易被過度強化。

絕大部分在組織工作的人,只要有數年以上工作經驗,都知道軟知識的重要。而各類型心靈成長,溝通協調,領導管理的書籍課程就孕育而生。在組織中,最極端的中階主管就會有意無意透露出「軟知識」遠比「硬知識」來得重要的許多(註2)。

最佳的情況是:硬知識和軟知識必須要互為成長基柱。兩者兼具的成長。

硬知識的累積:非常簡單,(1) 先設定知識累積範圍,例如設定為軟體品質改善 (2) 利用mindmap圖,整理自己已經在腦海的知識 (3)去圖書館至少借7本相關書籍,(4)上網尋找相關知識 (5) 閱讀並且搜尋完之後,僅憑自己的記憶和腦中統整結果,再次畫出mindmap圖,有必要的時候進行實作(例如寫程式)


經驗的累積


經驗可以解決在Cynefin framework中,「複雜」與「渾沌」這兩個象限的問題。(關於Cynefin請參考這篇)

不過,經驗的累積方式是經驗是否能「持續累積」的關鍵。

同樣一件事情做20年,有些人會取得20年的寶貴經驗,有些人卻是像是只做了1年一樣:只是做了20次一年。

以軟體開發為例:

1. 在SAP的ERP環境下,撰寫相關模組20年,如果沒有產業相關知識的成長,只負責出各種報表,那麼和2年經驗也差不多

2. 做為專案經理超過20年,如果遇到事情只會加班解決,那麼和1年經驗也差不多(參考這裡)。

3. 做為有10年開發經驗的java程式設計師,如果遇到組織調整,需要使用其他程式語言,但用各種方式拒絕推託,那麼未來可能就變成只有數年經驗值的程式設計師。因為推託學習不但會讓技術停滯不前,還會退後。

經驗的持續累積也很簡單。重點在於「持續」:每隔一段時間檢視自己的工作筆記,看看自己是否做了任何改善現在工作的技術的事情。如果沒有,就表示沒有持續累積經驗,經驗僅只是停滯而已。

沒有工作筆記?趕快去買一本吧,筆記本太便宜好用了。







註1:當然有些知識很難分軟硬,這裡只是概述而已。
註2:例如,軟體開發有個傳言:「coding co的好,要飯要到老。」

4/20/2017

數據分析 - 獵人頭如何從Github尋找人才?


前陣子遇到某特殊的獵人頭hunter公司(參考:這裡),竟然是透過分析統計在github, gitbucket的程式庫,來找到軟體人才。

目前,github使用者數量仍屬商業機密,但估計約在2千萬左右(參考:這裡)。當然,使用者大部分從事軟體相關的行業。

資訊科技,特別是軟體的實際成果,容易在網路上展示。因此,如果要找到「軟體開發人才」,github是一個很好切入的地方。一般獵人頭可能會人工搜尋,但身為工程師,當然是寫程式找到大量資料。

從github找人,這做法有一些顯而意見的好處:

1. 有可能看到此人實際上寫的程式碼
2. 有可能了解最近此人的工作範圍
3. 很快找到此人的聯絡方式(email)部落格或其他技術相關資訊
4. 有可能找到此人合作對象
5. 有可能看出此人的英文語言能力

當然也有些顯而易見的缺點:

1. 當然找不到那些不在把專案程式擺道github的人
2. 此人可能只是擺放玩樂性質的程式
3. 只能有機會看得出技術能力,非技術能力仍然需要其他佐證
4. 資料範圍過大,很難逐一肉眼看完

雖然我不是獵人頭,但基於工程師的精神,就嘗試一下解決「資料範圍過大,很難逐一肉眼看完」的問題。看是否能透過程式取得並處理gitbub資料,找到潛在挖角對象清單。

實際上做的步驟如下:

1. 了解gitbub資料如何取得:


github提供api可供程式使用。和許多Web Service一樣,也有完整的文件,請參考這裡


2. 以程式取得少量測試資料

github的web api測試起來很簡單。舉例來說,如果你已經登入github,用以下這個URL request就可以找到,以javascript與nodejs為關鍵字的所有程式庫:

https://api.github.com/search/repositories?q=topic:javascript+topic:nodejs

當然,他的回應是json格式,需要簡單地用程式轉換。例如下圖,乃是搜尋和javascript相關,並且其位置在台灣的使用者:



測試資料回傳乃是json,調整格式成為csv,以便於日後在excel做簡單分析。


3. 了解測試資料內容


如果已經有在使用github,那麼對於回傳的資料應該很清楚其內容意義。

如果不太了解github,就需要找對軟體版本控制系統有些認識的人幫助瞭解其含意。

這上述的範例:「搜尋和javascript相關,並且其位置在台灣的使用者」來說,程式會刻意收集following(有多少人在跟隨這個人的更新),follower(這個人跟隨了多少其他人)。此外,程式會額外計算push和javascript相關的程式庫的次數,取名為work,表示和javascript的相關工作在過去一段時間的次數。


4. 撰寫簡單統計程式,大量取得資料


當然,這個程式就放在github上。請參考這裡

程式本身是python撰寫,需要有github帳號密碼才能使用。


5. 結果


以上述範例:「搜尋和javascript相關,並且其位置在台灣的使用者」大量取得資料並且「過濾可取得公開email」的人數一共是661筆。並且取最前面的199筆,給熟識的headhunter (獵人頭) 鑑定看看是否有效果。

目前的回應都是此資料非常有用。

3/31/2017

企業巫醫 - 向上管理的實務作為?



向上管理是個歷久不衰的名詞,它和「人格特質分析」「領導與管理」等名詞雷同,每隔一小段時間就會以各種形式,出現在企業巫醫們的討論中。

近期隨意查詢就可以找到不少相關文章: 向上管理(cheers雜誌),如何讓老闆聽我的反對老闆的六種方式向上管理的四步驟 ......

「向上管理」向來是一個譁眾取寵的話題,眾多企業巫醫仍然以泛泛之談,試圖教導並解決一個現實而又務實的問題。

企業巫醫,總是能選定看似重要的無法辯駁,共通的話題,而且此類話題完全視個人情況而有截然不同的作為。因此,企業巫醫可以提出極端空洞的說詞,卻又多少讓人覺得有趣。除了「向上管理」之外,「創業」「創意」「領導與管理」「人格特質」等等都是屬於這類。

實務上,「向上管理」不能是打算進行的行為,而是產生貢獻中的其中一個結果。換言之,追逐向上管理,等於是捨本逐末的追逐影子行為。

因此,先務實地做到基本三件事情,假如踏實的做到了,向上管理就不是問題,而是附帶的結果。

1. 真正了解關於自己的現況事實

事實現況聽起來簡單,要找到也很簡單,但是要承認自己的現況事實其實有點難。

事實必須是清楚的,不模擬兩可的。例如,假設你是NBA球員,去年平均上場25分鐘,平均得分14分,這就是事實。至於你的技術能力好不好,並不是「事實」的一部分。以資訊科技的相關工作來說:參與過專案是事實,寫過java/python程式是事實,取得JSCP證照是事實,有Scrum證照是事實,帶領過開發團隊是事實,參與open source相關研討會是事實。

然而,具有良好溝通能力不算是一種事實,喜愛資訊科技不算是一種事實,

現況也必須是清楚的,不可能模糊。例如,目前薪資是現況,工作年資是現況,是否有直接report的人(也就是是否為管理者)是現況,最近一年有沒有拿到其他公司的offer也是現況,曾經拿到比現在薪水高的offer也是現況。

然而,覺得自己薪水被低估不是現況,覺得自己不受到重要不是事實,幾乎大部分的感受也都不是現況的一部份。

請參考這裡這裡這裡


2. 讓自己的實際產出超乎期待 


二因子激勵理論,描述「保健因子」和「激勵因子」兩種個人激勵因素。而其實這也是務實的評斷自己工作的方式。請參考這裡

要確定自己的產出超過期待,必須要確定產出有「超出」。

以基層程式設計師而言,在過去一年該寫的程式功能都有如期完成,並且品質在一定範圍之內。這樣的工作內容並沒有「超乎期待」,只是滿足「現在的薪水」而已。

要超乎期待的方式有很多。最容易的方式,是在目前工作範圍之外,「額外」並且「主動」完成有意義的事。例如,以基層程式設計師而言,在過去一年該寫的程式功能都有如期完成,並且品質在一定範圍之內,並且,主動地在額外的時間舉辦小規模研討會,分享工作上技術的進展。另一個例子,以基層程式設計師而言,在過去一年該寫的程式功能都有如期完成,並且品質在一定範圍之內,並且,由於主動學習其他程式語言,因此在其他專案上也能做額外貢獻。


3. 建立短中期職涯計畫並確實執行


在資訊科技產業中,實踐長期職涯規劃幾乎是不可能(註1)。

然而這並不代表自己現在就應該隨波逐流,看主管決定什麼就做什麼。個人應該要維持短中期的職涯規劃。特別是短期規劃。

短期規劃,必須要和技術能力以及現在工作有密切相關。

例如:

「作為一個程式設計師,未來8個禮拜,要能學會Scala基本用法,並且提出現在產品裡用Scala做分析的計畫」

「作為一個QA新鮮人,未來4周,要能將現在100個手動測試的case,至少其中20個變成自動化測試。同時,原本的工作也不會拖延」

中期計畫乃是半年到2年左右。必須要是「可以明白斷定達到與否」的目標。

例如:

「作為一個QA新鮮人,在2年內我想要變成資深QA,斷定是否為資深QA是以是否升遷或取得其他公司資深QA的offer」

當你完成數個短期計畫,通常表示你也踏實的逐步成長。即便有些短期目標沒有照時間完成,也沒關係,幾次之後,仍然是踏實往中期目標前進。

重點在於:這些目標是你自己決定的,並非主管或其他人硬塞給你。而目標既然和目前工作有關,自然就會協助你在工作上成長。


......
如果你非常非常確定已經完成以上三點,但覺得在這個組織中的成長仍有阻礙,還是很需要「向上管理」,用以獲得好的評價,獲得升遷?這基本上是不太需要,因為你應該儘速離開這樣的組織才是最好的方式。




註1: 「長期職業規劃」和「個人理想夢想」並不同。個人理想夢想可以需要很長很長時間實踐,也可能只需要很短的時間,也可能和職業無關。當然個人夢想就需要長期投入,也可以規劃,也可以不規劃。不過,不投入自己時間的夢想,通常就是空想而已。

3/23/2017

企業巫醫 - 贅字 廢話 泥巴仗




在組織中,溝通合作是大部分的人一定會做的事情。

溝通合作說起來簡單,畢竟人類是靠群體合作而存活在地球上。不過,在企業內部的有效溝通並不如想像中的容易(註1)。

某些人在對話或文字表達上,有意無意的更增加溝通的難度。如果是無心的,僅只是造成困擾而已。但如果是刻意為之,會讓溝通困難,讓事情滯礙難行。

無論有意無意,溝通上常見三個問題:「贅字」「廢話」「泥巴仗」

在這三個之中,贅字和廢話很煩人,但真正要解決的是可怕的泥巴仗。


贅字


典型的例子,像是最近淡江大學解聘兼任教師的新聞:高教工會主任:「學校也一再地向(兼任教師)表示說,也是因為今年的8月1日,勞基法要開始適用於,未具本職的兼任教師身上,學校不想負擔這樣的人事成本,所以他們才會做了一個解聘跟不續聘的動作。」

有人稱這類型的贅字為「語言癌」。(註2)

凡舉「關於XXXX這個部分」,「做一個XXX的動作」,無意義的拉長語句都是。

當然也有些人認為拉長語句是「敬語」的表達方式(註3)。

此外,狀聲詞:「嗯」「唉」「阿」因為在對話中,有實質表達情緒的功能,所以不算是贅字。

不過,贅字真正的影響其實很小,只是太多贅字會讓聽的人很不舒服而已。



廢話


在說明事情,或者文件上,用過多虛浮的形容詞,掩飾無意義的內容。或者,重複不證自明的真理,用以掩蓋無法找到重點的對話。

在政府機關的公務人員出國報告網,可以輕易地查詢到充滿廢話的報告。

例如:一個公司是多面向的結合。(簡單的說,整句都是廢話)

例如:透過本次會議實際瞭解大陸生醫相關市場現況,就本所研發之核醫藥物推廣應用極具參考價值,可納入本所未來研發方向之參酌。 (簡單的說,出國去參加這個會議,最後只是參觀看看而已,沒什麼東西是真的影響組織的研發方向!)

另一個例子:不論是什麼樣類型的數位化工具,除了便利性外,都應兼顧到安全性,日後推動電子化政府的過程中,應與各級資訊安全主管機關做密切的合作,確保資訊科技的演進不會成為資安漏洞。(資訊科技本來就不應該是資安漏洞,各級安全主管機關本來也就應該合作,哪會需要出國參加會議之後才知道這兩件重要的事?)

當然,某些企業網站資訊,也是廢話很多。不過,大部分是似是而非的術語,構築專業能力的感受。

例如:透過嚴格的專案控管與扎實的系統建置專業能力,我們有信心提供客戶最安心、最可靠的大數據優質服務。(如果把形容詞拿掉,這句話其實很短:我們提供專案控制和系統建置的大數據服務。但更具體一點,就是:其實有案子我們就可以接來做,大數據只是個行銷名詞)

有時候廢話很煩人,因為要花些力氣才能抵達事實真相。廢話浪費的很多時間,不過如果採用Scrum方法論,在會議上只專注於現況和事實,應該不太可能會有廢話太多的問題。至於網頁資訊和技術文件,就應該盡可能去除廢話。

泥巴仗


最高級,並且更難應對的是泥巴仗。

特別是在中大型組織,中階主管通常都位於關鍵職位。而好的中階主管,仍具備本職學能(註3),會根據事實來溝通。也因此,優秀的中階主管通常會強調技術事實,產業事實,專案事實,資源分配事實...等等諸多事實根據,作為溝通以及決策的基礎。因此,反倒不會強調本身的溝通協調能力。因為這樣的能力,如同影子一般隨附在工作之中。

然而糟糕的中階主管,由於已喪失本職學能(註4),就會強調其「協調溝通」成為其最重要的工作。然而,不基於事實和邏輯的溝通,會變得混亂不堪。某些糟糕的中階主管,在遇到爭議性問題時,會用打模糊的方式,試圖讓大家在泥巴仗中度過。而最高階的泥巴仗,會用看似合理的邏輯,但展示對技術完完全全無法掌握的事實。

例如:這個影片,非常經典,看似誇張,但在資訊科技產業其實常常發生。在該影片中,真正做事情只有一個人,而中階主管遇到技術難度的問題會省略甚至推諉,不能體會真正的重點而死咬不重要的細節,而技術人員要探索細節又會說這是專家的工作範圍。當然該影片是太誇張了一點,但其實在中大型組織時常發生類似的事情。

另一個例子:在老大靠邊閃中的有名片段,first thing or second thing。主角完全是用打泥巴仗的方式,在黑幫大老會議裡,刻意激怒某老大。而其他大老反倒會覺得生氣的老大很沒風度,一開始沒發現主角在打泥巴仗。

在此徵求案例:徵求在資訊科技中,重要會議裡打泥巴仗的案例。 


混亂泥巴仗是很可怕,要對應泥巴仗有先決條件,就是這不能是在「只有兩個人」的情況下。換言之,會議或者文件,至少要有三個人在場才有機會擺脫泥巴仗。

只有兩個人的情況下,只要有一人刻意打泥巴仗互相把對方弄的髒兮兮的,而且這個人還是中高階經理,另一個人根本不可能解決。唯一的方式是,儘速逃離現場,在下次確保有第三人以上在場。

在有起碼三人的情況下,以下方式可以解決泥巴仗問題。


1. 不隨之起舞


泥巴仗成立的條件是互抹泥巴。例如,在軟體專案中,當大家在解決A模組為何落後時,如果有人反覆提及一些沒有直接關連的事情:也許是另一個專案也落後了,也許是某RD的溝通態度不好。這些都是泥巴仗的徵兆。


2. 以白板展現事實


人的思考和言語是線性,因此在看穿複雜問題時,光是在腦中想是很容易被泥巴仗牽著走。

最好的方式是,一旦發現「同時」討論兩件以上的事情,就應該在白板畫圖或者條列。

畫圖是最好的選擇,最簡單的可以考慮心智圖或者魚骨圖。一旦有人試圖混淆事情,只要指一指說明我們現在在討論這個點,等討論完有決定之後,再往下一個點前進。而如果兩件事情有關連,就用線條與另一個點來說明此關連。

這也是為什麼,幾乎所有優秀的資訊從業人員(無論是低階還是高階)在會議中都喜歡坐在白板附近。


3. 耐心


簡單的說,就是有耐心的條理事情。透過工具(白板或紙)讓事情呈現。當知道對方採用泥巴仗手法-無論他是不是故意,就表示事情不會很快結束,因此要秉持著耐心條理問題。更重要的是,把這件事情當做類似刷牙洗臉的小事,在處理過程中沒有心情起伏 - 當然就不憤怒生氣)。






註1:特別是為求避免衝突,每人的說的話和實際心裡想的都有差距(參考left hand column),這讓組織 - 特別是資訊科技組織 - 運作上增加不必要的難度。

註2:  並不是去除重複字眼,極端簡潔就是好事。在文學作品中,言詞的優美有時候會透過層層疊疊的語句產生,請參考這裡。不過單就企業組織的溝通 - 例如開會 - 應該和寫小說是不一樣的。

註3: 參考這裡

註4: 以資訊科技來說,最基本的本職學能是寫程式,其他可以參考這裡這裡


3/07/2017

畢業前六個月 - 建構職業生涯



在台灣的碩士生,畢業前六個月通常忙於論文。如果不考慮繼續就讀博士,畢業前六個月其實是建構職業生涯的最佳機會。

更確切的說:畢業前六個月是讓你日後容易取得理想工作的最佳準備期間!

為什麼需要強調在6個月前建構職涯規劃?

環境上有許多現實的情況,例如,大部分好工作機會,其主管都傾向雇用有經驗的程式設計師。然而,絕大部分剛畢業學生並沒有實際軟體開發經驗。

因此,剛畢業的學生如果剛好獲得一個適合自己,能夠成長,能夠有所貢獻的工作,那麼就會進入良性循環。這個工作會讓這個學生更容易找到下一個好工作,或者即便不換工作,也能在目前的組織中成長。


反之,剛畢業的學生如果找到一個不適合自己,到處瞎忙,只是以時間換取薪資的工作,那麼就進入惡性循環。這個工作會讓該學生不容易找到比較好的工作,即便勉強換工作,也得靠運氣。

如果不想靠運氣,也沒有富爸爸,也不想自行創業(註1),則要做的事情很簡單:

(1) 考慮現況
(2) 設定短中期目標
(3) 建立事實


考慮現況


首先,最重要的是,取得一些關於自己的事實。是不是想要做關於軟體開發相關工作?想要做哪一類型的相關工作?是否知道自己還缺乏哪些能力?哪些地方的工作,可在短時間有巨幅成長?

如果想要當個程式設計師,要考慮的現況:

1. 能使用哪些程式語言:是真的會,而不是只寫過hello world和學校作業。並且有「事實」可以佐證。例如在github上的project,或者工讀經驗。

2. 能掌握資訊技術工具:是真的能掌握,而不是用過一兩次或者學校作業。並且有「事實」可以佐證。例如:工讀經驗,利用資訊工具做的個人專案等等。

3. 能掌握團隊專案合作方式:例如是否有Scrum相關證照(註2)。

4.....<其他還有很多請自行想像>

如果想要從事資訊業,但是一開始就做SA/PM類型的工作,在軟體開發職涯裡其實不太腳踏實地,不過,真不得已可以參考這篇:資訊科技學生畢業後只想當SA/PM (三個創意作法)



設定短中期目標


某些職涯教練,或許會建議新鮮人設定長期目標。甚且透過各種神奇的方式推展或瞭解自己的熱情(passion)所在:例如希望自己五年之後賺10億之類的。

大部分的長期目標雖然有趣,但是用處不大。設定可預計的中短期目標更為重要。

以6-12個月為期,讓自己在畢業前達某些技術性和非技術性目標,對未來職業生涯非常有幫助。以未來想要當程式設計師的學生為例,在畢業前六個月可以訂立以下目標:

* 開發並且將一個Android APP放在googlestore上:熟悉在android平台上開發APP,因此需要熟悉Java。

* 取得Scrum Master證照

* 閱讀3-4本關於軟體QA的書籍,並且運用在現在的專案上。(含建構測試案例,執行測試,系統化記錄錯誤,...)

訂立目標必須要是

(1) 有非常清楚的結果。如果目標是「熟悉java」,則最後有沒有達到此目標是非常模糊的,但是目標是開發android APP並且上架,就表示必須要寫java到某個程度才行(註3)。

(2) 可以在6個月之內達到。不要設定一個花10年才會達到的目標。如果真的有長期目標,當然可以設定長期目標,但是需要伴隨可以逐步前進的短期目標。例如,或許你想要成為java大師中的大師,這可能要花上數年,但必定可以有個6個月能達到的前期階段,例如:「不靠任何補習方式,就取得SCJP」

(3) 其結果會伴隨建立事實。請參考下一段


建立事實

在畢業前六個月,是最適合建立「事實」的時候。

建立事實,和畢業前花時間美化履歷表有很大的不同。

美化履歷表,是可以靠一兩個禮拜,找一些專業人士協助就可以很輕易的達到。但如果自己的「事實」不夠充分,再怎麼美化也沒有意義。

前一段關於短中期目標,只要你的短中期目標定義夠清晰。這些就是你要建立的事實。

如果你是在未來6個月即將畢業的學生,對自己的技術能力非常沒有自信,然而又想從事軟體工程師的工作,可以考慮建立以下三個事實:


* 透過自己決定的開發專案(例如Android APP),徹底實踐品質管理(QA) 

     (a) 找一個不用錢的QT工具:可以參考這裡
     (b) 在開發專案的過程中,徹底運用此工具,確保自己的專案品質。
     (c) 將結果詳盡記錄,就成為自己能當QA的事實


* 透過自己決定的開發專案(例如Android APP),徹底理解並且妥善運用git(或任何版本控制工具)

      (a) 版本控制是軟體專案的基礎中的基礎
      (b) 需要徹底了解如何branch,如何merge,如何處理conflict
      (c) 其結果構成了解專案開發的基礎事實

取得Scrum Master證照

     (a) 參考這裡
     (b) 雖然大部分的管理類型的證照意義都不大,但是取得成本不高的情況下,展現了你至少是瞭解Scrum。






註1: 想要自行創業的準備不太一樣,首先要了解創業如何必然成功,再參考其他相關資料

註2: 花大錢考管理類型證照其實不划算,但是可以考慮花小錢,請參考這裡

註3: 對,我們知道React Native可以讓你不需要寫java,但是這裡只是舉例而已。