Category Archives: CS-348

GIT(ting) My Friend A Promotion

For teams of developers having a centralized repository for code is essential. Git provides an extremely powerful and relatively user-friendly base for teams to collaborate effectively.

After teaching one of my close friends, involved in a development project at work, the basics of class diagrams. They gave her a more hands-on role with the entire development process. Even though she had never worked with programming before, having someone in a business oriented role who could communicate and check over the team of developers was perfect for them.

That’s when she was selected as the product owner for her company’s new website. In a serendipitous twist they were using git as their repository while I simultaneously was being taught about it in school.

The next step was to teach her a basic overview of how it all looks from a developers perspective.

We started with a picture from my professor.

At first glance, I had completely lost her. After explaining that she wasn’t the maintainer responsible for handling all of this her mind was eased a little. The main ideas were just to understand the flow of how the developers were going to be working. All she had to remember was FCBPP.

This acronym I created for her was simple. They would FORK their own copies. Make CLONES of that. Make a BRANCH where they would do their work. PUSH that work kind of like a save. Then create a PULL request. As a developer it is obviously a lot more nuanced and there are more steps involved. But for someone that isn’t actually doing hands on work that was enough.

After getting the gist of it and before getting further into the details of how it would benefit her to know that stuff. We took a look at the stuff she would really be involved with. The product and sprint backlogs.

In git it is actually fairly easy for someone who doesn’t really understand programming itself to look at, arrange and audit backlog items. It would also allow her to check in regularly to see where the team was when her boss would ask questions.

In the real life case while explaining this part we did use the real github of her company but for the sake of confidentiality it will be a new blank project.

I told her to focus on the issue board under planning. It looked similar to this:

With properly labeled boxes and the lists of items and features the team was working on or planned to work on she felt so much more comfortable asking about things and helping plan everything out. After circling around the topic a few more times we realized just how powerful having a product owner who knows this process could be

We also joked with her boss that with me teaching her these things I should be hired as a consultant (small business unfortunately) with a bonus for my professor.

From the blog Mikes CS 348 by Michael St. Germain and used with permission of the author. All other rights reserved by the author.

The role of individual contributors in the development process

For my first blog I decided to talk about how individual contributors can best fulfill their role in the process of developing a project. This is relevant to the course material because the role of an individual contributor, which is mostly to improve the code and coordinating teams of other ICs, is a similar role the members of a development team would have in sprint.

The position that ICs occupy in most projects is a very impactful and influential position, aside from their ability to directly change the code. Despite their limited access to the management side of most projects, their proximity to the code gives them unique perspectives on the possible directions project could take, and what is and isn’t feasible to implement. In David Noel-Romas’ blog “An ICs guide to roadmap planning”, he introduces the problem of the IC who wishes they had comparable influence to the planning process of the project to their influence on the state of the code. Romas’ suggests several solutions to this problem, including identifying stakeholders and planning around the potential impacts the project will have on them through feedback and other means, making sure the management end of the team is aware of your visions for the project and when would be the most convenient times deliver updates and new features, and rationally bounding the work your team can do in the given amount of time, making an effort budget and working according to it. I think these solutions all take care of the problem of an IC who feels they aren’t offering enough input to the planning process well, and do so in a manner where the team dynamic isn’t compromised.

One of the reasons I think these solutions are effective is because they lend themselves well to the team structure of popular development philosophies. For example, if a development team is using scrum, there are points in the development process where an IC and their team can convene with the rest of the team members, like the sprint review, and offer their opinion on the direction and feasibility of the changes desired by other members of the team. The sprint review also allows the ICs to communicate with shareholders and assess. Since there are multiple sprint reviews per project, this allows many chances for an IC to offer their opinion on the planning process.

I can definitely see where this information will be useful in my professional career, as development philosophies like scrum are commonly used, and the input of an IC in the planning process can be essential to delivering a well made product.

Link to source blog: https://increment.com/planning/individual-contributors-guide-to-roadmap-planning/

From the blog CS@Worcester – My first blog by Michael and used with permission of the author. All other rights reserved by the author.

 coding understandable program

For anyone who codes a  program, it is important to not just have a working program, but to have  a  program  that is   easy to understand, whether you publish your program onto github, or you want to  review  your program after finishing it. Clean code is a term that was first introduced by Robert Cecil Martin, also known as Uncle Bob. He wrote a book that gives best practices and tips for writing understandable and working code. 

When creating formulas for writing code, instead of including numbers in a formula, which could lead to confusion for  a number’s purpose in   a calculation. Creating   a variable that explains it’s purpose in a code makes calculation clear. Comments can explain the meaning of a statement in a  code,  and while comments can  attempt to clear up any confusion for anyone viewing code, it should not be used to explain a obvious statement, but to explain certain actions  in code. For constructing functions, it’s best to have a function perform one action, and if a function is very lengthy, a function should be broken down into multiple functions. 

When writing code with multiple nested if else conditions,  to  make a program easier to understand,  if else conditions should be split  into descriptive functions. As someone who has worked with different programming languages, I would want to use the practices of clean code, to write a working program that I can review and understand if i revisit my work.

What Is Clean Code? A Guide to Principles and Best Practices

From the blog CS@Worcester – jonathan's computer journey by Jonathan Mujjumbi and used with permission of the author. All other rights reserved by the author.

The Modern Standard for Collaboration: Version Control

Introduction

Version control is important for modern software development, enabling teams to collaborate effectively, manage changes, and maintain code quality. The blog post “Version Control Best Practices” by Tobias Günther offers 10 tips on how to use version control systems (VCS) like Git more efficiently.

Summary

The blog outlines essential best practices for working with version control systems, focusing on enhancing productivity and reducing errors. There were ten points but here are the top 5 most important in my opinion:

  1. Use Branches: Branches allow developers to isolate changes, experiment, and test without impacting the main codebase.
  2. Commit Often: Regularly committing small changes ensures incremental progress and simplifies debugging.
  3. Write Good Commit Messages: Clear, detailed commit messages help team members understand the context and purpose of changes.
  4. Go Beyond the Basics: Developers should invest time in learning advanced Git features like interactive rebases and cherry-picking to enhance their workflows.
  5. Don’t Commit Half-Done Work: Each commit should represent a complete, functional unit to maintain repository stability and clarity.

Why I Chose This Blog

I chose this blog because version control is a fundamental skill for software development, yet its nuances are often overlooked in coursework. While I’ve used Git for assignments, I realized that my approach lacked the deeper understanding laid out in this blog.

Reflection

There was a big emphasis on commits, which makes sense as commits are an integral part of version control and most of the tips talked about in the blog are practices that I do regularly, such as writing good commit messages. I don’t think it’s particularly hard to understand these standards for version control, and once you know them it’s just the norm to follow them.

Branching was something that I hadn’t known about prior to learning about it in class, but it makes sense to separate each new feature into its own area to work on instead of putting everything in main. This “tip” is really just a necessary way to stay organized and keep the repository and its pull requests in order.

Going beyond the basic features of git like committing and pushing is also a great tip, because although you could navigate git with only the basics, learning the more advanced features like rebasing can help greatly in certain situation where you’d be happy you know how to do it.

Future Application

There were some takeaways from this blog that I could incorporate into my own workflow. I think that I should commit more often than I do. I tend to forget to commit and only do so when I stop working but by then there could be a few features that are all crammed into one big commit. 

Citation

Version Control Best Practices by Tobias Günther

https://www.git-tower.com/blog/version-control-best-practices/#8-agree-on-a-workflow

From the blog CS@Worcester – The Science of Computation by Adam Jacher and used with permission of the author. All other rights reserved by the author.

How to review code effectively: A GitHub staff engineer’s philosophy

For my final blog post for the semester, I wanted to pick a topic that was different from project management, since I had already written about that a few times. Since our most recent topic in class revolved around GitHub and git commands, I wanted to explore a blog post that aligned with that topic. I came across a blogpost by GitHub staff engineer Sarah Vessels, from the github.blog page, about code review.

In this article, code reviewer Sarah Vessels discusses some practices to help improve code reviewing and make it more useful and efficient for everyone involved. She advises constantly checking your GitHub notifications inbox, anytime you have a spare moment. She also recommends using GitHub Slack Integration. Certain queries can help filter a slack group for finding outstanding pull requests that need review. We used Discord for our class instead of Slack, but as I understand it, Slack is more common in the professional world. I believe Discord has equivalent queries that can be used, anyway. The next piece of advice she gives is to use reviewer teams to manage notifications. While catch-all code owner teams can be okay as a fallback, it’s better to keep the number of code owner teams your own small, so that anything you get pinged for or anything that shows up in your inbox feels relevant to you, and not just something to ignore.

The next part she discusses, which I feel is the most important advice, revolves around giving good, constructive code review that doesn’t across as lazy. Good code review focuses on specifically saying,” I have a problem with this, maybe you should try xyz instead” instead of saying “I don’t like this” or “This won’t work” and leaving it at that. It’s good to ask questions, because the person who authored a pull request has more context for their changes, and gives them a space to explain and justify their reasonings. Personal preferences are fine, but approval should be about the overall integrity of the code. If the changes won’t break anything or affect production, leave the feedback with a comment but still approve the pull request anyway to keep the process moving. This is something I personally appreciate from the author, because while I don’t mind receiving feedback and improving my part of the process, I hate the feeling of holding back the overall process. This allows opportunities to open discussion without causing a holdup.

She has a few other suggestions in her blogpost, like being gracious and using draft pull requests, but I believe the most important things are her advice about the giving good feedback and managing notifications so you feel compelled to give every notification your full attention. I don’t know how much code I’ll be reviewing in the near future, but if I’m ever in this situation, on either side, this is good advice for me to keep in mind and remember.

Link: https://github.blog/developer-skills/github/how-to-review-code-effectively-a-github-staff-engineers-philosophy/

From the blog CS@Worcester – Site Title by Justin Lam and used with permission of the author. All other rights reserved by the author.

How to review code effectively: A GitHub staff engineer’s philosophy

For my final blog post for the semester, I wanted to pick a topic that was different from project management, since I had already written about that a few times. Since our most recent topic in class revolved around GitHub and git commands, I wanted to explore a blog post that aligned with that topic. I came across a blogpost by GitHub staff engineer Sarah Vessels, from the github.blog page, about code review.

In this article, code reviewer Sarah Vessels discusses some practices to help improve code reviewing and make it more useful and efficient for everyone involved. She advises constantly checking your GitHub notifications inbox, anytime you have a spare moment. She also recommends using GitHub Slack Integration. Certain queries can help filter a slack group for finding outstanding pull requests that need review. We used Discord for our class instead of Slack, but as I understand it, Slack is more common in the professional world. I believe Discord has equivalent queries that can be used, anyway. The next piece of advice she gives is to use reviewer teams to manage notifications. While catch-all code owner teams can be okay as a fallback, it’s better to keep the number of code owner teams your own small, so that anything you get pinged for or anything that shows up in your inbox feels relevant to you, and not just something to ignore.

The next part she discusses, which I feel is the most important advice, revolves around giving good, constructive code review that doesn’t across as lazy. Good code review focuses on specifically saying,” I have a problem with this, maybe you should try xyz instead” instead of saying “I don’t like this” or “This won’t work” and leaving it at that. It’s good to ask questions, because the person who authored a pull request has more context for their changes, and gives them a space to explain and justify their reasonings. Personal preferences are fine, but approval should be about the overall integrity of the code. If the changes won’t break anything or affect production, leave the feedback with a comment but still approve the pull request anyway to keep the process moving. This is something I personally appreciate from the author, because while I don’t mind receiving feedback and improving my part of the process, I hate the feeling of holding back the overall process. This allows opportunities to open discussion without causing a holdup.

She has a few other suggestions in her blogpost, like being gracious and using draft pull requests, but I believe the most important things are her advice about the giving good feedback and managing notifications so you feel compelled to give every notification your full attention. I don’t know how much code I’ll be reviewing in the near future, but if I’m ever in this situation, on either side, this is good advice for me to keep in mind and remember.

Link: https://github.blog/developer-skills/github/how-to-review-code-effectively-a-github-staff-engineers-philosophy/

From the blog CS@Worcester – Justin Lam’s Portfolio by CS@Worcester – Justin Lam’s Portfolio and used with permission of the author. All other rights reserved by the author.

scrum

Scrum is a framework that teams use to organize themselves in a project to reach a common goal. The values that members of a scrum team value are commitment, courage, focus, openness, respect. Scrum team is open to new ideas and opportunities, respecting each other, and have patience for the scrum process, and focusing on time-consumed tasks, and finding space for improvement. 

Scrum deliver a product for customer in a time period called a sprint. Product Backlog is the to-do list for a team which contains the requirements for a project. Product owner, which is one of the scrum roles, is responsible for maintaining and adding updates for the list, removing and adding new requests from customers. Sprint backlog is lists of items from the product backlog that is worked on during the current sprint. Increment is the end product of a sprint. 

The product owner guides the team on the next steps in the scrum process and ensures that the team understands the requirements that a business or client wants. The Scrum leader is responsible for making sure the scrum team works effectively. When working in a scrum team, there are different types of events that the scrum team is involved in.  Sprint planning is when teams estimate how much work needs to be done in a sprint. Daily Scrum is a short meeting where team members plan for the day, and provide updates on challenges experienced, and what work has been done. Sprint Review is the period at the end of the sprint, where the team reviews the work that has been completed, and presents it to stakeholders. Sprint Retrospective is when a team comes together to discuss the sprint result and make adjustments for future scrums. 

This semester in  CS 348, I had learned about scrum. With learning scrum, I was able to see how software team deliver products for clients. 

What is Scrum? – Scrum Methodology Explained – AWS

From the blog CS@Worcester – jonathan's computer journey by Jonathan Mujjumbi and used with permission of the author. All other rights reserved by the author.

Agile: What is it and why do some people not believe in it anymore?

This article is a beginning-to-end write up of the Agile methodology by Miriam Posner, an Assistant Professor at UCLA. She starts with a pov of someone watching an agile team in action, complete with all the user stories, story points, stand ups, a whiteboard, post-it notes, and sprints. For those who have not been introduced to this software development process, ‘stories’ are descriptions of features with ‘points’ showing the difficulty of implementing said features. ‘Stand ups’ are start-of-the-day meetings done standing up for quickness, the whiteboard is to organize each story point, represented by post-it notes, into the stages of ‘in-progress’, ‘done’, ‘backlog’, etc. ‘Sprints are just quick two week long work periods that help to break down the project into digestible chunks.

While this might seem rather much from to some people, others might have an opinion closer to Miriam, who found it to be efficient and intriguing. As such she researched the origins of Agile and learned the complicated history of managers and software developers. I will try to keep this summary brief while hitting all the major points.

Miriam starts with the buildup to Agile. It started in the 50’s and 60’s, most ‘experts’ said building the computer was the hard part and programming it would be trivial. The sheer enormity of their incorrectness led to a push in the field to adopt the name (and stricter processes) of engineering, leading to the coining of the term ‘software engineering’. The idea was that by following engineering techniques the experts would “transform the arcane and error-prone craft of computer programming to meet the highest standards of the engineering profession.” The next people to step in were the businesses who looked to hire these new ‘software engineers’. They created a framework of control where one person defines the project and breaks it up into steps, which are in turn handed to engineers to build and test before moving on to the next step. This was derogatorily called the “waterfall” method, so of course upper management took the name and method and ran with it. This method started to fail due again to people who were not programmers believing they knew what programming entailed. The main problem was that whenever any issue came up in the code, every step needed to be redone which meant the timeline would be increasingly muddled.

Next came Agile, created by “17 middle-aged white guys dressed in khakis and dad jeans” in the Agile Manifesto. In their words:
“We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.“

I would like to continue this dive but I am out of words.

Have a good day.

Link:
https://logicmag.io/clouds/agile-and-the-long-crisis-of-software/

From the blog CS@Worcester – Coder's First Steps by amoulton2 and used with permission of the author. All other rights reserved by the author.

What is Git?

A Beginner’s Guide to Git and Version Control

Git is a useful tool for software developers, yet its many features can be intimidating or confusing to beginners. This GitHub blog post “What is Git? Our Beginner’s Guide to Version Control” offers a clearer, more concise explanation of Git, its purpose, and what its practical applications are. This blog post is an excellent resource for anyone early on in their journey through software development, as the knowledge will be useful for years to come. I myself still needed some more practice with git commands, and benefited from reading the post.

Summary of the GitHub Post

The post explains important concepts such as what repositories, branches, commits, and merges are, and emphasizes how Git helps developers collaborate effectively on projects while maintaining a complete history of those changes.

The author discusses and defines many crucial Git commands like git init, git clone, git add, and git commit, breaking them down into much simpler, more easily understandable terms. Lastly, the post also discusses the importance of version control systems like Git and GitHub in preventing data loss, enhancing collaboration, and improving code quality overall.

Why I Chose This Post

I chose this post because Git is a critical tool in software development and is directly related to our current course material. As someone with limited experience with Git and GitHub, I often had to practice extra with its terminology and commands. Understanding Git is vital for success in our coursework, and future careers in software development, where collaborative coding is a big deal and a common occurrence.

Reflection

One takeaway from this post and course for me was the significance of version control in teamwork. The post reinforced the idea that Git is not just a tool for managing personal projects in the way that I have experience using it, but also a way to collaborate more effectively with others on software projects.

Upon learning all this about Git and GitHub, I planned to apply what I’d learned by setting up repositories for all my future projects, creating meaningful commit messages, and leveraging GitHub to store and maintain my history of works. Through that, I’ve been able to build up my own portfolio and showcase my works to others.

Conclusion

This blog post serves as an excellent starting point for anyone looking to begin learning Git, and to understand its role and uses in version control. Its practical approach and clear explanations make it accessible to complete beginners, while laying down the foundation for much more advanced concepts later on down the line. As I continue my journey in software development, I’m confident that the skills I’ve gained from this resource will be invaluable, and I do continue to use Git and GitHub very frequently.

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

Software Licenses

Hello everyone

For my last blog for the semester, the topic would be about Software Licenses and their importance in the computer science field. This was one of the most underrated things I learnt during the semester, so that’s why I wanna talk about it. Even though now it seems obvious, it never crossed my mind that I should always put a license on my project. This blog makes an amazing explanation on why you should always put a license on your work and also which one to choose from.

The blog begins by explaining the different types of software licenses, starting with:        Permissive Licenses – which impose minimal restrictions on what you can do like modification and distribution of it. Some of the most popular permissive licenses are the MIT and the Apache license. They are highly popular because they typically only require attribution, which is that you have to give credit to the original author.                                            Then the blog talks about:                                                                           Copyleft Licenses – anyone could modify and distribute the code, but they had to share their changes with the community under the same license. Some of the most popular Copyleft Licenses are the GNU Lesser General Public License (LGPL), which allow linking to open-source libraries with limited obligations but impose stricter requirements if the library is modified. There is also the GNU General Public License (GPL). They are a bit more restrictive, requiring that any derivative works be distributed under the same license and with access to the source code.                                                               

At the end of the blog, it addresses unlicensed code. Emphasizing that code without a clear license is not automatically free to use and may lead to copyright infringement. If the code does not have a license then it is considered to be under the default  copyright laws. This means that only the original author has the right to use, distribute or modify it. If someone was to happen to use it even if it is publicly available, it raises legal issues.          This blog to me was incredibly helpful and useful as it not only explained the various types of software licenses but also gave examples of them. It showed and highlighted the types of works and where would you wanna use these licenses and what works the best for you. One thing that I learnt while reading this blog was understanding what is an SBOM which stands for Software Bill of Materials. It is a detailed list of all the components in the code and their respective licenses. It is important to understand what licenses works the best for you so you can get the most out of it. The computer science field is an amazing work space that everyone can work together to build each other up and licenses help us do just that!

https://www.blackduck.com/blog/5-types-of-software-licenses-you-need-to-understand.html

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