Category Archives: CS@Worcester

Week 4 – CS 343 Blog: What is front-end?

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.

Bridging Frontend and Backend Development: My starting journey building therapeutic platforms

For this final blog post, I have decided to explore the realms of frontend and backend development. It has been an informational and exciting journey learning about backend development in my Software Construction, Design, and Architecture course, and with my background in psychology, I am driven by the curiosity of bridging these two fields. My current interest is figuring out how to use computer science to improve and aid mental health through application development.

This is something we currently see in terms of self-care apps and a handful of psychology games. I want to expand by building therapeutic platforms, engaging psycho-educational games, and functional apps for psychology. This goal pulls me in both directions of developing skills in frontend and backend development. I looked at a few resources to learn more about the characteristics of frontend versus backend, and this GeeksforGeeks resource provided a great starting point for understanding the characteristics of these domains, what skills I should develop, and what technologies I should become more familiar with.

The modern web is built upon two domains. As resources from GeeksforGeeks and FullScale clarify, these roles are functionally different and equally necessary for any application to thrive. The Frontend(Client-side) is the visible and interactive layer. It is responsible for all user interaction, visual presentation, responsiveness, and application behavior, using technologies like HTML, CSS, and JavaScript. This layer controls the user interface and user experience (UI/UX), defining what users see and how they interact with the platform.

On the other hand, the Backend(Server-side) is the behind-the-scenes infrastructure. This layer manages crucial processes like data (processing and management), storage retrieval, security protocols, user authentication, and ensuring the frontend receives the needed/requested information.

What really draws me to frontend development is the idea of using UI/UX as a therapeutic mechanism. This is where my psychology background connects directly with code. The interface itself determines how well an intervention works. For example, if I am building a tool for guided imagery or relaxation/deep breathing, the success is not just about the back-end data, but about making sure the visual cues and flow are seamless and actually helpful for the user. A clunky design can easily increase stress or cognitive load, thus undermining the whole point of the tool. As the resource “Journey of a frontend developer” states, this path is not just about making things aesthetically pleasing; it is about mastering responsive design and translating complex human needs and psychological principles into structured digital architectures. 


While my dive into frontend and backend began with an interest in frontend work (UI/UX), I recognize that knowledge in both areas is crucial to being a well-rounded developer and producing quality products. You simply cannot have a stable and secure platform without the backend part, due to the necessity of its operations. This balanced approach is the best way to build fully functional and high-integrity tools and to successfully merge my technical skills with my professional interests.

Main Resources:
Frontend Vs Backend Developmenthttps://www.geeksforgeeks.org/blogs/frontend-vs-backend/#

Frontend VS. Backend Software Developmenthttps://fullscale.io/blog/front-end-vs-back-end-software-development/

Journey Of a Frontend Developerhttps://medium.com/@ravindermahajan/journey-of-a-frontend-developer-9d09ab36dcd5

Additional Resources:
Frontend? Gross. This is Why I’ve Always Preferred the Backendhttps://blog.boot.dev/backend/why-i-prefer-backend/

Going to Backend Development from a Frontend Developer’s Point of Viewhttps://medium.com/@garciajvincent/going-to-backend-development-from-a-frontend-developers-point-of-view-6d7081609c56

From the blog CS@Worcester – Vision Create Innovate by Elizabeth Baker and used with permission of the author. All other rights reserved by the author.

The Importance of Frontend Development

Frontend development is an essential part of building any website or just an application. It is the part of web development responsible for what the users see and interact with the user interface  and user experience of a website or application. The author explains that the frontend is built using technologies like HTML, CSS, and JavaScript. HTML is the backbone of any webpage because it provides structure and organization with defining things like headings, images, paragraphs, and links. CSS works with HTML by controlling the visual representation of the page and allows developers to customize colors, fonts, and layouts. Meanwhile JavaScript adds interactivity, handling user input, and dynamic behaviors to the page. These all work together The article also outlines typical tools and practices used by frontend developers like code editors, local development servers , version control systems, package managers, and build tools. In addition, it talks about styling techniques, making content responsive, adding interactivity via DOM manipulation and event handling, and using frontend frameworks or libraries to streamline development. Overall the article supports advancing your frontend development skills and makes it much simpler going in as a beginner who doesn’t know much about it beforehand.

The reason I chose this article is because in our class we have used the backend code for Maria’s Pantry many times, but we had never really used the frontend until the very end of the semester. Since we didn’t have as much time to go over it I also found myself very confused at times as to what was the major difference and how important is it really. I mainly just wanted to do my own research and read about it since I felt it would be something extremely important to know as much as possible to any developer.

After reading the blog post I started to realize how important HTML, CSS, and Javascript were to frontend development. They hold up and give structure to the webpage. This post also names some courses you may take to practice frontend development like udemy, coursera, and codecademy that cover most of the basics behind HTML, CSS, and Javascript. I plan to look up on them and try to practice as much as I can cause I would like to work on my skills as much as possible as I believe that it would be valuable to any sort of career I may look forward to in web development.

https://namtheartist95.medium.com/what-is-frontend-development-5fdfdd892464

From the blog Thanas CS343 Blog by tlara1f9a6bfb54 and used with permission of the author. All other rights reserved by the author.

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

From the blog Maria Delia by Maria Delia and used with permission of the author. All other rights reserved by the author.

Companies and API Security

I recently wrote about an article that discussed important security practices for implementing APIs. Security seems like something that could not be overlooked by major companies, but 65 percent of Forbes AI 50 companies have leaked verified secrets on GitHub. Supposedly, VS Code extensions keep making things such as API keys, tokens, and other digital credentials known when uploaded to GitHub. One of the researchers attributes this partially to “vibe coding”. Recently, it has been discovered that LLMs have been able to give up API keys with certain prompts. With the rise of the usage of LLMs, this can be incredibly dangerous for these companies. Wiz is a security company that sells secret scanning as a service. It was recently purchased by Google for $32 billion. Wiz found that the most common sources of these leaks were Jupyter Notebooks, Python files, and environment files. The keys and tokens found in these leaks are ones that could cause for severe issues for these companies. These keys could also expose training data that may include sensitive business data. Wiz says that multiple companies who were found to have these leaks were notified about the exposures, but half the security disclosures either couldn’t be delivered or received no response. The article ends by saying: “The first step toward solving your secret exposure problem is admitting that you have a problem.”

This was very surprising to me. As I have been learning about APIs, I have realized how important it is to ensure that everything is secure. When I had read the other day about API security practices, I thought that these were standard practices that companies would not omit. When I had seen this article, I figured that I had to read it. It was such a shock to me that high-level tech companies would omit such an important step in API implementation at such a high rate. To make matters worse, many of them did not attempt to clean this issue up. The last line of the article really stood out to me. I couldn’t imagine being a part of such an important company and ignoring such a large issue. As AI continues to grow, I believe the companies that make an effort to keep their systems secure will be the ones that flourish. Overall, this article opened my eyes to a lot. It seems to me that it is good that I am learning about APIs now, as large AI companies still have a lot to learn as well.

https://www.theregister.com/2025/11/10/ai_companies_private_api_keys_github/

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

Choosing Code Rules: Navigating Licensing for Health Technology

Understanding software licensing is one of the crucial, non-coding topics that becomes a massive deal the moment you start building real applications. When covering this in my Software Process Management course, I was overwhelmed by the density and intimidation of the numerous license types and legal details. For this blog post, I decided to use this opportunity to strengthen my understanding of these various software licenses. This information is vital for my plans, especially when creating high-integrity therapeutic platforms where security and protecting ideas are non-negotiable. To achieve this goal, I looked at several resources to deepen my understanding.

To make sense of licensing, the best first step is grouping them into two major categories: Proprietary (Closed source) and Open Source. As the resource by Zluri, “3 Major Types of Software Licenses & Its Categories” states, proprietary licenses are the most restrictive type as their whole purpose is to keep the source/base code private. This means, you can only use the software via permission and under strict conditions; you will not be able to edit or distribute the code yourself. For my work, this proprietary model might be necessary to protect the specific clinical methodology or algorithms I develop for future therapeutic platforms. Open source licenses, on the other hand, make the source code publicly available, which is the best for those who are looking for collaboration and efficiency.

However, this resource by BlackDuck states, open source licenses can become overwhelming. To best understand, I grouped the following licenses from easiest to more difficult to handle. Permissive Licenses (i.e., MIT and Apache 2.0) are the easiest to use as they are very flexible and only require you to include the original copyright notice. Copyleft licenses (i.e., GPL) have a strict rule to follow. That is, if you distribute a modified version of software, you must also make your modified source code available under the same copyleft license. If I used a copyleft feature in a therapeutic game, for example, I would be forced to release the source code of my entire game; which is a major factor protecting the core methodology and design. 

Licensing is more about just reading and considering rules, strategic planning is very important with choosing which to work with. It directly impacts ethics, decisions, and compliance of any platform handling sensitive information. If I am to build things like interactive feedback systems or symptom management trackers, I need to know exactly which third-party tools I can safely use. My current task is figuring out that delicate balance to ensure I build professional, compliant, and sustainable software that protects both users and the core therapeutic intervention.  

Main Resources:
3 Major Types of Software Licenses & Its Categorieshttps://www.zluri.com/blog/types-of-software-licenses

Five types of software licenses you need to understandhttps://www.blackduck.com/blog/5-types-of-software-licenses-you-need-to-understand.html

Additional Resources:
Software Licensing Models: Your Complete Guidehttps://www.revenera.com/blog/software-monetization/software-licensing-models-types/

Software License Types, Examples, Management, & More Explainedhttps://finquery.com/blog/software-licenses-explained-examples-management/

From the blog CS@Worcester – Vision Create Innovate by Elizabeth Baker and used with permission of the author. All other rights reserved by the author.

Design Patterns

Hello everyone,

This will be my last blog of the semester and being the last one, I wanted to do something fun. When we went over Design Patterns in class, I was really amazed and I saw myself going back and thinking about it. I was even surprised to see that I had not written a blog about it. I wanted to do a little digging and wanted to talk in this week’s blog about a new Design Patterns that we didn’t cover in class, and the one I am going to talk about is “…drum rolls please…” Adapter Pattern!!!!

The idea behind it is pretty simple and as you can guess it comes from the name, and its general idea of it in software development is identical to the one in the physical world. When you travel abroad and want to charge your phone or laptop but the power outlet has a different shape from what you are used to seeing back home. In a different scenario, you are going to connect your old console to your new TV, but the plugs and outlet are not compatible so what do you do? In both of these cases you are going to use an adapter which allows you to use your own plugs in scenarios where you normally were not able to.The Adapter Pattern has the same principle but it is applied in object-oriented programming. A prime example of when this is used is when you already have a class and want to reuse in a different interface and rather than creating a whole new class just for that specific interface, youuse the Adapter Pattern. You then implement a class that bridges the gap between an expected interface and an existing class. That enables you to reuse an existing class that doesn’t implement a required interface and to use the functionality of multiple classes, that would otherwise be incompatible.The biggest advantage of the Adapter Pattern is that you don’t need to change the existing class or interface. By introducing a new class, which acts as an adapter between the interface and the class, you avoid any changes to the existing code. That limits the scope of your changes to your software component and avoids any changes and side-effects in other components or applications. This will save you a lot of time, effort, and a lot of headaches.

In conclusion be smart like your Adapter Pattern that you will be using, and make the ability to show your work and project to any interface without being held back from interface compatibility

Source: https://medium.com/@akshatsharma0610/adapter-design-pattern-in-java-fa20d6df25b8

From the blog Elio's Blog by Elio Ngjelo and used with permission of the author. All other rights reserved by the author.

Writing Good Documentation

Sources: Ángel Cereijo and GeeksForGeeks

Writing documentation for your project can be tedious and boring. Say you just finished your project, you published it, and you’re excited to see people use it… but they don’t know how. You need documentation to explain your project. 

Software documentation is the writing that goes along with your project, ranging from what your program does, how you plan to build the program, or any notes you may have for your team. There are four types of documentation: requirement, architectural, technical, and end-user. Requirement documentation explains the requirements for the program and how it should perform. Architectural documentation explains how the program should be structured and how processes should work with each other. Technical documentation explains the technical parts of the program, like the API and algorithms. End-user documentation explains how the software works for the user. 

Good documentation should be created throughout the development process. Saving it all until the end will burn you out and set you back. To prevent this, progress the documentation as you build the project. Split your project into smaller pieces, like how it is done in an Agile setting, and improve the documentation as new features are developed. 

Documentation should explain the purpose of the project as well. It should set up a problem that your program solves and why it is useful to solve the problem. Communicate with your team on how the problem is going to be solved and a plan to get there. Then, split the project up into tasks and assign them to the team members. Explain in detail any information needed for each task. Having the research and plan in writing makes it so anyone can complete the task at any time. As tasks are completed, update the documentation to the project before calling it completed. 

Having explanatory documentation also ensures that tests can be written easily, even without the actual code that is being tested. Then, as you write the code for that task, the tests are already completed and you can move on. 

As your team progresses through the project, your initial plan and process will probably change. With new resources and findings, the initial documentation needs to be updated as well. 

Once your project is published, your documentation is there to help the users easily use your program. It needs to be written in simple language for any reader and avoid ambiguity/unneeded repetition. 

Writing documentation is necessary for every project, helping to communicate with your development team and to serve as a guide to the users. It is important to write good documentation and keep in mind how other people will use it. Having the basics down of writing good documentation will help me in the future and give me a step up as a new software developer. 

From the blog ALIDA NORDQUIST by alidanordquist and used with permission of the author. All other rights reserved by the author.

Stay Educated

Let’s explore software process management through a domain that often gets overlooked in technical discussions (even though it’s unlikely in my opinion): education systems. To do this, the UNESCO article “Education Management Information Systems Progress Assessment Tool: A Methodological Guide for Educational Transformation.” The article explains how structured processes, data governance, and continuous improvement cycles help educational institutions operate more “effectively and equitably”.

The UNESCO guide introduces the Education Management Information Systems Progress Assessment Tool (EMIS‑PATT), a framework designed to help ministries of education evaluate and improve their data management processes. The article emphasizes that high‑quality education depends on high‑quality data — and achieving that requires clear processes for data collection, validation, analysis, and reporting. It outlines a structured methodology that educational organizations can use to strengthen institutional capacity, improve decision‑making, and support long‑term transformation efforts aligned with global education goals.

I chose this article because it highlights how process management principles extend far beyond software development. Education systems face many of the same challenges we discuss in SPM: inconsistent workflows, unclear responsibilities, poor documentation, and difficulty scaling processes across teams. Seeing these issues in a non‑technical domain helped me appreciate how universal process thinking really is. I was also drawn to this resource because it connects directly to real‑world impact — improving data processes in education can influence policy decisions, resource allocation, and ultimately student outcomes.

What struck me most is how closely EMIS‑PATT mirrors the software process models we study in class. For example, its emphasis on iterative assessment and continuous improvement parallels Agile’s sprint cycles. Its focus on standardizing workflows resembles the structured phases of Waterfall or the disciplined practices of DevOps. Even the idea of strengthening “institutional capacity” reminded me of how development teams invest in tooling, documentation, and onboarding to improve long‑term productivity.

This article also reinforced the importance of process transparency. In education, unclear data processes can lead to inaccurate reporting, inequitable resource distribution, or students being overlooked entirely. In software engineering, unclear processes can lead to bugs, delays, and misaligned expectations. In both cases, the solution is the same: define the process, measure it, and improve it continuously.

UNESCO made me reflect on my progression through taking this Software Product Management course. It was one of the most exhilarating experiences I have ever had in an educational environment. Throughout the various activities I’ve partaken, I not only gained new skills, but I learned my strengths and weaknesses. I see process management as a foundation skill & this resource has showcased the power of processes throughout entire systems, not just for software teams.

Source: https://www.unesco.org/en/articles/education-management-information-systems-progress-assessment-tool-methodological-guide-educational

From the blog CS@Worcester – theJCBlog by Jancarlos Ferreira and used with permission of the author. All other rights reserved by the author.

REST API Best Practices

In this blog post, I will go over some of the best practices with REST API design, especially considering performance and security at must for most API consumers. It is worth notice that proper API design will ease the maintenance for many services and applications running on a web browser, as the worst case scenario will be more difficult to maintain and becomes different from what everyone expect.

In summary, the post introduces the crucial ways to design the REST APIs properly, which there are accepted conventions to follow so we won’t run into the problems down the road. Some example practices can be Accept and respond with JSON, where JSON is standard for transferring data, as well as built-in methods for Javascript to encode and decode JSON either through the Fetch API or another HTTP client. Other practices are usage of nouns instead of verb for endpoint path names, since it could conflict with HTTP method which are already the verbs, as well as many other practices such as handling error codes, maintain good security practices, and caching data to improve performance, and versioning the APIs.

The reason I choose this article is because there are many ways to experiments with REST API, with the aim to design a web application that meet consumers need, especially end-user experiences. In most cases, we want to deliver the up-to-date user experience within the web applications, and making sure to handle things that are unexpected. In other words, we need to keep track on features in our web applications, monitoring bugs that occur to many users, and monitor versioning appropriately according to the semantic versioning. In my experience, programming and maintaining a REST API project would take very careful steps to count on user experience, as well as what to and not to access. The best example is the good security practices, which are the process of obtaining SSL/TLS security. The good boundaries for the user is to not access any more information beyond what they expected, because when doing so, they could access into another user’s information, as well as information from the admins of the web server.

From what I learned from the article, applying these practices will help me learn more about making a clean REST API project, maintaining the project in the future long run so users will always have access to their needs. As the project grows, it will often requires a higher demand in terms of backend features, hence careful handling is needed to meet all the expectations overall.

Source: https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/

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