ボタンを記録装置にしてダイエットをしてみた

1. はじめに

これは、SORACOM Advent Calendar 2018 - Qiitaの25日目です。
食べすぎてしまいそうなときは、グッグッとダブルクリックして我慢し、
食べすぎてしまったときは、グーッと長押しし、
ストレスをコーヒーで逃したときは、グッとシングルクリックして記録を取り続けました。
　

2. 結果

ボタンが発売される事を知った10/25の体重を量りまして・・・重い

2018/10/25

12/25の結果は、
2kgの減量に成功！？誤差

2018/12/25

この間のボタンの押した回数から、結構食べすぎている事が多かったです。
最初の方は結構頑張って我慢していたのですが、70kgの壁は超えられず・・・

ボタンタイプ	意味	クリック数
SINGLE	コーヒー飲んでリラックス	37
DOUBLE	食べ過ぎ我慢	24
LONG	食べちゃった	36
合計		97

まだまだボタンは押せる回数残っているので、このまま続けてみたいと思います。
　
こちらは、最高記録です。

70kgの壁その1

70kgの壁その2

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

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

SORACOM ユーザーコンソールでは20回押した事になっています。

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

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

1. はじめに

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

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の部分が製造番号です。
登録するとこのように表示されます。

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

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

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

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

4. つぶやいた結果

1回押した場合
2回押した場合
長めに押した場合
via AWS IoT Tweetというところがミソです。
（Twitterの開発者アカウントからのつぶやきです。）

5. DynamoDBにも登録したり

6. まとめ

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

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

1. はじめに

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

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

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

• EC2(Amazon Linux AMI)

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

jawsugosaka.doorkeeper.jp

AWS歴半年でサーバーレスに関する内容で登壇して来ました。
最近話題のサーバーレスという事で参加者が増えすぎたので3会場繋いでやりました。
初めての登壇なのに大丈夫かな？
3会場同時なんかどうやるの？
とか思いましたが実はあんまり気にしていませんでした。
なんせ自分の担当があるので、それ以外のことは運営スタッフにおまかせ状態でした^^
　
第1会場 38人
第2会場 47人
第3会場 35人
計：120人
　
行きましたねー。100人超え。
私の担当は一番多い第2会場のAWSJでした。
しかもトップバッター。
　

　
とりあえずスクリーンの横に立って、やってる感出してみる。
　

　
ライブコーディング風に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から離れると音声が届かないので、ほとんど下を向いてしまっていたことに途中で気が付きました（笑）
　


　
ほっと一息、質問コーナー。
　
Q1.
苦労した所はどこですか？
　
A1.
コンテンツの作成は専門の会社にお願いしていたのですが、一部に PHP が使われていたり、ヘッダーやフッターに SSI が使われていたので困りました。
S3 に置くので PHP は使えないし、SSI も動きません。PHP は止めてもらって、というか無視して、SSI についてはローカル環境に Xampp をインストールしてそこにソースを置いて wget で SSI が展開された html を取ってきて S3 にアップロードするという事をやっていました。
共通部分に修正が入るたびに全ソース修正するのが段々大変になってきたので、共通部分は JSON に持たしてページを開いたときに JavaScript で JSON からタグを生成するように変更しました。
　
Q2.
S3に置くようにしてサイトのリニューアル前と後ではパフォーマンスは良くなりましたか？
　
A2.
はい。かなりサクサク動くようになりました。
　
　
　

さいごに

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

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

1. はじめに（有名人に会いに行く）

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

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

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

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

3. HoloLensと私

HoloLensを付けたままの発表スタイルを確立？！
左手めっちゃ重そうですけど（笑）
　

なかなかカッコ良く締められていました。
　

4. Hololensの動作原理概要

個人的な見解ではありますが、動作原理の解説がめちゃくちゃ面白かったです！！！
中身を知り尽くしているから説得力がある！
　

こういうの面白いです。物理とか入ってくると。
まとめ資料欲しいです。
　

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

これを聞きに来たのです。
最初から惹き込まれるトーク。
　

ゼロ・グラビティというやつらしく、指1本で動かせるとか。
（でも戻すときは両手です（笑））
　

このダイヤルが超便利なんです。
ちょっとしたオブジェみたいでカッコいいですね。

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

Surface Studio凄い！
ダイヤル便利そう。
デザイナー向け？
最後の方にデザイナー登場w#HoloLensJP #KMCN #HoloJP #TMCN pic.twitter.com/8UrtYQKKGL

— koichi (@koichi0814) 2017年2月4日

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

Surface Studioの凄さパート2

「感想どう？」の件www#HoloLensJP #KMCN #HoloJP #TMCN pic.twitter.com/Js6knm74HU

— koichi (@koichi0814) 2017年2月4日

　

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上ではこんな感じになります。ちょっと見にくいですが。。

　

3. 実行結果

実行するとこのようなウィンドウが表示されます。

　
このときのデバッグログの表示を確認してみましょう。

index.jsとbrowserwindow.jsの文字が表示されている事が分かります。
メインプロセスとレンダラプロセスではログの出力が異なるようです。
そしてレンダラプロセス内のwebviewタグで指定したwebview.jsのログが表示されていません。
ここでかなりハマりました。
メインプロセスとレンダラプロセスが頭の中でごっちゃになってしまって、 メインプロセスではconsole.logが出力されて、レンダラプロセスでは出力されないものだと思い込んでしまいました。
メインプロセス(index.js)側では最初console.logを出力しておらず、 console.logが表示された方がメインプロセスだと勘違いしていたから余計に分からなくなってしまいました。
　
ではwebview.jsのログを探してみましょう。
ウィンドウにフォーカスを当てて、option + command + I (アイ)を押すとデベロッパーツールが表示されます。
ここで出力されているログはなんと「browserwindow.js」でした。
　
webview.jsのログは一体どこへ？
ウィンドウ（index.html）の「Open Dev Tool」ボタンを押してみましょう。
このボタンはindex.htmlのwebviewに対してデベロッパーツールを表示するようにjsを書いています。

ありました！
こんな所に表示されるので、Electronのメニューバーやショートカットキーでデベロッパーツールを表示させてログを確認していると、 思わぬ落とし穴に嵌りそうです。
　

4. まとめ

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

5. 未解決の問題

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

ちなみに、JavaScript file:のところに指定してもしなくてもブレークポイントで止まるのはメインプロセスだけでした。