# インターンテキスト v3.5検討＠2025

2025年は、3.5からバージョンアップは行わないが、準備や内容を向上させる。
今回のチューターのスキルや伝えたいことも鑑みて、テキストを再構成する。

# 前回の想定スケジュール
＊1st
10:20～10:50　趣旨概説
10:50～12:00　端末操作、環境理解、個人打鍵、リストアップ
13:00～16:00　改修方法概説、各班リストアップ、アサイン、改修開始

＊2nd
10:05～11:00　基盤系デモ→今年はRAGハンズオン、移植案件
11:00～12:00　改修継続
13:00～15:00　改修完了
15:00～15:30　発表準備
15:30～16:30　発表

くらいの想定なので、
テキストに沿っての説明時間は、
初日の4.5h程度と考えられる。
初日で、一通り各自での動き出しをしてもらえるように進めて、
午後でバグ発見、まとめ、担当決定、実際の改修まで入ってもらえるように進めたい。
二日目は、もう思うとおりに改修に専念してほしい。

そう考えると、
1. 概説　：　10分
2. 操作ツアー　：　10分
3. バグ管理ルール説明　：　10分
4. 端末操作説明　：　10分
5. 修正方法説明（DB）　：　10分
6. 修正方法説明（リテラル）　：　10分
7. 修正方法説明（コントローラ）　：　10分
8. 修正方法説明（リンク）　：　10分
9. 修正方法説明（ルーティング）　：　10分
10. ログの見方説明　：　10分
11. git操作説明　：　10分

2時間程度。
ただし、かなり参加者の理解が速く、
ネットワーク不調や端末依存の不具合がないことが前提で、
バッファを見ていない見積。
全て二倍かかった場合、初日が終わってしまう。

上記のように、
一旦テキストは駆け抜けてしまって、
実際のところは、それぞれ操作しながら進めていこう、
という方が、開発体験として良いものになるのでは？
要相談。
→上記方針で決定！

# 今回の改善検討
- 環境構築の改善検討
- →現状はgit活用、各自PCローカル開発環境利用、という、一般的チーム開発スタイルを念頭に、WSL利用としている。
- →問題は、回線が限られているため、Windowsアップデート、WSL環境構築を複数端末同時行えない。環境構築の手間がかかる。
- →案として、LinuxはAWS環境に用意すれば回線利用はWindowsアップデートのみとできる。
- →WSL上での開発は、vscodeの連動が楽ではあったが、AWS環境利用なら普通に修正してscpで良いと思う。

# 今回の要素検討
- 前回の基盤系デモに代わって、今回は何を行うか？
- sprig移植案は取り敢えずやってみた。アプリも基盤も伝えられることはありそう。時間あれば使っても良いかも。
- AWS環境利用を出来ればやっておきたい。今後が楽になるはず。仮想の話題を出して、そもそもが理解できるかや、理解できたとしても物理の面倒さを実感していないと、説明の効果は薄くなるかも。

# 前回の振り返り
- 発表に何を求めるか明確にしておくべき。最初の一人の流れを踏襲しがち。時間管理も甘くなりがち。
- 発表は結論ファーストに。
- gitでこまめにコミットしといてもらう方が良い。手戻り対策。
- 情報連携手段としてmattermostは有効だった。「gitで各自の修正をマージ」という方法を使わない場合の、チームの完成アプリをどうやって作るか？という点で、何らかのテキスト共有が必要という観点で。
- 各自がローカル開発環境での改修を行うが、発表用のアプリはどうするのが良いか？2025年度xx班リポジトリ、という形でフォークしておくか？誰かのローカル開発環境を、発表用にマージとするか？マージ作業に時間かけてほしい訳ではない。チューターで対応するか？各班で発表用端末を用意するか？
- 発表での画面共有で時間が想定よりかかった。発表のやり取り、流れはチューターでリハしておくべき。最後の発表の前に一度画面共有を練習する流れにするか。初日の終わりか、個人作業の中で中間確認として、など。
- バグの共有でホワイトボードを利用するが、担当やステータス記載などあると分かりやすいなど、アドバイスはした方が良いかも。先ずは紙にざっと書いてもらって、ホワイトボードは整理した表にしてもらう？エクセルなどに整理もしてもらうのも良い。
- 今回の環境構成図、アプリ構成図など、MVC構成図など、何らかの観点で幾つか図があった方が良いと思う。

# 結果としての準備状況
- AWS環境構築済
- RAGハンズオン準備済
- 移植案件準備済
- チャット、ファイル共有としてのMattermost準備予定

# 終了後、反省
反省は、、
- フォーマッタを準備すべきだった
- 改行コード、全角スペースの可視化をすべきだった
- vscodeでgit commit、git diff見えるようにすべきだった
- 基本的にテキストのコピペをおすすめすべきだった
- エクセル共有の仕組みを用意すべきだった
- 発表の際にタイムキーパーをお願いすべきだった
- 発表の際にQAを行うべきだった
- 手順に電源設定を入れておく
- もっと修正の根拠や修正の方法についての議論の時間を取りたかった
- 修正方法の説明、不要かも？資料見ながらやってみよう、で良い？
- サーバの時刻を日本時間にしておくか、それもバグに組み込むか
-

良かった点は、、
- 今回は回線について問題はなかった
- 端末スペックが良かった点は好評だった
- 各班2名の割合でチューターついてもらえたので円滑に進められた
- チャットツールは必須だった
-