Category Archives: CS@Worcester

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.

Deep Dive: UML Diagrams

This week I’m again back at my favorite site, GeeksForGeeks. For everything I learned about in class, there’s always something GeeksForGeeks can teach me. Unified Modelling Language (UML) is just how it sounds, a language for modelling a system. It is a multi-faceted tool and in class we learned about class and sequence diagrams. What I was happy to learn however is that these two examples of UML can be separated into two categories, Structural UML Diagrams and Behavioral UML Diagrams.

Quick note: I will be summarizing this article as someone who knows what UML class and sequence diagrams are. If you do not know what these are then I would read the article yourself to get to the same starting point.

The article starts with a brief summary of what UML is before hopping into the categories of diagrams and plethora of examples of each. First up is Structural Diagrams and they include the class diagrams most people have seen, composite structure diagrams that show more detail for the individual parts, object diagrams which model how instantiated class objects interact with one another in the system, and component diagrams show how the physical pieces of a system are laid out. They are followed by the deployment diagrams visualizing all the pieces of hardware with their corresponding piece of software components and to wrap this category up we have the package diagrams to show us dependencies and internal composition of, you guessed it, our packages.

Next up is the Behavioral Diagrams, categorically separated into state machine diagrams that models a classes change over time or results from an external stimulus, activity diagrams which are reminiscent of flow charts in their depiction of the various states of a system, and use case diagrams showing the requirements for a system to properly interact with the users (known as external agents). Next up is the good old sequence diagrams, followed by communication diagrams which show similar information to sequence diagrams but in a more ‘free form’. This leads into timing diagrams that are again, similar to sequence diagram except now they are showing the constraints on time and duration. And finally we see interaction overview diagrams which are just a high-level overview of the interaction within the system.

After these types of UML diagrams Geeks For Geeks has a refresher for the OOP principles in UML that then rolls into some of the tools used to make these diagrams as well as the steps to make them, best practices, use case for these diagrams, how they fit into the Agile development mentality, some of the common challenges in regards to making UML diagrams and finally some of their myriad of benefits.

Almost needless to say, I now have a bookmark to this article and will be giving some of the listed tools a spin once I have the time. I expect this knowledge to help me in mentally visualizing a system so I can better address any problems that arise.

Link:
https://www.geeksforgeeks.org/unified-modeling-language-uml-introduction/#3-types-of-uml-diagrams

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.

GitHub adds Copilot

Just this week, GitHub announced that they will be offering a free version of Microsoft’s Copilot. I came across an article that discusses this breakthrough. In this article, GitHub CEO Thomas Dohmke gives his direct input on the situation. He has always believed in offering free resources for developers and believed that Copilot should also be an available resource. He later goes on to explain that this is because He believes that people all across the world should have access to the same tools that allow them to become developers, as the $10 a month that you would have to pay for Copilot normally is relatively more expensive in other regions. While this is great news for developers around the world, it will be a fairly limited version of Copilot. In this free version, developers will be allowed 2,000 code completion suggestions per month. This includes suggestions that are not accepted by the user.

I found this article particularly interesting because we have been using GitHub and its many features in my CS 348 class this semester. We’ve mostly been using GitHub for creating repositories and creating pull requests for larger repos. It is incredibly convenient and makes version control much easier. However, this new feature adds a lot to the software. Not only can you store your work in a repo and add work to other repos, but you can also get AI assistance for what you are working on.

I believe this is an important breakthrough for developers globally. Dohmke’s idea of creating equal opportunity for developers worldwide is amazing to me. Not only is the future in technology, but we currently live in a world where technology is everything. There are great minds all over that may have never gotten the right opportunity. Perhaps this addition can help someone create a life changing software. Outside of speculation, though, this will help thousands of developers, as GitHub now has over 350 million users. While it is a limited version of the product, it is a big step taken by GitHub. It is nice to know that I am getting into a field that people are willing to offer help and services for the betterment of the industry. As someone who is still young and learning new things daily, I hope to be able to take advantage of this. I believe it will help me, along with many others, to write good code while still learning.

URL: https://techcrunch.com/2024/12/18/github-launches-a-free-version-of-its-copilot/

From the blog CS@Worcester – Auger CS by Joseph Auger 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.

Computer Programming and My Future

Hello Debug Ducker here, and this one is going to be a lot less focus. As I near the end of my college fall semester, I come to realize that I am nearing completion of college, and will hopefully come out with a bachelors degree in Computer Science. With this in mind I did some reflecting about my choice in the field and how have my classes helped me.

For this semester, I did a CS course called Software Construction, Design and Architecture. To best describe it, its like applying the fundamentals of computer science, while understanding new techniques to build better software . I remember at the beginning we review some CS concepts such as Polymorphism, Abstraction Inheritance, and Encapsulation, and when studying it I was surprise to see I was still familiar with the subjects. Even funny that I recently applied for an internship with a company that had me do a test involving those subjects It made me feel more confident with my abilities. Also with the way the class was setup I was a lot more engage with the subjects.

I also learn some new things that involve CS such as UML class diagrams that basically meant to outline the program class structure. Here is an example that I did for class assignment

This was meant for some appointment application, I just did a diagram of it. I can see this being helpful in the field to help people understand what exactly going on with classes if they are new to a project.

I also learn about API work and I am not exactly clear on how it all works but I say I understood a little. I relearn the HTTP methods during that time, which I needed cause it has been a while since I had experience with them. Funny, that one of the HTTP method names is just GET, which just gets you information from a database. Anyway I hope to return trying API so I can get a better grasp on it.

That is a review on the class work but about my efforts. I say I did quite well despite some difficulties. Some unexpected hurdles came but I was able to jump over them to the other side and learn some new skill as a result. Though time waits for nobody and I may have missed some things but hopefully that could be mended.

Now that I am typing these I would like to use to blog for other purposes in the future but we’ll see. Have a nice a holiday and thank you for your time.

From the blog Debug Duck by debugducker 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.

The Singleton & Desing’s Patterns

12/19/2024

At the start of the semester, we were introduced to Design patterns. These techniques include anything from completely restarting a project to erasing redundancy such as repetition of code. Our biggest focus was to use overrides ONLY where needed and it was our job to figure that out because there were certain methods that did need to be overridden.

We worked on a Duck Simulator that has methods for each duck itself, but some ducks needed functions to be overridden were as some didn’t need them for example a decoy duck does not fly. Whereas a mallard duck does therefore there is no need to override a function for that decoy duck. This design pattern is very easy to overuse specially for people not introduced to these types of problems.

The interesting part of this homework was also using the previously covered topic of UML diagrams. This homework though was more about reading and understanding but the main point was to transfer it to Java code. This was a nice intertwining moment because it makes it easier in the future to understand not just the UML but also the design patterns taught.

We created two different interfaces for the Duck Simulator which one was a Quack() and the other was Fly(). These made it so we as the developer do not have to keep overriding. Hence, we end up with a bit more files, but it saves us the trouble in the future if we needed to edit let’s say the decoy duck to fly. Now we are able to go into one file and edit without having affected any other files. Which in larger systems can become a big issue because now the developer has to go into every single file that uses said method which waste time and can be missed if multiple people are working on it at the same time.

We also learned about the singleton method which just retrieves a single instance of an object and if it is not there then it creates it does not use multiple of the same object. There is one down side I read about in the source and it was about unit testing. The source talks about many unit testing frameworks that rely on inheritance when producing a mock object which is a problem because the singleton class is private, and static methods cannot be overridden. Overall, it is still applicable, and we used it in the intermediate part of the design patterns homework to learn how it worked better to always only have one instance of a method.

Source: Design Patterns in Java

From the blog CS@Worcester – Cinnamon Codes by CinnamonCodes and used with permission of the author. All other rights reserved by the author.

Management Pitfalls, How to Navigate Them

I recently read the article “Common SDLC Management Pitfalls (And How To Avoid Them)” published on Forbes.com. This insightful piece delves into prevalent challenges encountered during the Software Development Life Cycle (SDLC) and offers practical strategies to mitigate them.

I selected this article because, as someone striving to enhance my understanding of software process management, recognizing common pitfalls is crucial for effective project execution. The article’s focus on real-world issues and solutions provides valuable guidance for both current and future projects.

The article identifies several key pitfalls in SDLC management:

  • Unclear Requirements: It emphasizes that ambiguous or incomplete requirements can lead to project delays and cost overruns. The recommendation is to engage stakeholders early and ensure thorough documentation to establish a clear project scope.
  • Inadequate Communication: The piece highlights that poor communication among team members can result in misunderstandings and errors. Implementing regular meetings and utilizing collaborative tools are suggested to enhance information flow.
  • Lack of Proper Testing: The article points out that insufficient testing can cause defects to reach production, affecting product quality. It advocates for integrating comprehensive testing phases within the development process to identify and address issues early.

Reflecting on these insights, I recognize the importance of establishing clear requirements from the outset. In past projects, I’ve experienced setbacks due to vague objectives, leading to scope creep and resource strain. Moving forward, I plan to prioritize stakeholder engagement to define precise and attainable goals.

The emphasis on communication resonates with my experiences in team settings. I’ve observed that regular check-ins and transparent discussions significantly reduce misunderstandings and align team efforts. I intend to advocate for consistent communication channels in future collaborations to maintain project coherence.

The article’s focus on testing underscores a critical aspect of software development. Previously, I underestimated the value of early and thorough testing, which led to last-minute defect discoveries. I now understand that incorporating iterative testing phases can enhance product quality and reduce time-to-market.

In conclusion, this article has deepened my understanding of common SDLC pitfalls and reinforced the necessity of proactive management strategies. By applying these lessons—clarifying requirements, fostering open communication, and committing to rigorous testing—I aim to contribute to more efficient and successful software development projects in the future.

For those interested in exploring this topic further, I recommend reading the full article: Common SDLC Management Pitfalls (And How To Avoid Them).

From the blog CS@Worcester – Zacharys Computer Science Blog by Zachary Kimball and used with permission of the author. All other rights reserved by the author.