はじめに
2020年8月から主にJavaとSpring Bootを使用したWebアプリケーション制作について学習しておりました。
その中で学んだことからポートフォリオとしてシンプルな機能のアプリを制作したので、そのアプリケーションについての機能、制作手順、課題をまとめています。
まだ実装できていない機能や使い勝手含め機能としては不完全ではありますが、
・2020年内での制作、公開を期限として制作したこと
・とにかく一旦リリースすること
を最重要視したため現状で一旦公開しております。
※今後も機能は順次追加予定です
制作期間
制作期間は 11/22~12/15
AWSの学習、デプロイ完了まで 12/16~12/30
全体として公開までおよそ5週間です。
成果物
インディーズバンドとライブハウス間の「チケット共有管理システム」
TicketManagerTool
GitHub https://github.com/KeitaUenishi/TicketManagerTool.git
制作の背景
ポートフォリオということではあるが実際に使えるもの、自身の体験から実際に課題を解決できそうなものを作りたいと考えていました。
自分は27歳までバンド活動をしており、ライブハウスでのライブを中心にさまざまなイベントに出演、主催してきました。
その中で比較的小規模なイベントなどに出演する際、基本的に来場するお客さんは「取り置き」という形で
・ライブハウスではなくバンドに直接連絡し名前、枚数を伝えチケットを予約
・バンド側がその取り置きリストを管理
・当日にその来場客リストをバンド側で記入し、提出
という流れとなっており、
お客さんはそのリストをもとに当日入り口で名前を告げ、精算し入場することが一般的でした。
この仕組みの問題点として自分が大きく感じていたのは
・当日まで全体の来場者数が読めない
イベントに出演する各バンドがそれぞれチケットの管理をしており、それぞれ日々集客活動をする中でかなりの数のお客さんと連絡をする。
そのため来場者を正確に把握するためには常に変動する数を1日ごとに管理しなければならず、手間がかかっていた。その手間により、来場予測が基本的に当日しかわからないことが多かった。
・ライブハウス側に直接連絡が来る場合もあり、それらはライブハウス側で管理する
結果的にキャンセルなどの管理も分散し連絡を密にしなければならないため手間がかかる
などの点から、来場客リストをWeb上で共通して手軽に追加、編集、削除できるアプリケーションがあればこれらの問題を解決できるのではないかと考えました。
また、現在のコロナ禍の入場制限がある状況で、動員数の把握は必須項目ですが、
このままでは日々変化する動員を逐一把握するのは困難であるため、出演者側とライブハウス側がリアルタイムで
動員数を確認できるようなアプリがあれば便利だろうというところについても考えました。
作成した機能
・簡易的なログイン機能、ライブ日程の一覧表示
※ログイン機能については新規登録機能を追加実装予定
・各ライブ日程ごとの来場客リストの表示
・各項目のバリデーションチェック、CRUD処理
制作の流れ
まず初めに、開発環境の選定と要件定義をしました。
開発環境
◦言語
Java１．８
◦フレームワーク
Spring Boot2.4.０
◦データベース
MySQL５．７
◦テスト
JUnit４
◦バージョン管理
Git
GitHub
要件定義
作成前に定義したもの
Must機能
- ライブ日程の登録
- 登録したライブ日程内にお客さんの情報を追加
- ログイン機能の実装
可能であれば
- お客さん側から、アプリのライブ日程を選択し名前を登録（ログインせずに、画面から登録）できる機能
- 現場で来場したかどうかを確認し精算完了有無をチェックする機能
- ログインするアカウント作成（各公演の出演者のみで共有）機能
- 各日程の来場予約者をカウントし、ページ上部またはライブ一覧に表示する機能
データベース設計
画面遷移図
作り方等を学習したのち、
シンプルな内容のためスピードを重視しA4用紙に手書きで作成
ガントチャートの作成
定義した要件をもとに、Trelloで大まかなガントチャートを作成
進捗内容は随時Googleカレンダーに記入し、ガントチャートと比較し管理
機能、画面実装
ひたすらコードを書き、エラーと闘いながら進めていきました。
今までの課題の学習と違い、実際に理解していないと何を質問すればいいのかすらもわからないため、正確には学習→質問→回答をもとに学習、検証→エラー解決をひたすら繰り返していたイメージです。
問題がどこにあって、どのように切り分けて考えるか。
仮説と検証を組み立て正確に問題を把握する能力が本当に重要だと実感しました。
画面の実装に関してはBootstrapを使い最低限の見た目を整えるにとどまっています。
（余裕があればもっといろいろ拘りたかったが、動くものとして公開することが最優先だったため後回しに）
AWSを用いたデプロイ
https://qiita.com/hiren/items/2a4f1b55c99ebfb3fd08
こちらの記事などを参考に環境構築。
EC2、RDSの設定後、
AmazonLinux2上にTomcat9.0.41をインストールし、webappsにデプロイ。
ビルドがうまくいっていないことによる404エラー
ローカルで読み込めているMapper.xmlファイルが読み込めていないことによる500エラー
RDSの言語設定による日本語の文字化け
などのエラーに悩まされながらそれぞれ解決し、公開。
（これらの内容については今後別の記事にまとめようと考えています）
振り返り
すでにさまざまな人が言われていることではありますが、実際に作ってみることがもっとも勉強になるということを実感しました。
これまでネット上にある記事を参考にしてさまざまなアプリケーションを写経しながら学習してきましたが、写経しながらではどういった流れで処理が進んでいるのかあまり理解できていなくても実装できてしまいます。
しかし自分自身で機能を決めて実装を進めていくと、写経だけではどうにもならないことが多々発生しました。
その中で問題点を冷静に切り分け、質問し、検証していく。
そして、解決できたときの達成感も束の間にまた問題にぶつかり、残り時間を逆算しながらできることとできないことを切り分けていく。
これらの体験も実際に作ってみないと体験できないことですし、実際の業務の中でも常に求められていくことなのだろうなと考えながら取り組んでいました。
今後もこれらのことを意識しながら、引き続き学習を継続していこうと思っております。
課題点
実装できなかった機能などもあり不完全なので、今後の課題を忘備録として残しておきます。
バリデーションが不十分
現状、ライブ日程を登録する際の日付については８桁の数字以外で入力するとバリデーションチェックがかかるようになっているが、８桁であればどのような数字であっても登録できるようになってしまっている。
ソースコードがメチャクチャになっている箇所がある
こちらはエラーなどの修正を重ねるたびにコメントアウトなどで自分の記憶に残るようにしているが、他人から見たらめちゃくちゃで意図がわからないと思われるものが多い。
実際の業務でこのように意図の伝わらないコードを書いてしまうと開発に支障をきたしてしまうことが考えられるため、今後リファクタリングをしつつも人に伝わるコードを書けるように心がけていく。
スペルミス
お気づきの方のいらっしゃるかもしれないが、GitHub上のTicketMan e gerToolというプロジェクトタイトルで既にスペルミスをしている（気づいたのがデプロイの段階だったため、現状はそのままにしてあります……）。
タイポやスペルミスなど超初歩的な部分で詰まることが何度もあったので、クラスやメソッドの命名も含めてより正確にできるように意識する。
※1/6修正 GitHubのリポジトリには残っているので気になる方はそちらへ
スマホだと画面が超見にくい
実際に使用するシチュエーションとしてスマホが中心となってくるということは考えていましたが、レスポンシブ対応などについては取り入れられておらず非常に画面表示が小さくなっています。
こちらについても早々に修正を考えておりますが、事前にユースケースについてもしっかり洗い出しておくべきだったと反省しています。
ログイン機能が不完全
機能説明欄でも記載した通り、SpringSecurityについての学習が不十分だったこともありログイン機能については中途半端な実装となってしまっています。こちらについても早々に追加実装予定です。
まとめ
反省点や改善点は正直あげるとキリがないのですが、結果的に実際にアプリケーションを作ってみるということがもっとも学習効率がよかったと現時点では感じております。
何より、どんな形であれ出来上がった時の達成感が気持ちいい！
実際に作ってみたいアプリケーションやアイデアなどは頭の中にまだまだあるので、今後も実際に形にしながら学習していきたいなと思います！
これからプログラミングを学習するという方も、ぜひある程度なんとな〜くの理解が進んだら単純な機能でも実際にアプリケーションを作ってみることをお勧めします！
そういった方々がこの記事を見て何か刺激になってくださるとすごく嬉しいです！
長文となりましたが、最後まで見ていただきありがとうございました！