Riot API を使った League of Legends ウェブアプリを公開するまで

League of Legends のウェブアプリを作ったので、その手順を書いてみます。

Riot APIについて

Riot Developer Portal
こちらからサインインすることで、だれでも開発用の API を使うことができます
f:id:ororog:20180213212841p:plain
しかし、開発用の API は次のような制限があります。

  • リクエストに制限がある (20 requests every 1 seconds, 100 requests every 2 minutes)
  • 有効期限(一日)がある
  • 開発用 API を使ったサービスを公開してはいけない

このため、開発用 API ではサービスを公開できません。Riot に申請する必要があります。

API の種類

前述の開発用 API (development API) の他に、Personal API と Production API があります。それぞれ次のような特徴があります。

Personal API

  • リクエストの制限は開発用 API と同じ
  • 有効期限がない
  • 申請が通るまで早い(2, 3日?)
  • アプリケーションが無くても申請可能
  • Personal API を使ったサービスを公開してはいけない

Production API

  • 制限が大幅に緩和される (RATE Limiting)
  • 有効期限がない
  • 申請が通るまで早くて2週間程度必要(体験談)
  • 申請にはアプリケーション URL が必要

個人で楽しむには Personal API でいいのですが、公開するにはやはり Production API が必要です。以下では、Production API を公開するまでの道のりを紹介します。

申請の準備

開発用APIでアプリを作る

どの程度のアプリで申請が通るのかわかりませんが、まずはアプリを作りましょう。開発用 API を使うと毎日更新が必要なことだけ注意しましょう。
開発効率をあげるために、Personal APIをとりあえず申請するのもありです。API を更新する手間が減ります。

ポリシーを理解する

GENERAL POLICIES を熟読しましょう。日本語はたぶんないです。日本 Riot が仕事してくれることを期待しましょう。違法なことはしない、APIキーをもらさない等が書いてあります。

申請する

いよいよ申請です。右上の REGISTER PROJECT から申請します。
f:id:ororog:20180219215621p:plain
次に、PRODUCTION APPLICATION を選択します。規約に同意し、アプリケーションを登録します。以下は、必要な項目です。

  • Project Name

いい名前を付けましょう

  • Project Description

プロジェクトの説明をします。こちら、たぶん日本語は不可です。
アプリのチェックする人が読むものなので、説明はなるべく詳細に書きます。
必要なら使い方も書いたほうが良いと思います。私は説明が足りず理解できなかったのか、アプリが完成していないとしてリジェクトされてしまいました。

  • Project Group

謎です。最初から値が入っているのでそのままにしました。

  • Project URL

実際に動いているアプリの URL を指定します。

登録時に、riot.txt をアップロードして、Riot からアクセスできるようにする必要があります。

結果を待つ

Pending

まずは承認待ち状態です。私は2週間ぐらいで最初の返信が来ました。

Approved

おめでとうございます。あなたのアプリを公開しましょう。

Rejected

私は最初にリジェクトされてしましました。アプリケーションのページのメッセージを見ることで、理由を確認できます。
f:id:ororog:20180219220827p:plain
私の場合、アプリケーションが動いていないと指摘を受けました。既に動いているはずなので、以下の情報をメッセージに追加しました。

  • 日本のデータにしか対応していない
  • 使い方の詳細

メッセージを追加して待つこと4日、無事承認されました。

情報源

基本的に英語ですが、困った場合は次のリンクを参考にしてみてください

リジェクトされた時、似たような人がいないか参考にしました。

作成したアプリはこちらです。 Target Bang!
アプリの紹介はまたの機会にさせていただきます。
皆様もアプリを作ってみてください。

仮想通貨で有り金全部溶かした人の顔BOT

仮想通貨で有り金全部とかした人の顔がみたいー、あびゃ〜

そんな純粋な子のためにボットをつくりました。

twitter.com

動機

仮想通貨暴落したら面白いなーと思ってる自分に気づいてしまったので…

中身

python3 で SqlAlchemy を使って作っています。コードはこちら。
github.com
images 以下にある画像をランダムに表示します。

仮想通貨の価格の取得には CoinMarketCap の API を使用しました。
coinmarketcap.com

登録不要で以下のように基本的な情報はとれたので便利です
https://api.coinmarketcap.com/v1/ticker/?convert=JPY
JPY に変換できるの今気づきました :)

通知のタイミングは、6時間以内に20%下落したらに設定しています。alt coin が多すぎて、下落したことがわかっても何の感想も得られないです。フォローはおすすめしません。

Rebase and merge 運用で merged な branch 一覧を表示する

Rebase and merge な運用でもマージ済みブランチを表示、削除するためのスクリプトを書いた。

仕事では github で PR をマージする時、Rebase and merge でマージしている。
Rebase and merge の良し悪しはさておき、Rebase and merge だとコミットのハッシュ値が変わってしまうため、git branch --merged などでマージしたものを表示できないのが不便。マージのたびにブランチを削除すればいいのだけど、ズボラなので気づいたら溜まってしまう。めんどくさいのでスクリプトを書いた。

list-merged-branch/list-merged-branch.sh at master · ororog/list-merged-branch · GitHub

適当な場所において list-meged-branch.sh を実行すればマージ済みのブランチが表示するので、あとは list-merged-branch.sh | xargs git branch -D とかで削除してやればよい。

中でやっていることは、Rebase and merge をしてもコミットの日時は変わらないため、master のログに、ブランチのハッシュ値を除いた部分が含まれているかどうかを見ているだけ。さすがにコミット日時とメッセージまで一致するコミットは無いだろうという考え。
個人的に便利になったのでうれしい。

Stripe の description と metadata

Stripe のオブジェクトの中になんらかのデータを保存したい時がある。たとえば顧客の情報だったり、支払いの補足情報だったり。会社名などを保存しておくと、ダッシュボードから検索できて便利。そんな時にデータを保存するフィールドとして、 description と metadata の2つの選択肢がある。どれを使うべきか?

結論として

metadata を使ったほうがよさそう

それぞれの特徴を列挙すると

description
  • 一部のオブジェクトだけ持っている (customer, invoice item, transfer など)
  • customer.description はダッシュボードで閲覧できるだけだが、invoice item.description は請求書に表示されるなど、公開範囲がわかりづらい。

description についての細かい説明は API の create のところに書いてある。たとえば、incoiceitem の description は
Stripe API Reference

An arbitrary string which you can attach to the invoice item. The description is displayed in the invoice for easy tracking. This will be unset if you POST an empty value.

と、請求書に表示されることが書いてある。一方で、customer の説明では
Stripe API Reference

An arbitrary string that you can attach to a customer object. It is displayed alongside the customer in the dashboard. This will be unset if you POST an empty value.

と、ダッシュボードがに表示されることが書いてある。

metadata

詳細は Stripe API Reference

  • 更新可能な Stripe のオブジェクトはほとんど metadata を持つことができる (Account, Charge, Customer, Refund, Subscription, and Transfer)
  • 各オブジェクトは20個のキーバリューペアを保存できる
  • Stripe によって metadata が参照されることはないし、顧客に見られることもない

metadata は顧客に表示されないことが明確で、各オブジェクトによって使われ方が共通である。description はその点ちょっとわかりにくい。これなら何か追加データを保存するのであれば、metadata を使ったほうが良さそう。

おまけ

Stripe API のドキュメントを読み直したら、customer.description の説明が正確になっていた。以前は description may be seen by users だった気がするけど、現在はダッシュボードに表示されると明確に書いてある。Stripe はプログラマに優しいのが良いところ。

Stripe API の IP アドレスとメーリングリスト

Stripe の API サーバーや webhook で使用されるリクエストの送信元はちゃんと定義されている

stripe.com

セキュリティを高めるのであれば、IP による制限を取り入れるのも大事
これらの IP アドレス情報の更新などはメーリングリストで通知されている

groups.google.com

Stripe を使った決済システム開発者なら入っておいたほうが良いだろう

Stripe の webhook でできること

Stripe は webhook を使うことで、イベントの通知を受け取ることができる。

stripe.com

Stripe のような外部のサービスを使うと、アプリケーションの外からの操作によってアプリケーションの状態が変わってしまうことがある。webhook を使うことで、アプリケーション状態を変える外からの操作を知ることができる。

続きを読む

StripeObject その2

前回の補足。

key があるかどうかで to_h するのはどうなの?と言われて keys.include? を同僚から提案いただいた。たしかに。
あいかわらず key は symbol になってるのでその点注意。

pry(main)> s = Stripe::StripeObject.construct_from({id: 1, 'foo' => 'bar'})
=> #<Stripe::StripeObject:0x3ffd9cecf14c id=1> JSON: {
  "id": 1,
  "foo": "bar"
}
pry(main)> s.keys
=> [:id, :foo]