https://codewithandrea.com/courses/
Topics to explore when learning Flutter:
- Riverpod
- Clean Architecture
Sai Jyothi Prasad Ponduru's learning blog
https://codewithandrea.com/courses/
Topics to explore when learning Flutter:
- Riverpod
- Clean Architecture
https://chatgpt.com/share/48336e83-2376-439d-acd3-79ea2fe5b7d6
The term "Access Key ID" is not called "Secret Access Key ID" because the Access Key ID itself is not considered a secret. Here's the reasoning:
Access Key ID: This is a public identifier for the credential. It is used to identify the user or service that is making requests to AWS. The Access Key ID is not secret, and it can be shared (for example, in logs) without compromising the security of your AWS resources.
Secret Access Key: This is a private component that must be kept confidential. It works like a password and is used in combination with the Access Key ID to sign API requests. Anyone with access to both the Secret Access Key and Access Key ID can make authorized API requests, so the Secret Access Key must be kept secret.
Session Token: In the case of temporary credentials from AWS STS (Security Token Service), the Session Token is also a secret and is used in conjunction with the Access Key ID and Secret Access Key to authenticate API requests for the session's duration.
Thus, the "Access Key ID" is the public-facing part that identifies the key, while the "Secret Access Key" and "Session Token" are sensitive, secret components. That's why the "Access Key ID" is named as it is—it's meant to be distinguishable from the actual secret that provides authentication.
AWS STS (AWS Security Token Service) is a service that allows you to request temporary, limited-privilege credentials for users or services to access AWS resources. These credentials are often used in scenarios where you don't want to use long-term access keys, or when you need to provide short-term access to resources without creating permanent IAM users.
Here’s a breakdown of key concepts related to AWS STS:
Temporary Security Credentials: STS provides credentials that are valid for a limited duration (from a few minutes to several hours). After they expire, they cannot be used to access AWS resources.
Assume Roles: One of the most common uses of AWS STS is assuming roles. For example, you can allow a user or application to "assume" a role that gives it specific permissions, even if the user or app doesn't have those permissions by default. This is useful in cross-account scenarios, federated access, or when using roles to segregate access levels within the same account.
Federation: AWS STS enables identity federation, which allows users from external systems (like corporate directories or external identity providers) to access AWS resources without the need to create IAM users for them. This is done via standard protocols like SAML 2.0 or OpenID Connect.
Cross-Account Access: STS makes it easy to provide access to resources across different AWS accounts. A user in one account can assume a role in another account and gain access to resources, all without requiring the user to have an IAM user in the other account.
Reduced Credential Exposure: Since STS tokens are temporary, they limit the risk if credentials are compromised. After the expiration time, the token cannot be reused.
aws sts assume-role --role-arn arn:aws:iam::123456789012:role/example-role --role-session-name session1
This command allows an identity to assume the role example-role
in account 123456789012
and gain temporary credentials.
In summary, AWS STS is a powerful tool for managing short-term, secure access to AWS resources without the need for long-term credentials. It’s especially valuable in complex environments that require secure, time-bound access control, such as in cross-account access or federated identity setups.
https://chatgpt.com/share/a15d63d2-a124-4e5d-8195-830e27fb395d
Whether targeting a role or specific AWS resources is more common or advised depends on the context and the desired security model. Both approaches serve different purposes in AWS Identity and Access Management (IAM), and each has its own use cases:
Use Case: When you want to define a set of permissions for who can perform actions.
Common: This is a common practice for controlling permissions at a higher level. You assign policies to roles, and these roles are then assumed by users or services.
Advised: This approach is recommended when managing multiple users or services because you can easily modify or revoke permissions in one place (the role) without touching individual resources.
Example:
"Resource": "arn:aws:iam::123456789012:role/MyRole"
Advantages:
Easier Management: You can centrally manage access by assigning or removing permissions from the role without having to modify each resource.
Scalability: If multiple users or services need the same set of permissions, it's easier to manage by assigning roles rather than specific resource-level permissions.
When to Use:
For multi-user or multi-service environments where permissions are broadly defined.
For complex environments where you want to delegate access to external entities (cross-account access, etc.).
When you need to limit actions based on who or what is trying to perform the action.
Use Case: When you want to limit what resources can be accessed or acted upon.
Common: Resource-based policies are used when you need fine-grained control over specific AWS resources. This ensures that only designated users, roles, or services can access or modify those resources.
Advised: Targeting specific resources is more advisable for high-security environments, or where sensitive data and actions need strict control.
Example:
"Resource": "arn:aws:s3:::my-bucket/my-object.txt"
Advantages:
Granular Control: You can enforce permissions on specific resources, ensuring tighter security.
Increased Security: You can prevent access to anything outside the explicitly defined resource, reducing the attack surface.
When to Use:
When you need to apply specific permissions to individual resources, like a particular S3 bucket, EC2 instance, or Lambda function.
When fine-grained permissions are necessary to ensure only specific actions are allowed on specific resources.
In cases where resources belong to sensitive environments or need to be tightly controlled.
IAM roles are generally more common in large-scale deployments and multi-service environments because they offer flexibility and ease of management.
Resource-based targeting is frequently used for controlling access to specific, high-security or sensitive resources.
Targeting Roles is recommended when you want to manage permissions for who can perform actions (identity-based access control).
Targeting Specific Resources is more advisable when securing specific resources in high-security contexts (resource-based access control).
In many cases, it's beneficial to combine both:
Use roles to manage who can access resources.
Use resource-level permissions to restrict what those roles (or identities) can do on specific resources.
For example, an S3 bucket might have a policy that allows only a specific IAM role to perform actions, and that role has a policy that allows specific users to assume it.
Discussion with ChatGPT about NACLs, Subnets, Security Groups
https://chatgpt.com/c/51ec2d12-d3ad-42e6-b20a-30470c0f442e
(Not a shared link. Have to be logged-in to chat.openai.com)
Types of Database Indexes when using Rails:
https://chatgpt.com/share/1c4a94ef-2f5d-4c77-8f7c-ebded5e6bf3c
Indexes for Dates:
https://chatgpt.com/share/e71c3bd7-3a05-48d6-8064-7dd64fb53672
https://temporal.io/blog/workflow-engine-principles
https://share.transistor.fm/s/65974dd6
Join Jason for another round of “Build Things on Purpose.” This time Jason is joined by Maxim Fateev and Samar Abbas, co-founders of Temporal, to talk about the software and solutions they are developing for orchestrating micro services. Maxim and Samar talk about their joint work in the past on various projects to include the Cadence project, which has laid the foundation for what they are continuing to do at Temporal. Check out this “Build Things” conversation as Maxim and Samar go into the details on the nature of their work at Temporal!
https://orkes.io/blog/why-your-applications-need-durable-execution/
https://materializedview.io/p/durable-execution-justifying-the-bubble
First heard about it in a podcast featuring Temporal's CEO
Deep Learning for Coders with Fastai and PyTorch: AI Applications Without a PhD
An open source framework for providing throwaway, lightweight instances of databases, message brokers, web browsers, or just about anything that can run in a Docker container.
The Coalition for Content Provenance and Authenticity (C2PA) addresses the prevalence of misleading information online through the development of technical standards for certifying the source and history (or provenance) of media content. C2PA is a Joint Development Foundation project, formed through an alliance between Adobe, Arm, Intel, Microsoft and Truepic.
Generate number of sub arrays with a particular sum: E.g. nums = [1,1,1] with sum 2
arr = [1,1,1] SUM =2 #arr = [1,2,2,3,4,5] #SUM = 5 sub_arrays = [] arr = arr.sort arr.each_with_index do |n, index| if n == SUM sub_arrays << [n] next end rest_of_array = arr[(index+1)..-1] temp_arr = [n] rest_of_array.each do |m| temp_arr << m if temp_arr.sum == SUM # We found a sub_array! sub_arrays << temp_arr # There might be duplicates of m, so let us remove m from temp_arr and continue temp_arr = temp_arr[0..temp_arr.length-2] end if temp_arr.sum < SUM # do nothing; we can continue to add more elements end if temp_arr.sum > SUM # discard all elements except n temp_arr = [n] end end end puts sub_arrays.to_s
https://world.hey.com/dhh/you-can-t-get-faster-than-no-build-7a44131c
We're making it using vanilla ES6 with import maps for Hotwire, and vanilla CSS with nesting and variables for styling. All running on a delightfully new simple asset pipeline called Propshaft.
https://chat.openai.com/c/388e1263-46a6-4406-b16d-8094b8232dfb
In essence, whenever you find yourself thinking, "I need a class-level configuration that should have a default, but I also want the flexibility to customize it for certain subclasses or instances,"
class_attribute
is a tool you might consider using.
Join multiple nested associations:
https://gist.github.com/abhionlyone/84dec0aa7a5d30b9e2bc6d7bd2094f20
https://chat.openai.com/c/14a54f06-d8e7-42af-b60e-402d821412be
Adjacency List Model vs Nested Set Model - https://www.youtube.com/watch?v=0G58ot8obFs
https://rohitpaulk.com/articles/redis-3
Solution to Redis project (step 4)