Week 11 AND Getting a better understanding of Docker and Module 2 concepts

Our following project, Module 2, can be viewed on our git repository for the project. For this project, we had to do the following for our workflow and how we approached this significant project that had us busy the entire week with my partner. We put about 40 hours into this project of work, researching and debugging by the end of the project. 

I first approached my microservice by building out the models. As I progressed with my design, I would reference and draw out my plan using Excalidraw. This helped me better understand how my microservice would connect to our inventory and service microservices.

To begin with my design, I must identify how my Sales Microservice is connected with the Services and Inventory. This is done through the Automobile Value Object. Since every Automobile in our database has a 17-digit VIN specifically unique to each car, my partner and I used the Automobile Value Object. After identifying the Automobile as a Value Object, I constructed my sales models. I used four models: AutomobileVO, SalesPerson, Customer, and RecordOfSale.



For the AutomobileVO, I used two fields of VIN specific to each car in our database and sold. This is because if the car is sold. Users will know whether the vehicle has already been listed as sold and prevent a double selling situation. For the SalesPerson, I used the fields first name, last name, and the Employee's ID. For the customer, I used the fields first/last name, address, and phone number to collect our customer's contact info. Lastly, for the record of sales, I included the price field and, in addition, three foreign keys in the form of Automobile, salesperson, and Customer. The first foreign key, "automobile," was used to connect this model to my AutomobileVO model. This allows for easy access to the automobile data associated with the record of a sale. The second foreign key, "sales_person," was used to connect the model to the SalesPerson model, allowing easy access to the data related to the salesperson associated with the sale record. The third foreign key, "customer," connects the model to the Customer model, allowing easy access to the sales record data.

After considering what would happen if a customer or salesperson were deleted from our database, I set the on_delete parameter to PROTECT to save the sales record. I did this because I imagine that in a real word business situation, having complete sales records is an important metric to measure any data analysis for the business. 

I moved on to my admin and encoders from these models to input my data into their respective Django Admin databases. From here, I created view functions to perform the following abilities of "POST," "GET," "PUT," and "DELETE" for my AutomobileVO, SalesPerson, Customer, and RecordOfSale. This allowed for my form functions to be able to Create a salesperson, customer, and a record of a sale. In addition, the ability to list a sales history, the sales team members, and customers. 

After this, we worked on the front end with React and built our Javasctipt files in our ghi folder to develop our components, states, and props. We constructed components to display or create the data in our forms. My partner and I will work on improving our project with our customization the following week. 

One of the big learning lessons for this week came from how we worked together on this project by ensuring we were developing on separate branches. Then we would have to switch to the primary component that held our working code and would then pull and merge into our working branches(sales or service) to have updated copies of the progress we were making. At first, this week, we had minor hiccups. However, overall we became more knowledgeable about working on two separate branches and committing, pushing, and pulling onto our Gitlab repository. 

To begin developing my microservice, I started by building out the models. As I progressed with my design, I drew out my plan using Excalidraw to understand better how my microservice would connect to our inventory and service microservices.

To start my design, I needed to identify how my Sales Microservice was connected to the Services and Inventory. This was done through the Automobile Value Object, which is specific to each car in our database and sold. By identifying the Automobile as a Value Object, I constructed my sales models using four models: AutomobileVO, SalesPerson, Customer, and RecordOfSale.

For the AutomobileVO, I used two fields of VIN specific to each car in our database and sold. This is because if the car is sold, users will know whether the vehicle has already been listed as sold to prevent double-selling. For the SalesPerson, I used the fields first name, last name, and the Employee's ID. For the customer, I used the fields first/last name, address, and phone number to collect our customer's contact info. Lastly, for the Record of Sales, I included the price field and three foreign keys in the form of Automobile, SalesPerson, and Customer. The first foreign key, "automobile," was used to connect this model to my AutomobileVO model, allowing easy access to the automobile data associated with the sale record. The second foreign key, "sales_person," was used to connect the model to the SalesPerson model, allowing easy access to the data related to the salesperson associated with the sale record. The third foreign key, "customer," connects the model to the Customer model, allowing easy access to the sales record data.To ensure complete sales records, I set the "on_delete" parameter to "PROTECT" to save the sales record if a customer or salesperson was deleted from our database.

I moved on to my admin and encoders from these models to input my data into their respective Django Admin databases. From here, I created view functions to perform the abilities of "POST," "GET," "PUT," and "DELETE" for my AutomobileVO, SalesPerson, Customer, and RecordOfSale. This allowed for creating a salesperson, customer, and a record of a sale and listing a sales history, sales team members, and customers.

After this, we worked on the front end with React and built our Javascript files in our "ghi" folder to develop our components, states, and props. We constructed components to display or create the data in our forms. My partner and I will work on improving our project with our customization during week 12 of the course.

One of the big learning lessons for this week came from how we worked together on this project by ensuring we were developing on separate branches. We would switch to the primary component that held our working code and then pull and merge it into our working branches (sales or service) to have updated copies of our progress. At first, this week, we had minor hiccups. However, overall we became more knowledgeable about working on two separate branches and committing, pushing, and pulling onto our Gitlab repository.

Going into week 12, we have our final Module 2 test on Monday and then several days to work on our partner project to complete stretch goals and make creative adjustments. This will be the last week in Module 2 before moving on to Model 3 for Week 13. 

This week in Santa Rosa de Cabal was quiet with a work routine all this week of HackReactor work on the computer from 8 am till 6:30-7 pm most nights and then assuring with either dinner or going out for dinner. Other addition, my girlfriend, her mom, and I made a trip to Pereira this weekend (the neighboring city that is about a 25 min drive away to go shopping for professional clothes for her for our New York City trip). Onto week 12 and continuing with the extensive learning and mindfulness habits. I marveled at the continued developments in AI generative technologies and the future impact that they will have on society and businesses. A website I have discovered from my continual research on AI is www.dataconomy.com, which has helped to increase my vocabulary and understanding of topics in AI. See you next week!