chore: delete refactored entries
This commit is contained in:
thomasabishop
parent
dfaaef5084
commit
410bd2a6b8
4 changed files with 0 additions and 259 deletions
|
|
@ -1,46 +0,0 @@
|
|||
---
|
||||
categories:
|
||||
- Computer Architecture
|
||||
tags: [memory]
|
||||
---
|
||||
|
||||
# The role of memory in computation
|
||||
|
||||
The following steps outline the way in which memory interacts with the processor during computational cycles, once the [bootstrapping](/Operating_Systems/Boot_process.md) process has completed and the OS kernel is itself loaded into memory.
|
||||
|
||||
1. A file is loaded from the harddisk into memory.
|
||||
2. The instruction at the first address is sent to the CPU, travelling accross the data bus part of the [system bus](/Computer_Architecture/Bus.md).
|
||||
3. The CPU processes this instruction and then sends a request accross the address bus part of the system bus for the next instruction to the memory controller within the [chipset](/Computer_Architecture/Chipset_and_controllers.md).
|
||||
4. The chipset finds where this instruction is stored within the [DRAM](/Computer_Architecture/Memory/Memory.md#dram) and issues a request to have it read out and send to the CPU over the data bus.
|
||||
|
||||
> This is a simplified account; it is not the case that only single requests are passed back and forth. This would be inefficient and time-wasting. The kernel sends to the CPU not just the first instruction in the requested file but also a number of instructions that immediately follow it.
|
||||
|
||||
|
||||
|
||||
Every part of the above process - the journey accross the bus, the lookup in the controller, the operations on the DRAM, the journey back accross the bus - takes multiple CPU clock cycles.
|
||||
|
||||
## The role of the cache
|
||||
|
||||
The cache is SRAM memory that is separate from the DRAM memory which comprises the main memory. It exists in order to boost perfomance when executing the read/request cycles of the steps detailed above.
|
||||
|
||||
There are two types of cache memory:
|
||||
|
||||
- L1 cache
|
||||
- Situated on the CPU chip itself
|
||||
- L2 cache
|
||||
- Situated outside of the CPU on its own chip
|
||||
|
||||
The L1 cache is the fastest since the data has less distance to travel when moving to and from the CPU. This said, the L2 cache is still very fast when compared to the main memory, both because it is SRAM rather than DRAM and because it is closer to the processor than the main memory.
|
||||
|
||||
Cache controllers use complex algorithms to determine what should go into the cache to facilitate the best performance, but generally they work on the principle that what has been previously used by the CPU will be requested again soon. If the CPU has just asked for an instruction at memory location 555 it's very likely that it will next ask for the one at 556, and after that the one at 557 and so on. The cache's controller circuits therefore go ahead and fetch these from slow DRAM to fast SRAM.
|
||||
|
||||
## Relation between cache and buffers
|
||||
|
||||
The terms _cache_ and _buffer_ are often used interchangeably because they are both types of temporary storage used to speed up CPU operations. Also they are both mechanisms for avoiding writing data to a storage device in the midst of active computation. They are different however:
|
||||
|
||||
- A cache is used to store a subset of data (typically transient in nature) from a more permanent or slower storage location. In the context of the CPU, the L1 is a cache whereas the DRAM is the more permanent storage location.
|
||||
- A buffer is a temporary storage area for data while it is being transferred from one place to another. It helps with "smoothing out" data transfers, ensuring that the sending and receiving entities (which might operate at different speeds) can handle the data transfer effectively.
|
||||
|
||||
Whereas a CPU cache is a **physical** part of the processor a buffer is more of a **logical** concept implemented within the system software. However a buffer does use physical memory - it is portion of RAM set aside for temporary storage.
|
||||
|
||||
[Registers](/Computer_Architecture/CPU/CPU_architecture.md#registers) should not be confused with caches. Unlike the caches, registers are a part of the CPU itself. They are much quicker but hold less data than the caches.
|
||||
|
|
@ -1,36 +0,0 @@
|
|||
---
|
||||
categories:
|
||||
- DevOps
|
||||
- Backend
|
||||
tags: [AWS, aws-lambda]
|
||||
---
|
||||
|
||||
# Accessing secrets from a Lambda
|
||||
|
||||
If a Lambda connects to a database or calls an API, it is going need access to authentication tokens/passwords.
|
||||
|
||||
You obviously should not store these in your code. Instead you should store them in AWS Secrets Manager and access them via the `aws-sdk` in your Lambda function.
|
||||
|
||||
In order for your function to be able to access the secrets however, it will need to be given permission. While the Lambda is not itself a "user" it does have an identity in the form of its IAM role. This is disclosed by its ARN.
|
||||
|
||||
To allow the Lambda to access the secret you should add a resource permission on the secret that designates the Lambda.
|
||||
|
||||
> When you create a Lambda function, you specify an IAM role that AWS Lambda can assume to execute the function on your behalf. This role is referred to as the execution role. The execution role grants the function the necessary permissions to call other AWS services, access resources, and perform other operations.
|
||||
|
||||
Here is an example of a resource permission giving access to a Lambda:
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "arn:aws:iam::885135949562:role/pocket-api-lambda-QueryPocketFunctionRole-GY5ZN3RW31KE"
|
||||
},
|
||||
"Action": "secretsmanager:GetSecretValue",
|
||||
"Resource": "arn:aws:secretsmanager:eu-west-2:885135949562:secret:pocket-api-credentials-wEvQMI"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
|
@ -1,70 +0,0 @@
|
|||
---
|
||||
categories:
|
||||
- DevOps
|
||||
- Backend
|
||||
tags: [AWS, aws-lambda, node-js]
|
||||
---
|
||||
|
||||
# Practical walkthrough of creating a Lambda function, trigger and subsequent events
|
||||
|
||||
## Basic set-up
|
||||
|
||||
First we name the function and accept the defaults:
|
||||
|
||||
|
||||
|
||||
This presents us with the function dashboard - a graphical representation of the Lambda showing [triggers]() as an input and destination as an output:
|
||||
|
||||
|
||||
|
||||
Beneath this we have a code editor with the handler function with a basic boilerplate:
|
||||
|
||||
|
||||
|
||||
## Adding a trigger
|
||||
|
||||
Next we need to add a [trigger](/DevOps/AWS/AWS_Lambda/Lambda_triggers.md) that execute the handler.
|
||||
|
||||
We will do this using [AWS API Gateway](/DevOps/AWS/AWS_API_Gateway.md). We select "Add trigger" from the dashboard view and input basic settings:
|
||||
|
||||
|
||||
|
||||
Now we see this step displayed in the dashboard:
|
||||
|
||||
|
||||
|
||||
With the endpoint and other settings displayed:
|
||||
|
||||
|
||||
|
||||
If we go to the endpoint URL (`https://4kjqwbvd7g.execute-api.us-east-1.amazonaws.com/default/myFirstFunction`), we will see the output: `Hello from Lambda`.
|
||||
|
||||
## Handling parameters
|
||||
|
||||
We can make the example more realistic by expanding the handler to accept query parameters. We do this by accessing the value `queryStringParameters` on the `event` object:
|
||||
|
||||
```js
|
||||
exports.handler = async (event) => {
|
||||
const name = event.queryStringParameters && event.queryStringParameters.name;
|
||||
|
||||
let message = "Hello Lambda";
|
||||
|
||||
if (name !== null) {
|
||||
message = `Hello ${name}`;
|
||||
}
|
||||
|
||||
const response {
|
||||
statusCode: 200,
|
||||
body: JSON.stringify(message)
|
||||
|
||||
}
|
||||
};
|
||||
```
|
||||
|
||||
If we now access `https://4kjqwbvd7g.execute-api.us-east-1.amazonaws.com/default/myFirstFunction?name=Thomas`
|
||||
|
||||
We get `Hello Thomas` as output.
|
||||
|
||||
For a more advanced API with multiple endpoints and parameters, it's easiest to use Postman:
|
||||
|
||||
|
||||
|
|
@ -1,107 +0,0 @@
|
|||
---
|
||||
categories:
|
||||
- Programming Languages
|
||||
tags: [python]
|
||||
---
|
||||
|
||||
# Repeating iterable data structures
|
||||
|
||||
In JavaScript when we return data from an API we tend to use an array of objects as the canonical form of a repeating iterable, e.g:
|
||||
|
||||
```js
|
||||
const data = [
|
||||
{
|
||||
name: "Thomas",
|
||||
age: 35,
|
||||
},
|
||||
{
|
||||
name: "Joe",
|
||||
age: 75,
|
||||
},
|
||||
];
|
||||
```
|
||||
|
||||
In Python there are two common ways to handle similar data structures:
|
||||
|
||||
- A list of lists:
|
||||
```py
|
||||
data = [
|
||||
["Thomas", 35],
|
||||
["Joe", 75]
|
||||
]
|
||||
```
|
||||
- A list of dictionaries:
|
||||
```py
|
||||
data = [
|
||||
{"name": "Thomas", "age": 35},
|
||||
{"name": "Joe", "age": 75},
|
||||
]
|
||||
```
|
||||
|
||||
## List of lists
|
||||
|
||||
### Sorting by common property
|
||||
|
||||
Assuming the sub-lists have an identical structure, you can [sort](/Programming_Languages/Python/Syntax/Sorting_lists_in_Python.md) them by a common property by passing a [lambda function](/Programming_Languages/Python/Syntax/Lambdas_in_Python.md) to the `key` value of `sorted()` and `.sort()`.
|
||||
|
||||
For example, to sort the following list of lists by the second `age` property:
|
||||
|
||||
```python
|
||||
people = [["Alice", 30], ["Bob", 25], ["Clare", 35], ["Dave", 28]]
|
||||
```
|
||||
|
||||
Using `sorted()`:
|
||||
|
||||
```py
|
||||
sorted_people = sorted(people, key=lambda x: x[1])
|
||||
print(sorted_people)
|
||||
# Output: [['Bob', 25], ['Dave', 28], ['Alice', 30], ['Clare', 35]]
|
||||
```
|
||||
|
||||
Using `.sort`:
|
||||
|
||||
```py
|
||||
people.sort(key=lambda x: x[1])
|
||||
print(people)
|
||||
# Output: [['Bob', 25], ['Dave', 28], ['Alice', 30], ['Clare', 35]]
|
||||
```
|
||||
|
||||
If you want to sort by name instead, you could change the lambda function to `lambda x: x[0]`:
|
||||
|
||||
```python
|
||||
# Using sorted()
|
||||
sorted_people = sorted(people, key=lambda x: x[0])
|
||||
print(sorted_people)
|
||||
# Output: [['Alice', 30], ['Bob', 25], ['Clare', 35], ['Dave', 28]]
|
||||
|
||||
# Using .sort()
|
||||
people.sort(key=lambda x: x[0])
|
||||
print(people)
|
||||
# Output: [['Alice', 30], ['Bob', 25], ['Clare', 35], ['Dave', 28]]
|
||||
```
|
||||
|
||||
### Updating a value within a list of lists
|
||||
|
||||
We can use `map` to mutate a given value within each list.
|
||||
|
||||
In the following example we have a list of the following structure:
|
||||
|
||||
```py
|
||||
data = [
|
||||
["1688582410", "Article One"],
|
||||
["1688647447", "Article Two"],
|
||||
["1689023491", "Article Three"],
|
||||
]
|
||||
```
|
||||
|
||||
Below, we apply a function to each of the first elements which is a Unix timestamp, converting it to a readable format:
|
||||
|
||||
```py
|
||||
readable_date = list(map(lambda i: [convert_timestamp(i[0])] + i[1:], date))
|
||||
```
|
||||
|
||||
Key points:
|
||||
|
||||
- We apply the `convert_timestamp` function to the first element of each sublist
|
||||
- We wrap this first element in `[]` so that it can be merged with the other elements of the list. This is necessary otherwise we will just return a list of the first elements and not include the other properties.
|
||||
- The map and lambda is the core structure. We wrap it in `list` because `map` returns an object not a list.
|
||||
Loading…
Add table
Reference in a new issue