Earlier in this course, I learned about UML diagrams, how to read them, how to make them, and so on. This section of the class stuck with me as I thought it was pretty interesting how we use these diagrams to “visualize” our code. I thought I’d gain some more insight on UML diagrams and possibly more on how they are used in the real world.

For those who aren’t so familiar with UML diagrams, let me give you some background. UML stands for “Unified Modeling Language” and is “a way to visually represent the architecture, design, and implementation of complex software systems” (Lucidchart). These diagrams can be generally divided into two types, structural and behavioral. Both types of UML diagrams are pretty self-explanatory but structural UML diagrams display the various pieces of a system and how they are related while behavioral UML diagrams show how the system “interacts with itself and with users, other systems, and other entities” (Lucidchart).

In this blogpost from Lucidchart, one of the first things that caught my eye was under the section “Why should you use UML diagrams?” Of the four bullet points, three of them had me nodding my head in agreement, these were:

• Bring new team members or developers switching teams up to speed quickly.
• Plan out new features before any programming takes place.
• Communicate with technical and non-technical audiences more easily.

To me, these points make perfect sense. I’m not very familiar with how development teams work in the real world but I assume that there are plenty of developers and others that may come and go in companies, groups, and such. It may sound like a simple switch or change but that new person may have no idea what they will be working on or how it will be worked on. UML diagrams could help them adjust more quickly and help them understand their role, team, and work better. As for planning, simply adding a new piece to the diagram to indicate a new piece of the system could help display the relationships to what they already have. And finally, UML diagrams are much easier to digest than multiple files, classes, blocks of code, and such, especially for those who are not developers. A customer may want some update or insight into what they are spending their money on, and so, teams can simply show them a UML diagram and point out where they are and where they plan to go.

Blogpost: https://www.lucidchart.com/blog/types-of-UML-diagrams

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

In the realm of software development and design, UML (Unified Modeling Language) class diagrams play a pivotal role. The blog post “UML Class Diagram Explained with Examples” by Algomaster provides a comprehensive overview of class diagrams, illustrating their importance in modeling the structure of a system.

Code, while essential for functionality, is not always the best medium for conveying complex relationships between components. To address this challenge, the Unified Modeling Language (UML) class diagram provides an abstract visual representation of the structure of a system. The blog post by Algomaster, offers a detailed explanation of UML class diagrams, including key concepts such as classes, attributes, methods, and associations. This resource was particularly relevant to our recent assignment on Modeling with UML Class Diagrams, where we were tasked with designing class diagrams to represent a student-course scheduling system.

The blog post breaks down the structure of UML class diagrams, explaining each component in detail with accompanying examples. The tutorial begins by outlining the core elements of a class diagram, including classes, attributes, methods, and associations.

I selected this blog post because it provides a clear, concise explanation of UML class diagrams and their practical application, which directly ties into the Modeling with UML Class Diagrams assignment. This resource helped me better understand how to translate Java code into a UML diagram by identifying key components such as classes, attributes, and methods. Additionally, the visual nature of the tutorial, with its real-life examples, made it easier to grasp abstract concepts and apply them to my assignment.

I feel more confident in my ability to design and interpret UML class diagrams. Visit the original post on Algomaster: UML Class Diagram Explained with Examples.

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

After spending some time exploring algorithms and blogs, I came across a post on a consistent hashing algorithm. I have had an interest in hashing and have found growing use for hashing algorithms as my classes and programming complexity progresses. This article is found on highscalability.com, and it is focused on providing a tutorial to understand how to use a consistent hashing algorithm for partitioning and load-balancing. The article’s title is Consistent Hashing Algorithm by NK

The blog identifies consistent hashing as an algorithm used to distribute data across multiple nodes in a distributed system, minimizing data movement when nodes are added or removed. It works by placing both nodes and data keys on a virtual hash ring. A virtual hash ring is a technique where each node is assigned a position on the ring based on the hash value of its identifier. The blog explains further that data keys are also hashed to determine their position on the rin as well. When a key needs to be stored or retrieved, the system traverses the ring in a clockwise direction until it finds the first node that is closest to the key’s hash position. This method ensures that only a small portion of the data needs to be redistributed when nodes are added or removed, making the system more easily scalable. The blog identifies these strategies and techniques to be best used in web development to handle caches. Through several figures, NK identifies as a way to improve load balancing and avoid hotspots, consistent hashing can use virtual versions of these nodes, where each physical node is mapped to multiple positions on the ring virtually. This technique can be essential for scaling distributed systems, like caching systems and distributed databases, that need to handle dynamic loads while maintaining high availability.

This is a topic that interested me greatly as I have–in conversations with friends in Computer Science–been consistently recommended to learn more about hashing. Through the CS-343 course, I have been looking for more ideas for algorithms and techniques to learn to improve my understanding as my senior year progresses. I will be prepared to answer questions regarding consistent hashing thanks to this article. This is of great value to me as I will continue to look for more on this topic, as I explore software development. While I did not cover every example or style found in the article, I found it all extremely interesting and comprehensive. This blog has many examples and well-made figures to explain things in a simple manner, and I will continue to use highscalability to learn more.

Source:https://highscalability.com/consistent-hashing-algorithm/

From the blog CS@Worcester – WSU CS Blog: Ben Gelineau by Ben Gelineau and used with permission of the author. All other rights reserved by the author.

Ever work with code that feels like it’s about to fall apart? That’s often due to design smells, which are signs of poor design that make code harder to work with. Here’s a quick rundown of six big ones: Rigidity, Fragility, Immobility, Viscosity, Needless Complexity, Needless Repetition, and Opacity

1. Rigidity

Rigidity is when code is hard to change. You try to update a small feature, and suddenly you’re changing ten other things just to make it work. This makes the code stiff, leading to slow updates and frustration.

2. Fragility

Fragility means that the code breaks easily. A small change in one part of the codebase suddenly causes errors all over. Fragile code is typically too tightly coupled, meaning different parts rely too much on each other, making even minor updates risky.

3. Immobility

Immobility happens when you can’t easily reuse code in other projects. Maybe you’ve written a method that could be helpful elsewhere, but it relies on so many project-specific details that you can’t transfer it without dragging a ton of dependencies. Immobile code wastes potential and limits flexibility.

4. Viscosity

Viscosity means the code is easier to “quick-fix” than fix the right way. The messy design makes doing things properly so difficult that developers often take shortcuts, creating even more technical debt. Viscous code tempts us to compromise, resulting in even messier code over time.

5. Needless Complexity

Needless complexity is adding extra, unneeded elements to the code. This could be because someone thought, “We might need this someday,” or because they’re solving non-existent problems. Extra complexity doesn’t just add confusion; it makes the code harder to read, test, and debug. Simple solutions are usually best.

6. Needless Repetition

Needless repetition is when you see similar code blocks everywhere instead of consolidating them. When you repeat code instead of centralizing it, it violates the DRY (Don’t Repeat Yourself) principle. This makes code harder to maintain, as changes need to be made in multiple places instead of just one.

7. Opacity

Opacity is when code is confusing and hard to read. Maybe variable names don’t make sense, logic is overly complex, or comments are missing. Opaque code is like a puzzle, requiring extra time to understand, and slowing down productivity.

Why It Matters

Design smells don’t stop your code from working, but they make it harder to understand, change, and maintain. Ignoring them means the code gets more frustrating to deal with over time. By refactoring to remove these smells, you make the code cleaner, easier to work with, and more enjoyable for everyone on your team. Next time you’re reviewing code, look out for these design smells, your future self will thank you!

From the blog CS@Worcester – Anairdo's WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.

The piece “Draw Your Own Map” encourages individuals to take control of their career paths rather than relying solely on their employers or societal expectations. It addresses the common notion that programming and career advancement in the field are limited, especially for those who may not fit the stereotype of fresh graduates. It emphasizes the importance of identifying one’s own career goals and taking proactive steps to achieve them.

The solution proposed involves identifying logical yet ambitious career steps and visualizing the incremental actions needed to reach those goals. It advocates for taking the first step, even if seemingly insignificant, as it generates momentum towards larger aspirations. Rather than setting only high-level goals, the article suggests defining small, achievable steps that provide feedback and aid in obtaining assistance from like-minded individuals.

The narrative includes personal stories illustrating individuals’ struggles to pursue programming despite organizational constraints. It highlights the importance of prioritizing personal aspirations over organizational expectations and seeking opportunities that align with one’s goals.

The actionable advice includes listing potential career paths, extending the list to explore additional options, and challenging preconceived constraints to open up new possibilities. It also encourages seeking mentors and kindred spirits who can provide guidance and support along the way.

Overall, the piece advocates for a proactive and flexible approach to career planning, empowering individuals to chart their own paths and overcome obstacles to achieve their desired destinations. What I thought was the most important of this piece is the career planning aspect of it especially since this semester I am finishing up my degree and starting on looking for a career, this also like points me in the write direction on a professional work future.

From the blog CS@Worcester – CS- Raquel Penha by raqpenha and used with permission of the author. All other rights reserved by the author.

The article “Pairwise Testing” by Ryan Craven explores into the concept and application of pairwise testing, a powerful technique used in software testing to enhance efficiency and effectiveness. Pairwise testing, also known as all-pairs testing, aims to analytically reduce the number of test cases required to test a system while still maintaining thorough coverage.

This blog begins by introducing the problem of combinatorial explosion in testing. Traditional thorough testing, where every possible combination of inputs is tested, quickly becomes impractical as the number of variables or parameters increases. Pairwise testing offers a solution to this problem by focusing on testing pairs of input values. The key insight is that many faults in software are caused by interactions between pairs of inputs rather than individual inputs themselves.

The author explains the core principles behind pairwise testing, emphasizing its ability to efficiently cover many combinations by selecting a representative subset. This approach significantly reduces the number of test cases needed compared to exhaustive testing while still providing effective coverage.

This blog also shares the concept of pairwise testing with a simple example involving a fictional coffee shop application. By identifying the parameters and their respective values (e.g., coffee size, type, extras), he demonstrates how pairwise testing can be applied to generate a minimal set of test cases that cover all possible pairs of values.

Also, the article discusses the benefits and limitations of pairwise testing. While it offers substantial reductions in test case count and provides good coverage, it may not detect faults involving interactions between more than two inputs. Craven advises on when pairwise testing is most suitable, such as in situations with limited time and resources or when dealing with complex systems with numerous input parameters.

This was a good blog post to read because it covered somethings we talked about in class during the group work. Through clear explanations and examples, the article serves as a helpful guide for understanding and applying pairwise testing in real-world scenarios. This is definitely something that will be very useful in the feature as my professional career expanded

From the blog CS@Worcester – CS- Raquel Penha by raqpenha and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance

In the world of software development, everyone is under a great amount of pressure to meet deadlines and deliver software. Because the entire team is under the pressure of meeting deadlines, the managers look for confidence when asking how long a feature will take to finish. Due to the new developer’s inexperience, they are unsure how to answer because they are not familiar enough with the technologies to be able to quantify how long the process will take. This pattern is called “Expose Your Ignorance.” In this pattern, it discusses the situation of a new developer who is unfamiliar with some of the required technologies their team uses, and is afraid to look incompetent.

Software developers tend to build their reputations through strong relationships with their clients and colleagues. Building strong relationships require honesty, and not just telling the client what they want to hear. Rather than pretending to know something, it is better to reassure the client by emphasizing the ability to learn new technologies and being able to apply them. Reassuring in this manner allows relationships to be built based on the ability to learn and adapt rather than based on what is already known.

The most obvious way to expose ignorance is to ask questions. The hardest part about asking questions is the fear of appearing incompetent. However asking questions and being direct is the easiest and most straightforward path down the software craftsman’s journey. Becoming comfortable with this process of learning, by asking questions to mentors, helps to prevent us from being locked into one domain of software development. An action that can be done to help with this process is to keep a list of what is unknown. Keep this list in a place that is public to the rest of the team to hold accountability and/or to help with understanding. Being in the habit of updating this list is also important to ensure continuous learning. Ultimately, possessing the ability to learn is one of the most important traits of a craftsman.

I found this pattern to be helpful because it provides a way with confronting feelings that may be uncomfortable when becoming a craftsman. I found the solution of making a list of what is unknown, and keeping that list public was interesting and changed the way I view the pattern because that is something I would not do. I would rather keep this to myself and work on it separately, but keeping this list public allows the team to hold accountability. This is because if the list has not been updated for a while, then that means the learning process has halted. I do not disagree with anything in this pattern.

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

For this week’s blog I decided to talk about the pattern from chapter 4 called “Be the Worst”. This pattern describes the situation where you have taken every opportunity to learn and eventually have outgrown your team. In this situation, it is important that you find developers that are better than you. When you take this route you will need to put in a lot of work because your aim is not to stay at the bottom but work your way up. You will be able to use multiple methods like mimicking other developers until you are on the same level and them. 

I agree with the solution for this scenario. I have found that I learn a lot when I am the weakest on a team. I am able to study the code written by the stronger members of my team and get insight on their choices. I found that learning from another person also speeds the process along. During this process, its important to avoid bothering your other team members too much. Although it can be convenient to just ask others, you need to establish a way to learn on your own so you can avoid prohibiting thew progress of others.

As one can guess, this method has risks like dragging the team down and running the risk of being fired because your productivity is not as expected. I have experienced pressure to avoid bringing the team down along with a lack of confidence in my own abilities. The first steps to follow this pattern is to develop confidence in yourself and focus on learning. Second, I think it is important to have open conversations with your team members and speak up when you may be falling behind. As mentioned in my other blogs, I have worked on past teams where I had to learned from other members. During this process, we all kept each other updated on our progress and it was crucial for us to work together to finish by our deadline.

 I think this pattern aligns well with the way I’ve been developing my professional skills and I cant say that I disagree with anything. Following this path will definitely help with self-assessment because the more you know, the more you know what you don’t know. 

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.

Summary:

This section really emphasizes the importance a mentor can have on someone’s apprenticeship. Guidance from someone who has already experienced the same or similar issues that you are going through is invaluable. On top of that, it establishes what realistic expectations one should have for a mentor. With computer science being such a vast field that is only getting larger, it’s unrealistic to expect one person to know everything about every topic. The last major point the section covers is that the flow of knowledge does not stop at you. An apprentice must be willing and able to pass on knowledge to other apprentices. 

Reflection:

Thinking back to my most impactful teachers and professors, it’s clear to see that their impact comes from their ability to mentor their students.  Having those impactful mentors throughout my education is what inspired me to seek a career in computer science. The best example I can come up with to relate the impact a mentor can have on an apprentice is this: Imagine trying to solve a hidden picture puzzle or “Where’s Waldo” and you can’t seem to figure it out. Having a mentor is like having a magnifying glass to help narrow down where you should be looking. This sense of direction is great to focus your efforts into researching helpful information. Considering how large the computer science field has grown.

When it comes to choosing a mentor in the computer science field, it is important to realize how large the field is. I have said it three times now, and I still don’t think that is enough to emphasize it. It is best to try and find a mentor that specializes in the field you want to learn about. Although, from my experiences, a mentor that does not specialize in the same field as you is still worth having. A mentor that specializes in any field can still give you tips on how they got to where they are. With the same mentality of teaching a person to fish over giving them a fish, learning how to learn is better than being taught something directly. With information so readily at our fingertips, the ability to research and find solutions is crucial in our world and especially the computer science field.

Bringing everything full circle is the idea that what separates an apprentice from a journeyman is the responsibility to help teach and mentor other apprentices. It makes sense that as I continue down the long path that there will be others behind me. I, personally, have always loved the spark that my mentors have ignited in me and it would be great to be able to pass that sling to others in the future.

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