EPT, or "80% There!"

Pareto Principle

The terminal is a complex system, opening up the user to a plethora of even more complex tools. The number of tools accessible through the terminal is ever growing. Sometimes these tools have a near impossibility to master, they have hundreds if not thousands of features. Surely this is what makes the terminal infamous as only be reserved for only the most nerdiest, only the most extremely apt engineers. This is certainly not the case. This is where EPT comes in. EPT, or 80% There embodies the Pareto Principle, also known as the 80/20 rule.

The tools behind the terminal are complex, but what if we only learned 20% of what is there. What if we put in the effort to learn only 20% of a tool, only 20% of its features, only 20% of the config file, only 20% of the CLI options? By learning only 20% of these tools, I believe, you will have everything you need to know to build your 80% solution.

Developing a 100% solution right out of the gate is almost always doomed to fail. The 100% solution requires error handling, it requires knowledge of edge cases, boundary conditions, faulty input, timeout conditions, and may other facets. In many cases, the time required to complete a job is exponential. Results are seen very quickly in the project, but you'll quickly experience diminishing returns the longer the project is developed. The time required to complete an additional task is orders of magnitude longer to complete simply because the project has grown in size.

EPT is here to help get the 80% solution, and get it quickly! I believe this can be done simply by learning 20% of the tools you need for the project. 20% effort should get you 80% results.

An analogy could be an iceberg. In a boat or a ship we can see the top 20% of an iceberg. We do not need to see the full 100% of the iceberg, we just need to know where the iceberg is, and avoid it! By seeing the top 20% of the iceberg, that gives us enough information to steer clear.

EPT will be a constant work in progress. It will never be done. If you wish to receive notifications when EPT is updated, be sure to click the bell on the the Git repository.

EPT is written like a reference manual, but is not any kind of definitive guide in the strictest sense and can certainly be subjective at times. If you want to have a discussion about this page then I encourage you to start a discussion using EPT's GitLab Issues , as it may result in positive changes for the EPT project.

EPT Writing Style

As you read articles on EPT there will be, more often than not, times when code or commands will need to be displayed. As EPT's goal is to briefly showcase many Linux and Unix based command line tools there will be many ways the article contents will be styled. It should be clear what the styling means, so this page can be used as a reference for how and why things are formatted the way that they are.

Running Commands

Since EPT is focused around the command line, it should be crystal clear how a command will be run and how sample output will appear. A command and its output will be indented, dimmed, and monospaced as such:

$ ls -al
total 56
drwxr-xr-x 10 devenv devenv 4096 May  5 00:33 .
drwxr-xr-x  1 root   root   4096 May  4 16:45 ..
-rw-------  1 devenv devenv  125 May  8 01:44 .bash_history
-rw-r--r--  1 devenv devenv  220 Feb 25 12:03 .bash_logout
-rw-r--r--  1 devenv devenv 3771 Feb 25 12:03 .bashrc
drwxr-xr-x  3 devenv devenv 4096 May  4 17:42 .bundle
drwxr-xr-x  6 devenv devenv 4096 May  4 17:36 .cache
drwxr-xr-x  6 devenv devenv 4096 May  9 18:10 .config
drwxr-xr-x  5 devenv devenv 4096 May  4 17:45 .java
drwxr-xr-x  5 devenv devenv 4096 May  4 17:32 .local
drwx------  5 devenv devenv 4096 May  4 17:33 .mozilla
-rw-r--r--  1 devenv devenv  807 Feb 25 12:03 .profile
drwx------  2 devenv devenv 4096 May  4 17:32 .ssh
drwx------  2 devenv devenv 4096 May  4 17:32 Downloads

Generally it will be obvious this is output from a command since it will have the typical $ before the command that will be ran. Everything else should be assumed is the output from the command.

Another note about running commands is that EPT will never implicitly run commands as root. If root is required for a particular situation then the article will explicitly invoke sudo in front of all the commands requiring elevated privileges.

$ sudo ls -al /root
total 32
drwx------ 1 root root 4096 May  4 17:23 .
drwxr-xr-x 1 root root 4096 May  9 16:49 ..
-rw-r--r-- 1 root root 3106 Dec  5 14:39 .bashrc
drwxr-xr-x 1 root root 4096 May  4 17:22 .cache
drwxr-xr-x 3 root root 4096 May  4 17:23 .gem
-rw-r--r-- 1 root root  161 Dec  5 14:39 .profile

While some online tutorials will implicitly use a # symbol to denote a root shell, such as:

# ls -al /root
total 32
drwx------ 1 root root 4096 May  4 17:23 .
drwxr-xr-x 1 root root 4096 May  9 16:49 ..
-rw-r--r-- 1 root root 3106 Dec  5 14:39 .bashrc
drwxr-xr-x 1 root root 4096 May  4 17:22 .cache
drwxr-xr-x 3 root root 4096 May  4 17:23 .gem
-rw-r--r-- 1 root root  161 Dec  5 14:39 .profile

This can easily be missed, and lead to confusion. EPT will keep this notation to a minimum in preference for using sudo from a non-root shell.

Code Formatting

Code Blocks

In some instances, EPT will need to present code to the reader. More often than not this will be shell code, but it can be from any language if needed. Code blocks will be highlighted based on the language they are written in, and will container a gutter with line numbers.

For example, a segment of Bash code will look something like this:

echo "Lorem ipsum dolor sit amet, ..." | grep Lorem

echo "This is some bash code"
echo "that spans"
echo "multiple lines"

# Convert a file from the DOS format, cause... who uses the DOS format anyway ;)
dos2unix dosFormattedFile.txt &>/dev/null

Probably the most important aspect of a code block is the copy button in the upper right corner. When clicked, the reader will have copied the code to their clipboard.

Inline Code

There will also be times when a short or small segment of code needs to be accented, but does not warrant a full code block. The code will be emphasized like this, which will not display any kind of special syntax highlighting.

Content Formatting

Paragraphs

There is not much to say about paragraphs other than each article will try to keep each paragraph short and to the point. After all, each article is only going to talk about 20% of a tool, right?

Lists

Bulleted lists will be formatted as such:

  • one
    • one
  • two
    • two two
  • three
    • four
      • five

And ordered lists will look similar, but with numerals:

  1. item #1
  2. item #2
    1. sub item #1
      1. sub sub item #1
    2. sub item #2
  3. item #3

Quotes

Text quotes will look similar to running commands and their output, however they will not be monospaced.

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

However, since text quotes will look similar to running commands, these kinds of quotes will generally be kept to a minimum.

Vim

Something to talk about.

  • running commands inline
  • navigating around a file
  • buffers and splits?
  • config file
    • running commands
    • setting color scheme
    • setting keybindings
  • workspaces and sessions
  • plugins?

A mouseless whhhhhat?!

In the mid- to late-60's, the first computer mouse was invented and demonstrated to the public. While revolutionary for the time, some might argue the computer mouse was not popularized until the 1980's when the idea of a "home computer" became more reified. Since then, computer mice have become iconic with modern life, and thus became extremely complicated with seemingly gluttonous features that can make the device cost hundreds of USD. Seriously, why are some so much for just a couple of buttons?!

For the vast majority of the early days in computing, mice just simply were not a thing. They just were not as mainstream as they have become today. The command line is centered around a mouseless environment. Text editors like vim, emacs, pico/nano, and many others were created because mice were not available to the overall computing population.

The mouse is not all bad. There is no way we could have specialized fields like graphic design, CAD software, audio/video editing, and much more! So why give up the mouse?

There is a slow growing movement in software development to go back to the old days of a mouseless development environment. Some argue their productivity is hindered when they need to use a mouse.

The why...

The computer mouse is highly inefficient when it comes to productivity. Think about it, a person needs to:

  1. move their hand away from the keyboard,
  2. optionally shake the mouse to discover it on the screen,
  3. move it at high speed to a general area where they want to click,
  4. move the mouse to the precise location which is often a relatively small area on the screen, compared to the screen's full resolution, and
  5. finally make the click (and if you're anything like me, you hope you didn't miss, cause, ya'know aging eyes!)

However, with a keyboard one can imaging the TAB key acts much like the mouse. We use the TAB key to change focus on different elements on the screen. We move between buttons and checkboxes to text areas and links. The key difference is the TAB key is exact! Precision is not really needed as focus snaps to the next possible element.

The how!

For some, the productivity increase of a mouseless environment can range from marginal to maximal. Others may see their productivity decrease. At the end of the day a mouseless environment is only as good as the user wishing to embrace it.

Are you convinced? Do you want to try a mouseless environment? It sounds great and all but how would we actually go completely mouseless? With the next series of "mouseless articles" I want to give you the tools to try it out. I will try to showcase the major systems that developers, system admins, and everyone in between use. I want to give you 20% of what is needed to use these systems productively without a mouse.

But first step #1: unplug your mouse. Seriously, there will be some struggling, but it is the only way to succeed. Trust me, once all of my mouseless articles are written I hope that you have all the tools needed to go fully mouseless from login to your daily workflow.

First Topic Heading

Write stuff here...

First Topic Heading

Write stuff here...

tmux

  • define sessions, windows, and panes.
  • creating sessions
  • creating windows
  • creating panes
  • navigation between them all
  • config file

ssh

doing something with ssh.

ssh ...