AWS Lambda Function Step by Step

Background

最近有個需求，因為要求全網站走https
但網站允許外站圖，因此沒辦法要求某些圖檔走http
原本在公司內做了轉抓圖直接回吐的程式，但因為從公司Server連外
因此得開Proxy，外站圖實在太多，沒辦法一一開通，也不太有道理全開
原本做法是在外網架個server跑，但Serverless service似乎更適合這需求
所以就找上AWS Lambda Function

在寫Serverless service過程，主要卡在觀念上，瞭解了就滿容易的
先從架構下手比較容易上手

應用架構

三個元件組成，如下圖

簡單來說，Lambda只是程式，
需API Gateway來處理http的request及response，
而Cloudwatch就可以monitor及看ap log，還可以設定dashboard及alarm

基本上只要寫好Lambda fucntion及設定Api Gateway就可以動了
那就開始吧~

1. Lambda function

1. Create function
   剛開始先選樣版來練習(在Blueprint輸入hello)
   
2. Config
   下一步填寫function name及role
   第一次建立會有role的問題，所以要先create new role
   選擇"Basic edge lambda"即可
   
   完成後，就可以看到hello的code，另外右上方有test
   可以設定測試案例
   
   
   
   1. 建立新的test case
      
   2. 系統已預算，直接created即可
      
      
   3. 測試
      
   
   
   沒問題就算完成了，再來就要設定Api Gateway
   

2. Setup Api Gateway
Api Gateway是來處理http request，再轉call lambda function
所以要設定相關的http request/response header及parameter
知道Api Gateway的定位，就容易設定了

1. Create API
   找一下Api Gateway(1的部份)，然後建立API(2的部份)
   
   
   
2. 先從最簡單的get開始
   醜醜的動畫...
   


3. 指定lambda function
   這個有好一點
   
   因為我的lambda設置在ap-northeast-1(不知道的話，就點回labmda function找一下)
   下方的function就會自己帶出來~
   這樣就完成了




4. 測試一下
   click "TEST"
   
   
   再次click "TEST"，右邊就是結果
   Response body是null，是因為原lambda function要帶參數，所以是回null
   
   


5. Request/Response參數
   放另一篇，太多看起來挺煩的
   

3. Cloud Watch

1. 看ap log
   進入CloudWatch Service, 點選"Logs"，找對應的Log Group
   如下圖，所有AWS的log都會放在cloudwathch，所以要分group
   
   log會用時間序切開，這樣比較方便以時間點切入找log
   有時log沒這麼快出現，就點一下1的refresh圖示即可
   
   
   進入就可以看到lambda function記的log
   在1的部份，由於未帶參數，所以三個value都是undefind
   如果有帶的話，就會如2的部份
   
   
2. 設定dashboard
3. 設定alarm
   好歹出了問題要知道
   

== Cache設定 因為是認url,應該認到uri (含?後帶的參數)，所以得在method裡選cache

git submodule

把別人的code放進自己的git repository會加入追蹤
但這樣挺怪的，而且將來3rd parity code會有更新問題
後來才發現原來git有submodule的東西，用一陣子後還挺好用的

• 新增
  git submodule add <repo> <local>
  
  

  注意!! 得在原git repo的根目錄加submodule，才不會造成git路徑錯誤

• 更新
  git submodule update --init --recursive
  

  第一次git clone後也要下，不然會是空的

升級PHP7及Phalcon3已知問題

PHP 7

1. COUNT field incorrect or syntax error
   placeholders must have unique names even if they have the same value
   不確認是PDO還是Phalcon，但知道placeholder不可重覆
   

   
   $sql = "SELECT * FROM m
   WHERE m.prod_market_sdate <= :nowDate         
   AND m.prod_market_edate >= :nowDate
   $statement = $db->prepare($sql);
   $result = $db->executePrepared(
   $statement,
   array(
   'nowDate' => date("Y-m-d H:i:s", time())
   ),
   array()
   );

   Reference: https://stackoverflow.com/questions/34089614/count-field-incorrect-or-syntax-error
2. Static property
   

   
   - $this->$fileErr => $self::fileErr

Phalcon 3

1. 不可以有重覆的andWhere
   雖然不應該有這問題...
   不過有時候條件太多，看走眼...
   

   
   $builder->andWhere("name = 'Peter'");
   $builder->andWhere("name = 'Peter'"); //重覆會有錯
   

讓Stub跑原本的Code

本來Stubbing寫好好的，遇到要call stub裡未stubbing的method
一時還不知道怎麼寫，因為會遇到undefined mock function
原來直接用getMockBuilder就可以了

class aaa {
  public function test1(){return true;}
  public function test2(){return true;}
}

class StubTest extends PHPUnit_Framework_TestCase
{
  public function testStub()
  {
      $stub = $this->getMockBuilder('aaa')
        ->setMethods(array('test1'))
        ->getMock();

      $stub->expects($this->any())
        ->method('test1')
        ->will($this->returnValue(false));

        $this->assertFalse($stub->test1());
        $this->assertTrue($stub->test2());
  }
}

加上Namespace後，getMockBuilder裡的class，要加完整的namepspace才會真的取到, 不然會做個假的(test2會是undefined function)

打造當責影響力

如果你真的想做一件事，你一定會找到一個「方法」
如果你不想做一件，你一定會找到「一個藉口」

今天上了內訓課程- 「打造當責影響力」
講師是李河泉老師
原本上課的計劃是學著怎麼帶人，讓同仁有當責的觀念
反而是上了一堂怎麼帶小孩的課程，倒是滿實用的... 回家馬上試試

新人難帶，自己是共犯

學員有人反應常發現有新人不會主動做事
想指責，新人倒是很自然的回應：「沒人跟我說要做」

講師便提到觀念來自- 1.家庭2.經驗
在場多為人父母,請問你家的小孩會主動做家事嗎？為什麼會這樣？
小孩從小就知道他沒做，爸媽就會做掉，自然沒有負責的心態，出社會就同一個樣子

卸責是人之常情，就是要讓他扛起責任，沒人會幫他，他就會扛起責任

從負責到當責

高鐵清潔員快步走VS觀望走

為什麼要當責

責任三層次

1.卸責- 「找藉口」避免被怪是人的天性
一般人「逃避」、「抱怨」
成功者「改變現狀」

工作中，六種一般心態

• 領多少做多少事
• 那不是我的工作範圍
• 有指示再做事
• 該有人告訴我怎麼做
• 下班該是我的時間吧
• 為什麼他這樣也行

改要從心態改起
為最終結果負責- 團隊中，每個人都從get reasons轉移到get results

抱怨是本能，解決是本事

2.負責- 只做好份內工作
人該積極主動最主要的理由

1. 薪水
2. 自己

「所有人」指責「某個人」，卻「沒有人」去做「任何人」都可以做的事

「負責」與「當責」 比一比

把事情做完	把事做完並做好
有義務採取行動	有義務確保這些行動能交出成果
只對「自己」許下承諾	對「自己」和「別人」許下承諾
只願意執行被交付的任務，沒有功勞也有苦勞	成果至上，不管多少困難，一定要交出成果

沒有人認為自己不負責，只是認為那些非份內之事

3.當責- 每個人「多做一點」，為結果「盡責」

如何當責
不斷自問的態度- 我還能做些什麼，好超越我的環境，取得我想要的成果
沒人能強迫你做事，除了你自己

每次主動扛起問題的呆瓜，有一天才發現他是學最多的人

團隊

奧茲法則- 人沒有完美，看你如何組合團隊


動態競爭
把成果跟其他人比，而不是跟自己比

人生不是得到($)，就是學到(經驗)

難題不是解開就是跳開，當一路跳開，最後剩的只有難題

把時間花在哪，成就就在哪

當責- 王牌法則

• 當仁不讓，責無旁貸
  每個人都練習把自己的責任往外擴張，讓團隊完整的圓沒有缺陷。
  花公司的時間，做自己的事情=>花公司的時間，學自己的本領
• 當然為最終結果負責
  團隊中，每個人都從get reasons轉移到get results

雪崩時，沒有一片雪花覺得自己有責任
--法國文學家伏爾泰(Voltaire)

當責- 團隊篇

3M當責文化，信件從董室會到收發室
盡責地把重要文件準時寄出
進一步確認對方收到

超越主管的期待，找到你的不可取代性
「累己」才能「累積」自己的實力

當責的最佳團隊(雁行理論)

借著V字隊形，整個雁群比每隻雁鳥單飛時，至少增加了71%的飛行距離
而顉頭的雁鳥最累，要交換時，會由誰來取代- anyone都可

CSPO課程心得

為什麼上CSPO
去年上了SCM課程，上完課發現「挺好的」(呂毅語氣)
學到滿多東西的，特別是Scrum每個meeting的Goal及Why
例如，講師詢問Daily meeting的Goal
自以為的回答「觀察每日進度及即時調整！」，又被追問那Why？為什麼要做這件事
才發現回答的都是What，回答不出來為什麼
Daily meeting的Goal是觀察及調整沒錯，但要知道目標才知道如何調整
目標到底是什麼 - 滿足這個sprint backlog item呀

被糾正觀念後，就覺得這課程真的滿不錯的
因此決定再來上PO的課程

學到什麼呢？以下做個筆記
Origin of scrum
The new new product development game
只給日期，時間到了要有Shippable product
其他讓Team自己決定(Cross-functional/Self-originated)
雖然之前SCM就有聽過了，但再聽一次，總是refresh一下Scrum最核心的精神

Empirical process (野雁)
開發Product如同野雁南飛一樣
做一段，檢查一下(Inspect & Adapt)
離目標多遠，需要調整以更接近目標
Scrum很多Practice就是要這事兒發生, ex. daily scrum, burn down chart, ...

Sprint中，PO需要參與嗎

• Product Backlog Item(What)
• PO的職責
• Sprint Backlog Item(How + What)
• Dev的職責

也就是Sprint中，Dev有需要再問PO，PO不用插手Dev

PO關心What，不是How

Demo meeting改叫Review meeting

回到剛的Daily meeting的Goal是要完成sprint backlog item
而Demo meeting的Goal呢？
除了demo外... 應該要Inspect與Goal的差異
因此應該叫Review meeting比較合適

Scrum framework 欠缺Why
Why是離Goal的差距，因此Review meeting是PO Inspect & Adapt的時機

再看各個meeting的重點 - 以終為始
說很簡單，但實做才發現自己都漫無目標的在做
雖然有inspect，但都沒在與goal比較，只是求局部最佳

Goal不是只有指如期完成，而是如期交付最適合市場的Product，也就是說最後交付的Product有可能已經不是當初定的Goal了

換位思考
這次上CSPO最大的感受... 就是每個問題的答案都跟我的想法有出入
甚至有時聽不太懂講師在說什麼，上SCM還沒差這麼大
後來才意識到我還在用developer的角度思考
我只想著要把MVP做出來，而PO想著是有Business value的feature
而且... 做出來要能feedback到之後的sprint

為什麼！？調整產品的走向呀~~
我還是只能想到自省會議的改善項目(Deliver的部份)
PO要想著Discover的部份

PM的價值在於Project成功，PO的價值在於Product成功
課程中有討論Product Owner與Project Manager的不同
點出兩者職責的不同，因此重視的東西便不同

「PM的價值在於Project成功」
這句話真是有fu
感受到過去被PM壓榨的fu
感覺上PM只在乎有沒有如期交付，但不會深入討論有價值的feature
只會逼著developer交付，把develop team當可以置換的人力
成功都是他的，失敗都是別人

但什麼才是對的，Project成功了，但Product失敗了,這能叫成功嗎？

PO應重視Business Value

課程中有玩Business Value Game,這跟之前玩的Kanban Game滿像的
遊戲裡有些可以改善開發效率的feature,很直覺的就應該先擺在前面先做

但遊戲結束後，才發現分數並不高
因為遊戲故意設計重點在Business Value(有做完才算!!!)
所以要評估如何讓Business value最大化
這裡的陷阱在回合有限，做完改善後，遊戲(專案)已經結束了
改善的項目是沒有business value的!!!

因此PO常不理develop team的改善需求
雖然現實也是這樣，但對PO還是有很多抱怨

事後討論，這類型的改善，應該在每個sprint一點一滴的做掉是最好的

這遊戲真厲害，一次讓兩個角色搞明白(呂毅語氣)

Product Version
影片 - IDEO Shopping Cart
影片提到如何在幾天內重新設計Shopping Cart(重點當然是在如何進行重新設計)

• 收集客戶問題，想辦法解決
• 不要自己想，太花時間了
• 看客戶怎麼用，自己也下去玩

Excise: Spec Writing Game
分成兩組人，一組寫文件，一組實作

• 題目
• 左邊是題目，右邊是我們的成果 XD
• 規則
• Timebox : 10分鐘
• 兩組人只能透過文字(件)溝通
• 不可畫圖(當然!!!)
• 可以修改文件
• Writer可以觀察實作者的情況，再修改文件
• 實作者不可提問

結果
太晚給Spec，有疑惑來不及修改文件
忘了把文件拍下來... 不然大家可以來畫畫看...
記得文件寫左上角的六角型直徑1.5公分
但Writer看我們畫完，才發現.... 他們是要寫半徑1.5公司... 所以大小差很多

上方的星星跟下方的甜甜圈則是連文件都來不及寫...

心得

• Writer會想把文件一次寫清楚，但花太多時間且有認知落差，發現實作誤解再調整文件
• 越早開始，越早修正認知落差
• 能當面溝通或畫圖描述都是很直接的幫助 => 用文字(件)不一定是最好的方法

又是一個一次讓兩個角色搞明白的遊戲(太強了)

Story是Delta，不是Baseline
透過Acceptance Test留下活文件