「web1week」の記事 - Crieit

ハッカソンイベントで、「2」に近い式をあてるゲームを作ってみた

2020-09-20T19:25:58+09:00

こんにちは、最近「個人開発ガリガリやって実力つけたいなー」と思っているよしです。
先日、web1week に参加してきました。
色々とてんやわんやしながらも、なんとか投稿までいけたので、レポートを残しておきますー。

はじめに

web1week の概要

「1週間でお題に沿った Web サービスを作ってみよう」というハッカソン的なイベントです。

9/7～9/13の1週間でWebサービスを作るイベントです！　Hello worldレベルのサービスでもOKですのでぜひご参加をお願いします！ #駆け出しエンジニア仲間が多い方は是非シェアもお願いします～お題は「2」です。https://t.co/cl4XbPFici
— だら🎄いろいろつくってる (@dala00) September 6, 2020

参加したきっかけ

前回も参加して楽しかったので。

前回参加の時は割と使える時間が多かった一方、今回は仕事が終わった後か休日に開発することになりました。
なので、最初はどうしようかとも思いましたが、他の参加者の皆さんの多くは同じ状況下で開発されているはずなので、まぁどうにかなるだろう...くらいの気持ちで参加してました。

※前回参加時のレポート記事
- ハッカソンイベントで、React Konva 製のジグソーパズルっぽいパズルを作ってみた

自分が作ったもの

Close to 2

今回のお題は「2」ということで、
計算結果が一番「2」に近い式をあてるゲームを作りました。
一応、スマホでも遊べます。

イベントボードへの投稿から引用。

初級、中級、上級で遊べて、難易度が高いほど長い式になり、30秒で何問正答できるかな？というゲームです。
自分で作っておいてなんですが、暗算得意じゃないと無理ゲーじゃねーかと思いました。

なんでこれを作ろうとしたのか

こちらもボードへの投稿に書いていたので引用。

元々は「２」に関するクロスワードを作ろうとしていたのですが、「２」縛りで問題を考えるのがしんどいの極みだったので変えました（しかも土曜...）
その時点ですでに投稿されていた方（特に、きらぷかさんとDE-TEIUさん）の作品を見て、シンプルなゲームでも十分面白いものが作れるんだなぁと思い、今回の作品に至りました。
（他の方の作品を参考にさせていただきましたが、丸パクリレベルになってしまわないよう気を付けたつもりです）

技術構成

最初は前回同様、Docker の Node.js コンテナを使おうとしてました。
ただ、yarn コマンドやアプリ自体の動作速度、VSCode で開発する上での環境など色々考えたらめんどくさくなったので、WSL の Node.js を使いました。
（フロント開発でわざわざDocker使う意味ある？という議論も見かけたことがあったので...）

本番は GitHub Pages でホスティングしています（gh-pages でデプロイ）

使用した主なライブラリはこちら
- React：言わずと知れたUI構築ライブラリ（create-react-app で導入）
- Material UI：UI コンポーネント集
- React Share：各種 SNS のシェアボタン集
- React Snap：SPA の OGP設定
- PropTypes：props のバリデーション
- ESLint：静的解析
- Prettier：コードフォーマッター

前回同様、基本的な UI は Material UI で構築。
一部、前回作ったコンポーネントを流用したものもあります。

どんな感じで開発してたのか

大体こんなでしたが、「8日目」があるところからわかるように、1日遅刻投稿です（苦笑）

1日目：9/7(月)

「2」というお題を目にして、何を作るか悩みました。
前回、React Konva というライブラリを使用したので、今回も何かライブラリを使おうかと Reactのライブラリを調べてました。

そこで GitHub - React Crossword という、クロスワードを作れるライブラリを見つけ、これで何かやろうかな？となりました。

2日目：9/8(火)

クロスワードで何かするのであれば問題を考える必要があります。
とりあえず環境構築だけしておこうと、この日はリポジトリ作って環境構築まで。

3日目：9/9(水)

技術構成のところで書いた通り、わざわざ Docker 環境を使うの微妙だなと思ったので WSL を使う方向へ移行。
React Crossword を試してみたかったので試してみてました。

おおー、ライブラリでホントにクロスワードできたー。（公式のサンプルコード）#web1week pic.twitter.com/4dA2snPpzC
— よし (@yoshi44_lion) September 9, 2020

4日目：9/10(木)

「2」をいろんな言語の読み方にして成立するような問題を考えてました。

5日目：9/11(金)

この日も問題を考えるも、あまり進まず...。

6日目：9/12(土)

さすがに問題をどうにかしないと...と焦り出しました（遅い）

「2」をいろんな言語の読み方にして成立するような問題を考えていたものの、思いのほか難しい
↓
これ無理じゃね？
↓
読み方でなく「2」が含まれるものに関する問題（例：2月の和風月名 → キサラギ）に移行してみる
↓
縦読み、横読みを成立させるのが難しい
↓
これ無理じゃね？

みたいな感じになった結果、クロスワードは諦めることに...。

じゃあ、何を作ろうか？というところで、すでに投稿されていた他の参加者の方の作品を見て、シンプル路線にすることにしました。
ここからやっと当作品を作り始めます。

元々、2に関するクロスワード作ろうとしてたけど、問題考えるのがしんどすぎて、他のものに切り替え中。明日、とりあえず公開できる程度になればいいなぁ。#web1week
— よし (@yoshi44_lion) September 12, 2020

7日目：9/13(日)

何とか実装が進み、一旦デプロイしてみようとなりました。
前回は Firebase Hosting を使用しましたが、今回は使うまでもないかなということで GitHub Pages にホスティングすることに。

GitHub Actions でデプロイする記事を見かけたので、それでやろうと試みるもビルドで失敗。
どうも ESLint の react-hooks/exhaustive-deps ルールに引っ掛かっていたようです（.eslintrc 設定に含まれていなくても、ビルド時にチェックされる？）

対応方法を調べて試すも、なかなか解決しなかったので、一旦は無効化で対応（あまりよくないことでしょうが...）
ビルドはパスするようになり、デプロイ自体は成功しているものの、なぜか真っ白なページしか表示されず...。

この時点でもうヘロヘロで瀕死だったので、この日は諦めて終わりました。

ゲームとしてはできてるんだけど、ESLint の新ルールにビルドを阻まれ、GitHub Pages にデプロイできる GitHub Actions 試そうとしたら、デプロイ自体は成功してるっぽいのに、URL にアクセスしても何も表示されないし。やり方悪いんかな...。もう疲れた...。一旦終わろう。 #web1week
— よし (@yoshi44_lion) September 13, 2020

8日目：9/14(月)

gh-pages を使用して手動デプロイしてみても真っ白ページに。
試しに S3 にデプロイしたら普通に動作したので、GitHub Pages の問題と切り分け。

真っ白ページの原因を特定。
GitHub Pages 特有の注意点を見落としていただけだったようです。
こちらの記事にまさしくなことが書いてありました。
- create-react-appとTypeScriptでサラッと作ったSPAをgh-pagesにスルッとデプロイすっぞ！

ただ、これでもなぜか GitHub Actions でのデプロイは真っ白
ページのままだったので、以降は手動デプロイでやるように。

GitHub Pages のデプロイで動いたー。どうも package.json に homepage キーで URL を指定する必要があったらしい。そういえば Jekyll をデプロイするうえでの注意点とかで、前に見たことあったような…。なんか URL がずれておかしくなる的な。#web1week
— よし (@yoshi44_lion) September 14, 2020

無事動作確認できたし投稿するかと思いましたが、こういうのはやはり OGP 設定や Twitter シェア機能を付けた方がいいよなぁ...ということで対応することに。
この時点でもヘロヘロ気味だったので、やっつけで対応して、日が変わる直前に何とか投稿しました。

なんとか形にできたー。計算結果が一番「２」に近い式をあてるゲームを作りました。よろしければ遊んでやってください🙏Close to 2 - （9/7～9/13）１週間でWebサービスを作るイベント - お題「2」 - Boards - Crieit https://t.co/HDSKmfCsWo #Crieit #web1week
— よし (@yoshi44_lion) September 14, 2020

おおよそどんなことをやっているのか

特に変わったことはしてないと思いますので、ソースコード見てもらった方が早いかとー。
- GitHub - close-to-2

参考にさせていただいた記事はこちらなど
- JavaScriptで要素がオブジェクトの配列を日付や数値でソートする方法
- JavaScriptで重複排除を自分で実装してはいけない（Setを使う）

課題

React Hooks のこととか、もうちょっとわかったら、全体的にもっとスマートに書けるんでしょうかね...。なんかごちゃついてる感。

OGP はやっつけで5分くらいで作りました(笑)

Twitter シェアボタンは、公式のものを SPA で使うには少し工夫がいるということで、なんかうまくいきませんでした...。
なので今回は React Share を頼りました。
本当は Twitter アイコンとともにツイートと書かれたボタンにしたかったのですが、React Share だとできないっぽい？ということで妥協することに。

今回参加してどうだったか

楽しかったですが、前回以上にてんやわんやしてたなぁと(笑)
特に最後の方。まぁ、自分が前半悠長にやってたせいなんですが。

Twitter シェアボタンを導入したおかげて、遊んでくださってる方の存在を確認することができました。
確認できるとやはり嬉しいですね！

他の方の投稿を見るのも楽しい + 勉強になりますし、こういったイベントに参加するのはいい経験になりますね。
web1week はほどよくゆるい感じの雰囲気があるので、敷居が低くて参加しやすいなと。
また開催されることがありましたら、余程忙しくない限りはなるべく参加していきたいなーと思います。

ありがとうございました！

参考リンクまとめ

好きな楽曲について語り合うウェブサービス「musico」を作ってみました。

2020-06-05T19:26:08+09:00

突然ですが、先々週に行われたweb1weekという1週間でウェブアプリを作って公開するオンラインハッカソンに参加しました。

（5/18～5/24）１週間でWebサービスを作るイベント - お題「Like」

と、言いたいところだったのですが、実は2日目以降、家庭内のインシデント対応やそれに起因する自身の体調不良で、全く開発を進めることができませんでした（汗）

昨日あたりから、体調含めて状況が落ち着いてきたので、遅ればせながら開発を進め、ガっと最低限の所まで作り込み、勢いでドメイン取って公開してみました。

以下、今回開発したウェブアプリについて。

お題は「Like」でしたので、好きな楽曲についてあーだこーだ語り合えるサービスを作ってみました。

「musico | find track you like and talk about it」（何故か英語ｗ）

フリーワードで楽曲を検索して、その楽曲にLikeやコメントをすることができます。

現時点での機能は以下、

未ログイン時

楽曲を検索、またはコメントがある楽曲リストを閲覧できる
楽曲のコメントページを閲覧できる
楽曲のプレビュー再生ができる（ファイルがあるもののみ）
Spotifyで楽曲を聞くことができる（別タブでウェブ版を表示）

ログイン時

上記に追加して、
- 楽曲にコメントできる
- 楽曲にLikeできる

動作ムービー

https://youtu.be/sDVK6O61_S0

各楽曲、コメントごとのページをSNSにシェアすることも出来ます。

https://musi-co.fun/tracks/6K53GM9W6Vle5KBwGFVnZM

開発時の様々や動機はなどは下記のハッカソンのボードに書きました。
https://crieit.net/boards/web1week-202005/musico

技術的なこと

技術スタック的にはFirebase+Vuejs（Nuxtjs）という、マネージドなサーバレス環境とコンポーネント思考なリアクティブフレームワークを組み合わせたJAMstackな流行りの構成です。

最初はホスティングにNetlifyを選択したのですが、SSR周りやFirestoreなど他に使ってるサービスとの兼ね合いも考えて、Firebase全乗っかりな構成にしました。

UIは最近良く使ってるBulmaのコンポーネントをほぼほぼそのまま使ってる感じです。

本業ではAWSがっちり使って、コンテナとかサーバレスとかマネージドサービスを組み合わせたサーバサイド寄りの開発が多いので、個人開発ではフロントエンド寄りの技術を選定しがちですね（汗）

あんまり凝ったことはしていないのですが、開発時に得た知見は今後すこしずつ書いていこうと思っています。

それではまた。

PS.

祝Crieit初投稿！！

ハッカソンイベントで、React Konva製のジグソーパズルっぽいパズルを作ってみた

2020-05-29T13:19:06+09:00

個人開発って何作るか悩んだり、モチベを保つのが難しかったりしますよね。
そんな自分が、先日web1weekというイベントで個人開発にチャレンジしました。
何とかリリースまでできたので、使用した技術やどんなことをやったのかといった内容を残しておきます。

はじめに

web1weekって？

簡単に言うと「1週間でお題に沿ったWebサービスを作ってみよう」というイベントです。
当コミュニティ Crieit の運営者である、だらさん主催で行われました。

5/18～5/24の1週間でWebサービスを作るイベントです！　Hello worldレベルのサービスでもOKですのでぜひご参加をお願いします！ #駆け出しエンジニア仲間が多い方は是非シェアもお願いします～お題は「Like」です。 https://t.co/ORZQGb6Yu2 #Crieit #web1week #StayHome
— だら🎄サービスづくりひたすら (@dala00) May 17, 2020

参加しようと思ったきっかけ

主な背景としては
- 個人開発に使える時間があった
- 前回の開催時も面白そうと気になっていた（今回は2回目の開催）
- 個人開発をやってみたかった（+こういったイベントならモチベも保てるかなと思った）
といった感じです。

個人開発は以前からやりたいと思うことはありつつ、結局モチベが続かなくて止めてしまったりということが多かったのです...。
もし何か作ることができたら、1つの実績にできて自分の財産になるかなーと思いました。

これは...やるしかない。

ということで参加。

自分が作ったもの

Jigsaw Like Puzzle

ちょっとしたパズルを作りました。
PC向け。スマホ対応は現状してません。

なんでパズル？

イベント記事への投稿にも書いていたので引用します。

「Like」ということで
好きなもの → 趣味とかかな？ → 絵を描くこと（最近全然描いてないけど） → Canvasでお絵描き実装ができるらしい → でも、ただ絵を描くだけじゃつまらない → もしかしてジグソーパズル作れそう？といった感じで行きつきました。

ジグソーパズル特有の形は再現できてないので、あくまで「ジグソーパズルっぽいもの」ですね。
完全に後付け理由ですが、Like って「～ようなもの」って意味もありますし、意図せずテーマに沿ったものになりました（笑）
こんなことあるんですねー。

構成

構成図描こうかなとも思ったんですが、大した構成でもないのでざっくり文面で書きます。

開発はDockerのNode.jsコンテナで。
本番はFirebase Hostingでホスティングしています。

使用した主なライブラリはこちら（正確には他にもあります）
- React：言わずと知れたUI構築ライブラリ（create-react-appで導入）
- React Konva：Canvasを扱うライブラリであるKonva.jsのReact版
- React Router：ルーティング
- Material UI：UIコンポーネント集
- PropTypes：propsのバリデーション
- ESLint：静的解析
- Prettier：コードフォーマッター

基本的なUIはMaterial UIで構築しました。
Boxコンポーネントがすごい便利でしたね。おかげであまりCSSを書かずにすみました。divがその分増えましたが。
パズル部分はReact Konvaで構築しています。

React KonvaとFirebaseについては初めて使ったので、まだまだちゃんとわかってないことも多いです。

どんな感じで開発してたのか

ざっくりこんな感じでした。

1日目：5/18(月)

お題に沿って何を作るか案がなかなか出てこなかったです。
React Konvaに行きついてからドキュメントをひたすら読んで、夕方くらいにやっとパズルいけるかも？ってなりました。

2日目：5/19(火)

午後からやっと手元の環境で動かしてみました。
色々試してみて、なんとなくいけそうかな？という手ごたえがありました。

パズルっぽいものを作成チャレンジ。 #web1week pic.twitter.com/JL4D2noURE
— よし (@yoshi44_lion) May 19, 2020

ただ、そこからパズルの元となる画像の適切なサイズ割り出しに時間かかりました...。3パターンできれいに割れて、適度な大きさのサイズがいいよねってなりまして。

3日目：5/20(水)

ようやく画像サイズを決定。

720 * 480
初級：120 * 120 → 6 * 4 = 24
中級：80 * 80 → 9 * 6 = 54
上級：60 * 60 → 12 * 8 = 96

その後、ストップウォッチの実装をどうやるかめっちゃ悩みました...。
記事を参考にしながら試すも、うまくいかずドはまり。
時間かかりつつも一応実装できました。

この時点でいまだにリポジトリを作っていなかったので、とりあえず作成だけ。

4日目：5/21(木)

ルーティングやOGP、画像の取り扱いをどうしようか悩みました。
結果的には、最低限遊べるレベルのリリースができればいいやということで、一旦は妥協することにしました。

午後からやっとプロジェクトのセットアップ。
Issueやプルリクのテンプレ、Dockerで開発環境構築ともろもろ必要な準備を整えました。

ピース位置チェック（正解位置に置かれたらはまる）のやり方がなんとなくわかって、よーし作っていくぞーという流れへ。

5日目：5/22(金)

パズル画面に背景テクスチャをいれようとしましたが、迷ったので結局止めました。

黙々と進めて、ぼんやりとしたイメージで作っていった画面のモックがおおよそできました。

やっとモック的なものができた #web1week pic.twitter.com/r9GK4fwEuM
— よし (@yoshi44_lion) May 22, 2020

モックに続いて、難易度選択モーダル、ピース生成ロジックを作成。

6日目：5/23(土)

ポーズモーダル、クリアモーダルを作成。

ここまでで、とりあえず最低限遊べることは確認できたのでリリースすることに。
コンポーネントを多少分けてはいましたが、ファイル分割とか全然できてなかったので、そこまでリファクタやってからリリースするかとも考えたのですが、もうやっちゃえとなりました。

ホスティングに関しては、多少慣れてるNetlifyでやる手もあるなと思いました。
ただ、今後機能拡張していくとしたらFirebaseの方が色々やれてよさそうと思い、こちらにすることにしました。

リリース（v0.1.0）して投稿。
リリースと言いつつ、色々と足りてないものがまだあるのでプレリリースみたいなものですね。

パズルリリースしましたー。 https://t.co/028WAbS7W9 よかったら遊んでみてください。 PC向け。簡易的なものなので、クオリティはご容赦ください🙏（5/18～5/24）１週間でWebサービスを作るイベント - お題「Like」 - Boards の投稿 - Crieit https://t.co/FldwX4odRN #Crieit #web1week #StayHome
— よし (@yoshi44_lion) May 23, 2020

おおよそどんなことをやっているのか

ソースコードはリファクタやったりして変わる可能性があるので、リポジトリ見ていただいた方が確実かもしれません（あまりきれいなコードではないですが...）
一応、Issue書いたりしながら進めました。
- GitHub - jigsaw-like-puzzle

以下の内容は執筆時点（v0.1.4）での実装のものとなります。
有識者の方からすると、この実装イケてないとかあると思いますがご容赦ください。

ストップウォッチ

概要

setInterval()とclearInterval()を使って実装。
恥ずかしながら自分はこの関数を使用したことがなかったこともあり、最初はストップウォッチってどうやって実装したらいいんだろう？という状態でした。

実装のやり方についてはこちらの記事をとても参考にさせていただきました。
- 【1から始めるReact】ストップウォッチを作る

1秒ごとに秒数カウントを+1して、その秒数カウントをもとに時、分、秒を計算して更新していくというものです。

問題点

同画面で開始と停止を行う上では問題なかったのですが、今回の場合は
- パズル画面の「一時停止」ボタンを押す → ストップウォッチを停止してポーズモーダルを開く
- ポーズモーダルの「復帰」ボタンを押す → ポーズモーダルを閉じて、ストップウォッチ再開

という仕様だったので、再開時に時間が最初からになってしまう問題が起きました。

秒数カウントはstateで管理してない変数だったので、再レンダリング時に値がリセットされていたんだろうなと。
そのため、秒数カウントの値をバックアップを取っておく感じでstateでも保持するようにしました。
1秒ごとの更新処理の際に、秒数カウント（変数）が0 だったらstateを確認して、バックアップがあればそこから復元するイメージです。

秒数カウントを最初からstateで管理すればいいのでは？となるかもしれませんが、stateでやるとうまく動いてくれなかったので、こういった形をとりました。

パズル

概要

React Konvaで実装していますが、その実体はCanvasです。
Canvasを扱うKonva.jsというライブラリがあり、そのReact版だそうです。

Canvasを扱うにはKonva.jsが便利らしいみたいな記事は複数見かけたんですが、自分はCanvas自体を使ったことがなかったため、いまいちピンとこず...。
なので、最初はひたすらドキュメントを読んで、おおよそどんなことができるものなのかを見ていきました。
その結果、パズルいけそうだなという目途がついたので使ってみたという背景があります。

Konva.jsの構造としては、以下のようになっています（公式より引用）

Shapeは複数種類があり
- Rect（長方形）
- Circle（円）
- Ellipse（楕円）
- Line（線）
- Image（画像）
- Text（テキスト）
- Star（星）

などがあてはまります。

これらは上位の要素を基準とした x、y座標であったり、横幅、縦幅、色、影などを指定することで、Canvasに描画をしていけるようになっています。

パズルの元画像

Imageコンポーネントを使用。
普通に画像パスを渡すのではダメらしく、use-imageライブラリのuseImageフックを使って生成した、DOM画像を渡すようにしています。
- GitHub - use-image

ちなみにピース数の計算との兼ね合いで、画像サイズおよびこのImageコンポーネントのサイズは 720 * 480 で固定しています。

パズルの額縁

Lineコンポーネントを使用。
4つの点の座標を指定して繋ぐことで図形を描画。これを上下左右で4つ作成しています。
ただの塗りつぶしだと安っぽくなるので、グラデーション指定にしてみました。

パズルのピース

Imageコンポーネントを使用。
useImageフックによる DOM 画像を渡しているのは同様ですが、cropを指定することで画像の切り抜きをしています。

例として初級の場合であれば、ピースサイズは 120 * 120 なので
1行目
- {x:0 y:0 width:120 height:120}
- {x:120 y:0 width:120 height:120}
- {x:240 y:0 width:120 height:120}
.
.
.

2行目
- {x:0 y:120 width:120 height:120}
- {x:120 y:120 width:120 height:120}
- {x:240 y:120 width:120 height:120}
.
.
.

みたいな感じです。
合わせてコンポーネント自体のサイズも 120 * 120 を指定になります。

draggableを有効化してドラッグアンドドロップができるように。
そのうえ、onDragStartとonDragEndでイベント処理を実装しています。

ピースドラッグ時の挙動

scaleを変えて、少しだけピースが大きくなるようになっています。
（公式デモのコードそのまま持ってきた感じです）

それに加えて、ドラッグしているピースが必ず最前面に来るような処理をしています。
Canvas要素は、あとに定義したものが前面に来るようになっているようです。
そのため、この処理をやらないと場合によっては、はめ込まれたピースの背面にドラッグ中のピースが隠れてしまい操作不能になってしまうことがあります。
そんなことなったら一気に萎えちゃいますよね。

ピースドロップ時の挙動

scaleを元に戻します。durationも設定してるので、ポヨンと大きさが戻るような見た目になってます。
（これも公式デモのコードをそのまま持ってきた感じです）

加えて、ドロップされた座標と正解位置の座標を比較。
誤差の範囲内であれば、draggableを無効 + ピースの座標を正解位置の座標に更新することで、ピースがはめこまれるような挙動を実現しています。
この処理はこちらの公式デモを参考にしました。
- Konva.js - Animals on the Beach Game

ゲームの流れ

これまでの内容を踏まえて、ゲームの流れとしてはおおまかにこんな感じです。
（並列で処理しているところもあります）

難易度選択
↓
難易度に応じたピース数（縦、横）、ピースサイズの値をセット
↓
この3つの値の変更を検知して、初期化ロジック実行
ピースの情報を持ったオブジェクトの配列を生成後、その順番をシャッフル
↓
ピースの情報を持ったオブジェクトの配列をもとにピースのコンポーネントが描画される
↓
ゲーム開始（ストップウォッチ開始）
↓
ピースのドラッグアンドドロップ
ドロップ座標が正解位置の座標の誤差範囲であればはめこまれ、正解ピース数が+1される
（これを全てのピースがはめ込まれるまで繰り返す）
↓
正解ピース数の値の変更を検知して、総ピース数と一致すればクリア（ストップウォッチ停止）

今回参加してみてどうだったか

楽しかったです！ただ、疲れました（笑）
お題があったとはいえ、ほぼ一から自分で考えて作る必要があったので、普段よりもいっぱい頭使ったからかなと思います。

とはいえ、個人開発として無事にリリースまでできたのはこれが初めてなので素直に嬉しいですね。
他の方の投稿を見るのも楽しいですし、学ばせていただく機会にもなりました。
こういった機会を設けてくださり、ありがとうございました！

ちょっとしたレポート記事を書くつもりがすっかり長くなってしまいました...。
ここまで読んでくださった方、ありがとうございます！

パズルの方は今後も合間を見つけて改修していこうかなと思ってます。
ちなみに最初に導入したGoogle Analyticsがちゃんと動いておらず、投稿時のアクセス数を見られなかったというヘマをやらかしていましたが、修正して現在は無事に動いてます（冷や汗）

もしお暇な時があれば、パズル部屋を覗いてみてください。

参考リンクまとめ

とっさのスピーチ力とか説得力を培うことのできる、A is like Bゲームを作りました

2020-05-25T01:34:59+09:00

とっさに誰かを説得しなければならなくなったり、何かを伝えなくてはいけなくなるような状況って結構ありますよね。
そんな力を培うことのできる練習ができるようなサービスを作りました！

お題をランダムに出題させ、それの回答を書いて、
Twitterにシェアしてみてください！（140文字以内じゃないとツイートできないと思います！）

ゲームはこれです↓↓
A is like B ゲーム

初の #web1week チャレンジです！　完成できてよかった。

このゲームはなに？

とっさの場面、上司やお客さんからの新しい話を聞いたとき、さっと主張しないといけない場面なのに、
何を言えばいいのか思いつかなかったり、考えるのに時間がかかってしまったり。。。
そんなことって、よくありますよね。

この「A is like B ゲーム」は、英語ディベートをやっていた学生の頃、私が先輩に教えてもらった方法です。
「A is like B」、つまり「AはBに似ている」、もしくは「AはまるでBだ」、という主張を、とっさに考えて言葉にする練習ができます。
よく大学への行き帰りの自転車をこぎながら、ぶつぶつとこの練習をしていたことを覚えています。

私が学生時代にやっていた英語ディベートは「パーラメンタリーディベート」といって、
いわゆる長期間文献を調べて臨むディベートとは違い、その日、その場でお題が出題されます。
20分ほどの準備時間で何を主張するのかを準備して臨むのです。

そのため、思考の瞬発力と、豊かな表現力が求められます。
真面目に練習しなかった私はとても弱く全然勝てませんでしたが、練習は楽しかったです。

意外と知られてない方法？

ネットで検索してみると、「A is like B」というワードはおそらくなさそうでしたので、
もしかすると、くだんの先輩が作った練習方法なのかもしれませんが、
この練習は非常に基礎練習として有効だなぁと思っていました。

開発について

今回、 #web1week のお題が「like」ということもあり、
天の邪鬼ワタクシ、シンプルにいいねやスキの意味のlikeではなく、
「～のようだ」「まるで～だ」という前置詞のlikeを採用してみました。

今回は使い慣れたNuxtを利用し、またNetlifyにホスティングしてます。
本当はデータベースと連動させていろいろやりたかったのですが
Firebaseの設定がどうにもうまくできなかったので、こちらも使い慣れているNetlifyにしちゃいました。

今後、まだまだ直したい改修予定としては、
ログインできたり、記録できたり、また時間制限などを追加したいと思っています。

まずはTwitterに投稿できるシステムだけつけてみました。
楽しみながらスピーチの練習や、説得力の向上をしていただけたらと思います。
ありがとうございました。

りんご

A is like B ゲーム

敗者のweb1week

2020-03-22T17:10:52+09:00

先週行われた web1week。
初開催にも関わらず50を超えるサービスが登場し、大盛況のうちに幕を閉じた。

経験者ならば理解を得られると思うが、個人開発という舞台には魔物が棲んでいる。
着手時点で思い描いた予定などペロリと喰われてしまう。

不意に削られる作業時間。
理想と妥協の狭間で揺れる要件。
技術仕様の落とし穴。
サービスの意義を自問自答し続ける日々。
リリース直後に訪れる無慈悲な障害。

これらを乗り越えローンチされた個人サービスの奥には、語られることのない物語が潜んでいる。
そんなサービスが50以上も並ぶweb1weekのボードは圧巻で、たとえHello Worldの様なサービスでも私の心を踊らせてくれる。
とても甲乙など付けられない。

しかし「敗者」は存在する。
「web1week楽しみ！」と方方で意気込みを語り、「やってみませんか？」と様々な人を勧誘した挙句、あろうことか最小限の機能でさえ1weekに間に合わず、最終的には要件すら満たせなかった。
紛うことなき「敗者」だ。
個人開発界隈ではよく「リリースすることが大事」と言われている。その通りだ。リリースさえすれば勝ちなのだ。

これは、そんな勝負に敗北を喫した男の記録である。

立案

月曜の午前0時、お題「Home」が発表された。
こじつけでも何でも「Home」を絡ませたWebサービスならクリアとのこと。
初学者でも参加し易いうえに、CGMやIoTを絡めたサービスも構想でき、かつ疫病の脅威に怯える時勢に寄り添った素晴らしいお題だと思った。
それと同時に頭を抱えた。
１週間で作り上げるとなると出来る事は限られている。ピンと来るアイディアが何も思い浮かばない。

「自分が実装してみたい機能」というアプローチで考えてみる。
我が家にはGoogle Nest Hubというガジェットが存在する。ディスプレイ付きスマートスピーカーというイロモノだ。
スマート家電のような贅沢品は存在しない我が家だが、昨年の私の誕生日に妻から贈ってもらっていた。しかし、動画を見るにはタブレットやテレビに転送で事足りるし、BGMをかける風習も無い。なかなか使う場面が訪れなかった。
これを何とか活用できないか。

玄関や冷蔵庫に貼ってるホワイトボード。これをNest Hubで代用できないかと考えた。
「いってらっしゃい」「おやつにわらび餅を冷蔵庫に入れてます」の様な、家族間のメッセージは手書きの方が嬉しかったりする。
しかし、ホワイトボードのデメリットはホワイトボードの場所へ行かないと書けないことだ。
仕事中に「冷蔵庫にわらび餅入れてるの忘れてた！」となった場合、LINEに頼るしかない。
スマホから手書きでメッセージを書き、玄関やリビングに置かれたNest Hubに表示されたらエモいのでは。

Nest Hubで表示するWebアプリについて調べてみる。
どうやらInteractive Canvasというフレームワークで実装するらしい。
しかし、基本的にVUI（音声ユーザーインターフェース）が前提となる作りで、ストアへ並べるにはGoogleの承認も必要となる。
今回の要件・納期では厳しい、、

方針を変える。
Nest HubにはGoogle Photosにあるアルバムを選択して、フォトフレームとして表示する機能がある。
Nest Hub側でメッセージ画像を入れたアルバムを選択して、Webサービス側ではそのメッセージ画像を更新すれば良いのはないだろうか。
調べてみた。さすがGoogle様。ちゃんとGoogle PhotosのAPIも存在する。

これでいこう。

WebサービスにGoogleアカウントでログイン
手書きUIのCanvasでメッセージを書く。
Nest Hub表示用のアルバムをGoogle Photosに作成
Canvasを画像化して3.のアルバムにアップロード
既にメッセージ画像が存在する場合は削除（アルバム内の画像は1枚のみとする）
Nest Hubで表示

OAuth2認証をクライアントで完結できれば、DBすら不要。
この程度なら1週間でいける。

市場調査もしてみた。

スマートディスプレイ（ディスプレイ付きスマートスピーカー）がどれぐらい普及してるのか気になるのでアンケお願いします！持ってるか持ってないか。押し入れで眠っててもOKです！
— きんみ | ツイッター大喜利サイト🎍ついぎり🎍作りました🙄 (@_kinmi) March 9, 2020

うん、Nest Hub専用サービスは良い感じのスキマ産業のようだ（強がり）

Nuxt.jsでプロジェクトを作成して今日の作業は終了。
この時点で月曜の夜。順調だ。

裏の目的

常々思っていたのが「もっと手軽に画像アップロード機能を作れないか」という事だった。
画像アップロードというのは、ストレージを用意して、アップされる画像の最適化処理を組み、著作権の侵害等を考慮して規約や同意UIの設計をしなければならない。
リリース後は不適切な画像が上がってないかウォッチする義務が発生するし、ストレージの残容量も気にしなければならない。
更に、増え続ける画像の管理方法（一定期間で削除するか、お金で解決するか）も検討しなければならない。
個人開発において、割とコストが高めの機能だ。

この課題はGoogle Photos等のユーザーが保有するクラウドストレージに公開状態で保存すれば解決するのではないかと考えた。
このご時世、Googleアカウントは誰でも持っている。アカウント登録時に自動で付与されるGoogle Photosの容量は高画質モードなら無制限だし、あくまで「画像を公開しているのはユーザー」という体裁を繕えるので著作権問題もグレーゾーンとなる（漫画村方式）
サービス側で保有するのは画像の静的URLのみだ。

今回、Google PhotosのAPIを使いこなせる様になれば今後の個人開発に幅を持たせることが出来るかもしれない。

ハマる

コロナ自粛の影響により勤務時間が削減され、個人開発の時間は比較的多めに取れた。
それでも間に合わなかったのは全てにハマったからだ。
全てだ。
時系列でハマりポイントを紹介していく。

JS ClientSDKが使いづらい

Google APIをWebで利用する場合、Google API Client Library for JavaScript（GAPI）というライブラリを利用する。
Initial Commitは2011年。それなりに年季の入ったライブラリだ。

NPMには登録されていない。

scriptタグで読み込む必要がある。
Nuxt.jsで外部スクリプトを使用する場合、$nextTicks()を用いてもスクリプトのロードが完了していない場合がある。
ロード状態を監視する必要があるので少し手間だ。

DiscoveryDocs

GAPIのスクリプトを読み込んだ時点ではinit()等、最低限の機能しか保有していない。
Getting Startedに記載されているが、API Key等を設定して初期化する際にDiscoveryDocsというURLを設定する。
DiscoveryDocsはAPI単位で用意されており、URLの先にあるJSONをGAPIでロードすれば機能として利用できる。
Google Photos APIのDiscoveryDocsは下記となる。
https://content.googleapis.com/discovery/v1/apis/photoslibrary/v1/rest
スクリプトの肥大化を防ぐための機構だろう。
ここまではまだ良い。手間を感じるがまだ許せる。

同期処理

ドキュメントのサンプルはthenチェーンで記載されている。
じゃあ・・・と思ってasync / awaitで書き直してみる。動かない。
そう、返却値はES6 Promiseじゃない。
goog.Thenableという独自インターフェースを継承したオブジェクトだ。
init().then(()=>{ }) の中でしかGAPIは動かない。同期的にいくつものAPIを使いたければthenのネストを深め続けるしかない。F*ck。

ES6が標準化されたのが2015年。このライブラリの開発当初ならスマートな仕様だったのだろう。
しかし、こちとら去年からJSを学び始めた身。
終始、この仕様に慣れず生産性が低下した。

認証で躓く

ユーザー管理にはFirebase Authenticationを採用した。
手軽に導入でき、「特定のユーザーには使わせない」といったセキュリティ対策も出来る。
Twitter API等、他社のAPIと連携する場合はトークンの保管といった一手間が必要になってくるが、今回はGoogle Platform内で連携するだけ。
簡単だろうと思った。

🙅 Firebase → Google API

以下の記事を参考に、Firebase UIでログイン→GAPIのイニシャライズを試みる。
Using Google APIs with Firebase Auth and Firebase UI on the Web

できない。
この記事ではFirebaseでログインした時点で GAPIの認証状態 : gapi.auth2.getAuthInstance().isSignedIn.get()が true になる想定だが false だ。
GAPIでもログインする必要があるのか？と思って試したがFirebaseとGAPIで二重ログインされてしまった。

記事のコメント欄に記載がされているが、現在はFirebaseでログインしてもGAPIでログイン状態を検知しない。
下記のissueにもその事が記載されており、ステータスはopenのままだ。
https://github.com/google/google-api-javascript-client/issues/561

🙆 Google API → Firebase

つまり現状、FirebaseとGAPIを連携するには認証順を逆にしないといけない。
GoogleAPIのサインイン : gapi.auth2.signIn()でログインした後、認証情報を取得して Firebaseの認証情報を使用したサインイン : firebase.auth().signInWithCredential()でもログインするフローとなる。
下記の記事を参考に実装した。
How to Use Google APIs on the Web

進捗：だめです

この時点で既に平日は終わっていた。残すところは土日のみ。
対応が長期化した要因は「出来ると書いてあったから」。
Firebase→GAPIの認証は不可能という可能性を考慮していなかった。
この考慮漏れが発生するとプログラマーの思考はどうなるか。
ひたすらタイポを探し続けるのである。

画像アップロードが用意されてない

まだ間に合う。
土曜にアップロード機能を実装。
日曜にデザインを微修正＆実機で動作確認。
ここまで盛大に躓いて尚、根拠なく「出来る」と盲信する。
進捗が遅れてるプログラマーにありがちな逆算スケジュールである。

🙅 GAPIで画像アップロード

ガイドラインを読んでみる。
https://developers.google.com/photos/library/guides/upload-media
どうやら画像をアップロードするには、二段階の手順を踏まないといけないようだ。

画像のバイナリデータをGoogleにアップロードする
上記返却値に含まれるアップロードトークンを用いてアルバムに追加する。

Google PhotosのDiscoveryDocsから該当のメソッドを探してみる。
無い。
何度検索しても「uploads」という処理は無い。
「なぜ無いのか」なんて考える余裕も無い。
（現在、不安になって再度探してみたがやっぱり無い）

GAPIじゃGoogleに画像をアップロード出来ない・・・？

🙅 axiosでリクエスト

悩んでいる暇は無い。もうクライアントSDKは捨てる。
ドキュメントにはエンドポイントが記載されているので、そこに対してaxiosでPOSTリクエストを投げてみる。

Network Error.

・・・久し振りに見たぜ。
has been blocked by CORS policy: No 'Access-Control-Allow-Origin'
CORSエラーだ。
おいおい、嘘だろ。CORSだと？
浅学だが、基本的にはAPI側での対応が必須だったと記憶している。詰んだか？

🙅 XMLHttpRequestでリクエスト

ドキュメントには「CORSもサポートしているよ」と書かれている。
How to use CORS to access Google APIs
クライアントSDKを用いれば回避できるよ。と。
使えねぇんだよチクショウが。
記事の最後にXMLHttpRequestを用いた例も記載されている。
存在は知っていたが初めて使うなこれ。
愚直に書いてある通り組んでみる。

has been blocked by CORS policy: No 'Access-Control-Allow-Origin'

泣く。

🙅 gapi.client.request()

まだだ。諦めない。
俺は長男だから我慢できたけど次男だったら我慢できなかった。

ドキュメントを漁り、もう１つの可能性を見つける。
クライアントSDKには標準で APIを叩く為のメソッド : gapi.client.request()が備わっている。
GoogleAPIのエンドポイントをベタ書きして引数に渡せば叩けるらしい。
クライアントSDKならCORSを回避できるんだろ？信じるぞ？
叩いてみる。

404

？？？
タイポ探しフェーズ（数時間）に入るも、やっぱり問題は無い。
リクエスト内容を確認した。POST先のURLが変わっている。
画像アップロードのエンドポイントはhttps://photoslibrary.googleapis.com/v1/uploadsだが、ドメイン部がcontent.googleapis.comに変わってる。
なんだこれは。
恐らく、クライアントSDKが書き換えていると推測。M*ther F*cker。

諦めた。

クライアントで完結することを。

🙆 Netlify Functions

ホスト先にNetlifyを利用している。
そこでクラウド関数を作れるNetlify Functionsを使ってみようと思い立った。
使った経験が無い機能だ。下記の記事を参考にHello Worldから始めてみる。
【入門】Netlify Functionsコトハジメ
そして「Googleに画像をアップロードしてアップロードトークン返すクラウド関数」を立ててみた。
うまくいった。
初めて使う機能なのに、ハマらず動く。ローカル環境もすぐ出来た。
感動した。モダン最高。

進捗：納期は昨日なので大丈夫です

この時点で日曜の夜。
軸となる機能は一通り完成したものの、「同名アルバムが存在していた場合」などのシチュエーションに応じた分岐は作れてないし、要件として「既にメッセージ画像が存在していた場合は更新する」といった機能も存在するが未実装だ。実機確認もやれてない。

「ごめんなさい」しつつ、月曜に出そう。
そう決めて床についた。

画像の削除/更新はできない

ベットに入った直後、悪寒がした。

見覚えがない。

散々GoogleAPIのドキュメントと格闘し続けたが、Google Photos内の写真を削除/更新するエンドポイントは見た記憶がない。
スマホを取り出し確認してみるも、やはり無い。

冗談だろ？クラウドストレージを操作するAPIのくせに削除/更新は出来ない？そんな馬鹿な話があるか。
調べてみる。
https://issuetracker.google.com/issues/109759781
結論：出来ないらしい

詰みです。お疲れ様でした。

過去画像を含めてランダム表示されるなんてホワイトボードじゃない。

「お手数ですがGoogle Photosを開いて、ご自身で過去の画像を削除してください。」
しょーもな。
サービスとして成立していない。

・・・いや、まだだ。

よし、譲ろう。

百歩譲ろう。

Google Driveなら削除/更新もAPIで可能じゃなかろうか。
Photosなんかより歴史あるクラウドストレージだ。
Google Driveへアップした写真をNest Hubで表示できれば問題無い。

Can I connect my Google Drive to my Google home hub?
結論：出来ないらしい

こうして私は、web1weekの敗者となった。

Safari対応（おまけ）

負け犬でも遠吠えぐらいは出来る。
「手書き画像をGoogle Photosへアップするサービス」としてローンチしよう。
そう決めて実機確認に入った。

CORSぞ

MacのChrome、Android Chromeは問題なく動作完了。
妻に「iPhoneでこれ使えるか確認してほしい」と依頼する。
返信は「画面が驚きの白さ」。
ここで初めてMacのSafariでも動作確認してみる。

has been blocked by CORS policy: No 'Access-Control-Allow-Origin'

CORSぞ。

何度立ちはだかれば気が済むのだCORSよ。
まぁ思い当たる節はあった。
GAPIが使い辛いので、下記のようにクラアントSDKを動的に読み込んでplugin化していたのだ。

export default async ({ $axios, store }, inject) => {
  // GAPIの読み込み
  const gapiScript = document.createElement('script')
  const src = await $axios.$get('https://apis.google.com/js/api.js')
  gapiScript.appendChild(document.createTextNode(src))
  document.head.appendChild(gapiScript)
  const gapi = window.gapi

  // ロード処理(Promise化)
  const clientLoad = new Promise((resolve, reject) => {
    gapi.load('client:auth2', () => {
      resolve()
    })
  })
  // GAPI初期化処理
  const init = () => {
    return clientLoad.then(() => {
      return gapi.client.init({
        apiKey: authConfig.Google.apiKey,
        clientId: authConfig.Google.clientId,
        discoveryDocs: authConfig.Google.discoveryDocs,
        scope: authConfig.Google.scopes.join(' ')
      })
    })
  }
  inject('gapi', gapi)
  inject('gapiInit', init)
}

不安はあったが、動いたのでそのままにしていた。
外部スクリプトを動的に読み込む場合、普通はCORSの問題が発生する。
素直にscriptタグで読み込むように変更した。

というか、なぜChromeでは読み込めたのか分からない。
同じGoogle製品だから？
プラットフォーマー恐るべし。

クロスサイトトラッキング

さて、初期表示までは問題なくSafariで動作した。
しかしGoogleへログインしても認証状態を検知しない。
プログラムが「ログイン中」と判断しないのだ。
こればっかりは思い当たる節も無い。

issueが上がっていた。
gapi auth2 issue on safari
同様の事象、かつオープンのままだ。
Safariの場合、Cookieを全削除するか、プライベートブラウズなら問題無いらしい。
マジかよ・・・
頑張れば何か対策できるのかもしれないが、負け犬にそんな根性は無い。
UserAgentから「Safari、もしくはiPhone/iPad」を判定して、該当する場合は長ったらしい注意文言を表示するようにした。

敗因

次回以降のweb1weekで勝つための敗因分析を行う。

PoC（概念実証）不足

一番の原因はこれ。
事前に「画像の削除/更新は出来ない」と知っていれば別案を採用していた。
とはいえ、1週間という過密スケジュールで検証工程を取れるかは疑問が残る。
少なくとも、

機能の洗い出し
実装に必要な外部インターフェースのドキュメントはちゃんと読む

まぁ、、当たり前のことはちゃんとしよう。ということ。

「出来ない」の判断が遅い

認証や画像アップロード等、ハマった際に「出来ない」という判断が出来ていない。
昨今の潤沢な開発環境に甘え、「出来ない事は無い」と思い込んでいる節がある。
確かに大抵の場合、ハマる原因は外部インターフェースの仕様変更、もしくはタイポが多い。
塩梅が難しいが、もっと早いタイミングでissueを探そう。

Google Photosを利用した画像アップローダーは作れるのか

冒頭に記した「裏の目的」について。
そもそもGoogle Photos APIの利用規約には「ホスティングサービスとして使うならCloud Storageを使え」と明記してある。
開発するサービスを「Google Photosへアップした写真の共有ギャラリー」という位置付けにするならグレーかな？と思ったが、
結論から言うと「多分、不可」だ。
少なくとも、そう言うサービスを作れるだけのAPIが提供されていない。

まず前述の通り、API経由での画像の削除/更新は出来ない。
あくまで画像のアップロードのみで、アルバム間の移動すら出来ない。

そして、更に致命的なことに静的なURLは取得できない。
写真のURLを取得するAPIは存在するが、一定期間が過ぎると無効化されるらしい。
これはGoogle Photosの「URLで共有する」と同じURLなのだろう。
URL先には静的な画像が埋め込まれているらしいが、それを取得するAPIは存在しない。
スクレイピングを駆使すれば取得できるかもしれないが、実用的では無いだろう。

「ユーザーのプライベートストレージを用いた画像アップローダー」は別サービスを検討した方が良さそうだ。

ゴミを公開する

これはweb1weekじゃない。
私が作りたかったものでもない。
ゴミだ。

Nest Board
https://nest-board.netlify.com/

Google APIは申請無しで使用できるが、Googleから承認されていない場合、ログイン時に警告画面が出る。
利用する際は注意文言を読んで頂きたい。

需要あるか分からないが、Nest Hub側で表示する際の手順も明記しておく。

1. スマホ（iPhone/Android）でGoogle Homeアプリを開く
Nest Hubの初期設定に必要なアプリなのでインストールされているはず。

2. 表示したいNest Hub > フォトフレームを編集 > Google フォトの順で選択

3. Nest Boardで作成したアルバムを選択する
初期値は「Nest Board」

4. 「フォトフレーム」画面の下部にある「個人的な写真の整理」を「リアルタイム共有アルバムのみ」にする
これを設定しないとNest Hubがフォトフレームに不向きな写真と判定して表示されない。
ハマりポイント。

以上の手順を踏めば、Nest Hubに手書きのメッセージ画像が表示される。

普段はソースコードを公開したりしないのだが、今回はリポジトリをpublicにした。
なぜなら敗者だからだ。
https://github.com/kin-mi/nest-board

おわり

次は勝つ。

(改良版)パワプロ風画面ジェネレータを作ってみた

2020-03-14T22:03:11+09:00

作ったサービス

https://pawapro-gen.netlify.com/

一旦書いたボード

web1week - パワプロ風画面ジェネレータを作ってみた

時間的に残りの機能間に合わないかと思っていたので、最低限動く機能で出したのですが、結論から言うと間に合いました。

インライン編集機能

当初はフォームとプレビュー機能を分けて作っていたのですが、
ほとんど全てインラインで編集できるように変更しました。

twitterシェア機能

OGPサーバの構築

以前slack流量計を作った際に、web表彰のスクリーンショットを撮っていたので、OGP作成にはそれほど抵抗はありませんでした。

あとはだらさんの作成されてるOGPサーバを参考にさせていただきました。

OGPサーバの構築に使った技術

NodeJS
Express
TypeScript
puppeteer
VPS
docker-compose

ロジック

ジェネレータからDBにデータを登録する
登録されたデータをもとにpuppeteerでスクリーンショットを撮る
DBに画像を格納する
OGPのサーバ問い合わせにはDBに保存してある画像を使用する
- OGPサーバに直接アクセスさせると負荷が集中してサーバが落ちるため

DB登録処理は既存のAPサーバに追加

OGPサーバは別コンテナ

twitter投稿

アプリ起動時componentDidMountのタイミングでUUIDを生成するようにしました。
react-shareというライブラリを使い、
beforeOnClickメソッドでDBへの登録を行っています。
ローディング画面も作りました(同時にバグ生成)。

{
              store.dispatch(switchLoading(true));
              let isSuccess = await postData();
              store.dispatch(switchLoading(false));
              if(!isSuccess){
                alert('データの保存に失敗しました。時間を空けるか、リロードして再度作成してください。')
                return new Error();
              }else{
                return Promise.resolve();
              }

            }}
          >
            保存してシェアする！

苦労したこと

画像のキャッシュ

ヘッダでキャッシュコントロールしたことがなかったので若干はまりました。

OGPのトリミング問題

twitterやFacebookでOGPの上下左右がトリミングされる問題があり、
Jimpなどで余白の拡張をしようと思ったのですが、時間がなかったこともあり、
React側でマージンをとってスクリーンショットを撮る際に余白ができるように修正しました。

できなかったこと

チーム・選手画像のアップロード

OGPの生成で手一杯だったので、base64化してDBに格納するところまで考えられませんでした。後々追加する予定。