I listened to the podcast episode “Comparing Git Workflows” from CodingBlocks, which relates git and workflow strategies. This podcast explores different ways that teams structure their Git workflows, what the trade offs are among them, and when one approach might be more suitable than another. They discuss many different workflows such as feature branching, Gitflow, centralized workflows, and many more. Taking into consideration on how these choices affect collaboration, history cleanliness, conflict resolution, etc. They compare simpler approaches that are easier for small teams with more structured models that are more strict for larger, distributed projects. They highlight how workflow decisions impact and affect team.

I chose to listen to this podcast because our course has just started to learn about git and how version control works in terms of commands like commit or branch. Learning about how workflows and team agreements integrate into real-world coding practices is likely going to be important and something we will work on in this course. “Comparing Git Workflows” gave me deeper insight into how different teams make those decisions and how those decisions can affect the teams workflow.

Listening to the episode taught me that no one plan is ideal for every situation. Before, I had assumed that there would be one best practice for all around coding, but hearing how workflow can change based on taken actions was eye opening. I also realized that simpler workflows might sacrifice structure or history clarity, but can offer agility, especially for smaller teams or solo developers. The discussion on this podcast helped clarify for me how preserving a linear history can help with finding bugs or reading logs, but also how tools can be misused if people rewrite shared history. Another takeaway was how important it is for teams to agree explicitly on their workflow, branching naming conventions, pull request practices, and many more key aspects. Hopefully I can apply what I learned in future team projects and potential jobs that are upcoming.

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

Hello, my name is Harley Philippe, and I’m currently enrolled in Software Constr, Des & Archit (CS-343) at Worcester State University.

From the blog CS@Worcester – Harley Philippe's Tech Journal by Harley Philippe and used with permission of the author. All other rights reserved by the author.

“How to create issues and pull requests in record time on GitHub” by Jon Peck is a blog discussing the importance of issues and pull request as well as how to efficiently use them. This blog goes on to explain how GitHub has improved the process of creating issues and pull requests, particularly with the help of GitHub Copilot. Instead of manually drafting titles, descriptions, labels and then writing separate pull requests, developers can use Copilot to assist with both issue creation and the process of turning those issues into draft pull requests. To start this blog reminds readers why well structured issues and pull requests are important. They provide shared information, enable online coordination, and many more important matters. It then explores the concepts of a good issue, including clear titles, explanations of expected versus actual behavior, reproduction steps or visual evidence, definitions of done, scope, constraints and useful data. From there the article shows how you can use Copilot Chat to speed up drafting issues. A developer can describe what is needed, include screenshots, and let Copilot suggest labels. Finally it demonstrates how to turn issues into draft pull requests by assigning them to a Copilot coding agent which can clone the repository, work in a secured workspace and produce commits in a draft pull request that remains open to continuous integration.

I chose this article because in our first pogil activity I didn’t have much experience using git and it’s available tools. Having read up on how version control tools are used not just for storing code but also for managing collaboration, code quality and workflow efficiencies. I learned that Issues and pull requests are surprisingly important to that process. This post shows explains this, It connects directly to what we have worked on in lectures, more specifically about assignment 1 about github, pull request reviews, issue tracking and practices in version control.

After reading this blog, the idea of version control to me is more than committing code or branching, it is about clear communication, traceability and making sure issues and pull requests are useful. I realized how much poorly constructed issues and pull requests slow down not only human reviewers but also automation tools. The idea of assigning a coding agent to issues via Copilot is interesting because it includes both human oversight while utilizing automation. In my future projects, I plan to apply these ideas by using formatting every issue in a useful way, making sure pull request descriptions link back to the issue and clearly explain what was done, and paying attention to data early so that project tracking and team collaboration become easier.

https://github.blog/developer-skills/github/how-to-create-issues-and-pull-requests-in-record-time-

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

Since UMass notified me that they were deactivating my old school email, I’ve transferred all my old blog stuff to this new, separate WordPress blog. This semester, my blogposts will be about software construction, design, and architecture.

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

This blog is all about my journey through CS-348 Software Process Management. Throughout the semester, I’ll be sharing my thoughts on what I’m learning, connecting class concepts to real-world examples, and exploring how effective process management can make software development a breeze. I’m excited to use this blog as a chance to practice clear communication … Read more

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

Hello everyone,

This blog has been created as part of my work in CS-343: Software Construction, Design, and Architecture at Worcester State University. Over the course of the semester, I will be sharing my reflections, insights, and experiences as I learn more about software engineering practices, design principles, and professional development.

The goal of this blog is not only to document my progress but also to connect what we learn in class to real-world applications in the field of computer science. I look forward to engaging with the wider community through my posts and learning from others in the course.

Stay tuned for upcoming posts on software architecture, design patterns, testing, and professional growth.

— Christian Oboh

From the blog CS@Worcester – Life of Chris by Christian Oboh and used with permission of the author. All other rights reserved by the author.

This blog dives into CS-343, exploring how to design, build, and maintain software that actually works in the real world. I’ll examine key software design principles, architectural patterns, and construction techniques that ensure programs are reliable, efficient, and maintainable. Along the way, I’ll analyze practical approaches to solving common challenges in software development, including debugging, testing, and refactoring, while exploring tools and technologies that support modern software construction.

Join me as I explore the art and science of turning ideas into usable programs. Through this blog, I’ll share insights on best practices, real-world applications, and strategies for creating software that meets both technical requirements and user needs. I’ll document my learning journey, reflect on lessons from hands-on projects, and track my growth as a Computer Science student as I deepen my understanding of software design, architecture, and engineering.

From the blog CS@Worcester – Insights from CS-343 by Yousef Hassan and used with permission of the author. All other rights reserved by the author.

Hi there!

This is my first blog post for CS343 for section two! I am excited to learn software construction techniques, design, and how to maintain a software. Hope to have a great class!

-Michael Clark

From the blog Mike's Byte-sized by mclark141cbd9e67b5 and used with permission of the author. All other rights reserved by the author.

In the Computer Science track at Worcester State, and as a prerequisite to this course, students have to take a Database Design course that teaches SQL. Because of this, before this course, when databases were mentioned, it typically invoked thoughts and memories of SQL queries and database management using the SQL language. However now, the project being made works with the use of MongoDB, a NoSQL database management system. This made me curious about the differences between managing databases with and without SQL and when it is smarter to use each.

I watched a video called, “Which is Better? SQL vs NoSQL”. The key point I took away is that SQL is a relational database whereas NoSQL, such as MongoDB, is a document database. The key differences being that relational databases store information in tables with keys whereas document databases store information in documents with JSON data. One main benefit of a document database such as MongoDB is that it is much easier to store unstructured data. This adds flexibility at the expense of being able to use simple commands such as JOIN which can be used in SQL. 

Another core advantage of NoSQL databases is that they can handle having multiple people connected to them at the same time. SQL databases on the other hand do not manage this well. This fact gave a lot of clarity as to the usefulness of using MongoDB over something like MySQL for the purposes of Thea’s Pantry.

The video also mentions that NoSQL databases are better at scaling across different servers which can be useful if we need to write information across multiple platforms and in many places.

Overall, from what I understand, SQL tends to be stronger for performing more in depth and informative queries on a set of data, at the expense of requiring the data to be organized and consistently formatted. NoSQL, on the other hand, does not have the inherent ability for users to submit queries on the data but it allows for lack of format and consistency and that leniency provides more flexibility for data storage. 

The ultimate conclusion was that both SQL and NoSQL databases are powerful in the hands of the right user. While they each have their strengths and weaknesses, they are similar enough to allow users to perform most of the same tasks on either one and that allows developers the freedom to choose the database that they are more comfortable using for the purposes of any project.

From the blog CS@Worcester – The Struggle of Being a Female Student in CS by Noam Horn and used with permission of the author. All other rights reserved by the author.