DEV Community: mikel brierly

Introduction to the command line

mikel brierly — Mon, 30 Nov 2020 17:55:41 +0000

This guide will go through what the the command line interface (`CLI`) is, why we need it, and how to start using it!

NOTE: All the examples here are for Mac/Linux users. If you are on Windows 10 or newer, you can use the Windows Subsystem for Linux.

You'll often hear the command line referred to in different ways:

terminal
CLI
command prompt
shell

Here we'll refer to it as the terminal and CLI (command line interface).

A Little Background

Before the introduction of the graphical user interface (screens with a mouse pointer), the only way to interact with your computer was through the terminal. The earliest terminals (dating back to the mid 1960's) literally punched out the user's program (hand-written and then transcribed) onto to a card. The terminal has evolved exponentially since then, but it is still text-based, and it is still the most efficient way to communicate with our machines.

Here is a really good thread talking about why punched cards were used for early computing

CLI Basics

Alright, Let's get into it. Go ahead and open the terminal application. (It's included on your operating system)

In your terminal, you'll see some information: which user is currently logged in, the name of the computer, and where you are in your computer right now. (there might be some slight variation, and this output is configurable). You should see a little squiggly line toward the end.

(if you don't see that, type cd and hit enter)

That little squiggle is called a tilde, and it indicates that you are at your home directory (you'll see it on the key above tab on your keyboard).

What's my home directory you say? Lets find out!

Type ls and hit enter.

ls

This command "lists" all the items in your current directory. (you can think of directories as folders). You should see some directories that look fairly familiar, such as Applications, Desktop, Documents, and Photos. To get into one of these directories, we can use the cd command.

cd

cd stands for "change directory". Let's get into the "Documents" directory.

cd Documents

Notice that our current directory has changed to ~/Documents.

Let's "list" what's inside.

ls

Probably some directories (folders), and files, each will be displayed differently. Directories are usually indicated by a color of some sort, and files are usually plain.

But for now, let's go back to the Desktop directory. To navigate back, type cd ..

cd ..

.. indicates going back one directory. A single . indicates right here where you are

..

I like to remember it by the twin suns of Tatooine, a BACKwater planet.

Make sure you put a space between cd and .. or the terminal will yell at you.

Now that took us back to the home directory ~, right where we were before. (if you want to jump to the home directory from any location, just type cd by itself).

Now let's make a file of our own! Type touch luke-skywalker.txt.

touch luke-skywalker.txt

touch is a command used to create files! You have a lot of power with touch, because you can add any extension you like to files you create, such power!

When you are creating your file, make sure that your filename has no spaces in it, as the command line will interpret "luke" and "skywalker" as two separate files to create if there is a space

I think our file needs a better place to live, rather than exposed out in the hoth-like conditions of the home directory. Let's create a new directory for our file to live in. Type mkdir tauntaun.

mkdir tauntaun

mkdir stands for "make directory". Let's run ls again to list our new directory.

Luke is looking a little chilly though, so let's help him out and put him inside the tauntan.

mv luke-skywalker.txt tauntaun

mv takes two operands (parameters), the first one is the item to be moved, and the second is the directory it is to be moved to.

Let's run ls again to see what changed.

luke-skywalker.txt is gone, which is expected, but let's check and make sure he's inside the tauntaun directory.

cd tauntaun

ls

Now you should see luke-skywalker.txt inside there!!

Is there anything else you can think of that Tauntauns are full of? Let's add them in!

touch guts.txt

touch bad-smells.txt

When we run this command, it creates that file inside the tauntaun directory because our current location is inside of it.

now when we type ls, we see that our "tauntaun" directory is full of guts, bad smells, and Luke Skywalker!

Let's make a directory now. We'll call it "stomach".

mkdir stomach

Now enter that directory with the cd command

cd stomach

Inside the stomach, let's make another file, this time with a different file extension just to mix it up.

touch hoth-hog.html

Let's run ls and make sure everything is where we want it to be.

Looks good!

At this point, we are inside the stomach of the tauntaun. but what if we wanted to go back multiple directories?

We can do that with the by chaining our .. operand. To go back two directories, we would say

cd ../../

This will take us out of the stomach directory, and also out of the tauntaun directory. (A single ../ would have just taken us out of the stomach directory.)

Useful CLI commands

Print working directory (where you currently are)

pwd

pwd allows you to check where you are currently located in your system.

It stands for "print working directory", and it shows you where you currently are. It will print out the path of where you are all the way back to the root directory (/).

~ = home directory
/ = root directory

Print file contents

cat

cat shows us the contents of a file right inside the terminal itself. Keep in mind this command is most useful for shorter files that are only a few lines long. (cat stands for concatenate, which means "link (things) together in a chain or series").

Here's an example of what the cat command prints out for a small html file.

Search

grep

The grep command searches any given input, selecting lines that match, and printing out what did match! Let's look at a simple example:

# create sample file:
echo "I am a test string I created just now" > test.txt

grep "created" test.txt

See how grep highlighted our search criteria?

grep can also search the output of another command, not just a file! Let's see how it could work with cat:

cat test.txt | grep "created"

To fully understand how this is working, see pipe (|) in the next example and give it a go yourself.

Pipe output

By using pipe (|), you can take the output of any command, and pass it into another command.

There are many things this could be used for, but a common one you can focus on now is using it in conjunction with grep to search for things. If you wanted to search the contents of a file, you could output it's contents using cat, and then search with grep using a pipe.

name-list.txt is a simple list of names. We can output them using the cat command

Now if we take that output and pipe it to grep, we can search its output.

cat name-list.txt | grep "Han Solo"

grep only gives output if it finds a match for what you passed it! In this case, it gave us the line with our search criteria: Han Solo.

If we wanted to see lines around our match, we could use a flag of -C:

cat name-list.txt | grep "Ahsoka Tano" -C 2

See our highlighted result? But it also gave us 2 lines above and below when we used the -C flag.

-C gives lines before and after match
-B gives lines before match
-A gives lines after match

Remember that | can be used with anything that gives output. (grep is just an example)

File Preview

head

Using the head command on a file will give you only the first few lines of the file. This can be helpful if you need to see a header, license, or just to check the structure of a document.

Line Numbers

-n

If you want to see your output numbered by line, you can use the -n flag. Any command that gives output can be used with the -n flag. Here's an example using cat on our names-list.txt file.

Copy

cp

copy takes two parameters, the first is the file to be copied, and the second is what you want to call the copied file (it can't have the same name as the original).

ex: cp file1.txt file1-copy.txt - this will create a copy of file1.txt named file1-copy.txt in the same directory you are currently in.

Delete (remove)

For files:

rm

For directories:

rm -r

rm stands for remove, but the -r can be a little confusing. The - indicates a flag, and the r stands for "recursively". We'll get more into recursion later, but for now, you can think of -r as a way to manipulate directories when a command without -r won't work.

For example, running rm tauntaun will tell you rm: tauntaun: is a directory. So we need to use the -r flag.

Quick note on deleting and modifying files: When you give CLI commands, there is usually no confirmation and no "undo's". If we want the command line to be a little more forgiving, we can use the "interactive" flag, "-i".

Interactive (confirm commands)

-i

-i will make the command line interactively ask us if we want to perform destructive actions.

rm -i -r hoth-hog.html

Using the -i flag will force you to confirm certain actions, and you can simply reply y or n to continue or cancel the operation.

Manual (help pages)

man

man stands for manual, and is used in conjunction with other commands. If you want to learn more about any specific command, you can simply type man before it, and you'll get a very thorough explanation of what it can do. For example, if you wanted to learn more about the mkdir command, you would type man mkdir.

man mkdir

To exit the man page, hit q.

Use your skills!

Download this repo to your local machine:
- Click the green code button at the top of the page
- In the dropdown menu that appears, click "Download ZIP", and save the file on your computer. (Somewhere you can conveniently access it.)
Use the terminal to navigate to the newly downloaded directory.
- The name of the folder will be command-line-master. master just means what branch of the code you have.
cd into the rebel-traitor-hunt directory
Use the cat command to read the contents of the file instructions-from-vader to get started!

Tips:

Keep this webpage open for referencing commands you'll need, and for brushing up on the lesson as you go along.
For extra help, open up the walkthrough file. It has detailed hints, and the commands to run if you still need that extra push.

If you want to learn more about the command line, or find more commands, MDN has a wealth of information, and goes into a lot of detail explaining what you can accomplish with this tool. For more reading, this is a good starting point.

Pixel Perfect

mikel brierly — Mon, 23 Nov 2020 17:21:39 +0000

CSS is a powerful, intricate language that gives the web beauty and life. But it also can make you want to throw your computer out of a four story window and never touch the front-end again.

Most frustration with CSS comes from a lack of understanding, which makes sense since it is often taught as an afterthought of web development. If CSS was treated like a language rather than a coat of paint, I think we would appreciate its value more.

All of the CSS we write eventually boils down to pixels displayed on a screen for our users to see and engage with. But the term pixel can be misleading when we are talking about the values in our stylesheets. It stands to reason that a "pixel" would be the smallest visible quantity that can be displayed on a screen. But in reality, a pixel is just... really small. (1/96 of an inch apparently, but who's counting)

Here's what the spec says:

The reference pixel is the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm's length. For a nominal arm's length of 28 inches, the visual angle is therefore about 0.0213 degrees.

I was not enlightened by that explanation, so I took some bigfoot-esque photos of different physical screens displaying a single yellow CSS pixel.

That's an older LG Monitor, an iPhone 8+, and a 2018 15" MacBook pro.

It looks like our 1 css pixel equated to: 1 screen px for the LG, maybe around 6 or 8 for the iPhone, and 4 screen px for the MacBook. That's just conjecture though, this is the important part:

So what?

It's important to understand how our tools work, and when it is best to reach for them. px isn't the only fish in the sea.

The CSS px value should be used when you need an absolute unit of measurement for an element that will not fluctuate in size on your page. (Or it will change very little)

There are other units of measurement in CSS that can offer flexibility and responsiveness in ways that px fails to.

div {
  height: 10em;
}

div {
  height: 10rem;
}

div {
  height: 10vh;
}

div {
  height: 10%;
}

em: Font size of the parent element

rem: Font size of the root element

vh: 1% of the viewport's height

%: Usually a percentage of the nearest "sized" parent element (There are a lot of caveats to this one)

In my personal opinion, if you need a unit of CSS measurement that offers the most flexibility and control, rem wins hands down. It is more predictable than em, and makes responsiveness a breeze when changing layouts or sizes for different screens. I won't get into the weeds here, it was very thoroughly explained in this wonderful article.

Hopefully you have a little extra nugget of knowledge when it comes to CSS units of measurement, cheers! 🍻

Pixel art by Clint Bellanger

Deliver us from dependency hell

mikel brierly — Fri, 21 Aug 2020 16:06:28 +0000

Most modern services and applications have a mass of dependencies that live in an ever-growing node-modules folder. Generally a lot of these libraries are being actively maintained, changed, and updated. If your dependencies are poorly managed, you can quickly find yourself in dependency hell.

If you're unfamiliar with npm, check it out here before reading on

🛒 Grocery Shopping

When starting up a node application, one of the first steps is running npm install. When you run this, node will check for a file called package.json in the base of your project. If that file is found, it will use the dependency section as a kind of "grocery shopping list" to go and gather "ingredients" (code bits) your application requires.

The "grocery store" in this case is something npm calls a registry. By default, your node app will look in the public npm registry for these packages, where most everything you need will be (private registries can be created for proprietary code and whatnot). If the package is found in the registry, node puts that "ingredient" into a node_modules directory at the base of your project.

It's important to note that packages that you require may have their own "shopping list" (package.json), and all of those nested dependencies must be resolved before your app moves on to the next dependency in its own package.json.

⬆️ Versions, 🥕 Carets, and 🃏 Wildcards

The versions of your dependencies are generally something like v1.3.5. This is called semantic versioning, or semver. With semver, the numbers represent changes to the code in varying severity - MAJOR.MINOR.PATCH.
From their docs -

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner, and
PATCH version when you make backwards compatible bug fixes.

With this in mind, a lot of people want to automatically update their app with any fresh new stuff their dependencies might have in newer, non-breaking changes.

Prefixing with tilde ~ will give you any new PATCH updates, but not major or minor. So ~1.3.1 could install 1.3.9, but not 1.4.0

Prefixing with caret ^ will give you any new PATCH and MINOR versions, but not major. So ^1.3.1 could install 1.4.9 but not 1.5.0

Let's take a look at our example code's dependency tree:

my-breakfast
     |
     |
    milk
     |
     |
coffee-script

Ok, more like a stick, but hopefully the chain of dependency is clear. Our package.json is requiring version v0.5.0 specifically of milk, but milk is requiring coffee-script anywhere from 0.9.6 - 1.0.0. npm install is run, we develop our app, everything is hunky-dory.

📼 Now let's fast-forward 2 months. Someone finds your project and wants to contribute. They fork and clone your repo, run npm install, aaaaand it doesn't work. "But it worked on my machine!" you cry. When your collaborator installed the node modules, they were guaranteed a specific version of milk, but they got a different version of coffee-script because milk's package.json used semver.

🗿 Setting your dependencies in stone

One solution to this is to use a package-lock.json file. This file gives you very granular control over the versions of every dependency that you install. If your package.json is like the shopping list, then your package-lock.json is like a budget. You can have cereal, but it's gonna be store brand instead of Cap'n Crunch. This specificity runs all the way down every branch of your dependency tree. You must have a package.json if you want to use a lock file (the package.json does a lot more than just dependency management, that's just the focus of this post).

🎁 Wrapping up

I personally feel that a package-lock.json file should always be used (in newer versions of npm, it is actually automatically generated). It just makes everything more reliable across environments and deployments. Here's some last little nuggets to hopefully help out when it comes to dependecies:

npm install --save will automatically update your lockfile and package.json with that package.
npm ci instead of just npm install will automatically rebuild your node modules, and build from your lockfile. It's a really helpful command for CI/CD and generally best to use in tandem with a lockfile.
For larger projects, and super robust dependency, check out docker and containers. It can function almost like a virtual machine that perfectly contains your code and it's dependencies, and is cloned to promote to different environments. So hopefully you end up with a lot less "it worked on my machine" kind of issues.

Thanks for reading all! Let me know in the comments if I made any egregious errors or left something important out.

MTFBWY

Intro to pseudo CSS superpowers

mikel brierly — Sat, 08 Aug 2020 02:59:19 +0000

When folks are learning HTML, CSS, and web development in general, the concepts of elements, classes, and selectors are all taught early on, and often grasped quickly. But what about their weird, colon-prefixed cousins that are often avoided and misunderstood?

pseudo classes, pseudo elements, and pseudo selectors. pseudo is my pseuperhero

Let's recap some foundational pieces:

An element is an HTML tag. Any valid markup with <brackets> is an element.
A CSS class is an identifier you give to one or more element.
A CSS selector can be used to access HTML elements by their class.

Alright fine, let's get into it:

A pseudo-class targets the state of an element rather than the element itself. Pseudo-classes always (should) follow a CSS selector and are preceded by a single colon :.

A pseudo-element is an "invisible" element originating from your CSS that is intended purely for styling purposes. (It does not become part of the DOM) Pseudo-elements always (should) follow a CSS selector and are preceded by two colons ::.

Here's what that would look like in the wild:

☝️ Those are some big honkin gifs, so give 'em a sec

And after those updates, the HTML in the inspector will show this:

::before and ::after are unique in the sense that they accept a "content" property. Without this property, the pseudo-element will not be style-able by your CSS. Often you will see content: "" if the pseudo-element is only needed for styling. This is called generated content.

If you hear the term pseudo-selector, it is an umbrella term covering both pseudo-element-selectors and pseudo-class-selectors. You can always tell the difference by checking to see how many colons there are. One for pseudo-class, two for pseudo-element.

caveat from MDN:
As a rule, double colons (::) should be used instead of a single colon (:). This distinguishes pseudo-classes from pseudo-elements. However, since this distinction was not present in older versions of the W3C spec, most browsers support both syntaxes for the original pseudo-elements.

Thanks for reading! If you're interested in learning more, MDN has all the goodies (as per usual). 🍻

A brutally honest look back at the beginning of my career

mikel brierly — Wed, 22 Jul 2020 12:55:58 +0000

TL;DR
I struggled through a coding bootcamp, polished up a mediocre final project and got hired at a start up that was gambling on low salary bootcampers to find a unicorn. I lazily coasted through a corporate buy-out that left me over-valued because of my "domain knowledge". After 4 years of learning very little, I'm owning my dev journey and working to get better and share with others.

4 years ago I graduated from a 6 month coding bootcamp called Galvanize. I was closer to the bottom of my class, and always took up offers for after class workshops to help struggling students understand concepts the rest of the class seemed to get immediately. I worked hard and made some awesome friendships, and managed to make it through the whole thing with a lot of help from my peers. Before we "graduated" (unaccredited af) we created capstone projects to present to our cohort and a handful of prospective employers who partnered with Galvanize. My project was an overly ambitious app called "Desk" that had a calculator, notepad, contacts list, etc. It was really just a cobbled together group of "hello world" tutorials and libraries that I slapped some CSS on. (Here's the splash page if you're curious.) The site had a busted FB login page, I couldn't get my DB set up properly, and I didn't really understand a lot of the frameworks I was working with. I also massively underestimated the effort it would take to build what I really wanted.

By the time the presentation day had come, I had removed all backend logic, (the "login" page was all for show), and when you closed your browser, the session would lose any and all data. It was 95% CSS with loads of dead node.js code. So naturally I did my presentation as if nothing were wrong, carefully traversing the minefield of bugs and things that didn't work. I was insanely nervous, but it went alright, and it looked more put together than it really was (like a lot of engineers you'll meet out there). If you want to watch and cringe knowing what's really going on, here ya go...

After the presentations, everyone in our class met with a few companies and recruiters that came out to maybe hire juniors. I was unbelievably fortunate to get scheduled for an interview at a small local company. Five or six of my Galvanize friends landed interviews as well, and I happened to be scheduled as the last one. When each one finished their interview, we all would swarm in to hear the horrors of what we might be in for at the mercy of the dreaded whiteboard. Everyone shared what their experiences were, and they all seemed to be focused on similar topics with matrixes and arrays and hoop-jumping circus acts. So I found as many coding challenges as I could that seemed to be in that wheelhouse, and prayed to the gods that I studied the right stuff.

When my number was up, I met with some really nice senior engineers that did their best to put me at ease and make it as painless as possible. They gave me a problem on the whiteboard that thankfully was matrix related, and had to do with finding a duplicate or something like that. I got it super wrong. Even after studying pretty much that exact problem I totally biffed it. But what I did do was explain my thought process and vocalized what my logic was to get me in this completely wrong rabbit hole (ex: I rephrased the question and wrote it on the board, broke it down into small pieces and wrote those goals down, and then talked about what I might do to solve each small little piece) In having that conversation, the interviewers were able to probe my thinking and give me pointers. Those exchanges helped to ease the stress of the experience. A conversation is always much easier than a performance.

After my brain fart was erased from the whiteboard and it was all over, they thanked me and said they'd be in touch. A very stressful week later I found out that they had offered me a junior dev role that I grabbed onto like a life preserver. I really, truly felt like I had gamed the system. Like I lied to them about who I was, and what I could do. Even outside of my capstone project being misleading and maybe even dishonest, I thought myself a fraud of massive proportions.

I should know all this stuff right? I don't think I can explain what problems Node solves, I can't even remember the syntax to a "for" loop without googling it. Most of the code I've written that works was copy-pasted... Who am I kidding?

Every day for the first 2 years at my job I felt like I was putting on the same front I did when I presented my capstone. I tried to avoid topics I didn't understand. I tried to get assigned work that didn't highlight my shortcomings. Most days I was incredibly paranoid that my ignorance would come to light and I would be scoffed at and shown the exit. But it never happened.

I just kept following the status quo set by my coworkers, and those feelings slowly started to be less pervasive. I became familiar with our companies systems and painfully outdated tech stack enough to hack around and make things work, but I wasn't much of a better developer than I was when I started. I was just learning what other people did to hide their lack of knowledge and understanding.

I learned that jargon was better than terminology, a blog post title could give you ammunition to belittle the decisions of others, being a senior engineer meant being able to deflect work by spouting abstract complaints about architecture choices, and that being a developer meant writing unsustainable code and claiming that if "they" wanted it done right, they should've given us more time. It wasn't a healthy environment to learn in, but I inevitably absorbed some of those toxic ideas.

We were eventually acquired by a large corporation that promised to bring change, but it never came. Promises of better leadership and opportunities were unfulfilled, and work went on like it always had.

Now four years later, I feel like I've barely moved the needle at all. I let stagnation get to me and poison my work ethic. But I'm done with that. I need to take control of my own journey, and that's what I'm going to do.

We are so incredibly lucky to be where we are today as developers. We stand on the shoulders of millions of brilliant people that have made engineering and the web what it is today. And we have a community of people that want to help and share and grow together. We live in an amazing time.

I'm really excited to be starting a new chapter in my development journey that is focused on self improvement, learning, and positive creativity. I'm looking forward to sharing with and learning from all of you along the way.

To anyone starting out who might be struggling, I want you to know that every single successful engineer you look up to has felt the same fears and doubts you feel now. It takes a lot to push through, but you can. Never ever quit because you think you're not good enough. You are.

MTFBWY

What were your knowledge gaps when you started your career?

mikel brierly — Mon, 20 Jul 2020 13:40:17 +0000

When developers sweep mistakes under the rug and cover up gaps in understanding with jargon and obfuscation, we reinforce the wall of imposter syndrome. Let's be inclusive and share what this journey is really like, warts and all.

Stuff I think is reasonable to not understand:
📌 higher-order functions, threads, closure, execution context, recursion, OOP vs Functional programming, a million acronyms everyone seemed to be throwing around

Stuff I probably should have known:
📌 Using an IDE, the difference between front-end and back-end, Node debugging and Chrome dev tools basics, using debugger instead of console.log, what is pure JS syntax and what is framework,

Stuff I'm not sure is "beginner" or not:
📌 this and prototype, merge conflict resolution, [reading [documentation]], the call stack, web API

I'm really curious what your thoughts are on this, and what your own lists will look like!

MTFBY

DEV Community: mikel brierly

Introduction to the command line

This guide will go through what the the command line interface (CLI) is, why we need it, and how to start using it!

A Little Background

CLI Basics

Useful CLI commands

Print working directory (where you currently are)

Print file contents

Search

Pipe output

File Preview

Line Numbers

Copy

Delete (remove)

Interactive (confirm commands)

Manual (help pages)

Use your skills!

Tips:

Pixel Perfect

That's an older LG Monitor, an iPhone 8+, and a 2018 15" MacBook pro.

So what?

Deliver us from dependency hell

🛒 Grocery Shopping

⬆️ Versions, 🥕 Carets, and 🃏 Wildcards

🗿 Setting your dependencies in stone

🎁 Wrapping up

Intro to pseudo CSS superpowers

pseudo classes, pseudo elements, and pseudo selectors. pseudo is my pseuperhero

Let's recap some foundational pieces:

Alright fine, let's get into it:

Thanks for reading! If you're interested in learning more, MDN has all the goodies (as per usual). 🍻

A brutally honest look back at the beginning of my career

What were your knowledge gaps when you started your career?

This guide will go through what the the command line interface (`CLI`) is, why we need it, and how to start using it!