概略
約2年前、30万円のSurfaceを購入し、独学でプログラミングの勉強を始めました。
私は実務未経験ながら、フルスタックエンジニアとして中堅レベルでの就職を目指して学習を続けてきました。
ポートフォリオとして取り組む題材は、早い段階から「ポケモン対戦ツール」に定めていました。
現在、その中核となるバックエンド（Django）部分の構築に着手した段階です（作業開始は昨日）。
プロジェクト概要
以下のような3段階構成で設計しています（構成は拡張します）：
- PokeAPIからデータを取得するDjangoコマンドを実装
- 取得データを加工・保存するコマンドも別途用意
- Django REST Frameworkを用いて、データをフロントエンドに提供
ディレクトリ構成（抜粋）
poke-back/
├── _config/
├── _venv/
├── ep_registry/
│ └── data/all_ep.json
├── fetch_pokemon/
│ └── temp/
│ ├── form_idxs.txt
│ ├── pokemon_idxs.txt
│ └── species_idxs.txt
├── ep_registry/management/commands/ep_registry.py
└── fetch_pokemon/management/commands/fetch_pokemon.py
構成は、独自スクリプト（tree.py）で自動出力できるようにしています。
これはプロジェクトを他者に共有する際や、LLMへの入力時に便利です。
ep_registry アプリ
このアプリでは、静的な JSON ファイル（all_ep.json）を元に、エンドポイント情報をデータベースに登録しています。
エンドポイントの数が多く、管理画面の視認性を確保する目的でアプリを分離しました。
fetch_pokemon アプリ
このアプリでは、pokemon-species / pokemon / pokemon-form の各エンドポイントから非同期でデータを取得し、加工・保存を行います。
使用対象のエンドポイントは、事前に ep_registry 側で using=True とマークしたものだけに限定できます。現在はこのアプリの Django コマンド（fetch_pokemon.py）を記述中です。
非同期処理について
非同期処理は私にとって大きな壁でした。
そこでまず、async/await を使わずに 並行処理を模倣したコードをLLMに書かせ、その挙動を観察することで、基礎的な理解を固めました。
その後、非同期コードの構造が自然と理解できるようになり、現在は aiohttp 等を使った実装を進めています。
エラーも出ておらず、順調に進行中です。
総括
文章力に自信がないため、読みづらい部分があるかと思いますが、継続的にアウトプットすることを大事にしたいと考えています。
最初は稚拙でも、記事執筆をルーチン化し、積み重ねていくことで、振り返りやポートフォリオにも活かせると考えています。
参考になる内容ではないかもしれませんが、「一人でよくやってるな」と思ってもらえれば幸いです。
written by 高梨 栞理（playingbirds）
本稿の執筆者「高梨栞理」はハンドルネームであり、実際の氏名とは異なります。