This week, I explored the blog post “Rebasing: What Can Go Wrong?” by Jessica Rose, a software engineer who delves into the potential pitfalls of using Git’s rebase command. In class, we use Git extensively, which made this post especially relevant. Rose provides a detailed explanation of rebase, a tool used in Git for streamlining commit histories. While it can be incredibly powerful, Rose emphasizes that it’s easy to make mistakes that can lead to confusion, conflicts, or even the loss of code changes.

The blog post highlights several common issues developers may encounter while using rebase, such as accidentally overwriting commits, losing track of the original branch history, or making errors when dealing with merge conflicts. Rose walks the reader through how to prevent these issues, offering advice like creating backups before rebasing and using interactive rebase for a more controlled process. She also provides helpful tips for handling conflicts during the rebase, stressing the importance of careful attention to detail and understanding the consequences of each decision made during the process.

I chose this blog post because it directly relates to our class’s frequent use of Git. Git is a powerful version control system that helps manage code, but as we work with it, we often encounter challenges in mastering commands like rebase. Understanding the nuances of rebase can help avoid the frustrations that come with making mistakes in a shared repository. This post offered practical insights into some of those mistakes, providing guidance on how to handle them more effectively.

What stood out to me the most was how Rose emphasized the importance of understanding what’s happening at each step of the rebase process. It’s not just about executing commands but also being aware of the impact on the entire commit history and potential conflicts. I found this especially helpful, as I’ve been guilty of rushing through Git commands without fully grasping their implications. The blog helped me realize that, even with powerful tools like rebase, the key is taking time to understand the underlying mechanics and risks involved.

The material from this post will certainly influence how I approach Git in the future. I now feel more confident using rebase, knowing that I should always create backups before rebasing and be mindful of merge conflicts. In future collaborative projects, I’ll make sure to use interactive rebase more carefully, ensuring I don’t overwrite commits unintentionally. Additionally, I’ll aim to avoid common mistakes like rewriting history that others depend on.

Overall, Rose’s blog provides an insightful and practical guide to understanding rebase and avoiding its common pitfalls. For anyone who works with Git or is learning it, I highly recommend reading the post to better understand the potential risks and how to manage them effectively. It’s a perfect resource for improving Git workflows and ensuring smoother collaboration in teams.https://jvns.ca/blog/2023/11/06/rebasing-what-can-go-wrong-/

From the blog CS@Worcester – CS Journal by Alivia Glynn and used with permission of the author. All other rights reserved by the author.

https://www.blackduck.com/blog/generative-ai-risks-in-software.html

This blog posts discusses the issues that AI generated code causes for licensing caused by the use of proprietary code in model training, and issues for coding standards caused by the varying quality of AI code. I chose to look at this blog because I know many of my peers, including myself, occasional use AI to generate code for debugging and for small chunks of code that they don’t feel like making on their own for the sake of efficiency. Even in these small cases, we run the risks proposed by the blog.
Reading this blog made me reflect on how I use AI in my own coding, especially as it relates to coding standards. Typically I use it for debugging, which really means the only thing I need to concern myself with is making sure I understand the adjusted code and it follows the same formatting I used. However, this has affected my thoughts about using AI for small snippets that would be more efficiently written with AI. Upon reflection with the article, it made me realize the reason we allow AI to write code, is the same reasons we always write bad code; we just want to get it done. The most interesting part is, it also has the same consequences as just rushing to get it done. There have been a handful of times when I’ve been looking at a peer’s code, and it did something I thought was quite impressive, then I went to ask them about the functionality of it, but they were unable to do the fact that they were not the ones who actually wrote the code I was interested in, and it was so abstracted that they themselves did not really understand it.
I will admit I’ve had similar things happen before. For example, there was one time when I was working on a project, and there was a method I had to write that was very annoying. So I asked an AI to write it for me so I could move on with my project unannoyed. The code it wrote functioned in the tests I gave it, and it was even formatted correctly, it also had comments that describe what it was doing. Later on in the project I was getting very ludicrous results, and I had no idea why. After a while, I went back to the code and realized, the comments it wrote basically just recited the prompt I gave it, and did not actually describe what it was doing. After making attempts at fixing it, I ultimately had to completely rewrite the method on my own, wasting much of my time. My experiences as well as this article have allowed me to realize just how important writing clean, and understandable code is, and why we should avoid trying to cut corners on our projects even if it seemingly save us time. It is far more important to make good code at an efficient, than generate functioning code at a fast pace.

From the blog CS@Worcester – CS ZStomski by Zachary Stomski and used with permission of the author. All other rights reserved by the author.

So, this video here is by a channel called Software Developer Diaries and is a quick rundown of what software licenses are and to avoid the dangers of not properly dealing with a software license. As well as going over the different types of licenses and the particulars of each type. I decided to look more into the topic of software licenses as I felt I wanted another perspective from someone in the field who was actively developing and using licenses. Also, I felt I needed a bit of a refresher on the different licenses and this quick video seemed perfect. Everything in this video is kind of exactly what you would expect aside from using a few examples of each license and then providing some use cases for each license. There were a few things I did learn from this video like permissive cases being the most popular form of license or how I forgot that copyleft licenses are freely used but can have different stipulations based on the license. Otherwise, I thought a lot of this information was nice and succinct and helped quite a bit to remember the importance of why we even use licenses and also to remember what each license does specifically. I think this video did reveal me to me some questions while I was watching it. It made me consider how in the future I will probably be constantly tangling with licenses all the time when using some kind of proprietary code or some piece of code I found somewhere and that I’ll need to remember to always look for the license file whenever I’m in github or something similar so as to avoid any kind of legal repercussions or worse. So for me this tells me to expect quite a bit of future annoyance and stress down the line but if I can just memorize the various licenses and what they are now I’ll be able to know what each does at a glance when I’m hunting for code. But otherwise this does make me wonder if there are other licenses other than the ones mentioned in this video, also it makes me wonder about why we initially started to use licenses. I understand now why we currently use them but what was the impetus for starting to use them? But that’s something to think about in the future, for now I need to concentrate on remembering the rest of these licenses.

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.

In the world of software development, design patterns have long been touted as the foundation for writing reusable, scalable, and maintainable code. However, in his blog post “Rethinking Design Patterns,” Jeff Atwood, the founder of Stack Overflow, offers a criticizing look at the overuse and potential drawbacks of design patterns. Atwood argues that while design patterns can be incredibly helpful, they are often overused or misapplied, leading to unnecessary complexity and rigid software designs, highlighting that the key to good software design is not slavishly applying patterns but ensuring that the solution is simple, clear, and flexible

I chose this blog post because it directly relates to our course’s exploration of design patterns and software design principles. Throughout the course, we have discussed the value of design patterns as reusable solutions to common problems, but Atwood’s post reminded me that patterns should not be applied indiscriminately. The post offered a necessary counterpoint to the overwhelming focus on patterns, encouraging me to prioritize simplicity and clarity in code design. The Duck Simulator assignment in our course is a perfect example of how design patterns can either simplify or complicate a project, depending on how they’re applied. Initially, in the Duck Simulator, we began with a simple inheritance model where different types of ducks, such as MallardDuck and RubberDuck, inherited from a common Duck class. While inheritance is a useful mechanism for shared behaviors, it quickly became clear that adding new duck types with unique behaviors (like the RubberDuck that doesn’t fly) led to a rigid structure that was difficult to modify.

This is something I’ve experienced in my own coding assignments: sometimes, I’ve reached for a design pattern without fully understanding the problem or whether the pattern was the best fit. For example, I have often used the Strategy Pattern when refactoring code, but I now realize that I may have overcomplicated simple problems that could have been solved with more straightforward solutions. Going forward, I plan to apply Atwood’s advice by being more discerning in my use of design patterns. Instead of immediately opting for a design pattern, I will first evaluate whether a simpler solution exists.

You can read the full post here: Rethinking Design Patterns.

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

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.

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.

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.