Zach's Blog

 The five most important things I learned in this course were system testing with Selenium, how to create a React front end, how to write a Software Requirements Specification (SRS), how message queues work, as well has how to deploy locally hosted applications to AWS. Though I've written unit tests for REST APIs, I've never had the opportunity to learn Selenium do automate system testing with a frontend application. Following my successful implementation of tests with Selenium I'm looking for ways to implement it in my professional applications. I've also not had the chance to develop a frontend website using React despite it's popularity and wanting to learn it, so this class was a great way to get started. Professionally I've had experience with contributing to an SRS and have heard about message queues, however getting more details in this class about how an SRS should be written as well as how message queues really work in a web application was very helpful...

 Two important project design methodologies are the Waterfall process and the increasingly popular Agile process. While both processes have been tested and are proven to be effective, there are key differences between the processes that may be a deciding factor over which methodology to use for a project. Some of these differences include how a project design is approached, the flexibility afforded by the methodologies, and how the project is planned. When approaching a project, Agile and Waterfall processes greatly differ with Agile processes breaking their tasks up into sprints and utilizing stories to track tasking. Agile also emphasizes iteration, feedback and adaptiveness. In comparison, projects using the Waterfall process emphasize rigidity and sequential tasking where tasks are clearly defined and must be executed one after another. These two approaches affect the flexibility afforded, where Agile allows easy adaptability to changing requirements, where Waterfall projects a...

      This week I learned more about Service Oriented Architecture (SOA) and how it can improve efficiency amongst large teams. In the initial design of our web servers, our system was monolithic. We had web servers for our front end and backend, and had a single database that was controlled by the backend. However this week we switched to SOA, allowing us to split up the two web servers, effectively making them microservices, and ran a independent databases on each. By doing this it was much more efficient for our team to work when split up, only requiring all hands when doing system testing. One important part of making our microservices communicate effectively was the use of message queues, specifically RabbitMQ. With message queues, each of the microservices could communicate with each other and keep track of changes in each database as well as track requests needing to be handled. One interesting thing I learned about RabbitMQ was the different methods in w...

      This week I delved into creating a Software Requirements Specification (SRS) document where I needed to learn how to write requirements as well as create a use case diagram to explain how users and secondary actors interact with our system. I learned how to use Luicdchart to create a diagram and watched tutorial videos from Lucidchart about how to create a proper use case diagram to best describe to a reader the functionality our system provides. One thing in particular that was interesting to learn about was that when designing a use case diagram, primary actors such as users logging into a website should be placed on the left, while secondary actors, such as a database that reacts to changes initiated by primary actors, should be placed on the right. After following this procedure and viewing my resulting diagram, it made sense to me why you would want to lay out the diagram in such a manner due to how seamless it was to read and understand what was going on at a ...

    The most interesting thing I have learned about in my reading of "Software Engineering at Google" are how each of the various processes are executed. While I am familiar with most of the processes I've read about so far, including code reviews, unit testing and system testing, the manners in which these are executed at Google are different from how they have been executed in my professional experience. For code reviews in particular, Google engineers ensure they invite various other software engineers to fill the roles of correctness and comprehension checking, language readability checking, and code owner. However, in my experiences this is not explicitly required. While a single engineer on the team often fills a couple of these roles, there wasn't an engineer specifically dedicated to carry out each of these tasks. Another interesting thing I learned was a recommendation about the use of the "sleep()" function in testing. While sometimes waiting is re...