Design patterns are extremely useful within software design. Essentially they are like established solutions to common problems within various contexts. We have learned a lot about design patterns this semester, especially creational, structural, and behavioral. Since we have talked about them and worked with them a lot, I thought it would be a good idea to write a post about what each is. A blog I found while researching more into the topic is called “Intro to Design Patterns” by Saverio Mazza. I think this blog does a great job at giving a brief overview of each of the three different design patterns and how they work. They are extremely helpful for anyone working in software design, and I feel like they will be used in any career I choose. I’m very grateful that I was able to learn more about these design patterns, and I hope my blog post will help you learn more too.

Creational Patterns: As it mentions in the name, creational patterns have to do with the way that objects are created. According to Mazza “They aim to abstract the instantiation process, making a system independent of how its objects are created, composed, and represented. Some examples of creational patterns include the singleton pattern, the factory method pattern, the abstract factory pattern, the builder pattern, and the prototype pattern.

Structural Patterns: These types of patterns deal with how classes and objects are composed in order to form larger structures. They make sure that when one part of a system changes, the rest of it doesn’t need to. Similarly, they make sure that parts of the system are decoupled and can improve the system’s flexibility and reusability. Some examples of structural patterns include the adapter pattern, the composite pattern, the proxy pattern, the flyweight pattern, the bridge pattern, and the decorator pattern.

Behavioral Patterns: Behavioral patterns deal with algorithms and the assignment of responsibilities between objects. They describe the patterns of communication between objects and classes as well as the patterns between them. They let you concentrate just on the way that the objects are interconnected. Some examples of behavioral patterns are the observer pattern, the strategy pattern, the command pattern, the state pattern, the visitor pattern, the mediator pattern, the memento pattern, and the template method pattern.

If you want to learn more about the specific patterns mentioned, I highly recommend checking out the linked blog for more information!

Link: https://medium.com/@saverio3107/intro-to-design-patterns-66f1aebe5be5

From the blog CS@Worcester – One pixel at a time by gizmo10203 and used with permission of the author. All other rights reserved by the author.

The blog post “Introduction to Dev Containers” on the Versent Tech Blog provides an insightful look into the benefits and use cases of Dev Containers in Visual Studio Code (VS Code). Dev Containers are an advanced feature that allows developers to define their development environment as a container. This ensures consistency across different environments and allows developers to collaborate without worrying about “it works on my machine” issues. In this blog post, the author explains how Dev Containers help in streamlining development workflows and how to set them up using VS Code.

The article starts by addressing a common pain point in software development: ensuring that the development environment is consistent across all team members. This is especially important in teams where developers use different operating systems or have varying configurations. By using Docker containers, VS Code’s Dev Containers allow teams to define a common development environment that can be replicated on any machine, avoiding discrepancies caused by mismatched dependencies or configurations.

The post explains how to configure a Dev Container in VS Code using a file called devcontainer.json, which specifies the operating system, programming languages, and dependencies required for the project. It also highlights how to use VS Code extensions within the container and how to work with the integrated terminal, which runs inside the containerized environment. The author emphasizes the simplicity of setting up Dev Containers, noting that once configured, developers can spin up the same environment across different machines with ease.

One of the key advantages of Dev Containers is that they provide a fully reproducible environment, which is a critical feature in team collaborations. Developers no longer need to manually install dependencies or worry about whether their local setup matches the production environment. Everything required for development is neatly packaged within the container. This aligns perfectly with the principles of modern DevOps and containerization, both of which have become integral to software development practices.

I chose this blog post because it directly relates to the topics we’ve been covering in our course, particularly around containerization and software environments. Our course has touched on tools like Docker and container management, and this article provided a clear, hands-on demonstration of how containers can be used in practice to simplify development workflows.

Reading this blog post gave me a deeper understanding of how Dev Containers can save time and prevent issues in team-based development. The ability to define and share development environments as code is powerful—it ensures that everyone on the team is using the same dependencies and settings. I also learned that by leveraging Dev Containers, teams can avoid the classic “works on my machine” problem, where a project may run fine on one developer’s computer but fail on another’s due to environmental differences.

In conclusion, the blog post “Introduction to Dev Containers” offers valuable insights into how Dev Containers can revolutionize the development process by providing consistency, portability, and ease of use. This tool is an excellent way for teams to improve collaboration and productivity. I look forward to implementing Dev Containers in my own development workflow.

Read the full blog post here.

From the blog SoftwareDiary by Oanh Nguyen and used with permission of the author. All other rights reserved by the author.

Hi class,

For this blog post I decided to choose the topic of team management. Team management. https://www.youtube.com/watch?v=BtBQdMWlpbQ. 

Anas Salman, who is a senior engineer manager at Uber, goes on to talk when meeting with a new engineer he will be very hands on with the said engineer in his career growth. When looking at growth for his engineers, Anas’ success is not if your engineer gets a promotion, but rather building skills and filling gaps in the engineers’ experience. Anas stresses a promotion is less important than doing great work, which a side effect would be a promotion.

Patrick acknowledges that people’s personalities and skills are different and vary, which as manager can sometimes be hard to find a good fit for the team. Anas agrees with this of which he has a baseline foundation of all incoming engineers/software developers. They must have a thorough understanding of the basics of coding.

Patrick begins the podcast by stating there can be a lot of processes set in place within team management, some of which can be tedious. Anas takes a different approach rather than looking at processes as simply that. As a manager, you must look at the processes and know three key aspects: to understand why it’s there, what’s the purpose, and the value. This will help your engineers not just do a process to do it, but understand it on a deeper level. 

Patrick states that as a manager, you need to have a motivated team, and sometimes it can be hard for engineers to find passion. Anas agrees with this. He says as a manager you need to align their passion with the needs of the team. This makes them more aware that this can lead to great growth in career and personal development. 

Patrick says the goal at the first meeting of the project all the way to the end of the project to his team and himself. By doing this, everyone on the team will be aligned with the shared goal. This will generate new motivation to start the project, coming up with new ideas and active discussions about how to reach the goal. 

My personal comments about this is that I like the way Anas thinks a lot about team management. If you’re in a team environment and you made a mistake and/or hit a challenge, he encourages this to happen, “Challenges are not usually bad things… I see them as gifts.” Anas says mistakes/challenges will be the accelerator for your career growth. Furthermore, he is showing his team that these are learning opportunities; I like that a lot and personally face challenges in and out of coding, by which adapting this mindset can only help me as an overall person and programmer, where simply doing will result in a greater outcome than seeking.

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

This week’s post will focus on the powerful backend tool, MongoDB and its data modeling features. MongoDB is a NoSQL database management system that’s mainly used to handle large datasets through a method called sharding. Sharding is a process that involves utilizing multiple servers to distribute data which improves scalability. This tool is especially flexible in various languages like C, C++, C#, Go, Java, Python, Ruby and Swift, making it applicable in numerous types of projects. Additionally, MongoDB is well-suited for use with Node.js, Express.js, and other modern web frameworks, making it an integral part of the MEAN and MERN stacks.

MongoDB is different from other backend data management tools because it uses NoSQL, instead of tables and rows of data it uses collections and documents of key-value pairs. These documents utilize Binary JSON or BSON because it accommodates more data types, making it versatile in any format. Gillis adds, “Documents will also incorporate a primary key as a unique identifier. A document’s structure is changed by adding or deleting new or existing fields”, which allows for fast indexing and queries.
Unlike traditional relational databases with fixed schemas, “MongoDB doesn’t require predefined schemas. It stores any type of data. This gives users the flexibility to create any number of fields in a document, making it easier to scale MongoDB databases compared to relational databases”. This one feature allows developers to not have to worry about changing schemas in the future due to changing product expectations.

According to Alexander Gillis from TechTarget, “Organizations also use MongoDB for its ad-hoc queries, indexing, load balancing, aggregation, server-side JavaScript execution and other features”. Uber uses MongoDB to optimize ride-hailing logistics, ensuring low latency even during peak traffic. Adobe uses it for handling billions of document transactions efficiently, ensuring user productivity on platforms like Adobe Creative Clouds.

When deciding to use MongoDB, it’s important to account for its shortcomings, for example, its non-relational nature can lead to duplicated data, which may require careful management. Additionally, it puts a lot of stress on memory resources. Another problem is its security, because user authentication is setup on default, hackers have learned to target un-secure MongoDB databases. Despite this, MongoDB is an example of how modern backend tools cater to the evolving needs of developers. Its flexibility and scalability make it a dependable tool when dealing with the unpredictable demands in software.

I specifically chose this topic to research because it will be crucial tool to have in my arsenal when working in full-stack projects. Additionally, this tool is the main backend tool for Thea’s Pantry, making this information vital for my capstone project. I hope to utilize this information next semester.

Blog: https://www.techtarget.com/searchdatamanagement/definition/MongoDB

From the blog CS@Worcester – Computer Science Through a Senior by Winston Luu and used with permission of the author. All other rights reserved by the author.

In this blog post, I will be talking about the various ways one can make their code reviews better. The blog that I am referencing is titled “How to Make Good Code Reviews Better” and is published on the Stack Overflow blog. The blog post outlines multiple strategies for people to improve their code reviews. These strategies include maintaining a respectful tone, offering specific and constructive feedback, and trying to focus specifically on high-impact areas. Furthermore, the importance of maintaining a balance between efficiency and thoroughness is highlighted in the blog, as balancing those two is very important if you want to ensure that reviews don’t become a barrier for your team during the development process.

I chose this blog because I thought that it would be a resourceful blog to read through, as these strategies can definitely help in the future for my professional career. This also relates to what we learned in class, as the blog heavily focuses on collaboration which can be tied back to our discussions about agile development.

This blog made me realize that code reviews should not be harsh critiques, but rather helpful conversations that provide insight on what should be improved in your code. It shouldn’t feel like a negative conversation, it should be supportive and friendly which creates a better working environment. For me, it also brings encouragement, as workers will feel more encouraged to improve upon their code if their coworkers are actively supporting them. Code reviews should be focused on the “what” and “how” rather than just listing all of the flaws of the code.

The blog also mentions how people should be reviewing for the future by providing insights that extend beyond the immediate fixes in order for the code to have better maintainability. The reviews should, of course, fix the immediate problems, but should also set up the program for better and for consistent success in the future. It should be focused on the sustainability of the code rather than just fixing all the short-term problems but not addressing how it will look in years. In general, every line of code that one writes should be written with the long-term impact of said code in mind.

Going forward, I am planning on applying these strategies of good code review in my professional career as well as my current academic career. If I am reviewing the code of a peer, I will aim to give constructive feedback that makes it feel encouraging rather than simply telling someone all the problems with their code. Doing this creates a better workplace environment where people feel comfortable with expressing their thoughts and opinions about things, creating a better team atmosphere and promoting teamwork and collaboration. I will also welcome feedback from peers about my work, as it is important to listen to the feedback of your peers, as in the end we are all working together towards a common goal.

Link: https://stackoverflow.blog/2019/09/30/how-to-make-good-code-reviews-better/

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

In software development, technical debt refers to the extra work required in the future when quick, easy solutions are chosen instead of more thorough, time-consuming approaches. This concept is explored in the article “What is Technical Debt & How Can Companies Manage It?” by Coder Academy.

The article defines technical debt as the accumulation of suboptimal code or design choices made to deliver projects faster. While these shortcuts may lead to quicker releases, they often result in higher maintenance costs and reduced code quality over time.

Key Factors Contributing to Technical Debt

• Time Constraints: Meeting tight deadlines can lead to hasty decisions that prioritize speed over quality.
• Evolving Requirements: As project requirements change, older code may no longer align with the current needs.
• Lack of Documentation: Poor documentation can create misunderstandings and increase errors, contributing to technical debt.

Strategies for Managing Technical Debt

The article suggests several ways to manage technical debt effectively:

• Regular Code Reviews: Consistently reviewing code helps identify and address suboptimal practices early.
• Refactoring: Improving existing code without changing its functionality can enhance readability and maintainability.
• Comprehensive Documentation: Thorough documentation supports better understanding and future modifications.
• Prioritization: Address technical debt based on its impact on the overall project’s progress and quality.

I chose this article because technical debt is a common issue in software development and is closely related to our course material. For Computer Science students, learning how to avoid technical debt is critical. If technical debt becomes a habit, it can lead to poor time management, less active learning, and weak decision-making skills. Understanding its causes and management strategies is essential for maintaining code quality and ensuring project success.

The article provided valuable insights into technical debt and its consequences. I learned that while quick fixes may save time initially, they often lead to higher maintenance efforts and system issues later. The importance of regular code reviews and refactoring stood out, as these practices can help reduce technical debt and improve code quality.

I also appreciated the visual diagrams and tables in the article, which made it easier to understand what technical debt is and how to manage it. I particularly liked the advice on avoiding technical debt and understanding its long-term impacts as a programmer.

By adopting the strategies outlined in the article, I aim to contribute to developing sustainable, high-quality software solutions. This knowledge will help me avoid accumulating technical debt in my future work. I am motivated to build new habits, such as maintaining good documentation, participating in regular code reviews, and prioritizing refactoring. These practices will help me become a more effective and skilled programmer.

Sources:
What is Technical Debt, and how can you manage it?

Citation:
Academy, Coder. “What Is Technical Debt, and How Can You Manage It?” Medium, Medium, 18 May 2016, medium.com/@coderacademy/what-is-technical-debt-how-can-companies-manage-it-1af08992f6d0. 

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

I just recently finished learning about git in a classroom setting, so every step from forking to cloning to branching and staging then committing into pushing ending with pulling. All the parts to get the gist of git, but nothing in the way of advanced use. Enter this article written by Gitlab.

As its title suggests, “15 Git tips to improve your workflow” has 15 total tips in regards to git, so lets go through some of them together.
1. Git aliases; amazing function, to think that rather than checkout, branch, or commit I could use a custom name. This is, in my opinion, great for new devs since once they grasp the concept of what a command does they can alias it to something that makes sense to them.
2. Visualizing repo status with git-prompt.sh; needs to be downloaded but definitely a useful tool for people like me who benefit from a more visual experience.
3. Command line commit comparisons; definitely more of a practical command that is helpful to see your workflow. Definitely going to be using this one to help me track what I actually worked on and might even download the Meld tool they mentioned.
4. Stashing commits; another practical command that makes sense just for a dev to know. If you have to push a sudden fix in the middle of adding a feature you can stash the changes made for the feature, commit the fix and then just pop the stash to get back all the previous work.
5. Pull frequently; nothing to add.
6. Auto-complete commands; tab to automatically finish a word is also applicable in search engine prompts as well. So useful for a new dev since if they forget the command but remember the first letter they can just flick through the commands until they find what they were looking for.
7. Set a global .gitignore; create a list of files to remove from commits and put it on the exclusion list, nice and simple.
8. Enable autosquash by default; had to look this up, apparently the squash command merges commits into one big commit. Personally not too sure of the use case so will have to test it out at a later date.
9. Delete branches locally that remote removed when fetching/pulling; as part of fetch, there is a prune attribute that will work this functionality and it just needs to be set to true.

Obviously there are 6 more tips and they are: Use Git blame more efficiently, Add an alias to check out merge requests locally, An alias of HEAD, Resetting files, The git-open plugin, and The git-extras plugin. I will not go over them here but definitely give the article a read if you are interested.

Link:
https://about.gitlab.com/blog/2020/04/07/15-git-tips-improve-workflow/

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.

Scrum is a widely-adopted framework in software development that is designed to encourage collaboration, smart time usage, adaptability, and transparency to deliver high-quality results to customers. The methodology centers around three roles: Scrum Master, Product Owner, and the Development Team.  Each role is critical to ensuring the scrum process is effective. Together, they uphold Scrum’s core values: commitment, focus, openness, respect, and courage.

The Roles in Scrum

1. Scrum Master:
   The Scrum Master serves as the facilitator and coach, ensuring that the team will follow the Scrum principles. They steer the team away from distractions, help remove obstacles along the way, and guide the team toward self-organization and improvement. Their role is not necessarily  about managing the team but empowering it to achieve its goals effectively.
2. Product Owner:
   The Product Owner is the voice of the customer, responsible for “maximizing” the product’s potential and value. They manage the product backlog, prioritize features based on the current sprint, and provide clear requirements to the team. They act as the bridge between stakeholders and the development team, ensuring that there is a complete alignment on goals and expectations.
3. Development Team:
   The development team consists of software development professionals who collaborate to deliver increments of the product during each sprint. They are self-organizing, meaning they decide how to accomplish their tasks without intervention from the Scrum aster or product owner. This is great for fostering ownership, accountability, and for delivering high-quality work.

The Values of Scrum

Scrum is mostly made up of  five key values that the team’s behavior and decision making:

• Commitment: Teams dedicate themselves to achieving sprint goals and delivering value.
• Focus: By working on a limited set of tasks at a time, teams maintain clarity and productivity.
• Openness: Transparent communication fosters trust and ensures that challenges are addressed collaboratively.
• Respect: Team members value each other’s contributions and expertise, creating a positive and supportive work environment.
• Courage: Teams take bold steps to innovate and tackle tough problems.

Why Scrum Matters

Scrum’s structured yet flexible approach enhances collaboration, reduces waste, and drives continuous improvement. By empowering teams to adapt to change and deliver incrementally, organizations can respond more effectively to customer needs and market shifts. Whether done in software development, marketing, or other fields, Scrum’s roles and values provide an amazing foundation for the success of a company.

Resource on Scrum Management

“What is Scrum in Project Management?” is an informative video about the Scrum methodology by the work management company Wrike.  This resource informatively explains all aspects of scrum, including but not limited to: goals, roles, practices, and examples.  It also explains the idea of a “sprint” which is the current goals of the development team that they must get done before the next sprint.  Check out the video for more information on Scrum Methodology.

Link: https://www.youtube.com/watch?v=M12HSYZkrgQ

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

One of the incredibly positive aspects of the software development community is the general spirit of collaboration. This is particularly true within the open source software community. Paired with the fact that anyone can maintain a project/portfolio on GitHub, there is a lot of code out there. I would argue that this is a good […]

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