採用イベント『サバノミソニ』#10 で話してみた #サバノミソニ #swx
前回のイベントから約5ヶ月ぶり2回目のお話の機会をもらったので、前回とほぼ同じスライドですが今思うことを相変わらずのゆるさで話してきました。
今回は
前回と違いタイトルが決まってたりw若干雑な依頼とかではなく・・・
1週間ぐらい前にSlackに12/21水曜の19時~って勉強会行っちゃいますか？とのメッセージが。確かにその日は勉強会の予定があり、会社のカレンダーにも記載されていました。
どーやらその日に会社でイベントをやるそうで、ありがたいことに前回の発表と同じもので発表して欲しいとのこと。
名指しとあらば可能なことは断らずに受けていくスタイルなので発表することに！というか、話すネタさえあればそんなに大変なことでもないですしね。
実際に
今回は15分と前回の発表より少し長めですが、資料は現状に合わせて細かいところを見直しだけにしました。実際にはいろいろ足してみたんですが・・・結局削除して無駄になることにw
会場には若者からおじさんまでと、今回は幅広かったように思えました。
しかし、この予定のほうが後から決まったのに偶然にもアドベントカレンダーの担当日に発表とはw
内山さんの投稿は宣伝しませんでしたがw アドベントカレンダーの宣伝は入れておきました。会社の公式からの扱いも合わせてw
前回から
前回から変化したことといえば、私自身がリモートOKになったことでしょうか？ これは本当にありがたくルール内であれば非常に自由度も高いので助かってます。
こういう部分はリモートやるぞ！という特別な扱いではなく、ごくごく自然に馴染んでるからかなぁ？と。
また、今回今日はここで15分話すために会社に来たぜーと言ったら、外野からリモートでプレンゼンしたら良かったんじゃね？とツッコミがあって・・・そんな全然思いつかなかったw
まだまだ、自由な発想や体験が足りないようなのでこの先生きのこるためには！で先に進んでいこうと思いました。
お待ちしております！
サーバーワークスでは絶賛仲間を募集中です。ご興味ある方は是非お声がけください。
以上になります。
Amazon Rekognition の Demo を試してみた #aws #swx #jawsug
★この記事は「サーバーワークス Advent Calendar 2016」の21日分のエントリーになります
注意
- 機能/サービスの検証とスクリーンショットの取得は
2016/12/11に行いました。 - それ以降に変更が加えられた場合は結果が異なる可能性がありますのでご注意下さい。
- 画像が多めになってます。（しかも
おっさん!!）
はじまり
ある日Slackに 書くよね😸？ の一言と上記のURLが送られてきましたw
名指しとあらば可能なことは断らずに受けていくスタイルなので書くことにっ！
とは言え、入社して半年で何をネタに書こうかなぁーと・・・ これまでサーバーワークスに関してだと↓な感じかぁー
何を書くか
サーバーワークスに関わることであれば何でもOK!!
と言うことなので、なんでもいいらしいがやはり大好きなAWSネタは入れたいところ。
サーバーワークスに入ってしばらくした後に、自己紹介のLTで画像認識を使ったネタをやったことを思い出したので、同じことを今回はAWSでやってみようかと思います。
Amazon Rekognition
今年のre:Invent 2016 で発表された新サービスで Deep learning-based image recognition と公式で説明されています
題材が こけし と謎めいていますが弊社のBlogでも紹介しています
これまでAWSではこの分野のサービスは存在しませんでたが、ようやくサービスとして利用できるようになりました。
ちなみに他のクラウドベンダーは以下のような感じです
使ってみる
AWS マネジメントコンソールにログインして Rekognition のページに移動すれば、Demoを利用することができます。
今回デモ環境で利用してみるのは Face comparison です。よーするに顔が似てるかどうかってやつですね。
デモを利用するだけならこれで準備完了で、あとは比較した顔画像を用意するだけ！今回は前述の通りLTでやった画像をそのまま利用します。
前提
LT全体はどーでもいいので、画像比較の部分だけ抜粋して何をやったかを少し。
↑の画像のように新旧画像w が本人として認識されるかを、マイクロソフトが提供している以下のサイトを利用して試してみました。ちなみに画像に書いてある通りにFacebookの自動タグ付けは反応しませんでしたw
ただ、このサイトで使われているのは
Powered by Microsoft "Project Oxford"
となっていることから、前述した Microsoft Azure Cognitive Services と同等なのかはわかりませんのでご注意ください。
TwinsOrNot.net 上のリンクは以下にリダイレクトされていますがどーなんでしょうか？？
実際に TwinsOrNot.net と Amazon Rekognition のDemo を試してみるのが良さそうなのでやってみました。
TwinsOrNot.net での結果
- 新旧比較
本人なのに・・・なんなのこの微妙な結果は・・・
- 100%一致を目指す最近の画像同士
安心の 100% を確認した。
Amazon Rekognition のDemoでの結果
- 新旧比較
本人なのに！！ ゼロ ってなんだよ！ゼロ・・・
- 100%一致を目指す最近の画像同士
95% ！！5%の違いはどこにあるのかー5%分また膨らんだのか！？
それでも新旧の比較よりはだいぶマシな感じがするから不思議w
まとめ
新旧比較では結果に大幅な違いが出た- 最近の画像同士では両方同じような感じ
- 画像認識などの技術に明るくないので想像するに、特徴点の比較数が異なっていそう？？
- Amazon Rekognition の方が差が極端なので特賞店の比較数が少ないのかもしれない
- まだまだ発表されたばかりのサービス＋Demo環境なので今後に期待したい！
- 検証するための良い画像は手元にあるのでw アップデートが楽しみです！
補足
twitter.comRekognition で compare-faces するときは similarity-threshold=1 とか適当な値をリクエストしておかないと、顔が似てないと足切りで similarity がレスポンスされないので注意な。https://t.co/6MaKMsPGSK
— しみず@AWS芸人 (@shimy_net) 2016年12月10日
CompareFaces - Amazon Rekognition
http://docs.aws.amazon.com/rekognition/latest/dg/API_CompareFaces.html
↑こんな話を目にしたので、Amazon Rekognition のDemoで一致が極端なのはもしかしてこれかっ！と思いみてみると・・・
ちゃんと "SimilarityThreshold": 1 が付加されたリクエストが送られてるっぽいと。
あーやっぱり本人なのに似てないということかw
サーバーワークスなのにネタ少なめじゃないですか？
と、言われる可能性を少しだけ考慮してネタを入れておきますw
初めてお会いした方にごくごく稀にですが 内山さん と呼び間違えらることがあります。多分ですがTVで活躍されている 内山くん とシルエットが似ているからでしょうかねぇ？
なので、今回はその 内山くん とどのぐらい似ているかチェックしてみようじゃありませんかっ！！
前提
その 内山くん の意識合わせをしておきましょう。イメージしている人が違ったら困りますし。
内山信二 - Wikipedia
https://ja.wikipedia.org/wiki/%E5%86%85%E5%B1%B1%E4%BF%A1%E4%BA%8C
今回の検証で利用した画像は、以下のご本人の公式BlogにUPされていたものを利用させていただきました。
TwinsOrNot.net での結果
- 内山くんの2種を比較
安心の100%一致なので次はいよいよ 内山さん と 内山くんの比較をw
- 内山くん と 内山さん の比較
最高で 78% とかなり高いスコアが！！！これはどういうことなのw
自分の新旧比較でも 77% とかなんですけども・・・これはもう似ていると言って差し支えないかもしれないw
- 内山くん（めがね有り） と 内山さん の比較
おい、100%の一致率のがあるぞw どーいうことだよww
メガネの有り/無し でだいぶ結果がかわりました。100%の一致はどーいうことなのよ。 他のも一致率は上がっているし・・・笑いの才能あるなぁーマイクロソフト！！
Amazon Rekognition のDemoでの結果
- 内山くんの2種を比較
本人なのにゼロ 再び・・・鬼だなw
- 内山くん と 内山さん の比較
全部ゼロ！清々しいぐらいにゼロになりますねーやっぱり結果が極端に出る感じがあります。
- 内山くん（めがね有り） と 内山さん の比較
こちらも全部ゼロ！残念ながら 内山くん = 内山さん の面白結果再びならず！
まとめ
- おっさんの顔画像多めで本当にごめんなさい・・・
- やはり2つのサービスで結果がだいぶ異なる
TwinsOrNot.netだけで見ると内山くん=内山さんとなる結果も！！あ、どうも内山ですw- メガネ有りと無しでのせいなのか結果が大幅に変わったのが興味深い
- Amazon Rekognition のDemoはこの場合も0/1のような感覚の出かた
- 両サービスともにまだまだアップデートの余地があり、やっぱり今後が楽しみ。
- Amazon Rekognition のDemoはWebで拝見することも多い勇者様もゼロになっていたので現時点では他の方も似たような状況なんだなぁーと
宣伝
サーバーワークスでは絶賛仲間を募集中です。ご興味ある方は是非お声がけください。
まだまだ続く「サーバーワークス Advent Calendar 2016」
12/25 の最終日までまだまだ続く サーバーワークス Advent Calendar 2016
明日以降の投稿も楽しみですね！
以上になります。
気がつけばもう4ヶ月が経過した件 #swx
今日は
今日は10月14日みんな知ってる鉄道の日ですね。
鉄道の日
https://ja.wikipedia.org/wiki/%E9%89%84%E9%81%93%E3%81%AE%E6%97%A5ja.wikipedia.org
6月16日から株式会社サーバーワークスで働き始めて、気がつけば早4ヶ月になります。何の通知もなかったので知りませんでしたが、気がつけばコーポレートサイトにもメンバーとして載ってたりします。この使われている写真が欲しいなw
笑いすぎてて目がなくなってるじゃんw とか思ったりもしますが笑ってなくても同じようなものだという話も・・・
無事に試用期間も終わりクラウドワークスタイルと呼ばれているリモート勤務を行えるようになりました。クラウドワークスタイルを含めたサーバーワークスのはたらき方は、中の人が話スライドを見るとわかりやすいかもしれないです。例えば↓とか。
試用期間の終わりに簡単な面談？振り返りがあるのですが、ちょうど入社して約1ヶ月で話した内容も自分で振り返りつつの面談だったので、このタイミングで自分が忘れないようにまとめてみました。
何で？
試用期間3ヶ月の終わりに代表と面談する時間が設けられていて、話のネタにするためのアンケートなんかもあったりします。 このタイミングで面談するのは、前職と現職の違いが明確になる時期であるのでそこでカイゼン案や意見が出ることを期待しているとのこと。
細かいアンケート内容はアレですが・・・ざっくり全体として
- 前職と現職の違い
- 前職の良いところ
- 現職の良いところ
- 現職のカイゼン点
- 今後やりたいこと
- 印象の違い
と、言う感じでした。 1 on 1 で話せる機会を設定しているのと、カイゼンのためのミーティングというのはいいなぁーと感じました。こいうのこれまでなかったなぁw
リモートワーク
実際にリモートワークをやってみて感じたのは
- 自宅から移動しないので楽
- 通勤時間分を作業できる
- 当然自由なこともできる
- 自宅から出ないので引きこもり気味に
- お昼にラーメン食べる機会へった
- 健康になるかどうか知らんw
- 勉強会への参加頻度も下がった気がする
- 煮詰まったときにいろいろできる
- 積み本消化とか
- 単純に休憩だけじゃなく風呂に入るとか
- slackやらgithubでのやり取り楽
- 非同期でのコミュニケーションなので返答ない時は他のことをする
- 作業を切り替えるタイミングがある
- ミーティングもリモート済むのは助かる
- 社内勉強会も中継されるので参加可能
- 対面ではないので雰囲気がわからないので長引くこともある
- 思いついた時に作業できる
- 仕事と私事の区別が曖昧になることもある
- 細かいことを気にしてるとダメな気がする
時間の自由は自分のペースで作業できることになるので、非常に有難いですねーこの1点だけ切り取ってみても、転職してよかったと感じます。
まとめ
なんかよくわからん感じになってますが、常にカイゼンを続けて変化に柔軟に対応して成長を続けられるのはすごいことだなぁーと
まー当然100%マッチしてるということはないのですが、前に比べたら余計なことを気にせずいろいろ出来る環境にいることは確かだなと。 今後は前に関わってた＆興味があること/分野にも可能な範囲で手を伸ばしていきたいものです。ゆるーくですがw
またどこかでお会いすると思いますが、その時はよろしくお願いいたします。
以上になります。
Slack+Chalice(API Gateway+Lambda)を使ってHerokuのコマンドを実行してみた #slack #aws #chalice #lambda #heroku
chalice（Python Serverless Microframework for AWS）を使って Content-Type: application/x-www-form-urlencoded のPOSTリクエストを受けるところまでは確認済みなので、今回はこれを使ってやりたかったことにチャレンジしてみました。
書いてる間にバージョンが0.3.0に上がっていました・・・試したのは0.2.0になりますので差異があったらごめんなさい
きっかけ
仕事で Heroku を使う機会が増えている今日この頃です。今までこんなに触る機会がなかったのでなかなか楽しく作業しております。
Heroku は多くのAdd-onsがあり、無償で利用できる物もあります。
当然今のプロジェクトでもいろいろと利用しているのですが、その中でHubotの無償運用なんかでおなじみのHeroku Schedulerを利用しています
Heroku Schedulerの説明を確認すると
このような一文が・・・
Scheduler is a “best effort” service ですってよ！
Scheduler is a “best effort” service, meaning that execution is expected but not guaranteed. Scheduler is known to occasionally (but rarely) miss the execution of scheduled jobs. If scheduled jobs are a critical component of your application, it is recommended to run a custom clock process instead for more reliability, control, and visibility.
実際に約2ヶ月間で１回だけ実行されないことがあり、そういう場合に何かゆるい感じで対応できるといいなぁーと思ったのが作業のきっかけです。上記の文面をみればわかりますが、ちゃんと対応するならrun a custom clock processにしろと書いてありますしねー
ちなみに、今回実行されていないことを通知したのも無償で使えるadd−onのDead Man's Snitchになります
チームメンバーに教えてもらったのですが、今まで全然知りませんでした。結構前からあるサービスみたいですねーいやー便利。単純に払い出されたURLにGETリクエストするとチェックイン状態になり、そのチェックインを毎時/毎日みたいなタイミングでチェックして、チェックインがなければ通知してくれるだけのシンプルなサービスです。
Herokuのadd−on経由だと１つのチェックインが無償で、チェックのインターバルと通知先に制限がある状態です。通常は有償なので制限ありでも無償で使えるのはありがたいし試しやすいですよね。
インターバルの制限は今回は問題にならないのですが、通知先がmailのみとのことなので、slackのEmail integrationを利用してチームメンバーと共有可能な状態にしました
通知はされるが
Email integrationを利用したので、何かあればslackに通知がされるようになりました。Email integrationでの通知はemailを添付ファイル扱いで通知する仕様のようです。
最初に思いついたのは
みたいな流れなのですが・・・Outgoing WebHooksが添付ファイル部分には反応しない仕様のようです。
email文中の特定のキーワードに反応してくれたら十分なんですが、残念ながら無理っぽいようです
結局
色々試した結果Outgoing WebHooksのTrigger Word(s)にemailを指定してすることでemailの受信時にWebHookがかかるようになりました。これはemail受信時の投稿がemail uploaded a file:<添付ファイルのURL>のような形式となっているので、この文中のemailに反応してWebHookが発行されているようです。
注意が必要なのは今回は動作確認なのでemailという単語でWebHookを発行しています。Outgoing WebHooksをintegrationしたslackチャンネルで日常的にemailという単語が使われている場合はTrigger Word(s)を別のものにした方が良いかと思います。
Outgoing WebHooks の設定画面のドキュメントには以下のようなデータがPOSTされると書かれています。
token=blaNqr3fL7b8AqnwCNFW86oZ team_id=T0001 team_domain=example channel_id=C2147483705 channel_name=test timestamp=1355517523.000005 user_id=U2147483697 user_name=Steve text=googlebot: What is the air-speed velocity of an unladen swallow? trigger_word=googlebot:
実際にはこのデータがapplication/x-www-form-urlencodedで送信されるので
token=XXXXXXXXXXXXXXXXXXXXXXXX&team_id=T0295086H&team_domain=serverworks&service_id=77430880359&channel_id=C1X85EYNR&channel_name=times-uchida×tamp=1476076555.001561&user_id=USLACKBOT&user_name=slackbot&text=email+uploaded+a+file%3A+%3Chttps%3A%2F%2Fserverworks.slack.com%2Ffiles%2Fslackbot%2XXXXXXXXXX%2F_missing__import_data_monitoring_hasn_t_checked_in%7C%5BMISSING%5D+import+data+monitoring+hasn%27t+checked+in%3E&trigger_word=email
のような形式で送信されてきます。また、今回のように添付ファイルがある場合でもPOSTデータに添付ファイルのデータが入るようなことはないようです。残念。
Please note that the content of message attachments will not be included in the outgoing POST data.
chaliceを利用する
WebHookのPOST先を作らないといけないわけですが、あまり手間をかけずに簡単に作りたいわけですね。Heroku使ってるならそれでいいじゃん！という話もありますが、chaliceでapplication/x-www-form-urlencodedが受けられるようになったのを確認したばかりなのでchaliceを使います
chaliceそのものの使い方は簡単＆他に詳しく書かれているものがたくさんあるので割愛しますが、chalice (0.2.0)以上を利用しないと上手く行かないと思うのでその点だけ確認してください
$ chalice new-projectで新規にプロジェクトを作成し、application/x-www-form-urlencodedのPOSTが受けられるよう設定します
from chalice import Chalice app = Chalice(app_name='slack_receive') @app.route('/slack', methods=['POST'], content_types=['application/x-www-form-urlencoded']) def slack(): body = app.current_request.raw_body
app.current_request.raw_bodyには前述の&で連結された情報が入っているので、この中から必要なものを取り出してあげます。
Pythonのデフォルトライブラリを利用してパースを行い、後で扱いやすいように辞書型にしておきます。
from urlparse import parse_qsl body = app.current_request.raw_body parsed = dict(parse_qsl(body))
パースした結果は以下のような状態になっていると思います
{'user_id': 'USLACKBOT', 'channel_name': 'times-uchida', 'timestamp': '1476076555.001561', 'team_id': 'T0295086H', 'trigger_word': 'email', 'channel_id': 'C1X85EYNR', 'token': 'XXXXXXXXXXXXXXXXXXXXXXXX', 'text': "email uploaded a file: <https://serverworks.slack.com/files/slackbot/XXXXXXXXX/_missing__import_data_monitoring_hasn_t_checked_in|[MISSING] import data monitoring hasn't checked in>", 'service_id': '77430880359', 'team_domain': 'serverworks', 'user_name': 'slackbot'}
必要に応じて値のチェックを行うわけですが、今回はtokenとtextをチェックしています。tokenに関してはLambdaのblueprintでslack関連のものを見ると、以下のようにAWS Key Management Service (KMS)を使った例がありますのでそれをそのまま利用します。
import boto3 from base64 import b64decode ENCRYPTED_EXPECTED_TOKEN = '<kmsEncryptedToken>' # Enter the base-64 encoded, encrypted Slack command token (CiphertextBlob) kms = boto3.client('kms') expected_token = kms.decrypt(CiphertextBlob=b64decode(ENCRYPTED_EXPECTED_TOKEN))['Plaintext']
KMSを追加してchaliceにてデプロイを行うと以下のようなメッセージが表示されるかと思います
$ chalice deploy Updating IAM policy. Unsupported service: kms
開発中ということもありすべてのAWSサービスには対応してないようです。ポリシーを自動生成してくれるのは非常に便利なので、今後のサービス対応に期待しましょう
じゃーどうすんの？って話なんですが、ドキュメントを見ると手動で作ったポリシーを使う方法があります。chaliceのプロジェクトディレクトにある.chalice/polict.jsonを編集してkmsの復号の権限を付加します
{ "Version": "2012-10-17", "Statement": [ { "Sid": "Stmt1443036478000", "Effect": "Allow", "Action": [ "kms:Decrypt" ], "Resource": [ "<your KMS key ARN>" ] } ] }
これでポリシーは問題なくなりましたが、今までと同様にデプロイを実行すると以下のような確認が行われます。この確認でYesを選択すると上記で手動追加したポリシーが削除され、chaliceが自動生成するものに置き換わりますので注意が必要です。noを選択するとデプロイ自体がキャンセルされます。
$ chalice deploy Updating IAM policy. Unsupported service: kms The following action will be removed from the execution policy: kms:Decrypt Would you like to continue? [Y/n]: n Error: Error when deploying:
手動で編集したポリシーを利用するためにはドキュメントにあるように--no-autogen-policyをつけてデプロイを実行します
The automatic policy generation is still in the early stages, it should be considered experimental. You can always disable policy generation with --no-autogen-policy for complete control.
これでKMSが利用できるようになったので、slackのtokenが意図したものかどうかを確認することができます。同時にtext中に意図した文字列があるかどうかも確認を行います。
Heroku APIを利用する
ここまでで、slackからのWebHookを受けて内容を確認するところまで終了しました。次はHeroku APIを利用してHerokuのコマンドを実行してみます。
APIを利用するためには認証キーを取得する必要があります。Herokuのアカウントページで認証キーを確認しておいてください
Authentication is passed in the Authorization header with a value set to :{token}. You can find a token to use on the “Account” page (in the “API Key” section) on your dashboard or by running this command:
このAPI認証キーもKMSを利用して暗号化を行って利用します。コマンドを実行するためにはHeroku Platform APIのDyno関連を利用します。
Herokuはドキュメントが非常に丁寧に書かれているので、ドキュメントをみれば問題ないかと思います。ドキュメントではcurlの例が示されていますが、Pythonではrequestsライブラリを利用しました。
Requests: 人間のためのHTTP — requests-docs-ja 1.0.4 documentation
http://requests-docs-ja.readthedocs.io/en/latest/requests-docs-ja.readthedocs.io
Heroku APIで指定されているHTTPヘッダー項目を付けるのを忘れなければ特別なことをする必要がなくDyno Createでコマンドが実行できます
このAPIでコマンドを実行した場合、レスポンスについてはHTTPステータスコード201が返却されます。
HTTP/1.1 201 Created ETag: "0123456789abcdef0123456789abcdef" Last-Modified: Sun, 01 Jan 2012 12:00:00 GMT RateLimit-Remaining: 2400
HTTPステータスコード - Wikipedia
https://ja.wikipedia.org/wiki/HTTP%E3%82%B9%E3%83%86%E3%83%BC%E3%82%BF%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89ja.wikipedia.org
このレスポンスからだと実行したコマンドが正常に終了したかどうか判断することができません。APIで結果を確認するにはLog Session関連を利用するのが良さそうです
Log Session CreateAPIのレスポンスで得られたlogplex_urlに対してGETを行うと実際にLogを取得することができます。
heroku[router]: at=info method=HEAD path="/login" host=hoge.herokuapp.com request_id=8184c319-ffb0-43ab-9ea7-861991176b3a fwd="XX.XXX.XXX.XX9X" dyno=web.1 connect=1ms service=7ms status=401 bytes=354\n2016-10-10T05:15:58.327710+00:00 heroku[api]: Starting process with command `python manage.py purgerequests 4 months --noinput` by uchida@serverworks.co.jp\n']
実際にはコマンド実行後に非同期でLogを確認する必要があるので、1つのLambda関数だけでなくSQSなどを利用して他のLambda関数で確認する必要があります。また、Herokuに関して言えばAdd−onで解決してしまうのもアリだと思います。
Papertrail のようなLogを管理できるサービスを利用すればサービス上で特定のLogを検知してslackに通知することが可能です。これを利用すればコマンド実行後の状態を検知してslackに通知してしまえば結果を確認することが可能となるため、わざわざプログラムを組む必要はなくなります。楽できる方がいいですしね。
Slackにレスポンスを戻す
ここまでで、slackからのWebHookを受けて内容を確認してHeroku APIでコマンドを実行するところまで終了しました。最後にslackにレスポンスを戻して終了です。
Outgoing Webhooks | Slack
https://api.slack.com/outgoing-webhooksapi.slack.com
ドキュメントを確認するとJSON形式でtextプロパティの値を設定すれば良いので、requestsのレスポンスを.json()で設定してslackに戻しています。ただし、このレスポンス中にWebHookのTrigger Word(s)が含まれていないことが前提になります。
import requests import json resp = requests.post('<URL>', data=json.dumps(data), headers=headers) result = {'text': resp.json()} return result
まとめ
ということで、これでSlack+Chalice(API Gateway+Lambda)を使ってHerokuのコマンドを実行することができました。まー何に使うの？って話はありますが・・・
chaliceを使うと非常に簡単にAPI GatewayとLambdaを使うことができます。自動で生成されるポリシーも便利ですし今後も楽しみです。一方で複雑になったり大規模になったりした場合は大変かなぁーという印象もあります。他のLambdaを利用できるフレームワークもたくさんあるので使いやすいものを選択するのが良さそうです。
また、今後リリースされるというFlourishも楽しみですね。もうすぐre:Invent 2016が開催されますし期待しながら待っています！
Appendix
利用したchaliceのコード例
import boto3 import requests import json import time from chalice import Chalice from urlparse import parse_qsl from base64 import b64decode app = Chalice(app_name='slack_receive') kms_client = boto3.client('kms') ENCRYPTED_SLACK_TOKEN = '<your own value>' SLACK_TOKEN = kms_client.decrypt(CiphertextBlob=b64decode(ENCRYPTED_SLACK_TOKEN))['Plaintext'] ENCRYPTED_HEROKU_API = '<your own value>' HEROKU_API = kms_client.decrypt(CiphertextBlob=b64decode(ENCRYPTED_HEROKU_API))['Plaintext'] SLACK_KEYWORDS = "<your own value>" @app.route('/slack', methods=['POST'], content_types=['application/x-www-form-urlencoded']) def slack(): body = app.current_request.raw_body print('body={}'.format(body)) result = {"text": "post OK !"} slack_token = parsed_l.get('token') if slack_token != SLACK_TOKEN: result = {"text": "slack token not valid!"} return result slack_text = parsed_l.get('text') if slack_text: print('slack_text={}'.format(slack_text)) index = slack_text.find(SLACK_KEYWORDS) print('index={}'.format(index)) if index != -1: start = slack_text.find('|') end = slack_text.find('>') sub_text = slack_text[start+1:end] print('sub_text={}'.format(sub_text)) if SLACK_KEYWORDS == sub_text: print("--- same words!! ---") # call heroku API auth_str = 'Bearer {}'.format(HEROKU_API) headers = {'Accept':'application/vnd.heroku+json; version=3', 'Authorization':auth_str, 'Content-Type': 'application/json'} data = {'command':'<your own value>', "attach": 'false', "type": "run", "time_to_live": 1800} print('headers={}'.format(headers)) print('data={}'.format(json.dumps(data))) resp = requests.post('https://api.heroku.com/apps/<your own value>/dynos', data=json.dumps(data), headers=headers) cont = {'status_code': resp.status_code, 'body': resp.json()} result = {'text': json.dumps(cont)} # log time.sleep(5) data2 = {} resp2 = requests.post('https://api.heroku.com/apps/<your own value>/log-sessions', data=json.dumps(data2), headers=headers) print{'resp2={}'.format(resp2.text)} log_url = resp2.json().get('logplex_url') resp3 = requests.get(log_url, headers=headers) print{'resp3={}'.format(resp3.text)} return result
こんなエラーメッセージが出たら
$ chalice deploy --no-autogen-policy Updating IAM policy. Updating lambda function... Creating deployment package. Sending changes to lambda. Lambda deploy done. API Gateway rest API already found. Deleting root resource id Done deleting existing resources. Error: Error when deploying: An error occurred (PolicyLengthExceededException) when calling the AddPermission operation: The final policy size (20575) is bigger than the limit (20480).
issue にもありますがLambda関数自体を削除して再度デプロイを行えば問題ありませんでした。
と思ったら、冒頭にも書いた通りにバージョンが0.3.0になり、このissueの対応が行われています。0.2.0以下の人はバージョンを上げましょう
地味に困る
エラーが起きるとChaliceのエラーとしてraiseされるので、何が原因なのか特定しにくい。単純にimportを忘れた場合もchaliceのエラーとなるので他の場所かと思ってしまうと言うね・・・この辺は何か改善してほしいなぁーすでにあるなら教えてください！
ChaliceViewError: An internal server error occurred.: ChaliceViewError Traceback (most recent call last): File "/var/task/chalice/__init__.py", line 207, in __call__ raise ChaliceViewError("An internal server error occurred.") ChaliceViewError: ChaliceViewError: An internal server error occurred.
以上になります
Python Serverless Microframework for AWS (chalice) でJSON 以外のPOST を受けてみた #aws #chalice #lambda
Python Serverless Microframework for AWS (以下、chalice) を利用して
Content-Type: application/x-www-form-urlencoded
のPOSTを受けてみたことを簡単にまとめてみました。
chalice は特に指定を行わない場合は application/json で受けるのがデフォルトっぽいですが、やっぱり application/x-www-form-urlencoded を扱いたいこともあるわけなので。
ドキュメントをみると
Quickstart and Tutorial — Python Serverless Microframework for AWS 0.2.0 documentation
と、丁寧に書かれているのでそのままコピペするも実行結果は
{
"message": "Unsupported Media Type"
}
API Gateway の設定がどうなっているか見てみると・・・マッピングテンプレートで application/x-www-form-urlencoded 用のテンプレートが指定されておらず application/json のみで、どんな場合もパススルーしない設定になっているというね・・・
と、ここまではちょっと前までの バージョン0.1.0 での話ですが、ドキュメントに書いてあって実現できなかったのはちょっと残念でした。
バージョン0.2.0
で、現在のバージョンは0.2.0になっており最新バージョンで再度試してみます
前回と同様にしてchaiceでデプロイを行うと、最新バージョンではちゃんとAPI Gatewayのマッピングテンプレートにapplication/x-www-form-urlencoded 用のテンプレートが指定されていました
やっと動いたよ！と思うんですが・・・いろいろやっている間にAPI Gateway側のアップデートがあり、「Lambda プロキシ統合の使用」といったリクエストをLambdaに簡単にスルーできるオプションが追加になりました
API Gateway のアップデート – API 開発を簡素化する新機能 | Amazon Web Services ブログ
https://aws.amazon.com/jp/blogs/news/api-gateway-update-new-features-simplify-api-development/
この機能を使えばContent-Typeを気にせずにLamda関数にリクエストを送れるので、今までよりだいぶお手軽な気がしますし、Lambdaのblueprintから新規作成したりすると、すでにこの機能を使ったANYでProxyを利用した接続になっています。
実際にchalice でapplication/x-www-form-urlencoded 用のテンプレートが用意された状態と、このProxy機能でスルーされた状態でLambdaに届くデータの内容を比較してみました。
送信したのは上記したchaiceのドキュメントに書かれている httpie を利用した例と同じで
http --form POST https://endpoint-hoge1.ap-northeast-1.amazonaws.com/dev/ states=WA states2=CA --debug
Proxyの場合はevent 引数に以下のような感じで入ってくる
{u'body': u'states=WA&states2=CA', u'resource': u'/proxy-test', u'requestContext': {u'resourceId': u'co8iwy', u'apiId': u'1m6791x3wk', u'resourcePath': u'/proxy-test', u'httpMethod': u'POST', u'requestId': u'6f00523f-8936-11e6-831a-e9eb40e256a5', u'accountId': u'316874585308', u'identity': {u'apiKey': None, u'userArn': None, u'cognitoAuthenticationType': None, u'caller': None, u'userAgent': u'HTTPie/0.9.6', u'user': None, u'cognitoIdentityPoolId': None, u'cognitoIdentityId': None, u'cognitoAuthenticationProvider': None, u'sourceIp': u'xxx.xxx.xxx.xxx', u'accountId': None}, u'stage': u'prod'}, u'queryStringParameters': None, u'httpMethod': u'POST', u'pathParameters': None, u'headers': {u'Content-Type': u'application/x-www-form-urlencoded; charset=utf-8', u'Via': u'1.1 064b8001bd91f53f9b5f04fba4435677.cloudfront.net (CloudFront)', u'Accept-Encoding': u'gzip, deflate', u'CloudFront-Is-SmartTV-Viewer': u'false', u'CloudFront-Forwarded-Proto': u'https', u'X-Forwarded-For': u'xxx.xxx.xxx.xxx', u'CloudFront-Viewer-Country': u'JP', u'Accept': u'*/*', u'User-Agent': u'HTTPie/0.9.6', u'Host': u'1m6791x3wk.execute-api.ap-northeast-1.amazonaws.com', u'X-Forwarded-Proto': u'https', u'X-Amz-Cf-Id': u'4meZj8EGU3Ui_FvMztZ-Y5Oh4pkz3Tm-s4wKSd1VaZ9o722piksxIA==', u'CloudFront-Is-Tablet-Viewer': u'false', u'X-Forwarded-Port': u'443', u'CloudFront-Is-Mobile-Viewer': u'false', u'CloudFront-Is-Desktop-Viewer': u'true'}, u'stageVariables': None, u'path': u'/proxy-test'}
'Content-Type': 'application/x-www-form-urlencoded; charset=utf-8' のPOSTを受けて 'body': 'states=WA&states2=CA' にパラメータ文字列が入っているのがわかります
当然パススルーしてるだけなので他のContent-Typeでも問題なしなので
{u'body': u'{"states": "WA", "states2": "CA"}', u'resource': u'/proxy-test', u'requestContext': {u'resourceId': u'co8iwy', u'apiId': u'1m6791x3wk', u'resourcePath': u'/proxy-test', u'httpMethod': u'POST', u'requestId': u'a407c1a9-8941-11e6-a603-f18eaa90784e', u'accountId': u'316874585308', u'identity': {u'apiKey': None, u'userArn': None, u'cognitoAuthenticationType': None, u'caller': None, u'userAgent': u'HTTPie/0.9.6', u'user': None, u'cognitoIdentityPoolId': None, u'cognitoIdentityId': None, u'cognitoAuthenticationProvider': None, u'sourceIp': u'xxx.xxx.xxx.xxx', u'accountId': None}, u'stage': u'prod'}, u'queryStringParameters': None, u'httpMethod': u'POST', u'pathParameters': None, u'headers': {u'Content-Type': u'application/json', u'Via': u'1.1 fbd80349eadc2efc6c27a91d8ce7b321.cloudfront.net (CloudFront)', u'Accept-Encoding': u'gzip, deflate', u'CloudFront-Is-SmartTV-Viewer': u'false', u'CloudFront-Forwarded-Proto': u'https', u'X-Forwarded-For': u'xxx.xxx.xxx.xxx', u'CloudFront-Viewer-Country': u'JP', u'Accept': u'application/json, */*', u'User-Agent': u'HTTPie/0.9.6', u'Host': u'1m6791x3wk.execute-api.ap-northeast-1.amazonaws.com', u'X-Forwarded-Proto': u'https', u'X-Amz-Cf-Id': u'QYZPvi7XzpkyeWG6FUIGPvilp3mRp4uE-bw6pk8D-5jFcR2IrrlH5g==', u'CloudFront-Is-Tablet-Viewer': u'false', u'X-Forwarded-Port': u'443', u'CloudFront-Is-Mobile-Viewer': u'false', u'CloudFront-Is-Desktop-Viewer': u'true'}, u'stageVariables': None, u'path': u'/proxy-test'}
'Content-Type': 'application/json' で受けて 'body': '{"states": "WA", "states2": "CA"}' とJSON文字列が入っているのがわかります。
Lambdaコード側で Content-Type によって処理を分ける場合があれば便利かもしれないですね
chalice の場合はドキュメントに書いてある通り、JSONの場合には current_request.json_body に値が、それ以外の場合は current_request.raw_body に値が入っているそうです
The second thing worth noting is that
app.current_request.json_bodyis only available for the application/json content type. In our example above, we usedapp.current_request.raw_bodyto access the raw body bytes:
Chalice — Python Serverless Microframework for AWS 0.2.0 documentation
http://chalice.readthedocs.io/en/latest/api.html?highlight=current_request#request
実際に試してみると
states=WA&states2=CA
のような形で、パラメータ文字列を取得することができます。また、こちらはJSON形式でリクエストを行うとマッピングテンプレートがありませんので当然ながら
{
"message": "Unsupported Media Type"
}
となります。
まとめ
API GatewayのアップデートによりProxy機能で簡単にLambda関数を呼び出して実行できるようになっています。
一方で、chaliceはターミナル上から手軽にデプロイと確認が行え、ログに関しても見ることができます。
API Gatewayの新機能での実現とchaliceでの実現、どちらでもJSON以外のPOSTは簡単に受けられました。chaliceは今後もこの手軽な感じで進んで行ってもらいたいです。
以上。
今年も土曜の午前中から高尾山にてビールが飲めるイベントを開催してみた #jawsug #jawsug_mt
今年で3回目の開催となりました夏の定番!?なイベントを今年も無事に開催しました。
登壇者、参加者の皆様ありがとうございました。
また、今年は募集が遅くなったり、タイムテーブルがなかなか決まらずに最少催行人数 50人 の制限に届かず開催が出来ないところでしたが
- Sansan株式会社
- 株式会社ハートビーツ
以上、2社さんにスポンサーとしてご協力していただくことにより、無事開催することができました。スポンサーの2社さん本当にありがとうございました。
さらに、イベント当日にも会場にて
- 株式会社スカイアーチネットワークス
- 個人参加者複数名
のご協力をいただきました。皆様本当にありがとうございました。
アンケートのお願い
上記のように、今年も色々な方のご協力と優しさによりなんとか開催することができましたが、次回以降も開催できるよう運営としてカイゼンをしていきたいと考えております。
つきましては、以下のアンケートにご協力いただけると大変助かります。参加/不参加にかかわらず回答可能な内容となっていますので、お時間がある時にぜひよろしくお願いいたします。
当日のつぶやきもまとめてありますので、よろしければ雰囲気を掴むために合わせてご覧下さい
イベントまとめ（個人的感想含む）
前年の高尾山は小雨降る天気で、今年も台風が接近していて心配ではありましたが・・・当日は晴れて気温も高く、絶好のビアマウント日和になりました。
しかし、駅に着いてみると京王線がこのタイミングで20分ぐらい遅延しているとのこと。会場の都合で時間で開始して、時間で終了しないとならず影響が出なければいいなぁーと。
ここまで年一回の家近くイベントの恩恵でのんびりしていたわけですが、さすがに電車遅延で開始に間に合わないと困るので、すこし早めに家を出ました。
で、見慣れたこの写真の場所に。もちろん普段は来ないので約1年ぶり3回目の到着です。行きはこちらも毎回乗るケーブルカーで。
ケーブルカーで高尾山駅まで行くと、同じケーブルカーに乗ってきたひとやら既に山頂まで行ってきた人やらが待ってました。
＊撮影：俺たちの松井さん
毎年山頂に行ってから来る方や、高尾山ビアマウントのある場所まで登ってくる人が居てなんのイベントなのかとw
#jawsug 高尾山 フライング登頂！ pic.twitter.com/blccEym7xS
— FUJISAKI Masanori (@fujisaki_hb) 2016年9月17日
入り口には安定の予約看板が！
・・・中央線だけで京王線の記載がないのがちょっと気になりますが。
時間になって高尾山ビアマウントに入ると、こちらも毎回おなじみの場所での会場設営。プロジェクターとスクリーンは持ち込みです。毎度毎度運搬している運営の方々ありがとうございます。
時間制限があるので、会場設営の間に各自飲み物やら食べ物やらを持ちに行ってもらいゆるーい感じで飲みながらスタートしました。
最初はSORACOM 松井さん
- 内容はSORACOMサービスの入門的なお話
- よく見るとSORACOMパーカーを着てらっしゃる！！
- 聞いてみたらワンオフものとのこと
- Funnelは「ファネル」で「ファンネル」ではないよ
- Funnel は個人的に好きなのでみんなももっと使うといいと思うよ
- もうすぐサービス発表から1年のSORACOMさんは勢いあるなー
- 社員数も30名程度と順調に増えてる様子
- 松井さんは高尾山が終わったら熊本に行くそうです・・・
- お忙しいところの登壇に本当に感謝です
- SORACOMさんの今後も非常に楽しみにしています！
続いてハートビーツ 藤崎さん
- 株式会社ハートビーツ の会社紹介
- スポンサーをした理由は毎年恒例の登山後のビールが飲めないのは寂しいから
- 東京ゲームショウに出店したり、ISUCONの予選に参加してたりするから社員は誘えなかった
- なので今回も1人で来た
- こいつやるな！と思った時は研修で iptables.c を読む機会を作ったりする
- スポンサーは本当にありがとうございました！
続いてクラスメソッド 大栗さん
- Blogの会社で有名なクラスメソッドさん
- 昨年に引き続きJAWS−UG富士山のお話
- と思ったら途中からシードル講座にw なんの話だw
- さらにそこからAWS Premier Night #1 の資料を使った再演に
- シードル講座のBlogとX1インスタンスのベンチマークはいつ!?
- 両方のBlogとドヤ顔を楽しみにしてます！
続いてホートンワークス 河村さん
- Apache NiFi のコミッター
- NiFi は「ナイファイ」と読みます
- ナイフとかいろいろ読み間違いが多いので是非覚えてください
- ホートンワークスの会社紹介とサービス紹介
- ホートンワークスのサービスに関しては前職の時にいろいろ説明してもらったなぁー
- 独自にコードを変更しないでOSS版をそのまま利用している
- NiFi を使ったデモを持ってきた
- 赤・緑・青 をTweetすると画面が変化するはず
- ネットワーク不調でデモ成功せず
- 是非別の機会にデモ含めてもっとお話を聞いてみたいです
Apache NiFi
続いてSansan 間瀬さん
- Sansan株式会社の説明
- サービスの紹介と構成も少しだけ紹介
- .Net で開発している
- エンジニア補助制度が半端ない素晴らしさだった
- 書籍購入補助やら端末購入補助やら、勉強会参加補助なんていうのもあった
- エンジニア補助制度は詳しく知りたい！！
- スポンサーは本当にありがとうございました！
続いても同じくSansan 簗井さん
- Eight の中の人
- いろいろごちゃごちゃしていたものを自動化したよ
- 手元でも環境が再現できるように工夫したよ
- そもそも環境のセットアップみたいな基本的なところが自動化されていないとみんな大変
- LT枠なので少し短めでしたがEight という身近なサービスをいろいろ改善しているのは面白そうだなぁーと
最後はサーバーワークス ぎょりさん
- 最後になってしまったので時間が押してちょー駆け足に
- イベントの告知を数個
- AWS Cloud Roadshow あるから来てね
- スッタフを全員女性で運営するイベントがある
- 全然人が足りないので是非協力してほしいとのこと
- 直前まで資料を修正していたのに時間が足りなくなって申し訳ないです
これで、撤収時間ぎりぎりとなり急いで撤収しました。
参加可能な人を集めて恒例の集合写真を撮って、無事に今回のイベントも終了となりました。
今回は人数が足らずいろいろとご迷惑をおかけしましたが、開催できて本当に良かったです。皆様本当にありがとうございました！次回以降も是非ご参加ください。
これも恒例の
集合写真が終わり解散すると、下山組と登頂組に分かれました。
これも毎年恒例になってますね。毎回登ってますがやっぱり途中でやめておけば良かったと思うんですよねw
無事山頂に！
今回は降りる時に来た道と違う道を通ることになりました。4号路という途中に吊り橋があるルートで戻ることに
めっちゃブレてるけどその吊り橋ですw
ケーブルカー乗り場まで戻ってきて、帰りもケーブルカーに乗ろうと思っていましたがケーブルカーの往復券でもリフトに乗れるとのこと。
せっかくなのでリフトに乗りますかーとなり、みんなでリフトで降りてみました
ケーブルカーより多少時間はかかりますが、晴れていればリフトの方が風が気持ち良く眺めも良かったです。あと、順次くるので待つ必要がないのもいいですねー
次回は上がる時もリフトでもいいかもなぁーと思いました。
麓に着いたら再度解散に！温泉に入ってから帰る組がいましたが、年1回の家が近いイベントなのでそのまま帰るぜーと・・・甘いものをチャージしてから帰りましたw
今年も楽しいイベントでした。開催できるだけでありがたいので今後続けていけるように是非アンケートにご協力よろしくお願いいたします。
この形でソフトクリームが売ってるのかすごい気になったなぁw
以上になります。
採用イベント『サバノミソニ』#5 でタイトル縛りで話してみた #サバノミソニ #swx
会社の採用イベントで話しをする機会をもらえたので、入ってみて感じたことをゆるい感じで話してみました。
そもそも
2016年06月15日付で株式会社ヴァル研究所を退職し、翌日の2016年06月16日付で株式会社サーバーワークスに入社しました。
前職では本当にたくさんの方々にお世話になりました。本当にありがとうございました。
直接ご挨拶できずに大変恐縮ですが、引き続き勉強会等であった際にはよろしくお願いいたします。
まーつまり今現在は、入社から約1ヶ月＆試用期間中という状態なわけです
きっかけは
前回のサバノミソニ #4でも同じような形で、入社1ヶ月程度の中途メンバーがLTをしていたようなので、今回も同じ感じで行って欲しいとのこと。
しかし、依頼された時の流れは↓な感じですごい雑wなんだこれはw
＊社内Slackより
タイトル縛りのあるLTはやったことがないので、せっかくだからそれにしましょうということに。というか便乗して煽ってくる人がいるのはなんでなんだぜw
実際にはこの後正式なタイトルにするので教えてください的な話がありましたが、そこは面白い方を取るスタイルでw
実際に
10分ということではありましたが、入社1ヶ月程度の仮免状態が感じていることを話してみました。
100%全部受け入れられて最高です！ってことができればそれはそれで幸せなのかと思いますが・・・おじさんというか35歳定年説で言えばもうおじいちゃんなので、気になる点も話してみました。
気になる点は悪いとか嫌とかいうわけではなく、もうちょっと工夫したらさらに快適になるよねーという形で捉えていただければ。
まーこの辺は普段の行いとキャラクターに依存するところも大きいので、違った捉え方をされたら自業自得ってことでしょうがないですがw
3つのところをなんとか6つまでひねり出したので、良しとしておきたいですw
今後は
試用期間をこの先生きのこるには！となると思うので、置いて行かれないように先に進んでいこうかと思います。
現状こんな感じでRubyなのか？AWSなのか？SWFなのか？の洗礼を受けているのでw
＊社内Slackより
お待ちしております！
気になった方はお問い合わせをお待ちしております。
問い合わせ先がなるほどよくわからん。って場合には私個人に適当投げてください。
