くらしのマーケット開発ブログ

「くらしのマーケット」を運営する、みんなのマーケット株式会社のテックブログ。積極採用中です。

Stripe Connect Expressの利用事例を発表しました

くらしのマーケット Stripe Connect Express 利用事例

こんにちは。みんなのマーケットでCTOをしている戸澤です。

くらしのマーケットでは2020年8月に初の決済機能である、オンラインカード決済機能をリリースしています。 オンラインカード決済機能の実装では決済代行としてStripe社のConnectを使用しています。 Connectはくらしのマーケットのような、売り手、買い手、プラットフォーマーの3者がいるマーケットプレイス向けのプロダクトです。

今回、Stripeのユーザーコミュニティである、JP_Stripesさんよりお誘いいただき、 くらしのマーケットでのConnectの選定の背景、リリースの運用面についてお話させていだきました。

発表資料

関連記事

オンラインカード決済の開発に関する過去記事もありますので、ぜひご覧ください。

tech.curama.jp

tech.curama.jp

ヤッホー!シワちゃんだよーん

f:id:curama-tech:20210218182038p:plain

こんにちは、バックエンドエンジニアのキダです。 先日くらしのマーケットでSign In With Apple(SIWA)対応のリリースをしました! SIWA対応でハマった点などを紹介いたしますので、興味がある方は参考にしてください。

背景

AppleのポリシーによりApple IDでログインできるソーシャルログイン機能のSign In With Apple(SIWA)は2020年7月より対応必須となりました。 ※ 元々は2020年4月からとなっていましたが、コロナウィルスの影響もあり延期されていました

対応必須の詳細は以下になります。

  • ソーシャルログイン機能持つアプリはSIWAの対応が必要
  • 対応してない場合、Appleのアプリの審査が通らない(新しいバージョンのアプリをリリースできない)

くらしのマーケットは店舗向けアプリと、ユーザー向けアプリが存在します。 ユーザー向けアプリは『Yahooログイン』『LINEログイン』を対応しているので、SIWAの対応が必須になっていました。 ユーザー向けアプリはAndroid、iOS共にWebViewで作成されていて、アプリネイティブの機能以外は全てWeb側で実装されています。その為それほど優先度は上がっていなかったのですが、iOSユーザー向けアプリにマージ済みでリリースできていない機能が溜まってきた為、2021年1月より対応を進めていました。

SIWAの特殊なところ

さて、そろそろ本題に入ります。 SIWAが他のソーシャルログイン機能と比較して異なる点を箇条書きにしてみます。

  1. iOS端末(mac, iPhone)のSafariでは独自のサインインUIが利用可能で端末にログイン済みのApple IDで簡単にSIWAでの認証が可能(touch ID, face ID利用可)
  2. メールアドレス、ユーザー名を連携するためにはコールバックエンドポイントをPOSTで実装する必要がある
  3. 利用者はメールアドレスの匿名化オプションと、転送停止設定が可能

1.はとても便利な機能なのですが、2,3は開発する際に考慮する必要があり、主にこの点でハマったので詳細を説明します。 この点はdev.toの記事がとても参考になったので、合わせて確認いただけるとよいと思います。

なおAppleのデータ、デザインに関するガイドラインは以下になるので、こちらもご一読する事をお勧めします。

https://developer.apple.com/design/human-interface-guidelines/sign-in-with-apple/overview/data-management/

https://developer.apple.com/design/human-interface-guidelines/sign-in-with-apple/overview/buttons/

メールアドレス、ユーザー名を連携するためにはコールバックエンドポイントをPOSTで実装する必要がある

例えばYahooやLINEログインは以下のようなフローで Authorization CodeのOAtuh2認証がされています。

  1. ログインボタンをログインや会員登録やアカウント連携ページに配置(/login, /regist, /connect のようなURL)
  2. ボタンを押すと、それぞれのソーシャルアカウントでの認証処理を実行
  3. 認証完了後に、元のページに code, state のパラメータをクエリストリングに付与してリダイレクト
  4. 元ページではcodeの内容を検証して、問題なければ認証完了として、ログインや会員登録が完了

ここの3でのリダイレクト処理はGETでリクエストされます。

さて、SIWAではどうなっているでしょうか。 まずSIWAでの1のボタンに設定するURLは以下のように設定可能です。

https://appleid.apple.com/auth/authorize?response_type=code&scope=email&response_mode=form_post&client_id={{ clientId }}&redirect_uri={{ redirectUrl }}&state={{ state }}&nonce={{ csrfToken }}

それぞれパラメータは以下のようになります。

パラメータ 用途 設定例
response_type Authorizationフロー code(id_tokenも可)
scope 連携するユーザー情報 emailとname
response_mode リダイレクト方法 form_post, query, fragment
client_id Appleで登録する識別子  
redirect_uri リダイレクトURL  https://example.com/login
state リダイレクト先で検証可能なcsrfTokenなど 自由に設定可能
nonce リダイレクト先で検証可能なcsrfTokenなど 自由に設定可能

ユーザー情報を連携するためにはresponse_modeform_postに指定する必要があり、GETで戻す前提の作りになっていたため、リダイレクト先でPOSTを受け取れるように修正する必要がありました。 くらしのマーケットでは先の/login, /regist, /connectのようなページは元々GET,POST存在していましたが、既存の仕組みではcsrfTokenのチェックでリダイレクト時にエラーが出てしまいました。

■ 対応策

こちらの問題の対応として、Appleからリダイレクトする専用のエンドポイントを作って対応しました。

以下のようなredirect_uriを設定して、動作します。

https://example.com/redirect/?/login

  1. ログインボタンをログインや会員登録やアカウント連携ページに配置(/login, /regist, /connect のようなURL)
  2. ボタンを押すと、それぞれのソーシャルアカウントでの認証処理を実行
  3. 認証完了後に、/redirectページに code, stateのパラメータをクエリストリングに付与してリダイレクト
  4. /redirectページで、stateの値を用いてセッションに保持したcsrfTokenチェックをして、問題無ければ元ページにGETでリダイレクト
  5. 元ページではcodeの内容を検証して、問題なければ認証完了として、ログインや会員登録が完了

/redirectを挟む事で元のエンドポイントでの修正を抑えて実装することが可能でした。 これにて一件落着に見えたのですが、もう一つPOSTに起因する問題がありました。

samesite cookieの対応

Google Chromeではこの認証フロー中にapple側の認証前(1.の状態)、apple認証後(4.の状態)でセッションが変わってしまう問題が出る事に気付きました。 具体的にどういうことかというと、セッション情報はcookieに保持していて、長期間同一のセッションとして管理されています。 Google Chromeでは2020年ごろからデフォルトのcookieプロパティがLaxになっており、今回POSTでリダイレクトする際にこのセッション情報を管理するcookieが失われてしまうといった問題が出ました。

こちらの問題は前段で上げたdev.toの記事に紹介されている、リダイレクト先のscopeで有効なsamesite="none"のcookieを短時間で設定する方法で回避ができました。

ちなみにユーザー情報を連携しない場合はGETでリダイレクトすることが可能な為、上記のような対応で懸念点がある場合にはGETで実装することも可能です。他のサイトも参考に見てみましたが、GETで実装されているサイトが多い印象です。

利用者はメールアドレスの匿名化オプションと、転送停止設定が可能

もう一つ特徴的な機能がメールアドレスの匿名化になります。 エンドユーザーとしては、メールアドレスの流出を防いだり、メールマガジンなどの配信停止を利用するサイトにアクセスする必要無く対応できる点で、とても良い機能に見えました。

以下のような画面で非公開設定が可能で、匿名化されたメールアドレスは以下のような形式になります。

<ランダムな文字列>@privaterelay.appleid.com

f:id:curama-tech:20210218182141p:plain

運用する側では以下のような対応をする必要があります。

  1. Appleサイトにて送信元メールアドレスとドメインを登録
  2. 配信停止から配信再開になった場合を考慮して定期的なbounceリストの削除

2.について少し説明します。 くらしのマーケットではメール送信にSendGridを利用しているのですが、以下の操作をした後にメールを送信し配信に失敗した場合bounceリストに入ってしまいます。

  • AppleIDのサイトからメールの転送を無効化
  • AppleIDのサイトからアカウント連携を削除

f:id:curama-tech:20210218182218p:plain

まだ本番ではbounceは発生していないですが、QAテスト時には同じAppleアカウントの連携を削除して、くらしのマーケットのアカウントを削除して、また新しくアカウントを作成してテストなどをしていたので、メールが届かないなどの問題がありました。 こちらはbounceリストから該当のメールアドレスを削除することで対応が可能でした。

最後に

色々とハマりどころがあったのですが、なんとか対応できました。 iOSユーザーにとってはとても良い機能だと思いますので、是非使ってくださいね!

くらしのマーケット開発職向けの会社紹介資料を公開します!

みんなのマーケット 開発職向け 会社紹介資料を公開します

こんにちは。みんなのマーケットでCTOをしている戸澤です。

みんなのマーケットでは採用を強化しており、 2020年11月から2021年2月の4ヶ月間で、開発メンバーだけでも18名が入社しています。

カジュアル面談や面接をしてきた中で、「当社が何を考えていて」、「今どんな状態で」、「これから何をするのか」が候補者に知られていないことに気が付きました。

そこでカジュアル面談や面接の中でお話している内容に加え、技術やプロダクト、働き方などの5つの項目をスライドにまとめて、公開します!

主な内容

  • くらしのマーケット について
  • 開発体制と技術スタック
  • プロダクトでこれから目指すもの
  • フルリモートワークでの働き方
  • 評価制度と報酬

内容はくらしのマーケットの開発職であるエンジニア、プロダクトマネージャー(PM)、UI/UXデザイナー、QAに特化しています。

このスライドは今後も定期的に加筆、更新していく予定です。

会社紹介資料

全職種で積極採用中!

ご興味のある方は以下リンクより応募ください。カジュアル面談も歓迎です。 https://www.minma.jp/recruit

全員で会議できる時間をいもす法で探そう

こんにちは。SRE / バックエンドエンジニアのマノメです。

前回の記事 を読んで、以前私が思いつきで作った、「全員で会議できる時間はいつか?」を調べるコードを書いたことを思い出しました。
どういうものかというと、チームメンバーの数日間の出勤記録をもとに全員が揃っている時間を割り出す、という至ってシンプルなものです。

弊社では現在、コアタイムなしのフレックスタイム制で、多くのメンバーがフルリモート出勤です。
会議をしたい!となったらもちろん、開始時間を決めてその時間に出勤するようにするべきなのですが、とはいえ生活時間を急に変えるというのは朝が弱い私のような人間にとってはなかなか大変です。
なので、チームメンバーが全員揃う時間帯を割り出して会議を設置すれば、そういった杞憂をせず済むと考えたわけです。
特にチームの再編を行った際は、このデータが参考になるのではないでしょうか。
そういった私の思いつきでコードを書いたものの、そのときにはすでにチームができて数ヶ月経って会議時間も決まっていたため、誰にも披露することなくお蔵入りになりました。

今回は、このとき作ったコードを元に、累積和のアルゴリズムのことをちょっとだけ話そうと思います。

作ったもの

Go で書いています。
余談ですが、くらしのマーケットでは一部で Go が使われている箇所があります。

用意したデータ

A 〜 D の 4 人の出勤記録をテキストに書き起こします。
※記事のために適当な値を作っています

# A
08:54-17:24
09:42-17:37
09:39-18:24
10:46-19:33
# B
10:23-20:32
10:16-18:28
10:28-19:42
10:45-19:36
# C
10:08-18:32
10:07-19:48
10:00-19:49
10:11-19:27
# D
11:14-21:00
11:02-20:47
11:47-21:19
10:59-21:04

書いたコード

func main() {
    // データを読み込んでいい感じにする
    // [[As_start_time, As_end_time], [Bs_start_time, Bs_end_time], ...]
    input := read()

    data := make([]int, 60*24)
    for _, i := range input {
        // i[0] が 出勤時間, i[1] が 退勤時間
        data[i[0]] += 1
        data[i[1]] -= 1
    }

    // 必ず全員いる時間 = データの数
    max := len(input)

    // 全員いる時間を探す
    cur := 0
    isMax := false
    start, end := 0, 0
    for index, d := range data {
        cur += d
        // 全員が揃った時間の記録
        if !isMax && cur == max {
            start = index
            isMax = true
        }
        // 全員が揃っていた最後の時間の記録
        if isMax && cur == max-1 {
            end = index - 1
            isMax = false
        }
    }

    fmt.Printf("%d:%d - %d:%d\n", start/60, start%60, end/60, end%60)
}

結果

与えられたデータより、11:47 - 17:23 が適切な会議の設定時間となります。

解説

さて、アルゴリズムについての話ですが、今回使ったのは いもす法 という素晴らしいアルゴリズムです。
これは、累積和を用いて複数の要素の重なりや深さなどを計算するものです。

例えば以下のような出勤表があるとします。

f:id:curama-tech:20210122132636p:plain
出勤時間のグラフ

これをもとに、愚直に累積和のデータを作るならこうなるでしょう。

08:00 09:00 10:00 11:00 ~ 17:00 18:00 19:00
A 0 0 1 1 1 1 1
B 0 1 1 1 1 0 0
C 0 0 0 1 1 1 0
合計 0 1 2 3 3 2 1

この「合計」の配列を用意して計算することになります。
ただ、プロットするのに以下のような処理が必要です。

input := read()
data := make([]int, 60*24)

// データのプロット
for _, i := range input {
    // i[0] が 出勤時間, i[1] が 退勤時間
    // 1 つのデータに対して、該当範囲を"塗りつぶす"イメージ
    for k := i[0]; k < i[1]; k++ {
        data[k]++
    }
}

max := len(input)

// シミュレート
start, end := 0, 0
isMax := false
for index, d := range data {
    // 全員が揃った時間の記録
    if !isMax && d == max {
        start = index
        isMax = true
    }
    // 全員が揃っていた最後の時間の記録
    if isMax && d == max-1 {
        end = index - 1
        isMax = false
    }
}

これは、人数(N) と 時間範囲(T) に対して、データのプロットに必要な計算量は O(N*T) 、シミュレートに必要な計算量は O(T) となり、合計で O(N*T + T) となります。

さて、いもす法を用いると、かなりシンプルに、計算量も抑えられます。
データの作り方が肝で、「出勤したら+1、退勤したら-1 する」という方法を取ります。

08:00 09:00 10:00 11:00 ~ 18:00 19:00 20:00
A 0 0 +1 0 0 0 -1
B 0 +1 0 0 0 -1 0
C 0 0 0 +1 0 -1 0

よって、データのプロットは最初に書いたコードの通り、

for _, i := range input {
    // i[0] が 出勤時間, i[1] が 退勤時間
    data[i[0]] += 1
    data[i[1]] -= 1
}

となります。
この場合、データのプロットに必要な計算量は O(N) 、シミュレートに必要な計算量は O(T) となり、合計で O(N+T) となります。
処理がシンプルになり、計算量もかなり減ります。

これなら、人数が大幅に増えても計算量が大きくなりすぎないですね。

さいごに

結局、いもす法を使って作った「全員で会議できる時間を探す」というコード自体は、実用性があるのかないのかよくわからない結果になりましたが、いもす法は実際のデータ分析においてとても役に立つと思います。
例えばこのご時世ですから、部屋の中に一定以上の人数がいる時間帯を調べて換気の強さを調整するというのができそうですね。
くらしのマーケットでいうなら、登録している出店者のサービス提供が最も盛んな時間帯を調べたい、といった場面で役に立つかもしれません。

こういったアルゴリズムは知っているとひょんなことで役に立つかもしれないので、そういった知識を深める場として競技プログラミングはいい機会だと思います。
競技に参加しなくても、エクササイズとして過去問に取り組むだけで勉強になると思います。
ぜひ、挑戦してみてください!

競技プログラミングのススメ

こんにちは、 @akira です。本年もよろしくお願いいたします。

2021 年のテックブログ一本目は、競技プログラミングの紹介記事になります。

サンプルコードは Go で記載しています。

競技プログラミングとは

出題されたお題をデータ構造とアルゴリズム(+数学 etc...)を駆使して解く競技です。

実際のコンテストでは制限時間内に難易度の違う問題が複数出題されるので、それらをいかに早く解くかを競います。

例えばこんな問題が出題されます。

自然数 n (1 <= n <= 1000)が与えられたとき、1からnまでの和を求める calcSum() を実装せよ

まず naive に brute force でこの問題のアルゴリズムを実装してみましょう。

brute force は、パスワードを一文字ずつ変えながらログインを試みる攻撃手法 brute force attack の名前などに使われており、「強引に何かを行う」といった意味をもつ単語です。

競技プログラミングにおいては、「総当りで計算する」といった意味合いがあります。

func calcSum(n int) int {
    rev := 0
    for i := 1; i <= n; i++ {
        rev += i
    }
    return rev
}

このとき、時間計算量は O(n) 、空間計算量は O(1) です。

時間計算量は、ざっくり言うと必要な手順の回数を指します。上記のアルゴリズムでは n 回ループが実行されるので、O(オーダー)記法で O(n) になります。

空間計算量は、ざっくり言うと必要なメモリの量を指します。上記のアルゴリズムでは、返り値の変数 rev 以外はメモリを使っていないとみなすと、O(1)(常に一定)と表せます。

この問題、時間計算量 O(1) で解くことができます。

問題は 1~n までの和を求めているので、初項 1、公差 1 の等差数列の和を求めればよいことになります。

初項 a、公差 d、項数 n、末項 l の等差数列における初項から第 n 項までの和 S は、以下の式で求められます。

S = n * (a + l) / 2 =  n / 2 * (2 * a + (n - 1) * d)

今回は a = 1, d = 1, n = n, l = n であるため、上記に代入すると

S = n / 2 * (2 * 1 + (n - 1) * 1) = n * (n + 1) / 2

この公式を利用することで空間計算量は O(1) 、今回のように n が大きくない(n <= 1000) 場合は、時間計算量 O(1) で計算することができます。

func calcSum(n int) int {
    return n * (n + 1) / 2
}

競技プログラミングの楽しさ

上記の問題だけでは少し物足りなかったかもしれません。

もっと本格的な問題を考えてみましょう。

ローマ数字は I, V, X, L, C, D, M (それぞれ 1, 5, 10, 50, 100, 500, 1000)を組み合わせて数を表す
通常は左から右に向かって大きい数から順に表すが、以下のケースは例外となる

・I は V(5), X(10) の前に書くことで IV(4), IX(9) を表せる
・X は L(50), C(100) の前に書くことで XL(40), XC(90) を表せる
・C は D(500), M(1000) の前に書くことで CD(400), CM(900) を表せる

自然数 num (1 <= num <= 3999) が与えられたとき、そのローマ数字を文字列で返す convertToRoman() を実装せよ

私は最近この問題を解いたのですが、最初の回答が以下です(ワントゥスリィ!)

var m map[int]string = nil

func convertToRoman(num int) string {
    m = make(map[int]string, 0)
    m[1] = "I"
    m[2] = "II"
    m[3] = "III"
    m[4] = "IV"
    m[5] = "V"
    m[6] = "VI"
    m[7] = "VII"
    m[8] = "VIII"
    m[9] = "IX"
    m[10] = "X"
    m[20] = "XX"
    m[30] = "XXX"
    m[40] = "XL"
    m[50] = "L"
    m[60] = "LX"
    m[70] = "LXX"
    m[80] = "LXXX"
    m[90] = "XC"
    m[100] = "C"
    m[200] = "CC"
    m[300] = "CCC"
    m[400] = "CD"
    m[500] = "D"
    m[600] = "DC"
    m[700] = "DCC"
    m[800] = "DCCC"
    m[900] = "CM"
    m[1000] = "M"

    rev := ""
    for num >= 1000 {
        q := num / 1000
        num %= 1000
        rev += strings.Repeat(m[1000], q)
    }
    num, rev = calc(rev, num, 100)
    num, rev = calc(rev, num, 10)
    _, rev = calc(rev, num, 1)
    return rev
}

func calc(rev string, num, d int) (int, string) {
    q := num / d
    num %= d
    rev += m[q * d]
    return num, rev
}

ゴリ押し感満載で、前半のローマ数字を打ち間違えたらそれだけで不正解となりそうなコードですね。実装も大変だった記憶があります。

ただ、上記のコードでも正解として通過はしました。

後ほど比較するためにざっくりで時間計算量を出すと、

  • num を 1000 以下にするのに for で記載してますが、1000 で modulo を取っているのでループは1回しか回らず
  • strings.Repeat() は O(log2(q)) とすると

最終的には O(log2(q)) でしょうか。

このコードをより改善しようと試みて書いたのが次のコードです。

var m map[int]string = nil

func convertToRoman(num int) string {
    m = make(map[int]string, 0)
    m[1] = "I"
    m[5] = "V"
    m[10] = "X"
    m[50] = "L"
    m[100] = "C"
    m[500] = "D"
    m[1000] = "M"

    rev := ""
    for num >= 1000 {
        q := num / 1000
        num %= 1000
        rev += strings.Repeat(m[1000], q)
    }
    num, rev = calc(rev, num, 100)
    num, rev = calc(rev, num, 10)
    _, rev = calc(rev, num, 1)
    return rev
}

func calc(rev string, num, d int) (int, string) {
    q := num / d
    num %= d

    if q == 9 || q == 4 {
        rev += m[d] + m[(q+1) * d]
    } else if 6 <= q && q <= 8 { // 8,7,6
        rev += m[5 * d] + strings.Repeat(m[d], q % 5)
    } else if 2 <= q && q <= 3 { // 3,2
        rev += strings.Repeat(m[d], q)
    } else if q == 5 || q == 1 {
        rev += m[q * d]
    }

    return num, rev
}

より短い行数で書けましたが、桁に 6,7,8 が登場する場合は strings.Repeat() も呼ばれるため、時間計算量は先程のものから悪化してしまっています。

どうにかならないものかと、他の方が提出した回答を眺めていると、次のような考え方で実装されていて驚愕でした(別の言語だったため、Go で再実装しています)。

今回の問題の numnum <= 3999 の制約があります。つまり千の位はたかだか 3 までということです。そこから次のような考え方が生まれたのでしょう。

func convertToRoman(num int) string {
    M := []string{"", "M", "MM", "MMM"}
    C := []string{"", "C", "CC", "CCC", "CD", "D", "DC", "DCC", "DCCC", "CM"}
    X := []string{"", "X", "XX", "XXX", "XL", "L", "LX", "LXX", "LXXX", "XC"}
    I := []string{"", "I", "II", "III", "IV", "V", "VI", "VII", "VIII", "IX"}
    return M[num/1000] + C[(num%1000)/100] + X[(num%100)/10] + I[num%10]
}

各桁で取りうる値を全て slice に保持しておいて、後はその値の文字列を連結しているだけの非常にエレガントなコードです。

時間計算量は、slice (array) は memory access のため O(1) 、 num <= 3999 であることと定数であれば O(1) としてみなせるため O(1 * 4) = O(1) になります。

こんなコードを最初にかけたら非常にスマートで楽しいに違いない、と苦しみながら解いた私は感じます。

これが競技プログラミングの楽しさではないでしょうか。

オススメの競技プログラミングサイト

以下のサイトが個人的におすすめです。無料で問題を沢山解けます。

上記以外にも、ゲーム感覚で挑戦できるCodingameなど、たくさんあります。

自分に合ったプラットフォームを選択するとより競技プログラミングが楽しくなるかなと思います。

終わりに

競技プログラミングに取り組むことで時間計算量や空間計算量を意識するようになり、実務でコードを書く際にも効率的にリソースを使えるようになります。

上記のような一見大変そうな問題をスマートに解くことにも楽しさはあるので、まだご経験のない方はこれから挑戦してみてはいかがでしょうか。

それでは!