merge

README.md

@@ -9,12 +9,31 @@ Following files are present in this directory. You may contribute to any of thes
 Potential Topics--
 
 - Tech stacks
-    1. React Native
+    1. [Nuxt3](https://github.com/learning-software-engineering/learning-software-engineering.github.io/blob/main/Topics/Tech_Stacks/Nuxt3.md)
+
+        Nuxt.js provides server-side rendering, automatic routing, code organization, and pre-configured plugins. It can be used to create applications quickly  and easily.
+
+    2. Django
+        1. Django Rest Framework
+    3. Salesforce API
+
+    4. CSS (Cascading Style Sheets) 
+
+    5. TypeScript
+
+    6. JavaScript
+
+    7. React Native
         1. Set up
+
+- Software Tools
+    1. Git
+        1. Git Workflows
 - Software Engineering
     1. Methodologies & Frameworks
         1. Agile
             1. Scrum
+               1. User Stories
             2. Kanban
             3. XP
         2. Waterfall
@@ -46,14 +65,17 @@ Potential Topics--
         4. Deployment
             1. Heroku
             2. AWS
+                1. Django Project Deployment: AWS, Vercel and Railway
             3. Firebase
             4. Digital Ocean
-            5. 6. Software development best practices:
+            5. Software development best practices:
+            6. Vercel Frontend Deployment (Automated)
     1. Designer Patterns
     2. Clean Coding
         1. Choose a coding style and stick to it
     3. SOLID Principles
     4. Code Smells
+    5. QA testing
 - Professionalism
     1. Customer engagement
         1. Meeting best practices
@@ -65,6 +87,11 @@ Potential Topics--
 
 
 - User Experience
+    1. Overview
+    2. Areas of User Experience
+    3. Helpful Courses
+    4. User Experience Orientated Games
 - Product Management
+    1. Beginner's guide to product management and becoming a successful product manager
 - Other useful resources
-- Teamwork
+- Teamwork

Topics/Development_Process.md

@@ -1,2 +1,68 @@
 ## Resources for Development Process
-### [Learning Git](./Development_Process/Git/Git.md)
+## Git
+### [Learning Git](./Development_Process/Git/Git.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)
+### [Quality Assurance Testing](./Development_Process/QA_testing.md)
+- [Automated Testing](./Development_Process/Automated_Testing.md)
+
+### [Getting Started With Docker](./Development_Process/Docker.md)
+
+
+## Build requirements
+### [Requirements.txt](./Development_Process/Build_Requirements/Requirements_txt.md)
+
+## React Testing Library
+### [React Testing Library](./Development_Process/React_Testing_Library.md)
+
+## 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.
+
+ - 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.
+
+ - 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)  
+
+
+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. 
+- 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. 
+
+- 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.  
+
+- Article Summarizing Clean Architecture (Examples and Code)
+  -  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 

Topics/Development_Process/Automated_Testing.md

@@ -0,0 +1,67 @@
+### Automated Testing
+
+Automated testing is an important part of industry software engineering development, and is
+virtually present at all major companies. While in certain companies, this role will be covered by a
+dedicated QA team, in others, it will be the responsibility of the developers themselves, e.g., at
+Amazon. Regardless, understanding and being able to write unit tests is important for a SWE to be
+able to communicate and standby their code.
+
+The automated testing process is part of the wider build/development process and is usually run as
+part of the CI/CD pipeline. The ultimate goal of automated testing is to ensure that the code
+functions as expected, and that any changes to the codebase do not break existing functionality.
+
+As background, most companies to implement their CI/CD pipeline with their Git implementation (of
+which are usually internal), and so we will be talking about unit testing and integration testing
+from the point of you pushing your code to a Git repository. So imagine that all of these tests will
+be executed from the moment that you push your code to your project repository.
+
+Further, there are usually "pipelines" for each project (e.g.,
+[AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome-introducing.html)),
+and each of your code commits "flows" through your project pipeline. Generally, pipelines are
+usually composed of a series of "stages" that are executed sequentially. For example, after some
+cloud machine builds your code, the first testing stage might be to run the unit tests, and the
+second testing stage might be to run the integration tests. These setups vary from project to
+project, and you may be able to override passing criteria, but testing can lead credence to your
+implementation, and can support allow your code to promote (pass on to) production.
+
+![AWS CodePipeline Diagram](https://docs.aws.amazon.com/images/codepipeline/latest/userguide/images/pipeline-elements-workflow-application.png)
+
+#### Unit Testing
+
+Unit tests are meant to test your code commit(s) specifically, rather than dependencies and other modules that
+may be present in the code base. So unit tests go well with the
+[microservices architecture](https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices).
+The industry will use various frameworks for unit testing, depending on the stack, e.g., language.
+For example, Python uses [unittest](https://docs.python.org/3/library/unittest.html), Java uses
+[JUnit](https://junit.org/junit5/) or [Mockito](https://site.mockito.org/), and
+JavaScript/TypeScript uses [Jest](https://jestjs.io/). A good choice is one that supports mocking,
+spies, and other features that allow you to avoid testing 3rd party function calls (don't run them).
+Instead you should assume some expected behaviour from 3rd party function calls, and write tests
+that cover every "branch" of your code (code coverage). With that stated, some resources for the
+most important parts of unit testing are:
+
+-   **Test Coverage**:
+    - Atlassian: [What is Test Coverage?](https://www.atlassian.com/continuous-delivery/software-testing/code-coverage)
+    - Microsoft: [Code Coverage](https://learn.microsoft.com/en-us/visualstudio/test/using-code-coverage-to-determine-how-much-code-is-being-tested?view=vs-2022&tabs=csharp)
+-   **Unit Test Cases**:
+    -   Guru99: [Unit Testing Tutorial](https://www.guru99.com/unit-testing-guide.html)
+    -   AWS Unit Testing: [Getting started with testing serverless applications](https://aws.amazon.com/blogs/compute/getting-started-with-testing-serverless-applications/)
+    -   Coursera: [How to Write Test Cases: A Step-by-Step QA Guide](https://www.coursera.org/articles/how-to-write-test-cases)
+-   **Mocking**:
+    -   Mocking in Python: [Mocking in Python](https://realpython.com/python-mock-library/)
+    -   Mocking in Java: [Mockito Tutorial](https://www.vogella.com/tutorials/Mockito/article.html)
+    -   Mocking in JavaScript: [A guide to module mocking with Jest](https://www.emgoto.com/mocking-with-jest/)
+
+#### Integration Testing
+
+Integration testing, in contrast to unit testing, is meant to verify that your code works with other components/modules/services. We want to test that overall the entire system works as expected. They often execute after setting a production-like environment, and integration test frameworks can differ between projects, but while there aren't really any ubiquitous integration testing specific frameworks, services like CircleCI can help automate the process, and [Selenium](https://www.selenium.dev/) is a popular tool for testing web applications. Some resources for the most important parts of integration testing approaches are:
+
+-  **General**:
+   -  Guru99: [Integration Testing Tutorial](https://www.guru99.com/integration-testing.html)
+   -  Educative: [What are the different approaches to integration testing?](https://www.educative.io/edpresso/what-are-the-different-approaches-to-integration-testing)
+-   **Big Bang Approach**:
+    -   Educative: [What is big bang testing?](https://www.educative.io/edpresso/what-is-big-bang-testing)
+-   **Incremental Approach**:
+    -   Educative: [What is incremental testing?](https://www.educative.io/edpresso/what-is-incremental-testing)
+-   **Sandwich/Hybrid Approach**:
+    -   Educative: [What is the hybrid testing approach?](https://www.educative.io/answers/what-is-hybrid-integration-testing)

Topics/Development_Process/Build_Requirements/Requirements_txt.md

@@ -0,0 +1,47 @@
+# **Requirements.txt**
+
+## **Introduction**
+
+
+`requirements.txt` is a crucial file in Python projects for managing dependencies. It lists all the packages required to run your project, including their specific versions. This file ensures consistency and simplifies the setup process for other developers working on the project.
+
+
+## **How to use?**
+
+### **Creating a requirements.txt file**
+
+To create and update a `requirements.txt` file, use the following command in your terminal:
+
+```bash
+pip freeze > requirements.txt
+```
+
+This command generates a list of all installed packages and their versions in your virtual environment and saves them to a `requirements.txt` file.
+
+
+### **Installing dependencies from a requirements.txt file**
+
+To install the dependencies listed in a `requirements.txt` file, use the following command in your terminal:
+
+```bash
+pip install -r requirements.txt
+```
+
+This command reads the packages and their versions from the **`requirements.txt`** file and installs them in your virtual environment.
+
+**Resources:**
+- [How to Create and Maintain a requirements.txt](https://learnpython.com/blog/python-requirements-file/)
+
+
+
+## **Best Practices**
+
+1. **Use a virtual environment:** Always work within a virtual environment to isolate your project's dependencies from your system's global Python environment.
+
+    [Guide to Python Virtual Environments](https://www.dataquest.io/blog/a-complete-guide-to-python-virtual-environments/)
+
+1. **Keep the file up-to-date:** Regularly update the `requirements.txt` file as you add, remove, or update dependencies.
+2. **List only necessary dependencies:** Only list the Python modules and packages your project needs. Do not include unnecessary modules or packages, as this makes the txt file bloated and difficult to read. It is also a waste of resources.
+
+**More Best Practices:**
+- [10 Python Requirements.txt Best Practices](https://climbtheladder.com/10-python-requirements-txt-best-practices/)