CST438 Week 8

This course was a ton of work, but also very fulfilling and rewarding in terms knowledge and skills gained. If I had to decide on my five favorite new things I learned, they would be as follows.

1. Git 

I believe that Git is criminally underrated in terms of skills that software engineers should master. Most people only know the very basics, such as git push, pull, commit, add, and fetch, without understanding the more complex stuff. When I first came into the course, I was in that boat, and it was a blast running into many errors with Git and learning the necessary skills to debug them. The crazy part is that Git goes so deep that I only went a bit deeper during the course. I will continue to learn more about Git.

2. Agile Method

From what I have heard, Agile is popular and very commonly seen in startups, which means that if I were to be hired at such a company, having the basics down already will put me in a great spot. I also think its fun to create epics and stories and complete stories during sprints. I am naturally extroverted so I might also be biased in favor of scrum meetings and teams with tighter communication.

3. React Basics

I am choosing this item because of how popular React is in today's tech industry. If I am not mistaken, it is the most popular frontend library which means that we are almost certainly likely to see it again as industry engineers. Being able to customize our project's React frontend was a thrill and I like the dark theme that I installed on it. I know that the skills I improved on in this course will almost certainly carry over well to that.

4. Service Oriented Architecture

Splitting our backend repo in two and having each part handle a different service was really cool. I especially like that this is something real, large companies do all the time, although apparently to far greater degrees (understandably). I'm not going to lie, it was confusing at first to wrap my head around the concept, but programming it directly really helped me to grasp the idea and now I am quite comfortable with the philosophy of and reasons for microservices. 

5. AWS Deployment

Admittedly, I thought that this was going to be complicated and possibly even dangerous considering the potential of being overcharged by AWS for unaccounted compute on our deployed project. However, as I worked through the assignment, re-read the document and re-watched Prof. Wisneski's video walk through, the process became clear and understandable. Furthermore, my application thankfully deployed successfully after debugging the manifest file error, which only took a few minutes extra. Last but not least, cleaning up was easier than I thought, and should prevent us from getting overcharged, which I'd wager is a great skill on its own. I am now open to learning more about AWS, especially since it's widely used in the industry these days and no doubt a great tool for contemporary software engineers.

CST 438 Week 7

Agile and Plan-and-Document, also known as Waterfall, are two software development processes with differing philosophy and organizational structure. Waterfall is a linear, sequential process where each stage—gathering requirements, designing, implementing, testing, deploying, and maintaining—is completed before the next is started. The process relies on detailed documentation and forward planning and so is ideal for the projects whose requirements and scope are clear and not expected to change. For example, defense or aerospace industries or manufacturing that need predictability, safety, and compliance are likely to employ the Waterfall model. Agile is the reverse because it is flexible and iterative. It breaks work down into tiny, manageable chunks named sprints, which take anywhere from two to four weeks. Agile requires ongoing feedback from the users and stakeholders in order to allow the product to be altered while it is still being developed. It emphasizes working software and collaboration over documentation and rigid processes. Agile is common where there is an acceleration in change such as in the case of the technology startups, digital product companies, and user experience or quick innovation-focused organizations. These companies are often forced to move at high speed because of market changes, and Agile provides the structure to do this without being bogged down by too much process. In general, Waterfall functions best in situations where requirements cannot change, times are limited, and there can be no acceptance of ambiguity. Agile, on the other hand, performs better in high-change environments where requirements from the customers and market demands will vary.

The choice between the two generally depends upon the project type, corporate culture, and how much adaptability the team is going to need to deal with change. A few contemporary organizations even employ hybrid strategies, using the planned design components of Waterfall and marrying them with the flexibility of Agile in order to fit more effectively with their own needs.

CST 438 Week 6

This week, we discovered a great deal about a new method of structuring services in software architecture. Before week 6, the project that we had been working on had a monolithic architecture—i.e., the backend was one app where all the services (such as the registrar, gradebook, and any future features) were bundled together and run inside the same server.

On the other hand, this week we studied microservices architecture, where each service is developed and deployed independently, typically on its own server or container. Each microservice typically has its own database, but some services will have additional tables specific to the function of their purpose. There are several reasons why one would want to use a microservices approach, including increased scalability—because each service can be scaled independently as necessary—and fault isolation, in that if one microservice fails, it does not necessarily bring down the whole system.

Another basic concept of microservices architecture is inter-service communication. Since each microservice is a separate application and often on different servers or containers, it is not possible to use direct function calls or shared memory (as in monolithic applications). Microservices communicate over a network instead, using protocols like HTTP or gRPC. This is called inter-service communication. Services normally expose APIs—typically RESTful endpoints—other services invoke to pass or receive data. In more complex systems, communication is asynchronous and through message brokers like RabbitMQ or Apache Kafka, where services subscribe and publish events. Asynchronous messaging further decouples and allows services to continue working even when a part of the system is behind or temporarily unavailable. The decision between synchronous and asynchronous styles is use-case dependent, trading performance, reliability, and complexity. Funny enough, we got to work with RabbitMQ in our own assignment, and it was an absolute blast to directly program an implementation of service oriented architecture using our pre-existing monolithic project.

Another advantage of microservices is that they are technology-agnostic. Because each service is decoupled, developers can choose the most suitable programming language, framework, or database for the problem that service is trying to solve. This can lead to better productivity and performance, as teams are not forced into a single tech stack. For example, one can construct a Python-based machine learning microservice using TensorFlow in one instance, and a high-performance user authentication service in Go. Provided that services adhere to pre-defined communication protocols—e.g., REST or gRPC—they can coexist beautifully in the overall system. This autonomy also enables parallel development across teams along with simpler integration of future technologies down the line.

A real world example of microservice oriented software is Netflix, which was originally a monolithic app, just like our own project. Netflix runs hundreds of microservices today that do everything from video encoding, user recommendations, and billing. Each microservice is deployed separately, communicates with APIs, and can be scaled based on usage patterns. This allows Netflix to achieve high availability, deploy highly frequently without downtime, and continue innovating at high velocity. Their use of asynchronous messaging and advanced DevOps tools also solves the complexity involved in such a large microservices ecosystem.

CST 438 Week 5

This week, we learned some fundamental concepts in the plan and document method for software engineering, also known as the waterfall method. As opposed to agile development, where teams have rough, generalized objectives (typically represented as stories) which are iterated upon at cyclical intervals, the waterfall method involves a very thorough planning phase where software requirements are extensively documented and followed through the entire development process, with perhaps only small adjustments here and there. We learned about the software requirements specification (SRS) document, which is a sort of blueprint for the software being developed, and how to write key sections in a typical SRS. It was fun learning all about UML case diagrams, use case documentation, and how to properly document database requirements. It's cool to know that the SRS, because of its indifference on exact implementation details, can serve as a type of generalized recipe for the software you are developing. For example, in our project, we do not (and should not) mention exactly what type of entry form we use for finding a student's schedule by year and semester, rather we simply mention that the student can select year and semester, and the frontend liberties are fully granted to the developer(s). I hope we can continue to train with the waterfall method and the agile method, and perhaps other methods in the future.

CST 438 Week 4

Admittedly, I was initially reluctant to learn about code reviews, because I thought they were too time-consuming. However, after having read about them in our textbook and especially collaborating with others in our course to accomplish software development tasks, I have grown very fond of them and would consider them to be my favorite thing learned so far, although I have much training to do myself before I become adept with them. The best part is that code reviews are a sort of safety mechanism to help ensure that your code works properly. Nobody is perfect, and we can certainly use a second set of eyes on occasion to keep our work in check. 

Another great benefit of code reviews is that they can help you maintain best practices and with maintaining good code readability. A seasoned developer once told me that your code should be as simple and as readable as possible, rather than being overly fancy or gimmicky. I certainly see the value in his advice now that we are working in a small team. I can only imagine how crazy it must be to work with very large teams, and how important code reviews are in those settings. Another benefit of code reviews they provide avenues for one to learn from more experienced developers. For instance, I was fairly rusty with Java after not using it for a while, but early on, my teammates were able to create some good examples of our code which helped me caught up to speed. 

Code reviews are so important that apparently they are a quintessential part of Google's culture, which is a key reason as to why their code is stable and maintainable in the long term. I hope we can continue practicing this process even after our course concludes.