Understanding the Essentials of GIT Version Control

In the ever-evolving landscape of software development and its processes, version control systems play a pivotal role in ensuring code integrity when it comes to GIT, collaboration, and project management. Among these, GIT stands out as a distributed version control system with a rich history and a plethora of capabilities.

Going and delving deep into the fundamentals of GIT, i wanted to see the brief history behind GIT-i uncovered the facts of it being created by a man who went by the name of Linus Torvalds(the same guy who created the Linux kernel operating system). We explore how the GIT application revolutionized software development by supporting a non-linear process of operating within coding projects, being able to facilitate large project management as well as enabling code tracking. The blog post i went on was mostly a comprehensive guide to using GIT, the characteristics it has, the main components, commands which we’ve already covered in previous classes and activities alongside it’s various applications in other domains.

This seemed like a good choice considering it proves a sort of holistic view of GIT, of course another core feature that we use for software process management course- but more precisely being able to understand version control systems which is very crucial in the modern-day software development industry- providing valuable insights in terms of how GIT aligns with the key principals associated with software process management.

This resource does deepen my knowledge and understanding GIT’s role in software development and the uses/features- from the distributed model, branch management, better data integrity as well as being able to maintain parallel developments even in large code projects is an important takeaway from all of this. it can also be used for a variety of situations, whether it’s an open-source project, managing a product or handling real-time web pages and applications.

Since GIT is a useful application that i think will be an important part of future coding endeavors- i do expect to use it as a core tool taking into account it’s capabilities, the previously mentioned efficient branching to the merging and its distributed nature making it an essential resource and asset for maintaining quality code and ensuring good collaboration between team members. Knowing of it’s advantages and disadvantages helps to make informed decisions based on the situations one may encounter when using the application. To conclude with, GIT is a pivotal element in the world of software development. This resource provides a comprehensive guide to GIT’s features, characteristics, and applications- making this a highly powerful tool.

https://www.educba.com/introduction-to-git/

From the blog CS@Worcester – CSTips by Jamaal Gedeon and used with permission of the author. All other rights reserved by the author.

Scrum for other fields?

This week in class, we went over the process of Scrum. Essentially, it is a loose framework on how a team should be working if they want the greatest potential from that work. I say ‘loose’ because it is loose, other than providing how the process should go, it allows teams to not only follow this framework, but adapt it and make it unique for their team and their work. I like this methodology for this reason. 

Scrum states that a team consists of developers, a product owner and a scrum master. Each has their own roles and responsibilities in the process. The process has five parts. The main event is the Sprint, which is a one month process where everyone is working in order to achieve a goal. Before this can happen, there is the Sprint planning, which is planning the Sprint and figuring out what needs to be done. Everyday before people start working, there is the Daily Scrum, a short meeting about what needs to be done that day. At the end of the Sprint, there is the Sprint review, going over the results and progress of the Sprint, and the Sprint retrospective, reflecting on the Sprint, as a whole and on individual parts, so that the next Sprint is better. Each part, and the roles, are described in detail in the Scrum guide.

In this blog post, Gregory Crown and Robert Pieper talk about how Scrum could be used outside the realm of software development, like marketing. I chose this particular post because not only does it connect to what we’re learning in class, it talks about how Scrum can be used outside of software development. In the post, they specifically talk about how marketing can use the framework of Scrum, and how it benefits from it. Pieper says that if it is a complex activity or problem, Scrum can help. He describes complex as something requiring a lot of opinions. He uses a water bottle as an example, saying one stakeholder may not like the color, another may ask what the purpose of the rubber thing at the bottom of it is, etc. Essentially, if you show the benefits of something, and there are a lot of different opinions on it, you can benefit from Scrum. He describes it in a very nice way, saying, “if you’re in a subjective environment where you’re getting a lot of opinions, use Scrum.” He says that if what you’re working on is something that just meets requirements, and then moves on, you don’t need Scrum. 

Personally, I agree with what he says. On paper, Scrum is an excellent framework for a lot of things. It has the layout on how to do things, but allows people to fill in the rest, however necessary for things to be done. It is a clean way of doing things, strict yet flexible. This shouldn’t just be a computer science thing either, if others can benefit from this, do it.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

CS343 Blog Post for Week of October 16

SOLID Design Principles Explained: The Single Responsibility Principle

This week, I wanted to further research software design principles and guidelines. In my past coding projects, there wasn’t any set framework or model I would stick to when writing my code. This led to creating classes that depended on each other too closely, and methods that attempted to accomplish too many tasks at once. To create better functioning software, I’m going to need to learn the best design practices to abide by at the outset of the project.

A popular set of design principles among software professionals are the SOLID design principles. Named by Robert C. Martin, SOLID is an acronym for 5 design principles that lend themselves to efficient, functional software. These 5 principles are:

  1. Single Responsibility Principle
  2. Open / Closed Principle
  3. Liskov Substitution Principle
  4. Interface Segregation Principle
  5. Dependency Inversion

This blog post from the Stackify website focuses on the Single Responsibility Principle and its role in the software development process. Robert C. Martin describes the Single Responsibility Principle as “A class should have one, and only one, reason to change.” Abiding by this principle may help avoid unintended consequences from future updates to the software, as fewer interactions may break as a result of changes to the code.

Even small-scale software projects will likely change significantly over time, and keeping the Single Responsibility Principle in mind will prevent your classes from being encumbered by unnecessary dependencies on each other. If a single class is called upon by many other classes within your software, changes to that class may break the functionality of any classes dependent on that parent class.

Making an effort to keep components of your program independent of one another also has the benefit of keeping your project simple for a human to understand and explain. When a piece of software can be understood by the developer or team of developers working on it, the flow of productivity is so much greater since fewer effort is being spent on deciphering how the software functions. Updates and new features can also be released more quickly and consistently when the structure of the program is easier to modify without compromising the interactions between its components.

Abiding by the Single Responsibility Principle does not mean only creating classes with a singular function, however. This approach can lead to the same problem of too many classes becoming dependent on a singular parent class, and unnecessarily complicates the structure of your program.

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.

Visual Studio Code (VS Code): A Powerful Tool for Developers

Considering Visual Studio Code is a staple, core feature of our class, i wanted to see if there was anything more to this application that would be the fundamental base block for our classes. From what i’ve learned, it’s a highly versatile and widely embraced code editor in the realm of software development-having been developed by Microsoft; being a FOSS(Free and open source software) which caters to the needs of developers on platforms like Microsoft/Windows, macOS and Linux, being significant in being able to provide a unified environment for coding, editing and troubleshooting any problems that may arise.

Some of the key features of the VS Code program includes the aforementioned cross-platform compatibility- being available for Windows, Linux and macOS, language support in that a variety of programming languages exist and extensions can also be installed for other programming languages that aren’t currently supported, a robust community that contributes to the vast selection of extensions that exist- alongside users being able to develop their own extensions- making this even more of a dynamic ecosystem that prove of mutual benefit for all.
VS Code also has built-in features- ranging from a console to Git support to a debugger. Besides those practical features, it’s the more broad applications- as VS Code finds a utility amongst most data experts, machine learning practitioners, system and cloud developers, and those working with various cloud providers.

I chose this text since it proves a valuable insight into the utilities of the Visual Studio Code program that we use daily in our class- in software process management having a variety of development tools at your disposal is somewhat critical as well as being to understand the capabilities and advantages of a tool like Visual Studio Code can and will prove useful in ensuring effective software development in most projects-as well as it’s versatility as a tool- performance and versatility are key considerations when choosing development tools, and these factors are closely tied to software process management’s goals of efficiency and effectiveness.

Taking this into account, i see these development tools not just as a means/way to write and edit the code for the projects but integral components that can streamline the software development process , this can align with the more efficient code practices in software process management that place emphasis on version control, debugging and code quality assurance. This knowledge reaffirms that selecting tools like VS Code is not merely a technical decision but one with broader implications for team productivity, code quality, and project success.

https://shiftmag.dev/vs-code-171/

From the blog CS@Worcester – CSTips by Jamaal Gedeon and used with permission of the author. All other rights reserved by the author.

The Vital Role of Documentation in Programming (Week-6)

Programming, for the uninitiated, may seem like a realm of arcane symbols and inscrutable logic. But at its heart, coding is about communication. It’s a dialogue between the programmer and the computer. Yet, there’s another layer of communication that’s equally crucial: the dialogue between the programmer and any other human who might interact with their code. This is where documentation comes into play.

What is Documentation in Programming?

Documentation refers to explanations and comments that accompany computer code. These can range from simple inline comments that explain the purpose of a specific line or block of code to comprehensive manuals for software libraries or applications.

Why is Documentation Important?

  1. Understanding the Why and How: Without documentation, another developer (or even the same developer, months down the line) might have a tough time understanding the rationale behind certain coding decisions or the functionality of specific sections of the code.
  2. Facilitating Collaboration: In software development teams, collaboration is vital. Comprehensive documentation ensures that every team member understands the code’s workings, making teamwork smoother and more efficient.
  3. Reducing Onboarding Time: When new members join a project, well-documented code helps them get up to speed faster, understanding the project’s nuances without constantly querying the original developers.
  4. Ensuring Code Longevity: Projects can span years, and original developers might move on. Proper documentation ensures that the code remains understandable and maintainable for future developers.

Types of Documentation in Programming:

  • Inline Comments: These are short explanations placed directly within the code. They can explain variables, functions, or the logic behind specific code blocks.
  • API Documentation: This is vital for libraries or frameworks. It explains the functions, classes, and methods available, along with their expected inputs and outputs.
  • Software Architecture Documentation: This gives a high-level view of the software, explaining the system’s structure, data flow, and more.
  • End-user Documentation: This is intended for the software’s users, explaining how to use the software, highlighting its features, and troubleshooting common issues.

Best Practices for Documentation:

  • Be Clear and Concise: Documentation should illuminate, not confuse. Aim for clarity.
  • Regularly Update the Documentation: As code changes, so should the documentation.
  • Use Tools: Tools like Doxygen or Javadoc can auto-generate documentation, making the task more manageable.
  • Encourage Peer Reviews: Just as code benefits from reviews, so does documentation.

While it’s tempting to think of coding as the solitary act of instructing a machine, it’s fundamentally about communication. Documentation is a testament to this fact. By ensuring that our code speaks clearly not just to computers but also to humans, we contribute to more sustainable, understandable, and collaborative software development.

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

A Successful Scrum Team

Overview

The objective of any scrum project management framework is to provide structure, fluidity, values and principles when completing a project. But all members of the project must equally pull their weight as well as know their role for the use of scrum to be efficient. A famous saying that relates to this is that “a team is only as good as its weakest link”. This phrase can be applied to basically any team, or group of people pulling for the same cause, in life. I think a scrum team is no different. This article I read by Dave West goes in detail about each role in a scrum team and how they tie in to each other for the team to collectively succeed.

Scrum Team Roles

Previously stated in class, the three roles of a scrum team are: the development team, the product owner, and the scrum master, with each role being just as important as the other. Starting with the development team, the developers are the ones responsible for working on the product. They are the ones bringing the blueprints and requirements, brought from the product owner, to fruition, essentially doing the dirty work of the team. The product owners show them what needs to be done and the deadline by which it needs to be done, and the developers take it from there. They self-organize and make their own decisions on how to complete the task. The development team could be of any occupation from writing, designing, programming, etc. The prime responsibility of a product owner is understanding business requirements and customer feedback. Based on those two things, the product owner is able to set the focus of the team based on meeting deadlines and release dates. It can sometimes be stressful and overwhelming for developers and product owners having to avoid falling behind. This is where scrum masters come in. The scrum master is the overseer, the piece holding everything together. The scrum master must have knowledge in development and product ownership. The development team and the product owner must be able to count on the scrum master for help and support. The scrum master is responsible for the scrum working as one and keeping the values strong in the team, sort of like a coach. The scrum master is usually the most active member of the scrum team.

Conclusion

As previously stated, I think for scrum to work, all members should be on the right pace. The minute that one role falls behind is the minute the framework fails. With much communication, and all members collectively on the right track, scrum is a very strong framework.

Article I Used

https://www.atlassian.com/agile/scrum/roles

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

What Daily Scrum Meetings SHOULD be Like

article link at the end

Overview

This week we began learning about different types of software methodologies, mainly focusing on SCRUM. Scrum, being one of the most popular software development organizational processes, has many factors to consider and to improve on. One of these pieces is the Scrum Meeting, a 15 minute or so meeting with your co-workers and “boss(es)” discussing the day’s work. However, such meetings can easily devolve or change into different forms; certain groups function differently. For example, one team of developers may find it beneficial to have shorter 5-10 minute meetings where there is less communication from each member. Another team may prefer longer meetings with each developer participating in a detailed discussion. But what should it really be about? How should people really be involved? This is where Mike Cohn’s article Daily Scrums: Synchronization Meetings, Not Status Meetings comes in.

What Not To Do

Cohn, a specialist in agile processes and helping companies utilize teams effectively, believes that many companies do Scrum meetings incorrectly. Most current scrum meetings involve each developer giving a report to their scrum master, whilst the other developers sit and wait their turn. Instead, he states that “the daily scrum meeting is designed for team members to synchronize their effort” (Cohn). This opposes the idea of such meetings being used to simply share what one is working on, and move on for the day.

Cohn’s Beliefs

Cohn believes that daily scrum meetings should have members enthusiastic about the project they’re working on with their team along with the progress being made. Such developers should also be sharing their progress and thoughts not only with the scrum master, but with the rest of the team as well. This encourages a broader discussion with more voices and teamwork involved. 

Cohn encourages Scrum Masters to participate in daily meetings, as they can then hear about impediments while also showing support for their team. Lastly, Scrum meetings should have brief updates that focus on what has been accomplished rather than what one spent time on.

Thoughts

I chose this article because it gives a truer, more refined approach to Scrum compared to the ones mentioned. Since I am a beginner to the idea and process of Scrum, I did not know of some of the problems with current iterations of daily scrum meetings. 

This article has been very helpful to me as it introduces what daily scrum meetings should be like. In the past, I had a misunderstanding about how Scrum meetings went; which lined up with what Cohn advised not to do. Although I have not had any real-life experience with Scrum meetings, I feel better prepared as for what to expect in future jobs. I will most likely be using this newfound knowledge in future projects, whether internship or job, big or small. I understand now that it’s best to look forward to scrum meetings as a time to come together and share, and to leave with excitement about progress.

Article: Daily Scrums: Synchronization Meetings, Not Status Meetings

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Semantic Versioning

Summary: Semantic Versioning (SemVer) is an essential system for versioning software. This blog post explores its core components, including major, minor, and patch versions. It also delves into pre-release and build parts and how version precedence works in SemVer. At the heart of SemVer lies a structured approach to versioning. It all starts with three fundamental numbers: major, minor, and patch. Each of these numbers carries specific meanings, making them the building blocks of compatibility and change management.

Reason for Selection: I chose this resource because semantic versioning is crucial in software development, and I wanted to gain a deeper understanding of how it works. This is also in line with what we are covering in class and in the development of Thea’s Food Pantry.

Comments on Content: The resource does an excellent job of simplifying the concept of Semantic Versioning. It provides a clear explanation of how version numbers are structured and the significance of each part. I now understand that the MAJOR version indicates major, potentially breaking changes, while MINOR versions introduce new features in a backward-compatible way. PATCH versions are for bug fixes.

One aspect of SemVer that I found particularly enlightening was the discussion on pre-release and build parts. Pre-release versions, marked with a hyphen, are often used to share software informally for testing. They may not be stable and might not satisfy compatibility requirements implied by the normal version. Build metadata, indicated by a plus sign, is used to record information about the build process, like who made the build, build machine, and more. This is especially valuable for tracking software development. I could

Understanding the precedence of version numbers is crucial for managing dependencies effectively. The resource explains that version comparison in SemVer is done from left to right. Versions that only differ in the build part are considered equal. Pre-release versions have lower precedence than their standard counterparts. Numeric identifiers always have lower precedence than non-numeric identifiers. This knowledge has provided me with a better grasp of how to choose the right versions when managing project dependencies.

Personal Reflection: This resource has clarified many of my questions about Semantic Versioning. It has demystified what can be a complex topic, making it accessible for developers at a beginner or intermediate level of experience like my own. Now, when I encounter version numbers, I can make informed decisions about their compatibility and the potential impact on my projects. As a software developer, I anticipate that this knowledge will be invaluable in ensuring the smooth integration of various software components and libraries. It will help me avoid compatibility issues and streamline the process of managing dependencies, ultimately saving time and effort in the development process.

Link: Semantic Versioning Resource

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.

SUCCEEDING WITH AGILE

A little journey on the others blogs to learn more about Agile methodology

The Evolution of Agile Practices

Is Agile Going Mainstream?
Agile methodologies have been a driving force in the world of project management and software development for years. They have reshaped the way teams approach projects, placing a premium on adaptability, collaboration, and flexibility over traditional, rigid methods. However, recent trends and discussions in the Agile community have sparked curiosity about the future of the Agile movement. Is it transitioning, shrinking, or possibly assimilating into conventional project management practices? This blog post delves into these intriguing discussions.

The Impact of Remote Work

One reasonable explanation for the drop in in-person conference attendance is the surge in remote work. The COVID-19 pandemic illustrated that remote collaboration is not only feasible but also effective. The convenience of virtual events may play a significant role in the decreased interest in physical conferences. As individuals discover that they can access valuable insights and networking opportunities from the comfort of their homes or offices, the shift away from in-person events becomes more comprehensible.

The Necessity of Agile Evolution

In a recent article, Stefan Wolpers explored whether Scrum, one of the most widely used Agile frameworks, needs to evolve. He discussed potential interfaces and changes that could enhance Scrum’s adoption and boost business agility. These conversations emphasize the ongoing need for Agile to adapt and evolve in response to the evolving demands of the business world.

Conclusion

Agile has undeniably left an indelible mark on project management and software development. Its emphasis on adaptability, collaboration, and flexibility has transformed the way teams approach projects. While conference attendance may be dwindling, the demand for Agile skills and practices is on the ascent, indicating that Agile is becoming absorbed into mainstream project management.

However, the evolution of Agile is far from over. Discussions about adapting Scrum and the need for hybrid approaches indicate that the Agile movement is still actively evolving to meet the demands of a changing business landscape. As we move forward, the key is to strike a balance between traditional project management and Agile practices to ensure successful project outcomes. Agile has not disappeared; it’s simply maturing and growing in influence.

This blog post delves into the evolving landscape of Agile methodologies in project management and software development. It examines the decline in conference attendance, which could signify the integration of Agile practices into everyday work. The post also highlights the impact of remote work on in-person events, the growing fusion of Agile into traditional project management, and the imperative for Agile to adapt to changing business needs.
Here is the link of the blog that I read https://www.leadinganswers.com/

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

The StackOverflow Problem

The world of Computer Programming is one that is comprised of people from every corner of the globe, from countless different social and economic backgrounds, which has led to one of the most diverse fields of study in the world. Some come from well-established foundations; utilizing the resources at their disposal to create new and innovative products. Many more come from more humble beginnings, forging their own path and transforming the world around them. Yet, across this wide spectrum of developers, researchers, and teachers, they all share one thing in common:

At some point in time, at the beginning of their studies, they had relatively no idea what they were doing.

Sure, this sounds harsh. But it’s true for quite literally every field of study imaginable. No one is born with the ability to write machine learning algorithms, develop web applications, or any other kind of work in the field. At one point or another, this knowledge was learned, practiced, and perfected.

In the world of computer programming, the amount of seemingly trivial yet incredibly difficult problems one may encounter can be quite high. They can often be hyper-specific issues where directly posing the question at hand to your peers may be the most effective way of coming to a solution. And in the modern age of the internet, an incredible medium of getting answers proves time-and-time again to be a rock-solid support for developers: StackOverflow.

Munroe, R. (2023) XKCD. http://www.xkcd.com/979

StackOverflow is a forum made for programmers to post issues and questions related to their work, and to receive answers from other programmers on how to resolve these issues. It can be astonishing how regardless of how niche or specific you think your issue may be, there’s an extremely good chance that someone else had the same problem, posted it, and received multiple different solutions. StackOverflow has the benefit of being powered by the vast workforce of the internet, where millions of people can chime in and offer their assistance. However, therein lies the problem:

The internet can be full of jerks.

Of course, I don’t mean to discredit the vast majority of users who are often incredibly helpful and welcoming to newcomers. The usefulness of StackOverflow and similar sites cannot be overstated. The core issue, in my opinion, is the vocal minority who either through arrogance or simply a lack of tact, can scare away those new to the programming field with a sarcastic attitude and an aura of superiority.

This isn’t just anecdotal either. Nate Swanner from Dice.com writes about how in 2019, after StackOverflow made efforts to convince users to “be nice” to each other, the annual developer survey reported that 73 percent of users saw no change in how welcoming the site was to new users. He acknowledges that while the vast majority of users are able to find answers to their questions, there exists a problem in how the forum treats its fellow developers.

“When you’ve got to wade through a river of ego and spite before being told to ‘Google it,‘ we start to wonder how long people will tolerate a Stack Overflow where a “cultural shift” hasn’t yet taken hold.

While one of my least-favorite things to do is to harp on a problem without offering any kind of solution, I really don’t believe there is one singular fix to this kind of issue. After all, this isn’t a phenomenon exclusive to StackOverflow, or even the Computer Science field for that matter. Sometimes, when we hear a question from someone that to us sounds trivial, our knee-jerk reaction is to think “Dude, really? THAT’S your issue?”

This is the mentality that I believe should be addressed and challenged more often in order to create a more welcoming community. The field of computer programming is growing fast. And there are definitely indications that we’re moving in the right direction. That same developer survey found that users on StackOverflow who were people of color felt more welcome than in previous years, which is a great step forward. However, fields of study are driven by the people who study them. And the more welcoming and supportive these groups are, the more a field will grow.

A quick side note: I hope this post didn’t end up being too philosophical; I had originally planned to write about a completely different topic, however after hearing about some experiences from a friend of mine who has just started his freshman year in a CS program, I felt that this was a topic worth discussing.

Citations:

Nate Swanner. “It’s Not Just You: Stack Overflow Is Still Full of Jerks.” Dice Insights, Dice, 18 Apr. 2019, http://www.dice.com/career-advice/stack-overflow-many-jerks.

From the blog Butler Software Construction, Design, and Architecture by Griffin Butler and used with permission of the author. All other rights reserved by the author.