Post-Rice Haze

Worst Line of Code and Why

I needed to grab the latest Link object for a certain Forum from Django’s ORM.

Normally, I’d do this with:

link = forum.link_set.order_by('-id')[0]

But for some reason, adding the slice (which adds a limit to the SQL query), was considerably slowing down the call. Whereas, just getting the iterator was fine.

link_qs = forum.link_set.order_by('-id')

Which is disturbing. I haven’t figured out why, but I wanted to get the code I was working on done before figuring out why this query was slow, so I hacked around it.

So, of course, I could just convert that QuerySet to a list and index the list with:

link = list(forum.link_set.order_by('-id'))[0]

But that would load the entire result into memory. My results could potentially be extremely large, so I didn’t want to go down that route.

So I wrote the obvious solution, using the iterator, but only saving the first result. Which turned out to be one of the worst lines of code I’ve ever written.

In all it’s glory:

for link in forum.link_set.order_by('-id'):
    break

i’ve lost it

i grew up. learned how to take care of myself.
buy beer. car insurance.

and suddenly the words don’t pretty. oh! forgot the insomnia of restless sparkling girls’ eyes from across the bar. two sets at a time.

oh!

suddenly midnights are:
consumption.
alcohol. television. transportation. oh!

nothing geography can’t solve?

Elegant Fibonacci Iterator

After a bunch of versions of Fibonacci functions months back, the following iterator appeared in my notebook.

def fib():

    future = [0, 1]

    while True:

        future.append(sum(future))

        yield future.pop(0)

Though of no particular engineering marvel. It is, at O(n), slower than the best case O(log(n)) I can do using matrix multiplication of powers of two.

I find it particularly elegant.

Mocking with Python

After recent conversations about the surgery I did to the DISQUS IMAP processing code in order to make it testable, I was steered toward Python mock modules. Of which there are a lot.

So I installed the python-mock module and coded up a quick example use case.

Often when writing unit tests, you stumble upon dependencies that the code you’re testing uses, but are orthogonal to the actual functionality being tested.

At DISQUS, this was IMAP processing code that clearly depended heavily on an api into an IMAP mail server. But the functionality being tested was just what the processing did to incoming email from said server. So I wrote a fake IMAP api that just passed around test messages.

However this is generally easier to do using mock objects. The mock objects can catch all methods called on them, so there’s no need to strictly match the expected api. And we can inspect the actual calls made to make sure they are what we expected.

So for an example I coded up a simple logger. In a production environment, it would be helpful to log data for debugging, etc. But while testing this is unnecessary.

The following code does BFS using a simple logger:

	def search(self, label):
		"""
		Search for label in graph. Return list of nodes visited in path.
         Note: Uses BFS.
		"""
		visited = set()
		queue = [(self, [])]
		while queue:
			node, path = queue.pop(0)
			self.logger.log('Visiting node %s with path %s.' %
                      (node.label, [n.label for n in path]), severity=1)

			if node in visited:
				continue
			visited.add(node)

			path.append(node)
			if node.label==label:
				return path
			else:
				for edge in node.edges:
					edge_path = copy.copy(path)
					queue.append((edge, edge_path))

		self.logger.log('Not found.', severity=2)
		return None

Which is easy enough to test, except that we’ll be leaving log files around with this information. Instead of a real logger, we can pass in a mocked object as such:

class NodeTests(unittest.TestCase):

	def setUp(self):
		logger = mock.Mock( {'log' : 'log called'} )

		austin = Node('austin', [], logger)
		dallas = Node('dallas', [austin], logger)
		houston = Node('houston', [austin, dallas], logger)
		san_antonio = Node('san antonio', [austin, houston], logger)

		self.logger = logger
		self.graph = san_antonio

	def testSearch(self):
		result = self.graph.search('dallas')
		labels = [node.label for node in result]

		self.assertEqual(['san antonio', 'houston', 'dallas'], labels)
		self.assertEqual(5, len(self.logger.mockGetNamedCalls('log')))

Easy enough. And a lot easier that writing up a fake logger that matches the expected api.

Tackling JavaScript

Lately, I’ve been looking at JavaScript a little differently. Instead of writing JavaScript as dirty hacks to do DOM manipulation, handle JavaScript as a first-class language in itself and write elegant code to do DOM manipulation. Something I should have been doing all along. Toward that goal, I tackled a little project to exercise writing elegant JavaScript code.

At least until I can have python in the browser.

This was sparked by bit of fiddling with SproutCore and reading about the other advanced JavaScript frameworks. In those frameworks, binding a bit of data to a view is the standard. The framework handles the glue code that keeps that data and the display in sync, while the programmer is left to do whatever data manipulation is needed.

So I wrote a small SproutCore application that read network feeds and updated a displayed HTML list. The code that updates this need only concern itself with the data side of the equation and not the view. Which was all MVC and fine and dandy. Elegant in fact.

But what bothered me was this data was handled in an intermediate representation defined by the framework. So to manipulate this data, I needed to know the framework’s API for manipulating it’s representation.

There’s no reason that internal representation cannot be similar (if not exactly like) JavaScript’s own Array.prototype.

Hence boundarray was born. Just a simple wrapper around the JavaScript Array.prototype with a near exact implementation that also handles updating a HTML list element. I thought this would be a perfect little project to exercise my JavaScript, so I quickly put up a public github repository and got coding.

It was certainly a learning experience in writing clean JavaScript code as well as truly getting to know JavaScript’s Array.prototype.

boundarray

boundarray provides a constructor called BoundArray that creates an intermediate representation that behaves exactly as a JavaScript Array with one single exception.

An example use of boundarray with code snippets and a working example lives here.

After conversations with a couple of JavaScript expert friends of mine, it became evident that it’s currently impossible to implement Array.prototype entirely in JavaScript.

The problem creeps in because Array.prototype supports implicitly growing the length of the Array. For example:

var numbers = ['one', 'two', 'three'];
numbers[4] = 'five';

The assignment in the second statement is out of the bounds of the array. So JavaScript silently grows the array and makes the assignment leaving an array that looks like: ['one', 'two', 'three', undefined, 'five']

Currently JavaScript provides no means of catching assignment to undefined properties. There is a way to catch calls to undefined properties with Object.prototype.__noSuchMethod__, but no similar method for properties.

But failing that one little difference, a BoundArray behaves exactly like a JavaScript Array as defined at the Mozilla Developer Center, but has the side effect of updating a displayed HTML list element.

For more information on BoundArray see it’s public github repository.

Next on the list is to consider rolling this into a plugin for JQuery or something similar.

Juicy

I always rap on and on about how hip-hop is the natural extension of postmodernism, but rarely offer up much on the subject. In an effort to start getting some of it on paper, I’m going to start tackling the topic here.

Saturday I went down to Mountain View for Rock the Bells. Mostly for Dead Prez. After their set, I get into the postmodernism speil with April, a poet herself, when a golden gem of an example presented itself.

Dead Prez’s set included a rap over the beat from The Notorious B.I.G.’s Juicy (video). But Dead Prez went beyond the simple example of intertextuality of borrowing another’s beat. They offered up their own version of one of the most famous verses in hip-hop, Biggie’s first verse in Juicy:

It was all a dream,
I used to read Word Up magazine;
Salt-n-Pepa and Heavy D up in the limousine.
Hangin’ pictures on my wall,
Every Saturday: Rap Attack, Mr. Magic, Marley Marl.
I let my tape rock ‘til my tape popped,
Smokin’ weed and bamboo, sippin’ on private stock;
Way back, when I had the red and black lumberjack,
With the hat to match.

Apparently released as “B.I.G. Respect” on their mixtape Turn off the Radio: The Mixtape Vol. 1, Dead Prez’s version isn’t just an unrelated rap over the same beat, but follows the same pattern of Biggies’.

It’s the story of their coming to age into their experience of hip-hop. It even follows the same general pattern.

It was all a dream!
Started organizing in my late teens,
Malcolm X and Huey P, who I wanna be.
Marcus Garvey on my wall.
I was just a young G, thought I’d been through it all.
Fuckin’ with po-po, used to stay “lock”.
Tryin’ to get my aim right, learning how to shoot a glock.
Way back, used to rock the army green fields jacket,
We was known for that.

This coming of age story has already been told. It’s part of the established hip-hop dictionary. Dead Prez just fits their own experience into the existing mold.

Just another example of the death of stylistic innovation common in postmodernism. As Jameson puts it:

We thus face an aesthetic dilemma: if the experience and the ideology of the unique self is over and done with, then it is no longer clear what artists and writers of the present age are supposed to be doing. It would seem that, in a world in which stylistic innovation is no longer possible, all they can imitate are dead styles.

However, hip-hop, I believe embraces this dilemma and lives within it. Art doesn’t need to be stylistically innovative.