junegunn

# fshow - git commit browser (enter for show, ctrl-d for diff, ` toggles sort)
fshow() {
  local out shas sha q k
  while out=$(
      git log --graph --color=always \
          --format="%C(auto)%h%d %s %C(black)%C(bold)%cr" "$@" |
      fzf --ansi --multi --no-sort --reverse --query="$q" \
          --print-query --expect=ctrl-d --toggle-sort=\`); do
    q=$(head -1 <<< "$out")
    k=$(head -2 <<< "$out" | tail -1)

megalithic

set filename to POSIX path of input
set cmd to "cd `dirname " & filename & "`; vim " & filename

tell application "iTerm"
	tell the current window
		# Uncomment the next line if you want to create a new iTerm tab instead.
		#create tab with default profile
		tell the current session
			tell application "iTerm" to activate
			delay 1

mattmccray

export function ComponentWithMixins( ...mixins) {

    class MixedComponent extends React.Component { }
    
    for( let mixin of mixins) {
        // TODO: Would need to handle mixin collisions...   
        for( let name of Object.keys( mixin)) {
            MixedComponent.prototype[ name]= mixin[ name]
        }
    }

domenic

Auto-deploying built products to gh-pages with GitHub Actions

This is a set up for projects which want to check in only their source files, but have their gh-pages branch automatically updated with some compiled output every time they push.

A file below this one contains the steps for doing this with Travis CI. However, these days I recommend GitHub Actions, for the following reasons:

• It is much easier and requires less steps, because you are already authenticated with GitHub, so you don't need to share secret keys across services like you do when coordinate Travis CI and GitHub.
• It is free, with no quotas.
• Anecdotally, builds are much faster with GitHub Actions than with Travis CI, especially in terms of time spent waiting for a builder.

ecnerwala

# +--------------------+
# |                    |
# |   GENERAL CONFIG   |
# |                    |
# +--------------------+

PROBLEM_NAME := problem_name
DEBUG := true
LANG := cpp

drewsberry

#!/bin/bash

# Run this scrript in the root directory of your Jekyll source
# repository for your GitHub page, and it will commit and push
# the source to origin/source, then build, commit and push the 
# resuling HTML to your origin/master, i.e. your website. The
# commit message for both commits is given by the first 
# argument.

if [[ -z "$1" ]]; then

staltz

The introduction to Reactive Programming you've been missing

(by @andrestaltz)

---

This tutorial as a series of videos

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.

---

pkuczynski

#!/bin/sh
parse_yaml() {
   local prefix=$2
   local s='[[:space:]]*' w='[a-zA-Z0-9_]*' fs=$(echo @|tr @ '\034')
   sed -ne "s|^\($s\)\($w\)$s:$s\"\(.*\)\"$s\$|\1$fs\2$fs\3|p" \
        -e "s|^\($s\)\($w\)$s:$s\(.*\)$s\$|\1$fs\2$fs\3|p"  $1 |
   awk -F$fs '{
      indent = length($1)/2;
      vname[indent] = $2;
      for (i in vname) {if (i > indent) {delete vname[i]}}

kevin-smets

Default

Powerlevel10k

branneman

Better local require() paths for Node.js

Problem

When the directory structure of your Node.js application (not library!) has some depth, you end up with a lot of annoying relative paths in your require calls like:

const Article = require('../../../../app/models/article');

Those suck for maintenance and they're ugly.

Possible solutions