2025-08-25

雑な近況アップデート

ご無沙汰しております。最後の投稿からそろそろ5年経つので近況を残しておきます。さいきんはですます調です。

2021年: 車の免許 (AT限定) をとった

恐ろしい乗り物だなと思いつつも、便利さには抗えなかった。恐ろしいのでわかばマークを今もつけています。

2021年: 大学を卒業した

2013年4月に帝京大学理工学部情報科学科に入学して2021年9月に卒業しました。序盤の数年はあまり本腰を入れられなかったのと途中で休学したりで、結局8年かかってしまいましたが、社会人で始めてもやれないことはなかった。ひとつひとつ挙げると些細ながら、後の生活にも役立ってはいます。

2023年: 永和システムマネジメント → Degica

2010年に ESM に join して、最後の日まで大変お世話になりました。同じチームで働けてよかった。

現在は Degica で KOMOJU という決済代行サービスを開発しています。エンジニアリングをはじめ一部のチームでは海外から来た人が多く、コミュニケーションは基本的に英語です。そのおかげもあって、前と比較して英語力は伸びたと思うけど、正直まだ駄目です。Ruby/Rails が基本なのはこれまでと変わりませんが、技術的にもドメイン的にも新しい部分が多く大変興味深いです。

これから

家の中も快適なんですが、少しは外に出ようかと思ってます。

2020-08-30

Stripe の Subscription 機能を Docker だけで素早く試す

Stripe のドキュメントによると、この機能を使っていわゆるサブスクリプション型の課金の仕組みを実装できる。公開されている参考実装には、Netflix のような毎月固定額の支払いに対応する例がある。ドキュメントだけでも十分に分かりやすいものの、これを実際に手元で動かすことで、何がどうやって動いているのかさらに理解が深まった。手元で動かすには Docker さえあれば大丈夫。

前提条件:

手元のマシンに Docker がインストールされていること。
Stripe のアカウントを持っていること。
参考実装で使う商品 (Product) として Basic と Premium を作成済みであること (手順)

ターミナル上でやること

全体を通して、シェル上で実行する操作は以下の通り。

# Stripe CLI のセットアップ
mkdir -p ~/.config/stripe
touch ~/.config/stripe/config.toml
docker run --rm -it \
  --volume ~/.config/stripe/config.toml:/root/.config/stripe/config.toml \
  stripe/stripe-cli login

# Stripe CLIで、飛んでくる webhook のリクエストをアプリケーションサーバに転送する
docker run --rm -it \
  --volume ~/.config/stripe/config.toml:/root/.config/stripe/config.toml \
  --name stripe-cli \
  --publish 4242:4242\
  stripe/stripe-cli listen --forward-to http://localhost:4242/stripe-webhook

git clone https://github.com/stripe-samples/subscription-use-cases.git
cd subscription-use-cases

# アプリケーションの実行に必要な環境変数を設定する
cp -p .env.example fixed-price-subscriptions/server/ruby/.env
$EDITOR fixed-price-subscriptions/server/ruby/.env

# Stripe CLI と同じネットワークを使いつつ、アプリケーションサーバを起動する
docker run --rm -it \
  --workdir=/work \
  -v $(pwd):/work \
  --network container:stripe-cli \
  ruby:2.7.1 bash -c \
    "cd fixed-price-subscriptions/server/ruby && bundle && bundle exec ruby server.rb -o 0.0.0.0"

必要なコマンドはこれだけ。今回は Ruby の実装を使うので、Ruby の実行できるコンテナを用意する。また、仕組み上 Stripe からの webhook を受け取る口も必要なので、そのために Stripe CLI の Docker イメージも使っている。ひとつひとつは少し複雑なので、それぞれ順番に見ていこう。

Webhook を受け取れるようにする

参考実装のアプリケーションサーバは手元のマシンで動くので、Stripe から飛んでくる webhook のリクエストをどうにかして受け取れるようにする必要がある。そこで Stripe のコマンドラインツール Stripe CLI の出番になる。Docker イメージが提供されているので、すぐに使える。

mkdir -p ~/.config/stripe
touch ~/.config/stripe/config.toml
docker run --rm -it \
  --volume ~/.config/stripe/config.toml:/root/.config/stripe/config.toml \
  stripe/stripe-cli login

Stripe CLI はログイン時にブラウザを開こうとするものの、ブラウザの入っていないコンテナ上で実行しているので当然うまくいかない。ただ、失敗したタイミングで URL が表示されるので、それを使って自分で開けば問題ない。ログインが完了すると、~/.config/stripe/config.toml に認証情報が書き込まれる。

出力されているURLを使ってログインする

準備ができたので、早速 webhook を待ち受ける。

docker run --rm -it \
  --volume ~/.config/stripe/config.toml:/root/.config/stripe/config.toml \
  --name stripe-cli \
  --publish 4242:4242\
  stripe/stripe-cli listen --forward-to http://localhost:4242/stripe-webhook

これによって webhook のリクエストはすべて http://localhost:4242/stripe-webhook に転送される。ここで転送先URLに localhost を使うことができるのは、次のステップでアプリケーションサーバを走らせるときにこのコンテナと同じネットワークスタックを使うためだ。また、そのためにあらかじめコンテナに名前を付けている。これによって、別のコンテナを走らせるとき --network container:stripe-cli と既存のコンテナを指定して同じネットワークスタックを使うことができる。

コンテナが起動すると、whsec_ で始まる webhook secret が出力される。これは次のステップで使う。

アプリケーションサーバを起動する

参考実装を GitHub から clone しよう。冒頭でも述べたように、ここでは Ruby の実装を使う。

git clone https://github.com/stripe-samples/subscription-use-cases.git
cd subscription-use-cases

アプリケーションサーバを起動するには、いくつかの環境変数を設定する必要がある。アプリケーションは .env から変数を読み取るので、リポジトリのルートにある .env.example を .env という名前でアプリケーションサーバのディレクトリにコピーする。お好みのエディタで環境変数を設定する。

cp -p .env.example fixed-price-subscriptions/server/ruby/.env
$EDITOR fixed-price-subscriptions/server/ruby/.env

STRIPE_WEBHOOK_SECRET には前のステップで手に入れた webhook secret を設定する。その他の値は Stripe のダッシュボードで確認できる。

Keys: ダッシュボードの開発者ページ

Prices: 商品ページの詳細

最後に、ruby コンテナの中で依存ライブラリをインストールしつつアプリケーションサーバを起動する。前述の通り、--network container:stripe-cli で Docker に Stripe CLI のコンテナと同じネットワークスタックを使うように知らせる。アプリケーションをホスト側のブラウザから開くため、-o 0.0.0.0 もここでは必要になる。このオプションによって、Sinatra に全てのネットワークインターフェースを listen するように知らせている。

docker run --rm -it \
  --workdir=/work \
  -v $(pwd):/work \
  --network container:stripe-cli \
  ruby:2.7.1 bash -c \
    "cd fixed-price-subscriptions/server/ruby && bundle && bundle exec ruby server.rb -o 0.0.0.0"

これで localhost:4242 を手元のブラウザで開き、subscription の機能が動作している様子を確認できるようになったはずだ。この参考実装では、subscription の作成、変更、キャンセルなどを試すことができる。Stripe CLI の出力は特定のイベントがどのタイミングで起きるかを知るのに便利なので活用しよう。

2019-04-06

Tokyo Rubyist Meetup で2年ぶりに発表した

4/3 の回で Docker について話した。英語の発表は2年ぶり2回目。業務で Docker を使って開発をしてきた中で、こういうとこが良くて、こういうところが面倒だった、みたいな感じの内容。

Using Docker for your Rails Development Environment - Tokyo Rubyist Meetup | Doorkeeper

Tokyo Rubyist Meetup で話すと、Paul さんの手厚いサポート (リハーサルとかスライドのレビューとか) によって自分の変な英語が次々とあぶり出されていくので勉強になる。ありがたい。

全体的に、話が伝わるかどうかを重視して準備した。最近気になっていたこととして「(第二言語話者としての) 自分のスピーチの内容は、思ったよりも相手に伝わってないんじゃないか」というのがある。テキストベースの一対一の会話と比較してみると、スピーチはちょっと難易度が上がる感じがする。話し手と聞き手の関係が一対多になって、方向はほぼ一方通行、テキストみたいに読み返したりもできない。それに加えて話し手が第二言語で話すとなると、正しく伝わる情報はさらに減りそう。Google 翻訳が一瞬で意味の通る日本語に変換してくれるその英文を、生身の人間が一回聞くだけで理解できるのかどうか、なんとなく不安になる。というわけで、RubyConf 2018 での Daniel Azuma の発表動画と Saron Yitbarek の発表動画、松田さんプロダクトの README (Himl など) を参考にしつつ、今まで自分があまり意識していなかったと思われる次の点に気をつけることにした。

重要な部分は言い換えて繰り返す
新しい話題はなるべく問いかけるかたちで始める
ひとつの文節をなるべく単純に、短かくする
子音をしっかり発音する

うまくやれたのかは正直よく分からない。今回は話し方をチェックするために録画してみたんだけど、前回の録画はないので比較できないのが残念。見えている範囲では楽しんでもらえたように思えるのと、フィードバックとして、普通に理解できたよ、前より発音良くなった、といった声をもらえたのは素直に喜びたい。次の機会があったら、今度は Q&A もう少しなんとかしたい。

2017-04-29

Tokyo Rubyist Meetup / 読んだ本

Tokyo Rubyist Meetup で発表してきた

4/19 の回で GraphQL について話してきた。「GraphQL は、Web API でありがちな諸問題への解決策のひとつとして良いもので、こんな感じで使います。」という内容。

Paul さんに発表しないかとメールで誘ってもらったのがきっかけ。その後、せっかくなので会場の提供も永和ですることになった。英語が下手でも問題ないか確認したところ「英語で発表したことがない人に登壇できる場所を提供したい」から大丈夫とのこと。

準備のために大量の英文を書いた結果、思ったことをその場で文にするのがずっと楽になった。録音した自分の発音を確認する作業を繰り返したおかげか、聞き取れる程度には発音できるようになったらしい。とはいえ、まだ満足に会話できるレベルには色々足りなくて、発表後の質問タイムではいくつかの質問にうまく答えられなかった。これは次の機会までの課題になりそう。もうしばらくお勉強と実践を繰り返していくつもり。

これからの「正義」の話をしよう

これまで何となく「正しいだろう」と素通りしてきたことについて、新たな視点が得られたような。最後あたりの話はちょっと難しい。

ゴドーを待ちながら

「ゴドーを待つんだ。」「ああそうか。」

こういうの好きだ、と思いながらささっと読了。その時代の背景を知っているともっと面白く読めるんだろうかと発行年を調べたら1952年。第二次世界大戦が終わったり、太宰治が入水して数年後。

2017-03-12

3月上旬のようす (ゆるデ部/GraphQL/How We Learn)

ゆるデ部 meetup 64回

前回で初参加して、今回が二回目。

前回音の鳴るシェルを作るために Pure Data で SE を作ってるんですがこういうのに使えるゲームの効果音みたいな素材ないんですかね、というようなことを言ったらザ・マッチメイカァズのようなまさに探していた感じの素材のありかを教えてもらう。「ダンジョンの壁に当たったとき」みたいな簡単な音を作るのさえけっこう手間だったので、ここで聞けてよかった。

効果音が揃ったのでそれなりに楽しくなったものの、もう少し面白くできないかなあと思ってしばらくほったらかしにしてた状態で2回目に参加。ドラムとか使ったシンプルな BGM があって、シェルを操作したときの音をそれにうまく合わせられると気持ちいいんじゃないかと言われてなるほどと思う。音ゲー的な感じだろうか。似たコンセプトのゲームに Rez というのがあるらしい。PS4買ったらやってみようかなあ。

GraphQL

年始から少し気になっていた GraphQL がおもしろくて API の実装を試してみたりしている。何が必要かをクライアント側がクエリではっきり簡潔に記述できるのいいなあ。スキーマから最低限の API ドキュメントが生成できるのも助かる。あと GraphiQL べんり。いいとこたくさん。でもサーバ側の実装はそんなに簡単じゃないかも。

作った API の使い心地を確認するために、いくつかクライアント側の実装も試してみた。Relay とか Apollo は色々やってくれて便利な反面、既にあるものを置き換えるにはそれなりに大きな変更が必要そうに見えた。その点 Lokka は単純な GraphQL のクライアントなので当たり前だけど自由度が高く、ちょっとした用途には使いやすかった。

参考にしたサンプルアプリは webpack でビルドできるものが多くて、試しに自分でも使いはじめてみたところけっこう楽ができてる気がする。

脳が認める勉強法 (How We Learn) を読んだ

記憶力や創造性についての事実が発見されていくまでのストーリー。その過程で行なわれた数々の実験についても詳しめに書かれていて面白かった。記憶の謎を解明するために何の意味もないたくさんの文字列を家族全員で学習する話とか、レム睡眠が発見されたときのエピソードとか。

学習の環境に変化をつけると何が変わるのか。学習前にテストを行なうことにはどれほどの意味があるか。アイデアの「孵化」はどのようにして起こるか。そんな感じのことが書いてある。巻末には TL;DR 的な Q&A が載っていて、実践的な内容としてはその数ページを読めば十分かも。

ここで読んだ孵化の話はアイデアのつくり方にもあった気がする。