なにがでるか

この記事は、 「MashupAwards2018 Advent Calendar 2018」9日目のエントリー です。 はじめに ここのところ、加齢のせいか記憶力の低下が著しく、前日の夕食に何を食べたかすら思い出せないことがままあります。先日も、MashupAwards2018 オレトクヒーロー部門 決勝審査会で発表するという貴重な機会を得たのですが、この時の感動や記憶も時間の経過とともに薄れていくんだろうなと悲しい気持ちになりました。そこで、記憶が新しいうちに記録しておき、いつか振り返りができるようにしておこうと思います。 ぺぺぺルーレット 今回、オレトクヒーロー部門の決勝審査会で発表したのは「 ぺぺぺルーレット 」。「パパパルーレット」の後継の座を狙ったサービスです。ぺぺぺルーレットについては、資料を見ていただくとして、本記事では決勝審査会に出てみて感じたことを中心に書いてみたいと思います。 ピンチ、決勝審査会に参加できない？ いきなりですが、決勝審査会の日はたまたま嫁さんが外出の予定で、子供の面倒を観ないといけない日でした。事前に子供に一緒に行くか打診したところ「遊びに行きたいから絶対にヤダ」とのこと。参加する前からいきなりのピンチです。 子供を説得する 子供にゴネられてしまってはどうにもなりません。そこで、考えたのが「もし優勝できたら賞金10万円のうち3万円をお前にやろう」という条件。この条件変更が功を奏し、彼は鋼より固い信念を曲げ決勝審査会についてきてくれることになりました。実はこの「3万円」は戦略的な金額設定で、彼が欲しがっている任天堂スイッチを黙示したものでした。無邪気に3万円ゲットを楽しみにしている彼の姿に軽い罪悪感を覚えつつ（ウソはついてませんよ）会場に到着しました。 オシャレなヴァル研究所さんのエントランス オレトク感がハンパない オレトクヒーロー決勝審査会に選ばれた作品は こちら 。事前にProtoPedia上で各作品をチェックしていたのですが、実際にモノを見てはじめて各作品のオレトク感のハンパなさを実感しました。テキストや動画だけでは伝わらない情報が多すぎるのです。チョコボールの数を自動で数えたり、チューしたり、先端に行ったり。特に印象が強かったのはしゃべる人工苔とウダ...

数日前から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状態があります。 宛先アドレスと件名がひと目で分かる 以前は宛先アドレスしか確認できませんでしたが、これに加えて件名...

先日、SendGridのドキュメントに新しいAPIドキュメントが追加されました。元々、APIリファレンスに相当するドキュメントは存在していたのですが、 StopLight というサービスの機能を使ってより使いやすく整理した、といったところでしょうか。 入り口 新しいドキュメントの入り口はちょっとわかりづらくて、 ドキュメントのトップページ 上にある「 SendGrid API 」というリンクです。 主な特徴 次に、この新しいAPIドキュメントの特徴をまとめてみます。 リクエストとレスポンスがちゃんと定義された 今まで定義されてなかったのかよ、って感じですが、 これまで はリクエストについては概ね定義されていましたが、レスポンスはほとんど定義されていませんでした。レスポンスの例は載っていたので特に不都合はなかったのですが、ちゃんとした定義があるに越したことはありませんね。 Swagger(OAS)/RAMLによる定義が公開された StopLightの機能の一つですが、APIの定義全体がSwagger形式とRAML形式で公開されています。これがあると、 SendGridのAPIサーバのモックを作ってテストに利用 するといったことができるようになります。 APIドキュメントからリクエストのテストができるようになった これもStopLightの機能の一つのようですが、各エンドポイントのページの「 Try it out 」タブを選択するとドキュメントからAPIのリクエストを送信して結果確認ができます。使い方はとても簡単で、必要なパーミッションを持ったAPIキーをYOUR_API_KEYパラメータに設定、リクエストJSONをBodyに指定して「 SEND REQUEST 」ボタンを選択するだけです。 コード生成ができるようになった 「 Try it out 」でリクエストを送信すると、代表的な言語のコード生成ができるようになります。「 Code Generation 」から一通りのプログラミング言語およびコマンドのサンプルコードが確認できるので、サッとコピペして使えます。 PostmanにSwaggerの定義ファイルを喰わせてみる Swaggerの定義 が公...

はじめに 10日ほど前の話になりますが、 sendgrid-kintone-plugin というkintoneからSendGrid経由でメールを一斉送信するプラグインを更新しました。最近物忘れがひどいので、やったことをまとめておこうと思います。 基本事項 このプラグインは、kintone上に保存したDBを宛先リストに見立てて、SendGrid経由で一斉配信する、というコンセプトで作られています。一覧画面に表示されたものが送信対象となり、送信するメールの内容はSendGridのテンプレート機能で管理します。フィルタを適用することで宛先リストの絞り込みもできます。 更新内容 今回更新したバージョンは「バージョン4」となります。ユーザ視点からすると大きな変化はありませんが、実はほぼ全面実装し直しています。一応、変更点は Change Log にまとめてありますが、たぶんわかりづらいので個別に説明します。 宛先フィールドに必須項目、値の重複を禁止の制限を加えました 宛先として指定可能なフィールドに「 必須項目にする 」と「 値の重複を禁止する 」の条件を追加しました。これまではこのような制限は明確には課していませんでしたが、SendGridのAPIの制約上、宛先フィールドは指定が必須で、ユニークである必要があるので、これに合わせてkintone側にも同じ条件を強制するようにしました。プラグインを新しいものに更新すると、 この設定がないフィールドは 宛先用フィールドとして選択できなくなっているので、フィールドの設定を変更する必要があります。 新デザイン対応 kintoneの新デザイン にプラグインのデザインを合わせました。機能的には変更はありません。ボタンやドロップダウンがそれっぽい表示になりました。ついでにテンプレートの編集画面にも飛べるようリンクをはりました。 新SendGridロゴ SendGridのロゴ を新しいものに差し替えました。 送信者名の指定が可能に 送信者名の指定に対応しました。 From: 送信者たろう＜hoge@example.com＞ みたいなメールが送れるようになりました。 Web API v3のメール送信用エンドポイント...

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に対応しなきゃ。。。

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...