前言 大家好，我是 LINE Taiwan Developer Relations 團隊的 - Evan Lin。 經過了一年多來的 LINE Developer Relations 的努力，想要在這篇文章裡面稍微整理一下整個團隊做了哪一些的事情，也希望為了「LINE 開發社群計劃」做年度報告。 根據原先 LINE Developer Relations 所寫的介紹文章 (Introducing Developer Relations team) 裡面很清楚地定義了這個團隊的主要目標如下： External Evangelism: 鼓勵開發者使用 LINE 的平台，API與SDK 來開發出具有魅力與有趣的應用服務。 (Encouraging people to make attractive and interesting services using the APIs and the SDK by LINE) Internal Evangelism: 透過一些方式使得工程師們自我成長與磨練自己 (Doing whatever our engineers feel difficult to do themselves in making improvements at work) Technical Branding and Hiring: 讓更多人了解身為 LINER(LINE 員工的自稱) 有許多有趣與令人興奮的事情。 (Letting people know how fun and exciting it is for engineers to work at LINE) 上一篇文章，已經明確的定義了 External Evangelism，接下來將更進一步的解釋 Internal Evangelism 與 Technical Branding and Hiring。 文章列表: [LINE DevRel] LINE Taiwan Developer Relations 2020 回顧與 2020 開發社群計畫報告 (part 1: External Evangelism) [LINE DevRel] LINE Taiwan Developer Relations 2020 回顧與 2020 開發社群計畫報告 (part 2: Internal Evangelism) (本篇文章) [LINE DevRel] LINE Taiwan Developer Relations 2020 回顧與 2020 開發社群計畫報告 (part 3: Technical Branding and Hiring) Internal Evangelism: 透過一些方式使得工程師們自我成長與磨練自己 首先這個部分大部分都是內部的分享與一些讓 LINER（在 LINE...

前言 大家好，我是 LINE Taiwan Developer Relations 團隊的 Evan Lin。 經過了 2020 年的 LINE Developer Relations 的努力，想要在這篇文章裡面稍微整理一下整個團隊做了哪一些的事情。 根據原先 LINE Developer Relations 所寫的介紹文章 (Introducing Developer Relations team) 裡面很清楚地定義了這個團隊的主要目標如下： External Evangelism: 鼓勵開發者使用 LINE 的平台，API與SDK 來開發出具有魅力與有趣的應用服務。 (Encouraging people to make attractive and interesting services using the APIs and the SDK by LINE) Internal Evangelism: 透過一些方式使得工程師們自我成長與磨練自己 (Doing whatever our engineers feel difficult to do themselves in making improvements at work) Technical Branding and Hiring: 讓更多人了解身為 LINER(LINE 員工的自稱) 有許多有趣與令人興奮的事情。 (Letting people know how fun and exciting it is for engineers to work at LINE) 以下的文章將會分成這三個部分來依序說明，也希望能讓更多的開發者跟著我們一起回顧 2019 開發者關係與技術推廣部有哪些有趣的成果。 文章列表: [LINE DevRel] LINE Taiwan Developer Relations 2020 回顧與 2020 開發社群計畫報告 (part 1: External Evangelism) (本篇文章) [LINE DevRel] LINE Taiwan Developer Relations 2020 回顧與 2020 開發社群計畫報告 (part 2: Internal Evangelism) [LINE DevRel] LINE Taiwan Developer Relations 2020 回顧與 2020 開發社群計畫報告 (part 3: Technical Branding and Hiring) External Evangelism: 鼓勵開發者使用 LINE 的平台，API 與SDK 來開發出具有魅力與有趣的應用服務 首先先介紹的是關於平台推廣的部分，今年的平台推廣主要有兩個重要的管道。一個就是開發者官方社群 OA (@line_tw_dev) 另外一個就是 LINE 開發者小聚。...

前提 一個關於 PTT BBS 後台 Golang 後端夥伴（因爲是交朋友專案，沒有薪水）的討論，在 Golang TG 的討論上也帶出關於 PTT 後台需求的討論。 以下經過整理後，貼上相關的討論內容。 以下先整理一些關於徵夥伴文的相關脈絡，裡面許多內容都是引用原文作者。 PTT 原文在這： moptt https://moptt.tw/p/Soft_Job.M.1610976994.A.2C8 ptt.cc https://www.ptt.cc/bbs/Soft_Job/M.1610976994.A.2C8.html 為何在找夥伴的文章上要求讀過 database/sql 與 go-sql-driver/mysql 兩個套件? 主要是風格問題，我(Pichu Chen) 基本上很擔心有人直接把 C Code Porting 成 Golang 的 Code, 然後註解通通都寫請去看 C Code 的哪個 function, 那這樣就GG了XD 關於 PTT BBS 找 Golang 夥伴，現階段目的? 這階段會想要先把整體 BBS 該有的讀寫的 interface 以及後續討論和採用的文化建立起來。 而目前我(Pichu Chen) 提出的解決方案是重新設計後端介面。 我們初期將會得到一個新的基於 HTTP 的後端介面， PTT APP 中台或者是行動 APP 的開發夥伴可以透過這個介面來存取 BBS 的資料庫。 在開發中有別以往 BBS 的開發流程，新的流程我會先將需要的功能寫成文字文件並且提出討論，一段時間後開立 GitHub ISSUE 進行實作。 因此可以確保新的程式碼是有文件以及清晰易懂的測試案例的，避免重蹈覆轍。 目前我們已經完成驗證帳號、取得看板(baord)列表、取得文章列表以及取得文章內容等功能，我們還需要持續完成新增推文(push/recommend)、新增文章、編輯我的最愛等等的功能。 但是我個人有個額外的請求，因為有先前在 Soft_Job 上提到的「東京都新冠肺炎對策網站(https://stopcovid19.metro.tokyo.lg.jp/)」的經驗，我還是希望能做到是由社群的多數人共同完成這個專案，而不是如同多數在台灣的開源專案，是由固定幾個「大神」來完成的。 PTT 目前的問題 (由輕重緩急排列) 介面/商業邏輯/資料庫的程式碼混在一起，造成調整使用者體驗上以及使用者介面上調整困難。 程式碼缺乏註解，可讀性極低。 原先的程式碼完全沒有 testing code. 程式碼完全沒有 benchmark 機制，修改架構仰賴設計者的威望而非科學證據。 大部分的架構仍然使用 32 位元的時間表示方式，這會導致 2038 問題。 密碼仍採用基於 DES 的雜湊方式，換句話說，強度不足。 過度仰賴共享記憶體的設計造成伺服器分散困難。 索引檔儲存方式彈性不足，不易新增新欄位。 轉信機制死亡已久。 站內訊息 （水球）、站內信無法透過手機即時通知使用者。 Current PTT 程式碼尚不支援 IPv6. 站內文章仍然使用 Big-5 儲存，不支援 emoji 或是台羅拼音。 不支援圖片上傳、音訊或是視訊通訊。 所以讀過 SQL 套件並不是要把 PTT 資料寫進資料庫? 其實bbs文章算滿階層的，就是文章自己擁有一個unique id，然後board去ref一個個的id，這個其實ptt已經有了，就是他們自家的網址轉換系統（像是: https://www.ptt.cc/bbs/car/M.1611180581.A.E43.html）這個什麼M.161180581.A.E43這類，所以既然有現成的key跟key generator，這方面應該可以不用重新設計。另外圖片跟log…er… bbs的資料應該絕大多數都不是圖片也不是log就是。 PTT 如果資料寫進資料庫的話 然後要不要把 BBS 的後端資料庫轉成 SQL 的討論歷史有點長了，但就結論而言數年來的討論下來，其實真的整個變成全SQL 架構的真的是沒有（也許巴哈有？畢竟他們家沒開源所以不知道）不過這階段我會想要先把整體 BBS 該有的讀寫的 interface 以及後續討論和採用的文化建立起來，因為先前確實有不少討論要不要轉成 SQL 的文章，但是實際上的效能測試也是幾乎沒有，那interface建立起來之後再試試看另外一個分支是以SQL實作的分支，這樣有效能數據之後這個問題才會比較容易在討論中有結論。 如果 PTT 資料有機會放入 RMDB 的話 如果說是把原有的資料庫轉成 SQL 系列的關聯式資料庫或者是 MongoDB 的話，我覺得優點上會是這些是現代開發人員熟悉的資料庫工具，再來是效能部分有其他團隊幫忙把關，以及有現成的分散式資料庫的設計。 缺點的部分我在數年前有問過學長，比較大的部分在於 SQL Command 需要另外做 Parsing，會有額外的開銷，再來是並不是所有東西都適合無腦塞SQL ，像是圖片或是Log檔設計我可能就不會把它放在關聯式資料庫上，我猜AWS...

作者： 夜觀天花板 出版社：高寶 出版日期：2019/06/12 語言：繁體中文 買書推薦網址：http://moo.im/a/789CHP 前言: 這一本是今年所讀完的第一本書。 這是一本相當有趣的書籍，透過類似 PTT 鄉民的寫作口吻來講解許多歷史上有趣的軍師。並且中間也穿插著許多知名的詩詞說明，讓閱讀起來相當的過癮。 比如說: 道衍：「王爺不要怕，貧僧是人畜無害的出家人，不如給您引薦幾個精通奇門之術的小夥伴怎麼樣？」 朱棣：「給本王來一打！」 系統提示：相士袁珙、卜者金忠加入燕王府，恭喜朱棣獲得資深神棍隊友×２。 相當多有趣的口吻，來讓閱讀上可以輕鬆又自在。 其實同系列好像還有一個「這些皇帝很有事」，是我接下來要閱讀的內容。 內容簡介與心得: 皇帝很有事、軍師不正常，國家馬上就滅亡。 腦洞大開與嚴謹考證激出的完美歷史新讀法！ 介紹帝系、佛系、法系這三系共十四種奇葩軍師， 輕鬆風趣的口吻加上講究嚴謹的考究帶你從另一個視角看歷史 章節條列 第一卷　帝系軍師：不行，免談，我做主 第一章　易燃易爆炸的偏執狂──王安石 第二章　人格分裂的兩個世界──張居正 第三章　令人恐懼的完美主義者──諸葛亮 第四章　誓做中華FLAG第一人──曹操 第二卷　佛系軍師：好的，都行，隨便你 第一章　戲精牆頭草症候群的誕生──蔡京 第二章　在修仙的妄想中如魚得水──李泌 第三章　佛系養生，瞭解一下──司馬懿 第四章　逃避雖然可恥但很有用──蘇味道 第五章　別說了，我有恐妻症──房玄齡 第三卷　法系軍師：閉嘴，安靜，別多話 第一章　行走江湖，全靠一張嘴──蘇秦 第二章　首例懟人症候群病毒誕生──魏徵 第三章　厲害了，我的超憶症──劉伯溫 第四章　令人窒息的誠實症候群──晏殊 第五章　真．佛系精神分裂作亂史──姚廣孝 一開始就是提到了比較獨斷的幾個軍師（曹操原來是軍師？），但是許多人其實文學造詣也都相當的高。不論是王安石的詩詞，還是諸葛亮的出師表，也都有在這一個階段提到。 到了後面的許多不同系列的軍師，也都提到許多他們的生平事蹟，讓讀者可以清楚的了解到這些軍師的生平之外，因為「伴君如伴虎」的關係，這些軍師的政治生涯也是起起伏伏。 許多時候大鳴大放，但是也會被貶謫到地方官去。 這些有趣的事蹟也會在這一本書裡面提到。 心得: 這一本書相當的舒壓，因為整體口吻就是用 PTT 鄉民的口吻來幫你解讀許多史書上面的內容。 整個相當的輕鬆，但是作者也會附上原文，讓讀者在相比較原文與作者的鄉民口吻上，會更加的佩服作者細心程度。透過這些有趣的口吻，來提升整本書的可讀程度。 由於我小時候經常閱讀相關的詩詞（要打電動就得要先被一首唐代詩詞），所以許多文字在作者的重新解釋下也變得更加的有趣了。推薦大家可以拿這一本書來當輕鬆的小品來讀喔。

前提 學習 Raft 的演算法的時通常都會將 Byzantine Failure 給排除掉，想不到在去年十一月底的 CloudFlare 的 incendent report 竟然用了現實世界的拜占庭問題來當作標題，就用這個來整理一些思緒。 什麼叫 Byzantine failure 在分散式系統中，不同電腦之間會相互的溝通作為「Consensus Communication」的資料確認流程。 需要不同電腦間，回報自己將要做的事情，或是進行 leader 投票的流程。 如果這時候發生了有一台電腦，跟某些團員講 A 跟另外一群團員又講 B 的狀況，造成整個團體無法達成一制性，或是達成了非預期狀態，就被稱為是 Byzantine Failure 。 許多的狀況下， Consensus Algorithm 舉凡 Paxos 跟 Raft 都會先假設 Byzantine Failure 是不存在的，因為這個問題會將 Consensus 複雜度又提升到另外一個境界。 參考文章: Wiki 拜占庭將軍問題 關於 CloudFlare 的復原機制 探討比較複雜的問題之前，其實這篇文章還有一個有趣的角度可以觀察。 就是如何透過 CloudFlare 的 Incident Report 來查看他們針對系統維護上有那一些備援機制。 服務備援機制 每一個服務都是一系列的 Rack Servers 每台機器有兩個 switches 每個機器主機架有兩個以上的電源供應設備 每個 server 都使用 RAID-10 的備份機制 (也就是 RAID 1 + RAID 0 的備份機制) 每一個 Rack 至少都是三台機器以上。 發生的問題 （圖片解釋： 左上角為 Server 1, 右側為 Server 2，下方為 Server 3 也是 Leader ) 由於 Server 1 到 Server 2 的網路發生問題。 造成 Server 1 與 Server 2 發生不同步的資訊問題。 Server1 認為 Leader (Server 3) 已經下線 Server 2 認為 Leader 是正常運行。 也是因為這樣的原因， CloudFlare 將這個問題在為 Byzantine Failure Reference Cloudflare Dashboard and Cloudflare API service issues A Byzantine failure in the real world Raft does not Guarantee Liveness in the face of Network Faults wiki: 拜占庭將軍問題 Raft lecture (Raft...

2020 年度回顧 女兒健康成長（父母最開心的事） 公開演講 13 場。 （而且年底公司大場，一天還講兩場） https://github.com/kkdai/slides 英文國際演講 2 場（一場日本 DevDay) https://github.com/kkdai/slides 15 本電子書閱讀. http://www.evanlin.com/categories/ Github 752 commits (2019 691) https://github.com/kkdai 3 場黑客松（梅竹，內部，校園競賽） 持續運動（但是運動量沒有之前高，要努力） 61 篇部落格（持續寫作，終生學習) 提攜後進，福音戰士二號機大有潛力 MHW, MHGU, 期待著 MH-R 2021 年度期許 家人健康 再瘦一點 Golang in Machine Learning