對你們來講，怎麼樣比較簡單？
所以我舉一個例子，像現在是一個外部廠商，然後他給你的，你不希望他丟blob給你，而是希望丟一個網址給你，這個是上傳的類似欄位，只是檔案暫時放在這裡而已，但是一收到之後，會自己放一個附本來這裡，因為你的資料庫要存。
但是這個檔名是一致的，像我們用uuid或者是什麼東西，對你來講，其實有另外一份放在中介的廠商，這個事情你並不是真的很在意，技術上也沒有什麼需要修改的地方，而且這樣子還有另外一個好處，就是你這邊也有一份，真的發生什麼事情，還可以看你的log，是這個意思嗎？
好，我們就這樣處理。
請問目前是用拉取回來看自己的狀態，或者是會用推送的狀態會主動告訴他？
所以走的是SMTP，並不是走簡訊或者是LINE？
如果是純SMTP的話，非常好，因為中間這個機器也可以是SMTP server，先寄給我們，我們收到再寄給使用者。
從我的角度來看，你們改越少行越好，當年有留一個email，也許我給你的，其實就會是長成好比像mail叫做「 foo@example.com 」，這個隨時都可以用，是這樣子。
但是這在中間這一台裡面轉成UUID，這邊看到的其實會變成一個完全一樣的，好比像「hike+7F76FC98-B535-4B90-86C7-0F2AC8A52F2E@…」，這邊就uuid，然後後面一定是「….gov.tw」，所以來你這邊申請的是，透過新系統的人是長成左下角這樣子，所有的程式都不要改，照樣寄信，我們當然就得來剖析這個信了，所以後面@是這樣的話，信的格式就可以改。
補件也是透過email嗎？
我怎麼知道要補件？
所以還是email，因此我們中間還是會知道，當你需要它做什麼事的時候，中間這邊一定會知道。
你是說補件的介面嗎？而不是審查員的介面？
簡單來講，就把這個當作無障礙設計，明眼人能夠用的，盲人也可以用，你用的東西是flash，盲人真的很難使用，必須做出簡單版，讓盲人也可以使用，機器是一種盲人，所以你的補件這一件事，如果它是在介面，如果我們走Plan B，你這個介面不要動就是了，我們自然會有另外一個虛擬補件介面來操作你的實際補件介面。
第二，如果要走Plan A的話，你的補件介面，就生出一個相應於在網站上能夠操作的API，也是用OAS 3來描述就好了，所以大概是這個意思。
基本上使用者在你這邊有做的操作都做，應該是說沒有任何的遺漏，不要說有哪一些東西忽然間又跑回你們家再操作，不如一開始點開四個視窗，就像現在的整合網一樣。
應該要這樣講，如果你的查詢介面相當老舊，然後你要走Plan A，就把那個database轉出來就是了，不要畫那一頁，有什麼資料就吐什麼資料，這是最簡單的。
如果這都要做Plan B的話，很命苦的中介廠商就要爬HTML資料，然後想辦法還原成結構化，可是即使是這樣子，應該也可以做得到。
但如果我們10月中這個系統還不完全能夠上線的話，當然我們未來可以再把這個做得更豐富，但是我想從爬山者的角度來看，我以前爬過哪一些，這個系統還是會需要的，因此我建議規劃的時候就規劃在裡面，但是確實上線節奏是可以放在稍微比較後面一點，大概是這樣子。
可以申請、查詢，發生事情了，可以通知他，抽籤中或不中，就是可以完成一個流程。
他們用慣了，不要打擾他們，後台的部分，你打擾他們，我們不能做一些便民的事情，讓大家省一小時，讓不幸的公務同仁多花一個小時，這樣的改革絕對不會成功，所以大家用慣介面就用那個介面，現在只是說山友並沒有覺得點開四個頁籤是大家習慣的頁籤，事實上他們用的非常不習慣，因此這樣的情況下，我們把他們的生活弄得好一點。
但是如果要讓管理人員等等，讓他們的生活好一點的話，這可能不是我們跟山友的協作會議可以解決的，可能要重新調查一下他們那一些利害關係人，自然也沒有10月上線的問題。
謝謝。
當然啊！如果有人就是要下載windows的報稅軟體，報到一半還會有一個娃娃跳出來說「感謝你對國家的貢獻」，他看慣了標楷體，你不能阻止他。
就不用提供服務，非常簡單。如果在你這邊申請的話，email的連結都是你們家的，如果裡面有內嵌網址或者是QR code，當然都是到你們本來的平台，我們系統是這樣設計的。
我們攔截住本來要寄給使用者的信，然後我們不發那一封信，把它扣起來，我們發那一封信，那一封信的網址是新的。
我們一收到什麼也好，上面logo是你們的網址、文案，這邊自然會有我們的網址、logo跟文案，看起來是兩個完全不同的網站，只是剛好可以做同一件事，跟你兩個方法都可以報稅是一樣的道理。
可能是一部分、一部分，這個你們要想一下。
因為要自己做？
你們要自己做就自己做。
B是別人做。
當然可以啊！如果你們公司很大，另外派一組人做Plan B，這個我們都不會反對，自己砍自己的站，當然這樣資安攻擊表面更小一點，這個是很棒的事情。
只是從採購的角度來看，因為這是指定廠商了，所以我們要知道的只是他們的指定廠商上，要填你們的名字或是要填別人的名字，我們只是要知道這一件事，至於你們自己砍自己的站，說真的從公務同仁的角度來看，是沒有什麼差別。
就是本來那一組人去煎蘿蔔糕的話，你們有沒有什麼別的組員可以做？
我們都同意，這個是你們可以自己決定。
前端等一下再討論。
好。所以剛剛處理三個後端系統，還有別的嗎？語言的部分是另外的嗎？後端系統先確認大家手上都已經沒有問題了，沒有一些額外別的系統嗎？
當然。
當然，其實臺灣的Plan B產業，也就是搶票機器人，那是非常蓬勃的，不管從車票到演唱會門票，都有許多寫機器人的經驗，所以專業度應該不成問題，這就是黑帽轉白的概念。所以大家在專業度的溝通上，應該不成問題才對。
如果後端都確定的話，我們會做成會議紀錄，我想會後大家也可以給做會議紀錄的朋友們一些指點，怎麼寫、怎麼樣的文句，才能讓大家對於政風、主計及長官等等都能在最短的時間內爭取到剛剛的那一個工項及資源，然後大家一起去做採購的動作，所以這個是後端的部分要麻煩大家幫忙的。
那就是前端了。應該這樣講，Plan B的每一條線，可以是一家不同的廠商，這是併聯，並不是串聯的概念，所以要一個月做完，並不是同一組人簽這個後端的Plan B，又簽那個後端的Plan B，這要三、四個月才做完，所以要一個月做完，勢必要同時讓三組不同的人，幫各位三個不同的後端來建立一個API的介面，如果願意認領半組去，那是非常好的，但是總之我要講的是，林務局或者是這邊也好，大家用90萬招標的對象，很可能到最後三個都不一樣，所以這個是實際上的狀況。
老師想要問的是，假設大家都如期如質完成，到底是誰把這三個長得完全不一樣的API或者是四個不一樣的API來統合前端可以做的事情，這個是前端廠商的工作。
所以最後會用到等於五個90萬？
我們現行的整合網就不去動它了，現行的就長現在這樣子，也許很多朋友很喜歡看試算表跟打勾的介面，及有些人很喜歡標楷體，每個人有美學上的堅持。
我們現在做的是新的網站，這個是不同使用者不體驗，而且10月上線的時候，真的只讓一部分的人使用，而且說不定可以抽籤——開玩笑的——所以在這個過程中，我們必須要讓舊的整合網可以持續網站營運，所以勢必營運團隊一定是不同的人，這個是很明確的。
像剛剛老師提醒的，並不是四個後端要想，而是全新的前端要想，如何想成人類可以理解整合式的流程，這是完全不同的技術專業，所以我們才會請不同的人來做，因為能夠做API建置的廠商，碰巧又非常懂前端的服務、互動設計，這是非常難能可貴的一件事，我們不做這一種想法，而且有這樣能力的人，90萬大概也請不起，這樣的情況，我們儘量把工項去做細的切分。
這個議程過了的話，我們就往前端走了。
前端仍然是90萬的話，還是從這邊發包，是這個意思嗎？
對。在場有人想要當前端嗎？在我們去問別的廠商以前？
