Week 6 — Last Individual Review

Data Migration & Seeding

In Println, data seeding and migration is done by one of our hackers, Muhammad. I did not do any of those because there is only one data type we need to seed, “User Profiles”. Therefore, I am going to explain my theoretical knowledge and understanding of what my coworker did. I will also write about my experience in Schema Migration.

Data Migration vs Schema Migration

Schema migration, or database migration, is a change management to relational database schema. I took part in this type of migration.

To do it, we need to create the schema migration script first, which is done by:

python manage.py makemigrations

To migrate, we run:

python manage.py migrate

which will apply the migrations to the database, in our case, our PostgreSQL database.

In Django, schema migration scripts are irreversible. That means, you cannot unapply any migrations done beforehand. I once made a mistake weeks ago, deleting old migration scripts, and building a new one. This created chaos throughout back-end and Heroku server. However, thank God for Muhammad, and I finally learned what Django migration scripts are.

Data migration, on the other hand, is a change management in the real data inside the database. This is usually done when we are changing into another DBMS. We did not apply data migration, however, we initialized data in our servers by seeding.

Think Big & Daily Improvement: What’s Next for Println?

Our Goals

From the first time I met our product owner, we always made ourselves clear that the goal of building Println is not just to complete PPL course, not just building another printing platform, but to solve problems regarding unreliability and difficulties of printing that we face today. We aim to create a responsive, fast, and reliable automatic printing platform that is scalable, which can be used and implemented easily to small and medium printing enterprises.

Product-Oriented, not Task-Oriented

I am very blessed to walk this Println journey with five talented, goal-oriented, and encouraging teammates. In every scrum meeting and sprint planning, we actively discuss the design of our product as a whole, to make sure that each of our codes aligns with our product goals, and integrates well to the system.

I know some other PPL students who struggle to integrate their code with their teammates, because they did not discuss it through. Their design and concepts did not align, and they only focus on their tasks without carefully thinking about how their code integrates to the system. I am lucky that this is not us, and I believe this is what differentiate us from other teams.

Other than finishing our tasks independently, we also make time to meet (usually on Saturdays) and do back-end front-end integrations. With the help of API Documentations that I made (published on Postman), we fix bugs, adjust endpoints that are too difficult for client to consume, and testing our application as a whole.

How I Improved throughout my Println Journey

I would say I improved both in technical skills as well as social skills in this journey.

Technically, I improved a lot. I learned about Django Rest Framework best practices. I learned about tools such as mocking, SendGrid, Google Social API, and others I never touched before. I, the dev-ops illiterate, also learned so much about Heroku and CI/CD. Being one of the responsible person in Heroku, I learned about PaaS and how it works.

Socially, I learned to work in teams. As a person normally working independently, I learned so much on respecting organizational needs above my own. I learn to position myself as a backend engineer, adjusting to front-end engineers. I learn to contribute my thoughts and ideas in team, and I make new, fun friends to work with.

What’s Next for Println?

After PPL, I am sure our responsibilities as engineer in Println technically ended. This does not mean we will turn a blind eye toward any faults in the system, but this only means our contract work is done. Therefore, it is our responsibility to leave the source code and the system in a good condition. It needs to be reusable, scalable, and readable to those new engineers building Println after this. That is why we learned so much from PPL about refactoring, testing, architecture, etc., to make sure our application is maintainable.

After PPL, Println will be MIC’s leading product in automatic printing. We hope with all the extra features we built, Println can be the best printing options for anyone needing printing services, not limited to Fasilkom students, but also throughout UI, and hopefully even beyond.

Println is planned to be sold as a service to printing enterprises to ease their access to customers.

My Tasks

There are two big PBIs I have been doing in this sprint: Dynamic pricing and forgot password.

Here are some of my code snippets.

Sending Email with SendGrid API

For automatic email provider, we use SendGrid API v3. It is cheap, has a free sandbox with up to 100 emails/day, and easy to configure. We only need to send the content and mail data to the SendGrid API, and it will be automatically queued to send by SendGrid.

For dynamic pricing, there are too much code to display. I made four endpoints for front-end to consume, which are:

• Create (POST)
• List (GET)
• Update (PUT)
• Delete (DELETE)