| # OBJECTIVE: Install Arch Linux with encrypted root and swap filesystems with an ENCRYPTED BOOT and boot from UEFI. We will | |
| also decrypt and mount our entire encrypted system using a single LUKS passphrase entry. | |
| # Note: This method supports both dedicated Arch installs and those who wish to install Arch on a multi-OS-UEFI booting system. | |
| # External USB HDD/SSD Installers Notes: Encrypted Arch installs can be booted and run from an external USB HDD or SSD, but | |
| # only when the installation is correctly set up. There are several necessary changes to my standard procedure you'll want | |
| # to make during the install process. Read my External USB HDD/SSD Installation section below before proceeding. |
| # The full public facing url | |
| #root_url = %(protocol)s://%(domain)s:%(http_port)s/ | |
| root_url = http://localhost:80/grafana/ |
| # OBJECTIVE: Install Arch Linux with encrypted root and swap filesystems and boot from UEFI. | |
| # Note this encrypted installation method, while perfectly correct and highly secure, CANNOT support encrypted /boot and | |
| # also CANNOT be subsequently converted to support an encrypted /boot!!! A CLEAN INSTALL will be required! | |
| # Therefore, if you want to have an encrypted /boot or will want an encrypted /boot system at some point in the future, | |
| # please ONLY follow my encrypted /boot installation guide, which lives here: |
| package main | |
| import ( | |
| "fmt" | |
| "net/http" | |
| "sort" | |
| "time" | |
| ) | |
| // a struct to hold the result from each request including an index |
| " Minimal neovim configuration for go | |
| " | |
| " deoplete requires neovim, so this will not work with regular vim | |
| " | |
| " prereqs: | |
| " - neovim | |
| " - neovim python3 (pip3 install --upgrade neovim) | |
| " | |
| " includes: | |
| " - syntax checking on save (using neomake, go and gometalinter) |
This method avoids merge conflicts if you have periodically pulled master into your branch. It also gives you the opportunity to squash into more than 1 commit, or to re-arrange your code into completely different commits (e.g. if you ended up working on three different features but the commits were not consecutive).
Note: You cannot use this method if you intend to open a pull request to merge your feature branch. This method requires committing directly to master.
Switch to the master branch and make sure you are up to date:
PRs are a great way of sharing information, and can help us be aware of the changes that are occuring in our codebase. They are also an excellent way of getting peer review on the work that we do, without the cost of working in direct pairs.
Ultimately though, the primary reason we use PRs is to encourage quality in the commits that are made to our code repositories
Done well, the commits (and their attached messages) contained within tell a story to people examining the code at a later date. If we are not careful to ensure the quality of these commits, we silently lose this ability.
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.