It's now here, in The Programmer's Compendium. The content is the same as before, but being part of the compendium means that it's actively maintained.
{ | |
"emojis": [ | |
{"emoji": "👩👩👧👧", "name": "family: woman, woman, girl, girl", "shortname": ":woman_woman_girl_girl:", "unicode": "1F469 200D 1F469 200D 1F467 200D 1F467", "html": "👩‍👩‍👧‍👧", "category": "People & Body (family)", "order": ""}, | |
{"emoji": "👩👩👧👦", "name": "family: woman, woman, girl, boy", "shortname": ":woman_woman_girl_boy:", "unicode": "1F469 200D 1F469 200D 1F467 200D 1F466", "html": "👩‍👩‍👧‍👦", "category": "People & Body (family)", "order": ""}, | |
{"emoji": "👩👩👦👦", "name": "family: woman, woman, boy, boy", "shortname": ":woman_woman_boy_boy:", "unicode": "1F469 200D 1F469 200D 1F466 200D 1F466", "html": "👩‍👩‍👦‍👦", "category": "People & Body (family)", "order": ""}, | |
{"emoji": "👨👩👧👧", "name": "family: man, woman, girl, girl", "shortname": ":man_woman_girl_girl:", "unicode": "1F468 200D 1F469 200D 1F467 200D 1F467", "html": "👨‍👩&z |
Testing React components seems simple at first. Then you need to test something that isn't a pure interaction and things seem to break down. These 4 patterns should help you write readable, flexible tests for the type of component you are testing.
I recommend doing all setup in the most functional way possible. If you can avoid it, don't set variables in a
beforeEach
. This will help ensure tests are isolated and make things a bit easier to reason about. I use a pattern
that gives great defaults for each test example but allows every example to override props
when needed:
Since Twitter doesn't have an edit button, it's a suitable host for JavaScript modules.
Source tweet: https://twitter.com/rauchg/status/712799807073419264
const leftPad = await requireFromTwitter('712799807073419264');
/* bling.js */ | |
window.$ = document.querySelector.bind(document); | |
window.$$ = document.querySelectorAll.bind(document); | |
Node.prototype.on = window.on = function(name, fn) { this.addEventListener(name, fn); }; | |
NodeList.prototype.__proto__ = Array.prototype; | |
NodeList.prototype.on = function(name, fn) { this.forEach((elem) => elem.on(name, fn)); }; |
var elements = document.querySelectorAll("div"), | |
callback = (el) => { console.log(el); }; | |
// Spread operator | |
[...elements].forEach(callback); | |
// Array.from() | |
Array.from(elements).forEach(callback); | |
// for...of statement |
DBCollection.prototype.read = function (id) { | |
return this.findOne({ _id: ObjectId(id) }) | |
} | |
DBCollection.prototype.delete = function (id) { | |
return this.remove({ _id: ObjectId(id) }) | |
} | |
function notablescan() { | |
var currentValue = db.getSiblingDB('admin').runCommand({ getParameter: 1, notablescan: 1 }).notablescan |
(function() { | |
function status(response) { | |
if (response.ok) { | |
return response | |
} else { | |
var error = new Error(response.statusText || response.status) | |
error.response = response | |
throw error | |
} | |
} |
To allow us to automatically create a good quality changelog from our git history we recommend the following formats for commit messages.
The aim is to capture a reference to any ticket, card, or story that this commit contributes towards.
Because we are now using the Pivotal Tracker Webhook on some projects we suggest wrapping your commit message prefix with square brackets []
http://pivotallabs.com/level-up-your-development-workflow-with-github-pivotal-tracker/