Coding is just like writing an essay, it requires a logical structure, clear message, and readability so others can understand it. That’s why we need “Clean Code” in every project of programming. Clean code refers to code that’s easy to read, understand, and maintain. The ultimate goal is not just working software, but software that remains clean and maintainable throughout its lifecycle. So, how do we write clean code?

According to the Codacy article “What Is Clean Code? A Guide to Principles and Best Practices” (https://blog.codacy.com/what-is-clean-code). They provide a good explanation about clean code and how do we make the code become more understandable for others to read, and also help us to improve more in coding skill.

Why Clean Code Matters

• Readability & Maintenance: Clear code helps developers (including new ones) understand and navigate the codebase faster. blog.codacy.com
• Team Collaboration: When code follows shared, clean practices, it’s easier for team members to read each other’s work and contribute. blog.codacy.com
• Debugging: Clean structure (good names, simple functions) makes it easier to isolate and fix bugs. blog.codacy.com
• Reliability: By adhering to best practices, you reduce the chances of introducing bugs and make the code more stable and reliable. blog.codacy.com

Key Principles & Best Practices

The article outlines several principles that help make code clean:

1. Avoid Hard-Coded Numbers
   • Use named constants instead of “magic” numbers so their meaning is clear and changeable.
2. Use Meaningful Names
   • Choose variable, function, and class names that reveal their intent and purpose. blog.codacy.com
   • If a name needs a comment to explain it, the name itself is probably too vague.
3. Use Comments Wisely
   • Don’t comment the obvious. Instead, use comments to explain why something is done, not what.
4. Write Short, Single-Purpose Functions
   • Functions should do one thing (following the Single Responsibility Principle).
   • When functions become long or handle multiple tasks, break them into smaller ones.
5. Apply the DRY Principle (“Don’t Repeat Yourself”)
   • Avoid duplicating logic; reuse code via functions, modules, or abstractions.
6. Follow Code-Writing Standards
   • Use consistent formatting, naming conventions, and style according to your language’s community or team guidelines. blog.codacy.com
   • Examples include PEP 8 for Python or common JavaScript/Java style guides.
7. Encapsulate Nested Conditionals
   • Instead of deeply nested if/else logic, move conditional logic into well-named helper functions — improves readability and reusability.
8. Refactor Continuously
   • Regularly revisit and clean up your code. Leave it in a better state than when you found it.
9. Use Version Control
   • Track your changes using a version control system (like Git). It helps with collaboration, rolling back changes, and safer refactoring.

Automate Clean Code Practices

• Codacy recommends using its tools (static code analysis, duplication detection, code metrics) to automate enforcement of clean-code rules as you write.
• This helps catch code-quality issues and security vulnerabilities early, keeping the codebase maintainable and high-quality. blog.codacy.com

Mindset Over Rules

• Clean code is more than following a checklist — it’s a mindset and a commitment to quality.
• The article argues for writing code not just to work, but to be read and maintained by humans.

From the blog CS@Worcester – Nguyen Technique by Nguyen Vuong and used with permission of the author. All other rights reserved by the author.

Rest API is something that really interesting and fun to work with. It enables communication between different software systems over the internet, typically using HTTP protocol. However, Rest API can be difficult sometimes due to its complex queries and filtering, and also batch operations and side effects, etc…Good thing is I went through this blog written by “Medium”. They explained some of the good tips for us to practice with REST API calls. I will walk through their ideas and plans to help us be better at REST API.

Here is their blog https://medium.com/epignosis-engineering/rest-api-development-tips-and-best-practices-part-1-9cbd4b924285

1. Planning
   • Do research first: Study existing REST API designs, standards, and popular APIs. Consider whether REST is the right paradigm, but also explore alternatives like GraphQL.
   • Look at other APIs: Try working with well-known APIs (GitHub, Stripe, Twitter, Paypal) to understand what work and what doesn’t

2. Foundations Matter

• A solid early foundation avoids costly refactors later.

• Assume the API will grow: design for scale, future endpoints, versioning, pagination, analytics, etc.

3. Specification

• Write an API spec before coding

• Use tools like OpenAPI/Swagger for designing your API contract

• Specification pays off – especially for APs that are not just internal

4. Testing

• Critical for APIs: because they connect server data with clients, they need to be very reliable
• Don’t rely solely on manual testing – build an automated test suite
• Focus on functional (black-box) tests, not just unit tests
• Use a test database that can be reset; include regression tests for past bugs

5. Deploymemt

• Decouple your API from other server apps: keep the API as a separate module.
• Why? So updating or deploying one part doesn’t risk breaking everything else.
• Independent deployments make development and operation safer and simpler.

6. Other Good Practices

• Be consistent in resource naming: choose either singular or plural for your endpoints (/car vs /cars), but don’t mix.
• For PUT or PATCH requests, return the updated resource in the response so clients know its new state.
• Avoid using multiple forms of authentication or session mechanisms: for example, don’t mix custom tokens with default PHP session cookies (PHPSESSID) — it leads to confusion.
• Don’t leak internal errors (e.g., SQL errors) to API consumers. Log the details internally, but return a generic 500 error externally for security reasons.

Why This Matters

• The article is very practical: instead of rehashing REST theory, it focuses on avoiding pitfalls the author has personally encountered.
• By planning, specifying, versioning properly, and testing early, you build a more stable and maintainable API.
• A thoughtful deprecation strategy and good error-handling also improve reliability and developer experience for your API clients.

From the blog CS@Worcester – Nguyen Technique by Nguyen Vuong and used with permission of the author. All other rights reserved by the author.

There are many different methodologies that can be used for project management. The two that I would like the most are Agile methodology and Scrum methodology. So, what are the differences between these two methodologies, and when is choosing the right one? In this article, I want to summarize the key differences between agile and Scrum methodologies based on what I just read from Northeastern University Graduate Programs. Their article is really helpful for me and you to understand what they are and their differences. The article link is posted below. Feel free to check it out for further information: 

Agile vs. Scrum: What’s the Difference?

Agile vs. Scrum: What’s the Difference?

By Shayna Jouber

What is Agile Project Management? 

People say that Agile is a way of thinking about project management that focuses on delivering in small steps, being in touch with customers, and being able to adapt to change. Agile doesn’t tell you what process to use; instead, it gives you ideals and principles (like those in the Agile Manifesto) that you may use with other methods (like Scrum, Kanban, XP, etc.).\

Important traits: constant communication with customers and end users, willingness to change the scope of work, and delivering work in small steps.

What is Scrum Project Management?

One such approach in the Agile family is Scrum. It offers a clear procedure for handling tasks, including who completes them, how they are arranged, and when they are finished.

Typical Scrum responsibilities include a cross-functional team, a product owner who is in charge of optimizing the product’s value, and a scrum master who makes sure the team follows Scrum procedures.

Work is divided into sprints, which typically last two to four weeks. The team decides which subset of the scope to finish at a sprint planning meeting. Every sprint concludes with a review and retrospective to consider what was accomplished and make improvements.

Frequent delivery of “shippable” increments as opposed to waiting until the project is finished to provide everything is one of the clear benefits.

Agile vs Scrum – Key differences 

Agile is the underlying idea or strategy, and Scrum is a way to put Agile into practice.

Scrum is always Agile since it adheres to Agile principles, but utilizing Agile does not imply using Scrum; you may choose to use another Agile methodology instead.

Choosing the Right Methodology 

• Agile: Agile makes sense if the project requires flexibility, frequent testing, stakeholder feedback, and shifting requirements.

• Scrum: Scrum usually works well in situations with a lot of uncertainty, rapid changes, and the ability to arrange into sprint cycles.

Selecting the approach is only one aspect of it; another is having strong communication, leadership, critical thinking, project management, and organizational dynamics skills.

Conclusion 

Don’t use “Agile” and “Scrum” interchangeably; Agile is more comprehensive, and Scrum is one way to achieve it.

Before choosing Agile, consider the context of your project; if you decide on Agile, select the appropriate approach.

Methodology is only one aspect of successful project management; other factors include teamwork, stakeholder engagement, effective leadership, and flexibility.

From the blog CS@Worcester – Nguyen Technique by Nguyen Vuong and used with permission of the author. All other rights reserved by the author.

During class, I went over the topic of REST API and how amazing it was to understand and analyze how it works. However, there are many types of API, including REST API, GraphQL APIS, RPC APIS, and SOAP APIs. Today, I would like to go through what catches my attention the most is SOAP APIS. I read an article about explaining how SOAP API work, when to use them, and how they compare with modern REST APIS, and I would love to share it with you. The article is posted below, and feel free to check it out for further information (all the information is according to the article) 

https://blog.postman.com/soap-api-definition/

WHAT is SOAP? 

In the late 1900s, SOAP, a messaging protocol that was developed to enable different systems running on multiple operating systems, languages, and networks, with the purpose is to exchanging structured information reliably 

Unlike REST, SOAP focuses on messages rather than resources. 

SOAP messages are formatted in XML and usually contain: 

• Envelope – defines the start and end of the message 
• Header – contains optional information like authentication or transaction details 
• Body – holds the actual request or response data 
• Fault – handles errors 

How SOAP works?  

A SOAP client sends an XML request to a server, which also responds with another XML message. These communications often occur over HTTP (but sometimes also SMTP, TCP, or UDP) 

• SOAP messages are defined by the Web Services Description Language (WSDL) to describe the operations, parameters, and return types

Advantages of SOAP

• Platform independent – works across languages and OS. 
• Protocol flexible – not limited to HTTPS 
• Strong security – supports encryption and authentication 
• Error handling – display clear fault messages 
• The ideal workplace, where rigid relationships and dependability are essential 

Disadvantages of SOAP 

• More complex and verbose than REST 
• Harder to evolve or version 
• Slower performance due to XML analysis 
• It is less appropriate for web applications because of its limited catching support. 

Common Use Cases 

SOAP API is commonly used in banking, telecommunications, transportation, and enterprise systems – these cases require reliability, structured data, and strict security. 

• Examples: 

In banking, SOAP API is used for bank transfers.

In transportation, flight booking systems 

ETC, ….

Shipping and logistics services 

Conclusion 

SOAP API is a great protocol, robust and standardized, but compared to REST, it’s less flexible. REST is better for modern web applications and faster iteration. SOAP API is always needed and valuable for many applications that prioritize security, reliability, and formal structure.

From the blog CS@Worcester – Nguyen Technique by Nguyen Vuong and used with permission of the author. All other rights reserved by the author.