ktheory

Copyright 2014 Kickstarter, Inc.

Released under an MIT License.

mneedham

import java.io.File;
import java.io.IOException;

import org.apache.commons.io.FileUtils;
import org.apache.commons.math3.stat.descriptive.DescriptiveStatistics;

import org.neo4j.graphdb.Direction;
import org.neo4j.graphdb.DynamicLabel;
import org.neo4j.graphdb.DynamicRelationshipType;
import org.neo4j.graphdb.GraphDatabaseService;

peschlowp

# Transactions with parent-child relationships.

# Delete the index, just in case it still exists.
DELETE /myindex

# Create the index with a mapping for the actual documents and a mapping for the parent transaction type.
PUT /myindex
{
  "mappings": {
    "transaction": {

peschlowp

# Transactions with parent-child relationships using counters.

# Delete the index, just in case it still exists.
DELETE /myindex

# Create the index with a mapping for the actual documents and a mapping for the parent transaction type.
PUT /myindex
{
  "mappings": {
    "transaction": {

karmi

nginx/
!nginx/.gitkeep
!nginx/logs/.gitkeep

src/

tmp/

rvanbruggen

// What is related, and how
MATCH (a)-[r]->(b)
WHERE labels(a) <> [] AND labels(b) <> []
RETURN DISTINCT head(labels(a)) AS This, type(r) as To, head(labels(b)) AS That
LIMIT 20

//show me NeoTech
match (n:Company {name:"Neo Technology"}) return n

//show me NeoTech (excl Partners)

josiahcarlson

'''
rate_limit2.py

Copyright 2014, Josiah Carlson - josiah.carlson@gmail.com
Released under the MIT license

This module intends to show how to perform standard and sliding-window rate
limits as a companion to the two articles posted on Binpress entitled
"Introduction to rate limiting with Redis", parts 1 and 2:

ipmb

upstream myapp {
    server 127.0.0.1:8081;
}

limit_req_zone $binary_remote_addr zone=login:10m rate=1r/s;

server {
    listen 443 ssl spdy;
    server_name _;
  

mikelehen

/**
 * Fancy ID generator that creates 20-character string identifiers with the following properties:
 *
 * 1. They're based on timestamp so that they sort *after* any existing ids.
 * 2. They contain 72-bits of random data after the timestamp so that IDs won't collide with other clients' IDs.
 * 3. They sort *lexicographically* (so the timestamp is converted to characters that will sort properly).
 * 4. They're monotonically increasing.  Even if you generate more than one in the same timestamp, the
 *    latter ones will sort after the former ones.  We do this by using the previous random bits
 *    but "incrementing" them by 1 (only in the case of a timestamp collision).
 */

KMahoney

-- So as an example of using a log orientated approach in PostgreSQL,
-- let's write a simple blog application. We will want to be able to:

-- * Write and edit blog posts
-- * Publish revisions of posts for public viewing
-- * Delete posts
-- * Add or remove tags to posts

-- Let's start by creating a schema.