allgress

(ns reagent-test.core
  (:require [reagent.core :as reagent :refer [atom]]
            [datascript :as d]
            [cljs-uuid-utils :as uuid]))

(enable-console-print!)

(defn bind
  ([conn q]
   (bind conn q (atom nil)))

garybernhardt

This tool is used to compare microbenchmarks across two versions of code. It's
paranoid about nulling out timing error, so the numbers should be meaningful.
It runs the benchmarks many times, scaling the iterations up if the benchmark
is extremely short, and it nulls out its own timing overhead while doing so. It
reports results graphically with a text interface in the terminal.

You first run it with --record, which generates a JSON dotfile with runtimes
for each of your benchmarks. Then you change the code and run again with
--compare, which re-runs and generates comparison plots between your recorded
and current times. In the example output, I did a --record on the master

eulerfx

A state machine is defined as follows:

• Input - a set of inputs
• Output - a set of outputs
• State - a set of states
• S0 ∈ S - an initial state
• T : Input * State -> Output * State - a transition function

If you model your services (aggregates, projections, process managers, sagas, whatever) as state machines, one issue to address is management of State. There must be a mechanism to provide State to the state machine, and to persist resulting State for subsequent retrieval. One way to address this is by storing State is a key-value store. Another way is to use a SQL database. Yet another way is event sourcing. The benefit of even sourcing is that you never need to store State itself. Instead, you rely on the Output of a service to reconstitute state. In order to do that, the state machine transition function needs to be factored into two functions as follows:

greenido

#!/bin/sh
#
# Automatic configuration of a VPN on GCE debian-7-wheezy server. 
# Tested only on debian-7-wheezy.
#
# This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 
# Unported License: http://creativecommons.org/licenses/by-sa/3.0/
#
# Thx to: https://github.com/sarfata/voodooprivacy/blob/master/voodoo-vpn.sh for the code/idea
#

mhart

#!/usr/bin/env node

var path = require('path')
var fs = require('fs')
var lib = path.join(path.dirname(fs.realpathSync(__filename)), '../lib');

require(lib + '/awslambda.js').start_runtime();

oakes

Contents

• Why care about Rust?
• The Toolchain
• Creating a New Project
• Modules
• Crates
• Types
• References
• Mutability

benjaminballard

VoltDB Operations Manual

This is an example of a document that a VoltDB customer or partner might write to document specific processes and commands for common operations with VoltDB.

Hardware & OS

For our VoltDB cluster, use servers with the following specs:
(Note: this is only an example, but you should document the exact hardware used for the installation, and use identical hardware if nodes to the cluster).

Amazon EC2 Example:

In production, we use c3.2xlarge nodes with 8 hyperthreads, 15GB of RAM

wincent

2015-01-29 Unofficial Relay FAQ

Compilation of questions and answers about Relay from React.js Conf.

Disclaimer: I work on Relay at Facebook. Relay is a complex system on which we're iterating aggressively. I'll do my best here to provide accurate, useful answers, but the details are subject to change. I may also be wrong. Feedback and additional questions are welcome.

What is Relay?

Relay is a new framework from Facebook that provides data-fetching functionality for React applications. It was announced at React.js Conf (January 2015).

ramn

#!/bin/bash

socat -v -T0.05 tcp-l:8081,reuseaddr,fork system:"echo 'HTTP/1.1 200 OK'; echo 'Connection: close'; echo; cat"

ryanbrink

#!/usr/bin/python
from AppKit import NSWorkspace 
print NSWorkspace.sharedWorkspace().activeApplication()['NSApplicationName']