Category Archives: CS-348

Blog post 1

The first quarter of the semester has come to a close. In CM-348 we have gone through a number of Git and GitHub features. Learning about pushing and pulling data, as well as doing some data cleaning was a great learning opportunity. As I finish my last year of school, I am trying to look at these processes in an analytical sense because that’s what I want to do moving forward.

In my free time over the past few weeks I have watched a lot of Alex The Analyst videos on YouTube. He has provided free knowledge on what it takes to become a data analyst. From interviews, to Git, to data visualization he provides a lot on his channel for people who want to learn. This week I watched his “2 Hour Data Analyst Masterclass” video. In this video, Alex breaks down what a data analyst interview process looks like from start to finish. He discusses what kinds of technical questions to expect, the importance of storytelling with data, and how to demonstrate value through projects or case studies. He also covers common interview mistakes, like not being able to explain one’s own projects clearly or failing to connect technical skills to business outcomes. This video was very insightful, he showed his viewers what skills you really need to get into the field, and it personally showed me some things I might need to work on.

I chose this resource because it’s directly relevant to where I am in my career path, as well as in my learning. I’m starting to build my portfolio and think seriously about interviews and job readiness. Alex’s advice helped me see how important communication is in data roles, it is more than being technically skilled, also being able to explain how your work impacts decisions. This connects to CM-348 because version control, documentation, and communication are key parts of the Git workflow. I am doing a bit of projecting here, but I look forward to watching more of his videos.

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

Blog Post 1

https://github.blog/engineering/engineering-principles/how-we-use-github-to-be-more-productive-collaborative-and-secure/

Since we’ve been going over GitHub and how and why we use it in class, I decided to pick an article right from the source. In the blogpost How we use GitHub to be more productive, collaborative, and secure, Mike Hanley describes how the staff at GitHub use GitHub themselves as well as how they’ve made new additions with developers in mind. A neat thing I thought as developers themselves working on GitHub I’m sure they thought “wouldn’t it be nice if…” then realizing “oh wait we can just add that”. One of those features that the blog mentions is the “new code search and code view”, which allows for a more quick and easy way to sift through multiple lines of code.

Another point in the blog was about productivity and under that Codespaces. As we had used Codespaces during the GitKit Chapters, it felt well integrated, so I was pretty surprised to find out that it was something that they had only recently implemented and started using (they started using Codespaces in 2021 and the article was written in 2022). Based on the article, this allowed what once took 45 minutes on local hardware to 60 seconds on much faster hardware then most would have on hand. This alone struck me as a sort of equalizer, allowing for more inclusivity in the fact that you don’t need to spend a lot of money on hardware to be on the same “playing field” as other developers.

The last main point in the blog goes into GitHub’s stance on security, which I guess isn’t to surprising as Mike Hanley’s current role in GitHub as well as his previous role was being in charge of security. Anyways, too often is cybersecurity put on the backburner until an inevitable data breach occurs, then it’s all “we value our customers security and privacy” and “security is our number one priority”. Mr. Hanley also seems to see things the same way, as he mentions how they were “still pleading with organizations to implement multi-factor authentication…”, something I consider to be pretty bare-minimum in terms of keeping ones accounts safe. Due to this stance on security I was glad to see that GitHub actually enforces multi-factor authentication with security keys. Another method of keeping things secure is their use of CodeQL. According to the article, in the same open-source spirit that GitHub was founded with, CodeQL queries are also open-source where either GitHub or other developers can share vulnerability patterns. This allows for not just “one set of eyes” to pinpoint possible exploits but instead the entire community.

Reading this article has given me a better sense of how the tools and practices we’re learning now actually look in a professional environment. On top of that seeing GitHub’s own team use features like code search, Codespaces, and built-in security tools shows how even though it feels like we’re leagues apart we’re still on even footing.

From the blog CS@Worcester – CS Notes Blog by bluu1 and used with permission of the author. All other rights reserved by the author.

Why My Homework on Forking and Pull Requests is Actually Career Prep

For the past few weeks in my Software Process Management class, we’ve been deep in the Runestone GitKit modules. At first, it felt like we were just going through the motions: fork a repo, create a branch, make a commit, open a pull request. It was a bit mechanical. But once we got to the later modules on syncing with an upstream repository and dealing with merge conflicts, the bigger picture started to click. I realized I was learning a real-world workflow, not just homework exercises. To get a better understanding of why this process is so important, I spent time on the Atlassian “Source Code Management” tutorials. I wanted to see how the steps from our class connected to the way professional developers actually work.

The Atlassian resource was the perfect companion to our GitKit labs. It framed everything we were doing in terms of a “Forking Workflow,” which is massively used in open-source projects and many companies. It explained that forking isn’t just a step; it’s a collaboration model. It gives you your own server-side copy (your “origin”) to experiment freely without threatening the stability of the main project (the “upstream”). This directly clarified the purpose of the two remote repositories we set up in GitKit. The tutorials also gave a crystal-clear explanation of pull requests, describing them not just as a way to merge code, but as a formal mechanism for discussion, code review, and ensuring quality before changes are integrated.

This connection between class and the professional world was a huge lightbulb moment for me. In Module 3, we learned the mechanics of git branch, git push origin feature-branch, and creating a PR. Atlassian explained the why: this process isolates your work, keeps the main branch stable, and makes every change transparent and reviewable. The steps we practiced for syncing with upstream in Module 4—git fetch upstream and merging changes—are exactly how real developers keep their feature branches up-to-date and avoid nasty merge conflicts. Even the .gitignore file, which we learned about, is a professional standard for keeping junk files out of the shared codebase.

Understanding this workflow is no longer just about passing the class; it feels like essential career prep. When I look at internship job descriptions, “experience with Git and GitHub” is a given. Now I know that means more than just making commits. It means understanding how to collaborate using forks, branches, and pull requests. It means knowing how to resolve a merge conflict gracefully instead of panicking. The hands-on practice from GitKit, combined with the conceptual framework from the Atlassian tutorials, has given me the confidence to say I understand a standard professional development workflow. I’m not just memorizing commands for an exam; I’m building a foundational skill I’ll use every day in my future career.

Resource Link: Atlassian Git Tutorials – Source Code Management

From the blog CS@Worcester – DoaaTime by Doaa Mutar and used with permission of the author. All other rights reserved by the author.

Quarter 1 Blog Post for CS-348

My chosen article for this blog post is this article from the National Institutes of Health.
https://pmc.ncbi.nlm.nih.gov/articles/PMC4945047/

While at face value an article from the NIH might seem completely off topic from our class and what we’re learning currently, this article is actually all about Github. The article is centered around the Bioinformatics industry, and how a big problem with it has always been sorting, storing and accessing biological data and information credibly and easily. The introduction of the article gives a solid run down of what Github is and its relation to Git, while the meat of the article surrounds 10 “rules” to follow while using Github.

I chose this article for my first blog post of the semester because it seemed ironically fitting for the current topic of Git in our class for being an article published by the NIH. But I also chose it because it heavily relates to our sort of beginners guided usage of Git and Github that we’ve been doing. The rules given by the article all seem like really helpful guidelines for anyone new to Github like I am. I’ve always wanted to use it for personal projects and such but it’s always seemed like a daunting platform. Granted our class has torn down a large portion of the wall getting in my way from using Github personally but I do also really like these guidelines given by the article. For example, their rule 1, using Github to track your projects progress and changes make to the project, that taking advantage of its own system for doing so is a massive help from tracking progress on ones own, especially when working with a whole team of people on one project.

Out of all these rules though, I really do think rule 5 and 7 are the ones I reflect on most, I’ll admit I’m sometimes lazy and sometimes forgetful. Sometimes I do skip a test on a project. But that’s where I realize I can use that to my advantage with rule 5 of this article. It talks about using Github’s web hooks to test your code, find bugs and detect logic errors every time you push your code. Personally I don’t think it’s advantage I would pass up and don’t want to pass up in the future of using Github for class and myself.

As for rule 7, I know it seems silly but I don’t really like to discuss or bring up problems or issues I have with my projects that I’m working on. It’s always seemed like such a hassle, and whenever I did discuss the issues I’m having, its usually over discord to multiple people at once making responses to each person a mess of trying to keep up and take everything into consideration. So genuinely I do think the issues section of a project will become a very powerful tool for me. It didn’t really hit me in class because actively trying to use it as someone identifying and fixing problems for a project that wasn’t my own felt discouraging, not sure why, but I didn’t really think about from the project lead perspective. I do think a tab dedicated to finding, analyzing and fixing issues will be extremely helpful to me.

From the blog CS@Worcester – Splaine CS Blog by Brady Splaine and used with permission of the author. All other rights reserved by the author.

Beginners guide to Software Licensing

by Petraq Mele

Hello to all reading this blog today, the topic this time is software licensing and its importance in the development of software. I began researching about it as I had very limited knowledge about it and its importance. I ended up reading a blog written by an experienced developer named Rahul Awati titled “What is a software license?”, and I ended up learning quite a lot about the importance of this topic.

Various icons representing software licensing concepts and principles.

So what exactly is Software Licensing?

Practically speaking software licensing is a document that provides legally binding guidelines for the use and distribution of software. You can think of all software licenses as essentially a contract between the developer(s) and its user(s). It outlines the rights between these two parties for a piece of software along with the terms and conditions. All software comes with a license/product key which is important for identity & verification.

Its fairly simple to license software. Legally you already have, as the author of your software, a natural right recognized by copyright laws. If you want to add anything else to a license many developers but it in a text file within their software packages. Some sources like choosealicense.com or www.gnu.org are useful for finding templates or examples.

Some things that you may find included in a license are:
– Basic information(Names, Contacts, Address)
– Charges
– Duration
– Distribution rules
– Terms of service/cancellation
– Governing law
– Maintenance
– Etc.

Types of software licenses:

A visual representation of the 5 approaches to software licensing, ranging from public domain to proprietary licenses.

A few software licenses include:
– Free and open source(FOSS): Allow anyone to use software, and even to study, change or copy its source code.
– Proprietary: Often referred to as “closed source”, this software has strict rules towards obtainability & alterations.
– Public domain: Like open source but should be cautiously used by businesses as it might not meet their expectations.
– Lesser general public: Developers can link to open source libraries within their software and use any licensing type for the code.
– Permissive: Allows users to modify & distribute a piece of open source software but with some requirements for them as well as preservation of license notices, copyrights, or trademarks.
– Copyleft: Open source as long as they make the modifications freely available. New products containing old code with a copyleft license must comply with the restrictions laid out in the old code’s license.

Why do we need licenses?

Licenses are important because of all the reasons we have outlined earlier. It helps protect both the developer & the user.

A few beneficial protections for developers include: Protection of intellectual property, ensuring control over their creation, limiting liability, & monetization of products.

As for the users, the benefits are: Prevents misuse/unintentional mistakes causing damage, protect from infringement claims/ liability, create positive relationship with other developers/users/vendors, & establish clear parameters of how many licenses an organization needs.

Based on these few protections you can see the importance of licensing. It keeps a professional structure towards the spread of software and encourages a just environment.

Final thoughts

Understanding software licensing is something each software developer should take the time to learn whether for their own personal gains, or as a way to safely use/produce software. Aside from the legal aspect of it, licensing is about respecting a developer and their work. As I mentioned earlier I want to give credit to Rahuls’ amazing blog as inspiration for mine. Be sure to read his blog if you want more insight on this topic.

From the blog Petraq Mele blog posts by Petraq Mele and used with permission of the author. All other rights reserved by the author.

Blog Post for Quarter 1

October 5th, 2025

Recently, I’ve been working on using Git. This came in the form of using a little bit of GitHub, a little bit of GitLab, and the textbook made to help instruct me on how to use them. I began to learn the basics of repositories, and how to make edits and pull requests.

For example, I am now able to create a fork from a repository, create a remote origin, a clone of that onto my local device, make edits using Visual Studio Code, stage those edits, commit those edits, push those edits back to my remote origin, then establish a pull request. And a little bit more. So far, this Quarter of my class has been pretty interesting. I will note how the public changes and such are very interesting to me. I don’t usually like being in public places often because I assume I should be competent before doing anything in public, but oh well.

For the blog post I selected, I wanted to know just a smidge more about Git, since I was learning about it. (This will be linked below at the bottom of this post.) It mostly discusses the future plans for Git and potential for AI.

Honestly, there isn’t much for me to really do from this. I just note how AI appears to be Git stuff I currently use, so that’s mildly interesting. Though, I found it interesting that Git, much like I, is currently developing. It’s fun to think about how I learn and improve as a person that other things in the world are doing the same. While they are wildly different contexts, I find it cool. Everything is always changing and such. Even as I learn, I make notes that aren’t in the textbook to myself. Git will probably always get things added by various different people as well.

It encourages and intimidates me in some way. It’s very cool that by the time I “get caught up” it’ll be better than what I’m currently using, but at the same time, what if everything I learned becomes redundant? Though, for me, I was always a person to enjoy experiences, and I never really liked the idea of a limit. If anything, it is just more “fun” for me. There’s more to learn and I’ll never be caught up. My experiences will lead to my growth, so when the time comes, I’ll be much more suited to using the new tools that arrive.

https://github.blog/open-source/whats-next-for-git-20-years-in-the-community-is-still-pushing-forward/

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

Reflection on “Coding Standards and Guidelines”

by: Queenstar Kyere Gyamfi

The GeeksforGeeks article “Coding Standards and Guidelines” highlights the importance of writing code that is clean and consistent. It also underlines the need for code that is easy to understand. It explains that coding standards are a set of rules and conventions that help developers maintain clarity and quality across a project. These standards cover areas such as naming conventions, indentation, code structure, comments, and documentation. The article emphasizes that following standards is not about limiting creativity. It is about making sure that everyone working on a project can easily read and maintain the code. It also points out that coding guidelines help prevent errors. They make debugging easier. They ensure that software projects remain manageable as they grow.

I chose this resource because I’ve noticed how quickly group projects can become messy. Each person having a different coding style contributes to this messiness. I’ve always cared about writing code that works. I’ve started realizing that how the code looks and reads is just as important. This is especially true in team environments. This article stood out to me because it clearly explained the purpose behind coding standards.

One key lesson I learned from this article is that consistency builds trust among developers. When everyone follows the same structure, it becomes easier to understand, review, and modify code written by others. The article also reinforced the idea that good code should be self-explanatory. For example, meaningful variable names like totalPrice or userCount communicate intent better than short, unclear ones like x or val. I also learned how proper indentation and spacing make code more readable and reduce the risk of logic errors that come from misaligned statements or missing braces.

Reading this resource made me reflect on my own coding habits. Sometimes, when I’m rushing to finish an assignment, I skip comments or mix naming styles without thinking about how confusing it might be later. Now, I see that writing clean code is an investment as it saves time when debugging and helps others understand what I meant. I also want to use tools like linters and formatters to automatically enforce standards in my projects.

Overall, this article helped me understand that coding standards are not about perfection but they are about communication. Clean, organized code reflects professionalism and respect for the next person who will read it. It reminded me that in software process management, technical skills and teamwork go hand in hand. Writing code that others can easily follow is one of the best ways to contribute to a project’s long-term success.

LINK TO RESOURCE:

https://www.geeksforgeeks.org/software-engineering/coding-standards-and-guidelines/

From the blog CS@Worcester – Circuit Star | Tech & Business Insights by Queenstar Kyere Gyamfi and used with permission of the author. All other rights reserved by the author.

What the “Grug Brained Developer” Teaches Us About Software Process Managment

Link: The Grug Brained Developer

For my self-directed professional development blog, I chose to read The Grug Brained Developer by Carson Gross, who founded the Hypermedia Research Group at Montana State. On the website, a free, digital version of his book, Gross manages to distill complex software wisdom into simple, almost primitive advice. Written like a caveman developer, it explores core ideas and fundamentals of coding and communication in a way that’s both funny and accurate.

The article’s central theme is simplicity. Grug constantly emphasizes avoiding unnecessary complexity in both design and process. He warns against over-engineering, over-abstracting, and blindly following trends—ideas that directly connect to what we’ve discussed in CS-348 about software process management principles like iterative improvement, communication, and agile adaptability. In short, Grug argues that most of software development isn’t about doing more, but about doing less and doing it better.

I selected this resource because it presents timeless software management lessons through a format that’s approachable and memorable. Rather than reading another dry technical essay on process maturity or workflow optimization, this post made me think deeply about how simplicity affects process management. In a course where we analyze methodologies like Scrum and Kanban, it’s easy to lose sight of the human side of software development—how teams actually think, communicate, and make decisions. The Grug Brain post brings that perspective back.

What stood out to me most was the section where Grug says, “If no can understand code, no one can fix. Then bug live forever.” This humorous line perfectly encapsulates why clear process and communication are essential to good software engineering. It aligns with our course’s emphasis on maintainability and collaboration. A well-defined process isn’t just bureaucracy—it’s what ensures that projects remain sustainable when team members change or systems evolve.

I also learned how simplicity ties into continuous improvement. In agile environments, each sprint is a chance to refine not just code, but the process itself. Grug’s idea that “small simple thing better than big clever thing” echoes this perfectly: effective software process management focuses on clarity, iteration, and team alignment over cleverness or premature optimization.

Reflecting on this, I realized that I often over complicate my own projects—whether by designing too many abstractions or worrying too much about tools instead of workflow. Going forward, I plan to apply Grug’s philosophy by prioritizing clarity in both my code and my project management habits. That means writing simpler documentation, refining processes only when necessary, and valuing human understanding above technical elegance.

In summary, The Grug Brained Developer provides a surprisingly profound take on process management: simplicity and communication are the real foundations of sustainable software development. I’ll carry this mindset into my future work, reminding myself that even in a world of complex methodologies, sometimes the best process is the simplest one.

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

VCS Safety Net: Protecting Code and Empowering Collaboration

For this quarter’s blog post, I chose to deepen my understanding of Version Control systems (VCS), specifically how tools like Git and platforms like GitHub and GitLab function within the software development lifecycle. Learning new tools and techniques takes continued practice, and learning Git was no different. My goal with this content is to strengthen my knowledge of the core concepts and purpose behind these vital tools, which is what my Software Process Management course is currently emphasizing working with and practicing.

I focused on a website from GitHub itself, which explained what version control is. I chose this resource because it provides a foundational explanation of VCS, its types, and current popular tools. This article, “What is Version Control?”, defines VCS as systems that give members working on the same project complete visibility into the history of the code, and centralize all members’ work. It describes how Distributed Version Control Systems (DVCS), like Git, are essential for software development. It explains key concepts including the ability to track every change, work independently, propose code additions, and safely integrate changes while preventing conflicts. In other words, the process of commits, branching, pull requests, and merging; all fundamental processes we are focusing on in my course.

Before this course, and diving into resources, my understanding of Git was minimal. I gained a much deeper grasp of how VCS tools are both seen as a safety net and a coordination tool. Branching is one of the most important steps within the software development process, as it allows a team (of however many or little) to work synchronously on a project without fear of overwriting or corrupting the main code. Allowing team members to work independently, cohesively, and in a time-efficient manner; while also being able to access and review modifications made by other members via accessing their branch of the project. 

Although all of the information is important, the section on best practices particularly resonated with me. While working with Git, we are encouraged to save changes in small increments, making sure to write a helpful commit message, rather than making large changes and saving at the end. Seeing this best practice emphasized in the article reinforced its importance. Using this technique significantly reduces conflicts and makes debugging errors and explaining changes much simpler. 

I expect that I will continue using Git throughout my professional career, and I plan to apply this understanding immediately as I continue working with Git in class. My goal is to use this knowledge and helpful techniques to practice improving my execution and workflow. I will prioritize working in small increments, committing those small changes, and reviewing my changes to ensure my progress is meeting expectations and to also contribute to the team’s collaboration.

Link to Main Resource:
– https://github.com/resources/articles/software-development/what-is-version-control – What is Version Control?

Link to Additional Resources:
– https://www.cbh.com/insights/articles/collaboration-tools-changing-the-workplace-landscape/ – Collaboration Tools Changing the Landscape of the Workplace

– https://www.planview.com/resources/articles/software-development-collaboration-tools-a-detailed-buyers-guide/ – Software Development Collaboration Tools: A Buyer’s Guide for Empowering Agile Teams

– https://fullscale.io/blog/benefits-collaborative-software-development/ – The Benefits of Collaborative Software Development

– https://www.geeksforgeeks.org/git/version-control-systems/# – Version Control Systems

– https://www.geeksforgeeks.org/git/what-is-git/ – What is Git?

– https://github.com/resources/articles/software-development/what-is-software-development – What is Software Development?

From the blog CS@Worcester – Vision Create Innovate by Elizabeth Baker and used with permission of the author. All other rights reserved by the author.

Understanding Project Management

The blog post by David Hartshorne begins with covering the basics of what project management is. Project management covers the overall facets of how to meet and achieve the deadlines of a project such as setting goals, meetings, and communicating and collaborating the the stakeholders/customers. This is all done in order to insure that tasks are completed in an efficient and timely manner to avoid mistakes or possible challenges from popping up. The blog then moves into have many different types of companies from software to construction as examples that use project management. The main types of projects are,

Predictive: Follow a linear timeline between phases

Adaptive: Short periods of work with frequent check-ins and feedback

Hybrid: A blend of the two

There are also five main phases to the process of a project which are,

Initiating: Laying the foundation of the project including understanding the project scope, main overview and budget

Planning: Define members roles, goals, time tables, and needed resources

Executing: The start of the project, institute changes and suggestions as needed

Monitoring: Check-ins and consistent communication, keep and eye on the goals and overall task at hand

Closing: Deliver the project, Conduct overview on the project on what went good and bad and where to improve

I chose this blog post due to its depth on the topic of what project management is. The blog focuses on the overall scope of the project and all of the possible avenues that need to be considered from tools to aid the process, team members and their roles, phases, tips, and the main areas of management. I also was attracted to this topic due to its application to industry as having a key understanding of project management is needed when either running a project or being the best team member that you can be. Having read the blog, there has been a fundamental shift in how I view projects and my role in them and my other team members. The need to constant communication has only been further reinforced as the backbone of a solid project. Clear defining of roles and goals is also needed to ensure that everyone knows what they need to do. With goals, something that also stuck with me is to keep the prioritization of the goals that need to be completed all within a realistic scope. This stuck out to me as I often feel like and find that scope creep can quickly seep into projects and teams and take hold. I have also begun looking into and pursing how to apply the suggested team-based tools like roadmaps and time management software to help keep me on task and use on future projects such as some of the suggested software like “Waterfall” and “Agile”. This blog was an excellent source on information on the management process and I encourage everyone to read it for themselves.

Works Cited

Hartshorne, David. “A Guide to Project Management.” Monday.com Blog, 20 Dec. 2020, monday.com/blog/project-management/guide-to-project-management/

From the blog CS@Worcester – Dan's Blog by Daniel Fung-A-Fat and used with permission of the author. All other rights reserved by the author.