Reflection On My First-Year Capstone Project At Holberton School
What I’ve learned from my final project of Foundations at Holberton School
Introduction
I can’t believe my first year at Holberton School is already coming to a close. It seems like just yesterday that I didn’t know the difference between a terminal and a shell, let alone how to use them, or what a virtual machine was, or how to edit a file with Vim or Emacs, or how to push a commit to GitHub. I’ve come so far in just 9 months. But the final project stretched me in ways none of the prior projects did. Here’s how that project went from my perspective.
Context
Students at Holberton School are divided into Cohorts, which are groups of students who progress the curriculum simultaneously and are expected to support each other through the learning process. There is a global cohort, which is the global community of students who at the same point in the curriculum, and there is a local cohort, which is the subset of the global cohort enrolled at a specific campus.
Foundations is the name of the first year of Holberton School. It’s divided into trimesters of three months each. During the last few weeks of the final trimester, students are required to research, prepare, and present a final project. Typically, Foundations projects are done in groups of three or less, though teamwork is encouraged.
I joined Cohort 14 at the New Haven campus, which began with 6 students. Statistically, one third of the students drop out by semester two, which is exactly happened. For the remainder of foundations, there were four of us. Fortunately, we had strong synergy. I think we would all agree that we got very lucky.
Semblance: Cohort 14 New Haven’s Capstone Project
The Project
Our final project is called Semblance. The purpose of Semblance is to connect people with their local communities by facilitating real-life, authentic, face-to-face conversations.
Semblance is the brainchild of Thomas Francis. Thomas is the entrepreneurial, no-idea-too-big type of thinker who’s always contemplating how the world might be improved from an empirical perspective. He had begun work on Semblance before he pitched it to us as a final project idea. Even once he suggested Semblance to us, it was long before we needed to choose a final project.
The Team
Our team consisted of myself, Nels Fichera, Thomas Francis and Carson Stearn. Thomas and I primarily worked on the back-end, while Carson and Nels worked on the front-end. I had two significant contributions: SendGrid integration and major work on the GraphQL schema. I made my team aware from the beginning that I had little interest in working on the front-end of the application. While it’s certainly rewarding to get visual feedback from code, I no longer find designing visuals, graphics, etc. more satisfying than writing functions with no visual interface the way I used to. In fact, I have come to find CSS to be a pain. I was perfectly satisfied working on the back-end and making it efficient, clean, and secure, and I believe I did improve our codebase in those areas.
My Motivation
I think I was the only one who wasn’t immediately on board, all though I didn’t reject the idea either. I was debating working on a solo project that fell more in line with my personal interest in the intersection between music and computers. However, I had a few reasons for not going solo. First, I was already working a side project that scratched the music + code itch so to speak. Second, I didn’t have a clearly defined vision for what I wanted out of a personal project, the best I had was a direction to head. Finally, judging from other presentations, it seemed like working as a team was never a poor decision. Teams are able to accomplish much more than individuals, and it generally seems to result in a more rewarding experience. I certainly don’t regret working on Semblance. I learned so much, not only about how to build a web application, but about how to be an effective team member as well.
The Timeline
By mid June we began our proposal for Holberton staff to approve it as our final project. We also drafted design and UX ideas. We did a lot of brainstorming and resource sharing between July and September, but we didn’t schedule tasks until the beginning of October. For my part, I spent several hours in of September learning how the project was structured, how to use Pyenv and Pipenv (and what the difference is!), how to use Docker, and reading up on Postgres and Django.
Tech Stack
Our stack contained more technologies than it makes sense to outline here, so I’ll just comment on the ones I worked with. Our project research paper contains a more comprehensive list if not an exhaustive one.
Docker
Using Docker (along with our package managers and virtual environments) made sure our services had deterministic builds. This ensured the app ran the same on Mac or Windows, and minimized the amount of installation each team member needed to do locally.
Django
We had some great resources for building apps using Django, so using it meant saving time researching. Django is both powerful and convenient. It served us well.
GraphQL
GraphQL consolidates an API into a single endpoint. Once implemented, it mean that we could make GraphQL requests for any data defined in the schema. That made the search function I was tasked with writing rather simple. It also means expanding the database does not also require expanding our API, it just may involve updating the schema.
Accomplishments:
App Architecture
Our app was divided into four containers. A web container handled HTTP requests, our front-end container ran Node.js, our back-end container served our Django app with Gunicorn, and finally, we had a database container running Postgres. The flow of data is essentially in that order. An HTTP request comes into the web container, which requests the front-end page. Searches made from the front-end request the API listening on the back-end. the API queries the database container and the data gets returned in the reverse order as it was requested.
SendGrid
The first task I was entrusted with was implementing SendGrid. The documentation on integrating SendGrid with Django was clear and thorough, so it didn’t take long to get it connected. SendGrid requires emails to be sent from a verified domain, so we purchased one. I modified the default .txt email template to be specific to Semblance, but what I would have liked was to set up an HTML email template. I tried adapting an HTML email that I received from another service, but I was unable to get configured in time for our presentation.
GraphQL & Graphene
My next task was to create a function that could search the database for users based on filters including gender, location and proximity, and archetypes the user identifies with.
First, I needed to understand what GraphQL was, and how to make a GraphQL request. While learning how to make GraphQL requests, I found that our schema did not accept any arguments. I thought that was unfortunate because arguments make filtering easy in GraphQL. So I started to learn how to make our schema process arguments.
We used Graphene to integrate GraphQL with Django. Graphene allows you to define the GraphQL schema. The schema is basically the definition of what data/tables you want to allow a GraphQL request to be able to access, and any available parameters. Results can be further filtered by passing arguments, which are interpreted by a resolver. The resolver was the key to processing arguments.
I found the documentation on Graphene to be lacking, and it took a lot of trial and error and logging to understand the datatypes being passed around and what classes different functions expected. I eventually was able to update the schema with custom types, and write a resolver that allowed filtering by location and distance, gender, and archetypes. I expected to have to write the code that filtered by distance and location myself, but I stumbled across a post on Stack Overflow that described how to filter a query set by said parameters. That was a major accomplishment as it made custom searches for users possible, which was a key part of what we wanted in the user experience.
Once the schema was updated and the resolver written, I was able to write a function for the frontend to pull data from the backend. The function is fairly simple; It’s just a GraphQL query (which is just a HTTP request with a certain format and syntax), made in vanilla JavaScript. I was able to show that a GraphQL request could be made from our front-end container to our back-end container, and return JSON data. All that remained was to get the parameters from the frontend components and to write a component that could display the results.
Improved Security
I think the security improvements to Semblance may have been the most important contribution I made long term. I noticed a few security issues, so I took it upon myself to address them. I made the change from embedding secrets in our source code to exporting them to environment variables and changing them so the previously embedded secrets became obsolete. I also privately shared environment files with the team so that their code would still work. Finally, anything I could not solve on my own I added to checklist which the team had access to, so everyone could be aware of the security issues yet to be addressed.
What I’ve Learned
I had no idea how much work could go into even a small web application. I’m not exactly surprised, but I have a deeper appreciation for the process. I realized more than half the battle is reading documentation and thinking about which approach to a problem would be optimal. A small part of the processes is actually writing code.
The biggest challenge I faced was figuring out what NOT to learn. We had three weeks of time strictly dedicated to our project, and with so many technologies, we had to be very efficient with the time we spent learning lest we fail to actually implement anything. I certainly spent more time than was necessary learning Postgres and trying to figure out how to get an HTML template set up. It was important to prioritize tasks based on what would be most impactful. It can be hard to discern what information is essential and what is secondary. When in in the thick of it, I found it easy to lose perspective and think that whatever I was currently interested in was much more significant to the project than it actually is.
I went into this project thinking I would be happier working on the back-end than the front-end, and I believe that was the case. I think back-end problems require a different kind of thought than front-end problems, and I think I handle the former more effectively than the latter.
I didn’t expect to enjoy working with GraphQL or making security updates as much I did. In fact, I didn’t go into this project thinking I would even do either of those things, I just saw the need for improvements in those areas and took it on myself to fix them. I found satisfaction in seeing how my contributions brought the project closer to the finish line.
I don’t anticipate contributing much further to this project, but I would like to see a few more things implemented:
- HTML email templates and an appealing email confirmation page
- A more comprehensive and dynamic GraphQL schema with more appropriate custom data types
- The resolver I wrote has a lot of repetition. I attempted to refactor it without so much repetition, but I wasn’t successful. Perhaps someone else could find a more elegant solution.
- All of our security tasks completed
- A production-quality front-end complete with functional interface that makes GraphQL requests, whether that’s with my user-searching function or otherwise
Closing thoughts
You can find the source code for the version of Semblance we created for the Foundations capstone at github.com/tieje/yorha. Further development can be found under github.com/tieje/Semblance.
As I mentioned earlier, I’m interested in music and sound applications of technology. When I’m not programming I’m probably playing the piano or producing music. I find DSP and ML fascinating, and I’d love to work on a digital audio workstation such as Logic, Ableton, or my DAW of choice, FL Studio. I’m planning to take the Machine Learning specialization at Holberton School.
SoundCloud: soundcloud.com/justinmasayda
GitHub: github.com/keysmusician
