February 3rd, 2021

[LINE DevRel] LINE Taiwan Developer Relations 2020 回顧與 2020 開發社群計畫報告 (part 3: Technical Branding and Hiring)

前言

大家好，我是 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，接下來將更進一步的解釋 Technical Branding and Hiring。

文章列表:

Technical Branding and Hiring: 讓更多人了解身為 LINER(LINE 員工的自稱) 有許多有趣與令人興奮的事情。

LINE 作為一個技術為本的科技公司，許多的底層架構與服務都需要開發人員。但是 LINE 的科技品牌知名度是一個需要持續努力的方向，所以 Developer Relations 還有一個重要的工作就是要讓更多的開發者能夠了解 LINE Taiwan 擁有相當多的開發人員，並且這裡有許多有趣的職缺需要各方好手的加入。

Summer Tech Fair

我們希望創造更多技術分享與跨國交流的機會，同時持續招募優秀人才加入 LINE 台灣開發工程團隊! 這是參加到今年第一個聯合徵才的台灣科技就業博覽會，希望能讓更多的學生朋友能了解 LINE 所帶來的學生實習計畫。「 LINE 技術新星人才計劃 – LINE TECHFRERSH 」。

參考文章:

社群活動協辦邀請 (Community Meetup)

今年開始 LINE 台灣不僅僅自己舉辦社群活動，更歡迎各個技術社群來 LINE 台灣 辦公室舉辦社群聚會。 除了希望跟社群多多交流之外，也會提供 LINE 內部開發者跟大家分享相關的開發經驗。 身為開發者的讀者是否知道其實 LINE 內部也有積極參與歡迎各個社群一起來申請與交流。

因為疫情原因延緩了上半年的活動舉辦，下半年在 LINE 辦公室舉辦了 5 場的開源技術社群的聚會，並且與許多的社群一起合作，並且讓許多社群能夠了解到原來 LINE 也是有相關的開發技術工程師，並且每一位同仁都具有開放的態度與樂意分享。

相關文章:

也歡迎參考以下的文章來了解更多精彩的社群活動內容：

LINE 年度開發人員招募大會 LINE Developer Recruitment Day

LINE Taiwan Developers Recruitment Day 是一個針對開發者的公開招募活動。邀請通過線上初試的優秀好手前來參加面試，此外也規劃了一整天的產品與服務介紹，歡迎受邀面試的開發者一起來了解。

透過這次的活動也能讓更多的開發者除了了解 LINE 台灣有相當多的開發職缺等待各方好手的加入。

相關文章

技術研討會 (COSCUP, DataCon, JCConf, JSDC)

對於技術研討會部分，今年的 LINE Developer Relations 部門也參與了 JCConf ，並且擺設攤位讓 LINE 台灣的工程師與大家交流與討論。

我們也發現每一場的交流，每一場的互動除了可以感受到 LINER 分享的熱情，更可以感受到每一個開發者對於 LINE 服務的喜愛與好奇。 大家對於這個每天都在使用的服務技術架構內容都想要一探究竟，四場的研討會也感受到工程們交流的熱情。

相關文章:

南韓，日本與台灣的資訊安全社群 - BECKS

一直以來，資訊安全都是 LINE 最重視的環節之一，除了積極推動各項資安強化策略，更從今年 (2019) 開始，定期於韓國、日本、台灣三地聯合舉辦 BECKS.IO – Security Meetup，邀請各國資安研究者參加，讓全球各區域的資安研究者，透過這個聚會進行更多交流。

2019 年一共舉辦了五場的 BECKS 聚會，也期許有更多的參與者可以加入我們。

相關文章:

LINE 台灣年度開發者盛事 - LINE TECHPULSE 2020

LINE TAIWAN TECHPULSE 2020 已經在 2020/12/18 在南港展覽館二館舉辦了，不知道今年各位有沒有參與到這一場精心安排的盛會。 身為主辦單位其中一員，總是希望每一個點子與想法都能夠分享給每一位來賓，希望透過這一篇文章，不論你有沒有親臨現場都能夠感受到團隊們的用心。

今年除了是新的場地外，工作團隊也精心準備了以下數個項目歡迎大家來詳細了解：

  • LINE CLOVA 會場體驗
  • 首次雙軌議程，技術與商業應用的完美結合
  • 互動攤位: 讓你了解大神的機會
  • 展示架(Poster) : 跟 LINE 台灣服務工程師面對面討論架構

相關文章:

小結

這是 LINE Developer Relations 2020 成果整理的最後一篇文章，感謝各位的觀賞。

開發者關係 ( Developer Relations ) 從來都不是一條輕鬆的路，開發者由於自身對於技術交流的渴望，即便再辛苦上完一天的班之後，仍然願意利用下班過後的空閒時間來參加技術社群認識更多的同好，砥礪彼此的技術。 所以身為開發者關係與技術推廣部 (Developer Relations) 的工作人員更需要有熱情來籌畫有深度，有內涵讓每一個辛苦開發者能夠收穫滿滿的活動來讓大家開心的交流。

2020 年過去了，你有參加過幾場 LINE Developer Relations 所舉辦的活動呢？ 讓我們 2021 年再相見。

立即加入「LINE開發者官方社群」官方帳號，就能收到第一手Meetup活動，或與開發者計畫有關的最新消息的推播通知。▼

「LINE開發者官方社群」官方帳號ID：@line_tw_dev

關於「LINE開發社群計畫」

立即加入「LINE開發者官方社群」官方帳號，就能收到第一手Meetup活動，或與開發者計畫有關的最新消息的推播通知。▼

「LINE開發者官方社群」官方帳號ID：@line_tw_dev

關於「LINE開發社群計畫」

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

February 2nd, 2021

[LINE DevRel] LINE Taiwan Developer Relations 2020 回顧與 2020 開發社群計畫報告 (part 2: Internal Evangelism)

前言

大家好，我是 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。

文章列表:

Internal Evangelism: 透過一些方式使得工程師們自我成長與磨練自己

首先這個部分大部分都是內部的分享與一些讓 LINER（在 LINE 裡面，內部員工都被稱為是 LINER ) ，能夠有更多自我成長的機會，並且透過許多的分享讓彼此能夠更了解，在合作上也能夠更加的順暢。

許多有趣的線上線上訓練課程

LINE 的工程團隊，對於 今年因為疫情的原因，原本安排好許多當面授課的課程也被迫改成線上來教授。 但是也因為這個原因，讓課程的參與人可以來自全球的工作夥伴，課程上可以看到來自於日本，韓國，台灣，泰國，印尼與越南的工作同仁。並且透過即時口譯的方式，讓整個課程變得相當的親切與有趣。 課程內容更是多元，舉凡 MySQL 的效能調校與架構解析，到 MongoDB 的架構分析，甚至是程式碼可讀性都是授課的內容之一。 工作同仁每個月都有相關的訓練課程可以挑選，這裡僅分享有公開出來的文章給大家。

參考文章:

鼓勵同仁參與外部活動與分享技術文章

(照片來自： iPlayground 2020 精彩回顧)

LINE 一項是鼓勵工程團隊不斷且持續的自我進修與學習，對於想要學習的同仁更是給予相當多的福利。如果想要參加外部的技術研討會，一經申請核可，所有的參與經費（交通費）甚至是公假讓同仁去參與，盡情地學習。 也希望同仁可以回來後，跟其他同仁分享與寫成相關的文章。此外，我們也鼓勵同仁分享在工作上或是自我學習的文章分享。以下條列出相當多的文章，歡迎大家好好的了解一下。

參考文章:

新進員工訓練 (Internal OJT)

由於今年因為疫情影響了到日本總部的新人訓練的機會，也因此 LINE Developer Relations 為大家著想就在台灣本島直接辦一場內部員工訓練(On Job Training)啦！ 而這一次更加上許多技術新星（LINE TECH FRESH) 的同學一起參與。 訓練內容內包含了組織架構，職能分工，一些工作上容易遇到的問題，並且也讓大家透過分組可以跟其他同仁更加熟悉，讓工作氣氛能夠更融洽。最後也安排手足球的比賽，讓大家感受到團隊合作的重要性。

參考文章

LINE Taiwan Internal Hackathon 2020

LINE 很重視員工們的自主創新與團隊合作，所以各地都會舉辦 LINE Internal Hackathon 。 在 LINE 台灣這已經是第二屆的內部黑客松競賽，也期待能夠看到不同團隊激盪後滿滿的創意。

第一屆內部舉辦的時候，受到許多的迴響。不少非工程團隊也希望能夠一起參與，所以今年特定修改參賽方式，第二屆的 LINE 內部黑客松競賽的主題就是 「Team up for A+」 ，目標希望同仁們能團隊合作，共同優化與創新出更令人驚豔（WOW) 的產品服務。

參考文章:

小結

本篇文章接下來針對內部開發者來做相關的成果紀錄，接下來將有另外文章來說明。技術品牌與招募的相關成果。歡迎大家持續關注。

關於「LINE開發社群計畫」

立即加入「LINE開發者官方社群」官方帳號，就能收到第一手Meetup活動，或與開發者計畫有關的最新消息的推播通知。▼

「LINE開發者官方社群」官方帳號ID：@line_tw_dev

關於「LINE開發社群計畫」

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

February 1st, 2021

[LINE DevRel] LINE Taiwan Developer Relations 2020 回顧與 2020 開發社群計畫報告

前言

大家好，我是 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 開發者關係與技術推廣部有哪些有趣的成果。

文章列表:

External Evangelism: 鼓勵開發者使用 LINE 的平台，API 與SDK 來開發出具有魅力與有趣的應用服務

首先先介紹的是關於平台推廣的部分，今年的平台推廣主要有兩個重要的管道。一個就是開發者官方社群 OA (@line_tw_dev) 另外一個就是 LINE 開發者小聚。

LINE 開發者小聚

今年由於疫情的影響，許多線下活動都受到影響。 LINE 開發者小聚前兩次的活動： LINE Developer Meetup 開發者小聚系列活動 #11 ( LINE 開發者官方社群線上直播) 與 LINE Developer Meetup 開發者小聚系列活動 #12 ( LINE 開發者官方社群線上活動) 也首次採取線上的方式來舉辦。

除了在第十一次的聚會中，我們邀請到了開發 LINE SPOT 口罩地圖的 Julian Shen 來分享如何打造 LINE SPOT，並且也讓大家了解如何在相當短的時間內，馬上串接官方資訊打造出 LINE SPOT 口罩地圖 。

並且也在第十二次開發者小聚中第一次邀請了 LINE TAXI 的 CTO Hatden 與疫止神通的工程師來首次分享了 LINE TAXI 的相關開發技術與疫情下的神器：疫止神通的開發經歷。

九月的時候，由於疫情趨緩我們也得已透過線下的方式在交大舉辦 LINE Developer Meetup #13 。也帶著許多服務的開發工程師跟同學們相見歡：

相關鏈結：

Chatbot Meetup 的持續支持

Chatbot Taiwan Meetup 是一個相當活力的社團，也是 LINE 希望能夠持續支持的在地開源技術社群。不論是每一個月的分享與邀請 LINE API Expert 的協助。 LINE 希望 chatbot 社群能夠逐漸地擴大，並且希望更多的開發者能夠加入開發 chatbot 的行列。 今年更在新Tech Evangelist - Nijia Lin 的加入後，讓更多人可以聽到第一手的平台更新。

相關鏈結：

LINE FRESH 2020 校園競賽

LINE FRESH 代表著 LINE 台灣與學生之間的深度連結，而「LINE FRESH 實習計畫」已連續舉辦6年，不僅藉此發掘校園中的各領域優秀人才，同時也有不少年輕學子由此作為職涯起點。

LINE台灣團隊決定，在今年這個特別的時刻，我們舉辦第一屆的校園競賽，期望透過競賽的形式，廣邀校園中的優秀好手發揮創意，運用LINE旗下多元服務或開放的平台技術，為台灣產業創造更多商業可能性、為台灣用戶提供更全面的便利生活體驗。

相關文章

2020 梅竹黑客松

LINE 很重視員工們的自主創新與團隊合作，所以各地都會舉辦 LINE Internal Hackathon 。 並且在日前也舉辦了 在 LINE 台灣第二屆的內部黑客松競賽，而這次很開心跟新竹市政府與梅竹黑客松主辦單位一同支持學生們創新的 Hacking 精神，一起舉辦了 「新竹 x 梅竹黑客松」 LINE 的競賽組別。

在決賽前一週， LINE 的開發工程師也應邀出席了企業工作坊透過教導同學們 LIFF 與 LIFF Share Target Picker 來讓每一個參賽的同學能夠了解。 （詳情請看： 梅竹黑客松賽前企業工作坊 – LIFF shareTargetPicker )

參考文章

COSCUP 與 MOPCon 支持

對於技術與開源社群的研討會支援， LINE 也是積極支持。 而在 2020 年，我們也在 COSCUP 與 MOPCon 進行平台的技術分享。歡迎大家來參考相關文章去了解如何開發一個 LINE Notifty 的 SDK 。

參考文章

平台技術線上推廣

針對平台技術的線上推廣部分，很榮幸能參與一些線上的活動與線上課程的分享。 首先是在亞洲資料創新應用大擂台上， 與 LINE AI Company 的 CEO - Isago-san 一起出席參與線上討論。 並且也很榮幸受到台北商業大學的邀請，為了 2020 LINE Chatbot 設計大賽提供 LIFF 的相關教學課程。

參考資料

  • 亞洲資料創新應用大擂台 https://www.youtube.com/watch?v=9sY5XF8Gf0E
  • 第二屆對話機器人設計大賽 - LIFF 的介紹與相關應用 https://www.facebook.com/watch/?v=728455674401659

小結

本篇文章僅先針對 “External Evangelism”來做相關的成果紀錄，接下來將有另外兩篇文章來說明。對內的開發者關係與技術品牌與招募的相關成果。歡迎大家持續關注。

立即加入「LINE開發者官方社群」官方帳號，就能收到第一手Meetup活動，或與開發者計畫有關的最新消息的推播通知。▼

「LINE開發者官方社群」官方帳號ID：@line_tw_dev

關於「LINE開發社群計畫」

立即加入「LINE開發者官方社群」官方帳號，就能收到第一手Meetup活動，或與開發者計畫有關的最新消息的推播通知。▼

「LINE開發者官方社群」官方帳號ID：@line_tw_dev

關於「LINE開發社群計畫」

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

January 21st, 2021

[TIL]Golang TG社群上關於 PTT BBS 的討論懶人包

前提

一個關於 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 目前的問題 (由輕重緩急排列)

  1. 介面/商業邏輯/資料庫的程式碼混在一起，造成調整使用者體驗上以及使用者介面上調整困難。
  2. 程式碼缺乏註解，可讀性極低。
  3. 原先的程式碼完全沒有 testing code.
  4. 程式碼完全沒有 benchmark 機制，修改架構仰賴設計者的威望而非科學證據。
  5. 大部分的架構仍然使用 32 位元的時間表示方式，這會導致 2038 問題。
  6. 密碼仍採用基於 DES 的雜湊方式，換句話說，強度不足。
  7. 過度仰賴共享記憶體的設計造成伺服器分散困難。
  8. 索引檔儲存方式彈性不足，不易新增新欄位。
  9. 轉信機制死亡已久。
  10. 站內訊息 （水球）、站內信無法透過手機即時通知使用者。
  11. Current PTT 程式碼尚不支援 IPv6.
  12. 站內文章仍然使用 Big-5 儲存，不支援 emoji 或是台羅拼音。
  13. 不支援圖片上傳、音訊或是視訊通訊。

所以讀過 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 S3 也不會。

但是也不是說 SQL 在 BBS 專案中就一無是處，印象中在 PTT BBS 他們有把推文放在關聯式資料庫，不過不確定是一般的 PgSQL, MySQL 還是 Sqlite (我猜是sqlite, 因為有喵到類似程式碼)

那至於現代新設計是否應該或是不應該使用 FileSystem 作為 DB, 我認為還是要看問題本身，新的專案例如 CoreDNS 他確實還是把發出的lease以空白分隔的格式存下來，他其實也是可以使用sqlite的，不過我認為他用sqlite的話他需要另外引入外部套件，再來是如果線上 OP 需要直接刪掉某個 lease 紀錄時他需要下 DELETE 命令，不會比 vim 打開後刪掉快。

再來現代關聯式資料庫的優點除了提供統一的操作介面以外，另外的好處是他有個基於 b+-tree 的 index, 這點是目前 BBS 系統中看不到的。目前BBS 系統中有看到稍微加速的索引會像是我要找 pichu 然後先以字首 p 做分類，去取 /usr/p/pichu 資料夾底下的東西，那眾所皆知， e i 的字頻通常會比較高，所以很有可能在這個資料夾裡的使用者或是版面數量會比其他資料夾多，造成些許的不平衡。比較好的做法也許是像是 git 的資料庫設計一樣，先將 userid 做 sha1 hash, 然後也是取一碼或是兩碼來做資料夾索引，這樣比較容易平衡。

但是現有的基於文章的作法確實也是有些缺點，舉例來說檔案最小大小會受限於檔案系統的限制，假如某個檔案系統的block size 是4KB, 那即使他只有一行12 Byte的文字，在硬碟中也會佔用4KB 以及一個 inode, 也因此後面各站都會宣傳禁止「一行文」，甚至後來發展出推文系統，基本上就是為了處理這個問題。不過現代硬碟空間其實大很多了，inode 數量也多很多了，是不是還是問題也可以重新探討。又或者是加上一些現代的機制去統計哪些文章被修改的次數可能已經超過一年了，屬於冷門文章了，然後去預測他接下來一年內被修改的機率低於一個 p 值之後就把他們Archive起來成同一個大檔案，在用另外一個 sqlite 檔案來索引他們的 fseek 位置和 length (更想不開的話也許還可以加上壓縮省空間。

也就是說，前人在設計這套系統的時候，他其實不太像是「使用資料庫」而以，他比較像是去討論如何設計一套資料庫，然後不同間 BBS 之間有互相參考之類的，才變成現在這個樣子。

至於這些討論文章，其實要去各個小站裡面翻，應該是Google 不太到了，或者是像這篇文一樣，時間到就被 telegram 洗到不知道哪邊去了～

其他：

  • PTT BBS source code https://github.com/ptt/pttbbs
  • PTT File struct https://github.com/ptt/pttbbs/wiki/STRUCTURE
  • MapleBBS 3.0 簡報文件 https://hackmd.io/@holishing/BkJHevM4f?type=view

TG 討論全文:

作為查詢之用

hsu jimmy, [20.01.21 19:04]
[徵才] BBS 後端實作 (全遠端)(無薪)
https://moptt.tw/p/Soft_Job.M.1610976994.A.2C8

Wu Gordon, [20.01.21 19:06]
[ Photo ]

Wu Gordon, [20.01.21 19:06]
好好奇為什麼需要

Stefan ﾠ😹, [20.01.21 19:07]
[In reply to Wu Gordon]
暗示了沒有用orm

Wu Gordon, [20.01.21 19:08]
但也沒有需要去修改成自己的版本為什麼會需要讀過呢？ 套件doc使用規範應該就可以滿足使用方式🤔

Wu Gordon, [20.01.21 19:08]
我只是好奇這樣需求的背後思維

Stefan ﾠ😹, [20.01.21 19:09]
也就是說重度使用了sql

Stefan ﾠ😹, [20.01.21 19:09]
任何形式的包裝也沒有做好

Stefan ﾠ😹, [20.01.21 19:09]
像sourcemod那種亂來的sql

Evan Lin, [20.01.21 19:13]
[In reply to Stefan ﾠ😹]
除了這個之外，可能希望能了解這兩個套件的寫作風格。
這樣也能確保知道對方寫作的方式可以基於這兩個套件的風格？

Wu Gordon, [20.01.21 19:14]
這樣啊

Julian Chu, [21.01.21 07:34]
看起來比較像是要借鑑database/sql的概念跟架構，提供一個共同的介面，抽換driver就可以存取不同格式的BBS檔案資料

Rayer Tung, [21.01.21 07:47]
話說ptt 用的不是通用SQL(好像是Postgres)嗎

Rayer Tung, [21.01.21 07:48]
有啥理由得自己幹一個adapter起來 而不是用既有的實作？

Rayer Tung, [21.01.21 07:49]
每個實作其實都是用共通介面的啊

Yami Odymel https://yami.io/, [21.01.21 07:54]
世紀之謎

Julian Chu, [21.01.21 08:27]
沒有印象ptt是用sql ，這資訊哪邊可以看?

Peiming, [21.01.21 08:27]
[In reply to Rayer Tung]
因為沒有用到任何 SQL，一個文章就是一個檔案這樣。https://github.com/ptt/pttbbs/wiki/STRUCTURE

Julian Chu, [21.01.21 08:28]
[ 🍺 Sticker ]

Peiming, [21.01.21 08:28]
更進一步的資訊要再找一下

Rayer Tung, [21.01.21 09:40]
ah, make sense.... 我一直以為他以前有匯入成sql過。不過這樣的話，第一件事應該是，把這個用FS當DB的系統匯入一個真正的DB吧 o_o

Rayer Tung, [21.01.21 09:41]
而不是想辦法硬幹FS當DB的Adapter

Rayer Tung, [21.01.21 09:41]
[In reply to Julian Chu]
這是印象中，不過顯然我印象錯了 😆

Peiming, [21.01.21 09:45]
[In reply to Rayer Tung]
這個想法主要是為了讓各家 bbs 可以寫自己的 driver，因為現在每個站台的 bbs 用的不太一樣
https://github.com/clyang/bbslist

Rayer Tung, [21.01.21 09:47]
這計畫滿宏大的 😆 不過我倒是覺得，假設我能決策的話，我會先把ptt轉db，而這個「對其他bbs的adapter」的priority我會放得很後面。不過也許他們有更多原因是我所不知道的，也說不定。

Rayer Tung, [21.01.21 09:47]
畢竟以FS當DB，在25年前make sense，但是在現在（甚至十年前）都是很不可理解的一件事。

Pichu Chen, [21.01.21 14:57]
[In reply to Rayer Tung]
Hello,

如果說是把原有的資料庫轉成 SQL 系列的關聯式資料庫或者是 MongoDB 的話，我覺得優點上會是這些是現代開發人員熟悉的資料庫工具，再來是效能部分有其他團隊幫忙把關，以及有現成的分散式資料庫的設計。

缺點的部分我在數年前有問過學長，比較大的部分在於 SQL Command 需要另外做 Parsing，會有額外的開銷，再來是並不是所有東西都適合無腦塞SQL ，像是圖片或是Log檔設計我可能就不會把它放在關聯式資料庫上，我猜AWS S3 也不會。

但是也不是說 SQL 在 BBS 專案中就一無是處，印象中在 PTT BBS 他們有把推文放在關聯式資料庫，不過不確定是一般的 PgSQL, MySQL 還是 Sqlite  (我猜是sqlite, 因為有喵到類似程式碼)

那至於現代新設計是否應該或是不應該使用 FileSystem 作為 DB, 我認為還是要看問題本身，新的專案例如 CoreDNS 他確實還是把發出的lease以空白分隔的格式存下來，他其實也是可以使用sqlite的，不過我認為他用sqlite的話他需要另外引入外部套件，再來是如果線上 OP 需要直接刪掉某個 lease 紀錄時他需要下 DELETE 命令，不會比 vim 打開後刪掉快。

再來現代關聯式資料庫的優點除了提供統一的操作介面以外，另外的好處是他有個基於 b+-tree 的 index, 這點是目前 BBS 系統中看不到的。目前BBS 系統中有看到稍微加速的索引會像是我要找 pichu 然後先以字首 p 做分類，去取 /usr/p/pichu 資料夾底下的東西，那眾所皆知， e i 的字頻通常會比較高，所以很有可能在這個資料夾裡的使用者或是版面數量會比其他資料夾多，造成些許的不平衡。比較好的做法也許是像是 git 的資料庫設計一樣，先將 userid 做 sha1 hash, 然後也是取一碼或是兩碼來做資料夾索引，這樣比較容易平衡。

但是現有的基於文章的作法確實也是有些缺點，舉例來說檔案最小大小會受限於檔案系統的限制，假如某個檔案系統的block size 是4KB, 那即使他只有一行12 Byte的文字，在硬碟中也會佔用4KB 以及一個 inode, 也因此後面各站都會宣傳禁止「一行文」，甚至後來發展出推文系統，基本上就是為了處理這個問題。不過現代硬碟空間其實大很多了，inode 數量也多很多了，是不是還是問題也可以重新探討。又或者是加上一些現代的機制去統計哪些文章被修改的次數可能已經超過一年了，屬於冷門文章了，然後去預測他接下來一年內被修改的機率低於一個 p 值之後就把他們Archive起來成同一個大檔案，在用另外一個 sqlite 檔案來索引他們的 fseek 位置和 length (更想不開的話也許還可以加上壓縮省空間。



也就是說，前人在設計這套系統的時候，他其實不太像是「使用資料庫」而以，他比較像是去討論如何設計一套資料庫，然後不同間 BBS 之間有互相參考之類的，才變成現在這個樣子。

至於這些討論文章，其實要去各個小站裡面翻，應該是Google 不太到了，或者是像這篇文一樣，時間到就被 telegram 洗到不知道哪邊去了～

Liu Kakashi, [21.01.21 15:01]
寫的很好耶，應該要留存一下

Rayer Tung, [21.01.21 15:04]
其實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就是。MAPLE時代的concern其實我也稍微知道一點，當年的SQL可能跑起來不如FS。但是現代的DB，有index，有redundency，有partition，這些都能大幅度的增加讀寫效率，當然MAPLE都20多歲了，改動這個的確非常困難，不過我想寫一個go sql lib相容的interface跟這個比，這投資哪個好哪個不好我覺得也許能討論一下? 😆

Rayer Tung, [21.01.21 15:05]
尤其是FS備份我猜應該他們用禮拜天早上rsync? 如果是的話，DB應該會做得比他好得多....

Rayer Tung, [21.01.21 15:05]
但是ptt是否仍然有那麼高的投資價值我就尊重主事者的看法了，畢竟其實共識上這算是一個sunsetting的東西，只是我們看能不能讓他走得更長一點

Pichu Chen, [21.01.21 15:33]
[In reply to Rayer Tung]
基本上沒有說要和sql lib 相容，當時會先請大家去看這兩個專案的原因上面 tg 群組裡面也有人提到了，主要是風格問題，我基本上很擔心有人直接把 C Code Porting 成 Golang 的 Code, 然後註解通通都寫請去看 C Code 的哪個 function, 那這樣就GG了XD

然後要不要把 BBS 的後端資料庫轉成 SQL 的討論歷史有點長了，但就結論而言數年來的討論下來，其實真的整個變成全SQL 架構的真的是沒有（也許巴哈有？畢竟他們家沒開源所以不知道）不過這階段我會想要先把整體 BBS 該有的讀寫的 interface 以及後續討論和採用的文化建立起來，因為先前確實有不少討論要不要轉成 SQL 的文章，但是實際上的效能測試也是幾乎沒有，那interface建立起來之後再試試看另外一個分支是以SQL實作的分支，這樣有效能數據之後這個問題才會比較容易在討論中有結論。

Rayer Tung, [21.01.21 15:35]
只是覺得幹一個sql interface可能難度滿大的，更令人擔心的是會不會因為FS讀寫的關係犧牲掉每個method的效能。不過的確，這個要做下去才知道，沒東西benchmark用猜的其實意義不大，這方向我覺得沒啥問題。領導這陳年堆積東西其實挺雜的，加油。

Rayer Tung, [21.01.21 15:36]
既然只是為了風格統一，我想應該很快就會有能benchmark的版本了

Evan Lin, [21.01.21 16:04]
[In reply to Rayer Tung]
可能看整體營運的想法為何，畢竟 ptt -> db 的等於就是打掉重練的架構。
不考慮 legacy 的疑慮，對其他 bbs adapter 或許真的比較重要。
在以前 Maple 時代要對接真的是很累～要跑另一個程式慢慢的對齊 (twbbs?)

如果能將 ptt 當成 single source of truth ，可以提供許多 API 讓更多人發想運用。
是很好的～ API 出來～我想也會有更多應用會發想出來（我就蠻期待的）

Kevin Yang, [21.01.21 16:06]
ptt 可能不久之後就掰了吧

Kevin Yang, [21.01.21 16:07]
不開放註冊 人氣一直掉

Kevin Yang, [21.01.21 16:07]
還有各路警察

Rayer Tung, [21.01.21 16:07]
[In reply to Evan Lin]
其實把ptt的fs based結構Restful化 就等於把MAPLE系列的bbs都能Restful化 我還滿期待那天的到來的 😆

Marcus Liu, [21.01.21 16:44]
其實 ptt 一直有在 call for help 
他們也是想先解決掉註冊問題

Marcus Liu, [21.01.21 16:44]
https://g0v.hackpad.tw/Ptt--ctwZwU7BxcJ

Julian Chu, [21.01.21 16:44]
就算是轉成sql 對現有資料的parser還是要做的吧， 直接轉sql風險比較高，提供一個介面增加彈性，先相容現有的資料格式，我個人覺得是低風險又可以比較快看到成果的選擇

Marcus Liu, [21.01.21 16:44]
但說真的 我覺得很難

Evan Lin, [21.01.21 16:54]
[In reply to Pichu Chen]
@pichuchen 跟 @killercat9  如果不介意，我整理一下這邊討論內容到部落格再來轉貼到臉書社團去。
就不會埋落在時代的洪流惹

Pichu Chen, [21.01.21 16:54]
我OK  CC BY-SA

Rayer Tung, [21.01.21 16:54]
沒問題

Rayer Tung, [21.01.21 16:55]
CC BY SA
January 18th, 2021

[好書分享] 這些軍師不正常 

作者： 夜觀天花板  
出版社：高寶 
出版日期：2019/06/12 
語言：繁體中文

買書推薦網址：http://moo.im/a/789CHP

前言:

這一本是今年所讀完的第一本書。 這是一本相當有趣的書籍，透過類似 PTT 鄉民的寫作口吻來講解許多歷史上有趣的軍師。並且中間也穿插著許多知名的詩詞說明，讓閱讀起來相當的過癮。

比如說:

道衍：「王爺不要怕，貧僧是人畜無害的出家人，不如給您引薦幾個精通奇門之術的小夥伴怎麼樣？」
朱棣：「給本王來一打！」
系統提示：相士袁珙、卜者金忠加入燕王府，恭喜朱棣獲得資深神棍隊友×２。

相當多有趣的口吻，來讓閱讀上可以輕鬆又自在。

其實同系列好像還有一個「這些皇帝很有事」，是我接下來要閱讀的內容。

內容簡介與心得:

皇帝很有事、軍師不正常，國家馬上就滅亡。
腦洞大開與嚴謹考證激出的完美歷史新讀法！

介紹帝系、佛系、法系這三系共十四種奇葩軍師，
輕鬆風趣的口吻加上講究嚴謹的考究帶你從另一個視角看歷史

章節條列

第一卷　帝系軍師：不行，免談，我做主

  • 第一章　易燃易爆炸的偏執狂──王安石

  • 第二章　人格分裂的兩個世界──張居正

  • 第三章　令人恐懼的完美主義者──諸葛亮

  • 第四章　誓做中華FLAG第一人──曹操

第二卷　佛系軍師：好的，都行，隨便你

  • 第一章　戲精牆頭草症候群的誕生──蔡京
  • 第二章　在修仙的妄想中如魚得水──李泌
  • 第三章　佛系養生，瞭解一下──司馬懿
  • 第四章　逃避雖然可恥但很有用──蘇味道
  • 第五章　別說了，我有恐妻症──房玄齡

第三卷　法系軍師：閉嘴，安靜，別多話

  • 第一章　行走江湖，全靠一張嘴──蘇秦
  • 第二章　首例懟人症候群病毒誕生──魏徵
  • 第三章　厲害了，我的超憶症──劉伯溫
  • 第四章　令人窒息的誠實症候群──晏殊
  • 第五章　真．佛系精神分裂作亂史──姚廣孝

一開始就是提到了比較獨斷的幾個軍師（曹操原來是軍師？），但是許多人其實文學造詣也都相當的高。不論是王安石的詩詞，還是諸葛亮的出師表，也都有在這一個階段提到。 到了後面的許多不同系列的軍師，也都提到許多他們的生平事蹟，讓讀者可以清楚的了解到這些軍師的生平之外，因為「伴君如伴虎」的關係，這些軍師的政治生涯也是起起伏伏。 許多時候大鳴大放，但是也會被貶謫到地方官去。 這些有趣的事蹟也會在這一本書裡面提到。

心得:

這一本書相當的舒壓，因為整體口吻就是用 PTT 鄉民的口吻來幫你解讀許多史書上面的內容。 整個相當的輕鬆，但是作者也會附上原文，讓讀者在相比較原文與作者的鄉民口吻上，會更加的佩服作者細心程度。透過這些有趣的口吻，來提升整本書的可讀程度。

由於我小時候經常閱讀相關的詩詞（要打電動就得要先被一首唐代詩詞），所以許多文字在作者的重新解釋下也變得更加的有趣了。推薦大家可以拿這一本書來當輕鬆的小品來讀喔。

January 15th, 2021

[TIL][讀後心得] 分散式系統現實世界的拜占庭將軍問題 (note from CloudFlare - A Byzantine failure in the real world)

前提

學習 Raft 的演算法的時通常都會將 Byzantine Failure 給排除掉，想不到在去年十一月底的 CloudFlare 的 incendent report 竟然用了現實世界的拜占庭問題來當作標題，就用這個來整理一些思緒。

什麼叫 Byzantine failure

在分散式系統中，不同電腦之間會相互的溝通作為「Consensus Communication」的資料確認流程。 需要不同電腦間，回報自己將要做的事情，或是進行 leader 投票的流程。 如果這時候發生了有一台電腦，跟某些團員講 A 跟另外一群團員又講 B 的狀況，造成整個團體無法達成一制性，或是達成了非預期狀態，就被稱為是 Byzantine Failure 。 許多的狀況下， Consensus Algorithm 舉凡 Paxos 跟 Raft 都會先假設 Byzantine Failure 是不存在的，因為這個問題會將 Consensus 複雜度又提升到另外一個境界。

參考文章:

關於 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