Category Archives: CS@Worcester

Front End Development

I have never worked on front end development until now. My preconceived notions made me think this would be simpler like web design, but I was wrong. This is the piece that the users interact with directly. Mistakes here make the project look sloppy, reduce user satisfaction, or can make it hard to navigate. The front end is the first impression, if this leaves a bad taste, then it may lower user satisfaction.

Front end development relies on three things, html, css, and javascript. HTTPs give us the skeleton of the page. It shows where our elements like headers, images, and links go. CSS takes what we have and stylizes it. This handles things like colors and layers. This is also responsible for ensuring the front end looks good on whatever device it is ran on. And finally java script introduces dynamic behaviors. This can include dropdown menus, data fetching, animations. This pulls everything together to create a responsive UI.

There’s a lot of good front end tools to check out. Tailwind css allows you to simply learn styling patterns that work, without having to write full css files. Bootstrap is a css framework that provides pre-built ,https, javascript and css components. Apparently 19% of all websites were created with this. Css loaders give you hundreds of loading animations that you can use in your projects. Coolers are a pallet generator. This allows you to see a variety of color pallets to choose from so you can see what you link and implement into your front end. A lot of these tools seem very interesting and have gotten me more interested because they seem very simple to implement while making your project look cleaner. These tools don’t exist to replace doin the work yourself. These are in place to support the core aspects of front end development. Some of these tools will help you build a layout faster, and other tools like codepen allow you to test without having a complete project. They give the developer some simple quality of life improvements that can make the process more streamlined.

https://www.wearedevelopers.com/en/magazine/210/best-tools-for-front-end-development

https://martijnhols.nl/blog/accessibility-essentials-every-front-end-developer-should-know?

From the blog CS@Worcester – Aaron Nanos Software Blog by Aaron Nano and used with permission of the author. All other rights reserved by the author.

The Definition of Done (DoD)

How to write a Definition of Done

CS-348, CS@Worcester, Week-4

Source Article: https://www.atlassian.com/agile/project-management/definition-of-done

Recently, in doing a project in class, I had to write a Definition of Done (DoD) file for my portion of the project. I had a basic understanding of what needed to be conveyed, but not exactly how to convey it. I wanted to know more. I looked further into what the industry standard is, and that’s how I came across this post, which I used to help me figure out the one for my project.

I recall from the previous class activity that we looked at the Scrum Guide by Ken Schwaber and Jeff Sutherland, and the guide did give information on what the Definition of Done was and what it is meant to convey, but I wanted something more in-depth.

According to the article, the Definition of Done is a shared set of criteria that tells a Scrum team when a product increment is truly complete. The specifications contained are not created by one person but agreed upon by the entire team because there needs to be a shared understanding of what’s expected at the end of each sprint and for the project overall. This is needed to avoid miscommunication and make sure the team adheres to the pillars of Scrum: transparency, inspection, and adaptation. The developers of the team have the responsibility of parsing out what the DoD will be continuously as it will evolve and change as increments pass.

I knew that whatever was agreed upon needed to be something that is measurable and testable, otherwise there would never be a satisfying way to declare being done. But the article mentioned something about the DoD needing to also be “ready to ship”. This means that there can be no hidden work left after the spring, and there can’t be extra polishing stages.

The most helpful portions of the article were the examples that were provided of what can be included in a DoD. Here are some of them./

  • Increment Passes SonarCube checks with no Critical errors
  • Increment’s Code Coverage stays the same or gets higher
  • Increment meets agreed engineering standards
  • Acceptance Criteria for Increment pass
  • Acceptance Tests for Increment are Automated

Most of the examples include the project passing specific tests or meeting certain standards that would be either required by the client or the organization the team is working for, which is par for the course. The DoD is an important part of Scrum, and I need to understand how to think of a project in order to write one in future cases.

From the blog CS@Worcester – A Beginner's Journey Through Computer Science by Christiana Serwaah and used with permission of the author. All other rights reserved by the author.

What is Linting

A quick overview of linters

, ,

Source: https://www.perforce.com/blog/qac/what-is-linting

Recently, in class, we did an activity on creating a lint script. The activity honestly confused me a little bit out of the many questions I had about it. One of the questions I wanted to explore is more about what linters do and why we use them. The activity gives a brief description of what linters are and their purpose.

According to the activity, Linters are tools that check the formatting and style of code and files in projects. Some extensions, like the one used earlier in the activity, markdownlint, can perform some of this checking, but not all tools are available as extensions. I would like to understand them a bit more, so I chose a source that went into extensive detail about what linting is and linters.

It scans the code for things that don’t necessarily prevent the code from running but can cause bigger issues later on, such as small bugs, conflicting formatting, and bad style choices. It can also look for common errors like indexing beyond arrays, dereferencing null pointers, unreachable code, and non-portable constructs.

It’s better suited for programming languages like Python and JavaScript because they are interpreted languages that don’t have a compiling phase, so linting helps with keeping up consistency. Linting is more effective in code that follows standard rules and is in projects that need to adhere to shared style guidelines.

Linters are a basic form of static analysis tool, which are any tools that can analyze code without running it. More advanced tools are able to detect:

  • Deeper data-flow problems
  • Runtime risks
  • Security vulnerabilities
  • Complex rule violations
  • Defects across multiple files or modules

Linters are a very helpful tool but they do have some limitation that needed to be accounted for when wanting to use it on a project.

Pros

  • Catch small issues early
  • Improve code consistency
  • Reduce time spent on reviews
  • Support teamwork and shared standards
  • Great for beginners who need guidance
  • Fit well into Agile workflows

Cons

  • Can produce many warnings
  • Sometimes flags harmless code
  • Cannot detect deep logic problems
  • Needs to be configured correctly
  • Can slow you down

Overall, I learned that Linters are one of many analysis tools that can be used in a program, and I also learned one of the ways methodologies like Scrum are able to keep transparency and deal with continuity and consistency issues when dealing with a larger team.

I would like to become more familiar with creating lint scripts, so I can integrate them more into my programs, especially since consistency is something I have issues with, the more I learn about how to code better.

From the blog CS@Worcester – A Beginner's Journey Through Computer Science by Christiana Serwaah and used with permission of the author. All other rights reserved by the author.

Blog post Quarter 4

For this quarters self-directed professional development blog, I chose to watch the YouTube video “Clean Code: Learn to write clean, maintainable and robust code.” It is an older video but I wanted a resource that explained Clean Code principles in a way that connects directly to real programming habits, especially since we’ve been focusing on refactoring and reducing complexity in CS-348. Instead of reading another article, I thought watching a different creator explain the ideas visually would help reinforce the concepts from class in a new way.

This video introduces Clean Code by framing it as both a technical and professional skill. The speaker explains that messy code slows down teams, increases bugs, and creates long-term maintenance problems, while clean code allows developers to move faster and collaborate more effectively. He breaks down major Clean Code principles, including meaningful naming, small functions, consistent formatting, avoiding duplication, reducing side effects, and writing code that communicates its intent clearly without relying on extra comments. He also emphasizes the value of refactoring regularly instead of waiting until the system becomes too large to comfortably improve.

I chose this video because it feels practical and grounded. This video also focuses on habits that any developer can adopt, whether they’re building side projects or working on large software teams. The examples were simple but effective, especially when he showed how shortening functions, renaming variables, or removing unnecessary logic instantly improved readability.

What stood out to me the most was his point that code should be written for humans first and machines second. This video made it click for me that good code is for humans first and computers second because he showed how unclear naming or tightly coupled functions force the reader to do mental gymnastics. When I look back at my older project, I can see exactly where I created those kinds of problems. This video made me more aware of how quickly messy patterns can spread if they aren’t addressed early.

This resource affected how I approach our CS-348 refactoring assignment. Instead of waiting until the end to fix everything, I’m improving readability each time I revisit a section. The video explained, clean code is about developing consistent habits that make software easier to understand, maintain, and extend.

Moving forward, I expect these practices to influence my future professional development. Whether I’m collaborating on a team or working independently.

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

When Architecture Matters

In building software, it’s easy to focus on writing code, making features, and getting things working. But real, maintainable systems require more, they require thoughtful architecture. In the article “Five Architectural Principles” posted in the Criteo Engineering blog on Medium, Peter Milne lays out five foundational principles that, in his experience, guide sustainable and scalable software systems. The article is short but it outlines an architectural mindset that feels especially relevant.

Milne begins by outlining five principles he believes lead to more maintainable systems, grounding each one in how teams can better structure software over time. He doesn’t claim that implementation is unimportant, but he does consistently direct attention towards fundamental architectural choices. That emphasis made me reflect on how many of my past projects became unmanageable messes simply because I was focused on writing code rather than the structure supporting it.

One of the principles that Milne discuss is the important of designing components around well-defined responsibilities. He explains that keeping components focused on a single purpose helps reduce unnecessary complexity as systems evolve. His explanation made the idea more concrete for me, especially because it aligns with some of what we’ve learned in class about separation of concerns and the value of components that can change independently.

Milne also emphasizes the importance of clear contacts, the rules or interfaces that describe how parts of a system should interface. He presents contracts as a way to maintain stability, even when internal implementation details change. His explanation made me think about much smoother some of my past group projects would have been if interfaces had been clearly defined from the beginning.

Milne also makes it clear that architectural decisions should be intentional rather than accidental. He doesn’t prescribe strict formulas, but he encourages thoughtful design so that systems can evolve without becoming overly complicated. That perspective resonated pretty heavily with me because it connected to an overarching theme that’s been prevalent throughout 343: the choices we make early on influence how well a system can adapt in the future.

Reading this helped me rethink the way I want to approach future projects. Instead of immediately writing code, I want to start by defining boundaries, identifying responsibilities, and agreeing on interfaces. Architecture is meant to support the system, not struggle to keep up with it. Even though Milne’s article is fairly brief and pretty corporate, it made me realize the value of the invisible structure supporting the visible behavior of software.

View at Medium.com

https://medium.com/criteo-engineering/five-architectural-principles-d32dc2bfefae

From the blog CS@Worcester – My Coding Blog by Jared Delaney and used with permission of the author. All other rights reserved by the author.

Understanding REST API design: Foundations and Modern Practices

For this blog I chose to explore the article “REST API Design: Architectural Foundations and Modern Practices” by Nikola Lazarov. Since CS-343 focuses on software construction, modularity, and clean interfacing, I wanted to learn more about how REST APIs fit into architecture beyond the basic GET/PUT/POST/PATCH commands. Lararov’s article stood out because it connects the roots of REST with other practical API design conventions we’ve learned in 343.

Lazarov begins by grounding the discussion in the original REST constraints defined by Roy Fielding. These include ideas such as statelessness, a uniform interface, resource-based design, and layered system architecture. The article then explains how these constraints influenced real world API design today. He connects these constraints directly to the goals of scalability, simplicity, and clear separation of concerns. For example, the statelessness requirements means that each request must contain all the information the server needs, which helps a system scale because servers don’t need client-specific context. His explanation in the article helped me understand that REST is a set of architectural decisions that influence how the entire system behaves and it isn’t nearly as independent as I thought.

The article also discusses how to apply REST principles in API design. Lazarov highlights the importance of resource-oriented URLs and matching HTTP methods, GET for retrieving, POST for creating, PUT for updating, and DELETE for … deleting. He also greatly emphasizes using meaningful HTTP status codes to communicate consistently. These design choices might seem small, but that’s kind of the entire point, these choices contribute to APIs that are predictable and easier for clients and developers to understand. Rather than presenting REST as a rigid formula, Lazarov explains how these principles guide the structure of modern APIs, helping developers create interfaces that are both intuitive and aligned with broader architectural goals.

I selected this article because I believe that it directly ties into topics we’ve explored in 343. REST APIs are essentially interfaces between components of service, so understanding why they are designed the way they are is directly relevant. I also wanted a source that explains the “why” behind REST’s patterns instead of just the “how.”

What I learned most from this article is how intentional REST API design is and what it should look like. I had previously thought of endpoints of pretty arbitrary choices, but Lazarov’s explanation helped me understand that each part of an API should reflect the underlying REST principles.

From the blog CS@Worcester – My Coding Blog by Jared Delaney and used with permission of the author. All other rights reserved by the author.

REST Easy: The API Guide Everyone Needs

In a world where apps constantly exchange information, REST APIs play a major role in making that communication fast, smooth, and reliable. Whether you’re checking your bank balance, ordering Uber Eats, or posting on Instagram, a REST API is working behind the scenes. But what exactly is a REST API, and why does it matter? Let’s break it down in a beginner-friendly way.

What Is a REST API?

A REST (Representational State Transfer) API is a set of rules that allows different software systems to communicate over the internet using simple, predictable URLs. REST is not a programming language, it’s an architectural style that uses standard HTTP methods like GET, POST, PUT, and DELETE to perform operations.

For example:

  • GET retrieves data
  • POST creates new data
  • PUT/PATCH updates data
  • DELETE removes data

Because REST uses these familiar operations, it is easy to understand and widely supported across web technologies.

How REST APIs Work

REST APIs treat everything as a resource, which is represented by a URL. For example, an e-commerce API might represent a product like this:

GET https://api.example.com/users/25

When your app sends that request, the API returns a response often in JSON, a lightweight format that is easy for humans and machines to read.

REST APIs follow a key principle: statelessness. This means the server does not store any information about past requests. Each request must contain everything needed to understand it. This makes REST fast, scalable, and ideal for large applications.

Why REST APIs Are So Popular

Because REST is simple, flexible, and language-independent, it has become the backbone of modern web and mobile development. Companies like Google, Amazon, Meta, Stripe, and Spotify structure their services around REST principles.

  • Simple — They use familiar web protocols like HTTP.
  • Flexible — You can use them with any programming language.
  • Scalable — They handle heavy traffic without breaking.
  • Separation-friendly — Frontend and backend teams can work independently.

Companies like Spotify, Google, and Amazon depend heavily on REST APIs to integrate services and deliver smooth user experiences.

Developers prefer REST APIs because:

  • They are easy to build and maintain
  • They work across many platforms
  • They separate frontend and backend development

In short, REST APIs allow apps to interact smoothly, reliably, and efficiently—powering almost everything we do online.

Conclusion

REST APIs remain one of the most important tools in modern software development. Their simplicity and scalability make them ideal for beginners and professionals alike. Whether you’re building your first backend or integrating external services into an app, understanding REST APIs is essential in today’s tech landscape.

References:

https://www.ibm.com/think/topics/rest-apis

https://www.redhat.com/en/topics/api/what-is-a-rest-api

https://aws.amazon.com/what-is/restful-api

https://www.codecademy.com/article/what-is-rest-api

From the blog CS@Worcester – MY_BLOG_ by Serah Matovu and used with permission of the author. All other rights reserved by the author.

Blog 4 – Software License

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.

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 Development – https://www.geeksforgeeks.org/blogs/frontend-vs-backend/#

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

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

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

Going to Backend Development from a Frontend Developer’s Point of View – https://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.