[研討會心得] 2019/03/28 CNTUG#14@LINE

前提

三月第一場社群活動邀請到 CNTUG (Cloud Native Taiwan User Group) 社群到 LINE 來舉辦。也請到遠從東京的維運開發團隊 Verda Team 來台灣分享,除了讓更多人能夠了解這樣的架構之外,也希望能夠引發一些討論甚至可以互相交流。

How We build Kubernetes service by Rancher in LINE / LINE 東京 Verda Team, 李飛翔

投影片

來自東京 Verda Team 的李飛翔也跟大家分享 LINE 是如何透過 Rancher 來打造 LINE 自己的 KaaS (Kubernetes As A Service) 。本文一開始先介紹了 Rancher 的一些功能與 Rancher 2.0 的目前狀況,也會介紹我們如何使用 Rancher 來打造 KaaS 。

LINE 如何透過 Rancher 打造 KaaS

  • API Server:
    • 首先左方可以看到,有一個 API Server 負責收發使用者的指令。 除了作為 Proxy 之外,也可以限制使用者使用有限的 Rancher 功能之外也可以整合一次對於多個 Rancher 的操作。
  • Kubernetes Provider:
    • 透過 Kubernetes Provider 是一個 Kubernetes 集群來管理多個使用者的集群( User Kubernetes Cluster)
  • User Kubrernetes Cluster:
    • 每一個服務或是產品會使用一個或是多個 User Kubernetes Cluster 。裡面都是透過 OpenStack 來建立 VM ,並且透過 Rancher 來部署。

如果今天一個開發者需要一個新的集群來部署一個新的服務。他透過 API Server 下指令部署新集群,這時候會透過 Kubernetes Provider 來運行 Rancher 來開啟新的 VM 並且來部署 Kubernetes 設定到該集群。

如此的輕鬆容易嗎? 透過一個問題來講解整個 Kubernetes 的架構與容易出錯的地方

架構雖然清楚又明瞭,但是事實上要運行卻沒有那麼的容易。這邊講者也分享藉由 “Websocket 無法正常建立“的錯誤,來分享如何追蹤這個問題來解決真正的問題。

如同上圖提到 Kubernetes Provider 是透過 WebSocket 與 Kubernertes User Cluster 溝通。有一天忽然發現了 WebSocket 忽然斷線的狀態,回過頭來看 Kubernetes DNS 的設定, Container 網路的架構甚至也解釋了flannel 網路架構。透過這些架構的解析,聽眾會了解在實體機 (Baremetal) 上面架設 Kubernetes 其實遇到的網路問題其實更多更複雜,因為牽扯跨實體機器與跨網路節點。

找到問題之後,試著做出一個 patch 來修正問題。確定成功之後也將這個問題回饋到 Rancher 的 OSS 來貢獻 LINE 研究的結果。

類似的問題就是 Verda team 的人每天所遭遇的問題,不斷睇偵測與測試問題的原因,透過不同層面的觀點來了解與解讀問題。如果最後發現問題可能是出在 Kubernetes 源碼部分, LINE 也不吝嗇貢獻出發現的問題與修正的方式。

An operator deploys/manages/configures LINE bot atop Kubernetes / 白凱仁 (Cloud Native Taiwan User Group)

投影片

接下來由 CNTUG 的共同主辦人白凱仁所帶來的很有趣的主題,透過 Kuberbetes 來部署一個 LINE chatbot Operator。

原因是打魔物獵人需要查詢許多魔物的弱點跟容易攻略的弱點,但是要用電腦找太慢了,於是就想說寫一個 LINE chatbot 。但是考量到魔物其實會不斷的修改跟增加,如果好不容易把魔物”火龍“的弱點加入之後,隔天又想查詢”角龍”,那這樣不就得要不斷的修改跟更新你的代碼。

加上最近 Kubernetes Operator 其實是一個熱門的話題,但是一直沒有一個有趣的應用,於是講者就透過 Kubernetes Operator 將 LINE chatbot 部署起來。

(架構圖節錄來自投影片,獲得作者同意)

透過上圖可以了解 LINE Bot Operator 分成 Bot Controller 跟 Event Controller 兩個部分。Event Controller 透過 EventBinding 的方式可以將不同的 event 一一加入卻又不需要撰寫太多額外的代碼。 以下分享一個講者所提到的例子:

透過部署以上的 EventController 只要使用者在對話匡裡面打入”火龍” 或是 “Rathalos” 就顯示出以下那些文字,而要增加一個魔物也很簡單只要再增加另外一個相似的 YAML 設定然後將這個 EventController 部署上去即可。既可以讓會眾了解 Kubernetes Operator 的強大,也可以讓 LINE Chatbot 的開發上有了另外一種新的思路。

總結

很開心邀請到 CNTUG 社群來到 LINE 台灣辦公室舉辦 meetup ,也很榮幸邀請到 LINE 東京 Verda team 的成員來分享 LINE 私有雲打造的方式。並且透過分析問題的方來帶大家走過這個流程,並且能夠分享透過閱讀 Racher 源碼的方式來解決埋在深處的問題,並且貢獻回去。 Kubernetes As A Server (KaaS) 是一個具有龐大願景的系統,這樣的流程需要更多的新血,我們也需要各位 Kubernetes 與網路高手的加入。如果你也想要更深入了解並且參與開發這樣的系統,可以考慮投你我們 Verda team 的相關職缺。

[TIL] LINE Developer Day 2018 投影片內容分享 - LINE Token Economy

LINE 區塊鏈平台及代幣經濟 - LINK Chain及LINK介紹 from LINE Corporation

前提

作為 LINE 的開發技術推廣,除了一般的 LINE 平台技術之外(也就是聊天機器人)當然也要懂公司所有的相關產品與技術。 去年在 LINE TechPulse 所邀請到的 LINK (LINE Token Economy) 來分享為何 LINE 需要 LINK 與其重要性。

稍微將相關投影片做一些翻譯與解釋,主要先針對為何 LINE 要做自己的區塊鏈服務與 LINK 想要解決的問題與想要達到的成果。希望能讓許多人更了解 LINK 的用途。

內容分享

P.3 LINE NEEDS Blockchain and Cryptocurrency

這一頁解釋了為什麼 LINE 需要自己做區塊鏈的服務。會從三個角度來看:

  • 使用者與服務的關係
  • 網路效應(需求方外部性: Network Effect)擁有權
  • 全球化平台

接下來從這三個面向來解釋。

使用者與服務的關係的演進關係

(P.4) 這個表格敘述服務與使用者關係的演進史:

  • 在網際網路以前使用者都是付費方,而服務提供商都是兜售服務來獲利。
  • 有了網際網路之後,由於使用者的人數變成轉換金錢的方式。於是服務變成都是免費(其實不是免費,而是第三方買單),而使用者變成是服務的接受者。 (網路新聞,網頁,官方網站.. 等等)
  • 到了現在“使用者產生內容”( UGC: User Generated Content ) 正紅,如何鼓勵使用者主動地產生大量而有價值的內容,就變成是很重要的事情。 (比如: 直撥主, 部落客…)

網路效應的擁有權

(P.5) 網路效應( Network Effect )是一個專有名詞講解的是使用者所獲得的效應會從著網路變大而越來越多。舉例而言就是社群媒體( SNS ) ,只要有更多人的加入裡面每一參與者能獲得的效應也就更大(越多人能聊)。

所以適時的獎勵系統( Incentive ) 可以幫助我們打造強壯的網路效應,讓每個人加入除了可以獲得更多的工具體驗外,也能有更多的參與感。

全球化的平台

(P.6) LINE 在全球有超過一億六千萬的活躍用戶,並且在世界各地都有相關的使用者。需要一個更好的方式可以讓不同國家的使用者可以相互交流,減少國家與國家間交易的限制與屏障。

透過這三個面向,我們可以了解 LINE 身為全球化平台,要打造更強壯的網路效應,並且讓使用者之間又更好的互動與更積極的參與服務與互動。 區塊鏈貨幣是不可或缺的。

(P.8) LINK(LN)作為虛擬數位加密貨幣,既是刺激使用者貢獻的獎賞,也是一種支付方式,更是一種工具。

(P.9)

  • 為了 dApps 與使用者所設計,必須要簡易使用不需要太多複雜的區塊鏈相關知識。
  • 作為分享與貢獻者的獎勵, LINK 不僅僅作為獎勵來刺激使用者外,也是一種方式來讓設計 dApps 的開發者來獲利的方式。
  • 作為連接經濟圈的唯一貨幣,不僅僅可以做為獎賞,開發者的獎勵外。更可以作為交易用途的中介。

(P.11)

這邊是拿 LINK 的私有鏈系統與一般透過 Ethereum 所打造的生態系與 LINK 生態系來作為比較。

  • Ethereum: 任何 dApps 要進行交易的時候,需要消耗一定數量的 GAS 。所以這時候的貨幣是 ETH ,但是使用者拿到的可能是透過 dApps 所產生的另外一種貨幣。 所以這樣的部份是有一點複雜的,
  • LINK: 相較之下 LINK 的系統由於是自己的私有鍊,所以作為交易的所使用的貨幣與使用者拿到的貨幣都是同一種。

(P.12)

  • 總發行量: 十億個 LINK (LN)
  • 不作為私有販賣之用,不作為 ICO ,只作為獎勵使用者之用。
  • 用途:
    • 80% 作為獎勵之用。
    • 20% 保留作為經營之用 (行銷,運作, dApp 推廣)。
    • 截至 2018/12 ,總共分配出去的有四百四十萬。

(P. 21)

透過 LINK 的生態圈, LINE 希望能更縮短實體世界與加密世界的差異性。 LINK 的目標是希望將實體經濟透過 LINE 的區塊鏈經濟系統帶到虛擬世界中。

也希望透過 LINK 成為唯一的貨幣可以在日常生活中作為使用。

(P.22)

不像許多的區塊鏈經濟都容易淪為貨幣的買賣與炒作之用,目前透過 LINK 其實已經可以跟許多現實世界的經濟活動產生互動。不論是找工作,買食物甚至是購物與內容分享都是希望能透過 LINK 來作為中間的貨幣媒介。

(P. 23)

接下來開始介紹已經完成的 dApps ,來看看究竟能在哪些服務之中取得 LINK 做為獎賞呢:

https://link.network/dapps/

  • 已經發行的:
    • BITBOX: 虛擬貨幣交易所,也是目前開放 LINK 作為交易的交易所
    • 4CAST: 使用者可以預測未來,如果結果正確可以獲得相關的報酬。
    • Wizball:透過虛擬貨幣作為的問與答系統(類似 Quora)
  • 另外三個還在開發的相關服務,分別跟美食評分,產品評鑑與地點評鑑有關。

(P.24) 當然除了 dApps 之外,LINE 內部的相關服務也有計劃將 LINK 整合進去。

總結:

LINE 作為全球性的平台,無時無刻都在思考著如何讓使用者與開發者獲得更好的體驗。要如何能夠讓開發者,使用者與平台三方之間能夠達成三贏的狀態。這就是需要有一些方式來改善,透過加密貨幣 LINK 可以讓使用者的貢獻獲得獎賞,開發者的努力獲得回饋,更可以鼓勵更多的人來使用平台。

Reference

[TIL] 關於 Golang 1.11 之後在 VSCODE 裡面的 GOROOT 設定

關於 vscode-go 的設定

使用 vscode 並且使用 Golang 1.11 之後版本的人,每次 Golang 版本更新可能會出現。

go: cannot find GOROOT directory: /usr/local/Cellar/go/1.12.1/libexec

之前我都手動改 vscode 裡面 goroot 設定,但是其實只要在 settings.json 增加以下這行就好。

{
....
"go.inferGopath":true,
....
}

Reference

  • https://github.com/Microsoft/vscode-go/issues/1879
  • https://github.com/Microsoft/vscode-go/wiki/GOPATH-in-the-VS-Code-Go-extension

[Coursera] Smart Contract (二)

Blockchain Specialization 系列上課心得

Smart Contract 課程鏈結: 這裡

文章鏈結:

前言:

Smart contract 的課程進入了第二週,不是很確定能不能夠在兩週連最後的程式作業都能夠完成。(看起來很難 XD) 不過還是希望能夠多寫一些部分,由於最終程式作業的部分題目就高達四頁滿滿的說明,看起來可能會需要多一個禮拜。 XDD

課程內容:

這部分的課程其實還蠻有趣的,包含以下的部分:

  • 了解 Smart Contract 的內容元素
  • Smart Contract 的程式語言 Solidity 的語法與語義
  • 如何透過 Smart Contract 來解決問題
  • 透過 Remix ( A Web IDE of Solidity) 來建立與部屬你的 Smart Contract

Week3:

回歸選票的智能合約

這個章節一開始就解釋關於 week2 的範例 Ballot 的內容。

  • 這是一個類似選舉的 Smart Contract
  • 只有主席能夠註冊候選人,其他人只能投票。
  • 主席一票代表兩分,其他人都只有一分。
  • winningProposal 會取得誰當選的結果

開始改進

但是其實這個範例有著許多設計不夠周全的地方:

  • 當沒有人註冊的時候, winingProposal 依舊會開票。
  • 投票沒有時間限制
  • 無法確定所有的選民都投票

解決第一個部分的問題,沒有投票的狀態

透過 modifier 來解決


   modifier validStage(Stage reqStage)
    { require(stage == reqStage);
      _;
    }

以上是 modifier validState 的定義,可以透過以下的方式來在 function entry 來檢查。

function vote(uint8 toProposal) public validStage(Stage.Vote)  {
 ......
 }

可以看的到,透過 validState 可以檢查輸入的狀態是否為事先定義的 regState

投票沒有時間限制

可以透過時間限制的方式來做,但是要如何在 solidity 裡面來檢查時間是否在有效期間內(事先定義為 30 seconds)

if (now > (startTime+ 30 seconds)) {stage = Stage.Done; votingCompleted();}

這邊也要註解一下: now 是 solidity 的保留自,裡面代表的是當前這個 block 被建立的時間。

這邊可以查詢相關 now 的文件,可以更清楚。 https://solidity.readthedocs.io/en/develop/units-and-global-variables.html?highlight=block.timestamp#block-and-transaction-properties

無法確定所有的選民都投票

比需要對每個 sender 來確認是否總票數有超過總人數,並且確定該 sender 並沒有過票。

 if (sender.voted || toProposal >= proposals.length) return;
 sender.voted = true;
 sender.vote = toProposal;   
 proposals[toProposal].voteCount += sender.weight;

關於各種不同的檢查方式在 smart contract 是否正常執行完畢

  • 使用 if … return
    • transaction 會 mined ,而且會執行成功。
  • 使用 modifier
    • Translation 會 mined ,但是執行會失敗

檢查方式透過執行完畢後,查看 detail 結果就可以看到

關於 Events 的使用方式

根據這篇文章的說明 https://media.consensys.net/technical-introduction-to-events-and-logs-in-ethereum-a074d65dd6 , events 可以分成以下三種類型:

作為回傳資料的方式

根據這段範例,可以看得出來 contract ExampleContract 的 function foo 是透過:

event ReturnValue(address indexed _from, int256 _value);

是作為回傳資料之用。

作為資料儲存之用

Week4: Best Practices

接下來這個章節來探討,究竟什麼才是 smart contract 的最佳應用。

Smart Contract 適合來解決

  • 分散式的問題
  • 點對點交易
  • Operate beyond the boundaries of trust among unknown peers.
  • Require validation, verification, and recording on a universally timestamped, immutable ledger

一些 coding 小建議

  • 不存放不相關的變數
  • 透過 modifier 來確保是否具有能夠執行 function 的條件 (切勿使用 if … return)
  • 只存必須的資料在 smart contract 之中
  • 不要將大量資料放在 smart contract 之中
  • 所有變數預設都是 private ,除非你特定加上 public 才能公開。
  • Public 變數在編譯的時候會自動產生 getter method
  • 將 events 使用在通知上面

在下列的時候使用 function access modifier :

  • 負責規則,法規與守則
  • 建立讀取 function 的基本守則
  • 將 application 相關的規則套用上去
  • 建立一個可驗證的元素可以用來檢視 smart contract

小結:

第三個禮拜跟第四個禮拜都開始深入使用 Solidity 一些比較重要的功能。包括了資料確認的 modifier 跟作為相關資料儲存或是回傳用的 events 。 這些東西才能夠顯示出來 Solidity 與 smart contract 跟其他語言與服務不同的地方。

Reference:

[Coursera] Smart Contract (一)

Blockchain Specialization 系列上課心得

Smart Contract 課程鏈結: 這裡

文章鏈結:

前言:

第二堂課其實拖得有點久,原本是在 LINE 就職前希望可以完成,但是也是拖到現在才完成。 不過這堂課有許多關於 Smart Contract 的細節討論,並且有不少程式碼可以寫 (Solidity) 。

透過線上模擬器 Remix 來學習 smart contract 其實蠻酷的,除了可以模擬 gas 的消耗外並且可以模擬多個點跑 smart contract 的結果。

課程內容:

這部分的課程其實還蠻有趣的,包含以下的部分:

  • 了解 Smart Contract 的內容元素
  • Smart Contract 的程式語言 Solidity 的語法與語義
  • 如何透過 Smart Contract 來解決問題
  • 透過 Remix ( A Web IDE of Solidity) 來建立與部屬你的 Smart Contract

Week1:

提出者 : Nick Szabo

在 1994 年首次提出 “Smart Contracts: Building Blocks for Digital Markets”

透過 Remix 來撰寫第一個 Smart Contract

Remix 網址 https://remix.ethereum.org/

這個範例很簡單,主要是拿來知道語法之用.

具有資料儲存的 Smart Contract

接下來要撰寫一個具有儲存空間的 Smart Contract ,其實也很簡單.就是透過 member variables 來儲存,並且可以透過 at the address 來建立兩個 Smart Contract ,並且可以檢查到兩個 Smart Contract 資料其實是互通的.(因為在同一個 node 上面)

一些需要在注意的細節:

  1. 能夠用來決定 Smart Contract 位址的為:
  • 建立者的位址

  • 建立者的隨機碼 (nounce)

  1. 透過線上Remix 系統,你要如何能夠找到 smart contract 的 bytecode
  • Compile 之後透過 detail 來查詢,結果如下。

  1. 如何來區別 Smart contract 的交易流程
  • Block number 跟 block 的總量。

Week2:

Smart Contract 基礎特性

  • Smart Contract 可以繼承(inherited) 來自另一個 Smart Contract
  • 執行 Smart Cotract 的需要消耗 Gas 其單位可以是 Ether 或是 Wei , 而 \(1 Ether = 10 ^ {18} Wei\)

Solidity 的一些特性

  • Int/uint 長度為 256 bits 。

  • 資料預設均為 private ,需要透過 get/set 來做存取。

  • 基本時間單位為: Second

  • Address: 20 bytes 的 Ehteruem address

  • Mapping 是一個 key -> value

    • 可以是 uint -> string
    • Struct -> struct 也可以
  • Message: 由兩個格式組成

    • Sender: 傳送的來源位置 (msg.sender)
    • Value: 傳送者送過來的 Wei (msg.value)

Solidity FAQ (會依據你使用的 Solidity 版本有關)

範例講解 miner

這個範例為課堂提供的範例,講解了關於 Solidity 的語言特性範例。裡面包含了 address, mapping 與 message。 稍微講解一下。

  • 兩個參數 miner (儲存一個位置, Balance 為一個 mapping (address => uint)
  • 透過兩個 function 來操作,但是都需要輸入 address
    • Mint: 代表類似挖礦的功能,會挖出自定義的貨幣 (coin) 。
    • Send: 代表轉帳類似的,會將自己的 Balance 內取的的 coin 轉給人。

Modifier

透過 modifier 能夠在 function 的進入點做資料一致性( Integrity ) 的檢查,寫法為:

這是一個 modifier 的範例,之後再 functiuon 只要加上:

  • public validStage(Stage.Reg) 會再進入 function 前檢查 Stage.Reg == stage,不然就不會跑 function

小結:

到了系列課程的第二個部分,一開始就給了不少的 Solidity 的範例程式碼來幫助了解整個語法與運作方式。 其實對於學習上來說是相當快速的。目前也只是介紹了一些簡單的語法,但是給的範例都還蠻實用的。除了有類似選票機制的 smart contract ,也有類似挖礦與轉帳機制的 smart contract。

Reference:

[好書分享] 世界一流菁英的77個最強工作法

(圖片參考 讀墨)

作者:金武貴  
原文作者:ムーギー.キム  
出版日期:2018/10/30

買書推薦網址: http://moo.im/a/notuLN

前言:

這本書會買是因為好像在 讀墨的一篇文章推薦裡面,本書介紹的工作法真的很值得學習。就買了電子書來看。 而且這本書的寫作方式相當符合暢銷文學作品的方式,比如說命名法,還有文章排版,可以參考『這本書要賣100萬本』的讀書心得。

這本書主要敘述作者身為財經專欄專家的金武貴,分享他在跟世界上不同國家的工作菁英工作時候發現對方的小習慣。並且用條列式與許多的範例來讓讀者更容易了解為何這些工作方式重要。

這些工作方式真的很值得學習: 從細節,專注,到堅持,自我學習與成長與熱愛你的工作。 每個工作法都是菁英的思維,很建議常常苦於工作成長受限的人來學習。

內容簡介:

本篇文章將七十七個工作心法(也可以說是良好的工作習慣)加以分類為以下的類別:

  • 基本功(最基本,連這些都沒有無法自詡為菁英):
    • 細節的筆記
    • 簡單扼要的信件
    • 串連想法的能力
    • 對於工作熱情的傳遞
    • 透過聲調的討論來講解溝通的重要
  • 自我管理:(比較像是良好的生活與工作心態,也是我最欣賞跟努力的部分)
    • 早起
    • 守時
    • 自我約束
    • 定時運動
    • 壓力管理
    • 學習習慣
  • 心裡的素質(有能力的人,往往心理素質都強人一等):
    • 自主性
    • 工作品質(論如何將一個小事情做到最好,最細)
    • 先見之明
    • 超乎期待(做超過自身待遇與被期待賦予的事情,絕對不要說不是我的事情就擺著爛!!)
  • 一流的領導人(當菁英變成主管後,該如何領導下屬):
    • 親切
    • 尊重
    • 讓部屬成長與得利
    • 以身作則
  • 自我實現(工作以外,更需要思考的好習慣):
    • 想做的事情,就要去做(選定自己熱愛的工作)
    • 熱愛你的工作,天賦的人不會退休
    • 活用強項(當你某件事情做得很好的時候,絕對不要免費幫人做)
      • If you‘re good at something, never do it for free.”
    • 組織團隊
    • 自我挑戰

心得:

如何變成受人尊重的職場菁英,如何讓自己在工作上能夠更加的順利與有成就,一直是常常被人拿出來的話題。不少的書籍都在講解如何做好筆記,如何管理上司與部屬之外,卻少有書籍像這本一樣有些章節從心理素質講起。

自職場上見過許多有能力的人,往往都是對於自我約束更努力的人。 最間單的就是對於食物,對於運動的堅持。我也是認為,一個成功的人往往對於自己訓練極致苛刻,對於時間的掌握能夠無比精確。 因為對於時間,對於自我約束的人都是在默默持續努力的人。

見過很多人對於工作很認真,但是對於自己生活的習慣無法約束。不能拒絕美食,不能持之以恆的運動(或是健身),每次喊著要學習卻無法認真學習玩一個段落。 都不是一個工作上菁英的表現。

這本書能夠鏈結這些心理素質到工作的習慣,工作的態度是我當初會選擇這本來讀的原因。許多的範例與案例也是讓人閱讀得津津有味。

另外一個喜愛這本書的原因也是作者很強調必須要熱愛自己工作的原因,經常看到不少人抱怨自己公司很累,常常被要求做一些不是自己該做的事情。這本書教導讀者應該要找到適合你天賦的工作,然後熱愛你的工作。這些會讓你在處理工作上許多小細節的事情能夠更加的樂觀與豁達。不再去怨天尤人抱怨公司虐待你,而是主動去思考該如何讓自己工作上更有成長,更有樂趣。

很推薦大家來讀這本書,也希望每一個讀者都能夠找到讓自己更快樂的工作習慣。