Category Archives: cs-wsu

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.

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.

Blog Post #4

Building Secure Web Applications

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.

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.
					

		
		
	


	

				

			
						

				Blog Post #4
			

								


				

			
Building Secure Web Applications


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.


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.
					

		
		
	


	

				

			
						

				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.
					

		
		
	


	

				

			
						

				Trending code practices
			

								


				

			
Article: https://github.blog/news-insights/octoverse/what-986-million-code-pushes-say-about-the-developer-workflow-in-2025/?utm_source=octoverse-cli-announcement&utm_medium=octoverse&utm_campaign=universe25post


GitHub, in this blog post goes over the various trends and changes within pushes and changes made to very high profile repos. These conclusions were made from from 986 million pushes made within the platform which gives a very large sample size which in my opinion would extremely accurately present the current recent trends within the tech industry and open source software. One of the conclusions that GitHub brings up is that it is extremely fast to make changes and build software now than ever before and because of this many developers aren’t just pushing when things are totally done, rather they are leaving somethings within their pushes unready but functional to be iterated and done later rather than having everything within the push completely ready. They equate this trend to the saying “done-ness is temporary”, furthermore pull requests are more concise and simple, and feature flags are often used more and more even if they might be “maybe” feature since developers tend to just shut that feature off and push their changes again without it. The last major point that the author brings forward is that communication has to change to reflect the faster nature of development meaning more communication, faster stand-ups and hiring those who ship faster. 


I chose this article due to the fact that the idea that the industry trend of how changes are made fundamentally shifting from large updates to shorter more small and experimental changes is extremely interesting since I’ve noticed this at my work where this is reflected. Often times changes are small and incremental and made to be built off of while maintaining functionality. Even more so my employers policy for pull requests has changed as well which is more simplistic and straight to the point rather than having such detail. But this isn’t without problem in my eyes as like the article states in order to gain missing information from the request communication is key and becomes even more important, especially in cases where there are present issues that require immediate action.


From this I plan to incorporate more things like being easier to reach for communication and communicating faster to better reflect the changes in trends of pushes, so that incase that I adopt the industry trends of smaller pushes to be iterated on with smaller and simpler pull requests, my workflows remain functional and optimized for the most quality while accounting for the changes in trends. 



From the blog CS@Worcester – Aidan's Cybersection by Aidan Novia and used with permission of the author. All other rights reserved by the author.
					

		
		
	


	

				

			
						

				Polymorphism and Inheritance: Building Flexible Game Characters
			

								


				

			
This topic explores object-oriented programming (OOP) concepts like polymorphism, inheritance, and design patterns, showing how these very basic core concepts create reusable code. In particular, the Gamma et al. book demonstrates practical use of polymorphism and abstract classes to define flexible software structures, while the OpenGL guide shows examples of implementing modular systems, such as game engines, where different objects share common behaviors but have distinct implementations. I chose these materials because developing flexible and scalable gaming systems needs an understanding of polymorphism and inheritance. Multiple character types, enemies, weapons, or objects that behave differently yet have similar functions are frequently included in video games. These resources make it easy for developers to build clear, modular code while handling complex interactions between game objects.


               With polymorphism, game developers can regularly allow different objects while each of them behaves uniquely. For instance, a role-playing game (RPG) may have several characters: Warrior, Mage, and Archer. They get from the common Character class that describe methods like Attack(), Move(), or TakeDamage(). Each subclass overrides Attack () to implement uneasy behavior: the Mage cast spells, the Warrior swings a sword, and the Archer shoots arrows. Without polymorphism, coders would use a lot of conditional statements like if (characterType == “Mage”) … else if (characterType == “Warrior”) …; this goes against Open-Closed Principle (OCP), making it difficult when adding a new character. Using inheritance and polymorphism, the addition of a rogue class would require only the implementation of the Attack() method, while existing code would remain the same.


I believe the contrast between conditional logic and polymorphism in game AI to be instructive. In simple projects, using conditional statements to handle various opponent actions could work, but as the number of characters, skills, and interactions increases, the code rapidly gets crowded and challenging to maintain. In contrast, polymorphism enables any type of enemy—such as a dragon, goblin, or mage—to implement its own action while staying handled by the game engine as a generic enemy object. By using this method, AI action becomes versatile, modular, and simpler to expand, allowing for the addition of new challenge types or unique attacks without requiring changes to the current code.


In the future, I want to use these ideas to develop generic avatar and item systems for my personal projects so that new content can be added without having to rewrite the logic. The usefulness of proper object-oriented design in real-world game production is proven by observing how these concepts are implemented in professional game engines like Unity and OpenGL, which close the gap between theory and practical application.


References


    

  1. Design Patterns: Elements of Reusable Object‑Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson & John Vlissides — Addison‑Wesley, 1994. Link: https://www.oreilly.com/library/view/design-patterns-elements/0201633612/ O’Reilly Media+1
    2. 

  2. OpenGL® Programming Guide: The Official Guide to Learning OpenGL® Version 4.5 with SPIR‑V by John Kessenich, Graham Sellers & Dave Shreiner — Addison‑Wesley Professional, 2016. Link: https://www.oreilly.com/library/view/opengl-r-programming-guide/9780134495514/
    3. 




From the blog CS@Worcester – Pre-Learner —> A Blog Introduction by Aksh Patel and used with permission of the author. All other rights reserved by the author.
					

		
		
	


	

				

			
						

				Building Secure Web Applications
			

								


				

			
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.


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.
					

		
		
	


	

				

			
						

				Effective API Design
			

								


				

			


I have been reading one of the articles by Martin Fowler titled APIs: Principles and Best Practices to Design Robust Interfaces. It discusses how API, or small bridges that are known as Application Programming Interfaces, enable various software systems to communicate and keep up with one another. Fowler emphasizes such points as the clarity of words, offering simplicity, being consistent, and not having to break old versions, and supports it with real code demos and real-life scenarios. It is a combination of theory and practical tips, so every person, who is interested in software design, can dive in.


I picked the read as the API design is one of the foundations of software engineering and intersects my course on Software Development and Integration. I prefer scalable apps that keep their heads clean and easy to be connected to by other developers. Exploring the work of Fowler was my form of education on how to create interfaces with sound principles of how to get folks to jump on and expand therein with no hassle. Most of the stuff that remains all theory-heavy is not so in this article but instead it presents actual, practical tactics, just what one needs at school and in the job.


The importance of versioning and maintaining backward compatibility was one of the largest things that I took away in the article. Fowler gives a reminder that APIs must evolve, but not exist to ruin other clients, which will require you to plan, test, and discuss with your users. That resonated with me as in group projects I had done before, a minor change to our module could bring down the line. Upon reflection, the well-planned API design rules seem to be the instinctive means of preventing such headaches and wasting less time.


I also liked the fact that Fowler emphasized intuitive naming and consistency. According to him, the more predictable the method names, parameters and endpoints are, the friendlier an API is. It actually saves a fair deal of time to establish a proper structure and hierarchy and results in a significant reduction of mix-ups, accelerates integration, and makes the entire process of dev enjoyable. I have remembered that a considerate design ensures not only the end user as well as the people who actually create with the API, but the ecosystem becomes efficient and simpler to maintain.


In the future, I will apply these tricks to my class projects and whatever work I happen to do in the profession. Whenever I create an API to support the web application or integrate more third-party services, I will focus on clean documentation, predictability, and retaining older versions. Following these rules, I will deliver interfaces that are great, that are easy to maintain, that will assist other developers and that will survive update. This paper has made me even more respectful of the discipline of API design, and I am willing to put these tangible strategies to immediate use.



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

		
		
	


	

				

			
						

				Word wide outage
			

								


				

			
https://www.cnn.com/2025/10/25/tech/aws-outage-cause


The cloud AWS provider experienced a massive outage on oct 20, 2025 that shut down or impacted many of the most popular services and products on the internet like Roblox, and snapchat. The outage was so large many systems and product became unusable. This issue stemmed from a DNS issue where multiple automated systems were trying to update the same DNS entry which then threw a empty field. This empty field then was carried down to other services like EC2 which then caused those to fail and further down into other workflows and other systems that relied on services like EC2. Those failures carried down to Network balancers which essentially snowballed into a enormous mess that wrecked many apps and services. I personally clocked into work with our error handling system and alerts absolutely flooded will alarms and alerts. This became so bad my boss told me to just ignore the errors for the day (One of my sprint tasks is to keep alerts down).  I chose this article due to its relevance to testing software and the probable use of git to find out when and where the error occurred. As the use of git bisect could be used to troubleshoot where the issue was introduced into the workflow to find out where the DNS field was assigned to two systems that could trigger at the same time. Furthermore AWS in their statement to the public states that “We know this event impacted many customers in significant ways, We will do everything we can to learn from this event and use it to improve our availability even further” This statement aligns with the values of scrum since it prioritizes openness and respect which AWS gives to its customers by openly documenting the issue that occurred while at the same time stressing the communication with the customers to reassure them in their recovery from the failure. They also follow the AGILE manifesto as they are responding to change over developing a plan since their customers need their services back now, prioritizing getting their services back online rather than documenting and collaborating with customers to have their systems restored. Delivering that they are only releasing their documentation once the system was fully restored under 15 hours showing that they needed to deliver on working software. In a way they could also be benefiting from focusing on individuals and interactions over tools since this error occurred at multiple levels but started at the same point so one tool or process couldn’t immediately understand the root cause. 



From the blog CS@Worcester – Aidan's Cybersection by Aidan Novia and used with permission of the author. All other rights reserved by the author.