Skip to content

Practice App Milestone Report

Jump to bottom
Furkan Bülbül edited this page May 13, 2023 · 19 revisions

Table of Contents

1. Executive Summary
2. Individual Contributions

Executive Summary

Summary of Project and Overall Status

Our group has successfully developed a practice application aimed at utilizing APIs that could be useful for an effective Disaster Response Platform and enhancing our proficiency in collaborative software development. Currently, the project is in its initial phase, with the majority of the basic functionality of the APIs implemented and tested.

Description of the Basic Functionality

The central functionality of our application is designed to serve as a conduit between users and a suite of valuable APIs, making it possible to access critical information with ease and efficiency. Powered by a robust backend constructed with Maven, Java, and Spring Boot, and a user-friendly frontend designed with React, our application has been built for users to easily and effectively access our APIs and obtain the functional information they need in a disaster scenario.

URL of Practice App Code and the Tag

URL of Deployed Application

Testing the Application

Using a Web Browser:

To effectively test our application, you would need: * A modern web browser (Chrome, Firefox, Safari, etc.) * Any other specific requirements (user accounts, data, etc.)

APIs can be conveniently tested using Postman, a popular API client that allows you to send requests and visualize responses in a user-friendly interface. Here's how you can do it:

  1. Go to https://www.postman.com/
  2. Create a new request by clicking the '+' button.
  3. In the new request tab, select the HTTP method from the dropdown menu (GET, POST, PUT, DELETE, etc.) depending on the API you want to test.
  4. Enter the API endpoint URL in the request URL field. The endpoint URLs are specified in our application's API documentation.
  5. Click the 'Send' button to make the request. The response will be displayed in the section below.

Repeat these steps for each API you want to test. Please refer to our API documentation for specific details about each endpoint, including the required HTTP method, request headers, request body, and the expected response.

Using Curl:

For APIs that require other HTTP methods (POST, PUT, DELETE, etc.) or a request body, you can use curl, a command-line tool available by default on most Unix-like operating systems, including Linux and MacOS. Here's how:
  1. Open a terminal.
  2. Type a curl command following this general structure:

curl -X HTTP-METHOD -H "Content-Type: application/json" -d 'REQUEST-BODY' ENDPOINT-URL

  1. Replace HTTP-METHOD with the required method (POST, PUT, DELETE, etc.)
  2. Replace REQUEST-BODY with the request body, if required, formatted as a JSON string.
  3. Replace ENDPOINT-URL with the API endpoint URL.

For example, to make a POST request to an endpoint http://app.Group1.com/api/example with a JSON body {"key":"value"}, you would type:

curl -X POST -H "Content-Type: application/json" -d '{"key":"value"}' http://app.GroupX.com/api/example

  1. Press Enter to make the request. The response will be displayed in the terminal.

Building the Application with Docker

  1. Clone the repository: git clone https://github.com/bounswe/bounswe2023group1.git
  2. Navigate to the project directory: cd Practice-App
  3. Build and run the Docker image: docker-compose up --build

Lessons Learned

Throughout the process of developing our practice application, we've come to understand the importance of effective team communication, the usefulness of our chosen development tools, and the challenges and benefits of distributed version control with git.

We found Maven, Java Springboot, and React to be robust tools for application development. Docker provided us with an efficient way to encapsulate our application and its dependencies for easy deployment. Git and GitHub were invaluable for managing our codebase, tracking changes, and facilitating collaboration.

However, we faced some challenges with merge conflicts and understanding Docker. We learned how to overcome these issues through research, collaboration, and practice.

Going forward, we aim to build on our successes and learn from our challenges to improve our teamwork and development processes.

Challenges

Our team encountered several challenges while developing our practice application. Two major obstacles were managing merge conflicts with git and understanding the nuances of Docker.

Merge conflicts typically occur when different team members modify the same parts of the code, and git cannot automatically determine how to combine these changes. For instance, there was an occasion when two team members were working on enhancing the same part of the frontend. Both members added new features, but their changes conflicted with each other. When they tried to merge their branches into the main branch, a conflict arose, and the merge process halted. To resolve this issue, we held a group meeting to discuss the changes made by both members. We evaluated the purpose and impact of each modification and made a collaborative decision on how to combine the changes without losing any significant features. We then manually resolved the conflict in the affected files, ensuring that the final version included all necessary features and functioned as expected. This experience taught us the importance of clear communication and coordination when working on shared code. One of the causes of the problem was that we were trying versioning for the first time.

Docker was a new technology for most of us, and getting comfortable with it was a significant challenge. We had a hard time initially understanding concepts like Docker images, containers, Dockerfiles, and Docker Compose. A specific instance of confusion occurred when we were trying to Dockerize our application for the first time. We struggled with writing an effective Dockerfile that could build a Docker image for our application. The image either failed to build or, when it did, our application didn't run correctly within the Docker container. To overcome this hurdle, we divided the task among team members and conducted focused research on understanding Docker's concepts and best practices. We also sought help from online communities and forums like StackOverflow. After consolidating our findings, we conducted a series of trial-and-error experiments until we successfully created a Dockerfile that built a working image of our application. This challenge reminded us of the importance of continuous learning and persistence in software development.

These experiences, while initially challenging, have improved our ability to work as a team, increased our problem-solving skills, and broadened our understanding of the tools and technologies we use. We believe that these lessons will prove invaluable as we move forward in our software development journey.

Individual Contributions

🏠 Home

Team Members

Cmpe451 Ind. Cont. Reports

Project Plan

Requirements

Refactored Mockups

Refactored UML Diagrams
  • ..

Milestone Reports for Cmpe451

Lab Reports

Communication Plan

Templates

Cmpe 352

Clone this wiki locally