前提整理

1. 目的
   1. 会社側
      1. 会社が求めるスキルを持っているのか確認する
   2. 自分
      1. 選考に合格する
         1. →いやちょっと違うか…自分のスキルを提示する、が正確か
      2. 合格しなくても意味のあるものだと尚良し
         1. ミニマルな開発で振り返りができそうなので知識の再整理
         2. 普段そこまで考えない観点が記載されているのでこの機会にできるだけ勉強
         3. 弊社教育課題にFBしたい
2. 期間は今日から2週間（〜11/22）
   • フロー、スケジュールどうする
   • どのくらいの工数感か？
3. 要件は？
   • 必須
   • 追加
4. 何を見たいのか→何を見せたいのか
   • 技術力
     • こちらがメインだと思うが、一番自信がない…ここを調べる時間をある程度取りたい
     • 目的がスキルの提示である以上誇張しても仕方ないが、調べる能力は示す必要がある
   • 全般的なマネジメント能力？
     • ここは相対的には自信があるので計画が大事になりそうか…
     • ただこういうの考えすぎて実装にたどり着かんのよな…

• 課題の取り組み開始から完了までに要した合計時間
  • スケジュールにメモるか
• これまでの総合的なプログラミング歴
• これまでの WEB フロントエンドプログラミング歴
• 着手にあたり参考にしたページや書籍、リポジトリ

ちょっと全部出来るか不安やから要件絞ってイテレーション2回回すか…

1. 必須
   1. 実装
   2. テスト（範囲は？）
2. 準必須
   1. CI
   2. テスト（必須以外。e2e大通り以外？）
   3. ドキュメント
   4. セマンティクス
3. できればやりたい
   1. 直遷移時のクエリによる条件構築
   2. デザインこだわる
      1. ヘッダ・フッタ
      2. アイコン
      3. チェックボックスはボタン形式
      4. 関東でくくる
   3. OGP
   4. 遊び

要件整理後に戻って来る

2週間じゃやっぱやりたいこと全部は厳しい…最悪MVP的に出すしかないな。
デザインのこだわりを一旦捨てて、機能要件を満たす＋テスト100を最低限。
そもそも初期状態ではデザインは作成しない

その他

1. 条件変更に伴うrouting history更新は？
   1. 直遷移要件特に言及ないしなぁ…あとは戻るボタンの挙動。選択ごとにhistory追加して戻ったら条件戻るのは気持ち悪いな…historyの更新は特に考えないことにする
   2. ただし、直遷移時にクエリから条件再生は時間があればやる
2. デフォルトの値どうしよ。東京？ユーザロケーションとるのはやりすぎか…全部か東京かな。
   1. ただ全部は結構エグい見た目にならんか…？
3. 条件クリアボタンとかは？クリア先のデフォルトがいまいちわからんしな。蛇足感あるので不要
4. アクセシビリティは特に言及ないので、タブ遷移とセマンティクスくらいを意識
5. SEOも言及ないので、title, descriptionくらいかなあ…OGPは時間あれば
6. WebVitalはまあ余裕あればだがそもそもそんな差が出ないはず

SLA

• PC
• ブラウザ
• 画面幅

類似サイト

http://data-biz.com/人口推移（都道府県別）-折れ線グラフ/

全部表示しといてクリックでほかをopacity変化か…これいいかもしれんな…。ただWFだとクリックしたものだけ出すようにって感じなんよなあ…デザインは好きにしていいとのことだが、ロジックをどこまで崩していいものか。
やっぱり動的に縦軸が動くと低スペックSPでUX低下しそう。ただ東京があるせいで差分が出づらくなる…

https://www.e-stat.go.jp/dbview?sid=0003448231
https://ieben.net/data/population/japan-tdfk.html
https://www.meisho-do.co.jp/kyouzai2/test/jinkou/

内容

1. ゆめみフロントエンドコーディング試験 API の「都道府県一覧」API から取得する。
2. API レスポンスから都道府県一覧のチェックボックスを動的に生成する。
3. 都道府県にチェックを入れると、ゆめみフロントエンドコーディング試験 API から選択された都道府県の「人口構成」を取得する。
4. 人口構成 API レスポンスから、「X 軸: 年」「Y 軸: 人口数」の折れ線グラフを動的に生成して表示する。
   1. 「総人口」の他に「年少人口」「生産年齢人口」「老年人口」も切り替える UI を何かしらの形で用意し、表示できるようにすること。（同時に表示する必要はない）

3. チェックされてから取りいかなきゃいけない？最初に取っといたらだめって話かな？単純に考えればSWRか
4. 毎回動的生成？ある程度グラフライブラリによしなにまかせるか？そういうオプションあったはず。
   1. WFにないから結構考えることありそう…同時に表示する必要はない、か…47 x 4を一画面は現実的じゃない気がするな…かといって４つ並べると、同一県における4つの比較はできない。それも用意して5つ…？
   2. 同一県における4指標比較なら積み上げが適切だが、それは他県とは共存できない
   3. あ、でも切り替えるって書いてあるか。だから同時の想定は無いんだな。同一県における比較はやれたら面白そうだが、今回は我慢して、各4指標をプルダウンとかで切り替えるスタイルかな。単一選択のフォームとしてはやはりプルダウンが優秀か。ラジオだとチェックボックスと重複してちょっと分かりづらいしな。

制約

• React / Vue.js のいずれかを用いて SPA を構築すること。（バージョンはできるだけ最新版をご使用ください）
  - React
  - Vue.js
  - Next.js や Nuxt.js などの、これらを内包したフレームワークの利用も許可する。

遷移もSEOもないならnext.jsはtoo much
Vueの復習機会にする手もあるが…他に新しいことしようとしてるし慣れてる素のReactか（素のReactで構築したことほぼないが。）

• 都道府県一覧および人口構成情報はゆめみフロントエンドコーディング試験 API を用いること。

OK。Swaggerありそうなので見る。
-> 雑感

• /prefectures
  • messageってなんだ
  • prefCode, prefNameがArray<Object>で返ってくる感じ
  • 関東とかのエリア情報はない→今回はやめとくか
• /population/composition/perYear
  • なんで/composition/perYearで切ってるんだろ
  • クエリで都道府県コード指定して返ってくる設計なのか
  • ん…データ構造どうなってるんや…boundaryYear...?
  • dataの中に4値がそれぞれオブジェクトで入ってる…？実際叩かんとわからんな。あとでやる→年度の指定と4値の取得出し分けを確認

• グラフは Highcharts や Recharts などのサードパーティ製のグラフライブラリを用いて描画すること。
  - ただし、グラフライブラリは上記のものに限らず、任意のものを用いて良い。

Gの時の選定を参考にするが、選定方法も問われるか…あまり時間かけられないが

• Google Chrome 最新版で正しく動作すること。
• PC / スマートフォン表示に対応すること。（レスポンシブデザイン対応）
  - ただし実機でなく、Google Chrome の検証ツールで確認できれば良い。

実機じゃなくていいのは楽。であればSLAは画面幅だけでよさそう。360かなあ…→シェア調べる

• リンターとフォーマッターを適切に設定すること。（以下ツールから選択すること）
  - ESLint / Prettier / Stylelint / Biome

初だからリスクもあるが、ちょっとここはつかってみたかったBiomeを入れたい。理由はやりたいだけだが、こじつけるなら早い、ESLint/Prettierの共存を気にしなくていい。

• style は自分で記述し、UI フレームワークなどは原則使用しないこと。
  - グラフライブラリ内包の style、リセット系の CSS ライブラリについては利用可。
  - また、CSS in JS や CSS Modules、Sass などのエコシステムの利用を妨げるものではなく、あくまで CSS の記述力を測る趣旨に留まる。

リセットCSS意外と変化が早くて毎回悩むが…destyleでいいかなあ…一応調べてみるか。
CSS modulesのつもりだったが、そいや素のReactってPostCSS周りの設定がいる？基本Next.jsとかだったからわからん…
社内でCSS modulesデフォルトにしてたから、CSS in JS実務経験無いし弊社リポジトリにもほぼ実績ないんよな…やってみてもいいがちょっと詰め込み過ぎか。

• TypeScript で記述すること。

OK

• テストケース / テストコードを作成すること。
  - テストツールは任意のものを用いて良い。
• テスト実行時にエラーが発生しないこと。

OK。
どのレベルを期待されているんだろう…Vitest / storybook playfunction / playwright e2eくらい？e2eは…まあいいか、やってみるか？

• ソースコードは Git で管理し、作成したソースコードは GitHub にアップロードすること。
• Netlify / GitHub Pages / Firebase Hosting / Vercel 等の任意のホスティングサービスにデプロイし、インターネット経由で閲覧できる状態にすること。

OK。デプロイ先は…Netlifyでいいかな

注意事項

• 2024 年 10 月までの試験課題に利用していた RESAS API は新規利用申し込みを停止しております。そのため、2024 年 11 月からは、ゆめみで用意したフロントエンドコーディング試験用 API をご利用ください。

OK

• セキュリティを考慮してコードを記述してください。
  - 本 API は運用の簡素化のため、すべての応募者に共通の API Key を提供しておりますが、実際の API を使用する開発を想定し、セキュリティを考慮したコードを記述してください。

お…苦手なのでこの機会に勉強しないと…。コードにあげないみたいなことを言っているのか、CSPとかも含め？観点すらいまいちわかってない。

• アプリのコンポーネント粒度の設計、Git コミットメッセージやコミット粒度、ドキュメンテーション等もレビュー対象となります。チーム開発を意識してコードを記述してください。

1. コンポ粒度設計は正解がないからなあ…今まではatomic designをミックスしたような分割にしてたしこの機会に整理するか…
2. Git コミットメッセージやコミット粒度…これはちょっとまずいな…やはりみんなコミットメッセージ見ているものなのか…今まで最終的なコードしか見てこなかったし、社内でアンケート取ったときもそんな感じで油断してた。みんなコミットを1つずつみてる…？
   1. せいぜい修正依頼後のコミット見るくらいなんよなあ…
   2. →いやたぶん、コミットのメッセージをみて流れをなんとなく把握するのかな…気になることがあれば中身を見る？コミットメッセージの流れが意味不明だと大丈夫か確認する、みたいな？
   3. っていう感じであれば、コミットメッセージが大事、ひいてはコミット粒度が大事ってことか…コミット粒度ってどういう観点なんだ…
3. ドキュメンテーションは一旦zennに雑に書いて、最悪それだけで赦してもらうか…時間があればいつも通りdocsifyで簡易版Docsを作る

コミット粒度

• 結局最終的なコードがマージされる以上、コミットという単位で気になるのは、思考の軌跡ってことになるはず
  • 最終的なコードが同じでも、思考の軌跡がいまいちだと大丈夫か？ってなるってこと
  • それか最終的なコードで大丈夫か？ってなって、思考を辿って指摘する用ってことか？そこまでちゃんと見れてなかったなあ…レビュの仕方を修正する必要があるか。1次のとき聞いとけばよかったな…
  • あーてかもしかしてmainからfeature切ってとかブランチ運用もちゃんとしてねってこと…？
• ではよい思考の軌跡とはなんなのか
  • コミットの大きさが大きすぎず、小さすぎず
  • じゃあ適切ってなんだ…個人的には全体から詳細に落としていきたいので、命名とかの抽象的なレイヤから、順次詳細に落としていきたい。ただ、機能しないものをコミットするのは気持ち悪い。
  • 今まででいうと、環境構築＞コンポ単位＞ページ単位みたいなPRがおおかったかなあ…コミット粒度あまり気にしてなかった。なんか作り出すと一気にうごくとこまで持っていきたくはなるよね…たぶんそれをやめろって話なんだが。
• 悪い思考の軌跡とは
  • 思考の軌跡がわからない＝コミット粒度が大きすぎる、小さすぎる
  • 分割粒度が適切であれば行ったり来たりするのはいいのか？まあそれはそれでそこに至った経緯がわかるか

https://zenn.dev/tkydev/articles/4286cb9691dd6b

「中身まだちゃんと見てないけど、とりあえずコミット分けてください。」
レビュアーはレビュー時に一つずつコミットを見ていくわけですが

おーまじか…PR分けてじゃなくてコミット分けてなんだ…その文化はなかった。コミット1つずつ見るはすごすぎんか…

複数のことをやらない
書いたコードを説明するだけのコミットメッセージになるようなコミットにしない
動く最低限に近づける
コミットは「小さい方が良いが、動作する粒度」

なるほど。複数のことやらないはなんとなく意識してはいるが徹底はできてないな…

レビュアーにとって有益なコミット名にするには、
なぜ？をできる限り記載する
「できるようになったこと」を書く
prefixをつける

gitmojiね

https://qiita.com/jnchito/items/40e0c7d32fde352607be
https://qiita.com/chihiro/items/04482caebc702e75e84d

ううむ…諸説あるな…
動く単位で、みたいなのは共通認識か？
分割単位はまあ…ケースバイケースでちょっと言語化が難しいのか…TDDとかやると手順わかりやすそう。テストで1コミット、1ケース修正で1コミット的な。

ボーイスカウトは素晴らしい

ううむ…PR分けてほしい派閥だな…

https://blog.masuyoshi.com/gitコミットの粒度はレビュワーを常に意識/

・feat: 新機能の追加
・fix: 不具合の修正
・docs: ドキュメントのみの変更
・style: コードの処理に影響しない変更(スペースとか、書式設定とか、セミコロンの欠落とかの修正)
・refactor: バグ修正や機能の追加を行わないコードの変更
・perf: パフォーマンス改善を行うためのコードの変更
・test: テストの項目抜けや、既存のテストの修正を行う
・chore: ドキュメントの生成や、ビルドプロセス、ライブラリとツールをなどの変更 新機能の追加

これくらいはなんとなくはやってるな

https://zenn.dev/kiyoshiro9446/scraps/8e9fdb323ec82f

ああ、うん、これが近い。
というか今回もPR出すようにすればいいか。CI組んで一応チェックして。CI組むのちょっと大変か…
コミットツリーってみんな気にするのかな…コミットツリーがきれいきたないってあんまり意識したことないんよな…あんまり困ったことがない。スカッシュはなんか致命的にやばそうでやめた記憶

うーむ、やっぱり結構整理することが多くて新しいことはそこまでやれない…いかに適当にやってたかが浮き彫りになるな…。新しいことはBiomeくらいにしておこう。

APIについて

本 API は運用の簡素化のため、すべての応募者に共通の API Key を提供しておりますが、実際の API を使用する開発を想定し、セキュリティを考慮したコードを記述してください。

CSS

リセットCSS

CSS設計

• css modulesかなあ…
  • viteは標準で対応
• scssは必要なレベルではないかな。mixin使うほどじゃない認識
  • あー…media queryで変数使えないのわすれてた…
  • 素直にscssいれるか…

Linter

Biome

CI

• ビルドチェック
• Lintチェック
• 自動テスト？

フォルダ構成

• astomic design
  • １ページだしtemplatesは省略
• presentation/containerパターン

SLAは無いに等しいからcan i useはあまり気にしなくて良さそう

注意点メモ

• console.logはLintで消す
• セマンティクス

今週平日の対応が難しくなってきたので、計画修正。やっぱイテレーション1をいかにやり切るかか…？→記載のない事項は削る

commitizen, biomeめちゃめちゃいい感じやな…