前言：

Google ML Study Jam 是 Google Developers 所設計的免費機器學習培訓計劃。

在這個初級培訓課程中，參加培訓的學員僅須運用 Qwiklabs 線上學習平台，按照自己的步調及時間，實際動手操作由培訓計劃所指定與機器學習相關的 Hands-on Labs，便能自我學習而擁有基礎開發 AI/ML 應用程式的能力。

只要完成指定課程中的四項，就有機會獲得最新版本的 TensorFlow T-Shirt 。看起來實在相當棒就忍不住把 Machine Learning APIs 都上完了。

這邊分享一下相關內容吧！

課程內容:

整篇課程其實相當的實用，也由於整個 HANDS-ON LAB 透過 qwiklabs 逐步教學從登入帳號，開啟 cloud console 都很容易可以完整。 而 Lab 重點也在希望能夠讓使用者整個走過一次相關的使用流程。 所以每個步驟力求簡單明白，不需要任何的程式設計基礎。

課程特點：

全部的 hand-on lab 在設計上相當友善，只要完整跟著做一次通常可以順利完成。整個課程有以下的優點。

完全免費的帳號與清楚登入流程

每個小課程有專屬的帳號，不用擔心你不小心學任何 GCP 的功能因為忘記關掉伺服器而花了大錢。

清楚的指令提供複製貼上

由於 GCP 許多功能除了啟動與狀態回報之外，大多數的功能都還是透過 console mode 的指令來溝通（或許說不少是透過 API 呼叫方式）。

這時候最怕就是指令過時或是需要自己摸索，這邊的指令全部都是清楚條列，並且可以一個按鈕複製讓學習上完全沒有障礙。

完整了解許多 gloud console 提供的功能

雖然說之前很常使用 GCP 上面的許多功能，必須得說這次的課程讓我清楚更多平時不常使用到的功能。

• 透過 gcloud console 編輯檔案
• 透過 gcloud console 來跑一個 local web server ，並且使用 web preview 來查看 8088 的輸出。

但是學習上也不是沒遇到問題啦～分享一下我遇過的問題。

課程遇到的問題

Scanning User-generated Content Using the Cloud Video Intelligence and Cloud Vision APIs

https://google.qwiklabs.com/focuses/1831 Scanning User-generated Content Using the Cloud Video Intelligence and Cloud Vision APIs 課程好像會卡住。

> gcloud beta functions deploy GCStoPubsub --stage-bucket gs://${STAGING_BUCKET_NAME} --trigger-topic ${UPLOAD_NOTIFICATION_TOPIC} --entry-point GCStoPubsub


ERROR: (gcloud.beta.functions.deploy) Missing required argument [runtime]: Flag `--runtime` is required for new functions.

原因是因為 gloud beta function deploy 的時候需要標註 runtime ，這裡的範例是使用 nodejs 只要改成以下即可。

gcloud beta functions deploy visionAPI --runtime nodejs --stage-bucket gs://${STAGING_BUCKET_NAME} --trigger-topic visionapiservice --entry-point visionAPI

參考相關 stackoverflow: https://stackoverflow.com/questions/51699289/gcloud-functions-deploy-unrecognized-arguments-runtime-did-you-mean-timeo

Reference:

• https://siddharam.com.tw/post/20190509/
• https://darkaries.github.io/2019/05/13/gcpmljam1/

前提

LINE 台灣開發者關係與技術推廣團隊 (Developer Relations) 除了對外部的開發者推廣之外，有另一個很重要的使命就是希望能夠透過相關的開發者活動能夠激發內部的開發者的潛力，不論是透過內部訓練或是相關的活動。而這次的活動就是希望能增進內部開發者技術文件的寫作能力外，更重要的是希望能夠增加開發人員彼此的溝通技能。也期許透過本次的訓練能夠增進內部開發者彼此技術文件分享的能力，也希望增進對外文件的撰寫品質與數量能夠更好。

什麼是技術寫作日 (Technical Writing Day)

身為開發者對於文件的寫作總是有許多困難的地方，不論是不知道該如何撰寫之外就是經常不確定如何撰寫讓使用者能夠淺顯易懂的文件。開發者經常認為程式碼能夠表達許多事情，而無法有效的將讀者或是使用者需要的資訊寫在文件上。 在開發者部落格寫作上，開發者們經常不知道該如何安排他們的文章內容，順序與如何有效地表達。

技術寫作日其實是一個由 LINE 技術文件作家 (Technical Writer) 團隊所籌畫的一系列活動。日前不僅在韓國有舉辦過（請參考這篇文章），其實在日本也舉辦過。這次很開心能遠從韓國與日本邀請到他們來到台灣舉辦。 不僅僅邀請了所有的內部開發者，連經常需要撰寫技術文件的團隊也都邀請一起來了解，並且增進我們技術文件的寫作能力。

關於技術寫作日的課程簡介

技術寫作日是一整天的訓練課程包括了早上的基礎訓練之外，下午有許多進階的訓練課程。在這裡簡單的分享幾個重要的課程與相關的介紹，分享給各位讀者。

Introduction to Technical Writing

首先登場的是由 Technical Writing Team Lead 所帶來的 Introduction to Technical Writing 。透過帶出軟體開發的流程 （ Concept, Analyze, Design, Development and Test ) 帶出其實技術寫作應該視為軟體開發的流程。需要有足夠的構思，設計之外，更需要詳細寫作後的測試。也就是重新檢視寫作內容，測試所有範例程式碼確認所有技術細節都是正確並且是最新的狀態。

LINE 的開發者有以下幾種方式是透過技術文件方式來做溝通：

• Wiki: 為開發者內部溝通最主要的管道，透過可以容易分享，共同編輯的 Wiki 系統。 許多的技術相關的溝通與討論往往是在 Wiki 上面而不是 Email ，讓許多的變更與分享更加有效果也能夠允許更多人開發同仁能夠一起協作。
• README 文件: 每個專案的負責人都會撰寫相關的介紹文件，不論該專案是內部專案還是開源的專案。
• API 文件: 平台團隊與 SDK 團隊經常會準備的相關技術文件，不論是內部專案或是外部的公開 API 。都會有清楚的 API 文件。

這些部分的文件撰寫都很需要 Technical Writing 的技術寫作概念的持續增進。

Introduction to P.O.W.E.R. Writing

第二部分介紹的是相當有用的概念 P.O.W.E.R Writing ， 而 POWER 其實是五個字的縮寫。

• Preparing
• Organizing
• Writing
• Editing
• Reviewing

在寫作技術文件的時候，透過使用 POWER 的原則可以讓寫作更加的順利，也可以增加文章的可讀性與減少錯誤的產生。這五個字就像是一個心法一樣，相當的重要而且相當的有用。方便我們可以準備技術的素材，組織整個文章架構，寫作更清楚的文字，透過使用更易懂的方式來修改，最後要不斷的審核。相當有用的一堂課程。

Writing Blogs

這一段的教學主要是簡介 LINE Engineering Blog 的發布流程，與為何要撰寫 Engineering Blog 與有哪些好處。

為何要撰寫 Engineering Blog 的部分。透過將技術文件分享在文字的過程，可以從頭到尾仔細地審視了解的技術，遇到的問題與解決的方法。這邊也鼓勵每個開發者都應該要試著撰寫部落格，除了可以增進每個人對於技術溝通能力之外，更可以清楚了解自己是不是還有不清楚的地方。 而且相當建議每個開發者透過公司的平台來發表相關的文件。因為除了平台的比較受到大家的重視之外，每一篇文章的發行需要透過許多專家層層的把關。從每一個文字的校對到資訊安全的審核，讓每一位開發者只需要專注在自己的文字表達部分。

每個開發者透過 Engineering Blog 還可以獲得許多同仁對於技術文字表達方式與內容的排列方式有著更深層的交流，真是獲益良多。

Organizing and presenting information using the wiki

Wiki 是 LINE 開發者作為內部技術溝通很重要的一個工具，不論是會議記錄，產品規格，甚至到部落格文章草稿。如何能夠有效地呈現卻是困難的，所以如何展現與擺放足夠的資訊在 Wiki 上面就是一門學問。這一場分享中，講者講解了如何透過 Wiki 的一些工具告訴大家該如何來有效的將資訊作為有效的相互鏈結，分享並且協作的方式。最後講者也分享一個很有趣的例子：

就在出國六個小時前，忽然找不到護照。不論在行李箱裡面，或是他的辦公桌上都找不到，最後卻在舊衣服堆裡面發現了。

這個故事就告訴我們，除了資訊的足夠之外如何有效地「擺放」你的 Wiki 頁面讓大部分的人能夠透過關鍵字或是階層式資料夾排列方式來尋找到文件就是一門大學問。

Writing developers guide

如何要開始撰寫開發者指南，永遠都是開發產品或是微服務 (microservices) 的很痛苦的地方。而這一段分享就是透過分享如何撰寫微服務的開發者指南來分享該文件應有的架構與特點。撰寫開發者指南講者建議就要由讀者的面向來出發。如果要撰寫一個微服務的安裝手冊，安裝需求與如何安裝就是每個使用者第一次看文件馬上會著眼的地方。那麼就開從這些地方開始準備，而且要不斷的反覆測試你的開發者指南，並且清楚地記錄下每一個容易犯錯的地方。不要讓使用者發生了錯誤而不知道該怎麼自行解決問題，這就是開發者指南最重要的幾個部分。

總結

身為 LINE台灣資深開發技術推廣工程師（Technical Evangelist) ，深刻的認為撰寫良好的技術文件的技巧也就是在磨練著開發者彼此對於技術的溝通能力。許多的開發者在文件撰寫上往往不知道該如何開始，如何將整個來龍去脈做有效與系統化的呈現。 透過技術寫作日的訓練，希望就是能夠讓開發者們的溝通能力更上一層樓。彼此能夠更精進文件撰寫能力與系統思考的組織力。 開發者關係與技術推廣部 (Developer Relation) 將持續引進與推逛更多內部開發者的相關課程訓練，對外也將持續的努力提供更好的，更友善的 「LINE開發社群計畫」。

關於「LINE開發社群計畫」

LINE今年年初在台灣啟動「LINE開發社群計畫」，將長期投入人力與資源在台灣舉辦對內對外、線上線下的開發者社群聚會、徵才日、開發者大會等，預計全年將舉辦30場以上的活動。歡迎讀者們能夠持續回來察看最新的狀況。詳情請看 2019 年LINE 開發社群計畫活動時程表 (持續更新)

LINE台灣持續招募中

你是有能力的開發者嗎？ 如果喜歡開發系統卻對於文件撰寫不知道該如何起頭，在 LINE 台灣會有相關的課程與訓練有系統的指導內部的開發者。想要加入我們嗎？ 快到以下的地方尋找你有興趣的職缺。

• LINE Taiwan Careers
• 2019 LINE Taiwan Developers Recruitment Day

前提

大家好我是 LINE 台灣的 Technical Evangelist - Evan Lin 。「開發社群計畫」是今年一個開發者關係與技術推廣部門一個重點，將在今年一整年中，在台灣舉辦對內的技術交流、教育訓練，對外的社群聚會、校園演講、開發者徵才日與開發者大會等各式各樣超過30場的活動。我們希望創造更多技術分享與跨國串連的機會，同時，持續招募優秀的人才加入LINE台灣的開發工程團隊。

四月的第二場社群邀請到 Golang Taipei Gathering 社群的朋友來到 LINE 台北辦公室，並且一起來分享與討論 LINE 內部開發流程上針對 Golang 使用上的心得分享。這次的相關資訊可以在 meetup Golang Taipei #40 找到所有的內容介紹，

Go GraphQL in LINE SPOT/ LINE - Denny Tsai

投影片

首先上場的是來自 LINE Spot 的工程師 Denny Tsai 。他也介紹了即將在 LINE 2019 下半年上限的全新服務 – LINE Spot 。提供消費者輕鬆搜尋所在地鄰近的店家資訊，以及店家進行中的特惠活動，消費者想要的資訊、店家想曝光的資訊都可以在 LINE SPOT 一站完成。這樣的服務將在 2019 年的第三季上線，敬請大家期待。

接下來講者開始分享如何透過 Go 跟 GraphQL 來當作微服務( Microservices ) 的 API Gateway 的經驗分享。由於產品的微服務漸漸增加，各個微服務都會提供個別的 API 供前端使用。除了 HTTP 的 API 之外還會多出了其他溝通的介面 (gRPC, Thrift…) ，如此一來造成前端與微服務間的串接複雜度提升。這時候會使用 API Gateway 當作統一進入點 ，進而使用 GraphQL 提供前端更好更有彈性的查詢方式，希望能夠 GraphQL 解決聽眾們經常遇到的問題。

GraphQL 是一個 Query Language 並且具有以下的優點:

• 單一進入點 (Single Endpoint)：
  • 不論是各種的不同的 API 需求，通通透過單一的進入點。
• 由客戶端來定義需要的資料型態 (Response shape defined by the client)：
  • 客戶端（通常指的就是前端）可以修改自己需要的資料型態，順序與排列方式。不需要修改任何的後端代碼。
• Transport Agnostic:
  • GraphQL 並不是一種語言而是一種標準，可是其實他並沒有限制所使用的傳輸層，因此可以使用任何適合的方式作為 GraphQL 的傳輸層。

此外講者也介紹了許多關於 GraphQL 有用的開發工具:

• GraphiQL: 一個在瀏覽器上的 IDE 可以讓你查詢與瀏覽 GraphQL 的工具。
• GraphQL Playground: 開發 GraphQL 的 IDE 與測試工具，提供許多良好的介面與具有互動式的文件。

除了這些工具之外，由於本場分享關於 Golang 的開發者。講者也分享了市面上比較熱門的 GraphQL in Go 的開發套件：

• https://github.com/graphql-go/graphql
• https://github.com/graph-gophers/graphql-go
• https://github.com/99designs/gqlgen

這三套大概是搜尋 Golang 與 GraphQL 最容易被人找到的三個套件（因為 star 數也最高)，但是講者最推薦 gqlgen 原因如下：

• Schema first
• Type safe
• Less boilerplate

而使用上也相當直覺，建立 schema 後，透過 gqlgen 初始化之後它會把所以相關需要的框架都建立好。只要進去將相關的 Resolver 內容填寫正確就可以跑起這個 GraphQL server 。

最後 LINE Spot 其實也希望有更多對於 Golang 有熱情的夥伴一起加入。

LINE Now/Spot 相關職缺:

• • Server-Side Developer

認識 Go 的 morestack/ Lee Xun ([email protected])

投影片

（本部分會不截圖，請各位去投影片內部找尋相關內容）

第二位講者是李洵，他所帶來的題目相當的硬但是也相當的有趣。討論的是 Golang 裡面的 morestack ，細節因為相當的硬且深入建議大家還是要去投影片鏈結細讀講者提供的投影片。

首先講者先分享了他自己為什麼喜歡 Golang 的原因: 除了 Goroutine 之外，就是 Golang 是編譯的程式語言。可以很容易地從組合語言來了解程式碼的執行細節。 講者也透過了比對了 C 語言的 Hello world 與 Golang 的 Hello 讓大家了解組合語言解讀的時候， Golang 的編碼上還要複雜的許多。接下來就拿了一個 C 語言與 Go 對於變數生命週期的管理來討論 Golang 在變數生命週期的管理是不同的 (這個在 Golang 裡面稱為 escape)。 由於在 Golang 裡面 :

• return A{}：將記憶體放在 gstack
• return &A{} ：在 compile 的時候記憶體放在 gheap 之間。

所以 Golang 記憶體的位址並不會因為變數的生命週期結束後，傳回記憶體位置而會拿到已經被佔用的記憶體位置。可以在 func 前面加上 //go:noescape 來關閉這項操作，這樣就會出現和 C 一樣的現象。

接下來講者又丟出了一個大家常有的疑問：「 goroutine 雖然好用，但是有沒有開發者會想了解目前正在執行的 goroutine thread ID? 」 因為在 C 語言中，每次 Create Thread 都可以拿到 thread ID 來清楚知道目前執行的 ID ，那麼 goroutine ID 呢？ 接下來講者就分享了如何透過 getgoid() 來取得 TLS (Thread Local Storage) 資料方式，並且講解如合透過 Memory alignment 來解讀目前的資料結構進而找出 getgoid() 。

接下來透過一個 deadloop 的範例程式開始要帶入本次演講的正題: 什麼是 Golang morestack。

在 Gorotine 裡面加入一個 deadloop (也就是 for {} 什麼事情都不做） 發現如果在裡面做記憶體位置處理的話。某些情況下會發現你的 deadloop goroutine 又會被其他 goroutine插隊（preemptive)。 那麼要多大的記憶體操作才會造成整個 goroutine 是可以被插隊呢？ 這時候先跳去討論了在不同的平台上面的 GOMAXPROCS ，也講解了不同平台上面如何取得你的CPU 數目的方式。 透過這些處理方式才能了解，由於有 StackGuard 當一個 goroutine 裡面的變數資料大過於 4KBi 由於超過了 gstack的資料空間大小，就會呼叫到 morestack 來搬移資料的方式會有極大的可能判定這些資料是比較少使用的。 就會將該 goroutine 是修改為可以被插隊的。 當 goroutine 內的資料空間大小介於 128Bi 與 4KBi 之間在 morestack 的判斷中，由演算法決定該不該被插隊。反之，比較小的區域變數空間就絕對不會被插隊。

或許這樣的設計也提醒開發者，如果發現 goroutine 本來跑的一些流程莫名其妙被中斷去跑另外一個 Goroutine ，也或許就是因為區域變數佔用太多記憶體而呼叫到 morestack ，造成系統判定該 goroutine 是可以被插隊的。

很有深度，相當硬但是又有趣的分享。

總結

很開心邀請到 Golang 社群來到 LINE 台灣辦公室舉辦 meetup ， 也很開心第一次能夠請到 LINE Spot 的工程師來跟社群們分享開發上的經驗。

關於「LINE開發社群計畫」

LINE今年年初在台灣啟動「LINE開發社群計畫」，將長期投入人力與資源在台灣舉辦對內對外、線上線下的開發者社群聚會、徵才日、開發者大會等，預計全年將舉辦30場以上的活動。歡迎讀者們能夠持續回來察看最新的狀況。詳情請看 2019 年LINE 開發社群計畫活動時程表 (持續更新)

Blockchain Specialization 系列上課心得

• Blockchain Basics

• Smart Contract

• Decentralized Applications (Dapps)

• Blockchain Platforms

Decentralized Applications (Dapps): 課程鏈結: 這裡

文章鏈結:

• Decentralized Applications (Dapps) (一）: Week 1
• Decentralized Applications (Dapps) (二): Week 2
• Decentralized Applications (Dapps) (三): Week 3
• Decentralized Applications (Dapps) (四): Week 4

前言：

這次的第二堂課跑得比較久，並不是因為課程比較難而是因為課程內部提供的 truffle 版本跟現階段的差很多，導致其實無法再 Mac OSX 上面順利的執行，需要修改不少的地方。雖然能夠幫助我夠熟悉整個 truffle 的架構，但是也真的得花很多時間解決各種問題。

如果還是一直卡住，真的還是得考慮使用 VirtualBox 來跑 VM 比較快。

課程內容:

Week2:

Truffle 的介紹

Truffle 與 Remix 的差異

這次主要會用到的工具叫做 Truffle ，在使用 Truffle 之前需要分別出跟之前使用 remix 的差別：

• 分析問題， Smart Contract 的 prototype 需要使用 remix 。
• 開發，測試與部屬 dApps 需要使用 Truffle。

如何透過 Truffle 部署簡單的專案

接下來透過 Truffle要來跑一開始最簡單的範例 Ballot 流程如下：

• 安裝 Truffle :
  • npm install -g truffle
• 初始化專案
  • mkdir ballot
  • cd ballot
  • truffle init

裡面會有幾個已經設定好的 template 包括了:

• migrations/1_initial_migration.js: 負責 migration script file
• truffle-config.js: 負責 truffle compiler 的設定檔案

增加設定檔案 truffle.js (這檔案是負責 truffle 部署的設定檔案)

增加 deployment 的相關設定 (建立一個檔案 migrations/2_deploy_contracts.js)

關於將舊的 Remix 的檔案 Migrate 到 truffle 這邊的部分就參考這篇文章。[TIL] Migrate solidity from remix to truffle (1) - Compile

Test-Driven Development

Smart contract 就像 hardware chip 一樣，一但部署了就很難變更（除非有大量問題導致必須修正）。 本小段的內容就是教導如何透過 TDD 的方式來撰寫 smart contract 。

關於 truffle test 的流程 (如果有任何 truffle test 錯誤需要來做 smart contract 修正)：

• truffle compile
• truffle migrate --reset
• truffle test

Web Interface & Testing

這一個章節開始要將 Web Interface 的部分導入到我們目前的專案之中，也讓我們更了解 Dapp 如何透過網頁前端的整合來呈現出來。

檔案架構

在這之前，讓我們更了解所有檔案架構：

• contracts: 所有的 smart contract 相關代碼。
• migrations: 放著 migration 會用到的相關 scripts 。
• test: 通常會放入所有相關測試代碼。
• build: 放著一些 json 設定檔案。
• source: 通常會放著 web 相關的資源。

關於 truffle command line 整理

• truffle init: 建立範例給你準備開始自己的 truffle 專案。
• truffle compile: 將 Solidity code 轉換成 byte code
• truffle develop: 部署基本的 truffle 內建的 blockchain 環境。
• truffle migrate —reset: 如果有修改 migration script ，需要執行來重置設定。
• truffle test: 執行相關測試代碼。

總結:

本堂課專注在透過 truffle 的學習來了解使用 truffle 能夠達到的許多工作，從基本的 Ethereum client 到 truffle 與 MetaMask 的工具使用都有學習到。

Reference:

• Truffle
• [TIL] Migrate solidity from remix to truffle (1) - Compile

前提

最近在上Coursera 的 Blockchain Specialization 系列的課程 Decentralized Applications (Dapps)，裡面提到使用 Truffle 。 由於課程裡面使用的 Truffle 版本比較舊（目前是 0.5.1，課程內是 0.4.0? ) ，本來想打算使用 VM 的方式來跑，但是發現現在的筆電跑 VM 有點悲情。

只好硬著頭皮來直接去修改相關的代碼，想想相關的修改應該也可以變成一系列的文章。 就來試試看吧！！

內容分享

Truffle 的介紹

Truffle 與 Remix 的差異

這次主要會用到的工具叫做 Truffle ，在使用 Truffle 之前需要分別出跟之前使用 remix 的差別：

• 分析問題， Smart Contract 的 prototype 需要使用 remix 。
• 開發，測試與部屬 dApps 需要使用 Truffle。

如何透過 Truffle 部署簡單的專案

接下來透過 Truffle要來跑一開始最簡單的範例 Ballot 流程如下：

• 安裝 Truffle :
  • npm install -g truffle
• 初始化專案
  • mkdir ballot
  • cd ballot
  • truffle init

裡面會有幾個已經設定好的 template 包括了:

• migrations/1_initial_migration.js: 負責 migration script file
• truffle-config.js: 負責 truffle compiler 的設定檔案

增加設定檔案 truffle.js (這檔案是負責 truffle 部署的設定檔案)

增加 deployment 的相關設定 (建立一個檔案 migrations/2_deploy_contracts.js)

將之前的範例 Ballot.sol migration 過來

這一段是 （Smart Contract ) 課程中搬過來的第一個範例程式 ballot.sol ，大家也可以直接參考以下的部分。

檔案記得要建立在 contracts/ballot.sol 下面，接下來會講解如何做正確的 migration 。

試著編譯 truffle

truffle compile 結果發現了一些錯誤，就來開始解決問題吧。

Compiling your contracts...
===========================
Error: CompileError: ParsedContract.sol:43:39: ParserError: The state mutability modifier "constant" was removed in version 0.5.0. Use "view" or "pure" instead.
    function winningProposal() public constant returns (uint8 _winningProposal) {
                                      ^------^

####先試著降 Solidity Compiler 版本

Truffle 0.5.1 使用到的 Solidity compiler 預設是 0.5.0 ，我們可以透過修改 truffle-config.js 來降低 solidity compiler 的版本。 可以參考: https://truffleframework.com/docs/truffle/reference/configuration#compiler-configuration

不過出現的問題卻更難解決:

Compiling your contracts...
===========================
Error: CompileError: ParsedContract.sol:7:14: Error: Expected identifier, got 'LParen'
  constructor() public {
             ^

看起來更看不懂，那麼換個方式。來幫現在的 Solidity code migrate 從 0.4.0 到 0.4.23 。

開始進行 Solidity 升級的步驟 (0.4.0 —> 0.4.23):

• 先將版本訂在 0.4.23 以上：
  • pragma solidity >=0.4.23 <0.6.0;
• 因為之後 constrctor 語法不同，改一下： (可以參考這個)
  • constructor(bytes32 _name) public {
• constant 在 0.4.17 後不支援，改成 view
  • function winningProposal() public view returns (uint8 _winningProposal) {

細節大家可以參考這個 coomit. https://github.com/kkdai/truffle_balot/commit/cc23ca5d97ecef48921c3b83c66a0763e7e43edc

總結:

這裡先整理第一階段的 Truffle compiler migration ，接下來還有truffle test 與 truffle migrate 相關的整合部分會加入。這個相關過程也讓我更了解 truffle 運作的原理。

Reference

• https://truffleframework.com/docs/truffle/reference/configuration#compiler-configuration
• https://solidity.readthedocs.io/en/v0.4.24/contracts.html

(圖片參考 讀墨 )

從特斯拉到太空探索，大夢想家如何創造驚奇的未來
Elon Musk : Tesla, SpaceX, and the Quest for a Fantastic Future

原文作者：Ashlee Vance
譯者：陳麗玉

前言:

現代的鋼鐵人 - 馬斯克，不僅僅被視為是狂人之外。更是讓推動電動車的特斯拉與新創火箭科技 SpaceX 兩個令人驚豔的黑科技公司的執行長與董事。這本書應該蠻久以前就想要買來看。前一段時間一次買了三四本，斷斷續續的下來總算把這本書看完。

最近持續要規定自己減少每天手機的利用時間，除了上班不得不用之外。應該在家裡都是要持續拿著我的 Readmoo 好好的閱讀書籍。

內容簡介:

最近的幾篇傳記不論是貝佐斯傳到現在這的本 馬斯克傳記，其實都算是從記者的角度來撰寫的文章，而不是本人或是完整授權的傳記書籍。這類的書籍脈絡都還算容易了解，從一開始的媒體寵兒的角度來切入馬斯克，開始帶入成就他被稱為矽谷鋼鐵人傳奇的起頭。

馬斯克從小出生是在一個南非的富裕家庭，但是從小的馬斯克因為經常陷入深沈的思考模式，也就是無視於周遭的人的聲音整個陷入自我的思考模式，由於這樣的原因讓馬斯克從小經常被欺負。 但是這些都無法掩飾他異於常人的思考邏輯，搭配著他喜好讀書（並且獨得相當快速）的習性。讓馬斯克很容易地了解並且有著良好的基礎。

出社會之後馬斯克更展現了他的才能從第一次創業透過網頁黃頁的 Zip2 ，並且從兩個人的公司打造自己的第一個企業。後來被康柏併購之後，馬斯克也得到了他人生的第一桶金。

接下來就像大家耳熟能詳的創業模式，他們創立了 X.com 並且與 Paypal 競爭了一段時間之後就併購了 Paypal 。但是這個時候馬斯克也被迫交出了執行者的職位。被迫離開執行位子之後， X.Com 將名字改為 Paypal ，之後就像大家熟知的一樣，接下來 ebay 花了十五億美金買了 Paypal 。馬斯克有了他的第二桶金，有點像是賈伯斯離開蘋果一樣，這時候的馬斯克將他的眼光放到了小時候的夢想 — 火星旅遊。

接下來讀故事就是大家較熟悉馬斯克同時兼顧了人類兩個夢想的科技公司，火箭科技的 SpaceX 與電動車產業的 Tesla 。這邊幫作者賣個關子好了，其實這一段轉折還蠻有趣的。

馬斯克之所以被人稱為現在的鋼鐵人，出了有錢之外，就是他驚人的執行力。他可以很快的學習一件事情，然後跟工程師辯論為何不該這麼做。某種程度也是一種缺點就是他很愛跟工程師說，「我來做你的事情跟兩家公司的執行長」但是恐怖的是，他會這麼做而且做得很好。

心得:

這本書主要是由記者角度來寫，裡面有許多的歷史事件的紀錄。由於沒有太多本人的資料，可能沒有夾帶著個人情緒的元素。·會覺得馬斯克真的像是機器人一樣，優秀而不帶著個人情感。 但是這本書也提到了，他的家庭生活與他對於第一個孩子夭折所帶來的痛苦。 這本書有許多有趣的歷史，更可以了解這些令人感到傳奇的執行長們的人生。像是賈伯斯，貝佐斯一樣，馬斯克一樣有著高超的學習能力與暴躁挑惕的個性。或許，這些也是這些傳奇執行者們的樣板一樣。

最後，相當推薦大家來看這本書。很多有趣的故事會讓你愛不釋手。