2019年11月11日 星期一

Apache Spark 3.0 Release Preview






一轉眼 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 在思考與運作。沒有誰對誰錯,只有當下適合不適合,與分配的比例。


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 StartupDesign Thinking、Agile)。

剛好最近新的工作是要負責開發新產品,同事也提議要來舉辦讀書會,我就找到了這本有趣的書,還真的有人再探討,同樣是精實創業( Lean Startup)同樣是開發新產品, B2B 與 B2C 有什麼差異?

2019年9月17日 星期二

加速 (Accelerate) - Lead time 我搞不懂你啊



在 Accelerate 第二章看到這個表(把Dev & Ops 兩個階段分開來看),就讓我想到之前看到上面 Gartner 那張圖,Design Thinking,Lean Startup,Agile 應該要整合在一起,這張圖告訴我們,只專注在Agile 上的優化可能還是無法解決商業成功的問題,這也是我一直以來在問自己的問題,縱使在產品 Delivery 上怎麼優化(當然不可能完美,但是還算有到一定程度),感覺對於商業成功的影響還是有種施不上力的感覺。




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月23日 星期二

得到萬維鋼的書單



一直以來我在得到最愛的專欄就是萬維鋼的精英日課,除了他都會講許多美國最新出版的有趣書籍外,重點會把自身的理解和經驗融合在裡面,甚至會把各本書之間的關連性串在一起,因此很多時候真的去看了那本書反而會覺得沒他講的精彩....XD


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 上面好好的問問題和回答問題累積積分,不玩則已深入研究以後才驚覺這真得是一個設計良好的成就系統,可以鍛鍊許多能力:
  1. 英文書面溝通能力 (因為在這邊你全部都得用英文溝通,不管是問問題還是回答問題)
  2. 解決問題的專業能力 (因為你要提出有效且讓人看的懂得解決方案)
  3. 看懂問題的能力 (就算是你熟悉的專業領域,也會看到千奇百怪的問題~)
  4. 審查問題的能力
  5. 審查答案的能力 
  6. 解決客戶問題的能力 (前提是你的產品要夠有名到客戶到上面問...XDD)

2019年3月2日 星期六

一個專業的雲端架構師需要具備協助建立團隊文化的能力

Google SRE implement DevOps



在Coursera 上 Google Cloud Professional Cloud Architect 的課程,原本以為是一個以技術為主的課程,上了之後才發現遠遠不只這些,而且有需多部分發人省思,一個專業的雲端架構師除了技術上要協助客戶釐清需求外,更重要的是幫助客戶完成商業需求,甚至要協助建立團隊的開發維運文化!

2019年2月20日 星期三

Google Cloud Load Balancing 將要針對 user-define request header 收費



今天早上收到這封信,腦中浮現出了幾個字養套殺使用者付費...XD
原本是一個Google 佛心來著的免費加值服務,現在卻變成要收費了,所以現在得好好算一下是不是要繼續使用這個服務。


你如何衡量你的人生 - 為你的孩子製造機會解決困難



最近看到朋友再讀『你要如何衡量你的人生』,看到他節錄的幾個章節很有感覺,所以又拿起來重新翻了一次,之前看這本書時小朋友還很小,但是現在小朋友大了,自己也面對許多人生的新問題,重新看再看這本書就更有感受了。

2019年2月10日 星期日

如何在 Google App Engine 2.0 使用 Go 1.11 開發



來到了Go的世界感覺的到的第一件事就是什麼都好輕啊,用的資源好少啊,難怪越來越多公司和專案都移到Go 得世界。 不過並不是輕和快就能輕易讓我們轉換語言,必須還得考量上手的速度以及相關library的支援度,好在Go 的社群也還算蓬勃發展,所以該有的library 都有人開發,唯一要注意的就是不像Java 有許多 Apache 這種大型社群 support的專案,go 的library 專案大多是個人開發,所以這些專案的熱門度,和維修狀態就需要格外的注意。


2019年2月2日 星期六

使用Mac 系統移轉輔助程式搬家後造成 zsh 損毀

圖片來源:官網


最近也遇到電池膨脹的災情,只好參考官網:https://support.apple.com/zh-tw/HT204350



搬家後產生了一連串的錯誤,主要都是Homebrew 和 Zsh 設定跑掉或衝突所致

Warning: git 2.20.1 is already installed and up-to-date
  To reinstall 2.20.1, run `brew reinstall git`
Error: Git must be installed and in your PATH!

2019年1月26日 星期六

英雄之旅 - 談商管類小說的套路

來源:Ted



英雄之旅這個套路來自二十世紀的神話學大師坎貝爾 Joseph Campbell 在 1948 年所著的《千面英雄》中的理論:所有英雄歷險故事的背後,其實蘊藏著同一形態的故事!

原始的分類是三幕:
  • 啟程(或隔離)
  • 啟蒙(或下凡、神化)
  • 歸返

2019年1月19日 星期六

回顧與檢討 Agile meetup - 為什麼我的敏捷總是卡卡的?


故事是從敏捷診療室開始.....(其實是靠正妹吸引目光)

故事的開始

  • 為什麼書上的方法用到我的組織都卡卡的? 
  • 為什麼社群介紹的Design Sprint 感覺很好用但是公司PM都不敢興趣?
  • 敏捷不是要短週期交付?但是客戶不願跟我們意嘗試這種方法?
  • 聽Seafood 說要吸引狼屬性的成員加入並且skin in the game很有道理,可是...我並沒有招募人事權?
  • 為什麼HR 都不支持我們推行敏捷?

從 2018年第一次到敏捷診療室駐診,到參加 DevOpsDays 的 Open space technology 我發現很多時候大家在討論敏捷推行問題時,因為沒有把情境與context 定義清楚,常常會有岳飛打張飛的情境出現,雖然討論的很熱烈但是似乎都沒具體的結論(不過~誰說一定要有結論,Open space 本來就只是要讓大家討論~:P),大概是因為我大公司小公司,B2B/B2C和做專案和做產品的公司都待過,我隱約覺得問就是出在組織特性的差異。

2019年1月9日 星期三

敏捷引導者練習 - Crossroad 人生的十字路口



『交叉路口』(Crossroad)這個桌遊是由東京『慶應大學』(Keio University)的『吉川肇子』教授( キッカワ トシコ; KIKKAWA TOSHIKO)根據 1995 年的日本阪神大地震於 2003 年所設計出的『模擬遊戲』,同時於 2004 年時在京都大學正式發售。

 在網路上能找到的就只有這篇文章:Select “Yes” or “No,” then simulate and pass down disaster experiences Naomi Hama, Director of Kobe Crossroads Society


2019年1月7日 星期一

Google Cloud Dataproc 如何建立 Custom Image 加快 PySpark 部署環境速度



這陣子最常使用的GCP服務就是 Cloud Dataproc , Cloud Dataproc 是為了簡化Spark及Hadoop服務而設計,能讓使用者進行批次處理、查詢、資料串流及機器學習等工作,其自動化工具可協助使用者更快新增及更容易管理資料叢集,並且能在不使用時關閉,以降低成本,使企業能把心力花在資料分析的核心工作上。

對我來說他有幾個優點:
  • 不用自己維運一組Yarn Spark Cluster,更不用煩惱需要擴充配置的問題
  • 需要用就直接開,開完就砍掉,一切自動化又省錢

加速 (Accelerate) - delivery performance 與 organizational performance 有關連嗎?

加速 (Accelerate) 第二章關於高績效團隊與低績效團隊的差距


天下武功無堅不摧為快不破,在加速 (Accelerate) 這本書的第二章裡找出了幾個指標,透過這幾個指標可以瞭解這個團隊的 delivery performance,分別是:
  • 部署頻率 (Deployment Frequency)
  • 對於變化的反應時間 (Lead Time for Change )
  • 平均修復時間 (MTTR)
  • 變更失敗率 (Change Failure Rate)

2019年1月6日 星期日

每天比昨天強0.1倍視覺化Trello管理法



The most dangerous poison is the feeling of achievement. The antidote is to every evening think what can be done better tomorrow.
最危險的毒藥是成就感。解藥是每天晚上都去想明天如何可以做更好。
───Ingvar Kamprad, Founder of IKEA


最近受到 91 的計畫感招,也要開始實行每天比昨天強0.1倍視覺化管理法!




原本我都會透過Evernote 做兩件事,收集讀書筆記,以及每一季都會整理這一季的重點成長或是milestone ,但是覺得91 的方法更直觀,而且應該執行起來會更有成就感。



2019年1月1日 星期二

初探專業引導技巧 (The Skilled Facilitator)


這本書:專業引導技巧 (The Skilled Facilitarator) 是逛網路書店偶然間看到的,看到內容後裁決的驚為天人,因為這本書幫我釐清了許多定義型的問題,而這些問題也是之前學引導時常常會問的問題:
  • 何時該用引導?
  • 如果我是主管適合用引導嗎?還是會變成誘導?
  • 為什麼引導技巧學的時候看起來很簡單,但是用起來好難?
  • 當在引導團隊討論時,發現團隊走偏,或是討論內容有問題好想參與討論怎麼辦?