https://www.atlassian.com/microservices/microservices-architecture/microservices-vs-monolith

Since learning about different software architecture styles like the monolithic architecture, the client-server architecture and the microservices architecture, I’ve been curious how large-scale applications transition from one architecture to another as the project grows in scale. I found this blog post on the Atlassian website breaking down the differences between the monolithic architecture and the microservices architecture, as well as telling the story of Netflix’s innovative migration from a monolithic architecture to a microservices architecture.

The article begins with the example of Netflix’s transition between architectures. Netflix was growing rapidly by 2009 and needed to expand its software infrastructure to meet the massive demand. Before “microservices” as a term was in wide usage, Netflix was one of the first major companies to migrate to a microservices architecture, and in 2015 earned a JAX Special Jury award for its successful deployment. Netflix’s new architecture would model itself on DevOps, defined by Amazon as “the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity (https://aws.amazon.com/devops/what-is-devops/#:~:text=DevOps%20is%20the%20combination%20of,development%20and%20infrastructure%20management%20processes.)”.

Following the story of Netflix’s change in infrastructure model, the article continues with an explanation of the monolithic architecture style. The monolithic architecture is a traditional design, which is defined by the application being housed in a single self-contained server. This architecture is simple to understand and easy to use as a foundation for your application. The major drawback of the monolith, however, is the difficulty in updating the application. Making changes to the code base requires bringing the entire service offline. Monolith architectures are not scalable with the growth of the application either.

The microservices architecture addresses some of the disadvantages that come along with a monolith architecture. The application is divided into independent services each with their own databases and methods. With this architecture model, only the components of the application that require changes need to be taken down, leaving the other components of the application free to continue working.

One inherent barrier to using the microservices architecture is the expense of multiple machines to host the different microservices, as well as storage space for their accompanying databases. It may only be beneficial for an application to transition to a microservices model once it has reached a certain scale. Small to mid-size applications may be perfectly well served by monolith architectures for much less cost than hosting the application across a microservices architecture.

From the blog CS@Worcester – Michael's Programming Blog by mikesprogrammingblog and used with permission of the author. All other rights reserved by the author.

A software development methodology is the methods and the different sets of workflow techniques that are used in order to design different I.T. software solutions. As I’ve been learning, there are many different types of these methodologies. According to Synopsys, the four most popular methodologies are Agile development methodology, DevOps deployment methodology, Waterfall development method, and Rapid application development. In my class, I’ve been learning about the Agile development methodology and the Waterfall development method. I think it is really interesting how there are so many different methods in developing software that all lead to the same outcome, and I’m interested in learning more about other methods. I think it will be very helpful to learn these different methodologies as some are more effective in certain situations. Synopsys has really helped me because it shows two of the methods I already know and allows me to get a better understanding of them, but also allows me to learn a couple new methods.

The first methodology that I learned about, the Agile development method, involves repeating all of the steps in short increments. The main reason that this method is used is to help minimize risk when adding new functions to the software. These risks can include bugs, changing requirements, and cost overruns. Like all of the methods, the Agile development method has both pros and cons. Some pros include allowing the software to be released in different iterations, not just one. This helps the developers fix bugs and change things early on in development. Another pro is that it allows users to learn the benefit of the software earlier, rather than waiting for the entire software to be incremented. However, there are also some cons to this methodology. One major con is that new users are often behind and not able to get up to speed, as they don’t have the documentation needed. This is because it relies on real-time communication. Another major con is that Agile development methods may not be as helpful in large organizations as they are used to other methods, such as the waterfall method.

The second method that I learned about is known as the Waterfall method. Unlike the Agile method, the Waterfall method performs each step in order and doesn’t move on to the next step until the previous step is completed. On top of that, each step is only performed once. The Waterfall method consists of different steps, otherwise known as sequential phases, which each have their own goals. These phases are Requirements, Design, Implementation, Verification, Deployment, and Maintenance. This method is also known to many as the traditional method, as many different companies use it. A major pro to using this method is it being easy to understand and manage, as there is only one step with one goal going on at a specific time. This allows less experienced teams and managers to understand and benefit from this method. A major con to this method is that is can be very slow and also very costly. This is because of the way that it is structured, as well as its tight controls. I haven’t learned about the other two methods on Synopsis, the DevOps deployment methodology and the Rapid application development, but I think this website is a great source to learn more about them, and I’m excited to do some more research on these topics.

Synopsis: https://www.synopsys.com/blogs/software-security/top-4-software-development-methodologies.html

From the blog CS@Worcester – One pixel at a time by gizmo10203 and used with permission of the author. All other rights reserved by the author.

Addressing Merge Conflicts on GitHub

In the fast-paced world of software development, collaboration is the lifeblood that fuels innovation. One of the most powerful platforms for collaborative coding is GitHub, a platform that has revolutionized the way developers work together on projects. However, this collaborative utopia is not without its challenges, and one of the most notorious hurdles developers face is the dreaded “merge conflict.” To shed light on this issue, I recently explored the blog post titled “How to Resolve Merge Conflicts in GitHub” on HubSpot’s website. In this blog post, I will share my insights and lessons learned from this valuable resource.

Understanding Merge Conflicts

The HubSpot blog post begins by elucidating the fundamental concept of merge conflicts. A merge conflict transpires when two or more contributors to a Git repository make concurrent modifications to the same file or lines of code. When an attempt is made to merge these conflicting changes, Git finds itself in a quandary, unable to discern which version to prioritize. The result? A conflict that requires manual resolution.

Resolving Merge Conflicts

The most invaluable takeaway from the blog post is the comprehensive guide on resolving merge conflicts. Here’s a summary of what I’ve learned:

1. Identify the Conflict: GitHub will promptly notify you if your PR encounters a conflict. These conflicts usually arise in files that have undergone concurrent modifications on different branches.
2. Locate the Conflict: Git marks the conflicting sections within your code with distinctive markers, including <<<<<<< HEAD, =======, and >>>>>>> branch-name.
3. Manually Resolve the Conflict: The HubSpot blog offers a detailed walkthrough on how to address these conflicts manually. It involves carefully reviewing the conflicting code, deciding which changes to keep, and removing the markers.
4. Commit the Changes: After successfully resolving the conflict, you need to stage the modified file using git add and commit the changes using git commit -m "Resolved merge conflict in file-name".
5. Update the Pull Request: By pushing the resolved changes to your branch with git push, the blog explains how to update your PR automatically with the resolved conflict.
6. Merge the Pull Request: Finally, once the conflict is resolved, and your PR meets all criteria, it can safely merge into the main branch, ensuring the seamless progression of the project.

   Through this journey, I’ve not only learned how to merge an issue on GitHub but also gained insights into resolving conflicts using Git. So, the next time I encounter a merge conflict, I won’t panic—I’ll simply follow these steps, and I’ll be well on my way to becoming a Git pro. Happy coding!

   My blog was based on the new things that I read on this blog link https://blog.hubspot.com/website/merge-conflicts-github

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

I recently came across a fascinating article that I believe directly relates to our course material as it is the focus of our current Design Patterns Homework. In this blog post, I will provide a summary, share my reasons for selecting this resource, offer my personal insights, and discuss how this newfound knowledge can be applied to our future practice as software developers.

The resource I found is an article titled “A Beginner’s Guide to the Strategy Design Pattern,” available on the FreeCodeCamp website. This article serves as an introductory guide to the Strategy Design Pattern in software development. It outlines the pattern’s purpose, components, benefits, use cases, and best practices for implementation. The core idea of this pattern is to encapsulate a family of algorithms, making them interchangeable at runtime.

Why I Chose This Resource

I selected this resource because I was struggling with understanding the homework assignment and this article helped me better understand the strategy design pattern. Moreover, the article provides practical examples and clear explanations that make it accessible to beginners like myself.

Reflections on the Content

The article begins by explaining the core concept of the Strategy Design Pattern. It emphasizes the benefits of encapsulating algorithms into interchangeable strategies, including improved code flexibility, re-usability, and simplified testing. I found this concept to be highly relevant to our studies, as it promotes clean and maintainable code, a fundamental skill for any software developer.

The article discusses real-world use cases for the Strategy Design Pattern, such as sorting algorithms, validation rules, and payment processing. These examples helped me see the pattern’s practical application in various scenarios, and I can envision using it in my future projects.

Additionally, the article provides a step-by-step guide on how to implement the Strategy Design Pattern in Java, breaking down the process into clear, manageable steps. This hands-on approach was incredibly valuable as it demonstrated how to apply the theoretical knowledge in a real coding scenario much like the one seen in the Duck Simulator.

Application to Future Practice

Understanding the Strategy Design Pattern will undoubtedly benefit us in our future practice as software developers. Here’s how:

1. Code Flexibility: By using this pattern, we can make our code more adaptable to changing requirements. It allows us to swap out different strategies at runtime, making our software systems more versatile.
2. Re-usability: The Strategy Design Pattern promotes the re-usability of code. We can create a library of interchangeable strategies that can be applied to various projects, saving time and effort.
3. Clean Code: Implementing this pattern encourages clean coding practices by separating concerns and reducing code complexity. This results in code that is easier to read, maintain, and debug.
4. Testing: With strategies separated from the main object, testing becomes more straightforward. We can test each strategy in isolation, ensuring that it functions correctly.

Conclusion

In conclusion, the Strategy Design Pattern is a valuable tool in software development, and I believe this article provides a solid foundation for understanding and implementing it. As future software developers, mastering design patterns like this one will be essential for creating efficient, maintainable, and flexible code. I encourage you to read the article and explore this pattern further to enhance your skills in software development.

From the blog CS@Worcester – Abe's Programming Blog by Abraham Passmore and used with permission of the author. All other rights reserved by the author.

I’ve heard these terms a lot, concurrency and multithreading, but I never really bothered looking into what they actually do. All I’ve really known about these terms was that they make things run faster. I mostly associated multithreading with hyperthreading, I’ve known that CPUs can use multiple cores for the same application to speed up runtime and make games perform better, but I was always sort of confused about how some games have issues with actually taking advantage of modern high-end CPUs. Usually, this is fixed by some sort of modification, if it’s been written already. That being said, my association between the two is only really surface level.

Hyperthreading is really just related to the physical hardware, which makes it different from multithreading in programming. Instead, multithreading is a form of concurrency in which a program has multiple threads that can run simultaneously, with each thread having its own operations and processes that it executes. What this ultimately means is that within a program, multiple operations can be executed at the same time.

This really fascinates me coming from the perspective of only writing straightforward code. While I sort of knew intuitively that programs can probably do multiple tasks at the same time, I’ve only experienced this on the end-user side of things, rather than the individual writing the program. After looking into how threads work in Java on a BairesDev post regarding Java concurrency, I can really see how powerful of a tool concurrency can be for runtime efficiency. This post essentially goes over what concurrency is and the ‘basics’ of utilizing built-in multithreading functions in Java, along with the advantages and disadvantages that this design comes with.

Of course, it does seem like it takes a careful approach to make sure that the implementation of such a tool is actually beneficial to the project. Even with this relatively simple tutorial, I did find myself a little confused at some points, particularly at the point where Locks are introduced. Though this could be the effect of the hour at which I decided to start writing this blog post, it still stands to reason that the complexity of writing a multithreaded program may result in a more difficult development process, especially in debugging.

Regardless, I was truly fascinated by the subject matter and I’m really excited to be going over concurrency in our course (CS-343). This seems like a tool I would really like to use as I enjoy toying with logistics in video games and the like.

From the blog CS@Worcester – V's CompSCi Blog by V and used with permission of the author. All other rights reserved by the author.

For this week’s blog post, I chose the article “Code Documentation: How to Do It Right” by the editorial team of SkillReactor. I chose this article in particular because it aligns well with the code documentation section of the syllabus. This article goes into great depth about code documentation and its benefits, as well as how it is best implemented. In this blog post, I will specifically be going over the code documentation tools discussed in the article and how the article discusses overcoming documentation challenges. Prior to reading this article, I wasn’t very familiar with code documentation tools, but I learned much about their function and how some of the tools mentioned can be used with multiple programming languages.

The article mentions a few specific code documentation tools that are commonly used in software development. One of the tools mentioned that caught my attention is Doxygen. “Doxygen is a versatile tool that supports multiple programming languages and generates documentation in HTML, LaTeX, and RTF formats.” Doxygen is very interesting because of its benefit of functioning alongside multiple programming languages and creating documentation in HTML, which, in my experience, can be very difficult to navigate without some form of documentation guiding you. I also found Sphinx to be fascinating because the article mentions that it makes use of automated API documentation generation. “Sphinx, primarily used for Python codebases, offers automated API documentation generation and support for reStructuredText markup language.” This tool having the capability to generate documentation for your code automatically can be immensely helpful; it being automatically generated can also help with accidentally using jargon or slang that may not be understood by others reading through your code. Another essential aspect that the article discusses is overcoming some challenges associated with creating code documentation.

Writing documentation into your code comes with great benefits, but often, it can be difficult to implement into your project. One of these challenges being maintaining up to date documentation with a project. “Although code documentation offers numerous advantages, it comes with its own set of challenges. Managing updates to documentation can be a daunting task, particularly in large projects where multiple developers are working simultaneously.” Another challenge that comes along with creating documentation is avoiding redundancy. “Another challenge is avoiding redundancy in documentation. When multiple code sections use the same functions or variables, it can be tempting to copy and paste documentation, resulting in redundant documentation and confusing code.” However, these challenges can be overcome with enough diligence. “To overcome these challenges, it is essential to establish specific standards for documentation management and to incorporate documentation review processes into the development workflow.” As long as these standards can be maintained and code documentation is regularly reviewed, the documentation implemented with your projects should be of high quality and make understanding your projects much easier for your fellow developers.

Article: https://www.skillreactor.io/blog/the-importance-of-code-documentation-and-how-to-do-it-right/

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

The article I chose for this week’s blog post is “What Is an Anti-Pattern?” by Andreas Schöngruber. I chose this article because it discusses what anti-patterns are, gives some examples of anti-patterns, and how to avoid them. I chose this article for this week’s blog because it fits well with the syllabus topic of anti-patterns. I found the section about recognizing and avoiding anti-patterns to be very helpful. This blog post will focus on the aforementioned section about recognizing and avoiding anti-patterns in your code.

I will first discuss the section of the article which discusses recognizing anti-patterns in your code. One method that the article mentions involves keeping an open mind and looking to others for feedback. “When identifying anti-patterns in our code or design, we must keep an open mind and question our assumptions. Sometimes, we may become attached to a solution that required a lot of time and effort, but there might be a better solution out there. To avoid this, it is helpful to seek feedback from others.” As this quote states, it is imperative not to be too attached to a process that you developed or are developing, especially if the time it takes to develop or implement this feature is more than the value that the feature is worth. Another important part of being able to mitigate the harm done by anti-patterns is knowing how to avoid them.

While being able to identify anti-patterns is incredibly important, it is also important that one knows how to prevent their occurrence in the first place. One method of doing so is by stepping back and looking at the greater picture of the project that you are working on. “When working on software projects, it is essential to be aware of common pitfalls that can lead to anti-patterns. One strategy to avoid these pitfalls is to take a step back and consider the larger context of the problem. Understanding the problem in its entirety will help in coming up with a good solution.” Instead of being hyper-focused on one part of a larger project, which could lead to anti-patterns arising in your code, its best to take a step back occasionally to make sure what you are working on is not falling into the traps of anti-patterns. Another method of preventing anti-patterns would be a divide-and-conquer approach to developing features. “Another strategy is to break down large problems into smaller pieces. Doing this can help avoid getting overwhelmed and make it easier to spot issues and inefficiencies.” Using this strategy can be very beneficial because it can allow you to see anti-patterns as they appear in your code.

Article: https://www.baeldung.com/cs/anti-patterns

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

Through the duration of this class, we have worked a lot with different types of classes, abstract and concrete, as well as interfaces to better design the code. It was not a new concept to me, as I have learned some of the basics to these in prior classes. However, I never truly understood the benefits and the right time to incorporate each. The articles I found give a simple explanation on the distinctions between concrete classes, abstract classes, and interfaces, as well as the correct situations to use them in.

A concrete class, sometimes just referred to as a class, is used to specify any entity. It also can work as a blueprint for all entities with the same attributes. An abstract class and interfaces are similar and was often confusing for me to distinguish the two of them at first. An abstract class will have methods implemented inside the body, but abstract methods will not have the body of the method inside this class. For example, the duck class I was working with for Homework 2 has the abstract class Duck and the abstract method display(). The body of the method is not present in the abstract class because the different concrete classes implementing Duck uses display() to show different messages. An interface only has the method names included for classes to implement with the interface but does not have any body of the methods. This is what partially distinguishes abstract classes from interfaces, as abstract classes can have concrete methods defined in them while interfaces can only have the method names defined. Interfaces are handy when only needing to enforce a contract. Whoever implements this interface will provide an implementation of all the methods. Abstract classes are helpful when only needing partial implementation, which leaves the responsibility of implementing non-useful methods from the class.

The phrase “program to an interface, not an implementation” is new to me and I am starting to make more sense of it. Concrete classes are the actual implementation, interfaces are the contract, and abstract classes are a trade-off between both. Being able to fully program these three structures into the program helps with maintainability, extensibility, and testability. When programming to an interface, you are forced to split the program into subsystems, with each subsystem responsible for certain tasks and having the ability to communicate with each other to complete the whole task. The key to making the program more flexible is focusing the design on what the code is doing rather than how it does it.

I decided to pick this topic for my blog because I had always had a good idea of how to physically write programs to function correctly. However, something that I never focused on before was the structure of the code which can help when needing to develop the program further after initial creation. Most of our time spent in the class so far has been focusing on this concept and it is proving to be very important the more a program continues to develop.

Program to Interface, Not Implementation – Beginner’s Tutorial for Understanding Interface, Abstract Class and Concrete Class – CodeProject

Programming to an Interface – DZone

From the blog CS@Worcester – Jason Lee Computer Science Blog by jlee3811 and used with permission of the author. All other rights reserved by the author.