menu

Search By Label

To query a MongoDB collection to search a RegExp, you can use the following syntax in a MongoDB query:
db.collection.find({
    name: {$regex: "Match here"}
})
To query a MongoDB collection where a specific field both exists and is not empty, you can use the following syntax in a MongoDB query (using the find method):
db.collection.find({
  description: { $exists: true, $ne: "" }
})

$exists: true: ensures the field exists.
$ne: "": ensures the field is not an empty string.

Partition for manageability, Sharding for scalability.

Partitioning
Dividing data into segments (partitions) for easier management or to group related data together.
Often used within the same system and transparent to the application.

Sharding
Splitting data across multiple databases or servers to distribute the load and scale horizontally. 

Each shard operates independently, and often, the application needs logic to direct queries to the correct shard unless the data storage system transparently supports the redirect.
You can use the command :%s/<string-to-replace>/<new-string> to replace all matches with a new string.
You should use these comparisons for their semantics.
Use is to check identity and == to check equality.
In Python names refer to objects, for example in this case value1 and value2 refer to an int instance storing the value 1000:

value1 = 1000
value2 = value1
>>> value1 == value2
True
>>> value1 is value2
True
In the following example the names value1 and value2 refer to different int instances, even if both store the same integer. Because the same value (integer) is stored == will be True, that's why it's often called "value comparison". However is will return False because these are different objects:
>>> value1 = 1000
>>> value2 = 1000

>>> value1 == value2 True >>> value1 is value2 False
This will open an interactive help session where you can type in the names of modules, functions, classes, etc., to get information about them.

Example Usage

Here’s a practical example:
import datetime
help(datetime.datetime)
This will provide detailed information about the datetime class within the datetime module, including its methods and usage.
It's a list of public objects of that module, as interpreted by import *. It overrides the default of hiding everything that begins with an underscore.

__all__ in a module, e.g. module.py:

__all__ = ['foo', 'Bar']

means that when you import * from the module, only those names in the __all__ are imported:

from module import *               # imports foo and Bar
You can use the command:
kubectl logs <pod-id> --previous
To show the logs from the version that crashes or use the command:
kubectl get pod celery-worker-5558fbffb-25dmw -o jsonpath="{.status.containerStatuses[0].lastState.terminated.reason}"
To show the terminated reason only.
If you need to run a command inside an existing Docker image or inspect the content of it, you can use the following command:

docker run -it <image_id> /bin/bash
Flask-Limiter adds rate limiting to Flask applications.
By adding the extension to your flask application, you can configure various rate limits at different levels (e.g. application wide, per Blueprint, routes, resource etc).
Flask-Limiter can be configured to persist the rate limit state to many commonly used storage backends via the limits library.


Source: https://flask-limiter.readthedocs.io/en/stable/
The CAP Theorem is a principle that says a distributed database can only guarantee two of the following three things at the same time:
  1. Consistency (C): Every read gets the most recent write.
  2. Availability (A): Every request gets a response (either success or failure).
  3. Partition Tolerance (P): The system keeps working even if parts of the network fail (e.g., servers can't talk to each other).

Example:
Imagine you have a system with multiple servers that store user data.
  • Consistency (C): If you update your email address on one server, all other servers will immediately reflect that change.
  • Availability (A): Even if one server goes down, the system will still respond to your requests.
  • Partition Tolerance (P): Even if a network issue occurs and some servers can't communicate with others, the system will continue working.

The CAP Theorem says:
You can pick two of the three properties (Consistency, Availability, Partition Tolerance), but not all three at once. For example:
  • CA (Consistency + Availability): If you want consistency and availability, the system might fail when the network partitions.
  • CP (Consistency + Partition Tolerance): If you want consistency and partition tolerance, the system might not be available (i.e., not respond to requests).
  • AP (Availability + Partition Tolerance): If you want availability and partition tolerance, the system might serve stale data (not consistent).


Why You Can't Have All Three
1. Consistency and Availability without Partition Tolerance (CA):
  • Scenario: Imagine a system where you have two servers. You want to guarantee that every request gets a response (Availability) and that all users see the same data (Consistency).
  • Problem: If a network partition occurs (e.g., one server can't communicate with the other), the system has to choose between responding to requests (Availability) and returning the most recent data (Consistency). It can't do both, because if one server isn't reachable, the system can't guarantee that the data will be the same on all servers.
  • Conclusion: In the case of network partitions, you must choose Availability over Consistency or Consistency over Availability. Therefore, you can't have both consistency and availability without partition tolerance.

2. Consistency and Partition Tolerance without Availability (CP):
  • Scenario: Suppose you want to ensure that your system is always consistent (all data is synchronized across servers) and can still function if parts of the network fail (Partition Tolerance).
  • Problem: In the event of a network partition, some servers might be unreachable, but the system will still ensure that all nodes have consistent data by refusing to answer requests until the partition is resolved. This means Availability is sacrificed — the system might not respond to some requests because it is waiting for the partition to be resolved to keep consistency.
  • Conclusion: If the system guarantees Consistency and Partition Tolerance, it may not be able to respond to requests during a partition, thus sacrificing Availability.

3. Availability and Partition Tolerance without Consistency (AP):
  • Scenario: You want your system to respond to every request (availability) and keep working even if some parts of the network fail (partition tolerance).
  • Problem: If there is a network partition, different parts of the system may start serving different versions of the data because the system will continue to process requests even when some servers can't talk to each other. This can result in inconsistent data between nodes.
  • Conclusion: In this case, you give up consistency to ensure both Availability and Partition Tolerance.
Tuples are used to store multiple items in a single variable.

Example:
thistuple = ("apple", "banana", "cherry")
print(thistuple) // ('apple', 'banana', 'cherry')

In Python, arrays and tuples are both used to store collections of data, but they have distinct characteristics and use cases.

A tuple is an ordered and immutable collection of items. Once a tuple is created, its elements cannot be changed. Tuples are defined using parentheses () and can store elements of different data types.
https://github.com/topics/cloudflare-firewall-rules
To create a new secret use the command:
kubectl create secret generic <secret-name> --from-file=key.json=gcloud_keys.json -n <namespace>
 Where we are setting the key.json file from our local file gcloud_keys.json 

After configure it you can verify is working by running:
kubectl describe secret <secret_name> -n <namespace>
Or see the content with:
kubectl get secret <secret_name> -n <namespace> -o jsonpath="{.data.key\.json}" | base64 --decode

And finally configure the secret on your deploy files.
The unnest() function in  PostgreSQL is used to expand an array into a set of rows. It takes an array as input and returns a new table where each element of the array occupies a separate row. This function is particularly useful for normalizing denormalized data stored in array formats and for performing operations that require each array element to be processed individually.

Uses of the PostgreSQL UNNEST() Function
  • Normalize Data: Transform array data into individual rows for easier processing.
  • Facilitate Joins: Enable joins with other tables by expanding arrays into rows.
  • Aggregate Data: Perform aggregate functions on individual array elements.
  • Filter Array Elements: Apply filters to specific elements within an array.
  • Convert Arrays to Tables: Turn arrays into tabular format for better data manipulation.
  • Combine with Other Functions: Use in conjunction with other PostgreSQL functions for advanced data operations.

Example of use
-- Selecting and unnesting an array of integers
SELECT 
    unnest(ARRAY[1, 2]); -- Expands the array [1, 2] into individual rows

Source: https://www.w3resource.com/PostgreSQL/postgresql_unnest-function.php