blog.takurinton.dev

僕がサブスクを使わない理由

2021-11-04

こんにちは

どうも、僕です。

半分くらいは釣り

僕が使っているサブスクのサービスは以下になります。

- AWS

- Spotify

- Amazon prime

- Notion(学生なのでタダみたいなもん)

別に、使ってないわけではないですし、しっかり使ってる方なのではないかとか思っています。(ごめんなさい)

そんな感じで僕がサブスクをあまり積極的に利用しない理由について書いていきます。

補足

書き終わってから思ったのですが、思ったよりサブスクのようなサービスは多くなく、マネフォくらいしかありませんでした。いつか税金についての勉強をして、freee を自作することができるようになりたいです。夢物語。

僕がサブスクをやらない理由

僕はなぜ積極的にサブスクのサービスに手を出さないのか。

その理由は大きく分けて2つあります。

大体のものは自作できる

大体のものは自作できます。

例えば、今作ってるものであれば、最近お金が溜まってきて金遣いがだいぶ荒くなってきたので収入を管理するようなアプリを作成しています。マネーフォワードのようなとても使いやすく優れたサービスは世の中にたくさん出回っていますが、あえて自作をすることでそのプロダクトの気持ちになることができたり、プログラミングの楽しさの本質に向き合うことができます。自分自身、ものを作るというよりもコードを書くこと自体に意味を見出すタイプで、よく言われるプログラミングは手段か目的かで言われれば目的派の人間ですが、それはものを作ることが嫌いという意味ではないので、積極的にものを作ります。

自分が使うものを自分で作るというのは想像以上に楽しいものであり、そこに金銭は必要ありません。自分自身の楽しさ、快適さ、世の中への理解のために、毎日コードを書いてものを作ります。それが自分の周りのものであり、自分の生活を豊かにするためのものであるだけです。

また、既存のサービスは供給過多な部分があり、自分が使わない機能まで親切に備わっています。しかし、それは体験を悪くする原因の一つであり、機能が充実していることが正義ではありません。そのような機能を自分で調整しつつ、欲しいものだけ実装することができるのも良さだと思っています。さらに、サービスとして運用すると、堅牢で高速、かつバグを発生させてはいけないということが求められますが、自分の開発であればいくらでも失敗することができます。そのようなお気軽さも含めて、趣味の延長として自分で使うものを自分で作り、運用をしています。

認証やセキュリティリスクが絡まない分、実装コストは抑えられ、大体のものは自作することができるようになります。おそらくこれでだいぶ多くの人が個人開発のハードルが下がるはずです。

技術を追い求めるのが楽しい

もう一つの理由は、技術を追い求めるのが楽しいからです。このような個人開発は、用途やユースケースにもよりますが、自分の知らない技術の素振りに適しています。ドキュメントを読むだけでは理解したことにはならず、実際にプロダクトに落とし込んだりすることが大事です。人それぞれ、未知の技術の素振り方法はあるとは思いますが、自分の場合はたまたま個人開発で自分が使うものを作ることだっただけです。これが正義とは言いませんが、やっぱり何かを兼ねた方が楽に習得できますし、楽しいです。

上で述べたように、収入を管理するアプリケーションは、スマホアプリにする想定でいるので、UI は ReactNative、サーバサイドは Rust を使って開発をしています。

どちらも、自分の中では未知の技術であり、特に ReactNative については Web でいう DOM のレンダリングとどのように違うのか、vdom のような木を仮想的に管理するような思想を引き継いでいるのか、ただ React の構文で書けるだけなのか、などの技術的な部分に関心を持って開発をしています。

技術を追い求める上で、さまざまなユースケースに対してさまざまな解決方法を見つけていくのは大切であり、このような形で習得するのは非常に楽しいです。

問題点

リソースが問題です。多分、普通にサブスクサービスを契約した方が安く済みます。

それでも自分が自分で開発することを好む理由は、やはり楽しいからではないでしょうか。楽しんで開発をすることで、人生が豊かになるとまで思っています。人それぞれ開発のモチベーションやトリガーは違うと思いますが、自分はここに重きを置いています。

現在、AWS の EC2 の t2.micro というインスタンスを使っていますが、そろそろ死期が近いです。頑張ってください。

課題

デプロイサイクルが整っていません。かれこれ2年くらい経つのですが、全然整備されていないので、手動でデプロイをしています。だいぶめんどくさいのでそろそろ整えたいです。

逆に、テストを回す環境は整っていて、GitHub Actions で push するとテストがされます。ただ、テストを書いていないので意味はありません...。

構成

最近はフロントエンドな人間なので、フロントエンドで技術的に挑戦するようにしています。

また、全体の構成についてですが、フロントエンドはリポジトリを細かく区切って vercel にたくさんデプロイしています。その分サブドメインが増えまくり、最近管理できなくなってきています。

逆に、サーバサイドはモノレポになっており、Go で書かれたサーバにリクエストが投げられ、処理されます。同じ内容を返すエンドポイントが REST API と GraphQL の両方用意されていて、フロントエンドの用途に対して柔軟に対応することができるようになっています。

具体的には以下のようになっています。

フロントエンド

フロントエンドは使ったことがあるレベルの技術だと以下があります。特に React は最近よく書いていて、メモ化やレンダリングの最適化、バンドルサイズを小さくすることなどに興味があり、取り組んでいます。

Vue や Svelte は9月まで仕事で書いていました。

- React

- Vue

- Svelte

- lit-html

- Vite

- webpack

現状、表で公に出してるサービスはブログだけで、ブログは Svelte で書かれています。仕事で使いそうだったので素振りで使いました。バンドルサイズが小さく、小さいアプリケーションなら適してると感じました。

ただ、大きくなると不利になる可能性が出てくるので、注意が必要だなと感じ、SPA 向きではないなとも感じています。

サーバサイド

サーバサイドは以下の技術を使っています。

- Python

- Go

- Rust

- Node.js

言語が4つ並んでいますが、ほぼ Go です。90%くらいは Go で書かれています。

逆に、Rust や Node.js は試験的な導入で、これから拡張していこうと思っています。

インフラ

AWS をメインで使っています。

DNS に Route53、Linux のインスタンスとして EC2、ミドルウェアとして Nginx、データベースは RDS を使っています。そろそろ GCP に乗り換えようとしています。もう2年くらい放置なのでそろそろ限界を迎えそうで怖いです。

技術的に挑戦はしていきたいものの、ここら辺はお金がかかるので放置ゲーになりがちです。その分、ローカルで Docker をいじっています。コンテナサービスは楽しいですし、それをよしなにデプロイしたりするのも楽しいです。そこら辺は仕事リソースを使って就職してから挑戦していきたいです。

今まで作ったもの

- 体調管理とその可視化、機械学習を使用した次の日の体調の予測

- ポートフォリオの統計情報や sessionStorage を使用したトラッキング

- ブログの管理画面

- ポートフォリオの裏側をノーコードツールのように

- チャット

- 写真投稿

- ノート

- ブログ

- 日記

これから作りたいもの

- notion

- オートロック

- マネフォ

- GitHub

- 収入管理(今やってる)

- conpass

- Google カレンダー

まとめ

書いてて思ったのですが、別にサブスクじゃないサービスが多かったです。

ただ、技術を追い求めるために、これからもさまざまな開発をしていきます。

一度基盤を整えてしまえば、あとは開発をするだけなので簡単だと思います。

いい環境を整えて、スケーリングしやすく、自分で開発しやすい環境を作っていきましょう!