前提 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 台灣的 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 而使用上也相當直覺，建立...

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...

前提 最近在上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...

(圖片參考 讀墨 ) 從特斯拉到太空探索，大夢想家如何創造驚奇的未來 Elon Musk : Tesla, SpaceX, and the Quest for a Fantastic Future 原文作者：Ashlee Vance 譯者：陳麗玉 買書推薦網址： http://moo.im/a/DHKPQX 前言: 現代的鋼鐵人 - 馬斯克，不僅僅被視為是狂人之外。更是讓推動電動車的特斯拉與新創火箭科技 SpaceX 兩個令人驚豔的黑科技公司的執行長與董事。這本書應該蠻久以前就想要買來看。前一段時間一次買了三四本，斷斷續續的下來總算把這本書看完。 最近持續要規定自己減少每天手機的利用時間，除了上班不得不用之外。應該在家裡都是要持續拿著我的 Readmoo 好好的閱讀書籍。 內容簡介: 最近的幾篇傳記不論是貝佐斯傳到現在這的本 馬斯克傳記，其實都算是從記者的角度來撰寫的文章，而不是本人或是完整授權的傳記書籍。這類的書籍脈絡都還算容易了解，從一開始的媒體寵兒的角度來切入馬斯克，開始帶入成就他被稱為矽谷鋼鐵人傳奇的起頭。 馬斯克從小出生是在一個南非的富裕家庭，但是從小的馬斯克因為經常陷入深沈的思考模式，也就是無視於周遭的人的聲音整個陷入自我的思考模式，由於這樣的原因讓馬斯克從小經常被欺負。 但是這些都無法掩飾他異於常人的思考邏輯，搭配著他喜好讀書（並且獨得相當快速）的習性。讓馬斯克很容易地了解並且有著良好的基礎。 出社會之後馬斯克更展現了他的才能從第一次創業透過網頁黃頁的 Zip2 ，並且從兩個人的公司打造自己的第一個企業。後來被康柏併購之後，馬斯克也得到了他人生的第一桶金。 接下來就像大家耳熟能詳的創業模式，他們創立了 X.com 並且與 Paypal 競爭了一段時間之後就併購了 Paypal 。但是這個時候馬斯克也被迫交出了執行者的職位。被迫離開執行位子之後， X.Com 將名字改為 Paypal ，之後就像大家熟知的一樣，接下來 ebay 花了十五億美金買了 Paypal 。馬斯克有了他的第二桶金，有點像是賈伯斯離開蘋果一樣，這時候的馬斯克將他的眼光放到了小時候的夢想 — 火星旅遊。 接下來讀故事就是大家較熟悉馬斯克同時兼顧了人類兩個夢想的科技公司，火箭科技的 SpaceX 與電動車產業的 Tesla 。這邊幫作者賣個關子好了，其實這一段轉折還蠻有趣的。 馬斯克之所以被人稱為現在的鋼鐵人，出了有錢之外，就是他驚人的執行力。他可以很快的學習一件事情，然後跟工程師辯論為何不該這麼做。某種程度也是一種缺點就是他很愛跟工程師說，「我來做你的事情跟兩家公司的執行長」但是恐怖的是，他會這麼做而且做得很好。 心得: 這本書主要是由記者角度來寫，裡面有許多的歷史事件的紀錄。由於沒有太多本人的資料，可能沒有夾帶著個人情緒的元素。·會覺得馬斯克真的像是機器人一樣，優秀而不帶著個人情感。 但是這本書也提到了，他的家庭生活與他對於第一個孩子夭折所帶來的痛苦。 這本書有許多有趣的歷史，更可以了解這些令人感到傳奇的執行長們的人生。像是賈伯斯，貝佐斯一樣，馬斯克一樣有著高超的學習能力與暴躁挑惕的個性。或許，這些也是這些傳奇執行者們的樣板一樣。 最後，相當推薦大家來看這本書。很多有趣的故事會讓你愛不釋手。

前提 大家好我是 LINE 台灣的 Technical Evangelist - Evan Lin 。「開發社群計畫」是今年一個開發者關係與技術推廣部門一個重點，將在今年一整年中，在台灣舉辦對內的技術交流、教育訓練，對外的社群聚會、校園演講、開發者徵才日與開發者大會等各式各樣超過30場的活動。我們希望創造更多技術分享與跨國串連的機會，同時，持續招募優秀的人才加入LINE台灣的開發工程團隊。 四月第一場社群活動邀請到 TWJUG (Taiwan Javsa User Group) 社群到 LINE 來舉辦。也請到 LINE Pay 的 Webber Su 來分享，除了讓更多人能夠了解 LINE Pay 工作經常用到的工具外，也希望能夠引發一些討論甚至可以互相交流。 Where is the ghost in the ghost island? Explore by Java and Mongo/ LINE Pay - Webber Su 投影片 首先上場的是 LINE Pay 的同仁 Webber Su 所帶來的透過開放資料集的一個案例分享。在 LINE Pay 的開發經驗上其實會遇到大量資料的處理與分析，但是由於許多的客戶資料都是屬於機密資料無法公開，所以透過開放資料集的案例來分享 LINE Pay 團隊日常遇到的相關問題。 透過開發資料將全台灣的事故資料匯入資料庫中，並且透過 LINE Pay Merchant Map 的部分的相關技術可以幫我們找出比較容易發生事故的問題區段。 在開始處理資料的之前，講者也分享了他會用到的相關開發工具如下： 以下稍微介紹每個工具的功能與相關作用： 資料的分析: Spring Web ， Spark 與 MongoDB 。 資料批次處理: Spring batch 與 MongoDB 。 網站的後台系統： Node.js ， Loopback 與 MongoDB 。 前台顯示部份: Vue.js 與 D3.js 。 這些開發工具也是 LINE Pay 團隊在開發上經常使用。除了開源專案工具之外， LINE Pay 也首次分享了 LINE Pay Merchant Map 的功能： LINE Pay Merchant Map 提供了地圖話資訊的條列與搜尋。包括了: List: 條列式的列表。 Nearby: 透過地圖是覺化的列出。 Search: 甚至透過關鍵字的搜尋方式。 在文字資料的搜尋上，究竟要使用 Elasticsearch 或是 MongoDB 作為文字搜尋呢？這裡講者也分享了當初在內部開發系統上，是透過哪些的評量方式來決定的。 由於許多效能的測試與評量上最後決定是 Elasticsearch 。而在地點鄰近搜尋 (Nearby) 上最後則是決定使用 MongoDB。 這個 Ghost Island 的架構其實也將 LINE Pay 開發團隊許多用到的工具分享給大家。裡面包括了資料該如何處理，該如何有效地處理與資料的讀取跟儲存？ 這邊講者也分享了一些經驗談，就像是這個案例一樣，對於資料的處理上要有許多小地方要好好處理。如果是開放資料的時候，對於資料的處理要更加小心。資料可能有誤，資料可能有缺甚至資料可能是空的。所以可能將資料多儲存在其他地方也是一個可以變通的方式。這樣可以避免在資料清洗的時候造成程序的錯誤。後端針對文字搜尋與鄰近地圖搜尋則是透過兩個不同的儲存工具（ Mongo 與 Elasticsearch )來處理資料。 而且講者也分享了在各個階段可能會踩到的雷（指的是遇到的問題）。不論是剛剛 Batch Spring process ，Spark 資料的處理上還是 Cargo 的部分。 整個主題雖然是使用開放資料的事故來做講解，但是不論是整個流程用到的相關開發工具還是可能會遇到的問題。講者也都分享出來 LINE...