前提 大家好，我是 LINE Taiwan 的 Technical Evangelist - Evan Lin。在 2020/10/21 的晚上，很開心能夠再邀請 TWJUG 社群來到 LINE 台北辦公室來舉辦社群聚會。這次的講者一共有四位，而其中來自於 LINE 的講者主要是 TECHFRESH 的 Wayne Wu ，來自 LINE 購物團隊的 Joanna Hu 與 Andy Chen。 活動網址： KKTIX: https://twjug.kktix.cc/events/twjug202010 開場 LINE TECHFRESH 介紹 LINE 台灣工程團隊每年透過 LINE TECH FRESH – 技術新星人才計劃，招募資訊科技相關科系，或對此領域有所涉略的大學生 / 研究生加入 LINE 團隊進行長期實習 (一年期)，讓同學們能在國際級科技公司中觀摩學習。 更多內容，可以參考這篇文章： LINE TECH FRESH – 技術新星人才計劃，實習經驗大公開 每一位實習同學都會分配到不同的團隊中，擔任著團隊裡面的種子工程師。經過一些內部與訓練型專案的指導，讓每一位參與的同學能夠了解跨國產品的開發流程與大公司的軟體工程技巧。 接下來由各個不同團隊來分享不論是擔任 TECH FRESH 的心得，或是許多有 TECH FRESH 的用人主管來分享他們專案的訓練方式與負責的業務範圍。 LINE 實習經驗分享 / Wayne Wu 第二位上場的是來自於台大資工系大四同時也是目前在 LINE 實習的同學 Wayne Wu ，他來分享從七月到現在剛好滿三個月的實習心得。 首先身為學生，在專題分工的習慣上常常有「責任歸屬」不均的狀況，「溝通」不順暢與「流程」不清楚的問題。但是來 LINE 實習的時候往往不會有這樣問題，透過有經驗的 Mentor 細心的帶領，並且在實習一個月後有了處理新專案的機會，讓講者在學習上更有自主性與積極性。 同時間講者也分享了，在 LINE 實習的時候感受到團隊內對於文件的高度要求。清楚的文件帶領的新手快速入門，並且 Mentor 也會要求處理過的同學試著紀錄下所有的經驗的學習機會。透過了定期內部讀書會，提高了學習的動力與技術力，並且透過經常性的溝通確保團隊內的同仁都是在共識下將專案積極推進。 跨國合作上，講者也分享了與越南工作同仁的小趣事。彼此在溝通上雖然都是透過文字，但是也讓語言能力與表達能力能不斷的提升。 最後這位同學也分享了他平時就是常常在懶骨頭上工作，可以更專注地處理手上的問題。風氣很自由並且工作彈性高，讓工作就像是另一場有趣的學習。 Migrating to JUnit 5 / Joanna Hu 接下來由 LINE SHOPPING 的工程師 Joanna 來分享 migrating 到 junit5 的經驗分享。首先先釐清幾個名詞: JUnit Jupiter: 支援 JUnit 5 test case 的新測試框架。 JUnit Vintage: 則是可以跑 JUnit3 與 JUnit4 架構語法的測試引擎。 JUnit Platform: 則是最底層用來在 JVM 下啟動測試架構。 為何整合到 JUnit5 高度支援 IDE 與 build tool 容易從 JUnit4 移植 並且有相關新功能 JUnit5 新功能 Nested testing 支援 Nested testing 讓測試檔案的架構變得更有系統，也可以分類成各種功能來跑不同規模的測試。 Display Name 支援 Friendly Display Name ，可以讓測試執行的時候不僅僅是顯示測試的名稱。而是更有意義的測試名字。 Parameterized...

大家好，我是 LINE Tech Evangelist - Evan Lin 。LINE 很重視員工們的自主創新與團隊合作，所以各地都會舉辦 LINE Internal Hackathon 。 在 LINE 台灣這已經是第二屆的內部黑客松競賽，也期待能夠看到不同團隊激盪後滿滿的創意。 第一屆內部舉辦的時候，受到許多的迴響。不少非工程團隊也希望能夠一起參與，所以今年特定修改參賽方式，第二屆的 LINE 內部黑客松競賽的主題就是 「Team up for A+」 ，目標希望同仁們能團隊合作，共同優化與創新出更令人驚豔（WOW) 的產品服務。 第一屆回顧 LINE Internal Hackathon 2019 - LINE Attitude 第一屆的 LINE Taiwan Internal Hackathon 主旨為 「AI is new Attitude」，由於 LINE 是一家注重 AI 的公司，我們也希望每一位員工都能透過機器學習為出發點，來反思每一個服務，一些內部應用是否可以透過機器學習與人工智慧的方式來優化。 第一屆的 LINE Internal Hackathon 我們收到許多有趣的應用，在 TECHPULSE 2019 上我們也分享了第一名的成果與技術。 也就是透過人工智慧的方式來幫助出差報帳的系統。 20019 LINE Internal Hackathon 第一名：自動報帳系統 LINE 的開發團隊遍及許多國家，於是 LINE 的工程團隊有許多的機會可以到不同國家的分公司去合作與討論。但是回來後最令出差人員困擾的就是要將許多的單據一步步的用人工的方式要輸入到系統與表單之中，這樣的作業流程往往要半個小時左右，相當的消耗人力。 去年的參賽隊伍透過人工智慧學習的方式，透過超過數百張出差表單的學習經驗。透過 iPhone 的軟體拍照之好，透過 OCR 的辨識與學習經驗，自動將不同表單填寫到正確的表單位置。並且產出報帳需要的表單文件。大大的將原本三十分鐘節省報帳的流程到兩分鐘之內。因此獲得了評審的青睞。 今年新增 (What’s new in 2020) 第一屆舉辦後收到不少的迴響： 非工程團隊能有否參與的機會？ 有點子但是都找不到工程師來一起組隊。 有沒有更多的時間能讓參賽隊伍完成這個專案？ 吸取了去年的意見，於是今年的參賽規則也做了部分的修改： 每個參賽的隊伍需要有不同團隊的成員（e.g. 開發人員＋行銷團隊，或是開發人員＋人力資源團隊）。但是開發人員與測試人員都算是工程團隊而無法這樣組隊。 第一階段提案入選的隊伍，能夠有三次的 Hacking Space (黑客工作訪)的機會。週末下午有特定的空間與餐點（下午茶）提供讓每個參賽隊伍能極盡可能得提高產品的完成度。 （ Hacking Space 的紀錄照片） 同事們都很妥善利用公司所提供的時間與空間，在不影響專案進度的狀況下熱情的參與。 總決賽 經過了三次的 Hacking Space 的活動後，也到了最後總決賽的日子。 為了讓公司內沒有參賽的同仁可以一起觀賞總決賽的展示說明。這一次特定在總決賽舉辦在公司內部的十二樓會議空間。 整天的活動分成三個部分： Hacking: 讓同仁做最後衝刺的機會，並且可以調整簡報的順暢度。 猜謎活動： 下午舉辦的猜謎活動，一些有趣的問題外。也讓緊張的氣氛獲得緩解。 最終展示簡報： 最終的簡報展示，必須包含可以 demo 或是讓評審實際遊玩的產品。 現場也有一些必要的佈置，並且也替每一位同仁定制了專屬的紀念 T-shirt 。提供給每一個參賽的同仁可以拍照，讓本次的活動不留白。 猜謎小活動 從去年第一屆就開始的猜謎小活動，其實題目都相當的有趣。除了有 LINE Friends 相關小故事猜謎外，也有一些 LINE 相關服務的問題。除了可以讓每一個同仁更佳的了解 LINE 之外，也可以讓每個同仁舉舉手，運動一下也可以舒緩緊張的比賽氣氛。 活動小結 今年的參賽題目都相當的有趣（礙於都有可能變成未來產品，不方便公開）。除了許多產品有人工智慧與機器學習的輔助之外，更有許多產品是相當有趣的突發奇想。也由於今年有 Hacking Space 的安排，每一個參賽隊伍的作品完成度都很高，不僅僅都可以讓評審現場的試玩之外，也都開放給公司內同仁測試。 完成度與穩定度之高，讓評審們都讚不絕口。 也想要參加有趣的 LINE 內部的黑客松活動嗎？ 那還不趕快投遞你的履歷加入 LINE 喔！ 立即加入「LINE開發者官方社群」官方帳號，就能收到第一手Meetup活動，或與開發者計畫有關的最新消息的推播通知。▼ 「LINE開發者官方社群」官方帳號ID：@line_tw_dev 關於「LINE開發社群計畫」 LINE今年年初在台灣啟動「LINE開發社群計畫」，將長期投入人力與資源在台灣舉辦對內對外、線上線下的開發者社群聚會、徵才日、開發者大會等，已經舉辦30場以上的活動。歡迎讀者們能夠持續回來察看最新的狀況。詳情請看: 2019 年LINE 開發社群計畫活動時程表 LINE Taiwan Developer Relations 2019 回顧與 2019 開發社群計畫報告 2020 年LINE 開發社群計畫活動時程表 徵才訊息 《LINE...

Refer article “Debugging Go in prod using eBPF” by Zain Asgar : https://blog.pixielabs.ai/blog/ebpf-function-tracing/post/ 前言: 在 Golang 上面來 debugging 其實有許多方式，不論是最常使用的 logging 或是透過 delve 甚至是 GDB 。 都算是常見方式來 debugging Go 。 但是最近看到這篇文章，覺得裡面提到的 eBPF (extended Berkeley Packet Filter) 算是蠻有趣，在這裡稍微做個簡單的整理。 Golang 上除錯的方式 (Debugging in Go) 一般來說要在 Go application 中來 debugging ，有以下的方式: Add log: 就如同大家熟悉的，使用 fmt.Println() 或是 log.Println() 。 Using debugger (delve or GDB) 不論是透過 vscode 內建的 delve ，或是透過 GDB 來做 debugging 。 透過 debugger 來除錯，其實是相當消耗系統資源，並且經常會中斷整體應用程式的運行。 Tracing 這裡指的是透過外部的 tracing tool ，不論事 USDT 還是 strace 都算是一種方式。 什麼是 eBPF eBPF (extended Berkeley Packet Filter) 根據官方網站 (https://ebpf.io/) ，是一個技術可以讓 application 跑在 sandbox 上面，並且可以透過 Syscall hook 方式來查看相關的資料而不需要修改任何的 kernel source code 。 應用範圍有: Secuerity: 透過 eBPF 可以做為一個與系統呼叫 (Syscall) 與硬體設備的中間層。 Tracking and Profiling:由於 Linux 系統都有提供 eBPF 的接口，可以透過這個直接 tracking 與 Profiling 你的應用。 (with very low latency) 。 這也是這篇文章提到的主要技巧。 為何使用這個? 既然提到 Debugging Go App 的所有工具，必須要跟其他方式做個比較。可以看到 eBPF 具有以下特性： Performance Impact 非常的低（disruption 也很低），類似於 Tracing tool 。但是跟 GDE 與 Delve 一樣可以追蹤到 Application Code。 但是無法作分散式系統的測量，因為一次 eBPF 只能針對你需要 hook...

前言 大家好，我是 LINE Taiwan 的 Tech Evangelist - Evan Lin。這次很開心受到 Golang 社群的邀請，參加了 “Golang Taipei Gathering #54” 的聚會活動，並且分享 Golang 開發的一些技巧與個人開發的心得。在此也跟各位分享本次參與的心得，並且也希望透過社群分享的力量能夠讓 Golang 更受到人了解。 社群 Chatbots Meetup： https://www.meetup.com/golang-taipei-meetup 本次活動網頁: 活動網址 Golang in LINE MUSIC TW - Wei@LINE Music 介紹 LINE Music 中主要使用到的 Golang 套件與相關的經驗分享。 errors x stack x info - Hsueh-Tsung Kuo @Rayark 投影片： https://hackmd.io/@fieliapm/Bk48ziTj8#/ 首先講者先介紹了 Go Error 系統的一些常被人詬病的問題： error 包含的資訊過少 不容易瞭解錯誤，拆包（摘解 error）與包裝 Go 1.13 的 error 可以參考一下這篇 Working with Errors in Go 1.13 ，可以透過 Warp 跟 UnWarp 來包裝與拆解 Errors 。 有沒有辦法 Inspect ? 透過 error.Is() 來判斷是不是同一個，或是透過 error.As()判斷是不是同一種類別 (type assertion)。 Go Error system sucks, 可以參考 Rust 的 error handling 與 Trait std::error::Error https://github.com/pkg/errors 不錯用，但是無法解析底層的 errors （因為跟底層的 standard error 不相容）。參考文章 Can new Go errors wrapper replace pkg/errors? 參考鏈結 Working with Errors in Go 1.13 Rust 的 error handling Rust std::error Can new Go errors wrapper replace pkg/errors? 活動小結 立即加入「LINE開發者官方社群」官方帳號，就能收到第一手Meetup活動，或與開發者計畫有關的最新消息的推播通知。▼ 「LINE開發者官方社群」官方帳號ID：@line_tw_dev 關於「LINE開發社群計畫」 LINE今年年初在台灣啟動「LINE開發社群計畫」，將長期投入人力與資源在台灣舉辦對內對外、線上線下的開發者社群聚會、徵才日、開發者大會等，已經舉辦30場以上的活動。歡迎讀者們能夠持續回來察看最新的狀況。詳情請看: 2019 年LINE 開發社群計畫活動時程表 LINE Taiwan Developer Relations 2019 回顧與 2019 開發社群計畫報告 2020...

大家好，我是 LINE Tech Evangelisgt – Evan Lin。LINE 一直以來不遺餘力地提升資訊安全，除了以 DevSecOps 的概念為基礎，將資安 DNA 注入 LINE 產品與服務，更積極促進整體資安生態圈的成長。 而 Beer is beautiful, hacks is amazing, BECKS is gold. BECKS是Beer與Hacks兩個字所組成。 透過一系列的 BECKS.IO – Security Meetup 資安社群活動，為韓國、日本、台灣等地的優秀資安人才提供當面交流、建立良好連結的機會! 本次 BECKS.IO 小聚選於台北的 Avenue 舉辦，邀請台灣的講者們，在輕鬆開放的氛圍中，暢談不同企業與個人的資安思維及實務經驗，並展望相關技術的未來發展。 KKTIX 活動網頁: 活動網址 Detect and track Apple devices for fun and profit - Ta-Lun Yen / TXOne Networks (Trend Micro) Threat Researcher 來得太晚，只聽到後半段。主要講解關於 Apple裝置的一些溝通與互動方式。不論是討論的 BLE 還是 Hotspot 的溝通方式。也有提到 Airdrop 的部分。 內容大多是溝通方式，可能有的資安疑慮。 現場也展示了透過軟體來掃出所有在場藍牙裝置的 uuid 與 MAC address。 From NLP to Neural Network based Malware Detection - aaaddress1 / Chroot member 原始論文： https://github.com/Lancern/asm2vec 講者網站: https://30cm.tw 惡意程式 (malware) 的 syntax pattern (from assembly call) uExitCode -> intterup 如何防禦 Malware 把程式切塊，找尋可疑區塊。 是否可以借助「語義學」模型來找出 malware 判斷方式 缺點: 指令與指令間的關係 (for loop 回傳 pattern) 大量改版，變種的 malware 。 根據舊的 malware 新增索引包，很容易被判斷跳脫 語義學(semantics)介紹 根據一個詞的前後文來判斷文字本身的意思 e.g. I drink beer, I drink wine. I guzzle beer, I guzzle wine. 透過共生矩陣表 (tokenFeq) 來找出前後文出現頻率，有出現 +1 。 透過詞頻率畫出的折線圖，可以找出類似的詞。 (e.g. drink and guzzle) cosine similarity 為何不直接用 semantics 分析方式? 如果有新的詞出現，造成 tokenFeq...

前提 大家好，我是 LINE Taiwan DevRel 團隊的 Evan Lin。很開心在這裡跟各位分享本年度的第三場開發者小聚。 這也是疫情後第一次在新竹舉辦的線下聚會的活動。 也是 LINE 台灣工程團隊第一次來到交通大學舉辦線下的活動。 本篇分享的就是該活動中由 LINE 台灣資料工程團隊的 Shawn Tsai ，跟大家分享機器學習如何的讓 LINE 的服務能更貼近使用者。 KKTIX 活動網頁: 活動網址 活動全文網址： TBD 投影片 影片 LINE 台灣資料工程團隊的組成 首先 Shawn 先跟大家分享 LINE 台灣資料工程團隊的組成，主要由以下三個角色所構成： 資料工程師 (Data Engineer) 身為資料工程師需要有一手強大的工程技能，不論是資料的截取，抓取與前處理 (Pre-processing) 。甚至是資料探索的部分，到最後機器學習模型的部屬都缺少不了資料工程師的協助。 資料科學家 (Data Scientist) 資料科學家的工作就是要協助資料工程師來擷取資料，並且一同討論如何前處理之後。將機器學習模型學期出來。 資料分析師 (Data Analyst) 資料分析師的重點在資料的探索，尋找出真正能解決問題的數值。並且針對完成的模型來做相關的測試與修正。 資料工程團隊與專案的合作方式 資料工程團隊主要由以上三個角色所組成，所有的資料工程團隊會因為不同的產品需求有不同的任務小組。 有些產品還在資料討論與擷取的階段，有些產品可能已經進入機器學習模型的調教。 針對不同產品線，每一個成員在日常的工作都可以參與許多有趣的產品與專案，更能學習新穎的機器學習模型方法來套入每一個日常工作之中。 資料工程團隊面臨的挑戰 由於 LINE 使用者超過兩千一百萬， LINE TODAY 上面一年產出一百萬篇文章， LINE 購物上每個月有五百萬筆商品查詢。這麼多的資料就是資料工程團隊要面臨的問題。 而機器學習本身可以是簡單的，也可能是相當複雜的。接下來就會根據產品的不同稍微解釋所使用到的機器學習技術。 LINE 客服小幫手 「糟糕…換手機要怎麼移動帳號？ 」 「怎麼購買貼圖送給親友？」 這些問題都是使用者每天都會想要了解的操作問題，但是要如何能及時的找尋到解答呢？ 這時候就可以透過「客服小幫手」機器學習的能力來幫你快速回覆。 手機點此加入LINE 客服小幫手帳號或搜尋 @linehelptw加入好友。 更多使用方面的介紹可以參考 「LINE 客服小幫手」智能客服全新升級～對談中解決用LINE大小事。 由於同樣的問題可能會有各種詢問方式，比如說： 為什麼有時候賴都不會通知? 訊息都跑不出來是怎樣? LINE 都不會叫也不會震動? 這三種完全不同的問法，可能導向的都是當初 iOS 11 更新造成的問題。這些如果要透過人力來回覆相當的費時，就需要使用自然語言理解 (NLU: Natural Language Understanding) ，並且是用到 LSTM 來了解文字在前後文中的相關性，並且透過 CNN 來獲取文字與其他文字的特徵。 這是第一個版本的解法，但是效果不算是令人滿意。 後來透過了使用 seq2seq ， CBoW ， DSSM與 BERT達成的 Esemble 的解決方案，這樣的方式大幅度的得到比較好的效果。 LINE 訊息查證小幫手 「LINE 訊息查證」平台在去年七月份正式上線，不僅有官方網站，更串聯 LINE 官方帳號，用戶只需把在聊天室中收到的訊息「轉傳」至「LINE 訊息查證」官方帳號。如過去已有查核報導在資料庫中，查證小幫手會自動判斷其真偽，系統將即時提供查證結果；如訊息尚未查核，將提報給專業查核單位，待釐清後再盡快回傳正確資訊給予用戶，提供最即時的訊息辨別服務，協助用戶辨識可疑訊息真偽，降低假訊息再次散播的機會。 每天收到的訊息量高達四萬則，但是人工辨識每天只能夠 300 則，所以這時候需要機器學習大量的協助。 透過了 Near-Duplication 與 Classification 兩種方式來尋找與分類訊息。現在訊息查證的效率也進步了十倍以上，並且成功的釐清了 46% 使用者所發送的可疑訊息。 不想要變成假訊息的傳播者嗎？ 一起加入 「LINE 訊息查證」官方帳號。 透過機器學習專案的學習 許多學生朋友都會好奇，真正在 LINE 來從事資料工程團隊的工作倒底每一天的時間都在做什麼？ 講者也很大方的跟大家分享了，身為資料工程團隊每一天大部分的時間真的都是花在訓練機器學習模型嗎？ 這張圖可以讓各位了解，大部分的時間都是花在機器設定（ Configuration) ，資料擷取 (Data Collection) ，並且相當多時間在資料的驗證 (Data Verification) 甚至是模型建立後的建置能夠不斷的更新最近的機器模型的基礎建設 (Serving Infratructure) 也會花費相當多的時間。 真正拿來做模型訓練往往是整個專案中少少的一個部分而已。 也可以知道資料科學家主要的時間與專業在於如何找出與辨識「關鍵的資訊」。 相關文章: 「LINE 客服小幫手」智能客服全新升級～對談中解決用LINE大小事