DewaldDeJager

Sync Fork

This workflow uses the GitHub CLI to keep a forked repo in sync with the upstream repo. Add it to your repo as .github/workflows/sync-fork.yaml.

It runs daily to sync the default branch and can be triggered manually for any branch.

Zebiano

DDClient setup

Warning: I believe the paths to be outdated, as DDClient docs point to /etc/ddclient/ddclient.conf instead of /etc/ddclient.conf. However, this document should still work regardless.

Quick and easy steps to get DDClient running with Namecheap and as a systemd service on Ubuntu Server OS.

• Installation
• Configuration
• Check if it works
• Run ddclient as a service

sindresorhus

Pure ESM package

The package that linked you here is now pure ESM. It cannot be require()'d from CommonJS.

This means you have the following choices:

1. Use ESM yourself. (preferred)
   Use import foo from 'foo' instead of const foo = require('foo') to import the package. You also need to put "type": "module" in your package.json and more. Follow the below guide.
2. If the package is used in an async context, you could use await import(…) from CommonJS instead of require(…).
3. Stay on the existing version of the package until you can move to ESM.

whatupfoo

Organization archetypes

The intention of this document is to provide some guidance and suggestions to customers who are wondering how they should structure organizations and teams in their GitHub Enterprise environment. The idea isn't to give hard and fast rules on which approach is better than the other, but to give examples of when one approach might be preferable to another depending on the use case.

1. A single organization with direct organization membership for repository access (not teams)

          ________________
          |     Org      |
          |    ______    |
          |   |      |\  |

| | Repo | \ |

nhtua

#!/bin/bash -i
#using shebang with -i to enable interactive mode (auto load .bashrc)

set -e #stop immediately if any error happens

# Install Open SDK
apt update
apt install openjdk-8-jdk -y
update-java-alternatives --set java-1.8.0-openjdk-amd64
java -version

48klocs

// Mercules' Erentil FR4 breakdown
// https://www.reddit.com/r/DestinyTheGame/comments/cbxao7/massive_breakdown_of_erentil_fr4_including_stats/

// Erentil FR4
dimwishlist:item=3027844941&perks=194952923,3868766766,280464955,1600092898
dimwishlist:item=3027844941&perks=194952922,3868766766,280464955,1600092898
dimwishlist:item=3027844941&perks=194952923,2969185026,280464955,1600092898
dimwishlist:item=3027844941&perks=194952922,2969185026,280464955,1600092898
dimwishlist:item=3027844941&perks=194952923,3868766766,1645158859,1600092898
dimwishlist:item=3027844941&perks=194952922,3868766766,1645158859,1600092898

luismts

Git Commit Best Practices

Basic Rules

Commit Related Changes

A commit should be a wrapper for related changes. For example, fixing two different bugs should produce two separate commits. Small commits make it easier for other developers to understand the changes and roll them back if something went wrong. With tools like the staging area and the ability to stage only parts of a file, Git makes it easy to create very granular commits.

Commit Often

Committing often keeps your commits small and, again, helps you commit only related changes. Moreover, it allows you to share your code more frequently with others. That way it‘s easier for everyone to integrate changes regularly and avoid having merge conflicts. Having large commits and sharing them infrequently, in contrast, makes it hard to solve conflicts.

lukechilds

get_latest_release() {
  curl --silent "https://api.github.com/repos/$1/releases/latest" | # Get latest release from GitHub api
    grep '"tag_name":' |                                            # Get tag line
    sed -E 's/.*"([^"]+)".*/\1/'                                    # Pluck JSON value
}

# Usage
# $ get_latest_release "creationix/nvm"
# v0.31.4

tracker1

Directory structure for JavaScript/Node Projects

While the following structure is not an absolute requirement or enforced by the tools, it is a recommendation based on what the JavaScript and in particular Node community at large have been following by convention.

Beyond a suggested structure, no tooling recommendations, or sub-module structure is outlined here.

Directories

• lib/ is intended for code that can run as-is
• src/ is intended for code that needs to be manipulated before it can be used