URL: TestoMat Mocha and Chai Web Application Testing
The chosen article walks us through the implementation and inner workings of two JavaScript testing tools. Mocha and Chai are two different testing tools that, when combined, form a powerful addition to any software development project. Mocha serves as a test runner, being responsible for executing the test suites. While Mocha can function independently and does not necessarily require any additional tools, combining it with Chai, an assertion library, allows for the validation of expected outcomes in test cases.

The blog post also provides us with several reasons why the utilization of both tools can help improve your software development speed and quality. Among the listed benefits are:

Mocha:

• Flexible and customizable testing.
• Simplifies the testing of asynchronous code.
• The ability to apply before, beforeEach, after, and afterEach.
• Runs tests in both browser and Node.js environments.

Chai:

• Provides clear and expressive assertions that improve the readability of your test scripts.
• Allows you to write descriptive tests using natural language constructions.
• Enables the creation of custom assertions tailored to your specific testing requirements.
• Supports assertions on complex data structures such as arrays, objects, etc.

At the end of the article, it presents an opportunity to implement Mocha with some real-world examples, which is great and especially helpful for anyone unfamiliar with the framework.

The reason I chose this article relates mainly to another class. I will be taking on the task of developing test suites for the Thea’s Pantry app. I also found it interesting because it explains why you would use both Mocha and Chai instead of using other tools or Mocha alone.

The content is helpful and does not seem to include any bias by presenting Mocha and Chai as the only testing environment for JavaScript. Instead, it highlights their pros and invites the reader to determine whether these tools will suit their specific use case. One thing that caught my attention about using Mocha is its ability to generate documentation through testing. This is great, as it will help me better understand how documentation related to testing is created and how useful it can be.

Mocha and Chai’s use of natural, human-like language makes testing much easier. The use of natural or human-like language in programming often makes me skeptical of such tools, libraries, or frameworks. Sometimes, this characteristic is marketed as a way to draw people in, as if it will help them code more effectively. Although Mocha and Chai are distinct tools, their implementation of this characteristic leans more toward improving readability for the programmer rather than for just anyone. What I mean by this is that they avoid technical or overly formal wording in favor of keywords that resemble everyday human language.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.

In today’s fast-paced digital natural world, software systems are required to be scalable, adaptable, and powerful. Microservice architecture is one architectural approach that has gained significant popularity in answering these objectives. Recently, I discovered a helpful document named “Microservices Architecture” on Microsoft’s Azure Architecture Center website, which offered a full description of this technique.

The article describes microservices architecture as a design pattern in which applications are developed as a collection of small, independent, and loosely linked services. Each service is liable for an independent function and may be built, launched, and expanded separately. This differs from monolithic systems, which have all components tightly integrated into a single codebase. The article highlights the advantages of microservices, such as increased scalability, shorter development cycles, and the option to utilize various technologies for different services. It also addresses difficulties like increased complexity in managing inter-service communication, data consistency, and deployment pipelines.

The reason I chose this article is because Microsoft Azure is a cloud computing platform that I am familiar with and am learning more about how it is within microservice architecture. The article’s clear explanations and practical insights make it an excellent pick for learning about microservices in a real-world setting.

Reading the article was an eye-opening experience. I was particularly struck by the emphasis on independence and modularity in microservices. The thought of each service being created and deployed individually appealed to me since it enables teams to work on different areas of an application without stepping on each other’s toes. This method not only accelerates development but also makes it easier to discover and resolve problems.

However, this article also made me aware of the issues that come with microservices. For example, maintaining communication across services necessitates careful design, while guaranteeing data consistency between services can be challenging. This helped me realize the value of solutions like API gateways and message brokers, which assist to speed these operations.

One of the most important lessons that I learned is that microservices aren’t a one-size-fits-all solution. The article highlights that this architecture is best suited for big, complicated applications that demand a high level of scalability and flexibility. For smaller projects, a monolithic approach may be more suitable. This sophisticated viewpoint helped me comprehend that the correct architecture is determined by the project’s individual requirements.

In the future, I plan to apply microservices architectural ideas to my own projects. I’m particularly looking forward to exploring containerization technologies like Docker and orchestration platforms like Kubernetes, both of which are commonly used in microservices setups. I’ll also remember how important it is to build clear APIs and implement effective monitoring mechanisms to handle the complexity of distributed systems.

https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices

From the blog CS@Worcester – computingDiaries by hndaie and used with permission of the author. All other rights reserved by the author.

Students often focus on code with a singular program as the goal. However, there are many different software architectures to consider based on the scope and specifications of a software. The article linked below gave a detailed comparison of two major architectures types: monolithic and microservices. A monolithic architecture is like the all-in-one software solution. […]

From the blog CS@Worcester – CurrentlyCompiling by currentlycompiling and used with permission of the author. All other rights reserved by the author.

Unified Modeling Language (UML) is an important tool in software development that helps developers visualize, design, and document the structure of their systems. It allows developers, project managers, and stakeholders to communicate with a medium that is easier to digest and explain. This week, I found a blog that introduces UML diagrams, “What is a UML Diagram?” from Miro. Miro gives an in-depth view of the types, benefits, and when to use UML diagrams.

Early in our course, we discussed and modeled Sequence and Class Diagrams. I chose this resource because of that foundation and because it is a great starting point for beginners. It also explained more diagram types than presented in class.

The blog explains that UML is a standardized modeling language used to visually represent a system’s design in a understandable way. It highlights two main types of diagrams, each with their own subtypes.

1. Structural Diagrams: These visualize the components in the system and their relationships. Some examples include:
   • Class Diagram: The static structure of a system showing classes, attributes, and relationships.
   • Package Diagram: Shows how packages and their dependencies are organized within the system
   • Deployment Diagram: Shows how software and hardware interact
2. Behavioral Diagrams: These visualize the system’s behavior over time. It is the dynamic behavior of the system. Some examples include:
   • Activity Diagram: Visualized the flow of activities within a system.
   • Sequence Diagram: Shows how objects interact over time.
   • Use Case Diagram: Shows the functionality of the system from the user’s perspective.

The post then describes the benefits of UML diagrams, such as simplifying complex ideas/code and improving team collaboration. It finishes by explaining the best practices and when to use UML diagrams.

This post helped me shore up my lacking knowledge of UML diagram types. I was unaware of most diagram types discussed, so it was nice to see what they were and how they were properly used. The site also provided a link to a diagram maker with some of the types which could be useful in the future.

The benefits were also insightful. The main takeaway was that the UML diagrams keep everyone on the same page. From the technically inclined to those lacking knowledge, you can communicate the system’s functions effectively. This seems especially true for those working in teams with different specialties. Having a roadmap for the system’s functions with a standard notation that everyone can understand allows the team to work more efficiently. In the future, I will use UML diagrams to keep everyone involved in our projects on the same page so we can collaborate to make our software more effective.

Resource: https://miro.com/diagramming/what-is-a-uml-diagram/#1.-simplifies-complex-ideas-and-systems

From the blog CS@Worcester – KindlCoding by jkindl and used with permission of the author. All other rights reserved by the author.

Understanding Versioning: SemVer vs. CalVer Most software, libraries, games, etc… will come with a version number attached. Often times, it is easy to just gloss over this and not pay much attention, however that number can reveal important information. The article linked below compares 2 types of versioning you may encounter. Semantic Versioning (SemVer) – […]

From the blog CS@Worcester – CurrentlyCompiling by currentlycompiling and used with permission of the author. All other rights reserved by the author.

Backend development is the backbone of any software application. It handles the functionality behind the scenes, supporting interactions between the users and the application or website. The backend manages databases and server-side logic so modern applications remain efficient, scalable, and reliable. Understanding the principles of backend development is essential for developers to create effective software.

For this week’s post, I found a resource discussing key elements of backend development called “Mastering Backend Development” by Dan for Roadmap.sh. Dan introduces a roadmap for becoming an effective backend developer, and in this post, he discusses some of the steps on this roadmap in detail.

Backend development has been a key component of our class. I chose this resource because it is connected to the course, and the roadmap seems accessible to new developers. Having a path for your research and actionable steps to take can help with any knowledge gaps or roadblocks in understanding backend development.

This resource outlines 19 important steps or knowledge necessary for backend development. I have limited the summary to those I found interesting or instructive.

Caching Strategies: Improving the performance by storing copies of frequently requested data, reducing database load, and speeding up responses.

Authentication and Authorization: Ensures only authorized users access the system by implementing security measures.

Architectural Patterns: Picking the correct pattern, like Monolithic or Microservices, helps build scalable and maintainable systems.

Observability and Monitoring: Provide tools to monitor the system’s health, optimize performance, and diagnose issues.

Continuous Learning: Staying up-to-date with technologies, frameworks, and best practices. This ensures developers can adapt to the rapid evolution of backend development.

Some steps seem self-explanatory, but they could provide a good foundation for someone new to backend development. I could see how new developers could choose to prioritize the software’s functionality while forgetting its efficiency, security, and diagnostics. The post also offered plenty of tools to help with each step, like Redis and Memcached for caching strategies and OAuth and JWT for authentication and authorization.

I felt Dan gave an excellent synopsis of the research needed for new developers. Plenty of steps were not readily apparent to me, like cashing or your system’s self-diagnostics. These steps will likely present themselves in development, but for someone with little experience, it gives a good direction for research. This mindset aligns with the last step, continuous learning, and the importance of staying proactive regarding new challenges and technologies. In the future, I will research these backend concepts and stay up to date so I can produce and maintain better backend software.

Resource: https://dev.to/roadmapsh/mastering-backend-development-mpb

From the blog CS@Worcester – KindlCoding by jkindl and used with permission of the author. All other rights reserved by the author.

While studying for my most recent exam in CS-343, I came across a phrase I was familiar with but did not know the meaning of: technical debt. I had a vague understanding and understood refactoring’s purpose to repay technical debt, but I was not positive. I came across an article on increment.com talking about refactoring the definition of technical debt into technical wealth. This article’s title is Reframing Tech Debt by Leemay Nassery

The article discusses the concept of tech debt, which is the accumulation of negative choices made during product development that can hinder long-term system efficiency. The article proposes reframing it as tech wealth. The article begins by explaining that tech debt arises from quick fixes and shortcuts taken to meet product goals. This debt leads to system inefficiencies that accumulate over time. Tech wealth reframes this idea as an investment in building scalable systems that improve developer productivity, system stability, and overall team happiness. A key example comes in the form of an automated deployment system, which makes all development afterwards faster. Tech debt is often seen as a nuisance or a negative aspect of engineering, but through tech wealth you allocate time to improve the code’s architecture. The article argues that addressing tech debt (or building tech wealth) should be prioritized, as it ultimately saves time and resources in the long term. The article gives some example strategies to build tech wealth:
1. Allocate Time in Planning Cycles: Teams should allocate a portion of their engineering capacity to work on tech wealth alongside feature development. For example, 20% of the time can be dedicated to tech wealth activities such as automating processes or improving system architecture.
2. Quarterly Focus: Teams can also dedicate a few cycles per quarter to focus entirely on tech wealth, using this time to clean up past code and improve the system’s foundation.

The article closes with a conclusion that suggests rethinking tech debt as tech wealth and incorporating this mindset into planning cycles. This shift not only benefits engineers but also leads to improved product outcomes for users, even if the benefits aren’t always immediately visible.

This article was essential in my complete understanding of the importance of technical debt. Through this article I was able to conclude strategies to tackle technical debt, and the power to be found in conquering it. I found the automated deployment example most tangible as I have had struggles developing in environments without that feature. Tackling these issues is an interest of mine and I am excited to read more.

https://increment.com/planning/reframing-tech-debt/

From the blog CS@Worcester – WSU CS Blog: Ben Gelineau by Ben Gelineau and used with permission of the author. All other rights reserved by the author.

REST stands for Representational State Transfer and API is application programing interface. Simply put, when there are multiple systems working together, a RESTful API allows a person to query or edit information in the system. I recently read a javaguides post on how to set up properly scalable API’s and wanted to share a short summary.

Tip 1: Domain Model-Driven Design
This means you should have the structure mirror the real-life pieces. So if, for example, you want the items of an order, the endpoint should look like “/orders/{id}/items”. Also, don’t nest it too deep, it will add needless complexity.

Tip 2: Choose HTTP methods appropriately
The 4 main methods and their use cases are; GET for getting data, POST for posting a new object to the database, PUT for putting a new object in place of an existing object, DELETE for deleting objects in the database. There is also PATCH which can be used patch an existing object. If you are using GET to modify an object you are adding unnecessary complexity. I personally will be adapting my use case of PUT after understanding the difference with PATCH

Tip 3: Implement Impotence Properly
A method is idempotent if no matter how many times it is called after the first, there is no behavior change from the first call. If you call DELETE multiple times on the same object then only that object should be deleted. GET is already idempotent, it will always get the object’s data regardless of whether you already called GET. PUT and PATCH should be implemented similarly to DELETE. The hiccup is with POST, because simultaneous calls are possible (two people can create new objects with the same identifier) logic to handle these calls needs to be made.

Tip 4: Chose the correct HTTP status calls
When a call is made, there are codes for the result. They are; 200 for a valid request, 201 for an object being created, 400 for an incorrectly formatted request, 401 if requester is unauthorized, 403 for a forbidden request, 404 if the object request is not found, and 500 for a server-side error. I am going to research more about how the permissions are set up when someone makes request and the logic behind blocking certain requests.

Tip 5: Versioning
Include which version of the API the request is using, maybe put it in the path “/v1/users”. They also list alternatives such as having a query parameter “/users?=v1” or adding a HEADER to the request that includes the version number. I never thought about adding versioning to the request but it makes sense to allow for previous versions to still request.

Tip 6: Use Semantic Paths
Singular resources use singular nouns and the path should be using the resources.
DON’T: POST /v1/loginUser
DO: POST /v1/users/login

Tip 7: Support Batch Processing
Something like:
POST /v1/users/batch
to allow for multiple users to be made in one POST.

Tip 8: Use query parameters for flexibility
You can add the ability to sort the data requested, or filter it, using queries. So:
/v1/users?age=gt:20
and
/v1/users?sort=name:asc
This is some awesome functionality and I cannot wait to implement it in my own system.

Link:
https://www.javaguides.net/2024/12/top-8-tips-for-restful-api-design.html

From the blog CS@Worcester – Coder's First Steps by amoulton2 and used with permission of the author. All other rights reserved by the author.