Tag: CS-343

• Improving API Documentation

  OpenAPI and Swagger are huge tools that software developers use every day. It is extremely important to use when it comes to building clear, maintainable, and interactive API documentation. The name of the article I chose was “How to improve API documentation with Swagger and OpenAPI”. According to this article, APIs are central to modern software design, and their documentation plays a critical role in ensuring that developers can consume them and maintain them correctly. “Using the OpenAPI Specification with the Swagger ecosystem offers the much-needed standardization to REST API documentation”. Besides, it explains that the OpenAPI Specification is human- and machine-readable, it clearly states the structure of the API, its endpoints, parameters, responses, and data models. This in turn helps reduce ambiguity, which often results from loosely documented APIs.

  Besides these, there are several tools that come with Swagger, including the editor, UI, codegen, and inspector. It allows developers to design and edit OpenAPI definitions in JSON or YAML with built-in validation so syntax errors can be caught right there and then. The UI presents OpenAPI definitions as documentation that users can try API endpoints from within their web browser. Codegen produces client libraries, server stubs, and SDKs that facilitate rapid development on multiple platforms. Finally, the inspector is a tool for testing APIs directly and generating an OpenAPI definition based on existing APIs.

  There’s also an updated version, allowing for more modularity and an approach to defining the surface area of an API, with the official release of OpenAPI 3.0. This provides even greater flexibility in describing the request and response model of an API. Good schema and component reuse are emphasized in the most recent version, and handling of multipart documents. Advertisements.The reason I chose this topic was because we have been doing a lot of work with swagger and APIs, and I wanted to look closely into how vital it is to be a software developer in the real world. I also wanted to look closer into how swagger can improve my design skills. After reading this article, I started to see why proper documentation isn’t just something nice and handy but a necessity in being a skilled developer. From now on, I plan to strengthen my understanding of swagger and APIs because I think it will also help me in improving my coding skills and future project.

  Resources: https://www.techtarget.com/searchapparchitecture/tip/How-to-improve-API-documentation-with-Swagger-and-OpenAPI

  December 7, 2025

  @Quarter-4, CS-343, CS@Worcester

  ---

• Understanding Software Architecture Through Martin Fowler’s Lens

  Software architecture is one of those concepts that students hear often but rarely get a clear definition of. This week, I chose to read Martin Fowler’s Software Architecture Guide because it went into depth beyond surface-level definitions of architectural thinking that we usually hear. Since our course is so strongly focused on building maintainable and scalable systems, this resource fit perfectly with the themes we have discussed around design decisions and long-term maintainability in software projects.

  Fowler opens the guide by addressing one of the most debated questions in the software community: What, really is architecture? He explains how many definitions focus on “high-level components” or “early design decisions,” but argues these views are incomplete. Referring to an email exchange with Ralph Johnson, Fowler insists that architecture is about “the important stuff.” Architecture is not about big diagrams or an early-stage structural choice; it is about experienced developers having a common understanding of the parts of a system that matter for its long-term health. This makes architecture dynamic and changing rather than merely static documentation.

  Fowler also describes why architecture matters, even when end users never directly see it: A poor architecture leads to “cruft,” or the buildup of confusing, tangled code that slows down development. Instead of enabling fast delivery, weak internal quality ultimately hurts productivity. The argument here by Fowler is that paying attention to internal structure actually increases delivery speed because developers spend less time fighting the codebase and more time building features. What struck a chord for me in this is how architecture is coupled with practical results: maintainability, reliability, and team productivity.

  I chose this article because I really enjoy the topic and wanted to learn more about software architecture in depth. Fowler’s explanation really helped me understand that architectural thinking is something developers grow into by learning to identify what is truly important in a system. This directly connects with the principles we’ve discussed in class around clean code, modularity, and design patterns. Reflecting on the material, I realized that in future software projects, including class assignments, internships, I will have to think about how my design decisions today will affect my ability-and my team’s ability-to maintain or extend the system later. Good architecture supports future evolution, as Fowler put it, and this is something I want to actively apply as I head toward more complex development work.

  Resource: https://martinfowler.com/architecture/

  November 16, 2025

  @Quarter-3, CS-343, CS@Worcester

  ---

• Understanding Concurrency from a Beginner’s Point of View

  Concurrency is one of those computer science topics that, in theory, makes sense but somehow manages to be a little confusing in practice. In Concurrency 101: From a Beginner’s Point of View, Mrinal gives a straightforward and step-by-step discussion on how languages such as Python, JavaScript, and Go handle more than one thing simultaneously. My favorite was the way the author explained concurrency not as “doing multiple things at the same time,” but rather as making progress on more than one task without getting in each other’s way.

  The article starts by explaining the distinction between concurrency and parallelism, a difference that is essential for authors of responsive programs to understand. Mrinal then discusses the mechanisms that support concurrency: processes, threads, and event loops. Each of these has trade-offs, processes are heavier weight but safer, threads are lighter weight with the risk of race conditions, and event loops (like JavaScript’s) rely on non-blocking operations to stay efficient.

  There’s a large section on synchronization and how programmers prevent “chaos” when threads are reading and writing shared data. I liked the presentation of mutexes and semaphores. The chef example for describing deadlocks made it easy to see how two threads might be waiting for each other forever. Mrinal does discuss practical solutions such as lock ordering, timeouts, and try-locks, all patterns we’ve discussed in CS-343 when we’ve talked about safe concurrent design.

  The post then moves to lock-free programming and message passing and explains how atomic operations and the Actor Model can eliminate many synchronization problems altogether. I liked how Mrinal mapped these concepts to real systems like Go’s concurrency model and Apache Spark’s distributed processes, and how scaling depends on understanding which workloads are benefitted by which model.

  I picked this resource because concurrency has been one of the more daunting topics for me. Having the opportunity to read a post that was written from the perspective of another student made it that much more relatable. The analogies, along with real engineering explanations, bridged the gap between textbook theory and real implementation.

  I took away from this blog to conceptualize concurrency as orderly cooperation between tasks rather than chaos waiting to happen. It opened my eyes to how careful design choices, like tidy lock ordering or message passing, can make programs more correct and speedier. In the coming times, I will apply these lessons when I am working on multithreaded assignments or any program that demands responsiveness, like my Android application that I made this summer which communicates with a Flask backend. Having the fundamentals of concurrency under my belt will allow me to write cleaner, safer, and more scalable code.

  Resources: https://mrinalxdev.github.io/mrinalxblogs/blogs/concurrency.html

  October 26, 2025

  @Quarter-2, CS-343, CS@Worcester

  ---

• Polymorphism in Object-Oriented Programming

  Polymorphism was one of those programming words that used to sound scary the first time I ever heard of it. It literally means “many forms” but in OOP, it’s not as scary-sounding as it is. It’s basically when the same method or function can be something different based on what object it’s being called from. As soon as I started reading over some examples, it made a lot more sense.

  Think of it like this: an individual might be a class student, a home sibling, and maybe a work employee. Same person, various role depending on context. In programming, polymorphism enables us to do one thing with one function that changes its behavior depending on the object.

  There are two main forms of polymorphism. Compile-time polymorphism (or static) is solved before the program ever runs. That generally happens with method overloading, where you have multiple versions on the same method name with different parameters. The compiler figures out which one to invoke. Operator overloading is another example, like using “+” for numbers and strings too.

  Then there is runtime polymorphism (dynamic), resolved as the program is running. That is what happens with method overriding. A case in point is a parent class Shape that has a method draw(). Subclasses such as Circle and Square override draw() to do something else. When you call draw(), the program picks one that matches the actual object.

  First of all, I used to confuse this with inheritance. They definitely go hand in hand, but they are not one and the same. Inheritance is when you are copying another class’s code. Polymorphism is when you have the same method name but have different action.

  A lot of people also think that using polymorphism, especially the runtime kind, makes programs really slow. I used to believe that too, but it turns out that’s not really the case anymore. Modern compilers are built to handle this kind of thing quickly with tricks like virtual tables, so the performance hit is tiny. The trade-off is worth it because you get cleaner code and way more flexibility, so worrying about speed here feels kind of outdated.

  I’ve read about this and it struck me how many times I’ve made my own code overly complicated. In Java, for example, I used to create a whole bunch of methods with unique names when I could have done overloading. I also blocked overriding in subclasses because I believed that it would be slow. Now I know that not just is that fine, it’s the correct thing to do most of the time.

  In the future, I’d like to use polymorphism more intentionally, especially in my Android applications. It’ll be a tremendous assistance if new functionality is introduced in the future because I won’t need to begin anew. That, to me, is the beauty of OOP, it’s not just about making things function, but making them simpler to maintain and extend in the long run.

  Resources:

  https://www.cincom.com/blog/smalltalk/polymorphism-in-object-oriented-programming/

  October 2, 2025

  @Quarter-1, CS-343, CS@Worcester

  ---

• Maria’s Blog

  Hi everyone my name is Maria and this is my introductiory post for CS343!

  September 8, 2025

  CS-343, CS@Worcester

  ---