Category Archives: Week 9

The Factory Method Pattern

Here we are again looking at another Design Pattern for software. Again from our friend Christopher Okhravi getting into the nitty gritty of the “Factor Method Pattern” and how it works using logic and examples all from the book “Head First Design Patterns”. I picked this because the last one of these I watched I thought really worked for explaining the Strategy Pattern for me so I wanted to give another one a watch for some more complicated patterns. First Mr.Okhravi walks us through how exactly a Factory Pattern works where we have a series of classes that all implement the same superclass and we then create these products through separate classes that instantiate them called a “Factory”. But when we instantiate one of these classes we don’t actually know which class we want to instantiate, we just need some kind of logic to produce them inside the factory that decides how the classes are instantiated. So this Design Pattern was certainly more of a challenge to wrap my head around but I think with this resource it’s helped me to understand it somewhat better. This pattern at least for me when working on it in the design pattern homework was definitely a little too convoluted for me to fully parse but it did still make some sense when I put it into practice. This video though has helped me to at least better understand the underlying logic of it all and really grasp the way it can work for other things and how you can even have multiple factories to produce objects in other ways. This resource definitely gave me a better appreciation for what the factory pattern is capable of and the different ways it can used. Not to mention that it seems infinitely customizable in that it’s scalability is huge. For the future I think I can expect to be using this at least for large scale projects that will have many different objects that need to added or used. This also makes me want to see what other design patterns there are other than the ones we have explored in class. So I think next I’ll be looking into other patterns and seeing what ones interest me. Other options I’ve been considering are patterns like the Decorator pattern or the Observer pattern both which look pretty interesting and I can’t wait to try them out!

Here’s the video!

—————————————————————-

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

Blog Week 9

The article I found today that I want to write about is titled “My 5 Biggest Screw-Ups as a Scrum Master”. I chose this article because the title of it really jumped out and resonated with me when I read it. I figured it would give me some good insight on what it’s like to be a scrum master and possibly have some good tips or tricks on how to avoid common mistakes when you’re new to it.

The article mentions his five major mistakes and how he fixed them, which I’ll get into below.

For the first mistake, he mentioned how when he heard differing viewpoints than his own, he would be upset. He fixed this by putting himself in the other people’s shoes, and trying to understand why they were seeing it how they were. For his second mistake, as it sort of ties into the first one, any feedback he got was very tough to swallow. To fix this, he actively sorted out as much feedback as he could in order to get used to it and learn from it. For the third mistake, he pretty much just simply allowed his group to “self-manage” on their own, but it led to a lot more confusion than anything. To fix this, he set goals and clear responsibilities for all members of the group but still allowed for the sense of freedom that self-management implies. As he says “it gives a sense of direction and vision for the state they want to achieve”. The fourth issue was missing out on signs of lack of trust; meaning not realizing the group members may have issues with each other. For his solution here, it really seems he doesn’t really have one. He tried everything he could but, at the end of the day, the two group members were never going to get along. I guess the takeaway here is to just recognize this and either reconstruct the group or direct your energy elsewhere. The fifth issue, working beyond his experience, was simply just that. He thought it would be a piece of cake to be a scrum master, but it was far from it. He learned you must expand your comfort zone by going into uncomfortable situations with the intent to learn, and that honesty is extremely crucial.

Although we learned about Scrum in class, this article did a good job summarizing and explaining the issues you may experience within it, especially as a first time scrum master. It’s honestly probably something I would have never thought of and I probably would’ve made the same mistake as the writer by thinking it would be a piece of cake. Because of this article, I now know a little bit more as to what to expect whenever I have my first big project as a scrum master and HOPEFULLY I can avoid some, if not all, of the mistakes made by the person here.

Link: https://medium.com/serious-scrum/my-5-biggest-screw-ups-as-a-scrum-master-f912be2ed2d4

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

Blog Entry Week 9

This week, I found a study on adopting design patterns in an IT organization. The study was conducted by the University of Oregon, and a link to the study can be found at the end of the blog. I selected this study due to the fact that it dove a lot into software design patterns and why, if they are implemented correctly, they can be extremely beneficial for a company to use.

The overall purpose of this study was to, as stated in the study, provide a scholarly annotated bibliography that examines software design patterns. It wants to provide IT leaders with proof that the implementation of design patterns can achieve increased operational efficiency or the delivery of strategic benefits.

By the end of this study, you can see some clear benefits of using a good design pattern. Operationally, there is a reduced development time as well as as a reduction of errors. This is due to the development process being streamlined, as well as being reusable with tested solutions. Strategically, patterns can contribute to a system that scales over time without a lot of rework, which is huge for organizations with rapidly evolving needs. Patterns also must create a shared language which inherently allows for better collaboration between different teams working on a project.

The study also goes over how it can be implemented using phased adoption; implementing patterns gradually allowing for people to adjust. On top of this, it mentions periodic review and sharing of documentation/knowledge, two very important ideas in terms of efficiently and affectively using design patterns.

Having read this study, it certainly reinforces a lot of the ideas we mentioned when discussing design patterns. I wouldn’t necessarily say everything I read was new, and the new sounding information may have just been worded in a different way, but the study certainly did a good job as sort of drilling the benefits of why a good design pattern can be highly beneficial.

This study also opened my eyes in the sense that I feel as though in my career I may keep an eye out for how different design patterns could be implemented into any projects that I’m working on. Being able to cut back on time, while still completing different jobs in an effective manner is something that will be very important and possibly put you above other people. If I demonstrate a knowledge of design patterns and can implement them well, or at least suggest them, it may at the very minimum open my companies eyes to different possibilities.

Link to study: https://scholarsbank.uoregon.edu/server/api/core/bitstreams/b5d95a74-77d6-454b-9ed5-1f2af2633f8a/content

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

The Troubles Of Learning Codebases

Often when joining a new job, you won’t be writing a new codebase from the ground up. Often we’ll have to familiarize ourselves with the preexisting codebase. Sometimes this codebase is old and needs to be updated or refactored. But how should we go about doing this? It is challenging enough to try to learn a new codebase, let alone trying to change or add to it. That’s what the question the article “Reducing The Learning Curve For Supporting Aging Codebases” by Scott Fitzpatrick aims to answer. The articles offer some dos and don’ts when it comes to trying to make it easier to learn a code base.

One of the first don’ts is to not rely on face-to face conversations and messages/email conversations. While these conversations can be helpful for developers in the moment, they offer little for someone trying to learn the codebase. Plus they can be hard to find and subject to deletion. I think the main point to take away from this article is the importance of good documentation and other resources. When it comes to making a codebase easier to understand, not just for newcomers. Having multiple avenues to try to learn from is important. Beyond just looking at the code, things like data flow and entity-relationship graphs. 

Other aspects beyond code are important too. Like good documentation on local environment set-up and system requirements/dependencies. Making these clear not only makes it easier from the newcomer, but also it helps learn about the frameworks and why they were chosen for the project. Knowing why an application uses certain frameworks and projects can help a new developer understand the reasoning and choices of the team.

Learning a new codebase is very challenging for anyone. I think this article offers good insights as to why certain practices are good and why some are bad. This also once again highlights why I think communication is the most important skill for a software developer. Being able to communicate with other developers not only through code, but through documentation is a very important skill. Making the lives of fellow developers easier by finding as many ways to communicate design and ideas. Although most developers hate writing documentation, it is a necessary evil that must be done.

I will definitely keep this in mind when writing code. Of course writing code that is readable takes precedence. But keeping up to date documentation is also vital to keep projects on track. I personally haven’t worked on a large project involving a large codebase before. So I haven’t had to write documentation for something that I didn’t write. Most of the time I don’t feel the need to write what the function or class does because I made it, so I already know. I think that’s a habit a lot of programmers have, that leads to a lot of lack or bad documentation. It’s something that I don’t have a lot of practice in, so its a skill I’ll have to start honing.

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.

Speed Over Design

The following blog I would like to talk about is called “The Hidden Cost of Speed” by Brayden H. Hord. He begins with a quick story about a project he worked on. In this story he describes how he, in an attempt to impress his bosses and meet his co-workers needs, pushed out a product as fast as possible. This worked for the moment. His bosses were happy and he continued his work. However months later, bugs and issues are arriving daily. The software he quickly developed was being used on a daily basis, something he had not anticipated. Now all the shortcuts he had taken earlier had come back to bite him. Now he had something that was being used extensively that was built poorly. 

Now he and his team had to work laboriously to try to fix these fundamental issues. Fixing the problems but also trying to interface between management and stakeholders. The truth is that these problems could have been avoided. If he had better planned and took more time to access the needs and requirements of the project. The moral of the story is that taking time to build right saves headaches down the line. The rest of the blog goes into more detail about why planning and communication are fundamental for all software developers. 

The reason I choose this blog is because I think it highlights one of the most important factors when it comes to software development, Communication. Most software is not built by one person, but rather a team of people. What makes a good team is communication, making sure everyone is on the same page. I think this is important to remember because building without a plan is a recipe for failure. It’s easy to get excited and try to push something that works. But something built on shoddy foundations is always destined to fall. 

Sure your code may work at the moment, but somewhere down the line issues will arise. As needs and more complex architecture is needed, the holes in the code will rear their ugly head. That’s why building code that takes into account not only the needs of now, but also the needs of the future. Building architecture that makes life easier in the future, not harder. I think that this is an important lesson for any software developer to know. Because building something right not only makes your life easier, but everyone else on the team’s lives easier as well.

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.

The Apprentice’s Superpower!

Hey Everyone ! As a computer science student embarking on my journey towards becoming a software development professional, the pattern “Unleash Your Enthusiasm” from the Apprenticeship Patterns book has matched deeply with me. This pattern emphasizes the importance of embracing and expressing the excitement and curiosity that often characterize the early stages of one’s career.
The pattern highlights the interesting attributes that apprentices bring to their teams, such as a fresh perspective, diverse ideas, and an exciting drive for learning. It acknowledges that while this level of enthusiasm may be seen as rare or even risky by more experienced team members.
What I found particularly thought-provoking about this pattern is the way it challenges the common tendency to conform to the norms of a team or organization. The pattern encourages apprentices to resist the urge to suppress their enthusiasm and instead to embrace it as a valuable contribution to the collective intelligence of the group.
Moreover, the pattern’s weight on the diversity of thought that enthusiastic apprentices can bring to a team resonates with my understanding of the importance of diverse perspectives in problem-solving and innovation. As I progress in my studies and eventually enter the workforce, I am eager to leverage my background and mindset to offer new upcoming solutions and challenge the current state.
In my own context, as a computer science student, I can see the value of this pattern in the classroom, where I can actively engage with my peers and professors, offering new ideas and questioning established practices. I am also excited to bring this mindset to any internships or entry-level positions I may pursue, with the goal of not only accelerating my own learning but also contributing to the growth and success of the teams I work with.
Overall, the “Unleash Your Enthusiasm” pattern has inspired me to embrace my natural curiosity and excitement for the field of software development, while also modifying that enthusiasm with an understanding of the importance of navigating team dynamics and building strong relationships with my colleagues. As I continue on my apprenticeship journey, I am committed to maintaining this balance, using my enthusiasm as a catalyst for learning and growth, and ultimately, becoming a valued contributor to the software development community.

April 7, 2024

andicuni

From the blog CS@Worcester – A Day in the Life as a CS Blogger by andicuni and used with permission of the author. All other rights reserved by the author.

Unleash Your Enthusiasm

For this week’s blog, I decided to discuss the pattern from Chapter 2 called “Unleash Your Enthusiasm”. This pattern discusses the enthusiasm for learning that many software engineering apprentices experience and how you should show it because, at this point in your career, you can provide unique qualities. This section discusses the situation where you may find yourself holding back because you may find that you have more enthusiasm than your colleagues. This is because there may be pressure to conform to the norm whenever you work on a team. In addition to this, many teams mainly focus on delivering the next product or improving on the aspects of the development life cycle. It also explains the risk of exposing your enthusiasm to an established team. In this situation, the text explains if the morale of the team is low or if they are not very welcoming to newcomers, you might make a poor impression. In this case, the text mentions that the advice in the section should not be applied blindly because you need to consider team dynamics.

The reason that I decided to pick this pattern is that I have never thought of concealing or holding back my enthusiasm for my craft. Every team that I have gotten the pleasure of joining in some way really valued my enthusiasm and the skills that they could learn from me. I have always been on a team where we all encouraged each other to learn from someone else on the team. Needless to say, I have never thought about the possibility of making a bad impression because of my enthusiasm for the task. In hindsight, I can see how exposing your ignorance of a topic can upset a team that values competence over enthusiasm for learning. I do think this quote from the text holds truth to it because of my own experience: “it is actually healthier for a team to consist of people with varying levels of experience”. Tech is a fast-paced industry so everyone is forced to keep up with new trends. A team that has a diverse set of skills at different levels is bound to create a healthy environment. With that being said, I can’t say that I disagree with anything from this section but I will be more aware of unleashing my enthusiasm on certain teams.

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.

Draw Your Own Map

The draw-your-own-map pattern talks about how people should take control of their career paths and not rely on others to define their path. This pattern talks about identifying the next logical steps, visualizing how to achieve those steps, and continuing to evaluate their goals and values. Draw-your-own-map pattern suggests that getting help from like-minded people and being open to adjusting one’s map to any changes that came up. This pattern shows stories about people who go into programming despite challenges from employers and orginizational limits. Draw-your-own-map encourages people to set a specific goal rather than setting a goal that isnt reachable. That step not only helps provide feedback but it also makes you seek guidance from like-minded people, those people can give you resources and support when trying to achieve your goals. One of the key ideas of this pattern is flexibility, it supports the idea of one’s mind to keep reassuring themselves that it’s okay to make changes. This pattern promotes an approach to career development and make sure to empower people to find their way through there careers with a purpose.

I thought this pattern was interesting because it encourages people to be creative and not rely on other people to define our paths, it should be our decision. I also thought the steps that the pattern talks about was very helpful, it’s important to set realistic goals so that you don’t overwork yourself to reach that goal. Visualizing the steps to achieving those goals also help make sure you don’t rush through the process and able to have a set plan. Evaluating your goal and values are also important as you go on to make sure that you can still reach your goal and be okay with any changes that come. This pattern has changed the way I think about achieving my goals, I know now to set a more realistic goal for myself and not be scared to get help from people who think like me. I don’t disagree with this pattern because I feel like this will help a lot of people with reaching their goals and make them think more realistically while getting support from others.

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

CS-448 Week 9 Be the Worst

The “Be the Worst” pattern encourages you to surround yourself with individuals who excel in their craft, even if it means being the least skilled person in the group. By doing this, you engage yourself in an environment that fosters continuous learning and growth, as it exposes individuals to new perspectives, challenges, and techniques that may not occur otherwise.

I find this pattern both interesting and thought-provoking because it challenges the traditional notion of seeking out environments where one is the most skilled or experienced. Instead, it encourages the embracement of discomfort and for individuals to seek out opportunities for improvement, even if it means initially feeling inadequate or out of place.

Embracing this pattern has caused me to reconsider how I approach my career and professional development. I have been inclined to seek out roles or teams where I felt confident in my abilities in the past, always fearing the possibility of struggling or being overshadowed by more experienced peers. However, I can see the value in seeking out environments where I am the weakest member after my reflection on this pattern. This will give me the chance to push myself to learn and grow at a faster pace, ultimately becoming a stronger and more versatile developer.

While I generally agree with the principles outlined in this pattern, I do acknowledge that it may not be suitable for everyone or in every situation. Some individuals may thrive in environments where they are the most skilled, finding comfort and confidence in their expertise. Additionally, constantly being the least skilled member of a team can be emotionally challenging and may require a certain level of resilience and self-confidence to navigate successfully.

Overall, the “Be the Worst” pattern serves as a reminder of the importance of humility, curiosity, and continuous learning in one’s professional journey. By seeking out opportunities to surround oneself with individuals who are better than them, individuals can unlock their full potential and achieve greater success in their chosen field.

4. Accurate Self-Assessment | 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.

Week 9 Blog Post

Choosing a topic for this week I tried to find something we had recently touched upon. Last week we went over mocking and expanding my knowledge of this topic can benefit me and the class. Searching for articles about mocking I stumbled upon one that shares the negatives of using mocking data. To counter-attack the ideas we learned in class it is always great to know both sides to using a concept. 

This article doesn’t fully dispose of mocking but gives ideas when it’s good to use. It gives a variety of examples including “Isolating the unit under test from other components or dependencies that are not relevant to the test, Speeding up the test execution by avoiding network calls or database queries that can be slow or unreliable, and Controlling the test input and output by creating predictable and consistent data that can be easily verified”. These ideas are then counterposed to the negatives such as “Introducing errors or inconsistencies between the mock data and the real data, which can lead to false positives or false negatives in the test results, Reducing the coverage and confidence of the test, by not testing the actual behavior and logic of the external source or the interaction with it, and Increasing the maintenance and complexity of the test, by requiring extra code and logic to create and manage the mock data”. The flaws of mocking data are mainly it does not use real data making it much more different from the real data creating disparities between the two. These tests ignore scenarios with much more complexity and these error and bugs can go unseen. The author assures the reader to use a data source to improve the tests.

After reading this article it gave me insight into the negatives of using mocking. The week prior activities made the use of mocking reduce time in creating classes but it’s good to know when it should be used and when it shouldn’t. I wish there was a perfect solution for every test but to find bugs in your code you must expand your horizon. Reading this article made me see that a variety of tests testing different things can overall benefit you. You never have to completely ignore a type of test but being able to see the positives and negatives can save you in the long run. Plus it will allow you to have a broader knowledge knowing that this may have flaws but there are things I can add to have a satisfactory end product.       

View at Medium.com
https://medium.com/@queenskisivuli/why-mocking-data-is-a-bad-practice-for-testing-a20d2d7104aa
View at Medium.com
View at Medium.com

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