sn.printf.net

MononcQc: Keep Your ORM Out of my Controller

Thu, 26 Aug 2010 03:25:00 +0000

Keep Your ORM Out of my Controller

One thing I've learned by working on a few legacy server applications is how a very small leak in an abstraction can be enough to make you lose weeks of work when tiptoeing around it to add or modify a feature, years later.

ORM usage as demonstrated in tutorials online (and therefore in many real life applications) frequently suffers from such leaks. This is a rant about it.

ORMs Are Middleware, Not an Abstraction

Object-Relational Mappers are all about abstracting away how you fetch data: they hide SQL, they hide implementation specific idiosyncrasiesm etc. That's a fine goal in itself, but the problem is how it is being used instead.

I frequently see them used straight in the controller to access data from the model layer. After all, most ORMs let you model your object transparently over the database table and often support all the CRUD idioms you might need. Adding more feels like abstraction for the sake of it and a loss of time.

As a perfect study case, let's take the following example from the 5th chapter of the Django Book. The following snippet is named The "Dumb" Way to Do Database Queries in Views (views are Django's equivalent to controllers):

def book_list(request):
     db = MySQLdb.connect(user='me', db='mydb', passwd='secret', host='localhost')
     cursor = db.cursor()
     cursor.execute('SELECT name FROM books ORDER BY name')
     names = [row[0] for row in cursor.fetchall()]
     db.close()
     return render_to_response('book_list.html', {'names': names})

Now, I agree this isn't the place to put SQL queries. The following solution is instead suggested:

 book_list(request):
    books = Book.objects.order_by('name')
    return render_to_response('book_list.html', {'books': books})

That's much better, really. The book_list controller now has a quick access to the objects it needs and is reduced to a much shorter two lines of code.

The problem I see with this is that the really important details are still there. I can still see "Give me a list of all books ordered by name." Okay, that doesn't sound too bad. That's because the query is very simple. Imagine that your boss comes in and asks you to have a block on a page that returns a list of all books having more than 150 pages, written by British authors who were born in the past century. Moreover, it should be possible to limit the books to a specific category (say, biographies) and it'd be nice to sort them by title.

Suddenly, the query isn't as simple anymore. You begrudgingly replace this and add the query to your controller. It now looks something like (pardon the pseudo-code ORM, no longer Django's):

Book.objects.filter('pages', larger_than=150).filter('author.nationality', 'British').filter('author.birthdate', larger_than=1900, smaller_than=2000).filter('category', 'Biography').order_by('name')

Oh. Well this is still nicer than the underlying SQL statement to be sure. No handling of joins, no handling of query building.

Now your boss has decided he wants this example search on 6 different pages (that require 6 different controllers). What do you do?

Copy/paste the query within all 6 controllers
Create a class with a method (or just a function) to handle it

Chances are the second solution is the best one. Not that we hate the ORM, but the query is pretty complex. What we really want might be something like "OldBritishBiographies()" and use that call in the 6 controllers instead. Now, why is it okay to use the ORM directly in the controller when the query is short, but we all cringe when it's long and ugly? Shouldn't we use only one way or the other?

I argue that all ORM calls should be wrapped in functions or methods. Otherwise, the programmer reading the code now has to understand something about 'author.birthdate', 'author.nationality' or yet 'name' (why not title?), etc. which are usually database column names.

This means that we're in the controller but we still have to grasp what the hell is going on in the database. The abstraction is leaking! We still need to know how the database works in order to fetch data from our models. That is because ORMs don't abstract away any applicative logic. All they abstract away is 'how you get the data', not 'what you are trying to get'. ORMs are middleware.

Any code base you have that will last a few years and scale up a bit will require a change in technology at some point. You want to move the book inventory to a web service, based on RESTful HTTP calls. Suddenly, none of the ORM calls above work without either tweaking the ORM a whole lot, or changing the calls to books in every controller that deals with them.

Except maybe that call about old British authors. It turns out this one only needs to be changed once, in its implementation. I suggest that this is because adding that descriptive function call completed the abstraction: you can get your results without caring about whatever the underlying implementation is. It could be done with or without an ORM, straight from text files, or even from a physical scanner with OCR. We just don't care, it needs to be implemented once and that's it.

The ORM is middleware between you and a database. A proper model is an abstraction between the data you get and whatever business logic is hidden behind it.

But wait, there's more!

To add to this all, keeping the ORM outside of the controller and inside the model as suggested above makes it infinitely much easier to do any kind of unit or integration testing.

It becomes easy to use whatever integration testing method you want to make sure your code fetches and stores data correctly from and to the database. It also becomes easy to build mock objects or functions to pass to the controller to test it independently from the model implementation.

Conversely, with ORM queries in the controller, verifying that everything goes fine is limited to testing the ORM itself or the controller and the underlying model at once. There is no easy way to test only one or the other without some copy/paste abuse because the ORM queries only exist as part of the controller.

So on one hand you have code that is easier to modify (because you need to change it at only one place) and to test. On the other hand you have code that is harder to maintain (because it is spread across controllers) and harder to test, just to add a kick to the nuts of the developer responsible of doing it.

Of course, using an ORM in the controller is still leagues better than what I'm having to maintain as described earlier. However, you should not assume your application won't live for more than a few years or that you do not need things such as 'being easier to test'. Please, for the sake of programmers doing maintenance on your code in the future, do your abstractions right. A small leak today is a flood tomorrow.

LOLLERZ: Kittyball go!

noreply@blogger.com (Blake Householder) — Thu, 19 Aug 2010 23:59:29 +0000

My game, Kittyball, just went live!

http://itunes.apple.com/us/app/kittyball/id384866969?mt=8

After several months of work, and all of Sarah's art contributions, it's nice to finally see it up for sale!

heeen: Day 6 - Big Basin Park

Thu, 19 Aug 2010 05:46:38 +0000

Es ist Samstag und es steht ein ganztägiger Ausflug an. Wir brechen zeitig auf um den Big Basin Park, bekannt für die gigantischen Redwoord Bäume bzw. Küstenmammutbäume zu besuchen. Der Weg dorthin schlängelt sich auf den letzten 10 Meilen durch Wälder und Berge, sehr malerisch und eine tolle Route zu fahren.

mehr Bilder...

Im Park wandern wir eine kürzere der zahlreichen Wanderrouten. Start- und Endpunkt der Kreisrouten ist dabei das Rangerhauptquartier, Holzhütten wie aus dem Pfadfinderbilderbuch. Die Bäume sind wirklich riesig und ihr Ausmass wird einem erst bewusst wenn man sich an den Stamm stellt und die Arme ausbreitet. Die Route führt an einem Wasserfall vorbei, der sich jedoch eher als Rinnsal herausstellt. Es soll auf weiteren Routen noch wesentlich größere Wasserfälle geben.

Wieder am Ranger Hauptquartier besuchen wir noch den Souvenierladen. Neben allerlei Kitsch, Nippes und T-Shirts gibt es auch Campingartikel. In der Mitte des Laden befindet sich eine Couch vor einem offenen Holzkamin - sehr gemütlich.

Bevor wir uns auf den Heimweg machen, beschließen wir einfach aufs geradewohl zur Pazifikküste zu fahren. Als es aus den Hügeln geht, halten wir am nächstbesten Parkplatz an und finden eine Bucht wie aus dem Reiseführer: Sandstrand und an Felsen brechende Wellen. Die Bucht ist zweigeteilt, vorne halten einige Familien Piknik während der hintere Teil nur von einer Hand voll nackter Männer beim Sonnenbad besiedelt ist. Das hat mich überrascht, hält man doch Amerika für das Land der Prüderie - doch darf man nicht vergessen daß wir im Dunstkreis von San Francisco befinden.

zootm: Simple JVM sandboxing

noreply@blogger.com (Calum) — Thu, 19 Aug 2010 06:33:31 +0000

I have written an dumb IRC bot which (among other things) can run scripts in arbitrary languages, provided they have Java implementations wrapped by the JSR-223 scripting API (a.k.a. javax.script in Java 6). At the moment I've got it doing Ruby, Groovy, Javascript and Scheme.

As part of this I decided that I needed to security restrict the script runner, since by design people will essentially be able to run arbitrary code in it. Java is so kind as to provide this sort of sandboxing functionality in its core framework (this is the same sort of security protection offered when you ran Java as an applet on a webpage years ago when applets were still cool), and although it's very well documented on a high-level online, I found it difficult to find a low-level explanation on exactly how to use the code to build a sandbox like I wanted, so here's how I ended up doing it.

It's worth noting that my IRC bot is actually written in Scala, so the actual Java code here (translated) is probably not well-tested. I've put the Scala wrapper I made at the foot of the entry in case it's useful to anyone.

First step – enable a SecurityManager

The first thing to realise (I certainly didn't) is that none of the security infrastructure in Java does anything until you enable it. By default the security policy checks are disabled (presumably for performance reasons); to enable them you need to attach an instance of SecurityManager to the system. You only need to do this once, and I'd recommend doing it as part of your app setup. It's really easy to do:

System.setSecurityManager(new SecurityManager());

The important thing to notice is that the current security policy — as defined by your .java.policy file in your home directory (I believe this is the same on Windows, incidentally), which will fall back to a very restrictive policy (the one used for applets) if the file doesn't exist. Now really I'd like any code that resides on my machine to run without sandboxing even when a security manager is in place (I like to live dangerously), so I can enter the following into my /home/calum/.java.policy file:

grant codeBase "file:/home/calum/-" {
  permission java.security.AllPermission;
};

The /- at the end matches all files below that directory recursively. One can also use /* to match all JAR and class files in a directory, / to match only class files, and specify individual files. For more information on policy files, check out this tasty document.

Important: Once you create this file, it overrides the default Java policy for anything you have a rule for. Do not just blanket grant permissions without a codeBase, you will be opening yourself to a world of hurt, in security terms.

Once you've restricted your JVM's permissions by adding a SecurityManager, then un-restricted them by granting the permissions back, you're ready to actually manipulate security on parts of code in your app.

Constructing an simple sandbox

Code can be invoked at modified privilege levels by the static AccessController.doPrivileged(PrivilegedAction,AccessControlContext) method. For this, we need to construct a PrivilegedAction<T> (essentially a Callable<T>) which encapsulates the logic to be run (if the logic throws an exception, you can use PrivilegedExceptionAction<T> instead). For our simple case we can fill this context with a single ProtectionDomain with a CodeSource (codesource can never be null) which is constructed will null values to indicate unsigned code from an unknown location, and a PermissionCollection consisting only of the permissions we'd like to grant our code (represented below as perms:

// Cast to Certificate[] required because of ambiguity:
ProtectionDomain domain = new ProtectionDomain( new CodeSource( null, (Certificate[]) null ), perms ); 
AccessControlContext context = new AccessControlContext( new ProtectionDomain[] { domain } );
T result = AccessController.doPrivileged(action, context);

Here's a full Java program which demonstrates the use of these methods (huge, I'm afraid — I've omitted the imports for brevity):

public class SandboxTest {
 private static final File file = new File( "/etc/motd" );
 
 public static void main(String[] args) throws Exception
 {
  // Do not forget this line!
  System.setSecurityManager( new SecurityManager() );
  
  System.out.println( "Calling method directly:" );
  
  System.out.println( readFirstFileLine(file).run() );
  
  System.out.println( "Calling method in restrictive sandbox:" );
  
  System.out.println( callInSandbox( new Permissions() ) );
  
  System.out.println( "Calling method with file read permission:" );
  
  Permissions perms = new Permissions();
  perms.add( new FilePermission( "/etc/motd", "read" ) );
  
  System.out.println( callInSandbox(perms) );
 }
 
 private static String callInSandbox( PermissionCollection perms )
 {
  ProtectionDomain domain = new ProtectionDomain( new CodeSource( null, (Certificate[]) null ), perms );
  AccessControlContext context = new AccessControlContext( new ProtectionDomain[] { domain } );
  try
  {
   return AccessController.doPrivileged( readFirstFileLine(file), context );
  }
  catch( Exception e )
  {
   return e.toString();
  }
 }
 
 private static PrivilegedExceptionAction<String> readFirstFileLine( final File file )
 {
  return new PrivilegedExceptionAction<String>() 
  {
   @Override
   public String run() throws Exception {
    BufferedReader reader = new BufferedReader( new FileReader( file ) );
    
    try
    {
     return reader.readLine();
    }
    finally
    {
     reader.close();
    }
   }
  };
 }
}

On my machine, this yields:

Calling method directly:
Linux thoth 2.6.24-19-generic #1 SMP Wed Jun 4 16:35:01 UTC 2008 i686
Calling method in restrictive sandbox:
java.security.AccessControlException: access denied (java.io.FilePermission /etc/motd read)
Calling method with file read permission:
Linux thoth 2.6.24-19-generic #1 SMP Wed Jun 4 16:35:01 UTC 2008 i686

Touch of Scala

Since I developed my app in Scala, here's a little object I built for simplifying this process. It works similarly to the callInSandbox method above, but also wraps Scala functions so you can use closures pretty simply:

import java.security._
import java.net.URL

object Security {
  private val codeSource = new CodeSource( null: URL, null: Array[cert.Certificate] )

  def sandboxed[T]( perms: PermissionCollection )( f: => T): T = {
    val domain = new ProtectionDomain( codeSource, perms )
    val context = new AccessControlContext( Array( domain ) )

    AccessController.doPrivileged( new Action( f ), context )
  }

  private class Action[T]( f: => T ) extends PrivilegedAction[T] {
    override def run() = f
  }
}

In order to use this, construct your Permissions that you want to grant to the item, import Security.sandboxed, and just wrap like this:

sandboxed( perms ) {
  println( "This code is running within the sandbox!" )
}

I hope this helps someone out!

zootm: Java gotcha o' the day

noreply@blogger.com (Calum) — Thu, 19 Aug 2010 06:31:04 +0000

Here's something in Java that I just couldn't predict what it was going to do:

try
{
    try
    {
        throw new RuntimeException("Lost?");
    }
    finally
    {
        throw new RuntimeException("Interloper");
    }   
}
catch (Exception e)
{
    System.out.println(e);
}

In hindsight I guess it's obvious that the exception thrown in the finally block would take precedence, but losing exceptions without having to explicitly deal with them seems quite the dangerous thing. It's just strange to say. That said, anyone throwing exceptions from a finally block should probably be strung up anyway.

zootm: Here's a feature I made earlier

noreply@blogger.com (Calum) — Thu, 19 Aug 2010 06:29:00 +0000

After being suitably wowed by Max Bolingbroke's implementing the Disposable pattern from C# in my current language-of-obsession Scala, I was looking at some of the other features of C#/.NET which are quite nice, and wondering how they could be implemented.

One set of stuff that is available in C# is the much-talked-about LINQ system, which lets you combine and query lists in a way fairly similar to SQL. They also do a bunch of clever things (like actually translating these queries into SQL, from what I can tell) but let's gloss over that for now.

In any case, there was a few of these operators don't exist in the Scala library, and since it's fairly easy to push new things onto objects in Scala, I decided to see how easily I could model them. For kicks.

Before I start proper I should mention two things:

I'm assuming programming knowledge, and probably some Scala experience here. That said, if you're used to this type of language you shouldn't have too much trouble reading the code examples, and hopefully you'll like the way the language works. If there's any questions, though, just comment. I don't imagine I'm a great writer.
There is probably better ways to do this stuff; I'm not hugely experienced with the language (I have at least thought of alternate ways to do some of the things). I'd be interested to hear any other approaches people have on this.

This is the first of two posts. In this one I'm going to set the stage, and do something simple. In the next one I'm going to continue down the same road, and so something a little more complicated.

"Adding" our own methods onto an existing class

UPDATE: This follow-up article shows a way of doing this that should make the code a bit more re-usable. The principle is pretty much the same, though.

This is just a bit of preparation for other things. Trust me when I say that we're going to want to put (or appear to put) extra methods onto objects with the Iterable trait. It's what all the cool kids are doing.

Following the naming scheme put forth by the Scala standard library, we can create a RichIterable class which will house the extra stuff we're going to be putting on the normal Iterable class, and make it a class which "wraps" an existing iterable object. With an implicit type conversion function which will wrap it up transparently, we can treat any Iterable as a RichIterable whereever the function is imported. This is done like so:

object RichIterable
{
  implicit def iterable2RichIterable[A]( iterable: Iterable[A]) = new RichIterable( iterable )
}

class RichIterable[A]( inner: Iterable[A] )
{ 
  // Extra functions go here...
}

Now all one needs to do is add the line import whatever.package.RichIterable._ and the power of these new methods will be theirs.

Pushing things into a map – `toMap`

This first one is the simplest of the methods I decided to implement; it is based on the ToDictionary method available in .NET. Basically the motivation is this:

I have a set of items with some distinguising property. I would like to put them into a Map object keyed on this property so I can look them, or maybe some property derived from them, up quickly.

Here's a more concrete example; we have our typical terrible-example-of-object-orientation class representing a car by its registration plate number and the name of its driver, which looks like so:

class Car( registration: String, driver: String )
{
  val getRegistration = registration
  val getDriver = driver
}

We have a big list of cars (a List[Car], if you will), but what we really want is a map from the registration plate number to the driver name, so we can do something like this:

val guiltyDriver = registrationMap( registrationOfCarSeenLeavingInAHurry )

We'd like to generate this map quickly and easily, and this is where the toMap function comes in; we want to be able to do something like:

val registrationMap = carList.toMap( _.getRegistration, _.getDriver )

This is fairly easy to achieve via a number of means, but I chose to build the inputs to the immutable Map's factory method. It takes any number of two-item tuples (doubles) and gives you a Map object back. So to construct those tuples from values in the list in this case we could do something like this:

a => ( a.getRegistration, a.getDriver )

Or more generally for a given function for the key, and one for the value:

a => ( keyFunc(a), valFunc(a) )

So to map an entire Iterable object (like our List) using these two functions, we could do this:

val tuples = inner.map( a => ( keyFunc(a), valFunc(a) ) ).toStream

The toStream at the end is just there because the fussy Map constructor wants a Seq. Presumably because it wants some guarantee that there's a finite number of elements. Wuss.

So to put this into a function we just need to take in the two functions, and push it out to the Map factory method:

def toMap[K,V]( keyFunc: (A) => (K), valFunc: (A) => (V) ): Map[K,V]  = {
  val tuples = inner.map( a => ( keyFunc(a), valFunc(a) ) ).toStream
    
  Map( tuples: _* )
}

This uses K for the type of the key, and V for the type of the value. The _* type parameter makes the Seq of tuples appear like a bunch of arguments, since this isn't automatic (this is similar to params in C# or the ... thing in Java).

This now works fine; so we can do something like this:

import RichIterable._
  
val cars = List(
    new Car( "SANTA1", "Santa Claus" ),
    new Car( "PANDA1", "P.C. Plod" ),
    new Car( "12345", "Count Count" ) )
      
val registrationMap = cars.toMap( _.getRegistration, _.getDriver )

println( registrationMap )
  
println( registrationMap("SANTA1") )

And we get the output:

Map(SANTA1 -> Santa Claus, PANDA1 -> P.C. Plod, 12345 -> Count Count)
Santa Claus

...which is of course ridiculous, since Santa rides in a sleigh rather than driving a car.

For convenience, we can also fulfil the situation where we just want to push our objects into a map keyed by the result of a function; that is, the same as the above, but the value should just be the input object. This is likely to be a fairly common use-case, so let's not make people type a lot to do it:

def toMap[K]( keyFunc: (A) => (K) ): Map[K, A] = toMap( keyFunc, a => a )

This is just calling the existing toMap function with a => a (the identity function, a fancy name for a function which does nothing at all) as valFunc.

In the next entry, I'm going to do something more substantial; an analogue to GROUP BY in SQL, which was the feature of LINQ I wanted the most. If you're too anxious to wait, this code is available here. It's a little untidy and uncommented at present, though (and doesn't currently contain a bunch of improvements I've since added).

zootm: Better classing through Scala

noreply@blogger.com (Calum) — Thu, 19 Aug 2010 06:23:12 +0000

Rather than the promised follow-up to my last post (it's coming, honest), I'm just going to update the way that I did the first section of that post. I realised earlier that rather than making my hastily-constructed RichIterable a class, I should have made it a trait. In this way, other classes can use its functionality explicitly if they know about it and, critically, can override the functionality in a way that makes more sense to them.

To do this and still be able to do the implicit cast thing I showed, we also need a concrete class to mix the trait in with. Since you can't (as far as I know) mix in traits after you've created an object, if we just create a wrapper class for Iterable objects:

class IterableWrapper[A]( underlying: Iterable[A] ) extends Iterable[A]
{
  override def elements = underlying.elements
}

Which means we can now express the implicit function from before as so, creating a new wrapper with our trait mixed in:

implicit def iterable2RichIterable[A]( iterable: Iterable[A]) = {
  new IterableWrapper( iterable ) with RichIterable[A]
}

This means that any other collection can just extend the RichIterable trait if they don't want to require the type conversion to use the new methods, or if they want to replace the functions with better implementations. Our actual RichIterable trait can be a subtrait of Iterable, too, meaning less indirection. It's wonderful I tells ya.

The extra curly brackets here do absolutely nothing; I just feel it's clearer to add them in if an expression like this one is too long to fit on a line.

zootm: Silly placeholder post

noreply@blogger.com (Calum) — Wed, 18 Aug 2010 17:48:43 +0000

I should update this blog more. Maybe just a little thing right now: I really like the option parsing library Trollop for Ruby. It's a great little system, and its values (or the ones important to me, at least) are that it is as easy as possible for the library consumer to use. I've been experimenting with making one with similar values for Scala, adding in the type safety and the like that you get with that language, while aiming to still keep a fluent interface.

Using it looks like this:

object Main extends OptionApplication {
 val options = new Options {
   banner = """
This is my test application.
There are many like it, but this one is mine.

Usage: Main [options]
"""
  
   val name = string( "Name to greet", default( "Nobody" ) )
   val alternativeGreeting = flag( "Use an alternative greeting" )
 }

 import options._

 def main() {
   val greeting = if( alternativeGreeting.value ) {
     "Bonjour, %s!"
   } else {
     "Hello, %s!"
   }
  
   println( greeting format name.value )
 }
}

Calling it from the "command line" (okay, I did it through Eclipse):

> Main --help
This is my test application.
There are many like it, but this one is mine.

Usage: Main [options]

Options:
-a, --alternative-greeting - Use an alternative greeting
               -h, --help - This help page
               -n, --name - Name to greet (default: Nobody)

> Main -n Calum --alternative-greeting
Bonjour, Calum!

> Main --pleasehelpme
Problem with options: unrecognised argument 'pleasehelpme'
Try --help for help.

Anyway, beyond just a random tour of that, why do I think this sort of thing is interesting? I like the idea that Scala works as a statically-type "scripting" language, as well as in the domains where Java works. I like the idea that command line tools and so on could be built with this easily. Java tends to only be used for huge big systems run inside containers and the like, because it's geared very much towards building the sort of huge system where this makes sense. Scala is fluid enough to give a lot of the advantages in fluidity you see from languages like Python and Ruby, and while it's a little more verbose, I think it's a useful alternative depending on your values.

What Scala is really missing, to me, is little "fun" libraries like you find in the form of Python Eggs and Ruby Gems. There's a lot of nice, impressive, projects but I'd like to see more in the realm of small projects that aren't necessarily a work of architectural genius, but are useful (or quirky) and encourage people to dabble and play. Java lacks a sense of fun and there's no reason that Scala should end up down that route. I might go into more detail with that feeling later; this is pretty poorly-drafted. Oh well!

LOLLERZ: New Project

noreply@blogger.com (Blake Householder) — Tue, 17 Aug 2010 01:05:34 +0000

I have started a project to create a site for developers and designers to share and collaborate on UI mockups and designs.

In the past, I have found it extremely frustrating to work on UI design with the current tools available. Trading zips of files through email and giant PDFs of mockup screens on shared storage are terrible ways to work.

It's hard to keep track of different versions.
It's hard to keep track of comments everyone has made.
It's hard for more than 2 people to be involved in the process.
It's hard to highlight changes.

I'm going to solve all of those problems.

LOLLERZ: Kittyball submitted!

noreply@blogger.com (Blake Householder) — Tue, 17 Aug 2010 01:04:28 +0000

I somehow forgot to mention this when I did it, but I submitted KittyBall to the App Store on Monday, August 9th. I guess we'll see what Apple thinks of it.

king_kllr: Education Slides

Mon, 16 Aug 2010 18:30:06 +0000

This past weekend I attended a symposium on authentic learning, in Santa Barbara, California. I gave a talk there about Open Source, and how we emulate the practices of a learning community (as often seen in colleges and universities) and whether the pedagogal practices we engange in (to help get new contributors started, and hopefully guide them to becoming committers) are applicable to other fields. Unfortunately the talk wasn't recorded, however my slides are available online, there is also an accompanying paper that will be available in the future.

MononcQc: Yet Another Article on Zippers

Fri, 13 Aug 2010 00:30:00 +0000

Yet Another Article on Zippers, in Erlang

What are zippers?

In Erlang (and in many other programming languages which include a functional subset), operations on purely functional data structures are frequently limited to O(log n) time complexity: there is no such thing as a true array with constant time access. No destructive updates. Nothing like pointers either.

Because of this, you end up with a bunch of modules like array, dict, gb_trees and whatnot, which are all built either on lists or trees with varying branching factors. None of them do better than O(log n), and list-based solutions don't do better than O(n) (although they can average n/2.)

There is, however, a class of data-structures that allow for amortized constant time for some operations: finger trees and zippers are examples of this.

So let's say you are writing a text editor and you need to hold a list of all the events typed in the currently open document. The naive implementation with standard data structures such as lists would force something a bit like [{TimeN, ChangeN}, {TimeN-1, ChangeN-1}, ..., {Time1, Change1}}]. That is, every time the user modifies the document, an entry of the form {Time, Change} is added to the beginning of the list.

What happens when the user wants to go back in history? A lot of programmers might just borrow the non-functional 'array and indexes' method: we keep a counter in memory (which acts like an index), and when the user presses some 'back' button, the index becomes N+1, N+2, etc. Conversely, when the user presses 'next', we remove 1 from that number:

1> lists:nth(1,[current,recent,old,older,oldest]).
current
2> lists:nth(2,[current,recent,old,older,oldest]).
recent
3> lists:nth(3,[current,recent,old,older,oldest]).
old
4> lists:nth(2,[current,recent,old,older,oldest]).
recent

This approach is directly based on how we're used to deal with arrays or dictionaries that support constant time access. Sadly, it's rather inefficient with functional data structures: the access time in the example above is O(n). If the document's history contains thousands of changes and the user loves to go through them, you end up doing a bunch of useless lookups, all the time. It's even worse if you allow the user to update the history and whatnot: not only do you need to traverse the list for lookups, but you need to rewrite a good part of the data structure every time you update it.

A valid alternative solution is to store everything we have traversed before in a secondary structure in order for the 'current' element to always be accessible in constant time. Instead of storing something like {3,[d,c,b,a]}, you'd store {[c,d],[b,a]}, or more generally: {Previous, [Current|Next]}, where Previous (the history of visited items) and Next (those left to go through) are both lists and Current is a single term. See the code below for an idea of how this works with more detail.

Not only does this approach make the current element accessible in constant time, but the previous and next one too! This lets you use the list a bit as a doubly-linked list in languages that support them, as in you can hold a 'pointer' to the current list location, and you can iterate backwards and forwards with little overhead. Moreover, changes to the list can be made in constant time (once you're at the right position) and the cost of modifying the elements is spent only when going backwards in the list.

Well that's a zipper. In this particular case, this would be a zipper with a list. Zipper is a generic term used to qualify a data structure that you can arbitrarily modify and navigate through.

I don't know if I'm being clear enough, but I nevertheless suggest the following articles if you want to get real information on zippers, rather than just my own little primer:

I especially recommend the last link (the part before type differentiation). It's the one I found the easiest to understand, although you need to be able to grasp Haskell's type system to understand it.

Zipper lists

So as described above, a list that we can go through in both directions [because we store seen elements] is a zipper, and can be implemented by holding a list/stack of all the elements we went through. Here's an implementation of zipper lists (abbreviated to zlists) according to the {Previous, [Current | Next]} structure:

-module(zlists).
-export([list_to_zlist/1, zlist_to_list/1,
         prev/1, next/1, current/1,
         replace/2, insert/2, delete/1,
         map/2, rmap/2]).

%% A zlist, or zipper list, allows to 'browse' a list
%% in two directions, much like a doubly-linked list.
%% Access to the next and previous element are both
%% constant time, and so is the cost of insertion and
%% deletion.
%% Lookups remain O(n).

%% {Previous, [Current | Next]}.
-type zlist() :: {list(), list()}.

%% Most zippers data structures wouldn't really need to convert between
%% types, but lists are kind of ubiquitous in usage, so it might be
%% proper to convert them.
%% Convert from standard list to zlist
-spec list_to_zlist(list()) -> zlist().
list_to_zlist(L) when is_list(L) -> {[], L}.

-spec zlist_to_list(zlist()) -> list().
zlist_to_list({Pre, Post}) -> lists:reverse(Pre) ++ Post.

%% Zipper lists can be moved inside in both direction, much like a
%% doubly-linked list in languages that support them. The functions
%% prev/1 and next/1 allow to move in such a manner. They crash whenever
%% you reach the end or the beginning of the zlist, exactly like the
%% functions erlang:hd/1 and erlang:tl/1 do.
-spec prev(zlist()) -> zlist().
prev({[H|T], Post}) -> {T, [H|Post]}.

-spec next(zlist()) -> zlist().
next({Pre, [H|T]}) -> {[H|Pre], T}.

%% current/1 allows to read the value of the list. fails on empty 
%% zlists, exactly the way erlang:hd/1 does. Also fails on lists where
%% the end has been reached.
-spec current(zlist()) -> term().
current({_, [Current|_]}) -> Current.

%% Replace changes the value of the current zlist item.
-spec replace(term(), zlist()) -> zlist().
replace(Val, {Pre, [_|Post]}) -> {Pre, [Val|Post]}.

-spec insert(term(), zlist()) -> zlist().
insert(Val, {Pre, Post}) -> {Pre, [Val|Post]}.

-spec delete(zlist()) -> zlist().
delete({Pre, [_|Post]}) -> {Pre, Post}.

%% Map and reverse maps as an example of potentially
%% useful functions
map(_, L = {_, []}) -> L;
map(F, {P, [H|T]}) -> map(F, {[F(H)|P], T}).

rmap(_, L = {[], _}) -> L;
rmap(F, {[H|T], N}) -> rmap(F, {T, [F(H)|N]}).

Not every useful function is implemented here. As an example, it could be nice to have an extract(zlist()) -> {term(), zlist()} function that removes the current value from the list while returning it, but I consider such functions to be shortcuts around the functions already presented here.

The zlists module could be used to implement the history feature mentioned in the first section of this post. You'd only need to use the prev/1, next/1, current/1 and insert/2 functions to do it.

Here's the link to the zlists module if you want it, and the unit tests module that goes with it. The unit tests are in a separate file because the error assertions would piss dialyzer off for the type checks.

Zipper Binary Trees

Zipper lists are conceptually simple enough to be easy to reinvent and replace with queues. More interesting are trees, because storing the history of how you go through them is a bit more complex.

Let's imagine a 'Book where you are the hero.' A simplified version of such a book could be represented as a decision tree where you can pick 'yes/no' to a question. Picking 'yes' goes to the right node, and picking 'no' goes to the left one. Each of these nodes then have more questions until you die or succeed. Going down such a decision tree is trivial. What's more interesting is when you need to go back one or more levels up in the tree to change your mind because you died and feel like cheating.

You could use a queue or zipper list to store all the choices you've made: {[yes, no, yes, yes, no, ..., yes], [yes]}. Going back one level would then be about traversing the queue and going down the tree following each decision except the last one in the zipper list. If you want to go up 4 levels, you need to go back 4 elements in the zlist, then down the tree. Again, this is not exactly optimal. By transforming a binary tree into a zipper, it becomes simpler to handle everything.

This is done by storing the past part of the tree (the previous node and the paths you didn't take) every time you go down a level. When going back up, just graft the child back onto the parent. Here's the initial tree:

And here's what the zipper could look like once choosing 'yes' once:

And then picking 'no':

As described above, when going back up a level, take the part on the 'current' side, and put it as the right child (because we went to the right) of the past tree. That will give you the original tree back.

To represent this in Erlang, we'll need a few constructs. First of all, a node of a tree (which would hold the questions and then the left and right branch) can be defined either as the atom undefined or as a tuple of the form {fork, Question, Left, Right}, where Left and Right are both nodes themselves.

The 'past' section will be called a thread and will be a stack of previously seen branches (or choices in the code below). A branch is simply a tuple containing the direction that was taken and the tree without the 'current' section. This will give a zipper of the form {Thread = [{Direction, Value, ParentNode}|_], CurrentNode}.

Here it is as implemented in the zbintrees module:

-module(zbintrees).
-export([root/1, get/1, put/2, right/1, left/1, top/1,
         set_left_branch/2, set_right_branch/2]).
-compile({no_auto_import,[get/1, put/2]}).

-type node(A) :: undefined
               | {fork, A, Left::node(A), Right::node(A)}.

-type choice(A) :: {left, A, node(A)}
                 | {right, A, node(A)}.

-type thread(A) :: [choice(A)].

-type zipper(A) :: {thread(A), node(A)}.

%% Creates a basic binary zipper tree. Should be called first when
%% declaring the data structure
-spec root(A) -> zipper(A).
root(A) -> {[], {fork, A, undefined, undefined}}.

%% Fetches the value of the current position
-spec get(zipper(Val)) -> Val.
get({_Thread, {fork, Val, _Left, _Right}}) -> Val.

%% Either replaces or create a new node (if it was 'undefined')
%% at the current position in the zipper binary tree. The
%% value of the node is the one in the second argument.
-spec put(A, zipper(A)) -> zipper(A).
put(Val, {Thread, undefined}) ->
    {Thread, {fork, Val, undefined, undefined}};
put(Val, {Thread, {fork, _OldVal, L, R}}) ->
    {Thread, {fork, Val, L, R}}.

%% Moves down the tree one level, picking the right child.
-spec right(zipper(A)) -> zipper(A).
right({Thread, {fork, Val, L, R}}) -> {[{right, Val, L}|Thread], R}.

%% Moves down the tree one level, picking the left child.
-spec left(zipper(A)) -> zipper(A).
left({Thread, {fork, Val, L, R}}) -> {[{left, Val, R}|Thread], L}.

%% Moves back up one level. When doing so, it reassembles the
%% Current and Past parts of the trees as a complete node.
-spec top(zipper(A)) -> zipper(A).
top({[{left, Val, R}|Thread], L}) ->  {Thread, {fork, Val, L, R}};
top({[{right, Val, L}|Thread], R}) -> {Thread, {fork, Val, L, R}}.

%% Shortcut function to add a left child
set_left_branch(A, Zipper) ->
    top(put(A, left(Zipper))).

%% Shortcut function to add a right child
set_right_branch(A, Zipper) ->
    top(put(A, right(Zipper))).

And you can also get the unit tests. An example usage of the tree could look a bit like what follows:

1> Tree = {[], {fork,
1>              "Open door?",
1>              {fork,
1>               "Enter hallway?",
1>               {fork, "you die alone.", undefined, undefined},
1>               {fork, "you die in a hallway", undefined, undefined}},
1>              {fork,
1>               "Eat the bacon?",
1>               {fork, "You die of hunger", undefined, undefined},
1>               {fork,
1>                "Eat more bacon?",
1>                {fork, "You die of hunger", undefined, undefined},
1>                {fork, "Hooray for bacon!", undefined, undefined}}}}}.
{[],
 {fork,"Open door?",
       {fork,"Enter hallway?",
             {fork,"you die alone.",undefined,undefined},
             {fork,"you die in a hallway",undefined,undefined}},
       {fork,"Eat the bacon?",
             {fork,"You die of hunger",undefined,undefined},
             {fork,"Eat more bacon?",
                   {fork,"You die of hunger",undefined,undefined},
                   {fork,"Hooray for bacon!",undefined,undefined}}}}}
2> zbintrees:get(Tree).
"Open door?"
3> zbintrees:get(zbintrees:right(Tree)).
"Eat the bacon?"
4> zbintrees:get(zbintrees:left(zbintrees:right(Tree))).
"You die of hunger"
5> zbintrees:get(zbintrees:top(zbintrees:left(zbintrees:right(Tree)))).
"Eat the bacon?"
6> zbintrees:get(zbintrees:right(zbintrees:top(zbintrees:left(zbintrees:right(Tree))))).
"Eat more bacon?"
7> zbintrees:get(zbintrees:right(zbintrees:right(zbintrees:top(zbintrees:left(zbintrees:right(Tree)))))).
"Hooray for bacon!"
8> "I won!".
"I won!"

I cheated the tree creation by doing it with the internal representation, but yeah. As the 'game' goes, you can see that I actually die ("You die of hunger"), then use the zbintrees:top/1 function to go back a level and keep going. A real world use would likely go through these steps in an imperative manner rather than just chaining the functions the way I do.

Zipper Forests

The zipper binary trees were fine for the simplified 'yes/no' decision tree, but the use cases are kind of limited. How many things can you think of where a binary tree going both up and down is really necessary? It's a bit more useful to have trees with as many nodes as you want. To build one, I'll use a structure similar to that is used in N-ary trees. N-ary trees usually have a maximum number of elements on each level, but for the purpose of simplicity I won't limit the number of elements.

A simple way to do things with N-ary trees is to hold each nodes of a level in a list. As such, one of our n-trees could look a bit like:

      [a,  b,   c,   d]
     /     |    |     \
[l,m,n]  [o] [p,q,r] [s,t,u,v,x]
                        |
                [1,2,3,4,5,6,7,8,9]

How to make this into a zipper? It's not just storing left or right and then rejoining the nodes like with zipper binary trees. Fortunately, we had zipper lists. By using them, we can simulate going from left to right and have an 'unlimited' number of nodes on each level. By nesting lists, we get the n-ary tree behavior we need.

The structure of the tree will go as follows. Each node has the form {Value, Children}. These nodes go into a zipper list to form a znode (I'm just coining terms/types for the hell of it). Each level of the tree is a znode. The tree as a whole has the form {Thread, Znode}. The following tree would be a valid zipper n-tree:

{[], % thread
 {[], [{a, {[], [{d, {[], []}},
                 {e, {[], []}}]}},
       {b, {[], [{f, {[], []}},
                 {g, {[], [{k, {[], []}}]}}]}},
       {c, {[], [{h, {[], []}},
                 {i, {[], []}},
                 {j, {[], []}}]}}]}}.

Or in a more visual manner:

    [a,  b,  c]
   /     |     \
[d,e]  [f,g]  [h,i,j]
           \
           [k]

I should already say that it's a bit of a misnomer to call them 'zipper n-trees' given I don't enforce the limit, but I'll stick to it for this post. I'll go as far as naming the module zntrees. The module supports basic operations: inserting, replacing, deleting values, creating an empty tree, moving to the left and right, and going to the current element's children or parent:

-module(zntrees).
-export([root/1, value/1,
         replace/2, insert/2, delete/1,
         left/1, right/1, children/1, parent/1, rparent/1]).

-type zlist(A) :: {Left::list(A), Right::list(A)}.
-type znode()  :: zlist({term(), zlist(_)}). % znode is a zlist of nodes
-type thread() :: [znode()].
-type zntree() :: {thread(), znode()}.

%% creates a tree with an empty thread and Val as the root.
-spec root(term()) -> zntree().
root(Val) -> {[], {[], [{Val, {[], []}}]}}.

%% Extracts the node's value from the current tree position.
-spec value(zntree()) -> term().
value({_Thread, {_Left, [{Val, _Children} | _Right]}}) -> Val.

%% Replaces the value from at the current tree position, without touching
%% the children nodes.
-spec replace(term(), zntree()) -> zntree().
replace(Val, {T, {L, [{_Val, Children}|R]}}) ->
    {T, {L, [{Val,Children}|R]}}.

%% Add a new node at the current position with the value Val.
-spec insert(term(), zntree()) -> zntree().
insert(Val, {Thread, {L, R}}) ->
    {Thread, {L, [{Val, {[], []}} | R]}}.

%% Deletes the node at the current position and its children.
%% The next one on the right becomes the current position.
-spec delete(zntree()) -> zntree().
delete({Thread, {L, [_|R]}}) ->
    {Thread, {L, R}}.

%% Moves to the left of the current level.
-spec left(zntree()) -> zntree().
left({Thread, {[H|T], R}}) ->
    {Thread, {T, [H|R]}}.

%% Moves to the right of the current level
-spec right(zntree()) -> zntree().
right({Thread, {L, [H|T]}}) ->
    {Thread, {[H|L], T}}.

%% Goes down one level to the children of the current node.
%% Note that in order for this to work, the {Val, Children} tuple
%% needs to be broken in two: the value goes in the Thread's zlist
%% while the Children become the current level.
-spec children(zntree()) -> zntree().
children({Thread, {L, [{Val, Children}|R]}}) ->
    {[{L,[Val|R]}|Thread], Children}.

%% Moves up to the direct parent level. Doesn't rewind the current
%% level's zlist. This means that if you have a tree, go to the
%% children, browse to the right 2-3 times, then go back up and
%% down to the children again, you'll be at the same position you were
%% before.
%% If you prefer the children to be 'rewinded', use rparent/1.
-spec parent(zntree()) -> zntree().
parent({[{L, [Val|R]}|Thread], Children}) ->
    {Thread, {L, [{Val, Children}|R]}}.

%% Moves up to the direct parent level, much like parent/1. However,
%% it rewinds the current level's zlist before doing so. This allows
%% the programmer to access children as if it were the first time,
%% all the time.
-spec rparent(zntree()) -> zntree().
rparent({[{ParentL, [Val|ParentR]}|Thread], {L, R}}) ->
    {Thread, {ParentL, [{Val, {[], lists:reverse(L)++R}}|ParentR]}}.

And now you can declare trees with any number of nodes. See the unit tests if you want.

The use cases for such trees are more abundant: undo trees, XML navigating with DOM, representing more complex 'choose your own adventure' books (or decision trees), directories in a filesystem, etc.

Here we'll try a DOM tree example with the following fake document:

<html>
    <header>
        <title>Hello, World!</title>
    </header>
    <body>
        <h1>Hello, World!</h1>
        <p>How are you, planet?</p>
        <ul>
            <li>Bat</li>
            <li>Man</li>
            <li>Na Na Na Na</li>
        </ul>
    </body>
</html>

You could build the tree as a zntree by using the functions root/1, children/1, insert/2, right/1 and parent/1, but this would be a little too verbose, so I'll declare it in it's final form:

1> Document = 
1> {[],
1>  {[],
1>   [{html,
1>     {[],
1>      [{header,
1>        {[],
1>         [{title, {[],[{"Hello, World!",{[],[]}}]}}]}},
1>       {body,
1>        {[],
1>         [{h1,{[], [{"Hello, World!", {[],[]}}]}},
1>          {p, {[], [{"How are you, planet?", {[],[]}}]}},
1>          {ul,
1>           {[],
1>            [{li, {[],[{"Bat", {[],[]}}]}},
1>             {li, {[],[{"Man", {[],[]}}]}},
1>             {li, {[],[{"Na Na Na Na", {[],[]}}]}}]}}]}}]}}]}}.
{[],
 {[],
  [{html,{[],
          [{header,{[],[{title,{[],[{"Hello, World!",{[],[]}}]}}]}},
           {body,{[],
                  [{h1,{[],[{"Hello, World!",{[],[]}}]}},
                   {p,{[],[{"How are you, planet?",{[],[]}}]}},
                   {ul,{[],
                        [{li,{[],[{[...],...}]}},
                         {li,{[],[{...}]}},
                         {li,{[],[...]}}]}}]}}]}}]}}

Ugly, but yeah. We can now play and navigate around the tree. The functions left/1 and right/1 can be used to access the current element's siblings while parent/1 and children/1 can be used to go up and down the hierarchy:

2> zntrees:value(zntrees:children(Document)).
header
3> zntrees:value(zntrees:right(zntrees:children(Document))).
body
4> Body = zntrees:right(zntrees:children(Document)).
<huge structure>
5> zntrees:value(zntrees:right(zntrees:right(zntrees:children(Body)))).
ul
6> List = zntrees:right(zntrees:right(zntrees:children(Body))).
<huge structure>
7> zntrees:value(zntrees:children(zntrees:left(zntrees:rparent(zntrees:right(zntrees:children(List)))))).
"How are you, planet?"

That last one is a bit exaggerated, I agree. Anyway, this zipper makes it possible to change a node's value in constant time. In the following example, I'll go to the first element of the list and replace "Bat" by "Platypus". The log n modifications needed to rewrite the data structure in normal trees are now amortized over the calls to parent/1, if you ever actually need to call it (if you don't, you never really have to pay that rewrite cost):

8> NewDocument = zntrees:replace("Platypus", zntrees:children(zntrees:children(List))).
<huge structure>
9> zntrees:parent(zntrees:parent(zntrees:parent(zntrees:parent(NewDocument)))).
{[],
 {[],
  [{html,{[{header,{[],
                    [{title,{[],[{"Hello, World!",{[],[]}}]}}]}}],
          [{body,{[{p,{[],[{"How are you, planet?",{[],[]}}]}},
                   {h1,{[],[{"Hello, World!",{[],[]}}]}}],
                  [{ul,{[],
                        [{li,{[],[{"Platypus",{[],[]}}]}},
                         {li,{[],[{"Man",{[],...}}]}},
                         {li,{[],[{"Na Na Na Na",{...}}]}}]}}]}}]}}]}}

DOM navigation is only one of the possible uses of zipper trees. As I mentioned earlier, undo trees or decision trees are also possible. In fact, this kind of zipper can be used to represent any undirected acyclic graph or forest: this means (I believe) that many graph-based problems where no cycle exist can be represented and navigated with the above zipper, including concepts such as minimum spanning trees. This could be useful, if anyone ever needed to do that kind of stuff in Erlang I guess. Which brings me to my next point...

Alternatives to Zippers

Zippers can be pretty useful when you need a specific way to quickly update a datastructure as shown above. Depending on the use case, using adjacency lists (or something close to that) with dicts, gb_trees or ETS tables can prove to be practical: those would in fact allow shared access and modifications to the data structures, something that sounds conceptually harder to do with zippers.

Anyway, I hope this was an educative/entertaining/distracting or anything not negative read.

heeen: Day 5 - Santana Row

Thu, 12 Aug 2010 06:24:56 +0000

Wir besuchen einen weiteren Mall, genannt Santana Row Plaza. Ähnlich wie der erste ist er offen gebaut. Parken ist umsonst, man will die Leute ja entspannt Geld ausgeben lassen. Das ist mir auf jeden Fall lieber als dauernd auf die Uhr schauen zu müssen. Der Mall ist größer und in mehrere Blöcke aufgeteilt. Es gibt vom Optiker über Tierboutique bis zum Laden ausschließlich für Behältnisse ("The Container Store") alles.

Zwischen den Geschäften gibt es verschiedenste Lokale. Es ist üblich nach dem Einkaufen in eines der Restaurants oder Bars einzukehren. Ich kaufe ein paar Bücher und Mitbringsel und danach kehren wir in einem Irish Pub ein. Dort gibt es gute Küche aber ich begnüge mich mit einem Iced Tea. Der wird in Restaurants übrigens ungesüßt serviert.

heeen: Day 4 - Tierhandel

Tue, 10 Aug 2010 07:31:26 +0000

Heute gehen wir in ein Italienisches Restaurant zu Mittag, wo ich mir eine Pizza genehmige. Auf dem Heimweg besuchen wir einige Handelsketten: Best Buy - dr Amerikanische Mediamarkt, sowie REI, einen Laden für alles was man unter freiem Himmel und beim Camping brauchen kann. Was das Camping angeht macht den Amerikanern niemand was vor, es gibt wirklich alles von Wasserdichten Schalen für Elektronik bis Kaffekonzentrat in Tüten: einfach in eine Tasse Wasser giessen, schon hat man überall einen Wachmacher.

Neben REI fanden wir noch einen Tierwarenladen. Hier konnte man neben allem was man auch bei uns im Freßnapf findet auch Tiere erwerben bzw. adoptieren. Unter anderem wurden Fische in kleinen Plastikbechern angeboten.

Wie diese Fische gefüttert und mit Sauerstoff versorgt werden konnte ich nicht ausmachen - einige bewegten sich ejdenfalls nicht mehr.

Ebenfalls in dem Laden befand sich eine Katzenadoptionsstation. Katzen die Augenscheinlich von den Tierfängern aufgesammelt wurden und kastriert und untersucht wurden, werden da hinter Schaufenstern zur Adoption feilgeboten. Was zunächst sehr deprimierend wirkt, ist wie ich finde jedoch eine Gute Sache™: Scheut man bei uns den Besuch im Tierheim doch eher oder geht dort nur selten absichtlich hin, werden hier die Tiere wesentlich näher an den Lebensmittelpunkt der Menschen gebracht. Ich konnte einen Kunden beobachten der augenscheinlich ein Bild einer Katze machte und an jemanden weiterschickte.

heeen: Day 2 - Erster Mall-Besuch

Tue, 10 Aug 2010 07:09:19 +0000

Heute gibt es Mittags kostenlose Sandwiches von Subway, mit Senf und Mayo zum selbst dazustreichen. nach der Arbeit treten wir zum ersten Mall den weg zu einem Mall, also einem Einkaufszentrum an. Viele überdachte Einkaufszentren, wie man sie in Deutschland importiert hat, sind ausgestorben und rotten vor sich hin. Neue Einkaufszentren ähneln den Einkaufsstrassen europäischer Innenstädte: statt eines großen Gebäudes gibt es mehrere Blöcke in denen sich verschiedene Ketten und Läden befinden. Die Wege zwischen den Blöcken haben Bänke und Brunnen und sind mit Pflanzen bewachsenen Pergolas überdacht.

Im Stanford Mall gehen wir zuvor in Bubbles Diner, einem Amerikanischen Imbiss wie man ihn aus dem Film kennt, essen. Für mich gibt es ein roast beef sandwich und anschliessend cheesecake.

Noch konnte ich dem Kommerz widerstehen und habe nichts gekauft.

Wieder am Hotel angekommen wartet endlich mein Koffer auf mich und damit auch meine Badehose. Jetzt kann ich endlich den heißen Whirlpool und das Becken genießen.

Janin: Release: dbus-core 0.8.4

Mon, 09 Aug 2010 00:43:26 +0000

stromdotcom: mentalBlock for iPad

Sun, 08 Aug 2010 08:30:22 +0000

mentalBlock for iPad is now available in the app store.

stromdotcom: Windows Phone 7 Anticipation

Sun, 08 Aug 2010 08:30:22 +0000

I am definitely looking forward to developing for Windows Phone 7. After the absolute humiliation that comes with developing for the iPhone (or, more to the point, passing through Apple's brain dead review process), I almost gave up on mobile development. That's a shame, because it isn't hard to see that ...

stromdotcom: Why I’m Developing for iPad

Sun, 08 Aug 2010 08:30:22 +0000

I have been pretty vocal in the past about my issues with the app store, Apple, Apple's development tools, the app market, and so on. Leading up to the release of the iPad, I goofed on it with everyone else, and scoffed at the idea of developing anything for it. ...

king_kllr: PyOhio Slides

Sun, 08 Aug 2010 08:30:09 +0000

I've (finally) uploaded the slides from my PyOhio talk (I gave a similar talk at ChiPy). You can get them right here, I'll be putting all my slides on Scribd from here on out, they were much easier to upload to than SlideShare, plus HTML5 is awesome!

king_kllr: Testing Utilities in Django

Sun, 08 Aug 2010 08:30:09 +0000

Lately I've had the opportunity to do some test-driven development with Django, which a) is awesome, I love testing, and b) means I've been working up a box full of testing utilities, and I figured I'd share them.

Convenient `get()` and `post()` methods

If you've done testing of views with Django you probably have some tests that look like:

def test_my_view(self):
    response = self.client.get(reverse("my_url", kwargs={"pk": 1}))

    response = self.client.post(reverse("my_url", kwargs={"pk": 1}), {
        "key": "value",
    })

This was a tad too verbose for my tastes so I wrote:

def get(self, url_name, *args, **kwargs):
    return self.client.get(reverse(url_name, args=args, kwargs=kwargs))

def post(self, url_name, *args, **kwargs):
    data = kwargs.pop("data", None)
    return self.client.post(reverse(url_name, args=args, kwargs=kwargs), data)

Which are used:

def test_my_view(self):
    response = self.get("my_url", pk=1)

    response = self.post("my_url", pk=1, data={
        "key": "value",
    })

Much nicer.

`login()` wrapper

The next big issue I had was logging in and out of multiple users was too verbose. I often want to switch between users, either to check different permissions or to test some inter-user workflow. That was solved with a simple context manager:

class login(object):
    def __init__(self, testcase, user, password):
        self.testcase = testcase
        success = testcase.client.login(username=user, password=password)
        self.testcase.assertTrue(
            success,
            "login with username=%r, password=%r failed" % (user, password)
        )

    def __enter__(self):
        pass

    def __exit__(self, *args):
        self.testcase.client.logout()

def login(self, user, password):
    return login(self, user, password)

This is used:

def test_my_view(self):
    with self.login("username", "password"):
        response = self.get("my_url", pk=1)

Again, a lot better.

django-fixture-generator

Not quite a testing utility, but my app django-fixture-generator has made testing a lot easier for me. Fixtures are useful in getting data to work wit, but maintaining them is often a pain, you've got random scripts to generate them, or you just checkin some JSON to your repository with no way to regenerate it sanely (say if you add a new field to your model). django-fixture-generator gives you a clean way to manage the code for generating fixtures.

In general I've found context managers are a pretty awesome tool for writing clean, readable, succinct tests. I'm sure I'll have more utilities as I write more tests, hopefully someone finds these useful.

king_kllr: MultiMethods for Python

Sun, 08 Aug 2010 08:30:09 +0000

Every once and a while the topic of multimethods (also known as generic dispatch) comes up in the Python world (see here, and here, here too, and finally here, and probably others). For those of you who aren't familiar with the concept, the idea is that you declare a bunch of functions with the same name, but that take different arguments and the language routes your calls to that function to the correct implementation, based on what types you're calling it with. For example here's a C++ example:

#include <iostream>

void special(int k) {
    std::cout << "I AM THE ALLMIGHTY INTEGER " << k << std::endl;
}

void special(std::string k) {
    std::cout << "I AM THE ALLMIGHTY STRING " << k << std::endl;
}

int main() {
    special(42);
    special("magic");
    return 0;
}

As you can probably guess this will print out:

I AM THE ALLMIGHTY INTEGER 3
I AM THE ALLMIGHTY STRING magic

You, the insightful reader, are no doubt fuming in your seats now, "Alex, you idiot, Python functions don't have type signatures, how can we route our calls based on something that does not exist!", and right you are. However, don't tell me you've never written a function that looks like:

def my_magic_function(o):
    if isinstance(o, basestring):
        return my_magic_function(int(o))
    elif isinstance(o, (int, long)):
        return cache[o]
    else:
        return o

Or something like that, the point is you have one function that has a couple of different behaviors based on the type of it's parameter. Perhaps it'd be nice to separate each of those behaviors into their own function (or not, I don't really care what you do).

I was saying that a bunch of people have already implemented these, why am I? Mostly for fun (that's still a valid reason, right?), but also because a bunch of the implementations make me sad. Some of them use crazy hacks (reading up through stack frames), a few of them have global registrys, and all of them rely on the name of the function to identify a single "function" to be overloaded. However, they also all have one good thing in common: decorators, yay!

My implementation is pretty simple, so I'll present it, and it's test suite without explanation:

class MultiMethod(object):
    def __init__(self):
        self._implementations = {}

    def _get_predicate(self, o):
        if isinstance(o, type):
            return lambda x: isinstance(x, o)
        assert callable(o)
        return o

    def register(self, *args, **kwargs):
        def inner(f):
            key = (
                args,
                tuple(kwargs.items()),
            )
            if key in self._implementations:
                raise TypeError("Duplicate registration for %r" % key)
            self._implementations[key] = f
            return self
        return inner

    def __call__(self, *args, **kwargs):
        for spec, func in self._implementations.iteritems():
            arg_spec, kwarg_spec = spec
            kwarg_spec = dict(kwarg_spec)
            if len(args) != len(arg_spec) or set(kwargs) != set(kwarg_spec):
                continue
            if (all(self._get_predicate(spec)(arg) for spec, arg in zip(arg_spec, args)) and
                all(self._get_predicate(spec)(kwargs[k]) for k, spec in kwarg_spec.iteritems())):
                return func(*args, **kwargs)
        raise TypeError("No implementation with a spec matching: %r, %r" % (
            args, kwargs))

And the tests:

import unittest2 as unittest

from multimethod import MultiMethod


class MultiMethodTestCase(unittest.TestCase):
    def test_basic(self):
        items = MultiMethod()

        @items.register(list)
        def items(l):
            return l

        @items.register(dict)
        def items(d):
            return d.items()

        self.assertEqual(items([1, 2, 3]), [1, 2, 3])
        # TODO: dict ordering dependent, 1 item dict?
        self.assertEqual(items({"a": 1, "b": 2}), [("a", 1), ("b", 2)])

        with self.assertRaises(TypeError):
            items(xrange(3))

    def test_duplicate(self):
        m = MultiMethod()

        @m.register(list)
        def m(o):
            return o

        with self.assertRaises(TypeError):
            @m.register(list)
            def m(o):
                return o


if __name__ == "__main__":
    unittest.main()

Bon appétit.

heeen: Day 1 - Weird Stuff

Sat, 07 Aug 2010 08:36:37 +0000

Montag - der erste Tag. Unsere Arbeitsplätze sind offene Tische im Erdgeschoss des Gebäude. Wir sitzen mit den Finnen an einer Reihe Schreibtische an der jeder sich einen Plaz suchen und seinen Laptop anstöpseln kann. Es gibt eine Cafeteria im Gebäude, die zwar nicht im regulären Betrieb ist, wo es jedoch Mittags kostenlose Snacks gibt. Heute gibt es Bagels mit verschiedenen Brotaufstrichen zum selbstbestreichen.

In der Mittagspause fahren wir mit unseren Finnischen Kollegen zu Weird Stuff - Merkwürdiges Zeug, einem Laden/Lagerhalle voller gebrauchter Computer und Elektronikteile. Ein finnischer Kollege hatte dort vorher schon einen alten Apple gekauft um ihn nach Finnland zu importieren - inklusive Gehäuse und Monitor.

Ich finde jedoch nichts was ich unbedingt haben müsste.

Im Umkreis des Ladens findet man viele bekannte Internet-Namen: wir sind an Gebäuden von Yahoo, Symantec und Verisign vorbeigefahren.

Anschliessend essen wir bei Specialtys einer Bäckerei/Sandwich/Frühstücks/Mittagskette. Dort gibt es Salate und Sandwichs aller Art, sowie Cookies und andere Gebäcke. Man bestellt das Essen an einem Computer im Eingangsbereich und erhält ähnlich wie bei Vapiano einen Piepser der einem sagt wann die Bestellung fertig ist. Das Essen ist hochwertig und selbst hergestellt. Ich hole mir ein warmes BBQ Sandwich und einen kleinen Salat, eigentlich hätte mir aber das Sandwich gereicht.

In Amerika trifft man in jeder besseren Gastronomiekette oder Restaurant auf Organic, also Bio-Produkte, es wird häufig auf Hormonfreies Fleisch und Gemüse von Örtlichen Farmern hingewiesen. Auch das Brot wird in jedem Laden der etwas auf sich hält im Haus gebacken. Auch auf Umweltfreundliche Verpackungen wird sich bemüht, im Bild sind die Teller und Servietten aus Recyclingmaterial. Überall kann man mit Kreditkarte bezahlen.

heeen: Day 0 - Anreise

Wed, 04 Aug 2010 07:11:22 +0000

Ich versuche hier mal das nichtgeschäftliche meiner Mountain View Reise zu sammeln.

Es ist schon spät und ich bin müde deshalb nur Tag 0 heute.

Wir sind sehr früh aufgestanden - etwa halb fünf wenn ich mich richtig erinnere. Ich habe nur eine oder zwei Stunden geschlafen wenns hochkommt, war aber relativ fit.

Eingecheckt habe ich online, was mir ausser der Sitzplatzwahl für Amsterdam-San Francisco aber nichts gebracht hat - Gepäck musste ich trotzdem ja noch aufgeben. An der Security wurde die Kamera mit einem Schnelltest auf irgendwelche Substanzen untersucht.

Der Flug nach Amsterdam verlief ganz normal, zu essen gab es eine Art Rosinenbrot Sandwich belegt mit Schinken und Käse.

Angekommen in Amsterdam, hatte ich etwa 90 Minuten Aufenthalt. Bin durch die Flughafenläden flaniert, aber nichts hat mich zum kauf bewegt. Dann nochmal durch die Passkontrolle und dann nochmal an der Security abgetastet. Mit einer Stunde Verspätung dann nach SFO gestartet. Ich habe mir einen Platz am Gang ausgewählt, was den Vorteil hat, leichter mal aufstehen und sich die Beine vertreten zu können. Aus dem Fenster sieht man ja eh die meiste Zeit nur Wolken. Die junge Dame neben mir hat während des ganzen Fluges hauptsächlich Rotwein genossen - insgesamt 5 Flaschen in Flugzeuggröße, also über einen Liter. Es scheint ihr aber gut bekommen zu haben. Im Flugzeug die Zeit mit Film und Serien verbracht und etwa eine halbe oder ganze Stunde geschlafen.

Ankunft San Francisco International. An der Einlasskontrolle über eine Stunde, eher 1:30 Stunden angestanden. Alle Fingerabdrücke ein Bild und ein Zollformular abgegeben und zwei Sätze zum Aufenthalt erzählt, dann zum Gepäckband. Mein Koffer nirgends zu finden. Später wird mein Name ausgerufen und es wird mir gesagt, mein Koffer sei noch in Amsterdam. Also die Hotel Adresse angegeben und ohne Koffer weiter. Die Zollkontrolle winkt mich dann nur noch durch. Mit dem Air Train (Bild oben) zum Autoverleih gefahren wo mein Kollege Steffen die ganze Zeit auf mich wartet. Wir mieten einen weißen Chevrolet, Automatik ist in den Staten Standard. Ich muss mich sehr konzentrieren nicht mit dem Bremspedal Kuppeln und mit dem Automatik-hebel Schalten zu wollen, was zu abrupten Bremsmanövern und Auffahrunfällen führen könnte.

Angekommen am Hotel bin ich noch erstaunlich Fit. Die Kollegen sitzen am Pool, doch meine Badehose liegt im Koffer in Amsterdam. Ich gehe in den Supermarkt ein paar Notwendigkeiten einkaufen (Sonntags!) und später flanieren wir durch die Stadt auf der Suche nach einem Abendessen (Steak New York für mich)..

LOLLERZ: The Modern Liberal Goal Part 2: Work as a game

noreply@blogger.com (Blake Householder) — Tue, 03 Aug 2010 02:18:11 +0000

So the question is:

If the liberal goal [everyone only has to work as much as they want to] is achieved, what is there to do for someone seeking to become wealthy? What can we do with an army of people who don't ever have to work for a living?

Now we've got two types of people in the world: those producing less than they consume, and those producing more.

The government subsidizes people who are overconsuming, so they never have to work if they don't want to.

So what's a future capitalist to do?

We have to make them want to work.

We can do this in two ways: make work fun, or make work easy.

How do we make work fun?
Make it into a game! People will put enormous effort into games voluntarily.

We've already got some great business models for this:

Work hard for free!
Open source software and Wikipedia use this model.
"Hey, give us tons of skilled labor and get no money in return!"
"ok!"

Work hard for social benefits!
Facebook, Twitter, LinkedIn, MySpace, and every social networking site ever.
"Hey, give us tons of information to help target ads!"
"ok!"

Work hard to create value for paying users!
Zynga, Chinese MMOs (see slide 16 of this excellent presentation). We can make a free-to-play gameworld where our non-paying users add value for our paying users to take advantage of.
"Pay for our game, you can kill noobs!"
noobs: "noooo *adds value*"

How do we make work easy?
Bring it to them! Who minds working from home? Idiots, that's who. All the cool people want to work from home.

What have we got?

Use the massively parallel processor in your head to solve problems!
Amazon's Mechanical Turk lets you solve a single tiny task and get a single tiny amount of money.
"Transcribe this for a quarter!"
"ok!"

Write an essay for $10!
Demand Studios will pay you to write essays for them, which they then spam all over the internet and place ads on. It solves two problems: how do we fill the internet with more crap, and how do we get people to write more crap?
"Write some crap!"
"awesome!"

Make some media and we'll sell it and give you a cut!
Infinite stock photography sites do this, as well as the Envato network for sounds, music, graphics, and other media.
"Make a song, we'll give you a few dollars per download!"
"groovy!"

Ok, that's enough examples!
Yay! I hope you're convinced that our brave new world of consumers is not necessarily a bleak dystopia. Sure, the government will take a ton of our money, and redistribute it to the less worthy, but that doesn't mean we can't still extract some value from them!

LOLLERZ: Amazon!

noreply@blogger.com (Blake Householder) — Tue, 03 Aug 2010 01:17:58 +0000

Today I started at Amazon.

Amazon is strangely a software company that sells retail products. I'm not sure how that happened, but I assume Jeff Bezos is to thank for it.

Thanks, Jeff Bezos.

So now I am officially a Software Design Engineer - Gift Cards User Experience. If you have any questions about being an SDEGCUE, feel free to ask me.

LOLLERZ: The Modern Liberal Goal

noreply@blogger.com (Blake Householder) — Sun, 01 Aug 2010 21:42:57 +0000

A while ago, I tried to answer a simple question as a thought experiment: “what is the goal of the ‘modern liberal’ philosophy?”

I believe the answer is “everyone only has to work as much as they want to”.

Why do I believe that?

In the United States, we have had a history of creating social welfare programs, and they tend to stick around. Welfare, Medicaid, WIC (the modern food stamps), unemployment, and disability are generally targeted at the poor and disadvantaged. Medicare and Social Security are targeted at the old, who often become poor as a combination of reduced earning ability and increasing health costs. Unemployment, in particular, simply gives money to people who aren't earning any. It's stated purpose is to help people "get back on their feet", but for practical purposes, it can be collected for a year (at least in Texas) without having to do anything in particular.

These welfare programs spring out of a philosophy of "need". I think there's a certain level of guilt that comes from rightfully earning the things we need, and continuing onward to earn things we want, while other people fail to even meet their own basic needs. Governments then codify this guilt into programs to take money from those who've earned it and give it, in varying forms, to those who haven't.

In a republic, these programs have a fair amount of stickiness due to taking money from a few voters and giving it to many voters.

Why do I think it is likely to happen?

Technology has given the most intelligent a massive lever with which to move the world and create value. A rich person today wields more power than nations of the past. Thanks to these forces, there is more marginal wealth per person at the top. Bill Gates easily met his own needs many years and many dollars ago. If we take 99% of his money, we can provide for probably tens or even hundreds of thousands of people. I think there is social pressure to do this.

Along with amplifying the top tier's ability to create wealth, technology also lowers the bar for the poor to meet their basic needs. Food is cheap compared to any time in human history. It becomes easier and easier for one person to meet their own needs.

Marshall Brain's Manna provides in interesting guess as to two alternative futures, one ruled by the tyranny of the rich, who provide for the poor, but restrict their freedom to virtually nothing, and a more communist society where everyone is "rich" by pooling resources.

If the liberal goal is achieved, what is there to do for someone seeking to become wealthy? What can we do with an army of people who don't ever have to work for a living?

I'll tell you tomorrow.

m0nk3yz: Miscellanea – Python Sprints, Nasuni, etc.

Fri, 30 Jul 2010 17:34:19 +0000

I’ve obviously been quiet here on my personal blog – as everyone who reads regularly knows I’m neck-deep in a pretty exciting startup call Nasuni as well as doing other projects, like the PSF Sponsored sprints thing. That combined with twitter means my time for other additional long-form content is minimal. So here’s a small roundup of interesting things:

Nasuni

Yup, still running Python and Django! We’re actually pretty proud to be a sponsor for DjangoCon 2010 coming up in September – I’ll be attending, so I hope to see all the familiar Django faces I know, and meet some new ones.

I’ve been blogging semi-regularly for the Nasuni blog itself – my posts are focused on product-things more than anything else. Here’s a small list of posts which I’ve done:

The Road to Release – Feature Previews – this is actually my latest one, and the first in a series where I’ll be showing off some of the new features we’re adding in the latest release.
Looking at OpenStack, a Rackspace and NASA initiative – For those of you who don’t know, Rackspace and NASA announced OpenStack – the awesome part? It’s all python – I had the swift component (which powers Rackspace’s cloudfiles system) of OpenStack running pretty quickly. I’d recommend snagging the code from launchpad and taking a look. Swift (the storage component) uses eventlet – and Nova (the compute part) uses Tornado and Twisted.
Storage Switzerland Test Drives the Filer – This is a response to an article written about the product – I actually used it to preview some of the work going into the next release of the Filer.
Thanks to Django – This piece goes into some detail about our use of Django, it’s one of our ways of saying thanks. I still need to rework it so we can send it over for the Django Success Stories page.
Thanks to the Supporting Cast – This is an earlier thank you post – but to the other people who have helped out a ton, including Greg Newman, Lincoln Loop, and Revsys.
The Donut Solution – This was a fun one, mainly to show that yes – we’re listening hard to customer feedback, and we’re improving/iterating quickly. Also, I get to show off UI improvements.
Finally – The Nasuni Blog team – this is the rosetta stone for the authors of the blog, describing who we are. I didn’t write this piece, but it’s good reading to figure out who is who.

If you’re interested in Nasuni – or cloud storage in general – I’d encourage you to sign up for the RSS feed. We’re trying to keep the information useful outside of “just us” (despite my urge and predilection to churning out completely product-related posts) – and if you ever have feedback, drop us a line.

PSF Sponsored Sprints

The project continues on – we’ve funded two sprints so far, and have several more coming down the pike. We’re always in need of volunteers to help us do things like the manuals and site maintenance/content authoring. Here’s some highlights:

The call for applications is open – The call for applications is open – and now I suspect we won’t be closing it. Originally, I thought we’d have to do things in waves of apply-approve. As time has progressed, I no longer think this is the case.
Montreal Python Packaging sprint wrap up – the wrap up report for our first sprint!
Europython core sprint report - another wrap up report for the core sprint we provided funds to.
Just added the locations page – we now have people/companies offering up space for sprinters! Check it out!
Finally - Sprints at PyOhio – PyOhio is going on this weekend, if you’re in the area you should really go check it out! Catherine has gone above and beyond with the entire “become a contributor” effort going on.

Please! If you’re thinking about holding a sprint - send us an application! Heck, even if we’re not sponsoring it, we’ll help promote you via the blog, and the sprint calendar we have up. A little fact? The sprints we’ve funded so far, and that are on deck for funding are all outside of the US, which is both awesome, and surprising!

PSF Board

Some of you probably know that I’m currently on the board of directors for the PSF – things progress well here, but I mainly wanted to call out the excellent blog Doug Hellmann has been authoring for PSF news. You should really be watching that because yes – we do do things, and hopefully over the next year, we’ll be doing more awesome things.

I’ve actually got a bigger post in the works for what I think the ultimate mission of the PSF is/should be as well as “how do you get money from us” as well. Must find the time!

Dietrich: Querying the 4 table structure.

noreply@blogger.com (Dietrich) — Thu, 29 Jul 2010 10:04:32 +0000

In my previous post, I described how four physical tables can be thought of as a means to create infinite virtual tables. One natural question you may have about this technique is "Ok, so how the heck do I query the virtual table?" It may seem a little challenging at first, but it is more than possible. Easy even.

Take our customer-process virtual table for example.

You need a query that will tell you every customer that has a max particle size over 1.5 inches. Remember that the table structure that drives this virtual table looks like this.

What we'll want is all the customer-process data results where the value is > 1.5 and the process-info-detail is Cement-Mixing's Max Particle Size.

That query simply looks like this :

SELECT CPD.CustomerProcessID
FROM Cust-Process-Data CPD
INNER JOIN Process-Info-Detail PID ON CPD.ProcessInfoDetailID = PID.ProcessInfoDetailID
INNER JOIN Process-Info PI ON PID.ProcessInfoID = PI.ProcessInfoID
WHERE PI.Process = 'Cement Mixing' AND PID.ProcessInfo = 'Max Particle Size' AND CPD.Value > 1.5

Or, to genericise it,

SELECT RowHeaderID
FROM CellData CD
INNER JOIN ColumnHeader CH ON CD.ColumnID = CH.ColumnID
INNER JOIN Table T ON CH.TableID = T.TableID
WHERE T.TableName = '{Desired Table}' AND CH.ColumnName = '{Desired Column}' AND CD.Value {ValueClause}

What I'll typically do with this clause is throw it in a sub select and join against the result. Pretend the above SQL format is abbreviated as Query in the following examples.

SELECT CustomerID
FROM CustomerProcess CP
INNER JOIN (Query) Q1 ON CP.CustomerProcessID = Q1.CustomerProcessID

And BAM we've got our results. This query structure is flexible enough to mimic 'and' and 'or' clauses against the underlying virtual tables. To get an and, you simply need to inner join the different subselect queries- the result set will only include rows that meet all the provided criteria - like so.

SELECT CustomerID

FROM CustomerProcess CP

INNER JOIN (Query) Q1 ON CP.CustomerProcessID = Q1.CustomerProcessID

INNER JOIN (Query2) Q2 ON Q1.CustomerProcessID = Q2.CustomerProcessID

And to mimic an 'Or' clause, you can simply union the sub selects. Cool, huh?

ShadowHawk: Running Internet Explorer 6 and 7 in Wine

Wed, 28 Jul 2010 11:30:12 +0000

Recently I ran into Brian Behlendorf (from Apache) at a conference on medical record systems. Brian was there demoing a new open source protocol for medical record systems to securely send eachother patient records (NHIN Direct). Combined, we were the only two who weren’t doctors, vendors, bureaucrats, or hotel staff at the conference.

I introduced myself, and Brian quickly recognized that I could probably help him with a Wine problem. He needed to run Internet Explorer 6 for the most benevolent reason of all: to prove to a client it didn’t work and that they shouldn’t bother trying to support it.

Internet Explorer in Wine

The good news is these days it’s very simple on the terminal. On Ubuntu:

Add the Wine Team PPA:
sudo add-apt-repository ppa:ubuntu-wine/ppa
Install the wine1.2 and winetricks packages:
sudo apt-get update && sudo apt-get install wine1.2 winetricks
Run winetricks:
winetricks ie6 or winetricks ie7
Run IE:
wine iexplore

Using the WINEPREFIX environment variable:

Note that, just like in Windows, you cannot have both ie6 and ie7 at the same time, at least not in the same virtual C: drive. Fortunately, it is easy to set up multiple wine folders (”prefixes”) for your version of IE to run. We do this with the WINEPREFIX environment variable.

WINEPREFIX=~/.wine-ie6 winetricks ie6 to install ie6 into its own virtual C: drive
WINEPREFIX=~/.wine-ie7 winetricks ie7 to install ie7 into its own virtual C: drive
WINEPREFIX=~/.wine-ie6 wine iexplore to run ie6
WINEPREFIX=~/.wine-ie7 wine iexplore to run ie7

As an aside, Internet Explorer 8 doesn’t currently work in Wine, however once it does there will also be a winetricks ie8 for you to test with.

sn.printf.net

MononcQc: Keep Your ORM Out of my Controller

Keep Your ORM Out of my Controller

ORMs Are Middleware, Not an Abstraction

But wait, there's more!

LOLLERZ: Kittyball go!

heeen: Day 6 - Big Basin Park

zootm: Simple JVM sandboxing

First step – enable a SecurityManager

Constructing an simple sandbox

Touch of Scala

zootm: Java gotcha o' the day

zootm: Here's a feature I made earlier

"Adding" our own methods onto an existing class

Pushing things into a map – toMap

zootm: Better classing through Scala

zootm: Silly placeholder post

LOLLERZ: New Project

LOLLERZ: Kittyball submitted!

king_kllr: Education Slides

MononcQc: Yet Another Article on Zippers

Yet Another Article on Zippers, in Erlang

What are zippers?

Zipper lists

Zipper Binary Trees

Zipper Forests

Alternatives to Zippers

heeen: Day 5 - Santana Row

heeen: Day 4 - Tierhandel

heeen: Day 2 - Erster Mall-Besuch

Janin: Release: dbus-core 0.8.4

stromdotcom: mentalBlock for iPad

stromdotcom: Windows Phone 7 Anticipation

stromdotcom: Why I’m Developing for iPad

king_kllr: PyOhio Slides

king_kllr: Testing Utilities in Django

Convenient get() and post() methods

login() wrapper

django-fixture-generator

king_kllr: MultiMethods for Python

heeen: Day 1 - Weird Stuff

heeen: Day 0 - Anreise

LOLLERZ: The Modern Liberal Goal Part 2: Work as a game

LOLLERZ: Amazon!

LOLLERZ: The Modern Liberal Goal

m0nk3yz: Miscellanea – Python Sprints, Nasuni, etc.

Nasuni

PSF Sponsored Sprints

PSF Board

Dietrich: Querying the 4 table structure.

ShadowHawk: Running Internet Explorer 6 and 7 in Wine

Pushing things into a map – `toMap`

Convenient `get()` and `post()` methods

`login()` wrapper