[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場以上的活動。歡迎讀者們能夠持續回來察看最新的狀況。詳情請看:

[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/sqlgo-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

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

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

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

前言:

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

比如說:

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

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

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

內容簡介與心得:

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

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

章節條列

第一卷 帝系軍師:不行,免談,我做主

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

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

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

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

第二卷 佛系軍師:好的,都行,隨便你

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

第三卷 法系軍師:閉嘴,安靜,別多話

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

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

心得:

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

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

[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

LINE TAIWAN TECHPULSE 2020 活動安排幕後祕辛

前言

大家好,我是 LINE Developer Relations 團隊的資深開發技術推廣工程師 - Evan Lin 。主要的工作項目就是平台技術推廣與技術品牌的建立與溝通。 LINE TAIWAN TECHPULSE 2020 已經在 2020/12/18 在南港展覽館二館舉辦了,不知道今年各位有沒有參與到這一場精心安排的盛會。 身為主辦單位其中一員,總是希望每一個點子與想法都能夠分享給每一位來賓,希望透過這一篇文章,不論你有沒有親臨現場都能夠感受到團隊們的用心。

這是第一次在南港展覽館二館舉辦,擁有像是飛機場走廊的背景。寬廣的腹地讓每一個參與民眾可以在保持安全距離的限制下,盡情的與工程師們相互的討論。 並且提供廣大的腹地,可以讓更多的開發者們聆聽到 LINE 工程團隊的分享與討論。

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

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

接下來本篇文章將針對這些精心準備的項目來詳細敘述,歡迎各位來好好的了解。

LINE CLOVA 會場體驗

刷臉入場 - 快速的 CLOVA Face Sign 入場機制

相信每一個有參與的參加者都有感受到,今年在活動開始前兩天。活動的官方帳號有發訊息要每一位參加者上傳臉部的照片,作為活動當天的臉部辨識入場的依據。 活動當天只要透過會場前面的平板電腦就可以馬上刷臉入場,不會有任何資訊檢查與驗證的問題。 也可以快速地減少每一位參與者的入場時間。 今年的入場狀況也縮短了許多,讓整個活動的進行變得相當的順暢。

對於開發流程有興趣的開發者,可以參考一下這篇投影片的開發經過。 之後 LINE CLOVA 在台正式開放後,歡迎每一位開發者來申請。

透過CLOVA OCR 來達到文字辨識攤位集點贈品

今年在攤位活動上,主辦單位也有了新的巧思。 透過每個攤位的活動集點,可以讓每一個參與者去每一個攤位了解更多資訊。 當通過每個攤位活動的時候,每一個參與者將使用照片上傳的方式,讓背板上的錦旗可以上傳到伺服器辨識出特定文字後才能通過集點任務。 這個部分也是透過了 CLOVA OCR 的光學文字辨識的技術,並且可以快速掃描各種制式表單上的文字,而不會有任何文字上面的問題。 也可以透過制式表單的定義後,自動掃瞄出相關的欄位資料。 讓開發者更加的方便。

更進化的相片牆:刷臉分享出你今天公開的貼文串照片。

就在去年的時候,主辦單位首次將相片牆加入了 TECHPULSE 。 每一位參與者只要按下官方帳號的分享按鈕,就會馬上啟動相機拍照過後的照片就會公開分享到 「LINE 貼文串」 並且加上了活動的標籤 Hashtag #LINETECHPULSE2020 。 而今年更佳的進階了,透過了臉部辨識 CLOVA Face 的導入,每一位參與者只要經過我們的相片牆。就會辨識出使用者,並且找出該使用者今天在 「LINE 貼文串」公開的活動貼文照片。

相關新聞:

首次雙軌議程,技術與商業應用的完美結合

今年首次在 TECHPULSE 採取雙軌議程,早上的議程維持的單軌的大場地。讓每一位來賓能夠聽到完整的 Keynote 議程,不論是由 LINE 技術長帶來的主題演講外,更有 LINE CLOVA 的介紹, API 平台的更新最後則是由資料工程團隊所帶來的 MLOps 的相關分享。 早上的兩個議程合併的場地,除了帶給聽眾足夠安全的社交距離空間外,更讓大家都可以第一首聽到與看到相關的相關的介紹。

而中午得時間,場地則一分為二分別為:

  • LINE 平台推廣講座
  • LINE 技術分享講座

讓不同取向的聽眾,可以挑選自己有興趣的議程來了解與講者互動。

A廳: LINE平台推廣講座

首先介紹的就是下午的 LINE 平台推廣講座,主要的目的是希望透過外部講者來分享如何使用 LINE API 平台的技術應用,並且讓開發者們來了解其他開發者是如何應用這些功能。 也希望透過這個講座可以讓更多開發者能知道一些進階的功能 Tech-Partner API 與問題詢問上要找哪一些大神(LAE)。最後也會分享 LINE 新星計畫 (PROTOSTAR) 透過許多新創公司的分享,了解 LINE 平台技術的應用與新星計畫的細節。

其中有三個大的主要議程:

LINE API Expert Sharing - Evan Lin

由筆者所帶來的議程,裡面除了介紹什麼是 LINE API Expert 之外,也請到了LAE Richard Lee 跟董大偉來分享。 如果想要瞭解更多關於 LAE 的相關資訊,可以參考以下資訊:

LINE Official Account Tech Partner and Module Channel Sharing - Jeremy Hsu

由 LINE Corporation Business 團隊的 Jeremy 所帶來的關於技術合作夥伴 (Tech-Partner) 的介紹,並且也透過漸強實驗室的 Chris 來分享了解到關於 LINE Beacon 的應用案例,了解更多關於 Partner 才能使用的專屬功能:

  • LINE Beacon - Stay event
  • Notification Message

更多資訊可以參考投影片的內容,我們也將準備更多詳細的文件說明,敬請期待。

LINE Protostar Program Introduction & Startup Demo - Kevin Chen

平台技術推廣講座的最後,則是由 LINE 新星計畫團隊 Kevin 帶來的關於 LINE PROTOSTAR 的介紹,並且帶出今年入選新星計畫的十個團隊。 這邊也提供相關廠商的資料與投影片如下:

B廳: LINE技術分享講座

在「LINE 技術分享講座」則是有 LINE 台灣的工程團隊帶來的滿滿的乾貨,不論是由 LINE Pay 帶來的新服務 My Card 關於開發的介紹,還是由 SRE (Site-Reliability Engineering)團隊所帶來的 GitOps 在 Kubernetes 上面的分享,還是許多台灣服務的開發工程團隊帶來的閃電秀內容。 滿滿的內容,希望每一位在資訊業界的開發朋友可以來相互交流,來了解工程團隊如何打造一個千萬人使用等級的服務,必且在大流量的衝擊下應該要注意到哪些事項讓服務的交付上能夠更加的穩定。

更多的內容將在文章下方的鏈結,歡迎大家直接看投影片來了解。

互動攤位: 讓你了解大神的機會

首先問了讓每個參與的人都有機會可以跟講者們面對面討論的機會,主辦單位這次提供了互動攤位。並且有四大主題攤位:

LINE Pay:

行動支付已經是一大風潮,想要透過 LINE 官方帳號來創業的夥伴們,都希望可以快速的了解如何串接 LINE Pay ,這個攤位給你一個面對面的討論機會。 今年更有新的服務開發說明 LINE Pay - My Card ,大家也可以拿著會場客製化版本的 TECHPULSE 會員卡,來攤位領取限量贈品。詳細說明如何串接服務大家也可以參考這篇新聞。

參考新聞:

LAE (LINE API Expert) 互動攤位:

LAE (LINE API Expert) 自從在 2018 Q1 宣佈以來,台灣目前也有十一位 LAE (可以去以下網址查詢所有的 LAE )。 經常大家都是遠遠地知道有這些 LAE 的存在,卻一直苦無機會能跟他們面對面的交流。 所以這次趁著 LINE TECHPULSE 的機會,也邀請了 LAE 一起來共襄盛舉。 有看到一個有趣的扭蛋機嗎? 可以看一下由 LAE 陳佳新帶來的文章。

參考文章

LINE PROTOSTAR 互動攤位:

本屆 TECHPUSLE 也邀請到運用 LINE 平台打造應用的10家新創團隊,命題都非常實用有趣,可分為生活助手、娛樂、教育,與金融科技相關的應用。 這邊可以讓各位去一個一個了解每一個新創團隊如何透過 LINE 平台與聊天機器人來發展自己的事業,並且如何透過一些 Messaging API 來讓自己的相關事業能更加活躍。

相關資訊

LINE TECH FRESH 互動攤位:

LINE 台灣工程團隊每年透過 LINE TECH FRESH – 技術新星人才計劃,招募資訊科技相關科系,或對此領域有所涉略的大學生 / 研究生加入 LINE 團隊進行長期實習 (一年期),讓同學們能在國際級科技公司中觀摩學習。LINE TECH FRESH 由經驗豐富的技術專案經理帶領團隊,接觸多元化的專案與產品開發,學習業界實際的軟體專案分工,並體驗跨國團隊合作。往年工作內容包含 server、web、mobile app、chatbot、IoT、data、DevOps 等領域,並透過實習熟悉 LINE 平台系統、SDK、API 等。值得一提的是,LINE TECH FRESH 是有給薪的實習機會,對於軟體開發有熱情、有想法的同學們,千萬別錯過這個揮灑創意與衝勁的機會!

今年除了有三位實習生站上大舞台來分享之外,同學們也有在攤位上面分享他們的實習經驗。讓有興趣了解的同學們也可以一起討論。

相關文章:

展示架(Poster) : 跟 LINE 台灣服務工程師面對面討論架構

此外,今年一共舉辦了三次的 LINE Developer Meetup ,並且有許多次的社群活動邀請到 LINE 台灣產品與工程團隊的開發夥伴來分享。 這些活動之中,也能感受到開發者們對於 LINE 的工程團隊其實充滿著好奇心,想要了解更多,不論是產品服務的架構,還是使用到的相關技術,或是團隊需要的相關技能。

所以我們這次也特定請到工程團隊們製作相關的服務架構或是團隊組成的相關展示架,並且歡迎大家來展示架攤位這裡直接跟工程團隊討論。

這次一共有九個展示架,其中有五個是產品團隊如下,其中有相關的文章可以參考:

  • LINE 熱點
    • 本年相關介紹與技術分享:
      • https://engineering.linecorp.com/zh-hant/blog/serving-location-based-data/
      • 影片 https://www.youtube.com/watch?v=7dNvssRRGBo
  • LINE MUSIC
    • 本年相關介紹與技術分享:
      • https://engineering.linecorp.com/zh-hant/blog/20200923-golangtw/
  • LINE 旅遊
    • 本年相關介紹與技術分享:
      • https://speakerdeck.com/line_developers_tw/20201119-line-travel-introduction
  • LINE 購物
    • 本年相關介紹與技術分享:
      • https://engineering.linecorp.com/zh-hant/blog/line-shopping-app-with-flutter/
      • https://engineering.linecorp.com/zh-hant/blog/line-jcconf-2020/
  • LINE TODAY
    • 本年度相關介紹 :
      • (YouTube) https://www.youtube.com/watch?v=zO9E3qcg99I
      • https://speakerdeck.com/line_developers_tw/20201119-line-today-introduction

另外有四個是工程團隊與組織:

  • LINE QA team
    • 本年度相關介紹 (YouTube):
      • https://www.youtube.com/watch?v=OzL9WTgD1V8
      • https://www.youtube.com/watch?v=kLN1CXhxN70
  • LINE Data Dev team
    • 本年度相關介紹:
      • (YouTube) https://www.youtube.com/watch?v=22MUda6g7Xk
      • (YouTube) https://www.youtube.com/watch?v=MOkqCYNZZSU
      • https://engineering.linecorp.com/zh-hant/blog/line-developer-meetup-11/
  • LINE UIT team
    • 本年度相關介紹 (YouTube):
      • https://www.youtube.com/watch?v=GYDa4wNUyB0
      • https://www.youtube.com/watch?v=PLkTwf_zQmE (英文說明)
  • LINE Client team
    • 本年相關介紹與技術分享:
      • https://engineering.linecorp.com/zh-hant/blog/line-shopping-app-with-flutter/

希望這參與的朋友都當初都有好好的來了解每個團隊,並且也透過跟工程團隊的互動可以有更多的理解。

投影片集錦:

Talks 投影片集錦:

最後,大家對於今年的 LINE TECHPULSE 2020 是否意猶未盡?

快來看看相關的投影片,溫習一下許多嶄新的功能吧。

以下先分享主要 Talk 的部分:

上午議程:

  1. Keynote by Marco Chen https://speakerdeck.com/line_developers_tw/line-techpulse-2020-keynote
  2. Life on LINE CLOVA by Aaron Wu https://speakerdeck.com/line_developers_tw/line-techpulse-2020-life-on-line-clova
  3. Platform API Update by Evan Lin https://speakerdeck.com/line_developers_tw/line-techpulse-2020-platform-api-update
  4. Scaling Machine Learning at LINE by Shawn Tsai and Penny Sun https://speakerdeck.com/line_developers_tw/line-techpulse-2020-scaling-machine-learning-at-line

下午議程 - LINE技術分享講座:

  1. LINE Pay New Service My Card by Hugo Huang https://speakerdeck.com/line_developers_tw2/line-techpulse-2020-line-pay-new-service-my-card
  2. How GitOps Helps
Kubernetes Adoption by Denny Tsai https://speakerdeck.com/line_developers_tw/line-techpulse-2020-how-gitops-helps-kubernetes-adoption
  3. Improve Automated Acceptance Tests through Test Isolations by Bryan Liu https://speakerdeck.com/line_developers_tw/line-techpulse-2020-improve-automated-acceptance-tests-through-test-isolations

更多資訊: https://techpulse.line.me/

閃電秀 (Lightning Talks) 投影片集錦:

閃電秀 (Lightning Talk) 一直以來都是技術研討會最精彩的部分之一。

不光是可以在很多的時間內聽到許多有趣的分享,更可以聽到許多精闢的技術分享與摘要。

這次要分享的就是 LINE TECHPULSE 2019 的閃電秀的部分,本次閃電秀分成三大主題,相關投影片依序如下:

  1. Lightning Talk 1- Agile, frontend and data.
    1. LDS - Sharing UI Components Between LINE Projects by Petr Mareš https://speakerdeck.com/line_developers_tw2/line-techpulse-2020-lds-sharing-ui-components-between-line-projects
    2. Large Scale Scrum (LeSS) Road, Where does it leads? by William Fu https://speakerdeck.com/line_developers_tw2/line-techpulse-2020-large-scale-scrum-less-road-where-does-it-leads
    3. SmartPOI by Johnson Wu https://speakerdeck.com/line_developers_tw/line-techpulse-2020-smartpoi
  2. Lightning Talk 2- Client Development
    1. LINE LINE SHOPPING App with Flutter by Chia-Cheng Chu (Aaron) https://speakerdeck.com/line_developers_tw/line-techpulse-2020-line-line-shopping-app-with-flutter
    2. Efficient Event Tracking Mechanism with Flutter by Kuan Wei Lin https://speakerdeck.com/line_developers_tw/line-techpulse-2020-efficient-event-tracking-mechanism-with-flutter
    3. Android Message Capturing by Jerry Che https://speakerdeck.com/line_developers_tw/line-techpulse-2020-android-message-capturing
  3. LINE TECH FRESH Program
    1. Life as FRESH LINER by Mandy Chang https://speakerdeck.com/line_developers_tw2/line-techpulse-2020-life-as-fresh-liner
    2. My Life in LINE : As a Junior LINER, Senior TECH FRESH by Carolyn Chen https://speakerdeck.com/line_developers_tw2/line-techpulse-2020-my-life-in-line-as-a-junior-liner-senior-tech-fresh
    3. From Classroom Assignment to Realistic Problem in LINE by Troy Chiu https://speakerdeck.com/line_developers_tw2/line-techpulse-2020-from-classroom-assignment-to-realistic-problem-in-line

更多資訊: https://techpulse.line.me/

活動小結

每一年的活動籌辦,都是希望每一個參與的來賓能夠有滿滿的收穫。雖然今年由於疫情的原因,許多線下活動受到許多的限制。但是主辦單位的我們,也是戰戰兢兢希望能提供最舒適與安全的環境下,讓每一位來賓都能了解到 LINE 平台的最新發展, LINE 工程團隊的努力與如何一起加入我們開發的大家族。

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

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

關於「LINE開發社群計畫」

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

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