nabettuの投稿 - Crieit

これであなたもエタらない！失敗しない個人開発５か条

2020-12-24T12:34:15+09:00

こんにちは！ちょっと遅れましたがアドベントカレンダー23日担当します @nabettu です！よろしくお願いします。

この記事はこないだのツイートの反響があったので、こちらについて深堀りする記事としたいと思います！

躓かない個人開発５か条- 作らずに済むものをできるだけ作らない- 小さく産んで大きく育てる- 技術習得を目的にせず作れる範囲のものを作る- 最低限自分、もしくは知人が絶対に使うモノを作る- プラットフォームでなく一人でも使えるツールを目指すこれを守ればエタらない！始めよう個人開発！
— nabettu🍲Notionでサイト制作できるNoCodeサービス開発中 (@nabettu) December 15, 2020

ターゲット

作りたい気持ちはあるし、プログラミングなどは勉強している＆仕事にしているけど、これといったプロダクトを作りきったことが無い方向けです！

作らずに済むものをできるだけ作らない

まずこれ、「完璧を目指すよりまず終わらせろ」って言葉もありますが、それ以前に作らなくて済むものはつくらないのが大切です。

NoCodeで対応出来る範囲も年々増えてきており、IFTTTやZapierでサービス間連携も可能です。

例えば「東京固いプリンカフェマップ」というサービスを作りたいなってなった場合には、Google Splead Sheetでデータを集めてGlideで表示するというものでも、最低限のサービスにはなります。

Google Mapでまとめられていたデータを使って「東京固めプリンマップ」のサイトをGlideで作ったよ

ここから、自分のコードで作りたいなという部分を徐々に作っていくのも手です。

小さく産んで大きく育てる

上記のプリンマップですが、最低限のものをまず作ってしまって、それから欲しい機能を付け足して行きましょう。

Google Formを作ってシートにデータを入れられるように
そのformをサイトに埋め込んだ形にして、静的サイトを自作したり
それからやっとマップを見れるだけのサイトの側を自作して
会員登録機能を作って、お気に入りできるように
現在地からプリンのお店を探したり
プリンに関するレビューを書けるようにしたり

などなど、一気に作ると何ヶ月もかかってしまって挫折しがちですが、1ヶ月1機能を目標！などにしていけば、いつの間にか大きなサービスになっていくのではないでしょうか。

技術習得を目的にせず作れる範囲のものを作る

新しい技術の素振りとしてサービスを作りたいという気持ちもわかりますが、なんだかんだサービスとして出す頃には、新しいことをやらなきゃならない場面が出てくるので、まずは自分が作れる範囲のものを作っていきましょう。

もちろん技術習得をしたい！という方はそっちが目標なので、手段と目的が入れ替わって「出来なかった」と落ち込むことの無いようにしましょう。

最低限自分、もしくは知人が絶対に使うモノを作る

作ったけど誰も使わないサービスというのは作っていて辛いですね。

最低限自分が絶対に欲しいと思っているものを作るようにしましょう。「これ作っても誰が使うんだろう」というモチベーションで続けても辛いだけです。

知人がほしいと言っているものであれば、プロトタイプなどからしっかりヒヤリングして「目的をブラさずに」作っていきましょう。

プラットフォームでなく一人でも使えるツールを目指す

「Twitterのようなサービスを目指すぞ」ってのが結構陥りがちな罠で、ユーザー投稿型のプラットフォームは投稿がなければコンテンツが無いので、ユーザーが集まりません。

ニワトリタマゴですが、そういったサービスは集客が最低限確保出来なければサービスが成り立たないので、まずは「ツール」として成り立つサービスを作るとよいでしょう。

例えば unityroom というプラットフォームがあります。これはUnityで作ったゲームを投稿するサービスなのですが、Unityでゲームを作ってもアプリにしてGoogle PlayやApp Storeに登録しなければ人に遊んでもらえません。

そこを「人にURLを送るだけでWebで遊べる形にできる」ツールとして成り立つサービスとなっています。そこから投稿が増え「いろんなゲームがWebで遊べるサービス」としてプラットフォームが成り立っています。

いきなり投稿を増やすのはなかなか大変なので、その投稿それだけで成り立つツールを作ってみると「閑古鳥がないている悲しいサービス」が生まれにくいのではないでしょうか。

まとめ

この５か条を守ればあなたも小さくとも使われるプロダクトを作れるはずです！

ぜひ楽しい楽しい個人開発の沼へあなたも入ってみませんか。

あなたの個人開発の目標はどこですか？

2019-12-16T12:34:22+09:00

Crieit のなんでも Advent Calendar 2019 12/9を担当するnabettuです。すっかり投稿するのを忘れていまして、今日書きました笑

この記事は個人開発をやっている駆け出しIndie Hackerのための記事です。

個人開発でモチベーションが保てないとか、集客が上手く行かないとか、色々悩みがあると思います。

そもそもあなたはなぜ個人開発をするのでしょうか。

一口に個人開発を行うとしても、その目標が明確になってないので漠然と「5000兆円ゲットしてないから失敗した」という気持ちになってしまうのでしょうか。

ということで今回はざっくり以下の５つのタイプに分けて、目標と達成条件を書いていきます。

技術習得をする・サンドボックスにする
ポートフォリオになるものをつくる
作りたいものをつくる・ライフワーク
自分や知り合いが欲しがっているサービスをつくる
サービス・アプリで生計を立てる

もちろん重複する場合もあるとは思いますが、自分の個人開発が上記のうちのどれなのか考えていただいてから読み進めてください。

技術習得をする・サンドボックスにする

エンジニアの個人開発っぽい目標ですね。OSSやツールを作る人も多いと思います。

仕事は仕事で開発をする前提で、自身のスキル向上のために色々触ってみて、それを何かしらでアウトプットしている形。

このタイプの方は 「使いたかった技術が十分に使えること」 が目標ですね。

「React.jsとFirebaseで認証付きWebサービスを作りたい」となったら、その２つの技術について十分に触ることが出来たら一旦目標達成でいいのではないでしょうか。なのでユーザーが集まらなくても、なんなら 公開できるレベルに達していなかったとしても技術は向上しているから大丈夫！ 仕事に活かしましょう！

次のステップとしては、ポートフォリオになるものに出来たらもっと仕事にも活かしやすくなるかもしれません。

ポートフォリオになるものをつくる

これは前述の技術習得を対外的に見せたいタイプですね。

今後就職・転職活動が控えている人、フリーで仕事を受けることがある人などが、そこで上手く活用できるように、 わかりやすく作ったものを見せられることが大切 です。もちろん社内で「新しいことに挑戦させてもらうための説得材料とする」場合等にも有効ですね。

このタイプの方は 「使った技術がしっかりアピールできること」 が目標ですね。

そのためにはまず

サービス・アプリを公開して誰でも触れる状態にしておくこと
使った技術などをしっかりブログなど解説・まとめておく

といいでしょう。

最近のQiitaではWebサービスを作ったら、使った技術についてまとめつつ集客するという記事が多いのでその波に乗ってもいいかもしれません。十分にユーザーが集まったらさらなるアピールにも繋がりますし。

サービス・アプリ開発を起点に就職・転職が決まったら目標達成ですね。

作りたいものをつくる・ライフワーク

とにかく作りたいものをとにかく作る 。趣味であり、それで収入が得られれば最高のライフワークになるというタイプ。

思いついたらプライベートの時間を削ってでもどんどん作ってしまうあなたは個人開発の申し子です。

このタイプはもう作れたら幸せなので、 作る時間を確保できればOK 、目標とかそういうの自体は必要ありませんね。

しいて言えばそれによってお金が得られてもっともっと開発を行う時間が取れたら言うこと無いですね。なので集客やマネタイズについてもっと力を入れていってもいいのかもしれません。次のステップは開発時間の最大化です。

自分・知り合いが欲しがっているサービスをつくる

「こういうのあったらいいな〜」という声を耳にしたあなたはシャシャっとプロダクト開発に着手します。その人にヒヤリングしながら欲しがっていたものを作ってみましょう。

それが動くようになって 「欲しがっていた要望が満たされた」ら目標達成 です。パチパチパチパチ

とはいえ一人が欲しいと言ってたら、同じような要望を持った方は実は他にももっとたくさんいるはずです。

なので自分・知り合いのために作ったものですが、 どうせならたくさんの人が使っても問題ない形にして公開できると、もっといろんな人を幸せにできるかも しれません。

サービス・アプリで生計を立てる

これを目標にしている人は少なくないと思います。3の「作りたいものをつくる・ライフワーク」の人も、開発時間の最大化を求めたらここに行き着くのではないでしょうか。

目標は 「マネタイズをしっかりやって、生活できるレベルの収入になる」こと でしょうか。それによって好きなことに時間を使えるようになるといいですね。

もしかしたらそこからスケールして起業とかも選択肢になるのかな？個人開発とはまた話が変わってしまいますが。

個人開発はとにかく

小回りが効くこと
自分の人件費を無視するとほぼ出金ゼロでできること
ニッチな市場でも個人の収入には十分なポイントがある

などが企業と比べて有利な点なので、それを活かして進めていければと思います。

まとめ

以上個人開発の目標と達成に関する記事でした。

みんながみんな「個人サービスで生計をたてる」を目指しているわけではないため、その目標を明確にすることで、各々がやることを決めていければと、と思いこの記事を書きました。

この記事によってあなたの個人開発が捗ると嬉しいです。

おわり

cometsを支える技術 ~ Crieit 個人開発サービスに用いられている技術アドベントカレンダー ~

2018-12-13T09:27:14+09:00

こんにちは！渡邊です！

この記事はCrieitでの個人開発サービスに用いられている技術 Advent Calendar 2018 の１３日目の記事です。

今回はcometsというWebサービスについて書きます。

cometsとは

https://comets.nabettu.com

発表スライド上にコメントが流せるWebサービスです。

Google Slideなどでブラウザを利用して発表しているスライドの上に、視聴者からのコメントをリアルタイムに流せるサービスとなっております。

こないだのjs祭りで使われた様子はこちら↓

https://twitter.com/kokushing/status/1063688045327601664

（こくしんよく撮れてる動画ありがとう！）

これを使うとどうなる

普通のスライド発表って発表者の言いたいことを言って終わりになりがちですが、これを使うと一方通行にならずにインタラクティブな発表が出来ます。「リアクション」だったり「質問」などをそのタイミングで見ている人が投げる事ができるのです。

終わった後に「質問ある人〜？」などで聞いてもシャイな人はなかなか手を挙げられないと思います。そこで、cometsがあれば匿名で意見を送る事ができます。

また、QRコード生成機能があるので、cometsの画面で作ったQRコードをスライドに貼っておくとスムーズに共有出来ます。

アンケートを集計するのにも使えます

cometsにはボタンを押すだけで簡単に定形のコメントを送れます。そのボタンの中に🍎や🍌などの果物ボタンが５つあります。

これを使うと、スライドに質問を書いておいて会場の視聴者にそのままアンケートをとれます。

例）発表スライドは何でつくってる？

🍎Keynote
🍊PowerPoint
🍌Google Slide
🍇Slides
🍈Prezi
その他（コメントで）

のようなスライドを作っておいて当日にアンケートを取れます。

アンケートによって話す内容を変えると非常にいい発表が出来ると思います。（「Netlifyについて知らない人が多いみたいだから詳しく話そう」とかとか）

ぜひ取り入れてみてください！

どうやって作ってるの？発表者編

発表者がGoogle Slideを起動している画面で、指定のブックマークレットを実行します。Chromeエクステンションではないので、どんなブラウザでも基本的に機能します。

実行すると視聴者と共有する合言葉を入れる欄が出てくるので、合言葉を入力してコメントを受け取ります。

裏側ではFirebaseのRealtime Databeseを利用して、視聴者がDBに追加したデータを検知して、同じ合言葉のテキストを画面に追加します。

画面に追加されたテキストはCSSアニメーションで右から左に流れていきます。

どうやって作ってるの？視聴者編

コメント画面はNetlifyでホスティングされた静的Webサイトで、画面を開くとFirebaseに匿名ログインして、コメント書いて送信ボタンを押すとFirebaseのRealtime DBに書き込みます。

開くURLには合言葉をパラメータでセットできるので、そのままURLをシェアも出来ます。

Twitterにそのままつぶやくチェックをオンにしておくと、コメントを送ってそのままTwitterの投稿画面に遷移出来るようになっています。その際合言葉はハッシュタグになるので、イベント指定のハッシュタグがある場合にはそれを合言葉としておくといいでしょう。

FirebaseのDBにはFirestoreという上位互換的なものもあるんですが、リアルタイムなデータのやり取りに関してはRealtime DBをFunctionsなどを挟まずに利用するのが早いです。

今後の展望

合言葉が日本語のときにQRコードがバグる
Twitterでハッシュタグのツイートがあったらそのままcometsと同じように流す機能
electronでローカルのスライドツールでもコメントを流せるようにする機能
サイトがBootstrapバリバリなのでモダンなデザインにする

などを、時間あるときにやろうと思っています。

ぜひ皆さんcometsを使って、インタラクティブな発表をやってみてください！

明日はあのnaichiさんが unityroomを支える技術について話してくれます！明日もまた見てくれよな！

読まれる技術記事を書くには？技術記事を書く時のポイントまとめてみた

2018-12-03T01:50:10+09:00

Crieitのアドベントカレンダー３日目です。担当の渡邊がお送りいたします。

みなさん、qiitaや自分のブログ、はたまたCrieitなどに技術記事書いていますか？

せっかく技術記事投稿サイトのアドベントカレンダーなので、技術記事自体を書くことについて書きます。

ノウハウと見せかけて当たり前の事を書こうと思います。

そもそも技術記事って書くべきなのか

エンジニアじゃなくても「情報発信」は大事です。フリーランスじゃなくともそこから仕事につながることもあるでしょう。100%書かないよりは書いたほうがいい。

もちろん仕事をとってくる目的で書いてるなら立派な営業活動なので書くべき。最新情報とかの発信はブランディングになるんですよね〜mizchiさんとかすごい。

そうでない方も、エラーで困った内容とかはできるだけログとして残しておくといいでしょう。どうせ３ヶ月後に同じでエラーが出て自分が読むことになります。笑

とはいえ無理してまで書くのは微妙ではある。コードを書く時間を減らさないように、息抜きレベルにしよう。

せっかくなら読まれたいよね

そしてせっかく書いた技術記事、どうせならたくさんの人に読まれたいですよね。

まず技術記事ってどんな種類のがあるか、分類しました

トレンド発信
困った事をまとめた記事
自分で調べる必要があってついでにまとめた記事
作っていたものを事例として紹介した記事
人に聞かれた事を書く記事
ポエム

それぞれについて、読まれるための大事なポイントを書いていきます。

読まれるトレンド記事

トレンド記事はとにかくスピードが大事！

界隈の人が「お、新しいライブラリが出てるな〜」とか、なんだなんだと言っている３日以内にさっと記事を出しましょう。

そしてトレンド記事は簡潔であることが結構大事。あくまで概要を知りたいって人が中心なので。

そのため「わかった気にさせる」ような内容を書けると「あ〜React hooksね。完全に理解した」って言ってシェアできる。

あとはブログじゃなくてもいいかも。TwitterとかYoutubeでいい場合もある。

困った事をまとめる

これはとにかくエラーログが大事！

できればタイトルにエラーで出る一番重要な文言を入れましょう。

これはそのエラーでググった人がたどり着けるようにです。つまり、書いてすぐ読まれることは期待してはいけません。

あとはそうすると、ググってヒットする必要があるので最低限のSEOが大事！teratailで回答ゼロの質問に負けたりしたら目も当てられません笑

エラーじゃないとしても「〇〇が効かない」とか、ググられそうな形のタイトルにしましょう。

とはいえニッチなエラー文言で記事書いてたら大丈夫な気もします。

自分が忘れたころに過去の自分に感謝することになったりもします。

自分で何かを調べる必要があってまとめた記事

これは網羅性が大事！

比較記事を書くとしてもリファレンス的記事を書くとして、長くなってもしっかり網羅的に書かれていることが大切です。

「これとこれで、結局速度はどっちのが早いんだ・・・？？？」ってなって離脱されるようなことは避けたい

あとこれもSEO大事かな〜そのワードで上位表示してないと読まれないので。

自分で作っていたものについて事例として紹介して書く

しっかり宣伝になるように書くのが大事！

結局その作ったものに人が来てくれないのなら、それ載せる意味ないやん。

理想は「プロダクトローンチ」→「このサービスのここどうやって作ってるんだ！？」→「うわ〜解説記事あるやんなるほどなシェアシェア」ってなること。

ただただ宣伝したいだけの記事はノイズだ〜qiitaじゃないとこに書いてくれ〜

とかこういうの気にしなきゃならないような内容がある記事は自分のブログに書いたほうがいいよ。文句いわれないでしょう。

あくまでqiitaに書きたい時にはちゃんと技術的な内容を中心に書くのよ〜（あたりまえ）

人に聞かれた事を書く

誰かに質問された内容を記事に落とし込む場合。２回も同じ事違う人に聞かれても記事のURLをシュッと出すことでありがたがられる。

これは聞かれた人が満足する内容だったのかどうかが大事。内容について聞いてきた人にチェックしてもらうとより良いかな〜

あとは、聞かれるってことは確実に需要がある記事なので、そういう機会があったらしっかり記事に書いたほうがいいよ。

ポエム

エモさが大事。なにはなくともエモ散らかしましょう。エモさがあれば、あとは何もいらない。裸になるほど読まれますよ。ザッツインターネット。

どこで書くか問題

次にどこで発信したらいいんだ〜っての結構悩みどころですね。

qiita

先程も触れましたが、qiitaはコミュニティなので、公式のコミュニティガイドラインがあります。それにそった記事を書いていれば、ランキング機能だったりSEOもよかったりして結構読まれるようになりますね。困ったらqiitaでいいかも。

自分のブログ

自分で立ち上げたブログなら何を書いても文句は言われません。「技術記事なのかどうか怪しいから」とか迷う必要もない。

ただ、ホスティングを自分でやる必要があるのは正直めんどくさい。笑

しかしそれ自体が技術アピールになったりしますので、ポートフォリオ代わりに作ってしまうのもあり。

「俺様のサイトはGatsby.jsだ。お前のサイトより早い」（これGatsbyの謳い文句ね）

そして細かいところが気になって、肝心の記事が書けないという負のスパイラルに陥らないように笑

QrunchやCrieit

そこでポエムだろうがなんだろうが書き散らかしてもいい上に無料の記事投稿サービスがありますから、この辺を使うのもいいですね。

note

SEOは強そうですね。ただ、エディタの書き心地が地獄なので私はマークダウンエディタが出たらなにかしら書こうと思います。有料にもできるし。

全体的に書くときに重要なポイント

タイトルが大事

使った技術内容とか引きになるようなものを織り込むのが大事。30字とかよりは長くならないようにしたい（google検索で文字が切れる限界そんなもんじゃなかったっけ）

記事を書いた日付がわかるようにしておく

qiitaなんかは「この記事は古いぜ〜」って勝手に出してくれるからありがたい。個人ブログはそもそも日付の表示忘れてたりするよね。古い記事は古いとちゃんと書いておかないと自分も後で困る。

動作環境などもできるだけ書いておく

そしてバージョン情報とかはできるだけ載せておこう。再現環境がcodepenとかであると最高。

短くても書いたほうがいいの？

以前はてな匿名ブログで「ゴミ記事を書くな」みたいなエントリーがありました。

るせぇぇぇぇーーーー！！！！！

どんなに短くても書かないよりも書いたほうがいいです。

エラー文言

hoge.js の３行目に fuga

この１行書いたら直った

たった３行でも、価値があります！

同じエラーで困っている誰かの助けになるかもしれません。

たとえ間違っていても、間違っている記事をググって出ないようにするのはgoogleの仕事なので、あなたは気にせずアウトプットしていいのです。

また、Qiitaには「編集リクエスト」って素敵な機能がありますよ！ミスってるのに気づいたらリクエスト送ってあげて。

あとQrunchは「ログ」って機能があって、ユーザーが執筆時にググっても出てこないようにするように設定する機能もあるので、気になったらログに設定とかもアリ。

なにはなくとも、書く余裕があるなら、書きましょう。マイナスになることはないです。

まとめ

書く記事によって読まれるポイントがあるので意識しよう
まぁそもそもほとんどの記事は読まれませんので、読まれなくても気にすんな
できるだけ親切丁寧に書いたほうがいいけど、しんどかったらさっと出してしまおう
場所はどういうアウトプットをしていきたいかによって変えてもいいかも
あとはとにかく書いて徳を積みましょう

以上です。

明日はクソアプリ友達のあんどさんがいい感じの記事を書いてくれます！

日本語のフリーフォントを一度に試せる「ためしがき」に用いられている技術について

2018-12-01T10:08:55+09:00

この記事はcrieitでの個人開発サービスに用いられている技術 Advent Calendar 2018 における記念すべき１日目の記事です。

このアドベントカレンダーの趣旨

「アドベントカレンダー」という文化については触れませんのであしからず。

この「個人開発サービスに用いられている技術」というカレンダーの言い出しっぺなので、軽く趣旨を説明したいと思います。

このカレンダーで皆さんに書いてもらいたいのは、個人でwebサービスやアプリを開発している方が自分のサービスをどのように作ったかというのを熱く語っていただきたいと思ったからです。

運営者ギルドというslackコミュニティで個人開発者が集まってワイワイやってるんですが、そこのメンバーを中心にして

日頃作ってるサービスの技術面がどうなっているかをこの機会に共有しあって、今後お互いに困った時にスムーズに聞けるようになるといいな〜

というのと

私自身webサービスが作るのも使うのも好きで、特に技術的に何を使って実現しているのかを考えるのも趣味だったりします。
それで過去にこのような「Webサービス分解」というテーマで記事を書いたりもしました。

「#Webサービス分解「Peing-質問箱-」の分解」

それで、それぞれみんなが自分で解説してくれると非常に面白い記事が出来上がるのではないかと考えたからです。

ということで、まずは私から個人で運営している「ためしがき」というサービスについて解説していきます。

ためしがきとは

日本語の商用利用可能なフリーフォントをまとめて試せて、そのままシェアしたり配布先にリンクしたりできるサイトです。今回はこのサービスの技術面について書いていきます。

ためしがきに用いられている技術

フロントエンド編

このサイトはサーバーレスSPAとなっており、Vue.jsのフレームワークであるNuxt.jsを利用して開発しております。

デザインは特にCSSフレームワークなど使わずにすべて自前でCSSを書いています。

このモーダルが開くときのアニメーションや、ボタン色が反転したりというアニメーションも基本的には自前のCSSアニメーションで実現しています。消しゴムも。

PCで見た際に文字数に応じてプレビューのコンポーネントのサイズが動的に変わっていく部分は、頑張って計算して数を決めているんですが、Gridとかにしたらもっと楽だったかも。追々直していきたいですね。

フォントの読み込みはのりぴー先輩のこの本を参考にして、ページ読み込みの際に一気にpreloadさせています。20MBくらいあります😥

誰でもつかえる！ウェブフォント実践マニュアル

あとは計量化のためにフォントファイルはすべてWoff2形式で配信しています。

縦書き機能

これこないだ追加した新機能なんですが、せっかく法人なのでPR TIMESさんにプレス売ったりしてみました。

日本語のフリーフォントが一度に試せる「ためしがき」が縦書き対応しました！

これもCSSで縦書きできないか〜って色々実験していたんですが、結果Safariとかで崩れたり、縦書き対応のフォントとそうでないフォントがあって切り分けが難しいことなど色々ありまして、結局縦書きCSSはやめました。

じゃあどうやって縦書きしているかというと、デベロッパーツールを見てもらうとわかるんですが１文字づつDomを分けて、かっこや点などの役物は回転や移動をして調整という形になりました。これだとフォントが縦書き対応しているかどうかは関係なくなります。

こちらの実装は前職のスーパーエンジニアの中山さんの作った西尾維新の公式サイトの方式等を参考にしています。

西尾維新公式サイト

（このサイト作られたの結構前なんですが、今見てもヤバさがヤバい）

結構CSS以外でもCanvasを使ってjavascriptで縦書きを実現する際にもこの手法をとられている場合が多いですね。フォントに依存しないというのが今回大量のフォントを利用するためしがきでは重要でした。

バックエンド編

ホスティング

ブランチ毎の確認やフォントを本番化前の確認ページにはNetlifyを利用しています。

本番環境のみFirebaseというサービスのHostingを利用しています。(CDNの速さがNetlifyはまだ少し遅いため)

フォントのシェア機能

ユーザーが指定のフォントで任意の文言でシェアを行う機能は基本的にfirebaseを利用していて、

html2canvasでクライアントサイドで画像化
firebase Storageにアップロード
strageのURLや文言をfirestoreに保存
firestoreで発行されたIDをもとにシェア用URL発行
シェア先のURLをgetするとOPimageに「storageに保存された画像が設定されたhtml」を返却するfirebase functionsが起動
5.にアクセスするとtameshigakiのtopへリダイレクト

という流れになっております。

1の画像化については、ユーザーの環境によっては不安定なためpuppeteerでの画像発行を試みようとしましたが、functionsでpuppeteer起動して画像発行・・・とすると待ち時間が多いため一旦クライアントサイドでの発行としています。これもチューニングして再挑戦したいですね。

CI環境など

Firebase Hostingはビルド環境などがないため、githubにpushしたのを検知してCircle CIでbuildしてfirebase hostingへdeployしてもらっています。

運用

フォントファイルの管理はヘッドレスCMSのcontentfulで行っています。

ただ、フォントファイルが重たい＆フォント情報の更新はあまり頻度が高くないためビルド時にcontetntfulからダウンロードしてきてbuildファイルに混ぜてdeployしております。

今後の展望

フォントの追加作業が大変で全然出来ていないので、ぼちぼち進めていこうと思っています。
フリーフォントを使ってブログ用OGP画像を作る機能とかもあったらいいかな〜と考えています。
どこかデザイン系でシナジーがある会社さん、有料フォントのサブスクリプションを行っているサービスさん、なにかしら協業したりできればと思っていますので心当たりある方はご連絡いただけると幸いです。