DEV Community: Benjamin Lannon

How does Dev internally catch posts that violate TOS?

Benjamin Lannon — Mon, 28 Oct 2019 12:40:26 +0000

This weekend I was endlessly scrolling through the main feed and saw some content that was violating TOS. Some was promoting things like vacations, or posts linking to sites with sexual content. I used the report abuse feature to report them, but given the traffic of the site, I am curious if the team has other avenues or tools to catch these types of posts and take them down?

GitHub Actions v2: JS Actions

Benjamin Lannon — Sat, 17 Aug 2019 13:18:24 +0000

Originally written on lannonbr.com

GitHub announced on August 8 a new beta of GitHub Actions including CI & CD support. I want to look into a variety of new features added into the new beta and capabilities they can do.

This post will look into the new "JavaScript Actions", which allows you to build new actions by just writing JavaScript.

Repo setup & action.yml

We can start out creating a JS Action by creating a directory where our action will live.

mkdir my-cool-action

Next, a file needs to be generated to describe some metadata for the particular action. Create a file named action.yml and fill it in with the following:

name: My Cool Action
author: Benjamin Lannon
description: 'Action that does some cool stuff!'
inputs:
  name:
    description: 'Name'
    required: false
    default: 'Benjamin'
runs:
  using: 'node12'
  main: 'main.js'
branding:
  color: 'green'
  icon: 'send'

The details for the YAML syntax can be found on GitHub's docs here: action.yml syntax docs. It is the file that will allow GitHub to know what file to look for when developing. The main things required are:

name: Gives your action a name.
description: Gives an explanation of what the action is going to do.
runs.using: tells you what kind of action it is. It currently supports either docker for container based actions, or node12 which is what we are using for JS based actions.
runs.main: When using node12 in runs.using, this param defines where your entrypoint is going to be located in the current directory.

As well, a field that is optional but good to look at is the inputs field which defines inputs to the action. all of the IDs will be translated to an environment variable as INPUT_ followed by the ID in uppercase (ex: name will be available as INPUT_NAME).

Next, we can create a main.js file to actually run some JS as part of an action.

// main.js

let name = process.env.INPUT_NAME

console.log(`Hello, ${name}`)

This is an extremely basic example that gets a field from the action and logs out to the console, but it proves that all you need to do to get started with JS Actions is a single yaml file and a JS file.

Inserting into a GitHub Actions Workflow file

Next, I am going to create a workflow that will use this action. I pushed this repo to GitHub so we can prepare to create the workflow.

Next, we want to create a workflow file. It will live in the .github/workflows directory.

# .github/workflows/main.yml
name: Run JS Action
on: push
jobs:
  run-action:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - name: my-cool-action
        uses: ./
        with:
          name: 'Ben'

Going step by step down the file, we describe the workflow, when to execute, and what to execute

name gives a name for this workflow at large.

on describes the event(s) that this action will run on. Here we chose push which happens any time a new commit is pushed to the repo. There's a large list of Event Triggers in the docs that will start workflows.

jobs then defines the set of jobs we need to run in the workflow. Currently we just want to run one job, so we create a single entry and give it an id of run-action.

In this job, we define the environment we want to run it in using the runs-on field. Here we choose ubuntu-latest (which at the time is the newest LTS, 18.04), but we can also run it on windows or macos if we so choose. You can learn here on the Virtual Environments that your actions run in.

Following, each job has a series of steps you want to run. The first step is fetching the repo down and checking out into it using an action built by GitHub called actions/checkout. Each step has a uses field which tells where to find an action. This can include relative paths in the same repo, owner/repo strings (including tags or commit SHAs), paths to a Dockerfile, or even docker images on a registry, and plenty of variations of all of these as defined further in the Actions Docs

Our second step is going to use our action. The relative path for the uses field starts at the root of the repo, and given we dropped the action.yml file in the root, which is how GitHub finds a JS action, we set the uses field to ./. With it as well, we want to pass in our inputs which we can do using the with field which is a series of entries that match to the inputs in our action.yml file.

For other information about the syntax for workflow files, head over to the Workflow syntax for GitHub Actions page in the docs.

If we finally commit this file, it will trigger a push, and such trigger the workflow itself. If you see below, GitHub provides a UI which we can see all of our jobs running and with such, the action we built works!

Follow up

This was an introduction to setting up a JS Action with the new GitHub Actions and creating a workflow. In future posts, I will dive into other new features around GitHub Actions Beta 2 and what we can create with them. Up next, I will follow this article up with creating more advanced actions that interact with GitHub's API using some libraries the Actions team made that makes writing actions easier to manage. Stay tuned.

Writing a validator for Gatsby's Site Showcase

Benjamin Lannon — Sun, 17 Mar 2019 18:23:39 +0000

This past weekend, I made a simple node script to run through the site showcase for GatsbyJS and was very happy with the end results and wanted to talk through the process.

Why do this?

As Gatsby continues to grow with currently over 450 sites in the showcase as a place to show off sites that use Gatsby, being able to maintain and see occasionally that the sites still are around and using Gatbsy is a good sanity check.

As well, this could be good to add into a CI process so when someone submits a site to the showcase, the check could be automated rather than needing to manually check if it is actually a Gatsby site.

Dig into the code

The entire source for this is located on my GitHub:

lannonbr / gatsby-site-showcase-validator

Node script to validate links on Gatsby Site Showcase are actually Gatsby sites

Gatsby Site Showcase Validator

Notice: This Repo is archived as it has been merged into Gatsby's core repo here: https://github.com/gatsbyjs/gatsby/tree/master/.github/actions/gatsby-site-showcase-validator

A simple node script that visits and checks all of the sites in the Site Showcase for Gatsby.

Instructions

Clone down the repository
Install the dependencies with npm or yarn
run node index.js

Run in Docker

You can also run it in Docker with the following command:

docker run --rm lannonbr/gatsby-site-showcase-validator:1.0.0

View on GitHub

Starting out, I pull down the sites.yml file from Gatsby's repo which is used to build the showcase and parse it with js-yaml. Now I have an array of sites and I loop through each and fetch the main_url for each site.

Then when I have the HTML from an individual site, I pass it into cheerio which is a DOM parser for NodeJS that has a jQuery like API.

let $ = cheerio.load(siteHtml);

The main part of the code is to check if it has an element with the "___gatsby" id. which is the default container that is built as part of Gatsby.

let gatsbyContainer = $("#___gatsby")

if (gatsbyContainer.length !== 0) {
  // The page is a gatsby site
} else {
  // The page is not a gatsby site, print out an error message
}

Otherwise, in total the file is only about 70 lines of code but overall it did a fairly good job.

Results

So from the stats, there were only ~20 sites that were either not loading or have moved off of Gatsby as a framework. Doing the math that is less than 5% which is a low percentage so it shows that the site showcase is reputable in showing that the sites that say they are a Gatsby site actually are.

Some cases for why there is a number of sites which return up being invalid likely end up being because the site used to be a Gatsby site but since was rewritten and then was forgotten to be removed from the showcase. Now that a tool like this is around, the number can decrease further and stay fairly low. It's a large task to maintain a large site showcase, but with a little bit of automation and scripts, the task can be made easier.

How does your company value documentation?

Benjamin Lannon — Sun, 24 Feb 2019 14:52:04 +0000

Although many of us benefit from the usage of documentation of both internal and external products, compared to other portions of the codebase including testing or the actual code, documentation can sometimes be lacking.

I want to ask the community how does your company value documentation? If it doesn't as much as you wish, how do you sell to a manager or your team that it would be beneficial to have a stronger focus on documentation?