鳳凰專案續作，獨角獸專案 - 企業轉型三部曲

從年初開始看英文版，並且寫了兩篇導讀：獨角獸專案導讀 I II，不過閱讀速度實在很慢，結果一拖就拖到了中文版出來了， 那正好就趁著年底一口氣把整本讀完。

我覺得獨角獸專案這本書就像星際大戰一樣，可以被分三部曲：

 

《星際大戰四部曲：曙光乍現》

 

其實書中的第一部和第二部都被我歸類在星戰第一部曲，就如同我之前兩篇導讀（獨角獸專案導讀 I II）所說的，著重在鋪陳技術老舊與商業挑戰的大背景，主角在充滿 Silo 和官僚的組織努力找出機會，最終被反抗軍發現且招募，並且開始跟反抗軍找出死星的弱點：就是整個「鳳凰專案」中最重要的瓶頸與核心服務所在 （數據部門），並且透過一連串的工程手段，業務隔離..等方法，試圖抽離出一個新的業務路徑 「獨角獸專案」，並且找到一個最小可執行但是影響商業甚巨的黑五推薦產品方案，取得小勝利....

第一部曲的重點五大理念：

1. 第一個理念：區域性與簡潔性
2. 第二個理念：專注，流暢和快樂
3. 第三個理念：持續改善日常工作
4. 第四個理念：心理上的安全感
5. 第五個理念：以顧客為中心
   

第一部曲給我的啟發： 

專注在影響圈

每個公司都有每個公司的問題，你永遠可以做一個抱怨公司哪裡做不好，卻依舊困在體制內的人，或是可以嘗試做出影響和改變，其實就是專注擴大在影響圈，縮小關注圈的範圍。

 圖片來源：經理人 2012.11.12 《先改變自己，才能擴大影響力、改變他人！》

 

當然自己的力量也許是很小的，所以在這段期間內也可以尋找和吸引更多志同道合的伙伴一起做出改變，加速擴大影響圈的範圍。

善用槓桿（Leverage）

再來就是人微言輕，當你沒拿出些成績時，別人當然可以不把你說的話當作一回事，在第一部曲的反抗軍們，就找出整個公司的瓶頸處，並且判斷把數據部門獨立出來運作機會比較大，就算出錯傷害也比較小，而且還可以直接影響到商業成果，可以說是花最小的 effort 取得最大的戰功，接下來改革才有希望。

縮時職涯上課心得：你追求的是什麼？

縮時職涯這門課，嘗試讓你在 3 小時內從 30 歲走到 50 歲，有人會說這是人生大富翁的桌遊，但真的仔細研究這真的是充滿教育意義的教具，並且嘗試回答我們覺得很難的問題，也就許多人終其一生一直在找尋人生的意義，以及嘗試瞭解到底什麼是成功？而許多人就是帶著這樣的問題和迷惘來到這門課~

那上完課後我有得到解答嗎？我可以說沒有馬上有！！但～～是這是門值得玩味與沈澱的課程，而且隨著時間與生命的歷練，心得和感觸會不斷的湧現出來。

上完當下最直接的心得就是：

• 選擇與學習很重要，但是運氣更重要。 
• 為了達到目標，因為時間有限，能控制的就是技能點數要更加謹慎，繼續積極投資  
• 每個人都有自己的價值觀和理想，每個人追求不一樣的幸福，真正內心的強大是看著別人光鮮亮麗的外表也不為所動，持續朝著自己的目標前進，所以又何必在意別人的想法和開發呢？

並且浮現出這首歌的歌詞.....XD

一時失志不免怨歎
一時落魄不免膽寒
那通失去希望
每日醉茫茫
無魂有體親像稻草人

人生可比是海上的波浪
有時起有時落
好運 歹運 總嘛要照起工來行
三分天注定 七分靠打拼
愛拼才會贏

 

KKStreamer 的 AWS re:Invent 2020 知識同樂會

 

 The innovation just keep coming

今年因為疫情 AWS re:Invent 2020 改成線上的，而且是免費的，所有人只要上網註冊，就可以透過網路，從 11/30 ~ 12/18 就可以參與。由於是預錄好的關係，所以網路上有有許多人第一時間就把 AWS CEO, Andy Jassy, 主持的第一場 Keynote重點整理出來了：

• AWS re:Invent 2020 - AWS 全球 CEO Keynote 懶人包就看這篇
• 2020 AWS re:Invent 即時新聞】- Andy Jassy Keynote
  

所以我就不在這邊特別談論關於技術的感想，反而想從另一個角度來分享我們怎麼看這個 Event。

這邊就要請出我們的 CTO Drake 來講述一下 KKStream 與 AWS 的故事：

KKStream 2016年開始營業第一天，就在雲端了，就在我們每天掛在嘴巴上的 AWS。事實上，在 KKStream 這家公司還沒成立前，在我們還只是 KKBOX 的一個 Video team 的時候，就已經打算不要有地端的機房，直上雲端了。（感謝當時的智慧與勇氣，要說服 KDDI 接受 Video Pass 新版直上雲端，是一件非常困難的任務）

之後，我們差不多每一年都會有人參與 AWS re:Invent，分享一些資訊回來的同時，也帶回了一些改變。像是 Enterprise Support 的使用、AWS Managed Services、Serverless Computing (Lambda, API Gateway, DynamoDB)、Aurora、Elemental Media Services、…

 

故事講到這裡，KKStream 每年送 KKStream 的同學們去參加 AWS re:Invent ，這不但是更新技術新知的機會，更是一種榮耀與獎勵。不過很不幸的 2020 年受到 COVID-19 的影響，全世界不得不重新面對這個現況，AWS 如此 KKStream 也如此，所以今年變成線上 Event 大家都可以免費觀看，不過如果我們只是鼓勵大家去註冊觀看可能就浪費了這次的機會，於是我們有了新的想法！也就是專屬我們 KKStreamer 的 AWS re:Invent 2020 知識同樂會。既然是同樂會，就不免俗的要先把大家的肚子餵飽，正所謂內行看門道，外行吃美食~

從英聽練習到理解

雖然我們面試並沒有考英文，但是其實 KKStream 的同學們的英文聽力都有一定的程度，畢竟除了每天要看許多英文文件外，還有許多機會要跟國外同事和客戶開會，所以把大家都邀請來一起『聽』講座應該不是太大的問題吧？但是看到這麼多人同聚在一起吃雞排看影片，總是會好奇大家真的聽的懂嗎？能吸收多少？

所以舉辦在 KKStream 的Lobby 舉行「一起看」的用意就是讓大家可以一起看、討論、確認剛剛那一句英文在講啥、問有什麼參考資料…等。大家在這個演講有看到什麼亮點甚至有趣的資訊，就像參加 Conference 共筆的感覺一樣，大家把吸收到的資訊和亮點丟到一個專門的頻道。

 

同學們馬上就會開始熱烈討論，新的技術可能的應用情境，以及規格比較。

正當我邊聽編寫心得時，不時也會收到同學們的火線支援，給我 Idea 和參考資料，感覺真的有一種參加同樂會和 Hackthon 的感覺~

這麼克難的環境，感覺跟我好像啊...XDDD

 

兼顧專業與同樂

同時，為了讓它更有趣一點，AWS Taiwan 甚至還會派專人來與我們一起參與討論，更加提高同學的參與度。

 

 

對這樣的活動有興趣嗎？喜歡這樣的企業文化嗎？還不趕快加入 KKStream，熱門職缺：

 

• APP Engineer ( Android / iOS )
• Architect
• Backend Engineer ( PHP / Golang / Python )
• Growth Hacker
• Product Manager / Technical Project Manager
• QA Engineer
• SRE / DevOps ( AWS / Azure )
• Software Engineer for Business Process
• Video Encoding Engineer
• ( KKS ) 日文雲端服務營運專員
• ( KKS ) Solution Partner

 

2020 Domain Driven Design Taiwan - 關於使用者研究的省思

 

今天最意外的收穫就是在 DDD Taiwan 能聽到 Nor 大大的這場演講： 從使用者研究的幕後花絮談起，這個演講題目非常特別，研究的對象不但是運輸業還是線下的領域，對於都在搞線上大數據研究的我們產生了不少省思，此外 服務設計和研究場域利益關係人這兩個名詞對我來說還蠻新鮮的。 雖然是不同領域，且比較冷門的 session（Nor 大大還自嘲大家技術聽累了才來他這邊休息），但是從需求訪談的實際場域設計，讓我得到很多啟發和感觸！ 

一談就贏實例心得：鬼滅之談判五大呼吸法！？

 

上課前我不斷的問自己，距離上完高階四班過了一年，我究竟成長了多少呢？ 不過不管有多少成長，一進到教室看到這個恐怖的 Schedule 依然倒抽一口冷氣，受到進階十班在社團用鬼滅洗版的影響，我腦袋不禁浮現出這些畫面...

 

Team Topologies - 團隊優先思考模式

Source: Team Topologies Chapter 3

 

距離上一次聽到作者的演講，並且寫了一篇：微服務架構或單體式架構?先從團隊認知負擔談起，也經過了一年多了，一直都沒時間靜下心來好好讀這本書。

直到最近漸漸開始感受到切身之痛，是時候該好好把這本書讀完（臨時抱佛腳的概念），隨著組織業務增長，團隊也越長越大，團隊之間需要更有效的橫向溝通與協做模式，此外組織為了要在業界佔有一席之地，也必須不斷的加強 domain knowledge 與技術深度，團隊成員都有種要爆的感覺，但是卻又無法具體的描述具體原因出在哪裡？因為人力資源不夠？這是每間公司都會遇到的問題阿，有哪間公司會說自己人太充足的？是因為團隊成員能力不足？其實團隊成員的能力也都是一時之選，那究竟問題出在哪裡呢？很有可能就是在於組織架構和協做溝通的方法。

正念領導力

 

正念領導力

 

這是一本可以用一小時就可以看完，但是卻需要用一輩子的時間來練習的一本書。

本書作者陳德中是台灣正念工坊創辦人，也是 SIY 認證師資 ( 前 Google 工程師陳一鳴正念情商與領導力課程， 另一本書：喜悅，從一個呼吸開始) 

正念（Mindfulness）是一種善意和好奇的心態，對當下身、心和外在環境所發生的一切保持覺察（客觀、允許、不批判的態度）。

根據調查，大腦運作平均 47% 時間花在分心走神。思緒遊走自動導航模式是大腦自然反應，注意力都放過去或未來、分心缺乏覺知，基於慣性模式與假設做出行動，透過系統化的正念方法，可以將腦袋裡自動導航模式轉變為覺知 Being Aware。 

 

Azure 上各種 Message Queue 的比較

 
資料來源整理自 Azure 官網：

• 什麼是服務匯流排傳訊？
• 比較訊息服務
• Azure 佇列和服務匯流排佇列的比較

 

傻瓜快速分類：

• 傳遞的是 Event 類型( 訊息量不大，多為狀態，射後不理)，考慮 Event 類型
  
• 如果是離散型資料，考慮 Event Grid 
• 如果是串流行資料，考慮 Event Hubs
• 傳遞的是 Message 類型 （訊息量較大，帶有資訊，需保證送達），考慮 Message Queue
  
• 訊息很多很大不用保證 FIFO，選擇 Storage Queue
• 訊息不會很大，要保證FIFO
  

此外 Service Bus 才有支援 AMQP，更多資訊請參考： 同樣都是Message Queue 到底AMQP跟JMS 有什麼差別？

 

Update 找到一個更棒的整理：

source: Azure Messaging Service in a picture

 

 

Amazon 14 條成長法則與 14 條領導法則的差異？從貝佐斯寫給股東的信一窺究竟

貝佐斯寫給股東的信

這本書與一般成功名人傳記不同處在於，除了作者以企業研究的角度切入，長期關注 Amazon 與 Jeff Bezos 的消息外，更以 Amazon 上市這幾年的股東會信件為主軸，來歸納出 Amazon 的14 條成長法則。相信大家應該會有些疑問，寫給股東的信有什麼特別的地方嗎？不就類似新聞稿的東西？

 

在解釋貝佐斯寫給股東的信為什麼值得一讀前，可以先聊聊同樣是寫給股東的信，但是大家更為熟悉的就是巴菲特給股東的信，每年投資界的盛事就是期待他老人家致股東的信，大家除了拜讀外更有許多人收集起來集結成書。

 

為什麼巴菲特要寫股東信？

 

第一點：溝通股東信是寫給股東看的，而他希望股東都能理解他的理念。

第二點：以身作則，老巴希望他投資的公司都能達到他想要的標準，所以他也以身作則的成為標準。

第三點：因為老巴好為人師，有傳道的渴望。

 

同樣的 ，Jeff Bezos 應該也會希望透過致股東的信，讓投資人和股東瞭解他的想法，以及他打算如何讓 Amazon 如何成為快速成長的公司，同時也希望投資人們有耐心和遠見可以跟他們一同成長。因此就算是以新聞公關稿，或募資的角度來看，也是非常值得參考的內容。

 

 

第五項修練的學習地圖

2020年全世界被按了一個強制暫停的按鈕，我也因為某些原因，趁這個機會多讀點書和整理一下學習歷程。在整理的過程中，依稀感覺到快要可以把整個學習歷程串起來的感覺，就像拳譜一樣，面對組織所面對的各個層級的問題，如果能把這些 workshop 依序舉辦，從第一式打到最後一式就可能變成大絕招？但是就跟武俠小說一樣，要推動這些招式最終還是得靠深厚的內力，否則只是徒具形式。而推動這些招式的前提假設就是 相信眾人的智慧 和 不斷學習反思 。

從OGSM 談策略

 

OGSM 打造高敏捷團隊 (現在就是一定要寫敏捷~XD)

從 OKR 到 OGSM

其實也不是說 OKR 不好，非得搞個 OGSM ，其實 OGSM 跟 OKR 觀念是很類似，只是之前在使用 OKR 上有點卡關，剛好看了這本書，順著他拆解的脈絡覺得很容易理解與執行，再加上作者為了賣書教育讀者，還是有特別指出 OGSM 可以解決 OKR 的什麼問題：

• OKR 的思路轉折交代不清楚 (從 O 跳到 KR 跳太快)
• OKR 缺乏實作案例
  
• OKR 無法貫徹執行 (無法有效跟 KPI ) 
• 不知道如何修改 OKR (不知道怎樣算寫的好)
  

那在實際運作上我究竟遇到什麼問題呢？

ICA 參與式科技之轉化型行動計畫(Transformation Action Plan)

 

 

 

最近公司正在為了二轉升空正在如火如荼的制訂規劃新的 Vision & Mission & Strategy ，我也臨危授命的去幫忙帶了幾場 workshop，主要是想透過組合技 ORID 焦點討論法與團隊共創法，幫忙一線主管們回顧過去，找出影響團隊無法達成目標的障礙加以移除，並且展望未來。

 

 

雖然大家討論的很熱烈，也的確讓許多問題都浮出檯面，但是由於我忽略了幾個重要的環節，所以總覺得最終產出還是虛虛的，趁著這次的機會趕緊去報名了 ICA 今年度的 轉化型行動計畫(Transfromation Action Plan) 課程，也可以檢視上次的 workshop 有哪裡做的還不夠？

談到 ICA 的引導，就一定要先複習一下 ICA 參與式科技的引導原則：

• 包容性
• 帶著真誠的尊重來參與 (相信眾人的智慧)
  
• 探索的歷程
• 留意脈絡幫助瞭解與許下承諾
• 引導式的風格
  

要相信團隊成員的集體智慧，流程只是個工具，用來幫助思考的順暢，但重點還是尊重，並且讓大家能充分表達意見的包容力，所以引導者的觀察力與場控力真的很重要（這也得靠經驗累積）。

 

教練 - 你如何衡量你的人生？

 source: The Secret Coach

 

原本以為『教練：價值兆元的管理課，賈伯斯、佩吉、皮查不公開教練的高績效團隊心法』這是一本透過 比爾 的生平事蹟，讓我們學習如何成為一個成功教練的書，但其實並不是，雖然裡面還是有蠻多金句可以參考， 之前我也有節錄出一些書摘 - 傳奇億萬美元級教練比爾·坎貝爾 Trillon dollar coach，但是仔細把他讀完就會有不同的感想。

關於產品調查的問卷設計

前陣子在讀 Lean B2B 時這張圖最讓我有印象，這也是我常拿出來提醒 Team Member 的，到底什麼是 MVP，應該盡量要取三個圈圈的交集處：

• 我們以為市場可能需要什麼
• 真實市場確實需要什麼
• 我們有能力做到什麼

而怎樣的產品對客戶來說怎樣算是一個好的 2B 的 solution 呢？可能有以下的面向，如果都能達到當然是最好的：

    •    Solutions that can help increase revenues (ROI)

    •    Solutions that can help reduce cost (TOC)

    •    Solutions that can help increase customer satisfaction

    •    Solutions that can help decrease risk

    •    Solutions that can help increase market share

趕快到市場上去被打臉尋求回饋固然是最重要的，但是出門前也是可以先從內部收集一些情報，剛好前陣子要跟全公司做個小型產品發表會，介紹這段期間以來 BlendVision 到底在做什麼？以及目前設計產品的理念以及開發進度，想說既然都花費大家時間來聽我們介紹，不如順便收集一些回饋。不過要設計一個好的問卷也是一門學問，在有限的時間下我們就借鏡那三個圈圈，把題目設計如下：

• 你覺得這個功能是有用的 (用來替換我們有能力作什麼)
• 你覺得客戶會需要這個功能 (=我們以為市場可能需要什麼)
• 已經有客戶提出這個功能需求 (真實市場確實需要什麼)
  

但是光是這樣可能還不夠，就算是匿名問卷，最好還是能區分這是以什麼角度來評估的？

• 工程師？
• PM？
• BD / Sales？
• Operator (維運/客服)

畢竟可能只有 PM & BD / Sales 有真實接觸市場和客戶的需求。

最後我們回收了 24  份問卷，畢竟不是大家都有空來聽我們介紹產品~~QQ

接下來我們就針對我們的 12 大 Feature 一一介紹功能，並且尋求大家的回饋。

不過畢竟這是倉促之間產生的問卷，所已有效性還值得商榷，而且問題的設計上也造成了(問卷)使用者的困擾，像上面這個打勾的方式就很讓人疑惑，你覺得客戶需要這個功能，也已經有客戶提出這個需求，但是你卻沒有勾你覺得這是有用的？？

後來事主自己跑來跟我們聊，原來她覺得只要下面兩個都有勾，其實就代表這個功能是有用，所以就不用她覺得是有用...XDrz...

所以如何設計問卷的問題真是門藝術啊...

有了同仁門的回饋，接下來就繼續到市場上去被人洗臉求成長了~~

不知道大家有設計相關的經驗可以分享嗎？

組織生命週期與溝通模式的變化

source: Organizational life cycle

最近在跟朋友聊天，聊到這個話題~

人和組織都有生老病死

組織是由人組成的，所以就像人一樣也會有生命週期，在不同階段都有相對應適合的管理模式和工作方法，反過來說就是眾多的管理學工具（方法論）都是為了解決特定的問題，也都有試用的場景，並不是都能一體適用。就像 design pattern 一樣，每個 pattern 都有要解決的問題和適用的場景，用錯時間和地點可能還會產生災難。

---

老漢愛提當年勇，但識英雄來自四面八方

人是經驗的動物，我們的所有行為都是受到我們信念的影響，而信念則是由過去的成功（失敗）經驗所形塑出來，而盲點往往就是從這邊產生。

情緒 ABC：

A (起源事因) —> B (信念) —> C ( 情緒與行為)
A 是既存事實不會導致 C
真正促成C 的是B

不管是主管和同仁在討論事情時或多或少都會引用過去成功案例和經驗，來佐證自己的觀點的正確性，但確常常忽略產生過去經驗的情境（ context ），是在怎樣的組織？處於什麼週期階段？由怎樣的人組成？這些經驗和成熟度才能適用？

source: Communication activity flow between different cultured individuals

而衝突就往往由這些點產生，不過有衝突也不見得是壞事啦，團隊領導的五大障礙這本書也有提到，如果把障礙反過來的正面模型則是：

1. 團隊成員互相信任  <--先有信任才敢衝突
   
2. 團隊成員含不保留地投入有關理念的衝突
3. 團隊成員承諾達成決策和行動計畫
4. 團隊成互相要求，為消除計畫中得障礙負起責任
5. 團隊成員將重點放在達成集體成果

你是對的不代表我是錯的

如何有效利用建設性的衝突，重點應該要放在溝通時要多分享產生這些經驗的 context，大家才能從中找出好的部分可以借鏡，壞的部分可以避免，就像我之前整理的 薩提爾與麥肯錫菁英的思考習慣如何解決負面情緒，裡面提供了解決方法：

如何從“必須型”轉變為“願望型” 五個步驟：

第一步，要肯定你的願望或者目標是有重要價值的﹔
第二步，要去否定絕對的要求，但它不是必須要實現的﹔
第三步，要考慮多種結果的可能性﹔
第四步，現實地評價壞的結果發生的情況﹔
第五步，就是盡最大的努力去實現最好的結果。

不禁又讓我想到組織變革的張力與拉力這個議題，拉扯總是來來回回的，而同樣的議題依舊來來回回的討論...XDrz...

如何透過 PowerBI Desktop 匯入Azure Billing 資料分析

source: power bi connect-data

這幾年 Azure 的更新頻率非常快，但是常常是翻天覆地改變的那種，像是如何透過Power BI 分析 Billing 就變了好幾版，所以每次都得重新熟悉。最大的改變我想就是閹割掉 Power BI 網頁版的所有 Input Source ，強制規定一定只能先透過 Power BI Desktop 來設定，這對於 Mac 的使用者真的很不友善....anyway...讓我們來看看新版的介面該怎麼使用。

成功為成功之母，如何從 near miss 中找出致勝關鍵

source: near miss

在 Scrum retrospective meeting 通常會有幾種問題：覺得的好的和不好的，要繼續做的和該停止的這種討論，不過通常對於做的好的，大多會流於感謝和整能量時刻，而很少會好好去討論為什麼的成功，和關鍵指標是什麼，以及這次成功會不會真的就只是運氣好？有聽過專案驗屍會議，但是很少聽過專案成功檢討會議？

我們都知道要敢於面對失敗，因為我們更容易從失敗中學習。但是其實最常被忽略的就是從成功中學習，尤其是那種被運氣影像，『差一點就會失敗』的成功，英文稱為『near miss』。

上游問題 - 如何處理寶寶心裡苦，但寶寶不說的狀況

Upstream: The Quest to Solve Problems Before They Happen

感謝得到-萬為綱老師搶鮮為我們介紹這本 2020 年一月剛推出，希思兄弟這本的新書，我想中文版大概要一年後才看得到？

看高手寫的書最爽的就是把那種『寶寶心裡苦，但是寶寶不說(or 不知怎麼說)』的狀況總結歸納出來，並且得到一些科學的建議。

然後我就可站在巨人的肩膀上，再透過旁徵博引的萬維鋼老師把本書脈絡整理了出來，最後讓我可以以懶人包和自己的經驗來三次創作😆

在我看來，上游思維用積極的觀點來說就是上醫治未病，但從消極面來看我想到一個問題，「先知除了在本鄉、本族、本家以外，沒有不受尊重的。」

為什麼先知總是辛苦又容易被討厭？原因有三

Go 小教室 - 如何讓mac 上的 goenv 可以選擇 1.12 以上版本

go 其實還一個很年輕的語言，所以每次升級，難免會有一些 breaking change，像最近從 1.13 升級到 1.14 就莫名的讓幾個 unit test 掛了，在還沒有時間去研究到底為什麼升版會造成 unit test 掛掉前，最好還是乖乖定版在 1.13，於是想說就灌個 goenv 來使用，沒想到用 homebrew 安裝的 goenv 卻只能安裝到 1.12beta

Inspired 產品專案管理全書 - 探索客戶計畫：用來提醒 Product Manager 的實用查核表

source: pngwave

工程師背景的我們，從以前最擅長與專注的就是在 Deliver 的優化，以及學習相關的方法論，但是隨著在社會闖蕩碰壁多年，漸漸發現其實 Define and Discovery 的方法論更是至關重要，可以幫助我們減少許多白費工的狀況發生（工程師最怕需求一直改，改出來又沒人用）。

去年聽了 Marty Cagan 的演講 - Product Is Hard ，就開始仔細閱讀『Inspired 產品專案管理全書』，並且思索如何應用在現在的產品，有許多內容和方法真是相見恨晚，在第 39 章整理了 Marty Cagan 在 2013 年寫的一篇文章  The Power of Reference Customers，而這個套路在矽谷的 SaaS company 更是隨處可見，可以在許多產品的業面看到以下訊息：

Google 認證與線上教學課程整理

目前Google Cloud 的認證有以下幾種，以及對應的學習資源：

# Associate Cloud Engineer

Qwiklabs - Cloud Architecture



# Professional Cloud Architect

Qwiklabs - Challenge: GCP Architecture


# Professional Data Engineer

Qwiklabs - Data Engineering

 
# Professional Cloud Developer

你知道在 Azure 上有幾種 On Demand 啟動 Spark 的方法嗎？

Source: Provision on-demand Spark clusters on Docker using Azure

最近需要開始分析一些 Log ，最直覺的方式就是使用最熟悉的 Spark 來分析，於是開始研究最近有什麼方便在 Azure 啟動 Spark 的方式，在 AWS 和 GCP 上，之前就已經有研究過專門支援的 PaaS 服務：

• AWS 就是 EMR ( 關於AWS Elaster MapReducer )
• GCP 就是 Dataproc - Google Cloud Dataproc 如何建立 Custom Image 加快 PySpark 部署環境速度

我知道 Azure 有 HDInsight ，但是之前使用覺得沒有 GCP Dataproc 好用，不知道 2020 年的今天，有沒有什麼新的 Solution 呢？畢竟 Azure 的 "強項" 就是透過大量跟 3rd-party ISV 整合來壯大自己的服務

Azure 小筆記 - 關於 Azure Data Exploer 又稱 Kusto

Kusto 簡單來說就是 Azure 版的 BigQuery，可用於儲存和執行巨量資料的互動式分析。它是以關聯式資料庫管理系統為基礎，支援資料庫、資料表和資料行之類的實體，並提供複雜的分析查詢運算子 (例如，計算結果欄、搜尋和篩選資料列、依匯總分組、聯結)。

Kusto 藉由「犧牲」執行個別資料列和跨資料表條件約束/交易的就地更新功能，提供絕佳的資料內嵌和查詢效能。 因此，它會代替 (而不是取代) OLTP 和資料倉儲處理等案例的傳統 RDBMS 系統。身為巨量資料服務，Kusto 會處理結構化、半結構化 (類似 JSON 的巢狀類型) 和非結構化 (自然語言) 資料。

資料來源：開始使用 Kusto

Go 小教室 - 如何檢驗 Go struct isEmpty

最近踩到一個 buffalo-pop ORM 的一個雷，範例如下：

type Job struct {
 ID             string         `json:"id" db:"id"`
 JobCreateType  JobCreateType  `json:"job_create_type" db:"job_create_type"`
 FileName       string         `json:"file_name" db:"file_name"`
 Status         JobStatus      `json:"status" db:"status"`
 CreatedAt      time.Time      `json:"created_at" db:"created_at"`
 UpdatedAt      time.Time      `json:"updated_at" db:"updated_at"`
 JobSourceInfo  *JobSourceInfo `json:"source_info" has_one:"job_source_infos" fk_id:"job_id"`
}

type JobSourceInfo struct {
 ID               string        `json:"id" db:"id"`
 JobID            string        `json:"job_id" db:"job_id"`
 SourceURL        string        `json:"source_url" db:"source_url"`
 }

一個 Job Struct 裡面有一個 Embedded Struct JobSourceInfo ，在資料庫裡面是 1 - 1 的關係，一開始產生 Job 時，並不預期一定會產生 JobScoureInfo，這時我們都會宣告為指標，理論上只要如下面範例，檢查是不是 nil 就能知道這個物件有沒被產生。

var ji *JobSourceInfo

if ji == nil {
    ji = new(JobSourceInfo)
    // do stuff 
}

但是.... Buffalo 的 ORM 的 Eager func 卻自作主張的幫我產生了一個 Empty Struct ，原本只需要檢查，指標是否為 nil ，但是現在卻得檢查是否為 empty Struct...

那讓我們來看看檢驗 Empty Struct 有幾種方法？

BlendVision on Azure appSource

BlendVision on Azure app Source

經過了半年的努力，我們第一版 MVP 終於在 Azure App Source 上架了。

談判系列叢書懶人包(2) - 不妥協的談判 Negotiating the Nonnegotiable

博客來 - 不妥協的談判(簡)

Amazon - Negotiating the Nonnegotiable

第一次聽到這本書是在 Alex 老師的 blog - 部落衝突，全面開戰?! 從《不妥協的談判》》（Negotiating The Nonnegotiable）看如何面對非理性談判，那時就對這本書覺得很有興趣，可惜的是這本書沒有繁體中文版，只有英文和簡體版，不過網路上的資源還蠻多的，所以真的有興趣也可以從演講開始聽起。

一談就贏：銷售贏家必勝攻略首發班心得 - 學問

業務就是巧言令色的弒血鯊魚嗎?

自從上次 Alex 在『速食遊戲演練班』宣布即將會開設新的銷售公開班，我就非常期待，這一次終於讓我搶到了頭香， 報名到了依舊秒殺的『一談就贏』之『銷售贏家』天字第一班，有很多人問我，你不是工程師嗎，為什麼要來報名銷售課程？

我的回答是：雖然我不是業務，不過跟業務都有很密切的關係，很多候要以 presales 的角色協助 sales or BD (Business Development) ，更多得時候要把他們的需求帶回來轉換成開發的 Spec。此外因為蠻長一段時間都待在新創公司，常常會需要跟老闆和 BD 們一起討論價格與商業模式~

之所以會想要來上這門課主要有幾個學習目標：

• 瞭解什麼是好的銷售人員 (與 evaluate 的標準)
• 學習更多關於定價與 BD 相關的知識與武器
• 學習從 BD 與 業務看市場的角度，來協助產品開發與策略規劃

短短一天的課程可以學到那麼多東西嗎！？

關於 Azure EA 的價錢與 RI 的價錢差異

source: How the Azure reservation discount is applied to virtual machines

關於 Reserved Instance 每一家的規則都有一些些許的差異，Azure 的 Reserved 有幾個特點：

• 現在買 RI 不用全額付款 (upfront )，只需要每月支付
• 如果買了 RI 後來發現用不了那麼多，可以解約，但是要支付 12% 手續費 (退款原則)

關於 EA 與 RI 的價格差異

在網路上看到一篇文章這樣描述，EA 有折扣，RI 也有折扣，那到底怎麼計算？

後來瞭解才知道，假設一台 VM list price 是 100元，EA 和 RI 的價格方別如下：

EA     (從 list price 折扣 5%~9% off) 所以價格是 95~91 元
RI 1y (從 list price 折扣 ~40% off) 所以價格約略 60 元
RI 3y (從 list price 折扣 ~60% off) 所以價格約月 40 元

EA 與 RI 的折扣不能疊加，只能擇優計算，所以如果就算你是 EA + RI 1y ，那你也只能拿到 60元的價格。


另外根據不同的機型，我做了一個比較表，如果開發機想要省錢，直覺的想法就是只有上班時間開機，下班關機，但是如果 3y RI 買下去，就算一直開機價格也比上班開機下班關機划算~

談判系列叢書懶人包(1) - 雙贏談判

話說在還沒上一談就贏系列課程前，就從 Alex 部落格看到他介紹了許多好的談判書籍，每個月博客來剁手日就會順手買下去，但是也都沒有乖乖看完，大多只是東翻一下西翻一下，因為覺得東西太多，完全不知到要怎麼應用到實際的談判場景？

說實在的那麼多本書，每本書的特色和是用的場景都不太一樣，有些是學案例，有些是學心態，有些是學戰術，如果想要完整的學習當然還是推薦先去上 一談就贏，之後再回來看這些書就會有很大的不同，因為對於談判的框架與輪廓有了更完整的認識和練習，現在再回來看這些書就更能進入狀況，也更有感覺，開始之到該如何利用每本書的小撇步，或是把這些案例當作是戰術上的參考。

溫故而知新，現在回去看之前的作業就覺得自己好傻好天真（代表有在進步！？）

• 一談就贏 - 思維12班心得
• 一談就贏 - 進階八班心得『專注在你能控制的部分』
• 一談就贏 - 高階四班心得