For my third blog, I read “Best Practices for Naming REST API Endpoints” from the DreamFactory blog. The article explains why clear and consistent endpoint naming makes APIs easier to understand, maintain, and scale. It focuses on something every developer deals with when building REST systems: how to structure resources so the API feels predictable and easy to navigate. Even though naming seems like a small detail, the article shows how much it affects the overall design of a system.

It explains that good endpoint naming starts with using nouns instead of verbs and keeping the focus on resources, not actions. Instead of naming an endpoint something like /createGuest, the blog says you should use /guests and let the HTTP method determine what action is being taken. So POST creates a guest, GET lists them, PUT updates one, and DELETE removes one. Reading that made me think back to what we’ve been doing in class with our Model 5 work, where we looked inside the src/endpoints directory and saw how each file maps to a resource. All of our endpoints follow that same pattern, which helped me see why the structure feels clean.

The article also talks about keeping paths simple and consistent. It mentions using plural nouns, avoiding unnecessary words, and sticking to predictable patterns like /guests/:id. When I went back to look at our endpoint files listGuests.js, retrieveGuest.js, replaceGuest.js, and so on, I noticed how everything lines up with what the blog recommends. Each file handles one resource and uses the method, path, and handler structure to keep things organized. That connection made the blog feel way more relevant, because it matched exactly what we’re practicing.

I picked this article because it ties directly into the work we’ve been doing in class with REST API implementation. We’ve been learning how to structure endpoints, read OpenAPI specs, and understand how operationIDs match the code. This blog basically explains the reasoning behind those design choices. It also fits with the design principles we’ve been talking about, like keeping things modular and easy to maintain as the project grows.

After reading it, I realized that endpoint naming isn’t just a style preference. It affects how fast developers can read the code, how easy it is to extend the system, and how clearly the API communicates its purpose. When the names and paths make sense, everything else falls into place. My main takeaway is that good API design starts with simple, consistent patterns, and naming is a big part of that foundation.

Link: https://blog.dreamfactory.com/best-practices-for-naming-rest-api-endpoints

From the blog CS@Worcester – Harley Philippe's Tech Journal by Harley Philippe and used with permission of the author. All other rights reserved by the author.

For my second blog, I read “Best Practices for Building a Secure and Scalable API” from MuleSoft’s API University. The article goes over how developers can build APIs that don’t crash when traffic grows and that keep user data safe at the same time. It focuses on two things every developer worries about: scalability and security, and how good design decisions affect both.

It explains that scalability is all about how well your API handles growth. Vertical scaling means giving one server more power, while horizontal scaling spreads the load across multiple servers. The author also talks about caching, async processing, and rate limiting to help APIs run smoothly when there’s a lot of traffic. That part made me think about our Microservices Activities in class, where we created REST endpoints and thought about how requests would move through the system. The same design choices we made like organizing resources clearly and using the right HTTP methods are what help APIs scale better in the real world.

Then it shifts to security. It breaks down the basics: use HTTPS for encryption, OAuth 2.0 for authentication, and proper logging to track activity. What stuck with me most was how it said security should be built into the design from the start, not added on later. That lined up with what we’ve been learning about maintainable design in CS-343. If you think about security and structure early, your system stays reliable long term.

I picked this article because it directly connects to what we’re doing in class. We’ve been designing REST APIs and talking about microservice architecture, and this blog felt like a real world version of that. It also ties into the design principles we’ve covered, keeping systems modular and loosely coupled so updates and security changes don’t break everything else.

After reading it, I realized scalability and security go hand in hand. You can’t have one without the other. A system that handles tons of traffic but isn’t secure is a problem, and the same goes for one that’s super secure but slow or unreliable. My main takeaway is that good API design is about balance, thinking ahead so what you build keeps working and stays safe as it grows.

Link: https://www.mulesoft.com/api-university/best-practices-building-secure-and-scalable-api

From the blog CS@Worcester – Harley Philippe's Tech Journal by Harley Philippe and used with permission of the author. All other rights reserved by the author.

For my first blog, I read “Software Architecture Patterns” from the ByteByteGo blog. The post explains what architecture patterns are, why they exist, and how they help developers organize software systems that scale and remain maintainable. It outlines several common patterns such as layered, event-driven, microservices, client server, and micro kernel, describing their main structures and the problems they solve. The article emphasizes that architecture is not about strict rules but about creating a structure that supports clarity, reliability, and growth.

The author shows how the layered pattern divides applications into presentation, business, and data layers, useful for simple or monolithic systems. Event driven architectures handle asynchronous communication, making them ideal for systems that must respond quickly to different events. Microservices split large systems into smaller, independent services that can be developed, deployed, and scaled separately. Client server architecture remains a foundation for most web applications, while micro kernel focuses on extensibility, often used in plugins or modular software.

I chose this blog because it connects directly with what we are learning in CS-343 about design principles, maintainability, and system organization. It presents architecture patterns as practical solutions rather than abstract theories. The visuals and examples in the article made complex ideas clear. Reading it helped me understand that the architecture pattern chosen for a project directly affects performance, scalability, and how teams collaborate.

What stood out to me is the focus on trade offs. Each pattern has strengths and weaknesses depending on the project’s goals. For instance, microservices improve flexibility but increase deployment complexity. Layered systems are easier to start with but can slow down change if dependencies grow too tightly coupled. This reinforced the importance of balancing simplicity, independence, and maintainability, key themes from our class discussions about SOLID and GRASP principles.

From this reading, I learned that good architecture is about creating boundaries that protect core business logic while allowing technology and frameworks to evolve. I plan to apply this by practicing modular design in future projects and thinking more critically before deciding on an architecture. Understanding patterns like microservices or event-driven systems will help me reason about trade offs when I design APIs or backend structures.

Overall, ByteByteGo’s article strengthened my understanding of architecture as the backbone of sustainable software. It made clear that design patterns are not only about writing code but about shaping how software grows over time.

Link: https://www.thoughtworks.com/en-us/insights/blog/architecture/demystify-software-architecture-patterns

From the blog CS@Worcester – Harley Philippe's Tech Journal by Harley Philippe and used with permission of the author. All other rights reserved by the author.

This week, while looking for blog posts to write about, I came across an article by Kiera Abbamonte on the Zapier blog called “The Best Free Project Management Software in 2025.” Kiera’s article dives into eight top project management tools that are totally free and packed with features for task management, collaboration, and keeping things productive. Zapier really went all out testing each one, breaking down what each tool does best. It’s a great find if you’re trying to manage projects without spending a ton.

Kiera starts off by explaining that while some people manage fine with just a to-do list or calendar, teams usually need more structured tools to keep everyone on the same page. When you’re working with others, it’s important to have ways to track tasks, communicate easily, and stay organized. Her list includes some well-known options, like Trello, which is big on visual task organization, and Asana, which focuses on teamwork. She also mentions tools like ClickUp for flexible task views and Airtable for custom workflows. For developers, Jira is recommended because it’s designed with Agile in mind, and Height even has some AI features for automating repetitive tasks. Finally, there’s Paymo, which is especially helpful for freelancers since it includes time tracking and invoicing all in one place.

I chose this article because it lines up well with what we’re learning about project management. It doesn’t just list a bunch of apps; it actually dives into why certain features—like flexibility, integrations, and collaboration tools—matter. Kiera does a great job highlighting the pros and cons, which helped me think about what I’d really want in a project management tool. It also got me thinking about how each tool might suit different types of projects.

After reading, I feel like I have a better sense of how the right project management setup can make a difference, especially for group projects. Trello’s visual boards, for example, seem like a simple, flexible way to keep tasks organized, whether it’s for personal projects or something with a team. Asana’s team-focused features make me realize how much clear task assignments and easy communication can help everyone stay on track. This article has definitely given me a few ideas on organizing future group projects to keep things moving smoothly.

If you’re curious about free project management tools, I’d definitely recommend checking out this article. It’s a practical guide for anyone looking to get organized without spending a fortune, and Kiera’s insights make it easy to see which tools might fit best based on your project needs.

Link to the post: The Best Free Project Management Software in 2025

From the blog CS@Worcester – Harley Philippe's Tech Journal by Harley Philippe and used with permission of the author. All other rights reserved by the author.

This week, while exploring some articles, I found one that really caught my attention: Happy Patel’s article titled, “Why Python Is So Popular Even Though It’s Super Slow.” Patel’s post dives into Python’s popularity in the programming world, even though it’s known for being slower than other languages. After a quick look into Patel’s background, I found that he’s a knowledgeable voice in tech, sharing insights into why developers choose Python despite its limitations. His article offers a well rounded look at the unique benefits of Python, such as its simplicity, versatility, and productivity, which contribute to its wide usage in various fields like web development, data science, and automation.

Patel kicks things off by breaking down why Python is generally considered “slow.” For instance, he mentions that Python’s code is interpreted rather than compiled, which can make it lag behind other languages in execution speed. Another reason for this lag is Python’s Global Interpreter Lock (GIL), which only allows one thread to execute at a time within a process. Although these details may seem like drawbacks, Patel points out that these traits also make Python flexible and user-friendly. Its high level syntax closely mirrors human thought, allowing developers to think more about problem-solving than strict coding rules. Patel sums it up well by explaining that Python essentially lets computers handle the heavy lifting, letting humans focus on creative coding.

Then, Patel goes on to highlight the reasons for Python’s enduring popularity, despite the speed limitations. One key factor he points out is that Python’s simplicity and readability make it incredibly productive. Development cycles are often much shorter, which can be a huge plus for companies where employee time is one of the most valuable resources. He argues that for many businesses, development speed and efficiency matter more than code execution speed. Patel also emphasizes that Python’s scaling capabilities, like horizontal scaling, let developers manage performance limitations, making Python adaptable for many real-world applications.

I chose this article because it not only aligns with our course material but also sheds light on Python’s “personality” in the coding world. I liked Patel’s casual and practical tone it’s informative without being overly technical. His points gave me a new perspective on how Python’s user-friendliness outweighs its slower speed, especially in environments where development time is critical. Patel’s discussion encouraged me to think about how Python’s design might be useful in my own coding projects, as it shows how the language’s efficiency and adaptability make it great for rapid prototyping.

Reading this article reinforced why Python is considered beginner friendly and why its productivity makes it so popular across industries. I’m excited to apply what I’ve learned, especially Python’s fast development approach, in future projects where flexibility and quick prototyping will be valuable. Patel’s article makes a strong case for why Python is more than just “slow” it’s practical, versatile, and adaptable, which are all reasons I’d recommend Python to anyone entering the programming field.

Link to the post: https://medium.com/@innvonixtechsolutions/why-python-is-so-popular-even-though-its-super-slow-cedfa2b8fe68

From the blog CS@Worcester – Harley Philippe's Tech Journal by Harley Philippe and used with permission of the author. All other rights reserved by the author.

Blog Title: Aligning Product-Driven Organizations with Customer Experience: Key Insights

This week, I listened to a podcast titled “How to Align Your Product-Driven Organization to the Customer Experience.”  The episode goes into and explores the challenges that product-driven companies face in ensuring their offerings truly meet customer needs. It explains in detail how organizations can align internal processes and product development strategies in concert with the overall customer experience and emphasizes the importance of both understanding and responding to customer feedback throughout the product life cycle.

The host starts off by discussing the gap that often exists between a company’s internal product focus and what customers actually want. They explain how organizations can get caught up in their own innovations, losing sight of customer pain points. The podcast stresses the need for continuous customer engagement, using both qualitative feedback and quantitative data to drive product decisions. They also highlight the role of cross-functional collaboration, urging teams across departments to work together to create products that not only function well but also deliver real value to users.

I chose this podcast because it directly relates to our course discussions on systems thinking and customer-centric design, both of which are crucial in software development. This points to a greater and broad development process: aligning internal systems with customer’s needs externally. More particularly, I felt that the guest speaker has done a very good job in bridging the gap between product innovations and customer satisfaction, a very crucial gap in most of the tech-driven industries today, including software development.

The one important thing I took from the episode has to do with how significant it is to assess products from a customer’s perspective. This is something that up until this point I had considered in terms of features against functionality. In this podcast, it helped me understand how important it would be to always reassess if those features actually impact the user experience. I also liked the talk about cross functional teams because it helped me confirm that successful collaboration among different departments brings much better results for any product. 

With my understanding now, using what I’ve learned can be used to integrate  into my approach to project work. Whether it’s in software development or product management, understanding the customer’s journey will be key to delivering value. I now see the importance of continuous feedback loops and how integrating customer experience into every phase of development can lead to better, more successful products. This episode has given me a fresh perspective on how to bridge the gap between product design and customer satisfaction, and I’m excited to apply what I’ve learned in future team projects.

Link to Podcast: How to Align Your Product-Driven Organization to the Customer Experience

From the blog CS@Worcester – Harley Philippe's Tech Journal by Harley Philippe and used with permission of the author. All other rights reserved by the author.

Blog Title: Exploring Software Development Methodologies: A Review

This week while searching for a blog I came across Kacper Rafalski’s blog post titled Software Development Methodologies: A Comprehensive Guide, which dives into the wide range of methodologies used in software development. From a few google searches I learned that Rafalski is a well established figure in the tech industry, known for his skills and knowledge in structured development processes, and his work provides insights on how various methodologies, such as Agile, Waterfall, and Lean, shape the success of software projects. In this post, Rafalski emphasizes the importance of choosing the right methodology based on project goals, team dynamics, and what a client needs. 

To start, Rafalski begins by explaining traditional methodologies like Waterfall, which follows a straight line in a downward sequential structure; this method is ideal for projects with clear, unchanging requirements. He contrasts this approach with the agile methodology, known for its repetitive and flexible approach, which accommodates changing client needs and fosters collaboration. Agile, according to Rafalski, prioritizes working software and client feedback over long and boring documentation, this makes it really useful in a fast paced working environment. He also highlights Lean one we have not covered yet in class hopefully soon. Lean is designed to  eliminate waste and maximize efficiency by focusing only on value-adding processes. He lastly mentions the newer methodologies, including Rapid Application Development-RAD and the Spiral model; each of them presented unique solutions for some particular project obstacles such as rapid prototyping and risk management.

I chose this blog posting for the following reasons: firstly, because it broadly and in great detail covers methodologies, highly relevant, therefore, to our course material. The tone of Rafalski is approachable and informative; he shows throughout by explaining complex subjects without getting too complicated on the reader.  I also liked his balanced discussion of the methodologies, which gave me the chance to think on how these approaches may apply to different software programming projects that I may encounter in my future. Also, the organization of the post makes it clear to follow and understand each methodology clearly. 

Reading this post clarified how to choose the appropriate methodology for a project. I really came to appreciate Agile’s iterative process and how in such an approach, adaptation to circumstances and collaboration is greatly enhanced, something that I hope to apply in future team projects. Generally speaking, I really recommend this post by Rafalski to anyone who wants to get a clear understanding of the diverse landscape of software development methodologies. This is not only an informative guide but also highly practical in field practice for software development.
Link to the post: Software Development Methodologies: A Comprehensive Guide

From the blog CS@Worcester – Harley Philippe's Tech Journal by Harley Philippe and used with permission of the author. All other rights reserved by the author.