cpursley

PostgreSQL is Enough

• Simplify: move code into database functions
• Just Use Postgres for Everything
• PostgreSQL is the worlds’ best database
• Postgres is eating the database world
• Hacker News discussion

Background and Cron Jobs

dukeofharen

_These are the rules for posting recommendations. If you break one, I will ignore you. Read them before making a suggestion:

1.If you suggest even one track that is already on the list, I will ignore all other tracks in your suggested list. Use edit/find (on this page), or hit control-f to search out tracks before recommending them. Don't just whip your playlist off into the comments, I want you to make sure it's a)better than some of the tracks on this list, and b)NOT ALREADY ON IT, before you suggest I add it. This list is massive, and the base of tracks it was selected out of is even bigger. I don't mean to be a jerk about it, but I don't have the time to sift through records that are already on the list. Plus, that tells me you didn't think about your suggestion.

2.If you've been listening to trance for less than 9 months, you have a DJ Mystik track on your computer anywhere, or you still (seriously) find tracks by typing "trance" or "techno" into a file sharing program, then please don't suggest anythi

jsjaspreet

import fs from 'fs';
import path from 'path';
import { graphql } from 'graphql';
import { introspectionQuery } from 'graphql/utilities';
import schema from './src/schema/index';

(async () => {
  const result = await graphql(schema, introspectionQuery);
  if (result.errors) {
    console.error(

oliveratgithub

{
	"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

developit

import { h, Component } from 'preact';


/** Creates a new store, which is a tiny evented state container.
 *  @example
 *    let store = createStore();
 *    store.subscribe( state => console.log(state) );
 *    store.setState({ a: 'b' });   // logs { a: 'b' }
 *    store.setState({ c: 'd' });   // logs { c: 'd' }
 */

GAME_MASTER_v0_1.protobuf

Result: 1
Items {
  TemplateId: "BADGE_BATTLE_ATTACK_WON"
  Badge {
    BadgeType: BADGE_BATTLE_ATTACK_WON
    BadgeRanks: 4
    Targets: "\nd\350\007"
  }
}
Items {

joshdover

Idiomatic React Testing Patterns

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.

Setup

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:

threepointone

architectures and whatnot

1. plain ol' React

let state = initial
render(view(state), element)

• view is pure!

davoclavo

emacs --daemon to run in the background. emacsclient.emacs24 <filename/dirname> to open in terminal

NOTE: "M-m and SPC can be used interchangeably".

• Undo - C-/
• Redo - C-?
• Change case: 1. Camel Case : M-c 2. Upper Case : M-u

3. Lower Case : M-l

OlegIlyenko

In this gist I would like to describe an idea for GraphQL subscriptions. It was inspired by conversations about subscriptions in the GraphQL slack channel and different GH issues, like #89 and #411.

Conceptual Model

At the moment GraphQL allows 2 types of queries:

• query
• mutation

Reference implementation also adds the third type: subscription. It does not have any semantics yet, so here I would like to propose one possible semantics interpretation and the reasoning behind it.