DEV Community: Lee

Stupid Short: Bash's |, >, >>, <, 2>>, 2> Operators

Lee — Sat, 14 Sep 2019 17:18:19 +0000

This is meant to be a stupid-short introductory and reference guide for quickly understanding these Bash operators: >, 1>, >>, 1>>, <, 2>>, 2>>. This is primarily done with one sentence and an example.

This guide assumes...

... you are using Bash terminal. (OS is not relevant)
... you are familiar with CLI usage and navigation.
... you are familiar with the concepts of Bash program arguments/flags/options.

Mostly-Short Explanation of Fundamentals
Vocab for Stupid-Short List
Stupid-Short Explanations List

Note: For this blog, we will assume we are only writing and reading files.

Mostly-Short Fundamentals

Admittedly, I never bothered to look up what the | > >> and < operators do in Linux until well into my programming career. If you've ever followed GitHub's instructions for adding an SSH key to your account, then you've already used are called Redirect Operators!

Fundamentals of Programs

A program has three input and output streams with their corresponding number. It has a standard input (STDIN)(0), standard output (STDOUT)(1), and standard error (STDERR)(2).

Note: My beautiful picture is only showing convention. If you build your own program, you can effectively name streams whatever you'd like and stream to whatever output. You don't know that though. If you do, act like you don't and read on.

Example: Let's take the good ol' ls. When you ls with no error, the input is ./ (Bash assumes empty is current directory), the stdout is the list of directories you then see, and the stderr is nothing (Because there's no error to catch).

Programs stream both stdout and stderr; this is because it's not "stdout or stderr", it's "stdout and stderr". Running ls presentDir notPresentDir, you can see both stdout and stderr.

By default, stdout, stderr, and stdin are all in the terminal. With these redirection operators, we're simply redirecting those streams elsewhere.

Vocab

"program": This is what executables are called in terminal. Every time you cd or ls, you're running a program.
cat: Program that prints the contents of a given file.
wc -w: Program that outputs the count of words in a file.
pbc: My alias for xclip -selection clipboard. For Mac folks, this is the exact same thing as pbcopy.
pbp: My alias for pasting clipboard.

Stupid-Short List

⭐️ The redirect operators have three numbers correlating with the output: 0 = input, 1 = output, 2 = error. If no number is given, this defaults to 1.
⭐️ If the file does not exist, these operators create the file.

`>` Write stdout to given file.

Sends stdout to a given file, instead of printing in the terminal.

$ ls -1 > list.txt

$ cat list.txt
lubbock.txt
odessa.txt
baird.txt

`>>` Appends stdout to given file.

Adds stdout to file contents, not replacing file contents.

$ echo "Flamingo" >> favorite-birds.txt

$ cat favorite-birds.txt
Cardinal
Penguin
Flamingo

`<` Redirects file as stdin

Passes the contents of a file as the stdin.
Example: If we use wc -w book.txt, the program will output the word count and the filename of book.txt (ex: 2394 book.txt).
If we use wc -w < book.txt we are "passing in" the contents of book.txt as the input, therefore wc -w < book.txt would return only the number (2394), as if we typed the whole thing into terminal.

$ wc -w book.txt
2394 book.txt

$ wc -w < book.txt
2394

`2>`: Redirect stderr to given file.

If there is an error, redirect the stderr to a file instead of printing in terminal.

$ ls cuteDogPics 2> example.txt

$ cat example.txt
ls: cuteDogPics: No such file or directory

`2>>`: Appends stderr to given file.

Exactly like >> and >, except with stderr.

$ cp ~/Documents/Reports/June2019.xlsx ~/Desktop 2>> ~/error.log

$ cat ~/error.log
cp: /Users/bananabrann/Reports/January2019.xlsx: No such file or directory
cp: /Users/bananabrann/Reports/March2019.xlsx: No such file or directory
cp: /Users/bananabrann/Reports/June2019.xlsx: No such file or directory

`|`: Use the stdout as stdin for the next program.

Use the stdout of the program left of the | as stdin to the program to the right.

$ ls -1
buffalo-gap.txt
abilene.txt
clyde.txt
lubbock.txt

$ ls -1 | head -2
buffalo-gap.txt
abilene.txt

Able to be daisy-chained

Using the |, we can ultimately chain as many programs as we'd like to achieve the desired result.
In the picture below, we take the stdout of the grep program and send it as the stdin of head and its arguments. We then send that stdout to the stdin of tail, then finally redirect the stdout to guestlist.txt.

Hope this helped someone, or sparked someone's interest to play around with these operators and research further on their own!

Happy Coding! 🍻

No Shame, Here's My First React Site

Lee — Sat, 23 Feb 2019 15:36:05 +0000

This past week, I worked on building a Would You Rather game with @RendonEls. I learned a lot about React, and definitely feel more comfortable with it after tackling this project.

However, a lot of times we only see others' highlight reels, so I figured I'd show off (and hide in the corner) my first full-CRUD site using React. No one is born a champion, so it's alright to have a bit of fun and briefly check out my Would You Rather game that isn't so production-ready. So hey, let's have some fun and look at all the things wrong!

Landing Page

When you first come on the site, you're presented with the homepage.

You have the ability to play, view stats, or go to options.

Playing the Game

Here is the play screen. Right now, the game isn't even playable, haha! But hey, it displays two random questions!

No way to select a question.
No next button.

Options - Create

After going into options, you can create a question. This part of the site is probably the part that looks the best, but is also the simplest.

Pressing submit neither redirects nor refreshes.
Navigating away, after submitting, does not show your question anywhere. You have to refresh manually no matter what page you go to. 😅

Options - Edit

Ah, the edit page. The bane of our existence, both on the back-end and front-end. In the end, it ended up being like 40 lines of code. This took us around 24 working hours to complete, but it works!

Clicking delete also immediately deletes the question, without refresh! 😃
Adding enough questions so it goes past the footer destroys the footer.

... And then you press edit.

Clicking edit on one will drop the boxes down for all.
Clicking submit updates them immediately within state, and doesn't refresh! 😃😃😃

That's it! I hope this sadistically inspires someone, or at least gets a half-smile from some veteran coders. May your bugs be short, and Happy Coding!

Deployed website:
http://dirty-fan.surge.sh/
Front-end Repo:
https://github.com/bananabrann/would-you-rather-frontend
Back-end Repo:
https://github.com/RendonEls/would-you-rather-backend

P.S. If you're feeling really ambitious, share us your first site ever!

Pierson L. Brannan

Coding, A Blue Collar Job?

Lee — Mon, 18 Feb 2019 02:16:49 +0000

Raising chickens in a rural area was something a part of my daily life. Moving into the city and jumping into coding, I have to admit: The same determination and hard work that drives rural Americans to success is the exact same I've seen in successful developers.

If you’ve never heard of this term, jobs that require manual labor are often called “blue collar,” and it’s been called this since 1924. These jobs can mainly be broken down into two categories: Unskilled, such as mining and warehouse, and Skilled, such as electricians and welders. Unskilled and skilled work blue-collar has been a major driving engine in the U.S. economy, and skilled blue-collar spurred the growth of the middle class.

The mindset we use when approaching a certain skill greatly impacts how fast or slow we might grow, or even the quality of the final output of that product. This mindset can be of efficiency, growth, quality, or whatever value that might drive you and that trade. I draw the resemblance with blue-collar work and coding because they both act on a tangible, physical output as opposed intellectual or efficiency outputs of the work from that such as lawyers and accountants.

The reasoning can go further when evaluating similarities in the market of coding and that of blue-collar work. With our older generations retiring, demand for skilled labor is at an all-time high, and companies are telling us they're willing to compensate. Let's look at plumbers, where the average in Chicago and NYC is now $70,000 a year. For more experienced plumbers, that number reportedly goes as high as $200,000! I'm sure you've heard of the same thing happening with developers. Bashing our head against our keyboard is grit not everyone is set up for, and difficult to place competent and skillful developers into the workforce. Developers with little to no experience are landing $70,000/yr or more jobs, and the sky is becoming the limit with more senior and experienced positions raking-in well over six digits nationally.

These stats do not mean there's a giant pot of gold for everyone that steps into software development. Like in blue-collar jobs, to reap the fruit of your own labor your skills and improvement must be accountable by only yourself.

The mindset that makes successful plumbers in NYC and Chicago is near identical of that of the developer, and I believe there are things to learn in improving our code skills from the lessons of those who use their hands.

Do you think of coding as blue-collar? Why or why not?

Thanks for reading, and happy coding!

I Ask: Do people actually say "MERN-stack?"

Lee — Tue, 29 Jan 2019 21:48:59 +0000

Have you ever heard the term "MERN-stack" used?
From your experience, would the majority of coders around you understand what that entails to someone's coding tools if they say they're a "MERN-stack developer?" What do you think about this?

MERN refers to Mongo, Express, React, and Node. It's a term I've started hearing early this month, and thought nothing of it other than a cool acronym to describe these toolsets. Then, I started hearing it called the "MERN-stack," and one or two "MERN-stack developers" and January passed on.

This is pure curiosity, and I'd be interested in reading your replies.

Thanks for your answers, and Happy Coding!
~bananabrann

Express Routing Walkthrough For Noobs: Pretend You're A Computer

Lee — Fri, 25 Jan 2019 01:25:06 +0000

Introductory
What's MVC?
What Happens When You Visit a Webpage
Become the Computer: A Roadmap, Routes
Become the Computer: A Roadmap, Controller Example
Conclusion

This Blog Contains:

Visualization of routing within Express
Basic, basic review of MVC
Does NOT contain explanation of Models or Controllers

INTRODUCTORY

So I’m learning how to code, and I’m holding on to the handlebars —get it?— for dear life. There’s so many “things,” with so much “stuff.” Along the way, my love of knowing what all the little files in my folders do is being blown out the window and swept away into the gutter to fall into the ocean to only be eaten by a shark. That shark is currently Express, Node, Handlebars, and somehow launching it at the moon hoping to catch the internet.

The biggest, baddest shark in the pond is Express. In particular, navigating between the files via routing. I'm starting to conquer the inner-understandings of it, and the best way that has helped me is to pretend I'm a computer. Beep boop!

This is very in the weeds when you're reading it, and is best explained in 10 seconds in-person, but this has been a very instrumental mindset in understanding how routes work within Express.

What's MVC?

MVC stands for Model, View, Controller. It's a way to organize our files within a project. We separate the files by what they do.

Model, what stuff is.
View, what stuff looks like.
Controller, what the stuff does.

There is no program to install, no uniform name, no nothin'. It's simply just a way we name and place a file for our own personal zen.

What Happens When You Visit A Website?

When you open your browser and type in a website, your browser submits what is called a GET request. This is one of four basic request types for data. With that GET request, the server of the website is "listening" to where you go. Because you decided to organize your files by MVC, our router is now responsible to linking your files together so that the correct response is served to the client!

Become A Computer: A Roadmap, Routes

The single-most thing that has helped me patch all of (mostly) Express, is to think about if I was a computer on the server-side. This is the fun part!

For reference in this example of computer roleplay, our relevant file structure will look this:

.
├── controllers
│   ├── application.js
│   ├── birds.js
│   ├── index.js
│   └── lizards.js
├── index.js
├── models
│   ├── Bird.js
│   ├── Lizard.js
├── routes
│   ├── birds.js
│   ├── index.js
│   └── lizards.js
└── views
    ├── birdsflying.hbs
    └── lizardscrawling.hbs

Your file structure of names, folders, conventions, might all be different. This is not a standard pattern, your routes can link anything to anything!

Our Journey Begins, Setting Up with index.js

As a highly advanced technological marvel, you need to be told a few things before you're ready to work. Who and what am I?

To do this, our index.js, with the main project folder, answers most of those questions.

Remember, we're the server!

const express = require("express");
// Cool, I'm going to be using Express today. I hope my user didn't forget to npm install express me!

const hbs = require("hbs");
// Looks like I'm also using Handlebars.

const app = express();
// Nice! When I see "app," I'm going to be calling the function named express.

const routes = require("./routes/index.js");
// Uh-huh... I see that when I call the variable "routes," I'm going to be shooting it over to the routes folder!

app.use(express.static("public"));
// Looks like I'll be serving "static" files today, such as CSS and JavaScript.

app.set("view engine", "hbs");
// Oh right, I'm supposed to use hbs when I go to display things.

app.use("/", routes);
// When I get something, I'll call the "routes" variable. Good thing I defined it above!

app.use(require("./routes/index.js"));
// I need the routes/index.js file, OR ELSE I QUIT. That'll show the user!

app.listen(3000, () => {
  console.log("server is running");
});
// Oh cool, I'm listening on port 3000.

Now that we know who we are, we're all ears for the user input!

Ground Zero, index.js

We have a request! Someone visited Port 3000, now we're ready to role! This is a GET request, so all we need to do is show the user something. We know this, because we're born with it! (We know these things from Express and JavaScript built-in)

Let's roll down our index.js file. At first, we just know who we are.
Alright. The user is requesting the the page called pigeon /birds/pigeon. Whoah! One of my commands activates when I'm requested for /! app.use("/", routes);
app.use("/", routes); So based on this, I call routes. We defined it earlier, with const routes = require("./routes/index.js");.
Nice! That require means I go to that file now, and keep going!

Journey to the Routes Folder, routers/index.js

Specified as earlier with app.use("/", routes); referencing const routes = require("./routes/index.js");, our adventure to find out what happens when our user visits /pigeon has first taken us to the index.js file within routes.

The routers/index.js file is basically responsible for funneling all the other routes together.

*Why? Future-proof our route so that we can simply refer to router/index.js instead of linking the routes directly.

We, the computer, read top to bottom. Using //, let's follow our path and see where our files want us to go.

// Ahh, the routes index.js file! Good times here. Let's take a look... I'm looking to see where I should go for /birds/pigeon.

const express = require('express');
// Looks like I'm still using Express.

const router = express.Router();
// Okay, I'm using Express's Router method for the following. I need this because it's a part of the framework.

router.use('/', require('./application.js'));
// If user requests homepage, shoot them to ./application.js. Remember, . is current directory, but this isn't what we're looking for!

router.use('/lizards', require('./lizards'));
// If user requests /lizards, we will send them to lizards.js. Nope!

router.use('/birds', require('./birds'));
// If user requests /birds, we wil send them to birds.js. This is what we want, let's go!

Stepping into routes/birds.js

Yes! We're here, in routes/birds.js! Alright, what's in here?


const express = require("express");
const router = express.Router();
// Hey, I remember these!

const birdController = require("../controllers/birds");
// Huh. Alright, we have a variable called birdController, and it requires us to go to the controllers/birds.js file. We don't need to mark it with `.js`, because Express framework tells us to. Remember, `..` goes up a directory and we're currently in routes!

router.get('/', birdController.show);
// Hey, this is our path, birds/, but we're looking for /birds/pigeon. We just see / and not /birds because we're in /birds. Think of it as changing directories. So... Nope, not our stop!

router.post('/pigeon', birdController.create);
// This is it! This is /birds/pigeon! But there's one thing... I have a GET request, not a POST request. So this is the correct path, but not the correct action. Let's keep looking...

router.get('/pigeon', birdController.show);
// YES! Here is our GET request for /birds/pigeons. Let's see... It wants us to execute the .show method on birdController. What's birdController? Oh, right, we defined it up above! We need to travel to ../controllers/birds.js

module.exports = router;
// How we travel! Without this, we'd be trapped here.

Become A Computer: A Roadmap, Controller Example

Arriving At the Magic, controllers/birds.js

We made it! Controllers are where the action is. Think of controllers are normal JavaScript. This is what the guts are, and that normal JavaScript drives it. Look how the models come in to play now, this is where it all happens, lead to you dynamically thanks to routes!

Notice the method from before when birdController called birdController.show, .show being the method.


const Bird = require('../models/Bird');
const User = require('../models/User');

module.exports = {
    create: (req, res) => {
        console.log("This is what we weren't looking for!");
    },
    show: (req, res) => {
        console.log("This is what we were looking for!");
        // The code here would be executed with birdController.show.
    }
};

Conclusion

Thinking about how the computer reads the code tremendously helped me understand why the code is written the way it is. I really hope it helped you visualize it and understand it too!

Find it helpful? Do I have any errors? Have questions? Have feedback? Let me know!

Thanks for reading, and Happy Coding!
~bananabrann

.includes For Noobs

Lee — Fri, 11 Jan 2019 21:03:46 +0000

Crash-Landing
Syntax
Search Within Arrays
Tell It When To Start! (Index, and Indexing Negatives)
Examples

CRASH-LANDING

~~Peer into the soul of JavaScript and interrogate what the meaning of code is~~ .include is a JavaScript method that searches for whatever you pass in it, wherever you tell it to search. It then returns true or false based on if it found what you were searching for. It is a very simple, but powerful method. For us beginners (me and you!) we'll just be looking at the syntax and attaching to array variables.

QUICK NOTES

You cannot search for multiple items at once with .includes.

SYNTAX

The syntax for .includes is .includes(value, i), where value is what we're searching for, can be an integer or string, and i is where we're starting the search. Remember JavaScript starts at 0!

SEARCHING WITHIN ARRAYS

Let's say we have an array of our moral character, and we want to know if our array contains certain items. With .includes, we can easily do this! Let's take a look.

const morals = ["honor", "courage", "justice", "yourself"];

We're trying to find some courage to continue tackling JavaScript, so let's use .includes to see if morals has our courage!
To do this on arrays, we simply call the array and place the syntax of .includes after it, as such:

// is the computer's response. If you want to see it, don't forget the console.log

const morals = ["honor", "courage", "justice", "yourself"];

morals.includes("courage"); 
// true
morals.includes("yourself"); 
// true
morals.includes("funny"); 
// false

You can also pass in integers instead of strings!

const numbers = [12, 22, 33, 44, 55];

console.log(numbers.includes(22));
// true
console.log(numbers.includes(39));
// false

If you would like to play with these examples, check out this CodePen!

TELL IT WHEN TO START

(INDEX AND NEGATIVE INDEX)

Now that we have the basics of .includes, let's look that that second thing .includes can take. Let's review syntax:

.includes(value, i)

Earlier, we were substituting things into the value portion, now we will be substituting something in for i, or the index. For the .includes method, this means where the computer will start looking for the number.

Check out this code:

const cities = ["Dallas", "Miami", "New York City", "Seattle"];

When we just pass in a string to search for, as we did in the section previous, the computer defaults to 0 -- start at the beginning.
Placing in a number, remembeirng that JavaScript starts at 0, we can tell JavaScript when to searching for it. If a value is within the array, but before the index, it will return false because of this.

Notice the changes in output:

const cities = ["Dallas", "Miami", "New York City", "Seattle"];

cities.includes("Dallas");
// true
cities.includes("Dallas", 0);
// true
cities.includes("Dallas", 1);
// false

Pretty simple, right? Good! Now let's do the final thing with .includes... Negative indexes! Woo!

Negative indexes act the same as indexes, but start from the end and work forward. When counting from the back, the 0 is not the first digit, contrary to regular JavaScript number counting. So in an array of [1, 2, 3] the 1 is an index of -3.

Let's see it under the microscope:

const people = ["Mike", "Jebs", "Sarah", "Gary", "Phil", "Merilyn", "Macy", "Stacy", "Hacy", "Lacy"];

people.includes("Lacy", -2);
// true. JS starts its search at Hacy
people.includes("Merilyn", -4)
// false. JS starts its search at Macy

Congratulations, you now understand this simple yet powerful little method! Go out into the world, and fix all its problems using .includes now.

Found this blog helpful? Didn't like it? Let me know!

Thanks, and Happy Coding!
~bananabrann