diff --git a/Programming_Languages/Frameworks/React/Application_structure.md b/Programming_Languages/Frameworks/React/Application_structure.md index 98b5c50..2dae2bf 100644 --- a/Programming_Languages/Frameworks/React/Application_structure.md +++ b/Programming_Languages/Frameworks/React/Application_structure.md @@ -1,6 +1,7 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - javascript - react --- diff --git a/Programming_Languages/Frameworks/React/Classes/Components_props_classes.md b/Programming_Languages/Frameworks/React/Classes/Components_props_classes.md index ccbe194..9163c7f 100644 --- a/Programming_Languages/Frameworks/React/Classes/Components_props_classes.md +++ b/Programming_Languages/Frameworks/React/Classes/Components_props_classes.md @@ -1,6 +1,7 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - javascript - react - react-classes diff --git a/Programming_Languages/Frameworks/React/Classes/Forms.md b/Programming_Languages/Frameworks/React/Classes/Forms.md index 5b15a4b..3c8ff97 100644 --- a/Programming_Languages/Frameworks/React/Classes/Forms.md +++ b/Programming_Languages/Frameworks/React/Classes/Forms.md @@ -1,6 +1,7 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - javascript - react - react-classes diff --git a/Programming_Languages/Frameworks/React/Classes/Lifecycle_methods.md b/Programming_Languages/Frameworks/React/Classes/Lifecycle_methods.md index 85bcfae..4df47b5 100644 --- a/Programming_Languages/Frameworks/React/Classes/Lifecycle_methods.md +++ b/Programming_Languages/Frameworks/React/Classes/Lifecycle_methods.md @@ -1,6 +1,7 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - javascript - react --- diff --git a/Programming_Languages/Frameworks/React/Comparing_classes_to_hooks.md b/Programming_Languages/Frameworks/React/Comparing_classes_to_hooks.md index 2b0c80d..74e741a 100644 --- a/Programming_Languages/Frameworks/React/Comparing_classes_to_hooks.md +++ b/Programming_Languages/Frameworks/React/Comparing_classes_to_hooks.md @@ -1,6 +1,7 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - javascript - react - react-classes diff --git a/Programming_Languages/Frameworks/React/Controlled_components.md b/Programming_Languages/Frameworks/React/Controlled_components.md index 90fda34..2916602 100644 --- a/Programming_Languages/Frameworks/React/Controlled_components.md +++ b/Programming_Languages/Frameworks/React/Controlled_components.md @@ -1,6 +1,7 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - javascript - react --- diff --git a/Programming_Languages/Frameworks/React/Errors.md b/Programming_Languages/Frameworks/React/Errors.md index f875e69..f73bfd4 100644 --- a/Programming_Languages/Frameworks/React/Errors.md +++ b/Programming_Languages/Frameworks/React/Errors.md @@ -1,6 +1,7 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - javascript - react - react-hooks diff --git a/Programming_Languages/Frameworks/React/Hooks/Application_state_management.md b/Programming_Languages/Frameworks/React/Hooks/Application_state_management.md index d9f8ef6..8fd3733 100644 --- a/Programming_Languages/Frameworks/React/Hooks/Application_state_management.md +++ b/Programming_Languages/Frameworks/React/Hooks/Application_state_management.md @@ -1,6 +1,7 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - javascript - react - react-hooks diff --git a/Programming_Languages/Frameworks/React/Hooks/Components_props_hooks.md b/Programming_Languages/Frameworks/React/Hooks/Components_props_hooks.md index 0e6b77d..fab8c7c 100644 --- a/Programming_Languages/Frameworks/React/Hooks/Components_props_hooks.md +++ b/Programming_Languages/Frameworks/React/Hooks/Components_props_hooks.md @@ -1,6 +1,7 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - javascript - react - react-hooks diff --git a/Programming_Languages/Frameworks/React/Hooks/Forms.md b/Programming_Languages/Frameworks/React/Hooks/Forms.md index 823a4de..15d6a1b 100644 --- a/Programming_Languages/Frameworks/React/Hooks/Forms.md +++ b/Programming_Languages/Frameworks/React/Hooks/Forms.md @@ -1,6 +1,7 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - javascript - react - react-hooks diff --git a/Programming_Languages/Frameworks/React/Hooks/Iterating.md b/Programming_Languages/Frameworks/React/Hooks/Iterating.md index c6e04cc..93c4e6d 100644 --- a/Programming_Languages/Frameworks/React/Hooks/Iterating.md +++ b/Programming_Languages/Frameworks/React/Hooks/Iterating.md @@ -1,6 +1,7 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - javascript - react - react-hooks diff --git a/Programming_Languages/Frameworks/React/Hooks/Memoization.md b/Programming_Languages/Frameworks/React/Hooks/Memoization.md index c677664..5010298 100644 --- a/Programming_Languages/Frameworks/React/Hooks/Memoization.md +++ b/Programming_Languages/Frameworks/React/Hooks/Memoization.md @@ -1,6 +1,7 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - javascript - react - react-hooks diff --git a/Programming_Languages/Frameworks/React/Hooks/useContext.md b/Programming_Languages/Frameworks/React/Hooks/useContext.md index a952216..90d4273 100644 --- a/Programming_Languages/Frameworks/React/Hooks/useContext.md +++ b/Programming_Languages/Frameworks/React/Hooks/useContext.md @@ -1,6 +1,7 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - javascript - react - react-hooks diff --git a/Programming_Languages/Frameworks/React/Hooks/useEffect.md b/Programming_Languages/Frameworks/React/Hooks/useEffect.md index c93b489..5d553e4 100644 --- a/Programming_Languages/Frameworks/React/Hooks/useEffect.md +++ b/Programming_Languages/Frameworks/React/Hooks/useEffect.md @@ -1,6 +1,7 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - javascript - react - react-hooks diff --git a/Programming_Languages/Frameworks/React/Hooks/useReducer.md b/Programming_Languages/Frameworks/React/Hooks/useReducer.md index 7dfb790..f98d489 100644 --- a/Programming_Languages/Frameworks/React/Hooks/useReducer.md +++ b/Programming_Languages/Frameworks/React/Hooks/useReducer.md @@ -1,6 +1,7 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - javascript - react - react-hooks diff --git a/Programming_Languages/Frameworks/React/Hooks/useState.md b/Programming_Languages/Frameworks/React/Hooks/useState.md index 4808162..dfcc95a 100644 --- a/Programming_Languages/Frameworks/React/Hooks/useState.md +++ b/Programming_Languages/Frameworks/React/Hooks/useState.md @@ -1,6 +1,7 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - javascript - react - react-hooks diff --git a/Programming_Languages/Frameworks/React/Prop_types.md b/Programming_Languages/Frameworks/React/Prop_types.md index 82d99e0..2b743df 100644 --- a/Programming_Languages/Frameworks/React/Prop_types.md +++ b/Programming_Languages/Frameworks/React/Prop_types.md @@ -1,6 +1,7 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - javascript - react - data-types diff --git a/Programming_Languages/Frameworks/React/React_Typescript/Built_in_hooks.md b/Programming_Languages/Frameworks/React/React_Typescript/Built_in_hooks.md index c7ae4f2..cab622a 100644 --- a/Programming_Languages/Frameworks/React/React_Typescript/Built_in_hooks.md +++ b/Programming_Languages/Frameworks/React/React_Typescript/Built_in_hooks.md @@ -1,6 +1,7 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - typescript - react - react-hooks diff --git a/Programming_Languages/Frameworks/React/React_Typescript/Components.md b/Programming_Languages/Frameworks/React/React_Typescript/Components.md index 80ae6a4..3a0177e 100644 --- a/Programming_Languages/Frameworks/React/React_Typescript/Components.md +++ b/Programming_Languages/Frameworks/React/React_Typescript/Components.md @@ -1,6 +1,7 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - typescript - react --- diff --git a/Programming_Languages/Frameworks/React/React_Typescript/Events.md b/Programming_Languages/Frameworks/React/React_Typescript/Events.md index 4ab2fb7..3d2c2ea 100644 --- a/Programming_Languages/Frameworks/React/React_Typescript/Events.md +++ b/Programming_Languages/Frameworks/React/React_Typescript/Events.md @@ -1,6 +1,7 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - typescript - react --- diff --git a/Programming_Languages/Frameworks/React/React_Typescript/Functions.md b/Programming_Languages/Frameworks/React/React_Typescript/Functions.md index 8afc319..76e14ff 100644 --- a/Programming_Languages/Frameworks/React/React_Typescript/Functions.md +++ b/Programming_Languages/Frameworks/React/React_Typescript/Functions.md @@ -1,6 +1,7 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - typescript - react --- diff --git a/Programming_Languages/Frameworks/React/React_Typescript/Props.md b/Programming_Languages/Frameworks/React/React_Typescript/Props.md index 223abc1..60da096 100644 --- a/Programming_Languages/Frameworks/React/React_Typescript/Props.md +++ b/Programming_Languages/Frameworks/React/React_Typescript/Props.md @@ -1,6 +1,7 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - typescript - react --- diff --git a/Programming_Languages/Frameworks/React/React_Typescript/Resources.md b/Programming_Languages/Frameworks/React/React_Typescript/Resources.md deleted file mode 100644 index 4b5df71..0000000 --- a/Programming_Languages/Frameworks/React/React_Typescript/Resources.md +++ /dev/null @@ -1,5 +0,0 @@ -# React TypeScript Learning Resources - -https://www.toptal.com/react/react-hooks-typescript-example - -https://react-typescript-cheatsheet.netlify.app/ diff --git a/Programming_Languages/NodeJS/Architecture/Event_loop.md b/Programming_Languages/NodeJS/Architecture/Event_loop.md index 9c93575..89d3466 100644 --- a/Programming_Languages/NodeJS/Architecture/Event_loop.md +++ b/Programming_Languages/NodeJS/Architecture/Event_loop.md @@ -1,6 +1,7 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - backend - node-js - async @@ -11,72 +12,69 @@ tags: Node.js provides a single-threaded asynchronous architecture which is achieved via means of the Event Loop. ## Multi-threaded synchronous architectures -In the context of backend, a thread as an instance of a request-response transaction. -For example a request is made from the client for a resource contained in a database. The back-end language is an intermediary between the client machine and the server. It receives the request and returns the resource as a response. +In the context of backend, a thread as an instance of a request-response transaction. -Many backend frameworks are synchronous but multithreaded. This means that a thread can only process one request-response cycle at a time. The thread cannot initiate a new cycle until it has finished with its current cycle. +For example a request is made from the client for a resource contained in a database. The back-end language is an intermediary between the client machine and the server. It receives the request and returns the resource as a response. -If there was only one thread, this would be inefficient and unworkable. Therefore the framework will be multi-threaded: multiple request-response cycles can be executed at once by different threads. +Many backend frameworks are synchronous but multithreaded. This means that a thread can only process one request-response cycle at a time. The thread cannot initiate a new cycle until it has finished with its current cycle. +If there was only one thread, this would be inefficient and unworkable. Therefore the framework will be multi-threaded: multiple request-response cycles can be executed at once by different threads.  To accomodate the ability to increase the scale of synchronous applications you need to be able to spawn more threads commensurate to increased demand. This increases the resource consumption of the framework (more cores, more memory etc). Moreover it is possible to reach a point where all threads are active and no more can be spawned. In this case there will simply be delays in the return of data. -## Node as a single-threaded asynchronous architecture - -In contrast, Node only has a single thread but it works asynchronously, not synchronously. Thus it has a **single-threaded asynchronous architecture**. This means whilst there is only a single thread it can juggle responses by dispatching them asynchronously. When a request is made it sends it off and continues with its execution and handling new requests. Once these resolve, the data is returned to the main thread. +## Node as a single-threaded asynchronous architecture +In contrast, Node only has a single thread but it works asynchronously, not synchronously. Thus it has a **single-threaded asynchronous architecture**. This means whilst there is only a single thread it can juggle responses by dispatching them asynchronously. When a request is made it sends it off and continues with its execution and handling new requests. Once these resolve, the data is returned to the main thread.  ## The Event Loop -Node implements its single-threaded asynchronous architecture through the Event Loop. +Node implements its single-threaded asynchronous architecture through the Event Loop. -This is the mechanism by which Node keeps track of incoming requests and their fulfillment status: whether the data has been returned successfully or if there has been error. +This is the mechanism by which Node keeps track of incoming requests and their fulfillment status: whether the data has been returned successfully or if there has been error. Node is continually monitoring the Event Loop in the background. -A running Node application is a single running process. Like everything that happens within the OS, a process is managed by the [kernel](/Operating_Systems/The_Kernel.md) that dispatches operations to the CPU in a clock cycle. A thread is a sequence of code that resides within the process and utilises its memory pool (the amount of memory assigned by the kernel to the Node process). The Event Loop runs on CPU ticks: a tick is a single run of the Event Loop. +A running Node application is a single running process. Like everything that happens within the OS, a process is managed by the [kernel](/Operating_Systems/The_Kernel.md) that dispatches operations to the CPU in a clock cycle. A thread is a sequence of code that resides within the process and utilises its memory pool (the amount of memory assigned by the kernel to the Node process). The Event Loop runs on CPU ticks: a tick is a single run of the Event Loop. ### Phases of the Event Loop The Event Loop comprises six phases. The Event Loop starts at the moment Node begins to execute your `index.js` file or any other application entry point. These six phases create one cycle, or loop, equal to one **tick**. A Node.js process exits when there is no more pending work in the Event Loop, or when `process.exit()` is called manually. A program only runs for as long as there are tasks queued in the Event Loop, or present on the [call stack](/Software_Engineering/Call_stack.md). -  The phases are as follows: 1. **Timers** - * These are functions that execute callbacks after a set period of time. As in standard JavaScript there are two global timer functions: `setTimeout` and `setInterval`. Interestingly these are not core parts of the JavaScript language, they are something that are made available to JS by the particular browser. As Node does not run in the browser, Node has to provide this functionality. It does so through the core `timers` module. - * At the beginning of this phase the Event Loop updates its own time. Then it checks a queue, or pool, of timers. This queue consists of all timers that are currently set. The Event Loop takes the timer with the shortest wait time and compares it with the Event Loop's current time. If the wait time has elapsed, then the timer's callback is queued to be called once the [call stack](/Software_Engineering/Call_stack.md) is empty. -2. **I/O Callbacks** - * Once timers have been checked and scheduled, Node jumps to I/O operations. - * Node implements a non-blocking input/output interface. This is to say, writing and reading to disk (files in the Node application directory) is implemented asynchronously. The asynchronous I/O request is recorded into the queue and then the call stack continues. + - These are functions that execute callbacks after a set period of time. As in standard JavaScript there are two global timer functions: `setTimeout` and `setInterval`. Interestingly these are not core parts of the JavaScript language, they are something that are made available to JS by the particular browser. As Node does not run in the browser, Node has to provide this functionality. It does so through the core `timers` module. + - At the beginning of this phase the Event Loop updates its own time. Then it checks a queue, or pool, of timers. This queue consists of all timers that are currently set. The Event Loop takes the timer with the shortest wait time and compares it with the Event Loop's current time. If the wait time has elapsed, then the timer's callback is queued to be called once the [call stack](/Software_Engineering/Call_stack.md) is empty. +2. **I/O Callbacks** + - Once timers have been checked and scheduled, Node jumps to I/O operations. + - Node implements a non-blocking input/output interface. This is to say, writing and reading to disk (files in the Node application directory) is implemented asynchronously. The asynchronous I/O request is recorded into the queue and then the call stack continues. 3. **Idle / waiting / preparation** - * This phase is internal to Node and is not accessible to the programmer. - * It is primarily used for gathering informtion, and planning what needs to be executed during the next tick of the Event Loop -4. **I/O polling** - * This is the phase at which the main block of code is read and executed by Node. - * During this phase the Event Loop is managing the I/O workload, calling the functions in the queue until the queue is empty, and calculating how long it should wait until moving to the next phase. All callbacks in this phase are called synchronously (although they return asynchronously) in the order that they were added to the queue, from oldest to newest. - * This is the phase that can potentially block our application if any of these callbacks are slow or do not return asynchronously. + - This phase is internal to Node and is not accessible to the programmer. + - It is primarily used for gathering informtion, and planning what needs to be executed during the next tick of the Event Loop +4. **I/O polling** + - This is the phase at which the main block of code is read and executed by Node. + - During this phase the Event Loop is managing the I/O workload, calling the functions in the queue until the queue is empty, and calculating how long it should wait until moving to the next phase. All callbacks in this phase are called synchronously (although they return asynchronously) in the order that they were added to the queue, from oldest to newest. + - This is the phase that can potentially block our application if any of these callbacks are slow or do not return asynchronously. 5. **`setImmediate` callbacks** - * This phase runs as soon as the poll phase becomes idle. If `setImmediate()` is scheduled within the I/O cycle it will always be executed before other timers regardless of how many timers are present. - * This is your opportunity to grant precedence to certain threads within the Node process + - This phase runs as soon as the poll phase becomes idle. If `setImmediate()` is scheduled within the I/O cycle it will always be executed before other timers regardless of how many timers are present. + - This is your opportunity to grant precedence to certain threads within the Node process 6. **Close events** - * This phase occurs when the Event Loop is wrapping up one cycle and is ready to move to the next one. - * It is an opportunity for clean-up and to guard against memory leaks. - * This phase can be targetted via the `process.exit()` function or the close event of a web-socket. - + - This phase occurs when the Event Loop is wrapping up one cycle and is ready to move to the next one. + - It is an opportunity for clean-up and to guard against memory leaks. + - This phase can be targetted via the `process.exit()` function or the close event of a web-socket. ## Event _loop_ and event _queue_ -The terms _event loop_ and _event queue_ are often used interchangeably in the literature but in fact they are distinct. +The terms _event loop_ and _event queue_ are often used interchangeably in the literature but in fact they are distinct. -The Event Loop is the Node runtime's method of execution, the queue is the stack of tasks that are lined up and executed by the loop. We can think of the queue as being the input and the loop as what acts on the input. The queue obviously emerges from the program we write but it is scheduled, organised and sequenced by the loop. +The Event Loop is the Node runtime's method of execution, the queue is the stack of tasks that are lined up and executed by the loop. We can think of the queue as being the input and the loop as what acts on the input. The queue obviously emerges from the program we write but it is scheduled, organised and sequenced by the loop. https://blog.appsignal.com/2022/07/20/an-introduction-to-multithreading-in-nodejs.html https://school.geekwall.in/p/Bk2xFs1DV diff --git a/Programming_Languages/NodeJS/Architecture/Global_object.md b/Programming_Languages/NodeJS/Architecture/Global_object.md index add9c10..d496fbd 100644 --- a/Programming_Languages/NodeJS/Architecture/Global_object.md +++ b/Programming_Languages/NodeJS/Architecture/Global_object.md @@ -1,18 +1,19 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - backend - node-js --- # Global object - > In Node every function and variable should be scoped to a module. We should not define functions and variables within the global scope. +> In Node every function and variable should be scoped to a module. We should not define functions and variables within the global scope. -* In Node the equivalent to the browser's `Window` object is `global`. The properties and methods that belong to this method are available anywhere in a program. +- In Node the equivalent to the browser's `Window` object is `global`. The properties and methods that belong to this method are available anywhere in a program. -* Just as we can technically write `Window.console.log()`, we can write `global.console.log()` however in both cases it is more sane to use the shorthand. +- Just as we can technically write `Window.console.log()`, we can write `global.console.log()` however in both cases it is more sane to use the shorthand. -* However if we declare a variable in this scope in browser-based JavaScript, this variable becomes accessible via the `Window` object and thus is accessible in global scope. The same is not true for Node. If you declare a variable at this level it will return undefined. +- However if we declare a variable in this scope in browser-based JavaScript, this variable becomes accessible via the `Window` object and thus is accessible in global scope. The same is not true for Node. If you declare a variable at this level it will return undefined. -* This is because of Node's modular nature. If you were to define a function `foo` in a module and then also define it in the global scope, when you call `foo`, the Node interpreter would not know which function to call. Hence it chooses not to recognise the global `foo`, returning undefined. +- This is because of Node's modular nature. If you were to define a function `foo` in a module and then also define it in the global scope, when you call `foo`, the Node interpreter would not know which function to call. Hence it chooses not to recognise the global `foo`, returning undefined. diff --git a/Programming_Languages/NodeJS/Architecture/Managing_environments.md b/Programming_Languages/NodeJS/Architecture/Managing_environments.md index 532d2d8..6857620 100644 --- a/Programming_Languages/NodeJS/Architecture/Managing_environments.md +++ b/Programming_Languages/NodeJS/Architecture/Managing_environments.md @@ -1,25 +1,29 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - backend - node-js --- -# Managing environments +# Managing environments With a full-scale Node application you will typically run three environments: -* Development -* Testing -* Production + +- Development +- Testing +- Production ## Accessing the current environment -To determine the current environment we can use the variable **`process.env.NODE_ENV`**. This works globally regardless of the kind of Node app we are building. +To determine the current environment we can use the variable **`process.env.NODE_ENV`**. This works globally regardless of the kind of Node app we are building. If you have not manually set up your environments, **`process.env.NODE_ENV`** will return `undefined`. ### Setting the Node environment + #### For the session + `NODE_ENV` is a bash [environment variable](/Programming_Languages/Shell_Scripting/Environmental_and_shell_variables.md) like any other. So we can set it in the normal way: ```bash @@ -27,13 +31,14 @@ export NODE_ENV=production ``` ### In Express -In Express, there is a built in method for retrieving the current envrionment: `app.get('env')`. Express will default to the development environment. + +In Express, there is a built in method for retrieving the current envrionment: `app.get('env')`. Express will default to the development environment.
! How to keep Express and Node environment in sync?
-## Configuring environments +## Configuring environments -We use the third-party [Config](https://github.com/node-config/node-config) package to manage different configurations based on the environment. +We use the third-party [Config](https://github.com/node-config/node-config) package to manage different configurations based on the environment. Once installed we set up a dedicated config directory with a structure as follows: @@ -44,32 +49,34 @@ config/ production.json ``` -For example: +For example: ```json -// default.json +// default.json { - "name": "My Express app" + "name": "My Express app" } ``` + Then to utilise config variables: ```js -const config = require('config') -console.log('Application name:' + config.get('name')) +const config = require('config'); +console.log('Application name:' + config.get('name')); ``` If we toggled the different environments, we would see different outputs from the above code (assuming we had different config files in `/config` with different names). ### Sensitive config data -We will need to store passwords, API keys and other kinds of authentication data for our application. We obviously shouldn't store this data openly in our config files since it would be made public. +We will need to store passwords, API keys and other kinds of authentication data for our application. We obviously shouldn't store this data openly in our config files since it would be made public. We can do so securely by utilising [environmental variables](../Shell_Scripting/Environmental_and_shell_variables.md) alongside the config pacakage. We create a file called `custom-environment-variables` (must be called this) and map a property to an environmental environment we have already set. Let's create an environmental variable for a password: + ```bash export APP_PASSWORD='mypassword123' ``` @@ -78,17 +85,16 @@ Then in our custom variable file: ```json { - "password": "APP_PASSWORD" + "password": "APP_PASSWORD" } - ``` We can then safely reference this value in the course of our normal code: + ```js -console.log(config.get('password')) +console.log(config.get('password')); ```! But how would this be achieved in a production server?
- -! And how could we do this programmatically at the start of a local development session without manually setting each environment variable in the terminal?
\ No newline at end of file +! And how could we do this programmatically at the start of a local development session without manually setting each environment variable in the terminal?
diff --git a/Programming_Languages/NodeJS/Architecture/Middleware.md b/Programming_Languages/NodeJS/Architecture/Middleware.md index c030805..3343e37 100644 --- a/Programming_Languages/NodeJS/Architecture/Middleware.md +++ b/Programming_Languages/NodeJS/Architecture/Middleware.md @@ -1,70 +1,72 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - backend - node-js - middleware --- -# Middleware +# Middleware + ## What is middleware? -* Anything that terminates the `req, res` cycle counts as middleware. It is basically anything that acts as an intermediary once the request is received but before the resource is sent. A good example would be the `app.use(express.json()` or `app.use(bodyParser.json)` functions we call in order to be able to parse JSON that is sent from the client. -* You will most likely have multiple middleware functions running at once. We call this intermediary part of the cycle the **request processing pipeline**. -* Generally all middleware will be added as a property on the Express `app` instance with the `app.use(...)` syntax. +- Anything that terminates the `req, res` cycle counts as middleware. It is basically anything that acts as an intermediary once the request is received but before the resource is sent. A good example would be the `app.use(express.json()` or `app.use(bodyParser.json)` functions we call in order to be able to parse JSON that is sent from the client. +- You will most likely have multiple middleware functions running at once. We call this intermediary part of the cycle the **request processing pipeline**. +- Generally all middleware will be added as a property on the Express `app` instance with the `app.use(...)` syntax. ## Creating custom middleware functions ### Basic schema -````js - +```js app.use((req, res, next) => { - // do some middleware - next() -}) - -```` + // do some middleware + next(); +}); +``` ### `next` The `next` parameter is key, it allows Express to move onto the next middleware function once the custom middleware executes. Without it, the request processing pipeline will get blocked. -Middleware functions are basically asynchronous requests and as such they use a similar syntax as Promises (e.g `then`) for sequencing processes. +Middleware functions are basically asynchronous requests and as such they use a similar syntax as Promises (e.g `then`) for sequencing processes. ### Example of sequence ```js app.use((req, res, next) => { - console.log('Do process A...') - next() -}) + console.log('Do process A...'); + next(); +}); app.use((req, res, next) => { - console.log('Do process B...') - next() -}) - + console.log('Do process B...'); + next(); +}); ``` > It makes more sense of course to define our middleware within a function and then pass it as an argument to `app.use()` -## Including middleware based on environment +## Including middleware based on environment + With a full-scale Node application you will typically run three environments: -* Development -* Testing -* Production + +- Development +- Testing +- Production We will not want to run certain types of middleware in all environments. For example, it would be costly to run logging in the app's production environment. It would make more sense to run this only in development. ### Accessing current Node environment - We can control which middleware we run via the Node envrionment variables: `process.env` (see for instance [ports](./Ports.md)). + +We can control which middleware we run via the Node envrionment variables: `process.env` (see for instance [ports](./Ports.md)). We could set [Morgan](/Programming_Languages/NodeJS/Modules/Third_party/Morgan.md) to run only in development with: ```js -if (app.get("env") === 'development') { - app.use(morgan("common")); - console.log('Morgan enabled') +if (app.get('env') === 'development') { + app.use(morgan('common')); + console.log('Morgan enabled'); } ``` diff --git a/Programming_Languages/NodeJS/Architecture/Module_wrapping_at_runtime.md b/Programming_Languages/NodeJS/Architecture/Module_wrapping_at_runtime.md index 87bbae8..c3d3432 100644 --- a/Programming_Languages/NodeJS/Architecture/Module_wrapping_at_runtime.md +++ b/Programming_Languages/NodeJS/Architecture/Module_wrapping_at_runtime.md @@ -1,6 +1,7 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - backend - node-js - node-modules @@ -10,10 +11,10 @@ tags: When Node runs each of our module files are wrapped within an immediately-invoked function expression that has the following parameters: -````js +```js (function (exports, require, module, __filename, __dirname)) -```` +``` This is called the **module wrapper function** diff --git a/Programming_Languages/NodeJS/Architecture/Ports.md b/Programming_Languages/NodeJS/Architecture/Ports.md index 542b498..c42cf87 100644 --- a/Programming_Languages/NodeJS/Architecture/Ports.md +++ b/Programming_Languages/NodeJS/Architecture/Ports.md @@ -1,6 +1,7 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - backend - node-js - node-modules @@ -8,12 +9,12 @@ tags: # Ports -When working in development we are able to specify the specific port from which we want top serve our application. In production, we do not always have this control: the port will most likely be set by the provider of the server environment. +When working in development we are able to specify the specific port from which we want top serve our application. In production, we do not always have this control: the port will most likely be set by the provider of the server environment. While we may not know the specific port, whatever it is, it will be accessible via the `PORT` environment variable. So we can use this when writing our [event listeners](Events%20module.md#event-emitters): -````js +```js const port = process.env.PORT || 3000; -```` +``` This way, if a port is set by the provider it will use it. If not, it will fall back to 3000. diff --git a/Programming_Languages/NodeJS/Miscellaneous/io_with_files.md b/Programming_Languages/NodeJS/Miscellaneous/io_with_files.md index 3563f08..3e229dc 100644 --- a/Programming_Languages/NodeJS/Miscellaneous/io_with_files.md +++ b/Programming_Languages/NodeJS/Miscellaneous/io_with_files.md @@ -1,49 +1,50 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - backend - node-js --- # I/O with files + ## Read file from directory (JSON) -````js -const fs = require("fs"); +```js +const fs = require('fs'); // Get raw JSON -let inputJson = fs.readFileSync("source.json"); +let inputJson = fs.readFileSync('source.json'); // Convert to JS let data = JSON.parse(inputJson); -```` +``` ## Write file to directory (JSON) -````js +```js let newFile = 'new.json'; -// Write JS object to JSON file as JSON +// Write JS object to JSON file as JSON fs.writeFileSync(writePath, JSON.stringify(alienblood)); - -```` +``` ## Delete file from directory -````js +```js let filePath = 'file-to-delete.json'; fs.unlinkSync(filePath); -```` +``` ## Applications ### Overwrite file -````js +```js if (fs.existsSync(writePath)) { - fs.unlinkSync(writePath); - fs.writeFileSync(writePath, JSON.stringify(someJS)); - } else { - fs.writeFileSync(writePath, JSON.stringif(someJS)); - } -```` + fs.unlinkSync(writePath); + fs.writeFileSync(writePath, JSON.stringify(someJS)); +} else { + fs.writeFileSync(writePath, JSON.stringif(someJS)); +} +``` diff --git a/Programming_Languages/NodeJS/Modules/Core/events.md b/Programming_Languages/NodeJS/Modules/Core/events.md index 607a27c..b4fb51d 100644 --- a/Programming_Languages/NodeJS/Modules/Core/events.md +++ b/Programming_Languages/NodeJS/Modules/Core/events.md @@ -1,83 +1,82 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - backend - node-js - node-modules --- -# `events` module + +# `events` module + In most cases you won't interact with the `events` module directly since other modules and third-party modules are abstractions on top of it. For instance the `http` module is using events under the hood to handle requests and responses. -Another way of putting this is to say that all events in Node inherit from the `EventEmitter` constructor, which is the class you instantiate to create a new event. At bottom everything in Node is an event with a callback, created via event emitters. +Another way of putting this is to say that all events in Node inherit from the `EventEmitter` constructor, which is the class you instantiate to create a new event. At bottom everything in Node is an event with a callback, created via event emitters. + +Because Node's runtime is [event-driven](/Programming_Languages/NodeJS/Architecture/Event_loop.md), it is event-emitter cycles that are being processed by the Event Loop, although you may know them as `fs` or `http` (etc) events. The call stack that the Event Loop works through is just a series of event emissions and their associated callbacks. -Because Node's runtime is [event-driven](/Programming_Languages/NodeJS/Architecture/Event_loop.md), it is event-emitter cycles that are being processed by the Event Loop, although you may know them as `fs` or `http` (etc) events. The call stack that the Event Loop works through is just a series of event emissions and their associated callbacks. ## Event Emitters -* All objects that emit events are instances of the `EventEmitter` class. This object exposes an `eventEmitter.on()` function that allows one or more functions to be attached to named events emitted by the object. -* These functions are **listeners** of the emitter. +- All objects that emit events are instances of the `EventEmitter` class. This object exposes an `eventEmitter.on()` function that allows one or more functions to be attached to named events emitted by the object. +- These functions are **listeners** of the emitter. ## Basic syntax -````js -const EventEmitter = require('events') // import the module +```js +const EventEmitter = require('events'); // import the module -// Raise an event -const emitter = new EventEmitter('messageLogged') +// Raise an event +const emitter = new EventEmitter('messageLogged'); // Register a listener -emitter.on('messagedLogged', function() { - console.log('The listener was called.') -}) +emitter.on('messagedLogged', function () { + console.log('The listener was called.'); +}); +``` -```` - -* If we ran this file, we would see `The listener was called` logged to the console. -* Without a listener (similar to a subscriber in Angular) nothing happens. -* When the emission occurs the emitter works *synchronously* through each listener function that is attached to it. +- If we ran this file, we would see `The listener was called` logged to the console. +- Without a listener (similar to a subscriber in Angular) nothing happens. +- When the emission occurs the emitter works _synchronously_ through each listener function that is attached to it. ## Event arguments -* Typically we would not just emit a string, we would attach an object to the emitter to pass more useful data. This data is called an **Event Argument**. -* Refactoring the previous example: +- Typically we would not just emit a string, we would attach an object to the emitter to pass more useful data. This data is called an **Event Argument**. +- Refactoring the previous example: -````js - -// Raise an event -const emitter = new EventEmitter('messageLogged', function(eventArg) { - console.log('Listener called', eventArg) -}) +```js +// Raise an event +const emitter = new EventEmitter('messageLogged', function (eventArg) { + console.log('Listener called', eventArg); +}); // Register a listener -emitter.on('messagedLogged', {id: 1, url: 'http://www.example.com'}) - -```` +emitter.on('messagedLogged', {id: 1, url: 'http://www.example.com'}); +``` ## Extending the `EventEmitter` class -* It's not best practice to call the EventEmitter class directly in `app.js`. If we want to use the capabilities of the class we should create our own module that extends `EventEmitter`, inheriting its functionality with specific additional features that we want to add. -* So, refactoring the previous example: +- It's not best practice to call the EventEmitter class directly in `app.js`. If we want to use the capabilities of the class we should create our own module that extends `EventEmitter`, inheriting its functionality with specific additional features that we want to add. +- So, refactoring the previous example: -````js +```js // File: Logger.js -const EventEmitter = require('events') +const EventEmitter = require('events'); class Logger extends EventEmitter { - log(message){ - console.log(message) - this.emit('messageLogged', {id: 1, url: 'http://www.example.com'}) - } + log(message) { + console.log(message); + this.emit('messageLogged', {id: 1, url: 'http://www.example.com'}); + } } +``` +_The `this` in the `log` method refers to the properties and methods of `EventEmitter` which we have extended._ -```` +- We also need to refactor our listener code within `app.js` so that it calls the extended class rather than the `EventEmitter` class directly: -*The `this` in the `log` method refers to the properties and methods of `EventEmitter` which we have extended.* - -* We also need to refactor our listener code within `app.js` so that it calls the extended class rather than the `EventEmitter` class directly: - -````js -// File app.js +```js +// File app.js const Logger = require('./Logger') const logger = new Logger() @@ -85,6 +84,6 @@ const logger = new Logger() logger.on('messageLogged', function(eventArg){ console.log('Listener called', eventArg) } - + logger.log('message') -```` +``` diff --git a/Programming_Languages/NodeJS/Modules/Core/fs.md b/Programming_Languages/NodeJS/Modules/Core/fs.md index fa846a8..879a141 100644 --- a/Programming_Languages/NodeJS/Modules/Core/fs.md +++ b/Programming_Languages/NodeJS/Modules/Core/fs.md @@ -1,6 +1,7 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - backend - node-js - node-modules @@ -10,7 +11,7 @@ tags: File System is an essential built-in module of Node that contains utility methods for working with files and directories. -Every method associated with `fs` has a *blocking* and *asynchronous* implementation. The former obviously blocks the [event queue](Event%20queue.md), the latter does not. +Every method associated with `fs` has a _blocking_ and _asynchronous_ implementation. The former obviously blocks the [event queue](Event%20queue.md), the latter does not. The synchronous methods are useful to have in some contexts but in general and with real-world applications, you should be using the async implementation so as to accord with the single-threaded event-driven architecture of Node. @@ -18,16 +19,14 @@ The synchronous methods are useful to have in some contexts but in general and w ### Read directory -Return a string array of all files in the current directory. +Return a string array of all files in the current directory. -````js - -fs.readdir('./', function(err, files) { - if (err) { - console.error(err) - } else { - console.log(files) - } - -}) -```` +```js +fs.readdir('./', function (err, files) { + if (err) { + console.error(err); + } else { + console.log(files); + } +}); +``` diff --git a/Programming_Languages/NodeJS/Modules/Core/http.md b/Programming_Languages/NodeJS/Modules/Core/http.md index 68f8d8f..e173283 100644 --- a/Programming_Languages/NodeJS/Modules/Core/http.md +++ b/Programming_Languages/NodeJS/Modules/Core/http.md @@ -1,4 +1,6 @@ --- +categories: + - Programming Languages tags: - Programming_Languages - backend @@ -8,42 +10,41 @@ tags: # `http` module -The HTTP Module allows us to create a web server that listens for HTTP requests on a given port. It is therefore perfect for creating backends for client-side JavaScript. +The HTTP Module allows us to create a web server that listens for HTTP requests on a given port. It is therefore perfect for creating backends for client-side JavaScript. ## Creating a server An HTTP server is another instance of an [event emitter](/Programming_Languages/NodeJS/Modules/Core/events.md)). It therefore has all the same methods as the `EventEmitter` class: `on`, `emit`, `addListener` etc. This demonstrates again how much of Node's core functionality is based on event emitters. -*Creating a server* -````js -const http = require('http') +_Creating a server_ -const server = http.createServer() // Create server as emitter +```js +const http = require('http'); -// Register functions to run when listener is triggered +const server = http.createServer(); // Create server as emitter + +// Register functions to run when listener is triggered server.on('connection', (socket) => { - console.log('new connection...') -}) + console.log('new connection...'); +}); -server.listen(3000) -console.log('Listening on port 3000') - -```` +server.listen(3000); +console.log('Listening on port 3000'); +``` This server is functionally equivalent to a generic event emitter: -````js -// Raise an event -const emitter = new EventEmitter('messageLogged') +```js +// Raise an event +const emitter = new EventEmitter('messageLogged'); // Register a listener -emitter.on('messagedLogged', function() { - console.log('The listener was called.') -}) +emitter.on('messagedLogged', function () { + console.log('The listener was called.'); +}); +``` -```` - -Whenever a request is made to this server, it raises an event. We can therefore target it with the `on` method and make it execute a function when requests are made. +Whenever a request is made to this server, it raises an event. We can therefore target it with the `on` method and make it execute a function when requests are made. If we were to start the server by running the file and we then used a browser to navigate to the port, we would see `new connection` logged every time we refresh the page. @@ -51,32 +52,28 @@ If we were to start the server by running the file and we then used a browser to A socket is a generic protocol for client-server communication. Crucially it **allows simultaneous communication both ways**. The client can contact the server but the server can also contact the client. Our listener function above uses a socket as the callback function but in most cases this is quite low-level, not distinguishing responses from requests. It is more likely that you would initiate a `request, resource` architecture in place of a socket: -````js +```js const server = http.createServer((req, res) => { - if (req.url === '/'){ - res.write('hello') - res.end() - } -}) - -```` + if (req.url === '/') { + res.write('hello'); + res.end(); + } +}); +``` #### Return JSON Below is an example of using this architecture to return JSON to the client: -````js - +```js const server = http.createServer((req, res) => { - if (req.url === '/products'){ - res.write(JSON.stringify(['shoes', 'lipstick', 'cups'])) - res.end() - } -}) - - -```` + if (req.url === '/products') { + res.write(JSON.stringify(['shoes', 'lipstick', 'cups'])); + res.end(); + } +}); +``` ### Express -In reality you would rarely use the `http` module directly to create a server. This is because it is quite low level and each response must be written in a linear fashion as with the two URLs in the previous example. Instead we use Express which is a framework for creating servers and routing that is an abstraction on top of the core HTTP module. +In reality you would rarely use the `http` module directly to create a server. This is because it is quite low level and each response must be written in a linear fashion as with the two URLs in the previous example. Instead we use Express which is a framework for creating servers and routing that is an abstraction on top of the core HTTP module. diff --git a/Programming_Languages/NodeJS/Modules/Modules.md b/Programming_Languages/NodeJS/Modules/Modules.md index c345c41..10ecc69 100644 --- a/Programming_Languages/NodeJS/Modules/Modules.md +++ b/Programming_Languages/NodeJS/Modules/Modules.md @@ -1,6 +1,7 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - backend - node-js - node-modules @@ -10,11 +11,11 @@ tags: > Modules are partitioned files where we define our variables and functions. Values defined in modules are scoped to that specific module, constituting a unique name space. This avoids name clashes in large programs. -* Every file in a Node application is considered a module. +- Every file in a Node application is considered a module. -* The variables and methods in a module are equivalent to `private` properties and methods in object-oriented programming. +- The variables and methods in a module are equivalent to `private` properties and methods in object-oriented programming. -* If you wish to use a function or variable defined in a module outside of its modular container you need to explicitly export it and make it public. +- If you wish to use a function or variable defined in a module outside of its modular container you need to explicitly export it and make it public. ## Structure of a module @@ -22,81 +23,74 @@ Node keeps an internal record of the properties of a module. To see this we can ```js // index.js -console.log(module) +console.log(module); ``` + This gives us: ```plaintext -Module { - id: '.', - path: '/home/thomas/repos/node-learning', - exports: {}, - filename: '/home/thomas/repos/node-learning/index.js', - loaded: false, - children: [], - paths: [ - '/home/thomas/repos/node-learning/node_modules', - '/home/thomas/repos/node_modules', - '/home/thomas/node_modules', - '/home/node_modules', - '/node_modules' - ] +Module { + id: '.', + path: '/home/thomas/repos/node-learning', + exports: {}, + filename: '/home/thomas/repos/node-learning/index.js', + loaded: false, + children: [], + paths: [ + '/home/thomas/repos/node-learning/node_modules', + '/home/thomas/repos/node_modules', + '/home/thomas/node_modules', + '/home/node_modules', + '/node_modules' + ] } ``` + ## Exports -* Whenever we export a property or method from a module we are directly targeting the `exports` property of the module object. -* Once we add exports to a file they will be displayed under that property of the module object. -* We can export the entire module itself as the export (typically used when the module is a single function or class) or individual properties. +- Whenever we export a property or method from a module we are directly targeting the `exports` property of the module object. +- Once we add exports to a file they will be displayed under that property of the module object. +- We can export the entire module itself as the export (typically used when the module is a single function or class) or individual properties. ### Exporting a whole module -*The example below is a module file that consists in a single function* - -````js +_The example below is a module file that consists in a single function_ +```js module.exports = function (...params) { - // function body -} - -```` + // function body +}; +``` Note the module is unnamed. We would name it when we import: -````js - -const myFunction = require('./filenme') - -```` +```js +const myFunction = require('./filenme'); +``` ### Exporting sub-components from a module -In the example below we export a variable and function from the same module. Note only those values prefixed with `exports` are exported. - -````js +In the example below we export a variable and function from the same module. Note only those values prefixed with `exports` are exported. +```js exports.myFunc = (...params) => { - // function bod[]()y -} + // function bod[]()y +}; -exports.aVar = 321.3 +exports.aVar = 321.3; -var nonExportedVar = true - -```` +var nonExportedVar = true; +``` This time the exports are already name so we would import with the following: -````js +```js +const {myFunc, aVar} = require('./filename'); +``` -const { myFunc, aVar } = require("./filename"); - -```` - -We can also do the exporting at the bottom when the individual components are named: - -````js +We can also do the exporting at the bottom when the individual components are named: +```js const myNamedFunc = (val) => { return val + 1; }; @@ -110,39 +104,38 @@ exports.myNamedFunc = myNamedFunc; exports.differentName = anotherNamedFunc; // We can use different names // Or we could export them together -module.exports = { myNamedFunc, anotherNamedFunc }; - -```` +module.exports = {myNamedFunc, anotherNamedFunc}; +``` The import is the same: -````js -const { myNamedFunc, anotherNamedFunc } = require("./modules/multiExports"); -```` +```js +const {myNamedFunc, anotherNamedFunc} = require('./modules/multiExports'); +``` ## Structuring modules -The techniques above are useful to know but generally you would want to enforce a stricter structure than a mix of exported and private values in the one file. The best way to do this is with a single default export. +The techniques above are useful to know but generally you would want to enforce a stricter structure than a mix of exported and private values in the one file. The best way to do this is with a single default export. Here the thing exported could be a composite function or an object that basically acts like a class with methods and properties. -*Export a composite single function* +_Export a composite single function_ ```js -module.exports = () => { - foo() {...} - bar() {...} +module.exports = () => { + foo() {...} + bar() {...} } ``` -*Export an object* +_Export an object_ ```js -module.exports = { +module.exports = { foo : () => {...}, - bar: () => {...} + bar: () => {...} } ``` @@ -152,8 +145,9 @@ Or you could export an actual class as the default. This is practically the same ```js export default class { - foo() {} - bar() {} -} + foo() {} + bar() {} +} ``` -Every method and property within the export will be public by default, whether it is an object, class or function. If you wanted to keep certain methods/properties private, the best approach is to define them as variables and functions within the module file but outside of the `export` block. \ No newline at end of file + +Every method and property within the export will be public by default, whether it is an object, class or function. If you wanted to keep certain methods/properties private, the best approach is to define them as variables and functions within the module file but outside of the `export` block. diff --git a/Programming_Languages/NodeJS/Modules/Package_management.md b/Programming_Languages/NodeJS/Modules/Package_management.md index 7b30956..26c147f 100644 --- a/Programming_Languages/NodeJS/Modules/Package_management.md +++ b/Programming_Languages/NodeJS/Modules/Package_management.md @@ -1,37 +1,39 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - backend - node-js - npm --- # Package management + ## List installed packages ```bash -npm list +npm list ``` -This will return a recursive tree that lists dependencies, dependences of dependencies, ... and so on. + +This will return a recursive tree that lists dependencies, dependences of dependencies, ... and so on. To limit the depth you can add the `--depth=` flag. For example to see only your installed packages and their versions use `npm list --depth=0`. ## View `package.json` data for an installed package -We could go to the NPM registry and view details or we can quickly view the `package.json` for the dependency with the command `npm view [package_name]` +We could go to the NPM registry and view details or we can quickly view the `package.json` for the dependency with the command `npm view [package_name]` -We can pinpoint specific dependencies in the `package.json`, e.g. `npm view [package_name] dependencies ` +We can pinpoint specific dependencies in the `package.json`, e.g. `npm view [package_name] dependencies ` ## View outdated modules -See whether your dependency version is out of date use `npm outdated`. This gives us a table, for example: +See whether your dependency version is out of date use `npm outdated`. This gives us a table, for example:  - -* *Latest* tells us the latest release available from the developers -* *Wanted* tells us the version that our `package.json` rules target. To take the first dependency as an example. We must have set our SemVer syntax to `^0.4.x` since it is telling us that there is a minor release that is more recent than the one we have installed but is not advising that we update to the latest major release. -* *Current* tells us which version we currently have installed regardless of the version that our `package.json` is targeting or the most recent version available. +- _Latest_ tells us the latest release available from the developers +- _Wanted_ tells us the version that our `package.json` rules target. To take the first dependency as an example. We must have set our SemVer syntax to `^0.4.x` since it is telling us that there is a minor release that is more recent than the one we have installed but is not advising that we update to the latest major release. +- _Current_ tells us which version we currently have installed regardless of the version that our `package.json` is targeting or the most recent version available. ## Updating -`npm update` only updates from *current* to *wanted*. In other words it only updates in accordance with your caret and tilde rules applied to [semantic versioning](/Software_Engineering/Semantic_versioning.md). +`npm update` only updates from _current_ to _wanted_. In other words it only updates in accordance with your caret and tilde rules applied to [semantic versioning](/Software_Engineering/Semantic_versioning.md). diff --git a/Programming_Languages/NodeJS/Modules/Third_party/Morgan.md b/Programming_Languages/NodeJS/Modules/Third_party/Morgan.md index 43715b5..7db50f6 100644 --- a/Programming_Languages/NodeJS/Modules/Third_party/Morgan.md +++ b/Programming_Languages/NodeJS/Modules/Third_party/Morgan.md @@ -1,6 +1,7 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - backend - node-js - middleware @@ -8,16 +9,18 @@ tags: # Morgan -Morgan is middleware that is used to log HTTP requests to the Express instance. +Morgan is middleware that is used to log HTTP requests to the Express instance. ```js -app.use(morgan('dev')) +app.use(morgan('dev')); ``` + With Morgan in place, every time we run a request it will be logged on the console that is running our Node application, e.g: ```plain GET /api/courses 200 95 - 1.774 ms ``` + This uses the `tiny` default which logs the bare minimum giving us: request type; endpoint; response code; and time to execute. But there are more verbose settings. -It defaults to logging on the console but can also be configured to write to a log file. +It defaults to logging on the console but can also be configured to write to a log file. diff --git a/Programming_Languages/NodeJS/Modules/Third_party/Nodemon.md b/Programming_Languages/NodeJS/Modules/Third_party/Nodemon.md index e086fa4..67c5b1c 100644 --- a/Programming_Languages/NodeJS/Modules/Third_party/Nodemon.md +++ b/Programming_Languages/NodeJS/Modules/Third_party/Nodemon.md @@ -1,12 +1,13 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - backend - node-js --- # Nodemon -We don't want to have to restart the local server every time we make a change to our files. We can use `nodemon` instead of `node` when running our `index.js` file so that file-changes are immediately registered without the need for a restart. +We don't want to have to restart the local server every time we make a change to our files. We can use `nodemon` instead of `node` when running our `index.js` file so that file-changes are immediately registered without the need for a restart. -This is a wrapper around the `node` command so it doesn't require any configuration. Once installed, update your start script from `node index.js` to `nodemon index.js`. +This is a wrapper around the `node` command so it doesn't require any configuration. Once installed, update your start script from `node index.js` to `nodemon index.js`. diff --git a/Programming_Languages/Shell_Scripting/Control_flow.md b/Programming_Languages/Shell_Scripting/Control_flow.md index 970e22e..7198835 100644 --- a/Programming_Languages/Shell_Scripting/Control_flow.md +++ b/Programming_Languages/Shell_Scripting/Control_flow.md @@ -1,12 +1,13 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - shell --- ## If statements -* Conditional blocks start with `if` and end with the inversion `fi` (this is a common syntactic pattern in bash) -* The conditional expression must be placed in square brackets with spaces either side. The spaces matter: if you omit them, the code will not run -* We designate the code to run when the conditional is met with `then` -* We can incorporate else if logic with `elif` +- Conditional blocks start with `if` and end with the inversion `fi` (this is a common syntactic pattern in bash) +- The conditional expression must be placed in square brackets with spaces either side. The spaces matter: if you omit them, the code will not run +- We designate the code to run when the conditional is met with `then` +- We can incorporate else if logic with `elif` diff --git a/Programming_Languages/Shell_Scripting/Cron.md b/Programming_Languages/Shell_Scripting/Cron.md index 526753e..c26f509 100644 --- a/Programming_Languages/Shell_Scripting/Cron.md +++ b/Programming_Languages/Shell_Scripting/Cron.md @@ -1,30 +1,37 @@ --- +categories: + - Programming Languages + - Linux tags: - - Programming_Languages - shell --- + # Cron +## `cronie` -## `cronie` -In Arch Linux I use `cronie` for cron jobs. (There is no cron service installed by default). Install `cronie` and then enable it in systemd with: +In Arch Linux I use `cronie` for cron jobs. (There is no cron service installed by default). Install `cronie` and then enable it in systemd with: - -```bash +```bash systemctrl enable --now cronie.service ``` + ## commands ### List cron jobs + ``` crontab -l ``` ### Open cron file + ``` crontab -e ``` + ### Check cron log + ```bash journalctl | grep CRON @@ -32,28 +39,29 @@ journalctl | grep CRON ``` ## Syntax -````bash + +```bash m h d mon dow command # minute, hour, day of month, day of week, bash script/args # 0-59, 0-23, 1-31, 1-12, 0-6 -```` - +``` **Examples** -Run on the hour every hour +Run on the hour every hour -```` +``` 0 * * * * mysqlcheck --all-databases --check-only-changed --silent -```` +``` -At 01:42 every day: +At 01:42 every day: -```` +``` 42 1 * * * mysqlcheck --all-databases --check-only-changed --silent -```` +``` + +Every half hour: -Every half hour: ``` 0,30 * * * * ${HOME}/bash_scripts/automate_commit.sh @@ -61,25 +69,25 @@ Every half hour: **Shorthands** -* `@reboot` – Run once, at startup -* `@yearly` – Run once a year, “0 0 1 1 \*”.\> -* `@annually` – same as @yearly -* `@monthly` – Run once a month, “0 0 1 * \*” -* `@weekly` – Run once a week, “0 0 * * 0” -* `@daily` – Run once a day, “0 0 * * \*” -* `@midnight` – same as @daily -* `@hourly` – Run once an hour, “0 * * * \*” +- `@reboot` – Run once, at startup +- `@yearly` – Run once a year, “0 0 1 1 \*”.\> +- `@annually` – same as @yearly +- `@monthly` – Run once a month, “0 0 1 \* \*” +- `@weekly` – Run once a week, “0 0 \* \* 0” +- `@daily` – Run once a day, “0 0 \* \* \*” +- `@midnight` – same as @daily +- `@hourly` – Run once an hour, “0 \* \* \* \*” **Examples** -```` +``` @hourly mysqlcheck --all-databases --check-only-changed --silent -```` +``` **View the logs** -````bash +```bash sudo grep crontab syslog -```` +``` diff --git a/Programming_Languages/Shell_Scripting/Environmental_and_shell_variables.md b/Programming_Languages/Shell_Scripting/Environmental_and_shell_variables.md index 5d2d995..9ae5c20 100644 --- a/Programming_Languages/Shell_Scripting/Environmental_and_shell_variables.md +++ b/Programming_Languages/Shell_Scripting/Environmental_and_shell_variables.md @@ -1,6 +1,7 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - shell --- @@ -8,14 +9,14 @@ tags: To understand the difference between environmental and shell variables know that: -* You can spawn child shells from the parent shell that is initiated when you first open the terminal. To do this just run `bash` or `zsh` . -* This is a self-contained new instance of the shell. This means: - * It **will have** access to environmental variables (since they belong to the parent / are global) - * It **will not have** access to any shell variables that are defined in the parent. -* **How do you get back to the ‘upper’ parent shell?** Type `exit` . -* Note that: - * Custom (user-created) shell variables **do not** pass down to spawned shell instances, nor do they pass up to the parent - * Custom (user-created) environment variables do pass down to spawned shell instances but do not pass up to the parent. They are lost on `exit` . +- You can spawn child shells from the parent shell that is initiated when you first open the terminal. To do this just run `bash` or `zsh` . +- This is a self-contained new instance of the shell. This means: + - It **will have** access to environmental variables (since they belong to the parent / are global) + - It **will not have** access to any shell variables that are defined in the parent. +- **How do you get back to the ‘upper’ parent shell?** Type `exit` . +- Note that: + - Custom (user-created) shell variables **do not** pass down to spawned shell instances, nor do they pass up to the parent + - Custom (user-created) environment variables do pass down to spawned shell instances but do not pass up to the parent. They are lost on `exit` . Q. What methods are there for keeping track of, preserving, and jumping between spawned instances? Is this even possible or do they die on `exit` . @@ -26,25 +27,25 @@ Q. What methods are there for keeping track of, preserving, and jumping between ## What is the shell environment and what are environment variables? -* Every time that you interact with the shell you do so within an **environment**. This is the context within which you are working and it determines your access to resources and the behaviour that is permitted. +- Every time that you interact with the shell you do so within an **environment**. This is the context within which you are working and it determines your access to resources and the behaviour that is permitted. -* The environment is an area that the shell builds every time that it starts a session. It contains variables that define system properties. +- The environment is an area that the shell builds every time that it starts a session. It contains variables that define system properties. -* Every time a [shell session](https://www.notion.so/Shell-sessions-e6dd743dec1d4fe3b1ee672c8f9731f6) spawns, a process takes place to gather and compile information that should be available to the shell process and its child processes. It obtains the data for these settings from a variety of different files and settings on the system. +- Every time a [shell session](https://www.notion.so/Shell-sessions-e6dd743dec1d4fe3b1ee672c8f9731f6) spawns, a process takes place to gather and compile information that should be available to the shell process and its child processes. It obtains the data for these settings from a variety of different files and settings on the system. -* The environment is represented by strings comprising key-value pairs. For example: - - ````bash +- The environment is represented by strings comprising key-value pairs. For example: + + ```bash KEY=value1:value2 KEY="value with spaces":"another value with spaces" - ```` - + ``` + As the above shows, a key can have multiple related values. Each one is demarcated with a `:` . If the value is longer than a single word, quotation marks are used. -* The keys are **variables**. They come in two types: **environmental variables** and **shell variables:** - - * Environmental variables are much more permanent and pertain to things like the user and his path (the overall session) - * Shell variables are more changeable for instance the current working directory (the current program instance) +- The keys are **variables**. They come in two types: **environmental variables** and **shell variables:** + + - Environmental variables are much more permanent and pertain to things like the user and his path (the overall session) + - Shell variables are more changeable for instance the current working directory (the current program instance) Variables can be created via config files that run on the initialisation of the session or manually created via the command line in the current session @@ -58,59 +59,59 @@ More generally they are used for when you will need to read or alter the environ To view the settings of your current environment you can execute the `env` command which returns a list of the key-value pairs introduced above. Here are some of the more intelligible variables that are returned when I run this command: -````bash +```bash SHELL=/usr/bin/zsh DESKTOP_SESSION=plasma HOME=/home/thomas USER=thomas PWD=/home/thomas/repos/bash-scripting PATH=/home/thomas/.nvm/versions/node/v16.8.0/bin:/home/thomas/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/var/lib/snapd/snap/bin -```` +``` However if you want to target a specific viable you need to invoke `printenv` with the relevant key, for example: -````bash +```bash printenv SHELL # SHELL=/usr/bin/zsh -```` +``` Note that `env` and `printenv` do not show all the shell variables, only a selection. To view all the shell variables along with the environmental variables use `set` . ## Creating, exporting and deleting variable shell and environment variables -* You set shell variables using the same syntax you would within a script file: - - ````bash +- You set shell variables using the same syntax you would within a script file: + + ```bash TEST_SHELL_VAR="This is a test" - set | grep TEST_SH + set | grep TEST_SH TEST_SHELL_VAR='This is a test' - + # We can also print it with an echo, again exactly as we would with a shell script echo S{TEST_SHELL_VAR} - ```` + ``` -* We can verify that it is not an environmental variable based on the fact that following does not return anything: - - ````bash +- We can verify that it is not an environmental variable based on the fact that following does not return anything: + + ```bash printenv | grep TEST-SH - ```` + ``` -* We can verify that this is a shell variable by spawning a new shell and calling it. Nothing will be returned from the child shell. +- We can verify that this is a shell variable by spawning a new shell and calling it. Nothing will be returned from the child shell. -* You can upgrade a shell variable to an environment variable with `export` : - - ````bash +- You can upgrade a shell variable to an environment variable with `export` : + + ```bash export TEST_SHELL_VAR # And confirm: printenv | grep TEST_SH TEST_SHELL_VAR='This is a test' - ```` + ``` -* We can use the same syntax to create new environment variables from scratch: - - ````bash +- We can use the same syntax to create new environment variables from scratch: + + ```bash export NEW_ENV_VAR="A new var" - ```` + ``` ### Using config files to create variables @@ -122,11 +123,11 @@ You can also add variables to config files that run on login such as your user ` A list of directories that the system will check when looking for commands. When a user types in a command, the system will check directories in this order for the executable. -````bash -echo ${PATH} +```bash +echo ${PATH} # /home/thomas/.nvm/versions/node/v16.8.0/bin:/home/thomas/.local/bin:/usr/local/sbin:/usr/local/bin: # /usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/var/lib/snapd/snap/bin -```` +``` For example, if you wish to use `npm` commands globally (in any directory) you will need to have the requisite Node executable in your path, which you can see above. @@ -136,25 +137,25 @@ TODO: Add more info about the path when I have it. This describes the shell that will be interpreting any commands you type in. In most cases, this will be bash by default, but other values can be set if you prefer other options. -````bash +```bash echo ${SHELL} # /usr/bin/zsh -```` +``` ### `USER` The current logged in user. -````bash +```bash echo ${USER} -# thomas -```` +# thomas +``` ### `PWD` The current working directory. -````bash +```bash echo ${PWD} -# /home/thomas -```` +# /home/thomas +``` diff --git a/Programming_Languages/Shell_Scripting/File_permissions_and_execution.md b/Programming_Languages/Shell_Scripting/File_permissions_and_execution.md index a81cd8d..2622f23 100644 --- a/Programming_Languages/Shell_Scripting/File_permissions_and_execution.md +++ b/Programming_Languages/Shell_Scripting/File_permissions_and_execution.md @@ -1,31 +1,36 @@ --- +categories: + - Programming Languages tags: - - Programming_Languages - shell --- # File permissions and executables -Every Unix file has a set of permissions that determine whether you can read, write or run (execute) the file. + +Every Unix file has a set of permissions that determine whether you can read, write or run (execute) the file. + ## Viewing file permissions In order to see file permissions within the terminal, use the `-l` or `-rfl` with the `ls` command. Remember this command can be applied at both the directory and single-file level. For example: -````bash +```bash drwxr-xr-x 7 thomas thomas 4096 Oct 2 19:22 angular-learning-lab drwxr-xr-x 5 thomas thomas 4096 Oct 17 18:05 code-exercises drwxr-xr-x 5 thomas thomas 4096 Sep 4 16:15 js-kata drwxr-xr-x 9 thomas thomas 4096 Sep 26 18:10 sinequanon drwxr-xr-x 12 thomas thomas 4096 Sep 19 17:41 thomas-bishop drwxr-xr-x 5 thomas thomas 4096 Sep 4 19:24 ts-kata -```` +``` ### What the output means -The first column of the permissions output is known as the file's *mode*. The sequence from left to right is as follows: +The first column of the permissions output is known as the file's _mode_. The sequence from left to right is as follows: + ``` -- - - - - - - - - - +- - - - - - - - - - type user permissions group permissions other permissions ``` +