[研討會心得] LINE Shopping App with Flutter: 使用 Flutter 來打造 LINE 購物的手機雙平台應用

October 29, 2020, 5:00 pm

寫在前面

大家好，我是 LINE Taiwan DevRel 團隊的 Evan Lin。很開心在這裡跟各位分享本年度的第三場開發者小聚中，由 LINE Client Team - Evan Fang 所帶來的分享 - 「 LINE Shopping App with Flutter 」。

KKTIX 活動網頁: 活動網址

活動全文網址： TBD

投影片

演講影片

什麼是「LINE 購物 App」?

(LINE 購物 App 功能介紹)

講者分享如何透過 Flutter 來開發下載榜第一名的「LINE 購物 App」。首先主要提到 LINE Taiwan Client App 團隊主要有負責的產品有:

LINE TODAY 的 App （在印尼有上架）
LINE SDK 也就是大家看得到的開源套件：
- https://github.com/line/line-sdk-android
- https://github.com/line/line-sdk-ios-swift
當然也有協助開發 LINE App 的一些功能。
最新的也就是今天要介紹的「LINE 購物 App」

關於「LINE 購物」的介紹

LINE購物與多家知名購物網站合作，匯集超過2,000萬件商品，只要在搜尋處輸入想找的商品，讓你一個網頁就能一次看各家購物網站的商品資訊和價格，讓你從此不用處處比！透過 LINE購物不僅僅可以一站找到你需要的商品，還可以獲得更多的回饋。

Flutter 打造 LINE 購物專屬 APP

為了提升更佳的使用者體驗，打造更精緻的服務介面，LINE 購物也決定在今年推出了專屬的 APP 。但是希望能快速地到使用者的反饋，並且即時的改善更好的使用者體驗。開發團隊選擇使用 Flutter 作為開發的程式架構，透過 Flutter 可以一次開發出 Android 與 iOS 的應用。而選擇 Flutter 的理由如下:

效能考量:

以整合性設計框架而言，透過 Widget Rendering 可以讓 Flutter 直接在 Canvas 上面操作，具有類似於 Native App 的效能。

快速開發:

單一的 code base 來開發兩個平台的 App。在 UI 元件的開發上，很適合透過 Flutter 使用。可以確保 UI 設計的一致性，讓使用者有相同的使用體驗。

Flutter 支援 Hot reload 可以在 IDE 上面只重新編譯更新的部分，能夠快速的看到變更的成果。

豐富的開發資源:

豐富的官方導覽教學，還有 Dart Devtool 與 pub.dev開發資源可以參考。

最後成果

最後的成果也相當的亮眼，使用 Flutter 可以在三個月之內於 iOS 與 Android 平台上完成一致性的使用設計體驗。並且獲得當月份的下載量第一名的肯定。

遇到的問題分享

當然在使用 Flutter 開源套件也會遇到一些問題，但是 LINE 開發團隊也有跟 Flutter 團隊回報並且溝通相關的問題。目的希望能讓套件更完善，也能讓產品更符合使用者期待。以下條列式一些問題:

問題： Flutter 在 Android 上無法變更鍵盤語言
- 解法:
  - 使用 Hybrid composition 並且更新 Flutter 到 1.22 版本之後。
問題： Hybrid composition 在某些狀況下會 crash app
- 解法：
  - LINE 提供相關解法與完整複製流程，並與 Flutter 團隊共同解決。
問題：在可以上下滑動的頁面呈現大量UI元件時，滑動時經常有記憶體不足的問題。
- 解法：
  - 修改讀取方式，僅使用者看到的部分(Viewport)會使用記憶體。釋放不在 Viewport 的UI元件資源。

小結

講者也分享了，目前 Flutter 很適合開發在不複雜的頁面。具有較高的效能，快速迭代與開發的工具，還相當的容易學習。但是如果需要開發比較複雜的頁面時，需要有能力追蹤到底層套件的原始碼，發生問題的時候才能夠解決。

最後也希望大家一起來下載一下 LINE 購物 App 感受一下 Flutter 開發出來的效能吧！！

↧

[好書分享] 慢老

November 5, 2020, 4:00 pm

≫ Next: [LINE FRESH 2020] 2020/11/14 LINE FRESH 2020校園競賽黑客松組活動紀錄

≪ Previous: [研討會心得] LINE Shopping App with Flutter: 使用 Flutter 來打造 LINE 購物的手機雙平台應用

慢老 - 改變對減肥、運動、睡眠的觀念，從日常養成保持活力不顯老的習慣
作者： 黃惠如  攝影： 林宗億  出版社：天下雜誌出版 
出版日期：2019/01/23 

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

前言:

這一本是今年所讀完的第十一本書。

其實我看書的習慣，一次同時會看至少三本書。通常是一本跟自我成長比較有關的書，一本放鬆的書（比如說：崩壞國文：長安水邊多魯蛇？唐代文學與它們的作者），或是一本傳記或是其他類型的書。這一本就是我跟賈伯斯傳一起在慢慢的的一本書，不過當然因為這本的內容比較精簡，所以一下就看完了。

當初會買這本書，好像也是讀墨的電子報還是文章推薦的樣子。裡面推薦到一些如何保養身體並且讓身體活動力能夠持續維持高效能的方式。所以就買了這本書來翻，發現許多概念其實很值得分享的。

內容簡介與心得:

怎麼吃、怎麼動、怎麼睡、怎麼想，決定你老得快或慢。
最新科學研究，幫你建立40歲後的新習慣，慢慢老。

科學研究有了新突破，找出老化的關鍵就是在基因末端像保護套的端粒，如果繼續磨損變短，就會老化。好消息是，端粒會聽從生活方式的指令而改變，我們每天怎麼吃、怎麼動、怎麼想，可以影響端粒長短。換句話說，我們自己可以決定老得快一點或慢一點。

那該怎麼吃、怎麼動？科學研究也有了新發現，改變過去的觀念。不吃油、每次運動不可少於30分鐘，都是該淘汰的舊觀念。20歲時忌口保養，到了40歲後，可能變成讓你顯老的錯誤。

慢老，是可以學習的生活習慣技術。

章節條列

PART 1　運動：一定要動，離開椅子都算數 PART 2　飲食：體重真的不是重點 PART 3　睡眠：定時上床、起床比睡多久重要 PART 4　防病：提早預防，縮短抱病壽命 PART 5　生活：慢老的日常，從改造環境開始 PART 6　情緒：就是這些個性讓你顯老後記　老化不可逆，但我們可以老得好

慢老這本書一開始從運動說起，畢竟現在人說的老化其實不是身體的年齡，而是目前身體的活動力。也就是如果～你雖然年紀到了五六十歲，但是還是健步如飛，還是能夠從事基本的運動項目。這樣來說～你還不是「老化」，反過來，如果因為身體的運動量不足，或是長期臥床造成肌肉萎縮，那麼身體的老化是更加的劇烈。更別說，臥床的老化還會伴隨著腦袋的老化。

第一章節提到運動的時候，重點在於有效的肌力訓練。長期的走路往往對身體負擔更大，不如有效的肌肉鍛鍊。裡面也有附上一些圖片，指導一些抓住短暫時間的放鬆與肌肉訓練。

第二章節就是提到飲食的重要，也是我近幾年不斷在施行的部分。除了少糖之外，對於蔬菜的攝取量也是在於儘量多吃青菜，而非少吃其他必要的油脂部分。

第三章節提到了如何睡得好，裡面也提到睡前看手機對於身體的影響。除了會減緩退黑色素的細胞做用之外，也會讓自己的睡眠品質降低。

第五章節則提到該如何透過一些習慣來讓自己預防老化。比如說流汗，比如說培養興趣來避免退休就會失智的風險。

第六章節則是從情緒來控制老化，憂鬱與煩惱是老化的主要加速器。所以如何讓自己的心智從抱怨與煩惱中改變成樂觀的態度來讓自己更快樂。

心得:

其實手邊還有一本類似的實體書「抗老化，你需要大重量訓練」，當初兩本書是一起買的。想要從肌肉訓練與身心調養方面來讓自己更能夠減緩老化的速度。（一直很驕傲說～身體有練到年輕約十歲左右）。

這本書有不少從營養層面帶來的新的常識，並且透過定期（有效）運動，與精簡的飲食來讓自己活得更健康。蠻推薦大家可以看看～檢視自己的養生態度是否有任何不正確的地方。

↧

[LINE FRESH 2020] 2020/11/14 LINE FRESH 2020校園競賽黑客松組活動紀錄

November 13, 2020, 4:00 pm

≫ Next: [好書分享] 零規則-高人才密度x完全透明x最低管控

≪ Previous: [好書分享] 慢老

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

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

競賽主題

而「黑客松」組的競賽主題如下: LINE 一直致力透過「生活方式的革新」，打破線上、線下隔閡，發展出更實用、更便利的平台與服務，提供用戶全方位的使用體驗。請發揮想像力與創造力，打造一個實用及趣味兼具的全新LINE服務項目或應用方案，抑或者提出對現有LINE服務的優化建議範本。

詳細規則與辦法可以參考以下由筆者一同拍攝的影片（羞

活動流程

在此也將本次競賽流程記錄在此：

07/15 報名活動開始
09/30 初賽報名截止
10/21 決賽隊伍公布
10/31 決賽導師會談
11/14 決賽與頒獎典禮

導師會談

其導師會談活動內容為，決賽的參賽隊伍當天到 LINE 辦公室接受資深 LINE 的導師們指導。透過開發層面，開發經驗與相關技術的討論與咨詢。

當天的業師也都是精選個團隊的資深工程師，包括了「LINE 熱點」,「LINE 購物」，「LINE Today 」，「LINE 分眾+」與資料工程團隊的資深工程人員。

當天也透過資深的業界導師們個別的指導，讓學生們對於整體產品的概念更加的熟悉，並且知道如何發揮自己產品的優點，一同打造出更令使用者驚艷的產品服務。

決賽當天

決賽當天的活動流程如下:

09:00 ~ 09:15: 開幕典禮與技術長致詞
09:15 ~ 12:30 Hacking
12:30 ~ 13:30 Lunch
13:30 ~ 14:00 Guess and Game
14:00 ~ 14:30 Preparing
14:30 ~ 15:30 Presentation
15:30 ~ 18:00 Break
18:00 ~ 18:30 Award

開幕主持

這次的決賽主持由筆者負責，雖然開場時間是 09:00 但是同學們都相當的熱情參與。讓工作同仁們都感到相當期待決賽的成果表現。

技術長致詞

「任何生活中的小痛點往往都是強大商業契機的解決方案」，LINE 台灣技術長 Marco Chen 在致詞的時候就是這樣鼓勵每一位參賽的同學。許多的生活中的小痛點，都會是每一個黑客松的好點子。這也是為什麼 LINE 台灣每年都有舉辦內部員工黑客松競賽的原因，我們相信，許多同仁的痛點往往也會是改變世界的好點子，並且也會是增進工作效率，促進同仁間合作的契機。

比賽最重要的是

開幕的時候，曾經有問台下參與的同學。「參加黑客松最重要的是什麼？」，同學們不約而同地大喊著，就是食物。當然作為「LINE FRESH 2020 校園競賽- 黑客松組」，由於同學們還需要打起精神做最後的準備，當然食物的準備都沒有少。源源不絕的小點心與咖啡可以刺激同學們的精神。

猜謎小活動 (Guess and Game)

在 LINE 台灣所舉辦的黑客松競賽中，有著一個有趣的傳統就是會有猜謎小遊戲。(參考 LINE Taiwan Internal Hackathon 2020) 內容就是透過一連串的有趣謎題的猜謎，來舒緩參賽者們緊張的情緒，也可以讓每一位同學更有精神的面對下午令人緊張的決賽報告。

題目的類型也相當的有趣，比如說: 「熊大本身的嘴巴哪一邊比較長？」「Sally 是雞還是鴨？」。每一位參與的夥伴都相當的熱情，也能感受到大家的緊繃的心情也能獲得舒緩。

獲獎隊伍簡介:

評審特別獎 - Study Cat

以創新整合應用服務，解決待辦事項欠缺有效管理、生產力低落的痛點。

評審特別獎－LINE LABEL

期許改善台灣資訊業中，資料標註人力成本過高問題的狀況。

第三名：隊名：春芽冷露加珍珠作品： InsurTech+ 智能保險導購平台

成員：

臺北科技大學-企管學系-曹明瑾
臺北科技大學-資管學系-盧淇筠
臺北科技大學-資管學系-游家和
臺北科技大學-資工學系-黃暉翔

作品簡介：

台灣民眾對於寵物飼養意願日漸提高，不過觀察飼主為寵物投保的意識較低，提案為現行保險業開拓智慧數位通路，以AI提供貼近顧客需求的保險服務，也讓寵物獲得保障。

### 第二名：隊名：哥老的愛作品： Crown Eye

成員:

台灣大學-會計學系-王重程
台灣大學-土木工程-陳霖家
翁挺瑋
陳韋同
陳韋晴

作品簡介：

視障者對於周遭環境感到陌生，或在戶外需要他人協助時，可透過LINE解決當下所遇到的問題，並降低對周圍環境的不安全感。

第一名：隊名: LINE Premium 作品： LINE Medi

成員:

台灣大學-經濟學系-許毓翔
台灣大學-經濟學系-游子慧
台灣大學-資工學系-宋易軒
台灣大學-資工學系-蔡青邑

作品簡介：

打造全新服務「LINE Medi」，目標透過此服務讓用戶建立個人的健康資訊，並為LINE建構一個健康管理的平台。

活動小結

首屆的 LINE FRESH 校園競賽在 11/14 舉辦決賽暨頒獎典禮之後劃下完美的 ending，這次競賽商業行銷組共有 16 組隊伍、黑客松組共有 10 組隊伍熱情參與。透過這次的競賽活動，希望帶給各位同學的是更多與 LINE 合作交流和實務經驗上的傳承，以及擦出創意火花的美好回憶。更多「LINE FRESH 2020 校園競賽」詳細官方報告，歡迎查看【LINE FRESH】2020校園競賽獲勝隊伍出爐！

關於 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 是有給薪的實習機會，對於軟體開發有熱情、有想法的同學們，千萬別錯過這個揮灑創意與衝勁的機會！

加入官方開發社群

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

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

關於「LINE開發社群計畫」

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

徵才訊息

《LINE 強力徵才中!》與我們一起 Close the Distance 串聯智慧新世界 » 詳細職缺訊息

↧

[好書分享] 零規則-高人才密度x完全透明x最低管控

November 16, 2020, 4:00 pm

≫ Next: [TIL][Golang] Type Parameters in Golang 初體驗 (a.k.a Go2 Generics)

≪ Previous: [LINE FRESH 2020] 2020/11/14 LINE FRESH 2020校園競賽黑客松組活動紀錄

零規則-高人才密度x完全透明x最低管控，首度完整直擊Netflix圈粉全球的關鍵祕密
NO RULES RULES
作者： 里德．海斯汀、艾琳．梅爾  
原文作者： Reed Hastings、Erin Meyer  
譯者： 韓絜光  出版社：天下雜誌出版 
出版日期：2020/10/28 語言：繁體中文 ISBN: 9789863986102

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

前言:

這一本是今年所讀完的第十二本書。

必須得說這本書大概是今年年底被強力放送的一本書（至少對我而言），不論是網路新聞評論，或是各種媒體上面都有廣告。但是最近在上 OKR 訓練課程的時候，又被講師打了一次，完全就忍不住買下來看。結果又是三天之內每天都在認真地翻閱，沒多久就看完了。

很推薦每一個做 Developer Relations 的人可以看一下，尤其是有做 Tech Hiring 相關事項或是有大量招募需求得公司團隊都需要了解，不論你是 HR 還是 Hiring Manager 。

內容簡介與心得:

Netflix創辦人暨執行長海斯汀（Reed Hastings）第一次公開他的經營心法，更打開大門邀請INSEAD歐洲工商管理學院教授梅爾（Erin Meyer）進入Netflix內部研究、訪談超過兩百位員工，兩人一起以對話形式解析Netflix看似沒有流程管控的「自由與責任」文化，提煉出Netflix能快速反應、持續創新的三大運作原則：

高人才密度才有最優戰力：混亂中要是業界最強者才能因應、創新。公司不是家庭，而更像職業球隊，高手同隊才能彼此刺激進步。對冗員零容忍，討厭鬼、懶鬼、濫好人都無法生存，淘汰平庸，少數優異者的績效與熱情都會更高。

絕對誠實養出信任與進步：犯錯不可怕，不知錯才是高風險。回饋列為會議表定流程，用善意誠實回饋、幫彼此從優秀變傑出，才夠格成為團隊一份子，大聲認錯、小聲慶祝。訊息公開曬在大家眼前，全員讀財報，大家都是共同承擔的一份子。

高度授權，效率與彈性優先：要快速創新，當責很重要。員工應該是能負責的大人，沒有服裝規定也不會有人裸體上班。充分資訊、安心授權，幫助每個人勇敢下賭注，建立「以公司最大利益為考量」的共識，分散決策，更能養成創業家精神。

章節條列

第一部　開始邁向自由與責任的文化

第一個章節相當的有趣，就是先講解出頂尖的人才的特點：「想要跟一群頂尖的人才一起工作」。如同 Google 受到高科技人才的喜愛一樣，除了相關的福利水準外，主要就是裡面有許多知名的高手在裡面。

有了頂尖的人才， NETFLIX 開始的就是給予適度的責任，並且開放適度的自由。也就是減少控制，畢竟頂尖人才不是不懂規則，並且不喜歡被規範。不論是告訴內部所有員工相關的訂閱數字，卻不擔心員工們會內線交易。（並非內線交易不會有問題，而是事先告訴員工這是違法的）。

第二部　加速推展自由與責任的文化

拿出業界最高的薪資，並且決策不需要向上匯報。在NETFLIX 的想法中，員工請來是要協助上級處理事項，而非事事匯報。需要簽約的時候，只要最高原則「一切都是為了 NETFLIX 的利益」也不需要報告到總經理，可以自己簽約。這樣對於頂尖的員工來說，也是一種責任，也是一種成就。可以加速組織的成長，讓組織的決策更加的快速。對於 NETFLIX 來說，請來的員工在他的負責領域，應該是最了解與清楚的。如果不能信任給予他簽約的權力（與責任），那麼是否就是雇用到不正確的人？

第三部　持續深化自由與責任的文化

特殊的用人邏輯「留任測試」

「留任測試」是一個 NETFLIX 雇用人的核心，也是頂尖人才的招募準則。

定期思考，如果你團隊中某個人明天就提離職。

你是否會說服他改變心意？
你會願意拿出更多薪資來留任他？

如果以上兩個答案，都是否。 NETFLIX 的準則就是你應該立刻解僱該為員工。因為他表現「不夠優異」。

這個點很特別，許多講求「家庭」概念的企業。透過的“犯錯”來處罰與解僱員工，於是員工害怕犯錯而不敢創新，讓企業慢慢的走向失敗。但是 NETFLIX 對於公司同仁，不是「家人」而是隊友。大家來公司就是來工作，就是來追求成長與足夠良好的待遇。因為是隊友，所以會要求彼此更加進步，因為是隊友就算隊友犯錯，為了求勝會馬上填補而一起繼續前進。

所以當你犯錯的時候，NETFLIX 不會解僱你，但是會要求你攤在陽光下好好檢討並且思考出改善的方式。如果對於同事有不同的意見，他們表達的方式就是「當你想講同事的事情，請假設他就在你前面，並且務必用一樣的話語當他面前再說一次」。除了可以杜絕打小報告風氣，更可以讓雙方都有成長與接受改善的空間。

沒有獎金制度

這點也相當有趣，NETFLIX 任何一個員工維持「高效能」是應該的，是不需要獎勵的。反之，如果員工沒有維持著高效能，那麼依照著「留任測試」是否應該要資遣他，透過他的薪水來找到更高效的員工？

第四部　NETFLIX文化走向全球

最後一個章節探討的是如何透過「零規則」這一種信任模式的管理方式來走向全球化管理。畢竟在許多國家中，類似的管理風格是不曾發生過的。這邊也探討，所謂的「零規則」並非適用於所有的企業，如果你的企業本質不能發生任何錯誤（比如說資安，金融相關體系」，這樣的話「規則」是不可或缺的。透過規則的設定，可以讓每一個員工依照規則來做事，確保不發生任何意外，當然也就沒有所謂的創意。

如果你的企業是倡導創意與高產值的腦力產業，那麼你需要擁抱失敗，並且屏棄平庸。這樣才能讓你的企業走得更長久，進而全球化。

心得:

這本書真的有打破我的許多舊有的觀點，讓我來依序條列出來：

「留任測試」這個想法真的很有用，雖然先不想我所處的產業我是不是類似 NETFLIX 拿了產業中最高的薪水。但是我經常在思考的就是，如果我哪一天提了離職，老闆們會不會為了為了把我留下不惜加我薪水？書上有提到，薪水自己提出來的。就像獎金制度一樣，維持著高績效的表現，是你對於你薪水的付出。反之，若是沒有高績效表現，公司也應該要拿著你的薪水去尋找更高績效的競爭者。（如果存在）。

雖然說許多企業都是根據「相同工作能力所支付的最低費用」方式來雇用員工。也就是同一份薪水，只要能找到「足夠用」的員工即可。這樣的方式讓許多企業都不具競爭力。加上了「避免犯錯」的錯誤迷思，讓許多公司內的員工，往往都是「不要做錯就好」，只願意做好自己手上該做的事，剛剛好也不會挑戰更高的成就。

這些東西往往再創意公司內是相當危險的，許多的員工是否能依照著「留任測試」來思考自己是否具有相當的競爭力。反過來，也應該思考如果老闆不願意留下你，是因為你真的表現不好？還是他沒有感受到你的付出。如果是後者，你要檢討你的努力方向，如果是前者應該要反思為何老闆有這樣想法。

另外一個角度，NETFLIX 也歡迎員工跳槽，甚至是歡迎接獵人頭的電話。第一句話往往應該就是，你那邊的薪水有比這邊還高嗎？如果是的，代表你應該跟你老闆去爭取更高的薪水。這是 NETFLIX 中唯一可以調整薪水的方式（在沒有升遷狀況下）。

不過回過頭來，想到許多工程師或許只看到「薪水高」這件事情。看到福利好這件事情，卻沒有思考過自己是否有成為「頂尖人才」的決心。是否有認真把公司當作球隊一樣看待，不是把同仁看成家人容忍墮落，容忍同仁放鬆。應該要一起鼓勵來戰勝其他球隊，爭取總冠軍才是。

真的寫了很多，這本書雖然是 NETFLIX 拿來招募人才用。但是也適合每一位作為人才招募與啟發員工潛能的人了解。或許，認真把同仁當成球員。找到「頂尖人材」讓他們充分發揮，才是正確的道路。

但是薪水待遇夠高的人，是否還需要 DevRel 來協助相關的工作？這點讓我放在腦袋裡好好的思考！

↧

[TIL][Golang] Type Parameters in Golang 初體驗 (a.k.a Go2 Generics)

November 29, 2020, 4:00 pm

≫ Next: [研討會心得] 在 LINE 熱點服務上如何處理地理性資訊

≪ Previous: [好書分享] 零規則-高人才密度x完全透明x最低管控

前言:

Generics (泛型)一直是 Golang 這個程式語言比較受到 C++ 與 Java 轉過來的開發者們經常訓問的問題。這個問題不僅僅算是經常被語言戰爭中主要的攻防端，更有許多發了需求要加入 generics（參考) 。這邊幫大家整理一下與嘗試一下最新版本的 Go2 到底 Generics 狀況如何了。

感謝 TG 上面討論的網友提供的鏈結，試玩一下 Go2 Playground 並且看了一下 Type Parameters 的 proposal 變更後，寫了一下心得。大家可以玩玩看，一起來更了解一下 Type Parameters 的提案內容。

我得了一個重大活動前，就很想要寫程式或是讀 Spec 的病。投影片明明在等我

為何程式語言需要 Generics

Generics (泛型)

泛型程式設計（generic programming）是程式設計語言的一種風格或範式。泛型允許程式設計師在強型別程式設計語言中編寫代碼時使用一些以後才指定的類型，在實例化時作為參數指明這些類型。

(來源： wiki)

也就是說，在強型態程式語言中，因為型態都必須去先給與。撰寫 function 的時候很難將型態加以抽象畫。讓型態可以事後在套入。拿個簡單的例子來說，根據文章 “Why Gnerics” 曾經舉過這個很棒的範例。先假設你需要將一個 slice 裡面所有元素從小到大來排序。

根據 Int 你可能會寫:

func ReverseInts(s []int) []int {
    first := 0
    last := len(s) - 1
    for first < last {
        s[first], s[last] = s[last], s[first]
        first++
        last--
    }
    return s
}

而如果是字串的時候，可能如下：

func ReverseInts(s []string) []sting {
    first := 0
    last := len(s) - 1
    for first < last {
        s[first], s[last] = s[last], s[first]
        first++
        last--
    }
    return s
}

根據以上的方式，你會發現兩個 function 其實真的沒有任何的差異。但是卻由於資料格式不同，需要特地用兩個 function 分開來撰寫。這樣對於維護上往往不直覺，以後發現其中可以優化或是有問題的時候，就一次需要把所有用到型態的程式碼都一起維護，相當的不直覺。

在 Type Parameters 之前Golang 沒有其他替代方案嗎？

先不談 Generics ，其實 Golang 可以透過 Interfaces 的方式來做相關的開發，這裡是相關的實作方式。先來解釋什麼是 interfaces :

Interfaces are named collections of method signatures.

(Refer: Go by Example: Interfaces)

根據這個範例可以簡單瞭解 interfaces主要用法。那為人所熟悉的應用方式是什麼呢？就是 sort.Sort()

package main
 
import "sort"
import "fmt"
 
type ByLength []string
 
func (s ByLength) Len() int {
    return len(s)
}
func (s ByLength) Swap(i, j int) {
    s[i], s[j] = s[j], s[i]
}
func (s ByLength) Less(i, j int) bool {
    return len(s[i]) < len(s[j])
}
 
func main() {
    fruits := []string{"peach", "banana", "kiwi"}
    sort.Sort(ByLength(fruits))
    fmt.Println(fruits)
}

透過 sort.Sort()的 function，你可以套入 int或是 string的排序方式，甚至你可以為了自定義的 struct 定義自己的 Len()， Swap()與 Less()之後就可以套用 sort.Sort()。當然其實也有 Go generation ， reflection 等等方式也是可以使用。這裡就不再詳述，歡迎大家參考延伸閱讀。

衍伸閱讀

Who needs generics? Use … instead!

Golang Generic Proposal 介紹影片:

以下有根據 Golang Generics Proposal 的敘述投影片，請注意這是第一個版本 (2019/07) 的 Generic Proposal ，裡面還是使用 Contract 的方式來實現 Type Parameters 。但是這個部分在之後已經修改成 interfaces來讓語法比較清楚。必須得老實說，當初 Contract 出來的時候，我真的也搞不太懂 contracts 跟 interfaces的差異。

What happened to contracts?
An earlier draft design of generics implemented constraints using a new language construct called contracts. Type lists appeared only in contracts, rather than on interface types. However, many people had a hard time understanding the difference between contracts and interface types. It also turned out that contracts could be represented as a set of corresponding interfaces; there was no loss in expressive power without contracts. We decided to simplify the approach to use only interface types.

https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md

試玩 Go2 Playground

就讓我們來透過 Go2 playground 提供的 Type Parameters 來回頭看我們原本的問題。是否有方式可以透過 Type Parameters來實作呢？

馬上來看結果: https://go2goplay.golang.org/p/doitUP4_1Jm

func ReverseSlice[T any](s []T) []T {
	first := 0
	last := len(s) - 1
	for first < last {
		s[first], s[last] = s[last], s[first]
		first++
		last--
	}
	return s
}

func main() {
	fmt.Println(ReverseSlice([]string{"Hello", "playground"}))
	fmt.Println(ReverseSlice([]int{1, 3, 5}))
}

Type Parameters加上限制

使用 any Type Parameter 其實相當的方便，但是往往取決於你可能處理的資料並不適合所有的型態的時候。其實需要加上一些資料的限制。舉個例子來說明：

範例：兩個參數取比較大的

	if a < b {
		return a
	}
	return b

這是一個相當簡單的比較方式，但是可以看到如果將這個方式透過 Type Parameters 來撰寫。會發現輸入的參數將不支援 string ，所以需要以下的相關修改。

https://go2goplay.golang.org/p/9BgTT0hCgD7

type numeric interface {
	type int, int8, int16, int32, int64, uint, uint8, uint16, uint32, uint64, float32, float64
}

func min[T numeric](a, b T) T {
	if a < b {
		return a
	}
	return b
}

func main() {
	fmt.Println(min(42, 84))
	fmt.Println(min(3.14159, 2.7182))
}

小結論：

Type Parameters 與 Go2 Playground 其實還在開發中，使用上也沒有那麼直觀與好用之外，可能還有一些 bugs 。不過真的很期待使用 Type Parameters 讓開發上可以真正將演算法與型態脫鉤，讓 function 能夠更簡潔。

Golang Blog: 2019/07/31 “Why Gnerics”
Golang Blog: https://blog.golang.org/generics-next-step
Type Parameters in Go https://go.googlesource.com/proposal/+/master/design/15292/2013-12-type-params.md
https://groups.google.com/g/golang-dev/c/U7eW9i0cqmo/m/-gDfa_6KAAAJ?fbclid=IwAR27mCQ8vgV9w8A201SlLMkyTnWJbfKVBoVRFutGU1zt1_KOCib9pVeQSMs
Type Parameters Draft Design in Gohttps://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md
Go2 Playground https://go2goplay.golang.org

↧

[研討會心得] 在 LINE 熱點服務上如何處理地理性資訊

December 2, 2020, 4:00 pm

≫ Next: [好書分享] 發掘你的微細領導力 (This Is Day One)

≪ Previous: [TIL][Golang] Type Parameters in Golang 初體驗 (a.k.a Go2 Generics)

寫在前面

大家好，我是 LINE Taiwan DevRel 團隊的 Evan Lin。很開心在這裡跟各位分享本年度的第三場開發者小聚中，由 LINE SPOT Team – Julian Shen 帶來分享他在處理地理資料 (location-based data) 時候所遇到的一些問題與經驗分享。關於LINE SPOT可以參考 Julian 在 TECHPULSE 2019 的會場有介紹過關於 LINE SPOT 服務介紹。。更多的 LINE SPOT 服務介紹與 LINE SPOT 架構介紹可以參考這篇文章「LINE TAIWAN TECHPULSE 2019 科技盛會精彩回顧」。

KKTIX 活動網頁: 活動網址

其他相關文章：

投影片

演講影片

地理資訊服務 Location-Based Services

這次主要介紹 LBS: Location-Based Serivice 的內容，關於 LBS 相關的遊戲或是服務我們經常可以看到，舉凡打卡，地圖，導航都會用到。那麼要尋找兩個點之間距離上，可以使用的技術也相當的多。

找出距離幾公里的景點

處理上面經常是拿到 GPS 座標，或是直接拿到地址。地址是可以方便人類來閱讀的，但是真正要電腦能夠處理的就是經緯度的座標位置。如果要對某一個座標找尋出距離三公里距離的所有座標，那是不是需要把資料庫裡面的地點全部拿來計算呢？這裡介紹了一種方式叫做 K-D Tree 。

K-D Tree 的方法就是將地圖平面透過二分法的方式來切割，將每兩個點找出距離後作為一個區塊。透過這樣的方式可以很快速地找出兩個最相近的距離點。

如何將搜尋結果作 Caching

如果有一群人同時開 LINE SPOT需要尋找三公里內所有座標，那麼有方式可以快速的暫存起來資料，並且快速的回覆使用者的需求嗎？這時候可以考量使用 Hashing 的方式來將經緯度數值直接轉換成一串文字，透過這個方式可以快速找到上一次搜尋的結果。如果沒有搜尋過才去跑 K-D Tree 的搜尋，這樣一來就可以在不經過複雜的運算就可以快速的回覆使用者。

這個方式雖然可以快速地知道有沒有搜尋過，但是有一些問題如下：

由於採取 zig zag travesal 的方式來 hashing ，可能不同的經緯到有相當相似的結果。
可能相當的接近，由於在邊界上可能造成 geohashing 結果不同。

其他的方式

Google 也有提出 S2 Cell ID 的方式來區分地理資訊。而 Uber 也有提出 H3 的方式，透過六角形的方塊來切分整個地理資訊。也因為使用六角形，才能更精確地將地球球形的地理狀況表現出來。

「LINE 熱點」美食推薦

別再說新竹市美食沙漠， LINE 熱點也是有精選「十家新竹在地美食店家」。

活動小結

希望同學們了解地理資訊的處理經驗分享後。也都可以來 LINE 熱點來分享你的新竹美食地圖。

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

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

關於「LINE開發社群計畫」

↧

[好書分享] 發掘你的微細領導力 (This Is Day One)

December 3, 2020, 4:00 pm

≫ Next: [好書分享] 韓國人和你想的不一樣

≪ Previous: [研討會心得] 在 LINE 熱點服務上如何處理地理性資訊

發掘你的微細領導力: 運用「第一天」模式覺察自身價值，成為更有分量的人
This Is Day One : A Practical Guide to Leadership That Matters
作者： 卓杜立  
原文作者： Drew Dudley  
出版日期：2019/10/03

買書推薦網址：http://moo.im/a/7afCJN)

前言:

這一本是今年所讀完的第十三本書。

是否一定要是身為管理階層才需要學習領導力？不論是領導力還是影響力，代表的就是你如何透過你自己的行為來影響其他的人。很多時候，每一個人或多或少都在別人的生命中影響著其他人。這些影響力是如何造成，你的生命中又曾經被多少人影響過？這一系列的問題引導著你，很適合透過這一本書來仔細思考。

內容簡介與心得:

請記住以下這句話：你對周遭的人、所屬組織發揮的最大影響力，幾乎都是日常無心插柳的意外結果。

大多數人把領導力想得過於狹隘，認為自己既沒做大事，也不在高位，需要有財富、頭銜及影響力等外在光環加持才能算是領導人。然而這種能力其實人人都有，甚至天天都在實際運用，只是肇因於陳舊思維與教育洗腦，矮化了自己的重要性與領導能力。

宏觀來看，其實職場或人生中的每段旅程（例如戒酒、保持身心健康、乃至創業成功等），都需要領導力的加持。曾是個學霸並遵循世俗成功標準與期望而活，也曾深受酒精、肥胖與躁鬱症所苦，領導力專家卓杜立在改變自己的過程中，發現了「第一天」領導哲學，也就是做每件事都要保持「第一天」的積極心態，便能持之以恆地落實個人的核心領導力價值，引領自己做出改變，進而影響他人。

章節條列

第一部　就從這一天開始

是否記得你的第一天上課，第一天上班？想要透過哪些行動舉止來讓其他人知道對於工作的態度？這邊提的是個人領導力，也就是你可以透過你自己的行為與態度來影響你周圍的人。

你不太需要很高的職位，或是很大的舞台。很多時候就是做好自己，或是「多做一點」就能夠展現個人的領導人，進而影響別人。裡面提到公司車機的例子：

一位在自己崗位職守數十年的小學公車司機，有一天載到一位 22 歲的年輕人。他好奇的問了那位年輕人為何上車，他卻回答說：「我明年要去讀哈佛大學研究所，我想要感謝你，因為你喜歡在開車的時候唱歌，不論小學生們如何笑你，你還是樂在其中的每天唱歌。你讓我深信，不需要在意其他人的眼光，努力做自己」。

第一天就是你想要改變自己的第一天，想要影響其他人的第一天。因為第二天往往是第一天的延續，於是這個章節探討得是你會如何在這個「第一天」發揮你的影響你，來影響其他的人。

第二部　領導力的六個關鍵價值

這個章節，作者透過領導力的六個關鍵價值，來讓你思考個人領導力的具象話與價值所在。透過你每一天去詢問自己以下的六個問題，你能夠逐漸建立起自己的微領導力。

影響力(Impact): 我今天做了什麼樣的事情，來影響其他的人?
勇氣(Courage):我今天做什麼有不一定很有價值，但是放手一博的事情？
給力(Empowerment): 我今天做了什麼事情讓其他人更接近目標?
成長(growth):今天做了什麼可以幫助其他人學習？
格調(class): 今天做了什麼能提高而非升高對立狀況？
自重(self-respect): 做了什麼事情來善待自己?

第三部　你如何定義你自己

對於定義自己這一段，作者先建議提出以下三個方式：

「假設性的關鍵價值」
- 假裝有個人跟在你身旁，那麼一個月後他會認為你這個人有哪些特質。比如說「扛責」，「冒險」，「紀錄」…
你的「床邊建議」
- 如果今天是你的兒子（女兒）即將要去外地讀書，獨立自主了。那麼你會給予哪些人身建議呢?
最優與最差
- 回顧自己人生，找出目前為止表現得最好與最差的狀態。

以上這些問題，不僅幫助定義你自己。更可以幫著你了解自己的長處與優點。進而找出自己適合影響其他人的特質來幫助其他人。

心得:

這本書當初也是因為讀了某些片段後，呼應起自己生命中的一些過程。曾經我們也是被某些人或是某些事所影響到，當然我們也有可能影響其他的人。在這裡分享兩個我印象很深刻的事件。

「現在做這些有什麼意義」

我的第一份工作是在外商（美商）工作，是做多媒體播放軟體的產品工作。因為大環境的變遷，產品不停萎縮的狀況下，公司最終裁員。還記得裁員公告一公佈的當天，我心情雖然很差，但是還是想把自己手上的工作做到完。這時候去找同專案的同事討論的時候，得到的卻是:

「現在做這些還有什麼意義？」
「現在做這些還有什麼意義？」
「現在做這些還有什麼意義？」

我當下其實相當的震驚，之後我默默地走回座位。然後告訴我自己，我決定要堅持自己想要做，或是應該做的事。不論大環境如何的變遷，我們不應該在那個時候就認輸。

「但是，我就是過不去啊」

一樣是在第一份工作給予我的啟發，當時正在管理著 OEM 的專案。雖然產品接近萎縮，但是還是發生了問題。這時候去問了當時的老闆應該要怎麼回覆客戶？只見他，雖然很想回家。但是還是說出了讓我印象很深刻的一句話。

我也是可以就這樣過去，不理這件事情。 但是我就是過不去啊！

也是這件事情之後，我更了解到。「人生，有所為，有所不為」。我們的堅持與固執，造就了我們人格的特質。每個人都會放棄，都會想得過且過。但是真正的堅持與固執才能成就我們，也希望這些小故事能夠影響正在看這篇文章的你。

每個人都會影響其他人的，希望我們都可以帶給身邊的人正向的影響。

↧

[好書分享] 韓國人和你想的不一樣

December 9, 2020, 4:00 pm

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

≪ Previous: [好書分享] 發掘你的微細領導力 (This Is Day One)

韓國人和你想的不一樣
人妻太咪的韓國有趣文化 × 特殊習慣 × 超妙生活觀察
作者： 太咪  出版社：時報出版 
出版日期：2014/08/25 

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

前言:

這一本是今年所讀完的第十四本書。

我說過，我通常會一本嚴肅的書跟著一本輕鬆的書來調劑身心。跟韓國與日本同事在溝通的時候，雖然除了語言本質之外，會發現其實大家的文化上差異真的很大。這本書就是買來讓我更了解韓國同事，也希望不要踩到一些文化上的雷。

內容簡介與心得:

瘋韓劇、追偶像、學韓文，也要了解韓國人的一切；
對韓國有成見？也許你對他們有些誤會！
太咪帶你深入日常生活，從此對他們瞭若指掌，
就算第一次走跳韓國也能立刻上手！

章節條列

Chapter 1　走跳韓國！食衣住行實用指南
Chapter 2　現實就像韓劇一樣浪漫嗎？
Chapter 3　第一次融入韓國就上手！

第一章節有許多跟韓國食衣住行有趣的經驗分享，包括了韓國鐵筷子的由來。韓國的泡菜湯不是拿來喝的，是拿來洗筷子的。更有許多有趣的名字，「大醬女」，「快快病」。也有許多韓國有趣的習性，坐地上，早餐吃米飯，泡菜，見面先問年紀，聚會的續攤（日本好像也有？）。更有提到有趣的汗蒸幕文化，職場的規則跟加班的習性。

心得:

這本有許多有趣的內容分享，雖然對我來說都是第一次知道的知識。但是常看韓劇的朋友可能都有觀察到一些小細節，很推薦大家來看這本書一起來了解韓國文化上的差異。這樣在跟朋友（同事）溝通時候的背景 context 比較能夠體會了。

↧

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

December 26, 2020, 4:00 pm

≫ Next: 2020 年度回顧與展望

≪ Previous: [好書分享] 韓國人和你想的不一樣

賈伯斯傳（最新增訂版）
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

↧

2020 年度回顧與展望

December 30, 2020, 4:00 pm

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

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

2020 年度回顧

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

2021 年度期許

家人健康
再瘦一點
Golang in Machine Learning

↧

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

January 4, 2021, 4:00 pm

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

≪ Previous: 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 之外，也請到了LAE Richard Lee 跟董大偉來分享。如果想要瞭解更多關於 LAE 的相關資訊，可以參考以下資訊：

由 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 的部分：

上午議程:

Keynote by Marco Chen https://speakerdeck.com/line_developers_tw/line-techpulse-2020-keynote
Life on LINE CLOVA by Aaron Wu https://speakerdeck.com/line_developers_tw/line-techpulse-2020-life-on-line-clova
Platform API Update by Evan Lin https://speakerdeck.com/line_developers_tw/line-techpulse-2020-platform-api-update
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技術分享講座:

LINE Pay New Service My Card by Hugo Huang https://speakerdeck.com/line_developers_tw2/line-techpulse-2020-line-pay-new-service-my-card
How GitOps Helps Kubernetes Adoption by Denny Tsai https://speakerdeck.com/line_developers_tw/line-techpulse-2020-how-gitops-helps-kubernetes-adoption
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 的閃電秀的部分，本次閃電秀分成三大主題，相關投影片依序如下：

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
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
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開發社群計畫」

↧

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

January 14, 2021, 4:00 pm

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

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

前提

學習 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 user study) by Diego Ongaro
The Cloudflare Blog
Improving the Resiliency of Our Infrastructure DNS Zone
A Byzantine failure in the real world
Link aggregation - Wikipedia
Cloudflare Status - Cloudflare Dashboard and Cloudflare API service issues
Raft does not Guarantee Liveness in the face of Network Faults
The power of the adversary
Pull requests · etcd-io/etcd
byzantine generals problem - Google Search

[Understanding the Byzantine Generals’ Problem (and how it affects you)

by Anthony Stevens

Coinmonks

Medium ](https://medium.com/coinmonks/a-note-from-anthony-if-you-havent-already-please-read-the-article-gaining-clarity-on-key-787989107969)

拜占庭將軍問題 - 維基百科，自由的百科全書 !
Raft lecture (Raft user study) - YouTube
Raft Consensus Algorithm

↧

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

January 17, 2021, 4:00 pm

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

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

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

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

前言:

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

比如說:

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

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

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

內容簡介與心得:

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

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

章節條列

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

第一章　易燃易爆炸的偏執狂──王安石
第二章　人格分裂的兩個世界──張居正
第三章　令人恐懼的完美主義者──諸葛亮
第四章　誓做中華FLAG第一人──曹操

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

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

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

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

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

心得:

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

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

↧

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

January 20, 2021, 4:00 pm

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

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

前提

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

↧

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

January 31, 2021, 4:00 pm

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

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

前言

大家好，我是 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 開發者小聚。

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旗下多元服務或開放的平台技術，為台灣產業創造更多商業可能性、為台灣用戶提供更全面的便利生活體驗。

LINE FRESH 2020 校園競賽黑客松組活動紀錄

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

↧

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

February 1, 2021, 4:00 pm

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

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

前言

大家好，我是 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 裡面，內部員工都被稱為是 LINER ) ，能夠有更多自我成長的機會，並且透過許多的分享讓彼此能夠更了解，在合作上也能夠更加的順暢。

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

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

參考文章:

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

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

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

參考文章:

新進員工訓練 (Internal OJT)

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

參考文章

【LINE】新進員工的內部訓練花絮

LINE Taiwan Internal Hackathon 2020

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

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

參考文章:

LINE Taiwan Internal Hackathon 2020 活動紀錄

小結

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

關於「LINE開發社群計畫」

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

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

關於「LINE開發社群計畫」

↧

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

February 2, 2021, 4:00 pm

≫ Next: [TIL][Golang] 打包你用 Golang 寫的 CLI 工具 (Command Line Tool)，並且搭配 Github Actions 準備 Changelogs

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

前言

根據原先 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 」。

參考文章:

LINE 開發社群計畫: Summer Tech Fair 台灣科技就業博覽會

社群活動協辦邀請 (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 所舉辦的活動呢？讓我們 2020 年再相見。

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

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

關於「LINE開發社群計畫」

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

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

關於「LINE開發社群計畫」

↧

[TIL][Golang] 打包你用 Golang 寫的 CLI 工具 (Command Line Tool)，並且搭配 Github Actions 準備 Changelogs

February 7, 2021, 4:00 pm

≫ Next: [好書分享] Instagram崛起的內幕與代價 - 以及它如何改變了文化、商業、科技、媒體，與我們每一個人

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

前言:

使用 Golang 來開發小工具最方便的方式，就是可以很快速將程式碼託管在 github.com 。並且透過 Golang 的跨平台編譯的工具，可以快速打包出各種平台（Windows, Linux 跟 Mac 平台）的執行檔。

那麼有沒有方式可以直接在 github.com 發行新的版本後，直接就打包好所有執行檔變且幫你把 Changelog 都打好呢？

TL;DR

本篇文將要介紹：

以前如何打包跨平台的套件 (GOX)
新的打包套件 GoReleaser
如何整合到 GitHub action
- 發行新的版本 (Release) 的時候，就直接打包好新版本
- 並且可以自動幫你打好所有 Release Note （包含 Changelog )

以前要如何打包你的 Golang CLI ?

在以前的時候，曾經有出過一個很方便可以快速打包所有平台執行檔案的小工具。 Gox 就是一個很方便的小工具：

GOX 快速快平台打包工具（以前）

https://github.com/mitchellh/gox

$ go get github.com/mitchellh/gox
...
$ gox -h
...

就這麼簡單，就可以快速編譯跨平台的工具。其實因為 Golang 從 1.5 之後就支援跨平台編譯。其實跨平台編譯透過

env GOOS=linux GOARCH=arm go build -v github.com/constabulary/gb/cmd/gb

透過這個方式就可以快速的打包你的工具，所以其實後來 gox 就也比較沒人在用。

需要注意地方：

AMD 64 只能編譯 AMD64
如果要編輯 ARM 就需要使用到 ARM 版本的處理好才可以。

關於跨平台打包（編譯）更多的文章:

關於跨平台編譯更多的詳細敘述，可以參考這篇 Dave Cheney 的文章。

GoReleaser 一個好用的打包發佈的工具

後來我也看到 https://github.com/kkdai/youtube 一起在打造的夥伴們有導入 GoReleaser。看了一下，發現還真的蠻好用的。

這裡簡單介紹一下， GoReleaser 有做哪些事情:

幫助你一次透過多平台打包套件
可以深度整合 Github 跟 Gitlab 讓你直接發佈整個產品提供下載
可以幫忙整理出 ChangeLog 可以幫忙整理出 ChangeLog 可以幫忙整理出 ChangeLog (懶人福星)
整合 Docker 相關功能（打包 Docker Image)

GoReleaser 的安裝方式

brew install goreleaser/tap/goreleaser
curl -sfL https://install.goreleaser.com/github.com/goreleaser/goreleaser.sh | sh

如何使用 GoReleaser

參考 GoReleaser QuickStar

goreleaser init來產生 .goreleaser.yml的樣板檔案
來測試一下打包 goreleaser --snapshot --skip-publish --rm-dist
設定環境變數，讓你可以跟 Github 整合 export GITHUB_TOKEN="YOUR_GH_TOKEN"
- Github Token 產生方式，去這一頁. https://github.com/settings/tokens/new
如果需要發布新版本，依照以下兩個步驟:
- ```
git tag -a v0.1.0 -m "First release"
git push origin v0.1.0
```
- goreleaser release
就會在 Github release 直接產生一個 Release ，並且把 ChangeLog 都包進去

是不是很方便？

可能會有的問題

第一次使用 GoReleaser 可能會遇到以下問題:

確認 Github Token 有確切的當成環境變數
每一次要 Release 前，需要手動將 git tag 打好 Push
沒有出現 ChangeLog?
- 記得不要打任何 Description 在你的 release
- 記得不要打任何 Description 在你的 release
- 記得不要打任何 Description 在你的 release

整合進 github action

Github Action 可以讓你更方便的，更直覺的來發布你的專案。而 GoReleaser 的 Github Actions 專案只需要透過以下方式：

建立一個檔案在 .github/workflows/release_project.yml (檔名可換)
內容參考官方範例

記得加入專案的 Secrets
- [Settings] -> [Secrets] -> (右上角) [New repository secre]
- 名稱: GO_RELEASER_GITHUB_TOKEN Token 就照之前申請的
由於設定 yaml 檔裡面有設定是

push:
    tags:
      - "*"

這樣就會每次有打 Tag 才會執行。

接下來只要在 github 上頁上的 Release -> [Draft a new release] 就可以了。

想找一個打包好的樣板，試試看？ Github Command-line Template Repo

https://github.com/kkdai/go-cli-template

GoReleaser Quick Star https://goreleaser.com/quick-start/
🚀 GitHub Action for release your Go projects as fast and easily as possible
Golang Github Actions Starter

↧

[好書分享] Instagram崛起的內幕與代價 - 以及它如何改變了文化、商業、科技、媒體，與我們每一個人

February 12, 2021, 4:00 pm

≫ Next: [好書分享] 訂閱經濟-如何用最強商業模式，開啟全新服務商機(Subscribed)

≪ Previous: [TIL][Golang] 打包你用 Golang 寫的 CLI 工具 (Command Line Tool)，並且搭配 Github Actions 準備 Changelogs

Instagram崛起的內幕與代價-以及它如何改變了文化、商業、科技、媒體，與我們每一個人
(No Filter : The Inside Story of Instagram)
原文作者： Sarah Frier  
譯者： 余韋達  
出版社：臉譜 
出版日期：2020/11/26 語言：

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

前言:

這一本是今年所讀完的第二本書。會讀這本書主要是因為聽「星箭傳播」的Podcast 節目第八十七集（不能再多？）的節目介紹到這本書。雖然有一個多小時的 Podcast 介紹這本書，但是還是讓人欲罷不能，很想買來好好的閱讀。

這本書主要是介紹 Instagram 的崛起，到了 2012 被臉書以十億美金的收購價格收購。一開始雖然承諾會讓 Instagram 以獨立的方式來發展，但是隨著臉書的使用者逐漸地轉移到了 Instagram ，也讓臉書的人做了許多相關的干涉，最後導致創辦人 Kevin Systrom 離開了臉書。裡面有許多詳細的描述，也讓人更了解臉書是如何併購一家公司。

參考節目：

內容簡介與心得:

創立於2010年的Instagram，在短短數年內崛起，為目前全球互動率第二高的社群媒體平台，僅次於臉書。每個月全球有超過十億人使用Instagram，日活躍用戶高達五億，每天上傳的照片與影片超過一億則。2019年，它的年廣告營收高達兩百億美金，表現大勝 YouTube的五十億。

究竟非典型的矽谷創業家凱文．斯特羅姆與出身巴西的工程師麥克．克里格，是如何在一片紅海中以「反直覺」的決策打造出Instagram，並帶領它在短短十八個月內從不被看好到一夕爆紅，吸引臉書（Facebook）CEO馬克．祖克柏斥資十億美金天價收購，進一步獲得今日商業上的成功？在傳奇性成功的背後，Instagram以及所有使用者，又付出了哪些代價？

章節條列

第一章代號：計畫
第二章成功的混亂
第三章一場驚喜
第四章充滿不確定性的夏天
第五章快速移動，打破成規
第六章全面宰制
第七章新名人階級
第八章追尋Instagram的價值
第九章 Snapchat危機
第十章自相殘殺
第十一章另一則假新聞
第十二章執行長
結語收購的代價

2010 年所開始的服務 Instagram ，一開始主打的就是簡單的相片分享服務與相片濾鏡服務。靠著分享到臉書與推特的功能，開始讓更多的人來加入使用。走著跟臉書不同的路線，主打著攝影分享，讓使用者可以快速分享，以使用者為主的概念。很快速地獲得許多的人加入。但是也被競爭對手（？）臉書看上，在 2012 併購，本書也介紹了整起併購案的整個經過（當然是透過新聞與許多其他人的採訪得知）。

雖然進入了臉書，一開始也是維持得獨立的方式來經營。一反臉書主要以廣告平台的經營方式， Instagram 透過主動與廣告主主動聯繫，並且提供許多的建議與專屬的優惠。讓許多的廣告商（甚至本來不喜歡臉書的廣告商）也會來投放 Instagram 的廣告。也透過使用者為主的經驗，並且沒讓人（明顯）感受到臉書擁有 Instagram 的狀況下。也加入許多功能加入讓臉書可以一舉打敗許多競爭對手（Snapchat) ，並且也在 2019 年讓使用者增長到十億，並且收入也高達臉書整體收入的四分之一。最恐怖的是，當許多年輕人都在笑臉書使用者老派的時候而跳去使用 Instagram ，卻沒有人感受到其實他也是臉書的使用者之一。

但是世界上並沒有那麼美好， Instagram 的快速成長令一方面也讓臉書的使用者成長遲緩了。於是臉書的高層（Growth Hacking team?) 也做了許多研究，並且開始阻礙許多來自於臉術轉換到 Instagram 的流量方式。當初「獨立發展」看起來也並沒有完全的實現，也導致創始人在 2019 年離開臉書。本書基本上有大概百分之二十的部分都在講解著他們成功所帶來的「犧牲」與「掙扎」。還有當初答應臉書購併所帶來的「代價」。

心得:

我想所有的新創公司的人，許多人都希望在成長得時候能夠順利地被大公司所收購。但是沒有人想過，許多好的服務都是避免被坐大才被對手「防禦性收購」的方式所購買下來。雖然臉書收購了 Instagram 之後，沒有馬上將它下架並且並為己有。也讓 Instagram 成長到超過十億的使用戶。但是由於許多的人就是不喜歡臉書而逃避到 Instagram 想不到還是在臉書的旗下。也難怪許多人會說臉書收購 Instagram 可以說是近十年最值得的併購案。

本書也清楚的交代了一家公司被併購後，並不是馬上所有人都能夠雞犬升天，馬上就坐擁千萬的財產。許多的併購案往往都只有讓工程人員得以併入母公司，雖然可能獲得便宜的換股機會，但是也並非所有人能夠用漂亮的股價直接轉換成現金。並且併購發生後往往會有母公司與子公司的資源分配問題，與「功高震主」的機會。就像是本書的 Instagram 一樣，遇到許多來自於母公司的審核與干涉。這些真實世界的內幕，在這本書很難得敘述得相當清楚。很推薦新創產業的從業人員好好看一看這本書。

↧

[好書分享] 訂閱經濟-如何用最強商業模式，開啟全新服務商機(Subscribed)

February 26, 2021, 4:00 pm

≫ Next: [學習心得][Golang] Go 1.16 新功能的「版本撤回(下架)」(Go Modules retraction)

≪ Previous: [好書分享] Instagram崛起的內幕與代價 - 以及它如何改變了文化、商業、科技、媒體，與我們每一個人

訂閱經濟 - 如何用最強商業模式，開啟全新服務商機 (Subscribed)

原文作者： Tien Tzuo、Gabe Weisert  
譯者： 吳凱琳  
出版社：天下雜誌出版 

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

前言:

這一本是今年所讀完的第三本書。 Netflix ， Spotify 許多訂閱服務已經存在在你我的生活之中。你否有思考過，你一個月需要繳交多少的訂閱服務呢？但是訂閱服務的商業模式是否是每一個產業都可以採用的？如果真的要將產品的販售模式改成訂閱模式，會經過那一些痛苦的轉換呢？購買訂閱模式的客戶，有哪一些需要改變的流程呢？

這一本書由全球最大訂閱管理平台祖睿（Zuora）執行長暨共同創辦人所分享的經驗談，談到了他之前在 Salesforce 與他自己創辦的 Zuora 後，對於訂閱服務的一個看法，並且分享產業轉換到訂閱產品服務可能會遇到的過程。

內容簡介與心得:

百年一遇的商業大變革，萬物皆可訂閱的時代已經來臨。
史丹佛最新熱門課程、全球最大訂閱管理平台執行長
教你掌握下個十年最重要商業趨勢——
萬物被連結，數據被秒解，競爭關鍵在服務。
最潮也最強的新商業模式，企業必懂、消費者必看！

章節條列

第一部　最強也最潮的商業創新

一開始作者開始介紹訂閱服務的整體重點，還有訂閱服務如何改變這個世界。 Netflix 透過訂閱服務改變了影音出租行業，讓曾經獨佔龍頭的百視達也只能落寞下場。甚至是Microsoft 與 Adobe 這些曾經是商業軟體銷售龍頭，如何改變產品銷售策略，來將其產品改變為訂閱服務。

舊的產品思維是:

做一個好產品
透過通路與業務，賣給客戶
透過行銷方式讓客戶來購買。
收取利潤，開發下一個產品（回到一開始成為循環）

但是隨著時代的變遷，用戶開始對於產品的要求越來越多。功能需求開發量也越來越大，如何界定新的產品服務變成一個很困難的問題。而訂閱服務的流程很明顯的不同：

打造一個好服務
免費（或是極低代價）吸引用戶來試用
透過訂閱獲得完整（更優秀）的功能
獲得訂閱的利潤。
透過定期得少量更新來讓產品更加優秀，吸引新的用戶或是取得向上銷售(upsale)的機會。

這樣的數位轉型，形成了新一波的典範轉移。這一個章節也提到了報社，航空公司，火車行業如何透過訂閱方式來轉移。

產品銷售模式的轉換 - 魚形曲線

如果要將產品銷售模式的從舊有的販賣方式改變成訂閱模式，可能會經歷一個利潤下降，但是成本上升的時段。主要原因是因為客戶轉換到訂閱模式後，造成當下的現金流減少。並且需要相關系統轉換的成本與人員的訓練。這一系列的變換，被稱為「The Fish Model 」。

大家可以參考一下由微軟執行長曾經在某次演講上提到的相關內容 - The Secret to Satya Nadella’s Success is a Fish-Shaped Curve。這也是許多人經常提到的，企業轉型重點在能不能吃得下那一條「魚」。

第二部　顧客導向，成為訂閱新贏家

假設經過了內部的討論後，公司內部也決定要將產品的銷售方式轉換到訂閱模式的話。那麼有那些地方需要變動呢？這一個部分在書上也有許多的著墨的地方。並且透過系統面，人事面，心理層面有許多相當實際的討論。

首先是產品的開發流程，由於產品的銷售方式變成訂閱後。並不是收到相關的費用來支持下一次的開發，必須要讓功能的開發更有系統化，更敏捷的方式來跟你的客戶溝通。

接下來行銷在銷售產品的流程上也會有巨大的變動，改換成訂閱模式後並不代表不需要行銷。但是以往的行銷是在於新產品發售後需要一個檔次的相關廣告來行銷。對於舊有產品用戶的轉換宣傳，如何讓他們願意順利的轉換到新的付費機制上。都是行銷需要考量的層面。首先可以思考的是從以往出走的客戶群來下手，會出走的客戶群往往都是因為「費用」，「功能」等等因為而轉往競爭者。透過消費模式的轉換，可以再次接近舊有的出走客戶來給予新的提案。

最後這本書也提到一個很有趣的點「資訊系統的配合」，一開始我還看不太懂。原來指的是銷售系統需要改變成「訂閱的模式』。如何透過訂閱模式來計算公司的收入模型，並且如何透過訂閱模式來開相關的政府單位需要的支出文件（發票或是明細）。都是資訊系統需要的（當然這似乎也是作者從事的部分 XD ）。

參考文章

[微軟重拾升勢的祕訣？魚形曲線！海外頭條](https://www.mdeditor.tw/pl/prIG/zh-tw)
The Secret to Satya Nadella’s Success is a Fish-Shaped Curve

心得:

其實在十年前，在我第一份工作上有機會在幫公司的產品加上訂閱相關的功能（雖然搞得快死）。那時候對於訂閱模式也沒有感覺，直到近幾年才覺得訂閱經濟已經慢滿的改變你我的生活。那時候主要還是弄加上訂閱機制，才知道有許多相關加密與訂閱流程。並且針對功能的開啟與解鎖都需要相關的控制。

近年來針對許多產業都將產品的銷售流程改成訂閱模式，從影片，甚至到了最多人爭議的音樂 CD 。進階的也造成了音樂產業的轉型。現在的藝人無法透過完整專輯的銷量帶來大量的收入，反而需要透過許多的廣告代言，宣傳代言，出席相關的場合所帶來的收入。

我想許多的產品也會是如此，資訊產品更是。許多的單一功能的產品也透過訂閱方式來讓使用者付費。雖然一年內，可以完整費用是變少的，但是隨著年份的增加也是有相關的支出會產生。加上訂閱費用往往在使用這這邊是不容易管理的。

這本書有許多實際上的演練與系統上的討論（當然也因為作者要賣東西？），但是相關討論事實上也是需要先注意到的。蠻適合非資訊人員與技術人員都應該要看一下的。

↧

寫在前面

投影片

演講影片

什麼是 「LINE 購物 App」?

關於 「LINE 購物」的介紹

Flutter 打造 LINE 購物專屬 APP

效能考量:

快速開發:

豐富的開發資源:

最後成果

遇到的問題分享

小結

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

前言:

內容簡介與心得:

章節條列

心得:

競賽主題

活動流程

導師會談

決賽當天

開幕主持

技術長致詞

比賽最重要的是

猜謎小活動 (Guess and Game)

獲獎隊伍簡介:

評審特別獎 - Study Cat

評審特別獎－LINE LABEL

第三名： 隊名： 春芽冷露加珍珠 作品： InsurTech+ 智能保險導購平台

成員：

作品簡介：

成員:

作品簡介：

第一名： 隊名: LINE Premium 作品： LINE Medi

成員:

作品簡介：

活動小結

關於 LINE TECH FRESH「技術新星」計畫

相關文章

加入官方開發社群

關於「LINE開發社群計畫」

徵才訊息

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

前言:

內容簡介與心得:

章節條列

第一部 開始邁向自由與責任的文化

第二部 加速推展自由與責任的文化

第三部 持續深化自由與責任的文化

特殊的用人邏輯 「留任測試」

沒有獎金制度

第四部 NETFLIX文化走向全球

心得:

前言:

為何程式語言需要 Generics

在 Type Parameters 之前Golang 沒有其他替代方案嗎？

衍伸閱讀

Golang Generic Proposal 介紹影片:

試玩 Go2 Playground

Type Parameters加上限制

範例： 兩個參數取比較大的

小結論：

相關文章：

寫在前面

投影片

演講影片

地理資訊服務 Location-Based Services

找出距離幾公里的景點

如何將搜尋結果作 Caching

其他的方式

「LINE 熱點」美食推薦

活動小結

關於「LINE開發社群計畫」

買書推薦網址：http://moo.im/a/7afCJN)

前言:

內容簡介與心得:

章節條列

第一部 就從這一天開始

第二部 領導力的六個關鍵價值

第三部 你如何定義你自己

什麼是「LINE 購物 App」?

關於「LINE 購物」的介紹

第三名：隊名：春芽冷露加珍珠作品： InsurTech+ 智能保險導購平台

第一名：隊名: LINE Premium 作品： LINE Medi

第一部　開始邁向自由與責任的文化

第二部　加速推展自由與責任的文化

第三部　持續深化自由與責任的文化

特殊的用人邏輯「留任測試」

第四部　NETFLIX文化走向全球

範例：兩個參數取比較大的

第一部　就從這一天開始

第二部　領導力的六個關鍵價值

第三部　你如何定義你自己