なにがでるか

久しぶりにSendGrid kintoneプラグインをバージョンアップしました。使い方については ドキュメント を見ていただくとして、この記事では、ドキュメントに盛り込まなかった裏の仕組みや、今回のバージョンアップ作業に伴い調査したことなどをメモします。 バージョンアップ概要 今回のバージョンアップ内容は以下のとおりです。 Dynamic Transactional Template 文字列置換 if〜else句 イテレータ サンドボックスモード リクエストパラメータ表示 リクエストパラメータのチェック To表示名 対応フィールドの種類拡張 サポート対象ブラウザを明記 Google Chrome Mozzila firefox Dynamic Transactional Template 文字列置換 「文字列置換」はメール本文や件名に宛先（kintoneのレコード）ごとにkintoneフィールドの値を埋め込む機能です。この機能はこれまでサポートしてきたLegacy Transactional Templateでも利用できました。 Dynamic Transactional Templateではこれに加え、「if~else句」と「イテレータ」機能が利用できるようになりました。 if~else句 if~else句はBoolean値により表示を制御する機能です。テンプレートに以下のように記述するとタグ「show」の値に応じて表示を切り替えることができます。 {{if show}} showの値がtrueの場合に表示 {{else}} showの値がfalseの場合に表示 {{#if}} kintoneの場合、（今のところ）Boolean値を返すフィールドは存在しないため、フィールドの値が指定されていない場合に返るnull値をfalse，値が指定されている状態をtrueとして判定する挙動を利用して制御します。より具体的には、 以下の3種類のフィールド が値無指定の場合にnullを返すので、if〜else句の制御に利用できます。 ドロップダウン 日付 時刻 イテレータ イテレータは配列により可変長要素を生成する機能です。テンプレートに以下の...

数日前からSendGridで Activity FeedのBeta版 が公開されたのでざっと触ってみました。今のところ、すべてのアカウントで使えるようになっているわけではなさそうです。 新しいActivityへの切り替え 左メニューから Activity を選択するといきなり Try the Beta の表示が出てきます。ボタンを選択して切り替えていきます。 ちなみに、一度切り替えると、元に戻すメニューは見つかりません。ブラウザを変えると古いActivityに戻るので、ひょっとするとブラウザ側で設定がキャッシュされているのかもしれません。 ※2018/3/11追記 元に戻すメニューが発見されました（ @kikutaro_ さんに教えていただきました）。これは気付かない！ 主な機能 これまでのActivityと比べてパッと見で機能がたくさんありそうです。ざっと見ただけで以下のようなものがありそうです。 検索機能が充実 以前のActivityでは、宛先アドレス/ドメインとイベント種別でしかフィルタできませんでしたが、新しいActivityではとても高度な検索が行えるようになっています。詳しくは後述します。 CSV形式でダウンロード 以前のActivityでは画面に表示されているデータのダウンロードはできませんでしたが、新しいActivityでは画面上に表示されるデータがダウンロードできるようになりました。 イベント単位の表示からメール単位での表示に 以前のActivityではイベント単位で表示されていました。各イベントの紐付けはSMTP-IDを見つつユーザ側で行う必要がありましたが、新しいActivityではメール単位でイベントがまとめて表示されるため、イベントの紐付けを行う必要がなくなり、とても見やすくなりました。これも詳しくは後述します。 配信状態がひと目で分かる 一番知りたい「結局どうなったの？」という情報は配信状態で表されるようになりました。配信状態には「Delivered（届いた）」「Processing（処理中）」「Not Delivered（届かなかった）」の3状態があります。 宛先アドレスと件名がひと目で分かる 以前は宛先アドレスしか確認できませんでしたが、これに加えて件名...

2015/7にSendGridのWebポータルが一新されました。これに合わせて新Webポータルのバックで利用されているWeb API v3も正式リリースっぽくなったみたい（これまでβだったなんて認識はあまりなかったのですが）なので、 sendgrid4r をv1.0.0にして安定版をリリースすることにしました。 v1.0.0は7/18にリリースしてましたが、早く記事書かなきゃと思いつつ時間がとれず、おたおたしていたら、新しいAPIが公開されて、これをサポートしたバージョンを v1.1.0 にしてようやく記事を書くことができました。 振り返ってみると最初にsendgrid4rをリリースしたのが2014/10みたいで、もうそろそろ1年経つようです。時の流れは早いものです。 SendGridでは製品のロードマップはあまり大々的に公開していないようですが、公式ドキュメントには地味に書いてあります。 API Keysをサポートするのが、Web APIのメール送信エンドポイントとWeb API v3のみ Permissionsという機能により、 API Keyで操作可能な機能が定義できる ようになる、らしい 新しい Marketing Campaign機能 とこれに関連して、Web API v3ベースの新しい Contacts API 、 Campaigns API の公開 旧来のAPIは全てWeb API v3で置き換えて整理していくのではないかという雰囲気を感じます。そして、何の前触れも派手なアナウンスもなく、着々と新機能を公開し続けています。うまく動いているものをどんどん置き換えていこうとするモチベーションがどこから湧いて出てくるのかよくわかりませんが、この動きの速さには毎度頭が下がります。 やべー、Permissionsが来る前に早くContacts APIとCampaigns APIに対応しなきゃ。。。

少し前からSendGridのイベントデータの突っ込み先として Azure DocumentDB が使えないか調べていたところ、しばやんさんがこんなツイートしているのを見かけました。たまたまだったのですが、ちょうど突っ込む部分ができたので GitHub に上げておきました。 SendGridのイベントデータはEvent Webhookという機能を使って取得します。全てのイベントデータを自由に扱うために不可欠な重要な機能なのですが、取れるデータがスキーマレスのJSON形式のデータなので、いわゆるRDBに突っ込もうと思うとそれなりにスキーマの調整に手間がかかります。 こういうデータの保存先としては、 MongoDB （特に MongoLab → 最強 ）や Treasure Data なんかが相性がいいわけですが、ちょっと前にAzureでDocumentDBというサービスが追加されたとのこと、ちょっと出遅れた感はありましたが、丁度良い機会だったので試してみました。 DocumentDBのガイドをみると興味深い特徴がいくつもあります。 スキーマレス JSON REST API トランザクション ストアドプロシージャ トリガ SQLクエリ MongoDBっぽい使い方ができて、MongoDBがカバーしていないところをカバーしようとしている雰囲気が伺えます。いかにもMS様っぽい登場のしかたですね。 パッと見、この特徴だけ見るとSendGridのイベントデータをREST APIを使ってそのまま突っ込めばトランザクションも効いてトリガも使えて最強かっ！！と期待したのですが、残念ながらそんなに話はうまくいかなかったので、その辺中心にポイントとなる箇所をまとめてみます。 配列を受け付けてくれないREST API REST API を見て気になったのが、データを生成する際は配列を渡せないこと。 Create a Document では一つずつ渡すインターフェイスなんですね。 SendGrid側は基本的にイベントデータを配列で渡してくるので、REST APIでデータを突っ込もうと思ったらこのAPIを配列長分繰り返し呼ばなくてはいけません。パフォーマンス的に無理があるというのは直感的に想像がつきます。 認証に一手間必要なRES...

はじめに メール関連の仕事をしていると、自分が受け取ったメールがどのサーバ（もしくはサービス）を経由して送られてきたのかがとても気になります。新しいメールが届く度、ヘッダを見ては「あーSESかー」とか「へーMandrillかー」とか「おっSendGrid！」といった感じで本文よりよっぽど楽しい場合もあったりします。でも、毎回生のヘッダを見るのはいい加減面倒になってきたので、もうちょっとマシな方法を考えてみました。 メールヘッダ SMTPというプロトコルはヘッダに経由情報が付加されていくという妙な性質を持っています。こういった振る舞いをするプロトコルって他にあるんですかね？あまり思い当たりません。元々、経由情報は正常にリレーされなかった場合のトラッキングが目的だったりするわけですが、様々な情報が得られるので意外と興味深いものだったりします。 経由情報を可視化する こうした経由情報ですが、正直見やすいものではありません。 Received: from [127.0.0.1] (localhost [54.64.73.243]) by ismtpd-047 (SG) with ESMTP id  14abd28c69e . 67a6 . 2d8d  for @yyyy.jp >; Tue, 06 Jan 2015 02:52:54 +0000 (UTC) この場合、ismtpd-047というホストがlocalhost [54.64.73.243]というホストからESMTP経由でメッセージを受け取ったよ、ということを表しています。 ルール を知っていれば読めるわけですが、実はフォーマットの自由度が高くて、この仕様決めた奴を一発ぶん殴りたくなるくらいフリーダムです。 せっかくこういった情報が公開されているわけなので可視化したら何か見えてこないかなー、と思っていたところ、以前から使ってみたかった Neo4j のことを思いつきました。Neo4jはグラフDBという類のDBで、Webベースの可視化機能も利用できるのでお手軽そうです。 システム構成っぽいやつ 受信したメールのヘッダを解析してNeo4jに突っ込む方法ですが、今回は、メールを受けるのにSendGridのParse Webhookを利用してみました。 普段使って...

smtpapi-ruby に サロゲートペア 対応を入れてみました。 smtpapi-rubyはrubyでSendGridの x-smtpapi ヘッダにセットする値を生成するためのライブラリです。x-smtpapiヘッダの値にはJSON文字列をセットするのですが、非ASCII文字は Unicodeエスケープ する必要があります。で、さらにコードポイント0x10000以降の文字についてはサロゲートペアを使って符号化してあげる必要があります。 今回の対応で、x-smtpapi内（ありがちなのがSubstitutionとかSectionとかで文字を置換するケース）でサロゲートペアが必要な文字が文字化けせずにちゃんとメールが送れるようになったよ、っていうのが今回の記事の内容です。 早速試しに送ってみます。 ゴチャゴチャと読めない部分4文字がサロゲートペアが必要な文字列です。なんて読むのかはわかりませんが。けして文字化けしたわけじゃありません。というわけで Substitutionの値として設定してもちゃんと置換してくれることが確認できました。 各文字のコードポイント　 0x291B0　　　 0x291B1　　　 0x291D3　　　 0x291D4　　　 やり方はわかったので他の言語のライブラリもやってみようかな。はたして使ってくれるが世界で何人いるかわかりませんが。

ちょっと前 に作った SendGrid-Reversi というサンプルアプリにHerokuボタンを付けてみました。 デプロイが簡単に行えて楽しかったのでメモします。 app.json という名前のファイルを 適切なフォーマット で書いてプロジェクトルートに置いときます。そのうえで、README.mdあたりにHerokuボタンを貼り付けておけば準備完了です。 app.json を見ると何となく分かるように、今回はAPP_URLとPARSE_HOSTという2つのパラメータがデプロイ時に必要になります。 また、アドオンとしてmongohqとsendgridをいれてあります。これを入れておくと勝手にアドオンが追加されて環境変数に追加されるアクセス情報を使って各アドオンが利用できるようになります。 この状態で上記リポジトリの README.md 内のHerokuボタンを選択すると次のような画面が表示されます（Herokuアカウント持っていることが前提）。 今回のアプリは、SendGridのParse Webhookを利用します。APP_URLにはWebhookのPOST先URLのルートを指定する必要があります。Herokuの場合、App Nameを指定しないと自動で名前がふられるため、このタイミングではAPP_URLが確定できません。これだと困るので、App Nameを指定した上で、その結果確定するこのアプリケーションURLをAPP_URLに設定するのが一番単純です。（アプリのURLを取得できればこんな冗長なパラメータは不要になるはずですが、取得方法があるのかはわかりませんでした） 例えば、 App Name：abcd APP_URL：abcd.herokuapp.com みたいな感じです。 一方、PARSE_HOSTは、メール受信用のドメインです。手っ取り早く設定するのであれば、 こちら の「5分間アプローチ」を参照します。サブドメインは未使用であればなんでもOKです。 アプリケーション起動時にSendGridとMongoDB周りの設定を自動的に行なうようにしてあるので、細かな設定は一切不要です。 一点注意ですが、内部で使用しているSendGridのEvent Webhookは設定変更後動作が有効になるまでに数分は...

SendGridのWeb API v3が公開されたので sendgrid4r というgemを作ってみました。 sendgrid4rはとりあえずSendGridのWeb API v3”だけ”をサポートしたライブラリです。今後v2をサポートするかどうかはわかりません。 v3はちょっと前に公開されたTemplate Engine APIを含むRESTfulな新しいAPI群です。 v3が出たからといってv2がすぐにdeprecateになるわけではないようです。 というのも、今のところv3は、v2と被る機能（v2を置き換える機能）を提供していません。 現時点で、以下の機能がありますが、今後もどんどん機能が追加されていく雰囲気を感じます。実はここに載っている機能の他にも、一瞬公開されてすぐに非公開にされた機能があります。 公式ドキュメント の更新履歴をよく見るとわかると思います。 Advanced Suppression Manager（ASM） IP Management Enforced TLS(Settings) Template Engine ASMは高度なUnsubscribeリスト機能で（特にマーケティングメール系の）色んな種類のメールの配信停止を個別に制御したい場合に使う機能 IP Managementは送信するメールの種類毎に複数のIPアドレスを駆使して、メールの到達率を可能な限り高めたい場合に使う機能 Enforced TLSは平文でメールが配送される経路を排除する場合に使う機能 Template Engineは複数のテンプレートの管理をデザイナ側に移譲する場合に使う機能 って感じでしょうか。 そういえば一応、今回のsendgrid4rの設計思想的なものをメモしておきます。忘れっぽいので。 今回目指したのは、以下の3点です。 機能追加を簡単に行えるようにしたかった APIのI/Fは全てSendGrid4r::Clientのインスタンスメソッドとして提供したかった ClientインスタンスごとにSendGridの認証情報を分離したかった v3は頻繁に機能追加されることが予想されるため、機能追加を簡単にするため、各サブ機能はmoduleとして実装して、これをClientクラスにincludeすることにしま...

前回 紹介したSendGrid-Reversiで Travis-CI を使った際に気になった箇所のメモを残します。 Travis-CIを使うためにはプロジェクト内に .travis.yml という名前のファイルが必要です。とりあえず、リポジトリトップ下に置いてポチポチ設定すればいいみたいです。 今回はこんな感じにしてみました。 language: ruby rvm: - "2.0.0" # - "2.1.0" env: - RACK_ENV=test services: - mongodb before_script: - bundle install script: - bundle exec rspec それぞれの詳細はTravis-CIの ドキュメント を見ればよいのでポイントだけ。 実行環境のバージョン指定は一つだけにしてみる 実行環境としてRubyを使っており、通常複数バージョン指定できるのですが、今回はバージョンを一つだけ（上の例だと"2.0.0"だけ）に限定してみました。 これは、テストケースでSendGrid APIを使っている関係上、複数環境でテストをするとテストが並列実行されてしまい、SendGridがテストケースの想定していない状態になってしまい失敗（テンプレート削除のテスト中にテンプレート作っちゃったり）するためです。実行環境毎のテストをシーケンシャルに走らせるためのオプションを見つけられなかったのですが、そんなのあるんですかね？ SendGrid環境も分けるようにしないといけないんでしょうか。それはちょっとキツイなー、と。 晒したくない情報は.travis.ymlではなくSettingsを使う 環境変数は「env:」配下に書いておけばよいのですが、パブリックなリポジトリにアップされた .travis.ymlファイルは公開されてしまうため、晒したくない情報（サービスへのログイン情報など）は書けません。 今回、SendGridへのアクセスを行なうテストケースがあったので、そういった情報をどこに置くかが問題となりました。調べてみるとそういう情報は「Settings」に書けってTravis-CIのヘルプに 書いてありました 。Settin...

きっかけ SendGridには多くのAPIがあって、どれをどういう風に使うのかがピンときていませんでした。で、自分含めそんな人向けに、SendGridのAPIをできるだけ多く使ってそれぞれの使い所をイメージしやすいモノを作ってみようと思いできあがったのがこのアプリケーションです。 できること メールを介してオセロができます。 ソースコードは こちら で公開しています。 中で何をやっているか こんな感じで動作します。 0：アプリケーション初回起動時 Web API/Template Engine APIを使ってSendGridの設定を自動的に変更します。設定が自動化されると、設定手順をドキュメント化する手間が減って楽ですよね。 SendGrid上にTemplateを作成します Event Notificationを設定してEvent Webhookを有効化します Parse Webhookを設定、有効化します Click Trackingを有効化します 1：ゲームの開始 Parse Webhook機能に設定したアドレスにメール（件名に相手プレイヤーのアドレスを設定）を送るとSendGridは受信したメールを解析して、Reversi Web AppにPOSTします。POSTを受けたアプリケーションはMongoDB上にゲームデータを生成します。 アプリケーションはSendGrid経由で各プレイヤーにメッセージおよびゲームボードのメールを送ります。 2：クリック ゲームボードのメール上で石を置きたい場所をクリックすると、クリックイベントがSendGridからReversi Web AppにPOSTされます。ここではEvent WebhookとClick Tracking機能を使っています。 クリックイベントはGETでアプリケーションに直接アクセスしても良いのですが、Click Trackingは元URLを隠ぺいするので、今回のアプリではなりすましを防ぐ意味合いがあります。（本当は単に使いたかっただけで、理由は後付です） テキストメール このアプリでは、マルチパートでテキストメールにも対応しています。 対応してみてテキストメール死ねって思いました。 その他 Ruby ...

Rubyの練習用にSendGridの Template Engine API をラップする gem を作ってみました。 Template Engine APIはSendGridが提供するAPIのうち現時点で最も新しいAPIで、JSONベースのRESTfulなWeb APIです。エンドポイントURLを見てわかるように、 https://api.sendgrid.net/v3/resources バージョン3だそうです。今までのAPIはだいたいver2ぐらいでした。これまでのAPIは、基本的にJSONとXML両方をサポートしていましたが、v3以降はJSONのみサポートします。さらばWeb Services、XMLってことなんでしょうね。それでいいと思います。 他に新しい要素としては、 基本認証で認証 HTTPSのみサポート Rate Limitsの導入 Paginationの導入 といったあたりがあげられます。 認証が基本認証になったことで、認証パラメータの扱いが標準的になり、curlとの親和性が高まって扱いが楽になりました。もちろん、標準的なRestクライアントなライブラリでも扱いが楽です。 Rate Limitsは一定時間にリクエストを呼び出せる回数を制限する機能です。応答に、X-RateLimit-*といったヘッダがついてくるので、これを見るとあと何回APIをコールできるのかを知ることができるようです。 Paginationは取得開始位置を指定してレコード取得することができる機能です。大量レコードを扱うAPIで重宝しそうです。現時点で公開されているTemplate Engine APIではサポートされていないようですが。 ドキュメントの内容を眺めていると、今後SendGridのAPIはこのv3ベースに移行していくんじゃないかな、という雰囲気が感じられます。既存のAPIをv3ベースで実装し直すかどうかはわかりませんが、少なくとも今後提供される新しいAPIはv3ベースになるのでしょう。 APIの分量も適度に少なくてラッパ実装の練習用には最適でした。

Twitter眺めてたらこんなのが目に飛び込んできた。 わかる、その気持ち。 でも、自宅PCでメールサーバ立てるのはちょっと面倒だ。ちょうどAzureとSendGridが使えたのでやってみた。ソースは Github に上げてあるので、誰でも今すぐ彼女がいるというステータスを手に入れることができる。 手順 とりあえずSendGridのアカウントを取得する。 次に、AzureでWebサイトを立ち上げて、Githubからデプロイするよう設定する。たぶんこの方法だと、自分が管理しているリポジトリしか指定できないのかな？よくわからないけど。その場合、 リポジトリ をForkしてから指定すればおｋ。 デプロイが終わったらWebサイトの「構成」を開いてアプリケーション設定を行う。 SENDGRID_USERNAME：SendGridのアカウント SENDGRID_PASSWORD：SendGridのパスワード FROM：彼女のメールアドレス。つまり、返信メールのFromに設定したいアドレス。 FROM_NAME：彼女の名前。今回はsayakaちゃんだ。ちなみにここで日本語を指定すると返信メール内の名前が文字化けする。アプリケーションはUTF-8を想定しているので、Webサイトのアプリケーション設定ってUTF-8じゃないのかも？よくわからないけど。 次に、SendGridのダッシュボードにログインして、 Inbound Parse Webhook の設定をしてドメインとURLを対応付ける。 今回は、Hostnameの設定は SendGridブログ にあるbymail.inを使った5分間アプローチを使ってみた。Urlの方はAzure Webサイト上でPOSTの受け口となるURL（http://????.azurewebsites.net/vp）を設定する。 以上で準備完了。 早速、さやかちゃんに確認のメールを送ってみる。 数秒待つと、さやかちゃんが返事をくれた。俺達付き合ってる。 キモいって言うな。 中の話 ちょっとだけ仕組みの話をすると、Githubからデプロイしたのはnode.js向けのWebフレームワークexpress 4で動くアプリケーション。こいつ...

こちらの SendGrid関連のイベント にて、SendGridの方からグサリと刺さる興味深いメッセージを頂いたので全文書きます。 "If you always put limits on everything you do, physical or anything else, it will spread into your work and into your life. There are no limits. There are only plateaus, and you must not stay there, you must go beyond them."     -- Bruce Lee http://www.brucelee.com/ かっこえぇ。。。

はじめに SendGrid Night に参加してきました。 詳しくはこのへんを。 SendGrid Nightやりました LTしてきました SendGrid Parse APIをデモってみる from Wataru Sato Parse APIについては、 宛先アドレスごとにPOST先を振り分けたい アドレスをフィルタしたい（POST側でフィルタしたくない） みたいなFeature requestがありました。確かに欲しいですよね。 今の仕組みはシンプル杉ですから。 Feature requestは受付窓口があるみたいなので、見つけ次第ビシバシ送りつけてやります。 それが使われるサービスになるための道です。 感想的なこと いっぱい人がいました。 既にSendGrid使っている人もいっぱいいました。 日本語サポート、ドキュメントに対する期待の高さも感じることができました。 やりますよ。

前回に引き続き SendGrid についてです。 今回は SMTP API を使ってみました。 SMTP APIについて SendGridのSMTP APIは基本的には普通のSMTPプロトコルに則ったものですが、X-SMTPAPIヘッダというカスタムヘッダを使うことで機能を拡張することができます。 X-SMTPAPIヘッダについて X-SMTPAPIヘッダはSMTPプロトコルの拡張ヘッダです。 X-SMTPAPI: { "category": "newuser" } みたいな感じでJSON形式でパラメータを与えることで機能を拡張します。 Section TagsとSubstitution Tagsについて 今回はSMTP APIで使える機能のうちSection TagsとSubstitution Tagsを使ってみました。 Section TagsとSubsitution Tagsは送信メールの内容を宛先毎に特定の文字列を置換するための機能です。toと合わせて使うことで機能します。 例えば、X-SMTPAPIヘッダの値を以下のような形にします。 { "to": ["test1@xxx.xxx", "test2@yyy.yyy"], "sub": { "-body-": [ "-bodyFemale-", "-bodyMale-" ], "-favorite-": [ "バナナ", "カツオ" ], " "-nickname-": [ "ミキ", "サブロー" ] }, "section": { " "-bodyFemale-": "-nickname-さん！女性向けの商品のご紹介です。", "-bodyMale": "-nickn...

Androidから SendGrid APIを使ってみたのでメモっときます。 SendGrid について PaaS/SaaSの一種でEメールを扱うサービスです。SMTPによるメール配信サービス、受信メールをトリガとした処理の駆動、扱ったメールの統計・統計結果表示、マーケティングメールの配信管理などの機能があります。 今回やったこと SendGridが提供するWeb APIとSMTP APIをAndroidアプリから行ってみました。やった内容としては、 JavaでSendGridを利用したメール送信 と同じです。 要は、 ・JavaMailを使ってSMTP APIを利用。 ・ sendgrid4j を使って基本的なWeb APIを利用。 と、これだけです。 具体的には、 JavaでSendGridを利用したメール送信 と同じなのでそちらを参照していただければと思います。以上でした。 で、終わってしまうのはアレなので普通のJavaと違った点のみ絞って書きます。 ソース とりあえず、 この辺 に置いときます。 尚、動かす場合、HelloSendGrid.java内のSMTP_AUTH_U SER、SMTP_AUTH_PWD、SENDER_ADDRESS、RECIPIENT_ADDRESSあたりをそれぞれ置き換えます。 依存関係 こんな感じ。合計約1.5MB。2,3年前だったらデカめな印象でしたがイマドキ特にデカくはないですよね。 Java環境との違い いずれもSendGridを使うための特別な事項はありません。ただ、ちょっとだけ事情が異なる点だけ。 Oracle提供のJavaMailは使えない AndroidではOracle提供のいわゆる JavaMailは使えません 。理由は、awtに依存しているためです。そういうわけで、 javamail-android を使います。基本的に両者のI/Fは同じみたいなのでjarファイルを入れ替えてあげるだけで動きました。 認証情報の扱いに注意が必要 今回のサンプルアプリケーションでは、SendGridの認証情報をコードの中に埋め込みましたが、一般に公開するAndroidアプリでこれをやるとSendGridの認証情報が...