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.

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.

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.

Christopher Okhravi explains in this video what a Strategy Design pattern is and how it works through some UML class diagrams and a little bit of pseudo-code as well as stopping at each point to explain each piece of the Strategy Pattern. All of this coming from a book called “Head-First Design Patterns” by Eric and Elizabeth Freeman. I wanted another viewpoint on the strategy pattern outside of class and in a more succinct form, so this video seemed like a good resource. Mr. Okhravi actually really cleared up a lot of the misconceptions I had about the Strategy Pattern in general, as the entirety of the video is essentially just one big example walking through each step of the Strategy Pattern process, even using the same example we had in class of the duck classes, although he does go into explaining each detail of the Strategy pattern thoroughly going into how inheritance is nearly as important as cohesion for this pattern. It also led to the revelation for me about not even needing subclasses and introducing the idea that cohesion was more important than inheritance with cohesion leading to more flexibility than just straight inheritance. Learning about this design pattern actually really helped to me to better understand how I would apply this when actually writing code, it also put the other design patterns we’ve learned about into a better perspective for me and kind of how powerful they really are. Other than this it also showed me that I didn’t really understand how the strategy pattern worked or what a design pattern completely was. But now thanks to this video I’ve definitely developed a better appreciation and a better understanding of how these design patterns work. From this point forward I’ll need to really have more supplemental material for every patter we learn about so I can actually interface with them properly. I think in the future I’ll really have to spend time learning more about other design patterns and their uses as these seem highly valuable to really understand and know how to use. Also, for any further delves into the other design patterns I’ll probably be going back to this creator here as he seems to have a good grasp on them and explains them clearly enough with the visual component for me to really understand it. I highly recommend giving this and his other videos a look as he sorts them into playlists for easy viewing.

Here’s the video on the Strategy Pattern.

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

In this presentation we are presented with a veteran of the IT industry, an author of the AGILE manifesto and manifesto for Software Craftmanship, and a man who hates that AGILE has been kidnapped by consultants and conference organizers and abandoned programmers, Robert C. Martin or better known as Uncle Bob. Now I wanted to watch this because I wanted to understand who this Uncle Bob person was and what he really meant by “Clean Code”. Uncle Bob’s first lesson starts off by giving us some examples of the scope and reality of software in our current day and age. He tells us how a person generally “can’t go more than 60 seconds without interacting with a software system” and then imparts some quick knowledge about why programmers are so slow. After this he then begins to break down this concept of “Clean Code” showing us what established and respected programmers think it us and giving us some examples of horrible first drafts of code that are nearly unreadable. Then after this showing us what refactoring this code looks like and then after this explaining some essential rules to follow when making your code clean. First and foremost, I really like listening to Uncle Bob as presents a lot of this information in an easily digestible manner and has excellent oratory skills that helped me really stay focused on the topic. The actual topic at hand was actually rather interesting, such as Uncle Bob explaining how teams get progressively slower and slower as they add features into a program due to the program becoming a bit of a monolithic mess. Or outlining a rule for functions to be as small as possible as “Long code is bad code”. Some of the topics Uncle Bob talked about were things I had no idea about like this Lambda feature he kept talking about in Java code, but that’ll have to be something I look into in the future. I think personally all of this has really given me a better perspective into what I should expect to be doing as a developer and how I should think about my code as I’m writing it. Mainly how my code should be organized and structured and especially what my workflow would look like, where I first write the code and get it working and then go back and make it clean. In the future I fully expect to be administering these principles into my code and career, and it would probably make sense to continually do this as it will not only make all my work easier for myself but also easier for my colleagues.

-Antonio Romeo

Also, here’s a link to Uncle Bob’s first lesson.

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

This blogpost by Martin Fowler was very interesting! It gave a very thorough and comprehensive look into what makes the agile methodology so different from older methodologies, which were very bureaucratic and abrasive when it came to change. It also showed why the principles of the more flexible, adaptive agile methodology helped to give more freedom to the developers and helped to create a better product for the developer’s clients. Reading all this put it into perspective for me how I will most likely be using this methodology in the future when I eventually go out to begin working and how this would really help to tighten up a team’s workflow and give them a better ability to put out a quality product. I really liked how as the post progressed there was a sort of small history about agile and how this blogpost was originally actually a means of pulling together most of the original ideas for the agile methodology in the past. I also understand now that agile really is just a perspective you need to have while working with a team and for a client that will help you to maintain a positive relationship with customers and maintain an efficient team. In the future I can assuredly see myself being apart of or using this methodology to develop software as it seems to be much more effective than older methods. The only thing I need to really look forward to is actually attempting to use the methodology as I don’t really have an understanding for how it would actually work or flow in practice. In essence, I think I picked this most of all because I still had questions about agile that have thoroughly been answered now, but I overall I hope for a chance to give it a try eventually in the future.

Summary: An in-depth discussion examining the difference in principles between the different methodologies of software process and an essentially original look at how agile developed and its methods, while also giving a sort-of mini history about agile and what it meant and means to developers.

Reason: I wanted a better more all-encompassing understanding of agile as I feel like I had heard this term outside of the course before, so I investigated it and came across this blog-post that seemed like it had a very detailed examination of it.

Blog Link: The New Methodology (martinfowler.com)

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

Looking back at this blog post it is a bit outdated, being posted nearly 2 decades ago but I still feel like it has a lot of quality information within it that can still be used today. I learned about several different architectures and their patterns that I thought were rather interesting. It was still a little over my head with a lot of jargon I didn’t understand, such as “Forms and Controls” and “Model-View-Controller” which is an apparently highly misconstrued architecture, that I had to look up, but I think this gave me a good look into what I can learn more about and where to direct my attention. I think in the future after I’ve learned some more basic architecture and design concepts, I’ll really be able to apply them and understand them more. Also, I’m a lot more interested in seeing more front-end things related to GUI and the process of developing a quality and useful GUI for a user. Now looking back at myself a little bit, reading this has really cemented for me how much I don’t know about the entire software development process. It truthfully shows me how I need to really pay attention and really work harder at developing my knowledge in the field as most of the blog post was entirely new to me and things I had never heard before which gets me excited about learning more! Also, all of the diagrams in the blog post were really neat and had a great effect in helping me understand the points of each pattern, so this has kind of helped me to understand how useful UML diagrams are and would be for designing and putting a program into and understandable and digestible format that makes it really simple to at a glance get what’s happening. I do think for my next blog post I may need to pick something a bit more my speed.

Summary: An interesting exploration of various architectures for GUI design and detailing their features as well as their underlying patterns within the architectures. Also is a sort of “intellectual history” of these varying GUI architectures.

Reason: I wanted to learn a bit more about GUI’s and how they work, this really details an almost historical record of UI development and how they work underneath. It also contains plenty of diagrams and detailed explanations that really helped me to better understand it.

Blog Link: GUI Architectures (martinfowler.com)

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