In the realm of web development, the importance of REST (Representational State Transfer) APIs cannot be overstated. They serve as the backbone of communication between client and server applications, facilitating the seamless exchange of data. My recent exploration of the article “Understanding REST APIs: A Comprehensive Guide” on Medium provided a deep dive into the intricacies of RESTful architecture, the principles behind it, and practical examples of its implementation.

I chose this article because it offers a holistic view of REST APIs, making it suitable for both beginners and seasoned developers looking to refine their understanding. The author does a commendable job of breaking down complex concepts into digestible sections, ensuring readers can follow along easily. The article not only covers the technical aspects of REST APIs but also emphasizes best practices and common pitfalls, which are crucial for anyone working with APIs.

One of the key takeaways from the article was the emphasis on statelessness in REST. Each API call is independent; the server does not store any client context between requests. This design choice simplifies scalability and reliability, allowing systems to handle multiple requests without the overhead of session management. Understanding this principle has reshaped my approach to API design. I now recognize the importance of making each API call self-contained and meaningful.

Additionally, the article highlighted the significance of HTTP methods—GET, POST, PUT, DELETE—and their respective roles in interacting with resources. This reinforced my understanding of how to use these methods appropriately to perform CRUD (Create, Read, Update, Delete) operations effectively. The practical examples provided illustrated how to structure requests and handle responses, making the learning experience both informative and applicable.

This material significantly impacted my perspective on API integration in my projects. Previously, I approached APIs with a surface-level understanding, often overlooking essential details that could enhance my applications. Now, I feel equipped to design and implement more robust and efficient RESTful services. In my future practice, I plan to apply these principles not just in personal projects but also in collaborative environments, where clear communication with APIs is crucial for successful integration.

In conclusion, “Understanding REST APIs: A Comprehensive Guide” served as an invaluable resource that deepened my understanding of RESTful architecture. The insights gained will undoubtedly influence my future work as I continue to navigate the complex world of web development and API integration.

For more details, you can read the article here: Understanding REST APIs: A Comprehensive Guide.

From the blog Discoveries in CS world by mgl1990 and used with permission of the author. All other rights reserved by the author.

This week’s blog post is about the differences between Visual Studio and Visual Studio Code. I wrote about this topic because we just started exploring development environments, and prior to Thursday’s class, I didn’t know these were even two different software packages. I had previously installed Visual Studio on my personal computer, and when asked to install Visual Studio Code, I thought I had it already. Upon realizing they are different suites, I realized that that distinction may have been the source of a lot of confusion and issues I was running into during a previous project, and therefore is an important enough distinction to discuss in the blog post. The resource I will be referencing is an entire thread I read through on StackOverflow, which was wildly helpful in understanding some of the key differences between the two. For anybody that (somehow) isn’t familiar with StackOverflow, it is a public forum where all kinds of tech people discuss code, useful field concepts, or really anything. This specific thread was a discussion about the two software applications and the differences between them, which I chose because StackOverflow has never failed me in a time of technical need. Here are some of the key distinctions I found.

Firstly, Visual Studio is a comprehensive Integrated Development Environment (IDE) designed  for larger applications, specifically those built with .NET languages like C# and VB.NET. It offers a ton of built-in tools for debugging, checking performance, and designing user interfaces. In contrast, Visual Studio Code is a lightweight, open-source code editor that supports a bunch of programming languages through extensions. It trades off some of the advanced features found in Visual Studio in exchange for flexibility and simplicity. VS Code is well-suited for web development, Python scripting, or small coding projects. It runs efficiently on less powerful machines, which makes it accessible for developers who may not need everything provided by Visual Studio.

One of the largest distinctions is in their intended use cases. Visual Studio is much better suited for working on complex applications that require extensive debugging and testing. For example, if you’re building a massive application with multiple dependencies and a need for thorough testing, Visual Studio’s comprehensive toolset can be extremely useful. Visual Studio Code is much better suited towards working with a variety of programming languages or with a more minimalistic setup. Visual Studio Code allows you to tailor your environment exactly to your needs through extensions and customizable settings.

Additionally, they differ largely in resource requirements. Visual Studio is bulky and requires a significant amount of storage and resources. Visual Studio Code is smaller and quick to install, making it a practical choice if you don’t need a full IDE.

In conclusion, choosing Visual Studio or Visual Studio Code largely depends on your project requirements and personal preferences. Each has its strengths and drawbacks. Moving forward personally, I will be using Visual Studio Code until a need for Visual Studio arises.

From the blog CS@Worcester – Mr. Lancer 987's Blog by Mr. Lancer 987 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.

In the world of computer science, especially for those new to programming, concepts like design smells and technical debt can seem daunting. However, grasping these ideas is crucial for building sustainable software. Design smells are indicators of potential problems in your code, such as overly complex structures or poor naming conventions. Technical debt, on the other hand, refers to the compromises made during the development process that can lead to greater issues down the line, akin to borrowing money that needs to be paid back later.

I recently came across the article “Understanding Technical Debt” by Tom Smith on Medium. This piece breaks down these concepts in an approachable manner, making them easier to understand for beginners. Smith discusses common design smells, such as “Long Method” and “Feature Envy,” and explains how they can accumulate into technical debt if ignored.

I chose this article because I believe it provides a solid foundation for understanding these concepts without overwhelming beginners with jargon. As I embark on my journey in computer science, I find it essential to learn about the long-term implications of my coding decisions. Smith’s article highlights the importance of recognizing design smells early on, which resonated with me as I often focus on getting things done rather than considering the quality of my code.

What I learned from the article is that design smells serve as early warning signs. For example, if a method is too long or complex, it may indicate that it’s doing too much and should be broken down into smaller, more manageable pieces. This insight has made me reflect on my past coding experiences, particularly a group project where we rushed to implement features without thoroughly reviewing our code. The result was a project that became difficult to manage and understand. I realized that by overlooking design smells, we inadvertently added technical debt to our project.

Moving forward, I plan to apply this knowledge in my coding practice by adopting a more mindful approach. I want to prioritize code quality and regularly check for design smells as part of my workflow. Implementing practices like peer code reviews and refactoring sessions will help ensure that my code remains clean and maintainable. I believe this proactive approach will not only enhance my skills but also contribute to a more positive team environment where everyone is encouraged to uphold coding standards.

In conclusion, understanding design smells and technical debt is vital for anyone starting in computer science. By paying attention to these indicators, we can write better, more maintainable code. I highly recommend reading Tom Smith’s article for a beginner-friendly introduction to these essential concepts.

Resource:
* Fowler, M. (n.d.). Technical Debt and Design Smells: A Practical Guide. Retrieved from Martin Fowler’s website.

* Smith, T. (n.d.). Understanding Technical Debt. Medium. Retrieved from Medium.

From the blog Discoveries in CS world by mgl1990 and used with permission of the author. All other rights reserved by the author.

I hear this a lot: getting into tech, and specifically software engineering, because of money. It certainly seems to be the case that many people since maybe the 2010s have worked on Computer Science degrees solely because of the income and luxury of it, rather than an actual enjoyment of it.

I always found myself good with technology. When I took my first Computer Science course in high school, I always ended up completing assignments in 10-15 minutes when the allotted time was around two class periods. This is what I’m good at, as far as I can tell, but that’s not necessarily enough for me to make a career off of. If I don’t care about it, then I’m stagnating. If my motivation is simply that I’m good at it, it doesn’t necessarily inspire growth.

These are two examples of unsustainable motivations. The idea is that we can get trapped in the motivations we set up for what we do, and they lock us into a (most of the time, negative) mindset. Instead of enjoying my day to day work, I’ll see it as just work, and want the day to be over as soon as it starts, without actually growing as a person or in my skill level.

While the solution given tries to offer a practical approach (writing down your motivations and how much they factor in to your decision to stay a software developer), I don’t necessarily think this is a strong solution. I’m inclined to say that you have to have a more inquisitive investigation to why you care about this career, and what is really motivating you. Ultimately, you yourself create this motivation, it’s not out there waiting to be found. You can either construct for yourself an enjoyment of the journey, or you can only care about the outcomes.

From this, I would say solely caring about outcomes is unhealthy, and that mindset lends itself to motivations like reputation and money. As such, you have to ultimately figure out how to care about the journey if you actually want to have some level of enjoyment in your career. Otherwise every day genuinely will be a soulless repetition of the last.

There’s a reason why Camus wrote that one must imagine Sisyphus happy. If Sisyphus were to redefine the pushing of that boulder as a journey, and the rolling down of that boulder as a satisfying conclusion and new beginning, then this punishment is not as severe. Of course, this requires a lot of mental effort, but I think it’s necessary to live a life that you can actually be happy with.

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

This week the pattern I decided to write about is from chapter 2. The pattern titled “Expose Your Ignorance” discusses something I’ve had to experience recently: letting those you’re working with fill the gaps in your knowledge. This section opens up with this quote by Jake Scruggs in “My Apprenticeship at Object Mentor”. The quote is “Tomorrow I need to look stupider and feel better about it. This staying quiet and trying to guess what’s going on isn’t working so well.” Opening this topic with that quote is impactful because I think a lot of people feel shame and would call themselves stupid for simple gaps in their knowledge when others have high expectations for them. It’s important to acknowledge that it’s okay to not know everything and be transparent about it instead of struggling alone while deadlines approach.

When I was working on a website with a group of other developers, we were all transparent with each other about our knowledge gaps for the tech stack we had to work with. This allowed us to play off of each other’s strengths and weaknesses. Some of us were more knowledgeable about the front end while others were more knowledgeable about what was required for the backend. I was more unfamiliar with what the front end required so I worked on the backend team. When we started working on the project, I was transparent about my lack of knowledge about JavaScript, routes, controllers, and HTTP requests. My team leader spent some time going over the material with me and provided some resources to research on my own. I then looked for more resources to learn. We also made an effort for everyone to learn a bit more about both the front end and the back end.

 In the text, it said, “Conceding to unspoken pressures and telling people what they want to hear is not a good way to build strong relationships.” I agree with this because our transparency made sure we were able to help each other grow and in turn strengthen our relationships with each other. Your reputation will be built off of your willingness to learn. There wasn’t any part that I could disagree with. When you’re honest about your ignorance you will end up picking up knowledge about a variety of technologies which will make it easier for you to adapt down the road.

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.

I would like to continue my reflection on my fundamental software development skills and how to reinforce them in this week’s blog post. The “Concrete Skills” pattern in the “Emptying The Cup” chapter of “Apprenticeship Patterns” by David H. Hoover and Adewale Oshineye describes the practice of building and maintaining your concrete skill set to make yourself a better choice for a professional role. Knowledge on how to write build files, familiarity with the standard libraries for your chosen programming language, basic web design, and JavaScript are some examples of concrete skills given by the authors. Possession of these concrete skills are what allow you to stand out as a candidate for a developer position. The authors recommend constructing “toy implementations” to demonstrate your understanding of these concrete skills in an interview.

I wanted to read and reflect on this pattern because recently I was challenged with a programming problem where I needed to iterate through the nodes of a linked list. I remember learning about the linked list as a data structure in a previous course, and now in the elective course that I’m taking, we’ve been tasked with implementing a linked list as well as performing operations on it. The implementation of each linked list node as an object with a ‘head’ containing data, and a ‘tail’ that functioned as a pointer to the next node in the list was familiar to me. Despite my previous experience learning about the linked list, I still spent a long time implementing a function that would do something and then iterate through the linked list. I knew I had to repeatedly set the head of the list to its tail within a while loop until the data ‘head’ of the list was empty. It was only with the help of my classmates that I rediscovered how to express that implementation in code and properly operate on each element in a linked list, and then exit the while loop once the ‘head’ member variable of the node was empty. I realized that while I believed that I understood basic data structures like linked lists, trees, and queues conceptually, I struggled with implementing those design concepts when put to the test.

The pattern’s recommendation to demonstrate your concrete skills through small-scale projects has me reflecting on my goals for a project I started a few weeks ago and have only spent a few collective hours on since. I’ve been wanting to practice my design patterns, so I started a Java project called “MonsterFactory” as an exercise. I have a collection of Java classes like Zombie, Werewolf, or Vampire that all inherit from a Monster superclass and share some member variables and methods. I want to implement a MonsterFactory class that follows the Factory software design pattern that could instantiate whichever Monster subclass we could want in any given situation. This project could serve as a functional example of my understanding of software design patterns, and I could also expand upon it to take advantage of the libraries offered in Java. I’m primarily working with strings and integers as data types in this project but learning how to work with images as a data type to accompany each Monster could be an entirely achievable goal for me to add to this project.

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

Summary of Craft Over Art:

The “Craft over Art” pattern delves into the distinction between craftsmanship and artistic expression within the realm of software development. It emphasizes the importance of prioritizing craftsmanship, which entails mastering the fundamental skills and techniques required to create high-quality software, over the pursuit of artistic flair.

My reaction:

Upon encountering the “Craft over Art” pattern, I found myself reflecting deeply on the essence of software development as a craft. What struck me most was the notion that craftsmanship transcends mere creativity or innovation—it embodies a dedication to continuous learning, refinement, and adherence to best practices. This perspective has profoundly influenced my perception of my intended profession as a software developer.

Initially, I was drawn to software development by the allure of innovation and the opportunity to unleash my creativity through code. However, this pattern prompted me to reconsider the significance of honing my technical skills and adopting disciplined practices. It made me realize that while creativity has its place in software development, it is craftsmanship that truly underpins the creation of reliable, maintainable, and scalable software solutions.

Moreover, the pattern’s emphasis on mastery resonated with me on a personal level. It sparked a realization that becoming a proficient software developer requires more than just technical prowess—it demands a commitment to continuous improvement and a willingness to embrace challenges as opportunities for growth.

While I wholeheartedly agree with the premise of prioritizing craftsmanship over artistry in software development, I acknowledge that striking a balance between the two is essential. Creativity and innovation undoubtedly drive progress in our field, but without a solid foundation of craftsmanship, they risk being mere flashes in the pan. Therefore, I believe that the key lies in integrating artistic expression with the principles of craftsmanship, leveraging creativity to enhance the quality and elegance of our code.

“Craft over Art” pattern has been instrumental in shaping my understanding of software development as a craft. It has inspired me to prioritize mastery, discipline, and continuous learning in my journey as a software developer, ultimately guiding me towards the path of excellence in my 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.