Introduction
Coming to the end of the second quarter of my senior project, I decided to use this blog post to reflect on my experience, and what I have learned in the so far. Having been a college student since 2016, I’ve been looking forward to getting to this point in my studies for years. To be honest, I had no real idea of what to expect from my senior project. However, I did have some goals and those goals were mainly to grow my skills in whatever way I could. So that’s what I did!
As some background, my project’s goal is to create a site which allows students to connect with mentors which match their technical and professional aspirations. Once a mentee is matched with a mentor, they will be able to reach out to the mentor in order to initiate a conversation regarding starting a mentorship. The mentor will also receive a small background including the mentee’s bio and the interests that they matched on. This site would be a full-stack software engineering effort, with the goal of building a safe, secure, and equitable platform for all prospective mentees and mentors.
FERPA
One of the first big topics our team had to research was FERPA, which stands for the Family Educational Rights and Privacy Act. The keyword in FERPA for us being educational and right to privacy. Because our application deals with student data, we need to take special consideration in not only the data that we collect, but also how we use it, how we share it, and where we store it.
First we needed to ensure that the platform we chose to build our application on would be FERPA compliant, and it would be safe to use for student data. Our platform Firebase is FERPA compliant, so we were good there.
Firebase FERPA Compliance Documentation: https://cloud.google.com/security/compliance/ferpa
Once we had a safe platform picked, we then needed to design and implement a FERPA compliant solution. This included meeting with our partners at OSU and gathering information on what data we could and could not gather and share. We learned about the difference between directory information and non-directory information, and what data is covered under FERPA. After diliberation and careful consideration, we decided to opt to only use directory information in our application and not collect information like what a student’s current program of study is. Instead, we would ask questions like, “what is your technical interests”. This way the data we gathered was not sensitive by FERPA standards.
User Agreements
Following FERPA compliance, we realized that we would need to understand what considerations we should make in terms of a user agreements. In order to uphold the integrity of the site and protect the community, user agreements must do their best to address potential abuse and misuse of the site through an acceptance of a terms of service when the user signs up for the site. User agreements are really there to protect the user and the other users so it’s important that the right information is contained. We learned that information like limitations of liability, right to terminate accounts, and how the user’s data and privacy is addressed are important key clauses to have in any user agreement.
Github Actions
For deployment of our code we opted to go with Github Actions as our source control solution was Github. I had never previously used Github Actions before, but I had used YAML before in other CI/CD tools like Jenkins and Azure DevOps. Github Actions is very similar to other CI/CD solutions, and can be configured to trigger on particular branches, and breaks up it’s work by jobs, steps, and tasks.
Firebase APIs
Our solution for hosting, Firebase, came with a lot of useful products which we integrated into our application. These products all came with APIs which could be easily integrated through an NPM package, which Google provides, and made tasks like setting up authentication, database storage, and file storage very straightforward. For example,
Authentication – Firebase’s authentication solution allows you to integrate with multiple identity providers with little configuration, and allows you to manage and store the users who signup for the app through an intuitive and easy to manage portal.
Firestore – Firebase’s database solution is called Firestore, which allows you to store data in a Json format. This works very well with application built with React because Json is the object notation used for all classes in Typescript in Javascript, so data could be stored in the database exactly as it does in the programming language itself. This is important because it makes the API very simple to implement since it needs very little logic to actually write the data to the database.
Storage – Firebase’s storage solution can be used to store files like in our case, profile images. Similar to the previous two solutions mentioned, there is a built in API which Firebase provides to send and receive file data from this storage account with very little overhead interms of code.
Asynchronous Development
Personally, I come from a software engineer background where I have worked on projects similar to this one, in a real professional development environment. This was obviously not the situation that we have in this course, as much as we tried to strive to create a similar feeling, our group is comprised of people with various levels of experience. Not only that, but all of us were in different timezones. At one time, only three of us at most would be awake and available at one time so it became basically impossible to get everyone in a meeting at the same time this quarter. Through these considerations arose asynchronous development strategies.
We adopted a methodology to,
- Make changes to the code on our own branch
- Communicate those changes to the code in Teams
- Commit those changes, and push the changes to the Dev site
These steps are straight forward, but missing any of these steps always caused us to get out of sync with each other. Through this I learned how to work as a development team when meeting times are highly constrained.
Leave a Reply