Hi，
我是 Ask Me Anything 活動的小編，請叫我AMA小編。
口罩地圖在四月底完成階段性任務，不過實在有太多的 IT 人開發的口罩查詢服務富含技術底蘊
於是本次 AMA（Ask Me Anything）一口氣邀請了 5 位實力堅強的來賓，他們開發的服務從口罩地圖、LINE Chatbot 到 App 都有，很難得的這 5 位大大齊聚 AMA ，分享開發的考量與技術架構，請大家把握機會於 5/5(二) 中午 12:00 ~ 5/7(四) 一起來跟大神們聊技術、聊人生、聊學習、聊成長囉！
首先，小編簡單介紹這 5 位來賓的姓名及開發的口罩服務：
David Tung（董大偉）／ 帳號：twdeveloper
口罩服務：即時口罩銷售查詢
James Tsai（蔡景翔）／ 帳號：jamestsai_tw
口罩服務：問口罩 iOS版 ， 問口罩 Android版
Jeffray Huang （黃忠成）／ 帳號：code6421vs
口罩服務：口罩地圖
Ian Chen（陳葵懋）／ 帳號：ianchen
口罩服務：敗口罩Linebot
奇步老爹（陳佳新）／ 帳號：jarsing
口罩服務：Line服務-尋找口罩
小編搶先問兩個問題，幫助邦友們對五位大大有進一步的認識
Q：請各位先作個自我介紹，好讓邦友認識你。
twdeveloper ：大家好, 我是 David（董大偉），微軟最有價值專家(MVP), LINE API Expert, 光岩資訊資深技術顧問，同時也是資策會、恆逸...等教育訓練中心講師。打從 Apple II 時代開始闖蕩江湖至今，在資訊業各領域均略有參與。做過 MIS/IT、當過 RD、帶過專案、團隊、也賣過軟體、持續擔任企業教育訓練講師與顧問，也出過幾本書……。打從沒有物件導向程式設計，沒什麼所謂的軟體生命週期管理與敏捷的年代，一路披荊斬棘、篳路藍縷，得以存活至今...近年來投入 AI、LINE Bot 應用開發與 DevOps、雲端運算...等相關顧問與教育訓練服務。jamestsaitw ：James Tsai（蔡景翔）／專長：Xamarin 跨平台開發 App 技術／成就：Microsoft MVP／口罩服務: iOS/Android 雙平台 App。
code6421 :Jeffray Huang（黃忠成），專研於.NET 與 Java 領域，資策會、Microsoft 講師，著有 4本書，
Microsoft MVP 2008~ 2018，目前是獨立顧問及 Skilltree 講師。ianchen ：大家好 , 我是 Ian（陳葵懋） ，另一個江湖藝名是No.18，本身是 Microsoft MVP，同時也是高雄 K.NET 社群的聯合創辦人兼技術推廣分享者，本身的工作是在軟體設計與開發，主要碰觸的技術是雲端、AI 服務以及 .NET 相關技術。
奇步老爹 ： 陳佳新 ，臉書社團 Chatbot Developers Taiwan 台中分舵負責人，自 2019 年 8 月起，每個月與社群志工合辦「中部人的 Chatbots Meetup 聊天機器人小小聚」開發者聚會活動。靠著參加程式競賽獲勝的獎金，以兒子們的小名在故鄉彰化創辦軟體公司奇步應用。專長是 LINE 聊天機器人，熟悉 Beacon 數位集章、 AR 虛擬實境、 LIFF 網頁應用，曾以作品彰化旅行+獲得政府競賽冠軍。
Q：請簡單介紹一下您所開發的口罩服務、技術架構，以及開發的考量點
twdeveloper ：因緣際會，我也開發了一個查詢即時口罩銷量的 LINE Bot 應用。我採用了自己書籍中所開發與介紹的LineBotSDK，我們在非常短的時間內就建構出第一個版本。而後持續增強與改善，搭配 LINE Notify 服務得以讓用戶在訂閱後持續收到附近藥局的即時口罩剩餘數量，以便於購買。這個系統採用 .net core 作為後端，以 Azure 雲端服務承載，搭配 LINE 所提供的 Notify、Messaging API，同時使用了 Azure DevOps、AppInsight 作為 CI/CD 和持續監測。雖然是一個小小的應用，但麻雀雖小，五臟俱全，是一個很有意思的案例...jamestsaitw ：技術架構－透過 Xamarin 跨平台開發技術零時差開發雙平台 App 上架。
開發考量－由於App 已是目前廣受台灣民眾接受資訊的方式，並且在App 設計操作上也能有更多的彈性，提供民眾有更便利/快速的口罩查詢。code6421 ：前端為 jQuery，API 端為 PHP，Background Job 為 .NET Core(運行於 Synlogy NAS)，最初是收集相關素材，後來發現廣大網友們已經把各類素材都準備好了，藥局座標點加上口罩即時資料(俗稱熟肉)，剩下的就只是一個背景下載的程式及前端部分，使用 jQuery 的原因是夠輕量、簡潔，符合可最快建置的目標，地圖部分一開始使用了 google map，後續則因為費用考量改用 Openstreetmap。
ianchen ：這一次開發敗口罩 Linebot，意外吸引百萬好友數，起初只是將網友公開的超商口罩存量API寫成Line聊天機器人程式，與親朋好友分享，沒料到上線幾個小時後，政府宣佈口罩實名制政策，並且願意提供公開資料，因此索幸就改成口罩版 Linebot，會選擇以 Linebot 方式呈現，是因為一來 Line 是大家都熟悉的軟體，再者我可以省略使用者介面的開發，並且一開始就打定以易用簡單為主軸，所以功能上直接以送出定位點就可以自動找尋附近的健保特約藥局以及口罩數量，整個應用是部署在雲端上，所以在口罩實名制開跑第一天遇到爆量的使用者(每分鐘 1500 ~ 2000 使用次數)，透過雲端擴展的能力，很快解決掉爆量的問題，服務也順利正常運作。
奇步老爹 ：受到大量網友發揮黑客松精神的號召，以及有感於親朋好友對於口罩的殷殷期盼，於是 2 月初有了開源資料集之後，便捲起袖子選用國人天天都在使用的 LINE 作為「尋找口罩」服務的入口，特色是介面簡約（大量使用表情符號）、回應速度快（傳送所在位置資訊，即可查詢「距離最近」和「口罩最多」的健保特約藥局），包括「今天禮拜幾，身分證尾數幾號可以領取口罩」的提醒功能，以及查看口罩領取規範的最新海報，也是老早就幫大家加上去了。
接下來，董大偉將擔任主持的角色，於活動期間 5/5(二) 中午 12:00 ~ 5/7(四) 帶領我們展開一段精彩的技術對談！
邦友們有什麼問題也歡迎搶先在底下留言，五位大大齊聚非常難得，想要與大大們交流的朋友把握機會囉！
大家好，
此次 AMA 很高興邀請到五位大大坐鎮，很榮幸 twdeveloper 願意擔任主持的角色，為我們展開一段深度的技術對談。
謝謝AMA小編。
也感謝忠成(Jeffray Huang), James, Ian, 佳新 大夥百忙之中抽空參加，那我就不客氣了，直接訪問大家囉...
樓上這個置入性太明顯喔 ＸＤＤ
Hi 各位大師午安,
很高興有機會讓各位一起上線...各位都是老朋友了，我就不多問候大家。直接進入主題。首先，想詢問各位大師關於應用開發的問題...
請問開發這次的口罩查詢應用，與其它一般的商用應用是否有所區別? 各位大師花了多少時間開發出第一版? 第一版出現後，一直到穩定的版本，大概又花了多少時間?
最近這幾年，在資訊領域，常常被提及的 "敏捷開發" 概念，在各位大師此次開發口罩應用的過程中，是否有所幫助? "敏捷開發" 真的能夠加速開發嗎? 還是其實與開發速度無關呢?
初版約 1 天半，但上線串接健保局之後立即被打爆，逐步改進後穩定大概是 2 天半，以這個例子來說，我覺得敏捷與否倒是沒差，因為很小。
這次的開發過程很短暫，第一版大約2~3個小時就完成，陸續隨著資料面變化以及政策的調整，初期幾乎每天就上一個版本
，比起商用應用差別最大的應該版本更新速度要快很多，需要的應變時間也短很多，要更敏捷(笑...)，由於我是個人開發在人力及時間上有限
，所以面對要調整的項目，更需要排定優先順序，快速完成然後半夜上版，所以Sprint是天天(笑...)
二月初的時候，看到網友大神們自發性地運用駭客松精神開發了許多口罩應用，終於等到開放資料集，於是捲起袖子也打照了一個，運用的是自己最熟悉的 LINE 聊天機器人技術，大約從晚上 10 開始製作，花了四個鐘頭，到隔天凌晨 2 點，製作了第一個版本，其中覺得最困難的部分是 GPS 座標的距離換算。往後的幾天每天都在衝刺呀，持續收集反餽，持續加入新功能。
David Tung 問口罩 App 從 Xamarin 專案始動前置準備到第一版雙平台落款的時間大約為 2~3 天(Youtube 直播 只針對開發上的過程，一種極限黑克松的概念)。後續開始走 App 審查(新版上架)，Google Play Store 大約跑了三天，Apple App Store 大約跑了五天。
對於 "敏捷開發" 的部分，問口罩 App 開始開發的過程中，有採用其中的 "看板" 管理，把整個 App 的功能一項一項拆分開來，在看板中做成小卡片，對於開發過程要前進的每個小目標就會相對直覺，不會讓自己迷失在整個 App 開發的進程(尤其是當時是基本上是極限黑克松式開發，很容易神智不清)，所以相對而言個人覺得是相當有幫助的。
我自己的第一版是在抓取到了open data之後的兩小時。由於本來就有開發LINE Bot，也有自己的.net core/.net SDK (https://www.nuget.org/packages/LineBotSDK/) 所以開發起來還算順暢，而GPS相關位置的計算，也是過去專案中就有的模組，反倒沒有花太多時間。比較多的時間可能還是在LINE Bot本身要進行production環境測試的難度比較高。另外就是初期的open data資料來源並不穩定。
真正比較辛苦的地方，是上線用戶出現後，由於伺服器端開始有流量，log中也開始發現了一些bugs，這時候花費的時間(修改、測試、上線...如此反覆)，就遠遠超過了一開始的那兩小時了...
to James,
聽說您開發口罩 App，在上架時遭遇到了很大的挑戰? 是發生了什麼事情呢? 發生在 Android 還是 iOS? 是否有什麼特別的感受可以與大家分享?
(to 其他大師， Line bot 或 地圖 有類似 "上架" 或 "審核" 的動作嗎? 在開發時有需要注意什麼嗎? )
David Tung 在疫情剛在中國爆發的時候，沒有人知道會發展成如何，而政府在相當早期(1月中~2月初)就開始有相關的措施。而2/6 政府確立開始推行口罩實名制政策，問口罩 App 就在當時決定開發。Android App 送審上架的時間點大約落在 2/8 前後，iOS App 送審上架的時間點大約落在 2/13 前後。
而後續時間軸進入到 3月初，Google 發出了 “面對 COVID-19: Google 如何協助台灣” 的新聞稿，已經在 Google Play Store 上架的 App 當天就被因違反相關措施而直接從 Google Play Store 封鎖 App 並且下架，讓人相當錯愕。
所幸多方奔波後，提出了相關的解釋與證明後，Google 有條件地恢復 App 的上架權限，問口罩 App 才得以在 Google Play Store 上重見天日，相關的詳細過程，相信有機會會再透過 DotBlogs 所經營的 James's Tech & Life Blog 發表文章娓娓道來的。
而在 Apple 方面要讓 全新 App 上架的審查也是困難重重，來回大約打槍了二~三次，Apple 才會放行通過上架(由於過去累積的上架經驗，已經有相當的心理準備了)。
相信只要有上架過 iOS App 的開發者，對被 Apple 審查打槍的經驗都會有相當的共鳴的。
to Jeffray,
對您來說，開發口罩地圖從技術上來說，應該談不上是有什麼挑戰，不過我們知道這類的網路服務，在上線時常常會有超過想像的流量，雖然可以採用雲端主機來解決，但難免會讓費用驟增，是否有什麼方式可以降低因為流量而出現的成本? 或是，在開發架構上有什麼選擇或建議呢?
這次特別避開雲端，採用一年只要 3500 的超低階主機，這種主機有個很有趣的特性，無法在裡面進行過多的外部連接，例如由健保局網站下載口罩資料，
一開始的架構是把資料由家裡的 NAS 排程下載，然後上傳至主機的空間，也就是沒有在主機進行外部連接、排程的架構，這部分是由 .NET Core 加上 synlogy NAS
完成，隨著時間的推移，我加上了偵測開賣時間的分析，NAS -> FTP -> Host 的架構維持了三天，每天吞下約 5 萬人次的的流量，這不算是個好架構，但是
是個很省錢的架構(沒花到錢)，後期我把部分的流量由主機移開，放到 Github 上，形成了 NAS->Github->HTML 的混合性架構，把主機的負擔轉嫁到使用端上，就實務上來說，
這算是省錢又可撐大容量的架構。事實上也有很多其他網友的架構類似，例如把網頁擺到 github 上，搭配本機排程，不用擔心空間、流量、資金，
就是一個 github 好棒棒的架構。
Jeffray 哥真的超猛的...用免費的資源可以打造出這麼棒的應用
我收過帳單，會怕 XDD
我突然想起當年我和 Jeffray，差點得到百萬獎金，後來因為某主機代管網站被流量操掛...我們的百萬獎金就...沒了的故事。 >_<
後來因為某主機代管網站被流量操掛...我們的百萬獎金就...沒了的故事。 >_<
To Ian,
Ian應該是我們幾位開發者當中，最受到流量衝擊挑戰的開發者了。Ian設計的『敗口罩』LINE機器人，才一上線好友人數就立刻衝上萬人，如今更已突破百萬好友之譜。這是您預期中的結果嗎? 當流量變多的時候，是否可能造成什麼困擾? 您又是如何因應的呢? 在這過程中，最大的收穫是?
衝破百萬好友數，遠超乎於我的預料，其實口罩實名制上線的前一晚，有預期隔天使用人數應該會爆增，因此在前一天的半夜調整程式後，順便也調整了雲端環境的服務等級，但隔天一早還是被打趴了，大約中斷了15分鐘服務，緊急再加大雲端環境的服務等級，並增加了自動擴展機制才得以順利渡過，當然後續也從程式端著手進行一些調整，這次最大的收穫是終於有機會體驗高負載的應用情境，實際從程式端及服務環境端二個面向著手改善應用服務的可靠度。
使用人數的激增，我自已事後分析起來，主要應該是在Linebot平台上我應該是第2快推出口罩查詢應用的，加上網路擴散效應，經過使用者的分享以及媒體的報導(我真的沒有買廣告喔，笑)，再著一開始我就鎖定最大的需求以定位點方式查藥局及口罩，透過最少操作步驟能確實滿足使用者需求，所以到目前為止我的Linebot一直沒有提供主選單，也是為了簡化操作，因此雖然我的Linebot功能不是最完整的，但使用人數卻是最多的，應該是這2個原因配合而成的結果
缺點是好友人數太多,目前我的Linebot並無法進行發送主動訊息,因為主動發送訊息所產生的費用會讓我破產XDD
這感覺是實體的DDoS XDD
確實是DDoS...但不能全部拒絕 XDDD
對了，這麼多訊息量進來，會不會有掉訊息的狀況發生呢?
這情況我倒是沒有收到user反應掉訊息或不回應的情形
to 佳新,
我們知道，您對於LINE Bot開發技術相當熟悉。除了這個口罩查詢line bot之外，你也曾開發其他Line Bot獲得大獎? 聽說是很高的獎金嗎? 怎麼會有這樣的機會呢?(對有興趣的開發人員，是否有所建議?) 此外，您這次開發的口罩查詢line bot似乎用了非常多的 emoji, 是有什麼特別的考量嗎? 這樣開發起來，會不會比較麻煩呢?
LINE 是國人每天都在使用的手機 App 之一，只需要加為好友就能夠使用，在推廣上很方便，因此非常適合作為服務的入口，而且大部分的功能也都能夠在 LINE 的聊天視窗或者 LIFF 網頁裡面實現。
說到「尋找口罩」為什麼只使用 emoji ，主要訴求是大量運用最合適的圖示（例如：成人、兒童、電話），讓重要資訊在文字當中更能夠脫穎而出、一目了然，於是捨棄了卡片式的左右輪播的排版方式。
另外剛好 David 提到比賽的部分，政府和民間每年都有許多有趣的競賽，非常推薦有志之士參加，我們自己經常使用 LINE 聊天機器人技術去實現點子，因為如同前面說的，非常容易推廣，去年有幸獲得創業歸故里競賽的冠軍，幾乎所有知道的 LINE 技術都用上了，包括 LINE Beacon 。
最近我也常遇到有人問，有了百萬好友數，有沒有賺到一些錢 Orz...(人客啊,完全沒有,都是免費服務的啊)
@NO.18 僅代表百萬用戶(我也有裝，我也是1/1000000)感謝您的熱情與堅持。
+1 
我也有問題要問 twdeveloper (舉手舉手)
聽說您開發的LINE bot有一個與眾不同之處，就是可以主動推播藥房的口罩剩餘數量給用戶，還可以讓用戶設定想要收取到的時間? 關於這部分是怎麼實現的? 是使用了什麼特別的功能嗎?
哈，這個是我超愛的功能。
LINE一直有一個LINE Notify的機制，可以推送訊息給用戶。過去LINE官方帳號發訊息免費(或極低廉)的時代已經過去。但LINE Notify依舊免費發送訊息。
我們把這個機制大量用在替代簡訊、或是IT維運的即時訊息傳遞(DevOps)、客戶通知(Notification)...其實使用起來相當方便好用。速度比傳統SMS簡訊還快，是一個發送通知的好選擇。
我有整理一些介紹在blog上:
https://studyhost.blogspot.com/search?q=line+notify
而我們在這次口罩查詢的Line Bot中，加上了後端schedule的功能，讓用戶可以在設定好之後，定時收到自己關注的藥房的口罩剩餘數量。有別於其他LINE Bot只能查詢，這是一個挺獨特且方便的功能。
to James,
知道您使用的是 Xamarin, 想請問...使用 Xamarin 比起採用原生的開發技術，有什麼優缺點? 對於想要開發 App 手機應用的開發人員，您建議學習 Xamarin 還是先採用原生的技術?
David Tung
對於 Xamarin 的優勢在於能透過程式碼共用機制的部分，來支援多平台的 App 開發，若以 問口罩 App 為例就是 iOS、Android 雙平台。
相信在場的每位開發口罩服務的大大們，相關的口罩資料都是取自於 衛服部 所提供的健保特約機構口罩剩餘數量明細清單 等政府公開資料取得。在 Xamarin 的技術上，例如要完成 App 中的口罩庫存資料就能透過規劃單一程式架構來讓雙平台 App 共用，相對的也使得後續的 App 維護問題也更加便捷。
若是 問口罩 App 在開發時採用的是原生 App 的開發技術，透過 Java/Kotlin 開發 Android，Objective-C/Swift 開發 iOS，那恐怕從開始開發到 App 於雙平台上架問世的時程上，就會再多加約莫一週以上的時間，更別提後續約莫 2 月底時，衛服部所提供的 opendata 有過的格式異動，造成 App 要維護雙平台問題的差異性了。
就開發 App 手機應用的學習經驗上，對於 .NET 開發人員 Xamarin 想必是不二選擇，畢竟使用的是熟悉的開發語言、IDE 工具、線上文件與微軟相關資料的查找。
但通常上手開發後會面臨的一個問題是，今天所面對的 App 執行平台並非大部分 .NET 開發人員熟悉的 Windows 平台環境，而是兩個陌生的 iOS 與 Android 平台環境。
Xamarin 團隊也在這方面下足苦工，努力的透過建置在 .NET Standard 為基礎的相關 Library 套件，例如: Xamarin.Essentials 來協助 .NET 開發者在面對雙平台的差異性問題，不需要額外了解雙平台太多的深入問題，即可達成目的，像是 問口罩 App 當中，要建立 SQLite DB 取得儲存的檔案路徑，在 Android、iOS 的原始作法上有其相當的差異性，但若透過 Xamarin.Essentials 套件的共用方法，再搭配 .NET Standard 的 IO 存取，即可完成此目的。
當然勢必會有不足的地方，但只要你願意，應都可以找到 workaround 解法或是在 Xamarin 的 github 提出良好的 feedback 取得更好的解法。
或是可以到小弟經營的 Xamarin Asia Developers 社群上發問唷 
所以回過頭來思考 David Tung 的學習問題，若是希望 App 在雙(多)平台上盡可能的同時出現，在資源有限(時間、金錢、人力)造成多方角力情況下，也許對於技術人員來說檯面上的 App 跨平台開發技術們，都不啻是個可供選擇使用的方向，當然 Xamarin 會是一個更棒的選擇囉!(老王賣瓜一下
)
To Ian,
聽說Ian最初開始採用的是MS Bot framework，使用這個框架是否有助於您在初期縮短開發時程? 框架本身有何優點? 後續為何會考慮採用其他架構呢?
一開始採用MS Bot framework是因為先前就對MS Bot framework有些研究，技術上也不成問題，另一方面也考慮到想同時間提供Facebook messenger bot，而MS Bot framework搭配Azure bot service可以同時掛接多個平台，為了快速發行應用，所以第一時間就用了MS Bot framework串接Linebot，並且MS Bot framework內建一些對話流程的管理，並且若需要更進一步做到對話管理的機制，使用MS Bot framework會比較方便，但後續因為一些因素限制決定不提供Facebook messenger bot版本，並且考慮到個資問題，也沒有進一步擴建對話管理的計劃，所以現在的版本是採用我自已寫的Line Message SDK封裝Line Message API 來開發的
讚唷~
下次也考慮一下我的 LineBotSDK 嘛(哈哈~ 
To Ian,
我們看到您的這隻Bot, 後來加入了AI人工智慧與語意分析? 這可是最近很時髦的議題，這部分是如何實現的? 可以達成什麼效果? 時做起來會很困難嗎?
前面提到了為了透過最少操作步驟能確實滿足使用者需求，所以我的Linebot一直沒有提供主選單，然隨即我發現還是有不少使用者很多時候不知道如何操作，不知道Line可以發送定位點，所以我先利用Line平台的功能，當使用者將bot加為好友時，主動發送一則訊息並且把簡單的操作指示加入訊息內，接著有些使用者並不想分享位置資訊但又想查口罩，所以解讀文字訊息還是有必要性，並且有些民眾因為買不到口罩會開始產生抱怨，轉而用文字做情緒的發洩，所以做為一個Linebot，完全無法回應文字訊息也說不過去，因此為了解決以下需求，就必須納入語意分析
剛好之前對於Microsoft Cognitive services裡的Language Understanding Intelligent Service(LUIS)滿熟悉的，因此就利用LUIS訓練這個口罩Linebot的語意分析模型，以Web API服務的方式結合到Linebot裡，整體實作上並不困難，主要還是在LUIS訓練上是否能明確區分語意。有關LUIS的部份，在我的blog上也有幾篇文章在談LUIS，有興趣的朋友們可以上我的blog(https://dotblogs.com.tw/ian/Series?qq=LUIS)
to Everyone,
儘管各位大師都是非常有經驗的開發人員，但這次的需求來的又急又快，且具有許多的不確定性。不知道開發中是否有遇到哪些困難點？各位大師又是用什麼工具技巧來解決？
面對需求的不確定性，或是緊急的需求，各位大師對開發人員有什麼建議?
不確定又快速的需求，考驗的是程式碼品質，在這個例子中，幾乎沒有時間測試，完全就是屬於改即上狀態，事前的 devops 流程很重要，我是使用自架的gitlab 來處理這塊
DevOps(CI/CD)的部分，我自己是透過 Azure DevOps，對於開發人員來說(不管是不是 .net開發人員)，Azure DevOps都是一個非常好用的開發流程管理工具。內建了看板(KANBAN)、Git Repos、CI/CD pipeline...算是相當完整。可以快速的實現CI/CD Pipeline...
更重要的是五人以下團隊免費...很夠意思。
講到Azure DevOps，我忍不住要推廣一下...小弟的拙著...
https://www.pubu.com.tw/ebook/188715
(歡迎舊雨新知支持指教)
我個人是使用trello做簡單的看板,安排要做的工作順序及進度,至於CI/CD就沒有時間做了XDD
在開發的過程，我使用「精實創業」的原則，先打造 MVP 最小可行產品，所以我首先要驗證的是能否從開放資料集裡面抓出健保特約藥局的 GPS 座標，再去換算與目前所在位置的距離，上網找了好幾篇資料，發現需要用到三角函數（因為地球是圓的），有了距離就可以畫出方圓 10 公里的範圍，篩選出還有口罩的藥局，這個部分距離換算和篩選的作業花了不少時間。
補充說明，我每次有新功能，都會發一篇介紹貼文到臉書，親朋好友就在在下方留言許願，一旦實作出來，就可以滿足到更多有同樣需求的人。所以是看留言和反應，沒有特別用工具管理。 ^_^
感覺三角函數還是有必要認真學的 XD
sin cos....塞到嫑嫑的......
DevOps(CI/CD)的實踐部分，問口罩 App 有透過 App Center 搭配 GitHub Repo 來做到這方面的實踐。
App Center 對於 App 開發人員來說(不管是不是 Xamarin 的 App 開發人員)，都是一個非常好的協助開發 App 平台。串接好 Git Repos (雖然在 "問口罩 App" 是串接 GitHub，但 App Center 也可串接 Azure DevOps、GitLab...等)之後，若開發人員完成某項功能時，將程式碼 Commit 到串接的存放庫後，App 就會開始自動在 App Center 上建置，若建置成功後，就可視需要立即將需要測試 App 推送到能協助測試 App 的人員手上；若建置失敗，也可從相關的 Log 了解到問題立即讓開發人員做修正。簡而言之就能透過 App Center 來完成整個 CI/CD 的過程。
最終若也完成相關的測試階段後，若有做好 App Center 與 各平台的 Store 發布串接設定，也可以直接從 App Center 把 (Android: apk or abb; iOS: ipa)推送到雙平台的 App 市集中等待發布。
BTW, 前述問題的回答中有提到 App 被 Google Play 直接下架(申覆到重新上架，大約花了兩週)，此時也能暫時透過 App Center 的測試下載，讓使用者暫時取得新版 App。
to everyone,
我們知道開發口罩相關應用，資料來源都肯定是透過政府單位的open data而來，此次串接open data的過程順利嗎? 是否有什麼需要注意的事情可以和讀者們分享?
另外，面對系統必須常常更新口罩剩餘數量這件事情，各位大師是怎麼處理的? 是需要在程式碼當中做一個schedule job嗎? 還是怎麼處理定時的更新呢?
流量的容納度，一開始其實蠻順利的，後面則開始發生健保局資料下載緩慢的問題，網友們則提供了 github 的分流，整體上來說，這次 github 幫很多忙啊(笑)，
我的例子是利用 .NET Core 執行於 NAS 之上來排程下載，這個模式好處是可以脫離 Host 的限制，也可以進行持續的資料分析，例如開賣時間，消化速度。
(C# 的 LINQ做資料分析很好用，有興趣的朋友可以關注 Skilltree 的 LINQ 課程啊，https://skilltree.my/)
open data是開放資料，但不意謂著一定滿足開發者的需求，以這次口罩為例，必須串接多個不同資料才能同時具備藥局基本資料＋口罩數量，所以開發過程必須先做點資料處理的工作，另外有時候資料難免有欄位值遺漏的情況，所以在程式邏輯上必須配合增加一些處理邏輯，而有些資料open data可能沒有，例如藥局基本資料只有地址，沒有經緯度，所以如果要做距離的計算，就必須自已想辦法處理經緯度問題，此外也曾發生過口罩2.0上線時，open data資料來源掛了，因此應用程式內也相對要考慮到面對這個現象該如何處理，像是應用內保留快取備份等等
口罩數量的更新，我自已做法是應用內會有一份快取檔案，當快取檔案超過更新時間時，會在第一個請求發進來時，同時更新最新資料，如果快取檔案時效還未超時，那麼就會以快取檔案做為資料來源，這麼做的考量是，原始資料來源更新頻率並不是每秒（實際上也沒必要），如果每個請求都直接向原始資料發出請求，那對效能是有影響的，也可能是多餘（因為資料可能相同）,如果有考慮做資料分析,那麼排程處理資料下載就有必要了
因為 github 那份資料集更新很快很即時，大約 30 秒就會更新，所以初期都是 on demand ，有用戶查詢就會去撈一遍資料集，確實曾經也遇過幾次資料集掛掉的情形，所以後來會用 crontab 每分鐘去撈一份副本，當 LINE 聊天機器人查詢 github 沒資料時，會轉而撈這份沒那麼即時但也夠用的資料。
再次說 github 是本次最大的貢獻者 XDDD
對於 opendata 的看法跟 No.18 的回應概念是類似的，在此也很感謝 No.18 分享藥事機構的地理資訊給小弟，讓小弟在前置準備作業上能更加的充裕。
原本 App 的設計上原本是直接取用 data.gov.tw 的口罩庫存資料，但在 App 發展初期就發現這個資料集的回應有發生主機癱瘓的可能性(可能是當時太多不同的應用同時上線)。
後續就利用 Azure 上的 Serverless 服務 Azure Functions 設定了 Timer ，將衛服部提供的 opendata 口罩庫存資料定時擷取到 Azure Storage 服務中的 blob 儲存，再讓 App 對自己建置的 blob 取得口罩庫存資訊。
當然 App 當中也有設計其更新口罩庫存資料的時間間隔之限制(恩...當然還是怕服務太燒錢)，不過這未來有機會再來專文討論的架構設計問題討論了。
to everyone,
各位大師能否談談您學習程式設計的經驗? 從開發第一個系統到今天，經過了幾年的時間? 資訊領域瞬息萬變，面對這麼多新的技術，你會不會覺得疲憊? 您覺得開發人員應該廣泛的學習?還是挑一兩個領域深入研究? 除了工作之外，每個月大概花多少時間在學習新技術上?
寫程式至今已經 25 年，專精跟廣泛是兩個極端，專精的缺點是容易被潮流所淘汰，廣泛的缺點是容易流於表面，我認為開發人員應該挑一個領域專精，另外把心胸放寬，接納別的技術來達到懬泛，我每月都會挑選幾本書看，不見得是熟悉的領域，但沒事練身體強身也不錯啊
從事程式設計領域有17年的時間，目前資訊領域變化真的越來越快，說真的要大範圍的涉略真的是考驗體力，我個人是採取先多聽多看(有很多資訊媒介要做到多聽多看不難)，做初步的吸收，然後評估哪些東西是目前我可能用的上，再優先深入學習，或是哪些是前景看好（但有可能眼光錯誤，投資有賺有賠，請詳略公開說明書...笑)，優先做技術上的POC評估，至於每個月大概花多少時間在學習新技術上，其實沒有細算過，但平均每天1~2小時應該是有的
每天都會逛幾個社團，每個月也會定期參加幾場小聚，可以從網友的問題討論、從 Keynote 和閃電秀講者的身上學到很多知識，再挑有興趣或者跟工作有相關的部分去深入鑽研。
小弟是看上面各位大大們的書籍與文章讓技術有更多的成長的!
個人學習技術疲憊的時候就會轉換個事物去關心(看看家裡哪裡髒了，清一清；看看周邊哪個家電怪了，整一整)，個人是覺得這樣效果還不錯。
BTW，因為家裡有喵星人常駐，跟喵星人互動也能有很好的紓壓並轉換心情
大家都是我值得學習的大師～
to everyone,
各位大師平日工作如此繁忙，是否還有時間讀書呢? 有沒有什麼書籍是各位大師最近讀過覺得值得推薦給開發人員的?
最近在看有關系統架構的書籍，microservice、DDD，其實系統架構的演化並沒有想像中的大，大家只是在解決以前沒能力或是時間解決的問題，程式碼品質也一樣，兩位馬丁大叔的書都值得一讀
https://www.amazon.com/-/zh_TW/Clean-Architecture-Craftsmans-Software-Structure-ebook/dp/B075LRM681/ref=sr_1_1?crid=3S2SPIGTQK3Z4&dchild=1&keywords=clean+architecture&qid=1588652575&sprefix=clean+archite%2Caps%2C505&sr=8-1
Clean Code、clean coder、Clean Architecture這幾本書，我還滿推薦的，尤其是已經有一定經驗的開發工程師，程式不只是CRUD也不只是會動就好，往更深的層面會發現其實還有很東西是值得討論跟學習的，進而影響到程式碼品質，這幾本書帶給我很多收獲推薦給大家。
程式資訊領域的經典書籍就是大大們提到的上述那些，只要自己願意精益求精，百尺竿頭更進一步的努力，就一定能更加提升自己。
倒是因為一個團隊工作的過程，無論是擔任何種角色，免不了需要多方的溝通。所以，想推薦一些比較軟性的書籍給大家閱讀，例如: 有些話，這樣聽那樣說，更好。
雖然書籍版面上有點 "被騙" 的感覺(與資訊類相關書籍相比)，但其實很多書中的論點都值得好好玩味。
我想請問如何成為 LINE API Expert
可以參考底下網頁:
https://www.line-community.me/contributors/request
工作之餘可以多參與由社群舉辦的實體活動，chatbot/linebot社群每個月都會有相關的小聚，除了可以認識更多開發人員之外，也可以在聚會中上台分享自己的技術成果或經驗。同時也可以透過blog, youtube或FB對開發人員或社群進行分享，這些積累都是成為LAE很好的助力。
Chatbot Developer Taiwan 歡迎常來做！
https://www.facebook.com/groups/chatbot.tw/
NiJia 這個置入好呀!!! 
這裡就有三位 LAE，還不置入！！
我可以請問如何成為微軟MVP嗎?
除了推薦人之外，要成為MVP必須累積一些專業能力的表現，例如社群分享你的技術知識，blog分享技術成果或經驗，都是評選MVP重要的參考指標，之外MVP都是每年要renew的，所以必須強迫自已不斷的精進
MVP都是每年要renew的，所以必須強迫自已不斷的精進
每年喔! 各位!!
補充一下，現任的 Microsoft MVP 也可以提名。
繼續請教 twdeveloper 唷!
我們知道你有針對 LINE API 開發給 .net / .net core 的 SDK，並且上架到了 nuget, 我相信你肯定也是採用自己的 SDK 做開發的吧? 使用這套 SDK 有什麼好處呢? 可以跟大家介紹一下?
LINE有提供一整套 Web API給開發人員。透過這組API，可以控制LINE 官方帳號與用戶之間的互動、訊息回應...等。
但由於官方並沒有提供.net SDK給使用C#/VB的開發人員，因此我們在LINE的Web API釋出初期，就自行開發了這套LineBotSDK，目前不僅支援 .net 也支援了 .net core，並且是nuget gallery下載次數最高的LINE Bot開發套件。
透過這個套件，可以讓.net技術人員在非常方便的狀況下，來開發LINE Bot，不僅僅支援 LINE Bot，也支援 LINE Notify, LINE Login, LIFF...等。
在套件中我們還順便整合了與MS LUIS/QnA Service相關的語意分析模組，也因為有這個套件，我們可以在此次疫情需求急迫的狀況下，迅速的完成LINE Bot開發。
有興趣的讀者不妨可以嘗試看看:
https://www.nuget.org/packages/LineBotSDK/
這邊也有相當完整的電子書介紹:
https://www.pubu.com.tw/ebook/103305
To Ian, 佳新,
為什麼選擇做LINE bot？而不是用App或其他的平台?(像是telegram, FB Messanger...etc.) 開發 LINE bot會不會花很多時間？ 該怎麼決定要提供什麼功能呢？
選擇做LINE bot主要考量點是，Line是台灣民眾很熟悉的APP，介面操作熟悉度自然不是問題，再者實作在Linebot上，並不用花太多時間做使用者介面的設計，最後則是要讓使用者隨手可用，在手機介面上相較於Web，Line的介面會有比較好的操作及顯示性，而APP則是要面臨上架審核耗時的問題，所以也不在考量之內。開發時間倒還好，因為我有自已寫了Line Message SDK，所以用C#寫起來很快，而功能的設計上以簡單易用，滿足使用者最大最迫切的需求為主，所以主打以定位點找最近藥局及口罩數量為主軸。
嘿啊，同意樓上，再來是長輩們可能不會安裝 App ，也不會開瀏覽器，但是會掃碼加好友，所以就決定用 LINE 聊天機器人來做了。
雖然 David Tung 大大沒有點名到，但是這邊也是要再來老王賣瓜一下 App，由於在介面上 App 會更有設計上的彈性，可具有更多樣性的資訊呈現，並與既有的 App 之間的 Ecosystem 充分互動。
但因為此次案例來的又急又快且應用場域特殊，較沒能有機會完整的規劃 UI 並與展現其 App 之間的 Ecosystem 的互動特性，是較為缺憾的地方。
至於 App 審核耗時，甚至 "被下架" 等問題，這不可否認的是 App 應用發行的痛點，所以若把 "疫役" 與 "場域" 等問題若也都考量進來時，此次 LINE bot 確實會是個比較好的選擇。
對了，這次最重要的是零時政府網站，有志參與政府相關案子的朋友，可以到這裡看看哦
https://g0v.tw/zh-TW/
to 佳新,
對了，您的 LINE Bot聊天視窗下方，為什麼沒有一般常見的漂亮的圖文選單(Rich Menu)呢？是否有特別的考量?
哈哈，單純是因為趕著上線，沒有太多時間和精力製作圖片，再來是這樣可能比較有駭客松的氣氛（咦），所以使用 Quick Reply 快捷按鈕來取代漂亮的圖文選單。 ^__^
to 佳新 & 各位大師,
開發這類的GPS應用時有遭遇到什麼困難或者有趣的事情嗎？
有地址，沒GPS 位置，還好網友提供了整合性的資料，我的例子是5 公里附近的點，這倒是不難，以前就做過，有趣的事當然是開台一小時大家陸續被打爆 lol
開台一小時大家陸續被打爆 lol
前期是先使用google API把所有藥局GPS位置找出來，做為Linebot的資料計算距離使用
我是大約凌晨 2 點開發完，隔天就從彰化開車南下去屏東，在嘉義附近經過北迴歸線時，突然發現篩選出來的健保特約藥局全都錯亂了，才驚覺 GPS 座標轉換距離的公式有誤（正負號的問題），趕緊在後車廂打開電腦 debug ，哈哈。
這時候就應該買台特斯拉自駕，就可以邊開邊Debug了(大誤..)
各位開發大師能否簡單介紹一下各自選擇的開發技術? 我相信主要原因肯定是因為熟悉，但除了熟悉之外，是否還有其他原因讓您選用這個技術?
對於目前的資訊技術人員來說? 好像跨平台與跨領域變成了某種潮流? 一個開發人員是否真的需要同時熟悉前後端、或是同時學習Desktop/Web/Mobile領域? 還有 IoT? 雲端? 這些不同領域的技術，是否在未來都是"一個"開發人員所必要的?
我的架構是 PHP +.NET Core + Javascript，用 PHP 是因為空間只支援 PHP，.NET Core 是想看看 NAS 上的支援。
現在是不分前後端的時代，以後會更加明顯，javascript可前可後，C# 加上 webassembly也是。
我的架構是用 PHP + MySQL 來開發 LINE 聊天機器人，雲端主機在東京，手機跨平台的問題， LINE 已經幫忙解決了。選擇用 LINE 是因為受眾用戶的年齡層很廣泛、只要加好友就能使用，在推廣上相當便利。
這次我用技術有C#程式語言、Azure、LUIS、Line Message API，主要還是在於熟悉度，另一方面考慮到使用人數，基於擴充彈性，所以雲端環境無可避免會需要用到，因此選擇Azure做為我的Linebot Host的雲端環境，看中的是背後營運商Microsoft前三大雲端平台（出事可以有個墊背的推...大誤XDD)，自然有一定水準的穩定性，至於跨平台因為是Linebot自然也沒有這方面的困擾，不過現代化的資訊系統架構常常面臨很多的挑戰，以致於必須有不同的應對策略，所以現在的開發人員沒有帶個2~3把刀，通常很難解決敵人
此次過程所使用的技術、服務、工具有:
想問說 有大師有做過類似於 Excel RTD的報價嗎???
在Excel RTD裡面 加入WebSocket，去回傳報價
因為我Excel RTD是購買人家套件才用出來的...可是安裝Nuget的WebSocket套件不是每一個都能裝...寄信問了作者有沒有推薦的WebSocket套件也告訴我沒有任何可推薦的...
想問說有大師有推薦的WebSocket套件可以裝在Excel RTD的嗎?
或是也有其他推薦的Excel RTD套件?...
歡迎各位一起來投稿 COSCUP - 「Open Source Chatbot」
分享給更多人知道～
https://pretalx.com/coscup2020/cfp?track=265-open-source-chatbot
iThome鐵人賽
看影片追技術