Will Bradley wbbradley

Push-o-matic

Want to work locally on your web site but have your changes periodically (like every minute) updated on Heroku?

#!/bin/bash

while [ true ]
do
	echo "Pushing recent changes to Heroku..."

Auction lot spacing

Devise an algorithm to order lots in an auction based on the following guidlines:

Sellers of individual items should have their own lots spaced as evenly apart as possible
Items sold should generally go from cheapest to most expensive

South Migration Rebasing

Framing the problem

(Note: this procedure will work pretty well for simple additions of properties on models, and the like. More complex changes will require more thought.)

Let's assume you have a branch off of master that has been creating lots of migrations. It forked when master was at 0017_migration_on_master.py. Now, on the branch, let's call it data-crazy, we're up to 0028_migration_on_data_crazy.py. Sadly, someone had to jump onto master and make a schema change to the database. This bumped master up to 0018_migration_on_master.py. Now, we need to merge those changes into data-crazy in order to eventually be able to merge back into master once we're stable and our feature is complete.

The Manual Rebase Process

Validate the new base of your rebase.

XHR

model = {
  property_a: 'hello',
  property_b: 'world'
};

xhr=jQuery.ajax({type:'post', dataType:'json', url:'http://localhost:8000/api/...', data:JSON.stringify(model),'contentType':'application/json'})

Refactoring and Data Migration in Django

Often we need to change the way a piece of data is modelled on our backend. Recently I was faced with refactoring a large model into component pieces and needed a cheat sheet for the best practices to use when migrating live data on our production server to a new schema.

This is an explanation of how to perform an extractClass refactoring from within the context of a Django models.Model. For this tutorial, I'll assume you are familiar with schemamigration using South.

The basic purpose of this type of refactoring is usually one of the following:

to DRY up your data model, such that a similar schema can be reused in multiple places
to implement a One to Many relationship on data that is currently One to One, and tightly coupled to an existing Model

	<script src="http://jashkenas.github.com/coffee-script/extras/coffee-script.js"
	type="text/javascript"
	charset="utf-8"></script>
	<script type="text/coffeescript">
	# Some CoffeeScript
	</script>

	import pdb
	from subprocess import call
	breakpoint = pdb.set_trace

	def set_trace():
	call(["say", "break point"])
	breakpoint()
	pdb.set_trace = set_trace

	[contenteditable] {
	border: 2px solid rgba(0,0,0,0);
	}
	[contenteditable]:hover {
	border: 2px dashed #eeeeee;
	}
	[contenteditable]:empty {
	border: 2px dashed #ddeeee;
	font-style: italic;
	}

	class MyModel extends Backbone.Model
	sync: (method, model, options) =>
	console.log 'MyModel : info : trying to coerce property_X to be property_Y when pushed to server'
	if method in ['create', 'update', 'patch']
	options.attrs = @toJSON(options)
	options.attrs.property_Y = @get('property_X')
	delete options.attrs.property_X
	super


	###
	# Backbone views
	###
	#
	# Handling subviews:
	# http://stackoverflow.com/questions/9337927/how-to-handle-initializing-and-rendering-subviews-in-backbone-js
	# Basic render strategy:
	# http://ianstormtaylor.com/rendering-views-in-backbonejs-isnt-always-simple/