Library Project

Final project from my DFE Software Development Bootcamp.

Contents

Why are we doing this?

The final part of my QA Academy DFE Software Development Bootcamp was a practical project. This piece would combine and demonstrate the methodologies and technologies learnt throughout the course.

The objective of the project was to create a Spring Boot API (application programming interface), a software interface that could provide services to another piece of software (probably a front-end).

The specifics of the objectives were

“an application back-end developed using the language from your Programming Fundamentals module (e.g. Java) a managed database hosted locally or within the Cloud Provider examined during your Cloud Fundamentals module (e.g. H2 or MySQL (local / GCP) a means of making API calls (Postman) and a means of checking persistence (Workbench/H2 console)”

Project requirements and technologies used

The project requirements were:

Code fully integrated into a Version Control System using the feature-branch model: main/dev/multiple features.
A project management board with full expansion on user stories, acceptance criteria and tasks needed to complete the project.
A risk assessment which outlines the issues and risks faced during the project timeframe.
A relational database, locally or within the Cloud, which is used to persist data for the project.
A functional application ‘back-end’, written in a suitable framework of the language covered in training (Java/Spring Boot), which meets the requirements set on your Scrum Kanban board.
A build (.jar) of your application, including any dependencies it might need, produced using an integrated build tool (Maven).
A series of API calls designed with postman, used for CRUD functionality. (Create, Read, Update, Delete)
Fully designed test suite for the application you are creating, including both unit and integration tests.

For my project I stuck with what I know and built on earlier work I had done during my bootcamp, choosing to make a simple library api. Due to the simplicity of the project, perhaps “book database” would be more apt. I was also inspired by the amazing ebook manager calibre.

Technologies used:

Table of technologies used:

Technology	Function	Version	Website/download link	Eclipse Marketplace link/Maven dependency link
Java	Programming language	Java 11	download
Spring Boot	Framework and inversion of control container for Java	2.6.3	website	link
H2 database	Java database	mangaed by Spring Boot	website
Maven	Build automation tool	3.8.4	download
Postman	API development support app	9.12.0	download
Git	Version control	2.24.3	website
JUnit	Testing Framework	managed by Spring Boot	website	maven repository link
Jacoco	Code coverage library	managed by Spring Boot	website	eclipse market place link for EclEmma code coverage tool
Mockito	Mocking framework for unit tests	managed by Spring Boot	website
Jira	Online project management tool		website
GNU Bash	shell script	3.2.57(1)	website

How I expected the challenge to go

I think I expected the project to go fairly well, even though I was less confident in, and had less experience of the Spring Boot framework than I might have liked. I had been using git and pushing my code up to GitHub over the last three weeks so I felt fairly confident in using git and GitHub. Whilst I still felt a bit unsure about my Java and testing skills, I did feel like I had a fairly robust theoretical knowledge and good notes and resources to rely on.

What went well? / What didn't go as planned?

Strengths:

I chose to build up the app from a very basic functioning version containing only controller and entity classes, without repository or service classes. This meant the project took longer than it might have done because it added more steps, the initial code contained some elements that were not used in the final product and conversely, the final product with the integrated service and repository classes contained some new code not in this first version. However, despite the time and effort this process took, I believe it was well spent as it meant I had a functioning app pretty much all the way along, apart from some odd bugs. I refactored my code incrementally and made sure new components were fully integrated into a functioning app before expanding further.

Weaknesses and troubleshooting:

As could have been predicted, I think some of the weakest areas of my project were the ones where my learning was quite a while ago, or I had spent less time on the topics. Apart from git, which I had been practicing, my knowledge of Jira software and the epic, user story and task model was rusty. Similarly, using the Spring Boot system was slower, as my theoretical understanding of the frameworks was less cemented.

Some problems cannot be predicted as such. On the afternoon of day three of doing my project my laptop died. The hard drive failed and then failed to boot or even recognise that it existed.

The saga of my computer issues

Further details

Luckily, I had been regularly pushing all my code to GitHub, so only lost the code for one test method. This mitigation ****** was exactly what I had written on my risk assessment two days prior.

Whilst I had not lost much work, I had to 1) find a new computer to use, and 2) set up a workable environment on said computer. I here would like to give great thanks to my brother for lending me his computer. Luckily it has the same OS as mine so that made everything easier.

The set up of my work environment probably took at least four hours. I had to do the following:

installing my IDE Eclipse
setting up an SSH key for my computer for GitHub access
cloning my project down from GitHub
installing MicrosoftTeams (for taking part in scrum meetings with course mates and tutors)
installing Spring Boot
installing Maven
adding Maven to the machine path
setting the path for $JAVA_HOME because that had not been set
configuring Eclipse so that it found the JDK so I could get the basic JRE libraries
installing EclEmma Jacoco coverage viewer
installing Postman

Overall I feel I dealt with this setback well and was very resourceful. Reinstalling and setting up my work environment also refreshed my setup knowledge for the technologies I was using. Ultimately, my project did not hugely suffer from my computer issues. The main impacts were:

Not having time to install and set up MySQL, therefore using H2 as my primary database.
Losing screenshots of Postman showing (almost) complete functionality from day two of my project work.
Having no time to add any, even minor, additional functionality.

In adition to a predictable amount of bugs that cropped up in my code which I was able to analyse and rectify (sometimes with support from colleagues and tutors), a few cropped up which I don't understand, but I still fixed:

At one early point my Spring Boot application was failing to boot, the application context wouldn't load. After some troubleshooting, we found that removing a Spring Fox dependency I had resolved the issue. It was probably this bug or something similar.
I was having trouble getting my H2 database to persist. I could see in the console output that the database kept dropping and then recreating itself on each start up. I tried a few configurations of my application-dev.properties file. In the end we fixed this issue by designating a file rather than the in-memory location, as explained here, which fixed the issue.

Possible improvements for future revisions of the project.

A few smaller functional changes which I would have liked to implement, had I more time are:

Utilising optionals so that incorrect requests would not cause a program shutdown.
Implementing custom exceptions.
Adding functionality to check the validity of an ISBN (International Standard Book Number) entered. This could be use a regex package, or could be a script like this.

Some more advanced improvements for an expanded project:

Adding custom queries for returning books of the same genre code (I used the Thema subject categories scheme) such that one could do a GET request to a url such as “/books/genre/general-fiction” and receive a list of all books with the genre code “FB”. (As I am using a recognised system like Thema, that data may be available online in a way that could potentially be collected and used automatically). Though the request in itself would not be hard, it would be the mapping of the genre url text and the genre code which would take more time.
As implied above, my Library project is very basic and is currently functioning more as book metadata storage. Therefore, further improvements would be adding user and loan entities and connecting them so that users could have loans of specific books.
Another avenue for expansion is that ISBNs actually contain quite a bit of data (see image below). Contained in the number sequence are values that map to a publishers, terretories or language groups and more. If my project could access such data then it would be possible to automate fields such as “publisher”.

Screenshots showing postman requests and the output from the API.

Whilst I did have screenshots of Postman showing (almost) complete functionality from day two of my project work, these have been lost as they were on my computer desktop (see above). Whilst those would have been nice to have the following screenshots demonstrate full CRUD (create, read, update, delete) functionality for my api.

Screenshots

Create functionality

Adding the book V for Vendetta using a POST request to localhost:8080/books. The request response is a 201 Created status and the book which has been inputted.

Read functionality

A GET request to localhost:8080/books, which gets a list of all books and a 200 OK status. You can see the newly added V for Vendetta.

Delete functionality

A DELETE request to localhost:8080/books/9780316449052. That is the ISBN of Rosewater. The response is a 202 Accepted status with no body data.

The previous DELETE request has worked and Rosewater is no longer returned in a GET to localhost:8080/books.

Update functionality

The Heart of the Race has been posted to the api.

A PUT request is used to edit the data for Heart of the Race. It returns a 202 Accepted status and the updated book data.

Read functionality

A GET request to localhost:8080/books/9781786635860, which retrieves a 200 OK status and The Heart of the Race with updated author fields.

Screenshots of database to prove that data is being persisted

Screenshots

The Catcher in the Rye has been added to the database on 3/2/2022.

A SELECT * FROM Books query shows all books in the database on 5/2/2022, including The Catcher in the Rye which was added two days prior.

Screenshot of test results, including coverage report

Screenshots

20/20 tests passing, including web integration, system integration and unit testing.

89.1% test coverage.

Jira Board Link

rosemadr/DFESW7_Final_Project

ErrorLooks like something went wrong!

About

Resources

Uh oh!

Stars

Watchers

Forks

Releases

Packages 0

Uh oh!

Languages

Error
Looks like something went wrong!

Packages