Category Archives: Quarter-3

Blog Post #4

Title: Building Secure Web Applications

Blog Entry:

This week, I developed the issue of web application security- a growing serious field in the software development. With the growing interconnectedness of applications and the increasingly data-driven nature of the application development process, the importance of user information and system integrity is equal to the one of the functionality or performance. The subject is related to the course goals related to the design of systems, software quality, and secure coding practices.

During my research, I paid attention to the general weaknesses that programmers have to deal with, including cross-site scripting (XSS), SQL, and insecure authentication systems. Such weaknesses are usually brought about by a failure to look into security requirements at the initial design phase. As an illustration, the inability to check input correctly may enable attackers to inject bad codes or access classified information. Security by design is based on the idea that protection must be implemented at each stage of development instead of viewing security as an a posteriori.

During my research, I paid attention to the general weaknesses that programmers have to deal with, including cross-site scripting (XSS), SQL, and insecure authentication systems. Such weaknesses are usually brought about by a failure to look into security requirements at the initial design phase. As an illustration, the inability to check input correctly may enable attackers to inject bad codes or access classified information. Security by design is based on the idea that protection must be implemented at each stage of development instead of viewing security as an a posteriori.

I also reviewed the industry best practice of enhancing application security. The common attacks are prevented with the help of techniques like the parameterized queries, the enforcement of the HTTPS protocol and encryption of the sensitive data and the use of the secure authentication frameworks. Periodical code inspection, automated testing, and standard compliance, such as the Top Ten guide by the OWASP, make code developers responsible to the creation of more robust systems. I was also informed that a healthy security culture in a development team, wherein the whole team takes the responsibility of securing the data of its users, is as valuable as any technical measures.

This subject matter was echoed in our discussions in the classroom on software reliability and maintainability. Secure code is just like clean code in that the code will be used over a long period. I was intrigued by the fact that the same principles of design made it more secure such as the principles of clarity, simplicity, and modularity. A well-organized system, which is simple to audit, has fewer chances of concealing undetectable weaknesses.

Reflection:

This study has made me understand that the need to develop applications that are secure is not just a technical one, but also a moral obligation. The developers should be able to consider the risks and the safety of users in advance. Security should not be at the expense of usability but rather it should complement usability to produce software that the user can trust. This attitude has motivated me to follow safe coding practices early in my work which includes validating inputs, data handling and sound frameworks.

In general, this discovery broadened my perspective on contemporary software design to include aspects of performance and functionality. Security is a key component of quality software engineering like never before. With these principles combined, I am more confident that I will be able to create applications that are efficient and scalable, besides being user-safe in the ever-digitized world.

Next Steps:

Next time, I will test some security orientated tools in the form of penetration testing systems and auto vulnerability scanners. I will also consider reading more on OWASP guidelines as a way of enhancing my knowledge on emerging threats and mitigation controls.

From the blog CS@Worcester – Site Title by Yousef Hassan and used with permission of the author. All other rights reserved by the author.

Software Frameworks

One day we played with “Hello world”, a couple arrays, and some text input from the user, and the next, we messed with a small terminal-based game, and ran an algorithm on some data. Up to this point, much, if not all, of the software most students have produced has been a relatively small, fairly local program, communicating with no more than a few other files within the same application, or to a tool like Docker.

When it comes to building applications with feature-sets that a business needs to operate smoothly, and ultimately make money, the scale and complexity of the applications being developed grows rapidly. Developing software to fully satisfy business requirements can be a very complicated and tedious process, and that is just the reality of engineering software.

In light of the challenges of efficiently and reliably producing software that works for a business’ use-case, developers have come up with many ways to streamline the process. One of the most popular ways to do this is to utilize a “framework”. To gain a better understanding of what a framework is in software engineering, I read through a blog post on Contentful, linked here:

https://www.contentful.com/blog/what-is-a-framework/

A programming framework is essentially a pre-built skeleton for an application. There are many different types of framework, those for the frontend, the backend, servers, mobile, and whichever it is, ultimately the goal is always the same; almost every application ever made is going to use these exact same functionalities, so now they are just bundled together for us to extend with our specific business logic.

Naturally, having a ton of parts of your application already put together and ready to be extended comes with major advantages, and unsurprisingly, a couple potential disadvantages.

The most significant upsides for frameworks come in the form of faster development, fewer accidental set-up errors, built-in security, and a baseline ground-level for applications, so all developers can know we’re working with a “Django” framework, for example. All of these benefits are massive, for both developers, and businesses.

The downside with a framework is that it’s already put together as it should be, and you probably shouldn’t change that skeleton, leaving you with less freedom to develop the application exactly as you might like. It also requires onboarding developers into that framework, as even if someone has worked with Python before, using the Django framework requires learning some more specific implementation methods and best practices related to everything Django is, not just Python.

I’ve enjoyed reading about software frameworks, as even though I’d heard of Angular, or Ruby on Rails, I didn’t fully understand what exactly was so important about these frameworks, and why so many of them were present on job postings everywhere. After reading about them, the answer couldn’t be more obvious. Professional developers will utilize these tools to improve and streamline their workflows, and that’s that!

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

Understanding REST API

Hello everyone

This week’s blog will focus on REST APIs, a topic we’ve been working with heavily in class and one that, admittedly, has left me in awe because I have realized how useful it is. Writing these blogs has actually been helping me a lot in understanding the topics we go over in class in a deeper level. Some new topics can be overwhelming at firsts but writting the blogs allows me to break down the complex concepts and understand them easier. While looking for different blogs that went over this topic, I found one that really stood out and grabbed my attention.

The author of the blog begins the blog with a clear definition of what REST API is, and this helps the reader to easies its way into the blog. I like how he stated the definition of REST API and then later one he rewords that definition in simpler terms. This allows readers who are new to REST API to not get overwhelmed and get scared by technical words. This is something that I personally value a lot and appreciate it when authors do that for us the readers. He then continues by mnentioning the six Principles of REST and follows it up by explaining each principle. For each principle he does an amazing job at explaining the core idea behind it without overwhelming the reader. He keeps it simple, not too long and follows it up with great examples making it simpler to understand each concept. I can’t explain every principle here but I will write a single sentence for each of them and what helped me the most in understanding them. Let’s first start by listing the six principles of REST API which are: Uniform Interface, Client-Server, Stateless, Cacheable, Layered System and Code on Demand. So the uniform interface constraint represents the idea that all components in a system should follow a general, consistent method of communication. The client-server principle emphasizes separating interface concerns from data storage so apps can be more portable and servers simpler. Statelessness means each request from a client must contain all the information needed to be understood—nothing is stored between requests. Cacheability allows clients to reuse certain response data to improve performance. A layered system restricts each component to interacting only with the layer directly beneath it, helping maintain structure and scalability. Finally, code-on-demand allows servers to extend a client’s functionality by sending executable code, though this one is optional as mentioned by the author but still a nice touch that he added it.

In conclusion, this blog was very informative and did an amazing job at teaching me more about REST API and helped me see the purpose of it, which is to make applications simpler, more scalable, and easier to maintain—for both clients and developers. The more you get into software programming the more you appreciate stuff like this and now I can even understand them which is the best part of learning!

Source: https://restfulapi.net/

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

Improving your API documentation using Swagger and OpenAPI

OpenAPI and Swagger are huge tools that software developers use every day. It is vital to use in order to build clear, maintainable, and interactive API documentation. The article I chose was named “How to improve API documentation with Swagger and OpenAPI”. The article explains that APIs are central to modern software design, and their documentation plays a critical role in ensuring that developers can consume and maintain them correctly. The article argues that using the OpenAPI Specification combined with the Swagger ecosystem brings standardization to REST API documentation that is very needed. It also explains that the OpenAPI Specification is readable by people and machines and explicitly defines an API’s structure along with its endpoints, parameters, responses, and data models. This standardization helps teams avoid ambiguity that often comes from loosely documented APIs. 

There are also many tools that come with swagger such as the editor, UI, codegen, and inspector. The editor lets developers create and edit OpenAPI definitions in JSON or YAML, with built-in validation so syntax errors can be caught immediately. The UI turns OpenAPI definitions into documentation that users can try out API endpoints from their web browsers. The codegen generates client libraries, server stubs, and SDKs that help to speed up the development process on different platforms. Finally, inspector is a tool for testing APIs directly and generating OpenAPI definitions based on existing APIs. 

There is also a recently updated version with the official release of OpenAPI 3.0 allowing more modularity and an approach to defining the surface area of an API. This approach provides more versatility when describing the API request and response model. The latest version also reinforces the importance of good schema and component reuse, as well as multipart document handling.

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 that is nice and handy, but a necessity in being a skilled developer. From now on I plan to strengthen my understanding of swagger and APIs as I believe that it will also help me in landing a job in the future.

https://www.techtarget.com/searchapparchitecture/tip/How-to-improve-API-documentation-with-Swagger-and-OpenAPI?utm_source=chatgpt.com

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

Blog 3 – Understand clean code

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.

CS-348 Quarter 3 Blog Post

For Quarter 3 I’ve chosen this article written by Ting Yu from the The Brink, at Boston University.
https://www.bu.edu/articles/2022/how-copyrights-patents-trademarks-may-stifle-creativity-and-progress/

This article was written in August of 2022. It establishes and idea that law has not been able to keep up with the development of the digital era. This idea, proposed by Jessica Silbey, an expert on constitutional and intellectual property law argues that current law does nothing to advance the public’s creativity and ability to make society better for the collective, instead society lined up today to empower individuals and corporations. In other words, Silbey explains that the idea of individual copyright and trademarking of ones own work is more an empowerment to exclude, making copyright and trademark law seem more on the offensive than defensive.

The reason I decided that this article fit the bill for the semester is of course its relevance to our topics surrounding copyright law and trademarks of our work as programmers and developers. But at the same time I chose it for its interesting take on the implications of copyright law and trademarks on the creativity of the public.

Pulling down from the summary of the article about the empowerment to exclude being used to describe copyright and trademarks, at first it felt like a weird take but the more I thought about it the more it made sense to me. While at face value the idea of copyright and trademarks is to protect the intellectual property of whoever created said property, on the grand scheme of things, especially in a world where you can instantly contact someone from the other side of the planet in an instant it does feel more like a trademark plays the role of a bouncer at the entrance of a club, letting in select people and excluding others. Although the people not being the problem but the intentions of said people as trademarks and copyright determine what one can do with an intellectual property. Something specific that Silbey brings up that to me shows the severe issue with current law is the example about how in days long past, it was usually the inventor of something who would own the patent to said thing, but in todays world its teams of people working all towards a single goal, usually in competition with other companies. Leaving copyright and trademarks usually in the hands of the company the team is operating under depending on contract stipulations. For example the battle between Microsoft, Sony and Nintendo to be the next big innovator in the gaming industry creates hostile work environments powered by profit and quotas. Copyright and trademarks usually held tight with an iron fist by these companies. So while I do need to give this idea more thought I definitely think Silbey has a strong point that shes making for us.

From the blog CS@Worcester – Splaine CS Blog by Brady Splaine and used with permission of the author. All other rights reserved by the author.

Week 3-CS 343 blog: REST API DEVELOPMENTS AND BEST PRACTICES

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.

Blog Post for Quarter 3

November 16th, 2025

Considering how clean code was recently on my mind (mostly due to a recent assignment), I thought it might be interesting to look into. I ended up finding out that there a various style guides (well, a comic from an assignment also showed me that too) and this blog shows some examples. It is nice as a basic overview of some style guides. It most notably noted 3 types of styles that revolve around whitespace usage and brace placement. It compliments what I was learning in class as the class typically focused on things like function and variable names, reducing the amount of nested loops, and the usage of too many parameters. The blog goes over how some styles place braces in a way to make it easier to parse through things like heavily nested loops and such. These both end up telling of ways to increase clarity but in different ways, which is super fascinating.

Interestingly, this led to me to look at my own code. My current code uses the “Allman” style of braces. This was taught to me back in AP Computer Science back in high school. I vaguely remember “Allman” being discussed in class, but I never made the connection between it and how I typed code. I ended up doing it since it was the easiest to read. Well, that and the professor told me that this was the “proper” way to code. (I vaguely remember the thing I did code in also automatically did it for me too.) Since then, I’d sometimes just go around and putting braces in that format. (Perhaps I’m worse off due to this since I overly rely on a style. I’ll need to learn to read other styles soon.)

Overall, I’ve mainly noticed my code is super, super bad. Like, overly bad. So next time I code something, I should do many different things. This blog I picked and the assignments on “clean code” would be a good start honestly. (Unfortunately, as someone who “thinks by doing,” I had a habit of creating copious amounts of technical debt without even realizing it. Then again, I was always the type to prefer redoing things entirely as opposed to looking for minor improvements….) Maybe one day my code will be actually good for once. And thankfully, I’ve got various places to start improving. There’s a long road ahead…. Well, at least that means that I have a lot of ways I can improve; the plateau isn’t here just yet. In fact, it is very far from where I am.

https://iannis.io/blog/the-ultimate-code-style/

From the blog CS@Worcester – Ryan's Blog Maybe. by Ryan N and used with permission of the author. All other rights reserved by the author.

OpenAPI and Cloud POS

I came across an article from Oracle that talks about the benefits of a cloud POS system that uses an OpenAPI backend. It starts by highlighting the importance of having a cloud POS system in a restaurant. The biggest benefits are its responsiveness, scalability, and security. It allows businesses to add and drop menu items with ease, and prioritize orders in the kitchen. It comes with built-in analytics to help them make decisions. Oracle tells about how Simphony, their cloud POS system, has local storage to allow the system to continue working through internet outages. Next, they compare OpenAPI to private API. The main difference is that OpenAPI allows for developers to connect the software more seamlessly with less restrictions. Private API, on the other hand, is only really available to internal developers, making it less user friendly. They then talk about how Simphony is built on OpenAPI architecture, making it easier for the customer to interact with, getting data and feedback quicker. This makes for a more trusting relationship between partner and client. They make a point that it provides both scalability and security. OpenAPI is flexible and responsive, giving businesses that choose to use a POS system with open API architecture an edge. In restaurants specifically, it allows for the front of the restaurant to connect with the kitchen more easily.

The reason this was important for me to read and write about is that we are spending a lot of time in my CS343 class discussing OpenAPI. It isn’t the easiest thing to grasp, but the more we learn about it, the more interested in it I am. This was especially interesting to me because Oracle is a very big tech company, and I was curious to see how they marketed their product that uses OpenAPI architecture. As we are learning about OpenAPI systems through real-world applications, it is always interesting to see how these things are applied in a real work environment. A POS system is a very appropriate use for OpenAPI. I enjoyed learning about the different types of products that Oracle offers using OpenAPI architecture. It was also cool to see how a company like Oracle uses OpenAPI and encourages their customers to use their products with it as well. It is reassuring to see how wide-spread the use of OpenAPI is. This encourages me to learn more about it in the future, and to make sure I am well versed in this subject matter.

https://www.oracle.com/apac/food-beverage/restaurant-pos-systems/simphony-pos/why-choose-cloud-pos-system-open-api/

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

Better your Coding Standards

For this quarters blog, I decided to write about Coding Standards and chose to read Why You Need Coding Standards by David Mytton. To start off, Mytton talks about what does “proper” code really mean. It is not just any code that works, but rather code that is easy to fix, add to, and update in the future. His blog mentions a common problems that we face today. Many developers start learning code with their own style which only they might understand. Once a project grows and other people join in, different styles will collide and make the code confusing. Mytton explains the frustration of working with messy code and how stressful it is to scroll through long, unclear code with confusing variable names, missing comments, and code without spacing.

There are two main examples that were used to show the difference that coding standards make. Both examples were written in PHP, the first example was messy. There wasn’t spacing, variable names were unclear, no braces around control structures, and long conditions missing parentheses. Although it technically worked, it was definitely hard to read at first. The second example showed the same logic. This time around there was clean formatting, clear variable names, proper indentation, and braces correctly placed. I’ve never used PHP but it was obvious that the second example was much easier to understand.

I selected this blog because recently in class we’ve been working on clean coding and realized how hard it can be to understand code written in different ways. I also wanted to further my understanding of how professionals handle this problem and how they keep projects organized. I think that this blog was able to explain that point in a simple and relatable way for me.

From this blog I learned that coding standards are beyond just “good habits.” It prevents confusion, reduces mistakes, and allows projects to run more smoothly. I also learned that a coding standard is not something that just one person creates and uses for themselves but rather by the whole team. I hope that I am able to fix my poor coding habits and write code that allows others to collaborate with my work. I think before this, I didn’t care much whether somebody would be able to read my code but rather if it was able to run then I was satisfied. My mindset has changed and I want to be more consistent with following coding standards.

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