Version Control

Version control is a software development process that tracks and manages every change made to a code base. Tracking changes allows developers to be able to see what changes were made, who made them, and when they were made. The history of these changes enables developers to revert changes back to previous versions in case of any irreparable damage.

Version control allows for multiple developers to work on a project concurrently. When multiple changes are made at once, conflicts can occur. Version control can identify those conflicts to allow development teams to quickly compare the changes and decide how to handle the conflict. Version control streamlines coordination, sharing, and collaboration.

Types of Version Control Systems

A version control system (VCS) is the system that tracks changes made to files. Common types of VCSs are distributed and centralized, the latter being most common.

Centralized VCS (CVCS)

In a centralized VCS, all files are stored in one central repository where developers work in. The central repository can be hosted on a server or on a local machine. CVCS is most commonly used in projects where teams need to share code and track changes.

Distributed VCS (DVCS)

Distributed VCS store files across multiple repositories, allowing developers access to files from multiple locations. DVCS is often used when developers need to work on projects from multiple machines or who collaborate with others remotely.

Lock-Based

Less commonly used, Lock-Based uses file locking to manage concurrent access to files and resources. File locking prevents more than one user to make changes to a file or resource at a time, eliminating conflict changes.

Optimistic

Optimistic VCS gives every developer their own private workspace. Once changes are made and are ready to be shared, a request is made to the server. Then the server looks at the changes and determines which can be safely merged together.

Popular Version Control Systems

Git

The most popular of version control systems. Git is an open-source distributed version control system that can be used with software projects of any size. This makes Git a popular choice for most, no matter the project.

Subversion (SVN)

Subversion is a centralized VCS; therefore, all project files are kept in one main repository. This makes branching impossible, allowing for easier scalability for large projects. A form of file locking is in place, allowing users to restrict access to subfolders.

Mercurial

Mercurial is another distributed version control system. Mercurial offers an intuitive command line interface that allows developers to use this system immediately.

Conclusion

I chose this resource because it clearly explains what version control is and why it’s important. Before reading this article, I was unaware of the different types of version control systems, and the popular choices that implement them such as Subversion. I also learned when each type of VCS might be more useful than another. This is only the beginning of my knowledge of version control systems. As my journey into software development continues, my understanding of VCSs will only broaden.

Resources:

https://about.gitlab.com/topics/version-control/

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

The podcast episode, “Scrum vs Agile & Keys to Success with Mike Cohn,” discusses the ways to succeed using the Agile methodology and how to work with the Scrum Guide to create an efficient plan for your team. I selected this episode because I believe that one of the major aspects of creating an efficient team is the steps you take to complete your work. To do that, you must follow a methodology to create a plan to complete your goal. In class, we learned about Agile and the advantages it had over waterfall, so listening to a podcast about Agile was very intriguing. The episode emphasizes that you don’t have to adhere to the Scrum Guide as if it were a rule book, and that you have to work with your team to find out what aspects of the guide work best within the team to allow for maximum efficiency. This is a big mistake that many people make because they are scared of “breaking the rules.” However, this is something that one must be able to do if they want to elevate their work to the next level. From this, I thought the podcast was very interesting since we recently learned about these methods in class. In class, we discussed the steps of Agile and the benefits it has compared to the waterfall methodology that we learned about prior. In addition, we also learned about the Scrum Guide, where we were taught the aspects as well as the elements that the Scrum Guide highlights to help users understand Scrum. From our work, we were shown that you are allowed to deviate from the Scrum Guide; it is just a basic framework to help users put the steps in an effective order. After the episode, I believe that it gave valuable insights on how these methods work in real company settings, highlighting how you don’t have to follow the guide to a tee and you must find out what works best for your team to allow for the most efficient work. Plus, through the discussion of real-world examples, it promoted further thinking about what we learned in class as well as how to connect the ideas we were taught to work experiences. Once it comes time for me to apply this to my work, it will be helpful to understand that the Scrum Guide is not a rule book but a guide to take aspects from to assist in efficient teamwork.

From the blog CS@Worcester – Giovanni Casiano – Software Development by Giovanni Casiano and used with permission of the author. All other rights reserved by the author.

This week, I wanted to continue from my previous entry describing the Single Responsibility Principle. The next concept named in the SOLID design philosophies is the Open-Closed Principle. I first heard the name of this design philosophy in one of my computer science courses. I couldn’t figure out what exactly it meant just going intuitively from the name, however, so I returned to the Stackify website from my previous blog post to continue reading about the SOLID principles.

The Open-Closed Principle was first coined by Bertrand Meyer in his 1988 book “Object-Oriented Software Construction”. Robert C. Martin would later adopt the Open-Closed Principle, calling it “the most important principle of object-oriented design”. He would explain the Open-Closed Principle as “Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.” In practice, this means programming such that new functionalities may be added without changing the existing code.

Bertrand Meyer originally proposed inheritance as a means of abiding by the Open-Closed design principle, but this introduces the problem of tight coupling between software classes. If one class is too dependent on a parent class to function, it will be difficult to make changes to one class without modifying the other class to maintain functionality. Instead, Robert C. Martin suggests using interfaces rather than concrete superclasses, redefining this design philosophy as the Polymorphic Open/Closed principle. The abstraction provided by interfaces helps avoid the problem of tight coupling between software classes.

The article goes on to provide a practical example of the application of the Open/Closed principle through creating a software class representing a coffee machine, and an accompanying class representing a simple app that controls the coffee machine. The article presents the situation where the user may have a different kind of coffee machine that they would like to control with the same software app. The process of refactoring the BasicCoffeeMachine code to implement a broader CoffeeMachine interface is detailed, as well as the process of refactoring the CoffeeApp to utilize the new CoffeeMachine interface. This way, the functionality of our software was greatly expanded, without having to remove large portions of our previously written code.

I chose to research more about the Open/Closed Principle this week because I don’t find myself using interfaces in my projects as often as I should. I could save space and make my code more efficient if I took care to design my software classes to an interface. The example in the article seems like it is employing the Strategy method when instantiating the CoffeeMachine objects. Understanding both the Strategy method and the Open/Closed principle will help me to make better use of interfaces when designing software classes in the future.

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.

Object Oriented Programming Principles

In object oriented programming there are four basic principles: Encapsulation, Abstraction, Inheritance, and Polymorphism. These principles are fundamental such that they are referred to as the four pillars of object oriented programming.

Encapsulation

Encapsulation is hiding or protecting data about a class. This can be achieved by restricting access to public methods. Variables within a class are kept private, while accessor methods are kept public in order to access the private variables.

Encapsulating data helps prevents unauthorized modifications of data by only allowing access to the data using the defined accessor methods. For example, when adding variables to a class rather than accessing/modifying them directly, one would create “getter” and “setter” methods that would still be able to access the data. These methods would allow users the same functionality, but without the risk of undesired changes.

Abstraction

Abstraction is showing only relevant data of classes. Abstraction enables working with high level mechanisms of a class rather than the specific details of implementation, thus reducing complexity.

Picture a system storing different types of vehicles. Rather than creating different concrete classes for each type of vehicle, abstraction can be applied to create one class, ‘Vehicle’, that has the frameworks of basic behaviors and attributes that all vehicles have. These could include methods and attributes such as ‘start()’ and ‘stop()’, and ‘make’ and ‘model’. Then classes for each type of vehicle can be made to extend the ‘Vehicle’ class. Classes that extend ‘Vehicle’ can add specific implementations to the methods and attributes, depending on the vehicle.

Inheritance

Inheritance can be defined as having a “is-a”/”has-a” relationship between a parent class and it’s child classes. The child class derives all methods and attributes from the parent class, enabling reuse of code, but also allowing the addition of unique attributes and methods.

Imagine a system for a college representing faculty and students. A parent class, ‘Person’, is created for common data among all people at the college such as ‘name’ and ’email’. Child classes of ‘Person’ can be created such as ‘Faculty’ and ‘Student’. Both child classes would inherit ‘name’ and ’email’ from the ‘Person’ class, while unique information can be added to each of the child classes. Unique attributes could include ‘gpa’ for ‘Student’ and ‘salary’ for ‘Faculty’.

Polymorphism

Polymorphism can be simply put as reusing code with different types of objects, reducing code redundancy.

Using an interface called ‘Shape’ with method ‘calculateArea()’, different types of shapes can implement ‘calculateArea()’ and change how the specific shape uses the method. For example a square would calculate the area differently than a circle. However, both can still use ‘calculateArea()’ due to polymorphism.

Conclusion

As we learned earlier in the semester, many of us did not have a complete understanding of the four principles above, which is why I chose to learn more about them. After reading the blog, I now better understand the differences and why each of the principles are important. I will be implementing these principles into all future projects.

Resources:

View at Medium.com

From the blog CS@Worcester – Zack's CS Blog by ztram1 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 “A PRIMER ON OPEN SOURCE LICENSE COMPLIANCE” by Dasha Gurova. This article discusses what Open Source Licensing is, what software licenses are, why you should implement an open source license compliance policy, some examples of semi-automated OSS compliance tools, and how to use OSS (open source software) compliance systems. I will be discussing the ways of implementing OSS compliance systems mentioned in the article, those being the manual and semi-automatic methods, and their strengths and weaknesses.

The methods the article mentions for maintaining OSS compliance are manual and semi-automatic. The manual process is a very time-intensive approach and an old-school approach. “A surprising number of companies are still using this approach. Basically, you create a spreadsheet and manually fill it out with components, versions, and licenses and analyze it against your policy.” The article also says that this method can be very effective on smaller projects if implemented early in the project’s development. This method would entail reviewing and logging the software’s license before implementing any components from the open-source software. However, if not implemented early, using this method can be very difficult to execute properly. This method also becomes much more challenging to maintain as your project uses more and more OSS components. Especially to make sure the licenses that you are using do not conflict with one another and are being adequately implemented. These issues can be made worse especially when this method is not being maintained properly, in addition to being used in a large project.

The other method mentioned in the article is the semi-automatic method. “This is a more reliable approach and is becoming more popular, as the importance of open source compliance practices grows along with the risks associated with ignoring these practices. There are many tools available, in a way that it gets overwhelming. Why semi-automated? Because there are always false positives if the license is not explicitly referenced in the header and you still have to read through some of them to discover special terms or conditions.” As mentioned in the article, this method is far more reliable but teams that use this method must be vigilant to see if the warnings that the tools give are false positives. If the team using this system just assumes all the warnings are completely accurate this could lead to a lot of headache trying to find other OSS that would comply even though you already had OSS that would work.

Article: https://www.zenko.io/blog/get-started-with-open-source-license-compliance/

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.

Learning the differences between Waterfall and Agile and choosing the methodologies best suited for the next project!

For this week I have decided to write about 2 different methodology, Waterfall and Agile. Which one is the best and when can we use each of them? I read a blog about both these methodologies and I am going to explain which one is the best to use on different cases.

In the world of project management, two prominent methodologies, Waterfall and Agile, offer distinct approaches to achieving project success. Imagine making a ham sandwich to grasp the fundamental differences between these methodologies. In Waterfall, you follow a linear process, just as you would follow a recipe step by step. Each stage, from gathering requirements to maintenance, proceeds in a clear sequence. However, like making changes to your sandwich after it’s complete, altering anything in Waterfall can be challenging. This approach demands a clear vision from the start and is ideal for projects with well-defined requirements and minimal changes expected, such as building a bridge.

On the other hand, Agile is akin to a group of friends embarking on a road trip with flexibility in mind. Instead of a fixed plan, Agile projects are divided into short sprints, typically lasting two to four weeks. After each sprint, the team evaluates their progress, incorporates feedback, and adjusts their course. Agile’s adaptability is perfect for projects with evolving requirements, quick adaptability, and a need for continuous feedback, as seen in software development.

Both Waterfall and Agile have their advantages and disadvantages. Waterfall offers well-defined project phases, clear documentation, and straightforward cost estimation. However, it struggles with making changes and may not suit projects with uncertain requirements. There’s also a risk of a mismatch between the initial design and user needs.

Agile, on the other hand, excels in accommodating changes, iterative improvements, team collaboration, and dynamic resource allocation. It is, however, susceptible to chaos without proper management and might lack comprehensive documentation. Setting a fixed price or timeline can be challenging, and there’s a risk of scope creep.

Choosing between Waterfall and Agile depends on your project’s nature. Waterfall is best for projects with clear requirements, usability tied to the entire deliverable, strict phase dependencies, and linear progress. Agile shines in situations where requirements may evolve, quick adaptation is essential, continuous feedback is necessary, and flexibility is key.

Selecting the right approach is not about determining which method is superior but rather about choosing the one that aligns with your project’s unique requirements. To excel in either Waterfall or Agile, consider using project management tools like Motion, which offers features that cater to both methodologies. Motion’s intelligent calendar and task manager assist with scheduling and prioritizing tasks, while its flexibility makes it adaptable for Waterfall’s structured phases or Agile’s iterative workflows.

In conclusion, project management is not a one-size-fits-all endeavor. Waterfall and Agile are two distinctive methodologies, each with its strengths and weaknesses. The key to success lies in understanding your project’s needs and selecting the approach that best aligns with those requirements. With the right tools and a clear understanding of these methodologies, you can navigate your project to success, just like choosing the right footwear for your journey – be it hiking boots or running shoes, tailored to the path you plan to tread.

Resources: https://www.usemotion.com/blog/waterfall-methodology-vs-agile

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

In the labyrinthine world of software design, where complexity can quickly become a daunting challenge, a guiding principle emerges as a shining beacon of simplicity and maintainability. This principle, known as the Principle of Least Knowledge or the Law of Demeter (LoD), serves as a valuable compass for software architects and developers. Its primary mission: to minimize dependencies between objects and foster a more modular and maintainable codebase.

At its essence, the Principle of Least Knowledge encourages developers to reduce the interactions between different parts of a software system. This reduction of dependencies simplifies the code and makes it more robust. The LoD suggests that an object should only have limited knowledge of other objects, specifically, objects that are directly related to it. In simpler terms, it advocates for keeping the communication between objects focused and minimal.

By adhering to the Principle of Least Knowledge, developers can significantly enhance the maintainability of a software system. When objects have limited knowledge about other objects, changes in one part of the system have minimal impact on other parts. This isolation of knowledge not only reduces the risk of unintended consequences but also facilitates easier testing and debugging.

As software systems grow in complexity, the LoD remains a steadfast ally. It ensures that each component knows only what is essential for its immediate tasks, fostering a more modular and less error-prone codebase. With the Principle of Least Knowledge as their guiding star, software developers continue to navigate the intricacies of software design, simplifying the path to robust and maintainable systems.

References:

• The Law of Demeter
• The Principle of Least Knowledge
• Law of Demeter and Principle of Least Knowledge

From the blog CS-343 – Hieu Tran Blog by Trung Hiếu and used with permission of the author. All other rights reserved by the author.

This week I am jumping to chapter 6 of Apprenticeship Patterns. The pattern I read was called Reading List. The context of this chapter is now that you have become proficient in your first language, you start to see the massive amount of information you still need to learn. The problem with this is there is more information that you need to learn than you can keep up with.

The solution for this is to track the books and other sources you plan to read and remember which ones you have already gone through. This pattern mentions it might be a good idea to store it in a place that will allow other people to benefit from it. Not only is this pattern used to manage books you are reading but it also helps with reflecting on your past reading habits. One of the most valuable things you can get out of a book is finding other books in the bibliographies that will be good information.

The action plan given to help with the problem is to create a text file and put in all the books you are currently reading. The text file will be your reading list and make sure you keep it up to date. 

I chose this pattern because I thought it would be good to know what to do after I have really mastered my first language and am ready to move on to new things. This will probably be a little while before I am ready for these next steps but being prepared will help with the transition. I will make sure to try out the solution for this pattern but use more than just books. Books are useful but there are plenty of other good resources that I can learn a lot from such as articles, videos, and blog posts, as well as learning from other people. A takeaway I get from this chapter is there will always be more to learn so having a solution to track what you are doing will be a big help with getting through as much as possible.

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

“Emptying the cup” is one of the most important and interesting chapters of the book “Apprenticeship Patterns” by Dave Hoover. This chapter is a call to all aspiring software developers to unlearn their preconceived notions, beliefs, and biases that may have been learned from past experiences, learning other programming languages, or etc. and become open to new perspectives. In the context of software development, the phrase “emptying the cup” means being open to new ideas, technologies, and practices. It means being willing to unlearn old habits and ways of thinking that might be blocking your growth as a developer. New software developers should be aware of the importance of curiosity and a willingness to learn from others so that they can grow into exceptional software developers.

This apprenticeship pattern revolves around clearing your mind of everything you know and opening yourself to new and different approaches to the problem. Clearing the mind of previous knowledge would get rid of old habits that the programmer may have picked up on while coding in the past. What works in one language might not necessarily work in another language, and there may be more efficient solutions to a problem in another language that may be the most efficient in the original language. What I found interesting is that emptying the cup is much like the metaphor “thinking outside the box.” Rather than using traditional or old habits to solve a problem, you should drop the old habits and think differently and incorporate new perspectives to solve the problem. Most people may fall back on a traditional or the most popular method to solve problems they may encounter while programming because it has shown to work in similar situations. But when programmers solve problems by thinking outside the box, they try to find untraditional ways to solve problems, or find unintended ways to solve them. Thinking outside the box and emptying the cup are similar since they both require the programmer to deviate from the usual methods of problem solving that programmers do and find a more creative way to come up with solutions.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

“Emptying the cup” is one of the most important and interesting chapters of the book “Apprenticeship Patterns” by Dave Hoover. This chapter is a call to all aspiring software developers to unlearn their preconceived notions, beliefs, and biases that may have been learned from past experiences, learning other programming languages, or etc. and become open to new perspectives. In the context of software development, the phrase “emptying the cup” means being open to new ideas, technologies, and practices. It means being willing to unlearn old habits and ways of thinking that might be blocking your growth as a developer. New software developers should be aware of the importance of curiosity and a willingness to learn from others so that they can grow into exceptional software developers.

This apprenticeship pattern revolves around clearing your mind of everything you know and opening yourself to new and different approaches to the problem. Clearing the mind of previous knowledge would get rid of old habits that the programmer may have picked up on while coding in the past. What works in one language might not necessarily work in another language, and there may be more efficient solutions to a problem in another language that may be the most efficient in the original language. What I found interesting is that emptying the cup is much like the metaphor “thinking outside the box.” Rather than using traditional or old habits to solve a problem, you should drop the old habits and think differently and incorporate new perspectives to solve the problem. Most people may fall back on a traditional or the most popular method to solve problems they may encounter while programming because it has shown to work in similar situations. But when programmers solve problems by thinking outside the box, they try to find untraditional ways to solve problems, or find unintended ways to solve them. Thinking outside the box and emptying the cup are similar since they both require the programmer to deviate from the usual methods of problem solving that programmers do and find a more creative way to come up with solutions.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.