If you can't explain it simply, you don't understand it well enough.
-- Albert Einstein
Explain me like I'm five is the best tag on DEV.to and you should definitely follow it
#explainlikeimfive
I have compiled for you some incredibly pedagogical answers on this website. Specifically I selected answers that were enlightening yet concise, and that explained with words only - no code.
There are lots of great content here, so 🔖 bookmark the article if you want to read it when you have more time.
Without further ado, here is the selection:
- DNS
- TCP
- Websockets
- GraphQL
- What is programming?
- What is a programming language?
- GitHub
- Recursion
- Dependency Injection
- Optionals
- Promises
- Async Await
- Open-Source
- Smoke Testing
- Vue
- React
- Redux
- What is DevOps?
- CI / CD
- Containers
- Docker & Kubernetes
Developer roles
Think of a restaurant. You have greeters (CDNs) and hostesses (reverse proxies) to direct customers (users) to their seats.
When they get there there are servers (FrontEnd Devs) who provide the customers a pleasurable experience (UX) as well as eserve them food (data).
In the back you have cooks (BackEnd Devs) doing prep work, dishwashers (SREs) making sure everything is clean and ready, as well as Kitchen Managers (DevOps) to ensure everything in the back is setup to run smoothly.
SPAs operate like a buffet in that they leave more work for the customers to do themselves and put more emphasis on the FrontEnd.
Where do FullStack devs fit in. They're the restaurant managers. They can fit into -- and accel at -- any role b/c they have likely worked in every role at one point or another.
It takes a lot of work to get good enough to be a FullStack dev. So much so that some other types of devs deny that they even exist.
The truth is, the hardest part about becoming a legit FullStack dev is pushing back against your employer so they don't keep you pigeonholed into a very narrow role.
Many devs are perfectly happy to get paid a lot to work a narrowly defined role. Pursuing FullStack is the hard path and the sacrifice in time/effort to get there may not be worth it.
Like every restaurant wants a badass restaurant manager like Gordon Ramsey, companies would really love to have badass FullStack devs on their team.
But! Very few companies will invest the time and resources to raise a dev to that level.
FullStack devs have a lot more freedom to migrate elsewhere if the work conditions are bad and they're very difficult and costly to replace.
FullStack devs have the capability to raise everybody up. But companies don't want to raise devs up to FullStack status.
Networking
DNS
If you're familiar with a modern smart phone with a "contact list" or "phone book", ask yourself when the last time you've had to recall the actual digits of the phone number are for a friend/family member. Hardly? If ever?
The Internet is made up of IP (Internet Protocol) addresses, the phone numbers of the internet -- an address is simply the location representing an entity and/or resource. It's hard to remember compared to your friend's name or the URL of a site, like Dev.to whose IP from where I am, resolves to 151.101.130.217. That would be difficult to remember each time I wanted to visit this site.
A DNS aka domain name service, provides translation of the URL (top-level domain) to an IP address in a decentralized, semi-federated, fashion that provides essentially a map to take what we can remember and translate it to something that we don't (the actual IP address)
TCP
You and a friend need to share a toy:
You ask a friend if he can play with the toy.
Your friend asks you if you actually asked him for the toy.
You tell your friend that you asked for that toy.
He gives you the toy.
UDP:
- Your friend throws a toy at you and walks away.
Websockets
You have a agreement with your best friend that she'll help with your math homework when you're stuck.
When you have a question, you call her, wait for her to answer, then ask your question, and listen while she replies. Then she hangs up and you carry on with your homework.
Most evenings, you call her a few times over the course of an hour or so. Sometimes she's too busy to answer, so you hang up, twiddle your thumbs and try in a few minutes.
But some evenings, homework is too hard, and you're practically calling her every five minutes. Although she doesn't mind helping you, neither of you are happy about the constant process of dialling her, waiting for her to answer, and hanging up, only to do the same thing a few minutes later.
Finally you settle upon a sane solution. You call her, and keep the line open. There's silence while you're working on your own, but when you have a question, you just have to start speaking and she can already hear you. When your homework is over, you can hang up for the evening.
Your friend is the server, you're the browser app, the call is a network connection and keeping the line open after calling is a websocket connection.
GraphQL
It's lunchtime at school and they're serving your favorite meal: Meatloaf and mashed potatoes.
You really like the meatloaf and mashed potatoes part the most, but you're a good kid so you know you need to eat your peas and carrots. You are excited about the corn and of course, the gravy.
But you don't want your plate to be covered in veggies, yuck! So you need to be specific about what you ask for. You need two scoops of mashed potatoes, a big slice of meatloaf, half an ear of corn, and about a fistful of peas and carrots. But communicating all this to the cafeteria chef is a mouthful.
That's why you use one of these:
It's a GraphQL tray. It shows the chef exactly the portions you need and all you have to do is hand over the tray. The chef is going to then scoop out the portions from their big Mongo vats of meat, potatoes and the rest. Some chefs use Postgres tubs. Maria and Cassandra brand tubs are also popular in some school districts. But none of that really matters to you. It might matter if you had to give the chef specific instructions, but it's his job to figure out how to scoop out the mashed potatoes and fit the into the shape of your tray.
Some cafeterias don't let you use a tray to get your food, and you have to come back for each thing you want.
For a while the cafeteria workers were RESTing easy with this system which was simpler than other SOAPy systems and is still perfectly useful for a lot of cafeterias. But this district thought that that was getting a bit chaotic and that's why they started letting kids bring trays to get all the food they need without having to make a bunch of trips or have to explain to the chef exactly how much of each they need.
The kids seem to be happy with the new system.
Programming
What is programming?
I taught 2nd graders the concept of programming by having them design and build a peanut butter and jelly sandwich.
Requirements: bread, pb, jelly, knife, plate, etc (have them on hand, but hidden, then have the class list what is needed)
Program: have one group list the steps to build it
Test: have another group follow the "program" literally
So, in my case, the first step in the program was to spread the peanut butter on the bread. We immediately found the first bug. The bread was still in a bag - it had to be opened and taken out and put in the plate. The peanut butter had was unopened, etc. Go back and iterate on the program until they get it right.
It gives them a great feel for how detailed a program needs to be, and that the computer only follows the instructions you give it.
What is a programming language?
I’ve always thought of programming as language.
In theory we are doing the same job as an ambassador, speaking the language asking for things. Solving culture specific disputes etc.
Except we are talking to computers, not people, and culture in this case could be patterns, frameworks applications, systems etc.
Incidentally it’s also why programming have been getting more verbal I believe.
GitHub
Ooooh when I first was learning about github/git an awesome analogy was taught to me - so I can't take credit for it (unfortunately)!
Git is like saving multiple drafts of written papers.
Github is a social media hub for those multiple drafts of papers that other people can view, work on, and collaborate on!
Recursion
Do you know Matryoshka dolls?
When you open a doll, you find another doll inside, and when you open that one, there's another one inside. The act of doing this is called recursion. Let's write code for that.
function openDoll(doll) {
if(doll.isEmpty()) {
return doll;
}
openDoll(doll.open());
}
Recursion is a way of doing an operation over a set of values, where each value is related to the previous one, without iterating or using loops.
</div>
Dependency Injection
When you go and get things out of the refrigerator for yourself, you can cause problems. You might leave the door open, you might get something Mommy or Daddy doesn't want you to have. You might even be looking for something we don't even have or which has expired.
What you should be doing is stating a need, "I need something to drink with lunch," and then we will make sure you have something when you sit down to eat.
Optionals
Suppose you have a labeled box which can hold anything you like. On the label you write that the box may or may not be empty, along with what kind of thing you will put in the box (like coffee cup).
You can then give this box to other people and they know that the box very well could be empty or it could contain a coffee cup. Therefore they need to prepare for the case where the box is full and for when the box is empty.
People can always check if the box is empty, pull the coffee cup from the box, do something with the coffee cup in the box but keep it in the box, etc.
- Box:
Optional<T>(also calledOptionin other langs like Scala) - Coffee cup: Object contained in
Optionalof typeT - Box label: type signature
- Giving the box to other people: returning object of type
Optional<T> - Check if box is empty:
Optional::isPresent - Pull the coffee cup from the box:
Optional::get - Do something with the coffee cup in the box:
Optional::map
Optionals are a handy explicit way of representing values which may or may not be present (basically it is meant to replace returning null)
Promises
Like you are five? Ok....
You ask your mum if you can have some sweets later. She can either resolve sweets ( yes you can have some), or reject your request (no sweets for you. You’ve been naughty).
When it gets to later, if her promise resolved (ie she said you can have some) THEN you can eat them. Otherwise, you have to CATCH the tears you cry because you can’t eat sweets. Simple, huh?
A promise contains a resolve and reject. When it is actually called (the function is invoked), if it resolves, use THEN, or CATCH the rejection.
Async Await
I have a reputation to uphold here: stackoverflow.com/a/1638961/31899 So let me give it a shot. Ahem! :)
I am your faithful dog JS. I love you with all my heart, but normally when you go off to school. I go do other stuff. I find React the cat and bark at him. That's fun because he's getting really old. I nap. I eat. I drive the dreaded "mail man" away from our house. Then, when you get home again, we play! Hooray!
But today, you said, "Await me and I will give you this bone." So I have not moved. I am a good dog. I am a very good dog. I will stay here and not do anything else until you get back and then I will get the bone and we will play!
That, is Async/Await for a five year old.
Methodologies
Open-Source
Waterfall: you're hired to build a house. the client tells you how many rooms he needs, how many windows, etc. then you build a house. then client tells you that he needs to use a living room as a plane hangar and the bedroom should be painted in purple
Scrum: you're hired to build a house. client comes by every week to tell you what he likes and doesn't like so you can make changes before it's too late. sometimes the client comes in the middle of the week and tells you that he's showing the house to his friends tomorrow and it would be nice if there was a fireplace in the living room. and most of the time the client isn't interested in technical details so spending a week making pillars to support the second floor is not a good idea because you'll have nothing to show
Smoke Testing
Great question! This one really got me thinking, here it goes.
For your upcoming birthday, you ask your parents to buy you a Lego 1989 Batmobile.
The day finally arrives, and you are presented with a wrapped package, but they don't tell you what's inside. It is a surprise.
Your excitement rises, but before you get your hopes up - you examine the package.
Judging by the shape and size of the package, it matches the size of the 3306 piece box for the Lego 1989 Batmobile. Smoke test 1 passed.
You take the present in your hand and feel its weight. Its not too heavy, not too light. Just about right for a box of Legos. Smoke test 2, passed.
You decide to give it one final test before calling it. You shake the box and hear the familiar sound of Legos inside. Smoke test 3, passed!
Now you are fairly confident that the present is some kind of Lego, but you cannot really be sure if it is the Batmobile, so you start with user acceptance testing, unwrapping the present and validating the contents of the box.
Had any of the smoke tests failed, you would have immediately known that the present is not what you asked for, without investing time in detailed testing.
Frameworks
Vue
Vue is like a cameleon. Whatever the environment, it adapts. Forest, mountain, plain desert, etc... It evolves and scales accordingly. You can use a simple script to include it in a static website and create a Vue component for only the login button for instance (send a login/password to the server, receive a token, store it in localstorage). Or create a full Vue application involving a router (VueRouter), a more complex data exchange system (VueX), with reusable components just like React. You can do 15%, 50% a whole application in Vue due to its incredibly simple integration. It uses concepts that are known to Web developers, no new syntax for writing Virtual DOM: it is just HTML that is cleverly converted to JavaScript. It just feels like writing yet another HTML page, with some JavaScript and CSS. But it was a Vue component! Haha you just got pranked...
React
A React component is essentially just a function that returns HTML. It can accept arguments if necessary, in the form of props, and can use those to determine what it renders.
While a component can technically be a class, it still makes more sense to think of it as a function, and with the advent of Hooks it's probably not necessary to build any one component as a class nowadays.
Redux
Imagine standing in front of a store window. With nothing set up, the state of the window is empty. The manager wants a fancy display every morning, so you put a few fancy looking empty shelves behind the glass. Later, the manager gets the idea to show off new products when they come in, so for each type of product, you need to decide how and where to place it on one of the shelves, what to do when there are too many items, no items of a type, and so on. Let's call this the setup. This happens every day after you get to work so you can see the shelves at the beginning of the day to make this first update.
Again, the manager has something to ask you. Now, it is possible to get updates during the day on changes to the products and new items in the store, so instead of just getting a list once of all the changes, each type and each product can get a change during your shift at work. You make sure that you can either reach out to the manager or they can push over to you any kind of update for you to run through the setup you created before.
The window is the store, having the fancy shelves is an initial state, getting an update from the manager is an action, the setup are the reducers, and the process of getting the update are subscriptions.
DevOps
What is DevOps?
It is winter, and one cold evening, a fairy visits you.
"You've got three wishes", the fairy says.
"I want a machine that throws snowballs", you say.
And puff, there's the machine. And the fairy disappears.
You invite your friend Simone over, and tell her what happened.
"Wow", says Simone. "How do you use the machine?"
"I have no idea. It's got like 1000 buttons.
It is way to complicated."
"Oh my god", says Simone. "What a pity."
That night, you sit in your room crying.
Suddenly, the fairy appears again.
"What's up? Why are you crying?"
"Well, you gave me that awesome machine, but I can't use it.
Simone can't use it either. It's too complicated."
"Well, you didn't say it needs to be simple. But remember.
You've got 2 wishes left."
"Ok. My friend Simone and me, we want to know which buttons to press. So that the machine builds snowballs, and throws them."
"Your wish is my command", says the fairy, and disappears.
You invite Simone over. But now, there is another problem:
you know exactly which buttons to press to make the machine build a snowball. But only that. You're kind of like the developer of snowballs.
Your friend Simone knows which buttons to press to make the machine throw a snowball. But only that. She's kind of like the operator of the machine.
If Simone and you work together, you can make the machine build and throw a snowball. But neither of you knows the whole story. Neither of you can use the machine alone. You always need Simone around. And while you can build snowballs that look really good, Simone often complains that they are too heavy and don't fly far enough.
But you're friends. You observe each other, and talk about the machine a lot. Because it's the most fascinating thing you know. And over time, you learn which buttons to press to operate the machine. And Simone learns to build a snowball with the machine.
You were a developer, and learned to operate the machine.
Simone was an operator, and learned to develop snowballs.
So now both of you are a developer, and an operator. You are DevOps.
One winter evening, you visit Simone.
Suddenly, the fairy appears again.
"You've got one whish left", the fairy says.
"It's your turn", you say to Simone.
Simone sits on her chair silently for a minute.
Suddenly, she jumps up.
And with a smile on her face, she says:
"I want a button on the machine that builds and throws a snowball.
And both my friend here and I can use it.
Don't trick us again. We are DevOps after all."
CI / CD
CI
==Automating the running of code, tests, and or builds on a separate machine
( 𝝀,✅,🔨) 🔜💻🔜👌🏾
Good CI will prevent 👇🏽
CD
==Automating the deployment of code to a server
𝝀 🔜💻
Good CD will prevent 👇🏽
It's important to note that Continuous Delivery and Continuous Deployment are not the same thing. The two get conflated and sometimes used wrong interchangeably. Continuous Deployment specifically means deploying straight to production.
When CI/CD is put into practice it creates automation. When automation works as it is intended, it's magical.
Containers
Five years old? Okey.
A Container is a box with all the pieces required to use a single toy. You can have multiple containers to combine your toys and create more better toys. Some boxes only have the pieces and you need to have multiple boxes to create a single toy.
A virtual machine is like having a box with the pieces to use a toy, but you all need eat your vegetables first each time you want to use the toy.
Docker is the name of a possible boxes where your toy can come. Is the most used and looks like a whale.
Azure Container Service and similar options from AWS and GCP are glue you can use to combine your Docker boxes to create better toys
Docker & Kubernetes
Docker images: think of them as blueprints, for example a blueprint for creating a cow.
Docker daemon: think of it as corral for letting the cows run wild.
Docker swarm (and Kubernetes): think of it as a rancher that manages the cows.
Let's say you create many cows (docker containers) with the same blueprint (docker image) and let the cows do their thing in the corral (docker daemon).
You have all the dairy cows in one place but it's getting pretty crowded and they're eating all the stuff around them (resources) and you need to redistribute them to other areas or they will die.
You hire the rancher named Kubernetes and tell him of all the other corrals (nodes). The rancher checks each corrals capacities (resources) that they can handle. The rancher will take care of moving the cows around when the corrals are low on food to more abundant areas and the rancher will also take care of creating new cows for you if cows die for any reason.
The rancher is responsible optimizing your cattle ranch as efficient as possible and making it scale as long as you tell him of all the locations that he's allowed to move the cows to. You can also tell him to only grow the ranch to a certain size or to dynamically scale larger to produce more milk based on the dairy consumption demand by the population (auto-scaling).
Did I miss something?
If you have found other explanations which are enlightening and concise, and which use only analogies, words and images, no code, please add them in the comments :)
That was it, thanks for reading! If you’d like to ask a reader question, you can do so at my “ask me” page on https://jmfayard.dev/
Top comments (6)
The authors of those awesome explanations like I'm five are @evanplaice @wulymammoth @bizzy237 @buzzingbuzzer @xtrp @evanoman @sergiodxa @javascripterika @georgeoffley @ben @johnmunsch @triplejdev @aminnairi @derek @matthewbdaly @rkichenama @miguelmota @dansherpa @sebbdk
Thanks a lot friends!
Fabulous roundup
No, YOU are breathtaking!
I'm bookmarking this for when I have trouble understanding any requrements haha
Thanks
Here is my "Like I'm five" explanation of blockchain.
dev.to/demetrakopetros/explain-blo...