2018 九州流浪到四國 Day 1 ~ Day 3

/0 評論/在： /通過：

Day 1 鹿兒島市及櫻島

這個暑假計畫再來與兩年未見的松本先生相會。本來計劃想去九州最南端的屋久島，但考量松本先生絕對會一路從四國松山殺到屋久島跟我們會合，這路途真的遙遠到無法想像，所以還是罷了，改計畫先飛到九州鹿兒島，其他就讓松本先生安排了。最終松本松山還是從四國松山開了600公里的路，來到鹿兒島市接機。然後接下來就開始跟我們想像中的露營旅程完全不同的十天九州流浪之旅了


睽違兩年未見的松本先生，有點變瘦了

第一天中午抵達鹿兒島機場，如果是租車的話，建議可以先開車到櫻島，然後再搭渡輪到鹿兒島市，車子是可以直接上到渡輪上的，這樣行程蠻順的. 從機場到鹿兒島市區的途中會經過 道之站垂水湯足館 先泡泡免費的足湯，邊泡腳可以邊遠脁櫻島火山


第一站 道之站垂水湯足館

櫻島火山有兩個比較大的火山口，南岳跟北岳，北岳已經很久沒噴發了，南岳是十不五時就會噴灰一下，我們來之前五天才噴發一次，前一個月也噴發一次，所以這次走在櫻島路上，有明顯感到空氣有火山灰，實在很難想像這邊居民是怎麼生活的.
櫻島火山在歷史中所記錄到的規模爆發次數已超過30次，其中以文明、安永、大正三次規模較大。黑神埋没鳥居可以看到在1914年大爆發中，鳥居被三公尺高的火山灰蓋過


黑神埋没鳥居


路旁隨處都有退避壕，讓民眾遇到火山噴發的時候，有地方可以暫避退避壕


可惜今天櫻島火山都被雲遮住了，無緣一睹其面目

今天住 Remm Kagoshima 雷姆鹿兒島酒店，C/P值超高的飯店，櫃檯有接待人員會說中文. 房間不算大，但設備很新也很乾淨，位置超優，旁邊就是商店街.

晚上誤打誤撞，在距離飯店大約 200 公尺不到，有一家吾愛人本土料理店. 想不到這家店來過的名人超多，台灣人比較認識的應該是安室內美惠吧! 大推六白黒豚の一人しゃぶ鍋 (六白黑猪一人涮涮鍋)，豬肉熟肥肉比例各半，但完全不膩，兒子不吃肥肉的，也完全吃光光


六白黒豚の一人しゃぶ鍋


吾愛人本土料理店

Day 2 指宿砂蒸溫泉及霧島神社

今天的行程一早從鹿兒島出發開車往南到指宿

指宿最有名的就是天然砂蒸溫泉了，指宿的沙灘很神奇的是下面剛好有溫泉地熱，把沙烘得熱熱的，砂蒸就是把人埋在砂裡面，“蒸”個十幾分鐘，其實蠻有趣的。


遠遠那個棚子裡就是砂蒸的地點

砂蒸是有步驟跟路線的，首先在更衣室裡面換著浴衣，浴衣裡面是不能穿衣服的，不過要是不好意思不穿衣服，要穿個泳衣還內衣的，應該也是可以的（反正浴衣包著，也看不出來），這時候要記得的是，砂蒸溫泉比較特殊，是可以帶相機進去，到了砂蒸的地點把相機交給工作人員，他們會幫忙拍照。接下來走到砂蒸的地點，會有工作人員指示要躺在哪個地方，躺好之後，接下來工作人員就會把沙子堆在你身上。砂蒸完畢之後，繼續沿著指示路線走，會到室內的溫泉澡堂，這時可把身上的沙沖洗乾淨，然後再泡一下溫泉，就結束了砂蒸溫泉體驗。

溫泉結束之後我們開車沿著海邊開，到了指宿エコキャンプ場（指宿生態露營場），從這邊走到海邊，在退潮的時候,海面上會出現一條大約800公尺沙洲小路，又稱”愛之小路”, 可以走到一個無人小島知林ヶ島。冬季波濤洶湧，所以難以形成沙洲，因此每年也只有3月到10月退潮的時候才能放心地在愛之小路上行走 。


知林ヶ島愛之小路

下一站是往北開一百多公里到霧島神宮。霧島之所以名「島」，是因為這裡的山脈常被雲霧環繞，隱約可見的山峰有如在海上浮起的小島般。霧島也是與神靈有著深厚淵源之地，自古以来傳說為「天孫降臨之地」，傳說日本是由這裡開始的。霧島神宫是尊奉天津彥彥火瓊瓊杵尊（據說是日本第一代天皇神武天皇的曾祖父）的曽祖父的神社。


霧島神宮

今天是開始露營的第一天，不過因為語言也不是很通，所以我們也搞不懂松本先生的計畫到底是什麼。只見他一路開，路上也沒看到一個像樣的露營場，最後他跟著導航，到了一個廢棄的營地。不過我們後來才知道，松本先生就是走這種路線的，只要還算可以，車開到哪裡就可以睡在哪裡。基本上，他的車子到了晚上，後面的座位打平，就變成一個Queen size的床，可以睡三個人。

有興趣知道這個秘密營地的朋友，可以直接點下面的圖片


秘密廢棄營地


車子後面可以睡三個人

Day 3 熊本城及長崎雲仙市

今天的行程一早從霧島附近的不知名野營地出發，往北開124公里，到日本三大名城之一的熊本城。不過熊本城在2016年的熊本大地震的時候震毀了，據說要花20年的時間才能重新修復完成。雖然熊本城大多數地方不是毀壞就是在整修中，但是還是蠻推薦來的，一方面是了解到熊本大地震規模的可怕，一方面也可以看到日本人在修復古蹟上的認真，一磚一瓦都有編號，像拼圖一般的再修復回去。維基百科上說明整個修復費用逾600億日圓，預計2036年會修復完成。


整修中的熊本城天守閣

WSO2 EI 學習筆記（ㄧ）訊息傳遞架構

/在： /通過：

WSO2 Enterprise Integrator (原名為 WSO2 ESB) 是一個輕量化、元件導向、基於Java的企業服務匯流排(Enterprise Service Bus ESB)。有關於ESB的入門介紹，可以參考這部說明的淺顯易懂的影片。WSO2 EI是基於 Apache WSO2 ESB可以讓開發者整合各項服務及應用更加有效率極容易，license 授權是基於 APACHE LICENSE, VERSION 2.0 100%的開源而且是免費。此外新版的 WSO2 ESB 也提供能連接例如Salesforce、Google、Microsoft Dynamics 365、Dropbox …..非常眾多雲端服務的能力。此篇文章主要是利用 ESB訊息傳遞架構 來學習及暸解 WSO2 Enterprise Integrator

下圖為WSO2 EI訊息傳遞架構圖 (Messaging Architecture)

當服務的調用端 (Service Consumer) 調用服務時，會經過以下步驟：

1. 訊息先透過傳輸層 (Transport) 進行傳遞

我們在傳遞訊息的時候必須要考慮我們的訊息是由什麼方式傳遞，這就是 Transport 所扮演的角色，Transport支援各種 Protocol例如 HTTP、HTTPS、JMS…. 完整的列表可參考 ESB Transports

2. 建立 Enterprise Integrate mediation engine 能讀取及了解的 XML

依照訊息的內容格式(content type)，例如 SOAP、JSON、CSV… 選擇對應 message builder，將訊息從 raw data 轉換成後續 Enterprise Integrate mediation engine 能讀取及了解的 XML。

如果有特定的內容格式是預設不支援的，也可以自己撰寫 builders。可參考 Working with Message Builders and Formatters

3. Quality of Service (QoS)

接下來訊息或透過QoS元件確保的安全性及正確性。例如我們必須先檢查料號格式是否正確，客戶是否存在，客戶編號是否正確等等，或是訊息中的某些欄位是有加密的，我們也必須在此將其解密。詳細說明可參考 Applying Security to a Proxy Service

4. Mediation Engine

WSO2 EI 的 Mediation Engine 核心為 Apache Synapse 。以下列舉幾項重要功能：

4.1 訊息傳遞路徑 (Message Router)

Message Router 的，Message Router會以訊息的內容來決定如何轉遞訊息。我們可以用一般程式語言裡面常用到的 Switch 語法來理解 Message Router。我們會在 Message Router 中去定義或撰寫特定的邏輯，來決定該訊息內容會轉遞到哪個 Service 。
。
更完整的說明可參考 Message Router

4.2 訊息過濾 (Message filtering)

可以經由 WSO2 EI 中的 Message filtering 功能，將訊息依照所設定的邏輯傳遞至特定的路徑。也可以用程式語言常用到的 if/else 語法來理解這個功能。詳細可參考 Filter mediator

4.3 訊息轉換 (Message transformation )

當傳遞端及接收端有不一樣的資料格式，例如欄位名稱不同，欄位型態不同，欄位數量不同…等等。可參考 Message Translator 來進行轉換處理。 Mediator Engine 中的 PayloadFactory mediator 及 Data Mapper mediator 可用來處理訊息轉換。可以藉有此功能增加或是刪減訊息內容，或是將訊息內容轉換到另一個格式，也可以在這邊進行資料驗證之類的處理。

4.4 豐富化內容 (Content enriching)

可以使用 Enrich Mediator 將訊息結合其他資料來源，以組成接收端需要的資料內容。

5. 建立接收端能讀取及了解的 RAW data

參照上述第2步驟，當訊息要回應到接收端時，訊息自然也需要從WSO2 EI的XML轉換回接收端所使用的 Protocol 及 data format。例如原本 FTP (UDP) 傳送進來的資料，透過步驟2的 message builder轉換為WSO2 EI能了解的XML，處理完之後，再透過本步驟中的 message formatter 轉換成 REST API (HTTP) 送到接收端。

以上 ESB訊息傳遞架構 流程圖說明了當發起了一個服務請求 (Request) 的時候，訊息是如何在 endpoint (服務端點) 間傳遞的。架構流程圖上的所有元件都可透過 WSO2 EI management console 監控及管理。

Meteor + ReactJS 學習筆記（四）部署至 Heroku

/在： /通過：

如果 Web 應用是要在 Internet 存取的，或是這個應用是要 24 小時存取但是你並不想要維護一台機器，也不想要擔心資安及防火牆的問題。當然你可以選擇到 AWS、Azure、Google上租個主機，然後架設 Meteor，但是這樣花費的成本是比較高的，最快且節省成本的方式是直接使用 PaaS (Platform As A Service) 服務。各大雲端廠商都有 PaaS，比較知名的有 Google App Engine、AWS、IBM Cloud (從前叫做 Bluemix)、Microsoft Azure、RedHat OpenShift。本篇採用的是2011年被Salesforce 所併購的老牌 PaaS 平台 Heroku 來做說明如何將Meteor專案 部署至Heroku

Step 1: 安裝 Heroku CLI (Command Line Interface)

Mac 使用者可使用以下指令安裝

brew tap heroku/brew && brew install heroku

Windows 使用者可點選下面連結下載安裝檔
The Heroku CLI Windows Installer

Step 2: 建立一個 Meteor + ReactJS project

可參考上一篇說明。請自行選擇一個專案名，不要跟 meteor-heroku-demo 重複

meteor create --react meteor-heroku-demo

cd meteor-heroku-demo

Step 3: 將專案目錄進行 git 儲存庫的初始化 

git init

git add .

git commit -m "My first commit!"

Step 4: 建立 Heroku instance 

heroku login

heroku apps:create <你的專案名>

Step 5: 指定使用 Meteor Buildpack

在 Heroku 上面，執行不同程式語言的專案，有不同的 Buildpack，Buildpack 是用來將建置專案會使用到的相關資源及 Scripts 轉換成 slug，slug 是執行在 Heroku 和行 dyno 之上，裡面包含專案的 source code、相依的模組及資源、特定程式語言的 run time。
以下指令是執定 heroku 使用 admithub/meteor-horse 這個 buildpack，而 admithub/meteor-horse 是由 AdmitHub 所開發，用來生成 meteor 專案的 buildpack

heroku buildpacks:set admithub/meteor-horse

Step 6: 建立 MongoDB

Meteor 的 Server 端是使用 MongoDB，所以必須也在 Heroku 上設定好 Mongo 的環境，Heroku上提供 500MB 免費的 MongoDB ，可透過以下指令設定

heroku addons:create mongolab

或是使用以下指令設定你自己的 MongoDB

heroku config:add MONGO_URL=<your mongodb URL>

Step 7: 設定你的 Meteor app 執行在 Heroku 上 

heroku config:add ROOT_URL=https://<你的專案名>.herokuapp.com

Step 8: 確認 heroku 指令是沒問題的 

git remote -v

//應該會出現以下回覆

heroku https://git.heroku.com/meteor-heroku-demo.git (fetch)

heroku https://git.heroku.com/meteor-heroku-demo.git (push)

Step 9: 部署至Heroku 

git push heroku master

當出現類似以下畫面，代表建置完成

Step 10: 使用瀏覽器確認 App 是否執行

使用瀏覽器打開 https://<你的專案名>.herokuapp.com