ryanflorence

const {
  NativeRouter,
  Nav,
  StackMatch,
  StackScene,
  StackTitle,
  StackContent
} = 'react-router/native'

const App = () => (

kbilsted

Moved to https://github.com/kbilsted/Functional-core-imperative-shell/blob/master/README.md

awjuliani

acdlite

// getComponent is a function that returns a promise for a component
// It will not be called until the first mount
function asyncComponent(getComponent) {
  return class AsyncComponent extends React.Component {
    static Component = null;
    state = { Component: AsyncComponent.Component };

    componentWillMount() {
      if (!this.state.Component) {
        getComponent().then(Component => {

mbollmann

class AttentionLSTM(LSTM):
    """LSTM with attention mechanism

    This is an LSTM incorporating an attention mechanism into its hidden states.
    Currently, the context vector calculated from the attended vector is fed
    into the model's internal states, closely following the model by Xu et al.
    (2016, Sec. 3.1.2), using a soft attention model following
    Bahdanau et al. (2014).

    The layer expects two inputs instead of the usual one:

giuseppebonaccorso

'''
OpenAI-Gym Cartpole-v0 LSTM experiment
Giuseppe Bonaccorso (http://www.bonaccorso.eu)
'''

import gym
import numpy as np
import time

from keras.models import Sequential

noeljackson

#from https://www.linux.com/learn/how-use-docker-machine-create-swarm-cluster
#export digital ocean token
export DO_TOKEN="abcdefghijklmnopqrstuvwxyz"

#make keystore
docker-machine create -d digitalocean \
-digitalocean-access-token ${DO_TOKEN} \
--digitalocean-region "nyc1" \
--digitalocean-image="ubuntu-14-04-x64" \
--digitalocean-size "512mb" \

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:

gilyes

Backup:
docker exec -t -u postgres your-db-container pg_dumpall -c > dump_`date +%d-%m-%Y"_"%H_%M_%S`.sql

Restore:
cat your_dump.sql | docker exec -i your-db-container psql -Upostgres

bitdivine

-- Refresh materialized views recursively

-- DEPENDS:
-- List the tables that a view depends on.
-- Thanks to Dave: http://stackoverflow.com/questions/4229468/getting-a-list-of-tables-that-a-view-table-depends-on-in-postgresql
create or replace function inf_view_dependencies(v text)
returns table (kind text, name text) as $$
SELECT     cl_d.relkind::text as kind
        ,  cl_d.relname::text AS name
FROM pg_rewrite AS r