DEV Community: Brandon Ward

A Blogging Platform Where Everyone Gets Paid

Brandon Ward — Sun, 28 Mar 2021 20:30:39 +0000

In the world of content creation, it is important to be a member of several content creation sites. Dev To is an excellent platform for all things tech.

Enter an Alternative Platform

No, you do not need to remove DevTo from your content creation strategy. In fact, you should actually pick your blogging platform based on your target audience!

Did you know there is a blogging platform out there named Publish0x, with the mission of paying both content creators and readers for their time? They pay in cryptocurrency, but the money is real!

How do I get paid?

They have 2 ways you can upvote a blog - tipping, or liking. Likes are similar to the kudos you can give on this platform, but tipping pays everyone involved! You have a limited number of tips each day, and these are rate-limited throughout the day as well. Tips are free, and come from Publish0x's rewards pool. The concept is unique and amazing - the standard tip is 80% of the tip to the content creator, and 20% to the content reader, but you can adjust the tip based on how valuable you feel the content is. This is a platform that pays everyone for their time!

What types of things will I find on Publish0x?

Anything, really. But this blogging platform is cryptocurrency heavy, and so it's an excellent platform to follow for Crypto news and trends. If you haven't seen this platform, you're not risking anything by giving it a shot!

GPG Signing Github Commits

Brandon Ward — Tue, 07 Jan 2020 04:33:18 +0000

GPG, or the GNU Privacy Guard, is a complete and free implementation of the OpenPGP standard, and allows you to encrypt or sign your communications.¹ While gpg is a great tool for encryption, this blog post will focus on the signing aspect, specifically, when using it to sign git commits for a GitHub repository.

Why?

Why should I GPG sign my commits? Simple, so that you can prove that they came from you! Just as in the world of academia, your reputation is everything, you should do everything in your power to protect it! While I am not saying anyone would ever try to steal your software engineering identity, GPG signing your commits is an easy way to guarantee that you can prove which commits you have or have not made.

I have configured my laptop to auto-sign all commits with my GPG key. Doing this allows all commits I create to have the 'Verified' stamp when viewing them in GitHub.

Whenever you view a commit I have created, it will appear like this:

Example of a GitHub Verified commit.

Clicked on the Verified gives additional information to prove that I am the one who as signed this commit, because I have uploaded my GPG key to my GitHub profile:

GPG Signature Details.

Just because a commit is signed with a GPG key though, does not make it verified. When I was initially setting this all up, the GPG key I used was secured with a password that my toolchain could not support. As a result, I decided to delete that GPG key and start fresh. Here is what my test commit with that key looks like:

Unverified GPG Key.

As you can see, I am in full control of this signing mechanism, and it is an excellent way to self-verify your work.

How?

This guide is written for MacOS.

The how-to articles are plentiful on the internet, and so here's another. Beyond just providing the steps though, this guide hopes to explain what each command is for (if it's not clear already).

Installations

First, we need to install some tools. This guide assumes you have Homebrew already installed. Homebrew is a MacOS package manager, and is incredibly useful for toolchain installation management.

Using Homebrew, install the gnupg command line tool for working with gpg keys, and pinentry for Mac. Pinentry is a collection of GUI based programs for working with GPG keys², and pinentry for Mac will allow us to save the GPG key password to our keychain for easier access.

brew install gnupg pinentry-mac

Configure Pinentry

We then must do some work to ensure pinentry is used immediately for interacting with our GPG keys.

echo "pinentry-program /usr/local/bin/pinentry-mac" > ~/.gnupg/gpg-agent.conf
killall gpg-agent

We tell our gpg agent to default to pinentry with the first command, and secondly, we kill all running gpg-agents to make sure our configuration takes effect immediately.

Generate a GPG Key

GitHub has phenomenal instructions for this, these instructions are inspired from this guide³. If something in this guide does not work for you, I recommend that you open GitHub's guide and follow it, this will focus on the happy path of GPG key generation.

If you have just installed gnupg, you should have a version greater than 2.1.17, so you can run this command to start the key generation process:

gpg --full-generate-key

Then, when asked for the type of key, press Enter to accept the default of RSA for both the private and public keys.

Enter your desired key size, a key of at least 4096 bits is recommended.

Enter the length of time you wish the key to be valid for, Pressing Enter will accept the default of never expiring. For this use case, that is perfectly acceptable, since if the GPG key ever gets compromised you can delete it from GitHub.

Verify your selections, and then enter your user ID information. A tip from GitHub - If you would like to keep your email private, use your GitHub-provided no-reply email address.

Type a secure passphrase - I recommend using a password generator to make a suitably long password, however, you should keep your password below 100 characters since this toolchain has had issues with longer passwords in the past. You should save this password in a password manager, I personally use BitWarden!

Congratulations! You have created a GPG key!
Now, it needs to be added to git and GitHub.

Adding your GPG key to Git

List your secret gpg keys, which is the portion of the key required to sign your commits and tags:

gpg --list-secret-keys --keyid-format LONG

In the list of keys, select the secret key id (sec) that you would like to use. In this example, the GPG key ID is 7FF2A19983627EC2

$ gpg --list-secret-keys --keyid-format LONG
/Users/username/.gnupg/secring.gpg
------------------------------------
sec   4096R/7FF2A19983627EC2 2020-01-02 [expires: 2022-01-01]
uid                          Username 
ssb   4096R/24F148EA2DB78C3B 2020-01-02

We will configure git to use our key to sign all commits.

You must use your GPG secret key ID in the following commands.

First, tell git which GPG key to use, then, tell git to automatically GPG sign every commit:

git config --global user.signingkey 7FF2A19983627EC2
git config --global commit.gpgsign true

Now, create a test git repository with a new GPG signed commit! You will need to enter the GPG password the first time you use it, and Pinentry will allow you to save this password to your keychain so that you will not need to re-authenticate in the future.

After committing, you can test the new signature, by running this command to ask git to verify the signature:

git log --show-signature -1

Adding your GPG key to GitHub

The last phase is to add your GPG key to GitHub, without doing this step, all commits will show as 'Unverified'. This fact also allows us to revoke a GPG key in the future, as if it gets compromised we can delete it from GitHub.

Using your same GPG Key ID from above, we need to export the key:

gpg --armor --export 7FF2A19983627EC2 | pbcopy

Then, in your GitHub Settings, select SSH and GPG keys, click 'New GPG key' and paste your key!

Again, GitHub has a fantastic illustrated guide for this if you get stuck.

Push your test commit from the previous phase, and when you view the commits, it will show up as 'Verified'!

🎉🎉🎉

That's it! You have now configured your computer to auto GPG sign your commits and therefore provide a mechanism to guard and verify your identity as a software engineer!

References

GnuPG - https://gnupg.org/
Pinetry - https://gnupg.org/related_software/pinentry/index.html
Generating a new GPG key - https://help.github.com/en/github/authenticating-to-github/generating-a-new-gpg-key

Angular for GitHub Pages

Brandon Ward — Sat, 04 Jan 2020 21:07:33 +0000

This is the story of my personal journey to deploying an Angular app as my GitHub Pages website, for some, it may even serve as a guide!

Before we begin

Important Tools
https://cli.angular.io/
https://www.npmjs.com/package/angular-cli-ghpages
https://github.com/features/actions

Source Code:
https://github.com/Bwvolleyball/bwvolleyball-github-io-src
Published Code:
https://github.com/Bwvolleyball/bwvolleyball.github.io
Final Product 🎉:
https://bwvolleyball.github.io

Goal

The primary goal of this story (or guide) is to create a GitHub pages website that requires no maintenance to deploy or keep up to date. One of the promises for a traditional GitHub pages website is that new source code is automatically deployed to the pages website upon commit. The issue with an Angular application is that it needs to be built / compiled / transpiled (in the case of TypeScript) before it can be displayed as a static web page.

Getting Started

First, generate and commit a starter angular application to the source code repository.

To generate a new Angular app, use the Angular Cli:

> ng new bwvolleyball-github-io-src
> git remote add origin git@github.com:Bwvolleyball/bwvolleyball-github-io-src.git

Next, we need to add the angular-cli-ghpages tool to our application.

> cd bwvolleyball-github-io-src/
> ng add angular-cli-ghpages
> git commit -m "Adding Angular GitHub pages plugin"

Finally, we need to add the GitHub Actions deployment job.
create .github/workflows/push-to-gh-pages.yml with the following contents:

name: Build and Deploy Github Pages

on:
  push:
    branches:
      - master # - only push to GitHub pages from the master branch

jobs:
  build:

    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [12.x]

steps:
    - uses: actions/checkout@v1
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v1
      with:
        node-version: ${{ matrix.node-version }}
    - name: npm install, build, and test
      run: |
        npm install -g @angular/cli
        npm ci
        ng deploy --repo=https://github.com/bwvolleyball/bwvolleyball.github.io.git --name=bwvolleyball --email=$EMAIL --message="Built from ${GITHUB_SHA} in the source repository." --branch=master
      env:
        CI: true
        GH_TOKEN: ${{ secrets.GithubToken }}
        EMAIL: ${{ secrets.Email }}

The most important parts of this build is that it:
a) installs the angular cli to build the application.
b) installs all dependencies in ci mode (more on that below).
c) deploys the project to my GitHub pages repository, on the master branch, with a commit message that contains the commit sha of the source repo for traceability.
The source file of this build is here.

All this is great, but we have more work to do before this will actually work.
You might have noticed the environment variables at the end of the build file, here’s a breakdown of what they do:

CI sets the ci flag for NPM. This is useful in case we accidentally ran npm install as that environment variable will still guarantee that ci mode is on and that the application installs dependencies strictly from the package-lock.json.
GH_TOKEN must be a Github Access Token so that the GitHub pages angular plugin has write access to your pages repo. Assuming your pages repo is public, you need to generate a token (link here) with only the public_repo permission (Less is more when it comes to security). This is a password that allows the build to push to the GitHub pages repo as me. This is a requirement of the angular-cli-ghpages tool we are using to publish / deploy our GitHub pages site.
EMAIL the most straight forward, I placed my email in a secret so that it’s not just sitting in the repository.

How to add the secrets:

By now you should have also noticed that GH_TOKEN and EMAIL are populated by secrets. In short, this is the mechanism GitHub Actions provides for encrypted build information.
From the repository that you are committing the source code to, select the Settings > Secrets menu, and enter your secrets:

Adding secrets to the source repository.

Once the secrets are entered, I can retrieve them directly from my GitHub Actions build as ${{ secrets.[SECRET_NAME] }}. I then inject these secrets into my build environment.

When you have these secrets set up on the source repository, it’s time to push our repo to GitHub and let it build! If everything is configured correctly, you’ll have a new environment tab on your GitHub pages repo after the build, and it’ll show that your pages application was just deployed:

The `environment` tab now has 1 item.

Activity log of recent deployments.

Thanks for coming along on this journey with me! As a reminder, all the source code and tools used to achieve this are listed at the top of this post. I am excited to finally have a zero-maintenance Angular GitHub Pages site!

Editor's Note

This blog originally appeared on Medium, however, I do not appreciate Medium's style of business, see these thoughts. I will not link to the original Medium blog post as I intend to delete it.