DEV Community: JayZho

Understand Async in JS: the core concepts

JayZho — Wed, 12 Oct 2022 05:24:26 +0000

1. Components of JS in the Browser

When people talk about "Javascript" nowadays they are most likely refering to the combination of Javascript + Browser. Strictly speaking, "Javascript" by itself is just a programming language with an interpreter(e.g. Chrome's V8 engine) that understands Javascript's syntax and semantics and converts the JS code you write to some lower level runnable code.

You might have wondered how JS is able to do asynchronous calls while itself being a single-threaded programming language. And the fun fact is, you were right, JS actually cannot. It's the runtime environment provided by browsers like Chrome and Safari that adds this extra async feature to the original JS. Apart from that, JS runtime environment also provides handy objects like DOM and BOM, which lets you interact with the elements in the HTML and the browser respectively.

When you write something like

document.getElementById("myDog").classList.remove("bad-dog")

you're using a feature provided by the JS runtime environment, namely, the DOM to interact with the elements inside HTML.

And when you wanna output the width of the screen and to load the previous URL in the history list, you might do something like

console.log(screen.width)
history.back()

In this case, you're accessing the objects screen and history provided by BOM, which is another feature in the JS runtime environment.

As you can see, it's really the runtime environment provided by a web browser on top of JS that allows us to build amazing things using the language Javascript. Hence, it's essential to have the clear picture in mind that Javascript in modern browsers refers to the combination of Javascript Engine and Javascript Runtime Environment.

Note that it's not only browsers that provide runtime environment for JS, for example, node.js also provides a runtime environment for locally running JS code.

For this blog, we'll only focus on the browser side.

2. The Async Mechanism

As mentioned above, JS is a single-threaded language. Therefore, the async feature is provided by JS rutime environment in the browser. To get a clear picture of this async mechanism, let's first understand the Call Stack.
Say we have this code

fuction a() {
    console.log("a")
}

function b() {
    a()
    console.log("b")
}

b()

The call stack of this chunk of code follows the "First in Last out" principle, meaning that the innermost function finishes first and the outermost function finishes the last:

Now we add in some async task:

function timesUp() {
    console.log("timesUp!")
}

console.log("before async")
setTimeout(timesUp, 1000)
console.log("after async")

When the asychronous code setTimeout() is added, the async function call behaves like a normal sync function which finishes immediately and let the call stack continue.
But from this point on, the browser secretly runs the async code in parallel(in C++ for Chrome) to the synchronous JS code, and when the async task is done, the browser pushes the callback function of this async task to a data structure known as the Event Queue, which follows the "First in First out" principle. And there comes our Event Loop guy, who is constantly checking if the call stack is empty, and if yes it pops the event queue and pushes onto the call stack, then the pushed callback function from the event queue will be executed normally as a synchronous function:

Pushing console.log("before async") to the call stack

Function finishes

Pushing setTimeout() onto the call stack

Async function call finishes immediately and gets run in the background by the browser, while the call stack continues to call console.log("after async")

console.log() finishes, the timer keeps running until 1000 milliseconds has passed

Async task done, its callback function gets pushed:

Event Loop grabs the callback and pushes to the call stack:

The call stack executes as usual:

Note that in the diagrams above, the Web API, Event Queue and Event Loop are all part of the JS runtime environment, meaning that they don't belong to the JS engine but instead are powered by the browser, without which we cannot run async code in JS.

Now that we understand the mechanism behind async events, we can see that the code below doesn't just give "setTimeout" a zero delay for no reason:

setTimeout(() => console.log("call stack empty, I'm from the event queue!"), 0)
console.log("call stack busy")

3. Promises

3.1 The motivation

Just because Promises are normally used in conjunction with async tasks, we shouldn't be tricked into thinking that by wrapping a function into a Promise, we turn it into async.(at least that's what I thought initially)

Promises are simply a syntactic sugar -- something that helps us format our code in a better way, but really it's just another way to specify(especially chain) callback functions.

Say you got an async function "asyncFunc", which takes in two callback functions, one to call on a success, the other one to call on an exception:

function asyncFunc(success_callback, failure_callback);

The way to turn it into a Promise is simply wrapping this "asyncFunc" by another function that also takes 2 callback functions, which are named "resolve" and "reject" by convention, and passing them into "asyncFunc" accordingly:

const promisedAsyncFunc = new Promise(
    (resolve, reject) => {
        asyncFunc(resolve, reject)
    }
)

Now we're able to specify its callbacks by append a .then() instead of nesting them into its arguments:

function successCallback() {
    console.log("yay")
}

function failureCallback() {
    console.log("oh no")
}

//traditional callback passing
asyncFunc(successCallback, failureCallback)

//using Promise
promisedAsyncFunc.then(successCallback, failureCallback)

This might seem redundant at the moment, but imagine you also have further callbacks to pass into your callbacks, what easily turns into a "Callback Hell", something like:

setTimeout(() => {
    setTimeout(() => {
        setTimeout(() => {
            console.log("3 seconds has passed")
        }, 1000)
    }, 1000)
}, 1000)

By wrapping setTimeout() in a Promise, we can specify its callback function by putting it in the .then() function, which can accept another .then() to specify the callback function of this callback function. (but only if the former callback function also returns a Promise):

function promisedSetTimeout(interval) {
    return new Promise((resolve, reject) => {
        setTimeout(resolve, interval)
    })
}

//now a non-recursive way for multiple layers of callbacks
promisedSetTimeout(1000)
.then(() => promisedSetTimeout(1000))
.then(() => promisedSetTimeout(1000))
.then(() => console.log("3 seconds has passed"))

Therefore, the motivation of Promise is clear: we want to flatten the "recursiveness" of the callback hell.

3.2 Returning vs. Passing in

In comparison to returning a Promise in the passed-in function of .then(), we can also return a non-Promise data and still be able to chain it using .then().
See the below example:

function someSyncCode() {
    return new Promise((resolve, reject) => {
        console.log("do task #1")
        resolve()
    })
}

someSyncCode()
    .then(() => {
        console.log("do task #2")
        return "task #3"
    })
    .then((task) => {
        console.log("got " + task) // got task #3
    })

Which works the same as returning a Promise in the first .then() and call resolve("task #3") instead of directly returning that string:

function someSyncCode() {
    return new Promise((resolve, reject) => {
        console.log("do task #1")
        resolve()
    })
}

someSyncCode()
    .then(() => {
        return new Promise((resolve, reject) => {
            console.log("do task #2")
            resolve("task #3")
        })
    })
    .then((task) => {
        console.log("got " + task)
    })

This way to pipeline function calls might feel a bit counter-intuitive, especially if you've been only dealing with normal function pipeling, where a function must directly return something for the next function to use as its input. But that's exactly the power of Promise chaining, which allows us to flatten the "recursiveness" of callbacks.

In short, a .then() always expects a Promise.resolve(output) object from its previous Promise, which then gets unwrapped and output gets fed to this .then()'s passed-in function. And we can return such an object in several ways:
1.Return a new Promise() and call resolve() with data passed in:

Promise.resolve().then(() => {
    return new Promise((resolve, reject) => {
        resolve("data")
    })
})

2.Return explicitly using Promise.resolve("data"):

Promise.resolve().then(() => {
    return Promise.resolve("data")
})

3.Return just the data itself. Then .then() will implicitly wrap "data" with a Promise, hence it's equivalent to returning Promise.resolve("data"):

Promise.resolve().then(() => {
    return "data"
})

Just to clarify, the second example might not feel intuitive since what we did in the first .then() is purely synchronous, making the need for passing the return value into a callback rather than immediately returning it seem unnecessary. The purpose is solely to compare the 2 ways of fulfilling a .then().

So yes, in a practical situation, we would do an async task in the first .then() if we're returning a Promise, something like:

.then(() => {
    return new Promise((resolve, reject) => {
        console.log("do task #2")
        setTimeout(() => resolve("task #3"), 1000)
    })
})

3.3 Multi-layered Promises

The Promise-unwrapping process in .then() is recursive, meaning that no matter how many layers of Promises are wrapped around the innermost data, .then() always unwraps them all until the data itself is revealed. Therefore, the simple example below:

Promise.resolve(0).then((v) => console.log(v)) // 0

has the same effect as this crazy multi-layered Promise example below:

Promise.resolve(
    new Promise((resolve, _) => {
        resolve(new Promise((resolve, _) => {
            resolve(0)
        }))
    })
).then((v) => console.log(v)) // 0

3.4 Microtask Queue

I said that Promises are purely a syntactic sugar, meaning that to the underlying program, chaining callbacks with Promises is the same as directly passing callbacks to functions.

That's not exactly true. Consider the following 2 examples:

Using Promise for passing the callback function "secondTask":

function firstTask() {
    return new Promise((resolve, reject) => {
        console.log("doing the first task")
        resolve("the second task")
    })
}

function secondTask(task) {
    console.log("doing " + task)
}

function thirdTask() {
    console.log("doing the third task")
}

firstTask().then(secondTask)
thirdTask()

Directly passing in "secondTask":

function firstTask(callback) {
    console.log("doing the first task")
    callback("the second task")
}

function secondTask(task) {
    console.log("doing " + task)
}

function thirdTask() {
    console.log("doing the third task")
}

firstTask(secondTask)
thirdTask()

Both examples print "doing the first task" first, but the first example prints "doing the second task" last, while the second example prints "doing the third task" last.

For the second example, the execution stack is straight-forward and the order of messages generated is expected.
We now take a look at the events happened behind the first example.

1.firstTask():

The function call firstTask() gets pushed to the call stack, which returns a Promise, hence the function passed into the Promise constructor

(resolve, reject) => {
  console.log("doing the first task")
  resolve("the second task")
}

gets executed immediately, prints "doing the first task", and resolve the Promise.

2..then(secondTask):

Since the previous Promise is resolved, the callback function secondTask now gets pushed to the Microtask Queue, waiting to be executed. Now we advance to the next line thirdTask(). Note that if there's more .then() following this .then(secondTask), they'll all get skipped and we still continue straight to thirdTask()

3.thirdTask()

We print "doing the third task".
Now the call stack is empty. The function call secondTask() gets pushed to the call stack and executed, printing "doing the second task".

The Microtask Queue, in comparison to the Event Queue(aka Callback Queue), is another queue with priority higher than the event queue. When the JS call stack gets empty, before pushing tasks from the event queue, the event loop first pushes tasks from the microtask queue to the call stack, execute them all, then grab tasks from the event queue if there's any.

Function execution in a Promise generated by .then or .catch or .finally get pushed to the microtask queue.

Below is a good example to show the execution priority of the call stack, the microtask queue and the event queue:

// executed first
console.log("one")

// executed the last
setTimeout(() => console.log("four"), 0)

// thirdly executed
Promise.resolve().then(() => console.log("three"))

// secondly executed
console.log("two")

4. Await & Async

We can turn a function into async by append the keyword "async" the a function definition, but it doesn't really turn it into a non-blocking function, surprisingly.
Consider the example below:

async function heavyComputation() {
    for (let i = 0; i < 1000000000; i++) {}
    console.log("heavy computation done")
}

console.log("before heavy computation")
heavyComputation()
console.log("after heavy computation")

Although we've declared that heavyComputation is async, hoping it won't block the execution of our main thread, we still have to wait for it to finish before we can run console.log("after heavy computation")

The reason is simple enough: all the "async" keyword does is:
#1: Implicitly making the function return a Promise
#2: Allowing the use of await inside the function, which is equivalent to using .then().

To put it simple, the keywords async/await are just syntax alternatives for dealing with Promises. Hence, it's not difficult to understand the behaviour of the above example, and we are able to easily understand that the two examples below are also quivalent:

function heavyComputation() {
    return new Promise((resolve, reject) => {
        for (let i = 0; i < 1000000000; i++) { }
        console.log("heavy computation done")
        resolve("computation result")
    })
}

function getResult(result) {
    console.log("got " + result)
}

heavyComputation().then(getResult)
console.log("main thread running...")

async function heavyComputation() {
    for (let i = 0; i < 1000000000; i++) { }
    console.log("heavy computation done")
    return "computation result"
}

async function getResult() {
    let result = await heavyComputation()
    console.log("got " + result)
}

getResult()
console.log("main thread running...")

If you're thinking that the second one looks a lot cleaner, then that's exactly the point of introducing the async/await keywords: it allows us to work with Promises in a more comfortable fashion.

Working with Git: a practical guide

JayZho — Sat, 01 Oct 2022 10:57:35 +0000

Some basic understandings

You need to well distinguish the concepts of the local repo and the remote repo. There are basically two separate repo. Each developer has their local repo, while the remote repo sitting on github acts like a single globalised repo. The interaction between a local repo and the remote repo is done via commands like git push, git fetch, etc.
Each branch has a HEAD, which is just a pointer to a commit that marks the tip of the branch. A branch is basically just a pointer to a commit and its commit history.

Fetch vs. Pull

To put it simple: git pull = git fetch + git merge
git fetch refreshes the local view of the remote repo to keep it up-to-date with all the newest changes in the remote repo. Notice the phrase "local view of the remote repo", it means that this action only let us know the current status of the remote repo, without changing(merging to) the local repo.
To merge the changes in any of the remote branches into our local branch, do git merge origin/<remote_branch>.

Working with branches

List all branches

To list all local branches and the branch you're on locally: git branch
To list all remote branches: git branch -r

Create a local branch

Create another local branch: git branch <branch_name>
Checkout to a local branch: git checkout <branch_name>
Create and checkout to a local branch: git checkout -b <branch>
Create a branch from another local branch and checkout to it: git checkout -b <new_branch> <from_branch>

Checkout to a remote branch

For git checkout <branch_name>, if there exists a remote branch with , git will

create a local branch with the same name as
checkout to this local branch
make this branch track

The purpose of "making a branch track a remote branch" is that when using implicit commands like git pull, git push or git merge, git knows which remote branch you're refering to. Otherwise it will say something like "no tracking information for the current branch".

To set the remote branch to track, use the command
git branch --set-upstream-to=origin/<remote_branch> <local_branch>

Notice that once this is done, the command git checkout <remote_branch> no longers set the local branch to track the remote branch , instead it stays tracking the remote branch specified in the previous --set-upstream-to command.

Create remote branch from the local branch

Checkout to a branch that you only have locally:
git checkout local1
Assuming that you've commited successfully, run the command:
git push origin local1
This will create a new remote branch named "local1", and push to it. Notice that it does not set the local branch to track the remote branch "local1".

Push to a different remote branch

Say you're in local branch "local1", doing git push origin main will push from local branch "main" to the remote branch "main". (So nothing to do with the branch you're currently in)
If you wanna push from local branch "local1" to a remote branch "remote", you can do git push origin local1:remote.

Integrating different works

The mechanism

Let's say we're on a feature branch and we wanna merge the main branch into this feature branch.
Before merging main into feature, git first determines the 3 commits that are: the base of the two branches, the tip(current commit) of branch "main", the tip(current commit) of branch "feature".

Then git will grab everything new from the newest commit(known as the tip) in branch "main" and chuck it into the tip of branch "feature", making this resultant repo a new commit on top of the previous commit in branch "feature".

If the branch "feature" has no newer commits after the common "base" commit, git simply makes the tip of branch "main" the new merge commit of branch "feature", known as a "fast forwarding" merge commit. And yes, the tip of a branch is nothing but a pointer to a commit, so in this case, git just let the tip of branch "feature" point to the same commit as the tip of "main", making this the "new" merge commit as the result of git merge feature main.

Merge from a branch

If you're already on branch A, then to merge branch B into branch A: git merge <branch_B>
Merge 2 branches explicitly: git merge <receiving_branch> <incoming_branch>
If the merge results in a conflict and you wanna abandon this merge action and roll back to the state before this merge, do git reset --hard HEAD.

Rebase to a branch

Rebase moves all the commits in one branch on top of another branch, making a single-line commit history. This is another technique used in merging different commits, and has advantages over git merge in the sense that it creates a linear branch history instead.

Computer Networking: Intuitive Understanding of the Basics (updating...)

JayZho — Fri, 30 Sep 2022 13:29:24 +0000

The 5-Layer Model

Application layer: Defines the meaning of the message. For example:

should we include the length of the message in bytes?
should we define a set of message types to indicate the purpose of the message? Something like "POST" and "GET" in HTTP
what Transport layer protocol should we choose? Do we care about the reliability a lot? Maybe UDP will do the job(instead of TCP) if missing packets are acceptable?

Transport layer: Defines the mechanism of the communication. Still programmable by software layer. For example, instead of using TCP, we could use the socket library in Python to totally implement our own transport layer protocol and apply it to both the client and server side to make it work.

Network layer: Defines the bigger picture of the network, in comparison to the Link Layer. Each IP address represents the entry to a local network, but the inside of each local area network is a black box for the Network Layer.

SSL (Secure socket layer)

Without any protection, the TCP layer transfers the message in cleartext, which could be dangerous. If you're interested enough, you could actually implement your own "SSL" by building a software that accepts data from the application layer, encoding it and passing it to TCP, on the receiving side simply do the opposite. By inserting this piece of software between the application layer and the TCP layer, you've got your own "SSL".
That's basically how SSL works and what SSL is.
HTTPS is an example that uses SSL to securely transfer data on top of traditional HTTP messages.

Cookie

Just a user profile created and stored on the server side:

Sam visits Amazon.com via his browser for the first time
Amazon's server: "Hey, a new guy is visiting us, let's create a profile for him with the unique identifier 'Sam001'". Then the server passes "cookie: Sam001" together with other response data back to the browser.
The browser: "Oh, I see a cookie header, let's store it onto the computer so every following request to Amazon.com we'll include this cookie, then the server knows it's us and it'll give us customised content!"
Sam continues browsing on Amazon.com, meanwhile the server tracks his activities like what types of products he's interested in, etc, storing this info in his profile on the server side.
A week later, Sam visits Amazon.com on his computer again. The browser sends the request with his cookie to the server.
Amazon's server: "Hey it's Sam001, according to our record in his profile here, he likes gaming a lot, let's send him some ads about our gaming product"
Sam sees gaming product on Amazon's site, wondering how they know him so well and spend his money recklessly.

Web Cache

Just a proxy server normally installed by ISPs on their access points.

A client requests for object "loneliness.com/hotgirl.png"
The browser sends the request to a web cache server instead of the origin server.
The web cache server checks if it has "loneliness.com/hotgirl.png" cached, if so it simply returns it to the browser; otherwise it requests the origin server, gets the object, cache it and also sends it back to the browser.

Note that some content might be outdated if cached for a relatively long time.
In this case, the Last-Modified: Wed, 7 Sep 2011 09:23:24 header in a response HTTP message would be used, and the next time a browser requests for the same object, the web caches server sends a requests to the origin server including If-modified-since: Wed, 7 Sep 2011 09:23:24. If it hasn't been modified on the origin server, it responses with 304 Not Modified with an empty body(saving some bandwidth), and the web cache is now reassured and happliy sends the cached content back to the browser.

DNS (Domain Name Service)

Just a translation from a human-prefered hostname to a computer-prefered IP address.

The process works as follows:

You visit "www.amazon.com.au" on your browser
Before sending the request to Amazon's server, the browser first extract the domain name "www.amazon.com.au" and send it to the DNS software installed in the browser.
The DNS software(client side) sends the domain name over UDP to a DNS server. This DNS server is normally a local DNS server employed by your ISP or institution, sitting in the network somewhere very close to your LAN.
The local DNS server now queries other DNS server(s) and eventually get back the IP address(es) for "www.amazon.com.au" and return it back to the DNS client software on your browser, which further give to back to your browser and your browser can now initiate a TCP connection with the server at that IP address and start the HTTP communication. Remember that if this "domain name" -> "IP" mapping happens to be cached in the local DNS server, it will immediately return it to your browser without the need to further querying other DNS servers.

Note that the process of querying other DNS servers to get the desired IP address is a bit more complicated than this, below is a brief discussion if you're interested:

The process of finding an IP address according to a domain name like "www.amazon.com" is typically an iterative process:

Since it's far too much data for storing all the "complete domain name" -> "IP address(es)" mappings, the DNS servers work in a distributed manner, each responsible for a (part of) certain hierarchy in the domain name. Intuitively, the highest tier domain like .com .net .edu don't have too many variations, hence there are not so many root level DNS servers globally in comparison to the number of DNS servers for lower levels.

When given a domain name to lookup at a local DNS server, the local DNS server first queries a root DNS server for the address of the next level DNS server. In this case, say "somedns.edu" is responsible for looking up all domain names ending with .com, then the root DNS server will pass back "somedns.edu" to the local DNS server, then the local DNS server further queries "somedns.edu", and "somedns.edu" sees that it's "(www).amazon(.com)", grabs an address in its record which is responsible for return the IP address for "*.amazon", and ... you get the idea.

Note that DNS servers could be widely used for load balancing purposes, since popular websites like Amazon has many servers all over the globe, when return the IP address for something like "amazon.com.au", the DNS server probably would have multiple valid IP addresses. What it does is that it rotates the list of all available IP addresses for Amazon servers every time a browser queries it, and since the browser normally would request for the first IP address it's given, this helps balacing the server's work load.

Understanding IP Addresses (Network Layer)

the home router (with NAT) doesn't look like a router to the outside networks, it simply looks like a device with a single interface(IP address) receiving and sending IP datagrams.
NAT is basically mapping (endDeviceIPAddressWithinTheSubnet, endDevicePortNum) to (publicIPAddressOfTheHomeRouter, homeRouterPortNum)
IP address is per interface, rather than per device.

Understanding MAC Addresses (Link Layer)

An Intro to Linux

JayZho — Thu, 29 Sep 2022 06:39:25 +0000

Users and Permissions

For each file, ls <filename> -l displays the permission of the file, something like -rw-rw-r--:

the first char specifies the type of file: d for directory, - for file, l for link.
every following 3 chars specify the permissions to 3 different groups respectively: the file owner, the group and others

The purpose of having these 3 different tiers for each file could be explained easily with an example:
You(t1) and your teammates(t3, t2) are working on a project, and you and your teammates and other random people are all using the same Linux machine in the school lab. You wanna give yourself the permission to read, write and execute the program "project.py", while giving your teammates the rights to read and execute but not modifying it, and you don't even allow others to look at your code.
Then what you could do is to create a group named "team", putting t1, t2 and t3 all under this group, then do chmod 750 project.py

Changing permissions

Only the file owner or the root user is able to change the permissions of a file. Three commands are used:

chmod <xxx> changes the permissions of the file, where each x corresponds to the permissions to the file owner, group and others respectively. Note that the numbers are: r:4, w:2, x:1
chgrp <group_name> <file_name> changes the group. Note that <group_name> must be an existing group in /etc/group
chownchanges the owner of the file. I've never used it though.

$PATH

This variable stores all the paths that are looked up when executing a command. For example, the command ls is stored under /bin/.
To inspect the vairable, do echo $PATH
To add something to the $PATH variable, do PATH="${PATH}:<absolute_path>"

Inspecting files

cat <filename>: print the content of the file
more <filename>: display the file page by page. Press space for next page, press q for quit, press Enter for next line.
head -<n> <filename>: display the first n lines of the file
tail -<n> <filename>: display the last n lines of the file

An Introduction to Database

JayZho — Wed, 28 Sep 2022 11:09:46 +0000

Background knowledge

Database - an organised collection of information, normally stored on a computer electronically.

DBMS - database management system, which is a piece of software that sits between the layer of database and users to allow efficient interaction with the database(querying, updating, deleting, etc), using a programming language such as SQL.

RDBMS - relational database management system, a subset of DBMS that uses tables of rows and columns to organise data.

SQL - a programming language that interacts with relational DBMS such as MySQL and PostgreSQL. Note that the SQL used for one RDBMS is not always protable to any other RDBMS without modification. SQL is actually a combination of 4 types of query language:

Query language: to query
Definition language: to define database schemas
Control language: to do things like user permission management
Manipulation language: like CRUD

NoSQL - Non-relational Database. Rather than tables, NRDBMS store data in a more flexible way, such as key-value pairs, JSON, etc.

What is an embedded/serverless database?

Many database uses the client-server mechanism, meaning that the DBMS is running as a server and it waits for request over the internet/locally from another software to manipulate the database and sends back the data accordingly.
An embedded database on the other hand, is integrated into the software itself, meaning that the software that wants to interact with the database will have the DBMS as part of its program.
A good example would be MySQL vs. sqlite, both of which are relational DBMS by the way.

Keys in RDBMS

Primary key - unique key for each entry
Composite key - multiple fields together to make up a unique key
Foreign key - a key linking to another table which acts as the primary key in that table
Secondary key - any primary key candidates that are not selected as the primary key. For example, for the table "student", "email", "student_id" and "phone_number" could all be the primary key, but when "student_id" is selected as the primary key, "email" and "phone_number" become the secondary keys for this table.
Partial key - one or more fields of a weak entity, which uniquely identifies the weak entity when given its own er entity(strong entity). For example, for "Building"(strong entity) has many "Room"(weak entity), the attribute "room_number" could be used as partial key of "Room", since a building cannot have more than 1 room with the same room number. However, attribute like "area" cannot be partial key, since a building can have multiple rooms of the same area.

From ER diagram to Database schema

Basically there's 2 types of tables created from an ER diagram:

Entity Table. Student, Employee, etc.
Relation Table. Superviser, Employment, etc.

Strong entity

Mapping an entity to an entity table is straight forward.

Weak entity

Create a separate realtion table. Include all weak entity's attributes plus the owner's primary key.

1 to ... relationship

If "A can have 1 or 0 B", "B can have 0 ... many A", then create foreign key on A's table, pointing to table B. Favor the total participation as this guarantees un-nullable field.

Many to many relationship

Create a separate relation table.

SQL Basics

Create/Delete/Alter table

Create a table called "student":

CREATE TABLE student (
    student_id INT PRIMARY KEY,
    name VARCHAR(20) NOT NULL,
    major VARCHAR(28),
    degree_id INT,
    FOREIGN KEY(degree_id) REFERENCES degree(degree_id) ON DELETE CASCADE,
);

CREATE TABLE degree (
    degree_id INT PRIMARY KEY,
    name VARCHAR(30) NOT NULL,
);

Delete the table "student":

DROP TABLE student;

Drop the column "major":

ALTER TABLE student DROP COLUMN major;

Add a column "gpa", which has 3 digits and 2 of them are decimals:

ALTER TABLE student ADD gpa DECIMAL(3, 2)

Insert/Update/Delete

Insert all 3 fields:

INSERT INTO student VALUES(5211225, "Shane", "COMP");

Insert only the specified fields: note that "name" cannot be null by the constraints defined before.

INSERT INTO student(student_id, name) VALUES(5211225, "Shane");

Update all major "Biology" to "Bio":

UPDATE student
SET major = "Bio"
WHERE major = "Biology"

Delete a specific entry:

DELETE FROM student
WHERE student_id = 5;

Querying

SELECT * FROM student
WHERE major = "Chemistry" OR name IN ("Claire", "Ben")
ORDER BY major
LIMIT 10

Redundency & Normalisation

What is redundency in a database schema?

Redundency could be a problem in the sense that it harms the consistency between updates. On the other hand, it could be benificial since it improves the performance by avoiding some "JOIN"s between tables.
The redundency in a database schema and its inconsistency problem has similarity to some bad code: Say you have some code that depends on another computation "plus two", and you use this dependent computation twice in this code:

// first time
a = a + 2;

// some other code ...

// second time
a = a + 2;

Now if you decide to change the "plus two" computation to "times two", you have to change everywhere that you wrote this code. (twice in this case). This can easily lead to inconsistency problem.
A better and fairly obviously practice is to write the "plus two" logic as a separate function and calls this function when needed:

function dependentComputation(x) {
    return x + 2
}
// use the logic
a = dependentComputation(a)

// use it again somewhere else
a = dependentComputation(a)

Later on when you have to change the computation, simply change it in the function and it automatically updates all the places it was refered to.

This is similar to how we get rid of the redundency in a database schema. Say two entries share the same third entity "account" in a table:

order_id | order_total | account_id | account_balance
0001       18.00         8888         20.00
0002       12.00         8888         20.00

When a new order is placed and added to this table, we have to update all other entries related to account "8888", otherwise inconsistent account balance would occur:

order_id | order_total | account_id | account_balance
0001       18.00         8888         20.00  <- INCORRECT BALANCE
0002       12.00         8888         20.00  <- INCORRECT BALANCE
0003       6.00          8888         14.00  <- ACTUAL BALANCE

Now just like how we extracted the computation logic into a separate function in the previous example, we now extract the "account related" fields into a separate table, and just add a foreign key pointing to the account table in each entry in the "order" table:

ORDER TABLE:
order_id | order_total | account_id
0001       18.00         8888         
0002       12.00         8888         
0003       6.00          8888         

ACCOUNT TABLE:
acc_id   | acc_balance
8888       14.00

Functional Dependency

For a table with attributes A, B, C, D:

A  | B  | C  | D
a1   b1   c1   d1
a2   b2   c2   d2

If knowing an attribute X determines the uniqueness of another attribute Y, then we say X determines Y, or Y is functionally dependent on X, denoted as X -> Y.
If the combination of some attributes is unique, say A and B together determines C or D, then we say AB -> CD.
Intuitively, a primary key or secondary key determines any other attributes.

Dependency Closure

The dependency closure of an attribute X in the table ABCD... is the set of attributes {ABCD...} that are derivable from X.

Normal Form

BCNF (Boyce Codd Normal Form):
If any functional dependency "X -> Y" in the schema satisfies that "X contains the whole key", then the schema is in BCNF. Notice that if X only contains a candidate key but not the primary key, it's still in BCNF.

The decomposition step to achieve BCNF regarding a functional dependency "X -> Y" in the table S is fairly straight forward:

Remove Y from table S
Create a new table "XY".

Working with Arrays in React (updating)

JayZho — Wed, 21 Sep 2022 09:30:55 +0000

Mapping to a list of components

Say we got an array of fruits, and we'd like to render each as a fruit card in the page, then we can use .map as below:

let fruits = ["apple", "banana", "peach"]
return (
  { fruits.map(x => <FruitCard name={x}>) }
)

But React may warn you that "Each child in a list should have a unique "key" prop". And the reason is as follow:

Say we initially had a list of fruits as ["apple", "banana"], and we mapped and rendered them as 2 individual <FruitCard> components in the page.

Later on, when we need to add one more fruit "peach" and update the page to display this third <FruitCard>, without the "key" prop, React actually has no idea about which fruits are newly added/deleted or which have stayed unchanged, hence it has no choice but to remove the previous 2 elements from the DOM tree and create a new element for each child of the updated list and add them to the DOM tree all over again.

To avoid this inefficient DOM update, React requires us to give each child a unique ID, then later when the list is updated, React only updates the ones that are changed according to their ID. In the example above, we could do something like: (assuming each fruit has its unique name)

return (
  { fruits.map(x => <FruitCard name={x} key={x}>) }
)

In this way, when "peach" is added, React knows that "apple" and "banana" were the old elements that are untouched, hence it only adds a new element for "peach" into the DOM tree, saving the work to remove and re-add the other 2 old elements.

In short, the "key" prop is to allow React to keep track of the list elements, therefore improving the performance on re-rendering.

Frontend Notes

JayZho — Thu, 15 Sep 2022 07:14:18 +0000

HTML

Some interesting tags

<a>: link to another web page
<label>: link text to an input, so when clicked it was as if the input is clicked
<iframe>: another html page within the current html page
<audio>: plays music in your page
<code>: monospace for letters
<pre>: take tabs and spaces into accounts
<header>, <nav>, <footer>, etc.: semantic tags rather than functional tags. But search engines like Google or web scrapers would grab info from tags like this and understand the web better.
<meta>: describes the meta data of the web page. Like page description, image, favicon, etc.

<meta name="viewport" content="width=device-width"> sets viewport size to the actual size of the device, rather than auto zooming out. (especially for mobile devices)
<meta name="viewport" content="initial-scale=1.0, ..."> tells how much we can zoom in/out.

<noscript>: defines what shows up when JS is disabled for the web.
<embed>: embeds media (like a youtube video) into the web page. The main difference from an <iframe> is that <iframe> is used to embed an entire html page while this is for media components.

Images

Raster image vs. Vector image

A raster images stores a 2D array of colours, gets blurry when magnified; while a vector image stores the geometry of the image instead.

JPG (raster)

24 bits per colour (more bits means more colour options)
Lossy compression (JPG encoded when storing and decoded when displaying, but can lose original info after decoding)
Suitable for high resolution photos

PNG (raster)

16 - 24 bits per colour
Lossless compression
Suitable mostly for non-photo use cases (when subtles details matter)

Base64 encoding

A binary-to-text encoding scheme to convert binary data to an ASCII string.
A common application is to represent image directly in the <img src="..." /> tag, which stores the image's data as part of the html, reducing the request to further retrieve that image data from an URI. This is a common technique for loading small image files.

CSS

Combinators

.B .C all .C that are inside .B
.B > .C all .C that are direct child of .B
.B + .C sibing .C that follows immediately after .C
.B ~ .C all sibings .C that follows after .C

Pseudo classes

<selector>:<pseudo-class>: select the elements with a special state.
e.g. button:hover div:first-child

Pseudo elements

<selector>::<pseudo-element>: create content for the selected elements or style part of the elements.
e.g. p::after { content: "."; color: red; } appends a red "." after every <p> element

Specificity

!important > inline style > id > class > type

Inline vs. Block elements

Inline elements(like <span>) takes only the width of its content, while block elements(like <div>) takes up the whole line, resulting in a newline for every element.

Grid layout

{display: grid}: Just another useful layout I don't use very often. Use it when necessary then!

A poor introduction to compilers.(still updating)

JayZho — Sat, 07 May 2022 02:21:45 +0000

What is a compiler

The job of a compiler is to turn source code that's written by humans:

int i = 0;
i = 10 + 20;

into machine code(a bunch of 0s and 1s) that's understood by computers in order to run the program: (say, 8-bit instructions)

01110010
01010111
...

Usually, the compilation process involves converting the source code into intermediate code called Assembly Code first, then further turning the assembly code into machine code.
The second step is relatively straight forward as it's mostly just a 1-to-1 replacement from assembly instruction to its binary representation.
This blog is largely about how we go from source code to assembly code.

From Source Code to Assembly

The big picture of this process is as shown below:

Step1: Lexical Analysis

-- turn the source code into a bunch of tokens.

In order to discuss lexical analysis, we should first have a look at what a programming language formally is.

Very much like natural languages(e.g. English), a programming language is just a set of strings(called "tokens"), where each string/token is a sequence of symbols allowed in this programming language.
For example, in English, the set of allowed symbols are roughly the 26 alphabets plus the standard English punctuation. Therefore,

How are you?

is a valid English sentence, while

H@w are you?

isn't, since "@" isn't a valid symbol defined in the language.

A programming language normally consists of 5 kinds of tokens:

Identifiers: variable names, function names are both identifiers.
Keywords: reserved words such as "if", "while" and "return".
Operators: +, -, <, >,
Separators: brackets, comma and semicolon.
Literals: source representation of a value

The job of this lexical analysis step is to scan through the source code and produce a set of tokens. For example, for a program that only has one line of code:

int a = 0;

The list of tokens produced after lexical analysis would be something like:

[
  Keyword("int"),
  Identifier("a"),
  Operator("="),
  Literal("0"),
  Separator(";")
]

Step2: Syntax Analysis

-- given a list of tokens, build a tree to represent the structure of this program.

In order for a sentence to make sense, it must be both **syntactically **and **semantically **correct. The syntax of a program deals with the program structure, while the semantics of a program deals with the program logic.
For example, the following sentence would be considered syntactically incorrect in general:

Tom likes.

since the verb "like" is missing its object.
A sentence could also be syntactically correct while being semantically incorrect. The sentence

Tom sees sounds.

obviously doesn't make sense, but it's syntactically correct as it consists of the subject, the verb and the object of a sentence.

The syntax rules of a language are called "Grammar", which defines what the structure of a language could be.