Brandon's Weekly Learning Journal

 Week 7, This week was rather interesting because of two parts. For one, we were tasked with pushing our work on the past few assignments into the Amazon Web Services (AWS). This allowed us to run our website's backend and front end in amazon's servers where they have many beneficial services to use in running it. It took a while for me to get running because somewhere along the lines I think I had a typo and I didn't catch it until the end.  The second part of this weeks module was making our own Software Requirements Specification (SRS). Whereas previous weeks, we've been following the Agile process to complete a project, this week gives us experience in the Plan & Document (PD) process. The SRS is part of PD process and it takes a good amount of time, especially if you are working on a large project. After reading up on it and already having an understanding of the Agile process, there are some key differences.  The main difference is that in PD, the project star...

 Week 6, This week's material was split into continuing our work on our assignment and continuing our reading in the textbook Software Engineering at Google. The assignment involved us creating system tests using the chrome driver to automate the inputs for testing on the frontend, which in turn communicates to the backends. This essentially allows us to make sure the whole system works as intended. The reading was interesting because it involves something known as Compute as a Service (CaaS). This becomes necessary to consider as an organization grows and requires more resources to run its services. However, what is considerably important is how the resources are handled, especially in the case where a batch or service job fails. There are different ways to treat these resources (i.e. pets vs cattle), but also the need to consider how much "slack" is appropriate to handle multiple failures and re-organization of resources to batch/service jobs. Having engineers manually ...

 Week 5, This week had fewer material to cover than previous weeks, however the textbook readings had quite a bit to say. The main topic being larger tests in a development environment and how they can tend to produce valuable information but also have big disadvantages to be worked around. For instance, running a large test can produce results more comparable to the product when released, however it costs more to run, and takes a much longer time compared to unit tests. Not only is it just more costly, but due to the nature of large tests, there can be a lack of standardization and ownership considering it would be made by multiple teams who may program differently. However, companies can use different types of large tests depending on what they are testing for. Maybe all in one system, the cloud or maybe spanning multiple systems. 

 Week 4, This week's module has us getting started on practicing the use of the organization feature of GitHub for our assignment. While last week introduced us to the use of it, this week we make use of pull requests as code review. The assignment is built using service-oriented architecture as opposed to a monolithic architecture, so we have two separate services, each with their own databases. It allows for more flexibility when making changes to the code, and if one fails, the entire system doesn't go down. Additionally, we read more in depth about code reviews. Google has a specific way they conduct code reviews, with a few key details being roles (language readability approver, peer engineer, and code base owner) and the encouragement of keeping the code reviews short. Which to me is the most interesting, because naturally you would think having as robust of a review as possible would be more beneficial, however there are diminishing returns when considering the peer'...

 Week 3, This week's module is more centered around the importance of incorporating testing with our code. In our case, we automated the input of the lab we worked on last week using a google chrome driver. This helps speed up the process of checking our code returns the correct result by having the inputs be done automatically, rather than typing out the inputs manually. With proper testing, we can be more confident in our changes, and more inclined to embrace change in programs, especially when it is necessary. Additionally, we are re-introduced to using the version control system known as git. It was nice to get a clear refresher on git, and it was interesting seeing the different ways people can manage their different versions of code. Personally, I see the strong points being the use of commits and branches. Being able to fall back on previous commits in a scenario where the head commit is not worth the investment and using branches to work on different versions of releases. S...

 Week 2, This week's module covers material based on REACT which serves as the front end of the web development framework. While in last week's assignment, we implemented a simple database that can be used updated or changed via typical html requests. However, we would only be able to do this by typing in the URL and parameters, while passing in a body containing JSON. This week allows us to create web pages where a user can interact with input fields, see error messages and make changes to the database, while making the webpage run more efficiently using a virtual DOM (Document Object Model).  I consider the strength of REACT is the improved efficiency from a normal framework. From what I understand, a DOM is a structure that represents the HTML elements of a webpage, and when changing the DOM, it updates all of the browser rendered elements. However, with the use of the virtual DOM, which is a lightweight version of the real DOM, we can change that first and only have to re-...