お掃除2506

お掃除がてら数年前の自分を振り返りたいなと思ったので描きました。

命名規則や公開範囲とかについて

副操縦士に聞いたところ、-区切りで書くのが良いらしい。

面白いですね！遊びで試したプロジェクトやメモを整理するなら、カテゴリごとに名前を決めると管理しやすいかもしれません。例えば：

sandbox-*：試作や遊びで作ったコード

prototype-*：アイデアを形にしたもの

experiments-*：技術検証用

archive-*：過去のプロジェクトやメモの保存庫

notes-*：設計やアイデアのメモ

例えば、Tailwindの新しいユーティリティを試したなら sandbox-tailwind-experiments 、Nuxt×Ollamaのアイデアなら prototype-ai-gui みたいな感じ。

あとは用途別に分けるのもいいですね：

fun-projects

small-tools

random-ideas

何か気に入るものはありますか？一緒にいい名前考えましょうか！

そもそも遊びのコードをそのまま放置するのは良くない、それこそtmp使えや！ですよ！
とはいえ、残したいと言う気分があるので、ネタに残せるレベルだったら残す方針で。

思い出話

整理しながら懐かしいrepo触ってるので、せっかくだし思い出話をしてしまおうと思います。

vox-ttsシリーズの開発と試行錯誤

vox-ttsは、VoicevoxのREST APIを活用したDiscord TTSボットで、私が最初に「書き切った！」と感じたプログラムのひとつ。Pythonで始め、のちにJSへ移行しました。この過程で得た知見を振り返ります。

開発のきっかけは、VoicevoxがREST API経由で音声合成できると知った瞬間の衝動。「これはやらねばならぬ」とコードを書き始めました。Python (discord.py) を使いましたが、後にJS (discord.js) へ移行。その理由は、ライブラリの不安定さよりも応答速度の改善を期待してた。しかし、最終的にはVoicevoxの生成時間がボトルネックだったため、この変更はそんなに意味がなかったです。

とはいえ、JSを選んだことで、イベント駆動型の設計が活きるようになりました。Discordのような「いつ発生するかわからない処理」に向いていて、非同期処理の管理がしやすい。特にPromise.allが便利で、APIコールの最適化に活用しました。例えば、複数のデータ取得を並列化することで、待機時間を短縮できます。

const [userData, posts, comments] = await Promise.all([
  fetch('/api/user').then(res => res.json()),
  fetch('/api/posts').then(res => res.json()),
  fetch('/api/comments').then(res => res.json()),
]);

console.log(userData, posts, comments);

(Promise.allの一例)

マルチスレッドと比較すると、JSの非同期処理は考えることが少なくて済むのが強み。スレッド管理や共有変数の競合を気にする必要がなく、awaitを必要な箇所だけに書けばいいのが直感的です。

vox-ttsの開発を通じて、PythonとJSそれぞれの特性や非同期処理を深く理解できました。イベント駆動型の設計は、リアルタイム処理を必要とするコードには最適です。

リポジトリへのリンク

vox-tts.py
vox-tts.js
- node-voxclient
  Voicevoxを使う関数群を分離したやつです。 ...全然記憶にない

参考など

experiments-discord-bot.js & node-dirtools

vox-tts.jsを作る前に検証用として作ったbotです。
vox-ttsの項で大体の説明をしてしまったため、ここではリポジトリのリンクに留めます。

リポジトリへのリンク

experiments-blockview.rs: Rustとの出会いと試作コード

Rustに触れ始めたきっかけは、ゲームのmod修正でした。
致命的なバグが放置されていて、誰も修正しようとしていなかったので、「ならば自分で直してみよう」と思ったのが始まり。Rustの本を読みつつ、当時流行っていたAIも活用しながらコードを書き進めました。

最初は試行錯誤の連続で、書いたコードも拙いものでした。unsafeを使いまくる方法を取っていたので、PRを出した際に大量の指摘を受けました。しかし、それが結果的にRustの型システムや所有権の概念を深く理解する良い機会になったと思っています。

Rustで書いた試作コード

Rustを学ぶために書いたコードのひとつに、8色程度の色データを配列に入れ、それを標準出力に四角絵文字で表示するプログラムがあります。例えば：

🟥🟦🟨🟩

実装方法としては、色データをenumで管理し、出力時には対応する絵文字を使う形を採用しました。
一見シンプルですが、後から見返すとswapを使ってデータを入れ替えたり、二次元配列で管理すべきデータを一次元配列に縛ったりと、なかなか無茶な設計をしていたことに気付きました。

とはいえ、この試作を通じてRustの型管理や所有権の扱い、さらにはデータ構造の設計について多くの学びが得られました。
今後はbmpに保存できるようにしたい...(現在やってる)

リポジトリへのリンク

experiments-wasm-vue

名前変えました。そして書いてたら長くなったのでページ分けました
-> Vue × WASM × Rust—試行錯誤とこれからの展望

item_json_maker: Minecraftリソースパック制作のためのツール

Minecraftのリソースパックを作る際に使用するツールとして、item_json_maker を作成しました。出番はあまりないかもしれませんが、必要になったときに便利なツールになればと思います。

開発のスタイル

このツールは、HTML・CSS・JSのみで作られており、Vueやその他のフレームワークは使用していません。 Bootstrapを活用しており、classを指定するだけでスタイルを整えてくれるので、その点はとても楽でした。ただし、Vueを知ってしまうと、プレーンなHTMLが整理されていないように見えてしまう問題があるのも事実。ファイルを適切に分割することで解決できる部分もありますが、シンプルなツールなのでこの形式でまとめています。

余談

中学生の頃はHTMLとJSを活用して遊んでいました。特にJSは、使用例を載せているサイトを参考にしながら、自分でサイトを拡張していくのが楽しかったです。こういう技術を学ぶ過程って、ただ知識を増やすだけでなく、「試してみる」「遊んでみる」ことが大事だと思っています。今でも新しい技術に触れるときは、ショールームを見ているような感覚でワクワクしますね。

今後

今のところ拡張の予定はありませんが、今後こういったツールを作るなら、VueやWASMも活用してみたいと考えています。フレームワークを使うことで、より整理されたコードが書けるようになるし、WASMを組み合わせることでパフォーマンス面でも強化できそうですね。新しい技術を活かす場面が出てきたら、またツールを作ってみようと思います！