Category Archives: Week 8

Another Look Through Someone Else’s Code

On my last post I looked through an independent developer’s code. It is messy so I applied clean code principles to it. Unfortunately, I only made a few fixes. There was a lot to say. Now, let us take a second dive into the rocky waters known as this developer’s code

Just to note, I will continue to use an uploaded replication of his code from GitHub:GitHub – LordEnma/YandereSimulatorDecompiled: Decompiled Code from the game Yandere Simulator.

The first thing I want to jump into is the Timer.cs file. It is part of the minigame where the player works in a cafe to make in game currency. The minigame is timed. It starts when the player presses start and when it runs out the minigames stops, calculates the in-game money earned and gives it to the player. One fix is to change the function named “Awake” into “GameTurnedOn” or “GameBegin”. Awake is supposed to tell the file that the player has started the game. The name given makes no sense since there is no sleeping in this minigame.

The next thing I want to discuss the ServingCounter.cs file. It is part of the cafe minigame. The counter is where the player sets their empty tray and picks of their tray filled with food. My first fix is to remove chefMask and trashMask from the SetMask function. Next, change Setmask to “SetservingcounterMask”. The whole file pertains to the serving counter. The chef AI and trash can should not be affected. It would be better to put something that could call on a function. Then the functions in their respective files would execute.

The next thing I want to discuss the KnifeDetectorScript.cs file. The whole thing is a mess. I think this sees if the player has a knife but it includes code of hiding a knife and interacting with a blowtorch. Maybe the code is for the player heating the knife with a blowtorch. Firstly, the name of the file is bad. It does nothing to describe what the code is doing. It is better to name the file “HeatingKnife”. Second, blowtorch is a bad name in general because the item looks exactly like a Bunsen burner. This has to be renamed to Bunsen burner. Lastly, why does the file mention a knife but the code does not specify a weapon? This would be confusing for anyone jumping into the code. Either change the code to only mention knife or change the file name to “HeatingWeapon”.

I have the same thoughts as the ones in my last post. The code is messy and any outside party trying to change it will have a lot of trouble. I also learned something new: the importance of naming things properly. Coding without proper naming is like trying to put furniture together with no labels. Even if you put to pieces together you run the risk of putting the wrong pieces together, getting them stuck and wasting time trying to fix it.

From the blog CS@Worcester – My Journey through Comp Sci by Joanna Presume and used with permission of the author. All other rights reserved by the author.

Understanding SOLID Principles: A Guide 

As a student learning software design, I’ve come across the SOLID principles in a few lectures, but I wanted a deeper dive to really understand how to apply them. I recently read a blog post titled “SOLID Principles — The Definitive Guide” by Midhun Vincent on Medium. This guide breaks down each of the five SOLID principles in a straightforward way, with examples and explanations that actually make sense for someone still new to object-oriented design. The article is totally in line with what we’re covering in my course, so I figured it was a great chance to see how these principles could improve my coding style now and in the future.

Summary of the Selected Resource

The article explains the SOLID principles, which are five key guidelines for designing object-oriented software that is easier to understand, extend, and maintain. The first principle, the Single Responsibility Principle (SRP), emphasizes that each class should focus on a single task, making the code simpler to maintain and update. Next is the Open/Closed Principle (OCP), which suggests that classes should be open for extension but closed for modification, allowing developers to add new features without altering the original code structure. The Liskov Substitution Principle (LSP)follows, which ensures that objects of a superclass can be replaced with objects of subclasses without causing issues in the application. Then there’s the Interface Segregation Principle (ISP), which advises against creating large, general-purpose interfaces and instead encourages smaller, more specific ones that suit the exact needs of different clients. Finally, the Dependency Inversion Principle (DIP) recommends that high-level modules should not rely on low-level modules but rather on abstractions, which reduces dependency and enhances flexibility. Together, these principles form a strong foundation for writing clean, modular code that can handle future changes more gracefully.

Why I Chose This Resource

I chose this post because the SOLID principles are really useful in building better code but can feel abstract at first. The article breaks down each principle in a way that makes them feel practical and achievable. Also, the examples in the post connect well with coding challenges we’ve faced in our course projects, especially in terms of keeping code organized and easy to debug. Seeing how SOLID principles can prevent code from becoming a tangled mess gave me a new perspective on how I approach my own assignments.

My Takeaways and Reflection

Before reading this post, I understood the theory behind the SOLID principles but not really how to implement them in my own code. Now, I can see why each principle matters and how they can actually save time by reducing the need for debugging and refactoring down the line. The Single Responsibility Principle, for example, made me think about how I often give one class way too many jobs, which then makes fixing issues complicated. By applying SRP, I can keep my classes simpler and less error-prone.

Moving forward, I’m planning to use these principles as I work on my projects, especially with the Open/Closed Principle and the Interface Segregation Principle. I can see how they’ll help me write code that’s easier to adapt if requirements change or if I add new features later. In the future, I think understanding SOLID will give me a solid foundation (pun intended!) as I move into more complex software development work.

Link to the Resource

https://medium.com/android-news/solid-principles-the-definitive-guide-75e30a284dea

View at Medium.com
View at Medium.com

From the blog Computer Science From a Basketball Fan by Brandon Njuguna and used with permission of the author. All other rights reserved by the author.

Tackling Merge Conflicts with GitKit: A Student’s Guide to Smoother Collaboration

Working on team projects in class has really brought out how tricky merge conflicts can be. Nothing quite like seeing “conflict” pop up after a pull request to slow things down! For this blog entry, I looked into a post called “Mastering Merge Conflicts with GitKit” , which breaks down why merge conflicts happen and shows how to tackle them using GitKit’s built-in tools. Since our course covers version control and team-based coding, I figured learning to manage these conflicts more effectively would make a big difference, not just now but for any future projects.

Summary of the Selected Resource

The post explains why merge conflicts occur in collaborative projects, like when multiple team members edit the same file or branch in different ways. The author points out that conflicts are actually pretty normal in team coding—it’s just part of working with a shared codebase. GitKit’s approach to handling conflicts was the real game-changer for me here. It uses interactive conflict markers, visual diffs, and a guided merge workflow to help developers see exactly where conflicts happen and resolve them without a lot of guesswork. It’s clear from the blog that these features simplify what’s often a frustrating process, making it more manageable and, honestly, less intimidating.

Why I Chose This Resource

I picked this post because merge conflicts have been a big obstacle for me and my project teammates. They always seem to come up at the worst times—right when you think you’re wrapping up! Learning more about practical strategies to handle them seemed like a solid move. Plus, I hadn’t really explored GitKit’s full range of features before, so this gave me a chance to see how it can streamline conflict resolution. With team coding becoming more common in projects, internships, and industry work, knowing about these tools feels pretty essential.

My Takeaways and Reflection

Before reading this, I mostly just knew the basics of handling conflicts through the command line. But after seeing what GitKit offers, I realized how helpful visual tools and conflict markers can be. They make it so much easier to understand what’s causing the conflict and to feel more confident about fixing it. Having a clearer view of what’s happening in the code feels like it will help me avoid mistakes and keep our project moving forward without so much stress.

Looking ahead, I’m definitely going to use these GitKit techniques in my future work. I plan to keep practicing conflict resolution so it becomes second nature and doesn’t disrupt my flow as much. I can see how this will really come in handy, especially when I start working on larger projects or in a professional setting where team collaboration is essential.

Link to the Resource

https://dev.to/htsagara/handling-merge-conflicts-in-git-how-to-fix-and-prevent-them-1m62

From the blog Computer Science From a Basketball Fan by Brandon Njuguna and used with permission of the author. All other rights reserved by the author.

Design Patterns

Design patterns are essential tools for software developers, providing standardized, reusable solutions to common coding challenges. Rather than developing unique solutions every time a familiar problem arises, developers use these templates to write organized, efficient, and adaptable code. Design patterns are not complete blocks of code but instead serve as blueprints, guiding the structure of code in object-oriented programming and enhancing overall project organization.

according to the published article on GeeksForGeeks, the article mentions about A key advantage of design patterns which is reusability. Patterns can be applied across different projects, which saves time and effort by eliminating the need to repeatedly solve similar issues. This flexibility also allows developers to apply patterns quickly in various scenarios, accelerating development. Another benefit is standardization; design patterns create a common vocabulary among developers, which simplifies communication and collaboration within a team. By recognizing these patterns, all team members can quickly understand and follow the structure of the codebase.

Design patterns further promote efficiency by offering solutions that have been tested and refined over time. Since developers do not need to invent new solutions for frequently encountered problems, they can progress faster with fewer errors. Additionally, design patterns are designed to be flexible. They are adaptable templates, meaning they can be customized to fit specific project needs, making them a versatile tool for a variety of applications.

Types of Design Patterns

Design patterns fall into three main categories: Creational, Structural, and Behavioral.

  1. Creational Patterns focus on managing object creation to keep systems flexible and independent of object-specific creation logic. Examples include:
    • Factory Method: Allows creation of objects without specifying the exact class.
    • Singleton: Ensures only one instance of a class exists globally.
    • Builder: Breaks down complex object construction into simpler steps.
  2. Structural Patterns emphasize organizing classes and objects to create efficient, larger structures. Examples include:
    • Adapter: Enables incompatible classes to work together by adjusting their interfaces.
    • Facade: Simplifies complex systems by providing a unified interface.
    • Decorator: Adds extra functionality to objects without altering other instances.
  3. Behavioral Patterns focus on defining how classes and objects interact within a system, streamlining communication in complex applications.

In summary, design patterns help developers produce clear, maintainable, and scalable code. By adopting these patterns, developers can approach recurring problems with reliable solutions, improving collaboration, reducing development time, and creating codebases that are easy to expand and adapt. In the fast-paced world of software development, design patterns serve as a stable foundation for building robust, flexible applications

Reference: https://www.geeksforgeeks.org/software-design-patterns/

From the blog CS@Worcester – The Bits & Bytes Universe by skarkonan and used with permission of the author. All other rights reserved by the author.

Why Python Is So Popular Even Though It’s Super Slow

This week, while exploring some articles, I found one that really caught my attention: Happy Patel’s article titled, “Why Python Is So Popular Even Though It’s Super Slow.” Patel’s post dives into Python’s popularity in the programming world, even though it’s known for being slower than other languages. After a quick look into Patel’s background, I found that he’s a knowledgeable voice in tech, sharing insights into why developers choose Python despite its limitations. His article offers a well rounded look at the unique benefits of Python, such as its simplicity, versatility, and productivity, which contribute to its wide usage in various fields like web development, data science, and automation.

Patel kicks things off by breaking down why Python is generally considered “slow.” For instance, he mentions that Python’s code is interpreted rather than compiled, which can make it lag behind other languages in execution speed. Another reason for this lag is Python’s Global Interpreter Lock (GIL), which only allows one thread to execute at a time within a process. Although these details may seem like drawbacks, Patel points out that these traits also make Python flexible and user-friendly. Its high level syntax closely mirrors human thought, allowing developers to think more about problem-solving than strict coding rules. Patel sums it up well by explaining that Python essentially lets computers handle the heavy lifting, letting humans focus on creative coding.

Then, Patel goes on to highlight the reasons for Python’s enduring popularity, despite the speed limitations. One key factor he points out is that Python’s simplicity and readability make it incredibly productive. Development cycles are often much shorter, which can be a huge plus for companies where employee time is one of the most valuable resources. He argues that for many businesses, development speed and efficiency matter more than code execution speed. Patel also emphasizes that Python’s scaling capabilities, like horizontal scaling, let developers manage performance limitations, making Python adaptable for many real-world applications.

I chose this article because it not only aligns with our course material but also sheds light on Python’s “personality” in the coding world. I liked Patel’s casual and practical tone it’s informative without being overly technical. His points gave me a new perspective on how Python’s user-friendliness outweighs its slower speed, especially in environments where development time is critical. Patel’s discussion encouraged me to think about how Python’s design might be useful in my own coding projects, as it shows how the language’s efficiency and adaptability make it great for rapid prototyping.

Reading this article reinforced why Python is considered beginner friendly and why its productivity makes it so popular across industries. I’m excited to apply what I’ve learned, especially Python’s fast development approach, in future projects where flexibility and quick prototyping will be valuable. Patel’s article makes a strong case for why Python is more than just “slow” it’s practical, versatile, and adaptable, which are all reasons I’d recommend Python to anyone entering the programming field.

Link to the post: https://medium.com/@innvonixtechsolutions/why-python-is-so-popular-even-though-its-super-slow-cedfa2b8fe68

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.

Retreat into Competence

This week I decided to write about the pattern called “Retreat into Competence”. This pattern discusses the common occurrence of feeling out of your depth and what you should do about it. In the past couple of months,  I have been confronted with the depths of my lack of knowledge and realized just how overwhelming it can be. It is for this reason that I chose to read about the suggested solutions for this pattern.

The solution provided for this issue is to retreat into your knowledge to regain composure and then “then launch forward like a stone from a catapult”. This method will allow you to realize how far you’ve come and recognize what you are capable of. You need to overcome your fear of incompetence to grow. I agree with the statement that “sometimes you need to take one step back in order to take two steps forward” and how it is important to focus on moving forward as quickly as possible. It took me some time to reflect on this solution but I think this is because if you don’t force yourself to focus on moving forward you can get stuck by being too comfortable. 

For the most part, I agree with the text. It is definitely a risky solution because it is important that you recognize that it is only a temporary fix. You need to be honest with yourself and have discipline to stick to a time limit as suggested in the last paragraph. Although this is a good solution for certain situations and/or certain types of people, sometimes I think you just need to throw yourself into learning the new material. In the recent projects I worked on where I realized the extent of my ignorance, I decided to dive right into some resources to help me learn. I was working with tight deadlines and had to learn as much as I could to be a useful team member. Regardless of this fact, the core of this section gets one thing right, to do anything you must first tackle your fear of incompetence and inadequacy. Although my first solution is to dive into new material, I may come across a situation where it will be more helpful to take 2 steps back. This solution was definitely interesting to read about because it is very different from my usual approach.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

‘Sweeping the Floor’ Pattern

The ‘sweeping the floor’ pattern in chapter four pertains directly to the beginnings of an apprenticeship or just work in software in general. This pattern explains that when you first begin the process of working in software while you will not be nearly as knowledgeable or efficient as the other members of your team with more experience you will still be able to contribute in smaller or more simple ways in order to still provide assistance and work with your team as you learn how to do more technical tasks. This strategy can be applied in every field as when you start your career or even when you start a part time job in high school you first have to be taught how to do certain tasks in the correct way but while you learn how to do the more complicated tasks correctly you will still be able to put effort into making tasks easier for others who are already able to do the more complicated tasks that come with your job.

This pattern stood out to me as I believe that this is especially important to remember when you are entering any job or looking to start your career after college as the thought of ‘not knowing’ how to do the more technical tasks can be daunting for people at times as they see it as a massive obstacle you must overcome when in reality you are not expected to be able to do every task that more experienced team members are able to do. You are expected to contribute in any way you can to help your team work and provide insight while also remembering to continuously learn along the way in order to enable yourself to do these tasks in the future so that one day you are the ‘more experienced team member’ that someone looks to for guidance. Advice like this is important for college graduates that are just starting their careers as in most cases our first jobs will be learning experiences that we need to embrace and make the best of in order to further our understanding of both the field and our colleagues. 

From the blog CS@Worcester – Dylan Brown Computer Science by dylanbrowncs and used with permission of the author. All other rights reserved by the author.

CS448 Software Development Capstone: Apprenticeship Patterns – “Reading List”

After my week of spring break, I’m looking to get back to building constructive habits and reinforcing my software development fundamentals. I was inspired to return to this chapter of the “Apprenticeship Patterns” textbook because I recently learned about a computer science problem called the Circle-Ellipse problem.

This hypothetical problem is meant to highlight the limitations of the object-oriented programming paradigm, specifically when using subtype polymorphism in your class design. In the Circle-Ellipse problem, two classes are defined, Circle and Ellipse, with the Circle class inheriting from the Ellipse class. The Ellipse class includes two member methods, stretchX() and stretchY() which can modify, or mutate, two private member variables of Ellipse each representing an X and Y coordinate. The programming language understands all instances of the Circle class as also being instances of the Ellipse class with this inheritance relation. The problem arises when considering the requirements of a subclass. A subclass needs to implement all the member variables and methods of its parent. The Circle class needs to implement stretchX() and stretchY() as a subclass of Ellipse. Using either of these methods to change the dimensions of the Circle would consequently make that object no longer represent a mathematically correct circle.

As this problem was explained to me, the Liskov Substitution Principle was mentioned. I remember reading about this principle as one of the 5 SOLID software design patterns. The Liskov Substitution Principle essentially states that in a program using subtype polymorphism, an object ought to be able to be substituted by one of its subclasses without breaking the program. The Circle-Ellipse problem represents a violation of this principle because an Ellipse cannot be substituted for a Circle except in one very specific case.

I hadn’t considered the limitations of inheritance relationships in software design before learning about this problem. I decided that after the lecture where I learned about the Circle-Ellipse problem, and after seeing so many titles and authors name dropped in “Apprenticeship Patterns”, that I should start compiling a reading list and start more intentionally defining my daily schedule, including time for reading about software design and computer science. I started with a summary of the Circle-Ellipse problem, and then went through the appendix in “Apprenticeship Patterns” to choose a few books that the authors cited the most often.

The pattern introduces the possibilities of making your reading list public on the internet or using an existing list to source further reading material. The reader is also prompted to look ahead to the future and maintain the reading list to use for reflection on their learning journey.

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

CS-448 Week 8 Long Road

The pattern of “The Long Road” highlights a common dilemma faced by aspiring software developers in today’s fast-paced industry. It contrasts the culture of instant gratification and superficial success with the desire to pursue mastery and craftsmanship in software development.

What intrigues me about this pattern is the disconnect between the long-term goals of becoming a proficient software developer and the short-term pressures to prioritize immediate financial gain and career advancement. Especially early in their careers, developers find themselves torn between these conflicting expectations while navigating through the complexities of the industry and trying to establish themselves.

This pattern resonates with me personally because it highlights the internal struggle I have faced in my own journey as a software developer. While I have not had any significant offers in the field of work yet, I know that true fulfillment in this line of work comes from the pursuit of excellence, continuous learning, and honing one’s craft over time. With my focus on excellence in my personal craft, it will pay off for me in the future later down the road.

The notion that the lessons and wisdom of seasoned software developers often goes unheeded in an industry that is constantly chasing the next big thing I found thought-provoking. The lack of knowledge transfer between generations of developers leads to the repetition of past mistakes and the reinvention of the wheel.

This pattern has caused me to reconsider my approach to my intended profession and how I want to work. Rather than falling into the external pressures and expectations, I am more committed to stay true to my passion for software development and prioritizing personal growth and mastery over short-term gains.

While I understand the advice to prioritize financial stability and career advancement, I do not completely agree with the notion that slow and steady skill-building is somehow less valuable or important. I believe that the pursuit of mastery is what ultimately sets exceptional developers apart and leads to long-term success and fulfillment in this field. I remain steadfast in my commitment to honing my skills, embracing lifelong learning, and striving for excellence in my craft, regardless of the trends or societal expectations.

3. Walking the Long Road | Apprenticeship Patterns (oreilly.com)

From the blog CS@Worcester – Jason Lee Computer Science Blog by jlee3811 and used with permission of the author. All other rights reserved by the author.

Learning Never Stops

I decided to read the “Reading List” section from the “Construct your Curriculum” chapter, and I found it quite eye-opening. I have read some general books related to software development and computing, whether discussing theory or practical information. However, I must admit that most, if not all, of what I have read has either been out of necessity for course requirements or coursework-related. I have yet to build a list of literature to read or go out to seek literature to read now. After viewing this section, I will get started looking deeper into the literature related to the particular fields I’m interested in to aid me in my future profession(s).

While there is plenty to read and endless amounts of information to consume, it’s important to find things that are related and applicable to my work or studies. At this current moment, I am interested in software development in general, but I would like to get into the fields of robotics and/or artificial intelligence after graduation. Even though these topics are constantly changing and evolving, I can find some good literature to aid in building my overall knowledge related to such topics.

With the advent of the internet, text is no longer purely physical, and I can access even more literature than ever before. But with that perceived benefit also comes the caveat of there being too much for one person to reasonably consume. There are plenty of resources I can use, though, including the internet, peers, and/or mentors. Utilizing such resources can aid in my sifting through the unnecessary filler content to delve into text that will meaningfully add to my knowledge base. Even if something may not be useful directly at the moment, I also recognize that important information isn’t always apparent at the exact moment it’s consumed. Focusing on my present needs but also tending to potential future ones, will most definitely add to my progress on my craftsman journey.

I recognize that my learning must never come to a halt since complacency could easily lead my path toward becoming a master craftsman to become derailed either temporarily or permanently. By looking for and curating literature to serve my own needs and wants related to my present and future professions, I will be able to become a well-informed craftsman while remaining open-minded to new and ever-rapid changes within the entire computing field, whether that lies in practical work or research. Regardless of what field I venture into, this skill will always serve to benefit my work and hopefully help me aid others in their journeys as well.

From the blog CS@Worcester – Eli's Corner of the Internet by Eli and used with permission of the author. All other rights reserved by the author.