2019 年上的許多課，和聽到的許多學科都在腦科學這個領域交會了，不管是年初上more fearless change 作者 Linda Rising 的課 ，到最近火紅的行為經濟學，組織行為學，生命科學..等。由腦科學的角度出發讓我不禁感嘆，我們最大的敵人就是自己這句話是真的，我們自以為是的心智和自由意志（所謂的靈性），每天必須對抗著人類這台精密的機器的玩弄，影響人類行為的根源：第一個是大腦神經元﹔第二個是荷爾蒙﹔最後才是是我們的基因和文化。
2019年12月31日 星期二
2019 年得到學習報告
2019 年上的許多課，和聽到的許多學科都在腦科學這個領域交會了，不管是年初上more fearless change 作者 Linda Rising 的課 ，到最近火紅的行為經濟學，組織行為學，生命科學..等。由腦科學的角度出發讓我不禁感嘆，我們最大的敵人就是自己這句話是真的，我們自以為是的心智和自由意志（所謂的靈性），每天必須對抗著人類這台精密的機器的玩弄，影響人類行為的根源：第一個是大腦神經元﹔第二個是荷爾蒙﹔最後才是是我們的基因和文化。
2019年12月28日 星期六
2019年12月15日 星期日
[書摘] (技術型)領導者，該想什麼
節錄出幾個我特別有感覺的部分，這本書每個章節後面列出許多問題，都值得領導者或想要變成領導者的人用來問自己，那些我有做到？哪些我沒有做到？我有辦法作的更好嗎？
MOI 領導模型
要讓改變發生，人們身處的環境必須包含三個要素：
- M（Motivation）動機
- O（Organization）組織
- I（Ideas or Innovation） 點子或創新
相對的，領導也有可能意味防止改變發生：
- M（Kill the motivation） 消除動機
- O（foster chaos）助長混亂
- I（suppress the flow of ideas）壓抑點子的流通
>> 要搞爛或搞好組織都要從這三個面向著手....
在一個組織裡面會有很多種領導者，比如說：
- 動機型領導者 - 超級推銷員，充滿魅力，有任何想法都能推銷出去
- 組織型領導者 - 工作有效率的企業經理人，辦起事來井然有序
不過這本書則是著重在技術型領導人，技術型領導人通常會注重於三件事：
- 瞭解問題
- 控制點子的流通
- 維持品質
領導者的養成
尤其是技術型領導者的重點是要先『學會如何學習』，並且要養成面對循環學習的態度，因為在學習的路上會不斷的交替，要學會面對低谷。有許多人就是無法接受面對這種循環面對低谷的感覺，為了了避開而選擇當『上司』管理人，但是反而摔入了峽谷，在人生的旅途上跌了一大跤（因為停止了學習）。
人們很容易認定『最弱的』環節就是『最重要』的環節，也難怪大家都會有個迷思：指定領導者是最重要的環節。於是大家都覺得所有的關鍵就是領導者，領導者要負起所有責任，讓領導者承擔更重的責任，所以也讓大家都更加害怕成為領導者。
（要知道領導者不一定是主管！也不一定是老闆....）
技術領導者 - 創新之路的兩難
而對於技術型領導者，大多是由技術明星變成，他們普遍就會有個恐懼，可能會失去吸收最先進的科技和知識，覺得技術能力會退步。的確不管是作者和我都會覺得，有時候為了增進管理和人際相關的技巧，不得不犧牲一些用來吸收技術性知識的時間。
而技術明星也通常是創新者，但是這又可能會變成有礙於他們學習所需要的領導技巧，因此難以攀上下一個高原期，如果不瞭解自己的創新/學習過程，一旦被賦予領導者的責任，這些技術明星可能會使不上力，覺得自己根本帶不動屬下，不知道該怎麼教他們變的跟自己一樣，又會覺得自己來似乎比較快，這時候反而就破壞了讓下屬創新的機會和環境.....
技術領導者面臨的三大障礙：
- 當局者迷：看不見自身行為，因為沒有機會改變自我
- 沒問題症候群：相信自幾知道所有問題的答案
- 單一解決方案：深信一定有一個最好的辦法
改善之路
- 培養自知之明：從寫日記開始
- 發展創新的能力
- 思考願景：
- 關鍵不再發生什麼事，而是當事人對事件的反應
- 每個人都有遭遇失敗的一刻，很遺憾的是，一個人成功後，下一步就很可能就是失敗
- 每個成功的技術領導者都有一個個人願景
- 沒有願景的人，對他人是沒有影響力的
- 成為激勵者 (這邊可以參我之前寫的考薩提爾的相關文章）
組織變革
從個人到團隊最後來到組織，組織是技術領導者的 End Game & End Goal，首先改革需要力量，也必須先取的力量，然後學習成為一個組織者。
讀一本書就像與大師對談，很多時候能聊的多深，取決於自己的經驗與歷練，當沒有累積足夠的經驗和能量，可能會沒有深刻的感覺，越到後面的章節，越有種現在進型式的感覺，需要再累積和驗證過一些東西才能再回來對話，所已有時候一本書必須要讀好幾次。
2019年12月10日 星期二
關於Marty Cagan - Product Is Hard 的筆記整理
原本想說沒機會去參加 Product Tank 的這場活動，還好事後有影片釋出，可以讓我補課，影片的內容的確有很多解決我的疑惑，也讓我很有感處，以下節錄出一些重點：
有那麼多好的工程師和設計師，為什麼一個好的產品那麼少？
- 因為好的產品經理實在太少了！
- 太少討論，和教學關於如何做好 Product （這邊指的應該是SaaS Product）
2019年12月9日 星期一
讓孩子了解什麼是民主，社會階級，獨裁
孩子的教育不能等，自從小貝哥回鄉下玩，回來以後就一直喊 xxx 凍算，叫覺得時候該好好教育一下，讓他瞭解什麼是民主，什麼是選舉，這些人都再做什麼，剛好前幾天在臉書上看到朋友在分享這套叢書，就趁著博客來剁手日買下去了 - 什麼是民主，社會階級，獨裁。
★二○一六年波隆那童書大獎★★委內瑞拉圖書銀行文學獎★
2019年12月7日 星期六
一談就贏 - 高階四班心得
我與談判大師的距離
說真的比起許多學長姐，我真的很幸運，才能用短短一年的時間，一路從思維班(12班)，進階班(8班)，上到高階班(4班)，2019 年真的過的異常的
為了對的起已經付出的時間與金錢，也對的起一路提點我們的老師和學長姐們，真的奉勸各位學弟妹，如果想學到真正的談判，一定要一路撐到最後全部上完，才真的有機會把完整的框架學會，老師會這樣設計不是沒有道理的。
學談判心境的轉變
如果用比較平淡的講法來描述我這一年來的心境，思維班讓我『硬起來』，準備隨時可以與人談判的勇氣，學到不要害怕衝突，談判並不只是比口才和爾驢我詐，到了進階班學到了價值三角讓我就像撿到槍一樣，想說終於有個看起來蠻好操作的框架，應該可以上場多練習了，但是到了高階班才讓讓我再度冷靜下來，發現不要因為拿了一個錘子，看到的東西都是釘子想要錘下去，慎選場景，先釐清目的，這個場景真的需要用談判解決嗎？還是應該摸摸鼻子，找其他方式來解決？
這不禁讓我想到老師上課前提到的『...我看到你們之中一些人，本身的缺點居然比原先擴展的還大，所以我很懷疑你們究竟知不知道學習的目的....』，看到這老師的提醒，我冷汗直流，心想這不就是在說我嗎.....
如果要用誇張一點的講法就是，學談判前就像一個小孩望著滿天繁星想說只要長大一點手伸長一點就能抓到星星，到了思維班就像一個小孩學到星星其實在外太空唷，要飛到外太空才能碰到，到了進階班才有了更精準的知識，知道其實那些發亮的星星叫做恆星，只要開太空船飛出太陽係就可以遇到，但是到了高階班才驚覺，原來出了太陽系那些星星距離我們幾百光年之外，就算以光速進行，也要一百年之久.....那這樣不是有生之年都沒望了！？別擔心這時候 Alex 會教你怎麼靠曲速和蟲洞到達目的地.....（並不會，這時候可能要回來修正目標，你真的是想要抓到星星嗎？）
向大師學習
對於 Alex 的強大的體認就跟對課程心得一樣，隨著自己功力的提升有著不同的體認，正所謂內行看門道，外行看熱鬧，對我們這種談判小白來說，一開始只是在看大師演練功夫招式，並且對於老師過往談判經歷和表演感到讚嘆，但是會覺得跟旁邊其他功夫師父比起來，好像覺得沒太大的差別（現在想起來真是汗顏），直到進階班跳下來跟著他一起演練招式，這才發現看起來簡單基礎的動作卻是滯礙難行，很努力都不一定能跟上動作，直到了高階班以為差不多可以跟上動作了，直到上場跟老師演練一下推手拆解招式，不出幾回合就被老師的內力震飛出去....（噴出一口鮮血，還非常感激的謝謝賜教）
此時腦浮現人生跑馬燈，盡是老師的課前作業問題『你們認為什麼是談判？你們學盤判是為了什麼？你覺得你可以做的更好嗎？如果重來那個當下你應該怎麼做？』...
老師不斷的在觀察我們每個人，這些人想要上的是怎樣的課？他們究竟想聽到什麼？他們分別的長處是什麼？有什麼短處（有沒有改善？）而這次高階班跟其他幾般最大的差別就是可以一整天跟隨在老師身邊觀察， 越是相處越能具體的理解到 Alex 的強大和我們之間的差距，跟我們離他還有多遠的距離，就連吃飯跟我們聊天都是有所準備和規劃絲毫不鬆懈的。
對於震撼的部分就先提到這裡，這篇真的不是來歌功頌德和拍馬屁的～ＸＤ 不過如果沒有這樣的鋪陳是無法體會我的收穫，也無法體會老師為了讓我們學習所
學習的框架
充滿風險卻逐步完善，逐步清晰的課程架構
老師在課堂上提到實務談判的三大核心難題：
- 多對多
- 動態
- 不理解對手（沒有重視細節，沒有重視人）
- 不知道如何出手
- 不清楚如何因應
- 不掌握時間
- 不能創造機會
- 內部無法達成共識
基於上面的困境就知道一個談判的課程所需要解決的問題實在太多，涵蓋範圍實在太廣，如果以正規的學校教育，可能要花一整個學期來學期，我更能理解為什麼老師的課程必須設計成這樣（當然也是冒著風險，冒著同學沒辦法跟到最後看到全貌），就像敏捷開發一樣由具體而模糊，每次都 delivery 一些可以用的東西，但是都還不是全貌，畢竟才三次總共五半的課，要跑完人家一年的課程，就沒辦法用一般的方法慢慢來，必須透過演練和活動讓同學體認出真正談判會遇到的困難，才有辦法糾正觀念，重新學習...
而老師要怎麼降低課程設計的風險？老師一直用行動在告訴我們：
- 創造連結
- 建立關係
- 培養共識
- 打造信任
透過課前作業，透過每一篇文章，透過每個學長姐的心得來傳達訊息，我們因為連結，建立的關係，培養了對課程與學習的共識，也信任老師會提供最好的課程來讓我們學習，並且深信是有用的。
警語：學弟妹在看學長姐心得時也必須注意，最危險的的就是看到學長姐的『關鍵字』和老師上課的金句來臆測課程內容，這就是老師所提醒的不要用已知去瞭解未知，所以我也盡量不去描述這些『重點』，留給各位在課堂上體會。
關於課程上的競爭
思維班的競爭其實是其實在混亂中就結束了，可能很多人都還沒意識到自己該爭什麼？為什麼要贏？真的有必要繼續往下上嗎？甚至有很多人只是來看看的(打卡集點的概念)。
到了進階班真正的競爭才開始，更有組織，更有意識的在小組競爭，除了好勝心和證明學習成果，更是為了爭取高階班的資格。
但是到了高階班整個競爭心態變了，不是不想贏，而是更想要贏得自己的人生，每個人都拿出自己生命中血淋淋的談判經歷來當案例，每個人都是為了自己的人生在競爭，想要贏過去的自己，想要解決生活中真正的問題，這跟過去看著老師拿出來與自己無關的案例，和同學『演』練談判的競爭心態差很多。所以小組與小組之間的競爭變少了，更多了一起協力學習一起幫忙解決問題的共患難心態。
此外看別人的案子和看自己的案子也有很大的差距，一旦牽涉到自己，就會有過多的感情和過去經驗的糾結，會讓自己不能做出最佳的判斷，這不也是我們思維班課前作業老師一直要我們思考的，我們到底為了什麼在學談判？我們認為談判是什麼？學完之後要怎麼用談判？要怎麼改善自己的缺點？(至少不能讓他再惡化)
價值連結的取捨
在進階班讓我感到收穫最大的就是價值三角，其中大家朗朗上口的雙贏，把餅作大，就是透過價值連結的活動產生，但是自己在練習和操作的時候一直覺得太理想化，很難被實作，直到了高階班透過談判架構的細部拆，解終於瞭解當初價值三角做的如此零零落落，原來一直沒有搞清楚利害關係人（有哪些種類？對於我方和對方的影響？），更不用說各自的利益都分不清楚，要怎麼作價值連結？更不用說極大化雙方的利益。
此外價值連結不是只有取得，還得有捨棄，為了得達到雙方的目標，我自己願意拿什麼來換？（你沒辦法要求和臆測別人會拿什麼來換），取捨？談何容易，為了達到目的，你願意犧牲掉什麼？沒想到居然還真的可以排得出來...(雖然我們可能還是會排錯)
談判框架 - 工程師的領域
以前都認為談判是適合業務哪種很會說話，反應很快人的天下，隨著課程雖然慢慢修正了這些錯誤的觀念，直到高階班讓我遇到了談判架構檢核表，不禁讓我驚呼～阿～這對工程師友善多了，讓我們思考更有所依循。
談判架構檢核表的推演，根本跟寫程式的『測試驅動開發』 ( TDD - Test Driven Development )方法一樣，一開始先立一個目的，隨著功能的實作中，不斷的查核檢驗錯誤，如果卡住了再回上一層修改和重構，有時甚至會回到最源頭發現根本是目標設立錯誤，不習慣 TDD 的人剛開始一定會覺得麻煩和速度慢，但是上手後整個手順和速度有著明顯的加速，更容易拆解和實作複雜的談判架構和演算法，就像老師說的很多時候那些 3*3 的沙盤推演不是靠天才橫空出世，而是靠一步一步推演出來的。
這個框架非常具有操作性，在第一天我們發現案例可能走不下去的時，我們馬上決定換另一個案例，坐在沙發上，我們光是按照檢核表透過口頭走過一遍，就把上課前七嘴八舌討論老半天都還搞不清楚的案例拆解開來，看清楚這是一個怎樣的『局』，當然至於要怎麼作的好對我們來說又是得花時間磨練的功夫了....
上完這門課真的是充滿了懊悔與落差，但是也真的很開心有了新的武器可以面對人生的挑戰（Ｍ屬性來著..），但是生活就是沒有時間讓我們停下來懊惱，壓力和挑戰還是持續的排山倒海而來，出了教室馬上就開始應用，面對人生的大魔王～～
最後要感謝我的同伴們（佳儀、育成、安婷、雅樂），因為這陣子實在太累太操了，沒有大家的支持沒辦法走道最後~~
延伸閱讀：
2019年11月11日 星期一
Apache Spark 3.0 Release Preview
Source: Apache Spark JIRA
一轉眼 Apache Spark 3.0-preview 已經推出了，眼看又快要跟時代脫節了...🙈
這次 3.0 的更新多到爆炸，所以再研究有什麼令人興奮的更新前，我們先來複習一下之前在 Spark+AI Summit 2019 Keynote 的預告有什麼需要我們注意的。
- 更多向量矩陣運算和GPU支援
- 跟 K8s 更緊密的整合
- Koalas - panda dataframe
2019年11月7日 星期四
使用 Go Get 在Docker 使用 multi-stage builds 搬檔案遇到的問題
source: mundodocker
前情提要
Docker 從 17.05 版本以後就有這個貼心的設計， multi-stage build（多階段建構），這對於長期因為 build docker image 太大而困擾的我們真的是很方便，所以現在 multi-stage build 幾乎已經成為 build docker image 標準配備。
在不支持多階段建構的年代，通常會有兩種作法：
2019年10月27日 星期日
一談就贏 - 速食遊戲演練班
第一次參加『一談就贏』系列的其他課程，而且還是空前絕後的『速食遊戲演練班』， 如果硬要把心得濃縮成摘要，大概就是：
這次的演練基本上就是結合『談判』、『銷售』、『MTa』三大綜合戰技，而其中我覺得最重要的是『MTa』的團隊合作（等等你根本沒上過啊...），縱使有再好的談判技巧和銷售定價策略，只要不能有效達成團隊合作，一切都是回到單兵作戰，吃的是本質學能，考驗個人戰技。
2019年10月25日 星期五
組織變革的張力與拉力
昨天聽完 #周師父 的演講，拿這張投影片搭配今天聽到 #梁寧 在講組織與關係就特別有感覺。
關於抗拒的張力與抗力的圖片在『最小阻力之路』和『第五項修練』中都有出現，但是用來解釋 Component team 與 Feature team 倒是第一次聽到，覺得很新鮮也很有道理。如果有再推行敏捷都會知道 Feature Team 的好處，而 Feature Team 也主要是以傳遞上商業價值為導向，但是系統開發的本質，卻是以 Domain Architecture Design 和 Reuse Shared Modules 的 Competent team 在思考與運作。沒有誰對誰錯，只有當下適合不適合，與分配的比例。
source: systemsbusinesscoach.com
2019年10月22日 星期二
Lean B2B - 架構與順序
source: Lean B2B
在講解作者提出的 B2B Startup Pyramid 前，我們再來看一次本書的目錄架構：
1. Why This Book Matters
Chapter 1. Introduction
Chapter 2. Where I’m Coming From
Chapter 3. The Nature of the B2B World
2. People
Chapter 4. Were it starts
Chapter 5. Choosing a market
Chapter 6. Finding Early Adopters
Chapter 7. Leveraging Domain Credibility & Visibility
Chapter 8. Contacting Early Adopter
3. Problem
Chapter 9. Finding Problem
Chapter 10. Conducting Problem Interviews
Chapter 11. Analyzing the Results
4. Solutions
Chapter 12. Finding a Solution
Chapter 13. Creating a Minimum Viable Product
Chapter 14. Preparing Your Pitch
Chapter 15. Conducting Solution Interviews
Chapter 16. Product Market Fit
5. Speed
Chapter 17. Common Challenges
Chapter 18. Speeding up Product Market Validation
Chapter 19. Conclusion
不過其實最吸引我目光的反而是『加速』章節的第十七章，B2B Startup 常見的問題，其實應該說許多公司都常見的問題，後面看到有什麼心得再來分享~
- Being everything
- Pet Problem
- The curse of “interesting”
- Postponed usage
- Long sales cycles
- Insufficient credibility
- Gatekeepers and Saboteurs
- Soft value propositions
- Committed budgets
- Insuffcient coaching influence
- Death by process
2019年10月2日 星期三
Lean B2B - 同樣是 Lean Startup B2B 與 B2C 有什麼差異?
從年初在準備『 Agile meetup - 為什麼我的敏捷總是卡卡的? 』這個活動時，就開始大量研究 B2B 與 B2C 之間本質的差異，以及對於導入敏捷會不會有什麼影響，一直覺得這個議題應該蠻適合研究的。而延續上一篇文章『加速 (Accelerate) - Lead time 我搞不懂你啊』，其實敏捷的本質就是圍繞在商業價值，所以關於 B2B 與 B2C 的議題應該延伸到整個價值流來檢視（包含 Lean Startup、Design Thinking、Agile）。
剛好最近新的工作是要負責開發新產品，同事也提議要來舉辦讀書會，我就找到了這本有趣的書，還真的有人再探討，同樣是精實創業( Lean Startup）同樣是開發新產品， B2B 與 B2C 有什麼差異？
2019年9月17日 星期二
加速 (Accelerate) - Lead time 我搞不懂你啊
在 Accelerate 第二章看到這個表（把Dev & Ops 兩個階段分開來看），就讓我想到之前看到上面 Gartner 那張圖，Design Thinking，Lean Startup，Agile 應該要整合在一起，這張圖告訴我們，只專注在Agile 上的優化可能還是無法解決商業成功的問題，這也是我一直以來在問自己的問題，縱使在產品 Delivery 上怎麼優化（當然不可能完美，但是還算有到一定程度），感覺對於商業成功的影響還是有種施不上力的感覺。
source: 加速 (Accelerate)
2019年9月14日 星期六
一談就贏 - 進階八班心得『專注在你能控制的部分』
這是一門談判課，『想贏』這個目標，究竟是想學好談判，能贏！還是想拿到進階班冠軍，有資格繼續挺進高階班？這個問題在這段期間一直在我腦袋裡翻轉，也一直被人反覆詢問.....
忘記從何時開始，每年都固定提撥一筆預算去進修(進場維修)，而一談就贏這一系列的課程真的是從開始上課以來最操也最辛苦的一門課(沒有之一)，Alex 打造出來的這個平台和這個局真的很
2019年8月18日 星期日
指數型組織 - 大型組織的變革策略
Source: Exponential Organizations, Salim Ismail
雪球速讀法這本書有提到，看書先看框架，如果對於框架有興趣，在去裡面看脈絡和內容，指數型組織這本書總結出一個共同的特性『宏大變革目標』(MTP)，其中又可以細分為構成的外部五大屬性以及內部五大屬性：
外部五大屬性（ SCALE ）：
- Staff on Demand（隨需求聘僱員工）
- Community & Crowd（社群經營與眾籌）
- Algorithm（演算法）
- Leveraged Assets（槓桿化資產）
- Engagement（參與）
內部五大屬性（IDEAS）：
- Interface（介面）
- Dashboard（儀表版）
- Experimentation（實驗力）
- Autonomy（自治力）
- Social（社交）
不過我覺得許多特性真的都是比較適合2C 類型的公司？
2019年7月29日 星期一
2019年7月25日 星期四
微服務架構或單體式架構?先從團隊認知負擔談起
自從鳳凰計畫以後都一直有訂itrevolution.com 在 SoundCloud 上的頻道
今天一早推送的新書試聽 Team Topologies 的新書，一聽驚為天人，感覺正在回答我最近面對與思考的問題，有興趣的可以聽這個演講。
2019年7月23日 星期二
2019年5月27日 星期一
我們面對的是棘手問題還是單純問題？
人生三部曲：
單純問題
小時候面對的都是那種問題被定義清楚的挑戰(如考試)兩難問題 (成年人只能選擇，沒有都簡單對錯)
出了社會越來越多人感到迷茫，因為要面對更多的是兩難的問題，沒有正確解與唯一解，更慘的是從小沒有培養面對這種兩難問題能力。棘手問題 (wicked problem )
當出了社會一陣子後，又會面對人生的另一個關卡，也使許多人的天花板，就是要面對棘手問題，棘手問題(wicked problem)是1973 Berkley 兩位教授(Rittel and Webber) 提出的定義：是指一個困難或不可能解決的問題，因為這個問題不完整、矛盾、不斷變化且往往難以識別或定義。 英語中使用「wicked」是指一種抵抗的決心，而不是指邪惡 ，故通常不翻譯為「邪惡問題」。另一種對棘手問題的定義是「問題因其複雜的社會意涵，而沒有任何能夠確定的停止點 。」且因為復雜的相互依賴性，試圖解決棘手問題的行動或方法可能會造成其他問題的產生。
2019年4月25日 星期四
Spark+AI Summit 2019 Keynote 重點搶鮮看
熱騰騰的 Spark+AI Summit 2019 的影片陸續出爐了，讓我們先來看看 Keynote 的重點內容 - Reynold Xin (Databricks), Brooke Wenig (Databricks)
第一個重點就是針對Unify Data 處理和AI Databricks 做了什麼努力，去年他們提出 Hydrogen 為了讓Spark 能更方便跟各種 ML lib 串接。
而今年的 Spark 3.0 放了更多重點在於讓 jvm base 的底層可以支援更多向量矩陣運算和GPU支援。
再來就是因應Kubernetes 的崛起，Spark 勢必得更加密切的與Kubernetes整合。
再來就是 Spark 3.x 想要解決 Data scientist 的痛，因為 Data scientist 通常用 python + panda 在他們的個人電腦上建模型和測試，但是一旦要scale 就得重寫code porting 到 spark，此外雖然看起來都是dataframe 但是實際上理念卻是差很多，所以stackoverflow 上常常都是這些型態轉換的問題。
於是Databricks推出 Koalas: Panda DataFrame API on Spark，最神奇的就是只要把panda的任function 換個名稱koalas 就無痛轉移了....XD
相信Data scientist 和 Data engineer 一定很期待，也可以少很多工~
2019年4月11日 星期四
從孫子兵法看今年Google Cloud 的策略
兵法到底要怎麼用在人生和企業經營？
節錄一段 #華山講孫子兵法 的一段就有很好的解釋：
今天大家都想學《#孫子兵法》並且把《孫子兵法》運用在企業經營裡面，但是你也要知道軍事兵法和企業經營的區別。
企業的競爭戰略確實是脫胎於軍事戰略，包括我們的企業管理也是從軍隊管理思想裡面發展出來的，因為人類社會是先有軍隊，后有企業。但軍事對抗和企業競爭有一個最大的本質區別——軍事是 零和游戲 ，而企業競爭不是。 零和游戲就是沒有雙贏，不是你贏，就是我贏，企業競爭是 重複博弈。
但是企業競爭不一樣。 市場是無限的，是發展的，是變化的，甚至可以說市場是多空間的，隨時可以有新的市場被創造出來。
做企業的人研究知己知彼，最重要的就是不要被競爭對手帶走，而是自己要聚焦於研究顧客，研究自己，專心搞研發，少研究對手。
所以商業中知己知彼的“彼”不是競爭對手，而是顧客 ﹔你想要做好經營，你就得了解顧客，你知道對手有什麼用呢？
有一句話：
“競爭思維就是沒有競爭力的原因”。
你總去考慮競爭對手，你的思維就會被競爭對手帶走而不去關注顧客。 你不知道自己是誰，也不知道顧客要什麼，僅僅知道對手有什麼用....
雲端大廠的競爭
就像三大 Cloud provider 之間的競爭，如果只是關注領頭羊的 AWS 有什麼，那我也要有，那對於廠商和消費者都是雙輸的局面，不過還好 GCP & Azure 也不是省油的燈，都另外有好好發展各自的強項，重點還是理解客戶要什麼，可以幫客戶解決什麼問題，這樣一來市場的動態變化還很難說...
因為別人有什麼什麼，所以我們也該有什麼，不然沒辦法賣，這充其量也只是Me too ，更不要從 Me too 的角度去競爭，應該反過來思考我們能提供什麼是別人無法提供，或是我們能做好什麼是別人不想碰的？
這次Google 更是推出 Hybrid Cloud 的殺手鐧 GKE On-Prem 以及 Anthos
目標有兩個：
1. 針對其它 Cloud Provide (AWS, Azure) 的客戶降低轉移門檻
2. 針對使用 Private Cloud 的客戶提高使用雲端的意願，並且幫助管理與轉型
顧客聲音，這幾個字幾乎成了今年Next大會的官方慣用語
而 Ithome 這篇文(【舊金山Next直擊】Google雲端新CEO大喊「聆聽顧客聲音」原則，更要開始搶攻多雲混合雲戰場 ) 更印證了我的想法，聆聽顧客聲音，專注在自己的強項。
而Google Cloud CEO Thomas Kurian 提出的戰略方針有四個特點：
特色1：GCP轉而聚焦數位轉型企業，而非所有企業
特色2：聆聽顧客聲音，走下雲端進軍多雲混合雲
特色3：大秀各產業指標型企業採用情況，更強調GCP新企業顧客
特色4：不是與開源爭利，而要和開源產業聯手服務企業
2019年4月10日 星期三
Stack overflow Developer Survey Results 2019
熱騰騰的 Stack overflow Developer Survey Results2019 就在出爐了，在這份針對stackoverflow 全球 90,000 developers 的問卷，看到了許多有趣的統計資訊，首先大概主要是因為語言的關係，亞洲區的參與率普遍都低，台灣佔了 0.21%，不過以人口比例來說應該也算不錯啦...XD
而這份Survey 有幾個重點：
- Python 再度擠掉Java 蟬聯成長最快速的語言，此外也是Rust 外排名第二最受歡迎的程式語言
- 許多人第一次寫程式都是在他們16歲的時候
- DevOps specialists and site reliability engineers 是屬於待遇最好，最有經驗的工程師，且都滿意他們的工作，換工作的意願最低...XD
- 開發者中中國的開發者是最樂觀的，相信他們的小孩會有更好的未來，反觀西方世界的法國和德國則是最不樂觀的
- 對於什麼會妨礙生產力這件事，不同性別有著不同的困擾，男人認為跟非技術人員工作很困擾的是，而女人認為在一個有毒的職場工作環境(toxic work environments) 讓他們很困擾。
- Stackoverflow 的重要性，可以節省開發者一週 30 to 90 分鐘~XDDD
2019年4月3日 星期三
2019年4月2日 星期二
工程師鍛鍊接軌世界的能力從stackoverflow 開始
說來慚愧，過去一直以來就是把 Stackoverflow 當作是google 問題解答的終點站，反正找到解答參考完答案就離開了，沒有login 也沒有給予解答的人感謝(投票)，更不用說加入這群討論甚至回饋社群。
最近看到一個問題，你對這個世界(社群)帶來多少impact? 能影響了多少人？雖然我有寫blog 有經營粉絲團，但畢竟是小眾。因為家庭因素也比較少在社群走跳甚至演講和分享，所以為了回答自己這個問題，我定下給自己定下了一個新的練習的目標，就是要在stackoverflow 上面好好的問問題和回答問題累積積分，不玩則已深入研究以後才驚覺這真得是一個設計良好的成就系統，可以鍛鍊許多能力：
- 英文書面溝通能力 (因為在這邊你全部都得用英文溝通，不管是問問題還是回答問題)
- 解決問題的專業能力 (因為你要提出有效且讓人看的懂得解決方案)
- 看懂問題的能力 (就算是你熟悉的專業領域，也會看到千奇百怪的問題~)
- 審查問題的能力
- 審查答案的能力
- 解決客戶問題的能力 (前提是你的產品要夠有名到客戶到上面問...XDD)
2019年3月21日 星期四
infrastructure as code 的組合技 Ansible + Terraform
今天在 Cloud Native Taiwan User Group 看到這篇關於Ansible 與 Terraform 的組合技，就非常有感觸，DevOps 的核心精神之一就是 Infrastructure as Code，但是 Code 就會變成 legacy code 😂，越少去碰它，越少去維護就會臭得更快，尤其是 tool 更新後....
2019年3月20日 星期三
中文抽詞
首先先產生最大抽詞的sliding windows
在不久的將來
不久的將來大
久的將來大家
的將來大家認
將來大家認知
來大家認知中
大家認知中的
+-------------+-------------------------+
|postfixCorpus| nGramList|
+-------------+-------------------------+
| 在不久的將來|[在, 在不, 在不久, 在不久的, 在不久的將]|
| 不久的將來大|[不, 不久, 不久的, 不久的將, 不久的將來]|
| 久的將來大家|[久, 久的, 久的將, 久的將來, 久的將來大]|
| 的將來大家認|[的, 的將, 的將來, 的將來大, 的將來大家]|
| 將來大家認知|[將, 將來, 將來大, 將來大家, 將來大家認]|
| 來大家認知中|[來, 來大, 來大家, 來大家認, 來大家認知]|
| 大家認知中的|[大, 大家, 大家認, 大家認知, 大家認知中]|
| 家認知中的行|[家, 家認, 家認知, 家認知中, 家認知中的]|
| 認知中的行銷|[認, 認知, 認知中, 認知中的, 認知中的行]|
| 知中的行銷將|[知, 知中, 知中的, 知中的行, 知中的行銷]|
| 中的行銷將等|[中, 中的, 中的行, 中的行銷, 中的行銷將]|
| 的行銷將等於|[的, 的行, 的行銷, 的行銷將, 的行銷將等]|
| 行銷將等於數|[行, 行銷, 行銷將, 行銷將等, 行銷將等於]|
| 銷將等於數位|[銷, 銷將, 銷將等, 銷將等於, 銷將等於數]|
=========== nGram word count ===============
使用 nGramList 把每個String 切成各種nGram 並且計算在全部詞中出現的次數
在
在不
在不久
在不久的
在不久的將
+-----+---------+
|nGram|wordCount|
+-----+---------+
| 在 | 2447|
| 在不 | 27|
| 不 | 2196|
| 不久| 3|
| 不久的| 2|
| 久| 23|
| 久的| 4|
| 的| 10974|
| 的將| 8|
| 的將來| 2|
| 將| 354|
| 將來| 10|
| 來| 1094|
| 來大| 8|
| 來大家| 3|
| 大| 1271|
| 大家| 112|
| 大家認| 2|
| 家| 308|
| 家認| 2|
| 認| 506|
| 認知| 88|
| 認知中| 9|
| 認知中的| 5|
把出現太少的nGram(必須大於minSupport) 和太短的字詞濾掉過後 ，再去產生 nGramCoherentWordList
這邊我們通常設定minWord =2
+——————+————+————+
postfixNGram | chars | entropy
+——————+————+————+
首 先
+——————+————+————+
首先 先
+——————+————+————+
首先先 來
+——————+————+————+
首先先來 說
+——————+————+————+
首先先來說 明
+——————+————+————+
然後把同樣的postfixNGram group by 起來，把相同的chars 串起來成為 rightWords
再利用 rightWords 去算 rEntropy
以下面的範例”三個” 右邊會接的詞有 月月月理月月月月月層ㄧ內月月原方原女月目能人月特第第月原月月
先統計每個詞的數量再去算entropy
月 15
理 1
層 1
第 2
+------------+----------------------------------------------------------------------------------------------------+------------------+
|postfixNGram| rightWords| rEntropy|
+------------+----------------------------------------------------------------------------------------------------+------------------+
| 交換| 時學生計產的過商學禮學資這學學學時時標就學計練的時期期學學學的達對之的的期學學時學機明學再學計整| 3.682203857235151|
| 交換學生| 經身為對時經體在生的回時的的|3.1820058147602137|
| 交易| 是即再的關如的營紀|2.9477027792200903|
| 交流| 了這溝進對就爬基而意而進文的的雖這並分的合| 3.880179922675738|
| 交通| 與方方費工裝同購規不費上|3.2516291673878235|
| 亦| 有時利或十能即可正邪是能是是無於可是積會選有可有可能隨可或能云有有友可讓想要即| 4.077212078381128|
| 亦可| 找提以選控延| 2.584962500721156|
| 亦有| 不使過小柔| 2.321928094887362|
人們的生活| 幾定數其遊型| 2.584962500721156|
| 人力| 短與量安使量財量過而財到得短|3.1820058147602137|
| 人包| 設分含在等括與|2.8073549220576046|
| 人化| 的行行行的媒的從的推廣商和都| 2.896291529045928|
| 人卻| 會可是決因很| 2.584962500721156|
| 人口| 統年密的中| 2.321928094887362|
| 人可以| 走走因用即好協縮訴善善視穿| 3.392747410448784|
| 人和| 諧我同機國造資兩| 3.0|
| 人員| 回能透或的了中講在可來分工溝用信因之的到在主問的也只可有並就的也能編面或才掌更我將以但可於搜本做卻感不和也我| 5.282484261342596|
| 人回| 復來顧覆饋| 2.321928094887362|
| 人因此| 我每這從到在| 2.584962500721156|
| 企劃| 編或能書以以相上並的數因這很出透是的的書書這部等力能龍龍龍龍競專希主有公實或甚等的網等而前並給與操將提想書書書經甚書書從的等平的書提相案案經提與書| 4.964017114285987|
| 企劃書| 如篩包競也所並但搜找|3.3219280948873626|
| 企劃的| 成機機技多想|2.2516291673878226|
| 企業|管管近最尋可或或品品的所問達比工與當的來實概的的能能接管彼數完營及在家能利找提難或能透如資網整都以前組實聯將為品能參做能將提的都必聯的三成的前與能組或制管進與從家探增成社透來行品所品透與的也想在...| 5.770892470985168|
| 企業的| 品情思新服第第產行|2.9477027792200903|
| 企業能| 夠即有夠夠透把|2.1280852788913944|
| 企畫| 書開其方和| 2.321928094887362|
| 伍| 去前後後的也中末前膝是還|3.2516291673878235|
然後把左右entropy 都選出來 join起來
那種,10,3.3219280948873626,3.3219280948873626
那麼,14,3.5216406363433195,3.664497779200462
邪惡,13,2.3535339485774815,2.9312089489103226
邪惡勢力,6,2.584962500721156,2.584962500721156
部分,64,5.177668898701708,2.9940566354932776
部落客,8,3.0,3.0
部落格,12,3.2516291673878226,2.91829583405449
部門,32,4.152518266288633,4.265319531114783
郵件,17,3.4104172527605203,2.5580510765444573
都不,34,4.314972767530033,4.910992253015046
都不會,6,2.2516291673878226,2.584962500721156
都以,6,2.584962500721156,2.584962500721156
都可以,29,4.857980995127575,4.487122805397799
都在,32,4.538909765557392,3.6831573285181993
都對,8,2.75,2.75
都很,10,3.3219280948873626,3.3219280948873626
都必須,5,2.321928094887362,2.321928094887362
都想,6,2.584962500721156,2.584962500721156
都是,126,5.984507619970812,6.099475487514781
都是在,6,2.2516291673878226,2.584962500721156
都是我,7,2.8073549220576046,2.8073549220576046
都會,52,5.301307266176413,4.979097891134807
都有,51,4.817334352276654,4.934160940904763
都沒,17,3.0574760762899325,4.087462841250341
都沒有,6,2.584962500721156,2.584962500721156
都能,58,4.961874642523482,4.879172375590212
都能夠,10,3.3219280948873626,3.1219280948873624
都要,16,4.0,3.875
把ngram 分解，”都是” —> “都” “是” 用來計算coherence
[2018-04-20 14:41:12,245][INFO] WordExtractionService : Select decomposeWord.....
+----+----------------------------------------------------------------------------------------------------+
|word| metas|
+----+----------------------------------------------------------------------------------------------------+
| 三|[[三年, 13, 0], [第三, 18, 0], [在大三, 15, 1], [大三, 46, 0], [三十, 7, 0], [的三, 11, 0], [前三, 11, 0], [三個, ...|
| 三個| [[三個月, 15, 1], [有三個, 10, 0]]|
| 三時| [[大三時, 12, 0]]|
| 上|[[世界上, 19, 1], [上會, 7, 0], [上有, 16, 0], [加上, 78, 0], [網路上, 37, 1], [路上, 65, 0], [上的, 103, 0], [系上...|
| 上我| [[加上我, 9, 0]]|
| 上數| [[上數位, 7, 1]]|
| 上最| [[世界上最, 5, 1]]|
| 上的| [[網路上的, 13, 1], [以上的, 18, 0], [平台上的, 6, 1], [線上的, 7, 0]]|
| 上社群| [[線上社群, 5, 0]]|
| 上線下| [[線上線下, 6, 0]]|
| 上透| [[上透過, 5, 1]]|
| 上進| [[上進行, 9, 1]]|
| 下|[[接下, 25, 0], [下來, 25, 0], [當下, 25, 0], [下的, 29, 0], [以下, 14, 0], [之下, 21, 0], [留下, 10, 0], [下了, ...|
| 下了| [[訂下了, 5, 0]]|
| 下來| [[接下來, 9, 0]]|
| 下去| [[堅持下去, 13, 1], [下去的, 8, 1]]|
| 世代| [[的世代, 6, 0], [世代的, 9, 1]]|
| 世界|[[世界上, 19, 1], [全世界, 8, 0], [拯救世界, 28, 1], [這個世界, 12, 1], [這世界, 5, 0], [改變世界, 8, 1], [世界在, 10, 1]...|
| 世界上| [[世界上最, 5, 2]]|
| 世界的| [[拯救世界的, 9, 1]]|
logger.info("recoverWord.....”);
產生要拿去算coherence 的組合
[2018-04-20 14:54:08,306][INFO] WordExtractionService : recoverWord.....
+--------------+------------------------+
| key| values|
+--------------+------------------------+
| [三個, 31, 0]| [[個, 1558], [三, 223]]|
| [三個月, 15, 0]| [[個月, 130], [三, 223]]|
| [三個月, 15, 1]| [[月, 186], [三個, 31]]|
| [三十, 7, 0]| [[十, 110], [三, 223]]|
| [三天, 13, 0]| [[天, 418], [三, 223]]|
| [三年, 13, 0]| [[年, 406], [三, 223]]|
| [三次, 5, 0]| [[次, 329], [三, 223]]|
| [上不, 10, 0]| [[不, 2196], [上, 1052]]|
| [上也, 9, 0]| [[也, 1316], [上, 1052]]|
| [上了, 10, 0]| [[了, 1426], [上, 1052]]|
| [上任, 5, 0]| [[任, 336], [上, 1052]]|
| [上來, 7, 0]| [[來, 1094], [上, 1052]]|
| [下定決心, 15, 0]| [[定決心, 15], [下, 558]]|
| [下定決心, 15, 1]| [[下定, 19], [決心, 31]]|
| [下定決心, 15, 2]| [[下定決, 16], [心, 604]]|
| [下我, 34, 0]| [[我, 4219], [下, 558]]|
| [下我們, 7, 0]| [[我們, 376], [下, 558]]|
| [下我們, 7, 1]| [[下我, 34], [們, 699]]|
| [下的, 29, 0]| [[的, 10974], [下, 558]]|
| [下載, 8, 0]| [[載, 30], [下, 558]]|
| [不上, 13, 0]| [[不, 2196], [上, 1052]]|
| [不了, 18, 0]| [[不, 2196], [了, 1426]]|
| [不但, 18, 0]| [[不, 2196], [但, 718]]|
| [不佳, 8, 0]| [[不, 2196], [佳, 42]]|
| [不停的, 5, 0]| [[不, 2196], [停的, 6]]|
| [不停的, 5, 1]| [[不停, 8], [的, 10974]]|
| [不僅, 66, 0]| [[不, 2196], [僅, 98]]|
| [不僅能, 10, 0]| [[不, 2196], [僅能, 11]]|
| [不僅能, 10, 1]| [[不僅, 66], [能, 2179]]|
2019年3月2日 星期六
一個專業的雲端架構師需要具備協助建立團隊文化的能力
Google SRE implement DevOps
在Coursera 上 Google Cloud Professional Cloud Architect 的課程，原本以為是一個以技術為主的課程，上了之後才發現遠遠不只這些，而且有需多部分發人省思，一個專業的雲端架構師除了技術上要協助客戶釐清需求外，更重要的是幫助客戶完成商業需求，甚至要協助建立團隊的開發維運文化！
2019年2月20日 星期三
Google Cloud Load Balancing 將要針對 user-define request header 收費
今天早上收到這封信，腦中浮現出了幾個字
原本是一個Google 佛心來著的免費加值服務，現在卻變成要收費了，所以現在得好好算一下是不是要繼續使用這個服務。
訂閱：
文章
(
Atom
)