DEV Community: mogwai

What do JavaScript devs need to know about Fintech development?

mogwai — Thu, 24 Jun 2021 02:39:17 +0000

A brief introduction:

I work in the European fintech space, on a platform that's an API of APIs that helps fintech businesses get off the ground quickly.

Even though my coding skills are pretty decent, I find that my real challenge starting out were mostly connected to my limited understanding of the financial industry as a whole. I've been bridging that gap by taking courses on financial markets, business models and technologies but I'd like to know from more experienced developers in the fintech space.

How did you get knowledgeable, and what would you say was the most important route to gaining this competence?

Understanding Math.random() in JavaScript!

mogwai — Sat, 01 Aug 2020 07:10:36 +0000

It’s incredible the number of times you’ll have to use Math.random() (out of all the Math methods that ship out-of-the-box with JavaScript).

If you’re a creative coder, you’ll need it to make generative art (even though many of the tools of creative coding ship their own flavor of the trusty Math.random()). As a result, it’s probably a great idea to reason about how Math.random() works.

At its very base, Math.random() is designed to do only one thing: generate a number between 0 and 1. I like to think of it as a white noise machine, generating white and black pixels to fill a whole screen. That analogy is powerful when you consider that white noise machines go into the creation of mosaics and even procedurally generated clouds, among other things.

In other words, Math.random() is deceptively simple:

0≤ n <1
//What Math.random generates

Math.random() generates a number between zero and one, but never (or rarely ever) generates one itself.

Extending Math.random()

If we think of 0≤n<1 as an algorithm for the procedural generation of random floating digits, we can then generate numbers not limited to 0 and one. We only need to reduce the skeleton of our desired range to the base format.

Say you want to generate a number between 5 and 15. This is the mental sequence you’ll follow:

I need a number between 5 and 15.
This can be represented mathematically as 5≤n<16 (can you guess why we write 16 and not 15?)
But Math.random() can only think in 1s and 0s. So how to get things in agreement?
First subtract five from every part of that mathematical model of computation.
That gives us 5–5≤n-5<16–5…
…which is 0≤n-5<11
Okay. So we have a zero on one end. But we need a 1, not an 11, on the other end!
Oh, I know! Let’s divide everything by 11!
0/11≤(n-5)/11<11/11
That’s 0≤(n-5)/11<1
Yay!
But we aren’t done :(
You see, (n-5)/11 is r. That is, the random number Math.random() will generate. What we want to get it the factor we’ll multiply r by to get numbers within the range we want (in this case, 5–15). To do this, we have to find n.
r = (n-5)/11
Multiply both sides by 11
n-5 = r*11
Add five to both sides
n = (r*11) + 5 Let’s take this for a spin, shall we? Let’s write a function called fiveToFifteen.

And it works!

But what if you wanted to change the number from five and fifteen to, say 8 and 19? Will you have to do that 18-step reasoning we did earlier?

Mercifully not. Instead of thinking in pure numbers (5 and 15), we can think in terms of min and max.

0 is min, 1 is max.

So we can start with this basic idea instead:
min ≤n<max
If we go through the 18 steps again, we have something like this at step 9:

min-min≤n-min<max-min, which gives us 0≤n-min<max-min
Divide through by (max-min), and we get:
0/(max-min)≤n-min/(max-min)<(max-min)/(max-min)
0≤n-min/(max-min)<1

Aha.

We can then run r = (n-min)/max-min

Multiply both sides by (max-min), and we get r * (max-min) = n-min
Add min r * (max-min) + min = n

We can then rewrite our function to adapt to any random number generation need like this:

function anyRandomNumber(min, max){
    let r = Math.random();
    r*=(max-min);
    r+=min;
    console.log(Math.floor(r))
}

anyRandomNumber(69,87)

Thanks to Scrimba’s math for frontend developers for helping me understand this, and I hope it is a useful mental model for you as well!
This was originally published on my blog

5 Non-Programming Books That Inspire Me to Become a Better Programmer

mogwai — Wed, 08 Jul 2020 00:57:31 +0000

Who's this for?

For the individual who loves to color outside the lines sometimes; the sort of person who thinks of programming as yet another professional attribute that can benefit from a broader approach to understanding life.

Why do we read?

Since the beginning of July, I've decided to inject a bit of consistency in the way I read. Like everyone else, I read something every day - a blog post, a news article, or something that ranks high on Readup, one of my favorite places to discover high-quality reading material.

As a programmer, however, whenever I find myself reading anything, I also find myself wondering if I wouldn't benefit more from reading Mozilla's (MDN) JavaScript documentation for some obscure JS use case, or completing Wiley's Poignant Guide to Ruby, or Eloquent JavaScript, or 'Think Like a Computer Scientist'...you get the idea.

So in July, I decided to return to reading about things that would enrich my reading experience overall, biasing in favor of things that will make me a better programmer. Here's a list of some books I have read in the past, and books that are on my in-progress tab which I think help me appreciate programming more instead of distracting me from the noble goal of becoming a 10X developer.

The Drunkard's Walk, by Leonard Mlodinow

This is probably my favorite book this year. I consider it a love letter to randomness, and the school of thought that formed around it: probability theory, statistics, even quantum theory.

It's perfect for people who enjoy prose, or cleverly-written essays. It is written from the perspective of an exploration into the history of the mathematics around randomness, and you'll discover that a lot of what we know about randomness was inspired by gambling, gaming, and the worship of gods! No wonder Einstein said God does not play with dice.

I started reading this book because I wanted to understand randomness more. It started one night when I was writing several functions to help with creating generative art. I was using a library that piggybacked off of the default Math.random() method to create 'noise' that ensured every generative art piece was different from the last. It piqued my curiosity about randomness and led me to this golden book!

Check out the book on Amazon

Cryptonomicon, by Neal Stephenson

This one is based on history - so probably accurate to call it historical fiction. Neal Stephenson is a masterful storyteller, and I can already see that (disclaimer: I'm about 20% into the book, which is about 1,539 pages on my Apple Books).

For anyone who's looked up Alan Turing (or watched The Imitation Game), you'd remember that in the Second World War, the Allies decrypted the Enigma Code, then spent a considerable amount of time throwing the Nazis off that scent. In Cryptonomicon, the story goes between two timelines (one set in the 1940s and 'present-day').

A fictional version of Dr. Alan Turing (among other notable scientists of history) is in this book as well, and they work with the protagonists to decode Axis communications, use it to thwart their enemies while simultaneously hiding the fact that they've compromised Axis communication codes.

In the present-day timeline, the grand-children of the World War II codebreakers continue the tradition, finally confronted with an unbreakable code that throws weirdness in the mix.

I started reading this based on a Twitter recommendation for some of the best speculative fiction (it started with someone complaining about SF being watered down nowadays), and I found this 'chunky' enough to take a stab at.

Get Cryptonomicon on Amazon

Pure Mathematics For Beginners, by Dr Steve Warner

I know, I know. Screw Mathematics. All my friends hate Mathematics. But, you gotta admit - math doth rule everything about us.

I was never one for Math, and I blame the way it was taught to me as a kid - it was just one more class to pass, with no immediately-apparent connection to my real world. Who cared if a plane traveled 30 degrees west, huh?

As soon as I entered the fantastic world of algorithms, it became apparent to me how much simpler my life would be if I returned to some math concepts. Here's my unpopular opinion: many tutorials and courses will tell you you don't need to know math to be a good programmer. That's probably true, but knowing math definitely makes you a great problem-solver!

This book starts with logic, which adds the spice to your || pipes (or logical ORs) and logical ANDS (&&), explains Set Theory, the principles of vectors, number bases, linear algebra among other things.

You don't need to read this deeply. Even a casual read of this will make you a better human being by far, I guarantee it.

Get Pure Mathematics for Beginners on Amazon

Our Final Invention, by James Barrat

I began reading this after getting high on The Last Invention of Man from Issue 43 of Nautilus.

If you've been infected by Elon Musk's paranoia about AI, then you should read this. Haha.

Musing on these topics reminds me of Rita King, who said: "Being human is a fleeting moment between stardust and robots."

Our Final Invention

The Tyrannosaurus Prescriptions, by Isaac Asimov

I love Isaac Asimov, and you do too - you just don't know it yet. This book is a collection of essays his sponsors asked him to write about the future, sociopolitical events, and anthropological observations in general.

Published in 1977, Asimov made attempts to guess the future of humanity. He was uncannily accurate in some regard and hilariously off-course in others, but the main reason I'm recommending this is that it gives you a precious insight into how people think about life in the meta, or the macro if you will.

In reading the Tyrannosaurus Prescriptions, I found myself yearning for an opportunity to think about the broader implications of things (Moore's versus Eroom's law, for example). and that is a rewarding exercise in itself. It can help shake the tedium from programming (let's face it: programming does get tedious sometimes!) and offer you a new perspective about your role in the universe.

I recommend for thinkers and dreamers alike!

Take a peek into The Tyrannosaurus Prescriptions here

Final notes

I am not affiliated with any of the links I shared, so this article is not a sinister plot to earn money off affiliate marketing. I just rather love recommending books!

Also, if you have interesting books I should check out, reply to this!

Have a great day, DEV sloths!

A Spotify Playlist Based on your Horoscope!

mogwai — Thu, 02 Jul 2020 00:28:47 +0000

Last month, I collaborated with another web developer/designer to create Astrofy, a simple app that creates a playlist based on your Horoscope.

Check it out!

Tech

We used the Spotify API for this, and the backend code was written in Node (via Expressjs).

Some modules that made this possible were aztro.js and horoscope.js. I should mention that we used the web-spotify-api npm module, which made it significantly easier to use the Spotify API in the backend.

In the frontend, I used React, with a few basic hooks, namely: useState and useEffect.

Help me revamp my web dev portfolio!

mogwai — Mon, 29 Jun 2020 02:59:16 +0000

I'm currently getting ready to revamp my portfolio page (I tend to use it as a way to update myself on design + dev knowledge - so my portfolio 'levels up' as my experience does.)

I've been writing code for ~10 months now, and I wrote this in the 8th month. Overdue for a makeover, eh?

View here
See my projects

I would appreciate actionable feedback/resources/considerations for making the new version great.

Thank you!

What's the quickest, most rigorous path to becoming a game developer?

mogwai — Mon, 15 Jun 2020 23:27:36 +0000

For context, I'm a JavaScript software developer and I've written my fair share of MUD (multi-user dungeon) games and canvas-based games, but lately I've been trying to kick it up a notch and create more robust, visually appealing games (ideally) for the web.

(Aside: I've been learning three.js, creative coding and AR.js. I'm neither here nor there with those either)

I hear that I need to learn Unity and C++, but I'm not particularly sure the best way to dive into this, and the more I think about it, the more I overthink it - the more I find myself procrastinating.

In a nutshell, I need help: if you're a game developer, what things do I need to know? I could really use a syllabus-styled list.

I'll appreciate all the help I can get!

Thanks

Your Heroku App Keeps Crashing After Deploy? Tell Me About It

mogwai — Sat, 06 Jun 2020 04:42:21 +0000

Heroku is easy to use, until it isn't. The first day we - a bunch of full stack developers-in-training - were introduced to Heroku in class, we were blown away.

'That's it?' we asked, bewildered.
'That's it!' laughed our instructor. It was the simplest class ever. Click here, tap here, grant permission there and you have a continuously deployed server. Whew. We took the day off and had fun for the first time in a long time.

Those beautiful days are long gone now, and in the real world, you'll discover that when Heroku fails, it does so in passively tyrannical ways. It is terser than your room mate. Today, I'm going to run through a list of Heroku errors I've encountered so far and how I solved them. Hopefully this article will save you a trek through several Stack Overflow pages.

First, let's keep the main thing the main thing

Don't forget to process.env.PORT all the things

As you probably know, your local environment uses a hard-coded port number to run your local servers. Things like 'localhost:5000' for example are great on your local machine, but if you leave that hard-coded port in your server, it will become a code H10 HEROKU problem.

As a rule, if you must use port 5000 locally, always use a logical OR to add the heroku environment.

`const PORT = process.env.PORT || 5000;

That should do it.

Why is this necessary? Heroku sets its own port at production time, and if you override it with your local configurations, it will throw up it hands in annoyance and quit on you.

The notorious Heroku logs

Sometimes you'll encounter a problem where you'll get a code H10 error that says 'MODULE_NOT_FOUND' without seeing what the module is. I'm not sure why, but it often feels like the heroku logs are incomplete.

This can be a pain in the ass to debug. What module is not found? Where?! These are the questions!

To fix this one, a great thing to do is to open the heroku cli on your favorite terminal.

Type in heroku run bash then npm start (if you're using Node js - basically start your server). It will throw the same error as before, but this time more explicitly. Note the errors, exit bash by typing exit, implement your fixes, do a git push heroku master and do a heroku restart and heroku open and things should be much better.

Procfile

You typically don't need to manually add a Procfile, since Heroku can read your package.json file to tell where the server file is located. However, sometimes the odds aren't in your favor (usually your fault), and now you explicitly need to tell Heroku where to look for your server.js or index.js or app.js file.

Whatever the case, this is where you create a Procfile (no extensions - it's like gitignore like that).

In the Procfile, you'll tell heroku how to find your file, eg:

web: src/index.js

HINT: You need a Procfile if Heroku says something like 'cannot find /path/to/file.js'

That's all for now. I hope this helps at least one person!

Quick Introduction to React Custom Hooks With Dropdown Selection

mogwai — Sun, 16 Feb 2020 14:19:02 +0000

Who’s this article for?

For people new to React, and for people who have some experience with React who - like me - become confused when they have to build their own (or read others’) custom hooks. I’ll explain this as simply as I wish it was explained to me.

Skip this if you already understand the basic philosophy of React Hooks. Everyone else, start here:

As if oft drummed into our heads, React is an unopinionated Library that we use to choreograph the front-end. A very important rookie question you have to ask early enough is "why do I need this complicated thing called React when I can just build my front-end using HTML and CSS?”

I think this question is important to ask because it allows you understand the value of React, which lies in something called state.

The simplest definition of state is that it represents the ‘status’ of data passing through a component. React updates the DOM when state changes, and this is something HTML and CSS alone are not equipped for.

Imagine you had a chat app, and you wanted to indicate, with a small ‘status’ icon (usually a tiny cicle) when they are online (green!) or offline (gray!). How would you do that?

In React, you can do this using something called Hooks. Hooks use ‘events’ to update state. If you spoke to the React hook known as useState, this is how the conversation would go:

useState: 'Hello, I'm a React Hook called useState! My job is to keep track of state changes in your React app and update everything according to your programming!"

You: "Oh, hey, useState! So I built a component that keeps track of a user's online activity and changes the color of this tiny circle."

useState: "I see. First, you have to set a default state. This is the state I'll display the circle as when nothing's happening."

You: "How about gray? For offline?"

useState: "Excellent. Works for me! Now you have to set a state setter!"

You: "state setter? What?"

useState: "Oh, it's how you teach me what to look out for to change the default state."

You: "Ah, so I tell the state-setter to watch for the user's 'last seen' status, and when it changes to 'last seen: now', to change the circle to green?"

useState: "Now you're getting it!"

That’s a crash course into hooks.

And now: Custom Hooks

The true beauty of a custom hook is that you can use it to create components that follow state-setting rules all across your application, which makes it easy to make app-wide updates without breaking anything.

Note: The following is adapted from a Frontend Masters class I took.

Imagine we wanted to create a custom hook that gives you a dropdown everytime you invoke it. Why would this be beneficial?

It means that with one custom hook, you can create all kinds of dropdowns.
You can have dropdowns with state tracking baked into them.
You can reuse your dropdowns all over your application.

In code terms, instead of writing this every time you want to make a dropdown,

import React, { useState } from 'react';

const dropdownlist = ["item1", "item2", "item3"]

const FirstDropDown = () => {
  const [firstdropdown, setFirstdropdown] = useState("I am the first!");
return(
  <label htmlFor="First Dropdown">
    First Dropdown
      <select
        id="first"
        value={firstdropdown}
        onChange={e=> setFirstdropdown(e.target.value)}
        onBlur={e=> setFirstdropdown(e.target.value)}
        disabled={!dropdownlist.length}>
          <option>All</option>
          {list.map=>(item=> <option key={item} value={item}>
          {item}
          </item>)}
      </select>
  </label>
);
};

export default FirstDropDown

you write a hook that allows you to create a state-managed custom component instead:

const Dropdownlist = () => {
  return (
  <label>
  <FirstDropdown />
  <SecondDropdown />
  <ThirdDropdown />
</label>
)
};

Let’s begin!

Constructing the Hook

First, create a new jsx document for the custom hook. Keep it in the src folder (if you’re following the conventional setup for React projects):
file > new > useDropdown.jsx
Inside your new file, import React and useState:

import React, { useState } from 'react';

Note: something that used to trip me up about React hooks is that you can only use hooks inside a function. I imagine this is because it keeps the hook in local scope and prevents unwanted side effects in global.

Create the dropdown component that you’re going to manage with hooks:

const DropDown = (label, defaultstate, options) => { }

The three arguments above do specific things within the dropdown component, and I’ll mention them now, but they‘ll make sense as we provide.

“Label”: Think of this as the name of the Dropdown itself. So a “Shoes” Dropdown shows a list of shoes to select, and "Shoes” is the label. In HTML, it would be represented like this:

<label htmlFor="Shoes">
    Shoes
</label>

“defaultState” represents, well, the default state of the hook.
“Options” in the case of a dropdown is usually an iterable (ideally, a list) that is used to build the options the user can select from.

Makes sense? Let’s move on!

Define the useState hook (the state setter!)

const DropDown = (label, defaultstate, options) => {
const [state, setState) = useState(defaultState);
}

Now, we create the Dropdown component itself

    const useDropdown = (label, defaultstate, options) => {
    const [state, setState) = useState(defaultState);
    const Dropdownmaker = () => (
      <label htmlFor={label}>
        {label}
          <select>
            <option>All</option>
          </select>
    </label>
    )
    }

Basically like you would a regular component.

Now it’s time to plug our state tracker.

Plug the state tracker to auto-populate the Dropdownmaker:

    const useDropdown = (label, defaultstate, options) => {
    const [state, setState) = useState(defaultState);
    const Dropdownmaker = () => (
      <label htmlFor={label}>
        {label}
          <select
          id={label}
          value={state}
          onChange={e=>setState(e.target.value)}
          onBlur={e=>setState(e.target.value)}
          disabled={!options.length}
            >
            <option>All</option>
            {options.map(item=>
            <option key={item} value={item}>{item}</option>)}
          </select>
    </label>
    )
    }

Now we return the necessary values for making the custom hook reusable as an array:

    const useDropdown = (label, defaultstate, options) => {
    const [state, setState) = useState(defaultState);
    const Dropdownmaker = () => (
      <label htmlFor={label}>
        {label}
          <select
          id={label}
          value={state}
          onChange={e=>setState(e.target.value)}
          onBlur={e=>setState(e.target.value)}
          disabled={!options.length}
            >
            <option>All</option>
            {options.map(item=>
            <option key={item} value={item}>{item}</option>)}
          </select>
    </label>
    );
    return [state, Dropdownmaker, setState]
    }

    export default useDropdown

With that, we can now import the custom hook into components that need it!

import React from 'react';
import useDropdown from './useDropdown.jsx';

const shoe_list = ["Prada", "Jimmy Choos", "Nike", "Adidas"]
const Component = () => {
  const [shoe, ShoeDropdown ] = useDropdown("Shoes", "", shoe_list);

  return (
    <ShoeDropdown />    
)
}

Explanation
This custom hook gives you a shoe with a label of “shoes”, a default state of empty array, and an options list of “shoe_list” (which I made into an array above - although ideally you’ll be pulling from an API).

The ShoeDropdown gives you a dropdown list as we designed before, and allows you set the state, which changes the default state based on selection.

And that’s it! A quick introduction to Custom Hooks using Dropdown Selections!

The Dining Philosophers Problem (Or Your Introduction to Thinking in Computer Science)

mogwai — Wed, 12 Feb 2020 18:23:52 +0000

Who's this article recommended for

Absolute rookies wondering what to expect from a study in computer science and how it can help elevate their general approach to coding.

Five Philosophers, Sitting in a Circle

Imagine that you're in charge of the eating arrangements of five sober philosophers sitting in a circle. On each side of them is a chopstick, which adds up to five chopsticks in total.

The philosophers, naturally, love to think. But they're also there to eat. The only way that they can eat is if they have two chopsticks.

How do you design a system (or algorithm, if you will) that ensures the philosophers can eat and think and eat and think and eat and think?

System constraints

There are three constraints to take into consideration here:
a. Food is infinite, ie a philosopher can eat for as long as they want, and
b. A philosopher can think for as long as they want.
c. A philosopher can only eat when they have two chopsticks

Thinking about the problem

A very useful framework for solving programming challenges like this one is Lambda School's acronym-based formula, called the UPER framework. It's straightforward and intuitive. It reads as follows:

U for Understand
P for Plan
E for Execute
R for Reflect (Loop!)

Understand

In trying to understand the problem, I made a drawing of the five philosophers and placed the chopsticks on each side of them, until I had the chopsticks distributed among them.

As soon as this was done, I spent some time thinking about the problem, which led me to realize that the chopsticks lend themselves to a concept known in computer science as semaphores. I'll supply a simple definition:

A semaphore is something used to keep track of a resource upon which a process (or series of processes) is dependent. In the case of the Dining Philosophers problem, we can think of the resource (chopsticks) in terms of a counting semaphore. A counting semaphore simply counts up (or down) on the availability of the resource (the chopstick).

Explained in a different way, if you wanted to use a bathroom in a building with only three bathrooms, you could meet the building manager who keeps an updated semaphore of how many bathrooms are occupied and how many are free. Armed with the semaphore, the building manager can then decide (using different techniques) who gets to use the rooms when they're free. After allocating a room, the building manager deducts one resource from the semaphore, and if a room becomes available again, he adds one more resource to the semaphore.

Long talk, but understanding the Dining Philosophers problem suggests that this is a resource allocation problem, so we need a counting semaphore to keep track of the chopsticks.

semaphore = 5

Plan

Now, we need to plan the best way to allocate the chopsticks so that each philosopher can eat and think without obstructing the activities of another one.

First, we can see that the philosophers have two states: eating and thinking.

philosopher.state[0] = {eating:true, thinking:false}

These states are mutually exclusive (a thinking philosopher is not eating, and an eating philosopher is not thinking).

We can go further in our assumptions that when one philosopher picks up a chopstick, it means they're ready to eat, and are simply waiting for the philosopher on either side of them to drop the chopstick they're holding.

In other words, there's a mid-state we have to account for. Let's call it ready_to_eat which we can observe by seeing a philosopher pick up one chopstick.

If we've planned properly, we should have a system that works like this:

philosopher[i] has 0 chopsticks
philosopher[i] is in thinking state
semaphores = 5philosopher[i] picks up 1 chopstickready_to_eat = truesemaphores=4philosopher[i] picks up second chopsticksemaphores=3philosopher[i] is in eating statephilosopher[i] puts down chopstickssemaphores=5philosopher[i] is in thinking state`

We can then loop indefinitely with these states and conditions accounted for.

Execute

This is the bit where we then create the program and run it with five processes (philosophers) in place. This program is nearly perfect, but as soon as we execute, we'll experience something called a deadlock (when processes are jammed and unable to terminate/complete execution because resources are locked in place).

In other words, the semaphores go down to zero, but all philosophers are locked in a ready_to_eat limbo state forever.

What happened? All philosophers picked a chopstick each! They're not thinking or eating - but they're ready to eat but have no spare chopsticks!

Reflect

In the reflection phase, we sit in the dark and ponder on our code and figure out ways to fix execution problems. In this case, we're going to reflect on fixing the deadlock problem before returning to execution.

Here are a few ways to resolve the deadlock problem:

Have four, not five philosophers: If we have one chopstick more than philosophers at the table, it becomes possible for a philosopher to be eating while other philosophers are in a ready_to_eat state without a deadlock happening.
We can also artificially constrain the system using a FIFO system + a skip: we start philosopher 1 at at eating state, which also puts philosopher 3 at an eating state. This means only philosopher 4 can be in a ready_to_eat state. If philosopher 4 is truly ready to eat, they’ll pick the chopsticks after 3 is ready and done, otherwise the chopsticks will be free for use by 5 when 1 is done. Whenever the counting semaphore defaults to zero, restart the FIFO (First in, First Out) system + a skip.
Make it so a philosopher can only pick up a chopstick when both right and left chopsticks are free.

Closing notes

Can you think of additional ways to fix the deadlock of the philosophers? Share!

What was the thing that made you finally 'get' JavaScript?

mogwai — Tue, 08 Oct 2019 00:35:09 +0000

Over the course of my learnings in different other disciplines, I've found (after the fact) that understanding one fundamental thing is what it took for everything else in the entire discipline to start making sense to me.

As an example: I struggled with transitioning from CorelDraw to Photoshop for a long time because I didn't intuitively get the 'layer' system of Photoshop (CorelDraw, at the time - dunno if that's still the case - just gave you one workspace and you moved things about relative to each other using 'Align' settings.

I struggled with CSS until I understood the Box Model (margin vs padding vs border), and now I can theoretically understand the other things and where they fit.

With JavaScript, I'm wondering what that 'smallest unit of understanding is'? It feels like it should be functions, but despite understanding functions, it took me a while to understand callbacks, and after understanding callbacks, it took me a while to understand eventHandlers, and so on.

Curious about the experiences of more advanced JavaScript users: what was that crucial turning point for you?

All responses welcome!