読者です 読者をやめる 読者になる 読者になる

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]

StripeObject について

最近お仕事で決済サービスの Stripe を使っているので色々メモする。
溜まったらまとめて Qiita に記事にするかな。

Ruby で Stripe の API を叩くと StripeObject が返ってくる。StripeObject のドキュメントは
http://www.rubydoc.info/github/stripe/stripe-ruby/Stripe/StripeObject ここにあって、内部に Set を持っていて key value を管理している様子。
この StripeObject は Hash っぽいけど Hash じゃないので稀にハマる。
以下の点が気になる

続きを読む