あらまし

Fediverseには色々なサーバがあります。Misskey、Pleroma、kmyblue、その他にも数多のサーバがあり、ActivityPubのもとにそれぞれのサーバが連合を組んでいます。

一つひとつチェックしようとするとちりつもやまとなでどえらい時間を食ったり、Chromeのメモリバカ食いなどでどえらい容量のRAMを食い尽くしたりします。
まるでCPUとRAMのバイキングやと…。

ということでそんな面倒なことを解消するべく、クライアントを作ることにしました。
半分は自分向け、もう半分はChromeのRAM浪費がヤダヤダとかfediverse上での情報をもっと整理したいとかのエンスージアストな廃人向けになっています→なりました

実際のコードはGithub上のリポジトリにもろもろを置いているので、お気軽にissueやコード設計のマサカリをいただければと想います。
https://github.com/Manche/MiView

前置きしますが、内容を一気に読もうとすると情報量が多いので、何度かに小分けしてセクション毎等で読んでいただく方が良いかもしれません。

事前準備

本格的にソフトウェアを開発するため、それなりに事前準備や計画を立てる必要がありました。
ちなみにここの時点でかなり重要なポイントはいくつかあります。

何があってもめげない気持ちは持つこと

道中、厄介な仕様だったり実装してもうまくいかないことがちょくちょくあります。
ということでコレだけは持っておきましょう。技術が分からなければChatGPTに聞いたり、調べてみたり、色々いったりきたりを繰り返していたらいつの間にか習得しています。

とりあえずの目標を立てる

• とにかくシンプルであること
• Windows上以外はとりあえず考えないこと
• 自分が使いやすいものであること

互換性や誰かが使いやすい等、開発以外のことを考えるとエタるので、まずは自分が使いやすいかどうかを中心に作っていくことにしました。
いわゆる昔流行ったTweenというクライアントがモチーフでもあります。

これでピンと来た方はツイ廃だと思います。

コード書くの大変じゃない？

ぶっちゃけそうです。面倒くさい。
これまでに1万行を超えるコードを書いていますが、1/3ぐらいがChatGPTに書いてもらっているコードになっています。

ある程度のスケルトンを作っておき、後でChatGPTに実装の修正を行ってもらうという形で進めました。

開発環境と運用環境の両方を用意しなくてはならない

メインで使っているPCは色々なライブラリなどが入っている関係で別途ステージングにあたる環境を用意しなければなりません。

ヤフオクで適当なワークステーションを購入し、それを使うことにしました。
【2025年最新】Yahoo!オークション -hp z4の中古品・新品・未使用品一覧

hpのZ4は3万弱で購入でき、しかもwindows11入りなこともあるので、ワークステーション導入にはうってつけ。

自宅のサーバを検証に使う

実はMisskey.ioがMisskeyのforkだったことを知っていたので、素の環境である自宅サーバ上のMisskeyも開発&検証対象としました。

ない場合はローカルなりなんなりと用意する必要はあります。
ただ、もろもろのリスクや仕様ズレを考慮すると、出来るだけバニラの方が良いかもしれません。

ある程度ほしい機能を絞り込む

最優先の機能はとにかく最優先でやりましょう。遠慮はいらない。
自分にとって一番ほしい機能を重点的に、そして代替できるものはそれを使い、開発にはできるだけ欲しい機能の実装に集中することでモチベーションを維持できます。

せっかく仕事以外でコードを書くのなら、欲しい機能を最優先にしたいですよね。

---

ある程度ざっくりと書きましたが、ここまでが準備です。
もう一度言います、準備です。

大げさかもしれませんが、開発のほとんどは準備で占めています。

さあ開発だ！

この段階まで来ると毎日何かしらの形でコードを書くようにおのずとなっています。
自分のほしいものを自分で作るので、あとは手を動かすだけ！

とにかく見た目だけでも作る

どんなアプリでも見た目があると何だかんだ開発を続けられます。
逆に、目新しい何かがないと新鮮さがだんだんなくなってきます。

見た目がなくても開発できる人はほぼほぼ超人か何かの類です。

進まない時は置いておく

いつどんな時に良いアイデアが浮かぶかは分からないので、常にどこかに構想を書いておける場所を用意しておきます。
ちなみに脳みそに突っ込んでおくと3日したら忘れてます。残っていたら作るのも有り。

どうしても手が動かない時は頭も動いてません。仕事にしろ趣味にしろこういう時は簡単な作業で1日を終えましょう。
ちなみにさらに頭を働かせようとすると、今度は眠くなります。不思議。

めんどくさいときは生成AIを使ったって良い、ただし！

スケルトンを作ったあとはとにかくコードの量が大事。
書いて書いて書きまくることになりますが、ややこしい実装やらなんやらは自分で書かなくても良いことがあります。

websocketの実装はChatGPTにまかせてました。

ただしデバッグやコードレビューはしっかりしておきましょう。
スケルトンが出来上がっている場合は特に外部実装を守れとか、既存のシグネチャやフィールド・プロパティを乱すなとか、しっかり言ってあげましょう。

ちなみに生成AIはベストプラクティスなコードを書かないことがよくあります。
スケルトンを用いるのはコードに最低限の品質を持たせるという意味でもかなり重要です。
外部実装は守ってね、フィールドやプロパティは保持してねと言っておくだけでもそこそこ良いコードを書いてくれます。ちなみにたまーに守らない時もありますが。

ディレクトリ構造をしっかりと考えて作ること

エタる原因の半分ぐらいは、久しぶりに触ったコードがどこに何があるのか分からんという状態にあったりします。
必要なところに必要なものを準備、そして必要があればスケールしたり、リファクタリングを繰り返す。そうして最後は適度に良いコードが出来上がっていきます。

最初のうちに整理できていないと、永遠にどこに置けばいいのか分からないコードがよく分からない場所にあり、そして最重要なライブラリになってしまいます。
いわゆる部屋の隅が物置状態になってしまうので、早めに整理しておきます。

phpならMVC、C#ならException、EventArgs、Model、Util、フォームらへんは整理しておきましょう。



一応参考例として載せておきます。

動作テストはどうするのか

ここで検証用マシンが役に立ちます。
まっさらな環境を用意するのはとても面倒くさいです。

めちゃくちゃめんどくさいです！！！！！！！！！！！！！！！！！！！！！！！！
(アルティメット事実)

ちょっと乱れました。お酒が入りながら書くと良くない。

ただ本当に大事です。バグが生まれる時点でまっさらなのか、それともてんこもりなのかで原因の切り分けがしやすくなります。
そしてそもそもまっさらな環境で動かなければプロダクトとしてはNGになってしまいます。
かといって何もない環境もそこまで多くはありません。

ここでメインPCの出番というわけですね。
ごった煮環境で初めて出てくるバグもまあまああります。例えばVRChatしながらとか、factorioしながら、LLMを回しながらな時はメモリを随時GCに投入したりするので、そこそこメモリ違反対策が必要なことに気づきます。

ここから更に観点に分けて実際に開発する上でのテスト方法を載せていきます。

とにかく動かしてチェックする

形式に則ってテストするのはめんどくさいです。仕事じゃないし。

ということで使い勝手とか動作チェックになってくるわけですが、「自分がほしい機能を優先する」ということがここで活きてきます。
とにかく大事な機能はテストテストです。

製作者が好きな機能しかテストしないなんてことは別に珍しくないです。

耐久テスト

とにかくメモリを食いつぶすテストです。
数日動かしっぱなしにしたり、あらゆるシチュエーションに耐えてほしい(願望)ということでやるテストです。

ソフトウェアはメモリを使いまわしても、解放を勝手にやってはくれません。
使わなくなった変数、メソッドを「今後使わないから」ということで捨てるのがよくある解放です。
いわゆる受動的な解放ってヤツですね。

逆に常に使うようなメソッドや変数において、例えば配列の数を有限にして古いものを捨てたり別の媒体に残す、ほかにもデータ領域と描画領域を分けるような方法があったりします。
これはメモリ領域を積極的に確保するということで、能動的な解放になります。

が、個人開発ではスペックでぶん殴る開発はあるあるなので、最適化が億劫になりがちです。
某FPSでも出た時点で最新スペックが必須・・・みたいなのもありますね。
CPU・メモリ・I/O・ネットワークをアプリの動作をする上でスムーズに、そして効率的にする、これがいわゆる最適化です。

耐久テストは数日～数カ月に渡ってやることが多いのでおろそかにされがちですが、実はめちゃくちゃアプリケーションの開発においてもっとも大事なテストの一つです。

ハンズオン・デベロッパーリリース

ここまでくると半分ぐらいは完成に近いのですが、最初のうちに公開しておくことで機能実装やコーディングにおいての意見が出やすいです。
が、ピボットしまくる段階や、まともに使えない状態では役に立ちません。
いわゆるデベロッパーリリースとして技術検証を流すか、もしくはある程度作っているアプリが操作できるようになってからハンズオンしてもらいましょう。

どんな技術を使っているの？

ここまできてやっと具体的な技術の話になってきます。
アホなぐらい前置きが長いかもしれません。
ただ、技術以前の問題や課題というのは非常に多いもので、実は技術自体はそこまで開発において重要なファクターにはなっていません。

そして一般的に言われる開発が難しいことに、技術ではなく政治やらモチベーション、そして設計やら手法やら色々全然技術じゃないやんけというところがここにありますよ、ということを意味してます。

実際に、技術者として仕事をする上で技術が役に立ったことはあまり多くなく、ほとんどは経験・応用力・基礎力・コミュニケーション・プランニング・リーディング・ディレクションといった技術単品以外のことが役に立っています。これらを前提に、技術が光るかどうかというのが決まっていきます。
アプリの開発における技術はこれから紹介しますが、そこまで強いものはありません。

非同期処理とイベント

処理の半分ぐらいは非同期です。
TaskやInvokeだったり、フォーム間のデータの受け渡しには独自Eventの定義をして行っています。

TaskはWebアクセス、Invokeは画面への反映、独自Eventはフォーム間やクラス～フォームのデータのやり取りを担っています。

C#はイベントドリブンに向いているのもありますが、データの受け渡しとしてイベントを乱用すると「自爆します」
自爆というのは、イベントが発生したタイミングで意図しない処理が伝播していくことだったり、それを防止しようとして大量にイベントが生まれてしまうことだったりします。

イベントをただ使いまくるのではなく、あくまで一連の流れとしての処理と、そしてクラスや処理が担う発生タイミングを意識することが大事。
ちなみにイベントはwebhookにおける「受信時」「送信時」「接続切断時」「接続時」みたいな特定地点のシグナルを使うことに用いています。ここらへんはちゃんとクラスの責務や疎結合を意識することである程度現れてくるのかなと思っています。

Webhook

処理のもう半分と2/3ぐらいはwebhookが主体です。
理由はクライアントだからなのですが、それ以上に処理を書く上でしんどい場面が多いです。

こういう時は自分で無理やり解決しないのが大事です。
理由は後述。

ChatGPTに並走してもらう

ムリしない、じゃあどうしようかということで、ここでChatGPTの登場です。
さあいっぱい使おう！・・・ちょっと待った！

まずはスケルトンを書きます。いたってシンプルな形でいいです。
最低限必要な処理を列挙し、簡単でもいいのでサクッと実装を書いておきましょう。

AIは0→1がまだ得意ではありません。
ある程度自分なりの実装はやっておきましょう。

ここでこれを読んでいる人に向けて、魔法のプロンプトを授けます。
「次の条件を守ってください。外部実装、プロパティ、メソッド構成を必ず守る。処理を大きく変えすぎないこと。以上。」
これを実際にChatGPTに乗せるとあら不思議！スケルトンをしっかり守った上で処理を作ってくれます。

ただし、コードを乗せるだけでは完成になりません。動かなかったらダメなので。
ここでテストの出番です。
テストとログライタを駆使し、更なるブラッシュアップをChatGPTなどに求めましょう。
根気よく繰り返していくことでKAIZENしていき、最後はほぼほぼ完璧になっていくことでしょう。

テストを怠った場合、まともに動かない品質のコードや読めないコードが放置されてしまうので、必ず自分で見て整理しましょう。
技術的負債は都度取り除いておくのがミソです。

残りの足らないところだけ書く

一般的とされるパターンから外れるようなコードをAIは書くことができません。
あくまで平均的なコードしか作れないので、ちょっとでも外れるのであれば自分で書く必要があります。
ここは・・・とりあえず頑張りましょう。

最新の技術は使わなくてもいい

よく、個人開発では最新の技術が多用されがちですが、言語の更新以上のレベルを求めるのであればやめておいた方がいいです。
ライブラリなどの仕組みはすぐに陳腐化します。特に誰か個人が作ったレベルのライブラリは、短くて1年後に使えなくなることがほとんどです。
したがって言語レベルで新しい技術を使うことにとどめておき、とりあえずライブラリとか最新のなんとやらは最低限にしましょう。

自分で使いやすいラッパー・ライブラリを作る

ちなみに自分自身で使いやすいライブラリやラッパーを作るのも、実は有りです。
公開しておけば誰かが使うこともあるかもしれません。

拡張メソッドは意外と使わないことが多い

独自定義のメソッドやイベントで使うことを予想しましたが、イベントの活用や適切な継承により逆に拡張メソッドを使うことがありませんでした。
過去に仕事で使ったこともありましたが、結局のところ既存処理のちょい拡張程度だったりします。
使いたい場合はシグネチャを前方互換させると良いかも知れません。使い所は・・・個人差によりけり。

最後に

まずは、最後までお読みいただきましてありがとうございます。
Qiita初記事になります。

物量を出来るだけ抑えめに、そしてざっくりと書きましたが、個人開発をする上でのある程度のポイントだったり心構えは提示できたかもしれません。
基本的に技術は後からついてきます。大事なのはやる気持ちですが、それ以上に準備も大事です。

ここまで読まれたのであれば、きっと仕事でも個人開発でもめげない気持ちで挑んで行ける方だと思います。
もし、まためげそうな時があればこの記事を再び読んでいただき、大事なポイントはどこかを自分なりに再度チェックするきっかけになれば幸いです。