mon petit blogue sans importance...

first day at Pycon 2008 (updated)

So i'm at PyCon 2008 in Chicago. A few notes about the conference in general, and the django code lab tutorial we had today.

The hotel is quite nice: the rooms are fine and quite big, it's all clean and very big, and a short shuttle hop from the airport. They're not cheap though: the conference rate is great at 99$/night, but then they ding you $18/day for a parking spot if you need it, $13/day for in-room wifi (good thing pycon have free wifi on their floor), and i paid $14 at lunch for a tuna sandwich + tiny bottle of Perrier at the only "restaurant" (a café counter) that's open for lunch. We got fed at dinner, and will be fed at lunches all other days, so that's ok, though.

They have free wifi for the conference, with a 45 Mbps pipe that pycon brought in just for t­he conference (as they tended to kill the upstream link of whatever hotel they were in the last few years). But the hotel, from what i understood, is providing the wifi itself... and they're not too good at it. To further complicate things, some ppl can't setup wifi on their machines, and end up creating ad hoc networks with the same name, which effectively hijacks the conference's essid... :( Hopefully they have that fixed before the bulk of the attendees get in tomorrow for the "real" conference. What was really strange is that my gnome network config tool got stuck in a state where everytime i logged in, even if i pre-config'd the wireless properly, it would just screw it up and i got disconnected. I had to turn on the kill switch, reboot, log­ in, disable the network in the applet, disable the kill switch, config the wireless interface manually.

So Martin (also from Akoha) and i got here this afternoon so we could attend the Django Code Lab. The concept is simple: they emailed the attendees in advance so we would send them pieces of code along with specific questions. It was a really great idea. They picked a subset of them and answered the questions. It led them to talk about many different areas, from fairly simple basic stuff (like don't put 600 url patterns in your main urls.py) to more advanced topics (like EAV or database scaling). I had sent them the code for our webservice, which is basically a REST-ish interface into django models. I spent a few hours last week making that piece generic so we can open-source it (which we'll do soon, along with pieces on the client-side that allow to code AJAX interfaces effectively). I had a couple of questions about pieces of that code, that i no longer remember, but mainly i wanted some feedback about it. Unfortunately, they had planned my part as the second-last, and they ran out of time. Jacob nonetheless gave me some feedback afterwards:

• he didn't like how our currently default method is to put the webservice inside the model: he feels this is clearly a view thing, so the declaration of it belongs in urls.py, and its definition in a file that's separate from models.py. I see his points, and fortunately the way the webservice works, you can indeed extirpate its definition from the model, so this wouldn't be difficult to do. It may just be a matter of enabling the declaration in urls.py instead of settings.py, and emphasizing the definition of the webservice for a model outside of the model itself. (updated π/2008:)
  
• however, the original method of definition a model's webmethod is to put those methods as methods of the model's WebService class, and putting that class in another file is how to address his comment.
  
• but the reason that we moved to a way where we can define a webservice method for a model directly as a method of that model is that the same method needs to be called as both webservice RPC calls, and from django templates (which can't reach a webservice instance easily).
  
• re-separating the webservice would make this again difficult, and we'd have to again write one method for the template to reach, and one in the webservice, which would call the model one
• then again, the templating philosophy in django would probably say that these methods the template calls don't belong in either place: they belong in views.py and would pass their result as context variables... but we like coding the models and its methods and not have to go back to the views after the fact because the front-end guy suddenly wants access to it...
  
• Sébastien from akoha also had made the previous point to me previously, as well as this one that Jacob talked about: separating the webservice definition from the models should also allow the publication of a webservice that is not tied to one model, but could potentially be an amalgamation of models, or publishing the same model under 2 webservice names with different functionalities (so the backend has a generic model, but that is published with specialized interfaces). I actually have a bug against myself in our internal bugtracker to do this.

Otherwise, he liked it, and sees the need for it. He has 3 slides on our WS in ­his presentation even though he didn't get to it. I was approached by 3 or 4 nice fellows who really liked to hear someone had working code for this problem, and are interested in seeing it. So perhaps we'll open-source before we can write an example application, which we had hoped to do but won't have time to for a little while.

Also in the code lab, i asked about horizontal database partitioning: being able to declare that certain models belong in a different database. The django guys felt that, while they might accept a full patch for this, django shouldn't have to know about how the database is partitionned this way, and a database clustering tool (for postgresql or mysql) that looks to django as one db server might be a better road. That being said, there was some talk of vertically partitionning the database, such as having a set of users on one db, and another set on another. They do want some level of support for this in django, however.

They talked about many other things: look at the slides for more info (damn, don't have the link with me, i'll update this tomorrow with it).

I've picked the talks i'm going to for the entire event. There's too many. There are 4 tracks, and for at least 25% of them i would have liked to see 2 of the tracks. Only for 1 time slot was i not thoroughly enthusiastic about any of the tracks.

by wiswaud on 14 March 2008
Tags: chicago, django, english, geeky, python