I believe that using systems like Git are an important tool for developers. Yet, one of the more challenging aspects of working with Git is resolving merge conflicts, an occurrence in collaborative projects. For this blog entry, I chose to review the Graphite guide on resolving merge conflicts. This resource provided a clearer, step-by-step approach to handling merge conflicts, and I found it both insightful and practical after learning it through homework and in class.

Guide of Merge Conflicts

The guide explains the basics of merge conflicts in Git, outlining what they are and why they occur. It details the types of conflicts, these arising from edits in the same line of code or overlapping changes across different branches. Resolving these conflicts using Git commands like git status and git diff to identify issues and git merge to bring changes together. The guide concludes taht with best practices to prevent merge conflicts, such as pulling the latest changes regularly, using feature branches, and maintaining clear communications within a team.

Why I Chose This Resource

I chose this resource cause it was a little confusing at first. After reading/researching multiple articles and websites like this one it refreshens your knowledge. Now I know that merge conflicts are a just not a concept we’ve discussed, but we learned about the importance of version control in collaborative coding environments. We learned how tools like Git enable teamwork by allowing simultaneous contributions, but we also explored how conflicts can arise when changes overlap. Despite this, this has to be one of the most stressful aspects of group projects.

Personal Reflections and Insights

Reading this guide helped de-reconstruct merge conflicts. I particularly liked the detailed explanations of the commands, as it’s easy to misuse or misinterpret them when under pressure or when you are clueless. While I’ve often focused on “fixing the conflict,” I’ve ignored on verifying how the changes interact, which has caused issues in past projects.

Another valuable takeaway I think was the important of adopting preventive measures. In class, we learned about best practices like pulling changes frequently and using feature branches, but this guide provided additional context that made these tips feel more somewhat actionable.

Future Practice

I want to apply this knowledge in upcoming group projects. Whether working on a shared repository for class or contributing to open-source projects, knowing how to resolve merge conflicts efficiently will save time and reduce confusion. This guide also inspired me to explore additional tools, like Visual Studio Code’s merge conflict interface, to streamline the process further. By combining these technical skills with teamwork, it will be better prepared to contribute effectively in collaborative environments understanding resolving merge conflicts.

https://graphite.dev/guides/how-to-resolve-merge-conflicts-in-git

From the blog CS@Worcester – function & form by Nathan Bui and used with permission of the author. All other rights reserved by the author.

For this week, I decided to find a blog about Software design principles to refresh my mind on the topic. I found a blog called “Main Software Design Principles Every Developer Should Know” by Amr Saafan. The reason why I decided to discuss this blog Specifically is because it breaks down each section in short simple bullet points.  

The first section is Object-Oriented Programming (OOP) principles. This section explains principles like Encapsulation which guarantees that objects securely manage their data and behavior while concealing their complexity and granting limited access. Next is abstraction- by concealing details and concentrating on key elements, abstraction makes problem-solving easier and allows for solutions that are extendable and reusable. Inheritance encourages code reuse by enabling classes to share properties and functions, whereas polymorphism enables flexible behavior depending on object types, increasing flexibility and minimizing code duplication. I remembered these principles the most, possibly because I’ve had plenty of discussions about it, however, I found the explanation of encapsulation very helpful.

Software design is further improved by the SOLID principles. In order to improve testability and maintenance, the Single Responsibility Principle (SRP) promotes modular classes with distinct responsibilities. In order to maintain stability, the Open/Closed Principle (OCP) advises adding functionality through new code as opposed to changing current code. The Interface Segregation Principle (ISP) promotes short, targeted interfaces, minimizing needless dependencies, whereas the Liskov Substitution Principle (LSP) preserves compatibility between base and derived classes. The Dependency Inversion Principle (DIP), which prioritizes abstractions over concrete implementations, encourages loose coupling. I needed a refresher of LSP and ISP the most out of this section and I found the explanations to be helpful. 

The next section (Don’t Repeat Yourself (DRY)), explains how it is useful to eliminate redundancy, which promotes simpler, maintainable, and error-resistant code through modularity and reuse. (Keep It Simple, Stupid  (KISS)) promotes straightforward, effective solutions that are simpler to comprehend and maintain, while discouraging overengineering. The You Aren’t Gonna Need It (YAGNI) principle suggests avoiding unneeded features in advance, simplifying things, and concentrating on urgent needs. Those principles felt self explanatory to me but they were explained well. The Law of Demeter (LoD) improves modularity and decreases coupling by restricting an object’s interactions to its immediate dependents. I definitely needed the explanation of this principle. I found it helpful to have the list of how to apply it which included items like Limit Direct Dependencies, Use Interfaces and Avoid Chain Calls. It aided in my understanding of the principle.

Next, the Composition Over Inheritance principle suggests building systems with reusable components rather than deep inheritance hierarchies, improving flexibility and modularity. Finally, the Principle of Least Astonishment (POLA) ensures software behaves as expected, minimizing confusion by being clear, consistent, and intuitive.

As a software developer, these design principles will help design scalable, flexible, and user-friendly systems. KISS and YAGNI simplify designs to avoid unnecessary complexity, while composition and encapsulation add flexibility. Following POLA makes the system easier to understand and use for both developers and users.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

Have you seen those memes about junior developers pushing the API key as a comment but never understood why it is such a big deal? Well, have no fear because if you have no idea what an API is, you’re at the right place.

So, What Even Is an API?

API stands for Application Programming Interface. It sounds super technical, but it’s not that bad. Basically, an API is like a menu at a restaurant. The menu tells you what dishes (functions) the kitchen (the system) can make for you. You don’t need to know how they’re cooking your pasta in the back; you just order, and it shows up at your table.

In the tech world, an API does the same thing. It lets one app talk to another without knowing all the inner details of how the other app works. Cool, right?

Why Do We Need APIs?

Imagine you’re building an app that needs weather data. You could go out, set up weather stations, and measure the weather yourself (good luck with that). OR you could just use a weather API that already collects and shares this data for you. APIs save you a ton of time by letting you use existing tools and data instead of building everything from scratch.

How Does It Work?

Here’s a quick breakdown:

1. You Make a Request: Your app sends a request to the API. Think of it like sending a text message that says, “Hey, can I get today’s weather for [city name]?”
2. The API Responds: The API sends back the info you need, usually in a format like JSON (basically a fancy way of organizing data).

That’s it. It’s like texting a really reliable friend who always gives you the answers you need.

Real-Life Examples of APIs

• Google Maps API: Used by apps to show maps and directions.
• Twitter API: Lets developers pull tweets or post updates automatically.
• Spotify API: Allows you to add music to your app or create custom playlists.

Even when you’re signing into a website with Google or Facebook, there’s an API making that happen behind the scenes.

Why Should You Care?

If you’re a CS student like me (or thinking about becoming one), learning to use APIs is a game-changer. It’s how you get your apps to do cool things without reinventing the wheel. Plus, if you ever want to work in software development, knowing how to interact with APIs is a must.

So, next time you hear someone drop “API” in a convo, you can confidently nod and say, “Oh yeah, I’ve used APIs before.” (Fake it ‘til you make it, kings.)

From the blog CS@Worcester – Anairdo's WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.

https://www.codingame.com/blog/agile-failed-peek-future-programming

This blog post by CodinGame provides a short history of development methodologies and goes on to make a critique of specifically Agile. It describes how, despite how widespread the methodology has now become, Agile has generally not succeeded as a methodology because of how it has been implemented by corporate management teams. While Agile as a methodology strives to be a set of principles that should guide a team to good practice and a healthy work environment, non-programmers use it as a tool to enforce hierarchical structures and rigid development. Most of what is said can likely also be applied to Scrum, but it is not explicitly mentioned.

This blog interested me because when I learned about Agile and Scrum, I always thought to myself, “Why would you ever not choose these methodologies? These seem far superior to outdated methods like Waterfall.” However, this post opened my eyes to how Agile really only works when implemented as was expected by those who wrote the manifesto. This post makes it very clear that what makes a methodology successful, or a team successful in general, is understanding its intent and being able to reflect on if its intent aligns with the work style of the team in question. Generally, I feel that if you’re a business leader who wants to have a rigid plan, then you should just follow a rigid plan like that of Waterfall, rather than creating a fake team experience with a smoke-and-mirrors version of Agile.

The post helped me reflect on what to look for in a well-functioning team. I think these insights can be very valuable for someone when they are looking for a place of work, as when you apply these critiques as a tool to analyze employers, it may be very apparent at some point in the process when a team is run by a group of developers and when a team is run by non-programmers enforcing a strict hierarchical system of development. I think this kind of resource would also be useful if ever in a position where one’s input is valued when evaluating how a team should handle itself, as it can be helpful in recognizing what are good tendencies in a team and what are bad tendencies, especially in a leadership position where hearing the whole team’s voice can be valuable. Being able to express why a decision may be bad is not only valuable for working in a team but also for working under management, as articulated thoughts may be enough to have an impact on their perspective as well.

This blog highlights the importance of understanding and respecting the intent behind methodologies like Agile; it serves as a notice of how we need to hold ourselves and team leaders accountable for how a team chooses to go about development.

From the blog CS@Worcester – CS ZStomski by Zachary Stomski and used with permission of the author. All other rights reserved by the author.

The blog “Microservices Architecture for Enterprises,” authored by Charith Tangirala, provides a detailed summary of a talk by Darren Smith, a General Manager at ThoughtWorks Sydney, on implementing microservices architecture in large enterprises. The blog explores key considerations for transitioning from monolithic systems to microservices, including cultural, technical, and operational changes. It highlights critical topics such as dependency management, governance, infrastructure automation, deployment coupling, and the evolving role of architects in fostering collaboration between technical and business teams. By sharing practical insights, the blog offers a framework to assess whether microservices are suitable for specific organizational goals and challenges.

I picked this blog because we are currently learning about microservices and APIs in class. I wanted to explore how the concepts we are studying are applied in real-world scenarios and understand their practical importance. This blog stood out because it connects the theoretical foundation of microservices with the challenges and solutions encountered in large enterprises. By studying this resource, I aimed to gain insights into why microservices are a valuable architectural choice and what factors should be considered when implementing them.

One key takeaway from the blog was the explanation of “deployment coupling.” It was interesting to learn how monolithic systems often require synchronized deployments, while microservices, through the use of REST APIs, allow for independent service releases. This flexibility is one of the main benefits of microservices. At the same time, the blog points out operational challenges, such as the complexity of monitoring and managing numerous services, which requires a strong DevOps infrastructure. It reminded me that while microservices can provide agility, they also demand careful planning and strong operational practices.

Another important point was the emphasis on organizational culture. The blog highlights how the success of microservices depends on cross-team cooperation, education, and alignment. This reinforces the idea that architecture isn’t just about technology—it’s about how people and teams work together. It made me realize that adopting microservices is as much about communication and collaboration as it is about code. I’ve also learned that companies like Netflix and Amazon have already implemented microservices architecture, leading to significant success with their products. This real-world application of microservices by industry leaders shows how impactful this approach can be when implemented effectively, further inspiring me to learn more and apply these principles in future projects

As I move forward, I want to keep learning more about microservices and APIs and use what I’ve learned in future projects. My goal is to apply these concepts to real-world problems and build systems that are flexible and efficient. I also hope to use this knowledge in my future career as a Software Developer, where I can create scalable and innovative solutions.

Sources:

Microservices Architecture for Enterprises

Citation:

Tangirala, Charith. “Microservices Architecture for Enterprises.” http://www.thoughtworks.com, 13 July 2015, http://www.thoughtworks.com/insights/blog/microservices-architecture-for-enterprises. Accessed 23 Nov. 2024.

From the blog CS@Worcester – CodedBear by donna abayon and used with permission of the author. All other rights reserved by the author.

After our recent studies relating to Docker managing dependencies and ensuring consistent development environments, I was interested in learning more about how to use it because I thought something like this could have saved me many hours of troubleshooting while completing a recent research project. This article, written by Medium user Dispanshu, highlights the capabilities of Docker and how to efficiently use the service in a cloud environment.  

The article focuses on optimizing Docker images to achieve high-performance, low-cost deployment. The problem some developers run into is having very large images which slow the build processes, waste storage, and reduce application speeds. I learned from this work that large images result from including unnecessary tools/dependencies/files, inefficient layer caching, and including other full images (like Python in this case). Dispanshu focuses on achieving the solution in 5 parts: 

1. Multi-stage builds 

2. Layer optimizations 

3. Minimal base images (including Scratch) 

4. Advanced techniques like distroless images 

5. Security best practices 

Using these techniques, the image receives a size reduction from 1.2GB to 8MB! The most impactful change being multi-stage builds to which the writer accredits over 90% of this size reduction. I have never used these techniques before, but my interest definitely peaked when I saw the massive size reduction that resulted from these changes.  

The multi-stage builds technique references the build stage and the production stage. By using this technique build-time dependencies are separated from the actual runtime environment which avoids the inclusion of any unnecessary files or tools in the resulting image. Another technique recommends minimal base images using the slim or alpine version (for Python) over the full version for the build stage and for production stage it is recommended to use the scratch base image (no OS, no dependencies, no data or apps). Using a scratch image has pros and cons, but when we are considering image sizes and optimization this is an ideal route. 

Another interesting piece of this article is the information relating to advanced techniques like distroless images, using Docker Buildkit, using .dockerignore file, and eliminating any excess files. The way that distroless images are explained by the writer makes the concept and the use case very clear. The high-level differences between the Full Distribution Image, the Scratch Image, and the Distroless Image are described as the different ways we can pack for a trip:  

1. Pack your entire wardrobe (Full Distribution Image) 

2. Pack nothing and buy everything at your destination (Scratch Image) 

3. Pack only what you’ll actually need (Distroless Image) 

The analogy makes understanding the relationship between these three image options seemingly obvious, but I can imagine applying any of these techniques described would require some perseverance. This article describes an architecture that juggles simplicity, performance, cost, and security with very impactful results. The results of this article are proof of the value these techniques can provide, and I will be seeking to apply them in my future work.

From the blog CS@Worcester by cameronbaron and used with permission of the author. All other rights reserved by the author.