merging main to my branch

README.md

@@ -25,6 +25,8 @@ Potential Topics--
 
     7. React Native
         1. Set up
+    8. Unity
+        1. Introduction to Unity Basics
 
 - Software Tools
     1. Git

Topics/Development_Process.md

@@ -1,72 +1,95 @@
 ## Resources for Development Process
+
 ## Git
+
 ### [Learning Git](./Development_Process/Git/Git.md)
+
 ### [Trunk-Based Development](./Development_Process/Trunk_Development.md)
+
 ### [Django Project Deployment: AWS, Vercel, and Railway](./Development_Process/Django_Deployment_AWS_Railway_Vercel.md)
+
 ### [Automated Frontend Deployment with Vercel](./Development_Process/Frontend_Automated_Deployment_Vercel.md)
+
 ### [Flask Application Deployment on Heroku](./Development_Process/Flask_App_Deployment_Heroku.md)
+
 ### [Quality Assurance Testing](./Development_Process/QA_testing.md)
+
 - [Automated Testing](./Development_Process/Automated_Testing.md)
 - [Large Language Model (LLM) for Testing and Debugging](./Development_Process/LLM_Testing_Debugging.md)
+
 ### [Getting Started With Docker](./Development_Process/Docker.md)
+
 ### [Getting Started With WSL 2](./Development_Process/WSL.md)
 
+## Nginx
+
+### [Introduction to Nginx](./Development_Process/Nginx.md)
+
 ## Build requirements
+
 ### [Requirements.txt](./Development_Process/Build_Requirements/Requirements_txt.md)
 
 ## React Testing Library
+
 ### [React Testing Library](./Development_Process/React_Testing_Library.md)
 
 ## URL Sanitization
+
 ### [URL Sanitization](./Development_Process/URL_Sanitization.md)
 
-## SOLID PRINCIPLES: 
+## SOLID PRINCIPLES:
 
 SOLID is a mnemonic acronym that represents a set of five very important software development principles which lead to code that is easier to read, maintain, and extend, leading to higher-quality software that is easier to evolve over time.
 
 The SOLID principles are:
 
- - Single Responsibility Principle (SRP): A class should only have one cause to change, according to the Single Responsibility Principle (SRP). According to this theory, a class ought to have just one duty, which implies that there ought to be just one motivation for change. This makes the class more understandable, maintainable, and reuseable as well as more flexible.
+- Single Responsibility Principle (SRP): A class should only have one cause to change, according to the Single Responsibility Principle (SRP). According to this theory, a class ought to have just one duty, which implies that there ought to be just one motivation for change. This makes the class more understandable, maintainable, and reuseable as well as more flexible.
+
+- Open/Closed Principle (OCP): Software entities (classes, modules, functions, etc.) should be available for extension but closed for modification, according to the available/Closed Principle (OCP). According to this principle, a system should be able to introduce new functionality without requiring changes to the existing code. Interfaces, polymorphism, and generalization are used to accomplish this.
+
+- Liskov Substitution Principle (LSP): Subtypes must be able to be used in place of their parent types. According to this concept, it should be possible to swap out objects from a superclass for objects from a subclass without having any negative effects on the program's correctness. This necessitates abiding by the superclass's compact.
+
+- Interface Segregation Principle (ISP): Clients should not be forced to depend on interfaces they do not use. This principle states that a client should not be forced to implement an interface if it does not use all of the methods defined by the interface. This helps to avoid the creation of fat interfaces, which are interfaces that contain more methods than the client needs.
 
- - Open/Closed Principle (OCP): Software entities (classes, modules, functions, etc.) should be available for extension but closed for modification, according to the available/Closed Principle (OCP). According to this principle, a system should be able to introduce new functionality without requiring changes to the existing code. Interfaces, polymorphism, and generalization are used to accomplish this.
+- Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions. This principle suggests that classes should depend on abstractions rather than concrete implementations, which makes the system more flexible and easier to modify.
 
- - Liskov Substitution Principle (LSP): Subtypes must be able to be used in place of their parent types. According to this concept, it should be possible to swap out objects from a superclass for objects from a subclass without having any negative effects on the program's correctness. This necessitates abiding by the superclass's compact.
+## Resource that gives examples of the uses cases of SOLID principles
 
- - Interface Segregation Principle (ISP): Clients should not be forced to depend on interfaces they do not use. This principle states that a client should not be forced to implement an interface if it does not use all of the methods defined by the interface. This helps to avoid the creation of fat interfaces, which are interfaces that contain more methods than the client needs.
+LINK : https://www.youtube.com/watch?v=_jDNAf3CzeY
+
+## Clean Architecture:
 
- - Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions. This principle suggests that classes should depend on abstractions rather than concrete implementations, which makes the system more flexible and easier to modify.
-
-
- ## Resource that gives examples of the uses cases of SOLID principles
-  LINK :  https://www.youtube.com/watch?v=_jDNAf3CzeY 
-
- ## Clean Architecture: 
-
 A system's design that divides it into logical parts and specifies how those parts may communicate with one another is referred to as clean architecture. The objective is to make the software system easier to design, deploy, operate, and maintain while still keeping as many options open  for as long as possible.
 
 Clean Architecture works on the well-defined division of layers. It is important to understand what the different layers are and which layers are allowed to interact with each other. The independence that clean architecute introduced to the a software system is vital since it reduces dependancies within the system. In clean architecture, the elements of the inner most layers should not have any information about the outermost layers. Anything declared in an outer layer must not be used anywhere within the inner layer of the code.
 
-![image](https://user-images.githubusercontent.com/75923742/227027780-b5fbf347-ff78-49fa-a122-8f9ac4ef53d4.png)  
+![image](https://user-images.githubusercontent.com/75923742/227027780-b5fbf347-ff78-49fa-a122-8f9ac4ef53d4.png)
+
+Some of the layers are (Simplified):
 
+- Business Rules:
 
-Some of the layers are (Simplified): 
-- Business Rules: 
   - Entity: A component of our computer system that represents a condensed set of critical business rules that are applied to crucial business data.
   - Use Case: Gives specifics on the input the user must supply and the output the system must deliver to the user. Additionally, it includes the processing steps required to create the result.
 
-- Entities: Contains functions, variables, and other structures that hold the main objectives of our application, they must be general and have the highest level of rules. 
-- Interface Adaptors: Responsible for communicating between the layers, takes data in and transforms it such that it can be sent to lower levels. 
+- Entities: Contains functions, variables, and other structures that hold the main objectives of our application, they must be general and have the highest level of rules.
+- Interface Adaptors: Responsible for communicating between the layers, takes data in and transforms it such that it can be sent to lower levels.
 - Framworks and Drivers: This section contains frameworks and databases responsible for communicating with the interface adapters.
 
+This is only a simplification of what "Clean Architecture" is; the topic is so vast that there have been texts that have been dedicated to this topic. Some resources that can be beneficial in understanding and clearing up any doubts about the topic have been linked below.
 
-This is only a simplification of what "Clean Architecture" is; the topic is so vast that there have been texts that have been dedicated to this topic. Some resources that can be beneficial in understanding and clearing up any doubts about the topic have been linked below. 
+- Text that goes into greater depth about each layer:
 
-- Text that goes into greater depth about each layer: 
-   - https://dev.to/rubemfsv/clean-architecture-the-concept-behind-the-code-52do#:~:text=The%20main%20rule%20for%20Clean,elements%20of%20an%20outermost%20layer.  
+  - https://dev.to/rubemfsv/clean-architecture-the-concept-behind-the-code-52do#:~:text=The%20main%20rule%20for%20Clean,elements%20of%20an%20outermost%20layer.
 
 - Article Summarizing Clean Architecture (Examples and Code)
-  -  https://pusher.com/tutorials/clean-architecture-introduction/
+
+  - https://pusher.com/tutorials/clean-architecture-introduction/
 
 - A very detailed explanation of Clean Architecture by Robert C. Martin or Uncle Bob and his book
+
    - https://www.youtube.com/watch?v=2dKZ-dWaCiU 
    - https://github.com/ropalma/ICMC-USP/blob/master/Book%20-%20Clean%20Architecture%20-%20Robert%20Cecil%20Martin.pdf 
+
+## Code Smells
+### [Code Smells](./Development_Process/Code_Smells.md)

Topics/Development_Process/Code_Smells.md

@@ -0,0 +1,37 @@
+## Code Smells
+Code smells refer to certain types of code that, while functional, will require increasing accommodation as more code begins to rely on the "smelly" code. While it is possible to ignore these types of code, the longer that they remain, the harder it becomes to fix issues they directly or indirectly cause in the future. Therefore, it's in a developer's best interest to be familiar with a broad spectrum of code smells so that they may identify and eliminate them as soon as possible.
+
+
+## A Motivating Example
+Consider the following snippet of code:
+
+```
+class Something:
+     temp_field: int
+
+     def do_something(self) -> int | None:
+         if self.temp_field == None:
+             return None
+         else:
+             return self.temp_field + 1
+```
+On its own, this code is functional, but it raises a number of questions. For example: when exactly is `temp_field` equal to `None`? When does it actually store relevant data? This answer is largely dependant on how the class `Something` is used, but the specifics may not be clear to someone reading this code. 
+
+This code smell is known as a "Temporary Field", which is when classes are given attributes to be used in some of their methods, but in some cases the attribute stores null values. While adding null checks easily allows code using these attributes to function, it decreases code readability, and if the technique is abused it can easily lead to unnecessarily long code. To fix this, refactoring is required.
+
+## Refactoring
+Refactoring is a software development practice in which code is rewritten such that no new functionality is actually provided, but the code becomes cleaner and better accommodates future extensions of features. While it is generally recommended in software development that code should not be rewritten, but extended (see the [Open/Closed Principle of SOLID](../Development_Process.md#solid-principles), refactoring typically prevents more significant amounts of code rewriting that may be required in the future.
+
+Many refactoring solutions to code smells are well-established and should be drawn upon once relevant code smells are identified. One such solution for the previous example is known as "Introduce Null Object", in which attributes that may be null should be defined over a new "Null" class, which can provide default values when the aforementioned attribute would have previously been null. This contains any null checks to the new class, allowing for the removal of if-statements in other code that may cause confusion or excessive code length. Furthermore, future code that may deal with the previously temporary field will also no longer need any null checks, as the new class does it for them. Thus, refactoring improved both the readability and extendability of the former code.
+
+## Categories
+While there may be many different types of code smells, all of them fall into one of five categories that can more easily be identified when writing code. The categories are as follows:
+- Bloaters
+- Object-Oriented Abusers
+- Change Preventers
+- Dispensables
+- Couplers
+
+## More Info
+For further insight into all the different types of code smells including explanations, examples, and solutions, the following resource is highly recommended:
+https://refactoring.guru/refactoring/smells