魚乾的筆記本

星期二, 1月 28, 2020

[書]大腦不邏輯

英：Neurologic
Eliezer J. Sternberg

重點

討論大腦如何運作，解釋行為怪異、催眠
解釋被外星人綁架的情節/瀕死經驗，為何都大同小異；
有些人會胡言亂語，但卻不像在說謊；
有些人會斷片，想不起剛發生什麼事；
記憶混亂，把別人的事套在自己身上

我也有發生過，畫面歷歷在目，但仔細回想我人根本不在那，那是朋友說的故事

利用想像力訓練，一樣能提升能力.ex 投籃
實際訓練約提升肌肉50%，心理模擬約15%

心得：
心理學滿有趣的，瞭解大腦如何運作，利用些技巧說服大腦，例如恐懼，戒煙，選擇性，甚至運動訓練

星期五, 1月 24, 2020

== 心得 ==
一個超過60萬人的企業，能夠不斷且快速提出新的服務，且樣樣都是全球領導地位，必然有過人之處

1.讓員工動起來
管理是被動，員工自己能動起來，只需給目標，追蹤指標就好
要讓員工自己動起來法則1：鼓勵「成功的失敗」，讓員工敢做；、法則10：倡導業主精神，讓員工想拚；
對

2.聚焦於客戶
為客戶解決問題，取得顧戶信任；不得以「公司政策」、「程序不允許」做為對待顧客的藉口。政策與程序是為了指決策而訂定，以顧客為念才是終。
自己曾到瓦城吃過飯，飯後店員詢問餐點是否滿意，回高麗菜苦苦的，店員二話不說直接取消不算錢，真的對瓦城充滿信任；

3.加速
速度比完美重要；公司越大，做決策花費時間越長
第一線員工會比管理階層清楚，用數據說話，用指標追蹤勝過用直覺判斷
用技術加快時間，不是加人加預算，限制可以滋生足智多謀，自給自足的發明

4.保持「第一天」心態
像新創公司般行動與思考，一旦喪失「第一天」思維，進入「第二天」意味停滯、衰退、最終就是死亡

== 筆記 ==

成長循環：測試
第一章法則1：鼓勵「成功的失敗」
自許為最善於失敗公司，鼓勵「成功的失敗」從中學習
別在意起初的幾步有多不適與笨拙
第二章法則2：下注於宏大構想
第三章法則3：實行動態發明與創新

成長循環：建造
第四章法則4：以顧客為念
為顧客解決問題取得顧客信任
第五章法則5：採取長期思維
第六章法則6：了解你的飛輪

成長循環：加速
第七章法則7：產生高速決策

第八章法則8：化繁為簡
第九章法則9：用技術來加快時間

第十章法則10：倡導業主精神
讓員工成為企業主，有動機打拚，而不是領薪水
努力工作，玩的開心，創造歷史

成長循環：規模化
第十一章法則11：維護你的文化
第十二章法則12：聚焦於高標準
第十三章法則13：評量重要的東西，質疑你評量的東西，信賴你的直覺
第十四章法則14：永遠保持「第一天」心態

星期日, 12月 30, 2018

征服股海 - 彼得林區

心得

投資你瞭解的產業及企業，才能發揮自身優勢
作者建議觀察日常生活的食品、用品，就能體會該企業是否有未來，進來買進其股票；

筆記

金科玉律：
    1.投資既有趣又刺激，但若不下苦功，就可能有危險。
    2.華爾街專家的意見、看法，絕不能帶給散戶任何優勢。投資你瞭解的產業及企業，才能發揮自身優勢。
    3.過去30年來，股市漸為專業人士和法人把持。大家都以為強敵環伺下，散戶相對不利。其實在這種情況下，散戶反而容易在夾縫中找到自己的天地。勇敢地邁開步伐，你也可以擊敗大盤。
    4.股票只是表象，上市公司才是實質，閣下要做的，就是搞清楚企業狀況。
    5.在短期內，或是幾個月，甚至幾年的時間內，上市公司經營的很成功，股價不一定就會有所反應。但長期而言，企業成功與否，跟股價會不會漲，絕對是百分之百有關。而利多不漲，正是賺錢的好機會。要買好公司的股票，還要有耐心。
    6.買股票時，要知道為何而買。光說：「這股票一定會漲」是不夠的。
    7.不熟悉的產業或企業，勝算通常不高。
    8.買股票跟養孩子差不多，別生太多讓自己手忙腳亂。業餘投資人大概有時間研究8家到12家上市公司，注意買、賣良機。但持股不必超過5支以上。
    9.如果找不到好公司的股票，儘管把錢擺在銀行，等發現再說。
    10 不瞭解其財務狀況之前，不貿然買進該公司的股票。資產負債表結構不佳的公司，就是會虧大錢的股票。
    11.不要一窩蜂搶買熱門產業的熱門股。低迷、停滯產業中的好公司，通常就是寶。
    12.小公司要等真正開始賺錢後，才去投資。
    13.投資夕陽產業，一定要找耐力夠的好公司。不過也要等整個產業有復甦跡象才行。
    14.同時操作太多股票，很可能忙中出錯。一生中只要能掌握幾支好股票，就夠您吃喝不盡了。
    15.在各個產業、各個區域內，一定還有投資專家還沒發現的寶藏，靜靜等待散戶發掘。
    16.空頭市場跟冬天寒流一樣正常。如果閣下預作防備，是傷不了人的。股市重挫，大夥驚慌殺出，正是撿便宜的大好機會。
    17.想賺股票的錢，誰都有辦法，但膽量可不是人人都有。若閣下很容易在驚慌中殺出，請遠離股市，連基金都別碰。
    18.世界上總有些事令人擔心，但別讓週末恐懼症把你嚇倒，也不要管報上那些聳人聽聞的預測。賣股票，是因為該公司基本面有問題，而不是天快塌了。
    19.天曉得利率、經濟景氣或未來怎樣，不如把精力放在上市公司，仔細研究閣下投資的企業最近狀況如何。
    20.十步之內，必有芳草。研究10家企業，總會發現其中有1家會比預期還好。若能研究50家，可能就會挖到5家。
    21.作股票但不下功夫研究，跟玩牌卻不看牌一樣。
    22.長期來看，精挑細選的股票，一定比債券或貨幣市場基金好。但若閉著眼睛亂買股票，可不比把錢藏在床底下高明。

星期二, 11月 27, 2018

[書]趨勢交易正典

趨勢交易正典：成為多空百萬贏家(全新增訂版)

Trend Following: Learn to Make Millions in Up or Down Markets (Updated Edition)

投資人一定曾聽過「海龜交易員」一詞，但鮮少人真正了解海龜交易策略的背後的精髓。由超過百萬流量的海龜交易者網站創辦人親自揭露，何謂贏家正宗「順勢系統」交易模式，同時也是一部詳解「順勢系統、績效分析、人類行為、決策制定」的獲利操盤策略！

心得

證據顯示順勢操作方式表現相當不錯，當價格跌破10期ATR追蹤型停損則結束部位，可以創造顯著的平均報酬

紀律

虧損部位永遠不加碼

達停損點便出場

筆記

Ch10 交易系統

五個問題掌握順勢交易系統的核心成份

任何時刻，如何決定買賣哪個市場？

沒人知道哪個市場會有足以彌補其他市場損失的重大趨勢，因此需分散交易

任何時刻，在個別市場買賣多少數量？

保守下注，帶來保守績效

大膽下注，會導致可怕毀滅

投資組合，ex. 最大10%，5部位承擔2%

依能心理能承擔的部位

如何決定買賣的時機？

趨勢確認時. ex 50 -> 70

不可能抓到底部

不要等行情折返，可能會買到更高

何時賣

抱到趨勢改變

約只有30~40%會賺錢

如何決定何時認賠虧損部位？

忍受承度2%~8%

騎在精力旺盛的野馬上

如何決定何時獲利了結

ATR 10 期

次高出場

補充

ATR停損

期間長度(8~12)沒有顯著差異，就用10期吧

停損大小

愈大勝率越大，但獲利/虧損倍數稍低

愈小勝率越小，但獲利/虧損倍數稍高

星期二, 11月 13, 2018

2018/11/13 自由人希望與能量分享會

自由人是做台指當沖交易

所以要用當沖來看其交易邏輯

心得

當沖交易，看的時間短，思維就會不一樣，要找出適合自己的交易系統，教了8種交易盤勢，練好擅長的盤，才能提高贏率

特別強調因國際資金操盤，只能順著勢做，而順勢又會刻意洗，所以不要重倉玩，利用加碼的方式跟著

以下筆記

一.月KD

交易就是停損或停利

看一堆技術反而亂
短線不看指標，太慢了，但長週期的kd有效，看月kd

台指改變，沒跟上就被淘汱

結構改變

高頻交易

10年速度慢，現在有高頻交易
有程式會刻意洗，人會有情緒，就認輸吧

盤後盤

國際資金可以玩整天

市場會淘汱不適合的人，不改變淘汱

看盤易被洗，不如不看
打不贏，沒有交易，沒有傷害

二.交易的期望值

自由人交易邏輯

停損沒來，就是停利來

看不懂就抱
看的懂就加碼
虧損就出場

試單一口

錯了就停損，對了加碼
自由人虧損抓30~50點

三.改變當沖交易的損益結構

成功交易

1.無數次的小賺小賠
2.偶爾大賺(靠加碼擅長的盤)
3.零大賠(千要避免，發生要仔細檢討)

大賠原因

重倉、過度交易、拗單

散戶三大絕招(千萬別做)

拗單，攤平，入金

如何大賺

找適合的交易系統

練好交易系統
找出擅長的盤面

檢討

統計檢討失敗記錄的共通性，改不了就避開不做
動作行為

做了什麼賠

交易時間

搞長做前1個小時
做2小時開始虧

以前做會賺，現在開始賠

市場變了，要調整

心理建設

停損就不做，不看了
盯盤只為了加碼

四.建立自己的交易風格

成功者的共通點 - 交易的一致性

選擇商品，週期

証券與期貨思維不同

賠錢一定會發生，掌握加碼，長期會贏

交易風格

方向一致性

只做多，50%勝率
雙邊做易被雙巴

順勢交易的一致性

順勢，高頻會刻易甩很大

股票拉拉看才知道有沒有人跟

沒人跟就反向空，勝率高

重倉要小心

盤整交易的一致性

80%是盤整盤
勝率高，但賺的少

A轉V轉交易的一致性

跳空反向一口，易是最佳點

每個轉折就加碼，打不死，換我打你

積極型與等待型

做多

積極型

開盤就持多單
往上突破

等待

爆量不跌，就多

爆量(3000)
但2018年沒效

只做v轉，守今低停損

做空

積極型

開盤就持空單
往下突破

等待

爆量不漲
只做A轉，守今高停損

每人風格不同

找出自己的風格，練擅長的盤

敏感度長，擅長才會賺
不擅長就不要做

出場

減碼

二壘是最高機率

五、結語

空頭波動大，做台指好賺

多頭賺的多，空頭賺的快

心理建設

有明確的停損，交易不再有恐懼
有明確的停利，交易看的到未來

現貨v.s. 期貨

期貨是沒錢人做的，小錢去搏

一直被綁住，沒有生活品質

買現貨慢慢抱比較輕鬆

趁崩下來就要撿

補充

反市場操作

美股漲就空，跌就多，勝率7~8成

操作注意事項

舊多單停損了，就可以新多單
margin call完，就會反彈
關卡價

選擇權抓整點(00/50)，所以突破都可能有一波
可當停損、停利點

星期日, 11月 11, 2018

[書]幽靈的禮物

心得

90年代，美國期貨論壇有位不願暴露自己身份的神祕人物，大家稱「交易圈中的幽靈」
而幽靈願供獻交易智慧、經驗及觀點，因此有了這本書

透過兩條規則說明交易，容易簡單。在實戰時，簡單才實用

規則一：只持有正確的倉位
覺得不如預期就出場，原本覺得只適用短線，其實不論任何情況，不如預期就先走，作者更提到不要等到錯(虧損)才出場。走為上策，仔細想想是滿有道理

規則一評論：容易被洗，但作者也提出看法，寧可出場放棄，因交易成本遠小於看錯的虧損

規則二：正確加碼才能獲利
重倉及加碼都可以增加獲利，但重倉易重傷，我們需要永久留在市場上，加碼才是正確做法，作對就繼續!!!

永遠守住規則一，機會來了，放膽用規則二

p.s. 最後補充的聖誕禮物故事，雖然跟理財無關，但滿感人的，值得一讀

筆記

Ch1. 你是誰？交易圈中的幽靈

交易的本質，就是犯錯

Ch2. 備戰交易：大師的匠心

安靜的辦公室：交易會秏盡所有精力
舒服的椅子：你無法控制市場，只能等停利或停損
電子鐘：自動報時，提醒先反應，不要等市場告訴你，寧可錯殺(最小虧損)
去除失敗的陰影：不要再想，暫停一下，花個10分鐘讀書也好

Ch3.規則一：只持有正確的倉位

雙向思維：如果輸了怎麼辦？

對輸的那面做好準備，自我保護，不能只準備機率高的情況

交易者不是律師，根據的只是假設而非事實
正確的持倉

讓市場告訴你交易正確，但不要等提醒錯誤

ex. 期望漲，但過1hr沒漲，就應該清倉

交易是「失敗者」遊戲，不是「勝利者」遊戲

如果沒被證明是勝利者，就是失敗者(錯，快走!)

Ch4.規則二：正確加碼才能獲利

當沖適用重倉

以獲取最大利潤，但易重創，不建議

長期適用加碼
輸贏均等的遊戲

事實上輸多贏少，所以儘量增加利潤，才能彌補損失

太小不如不做

由市場決定倉位大小

Ch5.規則一加二實戰

別想控制市場，控制好自己的資金

想像不同就走(守住資金)，寧可錯放，走為上策，易被洗，但交易成本遠小於看錯造成的虧損

永遠守住規則一，機會來了，放膽用規則二

Ch7. 當沖交易：規則成就短線高手

將規則一、二融匯貫通

Ch8.妙手連連，贏定期權

用不同角度看待問題，會讓你站在更有利的位置

Ch9.線圖交易：大師的天機

透過大眾指標觀察別人，透過自設線圖發現自己的優勢
短線吃運氣

Ch10.一聲棒喝：改變你的行為習慣

發燙的馬蹄鐵

運用建倉訊號，失效難免，要學會保護自己

經得失敗的人是最大的獲勝者

Ch11：樂觀自信，才能笑對交易險境
Ch15：巨量即是套現良機

有巨量，二天內清倉

Ch17：交易計劃

昨收與今開，支撐與阻力

投資理財書單

觀念(觀念很重要!!!)

富爸爸，有錢有理

瞭解被動收入

有錢人想的和你不一樣

標題很膚淺，但卻是很棒的勵志書籍，個有被影響到

思考致富聖經
窮查理的普通常識

簡單入門

艾蜜莉教你自動化存股，小資族也能年賺15%！
我的職業是股東
從零開始穩穩賺
我用死薪水，輕鬆理財賺千萬

適合新手，特別是不會投資，想把錢丟到基金或債券，指出應該買指數性基金，不要買主動性基金，因為... 「客戶的遊艇在哪裡」

交易觀念

幽靈的禮物

以對話方式傳達內容，讓讀者感受到一對一的幫助，主要想表達看錯就該停損，且不要等到市場反應才走；大獲利要透過加碼，不是重倉，輕倉操作，才持盈保泰

交易‧創造自己的聖盃

作者是知名的投資顧問，研究多位交易者的紀錄並訓練投資人找到適合自己的交易系統，成為成功的玩家
在分析提出很多判斷上的迷思，避免投資人的自以為，除了教進出場方法，更分析其優缺點，可以發現你想的到的，人家早就想到了，而且更有系統
作者也指出多數人花力氣在找分析市場的方法，但這卻是最不重要的，除了心理層面外，資金管理才是交易最重要的部份(如同兆捷分享的)，金融市場成敗關鍵是認賠出場或獲利了結

笑傲股市：歐尼爾投資致富經典
歐尼爾投資的24堂課

每章節利用簡單的篇幅說明重點，讀起來不費力，從心態、交易系統、趨勢、選股技巧都有提到

金融怪傑/新金怪傑史瓦格

短線

短線交易秘訣

長期

經濟指標教你加減碼
只買4支股，年賺18%

交易系統

技術分析

趨勢交易正典

順勢交易法，<<海龜特訓班>>作者的作品，雖然說是正典，但沒有講做法，就是「順勢」直到驅勢改變；歷史資料顯示比其他方法的報酬率都好，做不好太多是個人問題

海龜特訓班
期貨基本分析/期貨技術分析史瓦格

價值型投資

有關投資與人生最重要的事
巴菲特的投資原則
小資女艾蜜莉 – 我的資產翻倍存股筆記
巴菲特給股東的信(2017全新增訂版)
智慧型股票投資人
掌握市場週期 - 霍華.馬克斯
征服股海 - 彼得林區

星期一, 10月 01, 2018

[書]刻意練習

https://www.books.com.tw/products/0010752714

心得

透過練習紮實熟練度，但如何有效練習，有時練習的效果不會持續進步，如何突破瓶頸

筆記

目標練習

有目標的練習才會進步，而不是單純練習(天真練習法)，ex不彈錯，少5桿

突破瓶頸

不在更努力，而是嘗試新方法
克服障礙最理想的做法，就是以不同方式應對

練習還不夠，要挑戰極限
心智表徵有助認出模式，迅束回應

專家見林，普通人見樹

仰賴回饋

找更細微的錯誤與缺點

頂尖，傑出、優等的差異在大量練習

課後獨自練習的時間 => 心態：唯有如此才會進步

以頂尖前輩為師
Top Gun訓練

與頂尖飛行員模擬，不斷提問做對什麼，做錯什麼
強迫思考，自然就會思考

傳統方法著重知識

刻意練習聚焦技能表現及如何精進

開始分心或覺得輕鬆好玩，大概就代表沒有進步
放空練習沒有幫助，要專注在目標ex 技巧等
沒有老師，自己設計

專注投入，意見回饋，解決問題

突破高原

利用新的方式挑戰自己

找到持續不懈的動機

假設某件事是天生的，等於對自己說束手無策
練習控制在一小時內，人無法全神貫注超過1hr

撥固定時間

找出干擾並減少影響
動機 => 持續與停止的理由
相信自己會成功

旁人鼓勵
同好，社團組織

互相督促外，也可以分享做法、看法

拆小目標

星期二, 2月 06, 2018

Golang Fibonacci Closure

A Tour of Go玩到Fibonacci closure exercise
被前一個範例影響，一直在想把值保留著
但fibonacci是前兩個項目值相加，所以累加沒用，也沒辦法再減前一項的值
想了好久，瞄了解答才瞭解要用「暫存值」

有了"提示"就比較好寫了 XD

package main

import "fmt"

// fibonacci is a function that returns
// a function that returns an int.
func fibonacci() func() int {
    n := 0
    sum := 0
    x := 0
    y := 0
    return func() int{
        if n <= 1 {
            sum = n
        } else {
            sum = x + y
        }
        x = y 
        y = sum
        n++
        return sum
    }
}

func main() {
    f := fibonacci()
    for i := 0; i < 10; i++ {
        fmt.Println(f())
    }
}

看解答的下方還有人回更簡單的回覆
真是太強了...


func fibonacci() func() int {
    x, y := 0, 1
    return func() int {
        x, y = y, x+y
        return y - x
    }
}

p.s 話說這個swap的寫法真方便

Reference
Exercise: Fibonacci closure
An answer of the exercise: Fibonacci closure on a tour of Go

星期一, 1月 29, 2018

Coding style guide

忘了從哪抄來的 XD
把自己常用的語言排前面
不過GO真的是不錯，存檔時就先排好，寫不對還不給你Compile
PHP我還得靠hook來做，新的語言就是不一樣

Style guide
Code change should conform to the programming style guide of the respective languages:

Go: https://github.com/golang/go/wiki/CodeReviewComments
PHP: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md
Java: https://google.github.io/styleguide/javaguide.html
JavaScript: https://github.com/airbnb/javascript
Android: https://source.android.com/source/code-style.html
C#: https://msdn.microsoft.com/en-us/library/vstudio/ff926074.aspx
C++: https://google.github.io/styleguide/cppguide.html
Haskell: https://github.com/tibbe/haskell-style-guide/blob/master/haskell-style.md
Groovy: http://groovy-lang.org/style-guide.html
ObjC: https://github.com/NYTimes/objective-c-style-guide
Perl: http://perldoc.perl.org/perlstyle.html
Python: https://www.python.org/dev/peps/pep-0008/
Ruby: https://github.com/bbatsov/ruby-style-guide
Scala: http://docs.scala-lang.org/style/
Swift: https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/TheBasics.html
TypeScript: https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines

星期日, 1月 14, 2018

該來打地鼠了 GOGOGO

最近有認真讀了一下golang，感覺真的滿不錯的
針對現在的開發/佈署環境特性設計的，果然可以稱一下modern language

最吸引我的地方是套件及佈署的部份，因為這是我的痛點
在公司治理連年得名的地方，資安管理非常機車嚴謹!!!
NO YUM, NO FTP, NO INTERNET...
想像拔掉網路線把環境裝起來... 我是說真的(泣)

裝個PHP會裝起肖!!!
常遇到要裝1個rpm要抓30多個dependency packages
最近要升php 7... 真是瘋了!!!
p.s. 感謝有docker，雖然一樣得一個個rpm抓來裝，但已經方便多了

用java有好一點，只要把jar包進來就好，但maven一樣沒辦法直接抓
另外也被規定只能用jboss，對mircroservice而言不太適合
再者java開發挺花時間，要多寫很多code
以前沒感覺，接觸Coding Convention後，就真覺挺花時間的

還有還有~ compile花時間... 用慣PHP，再回來寫java就覺得開發很慢
如圖

抱怨了好多，快來看一下，只留自己想講的
其他看文章

Reference

9-reasons-to-choose-golang

Simple
效能
簡易的library管理
Go 原生大多數的Library, 還沒真的拿來開發所以還沒遇過，但即使沒有，看起就像npm裝一下就好了
沒有對外的網路，也是把library抓進來放就搞定
這對我太重要了!!!
易部署
compile後，只有一個binary檔案，不用再zip有的沒的
感覺沒什麼，不就是少寫一些deploy script!?
嘖嘖!這可以大大減少維護成本呀!!!
公司治理連年得獎的公司，上線一定還有Rollback plan，有時舊沒跑，真發生問題還不敢執行
而且這種公司一定有分權限，寫script的人，跟實際執行的人一定不同人
也就是說出錯了，懂的人看不到，看到的人不懂... 讓我死算了...

而且而且
Go把Code及library整個包進去，不同環境的Server不需要安裝套件就可以執行
光這點就不知道為此付多少血淚，我可以擺脫rpm dependency hell了!!! (泣)
更易用，更強大的執行緖 - Goroutines
Goroutine就像輕量級的執行緒，但稱其為併發，效能都是原生級的，範例如下
func main {
go loop //併發，程式會繼續往下走
}
跟java寫thread比起來，還真的更簡單，嘖嘖

其他補充

沒有Exception
我一直推不要用error code來判斷，用try-catch
try放happy path, exception就放exception，這樣程式碼很乾淨

沒想到golang居然沒有!?
一開始還滿難想像，也很難接受，本以為是一群怪咖對c狂熱導致
仔細讀一下，似乎還滿有道理的
作者認為try-catch-finally會導致convoluted code (不會翻譯，盤旋形的程式碼... 嗯大概有抓到意思)

最後直接比一下，似乎還真的比較"simple"
```
//java 
try {
} catch (Exception ex)
}
```
```
//go
if err != nil {
// handle the error
}
```
如果有多個就用switch，替代多個exception也是夠
```
if err != nil {
switch err.(type) {
case *ErrZeroDivision:
fmt.Println(err.Error())
default:
fmt.Println("What the h* just happened?")
}
}
```
不過敢拿出來嗆是因為go有multi-value returns，還真的挺方便的
如下例算平方根，如果只能return數字，那靠throw exception會比較好接
但如果可以分別回error及result，那就很好接了
```
func Sqrt(f float64) (float64, error) {
    if f < 0 {
         return 0, errors.New("math: square root of negative number")     
    }     
    // implementation 
}  

f, err := Sqrt(-1) 
if err != nil {     
    fmt.Println(err) 
} 
```
好像真有點被說服了...
讓我想起一位前輩說，科技進步，有時會推翻像地球是平的那種不可能改變的想法

Reference
- Go's Error Handling is Elegant
- Go Best Practices — Error handling
No type hierarchy
很多新觀念得再讀了
- SOLID Go Design

星期五, 12月 01, 2017

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

Create function
剛開始先選樣版來練習(在Blueprint輸入hello)
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的定位，就容易設定了

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

指定lambda function
這個有好一點

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

測試一下
click "TEST"

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

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

3. Cloud Watch

看ap log
進入CloudWatch Service, 點選"Logs"，找對應的Log Group
如下圖，所有AWS的log都會放在cloudwathch，所以要分group

log會用時間序切開，這樣比較方便以時間點切入找log
有時log沒這麼快出現，就點一下1的refresh圖示即可

進入就可以看到lambda function記的log
在1的部份，由於未帶參數，所以三個value都是undefind
如果有帶的話，就會如2的部份
設定dashboard
設定alarm
好歹出了問題要知道

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

星期四, 10月 19, 2017

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

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
Static property
```
- $this->$fileErr => $self::fileErr
```

Phalcon 3

不可以有重覆的andWhere
雖然不應該有這問題...
不過有時候條件太多，看走眼...
```
$builder->andWhere("name = 'Peter'");
$builder->andWhere("name = 'Peter'"); //重覆會有錯
```

星期五, 6月 09, 2017

讓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)

星期二, 3月 14, 2017

打造當責影響力

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

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

新人難帶，自己是共犯

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

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

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

從負責到當責

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

為什麼要當責

責任三層次

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

工作中，六種一般心態

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

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

抱怨是本能，解決是本事

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

薪水
自己

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

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

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

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

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

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

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

團隊

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

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

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

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

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

當責- 王牌法則

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

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

當責- 團隊篇

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

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

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

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

星期四, 3月 09, 2017

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留下活文件

星期二, 12月 20, 2016

Install igbinary

安裝

透過PECL
```
pecl install igbinary
```
透過Source Code

下載igbinary.tgz

wget https://pecl.php.net/get/igbinary-2.0.0.tgz

Install

#1 以igbinary-2.0.0.tgz為例
cd {install}/ 
#安裝igbinary-2.0.0.tgz
$ tar zxvf igbinary-2.0.0.tgz
$ cd igbinary-2.0.0..tgz/
$ phpize
$ ./configure
$ make && make install

如果./configure出現 no acceptable C compiler found in $PATH 需安裝gcc

檢查是否有igbinary.so

$ ll /usr/lib64/php/modules/ | grep igbinary.so  
-rwxr-xr-x 1 root root 312644 Dec 20 07:40 igbinary.so

編輯將igbinary.ini

 $ vi /etc/php.d/igbinary.ini 
 ============= 我是分隔線 =================  
; Enable igbinary extension module 
 extension=igbinary.so 
 ; Enable or disable compacting of duplicate strings  
; The default is On.  igbinary.compact_strings=On 
 ; Use igbinary as session serializer 
 session.serialize_handler=igbinary 
 ; Use igbinary as APC serializer 
 apc.serializer=igbinary    # php7後，還沒試過

重新啟動apache

 $ service httpd restart 
 $ php -m | grep igbinary #檢查是否安裝成功 
 igbinary

Reference

http://www.metod.si/how-to-install-igbinary-serializer-for-php/
http://blog.csdn.net/zhangxinrun/article/details/16964819
http://www.cnblogs.com/cndavidwang/p/3335846.html
http://bensnotepad.com/install-igbinary-for-php5-on-ubuntu/

星期一, 12月 19, 2016

Docker用Redhat/Centos7 出現 Failed to get D-Bus connection

我的媽呀~~
裝好一堆套件，想restart一下httpd卻出現Failed to get D-Bus connection
請示google大神，有人說CentOS 7.2就可以了~ 但用了是有錯

Container
最後看到個解法
必需要加上--privileged及/sbin/init
```
sudo docker run --privileged -d centos /sbin/init  
```
p.s /sbin/init也要哦~ 不然也沒用

話說docker run --privileged 是啥
看起來是讓container裡的root擁有真正的root權限
一開始看不太懂，不過想一下LXC的觀念就能理解了~
Dockerfile
解了container，寫docerfile也遇到
但dockerfile就不知怎麼給privileged! Dang it!

補充
利用--privileged及/sbin/init解後，container跑一陣子會出現agetty 100%
據說用這招就解了
systemctl stop getty@tty1.service; systemctl mask getty@tty1.service

Reference
https://github.com/moby/moby/issues/4040

星期二, 12月 06, 2016

Top 10 mistakes in handling website images and how to solve them

Reference: Top 10 mistakes in handling website images and how to solve them

挺不錯的整理，也把一些觀念一次釐清
還有說明做法~ 值得讀一下
以下簡述重點，詳細就看原作吧

Wasteful browser-side resizing
最好與指定的大小一樣大，不要靠browser自動縮放
Unnecessarily high quality JPEGs
85%與95% JPEG看起來不多，但前者17KB，後者要34KB
Incorrect image file types
JPEG: 適用風景圖，只要15KB，PNG卻要110KB
PNG: 適用圖表charts, logos，有留白的那種
GIF: 小動畫
Delivering non-optimized images
PNG可適度壓縮，讓檔案小50%
Forgetting to strip image meta-data
meta-data可能夾太多無用資訊，可以清掉省空間。
Delivering images straight from your servers
透過CDN加速。
Delivering static icons one by one
小的icons應該併成大張圖一起交付。
Using images when CSS3 can be used
不要用圖做button的圓角或mouseover的效果，可以透過CSS達成。
Incorrect image cache settings
圖片幾乎不會變，也就是說cache不需失效，但如果真的會變，可以透過fingerprint改變，就是url加上version之類的字串。
Using a single image size across all delivery mediums
利用JavaScript判斷device的解淅度，再讀取適當大小的圖

訂閱：文章 (Atom)