DEV Community: Akira

Explaining Like I'm Five: Connecting Front and Backend Systems

Akira — Thu, 14 Oct 2021 04:21:09 +0000

A large missing for myself and probably others is an accurate mental model of how frontend and backend systems interplay with each other. As a result, a lot of mental "soup" comes into play when it comes time to get your React/Vue/Angular talking to a backend system. This becomes especially problematic when you layer something as complex as an OAuth Auth Code Grant or other Auth systems on top of that.

So how can one think of frontend and backend systems communicating accurately while cutting out jargon and confusion?

Let's borrow from Richard Feynman, a theoretical physicist whose genius lied not only in his discoveries in the various fields of physics, but in his ability to explain deeply technical concepts to everyday people. He developed a technique where someone explains something to themselves in simple terms to discover gaps in their knowledge; an "Explain Like I'm Five", if you will.

Before reading ahead, pause and try your best to explain how a frontend and backend system communicate to yourself as if you are five years old. Don't use jargon (a five year old doesn't know what an API is), and keep this grounded in daily examples a five year old uses (mom's smartphone, a toy train, playing outside).

What did you come up with? Here's what I said:

When your mom comes to pick you up from school, first she has to get in her car. When she gets in her car, she does a couple of things: she opens the door, puts the key in the starter, turns on the engine, and then cranks up the radio to her favorite tunes! All of that is like how a frontend and backend work together. If your mom is a website's 'frontend', she is making her car, the websites 'backend' do things for her so that she can move on to the next stage of her journey for picking you up. For example, she tells the car to turn 'on' by putting her key in the ignition and turning it. She tells the radio to turn 'on' by pushing the on button and turning it up. In the same way, a website's frontend tells the backend what it wants, and the backend responds by giving the frontend what it wants. If the car didn't turn on, then it would be broken, right? The same can be said about the website frontend and backend - if the request from the frontend isn't fulfilled, something is probably wrong with the backend. Or if your mom tried to turn on her car with a banana instead of a key, that would be like the frontend of a website being broken so that the backend doesn't understand what she wants from it.

How was that? A little wordy and bizarre, but it showed me a huge gap in my own understanding: the fact that the implementation of that front and back end system communicating to me, is still a little fuzzy. The magic that happens to make the car actually turn on when the key is turned to me, still seems like a black box. But at least now I know what to drill - that very same implementation. And from drilling that implementation, I can refine my mental model.

Hot Tips to Get the Most from your Bootcamp

Akira — Fri, 13 Aug 2021 01:56:00 +0000

This is for my students, and for anyone who is embarking on learning to code, whether in a bootcamp, self-taught, or university.

Make flashcards of core concepts/new vocab/code snippets you see again and again. Use index cards, or better yet, Anki
Go to office hours, even if you fully understand the material, or conversely, even if you are completely lost.
Write down every error message you get and how you solved it.
Ask questions to the point of feeling obnoxious, then ask more questions.
Read the error messages/stacktrace. They are your guideposts.
Work on homework in groups.
Write about what you are learning. Publish it on Twitter.
Work in short sessions, 30 minutes at a time.
Have a time where you turn your laptop off for the night.
Do not allow yourself to be frustrated. Take a break before that happens.
Ask for extensions, if you need them!
Answer other people's questions. Concentrate on forming a collaborative dialogue with them, instead of having the 'right answer'.
Do not procrastinate. Often the hardest part is getting started. Just work on the thing for five minutes.
Anything worth doing is worth doing poorly. Try the 70% rule: can you get this thing to work 70% of the way?
Your new favorite phrase is 'I don't know.' Use it!
It is ok and expected to use Google, a lot. It is not cheating.
Seek positive encouragement from friends, family, or even the internet.
There are often many right ways to do something. It is ok if your way is different than your colleague's.
There are pieces of code, and then there are finished projects. Programming is everything that happens in between.
The best way to learn to program is not 'to build projects', necessarily. But that is a very efficient way.
Teach others. Take on a mentee.

Photo by Tudor Baciu on Unsplash

Setting up a JavaScript project

Akira — Fri, 12 Mar 2021 21:07:54 +0000

If you're new to JS, you've probably been hit with some confusion around package.json files, why you can't just run JS files from your terminal without hitting MODULE_NOT_FOUND errors, and wondering what the deal is with needing to npm install when you first clone a seemingly simple app to your local machine. I know I was, and so I'm going to demystify setting up a JS project into is separate "whys".

JavaScript is a little different than other languages in that it runs in the browser. That's great if you're simply developing JavaScript to run exclusively in the browser, but what if you want to TDD your JavaScript and run it on your local machine? What if you want to write server-side JavaScript that runs on a server? This is where Node steps in.

Node is a JavaScript runtime environment that requires some extra configuration in order to work. It needs to know metadata about your app before it can run, at a bare minimum, it needs to know the name of the app and its version. It reads this metadata from a file called package.json, and without that file, Node can't run your JavaScript code. So in order to run JavaScript anywhere outside of the browser relying on Node, you need to make a package.json file.

The way to do this is to run npm init from your command line.

You will see a message starting with This utility will walk you through creating a package.json file. It only covers the most common items, and tries to guess sensible defaults.

Several questions will pop up, for example asking what license it is under, the name of who made it, entry points, and other things. You can fill in as much or as little of this as you'd like, but the package.json will still create even if you leave all the optional fields blank.

In the end, you'll end up with a file that looks something like this:

{
  "name": "blog",
  "version": "1.0.0",
  "description": "a test package",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "Akira Brand",
  "license": "MIT"
}

Now, you need to install your dependencies. Run npm install + libraryName for any external libraries you are using in your project. This will add their metadata to the package.json file, so that whomever ends up running your project on their local machine can run npm install and have all the dependencies installed together so that your project can run.

For example, if I need to use express in my app, I would now run npm install express. Then the package.json file looks like this:

{
  "name": "blog",
  "version": "1.0.0",
  "description": "a test package",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "Akira Brand",
  "license": "MIT",
  "dependencies": {
    "express": "^4.17.1"
  }
}

Notice there is now an express version at the end of the package.json file.

It's good to note now that two more files/folders have arrived in your filetree, package-lock.json and node_modules. Those are different topics for a different post, but just know that they help manage the tooling around the npm packages you've just installed. Node_modules in particular can get really large, so use good judgment on committing it to GitHub along with your project!

The node documentation does a great job of explaining package.json in further detail.

Happy projecting!

Lessons Learned From Singing Opera

Akira — Tue, 26 Jan 2021 20:35:41 +0000

You learn a lot being a high-performance oriented classical musician. Here are some lessons I learned along the way, especially in how I needed to practice so methodically to have any hope of making progress, which may be helpful to people as they learn to code.

1) Isolate small, difficult sections

If you are having difficulty in a section of music, you don't go back and practice the entire piece over and over again. you isolate the measure (which is a very tiny segment!) of music you are most struggling with and practice that. You work smaller and smaller even until you can play it without getting it wrong. The same goes for coding. If you're struggling with a leetcode exercise, are you struggling with arrays? Objects? Maybe control flow? Go back and practice some short exercises focused on that one thing you are struggling with until you absolutely cannot get them wrong.

2) Practice until you can't get it wrong.

Don't practice a section of music until you get it right. Practice it until you can't get it wrong. The same goes for difficult concepts in code. Don't just do an array exercise until you're like "oh, ok I got one right, I guess I understand arrays now." Do array exercises until you literally can do them in your sleep. That's not to say you need to memorize every array method ever, but you should understand in-depth how arrays work.

3) Simple and good is better than complex and a trainwreck.

When singers audition, there is a lot of temptation to do a big, showy, frilly piece; however, those pieces can be exceptionally difficult and not necessarily showcase the singer in the best light. It's better to do a simple piece in the audition, but executed flawlessly, than a showy piece with lots of mistakes. Same with code, I think, is that its better to have solid, amazing basics and stretch from there in your work (of course, balancing this with pushing yourself forward is important), rather than biting off huge chunks of very complex projects that are way beyond your skillset and will ultimately lead you to get discouraged.

4) At the end of the day, you're telling a story.

I think this one is the most ethereal tip, but in classical music, as obsessive as it is on technical perfection (and I'm not kidding when I say perfection), your job is to tell a story through the sound of your voice and your technical chops serve that end. I think the same thing in code is important; keeping in mind that working code is better than perfect and that if you can't serve the end-user with your work, then something is off.

And yes, you can hear me sing; in a live performance of Poulenc's Gloria:)

Great places to meld music and code

Akira — Thu, 24 Dec 2020 02:38:52 +0000

https://earsketch.gatech.edu/earsketch2/

https://teropa.info/blog/2016/07/28/javascript-systems-music.html

https://sonic-pi.net/

Self-note: Try this to write a commit message when you're stuck in VIM

Akira — Fri, 13 Nov 2020 03:18:01 +0000

Maybe this will help you.

When git pulling master into a feature branch, you may get this error:

Merge branch 'master' of xxxxxxxx into xxxxxxxxx

Please enter a commit message to explain why this merge is necessary,

especially if it merges an updated upstream into a topic branch.

Ah, stuck in VIM.

Here's what I did. It seemed to work.

cntrl x + cntrl v + commit message + :wq

If that doesn't help, try this thread from stackoverflow https://stackoverflow.com/questions/19085807/please-enter-a-commit-message-to-explain-why-this-merge-is-necessary-especially

godspeed

Notes to Myself - First Dev Job Reflections

Akira — Sat, 31 Oct 2020 20:52:39 +0000

I've spent far more time fixing issues than I have spent time writing original code
Bugs are a thing and will always be a thing
Holy god having a monitor and keyboard is worth the cost
I guess I'm getting paid to be super uncomfortable all the time now
There are days I just don't wanna; and that's ok, I have to do it anyway, and if I do it, the suckage goes away after about 20 minutes.
I'm reading far more code than I expected: for every line of code I write, I probably read 5-20 lines of other code
I read way more english than I ever thought I would, too
Not every article you find on the internet about something is helpful
Once you get past very very basic things in code, the resources become far fewer in between, more full of jargon, and considerably less accurate, overall.
I see a lot of plagiarism and its gross. Don't steal other people's code examples or articles w/o attribution, yo.
Graphs, visuals, pictures, and color-coded anything is my friend.
If you can make coding funny and human it takes a lot of the suck out of it when you're struggling
Asking questions is ok and no one thinks I'm an idiot.
I should ask questions sooner than I do.
Just cause I'm new, doesn't mean I'm wrong
Its better to feel stupid in front of other people and figure something out than feel stupid in private and not make progress
A good team will make or break your experience, cause this job is HARD
Being physically active is a non-negotiable
I'm SO glad I didn't give up
Getting paid this much is a mental adjustment, it helps to reframe your salary as being compensated for business value-added. (hint---you're adding a lot of business value.)
Don't ever take side gigs that don't pay a regular developer rate, you won't be taken seriously and you won't be able to do your best work.
This is the most fulfilling job I've ever had.

Notes to myself - the DOM

Akira — Sat, 31 Oct 2020 20:43:30 +0000

Document Object Model - The DOM
The DOM is a cross-platform browser interface that treats an HTML or XML document as a tree structure, with each node is treated as an object that is part of a document. So, for example, in an HTML document that looks like this:

How are you doing today?

The tag is treated as its own element, that contains two other elements, an

element and a

element. Those elements have text inside of them, but the texts themselves are not elements, they are merely what the

and

elements contain.

You can use the DOM to hook onto these separate elements and manipulate the data inside of them. So, for example, if I want to change the text inside the

element, I can do so by hooking onto that particular node via its id, like so:

var element = document.getElementById(header);
element.innerHTML = "Goodbye!"
Notice that I used JavaScript to dynamically update the contents of the HTML node. The reason I can do that is the DOM has traversed my HTML document and made object nodes for each object in my HTML file. Pretty neat!

JS Array Stuffy Stuff

Akira — Mon, 05 Oct 2020 20:46:07 +0000

Honestly, maybe these array methods can help me understand stack. (pushing and popping things off a stack frame, anyone?)

let numbers = [1, 2, 3, 4, 5];

push

Adds an element to the end of an array
numbers.push(6); numbers [1, 2, 3, 4, 5, 6]

pop

Pops the last element off of the array and returns it
numbers.pop(); 6 numbers [1, 2, 3, 4, 5]

slice

Slices off whatever you want from index x UP TO index y (slice(x, y)), and returns it.
*Doesn't change the state of the original array
numbers.slice(0, 2); [1, 2] numbers [1, 2, 3, 4, 5]

splice

Deletes elements from index x for the number of places specified by y, returns the deleted element. (ie. array.splice(x, y)

numbers.splice(1, 2); [2, 3] numbers [1, 4, 5]

Oh my God, WTF is Stack

Akira — Fri, 02 Oct 2020 14:54:43 +0000

I have a short definition I'm writing.

Is this right?? Close??? Am I getting warmer???

"The stack is a temporary data structure used to temporarily store and retrieve data; and the heap is a temporary storage space that holds objects, etc, that we use in our program, it is dynamic and can change. The stack can also refer to the area allocated in memory where the stack data is stored."

Comments and corrections most welcome!

How Scope Works & Why You Should Care

Akira — Tue, 22 Sep 2020 22:07:46 +0000

Scope is one of those nasty components of programming which makes all the difference between a lifetime of misery as a programmer and a lifetime of misery but about things other than scope as a programmer. But in laymen's terms, scope boils down to defining where you can access data in your codebase.

I'll say that again.

Scope comes down to where data can be accessed in your codebase.

Why does that matter? Well, imagine a real world-scenario. Let's say that the codebase is your house, the data are things in your house, and the scope is where those things are stored in your house.

If everything in your house could be stored and accessed anywhere else in your house, you'd soon have an incredibly messy, disorganized house where it would take forever to find and use anything. Imagine a house where you have toothbrushes in your silverware drawer, underwear in your couch cushions, and artwork in your dresser. What a mess, right? Living there would soon become untenable.

🤫 Side note

If your house is actually like this,

I feels it
Marie Kondo can save you.

ANYWAY.

The same principle of an organized, accessible house, goes for scope.

If all my data was accessible everywhere in my program, I'd quickly have a mess of exposed variables that I'd have to spend hours searching for to use, and a completely overwhelmed garbage collector which wouldn't be able to keep track of what matters and what doesn't. It's not that it's impossible to have everything in the global scope, it's just that its a really bad idea.

There are three common types of scope in JS:

Local
Global
Block Scope.

Global Scope

Global scope allows data (stored in a variable) to be accessed anywhere in your program. It can also be changed anywhere in your program so honestly its a pretty terrible idea to use global variables unless you're by default, declaring them with CONST so they can't be changed. You can make data global by setting it to a variable outside of a function. You can only use var and const to declare global variables.

const someStuff = "things"

console.log(someStuff)
>> "things"

function sayStuff(){
  console.log(someStuff);
};

sayStuff()
>> "things"

As you can see, this globally scoped variable, someStuff, is accessible inside and outside of any function in my program.

Local Scope

Local scope allows data to be accessed anywhere INSIDE the function in which it was declared. The variable is still mutable, but since the variable is tied to it's function, it won't affect your entire program in unforeseen, horrific ways. Once the function finishes firing, the variable and the data contained within it are garbage collected and are no more; until you call said function again.

function sayHello(){
  var greeting = "Hello!"
  console.log(greeting);
}

sayHello()
>>"Hello!"

console.log(greeting)
>> ReferenceError: greeting is not defined

So, we can see here that the variable greeting exists only inside the function sayHello() as that is where I define it; once I tried to call the variable outside of the function; it no longer existed. So we can say var greeting is LOCALLY scoped to the function sayHello()

Block Scope

Last but not least is block scope. Data created inside a block scope are only available inside the block of the function in which they were created. This is great when you have short-term data you want to use in only very specific cases; like if an if statement returns true.

function rememberMe(name){
  if(name.includes("Akira")){
    let recognition = `Omg, hi, ${name}! I remember you!`
    console.log(recognition);
  } else {
    let recognition = `I'm sorry, I don't remember you, ${name}...`
    console.log(recognition)
  };
}

As you can see here, the let keyword let me use the variable name recognition only within its block. After the first block ended, I could set a new block variable with let and the same variable name of recognition, because JavaScript's garbage collector wiped out that block variable after the block finished firing. So, here the variables let recognition were BLOCK scoped to their particular block.

side note: a block is a fancy way to say anything between a pair of curly braces.

So, there you have it! Scopes demystified.

Drop a comment or a correction below, I'm happy to hear constructive feedback!

How-To Annoy Your Senator into NOT Voting in RBG's Replacement Until After The Election

Akira — Sat, 19 Sep 2020 03:49:08 +0000

If you are concerned about a replacement of RBG being made before the election, I urge you to call your senator first thing tomorrow and advocate for waiting to vote on Ruth Bader Ginsburg’s replacement until after the election is over.

Then do it literally as often as you can/want to.

You can find your senator’s number here.

And here is an excellent article on how to have a productive conversation with your legislator’s office, regardless of the issue.

Godspeed. Dissent with fervor.