Category Archives: CS-348

Using Github Codespaces in Class

Github in the classroom

While I have used github before in previous projects, this semester I have begun to dig deeper into it’s uses. Codespaces is one such use, and is an important tool to learn and use properly. While we have gone over github codespaces and git command line use in class, sometimes looking around online can help streamline the experience. Github themselves post their own blogs relating to their site’s recourses, and codespaces is no exception.

10 things you didn’t know you could do with GitHub Codespaces

This github blog details all of the various uses of their codespaces, and offers good suggestions, background, and description of both what it is, and why you should be using it. Mostly, this blog details the features that are both useful but not often utilized, as well as details why these features are helpful tools.

I chose to talk about this blog post (with my blog post, haha) because this is a tool that I personally have used, but didn’t really know too much about. I was told to use it in class for x y and z, but never really thought about how valuable it actually is. I only have experience with VS code and other Microsoft IDEs, but it’s cool to know that codespaces supports much more than just that one IDE. as well as this, I think it is extremely convenient to have access to a workspace without setting up everything locally, and am excited to try to learn how it better utilize this feature, as I realized that this feature has directly impacted my class experience; The professor only needed to give us a repository, and we were ready to work on our assignment, with no setup or install hassle!

Another feature of that I am now excited to try is live sharing. Live sharing allows you and other people to work in the same code file at the same time, similar to having multiple people in one google doc. It even shows where their cursor is and everything! I think this feature could significantly improve the group project experience, as previous years I’ve been frustrated with how annoying it is to work on the same code together with my group.

Lastly, codespaces allows you to easily manage all of your working areas, and makes file management easier to, well, manage! In my previous classes, I’ve found the most difficulty in the storage and file layout of my projects, which impacts how/if it runs at all on my local device. Being able to manage this and keep everything more separated with codespaces should, in my opinion, help with these troubles.

This concludes my mandatory blog post of Quarter 1 for the semester.

Till the next one,

— Will Crosby

From the blog CS@Worcester – ELITE Computer Science by William Crosby and used with permission of the author. All other rights reserved by the author.

Blog 1 – How to manage and improve software processing.

Improving your software processing is crucial, especially when working on a group project, managing time pressure, and leading a team, among other responsibilities. Here is a great resource that I found invaluable for beginners and interns. “https://axify.io/blog/software-process-improvement“

According to Pierre Gilbert, a software delivery expert, he highlighted the “7 steps” to implement software process improvement, or SPI. I will break down those steps to get a better understanding.

Step 1: Make the problem visible – Use historical data to show where delays, defects, process inefficiencies are happening

Step 2: Get the Team’s Buy in – Don’t just impose changes. Use data to show why improvements are needed so your team member see the value.

Step 3: Track essential metrics – Use DORA metrics + value stream mapping to find bottlenecks

However, this step still gets me confusing, so feel free to checkout the link to have a better understanding.

Step 4: See where improvements would be most effective – Prioritize high-impact areas rather than trying to change everything at once.

Step 5: Make a plan – Clear responsibilities; tools; define which existing processes are targeted; pilot projects before roll-out; ensure feedback loops.

Step 6: Implement the plan – Execute carefully; monitor; allow for adjustment; don’t force changes that slow things down without justification; use continuous feedback.

Step 7: Adjust as needed – SPI is never “done” – measure progress via KPIs, adapt if cultural or resource issues arise, keep refining.

After reading those steps, I can’t imagine the environment of software engineering is not as simple as I thought. Understanding the steps could help me preparing of what’s coming next.

Before improving SPI, we need to understand the common challenges people usually face when it comes to working on project.

Time pressure – in high-pressure environments, it’s easy to prioritize delivery over process improvement.

Poor management or lack of ownership – improvements can be fragmented without clear responsibility

Team maturity – less mature teams may struggle with discipline & consistent adoption.

Overall, reading this could help you get ahead of what’s upcoming in the software engineering environment. For further information, check out the link above.

#CS-348, #SPI

From the blog CS@Worcester – Nguyen Technique by Nguyen Vuong and used with permission of the author. All other rights reserved by the author.

Understanding GitHub

Quarter One Blog

The video I watched is a basic tutorial for GitHub. Corbin, the creator, explains that GitHub is essential for version control and organization, and how important it is when your code becomes more complex. He starts off by explaining what a repository is and how to make one in GitHub. Then, he shows one of his repositories for a project with a working program. He says if he wants to start making changes and adding to the code, he would create a branch to prevent the code from breaking and save a lot of time if he needed to backtrack and fix it. He shows how to make a branch, as well. He provides the basics for what we went over in class and in GitKit chapters and explains how to do it in a slightly different way than what was said in class. I chose this video because I find it useful when I have multiple ways to explain a topic and I can understand it better.

The process for creating a repository is not something that we went in depth on in class, so having Corbin explain how to go through that process was helpful. He touches on what the difference between public and private repositories are. In class and in FOSS applications, they would all be public repositories, but if you were just using GitHub to put your private code in the cloud and for your own version control, a private repository would be more useful.

Corbin provides a visual and explanation for what branches and forks do, but it is not as clear as what was shown in class. Having the different explanations of both is helpful for a deeper understanding. He goes over having a completed branch, how to merge it back to main, and explains what the version control deletions and additions look like. 

Outside of the Software Process Management class, understanding GitHub is super useful in the real world. Other classes, like the Software Development Capstone, will require the understanding of GitHub to complete the final project. A lot of companies use Git for version control and collaboration, and look for those skills on applicants’ resumes. I feel confident and comfortable that I can navigate and use GitHub in my life going forward. 

Last year, I took Software Testing before understanding Git. While I was able to figure it out and get through the class, having the knowledge I do now with the actual process and reasonings of it, I feel like I would’ve spent less time troubleshooting silly issues.

From the blog CS@Worcester – ALIDA NORDQUIST by alidanordquist and used with permission of the author. All other rights reserved by the author.

Understanding Git Collaboration: Communities, Upstreaming, and Merge Conflicts

Hello everyone! Welcome back to my blog posts. Today I would be delivering my first Quarter blog post.

For this week’s blog, I decided to read “Git Forks and Upstreams: How-to and a cool tip” from Atlassian Git Tutorials. I picked this article because it connects directly with what we’ve been practicing in class—working locally, pushing changes upstream, staying synchronized, and handling merge conflicts. I also wanted a guide that explained the actual Git commands rather than just high-level concepts, since I’ve been moving away from relying only on graphical interfaces.

Summary of the Resource

The article explains the difference between origin (your fork) and upstream (the original repository you forked from). It walks through how to set up your fork so you can keep it synchronized with the upstream repo, which is especially important when multiple people are contributing. Commands like git remote add upstream <url>, git fetch upstream, and git merge upstream/main are introduced step by step. The tutorial also shares a useful tip for checking how many commits your branch is ahead or behind the upstream, which makes it easier to stay in sync.

Why I Chose This Resource

I chose this article because it fills a gap in my own Git knowledge. Until recently, I mainly used the graphical interface on the side to commit, push, and sync my changes. That worked for basic assignments, but I often felt like I didn’t really understand what was happening behind the scenes. This tutorial helped me connect the dots by showing me the exact commands and explaining why they matter, especially in collaborative projects.

Reflection and Takeaways

This resource helped me see Git as more than just a tool for saving code. it’s really about teamwork. Understanding how to add and pull from upstream makes me feel much more prepared to collaborate on group projects or open-source contributions. I no longer see merge conflicts as something to fear, but as a natural part of multiple people working on the same code.

One big realization for me was how important it is to stay synchronized with upstream. In one project I did before, I once ignored updates for too long, and the merge that followed was messy and stressful. Now I understand that frequent git fetch upstream and git merge calls prevent bigger problems down the road.

Another personal shift was moving away from the GUI. While the interface made Git feel easier at first, I see now that the terminal gives me more power and clarity. Running git status, git log, or checking how far ahead/behind my branch is compared to upstream makes me feel more in control. It’s like going from driving an automatic car to learning manual, I finally understand how things actually work under the hood.

Looking ahead, I know these lessons will help me not only in this class but also in internships and my future career. Whether I’m working on an open-source project or contributing to a company’s codebase, being comfortable with upstream workflows and conflict resolution will make me a stronger and more reliable teammate.

Citation / Link

From the blog CS@Worcester – Rick’s Software Journal by RickDjouwe1 and used with permission of the author. All other rights reserved by the author.

Understanding Git: The Key to Safe Team Collaboration

In class we are learning about Git. Git is a version control system that allows multiple developers to make changes to a program and still control the commits if needed. The reason why I think this is because there will be times where developers make a mistake and cause a whole list of issues but with git they can go back to the previous commit and fix it there. This allows developers to be able to work on major projects without causing the main program to break. 

Another important aspect we need to consider is that it allows larger teams to be able to work on the same program at once. Which can save the company time and money. We also need to consider how developers from all over the world could help with open source projects without working on a fork of the repository so that they can make changes locally and not impact the upstream of the project. 

In my perspective git divides upstream, clone, local, online repo, branch so developers are able to make these changes safely and there can be people to double check their work. That is what organizations can have reviewers and maintainers trying to review changes so that the upstream does not break. In addition, it allows developers to be able to know when changes are made and what type of scale a change it is. When a company’s upstream goes down it can cause the company to lose a lot of money and reputation with clients and the public. 

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

First Blog Post!

This is my Blog for my Software Process Management course, and I’m really excited to learn more and grow through my writing. As I embark on this educational journey, I aim to explore various methodologies and practices within software development, delving into topics such as version control tools, Coding Standards, and Software Maintenance. By sharing my insights, reflections, and project experiences, I hope to not only reinforce my understanding but also connect with others who share a passion for improving software processes. Through this platform, I aim to foster discussions that encourage collaboration, innovative thinking, and a deeper appreciation for the intricacies of software management.

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

CS Introduction

My name is Seth Boudreau and I am a computer science student attending Worcester State University. I am going into my fourth year now as a student here and I am mainly making this blog to go along with my studies. Most of the information that I will type here will be for my two courses this semester: CS-343 and CS-348 and topics will vary based on information within the two courses.

From the blog CS@Worcester – Works for Me by Seth Boudreau and used with permission of the author. All other rights reserved by the author.

CS-348

This is my CS-348 blog.

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.

Intro

Hello, I’m William Do! This is for CS-348.

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

The Journey Begins

Hello! Welcome to my blog. My name is Elizabeth Baker, and this is my introduction post for two Computer Science courses at Worcester State University: Software Construction, Design, and Architecture and Software Process Management.

Later blogs will focus on taking course material and connecting them to various resources in class and on the world wide web, to build my understanding, confidence, and resourcefulness as a developing engineer. Here’s to endless knowledge and professional growth!

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.