Zach Kanzler theY4Kman

This library makes it easy to display progress to users on long-running tasks. It can be used directly with existing Celery tasks. Here's a quick demo:

# mymodule/views.py
from celery import task
from hivelocity.asyncweb import async_group

@task
def my_task(a, b, c):
 do_something_longrunning(a, b, c)

My gut instinct is directory structure comes natural if you understand the components of the library. I don't think it requires a laborious planning process. So, I'm gonna recount the components:

Underlying compiler (converts an AST directly to a Cypher query)
- Actual compiler (lucking out because there's only one dialect: Neo4j's Cypher)
- Basic elements of the compiler (MATCH, RETURN, etc)
- Basic types of Neo4j (string, int, float, array)
- Base type classes, defining the contract of types, and making user-defined types easy to define (akin to SQLA's TypeEngine and TypeDecorator)
Object Graph Mapper (OGM, the ORM of graph shit, ooh-la-la -- NoSQL with relationships)
- Node base class
Relationship base class

You may hear the term "Unit of Work" tossed around with SQLAlchemy, often in contrast with Django. Basically, with Django (which you'll hear has the Active Record pattern), you grab an object from the database, modify it a bit, then call its save() method to commit your changes to the database. The SQLAlchemy model, which I won't disguise my love of, works a bit differently: you grab an object from the database using a Session object, which keeps track of that object. You modify the object, then call the session's commit() method. The session then goes over all the objects it's keeping track of, recognizes what's changed, then develops a set of distinct tasks to carry out our modifications (the units of work).

I love this, because it allows for some pretty great optimizations. With Django, if you create a bunch of objects, you can either call save() on them all, which means a query for every object, or you call a specialized batch method to commit them all at once. With SQLAlchemy, you create instances

The Base

At the core of things, you're taking an abstract syntax tree (AST) and compiling it into a string (the query which gets sent to the database). The point of an AST is to break a language down into its core components, where each component contains other componennts until you reach a concrete level where things can go no further (such as a literal number 1 or a string "test").

To build a good extensible ORM, the you'll first need AST components. Let's build one of those, and a compiler to turn the AST into a query string.

class Element(object):
    __visit_name__ = 'element'

Abstractier

The compiler builds a query string from an AST. To execute queries, you'll work with the compiler's AST interface.

The OGM's interface is built on Nodes and Props.

Overview

At the lowest level, NeoAlchemy uses an AST to build and execute queries. An AST is built upon Element subclasses, each storing information about itself. This information is used by a Compiler subclass to turn each Element into a string. It does this using its visit_xxx methods, which match up to the __visit_name__ property of Element.

	import time
	import urllib2
	from datetime import datetime


	def do_dave():
	while 10 > datetime.now().hour > 15:
	time.thleep(5)
	urllib2.urlopen('http://www.reddit.com/')

	keycode 108 = Mode_switch
	keysym a = a A Left
	keysym d = d D Right
	keysym s = s S Down
	keysym w = w W Up

	// ==UserScript==
	// @name Hipchat Click to View Images
	// @version 0.2
	// @match https://*.hipchat.com/chat
	// @copyright 2014, Zach "theY4Kman" Kanzler
	// @grant GM_unsafeWindow
	// ==/UserScript==


	// Add styles to initially disable images

	// ==UserScript==
	// @name Hipchat Click to View Images
	// @version 0.1
	// @match https://*.hipchat.com/chat
	// @copyright 2014, Zach "theY4Kman" Kanzler
	// @grant GM_unsafeWindow
	// ==/UserScript==


	// Add styles to initially disable images

	from .local import config


	config.render(globals())