## Internationalization:

### Logical properties
	
Instead of writing `margin-left`, using `margin-inline-start` to refers to the margin on the left side of a content box in a left-to-right language, and the margin on the right side of a content box in a right-to-left language.
		
There are more [logical properties](https://web.dev/learn/css/logical-properties/) that can be

## Internationalization:

### Logical properties
	
Instead of writing `margin-left`, using `margin-inline-start` to refers to the margin on the left side of a content box in a left-to-right language, and the margin on the right side of a content box in a right-to-left language.
		
There are more [logical properties](https://web.dev/learn/css/logical-properties/) that can be explored further at web.dev

tips about internationalization:

When you're designing websites that will be translated into other languages and writing modes, think about these factors:
		 
Some languages, like German, have long words in common usage. Your interface needs to adapt to these words so avoid designing narrow columns. You can also use CSS to introduce hyphens.

Make sure your line-height values can accommodate characters like accents and other diacritics. Lines of text that look fine in English might overlap in a different language.

if you're using a web font, make sure it has a range of characters broad enough to cover the languages you'll be translating into.

Don't create images that have text in them. If you do, you'll have to create separate images for each language. Instead, separate the text and the image, and use CSS to overlay the text on the image.
	
My thoughts on logical properties: it's worth learning and adapting to use logical properties instead of directional properties since it's more resilient to different languages shown on your web page, for example, Arabic and Hebrew read from right to left, and some Japanese typefaces read vertically instead of horizontally.
		
## Typography

### Clamping text
	
You probably don't want your text to shrink and grow to extremes. You can control where the scaling starts and ends using the CSS clamp() function. This “clamps” the scaling to a specific range.
		 
The clamp() function is like the calc() function but it takes three values. The middle value is the same as what you pass to calc(). The opening value specifies the minimum size, in this case, 1rem so as to not go below the user's preferred font size. The closing value specifies the maximum size.
		 
```css
html {
 font-size: clamp(1rem, 0.75rem + 1.5vw, 2rem);
}
```
	
### Font loading

Use the CSS font-display property to tell the browser how to manage the switchover from a system font to a web font. You could choose to show no text at all until the web font is loaded. You could choose to display the system font immediately and then switch over to the web font once it loads. Both strategies have their downsides. If you wait until the web font is downloaded before showing any text, users may find themselves staring at a blank page for a frustratingly long time. If you show the text in a system font first and then switch over to the web font, users may experience a jarring shifting of content on the page.
	
You can mitigate the jarring effect of text shifting around by using size-adjust in your @font-face rule.
		
A good compromise is to wait for a short while before displaying any text. If the web font loads before that time is up, the text is displayed using the web font with no content shifts. If the web font still hasn't loaded after the time is up, the text is displayed using the system font so at least the user can read the content.
		 
Use a font-display value of swap if you still want the web font to replace the system font whenever the web font finally loads.

```css
body {
 font-family: Roboto, sans-serif;
 font-display: swap;
}
```
		
My thoughts on font loading: using font-display: swap to change the font, and combining with size-adjust to mitigate the jarring effect
		
Further [reading](https://web.dev/css-size-adjust/)

## Responsive Image

**CSS properties to achieve a great responsive image:**

```css
img {
 max-inline-size: 100%;
 block-size: auto; // means that the aspect ratio of the images will remain constant.
 aspect-ratio: 2/1; // (optional) If your design calls for an image to have an aspect ratio that's different from the image's real dimensions, use the aspect-ratio property in CSS
 object-fit: cover; // An object-fit value of cover tells the browser to preserve the image's aspect ratio, even if that means cropping the image at the top and bottom.
 object-position: top center; // If the cropping at the top and bottom evenly is an issue, use the object-position CSS property to adjust the focus of the crop. You can make sure the most important image content is still visible.
}
```
	
**Setting width & height on an image tag**

Even if the image is rendered at a different size (because of your max-inline-size: 100% rule), the browser still knows the width to height ratio and can set aside the right amount of space. This will stop your other content from jumping around when the image loads.
	
Use the loading attribute to tell the browser how urgently you want it to load an image. For images below the fold, use a value of lazy. The browser won't load lazy images until the user has scrolled far down enough that the image is about to come into view. If the user never scrolls, the image never loads.

There's also a decoding attribute you can add to `img` elements. You can tell the browser that the image can be decoded asynchronously. The browser can then prioritize processing other content.

```html	
<img
 src="image.png"
 alt="A description of the image."
 width="300"
 height="200"
 loading="lazy"
 decoding="async"
>
```
	
**Use the background-image property in CSS to load presentational images**

less ideal: 

If you embed an image that is purely a visual flourish without any meaningful content, use an empty alt attribute.

You must still include the alt attribute. A missing alt attribute is not the same as an empty alt attribute. An empty alt attribute conveys to a screen reader that this image is presentational.
	
**Image format:**

use WebP, main reason: saving around 25% or more on the image size for the same image quality. 
AVIF has a better compression rate, but has very limited browser support.


	
	
On the other hand, WebP has more than 96% usage on global users, only IE and safari on macOS Catalina oe before doesn't support it.


	
	
## Theming

You'll want to use CSS custom properties to store your color values. It can be useful in places like dark mode. Check the [theming](https://web.dev/learn/design/theming/) page in web.dev for more detailed information
	
## Carousels
	
Best practice on [carousels](https://web.dev/carousel-best-practices/)

medium_webp__format_coverage.png

small_webp__format_coverage.png

thumbnail_webp__format_coverage.png

webp__format_coverage.png

The modern approach on responsive design

I've done on setting up a boilerplate project with 4 statistic analysis tools for React framework(using create-react-app), you can find it out [here](https://github.com/thinkerelwin/boilerplate-of-creat-react-app).

The tools included in the project are:

1. Eslint (mainly used to check code errors)
2. Prettier (a code formatter with little configuration rules )
3. Stylelint (checking on style...

I've done on setting up a boilerplate project with 4 statistic analysis tools for React framework(using create-react-app), you can find it out [here](https://github.com/thinkerelwin/boilerplate-of-creat-react-app).

In case you wonder why we need these tools, you can imagine these tools are kind of like a person checking your code to see if there's an error every time you are viewing a file, saving a file, and even when you're submitting your codes, and they are totally free, it just needs some setup.

The tools included in the project are:

1. **Eslint** (mainly used to check code errors)
2. **Prettier** (a code formatter with little configuration rules )
3. **Stylelint** (checking on style issues)
4. **Typescript** (type check, really helpful for a project with more than a few developers)

These four are pretty popular right now, the one that might need an explanation is Stylelint, it's kind of like an Eslint working on Styles files, such as CSS, and SCSS. it can spot errors such as 'duplicated selectors and overridden properties, but also enforce specific code styles on your project. with these four statistic analysis tools combined together, we can format and check ```js, ts, jsx, tsx, css, scss, html, md, json``` files, those you'll encounter doing Front-end development.

Beyond that, it utilizes the ```lint-stage, husky``` library to automatically do static analysis with the tools mentioned above before one can submit their commit.

**Integrate these tools in your VSCode(optional)**

add this snippet to your setting.json in your VSCode to enable code check on viewing and saving files:
```json
{
  ...
  "[jsonc]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "editor.formatOnSave": true,
  "[javascript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[javascriptreact]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[typescriptreact]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[json]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[scss]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[css]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "stylelint.validate": ["css", "less", "postcss", "scss"],
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true,
    "source.fixAll.stylelint": true
  }
  ...
}
```

p.s. the check using Typescript will check all files in the project instead of those changes files in your commit. Because when making changes in one file might violate a type check on other files if the same types are being used on other files too.

medium_type-check-tools.jpg

small_type-check-tools.jpg

thumbnail_type-check-tools.jpg

type-check-tools.jpg

The modern static analysis tools for Javascript

The complete list of the description and prevention of each security vulnerability can be found [here](https://owasp.org/Top10/A00_2021_Introduction/).

Now let's look at each one more closely:

### **A01:Broken Access Control**

Common ones include the following:

CWE-200: Exposure of Sensitive Information to an Unauthorized Actor  
CWE-201: Insertion of Sensitive Information Into Sent Data


The complete list of the description and prevention of each security vulnerability can be found [here](https://owasp.org/Top10/A00_2021_Introduction/).

Now let's look at each one more closely:

### **A01:Broken Access Control**

Common ones include the following:

CWE-200: Exposure of Sensitive Information to an Unauthorized Actor  
CWE-201: Insertion of Sensitive Information Into Sent Data  
CWE-352: Cross-Site Request Forgery(CSRF)

Description:

All descriptions are applied to the front end **except** this one:

CORS misconfiguration allows API access from unauthorized/untrusted origins.

Prevention:

Implement access control mechanisms once and re-use them throughout the application, including minimizing Cross-Origin Resource Sharing (CORS) usage.
 
Model access controls should enforce record ownership rather than accepting that the user can create, read, update, or delete any record.
 
Stateful session identifiers should be invalidated on the server after logout. Stateless JWT tokens should rather be short-lived so that the window of opportunity for an attacker is minimized. For longer-lived JWTs it's highly recommended to follow the OAuth standards to revoke access.


### **A02:Cryptographic Failures**

Common ones include the following:

CWE-259: Use of Hard-coded Password  
CWE-327: Broken or Risky Crypto Algorithm  
CWE-331 Insufficient Entropy

Description:

all applied to the front-end.

Prevention:

All methods are applied to the front end except this one:

Do not use legacy protocols such as FTP and SMTP for transporting sensitive data.

Example of Sensitive Data Exposure;


### **A03:Injection**

Common ones include the following:

CWE-79: Cross-site Scripting(CSS)  
CWE-89: SQL Injection  
CWE-73: External Control of File Name or Path

Description:

User-supplied data is not validated, filtered, or sanitized by the application.
 
Dynamic queries or non-parameterized calls without context-aware escaping are used directly in the interpreter.

Prevention:

The preferred option is to use a safe API, which avoids using the interpreter entirely.

ex: using innerText instead of innerHtml(DOM)

don't trust the user input, always validate the user input if the data will be processed by the interpreter.

Validate the searchParams in the URL

### **A04:Insecure Design**

Common ones include the following:

CWE-209: Generation of Error Message Containing Sensitive Information  
CWE-256: Unprotected Storage of Credentials  
CWE-501: Trust Boundary Violation  
CWE-522: Insufficiently Protected Credentials

Description:

An insecure design cannot be fixed by a perfect implementation as by definition.

One of the factors that contribute to insecure design is the lack of business risk profiling inherent in the software or system being developed, and thus the failure to determine what level of security design is required.

Prevention:

All are related.

Example Attack Scenarios

Scenario #1: A credential recovery workflow might include “questions and answers,” which is prohibited by NIST 800-63b, the OWASP ASVS, and the OWASP Top 10. Questions and answers cannot be trusted as evidence of identity as more than one person can know the answers, which is why they are prohibited. Such code should be removed and replaced with a more secure design.

p.s. questions and answers for password reset can still be seen on some websites nowadays.

### **A05:Security Misconfiguration**

Common ones include the following:

CWE-16 Configuration  
CWE-611 Improper Restriction of XML External Entity Reference.

Description:

Error handling reveals stack traces or other overly informative error messages to users.

For upgraded systems, the latest security features are disabled or not configured securely.

The security settings in the application servers, application frameworks (e.g., Struts, Spring, ASP.NET), libraries, databases, etc., are not set to secure values.

The software is out of date or vulnerable.

Prevention:

All methods are applied to the front end except this one:

Sending security directives to clients, e.g., Security Headers.

### **A06:Vulnerable and Outdated Components**

Common ones include the following:

CWE-1104: Use of Unmaintained Third-Party Components

Description:

All points are applied

Prevention:

All points are applied

### **A07:Identification and Authentication Failures**

Common ones include the following:

CWE-297: Improper Validation of Certificate with Host Mismatch  
CWE-287: Improper Authentication  
CWE-384: Session Fixation.

Description:

All points are applied **except** this one:

Permits brute force or other automated attacks.

Prevention:

Where possible, implement multi-factor authentication to prevent automated credential stuffing, brute force, and stolen credential reuse attacks

Implement weak password checks, such as testing new or changed passwords against the top 10,000 worst passwords list

Align password length, complexity, and rotation policies with the National Institute of Standards and Technology (NIST) 800-63b's guidelines in section 5.1.1 for Memorized Secrets or other modern, evidence-based password policies.

### **A08:Software and Data Integrity Failures**

Common ones include the following:

CWE-829: Inclusion of Functionality from Untrusted Control Sphere  
CWE-494: Download of Code Without Integrity Check  
CWE-502: Deserialization of Untrusted Data.

Description:

It's one paragraph and applies to the front-end as well.

Prevention:

All applied to the front end **except** the following two:

Ensure that your CI/CD pipeline has proper segregation, configuration, and access control to ensure the integrity of the code flowing through the build and deploy processes.
 
Ensure that unsigned or unencrypted serialized data is not sent to untrusted clients without some form of integrity check or digital signature to detect tampering or replay of the serialized data

### **A09:Security Logging and Monitoring Failures**

Common ones include the following:

CWE-778 Insufficient Logging  
CWE-117 Improper Output Neutralization for Logs  
CWE-223 Omission of Security-relevant Information  
CWE-532 Insertion of Sensitive Information into Log File

This doesn't apply to the front-end.

### **A10:Server-Side Request Forgery (SSRF)**

It's a new category, so it doesn't have Common Weakness Enumerations(CWE) yet

As the title suggests, this is not related to client-side


medium_cyber-security.jpg

small_cyber-security.jpg

thumbnail_cyber-security.jpg

cyber-security.jpg

OWASP Top 10 security risk on 2021 for front-end

I have been using Typescript for some time, but still feels something absent on learning it, then I notice that beyond the basic syntax, I'm not familiar with the design pattern of Typescript. Sure, It's not actually a language, but since it's so widely used in my work, I feel that I should invest more time in learning the advanced usage of it.

I'll start from the definition...

I have been using Typescript for some time, but still feels something absent on learning it, then I notice that beyond the basic syntax, I'm not familiar with the design pattern of Typescript. Sure, It's not actually a language, but since it's so widely used in my work, I feel that I should invest more time in learning the advanced usage of it.

I'll start from the definition of some less common features:

**Enums:**

1. Used for values that are closely related.
2. They are known at compile time.

**Tuple:**

Rarely used, since they don't have keys to describe what value it holds. Can be used to describe data type from a CSV file(each row contains a different data type).

**Abstract:**

Used to delay a method implementation at a later stage(ex: at a child class)

**Generic:**

The constraint of it and how to fix it:

When you are using a property or a method that belongs to a specific data type, you'll see an error.

Fix: use extends to add the desired method or props to the generic type. check the code below for example:

```ts
function printHousesOrCars<T extends Printable>(arr: T[]): void {
 for (let i = 0; i < arr.length; i++) {
 arr[i].print();
 }
}
```

**Utility Type**

Omit, Pick is useful to interfaces that contain more than a few properties, for example, check this snippet from the official doc:

```ts
interface Todo {
 title: string;
 description: string;
 completed: boolean;
 createdAt: number;
}
 
type TodoPreview = Omit<Todo, "description">;
 
const todo: TodoPreview = {
 title: "Clean room",
 completed: false,
 createdAt: 1615544252770,
};
 
type TodoInfo = Omit<Todo, "completed" | "createdAt">;
 
const todoInfo: TodoInfo = {
 title: "Pick up kids",
 description: "Kindergarten closes at 5pm",
};
```

There are other utility types that can be used too, check [the official doc here](https://www.typescriptlang.org/docs/handbook/utility-types.html)

medium_learning-to-code.jpg

small_learning-to-code.jpg

thumbnail_learning-to-code.jpg

learning-to-code.jpg

Notes on using Typescript: with design pattern

It's useful when looking for a subset with certain quality  in a stream, like Kth largest Element or Kth smallest Element. 

The keypoint is understand how to get the parent index when bubble up, and left child index and right child index when trickle down, below is the implementation with comments:

It's useful when looking for a subset with certain quality in a stream, like Kth largest Element or Kth smallest Element. 

The keypoint is understand how to get the parent index when bubble up, and left child index and right child index when trickle down, below is the implementation with comments:
```js
class minHeap {
 constructor(capacity) {
 this.size = capacity;
 this.minHeap = []
 }
 
 add(val) {
 if (this.minHeap.length < this.size) {
 this.minHeap.push(val)
 // it's possible that the new element can be smaller than 
 // some element in this heap, so call in bubbleUp function
 this.bubbleUp(this.minHeap.length - 1)
 // if the new element is greater than the smallest element 
 // in a MinHeap, it will replace one of the element in the MinHeap
 } else if (val > this.minHeap[0]) {
 this.minHeap[0] = val
 this.trickleDown(0)
 }
 }
 
 peak() {
 return this.minHeap[0]
 }
 
 bubbleUp(index) {
 const parentIndex = Math.floor((index - 1) / 2)
 
 let max = index
 // if this.minHeap[parentIndex] > this.minHeap[max], than the element 
 // been inserted should bubble up
 if (parentIndex >= 0 && this.minHeap[parentIndex] > this.minHeap[max]) {
 max = parentIndex
 }
 
 if (max !== index) {
 this.swap(max, index)
 this.bubbleUp(max)
 }
 }
 
 trickleDown(index) {
 let leftChildIndex = index * 2 + 1
 let rightChildIndex = index * 2 + 2
 
 let min = index
 // if element at min index is bigger than element at leftChildIndex 
 // or rightChild Index, it should goes down the heap
 if (leftChildIndex < this.minHeap.length && this.minHeap[leftChildIndex] < this.minHeap[min]) {
 min = leftChildIndex
 }
 
 if (rightChildIndex < this.minHeap.length && this.minHeap[rightChildIndex] < this.minHeap[min]) {
 min = rightChildIndex
 }
 
 if (min !== index) {
 this.swap(min, index)
 this.trickleDown(min)
 }
 }
 
 swap(a, b) {
 [this.minHeap[a], this.minHeap[b]] = [this.minHeap[b], this.minHeap[a]]
 }
}
```
When finding Kth largest Element in a stream, it can be used like this:
```js
var KthLargest = function(k, nums) {
 this.heap = new minHeap(k)
 
 for (let num of nums) {
 this.heap.add(num)
 }
};

KthLargest.prototype.add = function(val) {
 this.heap.add(val)
 return this.heap.peak()
};
```

It's lots of code, but once I grasp the core of a MinHeap, it's not too hard to write it.

medium_data structure.jpg

small_data structure.jpg

thumbnail_data structure.jpg

data structure.jpg

Implement a MinHeap in Javascript

When starting my career as a software engineer, I felt overwhelmed by the algorithms, I didn't even know what is Big O.  Knowing it will take lots of time to learn it, I try to avoid it.

After spending a year to get myself familiar with Javascript, I know that it's the foundation of computer science, not specific to any programming language, which means once I learned the concept, I don't have to

When starting my career as a software engineer, I felt overwhelmed by the algorithms, I didn't even know what is Big O.  Knowing it will take lots of time to learn it, I try to avoid it.

But after spending a year to get myself familiar with Javascript, I know it's unavoidable to learn algorithms since it's the foundation of computer science, not specific to any programming language, which means once I learned the concept, I don't have to start over again when switching to a programming language in the future, which is very likely since I decide to code for my entire life.

Another good reason to learn algorithms is it helps me to identify the pattern of the problem, so I can choose the correct method to translate my pseudocode to actual algorithms that the computer can understand.

It's what a good software engineer should know and be familiar with. so slowly, when I have time, I practice the problems found on **Leetcode**, starting from the easy ones, after trying for about the first ten problems, the frustration that I accumulated is almost unbearable, an easy problem can take more than one hour, or even two hours to get a working solution.

It must have a better way to approach it, I told myself at that time, then, the next day, I start taking the algorithm class found on Udemy. It's compact, contain the essential knowledge to get myself familiar with data structures and common sorting algorithms, with that knowledge in my head, once again, I try to approach problems found on **Leetcode**, although it still takes lots of time to go through the first 130 questions on Leetcode, the frustration is not that high as before, it's a big step to me.

Then, another year passed, I think it's time to prepare myself for a senior role, so again, I revisit **Leetcode**, looking for problems I haven't seen before, or unable to write a solution on the first try.
When facing those new ones, I notice there are more patterns that I haven't encountered before. There must be some strategy for approaching these algorithms problems, I told myself.

When I post my frustration on these hard leetcode problems, a friend whispers to me, that he has been on the same road too, and sharing a very thorough curriculum focus on algorithms, super expensive, super extensive. After around two weeks into this class, I believe this is what I'm looking for, a great material for those who want to go deeper and in a systematic way, this is my fast-track into a strong foundation of algorithms.

Thanks, Hank!

medium_chess-play.jpg

small_chess-play.jpg

thumbnail_chess-play.jpg

chess-play.jpg

The fast track on learning the coding algorithms

For example:

You have a `useEffect` that watches the `event_id` and the `date_range`, they are separate states from `useState`.

when one of them changes, it will re-query a list of events. 

The user can change the `event_id` from a list of events, the user can also change the `date_range` by using the date picker.

Somehow, you got a new request that when an active `event_id` is changed, the...

Image in the following scenario:

You have a `useEffect` that watches the `event_id` and the `date_range`, they are separate states from `useState`.

when one of them changes, it will re-query a list of events. The user can change the `event_id` from a list of events, the user can also change the `date_range` by using the date picker.

Somehow, you got a new request that when an active `event_id` is changed, the date will reset to the default date instead of stay as it is.

How would you change your code, so when a user selects a new event, it will only trigger the API call once?

I got this question from a junior college last week, it's not the first I have been asked about this question, nor will it be the last time, I believe, it's not uncommon to meet such a scenario when coding a reactive web app.

For me, there are two options I can choose, each has its's trade-off:

1.  Group the action to set both states in a function, this is easier to do, but if they are called multiple times on different places, it will look ugly, this is when I will choose option 2 (beware(until we reach **React 18**, don't put an async action between setting the state, otherwise it will cause an extra render.)

2.  Group the `event_id` and `date_range` together into a `useReducer`, this makes sense since they are closely related to each other, and you can easy to update both state at a single event, it will look cleaner when reading, but it does require extra effort and space to transfer them to a `useReducer`,

medium_long exposure.jpg

small_long exposure.jpg

thumbnail_long exposure.jpg

long exposure.jpg

Avoid triggering multiple times on a useEffect when changing multiple state

### Sorting and Searching

Thanks for [https://www.bigocheatsheet.com/](link) for building this compact cheat sheet...

### Sorting and Searching

Thanks for [https://www.bigocheatsheet.com/](link) for building this compact cheat sheet:

![sorting_algorithms-bigO.png](https://res.cloudinary.com/myblog/image/upload/v1624798750/blog-strapi/sorting_algorithms_big_O_48cdc708eb.png)

- **Merge sort**: stable, used extensively. (Divide & Conquer)
- **Quick sort**: not stable, commonly used, beware, if the pivot is chosen poorly, it will hit O(n2). (Divide & Conquer)
- **Heap sort**: not stable.
- **Insertion sort**: used it if the array its self is almost sorted. (Decrease and Conquer)
- **Counting sort**: used for narrow range on the array, since it is run on O(n), will be faster than comparison sorting algorithms.
- **Radix sort**: for integers, it's O(n) on time complexity too.
- Selection Sort: Locate the smallest item, and put it in the first place, repeat this process n times for an array that contains n items. (Brute Force)
- Bubble Sort: Scan the array from right to left, swap the two elements in comparison if the order is not correct, bubble up the minimum to the left. (Brute Force)


### notes:

- The two that are commonly used are **Quicksort** and **Mergesort**, depending on the situation, **Bubble Sort** and **Insertion Sort** maybe be used too.
- Non-comparison sorting algorithms can go beyond the limit on time complexity O(n log(n)), for example: **Bucket Sort** and **Radix Sort**
- The algorithm of ```quickSort```: [can be seen here](https://leetcode.com/problems/top-k-frequent-elements/submissions/)
- The algorithm of ```quickSelect```:  [can be implemented here](https://leetcode.com/problems/k-closest-points-to-origin/)
- The implementation of ```minHeap```: with a little tweak, can be a maxHeap too. [link](https://leetcode.com/problems/kth-largest-element-in-a-stream/submissions/)

I think that's the end of this series, for now.

I might add more tips in the future as I progress through more and more Technical Interview questions.


medium_the-fundamental-of-coding-interview-question.jpg

small_the-fundamental-of-coding-interview-question.jpg

thumbnail_the-fundamental-of-coding-interview-question.jpg

the-fundamental-of-coding-interview-question.jpg

The Fundamental Of Coding Interview Question part 5 (Javascript)

### System Design and Scalability

this section is more related to the back-end than the front-end, but it's good to know from a broader view:

- **Communication**: it's more important in the system design than dealing with a specific coding algorithm question. because most of the time, a lot of details won't be covered in the problem description, so the candidate should ...



### System Design and Scalability

this section is more related to the back-end than the front-end, but it's good to know from a broader view:

- **Communication**: it's more important in the system design than dealing with a specific coding algorithm question. because most of the time, a lot of details won't be covered in the problem description, so the candidate should communicate with the interviewer to avoid unnecessary assumptions.
- **Start from a broad view**: otherwise it's easy to miss important tips in the description.
- **List your assumption or state them**:  this will allow the interviewer to correct me if the candidate gets it wrong.
- **Implementation**:  all the talking but not being able to actually implement it will hardly persuade your interviewer.

#### Steps about implementation:

1. Make sure I understand the question.
2. Develop a solution without the limitation of the question to get the general guideline for my solution.
3. Now, add the limitation back, how will you improve it to fit the question? (limitation might be something like limited memory, time complexity, or space complexity.)

#### Keys Concepts:

- Scaling(Horizontal, Vertical)
- Load Balancer
- Caching
- Asynchronous Processing & Queues
- Database Partitioning(Sharding)
- Database Denormalization(for relational Database)
- Networking Metrics(Bandwidth, Latency, Throughput)
- MapReduce(a combination of Map step with Reduce step, used when processing huge amounts of data)

#### Other topics to be aware of:
- Failures
- Availability and Reliability
- Read-heavy or Write-heavy
- Security


The Fundamental Of Coding Interview Question part 4 (Javascript)

### Recusrion and Dynamic Programming(DP)

#### Ways to approach:

- Bottom-up: Starting from the simplest case, then build a solution that on top of the previous one.
- Top-Down: The reverse of Bottom-up, less intuitive, but sometimes useful.
- Half-Half: They are usually seen on the bitwise operation and binary tree operation.


### DP & memoization:

- Using recursion alone sometimes is...

### Recusrion and Dynamic Programming(DP)

#### Ways to approach:

- Bottom-up: Starting from the simplest case, then build a solution that on top of the previous one.
- Top-Down: The reverse of Bottom-up, less intuitive, but sometimes useful.
- Half-Half: They are usually seen on the bitwise operation and binary tree operation.

DP & memoization:

- Using recursion alone sometimes is not efficient enough, need to add Memoization to avoid doing repeat calculation.
- For recursion to work, a return on the base case is needed, so is what should be returned, is it the recursive function its self, the counter, or the result array?
- Find the pattern of recursion is the most important one.
- using an algorithm in a recursive way takes a lot of space, but doing the same algorithm in an iterative way is not easy sometimes, it's all about the trade-off.
- when naming variables on the matrix, put *y* at first, *x* at second, like this: matrix[y][x]

The Fundamental Of Coding Interview Question part 3 (Javascript)

The complete list of the description and prevention of each security vulnerability can be found <a href="https://owasp.org/Top10/A00_2021_Introduction/">here</a>.
Now let's look at each one more closely:
<h3>A01:Broken Access Control</h3>
Common ones include the following:
CWE-200: Exposure of Sensitive Information to an Unauthorized Actor 
CWE-201: Insertion of Sensitive Information Into Sent Data

The complete list of the description and prevention of each security vulnerability can be found <a href="https://owasp.org/Top10/A00_2021_Introduction/">here</a>.
Now let's look at each one more closely:
<h3>A01:Broken Access Control</h3>
Common ones include the following:
CWE-200: Exposure of Sensitive Information to an Unauthorized Actor 
CWE-201: Insertion of Sensitive Information Into Sent Data 
CWE-352: Cross-Site Request Forgery(CSRF)
Description:
All descriptions are applied to the front end except this one:
CORS misconfiguration allows API access from unauthorized/untrusted origins.
Prevention:
Implement access control mechanisms once and re-use them throughout the application, including minimizing Cross-Origin Resource Sharing (CORS) usage.
Model access controls should enforce record ownership rather than accepting that the user can create, read, update, or delete any record.
Stateful session identifiers should be invalidated on the server after logout. Stateless JWT tokens should rather be short-lived so that the window of opportunity for an attacker is minimized. For longer-lived JWTs it's highly recommended to follow the OAuth standards to revoke access.
<h3>A02:Cryptographic Failures</h3>
Common ones include the following:
CWE-259: Use of Hard-coded Password 
CWE-327: Broken or Risky Crypto Algorithm 
CWE-331 Insufficient Entropy
Description:
all applied to the front-end.
Prevention:
All methods are applied to the front end except this one:
Do not use legacy protocols such as FTP and SMTP for transporting sensitive data.
Example of Sensitive Data Exposure;
<h3>A03:Injection</h3>
Common ones include the following:
CWE-79: Cross-site Scripting(CSS) 
CWE-89: SQL Injection 
CWE-73: External Control of File Name or Path
Description:
User-supplied data is not validated, filtered, or sanitized by the application.
Dynamic queries or non-parameterized calls without context-aware escaping are used directly in the interpreter.
Prevention:
The preferred option is to use a safe API, which avoids using the interpreter entirely.
ex: using innerText instead of innerHtml(DOM)
don't trust the user input, always validate the user input if the data will be processed by the interpreter.
Validate the searchParams in the URL
<h3>A04:Insecure Design</h3>
Common ones include the following:
CWE-209: Generation of Error Message Containing Sensitive Information 
CWE-256: Unprotected Storage of Credentials 
CWE-501: Trust Boundary Violation 
CWE-522: Insufficiently Protected Credentials
Description:
An insecure design cannot be fixed by a perfect implementation as by definition.
One of the factors that contribute to insecure design is the lack of business risk profiling inherent in the software or system being developed, and thus the failure to determine what level of security design is required.
Prevention:
All are related.
Example Attack Scenarios
Scenario #1: A credential recovery workflow might include “questions and answers,” which is prohibited by NIST 800-63b, the OWASP ASVS, and the OWASP Top 10. Questions and answers cannot be trusted as evidence of identity as more than one person can know the answers, which is why they are prohibited. Such code should be removed and replaced with a more secure design.
p.s. questions and answers for password reset can still be seen on some websites nowadays.
<h3>A05:Security Misconfiguration</h3>
Common ones include the following:
CWE-16 Configuration 
CWE-611 Improper Restriction of XML External Entity Reference.
Description:
Error handling reveals stack traces or other overly informative error messages to users.
For upgraded systems, the latest security features are disabled or not configured securely.
The security settings in the application servers, application frameworks (e.g., Struts, Spring, ASP.NET), libraries, databases, etc., are not set to secure values.
The software is out of date or vulnerable.
Prevention:
All methods are applied to the front end except this one:
Sending security directives to clients, e.g., Security Headers.
<h3>A06:Vulnerable and Outdated Components</h3>
Common ones include the following:
CWE-1104: Use of Unmaintained Third-Party Components
Description:
All points are applied
Prevention:
All points are applied
<h3>A07:Identification and Authentication Failures</h3>
Common ones include the following:
CWE-297: Improper Validation of Certificate with Host Mismatch 
CWE-287: Improper Authentication 
CWE-384: Session Fixation.
Description:
All points are applied except this one:
Permits brute force or other automated attacks.
Prevention:
Where possible, implement multi-factor authentication to prevent automated credential stuffing, brute force, and stolen credential reuse attacks
Implement weak password checks, such as testing new or changed passwords against the top 10,000 worst passwords list
Align password length, complexity, and rotation policies with the National Institute of Standards and Technology (NIST) 800-63b's guidelines in section 5.1.1 for Memorized Secrets or other modern, evidence-based password policies.
<h3>A08:Software and Data Integrity Failures</h3>
Common ones include the following:
CWE-829: Inclusion of Functionality from Untrusted Control Sphere 
CWE-494: Download of Code Without Integrity Check 
CWE-502: Deserialization of Untrusted Data.
Description:
It's one paragraph and applies to the front-end as well.
Prevention:
All applied to the front end except the following two:
Ensure that your CI/CD pipeline has proper segregation, configuration, and access control to ensure the integrity of the code flowing through the build and deploy processes.
Ensure that unsigned or unencrypted serialized data is not sent to untrusted clients without some form of integrity check or digital signature to detect tampering or replay of the serialized data
<h3>A09:Security Logging and Monitoring Failures</h3>
Common ones include the following:
CWE-778 Insufficient Logging 
CWE-117 Improper Output Neutralization for Logs 
CWE-223 Omission of Security-relevant Information 
CWE-532 Insertion of Sensitive Information into Log File
This doesn't apply to the front-end.
<h3>A10:Server-Side Request Forgery (SSRF)</h3>
It's a new category, so it doesn't have Common Weakness Enumerations(CWE) yet
As the title suggests, this is not related to client-side

Month: May 2022

A01:Broken Access Control