Merge branch 'main' into Vector

Topics/Development_Process/LSP.md

@@ -18,7 +18,7 @@ We could try extracting out the logic of setting the width and height simultaneo
 
 
 
-## 2. The Principles in The LSP
+## 3. The Principles in The LSP
 The subtype requirement is an incredibly powerful tool for reasoning about our programs, but how does the LSP help us guide our programming to satsify it? The LSP imposes requirements[^1] on method signatures common across many typed languages:
 
  1. **Contravariance of parameter types in the subtype** – if parameters **P** are permissible in method ***f*** of a type, then **P** is also be permissible in ***f*** of any subtype. Equivalently:
@@ -38,11 +38,12 @@ but also imposes additional behavioural requirements[^1]:
 
 Requirements 1 to 6 are straightforward, so we won't discuss them. But the reader should convince themself that they are important, and necessary to satisfy the subtype requirement. We'll discuss requirement 7 as it's the novel requirment introduced in the LSP, and has important implications on how subtyping/inheritance should be used. The Wikipedia article illustrates a nice example of a violation of the History Constraint in the case of subtyping between mutable and immutable objects, but we'll illustrate a scenario that is simpler and probably more relatable.
 
-If you've learnt about OOP, you may have been told that the use of mutable public instance variables in a class is generally not a good idea, and that you should instead create getter and setter methods for it. Whether or not you agree with this practice, using mutable public instance variables is problematic in the context of the LSP and using subtyping/inheritance: not only is it possible to freely mutate the state of the object, hence violating the History Constraint, but you may also break invariants which are assumed by the implementation of the methods in the supertype, causing catastrophic failure of your program! On the contrary, if all your mutable instance variables are private (meaning state can only be modified through exposed methods of the supertype), then its *impossible* for the History Constraint to be violated. Note that this does not mean that one *must* declare all their instance variables this way to satisfy the History Constraint, it's just that its a very simple and easy way to ensure that they do. Of course, one could be incredibly disciplined and meticulous in their programming, but at that point they may as well avoid subtyping/inheritance as they'll shoulder all the associated complexity and gain little to none of the benefits.
 
-A side note: the satisfaction of the subtype requirement is undecidable, meaning no computer program, hence no compiler or linter or any static analysis tool, can figure out whether or not its violated in general.
+If you've learnt about OOP, you may have been told that the use of mutable public instance variables in a class is generally not a good idea, and that you should instead create getter and setter methods for it. Whether or not you agree with this practice, using mutable public instance variables is problematic in the context of the LSP and using subtyping/inheritance: not only is it possible to freely mutate the state of the object, hence violating the History Constraint, but you may also break invariants which are assumed by the implementation of the methods in the supertype, causing catastrophic failure of your program! On the contrary, if all your mutable instance variables are private (meaning state can only be modified through exposed methods of the supertype), then it's *impossible* for the History Constraint to be violated. Note that this does not mean that one *must* declare all their instance variables this way to satisfy the History Constraint, it's just that it's a very simple and easy way to ensure that they do. Of course, one could be incredibly disciplined and meticulous in their programming, but at that point they may as well avoid subtyping/inheritance as they'll shoulder all the associated complexity and gain little to none of the benefits.
 
-## 3. Conclusion
+A side note: the satisfaction of the subtype requirement is undecidable, meaning no computer program, hence no compiler or linter or any static analysis tool, can figure out whether or not it's violated in general.
+
+## 4. Conclusion
 We discussed the notion of subtyping proposed by the LSP and its utility for reasoning about our programs. We looked at an example of how the subtype requirment can be violated in a simple use of class inheritance. We discussed the actual principles/requirements imposed by the LSP to guide our programming to satisfy the subtyping requirement. And finally, we looked at an example of how the novel History Constraint introduced by the LSP impacts how we do object-oriented programming. Hopefully this writeup gave a little bit more insight into the implications of the LSP and motivated its ideas for some readers. Of course, there's much more to learn about the LSP than what we've discussed here. The Wikipedia article and the original paper[^2] by Liskov and Wing are good places to go next.
 
 

Topics/Tech_Stacks/Postman/Postman_Environment_Variables.md

@@ -0,0 +1,84 @@
+# Postman Environment - Group sets of your variables
+## What is Environment
+ * Environment is a set of one or more variables that you can reference when sending requests or writing test scripts. You can create environments for the different types of work you do in Postman. When you switch between environments, all of the variables in your requests and scripts will use the values from the current environment. This is helpful if you need to use different values in your requests depending on the context, for example, if you're sending a request to a test server or a production server.
+
+ ## Why do we use Environment
+ * Isolate configurations for different development stages
+ * Data reusability & Test efficiency
+ * Reducing errors when testing different variables
+
+ ## How to create an Environment
+ 1. Select Environments in the sidebar (on the left) and select +.
+    ![](./assets/environment-create-new.jpg)
+
+ 2. Enter a name for your new environment.
+
+    ![](./assets/environment-naming.png)
+
+ 3. Add any variables you want to the environment. You can also add variables later.
+
+    ![](./assets/environment-create-variables.png)
+
+ 4. [Important] Save environment variables you added. 
+
+     ![](./assets/environment-save.png)
+
+ 5. To use the new environment, select it from the environment selector at the top right of the workbench. This makes it the active environment and sets all variables to the values specified in the environment.
+
+    ![](./assets/environment-selector.jpg)
+
+### More about adding variables
+When you add a variable to an environment, you can specify the Initial value (shared) and the Current value (local) for the variable:
+* Initial value (shared) - This value is synced to your account using Postman's cloud servers. It's shared with any collaborators who have access to the environment. It's also made public when publishing an environment along with a collection. If the value includes sensitive data, such as a password or key, you can mask the value by selecting the secret variable type.
+
+    ![](./assets/environment-initial-value.png)
+
+* Current value (local) - This value is used when sending requests in your local instance of Postman. It's never synced to your account or shared with your team unless you choose to persist it.
+
+    ![](./assets/environment-current-value.png)
+
+* Don't forget to save!
+
+### Global variables
+Global variables are a type of variable, accessible across all environments within Postman. This means that no matter which environment you switch to, global variables remain available.
+
+![](./assets/environment-globals.png)
+
+## Switch between environments
+* Postman displays the active environment in the environment selector, located in the top right of the workbench. When you send a request or run a script, Postman uses the current values for all variables in the active environment. To make another environment active, select it from the environment selector.
+
+    ![](./assets/environment-selector.jpg)
+
+* You can also make an environment active by selecting Environments in the sidebar. Select the set active icon to an environment to make it the active environment.
+
+    ![](./assets/environment-make-active.jpg)
+* To check a variable's value at a glance, select the environment quick look icon Environment quick look icon next to the environment selector. The environment quick look lists the initial and current values for all variables in the active environment.
+
+    ![](./assets/environment-quick-look.jpg)
+
+## Use variables in requests and scripts
+* To use an environment variable in a request, reference it by name surrounded with double curly braces:
+    ```javascript
+    {{base_url}}
+    ```
+* You can reference environment variables in request URLs, parameters, headers, and body data. Hover over a variable reference to view its current value.
+
+    ![](./assets/environment-hover.jpg)
+
+* You can access current environment variable values in your Pre-request Script and Tests code using the pm.environment.get method:
+    ```javascript
+    pm.environment.get("variable_name");
+    ```
+
+## Useful tips:
+1. You can duplicate an existing Environment by
+
+    ![](./assets/environment-duplicate.png)
+
+2. Just like a GitHub repository, you can fork, pull, create pull request, merge Postman Environments.
+
+    ![](./assets/environment-features.png)
+
+
+## References
+[1]. https://learning.postman.com/docs/sending-requests/variables/managing-environments/