なにがでるか

2014年末から2015年頭くらいにかけてNeo4jで 遊んでいました 。当時のバージョンが2.1.6くらいだったと思うのですが、それから数ヶ月経って、気付いたら最新版は2.3.0-M01ということで、意外とリリースのペースが速いことに気付きました。 というわけで、キャッチアップのために最近（2.1.6〜2.2.1）の リリースノート を日本語訳して理解した気になろうと思います。 言うまでもありませんが、この翻訳は私自身のメモのために作成したものです。校正、確認などを行なっていないのと、そもそも意味がわからず訳している部分も多数あるので、誤っている可能性が十二分にあります。というか、むしろ全部誤っているものと考えて、必ず原文で確認を取るようにしてください。 Neo4j 2.1.6 （2014/11/25） IOエラーが常に正しく扱われておらず、発生した変更のフラッシュに失敗することでデータベース内での矛盾が発生することによる致命的な異常終了の問題の解決 Luceneベースのインデクスが要求するファイルハンドルをかなり小さくした ストアの矛盾を報告しない可能性のある矛盾チェックの問題の解決 ノードの次数を簡単に得ることを可能にするJava API拡張（タイプと方向によるリレーションシップのカウント） ノードをトラバーサルするリレーションシップのロードに影響を与える重大なパフォーマンス劣化の解決 クラスタ環境においてバックアップストアを正常に読み込めないことがある問題の解決（Neo4j Enterprise） スレーブの機能停止後、マスターに切戻しする際に失敗することがある問題の解決（Neo4j Enterprise） Neo4j 2.1.7 （2015/02/03） リレーションシップグループストアメモリマッピング（neostore.relationshipgroupstore.db.mapped_memory）の標準設定を10Mから0に変更。これにより、かなりパフォーマンスが改善される。 予期しない異常終了後のリカバリ中に過度のメモリを使用する問題の解決 スキーマ制約の強制を改善。いくつかのレアケースの競合状態を解消 バッチインポーターがスキーマ制約を正しく適用することを確認 shortestPathを使用するい...

少し前から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　　　 やり方はわかったので他の言語のライブラリもやってみようかな。はたして使ってくれるが世界で何人いるかわかりませんが。

はじめに 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することにしま...