DEV Community: Josiah Webb

Starting a Project like a Power User

Josiah Webb — Wed, 26 Jan 2022 02:38:49 +0000

Have you ever wondered how some power users do everything from the command line? Well, then you have come to the right place. In this guide, I will help you dip your toes in by starting a project and ultimately pushing it to GitHub all from the command line. We will use a bit of the terminal, a bit of the integrated terminal within a text editor, and some of the command line interface tools provided by GitHub. With that said, there are a few prerequisites, if you will, that are helpful to follow along with this guide. Firstly, it is not imperative that you deeply understand each of these tools, but it is certainly beneficial to know of them. We will be using zsh and oh-my-zsh as the terminal shell. A shell is a program that allows you and other programs to interact with your computer’s operating system. Z shell, or zsh for short, is just one of the many shells and command languages. It is fairly common, so you may already have it. If not, I have provided a download link along with all the other tools used in this guide. Oh-my-zsh is a framework for zsh that helps manage plugins and allows for themes, among other things. Like, zsh, it is not required for this guide but for the sake of continuity, I wanted to make you aware of what I use. If you are using another shell (like bash, for instance) you may have a $ preceding all command line prompts instead of the → seen in this guide. The actual commands used in the command line are fairly ubiquitous among most default shells. We will be using VS Code for the text editor. Again, you can use another as long as you figure out how to access its built-in command-line interface. And finally, the version control system we will be using is git with GitHub. These two are essential to the guide as the commands used are specific to them. Below you can find links to acquire all of the tools used.

The Guide

Navigation

We will start by opening up the terminal. Once open we will be met with a screen that looks something like this:

-> ~

If you have leftover entries from a previous session or your terminal window seems busy, you can type the command clear at any time to clear the window. This command does not delete anything or take any meaningful action. It just cleans up your workspace so you can start with a clean slate (as seen in the pictures below). You can always scroll up to see previously cleared information. (Note: any time you type in a command, you must hit enter to execute it).

-> clear

Once your terminal is cleared, type in the list command.

-> ~ ls

This will list out all of the contents of our current directory (directory or folder can be used interchangeably, ‘directory’ is just the more technical term). If you are in your root directory (think of this as the outermost, home folder), your terminal will look something like this:

This is essentially showing the same information as if we were to open Finder (macOS) or the start icon (Windows); we are just accessing it in a different way. Finder or the start menu is part of the graphical user interface (GUI), and your terminal grants access to the command-line interface (CLI).

Alright, now let us find where we want our new project to live. You will likely house your documents in your documents folder, so let’s go there. To change folders, we will use the change directory command.

-> ~ cd ~/Documents

The cd portion changes the directory, and the ~/ portion designates to which directory. The tilde ~ means a relative path. Technically, when changing directories, we need to spell out the exact address. We use the tilde to forgo typing the absolute (exact entire address) path. If you ever need the absolute path, type pwd (print working directory) to view it. If we do so in the /Documents folder, we will get something like this:

-> Documents pwd
/Users/myusername/Documents

The relative path becomes increasingly useful as we dive deeper into layered directories. Additionally, if you are using zsh, the tab key allows you to autocomplete folder names and the tilde is not required to change folders housed in the current working directory (the folder you are currently in).

Another essential navigation command is the two dots.

-> ~ cd ..

Typing cd followed by a space and two periods will move you out of the current directory back to its parent directory. If we use the directory in the pwd example, typing in the .. command will move us from /Documents to /myusername.

Creation & Deletion

Let us say we want to create a project in our /Documents folder. Make sure you are there by either confirming with pwd or moving there with cd (as seen below, your terminal will also often print your current directory following the → or $). Once there, we want to make a new folder to house all the project files.

-> Documents mkdir my_new_project

The make directory command mkdir creates a new folder named with whatever string we provide after the command. Now a heads up, if you want spaces in the name, you must wrap the name in quotes.

If we happen to misspell the new folder name, there are a few ways to handle it. We can use the mv command and move the folder to the same place with a new name.

-> Documents mv ~/Documents/my_misspelled_proj ~/Documents/my_correctly_spelled_proj

Or we can delete the folder with rmdir and create a new one.

-> Documents rmdir ~/Documents/my_misspelled_proj
-> Documents mkdir ~/Documents/my_correctly_spelled_proj

Tip: if you put files in your directory but still want to delete the folder, including its contents, rmdir alone will not work. It only works on empty directories. If the directory has contents and you want to delete the folder AND its contents, you must use one of the following:

-> Documents rmdir -r ~/Documents/my_misspelled_proj

-> Documents rm -r ~/Documents/my_misspelled_proj

The -r stands for recursive and will cause all contained files to be deleted. The rm is the standard remove function. This will remove files. A huge heads-up, deleting things from the command line is permanent, and there is no confirmation. You will not receive an ‘are you sure?’ message, and the files/folders will not be in the trash. They are gone. This can be said regarding all actions taken from the command line but proceed with caution. Most small commands (i.e. commands covered in this guide) are of little to no consequence. However, as you become more adept with CLI tools, you will find yourself putting together more complex commands, at which point you will want to be very clear on what that command will accomplish.

Moving on. Once we create the folder we want to house our project files, we will cd into the folder and then create said files. Observe:

-> Documents cd my_new_project
-> my_new_project touch index.html styles.css script.js

The touch command creates files with the names we provide. At this stage, we must designate the file types. As seen above, we have created an HTML file, a CSS file, and a JavaScript file. You can make as few or as many files following the touch command. Once entered, use ls to verify their creation.

-> my_new_project ls
index.html styles.css script.js

We will get something like the above. Once verified, we can open these files directly in our default editor by typing code ..

-> my_new_project code .

The dot or period tells the computer that we want the preceding command to apply to all the files in the current directory. You can alternatively type the files’ names directly, and this is obviously useful if you want to open only one or some of the files in the folder.

Once the code command is entered, VS Code will automatically open in a new workspace with the selected files. From here, we can start building away.

Version Control & Pushing to GitHub

Let us fast forward a bit and say we have completed the first version of our app/site. We still have all of our files open in VS Code, and we have saved our progress locally to our machine. From here, we need to make sure we can control its version and push our progress to a remote repository. Open the integrated terminal from the terminal menu within VS Code. By default, you should be in your project’s directory. If you are unsure or need to do some navigation, use the commands laid out previously.

At this point, you will want to ensure that your GitHub CLI is set up properly. If you already have a GitHub account, it is likely just a matter of running brew install gh (macOS) or viewing the CLI README.md to install it, and then run gh auth login to ensure your account is connected. Visit GitHub’s CLI docs for further instruction/clarification.

If you think you have already run these steps or want to confirm you have done them correctly, running gh auth login can verify your status. If done correctly, you will get this message

➜  my_new_project gh auth login

? What account do you want to log into? GitHub.com
? You're already logged into github.com. Do you want to re-authenticate? No

Enter no when prompted. Now let us initiate our git repository.

➜  my_new_project git init

➜  my_new_project git init
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint: 
hint:   git config --global init.defaultBranch <name>
hint: 
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint: 
hint:   git branch -m <name>
Initialized empty Git repository in /Users/myusername/Documents/my_new_project/.git/
➜  my_new_project git:(master) ✗

When done, we will get the above message as confirmation. You will notice via the ‘hint:’ that you can change the name of your initial branch. As you can see, I have never bothered.

Now to add files to staging. To see what files can be staged, use git status.

➜  my_new_project git:(master) ✗ git status
On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        index.html
        script.js
        styles.css

nothing added to commit but untracked files present (use "git add" to track)
➜  my_new_project git:(master) ✗

You can see that we have three ‘untracked’ files. To add all of them to be committed, we can type git add .. As you may remember the . allows us to add all the files without having to type each individually. The . will not be used in all cases as many projects will contain files we do not want to commit, but in this case, it will work just fine. Once we have run git add ., we can recheck the status.

➜  my_new_project git:(master) ✗ git add .
➜  my_new_project git:(master) ✗ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   index.html
        new file:   script.js
        new file:   styles.css

➜  my_new_project git:(master) ✗

You will notice we now have files listed under Changes to be committed. Perfect. We can now commit our changes.

➜  my_new_project git:(master) ✗ git commit -m 'first commit'

You can commit without a message (-m followed by the message contained in quotes) but I highly discourage you from doing so. It is always good to have some indication as to what the commit is doing.

Once we hit enter, we will get more confirmation information. Something like this:

➜  my_new_project git:(master) ✗ git commit -m 'my message'
[master (root-commit) 5d104wg] my message
 3 files changed, 22 insertions(+)
 create mode 100644 index.html
 create mode 100644 script.js
 create mode 100644 styles.css
➜  my_new_project git:(master)

And finally, we will want to create our new GitHub repository and push it there.

➜  my_new_project git:(master) gh repo create
? Repository name my_new_project
? Repository description a great description
? Visibility Public
? This will add an "origin" git remote to your local repository. Continue? Yes
✓ Created repository josiahwebb/my_new_project on GitHub
✓ Added remote htps://github.com/josiahwebb/my_new_project.git
➜  my_new_project git:(master)

gh repo create will create a repository named after the directory that we are in currently. That would be ‘my_new_project’ in this case. We will then answer a series of questions, as seen above. We can rename the repo with the first question, designate its description with the second, and denote its visibility (private/public) with the third. The fourth question essentially asks what we want our remote server to be named. In other words, instead of instructing git to push my commits to a remote server at https://github.com/josiahwebb/my_new_project.git every time, I can say push it to origin (as you will see below). Origin is simply the default name; you can change the name if you wish. After creating the repo, you will now be able to see it on your GitHub profile. The last step is to push our files to the new repo.

➜  my_new_project git:(master) git push -u origin master 
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (5/5), 603 bytes | 603.00 KiB/s, done.
Total 5 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/josiahwebb/my_new_project.git
  [new branch]      master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.
➜  my_new_project git:(master)

The initial push will need the entire git push -u origin master command. -u is not necessary but quite handy. If we include that in our initial push, any subsequent pushes only need git push as long those pushes are going to the same branch. The -u tag is short for --set-upstream-to and, as you might infer, it sets the default branch for future git commands within this project.

And there we have it. We have created a project entirely from the command line. There is obviously a lot more to git, GitHub, and the command line, but I hope this guide at least helps get you started. I know something like this would have been immensely helpful when I first started. Thanks for reading!

The Three Essentials of CSS

Josiah Webb — Tue, 11 Jan 2022 20:15:27 +0000

Ahh, CSS, the great painter of the web. With CSS, you can make the web as pretty or ugly as you like. CSS stands for Cascading Style Sheets, and its name is unassumingly quite indicative of what it actually does. It is a sheet (file(s)) of text that the browser reads through to style your piece of the web.

The Cascade

Now on to these essentials. The first, as I previously hinted, is found in the name. ‘Cascading’ is the first and most important concept because the other two are incomplete and don’t make sense without it. Cascading refers to how the browser reads the file. Think of water as it cascades over a waterfall. The water flows from the high point to the low point. And much like we humans read a page, the browser reads a CSS file from top to bottom. ‘T to B’ as they say. Easy enough. So why is this important? Well, in communicating, we humans tend to repeat ourselves. Computers don’t like this and will take us on our LAST word (as it pertains to CSS, that is). Here’s an example:

The designer in this scenario started by thinking the heading should be attention-grabbing and fierce, hence deciding to make it red. Then the section’s tone changes so much that the red heading is no longer appropriate. The dev goes back into the code and slaps a blue value at the top of the page because that is typically where the h1 style is located. He is then perplexed when the heading color is still red. This is a silly example, but it illustrates how a computer cannot make inferences. It has strict rules to follow and will not deviate. If there is any repetition or conflicting information in CSS, the browser will always default to the last key-value pair listed when reading top to bottom. This holds true even if the conflict occurs in the same selector block, as seen below.

Specificity

At this point, more experienced CSS users may be saying, well, yea, but… Leading me to the second essential concept of CSS - specificity. You see, when I asserted that any repetition or conflict will always default to the last, I sort of lied. Specificity will override conflicts, and it can be quite valuable if you understand how to use it. Take my previous example. It turns out the designer intended to have three different colors for various headings on the page - green by default and blue and red fonts for specific instances. So how do we accomplish this? By being more specific. Being more ‘specific’ can be accomplished in a variety of ways, but the simplest is via classes and/or ids. Examine:

In this example (which is structured awfully - more on that shortly), the ‘h2’ heading with a ‘blue-font’ class will be blue. The ‘h2’ heading with a class of ‘red-font’ will be red despite the h2 selector coming last in the file with a color of green. This may be a bit confusing, and that is exactly why the structure (or order) of the file above is awful. Specificity will override the cascade. Ergo, it is best practice to list your selectors from most broadly defined at the top to most specific at the bottom, curbing confusion for both you and the next dev who reads the file.

Inheritance

Alright, you’ve grasped the cascade of CSS and its nit-picky specificity, on to the bow that brings it all together - inheritance. Inheritance is the key to writing concise CSS. If you understand this concept, you can drastically cut down on the amount of CSS written and make your selectors reusable. In essence, some more specific selectors will inherit designated values of more general selectors of the same type. Or, more technically, some child elements will inherit the traits defined for their parents (just like you and me). Notice I said ‘some,’ this is not an overarching hard and fast rule, but I digress. Let’s take our trusty example and add a few more values:

You’ll notice both snippets accomplish the same thing, but the first is far less verbose than the second. This sameness is the result of inheritance. When applied to an h2 element, the two designated classes will inherit the font and border values of the h2 element, meaning you don’t have to redefine those rules for each class. Now I hope you are having a bit of an ‘Aha!’ moment. If we stick with the less verbose method, it means that our color classes can be used for our two different headings and any other fonts we want to make those respective colors. In short, it allows for the reusability of classes across various elements.

Recap

When you are writing CSS, you should always keep these three concepts in the back of your mind. Remember, when constructing CSS, the browser will always read the file from top to bottom. As such, for everyone’s sake, including the computer, structure the file in descending order with the most general selectors at the top and every more specific selector coming thereafter. Once you’ve done so, you can better recognize which selectors will inherit which values. If you have a more specific selector that will accomplish a very specific task, keep it simple. If that selector will inherit desired traits from its parents, there is no need to re-designate those values. In short, in the following list, the former will overrule the latter.

Specificity
Inheritance
Source order (the cascade)

I hope this has been helpful! Thanks for reading and until next time…

gm!

Josiah

Everyone is Valuable, Don’t Be Afraid to Show It

Josiah Webb — Mon, 20 Dec 2021 23:12:17 +0000

A recap of "Bootstrapping a career in web3 with Alisha.eth"

gm!

So here we are, my very first article to be published on the internet. You’ll see here in a second why I have chosen now and my inspiration for doing so.

I finally got around to watching "Bootstrapping a career in web3 with Alisha.eth" the other day and I highly encourage you to take a look. Nader @dabit3 and Pranav @impranavm_ interview Alisha @futurealisha about her journey into web3. I won’t recount her whole story here as I really encourage you to take a look for yourself (starts @ 1:00) but I find it generally quite similar to a lot of our paths to web3. Either through vocation or simply our innate curiosity we take a look at this web3 thing to see what it is all about and like so many of us, she got a taste and couldn’t turn back. Now how she got there and the valuable insights she’s gained along the way are really where this interview shines.

In a word, create!

“Everyone is valuable because if you can communicate your story then it will have value to someone” - Alisha.

This is, in essence, how she made it to where she is today. Prior to landing that coveted web3 gig, she created for months. Creation came in the form of podcasts, articles, connections, and friendships. This is a vital step in any endeavor but especially in web3. You are able to convey your growth - your growth of thought, your growth of skill, your growth of insight. And after a time of consistent creation, Alisha actually had some pretty great options eventually landing with the ever prescient ENS where she is currently the community manager.

Now, this penchant for creation is almost a prerequisite for success in web3. Web3 is moving so fast that job descriptions are not an accurate representation of a role (if that description even exists in the first place). This can often be the case with startups in general but it is ratcheted up to the nth degree in web3. This leads to the true fallibility of job descriptions as a way to make decisions in the space. If you look at a job description and match it to your desires you may be disappointed when the details of your job inevitably change. In contrast, if you take a job based on the people working on the project or, from a high level, the protocol or project itself then the details will work themselves out. Especially if you have a willingness to create.

Alright, so you have a willingness to create. Why is this so important? It comes down to the idea of ownership. Ownership is really the whole ethos of web3. You get to own your creation. You own your creation of data, your creation of ideas, your creation of community. To put it simply, you own your creation of value. It is why, as Pranav put it, a culture of taking ownership is so crucial. Many of the projects/protocols in web3 rely on a flat structure. The space is fast and messy and tangental so having a team that can rely on each other to take ownership of their work is a must. If they relied on traditional hierarchical structures to provide tasks and direction, nothing would ever get done. And the amazing thing is, taking ownership in your creation of value for a project actually translates to real financial ownership in the project. Contrast this with a traditional public company where ownership is afforded to shareholders. Now I am sure they have earned their share (no pun intended) but let us be honest, save the founders and early employees (if they are still involved) the current owners have nothing to do with the production of value from the company and, as a result, care about one thing, profit. Of course, there is nothing inherently wrong with profit. I would go so far as to categorize it as a good thing. But being an owner removed from the inputs and outputs of a project your interests naturally gravitate towards the result of your stake.

This brings me to the last, and most important idea brought up in the conversation and that is the idea of stewardship. As the community manager of ENS, in Alisha’s view, she is simply a steward of the protocol that is serving the greater public. This helps frame this new idea of ownership whereby, as a steward, you are tasked with the health of the organization AND the community it serves. If the users of your protocol are now both contributors and owners the task of a steward becomes much more complex. As Nader put it, you are not only tasked with looking out for your own best interest but what is the collective best interest of the community. It is hard to figure out and very complex but will serve to be a much more fruitful future.

Ultimately, it is tough to be a hater when you’re also putting your work out there to be hated upon.

Hence why I have decided to start sharing my journey.

“Everyone is valuable because if you can communicate your story then it will have value to someone.”

I appreciate your encouragement, Alisha!

Thank you all for reading!

Until next time,

gmi

go make it ;)