一連串奇蹟換來一次成為講者的機會 feat. Mopcon 2019
前言
Hi！大家好，我是神 Q 超人，今年非常幸運能夠將自己第一次的講者經歷奉獻給 MOPCON，其實現在如果再來一次，
就和當天整個上午的狀態一樣，但既然一點都不上手，為什麼還要打這篇文章呢？因為對我來說這機會就像天上掉下來的一樣，如果不想辦法做一點紀念，怕幾年過後我就會忘記那個胃液快衝出喉嚨的感覺 😂
然後先聲明一下，不能說這篇文章會帶給在觀看的你們什麼幫助，但如果大家有一點點好奇在講者（至少是我 XD）背後的故事，也許可以試著看下去，本篇文章會掏心掏肺掏肝掏胃，把還記得的過程通通都說出來，看完後或許明年大家也能考慮衝個一波 🙌
為什麼要投稿？
其實想法很單純，
而且一開始其實也沒有打算投 MOPCON，最初是在閒逛 itHelp 的時候，突然看見「鐵人賽結束，然後呢？」之類的廣告，點進去是 Modern Web 的徵稿資訊，一時興起就想說，
結果怒收一封感謝信 😭
雖然當初就沒有抱著會中的心情，但説不難過還是騙人的，灰心喪志地想說我可能沒有這方面的天份，還是繼續打文章修煉好了。
後來因爲有個同事是 MOPCON 的工作人員，她就告訴我：「不然你修一下稿子，再拿來投 MOPCON 啊！」，聽到後其實我很猶豫，猶豫到截稿前最後一個禮拜都還沒有辦法下決定，
其實我也沒有想過自己那麼玻璃心 😂，我一直以為我是個放的開的男人，結果發現原來我放不開，後來的我是在非常非常強烈的決心下，強迫自己重新寫過稿子，再戰一次 MOPCON。
雖然按下送出投稿的當下心裡還是非常忐忑，不過真的很感謝當時的衝動和勇氣，才能夠幸運地得到這一次的機會：
稿子內容怎麼寫的？
大家可能會很好奇這一段，如何把自己要講的議程描述出來投稿，這點也是我非常頭痛的地方，但因為經歷了 Modern Web 的失敗，讓我在重新寫稿前，更仔細的思考為什麼被 Modern Web 給婉拒，最後大概是歸納了一個主要原因，那就是
因為第一份稿子太像在寫文章，
於是在投 MOPCON 的時候，與其去修改投給 Modern Web 的稿子，不如整個砍掉重練，而這一次在寫稿的時候，雖然也是用寫文章的方式，但我多考慮了議程的節奏，大概的格式架構分成以下幾個部分：
- 簡單描述議程想要分享的是什麼，內容有什麼特別之處，和別人有哪些不同。
- 考慮受眾對議程主題的了解程度，決定以哪些觀念切入，這些觀念帶給聽眾什麼。
- 切入後，以我的議程來說，思考大家可能會遇到哪些問題，以遇到的問題再帶出自己想表達的議程核心，這些主要都是站在聽眾的角度，來擬出議程稿子的內容。
- 最後的整合階段，就是替聽眾整理在實務上能得到的實際效益是什麼？有可能會遇到的問題還有哪些？等等……
但因為我的議程是講解技術概念的類型，如果大家打算以其他類型做投稿，可能就不太適合用以上幾點架構，但是不論是哪一種類型的稿子，
至於我對稿子最有自信的地方可能就是「分享實務經驗」這點，因為不論是何種技術都可以在網路上找到，但實務經驗就是很寶貴的內容，建議大家可以著重分享這個部分，讓議程變得與眾不同。
訪問時間
對！但是光是我講完全沒有任何公信力對吧？記得我上方提到的同事嗎？其實有參加 MOPCON 到最後的大家應該都有看過，她就是 MOPCON 2019 最後一場 Keynote （職涯論壇 — 接下來要繼續當工程師，或者轉職到管理職？）的主持人，
因為一直很扼腕沒在議程上自我介紹到，所以這裡就幫她一把了：
她非常大方的就答應我的訪問，我也整理了三個應該是大家最好奇的問題請教她，讓大家以後如果想要投稿，但又無法決定主題時可以參考：
一、議程的審核的方式與流程？
Brook：首先我們會依照該年的主題來組織議程委員會，委員們負責對投稿與推薦講者做內容品質的審核。雖然議程委員們都非常低調，但大家還是可以在官網的主辦社群看到各自年份的委員會成員。
收到投稿之後議程組會進行初步整理，再送給議程委員審核投稿內容。在審查時議程委員們可能會針對特定的面向給予投稿意見或評審想法，並在結尾歸納出適合 MOPCON 與否的建議。
基本上，每位議程委員著重的部分都不太一樣。有部分議程委員非常重視分享與社群交流的精神，如果在會後不能提供任何紀錄（簡報等資訊），讓後人參考學習會扣掉很多分數。也有一部份的議程委員對於喜愛的講題，會在表單上註記感覺很精彩、想聽這個議程之類的意見！
最終不管有沒有通過審核，我們都會把委員們提出的寶貴建議與和投稿者較相關的意見，以匿名方式轉述給投稿人，希望能藉此讓獲選者能把講題修飾地更佳臻善、落選者也能藉此改進未來的投稿內容增加獲選可能，但如果沒有相關的意見可能就不會收到。
最後，議程組才會依照審核結果，進一步以「 MOPCON 的會眾角度思考，組織出吸引人的精彩議程」為原則，來考量稿件的取捨。
二、什麼內容的投稿會比較受歡迎？
Brook：除了要符合該年主題外（通常會標註在投稿的頁面上），最重要的一點是一定要提供足夠的資訊，讓評審可以充分暸解，甚至能夠想像你大概會講什麼、怎麼講。
以內容組成來說，根據過往的經驗，在講題中帶入故事會更吸引會眾。如果講題是偏理論、技術的內容，那藉由故事可以讓會眾更容易吸收與想像。另一方面，如果是偏應用的內容，也能以故事帶會眾進入那個情境、發現並解決痛點。
所以推薦在投稿時規劃適合的故事，幫助評審更輕易地暸解內容。
三、哪些類型的主題容易一看就刷掉？
Brook：除非違反規則，否則絕大多數的投稿都不會直接刷掉，但誠如第一個回答所說，最重要的一點是避免提供過少或難以理解的內容，如果連稿件都寫得不清不楚，也很難說服這樣子的表達能力在台上能發揮多少。
除此之外，也會評估這個講題是不是已經有非常多的資源（在網路或書籍等等），以及在這次是否有提出任何新意或經驗。
沒想到在投稿之後，MOPCON 的議程委員與議程組還需要做那麼多的工作，在這裡微薄的對他們說聲辛苦了 🙌
會前準備
真正的考驗其實是在 Get 錄取通知後，不瞞各位說，在收到錄取通知後我就先跑日本玩個一趟（其實是早就規劃好了 XD），結果回來後才明白什麼叫做地獄，因為從來沒有演講經驗的我，第一次居然就登板 MOPCON 這種大場合，
但通常過了幾分鐘後就又認命回到電腦桌前，繼續在 HackMD 上敲敲打打，一開始我是打算先把所有能講、瞭解的東西都打上去，最後再根據內容刪刪減減，並整理重點到簡報上。
於是計畫 A 就真的讓我打了很多亂七八糟的東西 😂，後來想想這樣子好像不可行，我應該要有系統性的規劃自己要講什麼，而不是只把能講的說出來，於是我去打開當時投出的稿，想說從這裡下手，先把每個部分要講的東西放到簡報裡，之後擬出每一張簡報要講哪些內容
對沒錯，就是真的那麼硬，沒有經驗的我只能這樣子土炮到底，所以下班後不是在擬講稿就是在背講稿，然後每次背的時候都會錄音下來自己聽一遍，而大概在 MOPCON 開始前的那個禮拜四，我試講一遍給我朋友聽，
在當天晚上，雖然時間已經十萬火急，但我還是做了一件事情，就是把後面那些稿子都砍掉，不背也不講了，因為在沒有任何畫面的狀況下，要用說的去描述如何寫好測試案例，以及遇到的問題和怎麼修正真的太困難了，想到聽眾可能也沒見過測試案例（結果在議程中我有詢問大家有沒有寫過單元測試，結果大概 95% 的人都舉手哦！），就橫了心決定直接現場 Coding 了！
所以當天禮拜四又開始思考該以什麼樣的例子來帶入，在時間不多，希望一切從簡的狀況下，我準備了一個基本的 JavaScript 函式、計數器的 Component、還有 Mock 的應用這幾個例子（雖然最後時間還是來不及讓我全部講完，只能在 QA 時間補充 😭），隔天禮拜五我又請朋友再聽一次，回饋就都還不錯，只是 Live Coding 的劇本還要再練得更熟，而這時候也就已經是當時在議程上講的內容了！
這裡附上一堆版本的 HackMD 😂
議程當天
當天真的緊張到爆炸，就算在講者休息室吃了一堆麵包餅乾（真的很好吃），也沒有辦法平復那緊張的心情，於是只好跑到會場內四處晃晃，然後聽聽其他人的議程（這時候一直常駐想吐胃液的狀態），到開講前五分鐘在台上準備時還是非常緊張（我很直白的告訴議程廳裡面的工作人員說我好緊張，他還安撫我 😂，真的很感謝）
最後終於開始了，這時腦中是一片空白的，只想著把練習過的東西全部講出來，除此之外也沒有其他任何想法，而且不知何時場內已經坐滿人，後面也站著一排，其實很怕越講人越少（還好沒有，感謝各位捧場 ），另外很值得提的是，在議程中我看電腦或簡報的時間其實很少，眼神都忙著與台下的聽眾四目交接，特別感到很溫馨的是與我交流到眼神的聽眾都會給予肯定的點頭，讓我能越講越有自信，非常感謝 🙏
到結束後，大家還是一直鼓勵我或是對我比大拇指，這瞬間，那些沸騰的胃液才開始平復下來，只能說
只是到最後時間掌控的不太好，導致很多想講的都沒有講到，只能在 QA 時間補充，老實說因為我很怕結束後沒有人來找我，這樣會讓我在 QA 區孤單寂寞覺得冷，還特別拜託朋友當暗樁，要在 QA 時間過來和我聊天 😂，結果出乎意料非常多人，又多聊整整一場議程的時間！而在和大家討論的過程中本身也學到很多！會後也結交到許多新朋友 😃
之後也有和朋友聊到這段議程經歷的酸甜苦辣，特別是抱著頭後悔自己為什麼要投稿、每個夜晚都擔心到底來不來得及準備完成等等，從一直擔心會不會失敗，到最後笑著走出會場的過程，只能說五月天唱出一句心聲：
以上就是第一次成為講者所經歷的過程，也感謝那段時期自己付出的努力，讓我能繼續相信努力不會騙人！
在這裡當作番外篇亂聊一下好了 😂，文中提到說，在議程裡有找到機會詢問大家「有沒有在進行單元測試？」，其實在這之後還有接著問第二個問題：「有在進行前端單元測試的人嗎？」
但是大家仍然願意選擇這場說明前端單元測試的議程，代表其實想嘗試的人是很多的！但是前端的單元測試牽扯到了介面、框架和各種函式庫，基本的測試也許還能夠找到一些 Example，換作比較新穎或特別的用法，就要再多花點時間專研測試方法及最佳實踐！
因此議程結束後我一直在想，是不是能夠有個平台可以讓大家討論關於前端的單元測試呢？以 Facebook 的社團來說，大概就像是 Front-End Developers Taiwan、ReactJS.tw 等等，但搜尋之下似乎沒有，於是
會有這個想法我必須感謝在講者晚宴中遇到的兩位大大，是 好想工作室 的 Chris，他讓我知道原來不是只有我一個人在前端單元測試沙漠中無助的摸索，還有 遠距工作者在台灣 (work remotely in Taiwan) 的創建者艾霖，是她告訴我只要願意就能夠試著去改變環境！現在想起來真的覺得自己運氣很好！因為有了這一切的經歷，所以 F2EUnit.tw-單元測試在前端 就誕生了！歡迎大家可以加入一起討論 🙌
最後本篇文章是依照我自己的想法打出來的！如果各位對講者背後的故事還有哪些想知道的，都可以留言告訴我，我很樂意嘰哩呱啦的分享一堆 😂，謝謝大家！