git clone git@github.com:YOUR-USERNAME/YOUR-FORKED-REPO.git
cd into/cloned/fork-repo
git remote add upstream git://github.com/ORIGINAL-DEV-USERNAME/REPO-YOU-FORKED-FROM.git
git fetch upstream
// 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()); | |
}); |
unless Rails.env.production? | |
connection = ActiveRecord::Base.connection | |
connection.tables.each do |table| | |
connection.execute("TRUNCATE #{table}") unless table == "schema_migrations" | |
end | |
sql = File.read('db/import.sql') | |
statements = sql.split(/;$/) | |
statements.pop |
module AlertConfirmer | |
class << self | |
def reject_confirm_from &block | |
handle_js_modal 'confirm', false, &block | |
end | |
def accept_confirm_from &block | |
handle_js_modal 'confirm', true, &block | |
end |
#!/usr/bin/env python | |
# -*- coding: utf-8 -*- | |
# Based on the rolling codes/hopping codes problem: | |
# http://programmingpraxis.com/2014/05/16/rolling-code | |
# | |
# We simulate a parking lot with multiple fobs and receivers | |
# sending and receiving signals (respectively). This is also | |
# a demonstration of a simple use of generator-based coroutines | |
# in Python (although they are not necessary here). |
import android.support.v7.widget.LinearLayoutManager; | |
import android.support.v7.widget.RecyclerView; | |
public abstract class EndlessRecyclerOnScrollListener extends RecyclerView.OnScrollListener { | |
public static String TAG = EndlessRecyclerOnScrollListener.class.getSimpleName(); | |
private int previousTotal = 0; // The total number of items in the dataset after the last load | |
private boolean loading = true; // True if we are still waiting for the last set of data to load. | |
private int visibleThreshold = 5; // The minimum amount of items to have below your current scroll position before loading more. | |
int firstVisibleItem, visibleItemCount, totalItemCount; |
/** | |
* 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). | |
*/ |
There is a project that I've spent the last two to three months working on that uses Firebase. The project includes a web app and iOS application and focuses heavily on real-time user interaction. We've really enjoyed working with Firebase and the Firebase web and iOS SDKs. It makes this real-time programming much simpler than rolling our own data-syncing solution for the server and multiple client language.
It will soon (in the next two weeks) be time to release the project, and we have no effective way in place to back up our data. Firebase offers a "private backups" feature for the "Bonfire" plan, but we obviously don't want to pay the $150 / month until we absolutely have to. Until we reach a point where we will use the Bonfire plan, we are forced to roll our own solution.
Must-haves:
''' | |
Created on Feb 8, 2015 | |
@author: David Ray | |
''' | |
import numpy as np | |
from nupic.encoders.scalar import ScalarEncoder as ScalarEncoder | |
from nupic.algorithms.CLAClassifier import CLAClassifier as CLAClassifier |
// https://gist.github.com/mikelehen/3596a30bd69384624c11 | |
/** | |
* 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). |