MLH Fellowship Insider: Weeks 4 and 5
--
This summer, I’m doing the Major League Hacking (MLH) Site Reliability Engineering Fellowship which is run in partnership with Meta. The MLH Fellowship is a 12 week technical program where fellows complete an educational curriculum, build open source software, and receive mentorship from professional engineers to learn more about the world of site reliability engineering. I wanted to journal my experience as I go through the program and share it to provide more insights for anyone interested in applying!
Weeks 4 and 5
Weeks 4 and 5 were fun! Week 4 focused on services and databases, and week 5 focused on testing.
One of my main takeaways from week 4 was building some intuition around NoSQL databases. This was a point of growth for me because I experienced working with relational databases in school and internships, but I had not ever encountered NoSQL databases. NoSQL databases are less structured and do not enforce a schema or use relational tables to store data. It was challenging for me to imagine a case where this would be a better option than the data consistency and integrity provided by structured databases.
Through readings and discussions, I understand better now that NoSQL has a real advantage for projects where you are continuously adding new features, growth is unpredictable, and there is a time constraint/you need to get something up and running quickly (e.g., the case for hackathon and prototyping projects). The advantage is that it is much more efficient to setup and update a NoSQL database. This is due to relational database schemas being defined rigidly which require more time to properly test changes. The changes will also impact all layers of a software technology stack.
My mentor (a product engineer at Meta) told me that at Meta, updating the database is not a quick process. All entities must be updated to reduce risks of breaking something otherwise no update is done. This was interesting because it meant that everything needed to be updated even if, for example, you were to modify only one entity by adding one new field. I had not thought about this before but it made sense that a database update to only some entities could introduce errors.
For week 4’s coding activities, I got to apply what I learned by adding a MySQL database to my portfolio website. This was my first time setting up MySQL. We built a timeline page for our sites and defined get/post endpoints for retrieving/adding information from our database. We also used the linux process manager systemd to write a service for running our portfolio site on the VPS.
This past week (week 5), we partnered up and wrote tests for each other’s websites. We used the unittest python library to define tests for the website homepage, get/post api endpoints, and malformed data that is being inserted into the database. We also added more input handling (e.g., checks for if a required field was defined) in each other’s code. I enjoyed the challenge of writing tests for software I did not implement. Going forward, we will be using test driven development to ensure our code is more optimized and has better test coverage.
I have been really liking the structure of the fellowship. Each week, we cover a new topic and then build it into our personal websites. This has allowed me to better understand each component and appreciate the various layers in websites. Next week is the halfway mark! (I cannot believe we are already at week 6!) The topic is containers and I am excited to see what that is all about!
