いつブロ

いつまで続くか分からないブログ(仮)主に趣味やプログラミングに関するメモを書いています。

3日間使ってみた料金など #SORACOM LTE-M Button powered by #AWS

現時点の利用状況と今月の予想。
今のところ29.73円ですね。
LambdaもDynamoDBも無料枠内に収まるので、このまま月末を迎えて30円程度になるかと。  
f:id:koichi0814:20181104191755p:plain

f:id:koichi0814:20181104192306p:plain

SORACOM ユーザーコンソールでは20回押した事になっています。
f:id:koichi0814:20181104193038p:plain

DynamoDBに登録された件数の確認。
1行目のはテストなのでボタンが押されてLambdaまで実行されたのは15回ですね。 f:id:koichi0814:20181104193249p:plain
 
ボタンと AWS IoT1-Click を紐付けるときに1回は押すのと、
ボタンを開封した際に1回押したので2回は空振りしているような感じです。
また、ボタンを押したときに赤色で点滅したりしたことが何回かあったので、それを加えたら調度20回なんだと思います。
 
通信エラーか何かでもボタンを押したカウントがされているのではないかと思われるのですが、そこはどうなんでしょう?

最速で実装 #SORACOM LTE-M Button powered by #AWS

1. はじめに

SORACOM から AWS IoT Button のLTE版が出ました!

f:id:koichi0814:20181030234306p:plain
LTE-M 内蔵ボタンデバイス「SORACOM LTE-M Button powered by AWS」

このボタンが何かという説明は上記のリンクを参考にしてもらえればと思うのですが、 簡単に説明すると、これは物理的なボタンを押して AWS Lambda を起動できるというものです。

今までは AWS IoT エンタープライズボタン というのがありましたが、Wi-Fi での通信しかできませんでした。 この SORACOM のボタンはLTEに対応しているので、電波の届く範囲であればどこでもボタンを押して Lambda が起動できます。
 

2. ボタンを押して Twitter でつぶやく

Lambda を起動できるということは色々なことができます。手頃なところで Twitter でつぶやくというものがあります。つぶやいたからどうなのという話は置いておいて。

SORACOM ボタンを使えるようにする手順をざっくり説明します。

  1. 現時点でボタンを購入できるのは、SORACOM ユーザコンソール で発注するしかないのでアカウントを取得します。
  2. AWS のアカウントを取得します。
  3. Twitter の開発者アカウントを取得します。
  4. Lambda を実装します。(Twitter の開発者アカウントのキーやトークンを使います)
    シングルクリック、ダブルクリック、長押しの3タイプでつぶやく内容を変更します。
  5. AWS の IoT 1-Click というサービスでボタンと Lambda を紐付けます。
  6. ボタンを押します。

 

3. 少し分かり難い AWS IoT 1-Click の設定

SORACOM から AWS への通信までは割とスムーズに行ったんですが、
そこから Lambda を呼び出すときに躓いたので一連の設定方法を書いておきます。

3-1. SORACOM ユーザコンソール でデバイスを登録します。

まずは、注文履歴からデバイスを受け取り済みにしましょう。
次にメニューのガジェットからButtonsを選択します。
バイス登録のボタンから製造番号を入力します。
ボタンの中のDSNの部分が製造番号です。 f:id:koichi0814:20181102122504p:plain
登録するとこのように表示されます。 f:id:koichi0814:20181102121936p:plain

3-2. AWS の IoT 1-Click でデバイスを登録します。

ここに入力するのは、さきほどSORACOMの画面で登録した製造番号と同じ番号です。 f:id:koichi0814:20181102122743p:plain
入力後ボタンを押すように促されます。 f:id:koichi0814:20181102122918p:plain
登録は直ぐに完了します。 f:id:koichi0814:20181102123027p:plain
「管理 > デバイス」でデバイス一覧を開き、デバイスIDを選択すると次のような画面が表示されるので、 ここでデバイスを有効にします。 f:id:koichi0814:20181102123257p:plain

3-3. IoTプロジェクトを作成します。

「管理 > プロジェクト」からプロジェクトを新規作成します。 f:id:koichi0814:20181102123642p:plain
続いてLambdaと紐付けます。
画面が見切れていますが、プレイスメントの属性は特に入力しなくても問題ありません。 f:id:koichi0814:20181102124112p:plain
プレイスメントの属性は不要ですが、プレイスメントは必要です。(これに躓きました) f:id:koichi0814:20181102124512p:plain
すでに登録しているので編集画面にはなりますが、このようにボタンとの紐付けが必要です。 f:id:koichi0814:20181102124755p:plain

4. つぶやいた結果

1回押した場合 f:id:koichi0814:20181102125150j:plain
2回押した場合 f:id:koichi0814:20181102125203j:plain
長めに押した場合 f:id:koichi0814:20181102125212j:plain
via AWS IoT Tweetというところがミソです。
Twitterの開発者アカウントからのつぶやきです。)

5. DynamoDBにも登録したり

f:id:koichi0814:20181102125347p:plain

6. まとめ

ボタンを押したらプログラムが動くのはとても面白いですね!
単純な動作だから誰でもできるし、LTEに対応しているのでどこでも使えるのが良い!
数秒のタイムラグはあるけど本当に数秒だったので使い所は色々ありそうですね。

AWSでCI環境を構築するシリーズ① NginxでJenkinsとGitBucketを動かす

1. はじめに

AWSでCI環境を構築するときのメモです。
長くなりそうなので複数回に分けてアップしようと思います。

今回はNginxでJenkinsとGitBucketを動かす話を書きます。
次回以降はSSLに対応させる話を書こうと思います。
(こちらは需要がなさそうだったらお蔵入りに)

今回使うAWSのサービスはこちらです。

2. Java8のインストー

ec2を初めて起動したらアップデートです。

$ sudo yum update -y

Jenkins2系とGitBucketはjava8を使うのでインストールをします。

$ sudo yum install java-1.8.0-openjdk.x86_64

EC2にはデフォルトでJava7がインストールされているので、Java8に切り替える必要があります。

$ sudo alternatives --config java

2 プログラムがあり 'java' を提供します。

  選択       コマンド
-----------------------------------------------
 + 1           /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java
*  2           /usr/lib/jvm/jre-1.8.0-openjdk.x86_64/bin/java

Enter を押して現在の選択 [+] を保持するか、選択番号を入力します:

ここで2を選択します。

3. Jenkins2のインストー

yumリポジトリにJenkinsを追加

$ sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo

Jenkinsのインストール時に使われる公開鍵をインポート

$ sudo rpm --import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key

Jenkinsインストー

$ sudo yum install jenkins

起動

$ sudo service jenkins start

自動起動

$ sudo chkconfig jenkins on

4. GitBucketのインストー

$ cd

/home/ec2-user

GitBucket用のディレクトリを作る

$ mkdir gitbucket
$ cd gitbucket

GitBucketのwarをダウンロードする

$ wget https://github.com/gitbucket/gitbucket/releases/download/4.14.1/gitbucket.war

GitBucketの起動

$ java -jar /home/ec2-user/gitbucket/gitbucket.war --port=8090 --prefix=/gitbucket --gitbucket.home=/home/ec2-user/gitbucket&

自動起動
/etc/rc.d/rc.local に書き込む

$ echo "java -jar /home/ec2-user/gitbucket/gitbucket.war --port=8090 --prefix=/gitbucket --gitbucket.home=/home/ec2-user/gitbucket&" >> /etc/rc.d/rc.local

5. nginxのインストールと設定

インストー

$ sudo yum install nginx

設定

$ sudo vi /etc/nginx/nginx.conf

40行目の server { の中に以下の設定を追加

    location ~ /jenkins {
        proxy_redirect     off;
        proxy_set_header   X-Forwarded-Proto $scheme;
        proxy_set_header   Host              $http_host;
        proxy_set_header   X-Real-IP         $remote_addr;
        proxy_set_header   X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header   Host $host;
        proxy_pass         http://jenkins_server;
    }
    location ~ /gitbucket {
        proxy_redirect     off;
        proxy_set_header   X-Forwarded-Proto $scheme;
        proxy_set_header   Host              $http_host;
        proxy_set_header   X-Real-IP         $remote_addr;
        proxy_set_header   X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header   Host $host;
        proxy_pass         http://gitbucket_server;
    }

JenkinsとGitbucketの設定ファイルを作成

$ sudo vi /etc/nginx/conf.d/jenkins.conf

upstream jenkins_server {
    server 127.0.0.1:8080 fail_timeout=0;
}

$ sudo vi /etc/nginx/conf.d/gitbucket.conf

upstream gitbucket_server {
    server 127.0.0.1:8090 fail_timeout=0;
}

起動

$ sudo service nginx start

自動起動

$ sudo chkconfig nginx on

6. それぞれのサーバーへのアクセス

Jenkins

http://ec2のパブリックDNS/jenkins

GitBucket

http://ec2のパブリックDNS/gitbucket

次回予告

次はSSLでアクセスする為にELB(ロードバランサー)を使います。
ELBは443ポートで待ち受けていて、EC2の80ポートへ流します。
ELBとEC2は関連付けられるので設定は簡単です。

ただし、Jenkinsが内部でhttp://〜にリダイレクトしている箇所があるので、
このままの設定だと思わぬ動きをしてしまいますのでその対処法を書きたいと思います。

☆初登壇☆JAWS-UG大阪 第18回勉強会 サーバーレス #jawsug

f:id:koichi0814:20170226230514j:plain

jawsugosaka.doorkeeper.jp

AWS歴半年でサーバーレスに関する内容で登壇して来ました。
最近話題のサーバーレスという事で参加者が増えすぎたので3会場繋いでやりました。
初めての登壇なのに大丈夫かな?
3会場同時なんかどうやるの?
とか思いましたが実はあんまり気にしていませんでした。
なんせ自分の担当があるので、それ以外のことは運営スタッフにおまかせ状態でした^^
 
第1会場 38人
第2会場 47人
第3会場 35人
計:120人
 
行きましたねー。100人超え。
私の担当は一番多い第2会場のAWSJでした。
しかもトップバッター。
 
f:id:koichi0814:20170226232614j:plain
 
とりあえずスクリーンの横に立って、やってる感出してみる。
 
f:id:koichi0814:20170226233037j:plain
 
ライブコーディング風に15分で簡単なサーバーレスなアプリ(呼び方あってるのかな?)を構築している動画を再生している所!
ライブコーディングだと緊張して打ち間違いや手順を間違えたり、パニックになったりするので、15分でサーバーレスなアプリを構築できるように何度も練習して動画にしたものを15分に編集しました(笑)
 
はじめてのAWSサーバーレスということで、業務で実際に使っている内容を簡単なサンプルで再現する事にしました。
作ったサンプルはフォームに生年月日を入力して送信すると年齢を返すというもので、こんな手順で作りました。

  1. S3 のバケットと CloudFront を作成
    CloudFront 経由でしか S3 に直接アクセスできないようにします
  2. Lambda に設定するロールを作成
    S3 にファイルを作成するのでフルアクセス権限を持ったロールを作成します
  3. Lambda を作成
    パラメータの生年月日から年齢を計算して、結果を S3 に JSON ファイルとして格納します
    ファイルを作成したあとは、結果の画面を表示するために Location を指定して転送します
  4. API Gateway を作成
    Lambda は JSON を受け取る前提になっているので、フォームで入力された生年月日をJSONマッピングして Lambda を呼び出します
    Location をヘッダーにマッピングして 302 として返すようにします
    API Gatewayを直接呼び出されないようにキーも設定しておきます
  5. API Gateway 呼び出す CloudFront を作成
    API Gateway の URL を CloudFront の呼び出し先として設定します
  6. S3にソースをアップロード
    フォームの Action に API の CloudFront の Domain Name を設定します
  7. 完成
    1.で作った CloudFront の Domain Name をブラウザに入力して動作確認を行います

手順を間違えずにスムーズにサーバーレスを構築するのって、しっかりと頭に入ってないと難しかったです。
でもたった15分でサーバーレスができちゃうんですよね〜。
 
動画なので間違えたりしないのですが、
「ここを〜」とか「ここで〜」とか自分のMacに話しかけちゃってダメな感じでした。。。
しかも他の2会場に繋いでいるのでMacから離れると音声が届かないので、ほとんど下を向いてしまっていたことに途中で気が付きました(笑)
 
f:id:koichi0814:20170227000724j:plain
f:id:koichi0814:20170227004810j:plain
 
ほっと一息、質問コーナー。
 
Q1.
苦労した所はどこですか?
 
A1.
コンテンツの作成は専門の会社にお願いしていたのですが、一部に PHP が使われていたり、ヘッダーやフッターに SSI が使われていたので困りました。
S3 に置くので PHP は使えないし、SSI も動きません。PHP は止めてもらって、というか無視して、SSI についてはローカル環境に Xampp をインストールしてそこにソースを置いて wget で SSI が展開された html を取ってきて S3 にアップロードするという事をやっていました。
共通部分に修正が入るたびに全ソース修正するのが段々大変になってきたので、共通部分は JSON に持たしてページを開いたときに JavaScriptJSON からタグを生成するように変更しました。
 
Q2.
S3に置くようにしてサイトのリニューアル前と後ではパフォーマンスは良くなりましたか?
 
A2.
はい。かなりサクサク動くようになりました。
 
 
 

さいごに

スライドというか動画は300MBもあるのでどうやって公開しようか考え中です。。
言うの忘れていましたが、弊社ではクラウドエンジニアを絶賛募集中です!!

Osaka HoloLens Meetup vol.1 に参加してテンション上がった

1. はじめに(有名人に会いに行く)

f:id:koichi0814:20170205064704j:plain
Osaka HoloLens Meetup vol.1
HoloLens日本リリース記念ハンズオン&meetup 参加レポートです。
 
HoloLens持ってないし全く興味もないまま参加してきました。
参加の動機は、日本マイクロソフト株式会社 エバンジェリスト・業務執行役員である西脇 資哲さんに一度お会いしたかったからです。
あの「エバンジェリスト養成講座」の西脇さんですね。
 
もちろん勉強会の参加者の中には知り合いは居ませんでした!
(途中で気が付いたんですがお一人居ました)
そんな状態だったので、受付もぼっちで・・・と思って向かっていると、
まさかのちょまどさんが受付に居らして、コミュ障MAXに緊張してしまいました。。。
しかも横には西脇さんも居られて、、、
「あ、どうも〜」みたいな感じで、、、
Twitterのアイコンは自分の写真にしていたので認識されていたのかも知れません。(勝手な想像です。)
初っ端から超有名人に迎えられて(?)どうしていいものか戸惑ってしまいました(笑)
 
会場に入るとハンズオンからの参加者が既にお寿司を食べながらご歓談の様子だったので案の定輪に入れずでしたが、座席が空き放題で最前列の良い場所が確保出来てそれはそれで良かったです。
発表される方は絶対に前の方に集まるはずなので、それを見越しての最前列確保です。
西脇さんもすごく近くに座って居られましたが、最後の最後まで喋れず(笑)
何とか勇気を振り絞ってご挨拶出来たのは最後の集合写真のときでした!
目的は果たせました!
 
それにしてもちょまどさんはこの日のためにわざわざ大阪まで来られたそうで凄いですよね!
若い内からこんな行動力を発揮するなんて。ここはぜひ見習いたいですね。
私の会社にもこんな人欲しいです(笑)
絵も上手で漫画も描けてプログラミングも出来て英語も話せる、こんな人居ないですよ。普通。
これからのクリエイターをリードするマイクロソフト社員としては秀逸で必須なんじゃないでしょうか。
IT業界全体としても。
 
今回の勉強会参加でたくさんエネルギーを貰いました!
ほんと参加して良かったです!
 
という感じでした。
ふ〜。HoloLensの事何にも書いてない。
書きます書きます。
 

2. HoloLensの概要と、Windows Holographicに向けて

f:id:koichi0814:20170205065204j:plain
もちろん、中村さんの事は知らずに参加しました(笑)
HoloLensの話はこちらにまとまっています。
Natural Software
 
32bitのWindows10が内蔵されているということで、3次元の中でExcelを立ち上げたり、メーラーを立ち上げたり空間の中で作業が出来るそうです。

HoloLensを付けたら寝ながらでも仕事出来るようになるのかな。
 
スライドどこにあるのでしょう・・・
 

3. HoloLensと私

f:id:koichi0814:20170205070919j:plain
HoloLensを付けたままの発表スタイルを確立?!
左手めっちゃ重そうですけど(笑)
 
f:id:koichi0814:20170205071204j:plain
なかなかカッコ良く締められていました。
 

4. Hololensの動作原理概要

f:id:koichi0814:20170205071311j:plain
個人的な見解ではありますが、動作原理の解説がめちゃくちゃ面白かったです!!!
中身を知り尽くしているから説得力がある!
 
f:id:koichi0814:20170205071513j:plain
こういうの面白いです。物理とか入ってくると。
まとめ資料欲しいです。
 

5. マイクロソフトの最新テクノロジー

f:id:koichi0814:20170205071918j:plain
これを聞きに来たのです。
最初から惹き込まれるトーク。
 
f:id:koichi0814:20170205071950j:plain
ゼロ・グラビティというやつらしく、指1本で動かせるとか。
(でも戻すときは両手です(笑))
 
f:id:koichi0814:20170205072007j:plain
このダイヤルが超便利なんです。
ちょっとしたオブジェみたいでカッコいいですね。

言葉で表すのは難しいのでこちらの動画を見てもらった方が良いかもです。
 
西脇さんによるSurface Studioの紹介

 
個人的参加のちょまどさんによるライブドローイング
 

6. まとめ

HoloLensもSurface Studioも凄かったです!
今回全く知らずに参加しましたが、HoloLensって単なるVRだと思っていましたがそうじゃなかったです。
そもそもHoloLensのMRというものを理解する必要がありました。
www.buildinsider.net
Surface Studioのダイヤルはめちゃくちゃ便利なんじゃないでしょうか?
ダイヤルなんて昔からあるのにアナログがデジタルと融合したときの感動は凄いものがありましたよ。

Electronのconsole.logでハマる

1. はじめに

このエントリーはElectron Advent Calendar 2016 - Qiitaの3日目です。
 
分かっている人からすれば極々当たり前の事なんでしょうが、
私はめちゃくちゃハマったのでここに記録しておきたいと思います。
 
何にハマったかというと、console.logを使ったログ出力です。
console.logを使うとIDEのコンソールウィンドウにログが出力されるのだろうなと思っていて、 実際にやってみると確かに表示されたのでデバッグで簡単にログを出したいときはそうやっていました。 ところが、コンソールウィンドウに表示されないときがありました。
 

2. 開発環境

macOS Sierra
WebStorm 2016.3.1
 Application Parameter --enable-logging
 ECMA Script 6
Node.js 6.5.0
Electron 1.4.8
 
ソースは以下のような構成でした。
test_pj
- node_modules
- browserwindow.js - index.html
- index.js
- package.json
- style.css
- webview.js
 
プロジェクトの作り方も一応説明しておきます。
nodebrewを使ってNode.jsをインストールして、Node.jsのパッケージマネージャをpackage.jsonを作ります。

nodebrew install-binary v6.5.0
nodebrew use v6.5.0

cd ~/Documents/
mkdir test_pj
cd test_pj
npm init -y

package.jsonはこんな感じで作られます。

{
  "name": "test_pj",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}

次はElectronをインストールします。
--save-devとするとpackage.jsonに追記してくれます。

npm i electron-prebuilt --save-dev  

続いてpackage.jsonを修正します。
7行目に「"start": "electron index.js",」を追加します。

{
  "name": "test_pj",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "start": "electron index.js",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "electron-prebuilt": "^1.4.8"
  }
}

こんな感じでプロジェクトを作っていきました。
 
続いてindex.jsを作成します。
package.jsonのmainに書いたこのjsがメインプロセスといいます。
メインプロセスから作成するBrowserWindow(10行目)がレンダラプロセスです。ちょっとややこしいかも知れません。

"use strict";

const {app} = require("electron");
const {BrowserWindow} = require("electron");

let mainWindow;

app.on("ready", function() {
    // こっちがレンダラプロセス
    mainWindow = new BrowserWindow({width: 1000, height: 800, "node-integration": false});
    mainWindow.loadURL("file://" + __dirname + "/index.html");
    // mainWindow.openDevTools();
    mainWindow.on("closed", function() {
        mainWindow = null;
    });
});

// デバッグログ
console.log("index.js");

上の11行目でindex.htmlを指定しているので、index.htmlを作ります。
 
index.htmlでは15行目にwebviewタグを使っていて、srcに指定したgoogle.comを画面いっぱいに表示します。
16行目のscriptタグでbrowsewindow.jsも読み込みます。

<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <title>test_pj</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
<div id="menu-bar">
    <input type="text" id="url" value="http://electron.atom.io/">
    <button onclick="load();">Load</button>
    <button onclick="opendev();">Open Dev Tool</button>
</div>
test
<webview id="webview" preload="webview.js" src="http://google.com" style="position:absolute;width:100%;height:100%;"></webview>
<script type="text/javascript" src="browsewindow.js"></script>
</body>
</html>

webview.jsはデバッグログを出力するだけです。

"use strict";

console.log("webview.js");

browsewindow.jsは画面のボタンに対する処理を書きます。

"use strict";

console.log("browserwindow.js");

function load(){
    let url = document.getElementById("url").value;
    let webview = document.getElementById("webview");
    webview.setAttribute("src",url);
}
function opendev(){
    let webview = document.getElementById("webview");
    webview.openDevTools();
}

WebStorm上ではこんな感じになります。ちょっと見にくいですが。。
f:id:koichi0814:20161127130108p:plain
 

3. 実行結果

実行するとこのようなウィンドウが表示されます。
f:id:koichi0814:20161127130414p:plain
 
このときのデバッグログの表示を確認してみましょう。
f:id:koichi0814:20161127132442p:plain
index.jsとbrowserwindow.jsの文字が表示されている事が分かります。
メインプロセスとレンダラプロセスではログの出力が異なるようです。
そしてレンダラプロセス内のwebviewタグで指定したwebview.jsのログが表示されていません。
ここでかなりハマりました。
メインプロセスとレンダラプロセスが頭の中でごっちゃになってしまって、 メインプロセスではconsole.logが出力されて、レンダラプロセスでは出力されないものだと思い込んでしまいました。
メインプロセス(index.js)側では最初console.logを出力しておらず、 console.logが表示された方がメインプロセスだと勘違いしていたから余計に分からなくなってしまいました。
 
ではwebview.jsのログを探してみましょう。
ウィンドウにフォーカスを当てて、option + command + I (アイ)を押すとデベロッパーツールが表示されます。
ここで出力されているログはなんと「browserwindow.js」でした。 f:id:koichi0814:20161127132043p:plain
 
webview.jsのログは一体どこへ?
ウィンドウ(index.html)の「Open Dev Tool」ボタンを押してみましょう。
このボタンはindex.htmlのwebviewに対してデベロッパーツールを表示するようにjsを書いています。
f:id:koichi0814:20161127133801p:plain
ありました!
こんな所に表示されるので、Electronのメニューバーやショートカットキーでデベロッパーツールを表示させてログを確認していると、 思わぬ落とし穴に嵌りそうです。
 

4. まとめ

f:id:koichi0814:20161128002717p:plain
こんな感じでしょうか。
レンダラプロセスでのconsole.logも全部WebStormに出てくれたら良かったんですがね。
 

5. 未解決の問題

ついでに現時点でよく分かっていない問題があるので、誰か教えてくれるかも知れないという期待を込めて書いておきます。
それはデバッグ実行時にブレークポイントで止まってくれるのがメインプロセスのみという問題です。
WebStormだからなのか、WebStormでもちゃんと設定すれば止まってくれるのか分かっていないのです。
ブレークポイントで止まってくれていればconsole.logなんて出さなくても良い筈なんです。。。
念のため設定情報を貼っておきますね。
f:id:koichi0814:20161128004256p:plain
ちなみに、JavaScript file:のところに指定してもしなくてもブレークポイントで止まるのはメインプロセスだけでした。

#わいた温泉郷 という所に行って来ました

f:id:koichi0814:20160918223956j:plain
 
この写真は はげの湯温泉 旅館 山翠 の窓から撮影したものです。
当日は大雨の警報が出ていたのにもかかわらずこの地域のみ晴れるという幸運に恵まれました。
 
目の前に広がる景色の中、モクモクと出ている蒸気の所が「わいた地熱発電所」です。
住民の方々が作られた発電所だそうで、日本で16年ぶりの地熱発電所になるとのこと。
地熱発電について調べてみると日本は火山大国なのに意外と地熱発電所は少ないようです。
 
この写真は早朝に撮ったんですが、霧がすごく出ていてまるで天空の地熱発電所を見ているような気になりました。
天空の城で有名な竹田城跡の倍の標高750mもありますからね。
 

はげの湯温泉 旅館 山翠

f:id:koichi0814:20160918233324j:plain
どうしても頭の方の「はげ」しか思い浮かばないんですが(笑)
ロビーにはお土産が置いてあって「はげソーダ」というソーダが売っていました。
「実際にはハゲません」というコメントも付いていて、これは全力でネタにしてくれと言わんばかりに(笑)
写真撮り忘れたのが残念〜。
 
こちらの温泉は美肌効果があるそうで、確かにツルツルしている感じです。
帰って来て2日経ちますが、二の腕なんかはまだツルツルしている感じがします。
 
f:id:koichi0814:20160918232357j:plain
f:id:koichi0814:20160918232403j:plain
旅館では新鮮な刺し身が出てきて、これがまたぷりっぷりで美味しかったんですよ!
私はお酒が飲めないので、もうずっと食べていました。おかわりしたいぐらいに!
隣からは「あれ?もう刺し身がない」という声が聞こえてきましたが、それぐらい箸が止まりませんでした(笑)
 
自分のお土産にはこちらの2つを買いました。
「牛乳かすたーどぱい」も「シェフのわたぼうし」も妻が美味しいと言っていたので超オススメです。私が美味しいと言うと大体妻の口に合わない事が多いのですが、今回は意外と意見が一致しました(笑)
私は「シェフのわたぼうし」がお気に入りです。
作っている所が同じ会社なので両方美味しいのも頷けますね。
f:id:koichi0814:20160918234432j:plain
 

地熱を利用してパクチーの栽培

f:id:koichi0814:20160919000049j:plain
植えたばかりのパクチー。この台が他にも何個もあって、収穫体験もさせてもらいました。
手で引っこ抜くだけで簡単に収穫出来ました。
 
f:id:koichi0814:20160919000605j:plain
向こうの方に生い茂っているのが収穫用のパクチーです。
左右に分かれている所を収穫したんですが、結構な量です。はい。
 
このあと収穫したパクチーを麻婆豆腐に和えたりして戴きました。
初めて食べたんですが、天ぷらにしても美味しいかもって思いました。
天ぷらで思い出したけど、この山で山菜とか採れないのかな?と思ってみたり。
 

小国両神社

f:id:koichi0814:20160919001743j:plain
途中立ち寄った神社です。周りが山だからか何か神々しいものを感じます。

f:id:koichi0814:20160919002409j:plain
この絵馬の大きさ。これが絵馬なんですって。
他にも博物館に置いて有りそうなものもあって、面白い体験が出来ました。
ここでも写真少なめだったのが心残り〜。
 

まとめ

わいた温泉郷がある熊本県阿蘇郡小国町は崖のような階段の上にある神社や、山の奥の方にある祠などカメラが好きな人には特に面白いと思える題材が沢山あります。
温泉宿も他にもあるので、今度は違う宿に泊まりつつまだ行っていない所への散策もでき、非日常を味わうにはもってこいの場所だと思いました。
今度行ったらもっと写真撮りたいと思います。
ちなみにわいた温泉郷での撮影は約700枚でした。
まだまだ撮り足りない〜。