.NET Walker

前面 提過，LINE是一家非常熱愛Open Source的公司，諸多的solutions中，十有八九是藉由純Open Source技術來實現的，你很少很少很少看到其他軟體大廠的服務在LINE出現。也因此，當我在議程表當中，看到有Microsoft相關的場次時，不由得眼睛一亮，身為MVP，說什麼我也得前往瞧瞧… 議程表當中，共有兩個與Azure有關的場次，一場是由Kenichiro Nakamura分享的How to optimize bot development lifecycle with DevOps(這場非常有意思，我待會說)，另一場則是Ayako Omori的Developing chatbot with Cloud 101 for LINE account auto-reply，兩場都是純日文演說，我也都硬著頭皮參加了。 Bot Framework Ayako Omoris那一場是少數沒有英文即時翻譯的日文演說，導致我基本上是完全聽不懂講者在說什麼，不過，我卻大致可以掌握整場的內容。很矛盾? 一點也不。 因為內容是我非常熟悉的Azure Cognitive Services與Bot Framework，我發現技術語言是跨國籍的，我雖然完全聽不懂講者的日文，但只看Demo和操作，基本能夠掌握八成左右(所以如果讀者想去國外工作，大可不用過度擔心語文的問題)，講者除了大致完整的介紹了MS Bot Framework與LINE Bot如何整合，還有如何使用LUIS和QnA Maker服務，這些過去我在 書籍 和 線上課程 中大致也都有介紹，講者能在幾十分鐘的時間內把這些內容都塞進去，也算是不容易了。 除此之外，她也提到了MS最近釋出的 BotFramework-Composer (這就是個新玩意了)： Bot Framework Composer是一套 open source 的Chat Bot設計工具，可以讓你用視覺化的方式來建立Chat Bot。除了支援上圖這樣的所視及所得對談設計界面，也支援LUIS和QnA Maker，讓設計人員可以自由的使用這些雲端服務並整合在Bot當中，雖然目前還只是預覽版本，但未來頗值得期待。我知道台灣坊間也不乏這樣的工具，但掛著微軟的招牌，加上又是open source，背後有MS Bot Framework撐腰，又有自然語言語意...

我在現場看到LINE日籍講師使用 VS Code作為主要的開發工具，還頗讓人驚豔的 緣起 前陣子，LINE推進了LIFF這個框架來到 v2的版本 ，v1到v2是一個很大的改變，一般來說，我們改變主版號(from 1 to 2)意味著新釋出的版本將跟前一版有著不相容性，也就是一個重大的breaking changes，也確實，v2版本增加了很多亮眼的新功能，像是QR Code掃描、外部瀏覽器支援…等。 還不只如此，LINE 11/11發布了一個我認為很重大的 消息 : Users can no longer add LIFF apps to Messaging API channels 看到這個消息的第一眼，我只有一堆問號…，WHY? 為何LIFF 2未來只能從LINE Login新增LIFF，為何將要取消過去LIFF綁在Bot(Messanging API)身上的方式??? 我相信不只我有這個疑惑，很多熟悉LIFF的開發人員也是。我心裡始終帶著這些問號，來參加了今年的LINE Developer Day，當然，我希望能找到答案。 LIFF的改變 在Day 2關於LIFF的場次中，講師不免俗地把LIFF的歷史交代了一下: 其實從v1到v2也不過就是一年的時間，但重點當然不是歷史啊，重點是改變。到底有那些改變呢? 那得看當前的LIFF有些什麼: 上面這三張看似平淡無奇的投影片，其實是接下來講者埋的梗，我得說，後面看到差異的時候，是頗讓人興奮的。上面第一張投影片的Easy Development是理所當然，LIFF可以透過純HTML方式開發，且運行上是無需伺服器端的，但我們也知道，當前的LIFF只能運行在LINE的WebView環境，即便是開發方式和一般的HTML頁面相同，你還是會碰到像是開發階段難以debug之類的困擾。 是的，v1的LIFF是很難偵錯的，因為你必須在手機環境上(LINE的內部WebView)才能執行。我忍不住直接破梗好了，講者在最後ending的時候，上面第一張slide變成了： with LIFF v2，你可以在手機的外部瀏覽器上運行，這也表示，你有機會可以在一般的瀏覽器上進行開發和除錯。對，你沒聽錯，過去非得在手機裡測試偵錯的時代即將過去了，當你用LIFF v2架構開發搭配SDK，基本上你的開發根本就像是一個純Web Application(只是這...

過去幾年，我身邊很多軟體開發人員，要嘛往大陸發展，要嘛待歐美棲身，但LINE選擇的路線，卻給了我一個不同的啟發… 今年 的LINE Developer Day依舊位於東京舉辦，不過較之過往，擴大為兩天的議程，在keynote當中，講者有提到今年改為兩天的原因。總的來說，過去想說的事情多，能用的時間少，所以今年改為兩天乃是天經地義、理所當然(但…費用不就增加了一倍? )。 話雖然這麼說，但我其實一直對LINE的工程師文化很好奇，一個保有傳統謹慎保守基因的日系公司，怎麼去塑造一個對開發人員如此友善的開放文化? 你如果到日本東京新宿LINE辦公室的開放空間，會看到底下這樣的場景： 充滿自在氛圍的空間裡，有著喝咖啡寫程式的Developer、有著接洽外來訪客的員工、甚至放空休息的夥伴…在同一個空間裡，自在且互不打擾的完成自己當下的任務。 這種自由開放的氛圍很像這兩天的大會，當你仔細觀看，不難發現 議程表 上的內容，絕大部分都是LINE員工們真實開發經驗的分享，其中少數才是LINE相關產品和服務的介紹，這跟過去我們看到由企業主辦的年度大拜拜聚會完全不同，更有點像是open source社群聚會的感覺。 透過 上百個議程 ，講者竭盡所能的，把自身的開發經驗，分享給與會的其他開發人員: 這些議程當中，大部分是LINE如何透過open source開發技術，實現自身所需的商務需求、以及自己在採用open source技術所碰到的挑戰與解決方案，那這些議程是怎麼決定的呢? 我問了來自台灣LINE團隊的講者，這些議程主題怎麼決定的? 台灣LINE團隊的講者跟我說，大部分都是由LINE員工投稿，獲選後由LINE贊助講者參加大會，一聽之下，發現身為LAE的我們，平白享有免費三天的東京飯店＋來回機票，看起來待遇似乎比LINE自己的員工還好呢～ 其中有個頗有趣的地方，由於LINE大量的使用了open source技術，對於過去很少接觸 OSS 的微軟 .net 開發人員來說，參加LINE的聚會會讓你突然恍如置身到另一個世界中的感覺，議程當中許多過去在 .net 世界中沒有的東西，霎那間頗有讓人目不暇給之感。 今年的場地改在台場日航飯店舉辦，這個地點是著名的觀光勝地，搭地鐵前往的路上，電車上路過的海景頗讓人心曠神怡。當天天氣很好，廣場上藍色的天空讓人一覽無遺。 到了夜晚，當地頗具盛名的購物中心和...

早上keynote的迴響和疑惑還停留在腦海裡，沒想到一下就來到了中午，中午最讓人期待的當然就是與CTO的round table。 As a LINE API Experts，受邀參加一年一度的Developer Day是一種福利，但更有意義的則是和CTO以及其他技術主管的Round table，畢竟能夠面對面進行溝通，並且得知更多未來的發展方向與具體資訊。 先前 提到過，LINE在這幾年的時間內迅速擴充，如今除了即時通訊軟體，更涉足了Fintech, 區塊鏈, 與AI等多重領域。尤其是AI這部分，關於bot engine與OCR、NLP、speech regnition…LINE都有著自己的實作，這似乎讓人有些不解，在眾多的雲端服務環繞之下，為何LINE選擇自己開發這些技術呢? 為何不使用現成的工具呢? 除此之外，我們也發現，LINE在各國推展服務的速度與順序上，有著相當大的時間差異，未來這部分是否會有統一的時程呢? 說到這部分，我們也發現比起泰國和印尼，台灣的發展速度算是來的快上很多的，這點讓來自其他國家的LAE們頗為羨慕。 不僅發展策略，還有許多關於技術上的討論，諸如，LAE大夥兒也提到，在開發Liff應用的過程中，由於WebView是崁入在LINE App裡面的，因此很難Debug，這個部分是否有好的建議呢? (沒想到還真的有，容後再跟大家介紹) 而最讓人期待的當然是，LINE API Experts是否有類似Early Access Program之類的方案，能夠較其他開發人員更早知道API的釋出與更新呢？ 這些放在心裡的問題，肯定要一次問個夠… 凡此總總，都在兩場的round table有著相當深入的討論，由於LAE們是從不同國家來的，你不難發現，比起泰國、印尼、甚至日本當地的LAE，台灣代表團們可是火力全開，卯足了勁提出了一個又一個的問題，大概會議中有一半時間在回答我們這一票台灣去的LAE提出的種種問題，也算是不枉此行了。 有一個小動作我蠻佩服的，CTO和API Experts聚會結束之後，依照慣例要來張照片，但人那麼多照相隊伍該怎麼排呢? 正當大家杵在那兒不知道該怎麼動作的時候，CTO直接站出來蹲在最前面，不是站著唷，就直接蹲下來讓API Experts能夠站在身後拍照，這應該是我看過唯一一張公司女性CTO帶頭蹲著陪訪客拍照的照片，氣度非凡! 問飽了問...