Attitude is everything

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

December 31st, 2020

2020 年度回顧與展望

2020 年度回顧

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

2021 年度期許

  • 家人健康
  • 再瘦一點
  • Golang in Machine Learning
December 27th, 2020

[好書分享]賈伯斯傳（最新增訂版）(Steve Jobs) 

賈伯斯傳（最新增訂版）
Steve Jobs
作者： 華特．艾薩克森  
原文作者： Walter Isaacson  
出版日期：2013/09/11

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

前言:

這一本是今年所讀完的第十五本書。 其實這本書很捨不得看完，因為邊看這本書我習慣邊看著電影。或是邊看著蘋果的發表會來了解其中的一些細節。其實當年對於賈伯斯的認知，都是來自於早期的矽谷相關電影「微軟英雄」。 雖然這部電影其實也蠻久的了，但是許多的描述也是相當的深入，對其他相關的書籍與電影都影響相當的大。

後來由艾希頓庫奇所拍攝的「賈伯斯」，則更深入得探討到賈伯斯的內心轉折。也很建議大家來看。

最後，來談到這本書。高達六七百頁的書籍。內容包含了學生時期的賈伯斯，一直到賈伯斯因為癌症過世之前的心路歷程。都包含在其中，很值得推薦一看。

內容簡介與心得:

人人都知道賈伯斯不遺餘力捍衛隱私，這位傳奇性的企業家從未寫過回憶錄，但他在兩年間，接受本書作者艾薩克森多達四十餘次的深入訪談，並允許他遍訪他的朋友、親戚、競爭對手、仇人和同事，總數超過一百人。

艾薩克森寫出「最真實的賈伯斯」，書中描述這位創造力旺盛的企業家雲霄飛車般驚險刺激的一生。賈伯斯執著的個性、追求完美的熱情和狂猛的驅力推動六大產業革命，包括個人電腦、動畫、音樂、電話、平板電腦和數位出版。

這不只是賈伯斯的故事，也是一本談創新的書。在這個數位時代，很多企業都努力走在創新的最前頭，許多國家也汲汲於建立創新經濟，但就獨創、想像和創新，賈伯斯無疑是標竿人物。他深知要在二十一世紀創造出有價值的東西，必然要讓創造力和科技結合，因此他打造的公司，不但要有跳躍的想像力，更要呈現鬼斧神工般的科技工藝。

章節條列

1955-1980．天生反骨

這個章節講的主要是從小到求學時期到他的蘋果電腦公司的創立，並且詳細的敘述了他在學生時代在雅達利打工的怪僻。當時的他不愛洗澡，所以都是晚上才上班。但是因為寫程式的功力很了得，常常可以解決很困難的問題。所以當時的主管就讓他晚上才上班，這樣也可以避免他跟其他人的來往。

到了 Apple II 的大賣，也讓蘋果電腦變成上市的公司。瞬間也讓賈伯斯必須要在很年輕的時候就要率領著一堆比起他資深太多得各種專家來經營公司。

1980-1991．大起大落

從上市之後，麥金塔的打造更是讓蘋果電腦登上 1984 年的超級盃廣告。

但是隨著麥金塔的上市，隱憂也開始了。 蘋果電腦內部逐漸分裂鬥爭。賈伯斯也因此被趕了下來。

但是離開了蘋果的賈伯斯，雖然失意但是卻因此有機會成為皮克斯的股東。這裡也放一下最知名的 Pixar 的標誌。

1991-2004．不同凡想

藉由著 NexT 的併購案，蘋果電腦透過併購了賈伯斯後來創力的 NexT 而邀請賈伯斯回鍋當 iCEO（interm-CEO），之後則有了 iMac 等等，讓人驚艷的新產品。 也是在這個同時，皮克斯也迎來了最大的成功（玩具總動員的上映），皮克斯後來也接受了迪斯尼的併購，並且接手了動畫部門的開發。

這個階段的賈伯斯則是在前十年的沈澱後，完全堅持在更完美的產品研發上。

2004-2011．超越死亡

最後的階段，雖然 Apple 也開發出了劃時代的產品 iPhone 。 完全改變了應用端從桌面到行動裝置的年代，但是賈伯斯的身體也對他發出了抗議。 癌症的發病與延誤的治療，讓病情無法馬上獲得控制， 即便後來使用了許多相關療法，還是讓病情無法緩和下來而復發。

接下來，如同大家所了解的，到了過世的前幾天賈伯斯才卸下了蘋果 CEO 的重擔。在家人的陪伴下離開了。

心得:

記得當初賈伯斯過世的時候，許多人都相當的難過。 我想除了是紀念一個偉大的創業者，產品經理。更是紀念一個堅持己見的產品愛好者，經常在許多時候，都會有著想要偷懶與得過且過的心情。 但是受到賈伯斯對於產品的堅持與追求完美的信念，又會開始努力下去。

許多人說，賈伯斯也是人他也有很多失敗的過程。這本書也有他人性的一面，不論是年輕時候不願意面對自己的小孩，到後來又相當的後悔。不論是更多的失敗的產品，或是他被逼退的過程，更走詳細的敘述。蘋果之所以成為偉大的公司，正也是在於賈伯斯的統一集權的狀況。

不論你喜不喜歡賈伯斯，我們都得承認「Steve Jobs」 這個名詞應該會成為我們心中對於產品不停追求的象徵。

最後，這一句來自 Think Different 裡面的文字，分享給大家。

The people who are crazy enough to think they can change the world are the ones who do.”

──Apple's "Think Different" commercial， 1997