API Gateway を使って Amazon SESでメールを送信する - Qiita
はじめに AWS Lambda と API GatewayでRails使わずに済んだ話 // Speaker Deck をスライド公開したら意外とはてブ付いてたので、手順をQiitaに書いといた方が活用されやすいかなと思ったので書きます。 ステップ 以下の手順で構築していくことになります。 AWS Lambda に実行したいソースを書く AWS API Gatewayの設定をする 実際に呼び出す 1. Lambdaに実行したいソースを書く 今回は実際に私が利用したPythonでの実装例を書きます。フォームで入力を受け付け、運営側には入力された内容のメールを、ユーザには自動応答のお礼メールを送る、という内容です。 新規作成 > microservice-http-endpoint-pythonを使用 既存のコードはAmazon DynamoDBに入れるコードになっているのを以下のように修正
不要になったLaunch Configurationを削除するGemを作った - Qiita
背景 AWSのAutoScalingは超絶便利なのですが、AutoScalingの元となるLaunch Configurationが編集不可能であるため、AMIの構成を変更したりして新しいAMIを作ると、Launch Configurationも新たに作る必要があります。（コピー機能ができたので以前よりはかなりマシになりましたが） そういうわけで、Launch Configurationの数はオートスケーリングを運用していると必然的に数が増えていきます。数が増えていくと、Auto Scaling GroupからLaunch Configurationを選ぶときのUIがつらくなるので、定期的に削除する必要があります。 というわけでManagement Consoleから削除するのですが、なんとこのUI、複数選択だと削除することができません。 作ったもの というわけで、溜まっていくとつらくなる
hubotでデプロイ用のpull requestを作るプラグイン、hubot-deploy-builderを作成しました - Qiita
hubotでデプロイ用のpull requestを作るプラグイン、hubot-deploy-builderを作成しましたGitHubHubot はじめに Hubotでデプロイ用のpull requestを作るプラグイン、hubot-deploy-builderというものを作成しました。 弊社では、以下のようなルールで開発を行っています。 masterにマージが行われたことをトリガーとして本番デプロイが走る masterへのマージは、原則的にdevelopブランチからのみ行われる(developブランチが各開発者の開発したものをマージして、ステージング環境にデプロイしてテストするためのブランチ） デプロイ時に毎回develop => masterへのpull requestを作るのが面倒だったので、chatops化しました。 やってくれること developからmasterへのpull re
Railsでinitializersに書いた内容をdevelopmentモードで再読み込みさせる - Qiita
外部APIに接続するようなクラスの設計 Railsで外部のAPIサービスにつなぐクラスなどを書く際に、将来的にGemにすることを見越してできる限りそのプロジェクト自体に依存しないように設計すると思います。（ここでいう、「依存しない」とは、たとえばそのプロジェクトのSettingsLogicをこのクラスから見に行かないなど。） ここで、外部のAPIが接続時にAPIキーと、トランザクション毎に変わる情報を渡さないといけないとすると、APIキーは一度Railsを立ち上げると変わらないのでクラスに持たせて、トランザクションは引数で渡す、ということをやると思います。 class ExternalServiceAdapter include ActiveSupport::Configurable config_accessor :api_key def create_transaction(trans
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Railsで特定の日の新規ユーザ数などを取るクエリを作る - Qiita