This week, as we’ve been learning a lot more about Git and different features of it, I decided to find an article that talks about different commands that we may have not used and what they do. The article I found titled “Modern Git Commands and Features You Should Be Using” by Martin Heinz, explains some newer(ish) commands in Git that people still may not know about or just hardly ever use.

He opens up with the switch and restore commands but these are commands we’ve already learned about and used, so I’m going to skip over these.

The first one he mentions that I had not heard of is “sparse-checkout”. If you have a large repo with many different individual directories, it can cause certain commands to run extremely slow such as the normal “checkout” command or the “Status” command. With sparse-checkout, you can configure git to only checkout files in a specific directory. You would then use sparse-checkout set to download or checkout that specific directory. As you can see, this would be extremely useful in scenarios where you have a massive repo with a large amount of directories. Being able to specifically select the directories you want, rather than having to deal with all of them on more generalized git commands can be a huge time saver which is certainly a value many programmers hold highly.

Another command he mentions, which I find to be extremely cool and probably one of the most useful commands I’ve seen is “bisect”. Essentially, you run a “git bisect start” command linking a commit that does not work, as well as the last known working commit. Bisect will find the halfway point between these two commits, and you can either say “Good” or “Bad” depending on whether or not the commit is selects works or doesn’t. From there, it will keep on going halfway until it finds the exact commit where the errors that stopped the code from working started. This seems to be an extremely useful and honestly just cool command as it makes the process of finding the issues within a given program a million times easier. It is a command I will certainly be using in the future, probably a lot, and I’m very glad someone was keen enough to actually make this a working command.

Overall, the two commands I spoke about seem to be extremely useful, especially bisect, and I will certainly hold onto them for future reference in Git. Heinz also mentions the “Worktree” command but, while this command also seems quite useful, I found the other two to be much cooler as well as understandable to use. It also opens my eyes to the fact that there are also many other git commands and features that could be utilized, and I’m definitely going to look into the rest of them as I am sure I will find a few more very useful commands.

Source: https://martinheinz.dev/blog/109?utm_source=tldrwebdev

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 decided to find another Reddit post as the last Reddit post I covered I felt had a lot to take from it as it was a community of people giving their real thoughts and feelings on a certain aspect of Comp Sci. Today, I found a post on the importance of object-oriented design, and people discussing the different values it holds.

One of the top comments on the post is about how understanding object-oriented design is a great foundation for writing clean code, which is something we discuss in CS-348. It isn’t necessarily something you can just learn on the go while working, and, rather something you should try to learn about as much as you can while in school to then apply in the workplace. I’m very appreciative of reading this actually as I typically like to think most stuff gets easier to apply/learn as you’re working, but if a lot of people agree that you should understand as much as you can about object-oriented design BEFORE actually starting a job, then it’s certainly something I’m going to want to have down. The general consensus wasn’t that you won’t get better at applying these principles as you progress in your career but that you should have a strong foundation of knowledge on these principles going into your career as it is crucial to know certain aspects of it, like when one object ends and another begins or how to model object relations.

OOP is so important, many of the Redditors on this post also seem to agree that you’ll find it very hard to even get a job if you don’t at least have a base understanding of the concepts. It isn’t necessarily hard to understand a lot of these concepts as they’re pretty fundamental, but you should be able to answer questions either directly related, or somewhat related to OOP in job interviews as if the interviewer begins to think you may not know what you’re talking about, you may quickly lose your opportunity at that job. Some people did make comments explaining how it does depend on the concept of the job too such as the primary language you’ll be programming in or even the exact role of your job, but the general consensus still seems to be that you want to have at least a strong fundamental understanding of object-oriented design and the ability to apply it’s principles in your coding.

There are over 100 comments on this post that all make great points on why understanding these principles are very beneficial to you, even just a fundamental understanding of them can help you go a long way. It seemed to me that people had varying levels on how important overall understanding all of these principles are, but they all seemed to agree that knowing the basics of them and being able to apply them all to some degree in your coding, as well as being able to understand and talk about them (in interviews especially), is certainly the most important/beneficial thing you could do.

Source: https://www.reddit.com/r/learnprogramming/comments/z2fcyb/how_important_is_object_oriented_design/

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 an article that actually only recently came out about 8 days ago. The article, titled “Academic papers yanked after authors found to have used unlicensed software”, dives into two authors who had their paper retracted from an academic journal because of their use of a software in which they did not obtain a license from.

The authors used a software called “FLOW-3D” to help them calculate results exploring dam failures. When the parent company, appropriately named “Flow Science” found out about this, they made a complaint and were quickly able to have the papers taken down by  Elsevier’s Ain Shams Engineering Journal. The journal’s editor-in-chief even stated: “One of the conditions of submission of a paper for publication is that the article does not violate any intellectual property rights of any person or entity and that the use of any software is made under a license or permission from the software owner.”.

I find this to be an important issue that should be certainly talked about. This semester, we already learned of the importance of obtaining these licenses for a multitude of reasons, but I don’t believe we saw any real life examples of consequences if you didn’t. This article shows that, especially if required by a certain company, journal, or any sort of entity, using software or creating software and not properly getting a license for it can have repercussions. While I’m unsure if I’ll be writing an academic paper in the near future, I imagine at some point, if I further my education, I will. And if I do, and I need to use software in a similar manner to the people in the article used it, I will certainly make sure I am not breaching any sort of guidelines or laws set in place when it comes to the software licensing.

The article also mentions that, in 2023, over 10,000 research papers were retracted, which is a new record. I’m unsure if these were all due to licensing issues or if other issues were involved as well, but it still proves the point that it is taken very seriously and you can face the repercussions if you are not careful.

There are also many other types of consequences you may face by not getting licenses when it is necessary, but I think this article may be a good one to read especially if you plan on writing a paper or study at some point with which you used software to help solidify your paper. It is always good to be aware of what you need to do to be able to appropriately write a paper first, so you don’t have to deal with potential consequences if you don’t.

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

The article I read this week was called “The Art of Writing Amazing REST APIs” by Joy Ebertz. In this article, Joy explores the principles for designing effective REST APIs. It discusses key practices such as naming conventions, including IDs and types, ensuring resource stability, and bridging gaps between current and ideal API states. I’m going to get into some interesting points or ideas she has, and talk a little bit more about them. To wrap it up, I will explain how I think it could be beneficial to take, or at least consider, the principles she describes and apply them to a project down the road.

The first thing she talks about, which I believe is one of the more important things she brings up as well, is consistency. It is the foundation to writing great REST APIs. Consistency can be, and should be, applied to every aspect of writing REST APIs as, when everything is consistent, confusion will be kept to a minimum which should be what everyone is aiming for. If one endpoint returns user_ID while another returns simply ID, you can see where confusion could occur. Thus, standardizing these things can make everything much more efficient.

Another point she mentions is that every resource should include a unique ID and Type field to ensure clarity/stability. Unique IDs prevent ambiguity, enabling resources to be fetched or referenced consistently and effectively. Including a type prepares APIs for future flexibility, such as supporting multiple resource types in a single response.

Joy talks about many different principles and ideas to writing REST APIs but the previously mentioned principles were a couple of the more important ones I believe, as well as just my favorite ones in general.

Career-wise, I think applying these principles would be very smart to do. Shooting for an extremely consistent REST API benefits everyone involved with it, and using unique IDs and Type fields only produces further benefits. Applying all the principles she mentions in the article would certainly be the best way, or likely one of the best ways, to write REST API, but obviously different people may find different things they like better so there may always be some differences in opinion over writing a good REST API. If anything, you should at least take from the article the principles she presents and try to apply them, in one way or another, to future writing as it would really only advance your skill on the matter regardless. This is certainly something I will try to apply given the opportunity.

https://jkebertz.medium.com/the-art-of-writing-amazing-rest-apis-dc4c4100478d

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 an article questioning the relevancy of UML as Agile development processes are becoming more and more used today. This was an interesting article for me to read as it points out some of the flaws with trying to use UML while developing software with Agile, but also a couple of potential ways it can still be useful. The overall notion I got from reading this article was that UML has it’s time and place, but it is certainly becoming a thing of the past as developers start to lean more toward an Agile development process.

The article states that in an Agile environment requirements are typically not defined in detail prior to starting the project, as well as the design of the software. As the project progresses, the requirements and design will usually evolve over time. Also, formal documentation during a project isn’t as much of a necessity while going through an Agile development process. These three big components of Agile clash quite a bit with trying to implement UML as UML pretty much requires the exact opposite of these three components. Basically, you can’t define the design and details prior to the project because of insufficient information which you would need with UML, and it would also need a lot of effort to update the UML diagrams as the project evolves.

There are a couple ways UML diagrams could still be useful as listed in the article as well:

Once development is completed, it may be helpful to use UML diagrams to support the system. Using UML to define and standardize the architecture would also be another reason to still practice it.

I think, as I stated earlier, there is a time and a place for using UML. Obviously, if you haven’t adopted an Agile development process then UML could still be on the table to use; most people do use Agile now though. Because of this, you can certainly still use UML diagrams, but if you want it to be in an efficient manner, it should be used in one of or both of the ways mentioned directly above. It’s still great to have the knowledge of most certainly, as UML from what I’ve read and heard other people speaking isn’t completely outdated, but it definitely isn’t going to be something worth stressing over if you’re not the most knowledgeable on how it works.

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 Reddit post from just about a year ago on clean code. The post is asking people basically how they feel about “clean code”, so I thought it’d be interesting to hear some people’s takes on clean code and what they may like or dislike about it. The post links an article, “Goodbye, Clean Code” and while I will really just be getting the Redditor’s thoughts/opinions on the article and their overall takes on clean code, I will still post this article at the end of the blog as well.

The top comment on the Reddit post tries to sum up the article by saying it’s more or less about not passing judgment on someone’s written code without knowing the tradeoffs first. Doing a quick read through of this article confirms this, which I believe is a great point to make. Code may not ALWAYS be the cleanest, but before you go ripping into the structure of it, you may want to try to understand it first. A reply to this comment, which was the most liked reply so probably the most agreed upon point, was that coders should write comments when a line or lines of code are dirty due to a tradeoff. This, I completely agree with. If the code is recognizably dirty and it’s due to something really out of your control, I find it perfectly acceptable to write a comment explaining this so there is no confusion.

Another comment I found, which was within a thread of comments, was talking about “Clean Code” written by Uncle Bob. We learned a lot about Bob’s ideas on clean code during class, which was very beneficial. I will note though, he came across as very strict and stubborn on the rules. A comment in this thread clarifies this though by explaining how Uncle Bob, very early on in chapter one, states that people may “violently disagree” with him and that’s completely okay. So while he may be stern under his own volition, he understands where some people may draw a line.

Reading through all of these comments, I came to realize that while yes, clean code certainly is important, it’s only important to a degree. There are going to be projects where you may not be able to keep the code super clean, and you should then shift focus to keeping it as clean as POSSIBLE, and perhaps commenting on areas where it just wasn’t possible. It also is not the end of the world as some people may make it out to be, if you are unable to keep it extremely clean.

https://www.reddit.com/r/programming/comments/180evou/what_is_your_take_on_clean_code/

https://overreacted.io/goodbye-clean-code/

From the blog CS@Worcester – RBradleyBlog by Ryan Bradley 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.