CSUMB CST 438 Final Project Report

BY ERICA HICKS | DATE 6/18/2021

PART 1: WEBSITE SCREENSHOTS

Below are screenshots of the web app we deployed to Heroku.

Figure 1: As a user, be able to search for a hotel by city

Figure 2: As a user, be able to view info on the hotel

Figure 3: As a user, be able to select a hotel

 Figure 4: As a user, be able to select a room

Figure 5: As a user, be able to select the date to check-in and check-out

Figure 6: As a user, be able to create an account and login to confirm booking

 Figure 7: As a user, be able to cancel a hotel reservation

PART 2: LESSONS LEAR NED

This project was challenging but presented a lot of opportunities to learn from our mistakes. I learned a
lot about software engineering, project management, and soft skills beyond teamwork.

Web Service Architecture and REST

I learned how web services can be built and deployed on Heroku. More specifically I learned how Web
Service Architecture is a type of Service-Oriented Architecture that breaks the application into separate
services that communicate each with their own databases, underlying technologies, and teams
maintaining them. This is opposed to the Integrated Database design where the application has one
shared database that all the parts of the application link to. Tightly linking data and code is simpler at
first but does not scale well. With services, teams need only communicate the api as opposed to any
implementation details of the database or code.

REST apis are a type of Web Service Architecture. REST stands for Representational State Transfer. In a
REST api, web services communicate using the HTTP protocol GET, PUT, PATCH, POST, and DELETE
methods with data in json format in the body of the HTTP message.

I learned both how to use a REST api, like the public openweathermap api, and how to build and define
my own api. I also learned the difference between using a REST api to communicate between services
and a message queue like rabbitmq. REST is synchronized while a message queue is asynchronous, so
the code does not sit and wait for a response. After sending a message using HTTP, the HTTP protocol
dictates the code must wait for a response whether that be an HTTP 200 success response or an HTTP
404 not found error response.

The Agile Process of Developing Software

I learned the difference between Waterfall and Agile software development. In Agile, instead of well-
defined requirements, more informal discussions take place around short user-stories. This allows the
project to get going quicker and to be flexible and more focused on user needs than technical
requirements. Delivering the project in increments at the end of short “sprints” where some features
are implemented while others are left for later, allows for the client and/or user to provide feedback
earlier on so the project stays on track according to their vision and needs.

Defining and Tracking Requirements

I learned about BDD, behavior driven design, which uses the user stories described above. I learned how
to use Pivotal Tracker, a free project-planning tool for creating a shared task list with the project team
and creating reasonable estimates of when the project will be delivered. Each user story is given a
difficulty score, and the goal is to finish ten difficulty score points a week. Pivotal tracker allows user
stories to be marked as started, finished, or accepted. It was confusing at first that the current
iteration’s completed user stories would not move to the done column until the current project iteration
was over. They would just turn green and sit in the current week’s task list. The pivotal tracker interface
is not very intuitive in some ways, but the capabilities were still useful and powerful. For example, I
learned how to add blockers, so it was clear which tasks we were not able to work on until later in the
module-week when we could get help from the professor.

Testing
I learned how to create junit tests using Mocks so that the tests could run faster without making an
actual connection to the database. I also learned that unit tests should not be written for each method
as I always thought but should instead be written for each action a user can take. Using the phrasing
“given x, when y, then z” to define tests, is a helpful way to think about testing what should be returned
or set for a given user input instead of what interactions should occur. State testing is less brittle than
interaction testing because it focuses on what the public-api promises the user of the code, not on the
implementation details.

I also learned that it is better to ask for help than waste days debugging and trying to fix defects on my
own. It is hard to track down some bugs, like when half of the imports were from junit v4 and half were
from junit v5 creating a strange error with not much to work off of for debugging. I wish I got a chance
to do the assignment on how to use Selenium for end-to-end integration testing but did not have time.
Instead, every time I pushed code, I had to go to Heroku to see if the build was successful, open the web
app and MySQL to see if everything was working as expected and saving or deleting from the database
properly, and open the Postman tool to test the api. I learned having an integration testing tool would
be useful.

Communicating and Working across Teams

During the project, I learned how to work with other teams through trial and error. The first iteration,
we defined our api based off assumptions of what the api user needed. When delivering the api, our
documentation was sloppy creating some confusion which had to be quickly resolved. The second
iteration, the api user asked for more specific api features and clarification on some formatting like
dates. Starting with a loosely defined api allows for faster development, but it is important to have a
tight feedback loop so errors and omissions can get caught and rectified quickly.

Concluding Thoughts
There were many mistakes made along the way during this project. This project and this project report
have been a good learning opportunity on how to do a failure or root cause analysis when project goals
are not met to avoid repeating the same mistakes next time. I hope to implement these lessons in future
projects.