Friday, June 20, 2025
Friday, February 28, 2025
React - points to discuss
React Crash Course - React, Hooks, Redux, Sagas, React Router, Antd
Modules:
0) Introduction to React - What is React?
I) ES6 features to practice
II) React - JSX, Functional Components & React Hooks
III) React Router
IV) Redux
V) Ajax & Redux - Redux Middleware - Sagas
VI) Styled Components - CSS in JS
VII) React Component Library - Antd
VIII) Redux Forms
IX) Project 1: Shop - Products page with Pagination & Search functionality
X) Project 2: Login page
XI) Conclusion
0) Introduction:
i) https://twitter.com/sarah_bean/status/1303007613693521921?s=21
Above tweet shows that a lot of people still consider React to be 'unnecessarily complicated'.
There are people who point out that React has a learning curve and once we learn it, we'll start to like it and will see its benefits.
Anyone who is new to React, if they hear that answer will think - "Oh, that means React is definitely complicated"
If React is indeed complicated, then why are so many developers & teams adopting it?
The answer is - React will help a team to get its work done quickly and with high quality
The key words above are - quickly & high quality.
How is the above possible if React is complicated?
And the answer to that IMHO is:
- Component Libraries like Antd and
- State management libraries like Redux & Mobx
-- both of the above provide excellent developer-experience to anyone working with them
-- vast number of Antd components with high-customizability
-- excellent architecture of Redux and its simplicity and its excellent Developer Tools
- Promise of React Native
-- knowledge of React & Redux can be carried over to do Mobile Development using React Native
All of the above benefits are worth the initial learning curve that is demanded by React.
ii) Backend Web Application already available for this course
A React application needs a Web Server to interact with.
We will be using http://sp-react-course/ as an API.
This API has been specifically built for this course and will handle the requests.
This is so that you do not have to setup anything related to the backend/server and focus only on React.
All you have to do is - go to http://sp-react-course/get-token and generate a token
and then use that token when passing API requests.
The goal of this course is to stay laser-focused on learning React in a way that you would use in the real world.
I) ES6 features to practice:
There are a few ES6 concepts that are used heavily when writing React code.
Practicing them before we start writing React code is a pre-requisite IMHO.
Several things in React that feel complicated in the beginning actually turn out to be ES6 features in Javascript that one is not aware of.
We have to respect Javascript as a full-fledged language and learn its concepts if we are to work with it in React/Angular/Vue/Svelte etc.
0) JSX
https://stackoverflow.com/questions/6003819/what-is-the-difference-between-properties-and-attributes-in-html
1) Arrow Functions
Quirks in Arrow Functions when it comes to Brackets and Single Arguments
2) ES Modules
3) Destructuring
Array Destructuring
Object Destructuring
- Both of these are especially needed when writing Redux code
4) Function Generators
- Needed when writing Redux Sagas
5) Template Literals
- String interpolation
6) Tagged Template Literals
- required for Styled Components
7) Returning Functions (Not a ES6 feature)
Functions in Javascript can be passed as arguments to other functions.
Similarly, a function can return another function as its return value.
- Needed with Redux Thunks
8) Functions can contain other functions (Not a ES6 feature)
- Needed to understand Functional Components
- i.e. that a Functional Component is a single function that can contain other functions within it
9) let, const, var
- we usually use const
- rarely use 'let' (especially if we are using Redux where we create new objects/arrays instead of mutating existing objects/arrays)
- 'var' is almost not used anymore
II) React - JSX, Functional Components & React Hooks
i) we will not cover Class Components
- this is a deliberate choice to avoid trying to learn too many things at once
- Class Components can be easily picked up later
- Functional Components + React Hooks will be sufficient for a majority, if not all of our needs.
ii) Thinking in React
- what is 'state' in React?
- specify UI code taking 'state' as an input
iii) JSX
- quirks in JSX
iv) Functional Components
v) React Hooks
- quirks in React Hooks
v) Common patterns of writing React code
- destructuring state at the top before using them within the ui code
- using && as an IF condition to conditionally render ui elements
- use of 'handle' as a prefix to name functions for Button Clicks etc
e.g. 'handleClick'
V) Redux Middleware - Sagas
- we will not cover Redux Thunks
- this is a deliberate choice to avoid trying to learn too many things at once
- Sagas are more powerful and easier to understand IMHO
VII) React Component Library - Antd
- using a library like Antd allows developers to finish their work quickly
- UI/UX quality is high by default
- allows designers to design using a set of building blocks rather than imagining everything from scratch
Saturday, November 16, 2024
Code with Andrea - Flutter Courses
https://codewithandrea.com/courses/
Topics to explore when learning Flutter:
- Riverpod
- Clean Architecture
Saturday, October 26, 2024
Tuesday, October 15, 2024
Sunday, September 22, 2024
Monday, September 9, 2024
AWS - Access Key ID vs Secret Access Key
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 - Security Token Service (STS)
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:
Key Features of 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.
Example Use Cases:
- Delegating Access: You have a central administrative account, and you want to allow users from other AWS accounts to access your account’s resources. They can assume a role that you define in your account to temporarily gain the necessary permissions.
- Third-Party Access: You can give third-party vendors temporary access to your resources by letting them assume a role through STS without needing long-term credentials.
- Mobile Apps and IoT Devices: Instead of embedding long-term credentials in mobile or IoT devices, which can be insecure, you use STS to issue temporary credentials, which can be refreshed as needed.
Example of Using STS with AssumeRole:
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.
AWS IAM Identity Policy - "Resource" discussion
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:
1. Targeting an IAM Role (More common for users/roles):
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.
2. Targeting Specific AWS Resources (More common for resources):
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.
Which is More Common?
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.
Which is More Advised?
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).
Best Practice:
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.
Wednesday, August 21, 2024
Tuesday, August 20, 2024
AWS Networking contd. - NACLs, Subnets, Security Groups
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)
Monday, August 19, 2024
Friday, August 9, 2024
Monday, August 5, 2024
AWS Networking - Relationship between Region-VPC-AZ-Subnet-EC2
Amongst the following entities - Region, VPC, AZ, Subnet, EC2, which of these are associated with Routing Tables and NACLs?
Routing Tables and Network Access Control Lists (NACLs) are associated with the following entities in AWS:
1. **VPC (Virtual Private Cloud)**:
- **Routing Tables**: Each VPC has one or more routing tables that control the routing of traffic between the subnets within the VPC and the internet, or other VPCs. These routing tables determine where network traffic from the subnet is directed.
- **NACLs (Network Access Control Lists)**: NACLs are optional layers of security that act as firewalls for controlling traffic into and out of subnets. You can apply NACLs to each subnet within a VPC, and they provide stateless filtering of ingress and egress traffic at the subnet level.
2. **Subnet**:
- While subnets themselves don't directly contain routing tables or NACLs, they are associated with them:
- Each subnet is associated with a routing table from its VPC to manage the flow of traffic out of the subnet.
- NACLs can be applied to subnets to manage access and traffic flow into and out of the subnet.
**Regions** and **Availability Zones (AZs)** do not directly involve routing tables or NACLs, as these are specifically related to network configurations within VPCs. **EC2 Instances** are affected by these configurations but do not themselves contain or directly manage routing tables or NACLs.
What about Security Groups? Which entity or entities are those associated with?
**Security Groups** in AWS are primarily associated with the following entities:
1. **EC2 Instances**:
- Security Groups are used to control inbound and outbound traffic at the instance level. They act as a virtual firewall for EC2 instances to regulate allowable traffic.
2. **VPC (Virtual Private Cloud)**:
- Security Groups are defined at the VPC level and can be associated with any instance in that VPC. While they are created within a VPC, their rules apply to instances they are attached to, not subnets.
Unlike NACLs, which are associated at the subnet level and provide stateless filtering, Security Groups provide stateful filtering and are associated directly with instances, such as EC2 instances, RDS instances, and Elastic Load Balancers within the VPC. This means they remember the state of traffic flows and can automatically allow return traffic without additional rules.
So all network security instruments - Security Groups, Routing Tables, NACLs are defined at the VPC level?
Yes, that's correct! All these network security instruments—Security Groups, Routing Tables, and Network Access Control Lists (NACLs)—are defined at the VPC level in AWS. Here's how each operates within the VPC:
1. **Security Groups**: These are associated with individual instances within the VPC, such as EC2 instances. They control inbound and outbound traffic at the instance level and are stateful, meaning they track the state of network connections.
2. **Routing Tables**: These define the rules for traffic routing within the VPC and between the VPC and other networks. Each subnet in a VPC is associated with a routing table that determines where network traffic is directed.
3. **NACLs (Network Access Control Lists)**: These provide a layer of security that acts as a firewall for controlling traffic into and out of subnets. NACLs are stateless, so they do not keep track of the state of network connections and each packet is processed individually.
All three instruments are configured at the VPC level but apply at different scopes—Security Groups at the instance level, Routing Tables at the subnet level, and NACLs at the subnet level—to provide comprehensive network security and routing management within a VPC.
Thursday, August 1, 2024
Understanding usage of Database Indexes with Rails
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
Sunday, June 23, 2024
Sunday, June 2, 2024
Saturday, June 1, 2024
Workflow Engine Principles
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!
Durable Execution
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
Subscribe to:
Posts (Atom)