Subscribed unsubscribe Subscribe Subscribe

Terraform "officially" supported Arukas!!

f:id:febc_yamamoto:20170111214425p:plain
The Arukas provider was added in Terraform v0.8.7.
In this article, I will introduce from how to sign up for Arukas.io to how to use it on Terraform.

What’s Arukas?

Arukas is a Docker hosting service.
arukas.io And is explained on the official website as follows.

Arukas is the simplest-to-use Container-as-a-service that makes it easy to deploy and manage apps at scale.

Arukas’s Key features

Arukas’s Key features are introduced on the official website.
Among them, I think the following two features are particularly useful:

  • Allocate the third-party accessible endpoint
  • Easy to Scale out

There are explained on the official website as follows.

Allocate the third-party accessible endpoint

All applications starts with their own end-point ( *.arukascloud.io ) that allows the third-party access.
You can customise the subdomain as you would like.

Easy to Scale out

Arukas is designed to help you operate at scale.
The robust and reliable infrastructure needed to cope with the scalability is available on demand.

For details on other key features, please see the official website.
Now, let’s look at how to use Arukas.

How to sign up for Arukas.io

Current how to sign up is described on following page of the official website.

arukas.io

There are two ways to sign up.

  • 1) Use E-Mail
  • 2) Use Github account(OAuth)

Please choose the one you like.
Currently it seems that the account will be activated in about one week.

How to generate API key

When sign up is completed, access the Arukas control panel from the following URL.

https://app.arukas.io/

First, generate API key as shown in the screenshot below.

f:id:febc_yamamoto:20170111201857p:plain
f:id:febc_yamamoto:20170111201902p:plain

Now, API key is generated and displayed on the screen as following.

f:id:febc_yamamoto:20170111201908p:plain

Please keep these for future use.

How to use Arukas with Terraform

Now, Let’s use Arukas from Terraform.

First, install terraform according to following installation guide.

www.terraform.io

Next, create *.tf file.
The entire configuration is shown below. Save the contents to a file named example.tf.

provider "arukas" {
    token = "API_TOKEN_HERE"
    secret = "API_SECRET_HERE"
}

resource "arukas_container" "foobar" {
    name = "terraform_for_arukas_test_foobar"
    image = "nginx:latest"
    instances = 1
    memory = 256
    ports = {
        protocol = "tcp"
        number = "80"
    }
    environments {
        key = "key1"
        value = "value1"
    }
}

Replace the API_TOKEN_HERE and API_SECRET_HERE with your Arukas API key.

Incidentally, documentation of arukas resources on terraform is on the following page.

www.terraform.io

Next , Run terraform apply in the same directory as your example.tf, and watch it go!

It will take a few minutes since Terraform waits for the Arukas container to become available.

$ terraform apply
arukas_container.foobar: Creating...
  app_id:                 "" => "<computed>"
  endpoint:               "" => "<computed>"
  endpoint_full_hostname: "" => "<computed>"
  endpoint_full_url:      "" => "<computed>"
  environments.#:         "" => "1"
  environments.0.key:     "" => "key1"
  environments.0.value:   "" => "value1"
  image:                  "" => "nginx:latest"
  instances:              "" => "1"
  memory:                 "" => "256"
  name:                   "" => "terraform_for_arukas_test_foobar"
  port_mappings.#:        "" => "<computed>"
  ports.#:                "" => "1"
  ports.0.number:         "" => "80"
  ports.0.protocol:       "" => "tcp"
arukas_container.foobar: Still creating... (10s elapsed)
...

arukas_container.foobar: Creation complete

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

...

Done! Now,looking at the Arukas control panel, you should be able to confirm that the container is created.
When you access the URL of the endpoint, the default page of NGINX should be displayed.

The basic usage is over.
Please run various containers and enjoy on Arukas!

Conclusion

Arukas is in beta testing until April 2017.
Until then it is completely FREE to use, so let’s use it now!

【golang】Don't use filtering by build tags to vendoring

日本語版:【golang】vendoring時はビルドタグでのフィルタリングは使わない方がいい

TL;DR

  • govendor can specify build tags to ignore when vendoring
  • But, files necessary for build may not be copied under the vendor directory
  • Problems such as failure to cross-compile may occur by not copying necessary files
  • So, the size of the vendor directory may increase, but it is simpler not to use filtering by build tags

Introduction

Currently, golang has many package management tools as following:

Many other tools are also introduced on this page.

PackageManagementTools · golang/go Wiki · GitHub

Among them, I often use govendor.

github.com

govendor is very easy to use, I use it in many projects.
However, there was a problem depending on the setting of govendor.

What is the problem?

Last month , I made a following PullRequest to Terraform.

github.com

This PR is for adding Arukas provider.
This new provider was already released separately from Terraform as the following third-party-plugin.

github.com

This PR was immediately merged and released in Terraform v0.8.3.

But, at that time,,,

f:id:febc_yamamoto:20170115213957p:plain

Build on Windows broke!!!

What's!? What's happened!?!?

The Arukas provider release as a third-party-plugin included the Windows version, and it was able to build without any problems.
From that time on, the source code has not changed at all, why has the build broken?

Who broke the build on Windows?

I looked for gopkg.in/alecthomas/kingpin.v2 which was in the message from @jbardin.

gopkg.in/alecthomas/kingpin.v2 is a library imported by the Arukas provider.
This library has been used since Arukas provider was released as a third-party-plugin, so I know that it is compatible with Windows.

And, both Terraform and the Arukas provider as a third-party-plugin use govendor for vendoring.
So I decided to compare the files of gopkg.in/alecthomas/kingpin.v2 library copied under vendor directory(that was copied by govendor).

Compare gopkg.in/alecthomas/kingpin.v2 files under vendor directory

The following screen shot shows the comparison result. f:id:febc_yamamoto:20170115233145p:plain

It seems that guesswidth.go has not been copied for some reason.

Why??

Answer: govendor was setted to ignore some build tags

The govendor configuration file vendor/vendor.json has the following setting:

https://github.com/hashicorp/terraform/blob/v0.8.4/vendor/vendor.json#L3

   "ignore": "appengine test",

govendor compares the value set in ignore in vendor/vendor.json with the file name suffix or build tags to determine if it is the target file to ignore.
In this case test and appengine are specified as ignore targets.

And, the build tag of the missing file guesswidth.go is as follows:

https://github.com/alecthomas/kingpin/blob/v2.2.3/guesswidth.go#L1

// +build appengine !linux,!freebsd,!darwin,!dragonfly,!netbsd,!openbsd

In case of *nix platform, guesswidth_unix.go is used instead of this file.
It has the following build tags:

https://github.com/alecthomas/kingpin/blob/v2.2.3/guesswidth_unix.go#L1

// +build !appengine,linux freebsd darwin dragonfly netbsd openbsd

With these build tags, the guesswidth.go file is used when building on Windows.
However, appengine is specified in ignore in vendor.json, so govendor ignores guesswidth.go!!!

In this way, you can build with *nix but not build on Windows,,,

So what should we do?

Conclusion

Filtering by build tag has the advantage of being able to reduce the size of the vendor directory, but problems such as being unable to build in some platforms may occur.
In addition, troublesome work such as checking the build tag of individual files to be imported will occur to solve the problem.

For these reason, filtering by build tag should not be used when vendoring.
(Note: I think filtering works well only for "test" and "ignore" tags)

What is a use case that requires filtering when vendoring? I don't have it.
What do you think?
If you have a nice way please comment to this post!

2016年 活動まとめ

2016年も残すところ僅かとなりました。
今年は実り多い年だったので、忘れないうちに活動内容をまとめておきます。

全体的には?

オープンソース活動、記事執筆ともに順調な1年でした。

  • アプリ開発 : 合計30本以上のリリース
  • 記事執筆:Qiita / さくらのナレッジ / ブログ 、合計42本を執筆
  • イベントでの発表: 1回/月程度の頻度で勉強会/イベントへ参加、うち3イベントで発表あり

GitHubのcontributionはこんな感じです。
f:id:febc_yamamoto:20161228224141p:plain

傾向として、土日は家族と過ごすことが多いため、平日のコミットが多めとなっておりました。

アプリ開発の実績

アプリ単体でリリースしたものだけで15アプリ、記事連動したアプリやDockerイメージなどの細々したものを含めると30以上のアプリのリリースを行いました。

ライブラリ関連

さくらのクラウドAPIライブラリ「libsacloud」

github.com

docker-machine-sakuracloudで得た、Go言語でのさくらのクラウドAPI操作のノウハウを他のプロダクトでも利用できるようにするために
APIライブラリとしてスクラッチ開発を行いました。

このライブラリは現在でもバンバン開発しており、公式のAPIライブラリ:saklientよりも機能が充実していたりします。
さくらのクラウドへ新たな機能が追加された場合、概ね1週間以内には対応しています。

2016年に開発したプロダクトの多くがこのlibsacloudを利用する形となっているため、本年の本格的な活動開始がこのプロダクトで正解だったと思っています。


さくらのIoT Platform用APIライブラリ「sakuraio-api

github.com

さくらのIoT Platform用のAPIライブラリです。
主に「Terraform for さくらのIoT Platform」での利用のために開発しました。
こちらは来年も順次充実させていく予定です。

なお、さくらのIoT Platform用のライブラリとしては、WebHook関連のライブラリとして以下のようなものもあります。

github.com

こちらは先の「sakuraio-api」に統合を予定しています。おそらく来年上旬あたりの対応となると思います。

Terraform関連

Terraform for さくらのクラウド

github.com

Terraform for Arukas

github.com

Terraform for さくらのIoT Platform

github.com

さくらのクラウド、Arukas、さくらのIoT Platformへの対応を行いました。
特にさくらのクラウドについてはさくらのナレッジにて入門記事の連載を執筆中ですので、引き続き対応を強化していきます。

Packer関連

Packer for さくらのクラウド

github.com

さくらのクラウド上にマシンイメージを作成するためのツール「Packer for さくらのクラウド」を作りました。 こちらは開発はひと段落させたつもりですので、来年は大きな機能追加などは行わずバグフィックス中心になる予定です。

Docker関連

Infrakit - さくらのクラウドプラグイン

github.com

2016年10月に発表されたDockerの新しいアーキテクチャへの挑戦「infrakit」のプラグインとして、
さくらのクラウド対応を試験的に行ってみたものです。
infrakit対応プラグインとしては世界最速での開発/発表を行うことができました。

infrakit自体のDockerへの取り込みはまだまだ見えない要素も多いのですが、
infrakit.awsの実装など、具体的な実装ができつつありますので、様子を見ながらさくらのクラウド対応を行うことを視野に入れています。

WordPress関連

WordPress + オブジェクトストレージ用プラグイン「wp-sacloud-ojs」

github.com

WordPress + ウェブアクセラレータ用プラグイン「wp-sacloud-webaccel」

github.com

依然シェアNo.1であり続けているCMSの王様「WordPress」にて、さくらのクラウドのプロダクトを利用するためのプラグインを作りました。
こちらは開発はひと段落ついたかなーと感じているため、来年はバージョンアップ対応やバグフィックス中心になりそうです。

監視関連

Mackerelとさくらのクラウドのインテーグレーションツール「Sackerel」

github.com

はてなさんのイケてる監視ツール「Mackerel」とさくらのクラウドをインテグレーションするツールを作りました。
今後はMackerelだけでなく、もっと汎用的に利用できるようにすべくアイディアを練っている段階です。
PrometheusやZabbixなど他の監視ツールともうまく連携できる仕組みにできればいいなーと漠然と考えています。

その他:さくらのクラウド関連の細々したツール類

さくらのクラウド上の全リソース削除コマンド「sacloud-delete-all」

github.com

さくらのクラウドへのISOイメージアップロードコマンド「sacloud-upload-image」

github.com

さくらのクラウドへのアーカイブアップロードコマンド「sacloud-upload-archive」

github.com

細かいCLIツールを作成しました。
各ツールがバラバラに存在してしまっていることや、公式CLIである「sacloud」の開発が停滞していることもあり、
そろそろさくらのクラウド関連のCLIツールをまとめて再編してコミュニティーツールとして提供するのがいいかな?とも考えています。

この辺りは考えがまとまっていないので来年はじっくり取り組むつもりです。

その他:Arukas関連のツール類

プルリクエスト駆動開発用デプロイパイプラインツール「arukas-ship」

github.com

GitHub〜DockerHub〜Arukasとデプロイパイプラインを形成するためのツールです。
GitHubにpushするだけでArukasへデプロイできます。

このツールはQiitaに紹介記事を書いたのですが、
投稿から半年近く経っても徐々にストック/PVが伸びている息の長いプロダクトだったりします。

Arukas関連のプロダクトについては、来年4月の正式リリースに合わせ、見直し/更新などを行う予定です。

その他:オープンソースプロダクト開発への参加

docker-machineやpackerなどへのコントリビューションを行いました。

記事の執筆(全42本)

Qiitaへの投稿(34本)

qiita.com

Qiitaへは大小合わせて34本記事を投稿しました。
特に印象深い記事をいくつかピックアップしておきます。


qiita.com

DockerBlogからの翻訳&紹介記事なのですが、非常に興味深い内容でした。
CGIのように、リクエストを受けたらDockerコンテナを起動し処理するという内容ですが、 Dockerを用いたサーバーレスな構成の一例として非常にインスピレーションを刺激してくれました。


qiita.com

Docker + infrakitについての紹介です。
未だにinfrakitについて国内のみならず海外でも情報が少ないです。貴重な日本語記事ではあるのですが、
すでに若干コードの更新などが行われていますので、もしinfrakitに大きめな動きがあるようであれば新たに記事を投稿するつもりです。


qiita.com

HashicorpのNomadを利用した環境構築例です。
Nomadはもっと流行ってもいい気はするのですが、、コンテナ界隈、特にオーケストレーション周りの熾烈な争いの中で Nomadは今ひとつ突き抜けられない感じがしていますので、しばらくは概要を軽く様子見する程度で良いかなーと感じてます。

さくらのナレッジへの投稿(6本)

knowledge.sakura.ad.jp

月に1本程度のペースで投稿しています。
現在はTerraformについての連載を行なっています。

連載中ではありますが、面白いものを思い付いたら連載の合間でも差し込みで投稿する予定です。

その他(2本)

Qiitaでのさくらのアドベントカレンダーに2本記事を投稿しました。

febc-yamamoto.hatenablog.com

febc-yamamoto.hatenablog.com

イベント参加などのコミュニティー活動

月に1回程度のペースで各種勉強会への参加など行いました。
その中で、発表を行ったのは以下3つでした。

さくらインターネット」のDockerホスティング「Arukas」と「Docker Machine」ドライバについてのイベント

sakura-kanto.doorkeeper.jp

4/27 にArukasの発表のついでにdocker-machine-sakuracloudについてお話しさせていただきました。

この時の資料はこちらです。

speakerdeck.com


さくらじまハウス

7月に鹿児島県桜島で行われたイベントにLT参加しました。

sakurajimahouse.tech

資料はこちらです。

speakerdeck.com


東京で消耗したくない!」西日本にいながら”IT界隈の人”になったエンジニアと交流する会in北九州

speakerdeck.com

発表の場がちょっと少なかったので、来年はどなたかぜひ招待してください!どこかで喋りたいです!

まとめ

ということで1年を振り返ってみました。

割と濃い開発/執筆活動ができたかなと思います。
来年はもっと喋る機会が増やせればいいなーと思っています。
イベントを企画中の方がいらっしゃいましたらぜひ招待してください!喜んで参加します!

以上です。

「Terraform for さくらのIoT Platform」作りましたー!

f:id:febc_yamamoto:20161223153418p:plain

この記事はさくらのアドベントカレンダー(その2)の18日目の記事です。
現在12/25ですが、空いていたので投稿させていただきました。

qiita.com

作ったよー!

ということで、TerraformでさくらのIoT Platformを操作するためのプラグインTerraform for さくらのIoT Platform」をリリースしました!

詳細は以下のGithubを参照ください。ドキュメントもある程度揃っています。

github.com

何ができるの?

さくらのIoT Platformのコントロールパネルでの以下の作業を自動化できます。

  • プロジェクトの登録/更新/削除
  • モジュールの登録/更新/削除
  • 連携サービスの管理
    • WebSocket
    • Incoming Webhook
    • Outgoing Webhook

連携サービスは他にもAWS IoTやMQTT Client、DataStoreなどがあるのですが、
これらはさくらのIoT PlatformのAPIドキュメントが公開され次第実装します。

余談: go言語でAPIクライアントを実装するにあたりgo-swaggerを利用しています。
このため、現在未実装の機能についてはAPIドキュメントにて定義ファイル(yml)が提供された後で実装をする予定です。

使い方は?

準備として、Terraform本体のダウンロード、このプラグインのダウンロード、さくらのIoT PlatformのAPIキーの取得が必要です。
詳しくは以下のページを参照ください。

terraform-provider-sakuraiot/installation.md at master · yamamoto-febc/terraform-provider-sakuraiot · GitHub

その後、以下のようなTerraform定義ファイルを作成してterraformコマンドを実行することで、 さくらのIoT Platformの環境構築が一発で行えます。

サンプル

# ------------------------------------------------------------
# プロジェクトの登録
# ------------------------------------------------------------
resource "sakuraiot_project" "project01" {
    name = "example project"
}

# ------------------------------------------------------------
# モジュールの登録
# ------------------------------------------------------------
resource "sakuraiot_module" "module01" {
    project_id = "${sakuraiot_project.project01.id}"
    name = "example module"
    register_id = "put-your-register-id"      # (要編集)通信モジュール本体に記載されているモジュール登録用ID
    register_pass = "pur-your-register-pass"  # (要編集)通信モジュール本体に記載されているモジュール登録用パスワード
}

# ------------------------------------------------------------
# 連携サービスとしてOutgoing WebhookとIncoming Webhookを登録
# ------------------------------------------------------------
# Outgoing Webhook
resource "sakuraiot_service_outgoing_webhook" "webhook01" {
    project_id = "${sakuraiot_project.project01.id}"
    name = "example outgoing webhook"
    secret = "secret"                         # HMAC-SHA1署名用のシークレット
    url = "https://your-webhook-server.com/"  # Outgoing Webhookの連携先URLを指定
}

# Incoming Webhook
resource "sakuraiot_service_incoming_webhook" "webhook01" {
    project_id = "${sakuraiot_project.project01.id}"
    name = "example incoming webhook"
    secret = "secret"                          # HMAC-SHA1署名用のシークレット
}

どんな時に使うの?

使い所はズバリ「他サービスとの連携がある環境の構築」です! 例えばさくらのIoT Platformの通信モジュールで受けたデータをArukasで動かす場合、

  • 1) Arukas上にWebSocketまたはIncomingWebhookなどの連携サービス用コンテナを起動しておく
  • 2) Arukasが割り当てたエンドポイントの情報を元にさくらのIoT Platformで連携サービス(Outgoing-Webhookなど)を登録

といった、複数サービスを行き来しながらの面倒な設定が必要になるのですが、この辺りが一発というのがポイントです。
もちろん、環境をコード化することによって、バージョン管理ができるようになったり、コードレビューが行いやすくなったり、環境の複製/再利用が行いやすくなる、などの様々なメリットを受けることもできます。

試しに複数サービス環境を構築

さくらのIoT PlatformとArukasを連携する環境を構築してみます。

  • さくらのIoT Platformにプロジェクトを作成
  • さくらのIoT Platformに通信モジュールを1台登録
  • さくらのIoT Platformに連携サービスとしてOutgoing-Webhookを登録、通信モジュールからのデータをWebhookでArukas上のコンテナへ送信
  • Arukasでは通信内容を表示するだけのエコーサーバーを起動しておく
  • Webhookは外部からの不正アクセスを防ぐためにHMAC-SHA1署名用のシークレット文字列を設定する

準備

はじめに以下のページを参考に、Terraform for さくらのIoT PlatformとTerraform for Arukasのインストールを行っておきます。

定義ファイル

Terraform定義ファイルは以下のようになります。

# ------------------------------------------------------------
# HMAC-SHA1署名用のシークレット文字列を定義
# ------------------------------------------------------------
variable secret { default = "secret" }

# ------------------------------------------------------------
# Arukas上にコンテナ起動
# ------------------------------------------------------------
resource "arukas_container" "echo_server" {
    name = "sakura_iot_echo"
    image = "yamamotofebc/sakura-iot-echo"
    ports = {
        protocol = "tcp"
        number = "8080"
    }
    environments {
        key = "SAKURA_IOT_ECHO_SECRET"
        value = "${var.secret}"
    }
}

# ------------------------------------------------------------
# さくらのIoT Platformへプロジェクトの登録
# ------------------------------------------------------------
resource "sakuraiot_project" "project01" {
    name = "example project"
}

# ------------------------------------------------------------
# さくらのIoT Platformへモジュールの登録
# ------------------------------------------------------------
resource "sakuraiot_module" "module01" {
    project_id = "${sakuraiot_project.project01.id}"
    name = "example module"
    register_id = "put-your-register-id"      # (要編集)通信モジュール本体に記載されているモジュール登録用ID
    register_pass = "pur-your-register-pass"  # (要編集)通信モジュール本体に記載されているモジュール登録用パスワード
}

# ------------------------------------------------------------
# さくらのIoT Platformへ連携サービスとしてOutgoing Webhook登録
# ------------------------------------------------------------
# Outgoing Webhook
resource "sakuraiot_service_outgoing_webhook" "webhook01" {
    project_id = "${sakuraiot_project.project01.id}"
    name = "example outgoing webhook"
    secret = "${var.secret}"                                                            # HMAC-SHA1署名用のシークレット
    url = "${arukas_container.echo_server.endpoint_full_url}"    # Arukasが発行するエンドポイントのURLを参照指定
}

あとはterraform applyするだけで環境構築できちゃいます。便利でしょ?

今後の展望

Terraformの現在のバージョン(2016年12月現在はv0.8.2)はAWS IoTをサポートしていません。
しかしすでにAWS IoTをサポートするためのPullRequestが来ているようですので、近日中に対応されるのではないかと思います。

この辺りも自動化できるようになるとさらに夢が広がりますね!

お願い:複数の通信モジュールをお持ちの方へ

私のお小遣いでは通信モジュールをひとつしか買えませんでした。。。
このため複数の通信モジュールを利用する場合のテストが不十分です。
もし複数のモジュールをお持ちの方がいらっしゃいましたらテストにご協力いただけると助かります!
できれば三つ以上の通信モジュールがあるといいですね!

終わりに

これでさくらのサービスでのTerraformサポートはクラウド、Arukas、IoT Platformと揃いました。 次は、、VPSですね!

|ω・`)チラ

さくらのVPSAPIで操作できるようにならないかなー

|ω・`)チラチラ

VPSは初期費用がかかったりするのでAPIでの操作は難しいかもしれないですが、
ちらほらAPI欲しいという声を聞きますので、、、

もしさくらのVPSAPIが公開されたらTerraform対応しますので、ぜひ公開をお待ちしております。


以上です。Terraform for さくらのIoT Platform、ぜひご利用くださいー!!

【永久保証付き】Arduino Uno

【永久保証付き】Arduino Uno

DevOpsを支えるHashiCorpツール大全 ThinkIT Books

DevOpsを支えるHashiCorpツール大全 ThinkIT Books

Terraform: Up and Running; Writing Infrastructure As Code

Terraform: Up and Running; Writing Infrastructure As Code

バルス!さくらのクラウドに物理的に「バルス」を実装してみた

f:id:febc_yamamoto:20161210212946p:plain

本稿はさくらインターネット Advent Calendar 2016(その1)の19日目の記事です。
前日の記事は@BakeTanukiさんによるKUSANAGI + ウェブアクセラレータという組み合わせについてでした。

a-lab.biz

この記事の中で拙作「wp-sacloud-webaccel」についてもご紹介いただきました!ありがとうございました!!


さて、今回はさくらのIoT Platformを使ったネタを仕込んでみました。
成功例だけでなく、途中の失敗体験を含めて詰め込んでしまったために長い記事になってしまいました。すいません。

さくらのIoT Platformに取り組む/取り組まれている方の参考になれば幸いです。

言い訳:
筆者はWeb系エンジニアであり、ハードウェアについてはいわゆる「Lチカ」ができる程度です。また、IoTへの取り組みは今回初チャレンジでした。
このため、当記事で作成するものについて実用性や安全性など考慮出来ていませんので、当記事を参考する際はその辺りご注意ください。

はじめに:Terraformプラグイン開発中のお悩み

Advent Calendar1日目の前佛さんの記事「Terraform for さくらのクラウド入門チュートリアル」にてご紹介いただいた、 Terraform for さくらのクラウドというTerraformプラグインについてですが、プラグインを開発している時、実際にさくらのクラウド上にリソースを作成するテストも多いため、こんな悩みがあります。

さくらのクラウド上にゴミリソースが溜まっていく。。。」

実際にさくらのクラウド上にリソースを作成するようなテストを行う際、 テストの異常終了などでクリーンアップ処理が正常に行われず、ゴミが溜まっていくことがあります。

後でまとめて消しても良いのですが、対象リソースによっては作成数の上限があるため、 こまめに削除しないとテストの実行がままならないというものもあります。 例えばデーターベースアプライアンスは上限数が1のため、リソース作成済みだとテストで新たに作成しようとしてもエラーになってしまいます。

「手動でポチポチ削除するのめんどくさい、、、」

「めんどくさいなー」と思いつつ、さくらのクラウド上のコントロールパネルをポチポチ操作してリソースを削除しようとすると、

  • 電源を切ってからじゃないと削除できない
  • 他のリソースと接続している場合、切断してからじゃないと削除できない(スイッチとか)

といったことがあり、泣きながら個々のリソースの電源断/切断などを行なってから削除、という作業をしていました。

そこでふと思い浮かんだのが、、、

バルス」って叫んだら、さくらのクラウド上の全リソース消せないかな?

ということでした。(バルスとは:Wikipedia)

とりあえずやってみよう!ということで、「バルス on さくらのクラウド」を実装してみることにしました。

バルス」を実行するための構成要素は?

参考サイト:天空の城ラピュタ:Wikipedia

まずはどのような機能/要素が必要なのかの検討のため、「バルス」の動きを以下の図で表してみました。

f:id:febc_yamamoto:20161210144707p:plain

①飛行石に触れ②「バルス」と叫ぶことで飛行石が反応します。

バルス発動条件には諸説あるようですが、ここでは飛行石に接触した状態で「バルス」と言えば発動すると仮定しています。

続いて飛行石が③呪文が「バルス」かの判定を行います。

飛行石は他にもいくつかの呪文に反応するため、 飛行石自体が音声への反応/認識ができるようになっているものと思われます。

条件を満たすと、飛行石が④ラピュタの中枢にあるコンピューターへ破壊を指示し、 ⑤ラピュタの破壊処理が行われ、ラピュタが落ちることになります。

バルス」を現実世界に落とし込んでみる:その1(失敗編)

先ほど「バルス」の機能/要素を抽出したため、それを現実世界で実現可能な方法に落とし込んでみます。

後述しますが、この方法は結果的に失敗に終わりました。。。
このため、具体的なコードは最低限のもの以外省略しています。

f:id:febc_yamamoto:20161210144552p:plain

飛行石に触っているかの判定を実装する

バルス発動条件である飛行石に触れるについては①タクトスイッチを押すことで実装できそうです。

バルス」と言われたかの判定を実装する

飛行石はそれ自体が音声を認識しているようですね。
現実世界においては音声認識モジュールなどを利用すれば実装できそうですが、音声認識モジュールは高価な部品です。
私のようなハードウェアに疎いエンジニアにとって、高価なハードウェアは使いこなせなかった時の心理的ダメージやトラブル時の対応への不安があるので出来るだけ避けたいものです。

複雑な処理はさくらのIoT Platformの通信モジュールを使ってリモートで全部処理しちゃえ!

そこで、今回は「さくらのIoT Platform」の通信モジュールを利用し、 ハードウェアは最小限の動き(AD変換とデータ送信)のみ行うようにすることで安価な部品で事足りるようにしてみました。

f:id:febc_yamamoto:20161210144610p:plain

さくらのIoT Platformは、公式サイトにて以下のように説明されています。

「さくらのIoT Platform」は、モノとネットワークでデータを送受信するための通信環境、データの保存や処理に必要なシステムを一体で提供するIoTのプラットフォームです。
モノに組み込むための「さくらの通信モジュール」と当社のデータセンターを、安全性を確保するためのLTE閉域網で接続し、ストレージ、データベースなどのバックエンドシステム、外部のクラウドやアプリケーションサービスとAPI連携システムを一体型で統合的に提供します。

さくらの通信モジュールは複雑な設定など必要なく、専用のシールドなどを利用してArduinoに接続すればすぐ使えるようになっています。
Arduinoで利用できるライブラリも提供されているため、簡単なメソッド呼び出しで通信を実現することができそうです。

マイク入力 + AD変換 + データ送信

②「バルス」と叫ぶと、

  • (③の1)マイクで音声を入力、ArduinoでAD変換
  • (③の2)変換したデータを通信モジュールでそのまま送信

という処理を行うようにします。

さくらのIoT Platformは外部との連携用にWebhookが使える

また、さくらのIoT Platformでは通信モジュールからのデータ受信時に外部のシステムと連携するためのOutgoing Webhookが用意されています。
今回はこれを利用して、Arukas上にバルス判定サーバーを立てて、そこにWebhookで通知、各種処理を行うようにします。

f:id:febc_yamamoto:20161210174514p:plain

ArukasはDockerコンテナのホスティング環境です。まだβ期間ということで無料で使えます。

バルス判定サーバーでの処理

バルス判定サーバーでは以下の処理を行います。

waveファイルは非常に単純なファイルフォーマットのため、簡単なバイナリーの操作(ヘッダの設定)で作成することができます。

今回はWebhookの受信処理やバイナリー操作を行うため、実装にはGo言語を採用しました。

さくらのクラウド上のリソース全消し処理

バルス」判定がOKだった場合はさくらのクラウド上のリソース全消しを行います。
これはさくらのクラウドAPIAPIライブラリを利用すればすぐに実装できますね。
バルス判定サーバーをGo言語で書いたため、こちらもGo言語で実装することとしました。


ここまでの処理をまとめると以下のような感じになります。
f:id:febc_yamamoto:20161215224045p:plain

では後はこれらが本当に実現可能かプロトタイピングしながら確認してみましょう。

プロトタイピングしてみる!

これらの機能要素が本当に実現できるのか、小分けにして実装を試してみました。

マイクの入力を扱う

まずはマイクとArduinoでどこまで音声が拾えるのか試してみました。

マイクは1個240円で売っていたノーブランド品のMAX4466を調達しました。
(2016年12月現在はノーブランドのものは品切れのようですが、スイッチサイエンスさんでも同等品を扱っているようでした)

エレクトレットマイクアンプモジュール

エレクトレットマイクアンプモジュール

Arduinoは永久保証の付いているスイッチサイエンスさんの品を選びました。
また、安価なArduino UNO互換品もありましたので、万が一に備えて予備として購入しておきました。

【永久保証付き】Arduino Uno

【永久保証付き】Arduino Uno

こちらのサイトを参考に、マイク+Arduinoと手元のMacをUSB接続し、Processingでwaveファイルを作成してみました。
以下の流れで、マイクからの入力をシリアル接続(USB)経由で手元のMacに送ってwaveファイル作成を行なっています。

  • (1) 手元のMacにてProcessingを起動
  • (2) Arduinoにてマイク(MAX4466)からのアナログ入力を取得
  • (3) 取得した値はArduinoからシリアル出力
  • (4) Processingにてシリアル入力を読みwaveファイルを作成

f:id:febc_yamamoto:20161210144619p:plain:w400

結果、多少のノイズは乗っているものの、十分に声が判定できるwaveファイルが出来ました。
必要があればバルス判定サーバー上でwaveファイルに対して波形編集を行うことで音圧調整やノイズ除去などを行うようにします。

(なお、参考サイトのコードだとサンプリングレートが足りず、Arduinoレジスタ設定でanalogRead()の速度アップを行ったりしました。 )

Azure Cognitive Servicesで音声(wave)からテキストへ変換してみる

Azure Cognitive Servicesとはマイクロソフトが提供している、AIを利用して様々な「モノゴトを認識させる」ためのAPI群です。

f:id:febc_yamamoto:20161210170932p:plain

ここでは、先ほど作成した音声ファイルをAzure Cognitive ServicesのAPIを利用してテキストへ変換してみます。

REST形式でAPIを呼び出してみる

以下のドキュメントを参考に、REST形式でAPIを呼び出してみました。

Azure Cognitive Services(Bing speech API)ドキュメント

  • Azure側の準備

本稿では詳細な手順は省略しますが、APIを利用するには、AzureポータルにてCognitive Services APIsを有効化しておく必要があります。
こちらのサイトなどを参考に準備し、 APIの呼び出しに必要なキーを発行しておきましょう。

  • curlコマンドでAPIを呼び出し

APIの挙動を確かめるため、以下のようなシェルスクリプトcurlコマンドを利用してAPIを呼び出してみました。
対象の音声ファイルはカレントディレクトリにtest.wavという名前で配置しています。

#!/bin/sh

# 認証トークンの取得
curl -X POST -H "Ocp-Apim-Subscription-Key:[Azureポータルで取得したAPIキー]" -H "Content-Length:0" https://api.cognitive.microsoft.com/sts/v1.0/issueToken > test_token

# API呼び出し
VERSION=3.0
REQUEST_ID=`uuidgen`
APP_ID=D4D52672-91D7-4C74-8AD8-42B1D98141A5
FORMAT=json
LOCALE=ja-JP
INSTANCE_ID=`uuidgen`
DEVICE=test

curl -v -L -X POST -H "Authorization: Bearer `cat test_token`" \
     -H "Content-Type: audio/wav; samplerate=8192" \
     --data-binary @test.wav \
     -m 30 \
"https://speech.platform.bing.com/recognize?version=$VERSION&requestid=$REQUEST_ID&appID=$APP_ID&format=$FORMAT&locale=$LOCALE&device.os=$DEVICE&scenarios=ulm&instanceid=$INSTANCE_ID"

呼び出しが成功すると、以下のようなJSONが取得できます。

{
    "header": {
        "lexical": "バルス", 
        "name": "バルス", 
        "properties": {
            "HIGHCONF": "1", 
            "requestid": "xxxxxxxx-nnnn-xxxx-nnnn-xxxxxxxx10xx"
        }, 
        "scenario": "ulm", 
        "status": "success"
    }, 
    "results": [
        {
            "confidence": "0.8237563", 
            "lexical": "バルス", 
            "name": "バルス", 
            "properties": {
                "HIGHCONF": "1"
            }, 
            "scenario": "ulm"
        }
    ], 
    "version": "3.0"
}

無事認識されているようですね!
これと同等の処理をバルス判定サーバー上に実装すれば良さそうです。

さくらのIoT Platformとの連携用にGo言語でWebhook受信サーバーを立てる

続いて音声データをさくらのIoT Platformから受け取るために、Go言語でWebhook受信用サーバーを実装してみました。
さくらのIoT PlatformとのWebhookやりとり部分は今後も汎用的に使いそうなので「sakura-iot-go」という名前でライブラリとして切り出してみました。

このライブラリを利用すれば、以下のようなコードでさくらのIoT PlatformからのWebhook受信サーバーを実装できます。

package main

import (
    "fmt"
    sakura "github.com/yamamoto-febc/sakura-iot-go"
    "net/http"
)

func main() {

    // パス"/"で待ち受け
    http.Handle("/", &sakura.WebhookHandler{

        // IoT Platformの管理画面(Outgoing Webhook)で設定したSecret
        Secret: "[put your secret]",

        HandleFunc: func(p sakura.Payload) {
            // [ここにWebhook 受信時の処理を書く]
        },
    })
    // ポート番号8080で待ち受け
    http.ListenAndServe(":8080", nil)
}

これで無事にIoT PlatformからのWebhookを受信できました。
バルス判定サーバーはこのライブラリを利用して実装するようにします。

Arukasで動かすためにDockerイメージ化

Arukas上で動かすためには、DockerイメージをDockerHubで公開しておく必要があります。
そこで、Go言語で実装したバルス判定サーバーを実行するDockerイメージを作成し公開することにします。

Dockerfileの作成

Dockerfileは以下のようになります。
Go言語でアプリケーションを実装すると、実行ファイル1つにパッケージングすることができるので、Dockerイメージ化は非常に楽です。
実行ファイルをADDしてENTRYPOINTに指定するだけ済んじゃいます。非常にシンプルですね。

FROM alpine:3.4
LABEL maintainer="Kazumichi Yamamoto <yamamoto.febc@gmail.com>"
MAINTAINER Kazumichi Yamamoto <yamamoto.febc@gmail.com>

RUN set -x && apk add --no-cache --update ca-certificates

ADD 作成した実行ファイル /bin/

ENTRYPOINT ["/bin/作成した実行ファイル"]

いよいよ通信モジュールを繋いでみる

f:id:febc_yamamoto:20161210144838p:plain

次に実際に通信モジュールを繋いでさくらのIoT Platform経由で音声データを送ってみます。

音声データのサイズはどれくらい?

今回は1秒間の音声データを取得することにします。
音声認識をするためには、サンプリングレート8000程度は欲しいところです。

1回のサンプリング(Arduino上でanalogRead()を実行する)で1byte(0〜255)の値を取得するようにすると、
1秒 × 8000回 × 1byte = およそ8Kbyte となります。

バッファが足りない、、、!?

通信モジュールが1回で送信できるデータには限りがあります。 (通信モジュールβ版ではバッファ/データキューは32個とのことでした。参考:データシート)
このため、溢れたデータはArduino上のメモリなどのバッファに置いておかないと消失してしまいます。

そして今回利用しているArduino(UNO)には利用可能なメモリとして2KbyteのSRAM、1KbyteのEEPROMしかありません。
このままではおよそ8Kbyteある音声データが溢れて消えてしまいます。

このため、バッファリング用のSRAMモジュール(32Kbyte)を個別に追加して対応しています。

F-RAMモジュール FM25W256

F-RAMモジュール FM25W256

音声データを送信してみる

タクトスイッチを押している間、マイクからの入力を取り込むことにします。
入力データは一旦バッファに置いて、順次通信モジュールで送信してみました。

ここで問題が!!!

ここまでは順調だったのですが、とうとう問題が発生してしまいました。その問題とは、、、

  • 通信モジュールからCMD_ERROR_BUSYというエラーが返ってくる
  • 1秒分のデータを送信完了するまで40秒以上かかる

という2つです。40秒では支度できないということですね。困りました。。。

何が悪いのか?

Arduino側で、以下のようなコードでデータ送信を行なっていました。

void flushSamples(){

  // Tx Queue
  uint8_t ret;
  uint8_t avail;
  uint8_t queued;
  uint8_t buf[8] = {0};

  // SRAMに置いたデータを順次処理する  
  for(int i = 0;i < MAX_DATA_LEN;i++){

    // バッファ(8byte)にデータが溜まったら通信モジュールのキューに入れる
    if (i > 0 && i % 8 == 0){
      ret = sakuraio.enqueueTx(DATA_CHANNEL, buf);
      // キューに入れたらバッファをクリア
      memset(buf , 0 , sizeof(buf));
    }

    buf[i%8] = (uint8_t)data.read(i);

    // 通信モジュールのキューの現在サイズを取得    
    sakuraio.getTxQueueLength(&avail, &queued);
    if(queued >= 30){  // 30個キューに溜まったら送信実施
      ret = sakuraio.send(); // [ここでCMD_ERROR_BUSYというエラーが頻発]
      while(ret != 1){       // send()が成功するまでインターバルを入れながらループする
        delay(500);
        digitalWrite(STATUS_LED_PIN, HIGH);
        delay(500);
        digitalWrite(STATUS_LED_PIN, LOW);
        ret = sakuraio.send();
        Serial.print(".");
        if (ret == 1){
          Serial.println("Done.");
        }
      }
    }
  }  
  
  // コントロール用のチャンネルに終了コードを入れておく
  sakuraio.enqueueTx(CONTROL_CHANNEL, END_CODE);

  sakuraio.send(); // キューに残っているデータを送信
}

とにかく短時間で大量のデータを送る必要があるのがネックなようです。
CMD_ERROR_BUSYとなったらインターバルを入れているため、さらに時間がかかることになります。。。

データ量を減らせばなんとかなるか?

データ量を減らしつつ、「バルス」を送信できないか、、、

と悩んでいると、ふと違うやり方を思いつきました。

そうだ!モールス信号があるじゃないか!

音声入力の代わりにモールス信号で「バルス」という文字を入力してもらうようにすればデータ量を減らせそうです。

しかもモールス信号の復号程度ならArduinoだけで処理ができるため、飛行石自体が「バルス」という言われたか認識するという元の処理に近い形が取れそうです。

ということで設計から見直して再チャレンジしてみました。

バルス」を現実世界に落とし込んでみる:その2(成功編)

f:id:febc_yamamoto:20161210144601p:plain

シンプル!非常に単純になりました。

Arduino①モールス信号入力を処理します。信号の入力にはタクトスイッチを利用することにしました。

入力されたモールス信号が「バルス」だった場合は通信モジュールで②データ送信を行います。

サーバー側はデータが到着したらリソース全消し処理を呼び出すだけです。

いけそう!実装してみる!

ということで、以下のような回路にしてみました。

Arduino + LEDが数個 + 入力用のタクトスイッチという非常にシンプルな構成です。

f:id:febc_yamamoto:20161210144546p:plain

入力は「バルス」の英語表現である「balus」をモールス信号にて行います。

注:英語表記はbalus以外にも諸説あるようです。

モールス信号で1文字正しく入力するごとにLEDを点灯させるようにしました。

こんな感じに仕上がりました。

上から見た写真:
f:id:febc_yamamoto:20161210144817p:plain

Arduinoのスケッチはこんな感じです。(抜粋)

#include <SakuraIO.h>
#include "constants.h"
#include "morse_code.h"

// モールス信号で入力するキーワード[ l = long , s = short]
String magicalSpell = "balus"; // [ lsss , sl , slss , ssl , sss]
const byte spellLen = 5;

// モールス信号入力用バッファ
String inputBuf[spellLen];
// バッファの現在位置
byte bufIndex = 0;

// タイマー(スイッチON開始時刻、スイッチOFF開始時刻、最終操作時刻)
unsigned long startTime , endTime , silentTime;

// モールス信号での文字入力ごとに点灯させるLEDの配列
int LEDs[] = {LED1,LED2,LED3,LED4,LED5};

// 文字区切り連続入力防止用
bool isSpacePushed = false;

// バルス処理中フラグ
bool isSpellCasting = false;

// さくらの通信モジュール(I2C)
SakuraIO_I2C sakuraio;

// -------------------------------------------------------------------

void setup(){

  Serial.begin(9600);

  // Arduino各ピンの入出力モード設定
  setupPinMode();

  // さくらの通信モジュールがオンラインなるまで待つ
  connecToSakuraIoT();

  // 初期化完了をシリアル出力でお知らせ
  printInitMessage(magicalSpell);

  // 初期化完了をLEDでお知らせ
  blinkLED(BLINK_INIT);

}

void loop(){

  // バルス処理呼び出し中か?
  if (isSpellCasting){
    checkSakuraResponse();
    return;
  }

  // 無操作になって一定時間経過したら文字の区切りとする
  if (isMorseSilent()){
    Serial.println("space");
    pushMorse(CODE_SILENT);
    isSpacePushed = true;
  }

  if (digitalRead(SW) == SW_ON){     // タクトスイッチが押されている
    digitalWrite(LED_STATUS , HIGH); 
    if (startTime == 0) {
      startTime = millis(); // スイッチONにした時刻
      silentTime = 0;
      isSpacePushed = false;
    }
  }else{                            // タクトスイッチを離した
    digitalWrite(LED_STATUS , LOW);
    if (startTime > 0 && endTime == 0) {
      endTime = millis(); // スイッチをOFFにした時刻
      isSpacePushed = false;
    }
  }

  // タクトスイッチのON/OFF両方の時刻から信号の長短(ツー/トン)を判定
  if (startTime > 0 && endTime > 0){
    if ( isMorseShort() ){      // short(トン)か?

      // 入力バッファへプッシュ
      Serial.println("short");
      pushMorse(CODE_SHORT);
      
    }else if ( isMorseLong() ){ // long(ツー)か?

      // 入力バッファへプッシュ
      Serial.println("long");
      pushMorse(CODE_LONG);
    }

    //判定したら時刻をクリア
    resetStartTime(); 

    // 無操作時間の開始時刻を保持しておく
    silentTime = millis();
  }

  // 無操作時間が閾値(RESET_DUR)を超えたら、それまでの入力をリセット
  if (silentTime > 0){
    if ( millis() - silentTime > RESET_DUR) {
      resetAll();
      blinkLED(BLINK_TIMER_RESET);
    }
  }


}

// 入力バッファにモールス信号を登録
void pushMorse(String code){
  
  if (code.equals(CODE_SHORT)){
    inputBuf[bufIndex].concat(CODE_SHORT);
  }else if (code.equals(CODE_LONG)){
    inputBuf[bufIndex].concat(CODE_LONG);    
  }else if (code.equals(CODE_SILENT)){

    // 単語区切りを受信した。キーワードの文字数までは1文字づつ正答確認を行う。    
    if (bufIndex < magicalSpell.length()-1){
      // 入力されたモールス信号(1文字分)をシリアル出力
      printInputedMorseCode(bufIndex, inputBuf[bufIndex]);
      
      if (isInputMorseOK(bufIndex)) {   // 正しい(キーワードと合致した)モールス信号が入力されたか?
        digitalWrite(LEDs[bufIndex] , HIGH);
        bufIndex++;
      }else{
        // 間違ったコードが入力されたため、メッセージを表示して入力リセット
        printWrongInputMessage();
        
        resetAll();
        blinkLED(BLINK_NOT_CASTED);
        return;
      }
      
    }else{

      // === 入力信号が「バルス」だった場合の処理 ===

      // 入力OKメッセージをシリアル出力
      printOKInputMessage(magicalSpell);
      
      blinkLED(BLINK_CASTED);
    
      sendToSakuraIoT();
    }
  }
}

// さくらのIoT Platformへ指示(処理開始コード)を送信する
void sendToSakuraIoT(){
  sakuraio.enqueueTx((uint8_t)SAKURA_IOT_CHANNEL, (uint32_t)SAKURA_IOT_START_CODE);
  uint8_t ret = sakuraio.send();
  if (ret == CMD_ERROR_NONE) {
    // エラーがなかったら呼び出し中フラグを立てる
    isSpellCasting = true;
  }
}

// さくらのIoT Platformからの応答をチェック
void checkSakuraResponse(){
  uint8_t avail , queued;
  // 受信キューの状態を問い合わせ(現在利用可能なキュー長、キューの中のデータ数)
  sakuraio.getRxQueueLength(&avail, &queued);

  // キューにデータがあれば
  if (queued > 0) {
    uint8_t channel;    // チャンネル
    uint8_t type;       // データのタイプ[i,I,l,L,f,d,b]
    uint8_t values[8];  // データ
    int64_t offset;     // オフセット
    
    uint8_t ret = ret = sakuraio.dequeueRx(&channel, &type, values, &offset);
    if (ret == CMD_ERROR_NONE) {
      // エラーがなかったらデータの確認
      if (channel == SAKURA_IOT_CHANNEL){
        if (values[0] == SAKURA_IOT_END_CODE){

          // 正常終了コードを受信
          blinkLED(BLINK_NORMAL_END);
          isSpellCasting = false;
          return;
          
        }else if (values[0] == SAKURA_IOT_ERROR_CODE){
          // エラーコードを受信
          blinkLED(BLINK_ERROR_END);
          isSpellCasting = false;
          return;          
        }

        // 未知の値は無視
      }
      // 未知のチャンネルでの受信は無視
    }
  }
  blinkLED(BLINK_WAITING_RESPONSE);
}

サーバー側実装

後はサーバー側の実装ですが、こちらはさくらのクラウドAPIを順次呼び出して削除処理を行うだけです。
せっかくなので先ほどの「sakura-iot-go」を利用するために、Go言語で実装してみました。

sacloud-delete-all

なお、この処理は汎用的に使えそうなのでGitHubで独立したリポジトリとして公開しています。

実行!

では順番に実行していきます。

ArukasやさくらのIoT Platformの設定を適切に行なった上で、モールス信号で「balus」と入力してみましょう!

やった!無事動きました!
さくらのクラウドのコントロールパネルを見ると、無事リソースが削除されていることも確認できました!

9Vの電池をつなげて動かすこともできますので、外出先でも「バルス」できますね!

まとめ

ということで、さくらのIoT Platformを使って悪ふざけをしてみましたw

今回の処理内容について

今回の処理の流れは

  • 信号の入力があったら
  • さくらのIoT Platformを通じて通信し
  • サーバー上で削除処理を実行

というものですが、ちょっとしたアイディアで色々な応用ができそうですね。

例えばサーバー上で商品の注文処理を実装すれば Amazon Dashボタンのような動きをさせることもできます。
夢が広がりますね!

失敗/設計変更について

最初の設計では、通信時のBUSYエラーや通信時間が結構かかるという辺りで躓いてしまいました。
大量のデータを短期間で送るということがそもそも通信モジュールの特性とマッチしてないように感じました。

結局、何がおきているのか/何が原因でダメなのかがわからず、設計変更で逃げるような対応となりました。
ハードウェアの絡む問題が発生した際はやはり詳しい専門家のアドバイスが欲しいなーと思いました。 (今回みたいにそもそも設計がダメとかあるだろうし)

とはいえ、さくらのIoT Platformならお試しするための敷居が低いため、まずはプロトタイプで検証という動き方をするのがいいのかなとも思いました。

感想

今回IoT初挑戦だったのですが、めんどくさそうな通信や連携の部分が思ったよりすんなりと書けたことが驚きでした。

電子工作=Lチカというレベルでも、さくらのIoT Platformを使うことで簡単に通信/外部との連携処理まで実装でき、しかもセキュリティーやその後のスケールアップはプラットフォーム側に任せてしまって関心のあるサービスの実装に注力できるというのはいいなーと思いました。

おまけ:今回の副産物

今回のものは悪ふざけで作成したものですが、そんな中でも副産物として実用できるライブラリが数個収穫できましたので以下にまとめておきます。

ついでに今回使ったコードについても全部(ダメだった方も)公開しています。

失敗した方がどんなソースだったのか気になる方は参照してみてください。

ライブラリ

今回のコード(失敗バージョン)

今回のコード(成功バージョン)

以上です。ここまでお読みいただきありがとうございました。

最近の活動について

気づいたら4年ぶりのブログ投稿です。

この間活動していなかったわけではないのですが、、

  • 業務にて古い技術を採用せざるをえない事情があり、積極的に技術関連のアウトプットをするモチベーションが低下してた
  • Qiitaに投稿するようになった

などにより、こちらには投稿できてませんでした。 最近はまた活動再開してきてますのでぼちぼち投稿していきたいです。

最近作ったもの紹介

Docker Machine さくらのクラウド

DockerMachineさくらのクラウド用ドライバを作りました。

Terraform for さくらのクラウド

Terraformさくらのクラウド用プロバイダを作りました。

紹介記事では概要や実際の設定メモ程度しか書いてないので ぼちぼちちゃんとしたスタートガイドを書く予定です。

libsacloud

さくらのクラウドAPIのGo言語用ライブラリを作りました。 saklientを参考にしていますが、フルスクラッチで開発してます。

上記のTerraform for さくらのクラウドでも利用しています。

最近の活動その他

他にもAutoScalingのサンプル記事書いたり、 カンファレンス/勉強会に参加したりしてます。

直近だとPHPカンファレンス福岡に参加しました。

今後の活動

未定ですが、もう少しTerraform for さくらのクラウドの ドキュメントを整備しておきたいですね。

本日は以上です。

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES)

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES)

DevOpsを支えるHashiCorpツール大全 ThinkIT Books

DevOpsを支えるHashiCorpツール大全 ThinkIT Books


JavaScriptMVCとCanJS、jQuery++、そしてDoneJSへ

何気なくTwitterでJavaScriptMVCについてつぶやいていたら、 JavaScriptMVC作者さんであるJustin Meyerさんから メンションいただきました。

私が集めてた情報であまり間違っていないようですのでまとめてみました。

 

CanJSとは

  • CanJSはJavaScriptMVCからMVC関連部分のみを切り出したもの

 

jQuery++とは

  • jQuery++はJavaScriptMVCのサブプロジェクトjQueryMXからDOM HelperとEventsを切り出したもの

 

のようです。

 

以下CanJSのドキュメントでのサンプルコードですが、JavaScriptMVCとほぼ同じですね。

var Todo = can.Model({ findAll : 'GET /todos', findOne : 'GET /todos/{id}', create : 'POST /todos', update : 'PUT /todos/{id}', destroy : 'DELETE /todos/{id}' }, {}) 

もちろん細かな所では変わっています。

今後のバージョンアップ(DoneJS)について

今後のことがCanJSのブログに 方針含めて記載がありました。 (ちなみに、現在のJavaScriptMVCのバージョンは3.2.2です)

  • JavaScriptMVC3.3(次期リリース)

    コアとしてCanJSを含むことになるが、移行の為にAPIに互換性を持たせる

  • JavaScriptMVC4.0(次期メジャーリリース、「DoneJS」に名称変更される)

    コアのAPIについてもCanJSにフィットするように変更される

本家フォーラムでCanJSやjQuery++関連が混在しているのは当然だったんですね。(フォーラム眺めてると、「JavaScriptMVC関連なんだけど、ここでいいのか?」なんて投稿もありました。)

私は現在JavaScriptMVCのドキュメント翻訳を進めてるんですが(一緒にやってくれる人大歓迎ですよ〜)、

とりあえずこのまま進めても無駄になるってことはなさそうですね。 一安心です。

 

追記:CanJSはroutingも含んでいるようですね。

http://forum.javascriptmvc.com/topic/canjs-and-bitovi 

 

それでは本日は以上です。