kaza.ooo

This is a report on the participation in the Qiita Hackathon by team:m1nus. I will introduce the team members, the theme, the process, and the results of the hackathon.

Event Summary

Event Name: Qiita Hackathon 2024 Preliminary Round
Date: Saturday, September 21 - Sunday, September 22, 2024
Place: Online
Organizer: Qiita
Theme: Open

Meet the Team

Team name : m1nus

We named our team after character "minus" because we believe that subtraction is important in product development.
Membership :

I asked my labmate Mr.I to join us, and Mr.I asked Ms.K and Mr.O, the engineers at Mr.I's part-time job, to join us. We were the most fun team members! Thank you for getting together!

The roles of each member are as follows.
```
Team Leader: me
Frontend: Mr.I, Ms.K, and Mr.O
Backend: Mr.I and me
Design: Mr.I and Ms.K
Cloud infrastructure: me
```

How to proceed with development

Day 1

10:00-13:00

First, we had time to discuss the theme of Open by summarizing our ideas on miro. Each person explained what they felt about Open, and the ideas expanded from there as if they were playing an association game. There were so many interesting ideas that it was hard to narrow it down to just one. miro

What I felt was great about this ideathon was were able to discuss as a team until everyone was satisfied when deciding which idea to turn into a product. For reference, we did a tally of which idea we wanted to implement by majority vote, but in situations where even one person wanted to create something different, we were able to discuss it until both sides were satisfied.

As a result, we were able to unify our direction with the idea of making our own private space, the house, more Open. ideathon

13:00-18:00

With the direciton set, we began to put together specific requirements. What was particularly important was the Minimum Viable Product(MVP). Since hackathons are largely a race against time, we spent a lot of time classifying what were "essential functions" and what were "good functions" in order to provide minimum value through product.

I think the reason we were able to build a minimum working product within the hackathon period was bacause we were able to spend a lot of time here and clarify what to build and what not to build.

On the other hand, there were a lot of interesting features on the list of "features that would be nice to have," so it was frustrating that we could not get to the point where we could implement them.

Essential Functions

Functions	Descriptions
User Registration & Login	Register home address as well for future expansion.
"You can come home" status	The ability to publish the status of anyone who can come to the house and update the status in real time. Ability to retrieve your status.
Location-based information sharing	Share the exact location of the house to enable visits and help (initially open to all users).
Statu List	Ability to display a list of other users' statuses on the home screen. Status of "you can come to our house" opens the door.

Preferred Functions

Functions	Descriptions
Friends list and public range control	Ability to create a friends list and limit the public scope of notifications and statuses
Help request notifications (push notifications?)	Ability to send notifications for help in emergency situations such as cookroach extermination or rain control
Notification of calls for interaction	Ability to invite participants for specific activity purposes (e.g. let's play mahjong.) with notifications that include nearby strangers.
Same sex only	Ability to share statuses only with people of the same gender
Status expansion	Addition of "unlocked" status, etc. Users creating statuses, etc. This can also be used to get a current location other than home, so that people can gather there.
Maps	Make it easy to see on the map.
Authentication	User Authentication
"Comming!" Button	Let you know, "I'm on my way!"
Put a note on your status	Allow users to post status + notes
Get only friend's state

18:00-24:00

From this point on, the back-end and front-end were separeted for implementation, so I will summarize the work I did on the back-end side.

However, for each of the functions listed in the essential requirements, the following is a summary of the work I did on the back-end side.

User registration and login function

Implemented using the front end and Firebase Authentication
Functions around user home status and location information

The "user home status and location information" functions are directly retrieved from Firestore and displayed by the front end.

Therefore, we decided to start building a basic API for acquiring user status and an API for registering, acquiring, and deleting friends to make their status public, which was one of the "nice-to-have" features.

We used FastAPI and SwaggerUI to display the API specifications, and proceeded in a document-driven manner to synchronize with the front end. I was impressed by the convenience of being able to run tests on the API within the specification screen!

Day 2

0:00-9:00

Since the basic API implementation was completed, we moved on to debugging to ensure the API could be used without the need to build a local environment on the front-end side. Initially, we planned to deploy it to Vercel, but for some reason, the integration with Firebase using environment variables did not go well, causing us to get stuck. As a result, we switched to deploying it to GCP, which has better compatibility with Firebase.

We containerized the FastAPI project in Docker and pushed the Docker image to GCP, pulled the image from Cloud Run, and called the serverless API from the front end. When the front-end team requested modifications, we were able to deploy and reflect them easily, which we feel improved our development efficiency.

9:00-13:20 (Submission Deadline)

While modifying the API as necessary, it was time to start preparing for the presentation. As the front-end team was working on the final design of the presentation, I concentrated on making the presentation slides. However, since I had not slept at all up to this point, I could not think straight when putting together the structure of my presentation.

In the end, with everyone's help, I was able to complete our slides 5 minutes before the deadline and had to rush to submit them. I felt like I was submitting my graduation thesis close to the deadline.

Final Product

The final presented products are as follows. I didn't sleep at all, but the fun of development prevailed and I didn't fell sleepy.

Product name : Wanna come to my house?
Presentation :
Technical stack used :

Lessons Learned/Reflections

Good Points

I think that the active discussion in the team was a crazy good thing. I feel that all the conflicts were meaningful, and I am grateful to the team members for creating an atmosphere that allowed this to happen.

I especially enjoyed listening to the front-end team's discussion on screen design during the break.

The other thing I like about hackathons is that I get to meet a lot of geeky engineers. It really increased my desire to catch up on technologies used by other teams that I didn't know about.

Reflections/Learnings

One of the conflicts was a discussion about whether we should use NoSQL or RDB. We decided to use Firestore's NoSQL because of its speed and the fact that we wanted to create something that would work for now, but I felt that we needed to understand the advantages of each in a more systematic way.

Qiita Hackathon Participation Report