URLを生成する必要があります。パラメータストアを利用しました。docs.aws.amazon.com使う側からするとSTSの有効期限を7日までに伸ばす方法があるか、URL文字列にこの情報を含めずにURLを作ってくれる方が嬉しいんですが・・・そこは将来に期待しております。URLが生成できます。署名付きのURLが指定した有効期限より前に失効する場合は、利用している認証情報が一時トークンを使用していないかを確認することをお勧めします。4)を利用する必要があるため、確認することをお勧めします。roleで取得した一時トークンを利用していたことと、署名がSigV2で行われていたことの2点が問題となっていました。SigV4を利用していないだけかと思い、もう一つの認証情報の件にたどり着くのが遅くなりました。皆様はお気をつけください。今回は最終的にAWSサポートに確認して作業を行いましたが、AWSサポートは対応が素晴らしいのでもっと早めに確認するべきだったと。廃止の話題でご存知かもしれません。リクエストのみを受けつけます。使用するために、クライアントでコード変更が必要ですか。はいとの記載がありました。SigV4の利用を宣言する必要があるためとなります。コードとしては以下のあたりが該当するかなーと。github.comgithub.com署名バージョンの確認については、S3のログを利用して確認しました。docs.aws.amazon.com最近のアップデートでログに署名バージョンが出力されるようになったようです。1時間程度経過したのちに配信されることになるかと思います。docs.aws.amazon.comベストエフォート型のサーバーログ配信サーバーアクセスログレコードの配信は、ベストエフォートで行われます。ログ記録用に適切にバケットを設定した場合、そのバケットへのほとんどのリクエストについてログレコードが配信されます。ほとんどのログレコードは、記録された時間から数時間以内に配信されますが、配信間隔は短くなる場合もあります。サーバーログの完全性や適時性は保証されません。リクエストのログレコードが、リクエストが実際に処理されてからかなり後に配信されたり、配信すらされないこともあり得ます。サーバーログの目的は、バケットに対するトラフィックの特性を理解することです。ログレコードが失われることはまれですが、すべてのリクエストが完全に報告されるとは限りません。サーバーログに記録されていないアクセスリクエストが含まれる場合があります。今回はログを確認する手段としてDatadogを利用しました。他のAWS関連メトリクスと1箇所で確認できるのは非常に便利ですね。署名バージョンについては、Boto3(Python)に関してはSigV4を使うために明示的にプログラム中でバージョン指定が必要であり、これを行わないとSigV2で通信されていることがわかりました。単純にSDKのアップデートでは対応できないことになるので、S3に対してアクセスを行なっているプログラムを確認する必要があります。デフォルトなのは知らなかったですSTSの期限についてはworkaroundでもいいので延長できる方法が欲しいです権限がないのにURLが発行できるのもエラーで終わってもらえると良いきがしますBoto3側のドキュメントにSigV4の話とかリンクでいいので追加されていると親切だと思いましたDatadogはログインテグレーションして検索も簡単に!他のAWSメトリクスも合わせて1箇所で状態が確認できるので便利でした相変わらずドキュメントの読み込みが甘くて余計な手間が増えているなーとドキュメントはちゃんと読みましょう!以上になります。Lambdaでgolangが利用できるようになりました。aws.amazon.com待ちに待ってたので嬉しいのですが、業務でgolangを使う機会もなく・・・LTのネタにそんな状態のところにLTどうですか?とのお声がけがあったので、これはネタにするしかない!mastercloud.connpass.comと、いろいろと作業はしてみたのですが・・・結局間に合わずwuchimanajet7.hatenablog.com以前に書いたblogを資料にするだけになってしまいました・・・speakerdeck.comせっかくなのでとは言え、LTのネタにしようと作業自体は行っていたので時間のあるときにチマチマと作ってみてました。Goで行ったという感じです。Translateで行っています。当然ですが利用するにはプレビュー利用の申請が必要となります。翻訳元の言語自動判定を行える機能がこれを書いている時点ではないようです。Comprehendを利用しています。aws.amazon.com結果としてAWSのサービスのみで完結することができたので、外部APIを使う際に気になる翻訳文字列を外部に送信するところは気にせずに済むようになりました。Go以下のリポジトリにAWSが用意してくれたサンプルコードがあるので、特に困らず利用できると思います。github.com個人的には楽しみに待ってたので非常に嬉しいです。Translateを使ってみました。Comprehendを使ってみました。SAM)を使ってみました。Goは楽しいのでおすすめです!以上になります。いう開発者向けのイベントに参加してきました。Cloud9を動かしてライブコーディングがあったりして、2回目以降の開催にも楽しみになる感じのイベントでした。ポリシーを自動生成してくれるのが素敵なのが気に入っているので、これまでも↓uchimanajet7.hatenablog.comuchimanajet7.hatenablog.comuchimanajet7.hatenablog.comな感じで使ってみています。いう開発者向けのイベントに参加してきました。slackdevtokyo.splashthat.comその中で紹介されていた、emojiリアクションでメッセージを翻訳するbotをつくるというのがちょー楽しそうだったんです。Imurawww.slideshare.netJavaScriptで作られたbotのコードは公開されていて、Herokuへのデプロイならデプロイボタンもあってちょー楽そう。使って公開されているslackapi/reacjilatorと同じように動くものを作ってみました。slackapi/reacjilatorをchalice利用して実装し直しただけになります。変更点はGoogle翻訳は無料枠がないので、次の資料を参考にして無料の翻訳APIを利用するようにしてあります。APIを使ってみました。マイクロソフトアカウントの登録方法なんかは以前書いたAzureの記事をご覧ください。uchimanajet7.hatenablog.comコードは量も多くないので他の翻訳APIに変更するのも大変ではないと思います。当然ですが翻訳APIを利用するということはAPIに文字列を送信するということなので、十分理解した上で翻訳APIの利用先と利用を決めてください。Wikipediahttps://ja.wikipedia.org/wiki/Yandex翻訳APIの利用登録は非常に簡単で、GoogleアカウントがあればログインしてAPIキーを取得するだけで利用開始できます。tech.yandex.comドキュメントもAPIそのものも非常にシンプルなので、特に困るところはないかと思います。動作を確認するとかそういう用途では手軽で嬉しいですね。実際に利用する際にはAPIに文字列が送信されるということを考えてお使いください。GatewayのエンドポイントとLambdaを利用できるようになります。翻訳APIを他のものに切り替える場合は、APIを呼び出す部分を個別に実装すれば切り替えできると思います。国旗絵文字の文字列から翻訳APIに渡すための変換は↓を参考にしてください。SNSから呼び出されるものがあります。これはSlackのAPIがリクエストを受けてから、一定時間内にレスポンスを返さないとリクエストを再送する仕組みがあり、Lambdaのコールドスタート時に複数のリクエストが送信される可能性を低くするためです。SNSなどの他リソースを同時に構築することができます。documentationhttp://chalice.readthedocs.io/en/latest/topics/cfn.html使ってみる国旗絵文字をリアクションすると、その国の言葉に翻訳されます。翻訳API側が対応してないとbotからの返答がないようにしてあります。(ja-en)のように、翻訳元の言語と翻訳先の言語がわかるようにはしてあります。上記の例だとja(日本語)からen(英語)となります。639-1のコードと同等のようです。Wikipediahttps://en.wikipedia.org/wiki/List_of_ISO_639-2_codesまとめ勉強会やイベントに行くと知らないことや、やってみたいことのきっかけになるのはやっぱりいいな入出力にSlackを使うのは手軽だし分かりやすい今回みたいなBotだと全チャンネルではなく、特定のチャンネルにデプロイしたい。外部APIに文字列を送るとなると予期せず動作するのは好ましくない気がする。今回はプログラム側で許可するチャンネル一覧を持って対処した。今回は利用してないが、他の翻訳APIも複数利用する場合とかあればX−Rayも使ってみたいdocs.aws.amazon.comやっぱりわくわくしながら作るのは楽しくて良いですやはり楽しいは正義ですね以上になります。#8が開催された当日なので、それをネタにゆるーく書いていこうと思います。“Discovery”のナイトイベントとして開催したので、半年近く経っての開催となりました。LTE自体が気になりましたsoracom.jpもちろんこの他にもいろいろとリリースされてますので、あくまでも個人的に気になったという話です。LTEの当日の様子を簡単ですがご紹介したいと思います。当日の雰囲気は次のまとめをご覧ください。さんのセミナールームをお借りしました。素晴らしいセミナールムで開催できて大変助かりました。ありがとうございました。オーバービュー1つ目のお話はSORACOM片山さんによるeSIMのお話。これからのSIMはどうなっていくのか?といった内容のお話でした。資料と話の内容が非常に丁寧で、ぜんぜん詳しくない私でも理解できるような非常に素敵な発表でした。Bootcampにて再演していただけるといいなーと。そうなので、カタカナで表記するならワイオとなるそうな。solutions.ラズパイやArduinoでGroveセンサーを使う場合に、ブレッドボードのさし間違えでセンサーを壊してしまったことがある人もいるかと思います。手軽にセンサーを利用できるそうです。LTEモジュールも搭載しているので、SIMを刺せば通信も利用可能と。LTE単体からGroveセンサーをセットにしたものまで販売しているそうです。LTEを使った実機デモを行い、クラウド側とデバイス側が双方向で通信している様子がわかる楽しいデモでした。SORACOMさんか参加されたのは片山さん1人とのこと。自分が見てきた範囲でセッションの内容紹介をするとのことでスタートしました。今年のre:InventではIoT関連のサービスが多数発表され、AWSがIoTに積極的に取り組む姿勢が感じられて嬉しかったとのこと。会場では色々なIoTサービスやプロダクトの展示もあったそうです。DeepLensを触ったお話もありました。DeepLensにUSBドングルをさして通信可能か試した話もされてました。blog.soracom.ioこの中で話してのは画像?映像データはクラウドまで上がらずにどうやら機器内で判定がされ、結果のJSONだけが送信されてるとのこと。1年はWebの世界では長かったようで使っているJSライブラリが大幅更新されていた&SORACOMのアイコンセットがだいぶ増えたので、結構修正しないと動かなかったとかwコード自体はGitHubで公開されているとのことなので、この時期にビンゴをお考えの方いかがでしょうか?github.comビンゴの方は順調に進んでいきましたが、アイコンセットの数が多いからなのか・・・なかなかビンゴになる人が出ないという展開にwビンゴの景品はSORACOMさん、seeedさん、ウィングアークさんから提供していただきましたーありがとうございました。恒例の集合写真で締めでした。期待していますwアドベントカレンダーは間に合わなくてゴメンナサイ。UGに興味を持っていただければ嬉しいです。UG開催についての情報は、募集サイトやSORACOMさんの公式サイト、SNS等で発信されていますので気になった方は是非参加してみてください。soracom.jpsoracomug-tokyo.connpass.comtwitter.comwww.facebook.comwww.facebook.com以上になります。ラスベガスだと思うので、ゆるーく書いていこうと思います。Automatorはいつから提供が開始されたのか?調べてみると、次のニュースリリースが残っているのを発見しました。提供を2014年7月17日(木)より開始いたします。なっており、今から約3年半ぐらい前からサービスとして提供されていたことがわかります。200社を超えるAWS導入実績を持つ当社が、実環境で経験してきた様々な運用業務を「アクション」として実装しています。なっていますがwww.serverworks.co.jpを確認すると、現在は600社4,000プロジェクト以上のAWS移行実績!と記載があることをみても、時間の経過とAWSが利用されるスピードについて実感できるかと思います。2017」で明らかになるのか楽しみですwアップデート次に大きな機能追加があったのは、「構成レビュー」自動化機能の追加でしょうか?サービス提供時と同じく調べてみると、次のニュースリリースが残っているのを発見しました。www.serverworks.co.jpこれによると「構成レビュー」自動化機能の提供を2016年6月1日(水)より開始いたします。なっており、今から約1年半ぐらい前からサービスとして提供されていたことがわかります。使い始めるのはどうしたらいいのか?cloudautomator.com公式サイトからサインアップしてもらえれば、構成レビュー自動化機能は対象外となりますが1ヵ月の無料トライアルを行えます。pieCeというサービスに加入いただいている場合には、すぐにすべての機能をお使いいただけます。今後はどうなるの?という方は次のロードマップページをご覧ください。Automatorサポートページhttp://feedback.cloudautomator.com/のサポートページで受け付けておりますので、フィードバックをお願いいたします。サポートページhttps://support.serverworks.co.jp/hc/ja/categories/115001305127-Cloud-Automatorのマニュアルページをご確認ください。明日以降の投稿も楽しみです!qiita.com初日なのでゆるーく書いてますが、これからはもっと中の詳しい話や便利な使い方なんかが出てくるのを期待ですね!あと、埋まってないところがあるようなので我こそは!という方の参戦もお待ちしております!宣伝サーバーワークスでは積極採用中です。Automatorに興味がある方是非お声がけください!www.serverworks.co.jp以上になります。Firebaseという、Youtubeクローンのようなものを作ってみるというWorkshopでした。github.com内容は上記のgithubの内容を見てもらえればわかるのですが、ドキュメントが非常によくできているので指示通りに進めて行くとサクサク進んでいきます。2017のスタッフの方が、日本語訳したものまで用意してくれる素敵な対応。丁寧な説明を受けつつ、Workshopを進めて行く感じでした。いうクラウド界隈で有名な方々がなぜか参加しているという素敵な状況でした。twitter.comtwitter.comtwitter.comWorkshop自体のできがよく、さらにサポートも充実しているので予想よりも全体的な進捗がよく終わってしまう人がかなりいました。当日は不慣れなJavaScriptに苦戦して何も追加できずでしたので、せっかくだから空いた時間を使ってチマチマと機能を作ってみました。6として追加したのは、Webブラウザ上から動画ファイルを削除できる機能の追加です。普通すぎる機能なんですが、アップロードがWebブラザ上からできるところでWorkshopが終了になっているので、まーあってもいいかなぁーと。AWShttps://www.manning.com/books/serverless-architectures-on-awsこちらの著書も日本語版が出れば読みながら進めるのは良さそうですよねー日本語版に期待。Requestを送ってみました。手順書の英語がわからん。日本語版を書いてそれをGoogle翻訳しただけwフロントエンド側のJavaScriptがわからん。手順書と同様に日本語から英語にGoogle翻訳。Google翻訳ありがとう。Workshopに使えそうなサービスが出そう。アップデートでログイン中の操作画面にマニュアルのリンクが表示されるようになりました。ついても開発メンバーで分担しながら作っています。その際ちょっと気になってくるのが表記のゆれです。これは多人数でなくても1人で書いていても、書いている時期が異なると表現が異なるとかありますしね。使い方や機能を説明していくと当然ながらAWSについても言及する必要が出てきます。AWS用語で表記のゆれが出てしまうとユーザーは気になりますし、検索する場合にヒットせず困ることも出てきそうです。そこでAWSの公式ドキュメントに載っている日本語のAWS用語を利用して、表記のゆれをチェック行ってみます。用語集https://docs.aws.amazon.com/ja_jp/general/latest/gr/glos-chap.htmlツールを探してみる表記のゆれをチェックできるツールとして知っているのは以下2つ。github.comgithub.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ファイルを見てもらえば分かりますが、単純に用語をそのまま抜き出しているものと、半角スペースで分解して単語単位で抜き出してものがあります。'Service'の5種類を登録しています。これは実際にチェックする際により多くのパターンにマッチさせたかったためで、利用してみてマッチしすぎる場合は必要のない部分を削除して使う形にしました。いうtextlintの設定ファイルに、作成したaws_words.ymlファイルのパスを記載するだけです。Serviceも間違い。Consoleは英語なのでダメ。ような結果になり、ルールにしたがってチェックされていることが確認できます。[file]いくつか余計と思われる部分が指摘されていますが、これはルールを機械的に作り出しているために起こっているので、取り除きたい場合にはルールのaws_words.ymlファイルを編集します。便利にこれでMarkdownファイルに書かれている内容について、なんとなくですがtextlintを利用してチェックできるようになりました。実際にドキュメントを書く作業をしてみるともうちょっと便利にできそうな感じがするので試してみることにします。私の場合ドキュメントを公開するまでに、Markdown形式でドキュメントを書く。textlintでチェックし、修正があればなくなるまで繰り返す。Guideにドキュメントを反映するためにMarkdown形式からHTML形式に変換する。GuideにHTML形式でドキュメントを反映し、画像の追加や装飾などを行う。チームメンバーにレビューをしてもらい、指摘があればなくなるまで修正を繰り返す。定型作業を行っているので、この作業を効率化したいわけです。GuideにHTML形式で記載することになります。GuideがMarkdownに対応してくれるとうれしいなぁーwww.zendesk.co.jpと言っても、そこはどーにもならないので次のような簡単なコマンドラインツールをgolangで作ってみました。github.comできることは単純で、Markdown形式からHTML形式に変換できます。加えて、この変換作業の前後で任意のコマンドを実行できるので、今回はtextlintを実行する形にしています。textlintは別のプログラムなので事前にtextlintのインストールや設定は必要となります。詳細はGitHub上のREADME.mdファイルを参照してください。github.comMarkdown形式からHTML形式への変換にはblackfridayというgolangのライブラリを利用しています。v2への移行が進んでいますが、今回利用したのはv1になります。github.com出力するHTMLファイルにclassを動的に追加したいなら、v2に追加されたParseを利用して実現できそうな気がします。時間ができたら要確認かなぁ。何度もチェックして変換する工程を繰り返すことが予想されるので、fsnotifyというgolangのライブラリを利用して、ファイルの変更検知をできるようにしてあります。ファイルの変更を検知してチェックと変換を繰り返し実行します。github.comCLI化するのには有名なので説明不要だと思われるcobraというgolangのライブラリを利用しています。github.com作ったものを使ってみるせっかく作ったので使ってみるわけですが、前述したとおり変換前と変換後に外部コマンドを実行できます。今回は変換前にtextlintを実行してAWS用語のチェックを行い、変換後にはHTMLを実行環境のデフォルトブラウザで表示してレイアウトの確認を行います。設定ファイルには次のように実行するコマンドと置換する文字列を記載してあります。]}これで変更検知をする次のコマンドを実行して、ドキュメントを更新するとtextlintを実行して変換後のファイルを実行環境のデフォルトブラウザで表示できているはずです。現状は変化前、変換後のコマンド実行でエラーがあってもそのまま実行を続ける仕様ですので、textlintで指摘があってエラーが表示されていても実行は継続します。openコマンドでデフォルトブラザを開いているだけですので、ブラウザが複数立ち上がるってしまう可能性があります。Blogすごい書きやすいんだなーとあらためて思ったgolangは相変わらず便利、そしてちょー楽しいblackfridayはv2を使っていないので今後使ってみたいfsnotifyは便利だったので今後も使っていきたい当然このblogもMarkdownで書いているのでtextlintを使ってチェックした以上になります。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。