Aseem Kishore aseemk

A Neo4J Experiment: Lookup Nodes vs. Labels

Background

In previous versions of neo4j, people have used an "lookup node" pattern to access certain subgraphs or subsets of their data. The "lookup node" pattern basically creates a single node to act as the entry of an index, and relationships from that "lookup node" to whatever the contents of the index would be.

This can also be used for other use cases, such as creating partitions.

More broadly, these kinds of modeling tricks turn out to be very useful to capture a variety of different kinds of domain semantics, including all sorts of set membership expression:

Expressing that all linked nodes share some common property, without expressing the property individually in every node (i.e. companies whose home country = 'USA')

The prep-script.sh will setup the latest Node and install the latest perf version on your Linux box.

When you want to generate the flame graph, run the following (folder locations taken from install script):

sudo sysctl kernel.kptr_restrict=0
# May also have to do the following:
# (additional reading http://unix.stackexchange.com/questions/14227/do-i-need-root-admin-permissions-to-run-userspace-perf-tool-perf-events-ar )
sudo sysctl kernel.perf_event_paranoid=0

DIY CoffeeScript source map support

CoffeeScript already has source map support via the -m flag, but you have to compile the .coffee first and then run the .js with node for it to be effective. Running the .coffee directly with coffee seems to have no source map support.

This hack recalculates (and caches in memory) the source map on the fly so it can be imported into the excellent source-map-support module. It's disabled if you run the compiled JS file directly (as you would in production) because it assumes the source maps will already have been generated.

CoffeeScript 1.7 is shaping up to be a pretty kick-ass release with significant improvements. Here are the ones I'm most excited about, in order of my own excitement.

Parentheses-free chaining

jashkenas/coffeescript#3263

Years of being wished for, finally granted!

a simple git branching model (written in 2013)

This is a very simple git workflow. It (and variants) is in use by many people. I settled on it after using it very effectively at Athena. GitHub does something similar; Zach Holman mentioned it in this talk.

Update: Woah, thanks for all the attention. Didn't expect this simple rant to get popular.

Run these once to setup git options:

git config --global push.default current
git config --global merge.defaultToUpstream true
git config --global branch.autosetupmerge true
git config --global branch.autosetuprebase remote
git config --global alias.cb 'checkout -b'
git config --global alias.ps 'push -u'
git config --global alias.pl '!git fetch -p && git rebase'

Use them like this:

Splunk Recipes for Heroku

A collection of Splunk recipes for Heroku logs. Instructions for setting up Splunk Storm with Heroku can be found here. For the vast majority of these recipes you'll need to have enabled the Heroku labs feature, log-runtime-metrics, for your application.

	#!/usr/bin/env _coffee
	#
	# Helper script to search all of our files for i18n strings and update our
	# strings file. Helpful in case we missed a code path during testing.
	#
	# Specifically, searches for gettext `__()` calls in our checked-in files.
	#

	$ = require 'underscore'
	echo = console.log

	function params(fn) {
	var str = fn.toString();
	var sig = str.match(/\(([^)]*)\)/)[1];
	if (!sig) return [];
	return sig.split(', ');
	}

	console.api = function(obj){
	console.log();
	var proto = Object.getPrototypeOf(obj);