S3の署名付き URLを利用する際に注意する3つのポイント #aws #s3 #lambda #python #serverless

f:id:uchimanajet7:20190329093949p:plain

今回は

みんな大好きAWS S3ですが、署名付き URL(Pre-Signed URL)という便利で素敵な機能が利用できます。

非常によく利用される機能なので、ここで稚拙な 説明を書くようなことは割愛しますが、公式ドキュメントだと以下 Amazon CloudFront のドキュメントに詳細が書かれています。

docs.aws.amazon.com

今回はこのS3の機能をPython AWS Lambda で利用する際にハマったポイントを共有します。

Boto3 ドキュメントの確認

今回利用したAWS SDK Python(Boto3)のドキュメントを確認してみると

boto3.amazonaws.com

generate_presigned_url(ClientMethod, Params=None, ExpiresIn=3600, HttpMethod=None) となっており ClientMethod に get_object や put_object と言った署名付き URLにて操作を許可したいメソッドを指定して、Paramsbucket namekey name を指定するだけで戻り値として署名付きのURLが得られる完結な作りになっています。

通常は特に気にせず利用すればハマることもないかと思います。 今回は短時間ではなく1週間程度の期限を想定したことと、AWS Lambdaを利用したことでハマるポイントを作ってしまった形になります。

また、これに加えて Amazon S3 における AWS 署名バージョン についても考慮する必要があったため解決まで色々試行錯誤することになりました。

Point.1 実行権限について

AWS Lambdaを利用する場合 IAM role を利用して実行時に必要最低限の権限を付与した IAM policy を利用する形になるかと思います。

今回も個人的に好きな Chalice (Python Serverless Microframework for AWS) を利用しています。詳細は以下をご確認ください。

github.com

uchimanajet7.hatenablog.com

Chalice のメリットである IAM policy 自動生成は当然ながら利用するので generate_presigned_url(ClientMethod, Params=None, ExpiresIn=3600, HttpMethod=None) 関数するだけで問題ないと思っていました。

しかし、実際には自動生成で作成された IAM policy はClientMethod に記載したメソッドを 加味しない 状態で作成されていました。権限的には許可されていない状態となります。

この状態で generate_presigned_url を実行すると 権限不足で実行が失敗する と思っていましたが、実際には実行は問題なく終了して署名付きのURLが取得できます。

この取得したURLにアクセスすると、この段階で権限がないというエラーが表示され何も操作することができません。

だとしたらURL発行の段階で教えて欲しいのですが・・・ちょっと残念な仕様ですね。

以上を踏まえて generate_presigned_urlを利用して署名付きのURLを取得した場合で、アクセス権限が無い といったエラーでアクセスが行い時は、そもそも署名付きのURLを発行している IAM policy が必要な権限を持っているか確認することをお勧めします。

今回はIAM policyの自動生成を利用していたため、この部分に気がつくのが遅くなりだいぶ遠回りをして時間を無駄にした感が強いです・・・単純なところのなので見逃しがちですが、皆様はお気をつけください。

Point.2 有効期限について

IAM policy を追加して無事にアクセスはできるようになりました。 しかし今度は署名付きのURLが指定した有効期限より前に失効してしまう現象に遭遇しました。

この段階で指定していたのはExpiresIn=864000(10日間)でドキュメントには特に制限は書かれていないので原因が分からず困っていました。

boto3.amazonaws.com

しかしWebを検索してみると問い合わせが多い内容のようで以下の公式ドキュメントが展開されていました。

aws.amazon.com

AWS Identity and Access Management (IAM) インスタンスプロファイル: 最大 6 時間有効

AWS Security Token Service (STS): 最大 36 時間有効 (AWS アカウントユーザーや IAM ユーザーの認証情報など、永続的認証情報を使用して署名した場合)

・IAM ユーザー: 最大 7 日間有効 (AWS 署名バージョン 4 を使用した場合)

という記述があることから最大 7 日間なのかーという部分しか確認せずにExpiresIn=604800を指定してみましたが、残念ながら有効期限より前に失効する状況は改善しませんでした。

それもそのはずで、よく読めば利用している認証情報で有効期限の最大値が決まり、その最大値で有効期限が失効するということになります。

AWS LambdaだとIAM role を利用しているので、AssumeRole アクションにてAWS STS から一時トークンを取得し、その一時トークンで認証を行なっていることになります。

そのため、上記ドキュメントに記載のSTS 利用時に合致し指定している7日を待たずに失効する形になっていました。

ちなみに AssumeRole は

docs.aws.amazon.com

By default, the temporary security credentials created by AssumeRole last for one hour. However, you can use the optional DurationSeconds parameter to specify the duration of your session. You can provide a value from 900 seconds (15 minutes) up to the maximum session duration setting for the role. This setting can have a value from 1 hour to 12 hours. To learn how to view the maximum value for your role, see View the Maximum Session Duration Setting for a Role in the IAM User Guide. The maximum session duration limit applies when you use the AssumeRole API operations or the assume-role CLI commands. However the limit does not apply when you use those operations to create a console URL. For more information, see Using IAM Roles in the IAM User Guide.

の記載があるので、有効期限が最大でも12時間となるので今回はこの制限でURLも同時に失効していたことになります。

で、修正するにはどうすればいいのかと言うと・・・

最大 7 日間有効な署名付き URL を作成するには、まず、使用する SDK への IAM ユーザー認証情報 (アクセスキーとシークレットアクセスキー) を指定します。次に、AWS 署名バージョン 4 を使用して署名付き URL を生成します。

の記載にあるように、IAM user を利用する必要があるのでアクセスキーとシークレットアクセスキーをAWS Lambda中で指定して署名付き URLを生成する必要があります。

AWS Lambdaのソースコード中にアクセスキーとシークレットアクセスキーを持たせるわけにはいかないので、今回は定番のAWS Systems Manager パラメータストアを利用しました。

docs.aws.amazon.com

使う側からするとSTSの有効期限を7日までに伸ばす方法があるか、URL文字列にこの情報を含めずにURLを作ってくれる方が嬉しいんですが・・・そこは将来に期待しております。

あとは、以下のページにあるスニペットをそのまま使えば 問題なく7日間有効な署名付き URLが生成できます。

aws.amazon.com

import boto3
from botocore.client import Config

# Get the service client with sigv4 configured
s3 = boto3.client('s3', config=Config(signature_version='s3v4'))

# Generate the URL to get 'key-name' from 'bucket-name'
# URL expires in 604800 seconds (seven days)
url = s3.generate_presigned_url(
    ClientMethod='get_object',
    Params={
        'Bucket': 'bucket-name',
        'Key': 'key-name'
    },
    ExpiresIn=604800
)

以上を踏まえて 署名付きのURLが指定した有効期限より前に失効する場合は、利用している認証情報一時トークンを使用していないかを確認することをお勧めします。

また、合わせて署名バージョンについても SigV4AWS 署名バージョン 4)を利用する必要があるため、確認することをお勧めします。

今回はIAM roleで取得した一時トークンを利用していたことと、署名がSigV2で行われていたことの2点が問題となっていました。 SigV4を利用していないだけかと思い、もう一つの認証情報の件にたどり着くのが遅くなりました。皆様はお気をつけください。 今回は最終的にAWSサポートに確認して作業を行いましたが、AWSサポートは対応が素晴らしいのでもっと早めに確認するべきだったと。

Point.3 署名バージョンについて

前述のSigV4AWS 署名バージョン 4)を利用する件については、ここ最近のSigV2 廃止の話題でご存知かもしれません。

dev.classmethod.jp

docs.aws.amazon.com

Amazon S3 における AWS 署名バージョン 2 の廃止

Amazon S3 における署名バージョン 2 は廃止され、署名バージョン 2 の最終サポートは 2019 年 6 月 24 日に終了します。2019 年 6 月 24 日以降、Amazon S3 は署名バージョン 4 を使用して署名された API リクエストのみを受けつけます。

ということで、上記のページを読んでみると利用しているBoto3(Python)については

この SDK または製品を使用する場合 この SDK バージョンにアップグレード Sigv4 を使用するために、クライアントでコード変更が必要ですか。
Boto3 1.5.71 (Botocore)、1.4.6 (Boto3) にアップグレード。 はい

との記載がありました。Boto3のバージョンアップだけではなくクライアントでコード変更が必要 という記載があります。 これはPoint.2で紹介したコードスニペットをみると分かりますが

aws.amazon.com

import boto3
from botocore.client import Config

# Get the service client with sigv4 configured
s3 = boto3.client('s3', config=Config(signature_version='s3v4'))

S3のクライアントconfig=Config(signature_version='s3v4'))作成時に明示的に SigV4の利用を宣言する必要があるためとなります。

コードとしては以下のあたりが該当するかなーと。

github.com

github.com

署名バージョンの確認については、S3のログを利用して確認しました。

docs.aws.amazon.com

最近のアップデートでログに署名バージョンが出力されるようになったようです。

dev.classmethod.jp

docs.aws.amazon.com

Change Description Date
Added new fields to the server access logs Amazon S3 added the following new fields to the server access logs: Host Id, Signature Version, Cipher Suite, Authentication Type, and Host Header. For more information, see Amazon S3 Server Access Log Format. March 5, 2019

S3 サーバーアクセスのログはベストエフォートでの配信となるので 1時間程度経過したのちに配信されることになるかと思います。

docs.aws.amazon.com

ベストエフォート型のサーバーログ配信

サーバーアクセスログレコードの配信は、ベストエフォートで行われます。ログ記録用に適切にバケットを設定した場合、そのバケットへのほとんどのリクエストについてログレコードが配信されます。ほとんどのログレコードは、記録された時間から数時間以内に配信されますが、配信間隔は短くなる場合もあります。

サーバーログの完全性や適時性は保証されません。リクエストのログレコードが、リクエストが実際に処理されてからかなり後に配信されたり、配信すらされないこともあり得ます。サーバーログの目的は、バケットに対するトラフィックの特性を理解することです。ログレコードが失われることはまれですが、すべてのリクエストが完全に報告されるとは限りません。

サーバーのログ作成機能はベストエフォート型であるため、AWS ポータルで利用できる使用状況レポート (AWS マネジメントコンソール でレポートされる請求およびコスト管理レポート) には、サーバーログに記録されていないアクセスリクエストが含まれる場合があります。

さらに今回はログを確認する手段としてDatadogを利用しました。 ログインテグレーションを行なっていれば検索も簡単に行えますし 他のAWS関連メトリクスと1箇所で確認できるのは非常に便利ですね。

docs.datadoghq.com

以上を踏まえて 署名バージョンについては、Boto3(Python)に関してはSigV4を使うために明示的にプログラム中でバージョン指定が必要であり、これを行わないとSigV2で通信されていることがわかりました。

単純にSDKのアップデートでは対応できないことになるので、S3に対してアクセスを行なっているプログラムを確認する必要があります。

今後はSDK側のデフォルトがSigV4に変更というような方向で対応していただけると簡単で良いですが、影響範囲が大きそうなので無しの方向なのかなぁ

まとめ

  • Amazon Simple Storage Service (Amazon S3)

    aws.amazon.com

  • Simple って難しいなと思いました

  • AWSサポートは対応が相変わらず素晴らしいのでちゃんと利用しましょう
  • SigV2 がデフォルトなのは知らなかったです
  • STSの期限についてはworkaroundでもいいので延長できる方法が欲しいです
  • 権限がないのにURLが発行できるのもエラーで終わってもらえると良いきがします
  • Boto3側のドキュメントにSigV4の話とかリンクでいいので追加されていると親切だと思いました
  • Datadogはログインテグレーションして検索も簡単に!
  • 他のAWSメトリクスも合わせて1箇所で状態が確認できるので便利でした
  • 相変わらずドキュメントの読み込みが甘くて余計な手間が増えているなーと
  • ドキュメントはちゃんと読みましょう!

以上になります。

AWS Lambda Go, Amazon Comprehend, Amazon Translate で作るSlack 翻訳Bot #aws #lambda #slack #golang #serverless

Go Support for AWS Lambda

もう発表されて結構経ちますが、AWS Lambdaでgolangが利用できるようになりました。

aws.amazon.com

待ちに待ってたので嬉しいのですが、業務でgolangを使う機会もなく・・・

LTのネタに

そんな状態のところにLTどうですか?とのお声がけがあったので、これはネタにするしかない!

mastercloud.connpass.com

と、いろいろと作業はしてみたのですが・・・結局間に合わずw

uchimanajet7.hatenablog.com

以前に書いたblogを資料にするだけになってしまいました・・・

speakerdeck.com

せっかくなので

とは言え、LTのネタにしようと作業自体は行っていたので時間のあるときにチマチマと作ってみてました。

github.com

とは言っても、機能自体は特に変更なく実装をAWS Lambda Goで行ったという感じです。

github.com

また、翻訳する部分をこれを書いている時点ではプレビューのAmazon Translateで行っています。当然ですが利用するにはプレビュー利用の申請が必要となります。

aws.amazon.com

加えて Amazon Translate には翻訳元の言語自動判定を行える機能がこれを書いている時点ではないようです。これを補う手段としてAmazon Comprehendを利用しています。

aws.amazon.com

結果としてAWSのサービスのみで完結することができたので、外部APIを使う際に気になる翻訳文字列を外部に送信するところは気にせずに済むようになりました。

AWS Lambda functions in Go

以下のリポジトリAWSが用意してくれたサンプルコードがあるので、特に困らず利用できると思います。

github.com

個人的には楽しみに待ってたので非常に嬉しいです。 実際に使ってみると

  • ビルド結果が1バイナリなので細かいことを気にしないで良い
  • デプロイも1バイナリなので簡単
  • AWS SAMとの相性も良さそう
  • 個人的に好きな言語なので開発が楽しい
  • イベントごとにハンドラーを用意すれば良さそう

github.com

  • 普段使ってるgolangのライブラリが使えるのはやっぱり便利
  • kelseyhightower/envconfig はステキ

github.com

  • nlopes/slack を使ってSlackとのやりとりを簡単に

github.com

  • Slack APIからinvalid_limit Error が戻って来る
  • どうやらライブラリ側の問題っぽい
  • せっかくだから Pull Request を出してみた

github.com

  • このような場合でもgo getした手元のコードを修正するだけで動作させられるのは気軽で簡単で良いです

Amazon Translate

f:id:uchimanajet7:20180223084357p:plain

翻訳のためにAWSのサービスであるAmazon Translateを使ってみました。

  • これを書いている時点ではプレビュー
  • 利用には申請が必要
  • プレビュー中なのもあってか対応言語が少なめ
  • 基本の言語である英語と以下の6言語

docs.aws.amazon.com

  • Arabic (ar)
  • Chinese (Simplified) (zh)
  • French (fr)
  • German (de)
  • Portuguese (pt)
  • Spanish (es)
  • 翻訳元の言語を自動判別する機能がない
  • これもプレビュー中なのもあってなのか、翻訳元か翻訳先の言語のどちらか片方が英語でなければダメ

docs.aws.amazon.com

  • SourceLanguageCode
    • One of the supported language codes for the source text. If the TargetLanguageCode is not "en", the SourceLanguageCode must be "en".

  • TargetLanguageCode
    • One of the supported language codes for the target text. If the SourceLanguageCode is not "en", the TargetLanguageCode must be "en".
  • 日本語への対応が待たれる
  • 今後のアップデートに期待

Amazon Comprehend

f:id:uchimanajet7:20180223084539p:plain

言語自動判別のためにAWSのサービスであるAmazon Comprehendを使ってみました。

  • 単純にSlackのメッセージを言語判定するAPIに渡しているだけ

docs.aws.amazon.com

  • Comprehendにも対応言語がある

docs.aws.amazon.com

  • 料金の設定で100 文字を単位として計算されるため、今回のような使い方だと勿体無い感がある

aws.amazon.com

自然言語処理 (NLP): Amazon Comprehend のエンティティ認識、感情分析、キーフレーズ抽出、言語検出のリクエストは、100 文字単位で計算され、各リクエストにつき 3 単位 (300 文字) が最低料金となります。

  • 実際に今回の使い方だと思ったより料金がかかる印象
  • Comprehend自体がもっと大量の文章を対象にしているためな気がする
  • 複数の言語が混在している場合の自動判定結果
  • 他のサービスでも同様だがこの辺の判定が思ってるものと違うと利用が難しい
  • ComprehendはAWSマネジメントコンソールから簡単に試せるので触ってみるのが良い

AWS Serverless Application Model (AWS SAM)

デプロイのためにAWS Serverless Application Model (AWS SAM)を使ってみました。

docs.aws.amazon.com

  • golangはビルド結果が1バイナリなので相性が良かった
  • LambdaとAPI Gatewayしか設定してないのでテンプレートも簡単だった
  • 複雑なことをしないなら手軽でいい感じ
  • 環境変数を設定するのでオプションの設定が手軽にできると良い気がする
  • せっかくのgolangなのにAWS CLIの利用が前提なのが若干残念

docs.aws.amazon.com

  • 今後もLambda Goを使うなら一緒に使っていこうと思った

まとめ

  • AWS Lambda を利用するならAWSのサービスで完結している方が楽
  • 認証もIAMロールで行えるので色々気にする必要なし
  • 外部のAPIにデータを送信することもないので、こちらも色々気にする必要なし
  • SlackからのWebhookを受ける場合は、やっぱり非同期処理しないと複数回受信する(Lambdaのコールドスタートのため)
  • この使い方だと粒度が小さすぎるのかComprehend の料金がちょっと気になる
  • Translate 側で言語自動判別ができるようななれば、Comprehend は不要となるのでアップデートに期待したい
  • 他の絵文字と合わせるためにSlackの国旗絵文字の文字列が変更になったっぽい

get.slack.help

www.webpagefx.com

  • 一部の絵文字国旗でflag−で始まらないものがある(:de: :jp: など)

f:id:uchimanajet7:20180223091838p:plain

  • 絵文字文字列の変更を真面目にウォッチするのは大変そう
  • ちゃんと使うならこの辺も考えないとだめそう
  • あ、Lambda Goは楽しいのでおすすめです!

以上になります。

aws chaliceを使ってslackの翻訳botを作ってみた #aws #chalice #slack #bot

AWS Developers Meetup

先日開催された AWS Developers Meet Up という開発者向けのイベントに参加してきました。

AWS Developers Meet Up(2017 年 12 月 7 日開催)
https://pages.awscloud.com/DeveloperMeetup20171207.html

第1回目ということもあって、AWS SDKの紹介を交えつつ実際にAWS Cloud9を動かしてライブコーディングがあったりして、2回目以降の開催にも楽しみになる感じのイベントでした。

aws.amazon.com

aws.amazon.com

また、AWS AmplifyAWS Mobile CLIを紹介するデモではちょっとしたトラブルもあったりしましたが、逆に参加者の皆さんがトラブル解消のためにすごい画面に集中して一体感が出るという一幕もw

aws.amazon.com

github.com

個人的に楽しみに見に行ったのは Chalice(Python Serverless Microframework for AWS) のお話

github.com

すごい手軽に使えて、IAM ポリシーを自動生成してくれるのが素敵なのが気に入っているので、これまでも↓

uchimanajet7.hatenablog.com

uchimanajet7.hatenablog.com

uchimanajet7.hatenablog.com

な感じで使ってみています。

Slack Developer Meetup Tokyo

少し前に開催された Slack Developer Meetup Tokyo という開発者向けのイベントに参加してきました。

slackdevtokyo.splashthat.com

その中で紹介されていた、emojiリアクションでメッセージを翻訳するbotをつくるというのがちょー楽しそうだったんです。

www.slideshare.net

JavaScriptで作られたbotのコードは公開されていて、Herokuへのデプロイならデプロイボタンもあってちょー楽そう。

github.com

しかし、JavaScriptはこの前のServerlessconf Tokyo 2017 Workshopのコードを触った時にだいぶ苦労したので避けたい気持ちがw

uchimanajet7.hatenablog.com

ということで

slack 翻訳botも楽しそうだし久しぶりに chalice も触りたいということで、chalice を使って公開されているslackapi/reacjilatorと同じように動くものを作ってみました。

github.com

基本的には公開されている slackapi/reacjilatorchalice利用して実装し直しただけになります。

変更点はGoogle翻訳は無料枠がないので、次の資料を参考にして無料の翻訳APIを利用するようにしてあります。

omohikane.com

王道は Microsoft Translator API なんですが利用したことがあるのと、無料アカウントでも取得するのに多少手間があるので、使ったことのないYandex APIを使ってみました。

マイクロソフトアカウントの登録方法なんかは以前書いたAzureの記事をご覧ください。

uchimanajet7.hatenablog.com

コードは量も多くないので他の翻訳APIに変更するのも大変ではないと思います。 また、当然ですが翻訳APIを利用するということはAPIに文字列を送信するということなので、十分理解した上で翻訳APIの利用先と利用を決めてください。

Yandex API

無料で使えて登録も簡単な翻訳APIを調べていて初めて知りました・・・ ロシアでGoogleみたいなことやってるんですねー

Yandex - Wikipedia
https://ja.wikipedia.org/wiki/Yandex

翻訳APIの利用登録は非常に簡単で、GoogleアカウントがあればログインしてAPIキーを取得するだけで利用開始できます。

tech.yandex.com

ドキュメントもAPIそのものも非常にシンプルなので、特に困るところはないかと思います。動作を確認するとかそういう用途では手軽で嬉しいですね。

実際に利用する際にはAPIに文字列が送信されるということを考えてお使いください。

準備

上記翻訳API(yandex)の準備とSlackの公開されているスライドを参考に準備を行ったら、実行に必要なAPIキーなどの情報を書き足してchalice deployを実行すれば、API GatewayのエンドポイントとLambdaを利用できるようになります。

翻訳APIを他のものに切り替える場合は、APIを呼び出す部分を個別に実装すれば切り替えできると思います。

国旗絵文字の文字列から翻訳APIに渡すための変換は↓を参考にしてください。

Language Support  |  Translation API  |  Google Cloud Platform
https://cloud.google.com/translate/docs/languages?hl=en

Translator Language Codes
https://msdn.microsoft.com/en-us/library/hh456380.aspx

tech.yandex.com

AWS Lambda はAPI Gatewayから呼び出されるものと、Amazon SNSから呼び出されるものがあります。

これはSlackのAPIがリクエストを受けてから、一定時間内にレスポンスを返さないとリクエストを再送する仕組みがあり、Lambdaのコールドスタート時に複数のリクエストが送信される可能性を低くするためです。

chaliceではAWS CloudFormationをサポートしているので、AWS CLIと組み合わせることでAmazon SNSなどの他リソースを同時に構築することができます。

AWS CloudFormation Support — Python Serverless Microframework for AWS 1.1.0 documentation
http://chalice.readthedocs.io/en/latest/topics/cfn.html

使ってみる

https://user-images.githubusercontent.com/6448792/34078201-01eec178-e359-11e7-8494-17d044371c5f.gif

国旗絵文字をリアクションすると、その国の言葉に翻訳されます。 翻訳API側が対応してないとbotからの返答がないようにしてあります。

f:id:uchimanajet7:20171217183210p:plain

The message is translated in :flag-ca: (ja-en)

のように、翻訳元の言語と翻訳先の言語がわかるようにはしてあります。 上記の例だとja(日本語)からen(英語)となります。 翻訳APIからの戻り値ですが、基本的にはISO 639-1のコードと同等のようです。

List of ISO 639-2 codes - Wikipedia
https://en.wikipedia.org/wiki/List_of_ISO_639-2_codes

まとめ

  • 勉強会やイベントに行くと知らないことや、やってみたいことのきっかけになるのはやっぱりいいな
  • 入出力にSlackを使うのは手軽だし分かりやすい
  • 今回みたいなBotだと全チャンネルではなく、特定のチャンネルにデプロイしたい。
  • 外部APIに文字列を送るとなると予期せず動作するのは好ましくない気がする。
  • 今回はプログラム側で許可するチャンネル一覧を持って対処した。
  • slack側で設定できる場所があれば教えてほしい
  • チャンネルリストもディスプレイ文字列ではだめで、チャンネルIDが必要だった
  • チャンネルIDの取得の仕方については以下を参考にした

qiita.com

  • chalice はやっぱり手軽でこういうちょっとした用途だと便利
  • SNSを使って非同期にしてあるが単純にLambdaのinvokeでもよかったかもしれない
  • その場合chalice側でLambda関数名が付与されるので、そのあたりをもうちょっとスマートにしてもらえるといいなーと
  • 時間をみつけてchaliceのソースを見てみようと思った
  • Lambdaなので外部APIとのやりとりもX−Rayを使えば可視化もできて便利
  • 今回は利用してないが、他の翻訳APIも複数利用する場合とかあればX−Rayも使ってみたい

docs.aws.amazon.com

  • やっぱりわくわくしながら作るのは楽しくて良いです
  • やはり楽しいは正義ですね

以上になります。

SORACOM UG Tokyo #8 開催レポート #soracom #soracomug #iot

★この記事は「SORACOM Advent Calendar 2017」の 12/15 日分のエントリーになります

qiita.com

soracom.jp

何を書くか・・・

IoT通信プラットフォーム SORACOM のAdvent Calendar 2017 です。 SORACOM を使った技術ネタでしたらなんでもOKです!

とあるので、本当は技術ネタの方が良いのでしょうが・・・せっかくSORACOM UG Tokyo #8が開催された当日なので、それをネタにゆるーく書いていこうと思います。

soracomug-tokyo.connpass.com

技術ネタと話題のWio LTE話は、これまでのSORACOM Advent Calendar 2017で色々と書かれているのでそちらを見てくださいw

久しぶりの開催

前回の第7回目の開催が2017/07/05(水)SORACOM Conference 2017 “Discovery”のナイトイベントとして開催したので、半年近く経っての開催となりました。

soracomug-tokyo.connpass.com

discovery2017.soracom.jp

久しぶりの開催ということで、前回の開催からのニュースリリースを確認して個人的に気になるものを見てみると

soracom.jp

まず、みんなびっくりしたのはKDDIグループとなったことでしょうか?

soracom.jp

あとは、チップ型SIMやeSIMの提供が開始との話

soracom.jp

soracom.jp

Wio LTEの機器販売のとWio LTE自体が気になりました

soracom.jp

もちろんこの他にもいろいろとリリースされてますので、あくまでも個人的に気になったという話です。

当日レポート

では、本題のSORACOM UG Tokyo #8 / eSIMとre:InventとちょっとだけWio LTEの当日の様子を簡単ですがご紹介したいと思います。 当日の雰囲気は次のまとめをご覧ください。

togetter.com

会場

f:id:uchimanajet7:20171216110937j:plain

今回の会場はウイングアーク1st株式会社 さんのセミナールームをお借りしました。 素晴らしいセミナールムで開催できて大変助かりました。ありがとうございました。

帳票とBI | ウイングアーク1st
http://www.wingarc.com/

eSIM オーバービュー

f:id:uchimanajet7:20171216125258j:plain

1つ目のお話はSORACOM片山さんによるeSIMのお話。 SIM自体の基本的な話から、既存のSIMとeSIMがどう違うのか? これからのSIMはどうなっていくのか?といった内容のお話でした。

資料と話の内容が非常に丁寧で、ぜんぜん詳しくない私でも理解できるような非常に素敵な発表でした。

資料は公開されましたが、是非SORACOMさんが開催しているオンラインセミナーSORACOM Bootcampにて再演していただけるといいなーと。

www.slideshare.net

あ、あとで #ソラコムサンタ ハッシュタグつけてTwitterにつぶやいておこうw

twitter.com

今年も#ソラコムサンタ開催中みたいなので、クリスマスが楽しみですねー

twitter.com

Wio LTE の紹介

f:id:uchimanajet7:20171216140247j:plain

2つ目のお話はSORACOM松下さんによるWio LTEのお話。 WioとはWireless Input Output だそうなので、カタカナで表記するならワイオとなるそうな。

Wio LTE Cat.1 - Seeed Wiki
http://wiki.seeed.cc/Wio_LTE_Cat.1/

Wio Tracker (Wireless Input Output) is an open source gateway which enable faster IoT GPS solutions.

ラズパイやArduinoでGroveセンサーを使う場合に、ブレッドボードのさし間違えでセンサーを壊してしまったことがある人もいるかと思います。

Wio LTEでは直接コネクターにGroveセンサーをさせるので 上記のような悲しいことも起こらずw かつ手軽にセンサーを利用できるそうです。 また当然LTEモジュールも搭載しているので、SIMを刺せば通信も利用可能と。

SORACOMさんのサイトでは、Wio LTE単体からGroveセンサーをセットにしたものまで販売しているそうです。購入して年末年始にIoTを体験するのには手軽でいい感じかもですねー

soracom.jp

soracom.jp

最後に松下さんがWio LTEを使った実機デモを行い、クラウド側とデバイス側が双方向で通信している様子がわかる楽しいデモでした。

Wio LTEのハンズオンなんかは今後も予定されているようなので そのハンズオン会場で同じデモが見られるかもしれないですねー

ソラコムが見てきたAWS re:invent 2017 話

f:id:uchimanajet7:20171216140553j:plain

3つ目のお話は再び登場のSORACOM片山さんによるAWS re:Invent 2017のお話。 SORACOMさんか参加されたのは片山さん1人とのこと。なので、自分が見てきた範囲でセッションの内容紹介をするとのことでスタートしました。

今年のre:InventではIoT関連のサービスが多数発表され、AWSがIoTに積極的に取り組む姿勢が感じられて嬉しかったとのこと。 また、会場では色々なIoTサービスやプロダクトの展示もあったそうです。

会場のハンズオンでAWS DeepLensを触ったお話もありました。

aws.amazon.com

スライド中では画像認識している若干ドヤ顏気味の片山さんの写真も紹介されていましたw

f:id:uchimanajet7:20171216140719j:plain

SORACOMさんにはグローバル向けのSIMもあるので、早速現地でAWS DeepLensにUSBドングルをさして通信可能か試した話もされてました。

blog.soracom.io

この中で話してのは画像?映像データはクラウドまで上がらずにどうやら機器内で判定がされ、結果のJSONだけが送信されてるとのこと。 これであれば、大容量の回線でなくても利用できるしかつ、画像や映像という色々な情報が入っているものの取り扱いを気にしなくてよくなるので、大変ありがたい感じですねー

AWS DeepLens を開けてみたそうで

f:id:uchimanajet7:20171216140804j:plain

カメラはUSBで刺さってるだけだったそうですw

発表後に実物のAWS DeepLensを開けていただけたので見てみましたが、確かに刺さってるだけっぽかったですw

f:id:uchimanajet7:20171216140833j:plain

日本ではまだ発売されませんが、他のデバイスでも代用可能そうなのでソフトの方を他のデバイスにもデプロイできるようになると楽しそうですねー

www.slideshare.net

ソラコム ビンゴ

f:id:uchimanajet7:20171216140631j:plain

最後は再び登場のSORACOM松下さんによるソラコム ビンゴ 去年の同じ頃に使う予定で作ったビンゴアプリが1年越しでやっと活躍だそうですw しかし、1年はWebの世界では長かったようで使っているJSライブラリが大幅更新されていた&SORACOMのアイコンセットがだいぶ増えたので、結構修正しないと動かなかったとかw

コード自体はGitHubで公開されているとのことなので、この時期にビンゴをお考えの方いかがでしょうか?

github.com

ビンゴの方は順調に進んでいきましたが、アイコンセットの数が多いからなのか・・・なかなかビンゴになる人が出ないという展開にw

ビンゴの景品はSORACOMさん、seeedさん、ウィングアークさんから提供していただきましたーありがとうございました。

f:id:uchimanajet7:20171216140905j:plain

Groveセンサーってすごい便利で使ったこともあったのに、seeedさんの製品だとは全然知らなかったです・・・

Grove System - Seeed Wiki
http://wiki.seeed.cc/Grove_System/

Seeed Studio Bazaar, Boost ideas, Extend the Reach
https://www.seeedstudio.com/

最後は

f:id:uchimanajet7:20171216140933j:plain

SORACOM UG 恒例の集合写真で締めでした。 いつも写真撮影ありがとうございます!!

www.facebook.com

まとめ

  • 今回はSORACOMさんから色々話が聞けて勉強になった
  • 知らないことが知れるのは楽しい
  • たまにはこう言った感じで開催するのもいいなぁーと感じた
  • Javaはすごい(らしい)
  • 資料の公開は楽しみにしてますので、是非よろしくお願いします!
  • あと、#ソラコムサンタ 期待していますw
  • アドベントカレンダーは間に合わなくてゴメンナサイ。
  • 次回も楽しく開催したいのでよろしくお願いします!

明日も楽しみ「SORACOM Advent Calendar 2017」

12/25 の最終日までいろいろなネタが投稿される 「SORACOM Advent Calendar 2017」 明日以降の投稿も楽しみです!

qiita.com

ユーザーグループの開催レポートなのでゆるーく書いてしまいましたが、少しでもSORACOM UGに興味を持っていただければ嬉しいです。

今後のSORACOM UG開催についての情報は、募集サイトやSORACOMさんの公式サイト、SNS等で発信されていますので気になった方は是非参加してみてください。

soracom.jp

soracomug-tokyo.connpass.com

twitter.com

www.facebook.com

www.facebook.com

以上になります。

Cloud Automator について #cloudautomator #swx

★この記事は「Cloud Automator Advent Calendar 2017」の 12/1 日分のエントリーになります

qiita.com

cloudautomator.com

何を書くか・・・

AWSの運用を自動化する Cloud Automator の知見・情報など、Cloud Automatorに関することであれば何でもOKです🙆

とあるので、なんでもOKらしいので初日&AWSな方々はre:Invent 2017 でラスベガスだと思うので、ゆるーく書いていこうと思います。

技術的なこととか、深い話は今後のみなさんがきっと書いてくれるに違いないと信じておりますw

いつから

さて、Cloud Automatorはいつから提供が開始されたのか?調べてみると、次のニュースリリースが残っているのを発見しました。

www.serverworks.co.jp

これによると

Cloud Automator (クラウドオートメーター) の提供を2014年7月17日(木)より開始いたします。

となっており、今から約3年半ぐらい前からサービスとして提供されていたことがわかります。

200社を超えるAWS導入実績を持つ当社が、実環境で経験してきた様々な運用業務を「アクション」として実装しています。

となっていますが

www.serverworks.co.jp

を確認すると、現在は

600社4,000プロジェクト以上のAWS移行実績!

と記載があることをみても、時間の経過とAWSが利用されるスピードについて実感できるかと思います。

全然関係はないんですが、このニュースリリースなんでこんなにCloud Automator のロゴが大きいのかw Cloud Automatorのロゴを伝えたかったのか!?それとも何か秘密があるのか!?

f:id:uchimanajet7:20171129132943p:plain

今後の「Cloud Automator Advent Calendar 2017」で明らかになるのか楽しみですw

アップデート

次に大きな機能追加があったのは、「構成レビュー」自動化機能の追加でしょうか?サービス提供時と同じく調べてみると、次のニュースリリースが残っているのを発見しました。

www.serverworks.co.jp

これによると

「構成レビュー」自動化機能の提供を2016年6月1日(水)より開始いたします。

となっており、今から約1年半ぐらい前からサービスとして提供されていたことがわかります。意外と最近ですねw

どうしたら

Cloud Automator を使い始めるのはどうしたらいいのか?

cloudautomator.com

公式サイトからサインアップしてもらえれば、構成レビュー⾃動化機能は対象外となりますが1ヵ⽉の無料トライアルを行えます。

もしくは、pieCeというサービスに加入いただいている場合には、すぐにすべての機能をお使いいただけます。

www.serverworks.co.jp

今後は

Cloud Automator の今後はどうなるの?という方は次のロードマップページをご覧ください。

cloudautomator.com

こんな機能が欲しい!こんなことをしたい!との要望は

Cloud Automatorサポートページ
http://feedback.cloudautomator.com/

のサポートページで受け付けておりますので、フィードバックをお願いいたします。

また、単純にどんなことができるかドキュメントを確認したい場合は

Cloud Automator – 株式会社サーバーワークス サポートページ
https://support.serverworks.co.jp/hc/ja/categories/115001305127-Cloud-Automator

のマニュアルページをご確認ください。

明日も楽しみ「Cloud Automator Advent Calendar 2017」

12/25 の最終日まで今日からスタートの 「Cloud Automator Advent Calendar 2017」 明日以降の投稿も楽しみです!

qiita.com

初日なのでゆるーく書いてますが、これからはもっと中の詳しい話や便利な使い方なんかが出てくるのを期待ですね!

あと、埋まってないところがあるようなので我こそは!という方の参戦もお待ちしております!

宣伝

サーバーワークスでは積極採用中です。もちろんCloud Automatorの開発チームも採用中ですので、Cloud Automatorに興味がある方是非お声がけください!

www.serverworks.co.jp

以上になります。

#Serverlessconf Tokyo 2017 でやった Workshop に機能を追加してみた #serverless #ACG

今年の

今年も大盛況の開催だった Serverlessconf Tokyo 2017 の1日目に開催された pre-conference Workshop に参加しました。

tokyo.serverlessconf.io

幾つかの Workshop から選択できたのですが、私が選択したのは

Build your own serverless video sharing website with Lambda, API Gateway and Firebase

という、Youtubeクローンのようなものを作ってみるというWorkshopでした。

github.com

内容は上記githubの内容を見てもらえればわかるのですが、ドキュメントが非常によくできているので指示通りに進めて行くとサクサク進んでいきます。

http://bit.ly/acg-jpbit.ly

さらに日本のServerlessconf Tokyo 2017のスタッフの方が、日本語訳したものまで用意してくれる素敵な対応。

実際に

当日は @sbarski の丁寧な説明を受けつつ、Workshopを進めて行く感じでした。

twitter.com

また、サポート役として @ijin@toricls@horike37 というクラウド界隈で有名な方々がなぜか参加しているという素敵な状況でした。

twitter.com

twitter.com

twitter.com

Workshop自体のできがよく、さらにサポートも充実しているので予想よりも全体的な進捗がよく終わってしまう人がかなりいました。

そこで、終わった人はWorkshopで完成したものに新規で機能を追加してPull Requestを送ってみてはどうか?という無茶ぶりがw

公開されているWorkshopが需実していくのはいいことなので、私も何かしよう!と思ったのですが、LambdaがNode.jsで書かれているというね・・・

結局

f:id:uchimanajet7:20171129172234p:plain

当日は不慣れなJavaScriptに苦戦して何も追加できずでしたので、せっかくだから空いた時間を使ってチマチマと機能を作ってみました。

github.com

Lesson 6として追加したのは、Webブラウザ上から動画ファイルを削除できる機能の追加です。

f:id:uchimanajet7:20171129172318g:plain

普通すぎる機能なんですが、アップロードがWebブラザ上からできるところでWorkshopが終了になっているので、まーあってもいいかなぁーと。

ただ、このWorkshop自体が @sbarski の著書 Serverless Architectures on AWS With examples using AWS Lambda をもとにしているらしいので、著書の中には既にある可能性が・・・

Manning | Serverless Architectures on AWS
https://www.manning.com/books/serverless-architectures-on-aws

こちらの著書も日本語版が出れば読みながら進めるのは良さそうですよねー日本語版に期待。

Pull Request

著書の中で既存の可能性が高いですが、せっかく作ったのでPull Requestを送ってみました。

github.com

他にも心配な点がいくつか・・・

  • 手順書の英語がわからん。
    • 日本語版を書いてそれをGoogle翻訳しただけw
  • フロントエンド側のJavaScriptがわからん。
    • 動くようには書いたけどスマートじゃない気がするけど力尽きたw
  • Pull Request の英語がわからん。
  • 空き時間でのんびり作ってたらすごい時間かかった
    • 絶賛開催中のAWS re:Invent 2017 でWorkshopに使えそうなサービスが出そう。というか出てるきがするw

reinvent.awsevents.com

classmethod.jp

ちなみに @sbarskiAWS re:Invent 2017 で登壇したみたいですよ! that's awesome!

AWS re:Invent 2017
https://www.portal.reinvent.awsevents.com/connect/search.ww

私自身は今年も残念ながら参加できなかったので・・・・ 上記のセッション検索サイトで @sbarski の名前を検索すると

DVC301 - Evolution of Serverless Architectures through the Lens of Community
https://www.portal.reinvent.awsevents.com/connect/sessionDetail.ww?SESSION_ID=17198

SRV401 - Become a Serverless Black Belt: Optimizing Your Serverless Applications
https://www.portal.reinvent.awsevents.com/connect/sessionDetail.ww?SESSION_ID=14199

の2つのセッションがヒットしますねー

DVC301 の方は残念ながら動画が非公開っぽいですねー

www.youtube.com

SRV401 の方は動画が公開されていて見ることができるようです!

www.youtube.com

この他のAWS re:Invent 2017 動画は順次公開されているようなので、私と同じく現地参加できなかった人にはありがたいですよねー

www.youtube.com

来年は参加したいなぁー去年もそんなこと言ってましたがw

まとめ

  • 時間はかかったけどのんびり進められてなかなか楽しかった
  • やっぱりJavaScriptはよくわからなくて難しい
  • Workshopがシンプルなのでコード類もシンプルで素敵
  • AWSを知っている人なら、本当にサクサク進められるのでオススメ
  • サクサク進むけど出来上がるものは動きもあって達成感もある
  • 良い機会を得られたのが良かった
  • 他の参加者のかたも是非!新機能を!
  • Serverlessconf Tokyo 2017 スタッフの皆さんありがとうございましたー

以上になります。

textlintを使ってAWS用語をチェックしてみる #aws #textlint #golang

最近のアップデート

Cloud Automator のアップデートでログイン中の操作画面にマニュアルのリンクが表示されるようになりました。

blog.serverworks.co.jp

もちろんマニュアルだけでも閲覧できますので、気になった方は無料トライアルでCloud Automator を試してみてください。

Cloud Automator – 株式会社サーバーワークス サポートページ
https://support.serverworks.co.jp/hc/ja/categories/115001305127

cloudautomator.com

ドキュメントを充実させるには

ドキュメントを充実させていくには、地道に書いていくしかないわけで・・・Cloud Automator についても開発メンバーで分担しながら作っています。

その際ちょっと気になってくるのが表記のゆれです。 これは多人数でなくても1人で書いていても、書いている時期が異なると表現が異なるとかありますしね。

細かい言い回しならそこまで気にする必要もなさそうなのですが、Cloud Automator の使い方や機能を説明していくと当然ながらAWSについても言及する必要が出てきます。

AWS用語表記のゆれが出てしまうとユーザーは気になりますし、検索する場合にヒットせず困ることも出てきそうです。

そこでAWSの公式ドキュメントに載っている日本語のAWS用語を利用して、表記のゆれをチェック行ってみます。

アマゾン ウェブ サービス : AWS の用語集
https://docs.aws.amazon.com/ja_jp/general/latest/gr/glos-chap.html

ツールを探してみる

表記のゆれをチェックできるツールとして知っているのは以下2つ。

github.com

github.com

今回は対象のファイルがMarkdownファイルであるのと、手元で手軽に動かしたたいので、npmでインストールできるtextlintを利用してみます。

また、prh形式のYAMLでルールを指定できるように次のツールも利用してみます。

github.com

ルールを作ってみる

チェックを行うためにはルールを作る必要があります。

AWS用語については公式にドキュメントとしてまとまっているので、これを利用するために次のような簡単なコマンドラインツールをgolangで作ってみました。

github.com

できることは単純で、日本語のAWS用語ページをスクレイピングしてprhで使える形式のYAMLファイルを出力します。

詳細はGitHub上のREADME.mdファイルを参照してください。

github.com

スクレイピングにはgoqueryというgolangの便利なライブラリを利用しています。

github.com

実際のYAMLファイルを見てもらえば分かりますが、単純に用語をそのまま抜き出しているものと、半角スペースで分解して単語単位で抜き出してものがあります。

github.com

たとえばAmazon Simple Workflow Serviceを登録する場合、

 - expected: 'Amazon Simple Workflow Service'
 - expected: 'Amazon'
 - expected: 'Simple'
 - expected: 'Workflow'
 - expected: 'Service'

の5種類を登録しています。

これは実際にチェックする際により多くのパターンにマッチさせたかったためで、利用してみてマッチしすぎる場合は必要のない部分を削除して使う形にしました。

作ったルールを利用してみる

作ったルールを実際に利用するには.textlintrc というtextlintの設定ファイルに、作成したaws_words.ymlファイルのパスを記載するだけです。

{
  "rules": {
    "prh": {
      "rulePaths": [
        "./aws_words.yml"
      ]
    }
  }
}

試しに次のようなMarkdownファイルに、上記の設定でtextlintを実行すると、

# AWS用語のチェック

- awsはダメ。
  - Amazon Web Serviceも間違い。
  - 日本語なので正解はアマゾン ウェブ サービス。

- 同じくAWS Management Consoleは英語なのでダメ。

のような結果になり、ルールにしたがってチェックされていることが確認できます。

$ textlint test.md

/Users/uchimanajet7/self-work/github/awr/test.md
  3:3   ✓ error  aws => AWS                                            prh
  4:5   ✓ error  Amazon Web Service => アマゾン ウェブ サービス        prh
  4:5   ✓ error   => Amazon                                            prh
  4:7   ✓ error  違い => AZ                                            prh
  4:16  ✓ error  ェブ サービス => service                              prh
  4:16  ✓ error  service => Service                                    prh
  7:6   ✓ error  AWS Management Console => AWS マネジメントコンソール  prh
  7:6   ✓ error  でダメ => AWS                                         prh
  7:10  ✓ error  同じくAWS マネジ => Management                        prh
  7:21  ✓ error  ントコンソール => console                             prh

✖ 10 problems (10 errors, 0 warnings)10 fixable problems.
Try to run: $ textlint --fix [file]

いくつか余計と思われる部分が指摘されていますが、これはルールを機械的に作り出しているために起こっているので、取り除きたい場合にはルールのaws_words.ymlファイルを編集します。

もうちょっと便利に

これでMarkdownファイルに書かれている内容について、なんとなくですがtextlintを利用してチェックできるようになりました。

しかし、実際にドキュメントを書く作業をしてみるともうちょっと便利にできそうな感じがするので試してみることにします。

私の場合ドキュメントを公開するまでに、

  1. Markdown形式でドキュメントを書く。
  2. textlintでチェックし、修正があればなくなるまで繰り返す。
  3. Zendesk Guideにドキュメントを反映するためにMarkdown形式からHTML形式に変換する。
  4. Zendesk GuideHTML形式でドキュメントを反映し、画像の追加や装飾などを行う。
  5. チームメンバーにレビューをしてもらい、指摘があればなくなるまで修正を繰り返す。

の定型作業を行っているので、この作業を効率化したいわけです。

最終的にはZendesk GuideHTML形式で記載することになります。 ですので、最初からHTML形式で書く方が効率的なの気もしますが・・・ 個人的にはMarkdown形式の方が書きやすいので、Zendesk GuideMarkdownに対応してくれるとうれしいなぁー

www.zendesk.co.jp

と言っても、そこはどーにもならないので次のような簡単なコマンドラインツールをgolangで作ってみました。

github.com

できることは単純で、Markdown形式からHTML形式に変換できます。加えて、この変換作業の前後で任意のコマンドを実行できるので、今回はtextlintを実行する形にしています。

ただし、textlintは別のプログラムなので事前にtextlintのインストールや設定は必要となります。

詳細はGitHub上のREADME.mdファイルを参照してください。

github.com

Markdown形式からHTML形式への変換にはblackfridayというgolangのライブラリを利用しています。v2への移行が進んでいますが、今回利用したのはv1になります。

github.com

出力するHTMLファイルにclassを動的に追加したいなら、v2に追加されたParseを利用して実現できそうな気がします。時間ができたら要確認かなぁ。

また、何度もチェックして変換する工程を繰り返すことが予想されるので、fsnotifyというgolangのライブラリを利用して、ファイルの変更検知をできるようにしてあります。ファイルの変更を検知してチェックと変換を繰り返し実行します。

github.com

CLI化するのには有名なので説明不要だと思われるcobraというgolangのライブラリを利用しています。

github.com

作ったものを使ってみる

せっかく作ったので使ってみるわけですが、前述したとおり変換前と変換後に外部コマンドを実行できます。

今回は変換前にtextlintを実行してAWS用語のチェックを行い、変換後にはHTMLを実行環境のデフォルトブラウザで表示してレイアウトの確認を行います。

設定ファイルには次のように実行するコマンドと置換する文字列を記載してあります。

{
    "Page": true,
    "CSS": "style.css",
    "PreCommands": [["textlint", "%INPUT_PATH%"]],
    "PostCommands": [["open", "%OUTPUT_PAGE_PATH%"]],
    "ReplaceTexts": [
        "<blockquote",
        "<blockquote class=\"is-colored\"",
        "<ol",
        "<ol class=\"list-colored\"",
        "<img",
        "<img class=\"image-with-border\"",
        "<table",
        "<table class=\"table table--bordered table--color-header\""
    ]
}

これで変更検知をする次のコマンドを実行して、ドキュメントを更新するとtextlintを実行して変換後のファイルを実行環境のデフォルトブラウザで表示できているはずです。

現状は変化前、変換後のコマンド実行でエラーがあってもそのまま実行を続ける仕様ですので、textlintで指摘があってエラーが表示されていても実行は継続します。

また、openコマンドでデフォルトブラザを開いているだけですので、ブラウザが複数立ち上がるってしまう可能性があります。

まとめ

  • textlintを使って表記のゆれをチェックできる
  • 人のレビューを受ける前に機械的にチェックできるのはありがたい
  • 頑張ってprh形式のYAMLファイルを用意すれば、任意のルールでチェック可能
  • AWS用語は公式サイトにまとめられているので利用できる
  • ただし、日本語へのローカライズで問題ありそうな文言もあるので注意が必要
  • あと、誤表記やTypoを発見したらAWSへ積極的にフィードバックしておきましょう!そのうちきっと修正してもらえるハズ

f:id:uchimanajet7:20171016000127p:plain

アマゾン ウェブ サービス : AWS の用語集 - EBSbacked
https://docs.aws.amazon.com/ja_jp/general/latest/gr/glos-chap.html#EBSbacked

  • Zendesk GuideMarkdown形式が追加されてほしい
  • そー考えるとHatena Blogすごい書きやすいんだなーとあらためて思った
  • golangは相変わらず便利、そしてちょー楽しい
  • blackfridayはv2を使っていないので今後使ってみたい
  • fsnotifyは便利だったので今後も使っていきたい
  • 当然このblogもMarkdownで書いているのでtextlintを使ってチェックした

以上になります。