読書好きの方向けの引用共有サービス「引用箱」をリリースしました
はじめに
LEF（@lef237）と申します。読み方はレフと申します。2022年からフィヨルドブートキャンプという学習コミュニティに入会し、Web開発の基礎的な部分から順番に学習しておりました。
このたび、ずっと開発を続けていたWebアプリをリリースしました。
名前は「引用箱」というサービスです。
「未知の書籍と出会うきっかけとして、既読した人による書籍の引用から、気になる書籍を探したいが、引用が集まっている場所がない」
という問題を解決するために作った、読書が好きな人向けの引用共有サービスです。📚🔍
ユーザーは書籍の引用を記録することができ、Kindleの共有機能とは違って、自分以外の人の引用記録も見ることができる点が特徴です。
前半ではこのサービスの概要や使い方を、後半では技術的なことを書いていきたいと思います。
- サービスURL
作った経緯
小説や技術書を読んでいると、ふと目に止まった一文からとても良いアイデアが浮かぶことはないでしょうか？
そうでなくても、その文章が気に入って何度も読み返したいと思うことはあるはずです。実際、自分も良い文章を見つけた！と思ったときは、そのページに附箋（ポストイット）を貼ることは多くあります。🔖
しかし、それらの文章……つまり「引用」を、系統立てて共有するのは難しいです。
例えば、自分のお気に入りの「引用リスト」を一覧にして相手に見せたいと思ったとき、どうすれば良いでしょうか？
まず、それぞれの引用を探して、表計算ソフトなどに打ち込んで、まとめる必要がありました。しかもそのデータを、メールなどで相手に送る必要があります。これは、あまり良いソリューションではありませんでした。
Kindleには、引用を共有できる機能があります。電子書籍上で文章を選択して、シェアボタンを押すとツイートできます。しかし、ここには２つ問題があります。
- Kindle（電子書籍）で本を持っていないと、引用を共有できない
- 書籍ごと、ユーザーごとに引用を一覧表示することができない
- どのような引用が人気なのかを、ランキングのような形式で表示することができない
つまり、他の引用共有サービスにおいては、引用を探すのにかなり手間が掛かってしまいます。偶然の出会い、みたいな要素もありません。
そのため、引用だけが集まっているサービスを作ったら、ユーザー同士でお互いに引用を共有しやすいのではないかと思い、このサービスの開発に着手しました。
使い方
このサービスで大切にしたこととして、閲覧については登録無しでも問題なくできるようにしました。
自分もそうですが、新しいサービスに登録するのは、心理的なハードルが高いです。そのため、見るだけでも楽しめるようにしたいという思いがありました。
それぞれの画面について、画像付きで説明していきます。
トップページ中央
トップページのロゴの下は、このようになっています。
「ランダム表示」ボタンを押すことで、引用の順番をランダムに切り替えられます。自分の知らない未知の引用に出会うことができるでしょう。
「人気順で表示」ボタンを押すことで、人気のある引用を降順で並べ替えることができます。たくさんの人に引用されている文章を発見できます。
引用ページ
引用の個別ページはこのようになっています。ここでツイートボタンを押すことで、簡単に引用をシェアすることができます。
書籍ページ
書籍ページはこのようになっています。
もし、お気に入りの引用が見つからない場合は、自分で登録することができます（登録が必要です）。
CSVというデータ形式で、ダウンロードをすることもできます。このデータを表計算ソフトに貼り付けると、表で引用一覧を読むこともできます。
ユーザーページ
ユーザーページはこのようになっています。このURLを共有すれば、自分の好きな引用一覧を、他の方と簡単にシェアすることができます。
引用個別ページをスクロールすると、引用者が載っていますので、そこからこのページに飛ぶことができます。
書籍の一覧と登録
書籍の一覧ページはこのようになっています。
サービスに登録すると、新しい書籍を追加できるようになります。書籍が増えていくと、どんどん並んでいきます。
まだサービスが始まったばかりで、本の数は少ないです（画像はリリース前のもの）。早めに登録すると、たくさんの書籍を追加するチャンスかも知れません。
検索機能
画面の上部にはヘッダーがあります。
ここに、検索ボックスがあります。
著者名もしくは書籍名で、既存の書籍を検索することができます。
利用上の注意
インフラサービス（Fly.io）側の問題で、まれにサービスへの接続が不調になることがあります。
その際は、ブラウザのCookieを削除すると、うまく接続できるようになります。
お手数をお掛けしますがよろしくお願い致します。
（運営費を抑えるため、一番低価格のプランを使っているのも原因の一つかもしれません）
※現在はほぼ解決しているようです。
技術スタック
- Ruby 3.1.2
- Rails 7.0.4.2
- Slim 4.1.0
- Devise 4.9.0
- Active Storage
- Rucocop 1.48.0
- ERB-Lint 0.3.1
- Slim-Lint 0.24.0
- jsbundling-rails 1.1.1
- esbuild 0.17.11
- Tailwind CSS 3.3.1
- daisyUI 2.51.5
- Node.js 18.12.1
- React 18.2.0
- TypeScript 4.9.5
- ESLint 2.0.0
- Prettier 2.8.4
- Hotwire
- Turbo 1.4.0
- RSpec 6.0.1
- Factory_bot 6.2.1
- PostgreSQL
- GitHub Actions
- Docker
- Fly.io
技術選択の理由
今回のサービスを制作するにあたって、挑戦してみたいテーマが２つありました。
- 維持費をできる限り抑えること
- 新しい技術を使ってみること
維持費
まず、前者から説明していきます。自分は以前、尊敬するプログラマーの方がこのようにつぶやいているのを見かけました。
この「アーキテクチャは課金体系が決める」自分がまさにそうだ。課金体系でサービスのアーキテクチャ決めてる。
— V (@voluntas) 2023年3月5日
どれだけコストを下げて自分が提供したいサービスを実現するかが、すごい重要って思ってる。 https://t.co/1gA4woOozW
この「アーキテクチャは課金体系が決める」自分がまさにそうだ。課金体系でサービスのアーキテクチャ決めてる。
どれだけコストを下げて自分が提供したいサービスを実現するかが、すごい重要って思ってる。
午前10:35 · 2023年3月5日 @voluntas
インフラには色々なサービスがあります。どのサービスを使うか迷ったのですが、最終的にはfly.ioを選択致しました。
理由としては、fly.ioはサービス体系として、DBに保存する容量が少なければ全く課金されないからです。維持費が掛からないということは、それだけ管理・保守もしやすくなります。
実際、維持費が理由で個人開発のサービスを畳んでいる方は多いです。個人開発のこの規模のサービスであれば、AWSやGCP、Azureのようなインフラは逆にオーバーであり、サービスに適した選択ではなくなってしまいます。
fly.io上にデプロイするのには色々工夫が必要であり、fly.tomlやDockerfileを用意してあげる必要があり、インフラ周りの学習にもなります。これらの総合的な理由から、インフラはこのような形に落ち着きました。
とはいえ、fly.ioには不具合も多いので、サービスが安定せずユーザーエクスペリエンスを損なう場合には、別のインフラに乗り換えようと思います。
技術的挑戦
後に後述しますが、Rails 7とjsbundling-rails (esbuild) を用いてサービスを開発している人は、2023年の2月頃の時点では、世界に誰も居ないようでした（GitHub上で検索した限りだと、4月の時点でも２つだけしか公開リポジトリは存在していません）。
Rails 7をAPIモードにして、それをNextjsと接続して個人開発を進める方法もありました。
しかし、そのやり方は面白くありませんでした。既に、自分の先輩方がその方法を試していたので、先人の通った道を進んでいるような気がして、あまり楽しくありません。
そこで、Rails 7から導入されたjsbundling-railsと、それによって使えるesbuildを使って、Rails 7の通常起動モードのうえにReactを置く形にしました。
vite_rails（vite_ruby）を使うか迷いましたが、vite_railsに関しても既にブログ記事が存在していて、未知の技術感が少なかったので、ほとんどGoogleの記事がヒットしないjsbundling-railsを選択しました。
この選択をしたことで、自分でブログ記事を書くきっかけになり、jsbundling-railsやesbuildをrailsと一緒にGoogle検索すると、自分のブログ記事がトップヒットするようになりました。はてなブックマークのランキングにも載りました。
自分の尊敬する伊藤淳一さんにもツイートして頂き、それがバズるきっかけにもなりました。改めてお礼申し上げます。🙏
めっちゃ丁寧に書かれていて素晴らしい👍 僕もこのへんはあまり詳しくないので勉強になりました。 / “Rails 7 で React & TypeScript を導入する方法（tsx, esbuild, jsbundling-rails） - LEFログ：学習記録ノート” https://t.co/x7yVUEj5vc
— Junichi Ito (伊藤淳一) (@jnchito) 2023年2月21日
また、ただ単にReactを使えるようにするのではなく、挑戦も兼ねて、slimの中にReactを埋め込むような形にしました。
先述したように、esbuildを使っています。そして、webpackerは使っていません。そのため、react-railsのようなGemは使っていません。
そのため、HTML（viewファイル）からReact側へとデータを渡すために、Javascript（TypeScript）でのエンドポイントのmount処理を自分で実装して、うまくデータの受け渡しをするようにしました。
mount処理を自分自身で実装するのは大変でしたが、結果として完成することができたので、今では胸を撫で下ろしています。
また、TypeScriptを書いたことがなかったので不安でしたが、実際に開発を始めて見ると、すぐに書けるようになりました。この規模のサービスであれば、逆に問題なく型を導入できることが分かりました。
他にも色々ありますが、それらに関してはあらためて次の項に書いていこうと思います。
工夫・苦労した点
セルフレビューをたくさん書いた
このサービスを作っていった過程については、すべてリポジトリ内のセルフレビューに書きました。
そのため、このサービスを作る上でどこが大変だったかについては、リポジトリを見て頂けると、一番分かりやすいと思います。
セルフレビューを書くことで、自分が過去に苦しんだポイントを何度も復習できますし、他の方に情報を共有しやすくなるのでオススメです。
（セルフレビューのコメントを読むと、そのときの状況を瞬時に思い出せるので、こうしてブログを書く上でも役立っているし、同じ箇所で躓かないようになるというメリットもあります）
なぜ、自分がセルフレビューを書くようになったのか？
これは、チーム開発をおこなっていたときに、同じ受講生のmaeda-mさんがとても素晴らしいセルフレビューをしていて、この方法を参考にしようと思ったからです。
Pull Requestを作成し、他の方のレビュー依頼をする前に、難しい箇所をセルフレビューしておく。これだけでもコードの可読性が見違えるほど変わりますし、相手の方の時間を奪わずに済みます。
Fly.ioにデプロイすることで、コストを削減できた
先程の書いた内容との重複になりますが、無料でサービスを運営するため、Fly.ioを選択しました。
Fly.ioを使う上で意識したほうが良いポイントは、次の２つのファイルを管理することです。
- Dockerfile
- fly.toml
それぞれを適切に設定してあげないと、サービスがうまく動かないので注意が必要です。自分は自作サービスをデプロイするに辺り、Docker関係の本を読み直し、なおかつFly.ioの公式ドキュメントを読み漁りました。
例えば、自分はActiveStorageを自作サービスに取り入れています。このActiveStorageはかなり厄介な代物で、Gemfileを変更するだけでは画像を添付させることができません。
libvipsのようなパッケージをサーバーへとインストールさせる- デプロイするたびに画像が消えないように、永続化して保存する仕組みを作る
これらの点は、ローカル開発環境で構築するのでさえ大変ですが、fly.ioのインフラ上に構築させるのは更に大変でした。初めは原因が分からず、かなり焦りました。
fly.ioの公式ドキュメントや公式の掲示板、あるいは英語のYouTubeの解説動画を調べまくって、なんとか２つの技術的課題をクリアすることができました。
これらを解決するためにはインフラの知識が必要で、Dockerfileとfly.tomlを書き換える必要がありました。もし解決できなかったら別のお金が掛かるインフラサービスへとホストすることになったので、無事に解決できて良かったです。
fly.ioが運営している公式の掲示板に、様々なTipsが載ってあるので、それらを参考にすると難しいエラーや不具合情報にキャッチアップすることができます（自分で質問することもできます）。これからfly.ioを利用する方は、どんどんfly.io公式の掲示板を活用すると良さそうです。
※実際、日本人の方と思われるユーザーが、英語で質問していました。
bundling-rails (esbuild)
Reactを使うためにまず必要なことは、Reactを使うための環境設定をすることです。
これが本当に大変で、それだけでも複数の記事を書きました。
TypeScriptが使えるかどうか、という根本的な調査をしつつ、まずは仕組みを理解するところから始めました。
https://lef237.hatenablog.com/entry/2023/02/21/113432
前述したようにreact-railsgemを使うことができないので、エンドポイントを構築するのも苦労しました。
https://lef237.hatenablog.com/entry/2023/03/08/112950
かなり苦労しましたが、良かったことがいくつもありました。それは、これらのブログ記事が、多くの方に読まれる結果に繋がったからです。
自分の観測した範囲でも、FBC以外の方だと、Rubyの高橋会長や、App Developerのlaisoさん、Railsチュートリアルの安川さんや、TechRachoのhachiさん、RUNTEQの受講生の方から、Twitterやはてなスターやはてなブックマークでご反響を頂けました。
takahashim なんでyarnだと駄目なんだろう（Rails7は関係なさそうだし）/このスタイルだとvite_ruby（vite_rails）も候補に入れるとよいのでは。viteならフロントエンドとの親和性も高そうなので
ここで、高橋会長からのご質問に対してご返答しようと思います。
まず、１つ目の「なんでyarnだと駄目なんだろう」ですが、これは完全に自分の設定ミスでした。Rails 7の設定を見直して、現在はyarnでセットアップするように修正致しました。また、それに伴ってブログ記事も修正致しました。ご指摘頂き、ありがとうございます🙏
２つ目の「vite_railsも候補に入れるとよいのでは。」ですが、これは自分の好みでjsbundling-railsを選択しました。
FusicのDaiki Urataさんが、Rails7のフロントエンド周りをvite_railsを使って設定していました。この記事に対するライバル意識ではないですが、これをそのまま真似しても技術的な挑戦にはならないだろう、ということで、jsbundling-rails (esbuild) を選択することにしました。
上の画像のように、jsbundling-railsを使っている公開リポジトリ（特にesbuild）は、タグ検索した限りでも（自分も含めて）世界に２つだけしか存在していない状態で、インターネット上にほとんど情報が存在していない状態でした。これはやりがいがありました。
そのため、公式ドキュメントや公式のリポジトリ、DHHが出している動画やブログなどを読んで、理解を深めました。大変でしたが、とても楽しかったです。
ReactとHotwireの組み合わせ
あまり知られていないかもしれないのですが、実はReactとHotwireって、Rails 7上で同時に動かすこと（共存）ができます。
それについて、ブログ記事にもまとめてみました。
https://lef237.hatenablog.com/entry/2023/03/26/110425
この共存によって、簡単な確認ダイアログをHotwire（Turbo）で、複雑なフロントエンドの処理をReactで書くことができます。とても便利です。
この方法についても、GitHubの公開リポジトリを検索しましたが、2023年の3月の時点では世界で誰もやっていなかったので、現状この作りでサービスを運営しているのは世界で自分だけかもしれません。
TypeScript
自作サービスを開発し始めるまで、一度もTypeScriptを書いたことが無かったです。
しかし、実際に書き始めてみると、意外と簡単だな～という印象を受けました。
というのも、基本的な概念としては「JavaScriptの型を明示的に書こう！📝」というだけなので、とりあえずJavaScriptを書いてみて、そこに後から型を付けていってあげるだけでTypeScriptのコードを作ることができます。
型チェックをしてエラーが出たら、そこを修正すれば良いだけなので、特に難しい点はありませんでした。
ただ、DOM関係のオブジェクトだったりは、どのように型を書けばよいのかが分からず、エラーを調べるのに苦労しましたが……。
SQL文
自分のサービスで、引用された回数順（引用をストックされた数順）に並び替えられる、「人気順」のボタンがあります。
この人気順に並び替えられるためには、親引用から派生する子引用の数を集計して、その数によって親引用を並び替える必要があるのですが、この複雑な処理でDBからのデータ取得と並び替えがうまく反映されず苦労しました。
原因としては、ActiveRecordでデータを取るときに、Arrayオブジェクトになっていたのが原因でした。Arrayオブジェクトではなく、ActiveRecord::Relationオブジェクトとしてデータを取ってくる必要があったのです。
普通のActiveRecordのRubyな書き方では、対応しきれませんでした。そのため、素のSQL文を書く必要があったのですが、これを書くのに本当に苦労しました。
- オブジェクトの型が違うことに気づくこと
- 複雑なデータ処理をORMを使わず素のSQL文で書くこと
この２つの難関を突破する必要があり、解決できたときには安心して、思わずマシュマロを二袋食べてしまいました。
Tailwind CSS
Tailwind CSSには、メリットとデメリットがあります。
- 良い点：CSSのファイルを作成しなくて良い
- 悪い点：viewファイルが複雑になる
自分は昔Bootstrapを使ったことがあったので、今回はBootstrapを使わず、Tailwind CSSを使ってみようと思って使ってみたわけですが……これが本当に大変でした。
というか、デザインの部分が自作サービスの中で一番難しかったのではないか、という想いが自分の中で浮上しています。
Daisy UIを使うことで、少しはデザインしやすくなりましたが、それでも難しかったです。
特に、slimとの親和性があまり良くない気もしました。Reactのtsxへと書いていくぶんにはそんなに困らないのですが、slimへと書いていくと目が滑るというか、ちょっと迷ってしまった部分がありました。
しかし、これは慣れの問題かもしれません。自分はWEB+DB PRESS vol. 133のTailwind CSSの特集記事と、それから公式ドキュメントを読んで使い方を学びましたが、そもそものところでCSSの書き方をだいぶ忘れていたので、そのあたりも苦労したポイントでした。
それから、今回既にリリースはしていましすが、デザインに関してはまだまだ改善点もあるので、どんどん改善していきたいと思います。
（デザインに関しては、明確な正解がなく、終わりがないです）
デザインに関しては、また後述したいと思います。
Windows(WSL2)
自分はMac miniも持っているのですが、開発の難易度を上げるためにWindows（WSL2）を使っていました。
これが大変で、開発のたびに原因不明のエラーに苦しめられました。ゲームで言うところの、HARDモードみたいな感じでした。しかし、エラーが出るたびにその問題を解決することで、問題解決能力を高めることができたので、結果として良かったです。
あえて実装しなかったもの
いいねボタン
これは導入するかどうかかなり迷いました。ログイン無しでも「イイね」することができたら、確かに楽しそうと思ったからです。
しかし、今回のサービスで達成したかった問題は、「ユーザー同士でお気に入りの引用を共有しやすくすること」であり、匿名の状態で「イイね」を押せるようにしてしまうと、どの引用が実際の登録したユーザーの方にとって人気があるのかどうかが分からなくなってしまいます。
DHHのGetting Real的な思想を改めて振り返っても、今回のサービスの場合、「イイね機能」は余分で要らない機能になりそうだったので、没に致しました。
もしかしたら気が変わって実装するかもしれませんが、今のところは予定していません。
やって良かったこと
輪読会を主催した・たくさん参加した
今まで参加した輪読会を挙げてみたいと思います。
- ゼロから分かるRuby超入門
- JavaScript Primer
- パーフェクトRuby on Rails【増補改訂版】
- プロを目指す人のためのRuby入門2023
- プロを目指す人のためのTypeScript入門
- りあクト！ TypeScriptで始めるつらくないReact開発
- 目覚まし会
- 1分間スピーチ
- グループコーチング
- リーダブルコード輪読会2023（自分が主催）
輪読会EXPOとリーダブルコード輪読会の主催を務めることができたのは、自分にとってとても大きな財産になりました。周りの方々に助けられたおかげで最後まで完遂することができたので、参加者の皆様には感謝してもしきれないです。🙏
また、JSPrimerとTypeScript輪読会で、先輩のharuguchiさんが、技術的なことを色々伝授して頂いたので、すごく助かりました。✨
bootcampのチーム開発
自分は今年に入るまで、Reactを書いたことがありませんでした。
クラスコンポーネントと関数コンポーネントの違いすら分からず、Hooksについての知識も乏しい状態でした。
しかし、そんな自分がSWRも含めて、TypeScriptでReactを書けるようになったのは、大きな要因がありました。
それは、OSSのコードbootcampのチーム開発で、Reactのコードをたくさん書いたことです。
チーム開発では、文字通りチームでアプリを開発していくわけですが、そのチームメンバーの中にフロントエンドが天才的に書ける素晴らしい方がいらっしゃいました。その方のコードを参考にし、なおかつその方からDiscordでペアプロしたり輪読会でコミュニケーションを取ることで、Reactの書き方を学んでいきました。
もし、その方がいらっしゃらなければ、自分はおそらく自作サービスに他のフロントエンドフレームワークを使っていたと思いますし、TypeScriptで書いていたかもしれません。
Reactを書けるようになったのはAntiSatoriさんのおかげです。ありがとうございました。
Reactは……というかReact Hooksは、一度書き方を学んでしまえば、後はサクサクと書くことができます。
自作サービスで、スマホ表示の際にドロップダウンが表示されるようにReact（TypeScript）で実装したのですが、この実装はたぶん２時間も掛からなかったかもしれません。React Hooks、最高です。
質問・雑談タイムにかなりの割合で参加したこと
フィヨルドブートキャンプの質問・雑談タイムに、かなりの確率で参加しました。
質問があるときもないときも、なるべく参加するように致しました。
そのおかげか、ちょっとした疑問が湧いたときにもすぐに訊くことができ、スピード感をもって開発することができたと思います。
特にTurbo Drive（Turbolinks）の機能については完全に知らなかったので、komagataさんのアドバイスがとても参考になりました。
GitHub上のOSSを読んで研究したこと
コードを書けるようになるために一番必要なことは何でしょうか？
人によってこの答えは様々だと思いますが、自分は生きたコード……つまり、実際に動いているアプリのコードを読むことだと思います。
そのためには、GitHub上で良さそうなリポジトリを検索して探して、そのOSSをコードリーディングしていくことが一番近道だと思います。
そのおかげで、実装方法を学ぶことができた側面も大きいと思います。抽象的な観念が役に立つ場面もあれば、具体的な事例が役に立つ場面もあります。
公式ドキュメントや書籍で体系的かつ抽象的な観念を育てながら、GitHub上の公開リポジトリで具体的なコードを読んでいくと、最短でスキルをアップすることができます。
小さめのリポジトリを探す方法については、FBC内のQ&Aで質問して、kazumiさんやmhさんが良い探し方を教えてくれたので助かりました。
小規模なアプリ（Webサービス）を見つける方法について | FBC
上記のリンクはFBCの会員の方しか読めないようになっているので、簡単にその内容をまとめてみたいと思います。
- GitHub上で「ポートフォリオ」「Portfolio」で検索する
- 書籍のサンプルリポジトリを活用する
- gothinkster/realworldを参考にする。
- 公式リポジトリのデモプロジェクトを探す
- Awesomeリストを探してみる
他にも具体的な検索方法がたくさん挙げられていて、とても参考になりました。
一流のエンジニアとして活躍している方々が、「どのような方法論で、どのような過程をもって目的の情報に辿り着いているか」というノウハウそのものは、ネット上で検索してもなかなか見つかりません。そのため、こうしてコミュニティの掲示板で活発な知見が次々とシェアされていることは、それだけでも貴重な体験でした。
Getting Realの考えを守ったこと
DHHの教えは偉大です。これを内面化できているかどうかで、自作サービスが開発できるかどうかの分水嶺が決まると言っても過言ではありません。
https://docs.komagata.org/5741
特に、エレベーターピッチが一番重要だったと思います。
最初のうちは、今では実現が不可能だとはっきり分かるような、壮大なアプリを作ろうと思っていました。
しかし、そこでmachidaさんに色々なアドバイスを頂いて、自分の考え方がいかに浅薄であったかを思い知らされ、ビジョンをより適切なものへと修正することができました。
自作サービスを最後まで作りきれたのは、machidaさんが適切なアドバイスをくださったおかげでした。
やるべきことを絞り、やらないことを除外する。この「選択と集中」という概念は、株の世界でもよく言われていることでした。一流の考えは、どこにおいても普遍化されるのかもしれません。
日本語や英語以外の記事も読んだこと
上記のように、jsbundling-rails (esbuild)で開発している人は世界を見てもほとんどいなくて、そのため情報もなく、分からないことが山ほどありました。
謎のエラーが出て、何日も進展がないこともありました。
そんなとき、ふと、スペイン語の記事や中国語の記事を試しに読んでみました。
するとどうでしょう。なんと、読めるのです。スペイン語は大学の第二外国語で学んでいましたし、中国語は漢字です。だから、直感で読めるのです。それに、うまく読めなかったとしても、漢字を読めばなんとかなります。
なので、スペイン語や中国語の記事を読み漁りました。その結果、エラーを解決する方法を見つけられたのです。
Google検索してスペイン語や中国語の記事が一覧に並んでも、普段は無意識的に避けてしまっているかもしれません。そこを、意識的に方法を変えてみることで、解決法を見つけられたのは、自分にとって大きな発見でした。
情報発信をした
制作過程で学んだことを、随時、情報発信しました。
凄い方がリツイートしてくださったり、はてなスターを付けてくださったりしました。はてなブックマークのランキングにも掲載されました。
ランキングに載ったからと言って、別に凄いわけではないとは思いますが（というより運が良かっただけですが）、有益な情報を世の中に届けられたという実感はあり、その手応えはありました。
自分個人としては、ただ単に学習していたときに詰まっていたポイントを、ノートにメモする感覚でブログにアップしているだけの簡単な作業なので、これからも情報発信はしていこうと思います。
今後取り組みたいこと
デザインの更なる改善
デザインを更に修正していきたいです。特に、「共同引用」という言葉を「ストック」という概念に変えたり、ストックしたユーザーが引用カードに並ぶようにしたいです。
以下の画像は、machidaさんから提案されたカードの修正案です。自分もこのほうがデザイン的に素晴らしいと感じたので、時間に余裕があるときに修正したいと思います。
デザインには終わりがなく、修正しようと思うといくらでも修正できます。
そのため、アジャイル的に、サービスを運用しながら徐々に改善していきたいと思います。
Ruby gemの作成
自分の中にとあるアイデアがあり、そのgemを趣味で開発してみたいと思っています。
しかし、どのくらいの規模になるのかとか、どの程度まで調査・研究する必要があるのかとか、そもそもそれを作ることにどれだけの意義があるのかとか、そうしたことが精査できていない段階なので、具体的な内容についてはまだ述べることができませんが、何かしらのgemを作ってみたいと思います。
以前JavaScriptでnpmは作成したので、今度はgemを作りたいという想いがあります。
アルゴリズム、数学
昔はがっつり勉強していたのですが、今はもう、数学を完全に忘れてしまっています。高校数学からしっかりやり直したいです。
アルゴリズムを勉強して難しいロジックのコードも書けるようになりたいです。
Hotwireを深掘り
Hotwireをもっと掘り下げてみたいと思います。
今回は技術的な挑戦のために、React + Turboで開発しましたが、次はStimulusを使ったらどうなるかとか、そうしたことも意識したいと思います。
T3 Stack appでアプリを作りたい
この『引用箱』を開発する前は、『スペイン語タイピング』という日本人向けのスペイン語タイピングアプリを作ろうと思っていました。
なので、今度はフロントエンドを中心にしたアプリを個人開発で作ってみたいと思っています。
具体的には、このT3 App（T3 Stack）という技術を使ってみたいと考えています。
Next.js, TypeScript,tRPC, Prisma, Tailwind CSS, NextAuth.jsをまとめてバンドルしてインストールできるツールらしいです。
バックエンドもフロントエンドも全部TypeScriptで書くとどんな開発体験が得られるか、すごく気になっています。
Discordのログをまとめるアプリ（Dislog）
TwilogのDiscord版を作ってみたいです。
Twilog - Twitterのつぶやきをブログ形式で保存
個人のチャンネルのTimesを一日一回自動的にクロールして、それを日記のようにブログにまとめてくれるサービスです。
DiscordのAPIは単純なので、比較的簡単に作れる気がしています。
また、MastdonやMisskey版のTwilogを作っても、需要はありそうだと思いました。
※アイデアに著作権はないので、作りたい方はぜひ作ってみてください。
AWS
業務では必須らしいのでAWSに関する学習をしてみたいと思っています。
自作サービスでは料金的な問題もあり、サービスに合った最適なインフラを選びたかったので、fly.ioにしました。
しかし事業においてはAWSが選択されている場合が多く、その知識を身につけるのはマストにように感じたためです。
とはいえ、fly.ioが中規模のサービスでもどんどん活用され始めているというニュースを見たりもしたので、そういう意味ではfly.ioに触れられたのは良かった気がしています。
さいごに
自作サービスを通じて、バックエンド（Rails）・フロントエンド（TypeScript）・インフラ（fly.io）を一通り経験できたのはとても良かったです。
自分の将来の目標について書いてみたいと思います。
具体的には、「少人数でアジャイル的に取り組みながら、巨大なアプリを開発することができる、フルスタックな能力を獲得したい」というのが、自分の当座の目標になっています。
極端な話、開発メンバーが自分一人しか居なかったとしても、そのサービスを作りきれるようになりたいです。
また、「技術への深い理解を得たい」と思っています。これからの時代、表面をなぞっただけの浅薄な知識では、ＡＩに対して太刀打ちできないと感じたからです。物事の根本から深い理解をして、アーキテクチャや設計段階からの本質的な開発をできるようになりたいと思っています。
長期的な目標では、どの領域でも一流だと認められるような、大谷翔平選手のようなプログラマーを目指したいと思っています。
大谷翔平選手も最初の頃は、「二刀流をやめて、ピッチャーかバッターかどちらかに絞れ」と言われていました。しかし、大谷選手は、その両方を諦めること無く、そして両方の道において一流になれたのです。
謝辞
一人ひとり名前を挙げるには多すぎるほど、たくさんの方にお世話になりました。 改めて、フィヨルドブートキャンプの皆様に、心よりお礼を申し上げたいと思います。🙏
本当に偶然でありますが、2020年にフィヨルドブートキャンプを知ることができて、幸運だったと思います（実際に参加できたのは2022年からでしたが）。
この記事は自作サービスの紹介記事であり、アフィリエイトのブログ記事ではないので、フィヨルドブートキャンプが何かについての詳しい説明は致しません。
今の時代、プログラミングの学習は独学で充分です。具体的な技術力で言えば、学習コミュニティに参加する必要はないでしょう。
しかし、それでも自分は、FBCで学習することができて本当に良かったと思います。もし、FBCがWindowsに対応していなかったら、自分は独学で学習して一人で就職活動していたと思います。
チーム開発を経て、素晴らしいサービスは、たくさんの方の創意工夫や助け合いのうえに成り立っていることを知りました。また、OSS活動の素晴らしさも知ることができました。
https://lef237.hatenablog.com/entry/2022/07/10/151404
こちらの記事をご覧ください。
自分が生まれて初めてOSSへとコントリビュートできたのは、FBC内で助言をしてくださったからです。
もし、一人でgemのバグを見つけても、原因を特定しきれたかは分かりません。実際にgemのソースコードを読み解き、バグを生んでいるコードに気づき、それを修正してPull Requestを送ってコントリビュートできたのは、自分が助けて頂いたからです。
その感謝の気持ちを、これからも忘れずに「世界」というの名のソースコードに、コントリビュートして参りたいと思います。🌏💻
以上、長文をお読み頂き、ありがとうございました。🙏
『引用箱』は、デザインや機能も含めて、今後も改善を続けていく予定です。
もし、バグなどがありましたら、Twitterなどで教えて頂けると幸いです。
