Blog Post 3

https://www.freecodecamp.org/news/permissive-and-protective-software-licenses/

For this blog entry I’ve decided to dig into the world of software licenses. In class we went over quite a few different licenses like GPL, MIT, and Apache, but just looking through the https://www.tldrlegal.com/browse site, it’s clear we only scratched the surface. That’s not even including the fact that from what I understand anyone can make up their own license with a word doc and lawyer, and the list of different licenses just grows. Yet despite that all licenses have a common goal, which is to explain who can do what with somebodies work and what they can do with it. This is a very important aspect to software development, which I never really considered as something I would have to think too deeply on, mainly because legal matters aren’t really my expertise. Because of that I wanted to find a blog post that could break things down in a way even someone like me could understand.

In my search I found How Do Open Source Licenses Work? Permissive and Protective Software Licenses Explained written by David Clinton. In the post David broke the types of licenses into two categories, permissive and protective.

On the permissive side we have licenses like MIT and Apache. With these types of licenses they basically let people do almost whatever they want. The article puts it pretty clearly: permissive licenses “give you the right to use the software for any purpose – including commercial purposes – and the right to modify the software to suit your needs.” For someone like me who prefers simple, straightforward rules, this one seemed the one I’d be most compatible with.

Then we have protective licenses, which David also referred to as restrictive licenses. These are the copyleft licenses like GPL that we went over in class. Similar to permissive licenses they give the users the right to use, modify, and distribute the software, but with the extra conditions that said software must remain free and open source now and forever. Considering this I can understand why David would call these types of licenses restrictive, but at the same time a part of me understands and appreciates someone who would choose this type of license.

After reading this blog post I definitely got a better understanding of the different types of licenses and David did a good job in breaking it down to the essentials. The thing though is that while it answered the question on how licenses work, I am now posed with the question of which type I’d choose. On the one hand I like the flexibility of permissive licenses and the fact that you can either share or sell your work. On the other hand protective licenses seem to prioritize “the little guy” and keeping improvements in the open, which I like, but I also know if I put in the work of making improvements I would like the option to get paid, though I guess that says more about me. So much too think about.

From the blog CS@Worcester – CS Notes Blog by bluu1 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

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.
					

		
		
	

							
	

				

			
						

				The art of REST API design
			

								


				

			
Something I have personally never worked on as a developer is REST API. AWS is a piloting force in the sphere of web development so there was no better place to read up on this subject than there. Going through you can really see why REST API is so vital to the modern web.


An overview of REST API design principles, methods, and benefits, illustrating key concepts for web development.


What is an API?


API stands for Application Programming Interface, this defines the rules you must follow to communicate with other software systems. 


API is a gateway betweek:


    

  • Clients: Users who want to access information from the web
    • 

  • Resources: The information that different applications provide to their clients.
    • 



What is REST?


REST stands for Representational State Transfer, this is a software architecture that imposes conditions on how an API should work. It was originally created as a guideline to manage communication on complex networks. As a result one architecture developers can use is RESTful API.


Here are some of the principles of the REST architectural style:


    

  • Uniform interface

      

    • Indicates the server transfers information in a standard format
      • 

    • 4 architectural contraints:

        

      • Requests should identify resources
        • 

      • Clients have enough info in the resource representation to modify or delete the resource if wanted
        • 

      • Clients receive info about how to process the representation further
        • 

      • Clients receive info about all other related resources they need to complete a task.
        • 

      

      • 

    

    • 

  • Statelessness

      

    • A communication method in which the server completes every client request independently of all previous requests
      • 

    

    • 

  • Layered System

      

    • Client can connect to other authorized intermediaries between the client & server, and it will still receive responses between the server
      • 

    

    • 

  • Cache-ability

      

    • Able to store some responses on the client or on an intermediary to improve response time
      • 

    

    • 

  • Code on demand

      

    • Servers can temporarily extend or customize client functionality by transferring programming code to the client.
      • 

    

    • 



Benefits to REST API:


Here are the few of the benefits AWS includes:


    

  • Scalability
    • 

  • Flexibility
    • 

  • Independence
    • 



How it works:


The basic functions are similar to browsing the internet, here are the general steps towards any REST API call:


    

  1. The client sends a request to the server
    2. 

  2. The server authenticates the client and confirms permissions to make request
    3. 

  3. The server receives request and processes it
    4. 

  4. The server returns a response to the client.
    5. 



The client request contains these main components:


    

  • Unique resource identifier
    • 

  • Method

      

    • GET

        

      • Access resources at URL
        • 

      

      • 

    • POST

        

      • Send data to server
        • 

      

      • 

    • PUT

        

      • Update existing resources on the server
        • 

      

      • 

    • DELETE

        

      • Request to remove resource
        • 

      

      • 

    

    • 

  • HTTP headers

      

    • Data
      • 

    • Parameters

        

      • Path: Specifies URL details
        • 

      • Query: Requests more info about resource
        • 

      • Cookie: Provides authentication
        • 

      

      • 

    

    • 



Final Thoughts:


My understanding of REST APIs was very limited but leave it to the best in the business to have all the information necessary to learn. I definitely think it would take time to implement nonetheless but having this basic understanding is important in the end. If you want to learn more yourself visit this page on AWS.


, , 



From the blog Petraq Mele blog posts by Petraq Mele and used with permission of the author. All other rights reserved by the author.
					

		
		
	

							
	

				

			
						

				Using environments to develop software
			

								


				

			
Different environments in software development, outlining the roles of Development, Testing, Staging, and Production environments.


So you want to get started with developing a piece of software but aren’t quite sure where exactly you are meant to do that. Well luckily for us we have environments created specifically for developing software.


Introduction to development environments


Put simply, it is an environment which provides developers with a workspace that features programming software and other resources and processes required to develop source code for an application.


Some key components of development environments can include:


    

  • A physical or virtual machine, including an underlying operating system, database system, and so on.
    • 

  • Development tools, including development environments, compilers, and libraries.
    • 

  • Data management solutions
    • 

  • Associated services, including internally hosted resources and external environments, such as those running in the cloud.
    • 



Environments must be able to support a few things like:


    

  • Writing code
    • 

  • Debugging
    • 

  • Testing
    • 

  • Version control
    • 



The importance of these environments


All developers can find benefits to using these environments. It helps improve productivity, stability, reliability, and more towards development.   The usage of these environments speaks for themselves as to just how beneficial they truly are to software developers.


Integrated development environments (IDE):


An overview of Integrated Development Environments (IDE), highlighting key features like writing, debugging, and running code.


IDEs are a very popular form of Software development environments. Some popular IDEs, a few of which you have almost guaranteed heard of, include:


    

  • The JetBrains environments (CLion, GoLand, PyCharm, RubyLand)
    • 

  • Visual Studio
    • 

  • Eclipse
    • 

  • XCode
    • 

  • Android Studio
    • 



A bar chart displaying the most popular integrated development environments (IDEs) from 2004 to 2019, highlighting Android Studio and Visual Studio as top choices.


What makes these environments to attractive is that they are fairly user friendly, with a little practice of course, and paired with the fact that they can be extremely customizable therefore giving a software developer the freedom to focus on other things related to their developments. 


Final thoughts


Doing my research in development environments taught me just how many different development environments there are, all useful in their own respective ways, and many open-source as well. I am used to using a few IDEs like Eclipse for Java development or Visual Studio for general development but expanding my knowledge of environments is very useful for specialized projects. If you wish to learn more I would highly suggest reading this article from devzero.


, , 



From the blog Petraq Mele blog posts by Petraq Mele 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.
					

		
		
	

							
	

				

			
						

				A SIMPLE UNDERSTANDING OF SOLID PRINCIPLES.
			

								


				

			
When I first started writing object-oriented code, I struggled with messy classes, confusing logic, and unexpected bugs from the smallest changes. It felt like no matter how hard I tried to stay organized, something always broke. Learning the SOLID principles completely transformed the way I write code. These five guidelines helped me simplify my projects, make them easier to extend, and create code that finally made sense. If you’re just starting out, I hope this breakdown helps you the way it helped me.


1. Single Responsibility Principle (SRP)


A class should only have one job. That’s it.
When one class tries to do everything ,handle data, print reports, manage files, and validate input ,it becomes fragile. Changing one responsibility risks breaking another. I used to write huge classes thinking it would “keep things together,” but it only created chaos. Once I started separating responsibilities into smaller classes, everything became easier to understand and debug.


2. Open–Closed Principle (OCP)


Your code should be open for extension but closed for modification.
This principle protects working code from unnecessary edits. Instead of constantly changing old methods, you extend behavior through new classes or strategies. It’s like adding a new room to a house without tearing down the entire structure. OCP helped me stop rewriting code that already worked and start building on top of it safely.


3. Liskov Substitution Principle (LSP)


Child classes should be usable anywhere the parent class is expected without breaking the program.
This matters when using inheritance. If a subclass changes behavior in a way that surprises the rest of the program, it violates LSP. Understanding this helped me avoid “clever” inheritance tricks that only made my code harder to maintain.


4. Interface Segregation Principle (ISP)


Don’t force classes to depend on methods they don’t use.
Large interfaces lead to confusing, overloaded classes. Smaller, more focused interfaces keep your code clean and prevent unnecessary dependencies. ISP taught me that more interfaces and not fewer can actually make a system easier to manage.


5. Dependency Inversion Principle (DIP)


Depend on abstractions, not concrete classes.
This principle makes your code flexible and testable. By depending on interfaces instead of specific implementations, you can swap parts of your system without rewriting everything. DIP made testing and updating my code so much easier.


In conclusion, the SOLID principles aren’t just theory, they truly make your projects cleaner and more maintainable. You don’t need to master them overnight. Start applying one principle at a time, and soon your code will naturally become more structured, scalable, and beginner-friendly. If I could learn it, you absolutely can too.


References:


https://www.freecodecamp.org/news/solid-principles-explained-in-plain-english/



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