DEV Community: theoluyi

Some Messy Notes on Typescript

theoluyi — Fri, 01 Jan 2021 02:08:15 +0000

Disclaimer: These are my notes from Ben Awad's video on React TypeScript Tutorial...

So what I think I know: an interface defines the shape of an object. It allows you to say what the properties of that object will be. More precisely, an interface allows you to predestine the name of the object keys, and the type of the object values.

An interface reminds me a bit of a class in Ruby, in that it serves much like a blueprint for instantiating new objects. However, the type-constraining of the object values is what gives Typescript its name, so while there seem to be structural similarities, the functionality is quite divergent.

My brain's attempt to put more tangibility into the idea of a Typescript interface and Typescript in general is that it acts like a sieve or filter. If we have a react component receiving props and its props are typed via an interface, the interface acts as a stopgap against the most basic kinds of errors, i.e., that of the props object being different from what the component itself expected.

I think of a waste treatment plant, where wastewater is eventually recycled into drinkable water. If at one stage, we have a very fine sieve that only lets through very small particles but not sand, wood, or other debris, then at that stage the sieve has essentially worked as a interface for translating and filtering out inappropriate object types that do not conform to the type: liquid.

Whether or not the water is drinkable or not is an issue to be solved further down the line by other means, but it makes sense for the sake of keeping things SRP that we would want to make sure solids are not making there way into what we hope to purify into drinkable water later on.

This logic applies not just to Typescript React components but really any piece of data we can type with Typescript. I'm not sure exactly what word to describe this with, but ones that come to mind are structure, architecture, stigmergy. We're building these things into our programming language, by adopting Typescript, we're breeding in consistency through grammatical constraints on the way we express our code.

One basic piece of syntax we can use in Typescript interfaces is a question mark following a key name and preceding the colon before the value. This ? makes keys/properties of the interface/object optional.

If we want more complex types we can nest interfaces within other interfaces. Examples below:

interface Person {

firstName: string;

lastName: string;

}

interface Props {

text: string;

ok?: boolean;

i?: number;

fn?: (bob: string) => string;

person: Person;

}

HTML Events and the Radio Input

theoluyi — Fri, 11 Dec 2020 02:38:49 +0000

In HTML, a Freak in the Stylesheets — What on Earth is HTML pt III, I talked about how HTML doesn’t really do anything. Ben Romy explains this pretty succinctly, saying, “Programming languages have functional purposes. HTML, as a markup language doesn’t really “do” anything in the sense that a programming language does. HTML contains no programming logic. It doesn’t have common conditional statements such as If/Else. It can’t evaluate expressions or do any math. It doesn’t handle events or carry out tasks” (Why HTML is Not a Programming Language).

Something that still doesn’t quite sit right with me though is radio inputs. If HTML has no programming logic (including if/else logic) and is entirely structural, how can it be capable of handling something like a radio input without JS? A radio input to me seems like a perfect instance of if/else logic: if this input is selected, mark all others as deselected.

This quibble also extends to really any kind of input. If HTML can’t handle events, how am I writing text into it? The first clarification I must make to myself is that HTML DOES have events. It just doesn’t HANDLE those events. So Ben Romy’s point stands.

The tl;dr answer here is I’m not sure, but I have two theories:

1) Less likely theory: my assumption that there is if/else logic built into a radio button is wrong, and HTML doesn’t actually have to do anything programmatically when a user clicks a new radio button and the previously selected one is emptied; maybe this behavior is just intrinsic, like this pseudocode: “when button is selected, wipe clean all others before marking the radio button as selected.” This seems like a nice “u dumb bro” retort to my nitpicking, but I don’t think it completely explains it.

2) More likely theory: the DOM and JS are involved here, and the radio button has some built-implicit event handlers+listeners here, which you don’t see when you write a radio button into your code, but is actually there any time the browser actually deals with displaying/”function-ing” your radio button. Or basically, browsers are f-ing complicated. This seems a better/more likely explanation since it would also cover how other input types work, i.e., they’re complicated interactions between HTML/CSS, JS, DOM, your browser, etc.

The rest of this is me reminding myself of basic language boundaries/definitions. Enjoy if you want a refresher:

I assume I am not alone in this confusion over basic HTML that I have, which probably relates to barely learning any vanilla HTML and jumping into JS and then React directly in a bootcamp learning setting. For the previously uninitiated, combining HTML and JS as JSX confuses the boundaries between what part of the code is HTML, and what part is JS, what part is structure, and what is functional/scripting logic. Beyond that, I have a feeling a lot of my confusion legitimately relates to how confusing and complex the browser and DOM are.

In React land, when I write <button onClick={() => console.log(“Hello Dolores”) } >Say Hello</button>, even though this is all technically JS/JSX, when that actually gets converted into HTML and JS, (I think) onClick becomes an HTML onclick event handler, while the anonymous function I’ve passed in is the event listener. The handler handles the firing of the callback, which itself “listens” and is called whenever the specified event is delivered to the target.

listener is the callback (value) (JS). The key letter for remembering this is “L:” Listener is a caLLback.

handler is the HTML event attribute (key)… This might be a stretch, but maybe the key letter for this could be “A,” since we can think about the hAndler as the Event API for interconnecting HTML, JS, and the DOM.

Multiple ways to add event listeners:

Above, declarative React style of adding an event handler (camel-cased onClick, onHover, onChange handlers)

target.addEventListener(type, listener [, options]);

Declarative HTML style:

“Adding an HTML attribute named on<eventtype>:”

<button onclick="handleClick()">,

Imperative JS style:

“Or by setting the corresponding property from JavaScript:”

document.querySelector("button").onclick = function(event) { … }.

from MDN DOM onevent Handlers

MDN's Events and the DOM article gives three types, so you can assume that some of the ones I’ve named above are redundant, e.g., the React version is syntactic sugar for the EventTarget.addEventListener() style.

What the Fork is HTML? Part II

theoluyi — Fri, 16 Oct 2020 02:24:14 +0000

Pardon my French, but HTML

is a bastardized language. Kind of like English, HTML is a linguistic hodgepodge. HTML is a yes man: it seems to absorb all the roles and needs imposed on it, without a second’s hesitation to ask “Was I made for this? Am I even good at this?”

To be more specific, HTML is:

part behavioral description: an input with its type attribute set to "radio" creates an input that has behavior different from an input with type=”text”
part media description: img tags explicitly specify the media they contain
part visual description / uncreative stylist (why are h1 and h2 tags different sizes, couldn’t you have just let CSS decide?),
part organizational structure: use tags to enclose different elements and nest them within each other to form a hierarchical tree structure,
part tagset/knowledge structuring markup language: use this h1 tag so that every browser/technology understands this is a heading and displays it in a helpful way regardless of viewport and in alignment with assistive technologies,
part fundamental web technology that changed our relationship to information: anchor tags are the real world manifestation of the concept of hyperlinks, i.e., non-linear text! In other words, access to virtually infinite information: for research purposes, web scraping, doom-scrolling, YouTube-rabit-hole-falling-down, Jesus-Game-Playing, you name it. While we take the activity of "web-browsing" for granted now, this was one of the fundamental game-changers that reshaped the world, and the ability to hyperlink using HTML was what made it a reality.

As you can imagine with something given so many different roles, it doesn’t do all of them that well. However, it seems that HTML does enough of them well enough that it’s still around.

However, with all these different bizarre hats HTML wears, understanding how one SHOULD use HTML, rather than how one COULD use it can be difficult. So here are some pros and cons of HTML that I learned from the world wide web.

While venting is fun, this is not intended as a complaint about HTML (very convincing, Theo, I'm sure they all believe you now). Instead, this is for the sake of categorizing an exotic but dangerous and wily animal. I hope it helps other people like myself struggling to tame this beast:

CONS: Chaos and Complexity

HTML isn’t semantic enough: it doesn’t unambiguously tell you that this div with an h3 tag and nested paragraph tags are all talking about a single lawnmower for sale. Sure, the h3 might enclose the text “lawnmower” and the p tags might say “for sale,” “baby lawnmower,” and “never used”. However, to my knowledge, HTML doesn’t really help you explicitly tie these pieces of data together, to make it clear to a computer that these are interconnected data.
–– Wikipedia: Semantic Web
–– semantic here is used in the context of the goal of building a “Semantic Web,” i.e., a data web in which all information is appropriately structured and tagged so that it is machine readable
HTML has a dumb amount of tags that most people don’t need to know: HTML specs are not really for web developer use and more for people who professionally study browsers. I get the sense that studying these specs to learn web development roughly equates to reading the dictionary to learn English. Sounds like something I would do.
–– What's HTML and how does it work? | Web Demystified, Episode 1
HTML attributes also have their own problems: “Some attribute types function differently when used to modify different element types. For example, the attribute name is used by several element types, but has slightly different functions in each.” –– Wikipedia: HTML Attribute
As I pointed out earlier, HTML has at times taken on roles that make more sense for CSS. For instance, HTML presentational attributes have been deprecated in the HTML5 specs, with the advice being to use CSS to achieve the same effect while maintaining separation of concerns. These obsolete attributes can still be used, of course, which creates a lot of confusion around best practices. –– W3C: 4 Conformance: requirements and recommendations –– WHATWG: Presentational elements and attributes

PROS: Aspects of HTML that make sense to me at least

HTML uses boxes to construct web pages. HTML is the structure and content of a web page. –– What the Hell, is HTML? :: HTML Tutorials :: EP 1 That seems simple enough, right?
HTML accepts everything, which is what allows something to become a lingua franca. Like bread, HTML is more often the vehicle other flavors ride on rather than the target flavor itself. While HTML grew out of SGML–which was initially display-agnostic and used simply to tag information–HTML’s structure works and has continually evolved to allow it to contain many types of information.
HTML can be modified by specifying attributes, CSS, etc.
Scripting languages like JavaScript can be embedded inside HTML, which enables more complicated behaviors and interactions between web pages and people.
Perhaps it is HTML’s weakness, its abject failure to clearly define its own mission, that makes it so versatile, a bridge between the user and the developer, between pure presentational display and hard data.

Maybe, at the end of the day, HTML is like humankind, as Tesla put it:

“Our virtues and our failings are inseparable, like force and matter. When they separate, man is no more.”

HTML is what it is because it has always been a hastily evolving technology. It will never be perfect. Ironically, it being so unwieldy might also make HTML easier to update as technology evolves: it’s not like it can get much worse, can it? Nobody quote me on that.

What is HTML, really, deep down?

theoluyi — Fri, 09 Oct 2020 03:57:36 +0000

HTML is something every web developer has to know.

But do you know where it came from? That the creator of it, Tim Berners-Lee, wishes he called it HTM instead of HTML, because of the confusion that arises from SGML, XML, and HTML all ending with “ML?” That HTML evolved out of SGML, but is an application, not a subset of SGML? (XML is a subset of SGML. HTML is not a subset of SGML).

In the olden days,

people were just trying to tag different types of documents. The point wasn’t to create webpages. That comes later. There were all sorts of academic and military desires for annotating documents so that different pieces of data could be located more easily within those documents. So in the same way that an English teacher marks up student papers with blue ink, Generalized Markup Language (GML) was developed at IBM. This eventually developed into Standard Generalized Markup Language (SGML).

An important aspect of these markup languages (or should we say, markup META languages) is that by having starting and ending tags to contain text, they created an unambiguous hierarchy of elements that could be arranged into a tree data structure.

Later on, SGML was adapted by Tim Berners-Lee (who invented the world wide web!) to create HTML for displaying text on webpages. This is a big turning point and important for understanding what HTML is. SGML, a hierarchical system of used for punctuation and identification – angle brackets defining tags to wrap around pieces of text to identify what sort of content/category that text is – is used as a template for creating a system that tells a web browser how that information should be DISPLAYED. To emphasize, SGML itself is agnostic about presentation, its purpose is simply for labeling text data, whereas as HTML uses tags in much the same way for a completely different purpose, i.e., to describe how the webpage should look.

Another important contrast between HTML and SGML is that HTML is a FIXED tagset (you can’t just decide you want an tag in HTML, but you could in SGML if you decided that was your tag to identify keyboard mashes).

Seeing this much effort spent to tag and categorize data, it’s ironic that the very names of these systems have done a poor job of differentiating them from one another, leading to much confusion.

The two enabling technologies of HTML (SGML and XML) both end with ML. This implies to most people that SGML, XML, and HTML are all similar. However, SGML and XML are tagset technologies (essentially, punctuation rules). This is in contrast to HTML which is a FIXED tagset. EXTRA BITS: SGML HTML XML - Computerphile

In reality, however, while Tim Berners-Lee could have averted confusion by calling HTML simply HTM, the naming convention was screwed from the get go. It is really SGML and XML that are misnamed; they should be SGMML and XMML, (“markup META language”).

This would clue more people in to the fact that XML is a SUBSET of SGML. In other words, SGML contains XML. HTML is an APPLICATION of SGML, NOT a subset of SGML. These are different sorts of relationships, different evolutionary chains.

“Meta language & Markup language.
XML and HTML are not the same kind of markup language. Xml can be used to describe and generate other language markup that are interoperable with any kind of application in various presentation [sic] for different target groups and purposes. Given its flexibility, Xml is perfectly suited for marking up information of any kind.”

Here’s an example of an explanation that isn’t exactly incorrect but could easily mislead someone.

It says both of these languages are “born out” of SGML, but does not mention that they are not related to SGML in the same way. XML is like a light-weight clone of SGML; both are used for categorizing text inline using tags. HTML, on the other hand, is used for creating web pages.

“HTML was born out of the Standard Generalized Markup Language (SGML). It provides a set of rules for tagging elements in a document and defining markup languages such as HTML. SGML is not a markup language rather it acts as a language to create markup languages. Another markup language which is born out of SGML is XML.” https://jaxenter.com/html-origin-171035.html

Lastly, what’s up with "hypertext?" Hypertext is text like hyperlinks that allows us to navigate from one webpage to another by clicking on HTML elements including text, images, buttons, etc. While we take this for granted, hypertext is a fundamental technology of the web that didn't exist at one point, and is literally what enables us to “browse” in a web browser.

“HTML is the combination of Hypertext and Markup language. Hypertext defines the link between the web pages. A markup language is used to define the text document within tag which defines the structure of web pages. This language is used to annotate (make notes for the computer) text so that a machine can understand it and manipulate text accordingly.” Geeks for Geeks: HTML vs XML

So we’ve figured out what the hyper text part means, and we already figured out what markup is about (it’s for annotating text inline like an English teacher, assuming your English teacher is trying to categorize and scrape data from all of their students’ papers).

Lastly, language? Is it really a language? Is it a programming language? Apparently, yes, but it’s not Turing complete, so it can’t be considered a full programming language.

However, you can think of it as a declarative programming language specific to programming webpages, where a tag acts as a function and the text enclosed by that tag is like an argument, and you are asking HTML to return, for example, an h1 tag that says “I’m a little teapot.” You don’t have to tell HTML how to create that element, it just does it for you, meaning this is declarative, not imperative, programming.
Lastly, and more practically relevant is that HTML is only for making web pages, and thus could never be considered a general purpose programming language.
HTML IS a Programming Language (Imperative vs Declarative) - Computerphile

SOURCES

Professor David Brailsford and Computerphile with amazing explanations of these topics.

Creating My First Unit Tests with Jest

theoluyi — Fri, 02 Oct 2020 03:50:29 +0000

When I first started coding I always appreciated the satisfaction of passing tests and getting those snazzy green checkmarks in the terminal. Even the red x of failure I appreciated in his blunt honesty: speaking clearly to me, saying, “why don’t you try that again, sir.”

I remember feeling disappointed when I progressed further with programming and realized that these reassuring little guys didn’t just populate the inside of my computer like angry red devils and supportive green smurfs, that it was in fact possible to veer into the dark abyss of the terminal with no external reference points for correctness or accuracy to the thing I was actually trying to write.

The technical stuff is at the bottom, do yourself a favor and skip this middle part smh

But in the battle-blur of bootcamp, I had to keep my eye at the ready for any code challenge waiting to pounce and rip my head off, any quirk of JS I might fail to pick up in lecture that might lock me in a virtual cage like Matilda in the Chokey. The vagueness bothered me, but I moved forward and wrote messy, untested code with wild abandon; I swam with the code currents, the widening gyre.

After I read Eric Elliot’s article TDD Changed My Life, however, I knew that there was something out there that would fill this code void in my soul.

I was scared, but intrigued. Was there something wrong with me? Nobody else liked testing. Was this normal? Everyone else seemed to forge on ahead, brandishing their programming pistols and coding cutlasses with confidence. But eventually I had to admit it: I was curious about Test Driven Development. Google was my point of entry into self-acceptance and a whole new world.

But seriously I want to finish writing this post so let’s get to some technical stuff.

I worked on a codealong called Jest Tutorial for Beginners: Getting Started With JavaScript Testing from Valentino Gagliardi.

To start with the most basic idea, in testing our code, we want to verify that our code actually does what we expect it to do. It naturally follows from this that the way we make tests is by creating example inputs and example outputs that model the transformation we want the function to perform.

Then we essentially run the ACTUAL function with the example input and see if the function ACTUALLY produces the output we want. If it doesn’t, then the test doesn't pass, which means WE DID IT. We made a test that fails, because the function doesn’t exist yet. Only the test does. In this way, we start with the test, and let that drive us toward working code that passes it. It’s simple but brilliant for structuring the problem-solving process and approach.

We can use several key methods in Jest to accomplish this: describe, test, and expect.

describe is a Jest method for containing related tests. For example, in this tutorial, the first test I created verifies whether or not a filter function correctly filters an array of objects based on a search term. Describe takes two arguments: 1) a string describing the test suite (a test suite is just a bunch of test methods testing different aspects of the function), and 2) a callback that wraps the actual tests
test is another method which like describe takes a string and a callback. The string describes the particular test, and the callback wraps more code, such as variable declarations and statements using the next keyword: expect. expect is where the real nuts and bolts of testing become visible.
expect is where we perform the comparison of the function’s actual output to the output we would like it to have
so we have a 3 part nesting: describe contains test statements, and a test statement contains expect statements (if I am misusing the term statement here I apologize)

It’s much clearer to follow with the code, so I am copying it here; the tutorial is Valentino Gagliardi’s so if you’d like to work on it yourself click here: Jest Tutorial for Beginners: Getting Started With JavaScript Testing

// begin tests
describe("Filter function", () => {

    //test stuff goes in here
    test("it should filter by a search term (link)", () => {
        //actual test

        const input = [
            { id: 1, url: "https://www.url1.dev" },
            { id: 2, url: "https://www.url2.dev" },
            { id: 3, url: "https://www.link3.dev" },
        ]; // end of const input varDeclare

        const output = [ { id: 3, url: "https://www.link3.dev" }];
        const output2 = [ 
            { id: 1, url: "https://www.url1.dev" },
            { id: 2, url: "https://www.url2.dev" } 
        ]

        expect(filterByTerm(input, "link")).toEqual(output); 

        expect(filterByTerm(input, "LINK")).toEqual(output); // new test for case insensitivity

        expect(filterByTerm(input, "uRl")).toEqual(output2);

        expect(filterByTerm(input, "")).toEqual(input)
    }); // end of test block

Here is the function that the above code is testing

function filterByTerm(inputArr, searchTerm) {

    // case insensitive reg expression evolves from searchTerm
    const regex = new RegExp(searchTerm, 'i'); 

    return inputArr.filter( function(arrayElement) {
        return arrayElement.url.match(regex)
    })
}

querySelector vs getElementsByClassName (NodeList vs HTMLCollection)

theoluyi — Fri, 25 Sep 2020 03:58:31 +0000

For this blog entry, I wanted to talk about DOM traversal, but quickly got derailed by some funky JavaScript document methods and their idiosyncrasies. However, let’s start at the beginning:

The DOM or Document Object Model, which is the HTML skeleton forming the body of every webpage, is a tree. Any time we call JavaScript’s built-in querySelector method on the document or on a particular node, we are traversing through that tree and inspecting the CSS selectors of elements within that tree.

COMPUTER SCIENCE ALERT
Trees are a common data structure in computer science and search trees are a common type of tree data structure used for finding keys in a set.

MDN describes querySelector as implementing:

“depth-first pre-order traversal of the document's nodes starting with the first element in the document's markup and iterating through sequential nodes by order of the number of child nodes.”

While at present I haven’t found confirmation that other document methods use this same depth-first pre-order traversal strategy to navigate the DOM tree, I did stumble upon some important differences between these document methods that I’d like to cover. The issue is, what are the return values of these different document methods?

querySelector() returns an element. More specifically, MDN explains that its return value is:

“An HTMLElement object representing the first element in the document that matches the specified set of CSS selectors, or null is returned if there are no matches.”
Seems simple enough. However, querySelectorAll() may have to return more than one element, so how does it do this? It returns a static NodeList representing all the matching HTML elements. Well what does it mean that it’s static? We’ll get to that shortly.
getElementById() also returns an element. However, MDN simply calls this an “Element object describing the DOM element object matching the specified ID.” It does not call it an HTMLElement as it does the return value of querySelector, which leads me to believe that there is a difference here. However, at least it is still a single return value.
getElementsByClassName() returns a live HTMLCollection, “an array-like object of all child elements which have all of the given class name(s)” (MDN).

What is practically important about this?

querySelectorAll returns a NodeList (static)
getElementsBy___ returns an HTMLCollection (live)

NodeLists returned by querySelectorAll methods are static, but depending on how we manipulate them, their return values can either stay static or become live. Node.childNodes is live.

Neither of these are arrays, they are just different types of objects. HOWEVER, with NodeLists (which are newer/more modern) you can still use forEach() to iterate through them.

You cannot directly use forEach to iterate through an HTMLCollection. (If you need to though, you can use the Array.from() method to turn an HTMLCollection into an array, and then you can iterate through it using .forEach(), .map, etc.)

The difference between static and live is that live reflects exactly what is currently on the DOM, whereas static collections will not update if something is deleted on the DOM.

A helpful thing to remember is that some dude on the internet (sorry dude, I forget your name but I appreciate you) said that HTMLCollections are an artifact we just have to deal with. I think this preference for NodeLists is also related to the HTMLCollection annoyance of not being able to directly iterate through them.

Tl;dr: probably just use querySelector() or querySelectorAll() to avoid issues with HTMLCollections.
Further reading: what is meant on MDN by differentiating between an Element and an HTMLElement?

An Automotive Analogy for Web Architecture

theoluyi — Thu, 17 Sep 2020 23:28:32 +0000

Key Terms:

Protocol, Transmission Control Protocol (TCP), Internet Protocol (IP), Switching, HyperText Transfer Protocol (HTTP), HTTP request-response cycle, Header, Payload.

As a developing web developer, I want to understand the structural elements of the web. The web does not work exactly like the rest of the world; it is de-centralized/distributed, works at roughly the speed of light, and in its infancy felt like witchcraft. I've taken it for granted for many years, but now learning how it works, it feels like magic all over again. But magical is often synonymous with incomprehensible, so rather than remain mystified, let's break down how this stuff actually works.

I think we'll find that breaking things down into their fundamental elements–don’t worry, I'm not going to talk about binary–we’ll find the architecture of the web to be fairly straightforward. It won't remove the magic from the music, but, I hope, like understanding music theory, will add a background layer of intellectual excitement to the experience of thinking about the structure of our collective human consciousness that is the web.

First, some definitions:

What is Packet Switching?

Packet switching is one mode of transmitting data. In contrast, phone networks use a different means of data transmission called circuit switching. In packet switching, the way in which information is transferred is in small packets of data. Packets make their way across the web, from client to server and vice versa. Usually a packet’s size will be between 1-1.5 kilobytes (1,000-1,500 bytes). By dividing information into these nice little kilobyte-sized portions, the web can eat up our data without choking and gasping for air. Packet switching makes information transfer more reliable.

Here is a helpful gif to illustrate how packet switching works:

What is a protocol?

In telecommunication, a communication protocol is a set of rules, syntax, and other fundamental decisions that standardize and dictate information exchange between two or more parties.

What are the main protocols we should know to understand information transmission on the web?

TCP stands for Transmission Control Protocol. IP stands for Internet Protocol. These protocols work together and are often referred to collectively as TCP/IP.

TCP/IP was constructed to transmit packets and is thus known as a packet switching technology. Packets need a header to specify their origin and destination as well as the actual data they are conveying. If packets are like a letter, where the header is the address that anyone can see on the outside of the envelope, and the data is the letter enclosed in the envelope, then TCP/IP is like the postal service that accepts it from the sender and does its best to get it to the receiver.

TCP/IP has 4 layers (ATIN): Application, Transport, Internet, Network

How do these layers work you ask?

SHORT ANSWER: UHHH NOT SURE. I’ve outlined how I understand these layers below, but some of this might contain errors, especially the transport layer. These layers don’t appear to have a standardized nomenclature, so I see different labels for them in different descriptions.

(Image Source: What is TCP/IP? by TechQuickie )

Application Layer: HTTP functions at the application layer. For email, SMTP is used instead of HTTP. HTTP and SMTP are both application protocols, hence the name of this layer. If it helps, you can also remember this layer’s name as the one at which your web browser and other APPLICATIONS interact.
Transport Layer: TCP (and UDP) live at the transport layer. TCP is like the factory that is producing the cars (packets) according to exact specifications so that they are road-ready. It can also recombine packets into a giant super-car (think of a combiner transformer). From the transport layer, the packets then go to the internet layer.
Internet Layer: here packets are subject to the Internet Protocol (IP), which labels the packets with A) the origin and B) destination IP addresses so that the packets know where they are going. Next is the network layer.
Network Layer: this layer deals with MAC addressing which gets you to correct the physical machine, as well as conversion of the data into the electrical signal that will pass through the INTERNET plumbing.

Are you ever going to explain the car analogy?

YES. To borrow a chestnut from Al Gore and the 1990s, information exchange on the internet can be imagined as a SUPER HIGHWAY. However, now in 2020 this analogy can actually be helpful if we flesh it out with details. Let's make it more sci-fi and weird, just like the web.

A gigantic mega-car (the whole piece of data being transmitted) is broken down into dozens of little cars (packets) based on conventions laid out in TCP/IP. Each little car is given a header and a payload.† Basically, imagine a giant transformer like Optimus Prime breaking down into its constituent little transformers (to avoid traffic), pointing across LA's urban sprawl, and all saying in unison "We will meet at that In-N-Out Burger."
TCP/IP is also like the white dashed lanes of the highway and the laws governing the road, which dictate how the cars come and go. TCP is congestion averse which means that it prioritizes speed of transportation.
The cars (type=string) pass through the TCP/IP layers until they are zapped with a death ray/teleporter beam (i.e., converted into an electrical signal).
After some distance, the cars are resurrected from the dead, reconstituted into little car packets, and then once again into the giant mega car on the other side (client/server).

The End

Footnotes

†I imagine the header in several ways: as writing that covers the entire front of the car, as the engine which allows the car to go to its destination, as the license plate that gives the car legal recognition and permission to be on the road in the first place.

One can imagine the payload in several ways: the people in the car, the lumber in the back of the truck, or the actual entire back part of the car. In any case, remember that the payload is the information you are actually trying to transmit.

This explanation from Wikipedia is also a helpful way to think about it Wikipedia - Payload (Computing) :
"In computing and telecommunications, the payload is the part of transmitted data that is the actual intended message. Headers and metadata are sent only to enable payload delivery.

In the context of a computer virus or worm, the payload is the portion of the malware which performs malicious action.

The term is borrowed from transportation, where payload refers to the part of the load that pays for transportation."

Sources:

HTTP

HTTP Zine by Julia Evans
Podcast Episode: "HTTP with Julia Evans" on "JavaScript - Software Engineering Daily"

TCP/IP

Packet Switching

How Stuff Works - Packet Switching

Explore CSS Units with Theo

theoluyi — Fri, 11 Sep 2020 03:27:11 +0000

Hello internet.

Welcome to my first post-bootcamp blog article. It’s not as bad as I thought it would be! I am very excited to take you on this journey with me while I speedily acquaint myself with CSS units. Next week I hope to build on this by looking into flexbox; in particular I’m interested in thinking more about how trying to anticipate and handle different sizes/lengths of elements dictates the entire logic of CSS; flexbox seems to be another extension of this idea.

To begin with, the first thing I Googled tonight was “different css dimensions,” which brought me to a w3schools article on CSS Units. After giving some examples of different CSS properties which take “length” values, the article explains that there are two types of length units in CSS: absolute and relative.†

†I also feel it worth mentioning that Matthias, in his CSS units explainer, adds a third type of unit, viewport units, which I find a helpful category.

Absolute Lengths

ABSOLUTE LENGTH UNITS: cm, mm, in, px, pt, pc
ABSOLUTE LENGTH UNITS YOU CAN FORGET: cm, mm, in, pt, pc
Absolute lengths are real world lengths that can be measured consistently/constantly (in=inches, cm=centimeters, etc). Pixels are also listed in the w3schools article here as an absolute length, with the caveat that pixel density varies depending on the device you are using.

I understand this choice to leave pixels in the absolute length category as logical given that unless someone is switching devices, elements styled with pixel units will appear to stay constant despite, for example, resizing the browser window. However, resizing the browser window could change the size of elements styled using relative lengths.††

††Or if you want to be more precise by using Matthias’s definition, elements styled using viewport units.

Relative units we can thus understand as being relative to some sort of variable software aspect, and so pixels don’t count as relative since they are relative to an aspect of the particular piece of hardware you are using (i.e., the DPI/PPI of your device).

Before moving on to relative lengths, I’d like to quote one important point from that w3schools article:

“Absolute length units are not recommended for use on screen, because screen sizes vary so much. However, they can be used if the output medium is known, such as for print layout.”

I find this point noteworthy since I feel I’ve seen people use px plenty, and so it seems that this is not a best practice.

In actual practice, it probably doesn’t matter much if your div’s border property is defined as {border: 1px solid black;} rather than {border: .05rem solid black;}‡, but I like the principle of everything scaling evenly, and pixels being an absolute length precludes this.

‡Apparently the default root element (the html tag) font-size in most browsers in 16px, and so 1px should be exactly 0.0625rem, or roughly .05rem if you don't want to be too programmy about it, assuming it is relative to that 16px root element.

Relative Lengths

RELATIVE LENGTH UNITS: em, ex, ch, rem, vw, vh, vmin, vmax, %
RELATIVE LENGTH UNITS YOU CAN FORGET: ex, ch
Relative length, in contrast to absolute length, is defined relative to another length property. This I assume is where experience as a web developer becomes styling gold. Experience will allow a CSS fashionista to understand what types of elements should be sized relative to what other lengths; in this way there is basically no need to memorize dozens and dozens of different relationships between different elements of your app, instead you simply follow basic design principles and best practices that will remind you of which elements should depend on which other lengths. Those other lengths would relate to browser/viewport size or the font-size of other elements.

An em, ex, and ch will all define length relative to the font-size property of the parent, but they do so in different ways. Em is based on the overall height range covered by capital letters in that font/font-size※, ex is based on the height of the lowercase x (apparently this roughly maps to the height of most lowercase letters), and ch is based on the width of the 0 character. Basically, if you’re going to use one of these, use em.

※ “An em is a CSS unit that measures the size of a font, from the top of a font’s cap height to the bottom of its lowest descender. Originally, the em was equal to the width of the capital letter M, which is where its name originated.” (Quote from “The Principles of Beautiful Web Design”).

However, if you want to make your life easier, I think using rem is best, since it is the same as em only the element it is relative to is the root element, i.e, the html tag, meaning that it doesn’t matter how nested your html is if sizes are styled using rem units because they will all reference the root, instead of each html element referencing its parent, and so on and so on up the entire tree.

Viewport Lengths

Vw and vh are just viewport width and height, and vmin and vmax just choose whichever of these two are smaller (vmin) or larger (vmax) as the reference length. 100vh is 100% the size of the viewport height, 1vh is 1% or .01 the size of the viewport height. The viewport is just the browser window, so this essentially allows you to have your content resize itself depending on how large the window is, and by extension by how large the device screen is.

You still reading this?

If you find this topic useful, here’s Matthias’s great explainer that gets into this with a bit more depth and has some nice visual aids that should help with comprehension.

Key takeaways for me: 
• use rem and em as your relative length units, emphasis on rem; 
• learn more about viewport length units to understand best
 practices for adapting to different device sizes;
• avoid using absolute length units since these won’t scale well;
 only use them when it is important that something exactly represent
 real world size or stay constant in size regardless of the size of
 the device/browser window it is being viewed on;

See you next week!