In our world, when you want to drive a car outside the public, you would need a driving license to do so. This is because you need the permission to use the road freely. Also, if you want to go fishing, you also need a fishing license, this gives you the permission to fish at any public lake or public fishing area. As we know, license provides you the authorization to access something that requires from someone’s permission. Same with software engineering, in software, we require license to access someone’s code or project. It grants right for you without transferring ownership from the author. However, there are multiple types of software licenses, each has their own function. I will explain everything in this blog based on what I read from https://finquery.com/blog/software-licenses-explained-examples-management/

What is a software license?

A software license is a legal agreement between the software creator/provider and the user (individual or organization) that defines how the software may be used. It doesn’t transfer ownership — it grants rights.

The license specifies things like how many devices you can install on, whether distribution or modification is allowed, and other restrictions (or freedoms) depending on the license type.

How licenses work & why they matter?

When you obtain software, what you actually pay for is the right to use that software under certain terms, not the software itself.

Licenses protect the intellectual property rights of developers, control distribution, and can also allow or forbid modification. That helps prevent piracy and misuse.

Before using software, users often must agree to an End User License Agreement (EULA) — a legally binding contract defining permitted and prohibited actions under that license.

Common Types of Software Licenses

• Public domain license: No restrictions — software is effectively “free for all.” Anyone can use, modify, relicense, or commercially exploit it without needing to pay or give credit.
• GNU Lesser General Public License (LGPL): Open-source license allowing developers to use/license the code in their own projects without having to release their own source code.
• Permissive license: A flexible open-source license with minimal restrictions — typically just requiring attribution/copyright notice on redistribution. Common in open-source community
• Copyleft license: More restrictive open-source license: if you modify and distribute the software, you must also make your version’s source code freely available under the same license
• Proprietary license: Most restrictive — software remains proprietary, users get limited rights; typically no access to source code, and strict limits on copying, sharing, modification, or redistribution.

Software License Management

Because organizations often use many pieces of software (some licensed, some subscription-based), managing this properly is important. The article recommends:

• Keeping a centralized inventory of all software licenses and subscriptions used within the organization.
• Tracking license usage, renewals, and compliance — ideally via a dedicated license-management tool rather than manual spreadsheets.
• Establishing reminders for renewals and conducting regular audits to avoid under- or over-licensing, penalties, or wasted spending

Conclusion

If you ever find an interested code, or project, that you want to install it in your computer or use it as references, make sure to keep an eye on its license. Identify its type, and follow the permission it allows. This keeps you avoid any legal risks, control costs, and efficiently manage software assets.

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

Have you ever wondered everything you see on your phone’s screen in any of applications you clicked on, how do they work that makes you be able to interact with it? Of course, they’re programmed by the programmers, but in order to design the app and allow users to interact with the app, it’s not just about programming, it’s a whole process of implementing what is called “Front End”. So, what is front-end? Why does it matters in building an application or website?, who takes control of it? Everything will be explained in this blog based on what I read from https://airfocus.com/glossary/what-is-a-front-end/ by airfocus, “Front End (in website).

What is front end?

The front end refers to everything a user sees or interacts with when using a website or app. That includes layout, design, buttons, navigation menus, images — in short, the look and feel / user interface.

Technically, front-end work is implemented using web languages like HTML, CSS, and JavaScript.

In contrast, the back end handles behind-the-scenes functionality: data processing, business logic, server communications. The front end and back end together must work smoothly to deliver a good user experience.

Why Font End decisions matter?

According to airfocus, front-end design is critical for product success because:

• User engagement & satisfaction: A well-designed front end makes it easier and more enjoyable for users to interact with the product — reducing friction, boosting clarity, building trust.
• Ease of iteration and experimentation: Clean, intuitive front-end design allows product teams to iterate faster — experiment with UI/UX improvements, adjust features based on feedback, without overhauling the whole system.
• Brand perception & consistency: A consistent, polished front end across platforms (web, mobile, etc.) strengthens brand identity and trust. A clunky or inconsistent UI risks undermining user perception of the brand

Roles & Collaboration: Who shapes the front-end — and how product leaders fit in

While front-end code is done by engineers / front-end developers, product managers (or product leaders) have a crucial role: they translate user needs and business goals into clear priorities for what the front end should deliver.

Product leaders don’t need to write code — but they should understand dependencies between front-end and back-end, and advocate for a user-centered design that balances business constraints, technical constraints, and user experience.

Effective front-end strategy means collaborating with design and engineering leads, making trade-offs transparent, and using structured planning tools (roadmaps, scoring, templates) to guide front-end work.

Conclusion

Overall, front-end developers is a very important position in building an app, or website. Specifically, front-end is like an appearance of what you can see and interact with within the app. If there is no front-end implementation, there is no app or website even exists.

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

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.