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.

Back again with another design pattern, and this time with one I have absolutely no idea about. I chose this particular video because I like this guy’s videos and I think he does an excellent job with explaining things in a way I can understand and I wanted to know some more design patterns. From another video by Christopher Okhravi I am learning about the Observer Pattern. Mr.Okhravi goes over this pattern with a lot of visuals which I very much appreciate and also goes into great depth with this pattern, but what does this pattern do? This pattern which involves utilizing one object that acts as the “Observable” and then this Observable object has a relationship with many “Observer” objects where if there is a change inside the Observable the Observable pushes out a change to all the Observer objects it’s connected to.

Looking at this pattern it’s kind of hard for me to wrap my head around an example of what it could be used for, but I did understand how the system itself would work, it just feels somewhat more complicated than I can really handle at this moment. Otherwise, though I did feel like I learned quite a bit about this pattern like how different languages have different variations and limits on what an observer pattern can do. Though the somewhat odd nature of the pattern does confuse me, even though it looks so simple. Like how it’s kind of cyclical where we are passing observer objects to the observable and then back again. This just really confused me but I think I’ll need to watch the video again to really grasp it fully. The example Okhravi uses of a “weather station” helped to really elucidate what I was confused about, where we have the physical components displaying the data and then the actual data that is being monitored by the weather station and watched by those observer components.

I think for the future I’m not really sure how often I’ll be using this pattern but I can foresee some use cases for it as it might be very useful when I need constant monitoring of something. But I think evidently even if I can’t come up with any ideas now I definitely think in the future I’ll be making use of this pattern and that I need to learn about even more patterns so that I can apply them where I need them, and to maybe go back and relearn those initial patterns I learned about.

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.

As an expressly visual and hands-on learner, I try to find resources that have decent practical visuals and explanations. In class we already do this, and I’ve already had the chance to have some practice with Git and various remote repo websites like GitHub. But I wanted to have a more succinct and shorter summarization of Git and how to use it. This video was actually perfect for that as it essentially runs through what Git is, how it’s used and what it’s used for and then goes over some complicated problems that can show up eventually when using Git. I mostly chose this specific video because of what I’ve mentioned previously where I was looking for something a bit more visual for me to sink my teeth into that I can extract information from as using git is still somewhat complicated to me.

Watching through this video was actually pleasant as it had lots of very appealing and easy to understand visuals with a lot of examples of everything discussed or mentioned in it. I very much enjoyed the experience it provided but it was still a mostly basic, more foundational resource designed to give a nice outline of what git can do and that I can really appreciate as I’m still relatively new when it comes to something like this. But seeing how git is more flexible than I initially thought was nice to know as I didn’t really connect that it also works with other repo websites other than GitHub, as I’ve only really had to use it in that instance.

But seeing the different applications of git and the different issues that can arise with it I am imagining that it will most likely be a headache that I’ll have to contend with very often, especially when it comes to merging problems. Hopefully though this will not be the case and every project I work on will go perfectly. Evidently though I can foresee that git will actually just be something I have to interface with on a most likely daily basis where I’ll be pulling, committing, fetching, merging, and pushing all the time especially if there’s any collaboration to be had. So, it would only make sense for me to really practice and understand the depths and complexities of what git can do, so for the near future I’ll probably be looking for something to take me into those depths.

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.

Growing up, sometimes when I would Google search things, the page would not load and instead, it would give me a code, typically a 404. I never understood what it was or what it meant until recently. The 404 is a REST API response code, a code that the server returns when a web page or URL requests something. There are a bunch of codes, ranging from successful requests to malformed URLs to unstable connections to the servers. But there is more to them than just response codes.

In this blog post, the Postman Team talks about everything REST API related, including their history, how they work, their benefits, some challenges, and go over some examples. REST API uses resources, which can be a number of things, such as a document, an image, or multiples of them. REST is able to use an identifier to determine the type of resource being used in interactions. REST API uses methods, which is the type of request that is being sent to the server. These methods are GET, PUT, POST, DELETE, and PATCH. Each does something different from each other, allowing the user and the server to do a multitude of actions. GET does what the name suggests, it asks the server to find the data you asked for, and then it sends it back to you. DELETE deletes the specified data entry. PUT updates the specified entry, PATCH will do a similar thing. POST will add a new entry. With these methods, they return codes, describing what happened with the request. 200 is a successful response, 201 is a successful creation, etc. There are a number of codes, going from 100 to 599, each with a different response. REST API is flexible, allowing you to do more with them. REST API is used mainly for web use, but can also be used in cloud services and applications. The benefits of using REST API include scalability, flexibility and portability, independence, and lightweight. The challenges of it though are endpoint consensus, versioning, and authentication. The blog post goes into detail about all this in their post.

I chose this blog post because it did a good job of explaining everything about REST API. It even has a YouTube video listed in the post, which also explains what is in the blog post. APIs are used everywhere, so it is interesting to learn about something that is essentially a part of all computer related things. Although this is REST API related, there are a number of APIs, each with something different that they offer.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

The Deep End

“The Deep End” pattern is about feeling unsatisfied with the path taken when learning new skills. The path taken has been small, safe steps that has made the learning process plateau. A way to jump start the learning process is by challenging yourself with bigger things such as bigger projects, working with larger teams, more complex projects, etc.

A solution to this pattern is to jump into the deep end, rather than waiting until you are ready. This is because the latter can lead to never starting anything, or challenging yourself to learn new skills. When a difficult problem occurs, rather than shying away, diving into the deep end and facing the problem head on is what will help in the long run. However there are some risks that are involved with going straight into the deep end. A risk is that you may get overwhelmed and fail. Although you may fail, failing is not necessarily a bad thing. Being prepared to fail, and recovering is what drives growth and provides opportunities that would be lost if the risk was never taken in the first place.

As mentioned before, in order to grow, bigger projects need to be made as a way to challenge yourself. Previous project’s size can be quantified by looking into those previous projects and marking down how many lines of code was written with how many developers. After reviewing all previous work, a chart can be made to see where how the next project compares.

Conclusion

I enjoyed reading about this pattern. I found the action to the pattern to be interesting because creating a chart, representing the size of your previous work, is something I would not have thought to do. However that process can be useful when determining if a project is at a large enough scale that can challenge previous projects. The pattern has changed the way I think about failure and taking risk. I like how the pattern paints the potential of failure as something that should be invited because I feel that failure is something that is not normally deemed acceptable. The pattern has ultimately changed the way I think about taking risks because risks and recovering from failures are what key to growth.

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.

Pattern Summary:

The “Dig Deeper” pattern from “Apprenticeship Patterns” advises aspiring software craftsmen to explore their craft beyond surface-level understanding. It emphasizes the importance of curiosity, continuous learning, and seeking deeper insights into software development concepts, tools, and techniques.

Reaction to the Pattern:

Upon reading about the “Dig Deeper” pattern, I was immediately struck by its relevance and applicability to my journey as a software enthusiast. What stood out to me as particularly intriguing and valuable was the idea of embracing curiosity as a driving force for growth. This pattern encourages us to go beyond mere familiarity with programming languages or frameworks and delve into the underlying principles, design patterns, and best practices that shape our craft. It has sparked a renewed sense of curiosity and passion for exploring the depths of software development.

Impact on Professional Perspective:

The “Dig Deeper” pattern has had a profound impact on how I view my intended profession and approach learning. It has shifted my focus from superficial knowledge acquisition to a more profound understanding of core concepts and foundational principles. By digging deeper into software development topics, I’ve gained a deeper appreciation for the intricacies and complexities of the craft. This pattern has reshaped my learning strategies, prompting me to prioritize depth over breadth and invest time in mastering fundamental concepts.

Disagreements and Critiques:

While I wholeheartedly embrace the essence of “Dig Deeper,” one potential challenge I’ve encountered is the overwhelming volume of information available in the software development realm. It can be daunting to decide which areas to delve deeper into and how to manage the depth of exploration effectively. However, I’ve found that setting specific learning goals, leveraging resources like documentation, tutorials, and mentorship, and focusing on practical application have helped overcome this challenge.

Overall Reflection:

Embracing the “Dig Deeper” pattern has been a transformative experience in my professional development journey. It has fueled my curiosity, expanded my knowledge horizon, and enriched my problem-solving capabilities. By diving deeper into software development concepts, I’ve gained confidence, resilience, and a deeper sense of fulfillment in my craft. This pattern has instilled in me a lifelong commitment to continuous learning and mastery, shaping the way I approach challenges, collaborate with peers, and contribute meaningfully to the software development community.

“Dig Deeper” serves as a guiding principle for aspiring software craftsmen, urging us to move beyond surface-level understanding and embrace the depths of our craft. By cultivating curiosity, seeking deeper insights, and mastering fundamental concepts, we pave the way for growth, innovation, and excellence in our profession.

From the blog CS@Worcester – Hieu Tran Blog by Trung Hiếu and used with permission of the author. All other rights reserved by the author.