Everyone knows that to create a new Promise, you need to define it this way:
new Promise((resolve, reject) => {
...
resolve(someValue)
})
You pass a callback that defines the specific behavior of your promise.
/** | |
* # How does `A extends B` work in TypeScript? | |
* | |
* If you think about types in terms of sets containing possible values, | |
* the `string` type is the set of all possible strings, | |
* the `number` type is the set of all possible numbers, | |
* the `'hello'` type is a set containing only the string 'hello' | |
* and the `2` type is a set containing only the number 2. | |
* | |
* Then you can think of `A extends B` as asking this question: |
$ uname -r
export type Option<T> = | |
| { readonly type: 'some'; readonly value: T } | |
| { readonly type: 'none' }; | |
export const none: Option<never> = { type: 'none' }; | |
export const some = <T>(value: T): Option<T> => ({ type: 'some', value }); | |
const compose = |
Originally taken from: Braintree Article and expanded on by me.
<!DOCTYPE html> | |
<html> | |
<head> | |
<title></title> | |
</head> | |
<body> | |
<!-- This iframe will always fill the parent width, but will remain at 16:9 aspect ratio --> | |
<div class="ratio-16-9"> | |
<iframe class="ratio-inner" src="https://sketchfab.com/models/{{model_id}}/embed"></iframe> |
Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, it's quite easy to make mistakes or not know what you should do when you're initially learning the process. I know that I certainly had considerable initial trouble with it, and I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.
In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.
Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or j
Git hooks for better pivotal integration:
pre-commit
:
develop
, master
) and hotfix
es are not constrainedprepare-commit-msg
: prepend issue number to commit message if it's missing and if it is set in the branch name (see pre-commit
hook)post-checkout
: [optional] automatically update submodules when checkouting a branch (requires to define the AUTO_SUBMODULE_UPDATE
environment variable)For easy setup:
// CSS Color Names | |
// Compiled by @bobspace. | |
// | |
// A javascript object containing all of the color names listed in the CSS Spec. | |
// This used to be a big array, but the hex values are useful too, so now it's an object. | |
// If you need the names as an array use Object.keys, but you already knew that! | |
// | |
// The full list can be found here: https://www.w3schools.com/cssref/css_colors.asp | |
// Use it as you please, 'cuz you can't, like, own a color, man. |
If someone forks a gist and you'd like to merge their changes. Do this:
clone your repo, I use the name of the gist
git clone git://gist.github.com/1163142.git gist-1163142
add a remote for the forked gist, I'm using the name of my fellow developer
git remote add aaron git://gist.github.com/1164196.git