Max Polun

What rails could learn from pyramid

I like to look at new web frameworks every once in a while. I’ve used and enjoyed rails, I’ve used django, I’ve used bottle, but it’s hard to find a new one that I like. Too many have weird ideas of what webdev should be like. Pyramid has some odd ideas, but it also has some really good ideas.

First some terminology: in pyramid you have Models (using whatever sort of ORM you want, usually sqlalchemy), Views (which are similar to rails controllers), Renderers (similar to rails views), and configuration (which is used for a variety of things, but mainly routing).

Here’s what I think is valuable in pyramid:

  • Easy to test views: The views (again, corresponding roughly to rails controllers) are very easy to test, they’re just functions (or methods, or callable objects of any sort) that take a request object and return a response. Actually, in the common case that you don’t need to set any special headers or anything, you can just return a dict. In rails, most people I’m aaware of don’t bother with unit tests of controllers and just do integration tests. That at least in part because you’re mutating a controller object rather than just returning a simple dict. It’s not impossible, but having a good TDD workflow is all about making testing easy. And then when you return the dict, you set the renderer that gets called via an annotation. So you would have code that looks like this: ~~~~
# in
@view_config(route_name='myroute' renderer='templates/myroute.jinja2')
def myroute(request):
	return {"hello": request.matchdict["name"]}
class MyRouteTest(unittest.TestCase):
	def test_name(self):
		request = testing.DummyRequest()
		request.matchdict['name'] = 'Test'
		response = myroute(request)
		self.assertEqual(response['name'], 'Test')


  • flexible routing: routing can be done in two ways for pyramid projects, regex matching (like rails does it), and traversal of an object graph. traversal of the object graph lets you do things like give people nested folders easily, without having special routing logic. I also like how the regex matching routing works, but that’s a toss-up if it’s actually better.

  • A component system: this is kind of cool, but you can access assets of other packages by using a name like mypackage:templates/template.jinja2 This seems simpler to me than having to run a rake task to initialize and import all assets when you’re adding some third-party component like you do in rails. I know when using spree I have wished a few times that I could access some of the default project assets without having to copy the whole views/ folder into my project.

  • Scaling up and scaling down: This is one of the main hooks the pyramid devs like yo talk about, it’s easy to set up a single-file pyramid project, but it also scales up better than most microframeworks. It’s pretty rare to see a “medium-sized” framework like this. You can use it for simple projects with confidance that it’ll be ok when things become more complex.

Some things are really judgement calls, rails is very convention based: you don’t have to tell it what view to call, it inferrs that from the name of your controller method. Pyramid is much more configuration based, which is more pythonic, but maybe not better (or worse, just different). I prefer configuration when it’s simple (like in pyramid), but it can get out of control.

Posted in: at 22 Jun 2012

Compatibility is hard (or why JWZ is wrong)

Recently Jamie Zawinsky (who famously worked at netscape in the early days) wrote an artical about how he ported xscreensvaer to the iphone. One of the main issues was that the iphone (and android, and webgl, etc) only supports openGL ES, so he had to write a shim. The question is, should the khronos group have take the immediate mode stuff out of opengl es? Given that open gl es was intended to be an incompatible version that drops support for a lot of legacy stuff, immediate mode was what was going to be dropped, since anyone who wants to write a performant opengl program on modern hardware didn’t use this anyways. However jwz’s suggestion was that immediate mode stuff be emulated in a library that uses modern techinques to implement the immediate mode API. I think that’s a bad idea to be in the standard, and here’s why: You don’t want to subtly change the semantics of something so basic. If you want a compatibility shim like this, you want it to be statically linked so you have control over it, otherwise every system could slightly change how your program works. xscreensaver is a pretty trivial program compared to almost any game, and even in that small program, he’s seeing little compatibility issues with the rendering.

Maybe opengl should never have made ES (though having something so small to implement makes things like webgl much more feasible especially from a security point of view), I don’t know enough about the details of modern graphics hardware, what sorts of systems they were trying to get opengl on when they created es. However changing the semantics of such a basic part of the api would cause much more of a problem then forcing people to rewrite. Desktop (for lack of a better term) opengl has a pretty good deprication policy. Things are marked depricated in one version, and can be removed in future versions, but you can always force an older version of opengl.

I do think that removing something from an API is not something you do overnight, it’s not something you do without a solid deprication policy, and it’s not something you do unless you really need to. I’m generally in favor of keeping compatibility, but like anything else, you need to balance it with other concerns.

Posted in: at 22 Jun 2012

Comments are a go

I’ve set up disqus – comments are now allowed.

Next on the list is setting up a resume page and an about page.

Posted in: at 15 Jun 2012

DNS serves cache for a long time

So, this is up on github pages now, but the DNS cach is taking a looong time to update. It gives me time play with jekyll, and figure out how I want things to work. I want to wait for the site to be on before I set up comments. I guess I’ll use disqus.

I did have a thought on how to set up some nice js/ajax-y stuff on a static site like this, though I’m not sure if I’ll implement it. It’s really pretty simple, you have a rake task (or if I was hosting this myself, a jekyll plugin) that generates static json files. So you could end up with somethign like:

/posts.json (has a listing of all the postings)

and then in the posts.json file it would be like:

	{"title": "Title of the post", 
	"url": "/api/2012-06-15-title_of_the_post.json"},

Youd basically serialize all of the jekyll compile time data structures to static json files. You could even do a single page blog that uses HTML5 history. I don’t think it would be that hard, but since jekyll is static I’m not sure how much you’d gain other than eye candy. You could possibly cover up some of jekyll’s shortcomings, like making tag index pages and the like, but is that really easier than the other standard solution, generating them using rake (or a plugin if you’re not on github pages)?

Anyways, something to think about. I might give it a shot when I have some free time (which would be unusual).

Posted in: at 15 Jun 2012