今天非常感謝大家在午餐時間，過來這邊討論這個案子。由於今天院長主持會議的裁示，literally是剛才出來的，所以我們事前來不及用書面的方式來通知各位，先跟大家致歉。

剛才葉寧已經比較明確的講了一個時程，這個時程基本上跟上次我們在這邊開會的時程是完全相同的，也就是十月有一個初步的版本，讓先期的使用者可以做一些我們挑特定路線也好，特定的用地也好，就不是所有東西都可以用的情況下，讓大家在十月一號可以做一個基本的測試，那十月十五號我們把系統整合上面透過這些封閉式測試找的問題加以修復，十一月一號我們會掛上一個public beta，但實際上是大家都可以用的，那大家用了一定還會有各式各樣的意見，給各位的結案期程說不定要到十二月一號，就是把大家實際測試碰到的問題加以修復。

但是院長比較在意的是說他自己本人，或者景森政委本人，就算一開始不在我們測試的群組，那十一月一號也就可以上去用用看了，應該是這個意思？

（點頭）

那我們就確認院長的裁示。在這個裁示的前提底下，我想我們上次有討論出一個前後端分離的這樣的一種基本的想法，那我就重新再畫一次，因為在場也有上次會議沒有來的朋友嗎，對不對？那我們大概後面的後端可以分成農、內這兩個系統嗎，這兩個系統底下又有不同的系統，有山屋、有自然保護區、那內這邊有警政，以及國家公園，那我們目前有一個cpami，這應該是營建署的一個網站，會按照使用者輸入山徑的問題，告訴他要打三個勾，這邊有四個按鈕，這樣就知道要按其中的某三個按鈕，按了這個按鈕會導流到後面這些系統去完成分別的申請跟分別的登記，到這邊應該沒有什麼問題，是現行狀況的描述。

那我們十一月一號要開放大家測試的新的網站，我們到底叫Mountain還是Hike好像還不確定，我們暫時叫Hike好了，主要原因是cpami那個網站也叫Mountain。

所以我們新網站先叫Hike好了，不是最後一定要叫這個名字，那這個新網站它做的事情比較特別，就是說使用者透過瀏覽器從網際網路進來之後，這個Hike這個網站只是一個前端，他會透過我們叫做OAS3的一個，簡單講就是開放式的API的一個方式，大家把它想成插座跟插座中間的連線的這樣的概念，很像USBC對USBC的那種插座，那它會連到一台伺服器，那這台伺服器自己沒辦法完成申請或登記的動作，它就必須跟這些地方的伺服器，進行一個我們叫做機器對機器的一個交換。

好比像說如果它現在想要申請山屋，它就必須跟山屋系統的伺服器的代理進行交換，它不可能同時，因為自然保護區裡面沒有山屋，如果它跟山屋無關而是自然保護區，他就要去幫忙做這樣的交換，那我們機關因為機房二級向上集中等等，理論上我們也有一種設計模式是這樣子的，但是後來經過一些需求訪查，跟各部會朋友討論之後，我們發現可能不需要這樣子，可能這個中間只需要一個總交換的類似總機這樣的事情，主要的原因是因為他只是一個轉發的收發代送的工作，所以這個伺服器本身不需要有資料的管轄權就可以做架設，因為最後這份資料不管是所附的憑證，還是存在各位本來有的後端的伺服器，它只是轉發代送的工作，所以你不需要有依法的管轄權你也可以寫中間的這一套伺服器，這是我們之前在需求訪談的時候有確立的一個原則，所以現在也不需要兩個S，現在就是中間一個大S、四個小S的狀況，跟藝人是沒有關係的。

這個時候他們中間要怎麼樣去進行溝通呢？這是大家有不同的想法，好比向有些朋友們我們已經聽到需求，說希望應用webhook的技術，也有些朋友們目前適用email去發通知的，有些朋友決定使用SMTP技術，當然這只是主動地發通知的部分，還有送出申請的部分，這都是往這邊的箭頭，那往這邊的箭頭大家都覺得走HTTPS，也就是OAS3啦，這個大家好像問題都不太大，這是上一場會議得出來的最基本的想法，那內政部在警政署跟國家公園，我們本來以為這個也許哪一天就可以消失了，因為警政署就不管制了，就不用申請入山登記了，不過我們從警政署這邊聽到的是這個還要一陣子，好像不是今年就會發生的事情，甚至也未必是明年會發生的事情，所以至少在接下來一年多裡面，不好意思這個還是會存在，這條路到底要怎麼走還沒有具體的技術評估，不過想必送過來大概還是HTTPS、OAS3吧，希望，當然如果你想走HTTPS然後用這個phonehost之類的，也許我們都可以進行討論，但總之我們沒有收到這個評估。

國家公園這邊倒是比較簡單一點，因為所有國家公園用的是同一套系統，現有如果走HTTPS，而且也沒有發email也沒有發簡訊的話，還是有？沒有嗎對不對？有？有發？那就還是走HTTPS，你要webhook也好，或者你要SMTP攔截也好，你可能就要走兩個協定了對不對？發主動通知的部分。OK，好。那這是我們上一次看到的架構，那現在就有一些需要釐清的。

那這個可能營建署的同仁之前有表示過一些疑慮，那我聽到的有兩個，一個是說這個東西他還會不會存續？答案是會，這兩個網站是並行不悖的，這是一件事情。第二件事情勢說如果這樣的話做一個Hike的網站跟做cpami的網站，而且這個Hike的網站其實是兩件事情，是一個後端加一個前端，這樣從審計的角度來看沒有重複招標的問題嗎？那這個問題的答案就是說cpami的舊網站到底會不會用到這個伺服器？如果這邊存在這一條線，那他看起來就是cpami網站的擴充，那我可能也很難跟審計交代。那如果我們把它定位成，沒有，這是一個全新網站，而且這個案子是只支援這個全新網站，而跟cpami前端關係不大，事實上沒有關係，這是兩個獨立的事件，那我們就比較能去說這是兩個不同的標案，這是我們對事前收集到詢問的具體回應，各位應該還有別的問題，接下來我們就進行QA的程序，我只是針對上次開會的資訊做補稱，那看葉寧要不要？

我知道組長的問題，包括即時回覆的功能是不是存在，將來用這個方式做之後進一步維運改善怎麼處理，看組長可以先問。

政委還有大家好，我們包括林務局、警政署、國家公園，自從有入山申請這麼多年來，大概容易碰到的問題是使用者他們的需求，我們在看這個問題會以我們這麼多年經營這個網站到個別管理處到現在面臨的問題，我們來看一個是情，剛政委講的架構還滿淺顯的，到這個階段可以理解，目前CMI這個整合網林務局可以進來，裡面的東西包括所有的法規、路線規劃訊息等等都在裡面了，現在是6/30上限第一階段被刪有詬病的是我分別要申請的實質審查還是要連結到原來網站上做審查，這是第一點，所以要做這個整合的東西。剛剛政委講到Hike，如果是整合起來，那原來這個是存在，因為所有規劃路線、QA、最新消息都在裡面，這樣變成兩個網站……

沒關係，就申請的時候，超連結過去。

這邊再連一個連結過去這樣，這是第一個，那第二個就是說因為我們登山隊有很多人，一隊可以多達十二個，當初為什麼後來整合到最後的作法是線上會即時回應這個訊息，比如說申請的時候可能時間還沒到，就告訴你要在兩天才能申請，很多管理處規定有差異，例如玉山領隊規定二十歲才可以當，那這個太魯閣十八歲就可以當領隊，我一隊十幾個人的個資，其實開始送的時候就應該要有。

我們在講的是這個系統，是不是？

對，即時就講說這個不符合規定，不要說整個輸入完送進去，審查之後說這部符合，那就整個要重來，這是線上即時性的部分。我們問題是如果Hike這個網站有一個server在這邊，那這個server跟每一個server之間，那這個部分的即時性的東西，就是說Hike這邊申請的時候，應該也要達到原來的功能，這樣對山友才是真正整合，如果說批次，或該入輸入的資料送進去才回應說你不符合規定，這樣有點走回頭路。只是說好，如果說這個功能要維持，國家公園坦白講山屋也多、路線也多，每個國家公園又都有些差異性，那個規則就相對複雜很多，這些規則要如何在線上即時的，山友在Hike申請時，你輸入哪個關鍵地方不符合要馬上跟你講，這樣才節省他時間的這個需求如何滿足，才能維持原來的期待跟想像，大概是這樣，從使用者需求導向來提這個問題。

第二個就是剛講的，現在有時間上壓力，我們行政部門就是一百萬這東西很敏感，這個部分的確我們要壓一百萬以下的時候，那前台又有一個，就國家公園部分，前台還是我們營建署負責，要負責前台跟後台國家公園的部分，變成就是兩個案子。

我試試看。網頁沒有糾正我啊？它只是顯示一個提示？

您現在在申請人頁面，我們允許人代填。

可是我的生日填2020年耶？

申請人沒有控管，你現在是申請人還是領隊？

申請人啊。所以這句紅色是參考用的？

你送不出去了。

我先亂填一下。那我送不出去的意思是在哪裡會送不出去？這裡嗎？

不過因為後面幾欄沒填完所以送不出去。

我們現在把它填完。這裡對不對？所以這是一個前台在瀏覽器層就進行的一個確認。所以前台控一次？

這裡面包括名額夠不夠？

這是只有前台控，還是後台也控？

後台，後台去算，因為有的人會寫程式去串。

任何狀況後台都會控，前台只是有時候會幫忙一下，但假如我把javascript關掉或怎麼樣，硬送去它還是不會理我。

對。

我先確認這一點，謝謝。

大概是這樣。

好，這個題目我們有兩件事情，一件事情是說隨著時間更改，它會有所不同的狀況，好比像你說這份申請表現在送不會過，但過兩天開啟就會過。

進到可以申請的時段。

意思是不能預購，這是一個。不能預購的部分，似乎從Hike過來好像沒有太大差別，反正就是失敗，你知道我意思嗎？如果後台不開放預購，前台填完送出，而不是一邊填一邊糾正。

我們現在分兩段，一端是程式邏輯去判斷，而且您剛剛說前台做的後台一定會做一次，所以後台的部分有個後控，前台部分有一些前控，也包含動態的去查的一些資料，盡量讓使用者方便，能前控就前控，不然多一些表，從使用者感受來講，前控的部分還得前控他，不然他覺得被欺騙感情，填了這麼多才知道不行。那從資安角度，已有的後控倒是什麼都不用改，所以後控並不是一個議題。

後控確實不是問題，但前控有很多事要確認。

所以現在真正的問題只是Hike要怎麼進行前控，這是議題一。

其他同仁還有沒有其他問題？

我補充一下，就我前兩天跟秉倫聯絡過，這部分他說我們的JS都可以爬回去所有代理的程式，不知道有沒有理解錯誤，所以前控這一段只要JS方式alert出來應該是可以爬的回去，這是我的理解。

這是對的，前提是alert不要變成雙重用途，好比像今天會下大雨，但跟送出沒有關係，如果什麼事都沒做你就alert，這種alert我們就如實顯示而已，不會讓它送不出。

但是剛剛李老師講的前控剛應該包括送不出？

我理解，alert包含阻止你送出跟不阻止你送出，我們如果在寫爬蟲，我們要知道這兩個是不同的，例如一個用驚嘆號，這個我們都很容易約定，這個再說。

但是阻止送出的這一段會是一個問題。

好，這還是同一個議題，只是加一個敘述而已。

看大家還有沒有什麼其他問題？

我在補充一個問題，其實我昨天有發一個mail給秉倫，因為我們在填有一個類似step1、step2、step3，所以我們上次會議說如果田資料採用plan B，問題是代理人是不是能夠照著我們的順序往下填。

那個代理人程式後面應該是Headless Chromium，意思是Chrome做的到的它都做的到，除非你用的是ActiveX或者Flash技術，不過那樣國發會就要找你麻煩了。（笑）

如果你用的是標準web技術，這是沒有問題的。

我先預告一下要處理的問題，除了技術問題，至少功能上不會比現在遜色是一個要題，第二個部分如果按照政委設計來做，是不是有適當的廠商來做，包括營建署的前、後，以及警政署還有林務局的兩個廠商都在，這也是我們請資拓來要進行救火的原因。

這裡有六隻系統，ABCDEF，我們收到的訊息是C跟D是以既有預算跟廠商辦理，確定吼？另外收到的訊息在上次會議，E的部分是假設沒有被廢掉的話是既有預算跟廠商辦理，不過這個訊息似乎有所更動，第一個這個沒有要被廢掉，系統一還是存在，再來是警政署到底有沒有現有預算廠商辦理，是不是可以更清楚的瞭解一點？我再講這個部分。

報告主席，警政署第一次發言，因為上次討論既有預算跟廠商辦理的時候好像是上一次的plan B，要做一個路徑，但目前好像不是照上次的plan B來做。

這還是plan B啊，你們有這個系統啊。plan A跟plan B的差別只是這個東西包進來還是切出去，因為上次有些朋友沒來，plan A就是說本來這個前台自帶API的功能，B就是有人寫一隻爬蟲幫你原來的網站加上這個功能，如果這個大框是「a」的範圍，那麼小框是「b」，因為大寫字母用掉了只好用小寫字母。

跟主席報告，如果按照這個構思的話，B的部分我們評估代理人程式要自己來做，這部分有涉及到經費問題，我們還需要，估是在一百萬以內啦，但我們如果自己做的話還有跨級單位……

但是A就沒問題嗎？那就是你上次講的不算嗎，一句話講就是這樣嘛。

我們沒有辦法等你們慢慢評估，原因是說我們如果承諾院長說十一月一號上線，我們不能說因為警政署還在評估所以沒辦法上線，而且我們的理解，你們的系統應該相對於國家公園是最簡單的，可能四個裡最簡單的，所以相對經費也是最少的，我們只問一個問題，你們的廠商有沒有能力、能不能配合這個時程做？

不管plan A或plan B。

跟主席報告，我們全力配合這個作業。

我的意思是你要不要另外的廠商作，先確定。

既有廠商這邊發言，我們會配合。

你們打算採取哪一個作法？

我們目前短期目標是plan B，然後遠程是這邊會開發，長期目標會歸類做完。

那我還要在問一個，如果plan B是同一個程式，A你把一些鷹架拆掉就做完了，如果你未來再收警政署一筆大錢，那這是不合理的。

所謂經費的部分目前就是還沒有詳細預估，不過基本上我們經費上不會造成單位的困擾。

好喔，所以現在的plan B跟未來的plan A我們希望在九十萬之內可以一起完成，不是B先報九十萬、A又報九十萬，這樣審計就要找我們麻煩了。

如果廠商都這樣表示，我們可不可以請公務同仁有一個明確的回覆？

對不起，我再提醒一下，這是院長裁示，我已經很明確跟國勇部長說這件事情，如果你們真的好比缺像說能夠向上管理到部長簽個字才夠的這個程度的話，我很願意再去跟部長講一次，除非你們內部因為什麼程序，你非得找這家廠商或非得不找這家廠商不可，我們要聽的是這件事。

廠商已經表明時程跟架構上可以配合了，當然希望你優先跟這家廠商合作，但如果你不方便講出說其實你覺得這家廠商沒有能力做的話，你可以用比較委婉的方式說，政治風險我都可以負責。

那現在如果只是因為沒有錢，那沒有錢不應該是一個問題，我是要說這個。

我確認一下，就我的認知就是這個路線上，他可能跟S的過程當中應該會有部分的plan A、plan B。

可能進是走一條路，出是走一條路啦。

但是這個部分，我們不負責來爬的這一塊，應該是這樣子吧。

應該是這樣講，如果有爬蟲需要寫，那那邊要講清楚兩件事，一個是給你一個路徑，就是最簡單的html，css、javascript都不要出，那意思就是說你不用特別寫爬蟲，他就是爬蟲ready。

就我們是被爬的啊。

這我理解啊。

那爬的應該不是我們的事。

你不能他爬到一半，然後你去更改他的form的樣子、id把它抽換掉，但是我要講的是說如果你的前台如果本來非常複雜，爬蟲好不容易寫到一半，前台給他抽換，那這是你們的問題。

當然、當然。

那我幫忙問一個問題，因為有些單位不確定這個爬蟲是誰要發包，都還覺得是中間那個大S，例如說營建署整個發包下來。

這分兩塊，因為你們有九十萬嗎，那加起來386，九十萬以下我們以行情來講啦，專門寫一個爬蟲，沒有九十萬啦，我自己接案的時候九萬就做了。

我的意思是說，這很可能還是要用好比說C，C部分是山屋自己可以出一部分嗎，然後一部分是他要透過一個爬蟲來達成，我聽到是這樣，那這條線跟這條線，你縱然可以給兩家不同的廠商做，但他還是一包九十萬以下的預算。那我要強調的一件事情是，寫爬蟲跟把網站改成讓爬蟲容易爬，他並不值九十萬，分別來看，真的都不值九十萬。

我先前作為一個資訊從業人員，只要你不是activeX，那我可能要去用Sikuli之類的技術。只要你是web base的東西給我爬，九萬、十萬我就寫了。

反過來說你們如果要部分改成API出來，你也不該收九十萬，所以誠然會有兩家廠商，一家寫爬的這段，我們已經快沒有字母可以用了，姑且叫做甲，這邊叫做乙好了，需要爬的那一段就是甲，你自己出的API叫做乙，這兩個還是需要在一個單位，就是目前山屋這個單位來付錢，但是錢可以付給兩個不同單位，一個單位去承包乙的部分，一個承包甲的部分，或者假設做乙的部分的廠商，他真的那麼有自信，覺得他把甲的API也寫出來，那也許轉包，但是如果他現在很不想寫這部分，那甲你就得再包出去，這兩個總和加起來還是你們的錢，不是營建署的錢，也不會是審計人員的錢。

同樣的問題應該也存在警政署這邊？

聽起來這位廠商的意思是他先自己爬自己網站，再把自己網站變成很好爬的版本，這兩個加起來剛已經聽到了九十萬之內可以完成，所以沒有這個問題。

好，那警政署可以嗎？

我們自己內部協調經費部分。

我們只要求如期達成，如果需要我們跟部長或署長講，趕快說。

警政署報告，我們這邊會如期完成。

非常感謝。OK，好。那在農委會這邊還在討論技術細節的時候，我想詢問國家公園這邊是打算採用什麼樣的方法？

先跟主席討論一下，因為上一次的說法plan A跟plan B，plan B是爬蟲程式，但是9/2寄過來改成是要架一個server在中間，那A跟B是同一個廠商去做嗎？

對不起，可能沒有畫得很清楚。爬蟲程式他固然可以運行在B的這個機房，這是我們上次講的事情，但是這個意思仍然是，假設F是一個爬蟲了，他跟B運行在同一個機房，你知道我的意思嗎？這就是為什麼我們要調查你們內外網資安有的沒有的東西，因為他牽涉到F的這一包，假設你要採取plan B，到底跟你本來的網站是同一個網段呢？還是如同上次有一位非常專業的同仁詢問的，我這邊要壓一個SSL private certificate給你，專門讓F能夠看的到某部份的國家公園網站？

這跟上次講的並沒有任何差別，只是物理上我們逼這邊願意來host F的程式，只是這樣子而已。好，不過這跟你問題沒有關係，您的問題是A跟B是不是要運行在同一個機房？

A跟B是同一個標案還是兩個標案？

上次並沒有講這個，確實，我同意。

B的scope到這裡，包含API設計，那A是好像一個純前端的東西，是一個API的consumer，好，那他要不要是同一個標案，如果你現在的想法是你受到採購法限制，A＋B必需要九十萬之內處理的話，那這個就有一點點去拗寫B的那個人，因為在我本來的想法裡，在我自己接案的時候，A我應該二十萬之內寫的出來，但是B可能真的要八九十萬，所以加起來就有爆表的可能性，您提出來這個是完全正確的，這個我先承認。

好，那至於A跟B能不能切割成兩個標案處理，要看B會不會連到除了A之外的前端。如果B它會連到A之外的前端，就可以跟主計說其實B就是大家都可以取用的東西，就像我們的PTX，這最經典的例子，交通部API那個東西，PTX雖然交通部自己有一個A，有一個視覺化的方式，但坦白說就是做的有一點陽春嘛。但是民間有很多加值的朋友把這東西做的美輪美奐，菜價看板也是這樣子。

所以如果我們能證明給主計說，B你看這邊有很多A1、A2、A3，都可以consume A的API，這樣我們去justify這是兩個標案，顯然就沒有問題，因為很明顯B的服務對象不只是A而已，B只不過是A的reference implementation，就是給大家參考用的一個實作。

這樣子的話確實可以邏輯上變成兩個標案。但是如果現在沒有A1、A2、A3，那這個邏輯上就是同一回事，這樣自然只能在一個標案解決，這是我的一個具體回答。

好，那另外一個就是，我們這邊是國家公園的廠商，我們要表達一下說，我們前控後控主席也提到相當多，我們三個管理處有三個工程師，那今天兩個工程師趕出來，那一位是太管處一位是雪霸，那我們規則相當的多，所以操作只是其中一個管處而已，還有三個管處，這時候怎麼寫到F然後把前控後控機制寫出來，工程師這個禮拜都在清，大概一百六十隻，如果全部要我們在九月底十月初寫出來……

這一百六十隻規則的效果，是否都只是讓他送不出表單？

送不出表單的意思是說？

就是他的申請會失敗。

對。

對嘛，所以這是同一隻API，只是有一百六十個檢核條件嘛。

不一定耶，我們全部包成一隻就對了？

以API設計來講，這是一個端點啊。你知道我的意思嗎？因為我們要問的只是好比進行政院，當然我現在刷臉就可以，當年說要驗身份證件的，那他當然就有很多要檢查的規則嘛，證件是不是偽造的，跟我看起來像不像，然後看起來有沒有攜帶槍砲彈藥，我們相信行政院的警衛也可能有一百六十個規則。

雖然我不知道多少個，但是最後他只有放行不放行這個選擇而已。所以從端點來看，我作為行政院的訪客只有進的來進不來，我如果是S，我需要跟B講的只有進的來進不來，是單一端點啊。進不來的原因可能很多，你附一個理由嗎，他事實上只是進不來的一個payload而已嘛，就是從HTTP來講他只是一個forbidden而已嗎，那forbidden要有一個content，content就說明為什麼forbidden，以後控來講，這邊不要說一百六十類，一千六百個也是同樣感覺啊。

主席不好意思，我跟工程師確認，因為我們的檢核機制，他會有一些前後性能關係，我們寫在一隻裡面我們在控制上會更複雜，我要寫成一隻給你的時候，包含要未滿十八歲要有家長同意書的檢核，他在填某一段時我們才出發，太管處七十歲以上還要發簡訊通知說要注意身體安全。

這是主動通知端點。剛問的是結果，是不是進的去。

申請的時候我會發通知給你，這些怎麼把……

瞭解，那這是列舉，現在有進不去、進的去、進的去但受到通知。還有什麼樣態？

拒絕通知、繳費。上傳文件……

那一樣啊，只是要求額外欄位。

應該是說裡面規則太多了，如果要把它，中間的B去用，我們需要更多時間，就算寫了一隻web API好了，要能沒有遺漏的方式，這時間上要……

簡單來講，你們自己砍自己的站都沒有把握，就是自己寫爬蟲爬自己的站，都沒有把握能如期做到？

不是說沒有把握做的到，是我要時間。

那假設等到你時間到了，好比像說請你改做到明年二月，那會表示什麼事呢？

如果那表示你們原來用語言程式寫的東西，會通通變成data driven，會變成以資料為定義的嗎？以後所有國家公園要改規則只要填表就好，他用試算表就可以控制嗎？

（搖頭）

那這樣有什麼意義？那就是重新刻一個有一樣功能的網站而已。

會變成是這樣，因為太多東西了。

其實如果你要改成data driven，這個我們在資訊學上這是一個architecture change，一個整個概念都要轉變，不是用程式來定義而是資料來定義，這個你說要爭取四個月做這個，我其實非常贊成，我覺得非常好，而且四個月做的完已經算快的了。

但是我現在聽到，你在爭取時間的並不是這個，四個月之後也無法做到資料驅動，那這樣的話，似乎就根本不用討論這個選項，你自己透過plan B砍自己的站，這件事情沒有效益啊，那這樣你只能走plan A。你有聽懂我意思？

有，我們在討論在變形一下看什麼方式做，譬如快速判斷yes or no解決掉，我們會跳滿20、18。

就是你前控先拿掉嗎？有一點這種感覺。

有些前控看能不能過濾一些，但是現在山友很習慣，例如說七十歲以上要收一個簡訊來關心我一下這樣，像這個可以慢慢的濾掉。

好，我有一個具體建議你聽聽看，也不是我說了算，因為你剛剛講的，也就是如果延期，但最後不能變data driven，這我們無法討論了。

我說一個可能性，我們還是走plan B，你本來網站就給他保持，但是有一個client certificate或一個特定IP來的，也就是你可以信任的客戶端，當他來的時候你就給他一個很簡單的網頁，所有不相干的、人看的都拿掉，我不是要你加什麼，就拿掉就好。

並且你承諾說未來，好比你現在是填到一半跳一個alert嗎，你不要過了三個月你填到一半不用alert了，你去用一個light box，你知道我意思嗎？你現在本來怎麼做，未來就繼續怎麼做，使用者介面的用法相同，甚至專門為了這個IP，為了這個client certificate你保留一份舊版，mount在某一個路徑底下，他就是一個活化石。

那當然你的各個國家公園一定會想要改規則，這個規則你可以兩邊改，我要的是當他跟使用者互動的時候，你用的那一個使用者介面技術保持相同，你現在alert就alert，不要改line box，你知道我意思嗎？

對，那這技術上沒問題，但國家公園裡面會有山屋跟營地的承載量，這兩個的數量我如何去加總跟計次？

你就用你的web介面，你的API出來的那個MIME Type，就是叫text/html，不用去轉JSON，你也不用去想XML，你就是出原本的hypermedia，你知道我意思嗎？你什麼都不用做，事實上是請你少做一些事，不是多做一些事。

但是這個總數……不好意思，這邊還會牽涉即時，我怎麼去把它前台……

先不用管前台。你對F的溝通，這一段，這個東西就叫html+javascript。

應該說連F這一段，其實我應該都會讓B跟A那邊好接的話，應該是把F這邊一起做進來。

換句話說，就是你的html+JS，你只要這一段凍結掉，不要再去改你的html跟JS的結構，你的function名字也不要改，你就長那樣。

後台加新規則，都同意可以隨時加，你就加在後台。但是你的承諾就是說不要用不同的JS library，不同html排版來做這件事情，這個應該做的到吧？說真的，這個應該不要說九萬，九百塊就可以做的到的事情。

瞭解。

所以我們現在先確定國家公園這一邊既有架構不動，然後F的這一段因為是plan B了，要寫一個真正意義上的爬蟲，要模擬一個瀏覽器了，那F這一段想必就得在B的機房跑了，因為資安的關係，好，到這裡沒有問題吧？那如果沒有問題，就要下去寫囉。

那我們接下來要詢問營建署的同仁，因為他們要發包A、B兩案，其他案子都很容易，因為F案說真的，真的是一個全新的東西，你們跟主計是很好交代的，A跟B到底是一案還是兩案就沒有那麼好交代了，這個看葉寧有沒有什麼好建議？我們具體上面如果A跟B是同一個廠商都拿了九十萬，雖然B跟可以跟A1、A2、A3服務，這個到底會不會造成成分裡採購，我是假設性問題。

我們有幾個問題我先確認一下。A跟B的部分目前的實務上面如果加起來變成一個案子，一定破一百？

如果他不破一百的話，可能要犧牲一些A的畫面品質。

OK，好，那所以我們有兩種選擇，一種是A＋B不破一百的狀況，可以用指定廠商的方式來做，另外是A跟B開兩個標？

不同廠商。

是不同廠商？好，但是B不可能跟，我是隨便亂講因為我不懂，B不可能跟國家公園那個結合，那兩個結合會……

如果B＋F是一包，我覺得不宜耶。

好，我只是隨便亂問。

因為F很複雜，現在F變成CDEF裡面最複雜的一個。F的技術難度變成最高，所以B＋F大概也破一百。

所以B＋任何都？

不會不會，B＋E大概就在九十以內，因為E那邊警政署自己吸收掉大部分的成本。

可是這就要用國家公園的錢？

現在有A、B、F三個標案。

那可是A跟B兩個分開開，然後同一個廠商做，這樣看起來是不對的？

好比像說A跟F包到同一個廠商那說不定還work，因為這是兩個不同的標案，而且這兩個說真的毫無關連。

所以這個問題也不難解決，第一選擇是A、B、F開三個標，每個標都會在合理的價格範圍之內。

但是，A+B如果超過一百萬，就不能同一家得標。

對，那F直接，我是外行直接問問題，F的部分看起來是李老師的團隊可以做？

沒有，他們剛自己說，不能在這麼短的時間裡做。

F的部分不會，所以A，我再確定一次我有沒有聽錯，ABF是目前營建署要開的三個標案，李老師的部分有要做任何一個嗎？

李老師的意思是他偏好不做F。但是A跟B我還沒聽到。

（搖頭）

三個都不偏好？

三個都不偏好？所以李老師不打算做任何一個。

時間上我們沒辦法。

要請李老師做左下角複製一份、凍結、不要動它。那個預算可能只有九百塊，對不起。

所以A、B、F我們至少要找到兩個廠商來做這件事。

不好意思，我問一下，我左下角複製出來放著，我的任務就算結束了？

是的。

我們並不妨害說，所以B其實是A跟F，應該是要找到兩個廠商？

要找到一個廠商，一個接A，一個接B，那如果那個廠商接A同時接F是無所謂。

好，可是最大的是B。

也沒有，F也很複雜，是不同的技能，應該這樣講。

我們的backup就是資拓嗎？還有現有的林務局，或者是林務局可以接B？這樣OK嗎？

如果左上角那邊願意把B或F吃下來，那當然是非常容易的，現在只是你們有沒有興趣而已。經費當然是從內政部出。

他們本來在林務局的標案還是林務局，只是因為廠商已經理解了，他們能不能做營建署的案子，聽起來可以啊。

當然可以啊。逸凡還是？

我們把C做好就好了。

好。那凌群看起來是？

就請自由表示意見。

報告，凌群也是把……

也是把自己的做好就好了。

好，那資拓聽到現在，就是ABF有沒有什麼偏好？

或者是AF。

或者是你們九十萬可以做完B、F，這樣也很好。

對，說不定。

各位好我是資拓的技術工程師，因為其實我們資拓是第一次參與，那有一些就是之前的……

請問。

現在嗎？

可以把我當作是技術人員來問，不用拘束。

其實對我們來講第一個就是說，因為其實他申請這個東西，我們現在看起來各大網站，不管是林務局或者是營建署，他的審查都不是即時審查，那現在我們要做的東西已經可以跨越到即時審查了嗎？

沒有，他們本來要人工核的還是人工核。

如果是這樣的話，我們第一個問題是為什麼會有SMTP往回去S？或者是那個什麼……

這個原因是這樣，有時候人工審查之後會要通知他補件，所以他需要一個pushing notification，告訴他說雖然你上傳了某些文件，不過我們一看這個你上傳的不好意思是你的駕照，我們根本不想看你的駕照，這時候就會收到一封信說請不要補你的駕照而是你的登山規劃書什麼之類的。

好，謝謝，如果是這樣A跟B這邊除了可能事後還要去通知申請的人，那這樣的話是不是還要做可能會員管理之類的？

不需要，沒有會員管理的問題，因為他申請的時候一定有一個email，email其實我們在上一場會議有討論一個方法，你不用登入但是要提供email，因為有通知要發給這個email嗎，那但是你在B往C的時候，你的email是轉架成自己的mail server的一個UUID的帳號，所以他的信就會寄到你這裡了，你的資料庫知道當年這個UUID是誰，你只要轉信就好，轉信只要做一件事，裡面的網址要換成你的網址，就這樣。

那為什麼不用現行就由山屋這邊自己發mail就出去？

因為他當時在Hike填的是一個介面，但是他收到山屋的通知信之後，回山屋是另一個介面，你知道我意思嗎？我們要一站式服務，從頭到尾不要離開那個網域，但現在會變成是說，我在這個網域填了，填得非常順利，我們透過使用者服務設計弄得非常漂亮，那但是就好像說報稅我們都用過重新設計的軟體，就是web介面非常漂亮，但是國稅局發現你少了一些文件，現在請去跟你的朋友借windows電腦下載某些程式你才能補件，這個時候他的感覺可能不是很良好。

因為SMTP回來的時間很有可能一天或兩天，會不會這樣子？

審核需要時間，大概一兩個工作天。

回傳的問題我們大概知道，那另外想要再確認一下A這個部分就Hike這個網站是不是等於說原來類似像山屋、自然、國家公園這邊做前控的邏輯是不是也要套到Hike的部分？

剛才我們這邊聽到了兩件事情，一個是說後控他們會給F那邊一個非常清楚的status code，所以你什麼都不用做，就是forward那個status code回來就可以了。前控的部分就是所謂javascript的部分他們這邊是說沒辦法用data driven的方式描述給你，所以會變成F這邊要變成你隨填隨送到F，F收到之後會有一個partial content，他的partial content就已知是一個error code，那這個時候等於要不斷的用ajax送那個form過去，那所以說這個form每一次都是你的全送，不過這只是文字資料不算什麼，沒有什麼頻寬問題，然後當他隨時回你什麼validation的時候，你又javascript跳出來，那F這邊的廠商要保證說他要把這邊的alert轉換成某種status code的payload，那是F要擔心的事，除非你要寫。

所以簡單來講所有前控的validate都是用一致的方式去coding？

因為我們用OAS3，這個是OAS3唯一接受的方式，如果你是RPC你有好幾種pattern可以選，但是OAS其實你只有一種pattern可以選。

不好意思我請教一下，前面那個Hike現在那個山屋自然警政國家公園網站上的一些申請或異動查詢，這些function都要在Hike上面？

因為B都會寫給你，A只是B的consumer，反正B有的A就畫出來，就是這樣。就是B有什麼A就得畫什麼，如果B沒有的A可能寫個comming soon之類的。

瞭解。

我說真的，那時候還講說，如果十月一號B只寫完一部分，那我們是不是要用綠野仙蹤法，請朋友們趕快看到A然後趕快轉頭往C跟D打個資料然後告訴A，這個我們都討論過了。

所以就是A跟B的部分，你要想像最後B會什麼都有。

好吧，那我可不可以問外行問題，所以資拓你要接哪一個？

有沒有興趣？

不好意思，其實今天第一次會議，對國家公園這些邏輯比較不清楚。

當然，不過ABF剛好是web的三層不同資訊技術，這邊只是問你們對哪層的資訊技術有興趣而已。

不好意思，可能AB比較OK。

AB是在你們的守備範圍裡，好，那下一個問題就是AB加起來九十萬，你們願意協助嗎？

或是一百以下。

如果可以的話對營建署來說他們鬆一口氣。因為他們不要跟三個廠商打交道，這樣他們發一個AB案跟一個F案就結束了。

這個我想，因為剛聽主席講你的估算，B大概八九十。

如果我來寫B，大概要八十萬，對。

所以八十加二十大概一百，要成就這件事情就合起來。

你就打個九折，謝謝，非常感謝。那這樣的話我們這邊會再去找能夠寫F的廠商，然後會，如果營建署已經有認識的那當然也很好，那但是總之大家，或者資拓，畢竟你們最後還是要配合的，如果你們有偏好可以寫F的人，也不妨跟我們講，不是你講了我們就一定會報給你們，至少就是擴大我們的交友圈，是不是這個意思，那這張圖我會後會提供給你們。

我再請教一的問題，那剛剛這個implementation，需要的一些軟硬體的環境都含在這個費用嗎？

這個我們有現成的環境，因為現在是二級向上集中，內政部綠能機房是不是可以用了？

內政部那個向上集中，營建署按照表定計畫時程是在明年。

真的？所以二房東有不同的搬三房東進去的時間就是了，好。不過這是小事。

你們在開發的時候我們是可以去申請那個，相信你們也很熟悉國發會的第二資源池，資安是沒有問題的，我們可能就先用資源池二來做。就是中華電信的HGR，這個你們很熟，就是新版報稅軟體那個，那是開發階段。

你到部署階段，按照我們向上集中概念，總有一天會回到內政部的機房去，只是按照個講法是明年，有知道第幾季嗎？

明年底。

明年底就第四季。

我們只是需要一個確定的時間。

那如果是有需要是不是要跟部裡面協商，這個算是新的東西，就直接放在他那邊？

這也可以啊，這很好，所以那個機房已經可以用了，只是營建署還不能搬進去？

對，它現在建置在東七。

那已經ready了，東七應該已經好了啊？

它也是今年底要完成。

環境已經好了，這個我瞭解，現在就是在測試而已。

東七很好搬啊，那開發在HGR，開發完之後，明年一月搬到東七去？這個應該沒有問題。

可以嗎？

就跟部裡面協調。

所以這個就拜託你們嗎？還是我們要跟部裡面講？

這個我們要講，這沒有問題。

好，那我們就分兩階段，資拓在開發的時候我們要協調HGR給你們，到部署階段，大家都公測完了之後沒有問題了，明年一月一號之類的時間，我們會跟內政部這邊協調，讓他們東七那邊騰出空間來，那以後大家就在東七那邊處理了。東七那邊有個好處是他們房客還不多，所以你ABF全部跑在那邊大概也不會發生什麼事情。那就這樣。

所以我們現在剩下F還沒解決？

我們現在就是要找一個能夠寫F的廠商，看資拓有沒有認識的，或是再去找。

會後我們可以再談。

最後是有關時程面，前面API的design應該要更早出來，要不要後面沒辦法接手？

你說B嗎？

小S的API。

不過現在如果AB是同一個人，那條大pipe你們在開發階段，愛改就隨時改啊，對不對？這條已經不是問題了。

你們在講的是CD這兩條嗎？據說已經都收到技術文件了，所以現在最沒有的是這一條，因為F的廠商還沒有找到，其他你們大概都不太需要擔心。

F我們越早找到你們就越不需要擔心，F我現在不能promise你時程，因為什麼時候寫出來還不知道。但是其實因為CD不重合，你一個申請不會同時動到C跟D，所以你們在測的時候沒有那種爆炸性測試的問題，你就測把C皆起來試試看，把D接起來試試看，這樣就可以了，短期之內E那邊ready了，你們就把E也接起來，這樣就差不多可以用了，那F的部分你們也許最後再接。那這樣不會耽誤到你們的工期。

我們技術窗口還是展銘這邊嗎？

當然。那請展銘發言。

不好意思，我還是要問一下C這塊，所以還是要plan A跟plan B混合嗎？

一定的啊。

對，AB混合加起來的錢不要超過九十萬。

那plan B的部分不是你們接嗎，那會是？你們要同時做A跟B？

我們山屋的部分會同時用A跟B的方式。

但是那個爬蟲就相當於F的那個部分你們希望別人寫嗎。

就是現在這個S，就是B的部分。

對，沒錯，就是甲案的部分，這個我們真的已經把所有能用的字母都用完了。跑在B的機房的那隻甲案的那隻爬蟲程式，剛才資拓已經說並非他們專長，我們可能要跟F同時找人。

他是包含在哪一個標裡面？

他是在C，C你得切一點錢出來給他。

我們是被爬，所以……

你們被爬其實沒有工作。

其實有啊，我們還是要改寫。

那個工作量不成正比。你們生API，這個有工作量這沒有問題，那你們被爬的部分讓他容易爬一點這個工作量相對少，我只是要講這個。

好，那所以就是說甲案那邊到，C之乙這部分還是要收一些錢，這沒有問題的，只是說C之乙跟C之甲加起來不要超過九十萬，至於你們是用委託承攬轉包分包，隨便啦，你們高興就好，只是加起來不要超過一百萬，主計大概就不會找你們麻煩。就是這樣子。那至於C之甲跟F要不要是同一個人，如果是同一個人也不錯，不是也無所謂。

所以不是他們自己去找，是我們？

我們可以替它們找，如果你們有合作愉快專門寫爬蟲的朋友，你們就提出就好。

我比較好奇的是B的爬，我們如何切割說B的山屋這塊的爬，是我們來寫給他們去分到他們的系統？

依你們的現有介面。

但是剛講說我們如果要做爬的那一塊。

你們連C之甲都要做？

那就會跟B去結合在一起。

那就會變成是你們要寫一個基本的OAS3的說明。因為寫完之後他們這邊看是不是內在一致合乎邏輯，他們就會告訴你可能這邊的status code改一下嗎，就這樣，這就是兩位API廠商約定的事情，不過這個說真的比較容易，不是困難的工作。

他其實滿麻煩，是因為中間的篩選機制。

我們剛剛已經說了，這邊永遠只回200、400，你就只回2XX、4XX，所以他的endpoint design並不難，但是你要說的是endpoint裡面的規則很繁雜。

但是從B的角度，不管你多繁雜，我就看你回來的status code而已。

我的意思是B裡面的C爬蟲的部分，如果我們來寫，如何跟B去結合在一起。

那就是你這邊要有一個他們所期待的回應status code和payland，就請兩位直接溝通一下。如果你們自己可以在九十萬裡面，甲乙兩案全部都跟這邊切割完畢，各做各的都接的上，這樣我們就不用找第三個廠商進場，這個你們的溝通成本會少很多。因為2!還是2，但是3!就不是3了。這個你們要討論一下。

能確定的先確定。

最好現在就確定。

組長不好意思，除了剛剛F的部分還沒有人處理之外，您那邊還有沒有其他的，包括行政上的問題？

AB現在是資拓這邊的案子，那我們就這樣來處理。

那F就是國家公園的一個附屬案，為了國家公園符合國發會open API政策之目的，你要開一個案給國家公園，那就是兩個案。好，那你們這邊有結論了嗎？你們希望有第三個廠商幫你們把爬蟲寫起來，還是你們自己就可以切開？

我想我們再討論吧。

但是這兩個都還有選項嗎？

其實對我這樣看，我是C的甲的範圍的大小，取決於C的乙。

對，完全正確。

所以會變成其實這兩件事應該是有關連。

兩個加起來剛好會等於百分之百，沒錯。

現在問題是甲的部分如果太多，就會跟F的形狀會變一樣，如果乙的部分，甲只有那一兩個，說真的B吸收是很容易的事情，這個也許，因為我們現在已經要找F的廠商了，可不可以盡可能禮拜一給我們一個確定的答案，我們需不需要找F的重時，也幫你們的C乙的部分很少而甲需要幫忙，我們需不需要找一個人幫你們忙，那如果不需要就你們自己處理了，好不好？禮拜一告訴我們。

禮拜一，還是一樣跟展銘說。

OK，那就這樣，如果是最後不需要第三個廠商，你們這邊的標案就非常容易了，我們就再也不需要指導你們了，那如果是兩個廠商要進行一定之分割的話，也許RFP的部分再跟展銘討論，好，就這樣囉，好，謝謝，謝謝大家。

所以最後，營建署還差一個廠商？那A跟B的部分營建署已經包給資拓了嗎？

F的部分如果營建署有找到廠商你們也自己去做，如果沒有找到，就以我們找的為主，因為我們有院長的期限在那邊，這件事就這樣。

好，謝謝大家。