「SendGrid」の記事 - Crieit

数日で有料サービスをリリースしてみた話

2021-11-17T09:36:55+09:00

有料サービスを２，３日位で作ってリリースしてみました。多分計10時間ほど？　急にぱっと思いついて次の日の夜くらいにはだいたい完成していました。作ったのは下記のHand Refactorerというプログラムのコードを手動的にリファクタリングしてくれるサービスです。

130円でプログラムのコードを手動的にリファクタリングしてくれるサービスをリリースしました。プログラミングを始めたばかりの方にはもしかしたら役立つ場合もあるかもです。よろしければお試しください！！https://t.co/bHlNXJFbTh pic.twitter.com/VhPI80a6Cl
— だら@Flutterもやってる (@dala00) November 14, 2021

ちなみにこれ自体は単に自動的じゃなくて手動かよというツッコミがほしいだけのために作ったネタクソアプリです。

色々やるべきことを削ったりなどで考えたりしたので書いておきます。

サービスの流れ

そもそもサービスの流れですが、まずユーザーがリファクタリングしてほしいコードを入力して登録します。

それを僕が人力でリファクタリングし、回答として登録するとユーザーがそれを確認できる、という形です。

課金関連の開発を極限まで削る

課金となると、結構色々考えなければなりません。ユーザー登録し、そのユーザーに対して課金ログを保存し、購入履歴などを用意する必要があります。ただそこまでするとどうしても工数がかかってしまいます。そのため下記のようにして開発事項を削りました。

オーソリを使う

オーソリというのは、仮売上です。即課金確定するのではなく、注文が確定した時にキャプチャという処理を行って決済を確定させる方法です。ユーザーが注文してきた時に仮売上とし、僕が処理を行って納品でき、ユーザーがそれを意図的に閲覧した場合に納品確定としキャプチャを行うようにしました。

この方法には色々メリットがありました。

ユーザーの心理的不安を取り除ける

個人サービスですので、そこに課金するのにはちょっと不安があります。ただ、ちゃんと納品が行われないと課金が確定しないということが事前にわかっていればその不安をある程度取り除くことができます。

確定する場合には、ユーザーに回答画面のURLが貼られたメールが送られます。ここでも実際に見て課金を確定するかどうかをユーザーが意図的に選ぶ事ができます。興味がなければ見ずに終わらせればいいですし、お金を払ってでも見たいと思っていれば閲覧して確定できます。

運営側の不安も取り除ける

個人サービスで課金機能を提供するのは、運営者としてもなかなか気持ち的に不安になることが多いです。うまくサービスを提供できなかったらどうしよう、大きなミスに気づかず迷惑をかけてしまったらどうしよう、など。

しかしオーソリを利用してユーザーがお金を払って結果を見たいと確信して行動する時に初めて課金が行われるようにすれば、なかなか間違えたり問題が起こる可能性は低くなります。そうなると運営側としても問題が発生しにくく安心です。

また、最悪僕が怠けたりなにか急なトラブルで全然手を付けられず放置したとしても一切課金されることはありません。また、そんなにリファクタリングすることがないコードであれば確定しないことでキャンセル扱いにすることもできます。

このようにしてお互いの不安をなるべく少なくすることでユーザーは購入を、運営はリリースをしやすい気持ちにできるようにしました。これができなければ色々と複雑なテストをしたり入念にいろいろな機能をつくったりしてなかなかリリースはできなかったでしょう。

チェックアウトを使わない

Stripeにはチェックアウトというプログラムを書かなくても商品を売れる機能があります。すごく簡単なのですが今回はそれは使いませんでした。というのも売上の結果を知るためにWebhookでチェックする必要があり、ちょっとそれが面倒でした。プログラムで決済してしまえば登録時に一緒にやってしまえばすべてが終わるためそちらの方が処理的にもわかりやすくテストもしやすかったためです。

メールアドレスを使う

メールアドレスを使うことでログイン機能を削りました。ユーザー登録をすると、やはり離脱率は上がります。ちょっと投稿して利用するだけのサービスでユーザー登録は面倒くさいです。

また、ログイン機能を作るとそれはそれで結構面倒です。Next.js と Firebase を使っているのですが、それで認証を入れるとFirestoreのセキュリティルールも設定しなければなりませんし、その状態だとNext.jsのサーバーサイドレンダリング時にエラーが発生することもあり、結構確認事項が増えます。ログイン機能を作らずメールアドレスのみの照合とすることでそれら全ての開発を削りました。

メールアドレスだけでは勝手に決済されて危険なのでは？　と思われるかもですが、クレジットカード自体は操作している人自身のものを入れなければならないためなりすましは難しいですし、できたとしても結局オーソリまでしか進めないため、利用者が最後まで進まないとお金は一切動きません。

またこれにより結果のURLはメールで本人しか知ることができないため漏洩の心配などもありません。

最初はユーザーもメールアドレス登録するのはいやかな…とも思ったのですが、そもそも大量の依頼がくるとそれはそれで僕のスケジュールがパンクしてしまうのである意味抑制になっていいかなと思っています。

極限までハードルを下げる

このハードルというのはユーザー、運営者両方のことです。

まず費用は130円という自販機でジュースを買うのと同じ（？）ような料金にしました。また、説明分にはレジャー感覚で使ってほしいということ、意図した結果が帰ってくるとは限らないということを書いておき、運営者的にもちゃんとした結果をださなければ、という不安をなくし、利用者としてもさほど結果に期待しない状態を作っておきました。

ハイクオリティになったり、ハードルの認識の齟齬があると開発もそれに対処するためにちょっとやることや考えることが増えたりなど、すぐにリリースはできません。とにかくすぐに作るレベルのサービスに連動したクオリティの商品をそれに見合った低価格で提供することによってリリース時の負担を下げました。

管理機能を公開しない

リファクタリング結果の送信ですが、Firestoreのダッシュボードだけではできません。そのためそこは返答用の画面を作ってあげる必要がありました。

しかし前述の通り認証もありませんし、URLを作ってしまうと万が一アクセスされてしまった時に情報が漏洩してしまいます。

そのため管理画面は公開せず、別プロジェクトとして作り、ローカルのデバッグ実行だけでできるようにしました。絶対に他の人にアクセスされることもありませんので安全です。また、作っていたプログラムをコピーするところから始めたのでベース部分はまるまる流用でき、特に大変でもありませんでした。

Firebaseクライアントを使わず全部APIのみにする

前述の通り、セキュリティルールを設定するのが面倒だったためFirebaseのクライアントはアクセス解析にしか使っていません。セキュリティルールは全部のデータへのアクセス不許可にしています。

普通に単なるAPIとしてfirebase-adminを利用してサーバーサイドのDBのようにして作っています。なにもかんがえることもなく非常に楽です。勝手に変なデータにアクセスされてしまうこともありません。

また、Firestoreを使うことによってデプロイする場所を選ばなくてもよいようにもなっています。

今回はCloud Runにデプロイしました。前述の通りDBはFirestoreなのでどこにでもデプロイできます。本来はVercelが一番楽なのですが、この無料プランは個人的な利用のみに限られますので、今回の場合は利用できません。ということでCloud Runを使いました。GitHubにpushしたのに連動して自動的にデプロイもできますし。Herokuでも良いと思いますが頻繁に利用されるサービスではありませんし、あまりアクセスして遅いのもあれかなと思いCloud Runにしました。

せっかくなのでDockerfileを使わないでデプロイできるBuildpackというものを試してみたかったというのがあったのですが、どうもビルド無しで実行されてしまうようでエラーになったので今回は諦めてDockerfileを使うことにしました。だいたいDockerfileならどっかーにあると思いますので。

今回は下記を使いました。
【Node.js/Next.js】Cloud Runで動作する軽量なDockerを構築してみた

これの真ん中のやつでだいたいデプロイに8分ほどかかります。それほどパフォーマンスが必要ではないので一番最初の簡易的なやつでも良かったのかもしれません。なんにしろVercelよりはやはりどうしても遅くなってしまいますね。

あと日本リージョンにしたのでちょっとネットワーク料金がかかります（アクセスがちょっと多ければ月何十円とか100円とか？）

CSSも使わない

今回はChakra UIを使いました。とにかくデフォルトのデザインパーツで、カスタマイズは全部Chakraコンポーネントのプロパティのみで、ぶわっと作りました。非常に楽です。

DIFFの表示

リファクタリングということで、DIFFを表示したほうがわかりやすいかなと思いました。

React Diff Viewerというのを使いました。
https://github.com/praneshr/react-diff-viewer

まとめ

最初に書いたとおりクソアプリですので、ものすごい依頼が増えない限りは特にアップデートする予定はありません（依頼がきたらちゃんと対応します。リファクタリングは結構好きなのでわりと楽しんでやっています）。

ただ数日で作れたので、これを機に低価格で同じように自分で提供できることを売るのも面白いかなとは思います。どうしても手がかかるので規模が大きくなるとスケールもしないし限界がありますので、あくまでも今回のようにジョーク交じりかつすごく負担の少ない作業だけになるとは思いますが。

逆に言うと、低価格でちょっとなにか提供できる、というひとはたくさんいると思いますので、みんながこういうサービスを各々作れたら面白いのにな、とも作ってる途中に思いました。例えば小説の手直し、絵の手直し、もしくはちょっとした絵を書いてあげたり、サービスの感想を伝えてあげたり、なにか写真をとってあげたり、ロゴをつくってあげたり。皆自分の得意なことを提供して少しでもお金になれば楽しいのでは、と思いました。

もちろんそういうモール的なサービスはいくつかあると思いますが、あくまでも自分の個人商店的な感じで運用するのも面白いと思います。

自分でみんながそういうことを提供できるサービスを作ればよいのでは、とも一瞬思ったのですが、やはり価格的に運営者に入るお金はかなり薄利になり、儲けを出すにはかなり大量に集客しないといけませんし個人だと逆に大変なことが多そうなので、無理かなと思いました。Skebのもっと安くて気軽バージョン的な感じかもです。

なので可能な方は是非同じ様なサービスを作ってなにか提供してみると面白いのではないかと思います。

EXCEL VBAからSendGrid WebAPI経由でメール送信

2020-12-26T12:11:54+09:00

はじめに

（Qrunch からの移管記事です）

タイトルの通り、EXCEL VBAからSendGridのWebAPI経由でメール送信をする方法を記載。
「WebAPIとか全然わからない」の状態から頑張って送信までできるようにしました。

普通はCDO.MessageでSendGridへSMTP通信すればいいだけですが、
ネットワーク構成の都合上「外部へのSMTP通信は不許可、HTTP/HTTPSはOK（ただし認証プロキシあり）」という環境化だったので、WebAPIを利用せざるをえませんでした。
⇒むしろSendGridにWebAPIがあってよかった。

同じような境遇の人がいたら参考にしてください。（いるか？）

参考URL

１．VBAでのWEB API
https://qiita.com/haseshin/items/4acf31db9a672ed691df
２．VBAでのWEB API & JSON
https://qiita.com/MakotoIshikawa/items/be902e6bd3fa2e5c5fe5
３．SendGridのリファレンス
https://sendgrid.kke.co.jp/docs/API_Reference/index.html

事前作業（SendGridの認証について）

「SendGirdのユーザ名とパスワードをどこかで指定するんだろうなぁ」
と思ってたのですが、不要でした。

SendGridのポータルサイトからAPIキーを発行してください。
発行したAPIキーが認証情報になります。

実装コード

Sample

Private Sub SendMail() 

    Dim objHTTP As Object
    Dim json As Variant

    json = "{""personalizations"":" _
              "[{""to"": [{""email"": ""[email protected]""}],""subject"": ""Mail Title""}]," _
              """from"": {""email"": ""[email protected]""}," _
              """content"": [{""type"": ""text/plain"",""value"": ""Mail Body""}]}"

    Set objHTTP = CreateObject("MSXML2.ServerXMLHTTP.6.0")

    With objHTTP
        .Open "POST", "https://api.sendgrid.com/v3/mail/send", False
        .setRequestHeader "Content-Type", "application/json; charset=UTF-8"
        .setRequestHeader "Authorization", "Bearer xxxxYourApiKeyxxxxxxxxxxxxxx"
        .setProxy 2, "proxyhost.com:9293"
        .setProxyCredentials "proxyUser", "ProxyPassword"
        .setOption 2, 13056
        .send json

        If .ResponseText <> "" Then
            MsgBox .ResponseText
        Else
            MsgBox "OK"
        End If
    End With

End Sub

流れ
・JSON形式でメール設定を定義（細かい内容はリファレンスの「V3 Mail Send API概要」参照）
・MSXML2.ServerXMLHTTP.6.0オブジェクトの生成
・POSTメソッドでSendGridのMail Send APIをオープン
・ヘッダ設定。Content-TypeにJsonの指定。
　AuthorizationヘッダにAPIキーをセット。Bearerの指定をお忘れなく。
・プロキシ設定。setOptionの記述はSSL認証に関するエラー回避。
・送信。エラーの際にはResponseTextにエラー内容が入っているはず。
補足
・「xxxxYourApiKeyxxxxxxxxxxxxxx」がAPIキーです。
・プロキシを経由しない環境であれば「setProxy」、「setProxyCredentials」、「setOption」は省略してください。

VBAでのJSONファイルの取り扱い

JSONファイルをVBAでまじめに取り扱うのであれば「VBA-JSON」の利用なども検討してください。
⇒参考URL３の記事に詳しく記載されています。

所感

・VBAでのWebAPI利用なんてサッパリだ、の状態からなんとか実現できました。
・以外にVBA&REST APIの情報がネットに転がっていて助かった…

Wordpressを無料でS3、SendGrid、Heroku、Composerでデプロイする

2018-10-10T19:35:48+09:00

https://github.com/PhilippHeuer/wordpress-heroku

こちらのGithubにある「Deploy to heroku」ボタンをクリックすることでも構築できるのですが、画像やプラグインを永続的に維持するためにはローカルに構築してcomposer updateしてから差分をgit pushし、同じソースコードをherokuにデプロイする必要があるのでした。

いろいろいじってやってみたところ、なんとかできたので、この後もいろいろ試したいと思う。

一番苦労した点は、英語版Wordpressを日本語化する方法だった。

ローカルでWP CLIを使って日本語化ファイルをダウンロードし、git pushしたらできた。

wp core language install ja --activate

参考URL
https://upd.world/wordpress-cloud9/
https://qiita.com/miya0001/items/96a684e2f819f9d8b4a4
https://qiita.com/fuwamaki/items/8684003bb47197336645

WEBサービスの通知機能実装が面倒すぎるので困った

2018-06-20T08:12:23+09:00

先日Crieitにコメント機能を付けました。そうなると必要になってくるのが、通知機能です。

記事を投稿した人はコメントがついたら通知が欲しいでしょうし、コメントした人も自分のコメントに返信が来たり、同じ記事にコメントがついた場合にはすぐに見たいと思いますので通知が欲しいはずだからです。

通知機能の選択肢

WEBサービスに通知機能を実装する場合、現在だと大まかにふた通りのやり方があると思います。

メール通知

昔からある一般的な方法です。一番無難な方法でもあると思います。通知メールを残しておけば何の通知だったかあとでも確認できますし、メール通知機能さえあれば必要最低限はまかなえると思います。

PUSH通知

FCMを利用したPUSH通知です。メールとは違い、端末に通知が来て直接アプリケーションの画面が開けるため、スピード感がありWEBサービスには向いています。

どちらがいいのか？

最終的には両方の通知機能を実装することでしょう。ただ、個人でWEBサービスを作っている場合や、スタートアップなどがスモールスタートする場合などは何でもかんでも最初から実装しておけばいいというわけではありません。

サービス的に両方絶対必要、ということであれば仕方ないですが、時間に限りがありますし通知機能の実装は非常に面倒ですので、絶対必要でなければどちらかの通知機能に絞った方が良い場合もあると思います。

どちらにどういうメリットがあり、どちらがどれだけ面倒か考えていきます。

メール通知

メール通知のメリットは前述の通り、とりあえず作っておけば最低限大体のことは満たせるということです。ただ、実装方法は色々ありますが、結構面倒な点もあったりします。

サーバー上のメールサーバーを用意する場合

Postfix等を使えば特に外部サービスを利用しなくてもメールを送信することができます。ただ、自分で設定をしなければならないので面倒です。一回くらいなら自分で頑張って設定しようかと言う気にはなるのですが、もしもう１台増やすか、ということになった時などにまた同じ設定をしなければならないのかと思うとうんざりします。

僕は仕事上インフラ周りも触ることはありますが、メールサーバーは正直必要最低限は最初から送信できたりすることもあり、WEBサーバーやDBの設定に比べて扱う頻度が低く、大体次触る頃にはほとんど設定方法を覚えていません。そのためネットで調べながら設定することになり、時々つまづくこともあるのでかなり面倒です。

特に普段サーバー環境構築をしない人からするともっと大変だと思います。例えば下記の記事に設定が書いてありますが、長い設定画面が出てきたあたりで読む気すら起こらなくなると思います。
Ubuntuでメールサーバー構築

メール送信サービスを利用する場合

上記の理由から、SendGridやMailgunメールサービスをつかってメール通知を実装するともっと楽になります。色々と機能もついており非常に便利です。ただ、これはこれでいくつか問題があったりします。

送信数制限

送信数制限があるため、多く送ると費用がかかるようになります。例えばSendGrid等は現在月12000通です。

さすがにそれなら超えないんじゃないか？　と思いますが、１サービスではなく１アカウント毎の制限になりますので、いくつもサービスを作っていて、ある程度メールを送信するしている場合はわりと超えてしまうのではないかと思います。

今は良いけど今後サービス新しく作る場合にどうしようか？　と悩むこともあると思います。

リレー方式の場合はダメな場合がある

僕が愛用しているGCEもそうですが、ポートに制限がかかっている場合があり、リレー方式の送信方法だとブロックされてしまい送信できません。マニュアルはありますがこれもちょっとうんざりする系です。
SendGrid でのメールの送信

API方式がいい

API方式は良いです。一番簡単だと思います。ただ、言語によってはなぜかリレー方式しか使えないライブラリがあったりするので、このあたり気をつけないとローカル環境では動いたのに本番では送信できないとなりますので気をつけましょう。

あとはどの方式にも言えますが、DNSでSPFの設定をちゃんとやっておく必要があります。これをやっておかないとスパムメール扱いされてしまう事が多いです。メールサービスであればマニュアルに書いてあることも多いと思います。

WEB PUSH

FCMを利用したWEB PUSHによる通知です。スマホなどで通知を受け取り、すぐに目的のURLにアクセスできるため、サービスにユーザーを頻繁に呼びこむのに優れています。

単にユーザーに通知を送るだけでなく、トピックを作っておいて、そこにユーザー端末を登録してトピックに通知を送ると登録されているユーザー全員に通知を送ることができる、などもあり、非常に便利です。（もちろん、そのあたりの登録、解除の仕組みなどもちゃんと作らないといけません。自前のDBに保存しておく必要もあります）

通知の履歴が残らない問題

通知の履歴が残らないため、通知を消してしまったり、通知からサービスにアクセスしても一旦どうでもよくて離脱し、再度気になった時にアクセスできない、といった問題が出てきます。（実際にはスマホには履歴が残っているのですが、見るのも面倒で知らない人も多いと思います）

そのためサービス側に独自の通知履歴を作らなければなりません。

独自の通知の実装

独自の通知の実装ですが、これがまた面倒です。というのも、通知というのは色々なところで発生します。例えばフォローしているユーザーやカテゴリに何かが投稿されたり、自分の投稿にコメントがついたり。

つまりDBの構造として単純なbelongsToで作ることができません。通知自体はあまり他のところで使われるものでもないのでpolymorphicであれば割とシンプルに困ることなく作れるかもしれません。何にしろ条件分岐にしろ、関連モデルに共通のメソッドを用意するにしろ、やることは増えるので面倒なのは面倒です。

元はといえば単にユーザーに最低限の通知をしたかっただけのはずなのに…。

フロントとの連携の問題

単に通知一覧を実装するだけであれば問題ないのですが、WEBサービスのヘッダ部分に新着通知アラートをだしたりすることになるとまた面倒なことになります。どこまで閲覧済みかという情報を保存しておかなければならないからです。

フロントエンドと連携する場合、ユーザーの確認とDBの更新のタイミングが必ずしも同じではなくなるため、適当に作ったりするとまだ確認していないのにある一瞬のタイミングで全ての通知を確認済みにしてしまって新着通知が消えてしまったり、逆にフロント側では新着確認済みになったのにリロードするとまた新着が復活してしまう、ということが発生したりします。

Facabookもこの不具合が多く非常に困ったため、Fluxを提唱したという話をどこかで見ました。ほんとに通知機能というのはやっかいなシロモノです。

個人のWEBサービスなら良いのですが、もし仕事でするとなると仕様策定側が便利にしたいと思ってあれこれ勝手に決めてしまうこともあるので大変そうです。

周辺機能の実装

通知を作るとなると、周辺にも色々と機能を実装する必要が出てきます。これも非常に面倒です。元はといえば単にユーザーに最低限の通知をしたかっただけのはずなのに…。

トピックやユーザーなどにウォッチ機能、もしくは通知解除機能を実装する必要がある
ユーザーの個人設定に一般的な通知許可設定を実装する必要がある、もしくはここにも分類毎の許可設定が必要

まとめ

こんな感じで、単に通知機能を作りたいだけのはずなのですが、周辺部分も含めると結構工数がかかってしまい、なかなか厄介です。考えれば考えるほど、こだわればこだわるほど色々できてしまう箇所ですので、いかに絞って仕様を策定するかは非常に重要になると思います。
（メールサービス関連はざっと調べただけですので誤っている情報もあるかもしれません。検討される際は実際に確認してください）

記事を書きつつ気持ちを落ち着けて考えてみましたが、CrieitとしてはとりあえずSendGrid等のAPI送信で試そうかなと思います。一応公式のライブラリの方はAPI方式っぽいので。（SendGrid公式のLaravelやRailsのサンプルはリレーっぽいのでなんか不親切な感じがします）

…と決めたら決めたでまた悩む…。

追記）
FCMにする。

追加）
結局メール（API）も入れました。