June 27th, 2017

[研討會心得][iThome GopherDay] What can Golang do? (Using project 52 as examples)

演講摘要

入手一個新的語言永遠不是一件簡單的事情。

不論是要學習 toolset 跟語言的語法，一直以來在過程中最大的問題永遠都會是：這個語言究竟能做些什麼？

講者曾經在 2015/06~ 2016/06 一年中挑戰自己每個禮拜寫一個小的專案，名為 “Project 52” 。透過 “Project 52”，講者會告訴你，究竟 Golang 能做些什麼：

簡潔的語法 強大的工具鏈 超高的效能 Google 開發出的 Golang 不僅僅能讓你更專注開發，還能幫助你開發高效的應用程式。

Slide

iTHome Gopher Day 2017: What can Golang do? (Using project 52 as examples) from Evan Lin

心得

第一次台灣舉辦的 Golang 研討會。感謝 iThome 的工作人員。 整個會場人爆滿，加上有便當跟餐點都很棒。謝謝各位講者的分享。也希望每個聽眾都能 enjoy.

June 21st, 2017

[研討會心得][iThome Cloud Summit 2017] The next generation of data center: Machine Intelligent Cluster

演講摘要

隨著時代的演進，管理機器的方式也隨著慢慢進化。隨著一台台機器的管理方式，變成了集群（Cluster）的管理方式． 而應用程式的部屬方始也從最原始的實體機部署，到了虛擬機器（VM）甚至到了容器（Container）的部署方式。

Kubernetes, DCOS 與 Docker Swarm 就是結合了容器部署與機器集群的管理方式的一個管理套件。但是集群的部屬方式並不代表你可以節省部署與維護的人力，因為隨著集群的數量變大，緊接來著就是需要更多管理的技巧。 比如說：

如何有效地管理集群的使用率? 如何讓集群內閒置機器能夠自動關閉? 如何有效地自動擴展你的集群? 如何讓集群偵測惡意攻擊或是自我修復? 講者將會帶來一個新的觀念，就是一個具有機器智能的集群管理系統。結合時下最受歡迎的機器學習架構（SMACK）與深度學習代表的 Tensorflow 如何讓你的集群能夠更有效地分析使用量，進而讓你的集群變得有智能。變成下一代的機器智能集群（Machine Intelligent Cluster）。

Slide

iThome Cloud Summit: The next generation of data center: Machine Intelligent Cluster from Evan Lin

心得

今天在 iThome Cloud Summit 2017 的投影片． 第一次嘗試投影片不要做太多，然後講多一點．結果就是到後面講得有點趕． 很開心今天學員們都對這樣的議題很有興趣，也歡迎大家多多詢問．

June 14th, 2017

[TIL][Python] Let's play darkflow and face_recognition

darkflow

https://github.com/thtrieu/darkflow

face_recognition

https://github.com/ageitgey/face_recognition

How to install in Mac OSX

  • Install opencv3 + python3 + dlib

  • Install cython on Python3: pip3 install cython
  • Install darkflow
    • git clone https://github.com/thtrieu/darkflow.git
    • cd darkflow
    • python3 setup.py build_ext --inplace
    • pip3 install -e .
  • Install face_recognition
    • pip3 install face_recognition
June 5th, 2017

[TIL][Python] OpenCV with Python2/Python3, dlib for python3

Python2 (opencv2) with Homebrew

Python 2

  • brew install python
  • brew install opencv
  • python
>>> import cv2

Python3 (opencv3) with Homebrew and PIP

Python3

  • brew install python3
  • brew uninstall opencv3
  • brew install opencv3 --without-python --with-python3
  • echo /usr/local/opt/opencv3/lib/python3.6/site-packages >> /usr/local/lib/python3.6/site-packages/opencv3.pth
  • python3
>>> import cv2

Refer to this

Install dlib (only for Python3)

dlib is very useful for face detection machine learning, but it is hard to install on mac osx with python. compile issue and compile issue2

I got some script from this, but still not working for me.

Using PIP3 to install dlib for python3

  • Install boost for python3 but not for python2
    • brew install boost-python --with-python3 --without-python
  • pip3 install dlib
  • python3
>>> import dlib

Reference

May 23rd, 2017

[TIL] 為了自己的習慣，弄了一個簡單的服務 Github issue bookmark

本篇提到的開源專案:

https://github.com/kkdai/bookmark-makerserver

https://github.com/kkdai/bookmarks

起因

平時習慣拿 twitter 作為 bookmark 的概念，看到喜歡的鏈結或是網站就直接 tweet 出來． 但是都沒有記錄下來．

之前有想過透過程式設計週記的方式來記錄下來，但是又覺得太過流水帳而且沒有辦法有系統的分類．

想著想著就想到透過 Github Issue 來做這件事情，有以下的好處:

  • 可以透過 Label 來分類
  • 可以使用 Github 的搜尋功能來尋找想找的部分
  • 可以補充很多的 comment 在同一個 issue 上面做為閱讀後的心得記錄．更方便未來搜尋．

架構

一如往常，我依舊使用許多免錢的架構．並且將整個流程都開源給大家分享，大家應該可以在五分鐘內建立自己的整體流程．

你可能要自己做的事情如下:

  • 取得 Github Auth Token (去這裡)
  • 取得 IFTTT Maker 帳號與權限
  • 修改一下 IFTT Maker 資料．

詳細流程都在 https://github.com/kkdai/bookmark-makerserver

支援的語法範例

這裡提供一些 tweet 的範例，還有他會變成何種 github issue

gernest/mention: Twitter like mentions and #hashtags parser for Go(Golang) # easy way to get hashtag in #golang https://github.com/gernest/mention

  • Title: gernest/mention: Twitter like mentions and #hashtags parser for Go(Golang)
  • Content: easy way to get hashtag in
  • Labels: hashtags,golang
  • Link: https://github.com/gernest/mention

希望能提供給一些需要的人，有任何問題歡迎發 issue 討論 ..

未來發展

幾個階段…

  • 第一個階段應該會先支援 Facebook 貼文，並且根據我臉書文章格式來貼 Github issue
  • 等收集好大量的 Github issue 後，應該會寫另外一個工具來定期（每個禮拜） 根據 Github issue 來產出 Monthly_README.md
  • 甚至可以把這個機制弄成電子報… 恩… 應該說是部落格好一點．
May 20th, 2017

[Coursera] Illinois: Cloud Computing Concept Part 1 : Week 5

課程鏈結: 這裡

學習鏈結:

課程內容:

這裡先簡單的介紹整系列的課程內容，希望能讓大家了解這個課程想做什麼．

這整堂課主要是圍繞著 Cloud Computing 經常會使用到的技術與相關的概念． 整堂課其實只有一個程式語言作業:

	使用 C++ 寫 Gossip Protocol

雖然課程裡面程式語言的作業不多，但是整體上的內容還算不少． 除了有談到一些雲端技術的基本概念:

  • Map Reduce
  • Multicasting and Gossip Protocol
  • P2P Protocol and System
  • K/V DB, NOSQL, and Cassandra (畢竟都談了 Gossip)
  • Consensus Algorithm - Paxos, FLP Proof

其實課程內容很有料，也可以學到很多的東西．

前提:

Snapshots

Global Snapshot

Global Snapshot =

  • Global State =Individual state + communication channel

時間不同步的時候所造成 Global Snapshot 會失敗的原因

  • 時間不正確
  • 無法抓到溝通的狀態

任何造成 Global Snapshot 變動的原因:

  • Process send/receive message
  • Process move one step

以一個範例來解釋演算法

基本定義:

  • There are no failures and all messages arrive intact and only once
  • The communication channels are unidirectional and FIFO ordered
  • There is a communication path between any two processes in the system
  • Any process may initiate the snapshot algorithm
  • The snapshot algorithm does not interfere with the normal execution of the processes
  • Each process in the system records its local state and the state of its incoming channels

Chandy-Lamport Global Snapshot Algorithm

Wiki

  • 隨便挑一個 Process (\(P_i\)) 來對所有其他的 Process 傳送一個 Marker 訊息 \(C_ik\) )
    • 並且開始記錄所有進來的 Message (InComing Msg)
  • 如果收到的 Process \(P_j\) 並沒有收過 \(C_ij\)
    • 先將該訊息 \(C_ij\) 的 State 標示為 “empty” 一樣開始傳送 \(P_jk\) Marker 給其他 Process
  • 如果已經收過了
    • 代表所有 Process 已經開始在傳遞 Marker 而其他訊息已經完整的到了．
  • 停止條件:
    • 當所有節點都收到 Marker 代表儲存的資料已經完成．
    • 當所有 Process 收到其他訊息都是 Marker (需要有 N - 1 個)

最後還要把各個分開的 Snapshot 組合成 Global Snapshot

停止條件，所有節點都收到 Marker 外，所有等待外部回來的資料 (marker) 也都收到．

將 Snapshot 統一回收整理成一個大的 snapshot

P.S. 這個演算法並不記錄對外的資料，因為由收到資料的人統一來記錄結果．

Consistent Cut

講解到 Snapshot ，不免俗就要講到擷取 snapshot 的時間點 (cut)．

Consistent Cut

  • A cut C is a consistent cut if and only if: for (each pair of events e, f in the system)

也就是說每一個 pair f->e (f happen before e) 如果有 e in the cut 那麼必須 f 也必須要 in the cut． 反之不需要滿足．

透過 Chandy-Lamport Global Algorithm 截取的 Snapshot 都滿足 Consistent Cut

證明: \(e_j\) in the cut (透過 \(P_j\) 記錄到) 那麼 \(e_i\) (透過 \(P_i\) 記錄到) 必定也在 snapshot 之中．

  • We already know \(e_i -> e_j\)
  • We also know \(e_j\) in the cut but \(e_i\) not in the cut
  • Because \(e_i -> e_j\) and \(P_i\) already record state for \(e_i\)
  • Since \(e_i\) happen before \(e_j\), if \(e_i\) not in the cut so \(e_j\) must not in the cut too.
  • Contracdition.

Safety and Liveness

Conrectness => Liveness or Safety

Definition:

  • Liveness: something good eventually happen
  • Safety: Guarantee something bad never happen

Chandy-Lamport Algorithm 與 Safety, liveness 的關係:

  • 一旦 Stable 就會一直保持 Stable
  • 只能滿足 Liveness but non-safety

Multicast

Communication 的種類:

  • Unicast: 訊息從一個傳送者送到一個接收者
  • Multicast: 訊息寄送給一群的人
  • Broadcast: 訊息寄送給全部的人

Multicast Ordering

探討順序的時候，有以下三個方式的 multicast :

  • FIFO Ordering
  • Causal Ordering
  • Total Ordering

FIFO Ordering:

這邊的 FIFO 代表的是，先發送的人就會被收到．（同一個 Process 上):

  • 先發送的人，會先被人收到． (同一個發送的人，先後順序在某個節點上應該會保持一樣的順序．)
  • Ex:
    • \(P_i -> P_j, P_k, P_l\), \(P_m -> P_j, P_k, P_l\)
    • 根據 FIFO 原理
    • \(P_j\) 收到順序也會是 \(P_i (P_ij), P_m(P_mj)\)

Causal Ordering:

Causal Ordering 代表的是因果的關係，也又是接受到的人絕對比傳送的人還晚． （因為傳送過程的 latency) 這邊指的是跨 Processes ，的因果關係．

Causal Ordering -->(imply) FIFO Ordering

由於 Causal Ordering 可以跨 processes 跟同個 process ． 如果是在同個 Process 的話，就是指的是先入先出 (FIFO) 因為同一個的先後順序必定影響該 multicast 的順序．

Total Ordering:

所有 process 收到訊息的順序都相同．

Hybrid ordering

  • FIFO-Total:
  • Causal-Total:

Implement of multicasting

Implement FIFO Ordering

拿這張圖來解釋如何讓 FIFO Ordering 能夠滿足:

  • P1 有兩個 multicasting [1,0,0,0] 與 [2,0,0,0]
  • 會看到在 P3 那邊 [2,0,0,0] 比起 [1,0,0,0] 先到
  • 所以後面的需要先等一下 (buffered) 改成 [0,0,0,0] 等到後面到了才能改．
  • 但是 P1, seq: 2 與 P3 seq: 1 不會有這樣的問題．因為 FIFO Ordering 並不局限於跨線程

About total ordering

就是計算每個人收到的順序必須要跟開始發送的順序一樣（可跨程序） 就算是．計算的方式就是去累進收到的順序．

Implement Causal Ordering

滿足條件:

	所有的接收者都必須有著相同的接受順序（跨程序）．
	
	If multicast(g,m) -> multicast(g,m’)
	then any correct process that
	delivers m’ would already have
	delivered m.

做法:

  • P1 與 P2 原本就滿足 Causal Ordering ，故不提．
  • P3 先收到 P2 msg ，這時候就知道要等待 P1 msg 因此就 buffer
  • P3 後來又收到 P4 msg ，又必須要等待 P1 msg 所以就 buffer
  • P3 要一直收到 P1 msg 之後，才會把 P2 與 P4 msg 收起來
  • 如此一來就滿足 Causal Ordering

Reliability of multicast

	Reliability = Correctness = Ordering

在此討論的 Reliability 都是基於 non-Faulty (沒有錯誤發生的) process 上面來討論．

現實中的實現方式

在現實中如何透過實現類似 multicast 的確保方式？

	每個 process 收到之後，在發送 multicast 給其他 process 作為標記

透過這樣的方式，才能確保每個 process 收到的 msg 順序是正確的，因為順序需要有外部的資訊來紀錄．

Virtual Synchrony

View

每個 Process 都維護一套自己的 member list ，那樣的 member list 就稱為 “View”

View Change

當 Process 發生了 “新增”, “離開”, “故障” .. 等等影響 member list 的事情就稱為 View Change

Virtual synchrony

Virtual Synchrony 保證所有的 View Change 都會發生於相同的順序上．

ex:

  • P1 join
  • {P1, P2}, {P1, P2, P4} , {P1, P2, P3} are all view change
  • 所以 P2 會收到 一樣順序 {P1, P2}, {P1, P2, P4} , {P1, P2, P3}

Paxos

Consensus Problem

問題釐清:

為何 SLA 永遠都是 five-9' 獲釋 seven-9' 永遠不能夠 100%?

解答:
所謂的錯誤，不光是任何人員控管與公司流程上的錯誤．當然也不在於機器本身的錯誤． 而是在於是否能夠達到一致性( Consensus )．

Consensus Statement:

Consensus Constraints:

  • Validity: 需要全部人提議相同數值才能決定．
  • Integrity: 最後決定的數值必定是某個 process 提議出來（不是無中生有)
  • Non-triviality: 至少有一個初始狀態，而不是常見的 all-0, all-1

Consensus In Synchronous Systems

Synchronous Systems 的特性:

  • 訊息有時間限制
  • Process 間交換訊息有時間限制 (round: f, upper bound)

如果能夠解決 Synchronous Systems 的一致性 (Consensus) 問題 ，那麼是否能夠解決 Asynchronous System

–> 將訊息交換的時間限制延長到 N

Paxos

關於 Paxos

並沒有完全解決 Consensus 的問題，

但是可以提供兩種主要特性:

  • Safety:
    • 不違背一制性
  • Evantual liveness:
    • 如果有問題發生，還是可以達成一制性． (但是不保證，原因後續）

並且在以下系統都有使用:

  • zookeeper
  • Chubby

Paxos 三個階段:

Election

  • 每個節點 (node) 會送出 election request
  • 需要達到大多數 (majority) (或是稱為 Quorum)
  • Paxos 允許 multiple leader (這裡先不討論那麼複雜)

產出會有一個(或多個) Leader

Bill

  • Leader propose value (v)
  • 如果節點同意會回覆

Law

  • 如果 Leader 獲得大多數的同意
  • 會發出 Law (or Learn) request 給每個節點，確認數值的紀錄