なにがでるか

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

はじめに 2014/11/8に開催された Mashup Battle 2ndSTAGE(MA10) に参加してきました。まなみさんに「ブログ書いてねー☆」とのお言葉をいただいたから、というわけではないですが、自分が参加したMAのイベントの振り返りも交えつつ書きます。 MAには今年初参加という新参者ですが、2ndSTAGEはとにかく楽しいイベントでした。API提供側という立場での参加だったので、今回は気楽なノリで参加したつもりだったのですが、会場に行ってみたら投票権がある、というのは完全に不意打ちでした。（50以上のプレゼン全部見なきゃいけないのかよ！みたいな。すみませんｗ） でも、実際プレゼンが始まると楽しい、楽しい。あっという間の8時間でした。一般参加はできないイベントなので、参加させていただいて本当にありがとうございました。 プレゼン見てみなきゃわからない 今回のイベントに至るまで、多くの作品は事前にある程度オンラインで見て、それぞれの内容をなんとなく把握していたつもりでしたが、作者が自分の言葉で語るアツいプレゼンのインパクトは大きいですね。全然違った見え方をした（そして、本当の意味がようやく理解できた気がした）作品がいくつもありました。 あと、MA関連のハッカソン・アイデアソンに参加した際、一度実際に見ていた作品もいくつかあったわけですが、その多くが新しい機能を追加してきていて、同じ作品のはずなのにこれまた違った見え方ができました。 ちょっと振り返り 今年は、以下の関連イベントに参加しました。 Mashup Hackathon 北陸 in 福井 Mashup Ideathon 福島 in 会津 Mashup Ideathon 東京vol.02 インテル® Edison ボード　ハッカソン東京 Mashup Battle 2ndSTAGE （自分は作る立場ではなかったわけですが）ハッカソンは短い時間でモノを作り上げるあの緊張感とワクワク感がたまりません。個人的には最初に各自が考えたアイデアを他の参加者に（ある意味ドヤ顔で）説明するあの時間帯が一番好きです。 その他感じたこと その他思いつく限りバラバラっと。 2ndSTAGEで、アイデアソン・ハッカソンでお会いした方と再会できて嬉しかった 直接

ちょっと前 に作った 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で動くアプリケーション。こいつ

はじめに reflector.io というサービスを使ってみたのでメモです。 reflector.ioはSendGrid Labsが提供しているWebhookのリクエスト転送サービスです。 他に似たようなサービスを知らなかったので類似サービスとの比較とかできません。 Webhookとは まずは、 Webhook の説明から。 Wikipediaによると、Webhookというのは、WebページやWebアプリケーションがHTTP(s)によりコールバックで通知を行う動作のことを意味するようです。 通常、Web APIは、APIを利用する側がクライアントとなり、GETなりPOSTなりのリクエストを発行してサービスを利用しますが、Webhookはちょうどこれとは逆の動きとなります。つまり、予めコールバックして欲しいURLを登録しておくと、そのサービスで何らかのイベントが発生したタイミングで、そのURLにコールバック（たいてい、POSTリクエストを発行）してくれます。POSTを受け付けるサービスを用意するのは利用者自身という意味で「逆の動き」ということになります。 reflector.ioとは reflector.ioがどういうサービスかは こちらに記載 があります。 冒頭にも述べましたが、一言で表せばWebhookのリクエスト転送サービスです。 「リクエストを転送する」という意味ではHTTPプロキシに近いかもしれません。 特徴的なのが「グループ」という概念と、「パススルー」「フェイルオーバー」という２つの宛先タイプ設定を持つことです。 グループ Webhookを作成すると、配下に複数のグループを定義することができます。グループは、宛先タイプという属性と複数の宛先を持ち、宛先タイプの設定によって、配下の宛先に対するリクエストの転送方法が変わってきます。 宛先タイプ：パススルー 受信したリクエストを複数の宛先に同時に転送します。例えば、一回のリクエストで動作の異なるWebhookを複数動作させたい場合にこちらを利用します。 宛先タイプ：フェイルオーバー 受信したリクエストを複数の宛先のうちもっとも優先度の高い宛先に転送します。耐障害性を目的とする場合に利用します。宛先が一つコケても次に優先度の高い宛先に

はじめに SDK 2.0の情報が出始めたのが2013/11中旬頃、既にPebble熱は冷め、完全にスルーしようと思っていましたが、1月下旬にとあるユーザさんから「Pebble 2.0対応しないの？」みたいなメールをいただき、遅ればせながら対応を開始しました。で、おかげさまで、無事に2.0への対応を完了し、Pebble AppStoreでPublishしましたのでマイグレーションまでの手順をざっくりとメモしときます。ただ、現時点ではまだPebble AppStoreは公開されていません。そのうち、公開されるんじゃないですかね？ SDK 2.0の準備 公式サイトをみてそのままやるだけです。 https://developer.getpebble.com/2/getting-started/ 現時点ではまだPebbleアプリ自体がベータ版なので、上記手順に従ってアップグレードします。たぶん、ハマるところはないと思います。 コードのマイグレーション 今回のSDKのバージョンアップは結構大きな変更を含むので、以下のページにマイグレーション手順がまとめられています。 https://developer.getpebble.com/2/guides/migration-guide.html こちらもそのままやればハマるところはないと思います。 というのは半分正解で半分ウソです。 実際問題、この手順でやればいいのですが、細かく説明されていない箇所もちょくちょくあって、SDK付属のサンプルアプリのコードを見て真似する形で修正しました。あと、コアなAPIのI/Fが結構変わっているので、手順に従って修正していても超不安でした。 Githubにブランチを切ってみましたので、 diff を見てみましょう。 公式マイグレーション手順以外でのポイント 公式のマイグレーション手順に記載されているところはそちらを参照して頂くとして、それ以外でハマった箇所だけピックアップしていきます。 window_set_window_handlers() サンプルコードを見ているとinit()系関数内で以下のような記述がよく出てきます。 いつからこんな書き方をするようになったのかわかりませんが、SDK付属の各サンプルはシレっとこんな書

もう1月も4日となってしまいましたが、昨年の振り返りと今年について書いときます。 Google I/O 2013に行けなかったこと 文字通り完全に全裸待機していたにも関わらずチケットが取れず悲しい思いをしました。 2014年もチャンスがあればトライしてみたいと思います。 SmartTrainingのPebble対応 久々に新しいプラットフォームで遊べた感がありました。2014年もまた新しい何かで遊べるといいなとは思いますが、たぶんそれはモバイル系ではないでしょう。 SendGridチームの一員になったこと 縁あってSendGridチームの一員になれました。これまでのクライアントサイドの立ち位置からサーバサイドもしくはインフラサイドになったことで大きな意識の違いを感じています。技術的にも、仕事の進め方的にも自分にとって新しいことだらけで新鮮です。多くのことを吸収する絶好のタイミングです。 楽しめるだけ楽しんでいこうと思います。 とは言え冬は山に そう言いつつ冬にしか雪は降りません。雪山に開発環境を持ち込んでこんなエントリを書いています。現在は、横で3歳児が昼寝しているので、起きるのを待ちつつPostgreSQLダウンロード中です。起きたらまたスキー滑りに行きます。起きなければherokuとrubyで遊んでみます。こんな状態でもいろいろできるという今の世の中は便利ですね。 パセリ農家の思い 個人的な感触では世の中に出回っているパセリの9割は食べられることなく捨てられています。それでも、パセリは添え物として皿に乗って出てきます。パセリ農家の思いやいかばかりかと、案じていますが、「皿の彩」という位置づけで不動の地位を築いたパセリは現状の立ち位置で満足なのでしょうか。 そんな感じで2014年も行きたいと思います。