Hierarchical data metrics that allows fast read operations on tree like structures.
Based on Left and Right fields that are set during tree traversal. When entered into node value is set to it's Left, when exiting node value is set to it's Right.
Hierarchical data metrics that allows fast read operations on tree like structures.
Based on Left and Right fields that are set during tree traversal. When entered into node value is set to it's Left, when exiting node value is set to it's Right.
by alexander white ©
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
package main | |
import ( | |
"fmt" | |
"time" | |
) | |
const LIM = 41 | |
var facts [LIM]uint64 |
/******************************************************************************* | |
1. DEPENDENCIES | |
*******************************************************************************/ | |
var gulp = require('gulp'); // gulp core | |
sass = require('gulp-sass'), // sass compiler | |
uglify = require('gulp-uglify'), // uglifies the js | |
jshint = require('gulp-jshint'), // check if js is ok | |
rename = require("gulp-rename"); // rename files | |
concat = require('gulp-concat'), // concatinate js |
If you use git on the command-line, you'll eventually find yourself wanting aliases for your most commonly-used commands. It's incredibly useful to be able to explore your repos with only a few keystrokes that eventually get hardcoded into muscle memory.
Some people don't add aliases because they don't want to have to adjust to not having them on a remote server. Personally, I find that having aliases doesn't mean I that forget the underlying commands, and aliases provide such a massive improvement to my workflow that it would be crazy not to have them.
The simplest way to add an alias for a specific git command is to use a standard bash alias.
# .bashrc
Press minus + shift + s
and return
to chop/fold long lines!
// assumes you add a timestamp field to each record (see Firebase.ServerValue.TIMESTAMP) | |
// pros: fast and done server-side (less bandwidth, faster response), simple | |
// cons: a few bytes on each record for the timestamp | |
var ref = new Firebase(...); | |
ref.orderByChild('timestamp').startAt(Date.now()).on('child_added', function(snapshot) { | |
console.log('new record', snap.key()); | |
}); |