Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Integrating the enterprise using django - Ed Crewe (djangocon.eu)
Single sign-on, group repository, identity management, cloud tools, perhaps google apps, specific university department apps. There's a whole lot enterprisy stuff out there and django might have to connect to them. Data is also in big central oracle databases. There's file storage on a SAN. Authorisation integration. Single sign on and group management. django-cas helps. Data integration, for instance group lists from various sources. External data in databases is fed by other apps like a CMS or department apps. Storing that data is oracle's job. But the data structure tends to change. So the defined views in oracle that abstract away the differences. Django just connects to them with read-only models. Sometimes bit sql statements are needed. They even went so far as to generate sql statements with django templates to give users the chance to make custom queries! For configuration of the multiple sites they use decorators in the urls.py to customize the configuration. Last step is the chrome. The look and feel of the site. They grab the layout from existing sites to integrate a bit with those sites automatically. Question from me: regarding the chrome: it sounded a bit like xdv, wsgi middleware for hooking up with … -
The django ORM and multilingual database contents - Jonas Obrist (djangocon.eu)
What he wants is multilingual content in the database with an easy API. He doesn't want to use something like gettext as that has other uses. Some approaches: Single-table: one extra field per translatable field per language. Plusses: somewhat easy to implement. Few queries. Fallbacks are simple. Minusses: ordering/filtering is hard. Migrations are no fun: for every new field, you need a schema migration. Query results can get big. Hash-table: one extra table with key/value translations. Pro: easy to implement. Only translate once. Con: slow, no ordering. Dual-tables: one for translated fields, one for untranslated fields. Pro: can be very fast. Few queries. Works great with south. Con: harder to implement. Django doesn't like you to implement it this way in a generic way. Only in your own app is ok, but a generic solution is hard. Other things like JSONField, build-in google translate, things he doesn't like. django-multilingual-ng is something he wrote build upon django-multilingual. Don't use it. It is slow. Dual-table approach. django-nani: dual-table approach again. His current effort. It tries to be as fast as possible. QuerySet API should stay the same where possible. Documented. (After twittering him, Jonas added the README to the pypi page within … -
Core developers panel (djangocon.eu)
Participants: Andrew Godwin, Idan Gazit, Russell Keith-Magee, Alex Gaynor, Jannis Leidel. (Note: I didn't get the first 15 minutes of the panel: there was a free chair massage downstairs. I was in line for half an hour, so I didn't want to skip it). You've added core contributors last year. How has that played out? Positive experience? Well, it worked out real well. The people we added should have been added a long time ago. There's been a complete absense of a committer bottleneck, great. There've been a few hickups, but we really should have done it much earlier. They're planning on adding a couple of extra committers soonish. "Several people have said that they have used (or considered using) non-Django solutions for all or part of their stack for realtime/async performance (eg "the node.js crisis"). Do you think this is a crisis that Django needs to address? If so how? Not too big a problem. There are solutions, like gunicorn with eventlet. Sometimes, however, django can get in the way but there's lots of room and opportunity for improvement. Another good solution came up earlier this conference with the mozilla add-on website: django for most of the site and … -
Reusable apps using "Eight Spaces" - Klaas van Schelven (djangocon.eu)
(I've got a summary about an earlier talk he gave about this, btw). He works for legalsense and makes sites for lawyers. Lots of smaller websites. Every website has small differences, which is relevant to this talk. Django is great. It is modular, but integrated. Views, models, model admins, all tied together. This talk is about reuse, but he doesn't mean the framework-y stuff that django already does like south, model fields, template tags. It means reuse of apps. What is an app? Something with a models.py, a couple of templates, an admin.py, urls a couple of views. That's what we mean with an app as programmers. The customer doesn't have this view. A customer sees "a blog" and "a customer list". Things the customer can touch. Reusing apps is a recurring theme. Perhaps it is even the holy grail. Changing an app is often a part of reuse. So you need to change something in an app. For instance you want to add a Dutch social security number to django-authentication. None of their clients want to do that, except one. That's the kind of very local per-site reuse they have to handle. Adding just one field should not be … -
Celery, an asynchronous task queue (not only) for Django - Markus Zapke-Gruendemann (djangocon.eu)
Unrelated-to-this-talk message: next djangocon.eu will be in Zürich, organized by divio. Why use a task queue? If a user clicks something, he has to wait. Adding a comment means checking for spam. Uploading an image means generating thumbnails. Ordering a product means processing payments and sending emails. You can use a cronjob for recurring tasks. But you have to wait for the cronjob to come along and sometimes the cronjob might not have anything to do. A task queue can help! You can decouple information producers and consumers. Asynchronous processing might mean a speed increase. Scalability can improve. Celery is such a task queue. Written in python. In celery, clients connect to a broker which gives tasks to workers. So both clients and workers are scalable. Celery supports synchronous, asynchronous and scheduled tasks. As a broker it recomments RabbitMQ. RabbitMQ is written in Erlang and it has clustering support if you need it. Some of celery's features: serialization to pickle, json or custom code. Tasks can be grouped into sets and subtasks. You can retry failed tasks. And there's routing (on some brokers), so you can configure which queues get used for what. Results, when finished, can be stored in … -
Unjoinify, taming the sql beast - Matt Westcott (djangocon.eu)
Unjoinify helps with deeply nested sql data sets. He doesn't have a full solution for "eager loading" and the "n+1 query problem" and "select_related", but unjoinify does help with it. With nested data sets it is common to see structures like this in your template: {% for festival in festivals %} {% for movie in festival.nominations %} {% for actor in movie.actors %} And in the end django toolbar will tell you you've just done 500 queries. You can do something with .grouper (see template built-ins), but that's also not optimal. You could do it with a nice multi-line hand-crafted tedious raw sql query. That's tedious, but not impossible. What'd be nicer is to have some tool do all this for us. That's where unjoinify comes in. Unjoinify uses django's double-underscore special name idea to specify what you want out of the database. Unjoinify figures out how to get it out of the database: nomination__movie__id nomination__movie__title nomination__movie__actors__name This means long names, so there's another trick to get it out in a nicer format. (Note: I might have written this down incompletely/incorrectly, so check the documentation.) It uses python's built-in itertools.group_by() to make iteration over similar items at the same level … -
Continuous integration and continuous deployment - Szilveszter Farkas (djangocon.eu)
Szilveszter works for http://prezi.com/, an online presentation website. For their site, they had a small test suite. 30% coverage. Everyone had feature branches. When completed they were merged and released, leading to bugs and integration issues. Now they use continuous integration and continuous deployment and their process is much more slick. Branching for feature branches often used to end up in a "merge hell". What they, ironically, do is to use a centralized model now. Everyone works on trunk/master and every commit is emailed and can be reviewed. Features are written concurrently in that same trunk/master. They fixed their test coverage by fixing all failing tests first. Then the rule was instated that every new piece of code must have tests. And bugs need a test too. For continuous integration they use jenkins. For django, there's integration with django-jenkins. The continuous integration is not to the production system, but to a staging system. That really helps quality assurance, as there's always a fresh website to work with. But... how do you release features that take more than a day to implement? Well, just release them every day, but don't show them to (all) users. They use gargoyle to flag features … -
Bitbucket, lessons learned - Jesper Noehr (djangocon.eu)
-
Who cares about zope? - Martijn Faassen (djangocon.eu keynote)
Note beforehand. Martijn Faassen is well known in the zope world. Remember zope? The python web framework that used to have the buzz that django has now? I remember two europython conferences where one of the three tracks was zope/plone-only. Those europython conferences were one of the things he started, btw. So I expect a bit of a history lesson and some valuable input from another python web framework and perhaps some community organizing comparisons. We'll see! Now on to the actual summary. Martijn wrote/started a couple of things: formulator, five (zope3 in zope2), lxml, grok webframework, etc. He started python programming in 1998. And around that time he also started with zope: yes, it is that old. In 2008 at djangocon, there was a talk by Mark Ramm about what django could learn from zope. Matt is a turbogears guy, btw. The reactions were pretty harsh sometimes, like "we lost a whole generation of web programmers to zope" and "django is an anti-zope". Some inflammatory comments to start off the discussion in the internet forums. Just to get it over with :-) Django now has class-based views. Zope's class based views are from 2004. (In his presentation he called … -
Good reasons to use django-dbtemplates
I'm loving the humble django-dbtemplate app at the moment. I wanted to share my experience here, perhaps it's something to consider for your next project. Project brief I recently deployed a nice simple django based web application to streamline an otherwise labor intensive business process. The application managed requests through a business workflow by generating emails to different people asking them to complete tasks online. Nothing particularly special but Django did the job perfectly. During the project the client required various template changes. Mainly small email and webpage tweaks really but important none the less. Managing template changes during the campaign For the first time I included django-dbtemplate in my project. Initially I didn't really have a strong reason for including it but I did anyway - it proved to be a great decision. With dbtemplates I was able to update templates on the live system via the admin interface. Just type in the name of the template to load it into the database and then make your changes. Without dbtemplates I would have had to make these changes another, either: Commiting template changes into the code base - that would have involved a full patch release including committing … -
Django: Executing manage.py from Anywhere
One nice convenience would be to have a way to call manage.py from anywhere within a virtual environment. For example, if I want to execute 'manage.py shell', it would be nice to be able to execute that from anywhere rather than having to change directory to where manage.py lives.We can already run management commands from anywhere using django-admin by utilizing the --settings flag, but doing this requires a lot of typing. And wrapping the django-admin in a shell script seems inelegant somehow.Instead, I wrote a small python script based off of manage.py. This can be placed in the ./bin directory in the virtualenv. The DjangoManageSettings object is meant to be customized on a per project basis, and I intend to make it so it can be passed in from a file configuration somewhere.Anyway, thought I would share. I'm curious to see other approaches to this.# ---------- ${VIRTUAL_ENV}/bin/django_manage.py -------------------------#!/usr/bin/env pythonimport os, sysfrom django.core.management import execute_managerclass DjangoManageSettings(object): def __init__(self): self.VENV_ROOT = os.getenv("VIRTUAL_ENV") # The name of the module that settings.py resides in self.PROJECT_NAME="myproject" # The path to the directory where the Django project lives. # I made it relative to the virtualenv root. self.PROJECT_PARENT_PATH = os.path.join(self.VENV_ROOT, "app") # The name of the django settings model in the … -
Django Hosting Roundup: (Ep.io vs Gondor.io vs DotCloud vs AppHosted vs DjangoZoom) Who wins?
For the past 6 weeks I have been trying out all of the new django/python hosting services that are currently available today, and I have been writing about my experiences along the way. It only makes sense to conclude this series of articles with one last article comparing all of the services against each other. It is important to note that many of these services are still in development and aren't even available to the general public, so I'll try to keep this article up to date as these services change over time. With that said, don't take my word for it, go out and try all of these services on your own and find out which one you like the best, you won't be disappointed. Quick Recap ep.io Pretty solid offering, with a nice set of features and a decent price. Good set of documentation. gondor.io Their website has a nice list of features that they expect to have once they officially launch, but most of those features aren't available yet. The documentation is a little light, but the service has a lot of potential. dotcloud.com They have a ton of money ($10M), and with it, a ton of … -
Getting Started with AJAX in Django: a Simple jQuery Approach
AJAX in Django using jQuery I recently created a side project to explore a few tech areas I wanted to learn more thoroughly. One of those areas was how to implement AJAX in Django using jQuery. In a nutshell, the site, TruthTruthLie.me (update 3/5/2013: the site is temporarily offline as switch my Facebook Connect implementation from django-socialregistration to django-social-auth) presents three facts about you and challenges your friends to click on the one that is a lie. When your friend clicks on a fact, I send the clicked fact_id via AJAX to a url. A Django url pattern routes the click to a view where I check what “type” the fact is, return the result via JSON to the client and update the page dynamically without a page refresh. Below are the stripped down page, url pattern and view that I use to get this done. You can also check out my simple but working AJAX in Django using jQuery demo page. ajax_in_django.html: <html> <head> <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"> </script> <script type="text/javascript"> $(document).ready(function() { $('.fact').bind('click', function () { $.get("/test/"+this.id+"/", function(data) { if (data.fact_type=="T") { guess_result="This fact is true! " + data.fact_note; } else { guess_result="This fact is false! " + data.fact_note; … -
Monday lightning talks (djangocon.eu)
Time for some quick typing! The 5-minutes-a-piece lightning talks! Introducing django REST framework - Tom Christie See http://django-rest-framework.org/ . The first version was released in February. Django rest framework uses django 1.3's class based views. Very cool is that it creates web browsable APIs. We're all building cool REST services, but you can't browse them on the internet to discover about them. An API should be self-describing. But an API explorer is not the answer: it is an unnecessary indirection. It is not just about making everything shiny. If we design our API to be browsable they will be better designed and faster to work with. They're also more transparent, open and self explanatory. Making it open in this way helps you in designing it. Revised form rendering - Gregor Muellegger Revised form rendering is a GSOC project. The current rendering just plain sucks. It is not possible to change a widget on the fly. You can't change the order of the form fields without editing the python file. Etc. So: template based form rendering! There'll be a new form template tag with a couple of options to modify the form before rendering. {% formlayout "ul" %}{% form myform %} … -
Django, compass and the less framework - Idan Gazit (djangocon.eu) — Reinout van Rees' website
So if you’ve got problems on the desktop and other bigger devices, too, why do we have that mobile/the_rest split anyway? Why not just accept the continuous spectrum regarding screen sizes? -
3 CMSs in 45 minutes (djangocon.eu) — Reinout van Rees' website
-
Django and pypy - Alex Gaynor (djangocon.eu) — Reinout van Rees' website
How to use pypy? Well, just use it. manage.py runserver will work. For server side work, take any of the pure python wsgi servers. So not mod_wsgi as it is a big C extension, but use gunicorn for instance. -
How I learned to stop worrying and love python packaging - Jannis Leidel (djangocon.eu) — Reinout van Rees' website
Regular python packaging (in our case in combination with buildout) is something we use a lot. So a talk on this at the djangocon.eu is something I look upon with a favourable eye. (I’ll even take the opportunity to point you at my software releases series.) -
Large django sites at mozilla - Andy McKay (djangocon.eu) — Reinout van Rees' website
-
From static to realtime - Eric Florenzano (djangocon.eu)
Note: Eric is one of the founders of convore (see the djangocon eu 2011 group on convore). His talk is on converting a django site to the realtime age: does the django heart stay in place or is it replaced with something "more current" like node.js? In the end, he told his story as a fairy tale. Entertaining and slick. Good job! At a certain time he thought about writing a shiny new social photo website. All the cool sites were about social photo stuff. So he build one. And it became popular! And slow. So caching to the rescue. It helped. For a while. It became even more popular. Social photos mean frantic reloading of webpages. So it became slow again. Full-page reloads. Even expiry headers didn't help. Good artist copy, great artists steal. So he stole some ideas from twitter. Just a quick json endpoint that listed the most recent photos. And a bit of javascript that reloads that small bit of content every five seconds. If something has changed, a button would pop up so the user could reload. The users loved it. But every user that visited any page on the site would keep hitting that … -
Opening - Remco Wendt (djangocon.eu)
Opening of the third European Djangocon! Remco tells us to behave as there's a java island (java-eiland in Dutch, see photo below) 200m from the conference location. So if you write non-clean code during the sprints you'll be banished to this prison island :-) Nice to see our (Nelen & Schuurmans) company name right there on the left hand side on one of the big sponsor banners, btw! The question everyone is about to ask: yes, the wifi is holding up nicely :-) Warning: the public transport in Amsterdam is on strike on tuesday. Good thing that the city of Amsterdam sponsors us with free bikes for the duration of the conference. On wednesday there are bitbucket-sponsored drinks. Also several other people have been invited from tech companies in Amsterdam and from ruby/js/etc. On hashtags: on twitter, look at #djangocon. -
DjangoCon Europe 2011 live stream
LiveStream via Ustream Starting monday at 09:30 CET, DjangoCon Europe 2011 will be broadcasting live all presentations. You can tune in via Ustream using the DjangoCon Europe 2011 channel -
Preparing for djangocon (djangocon.eu)
It is sunday evening and tomorrow morning I'm going to Amsterdam for the djangocon.eu conference. I'm staying at home at night as it is close by enough. It'll mean less night rest than I'm normally getting at a conference, as I'll have to subtract a one one-way hour commute (two hours total) from every conference day's night rest. A big part of a preparation for me means preparing my talk summaries. Last year I wrote a metric buttload of summaries and this year I'm going to do the same. This does mean looking up all the talks beforehand and preparing a text file on each and every one of them. With a link to the project readily pasted in and a proper reference to the author. And an photo pasted in. I want, somehow, to have a photo for every entry. Normally I take photos in the conference town and at the conference, but I don't stay in Amsterdam itself, so I won't have much chance at making photos. Only of the station and so. So what about model train photographs? Not a bad idea at all :-) I've got a lot of photos of excellently modelled railways. Not the … -
Add your questions for the panels
Add your questions for the panels We have set up Google moderators for the scalability panel and core developers panel where you can add your own questions and vote on the questions that have already been added. -
DjangoZoom.com Review
This is part five in my series on django hosting services. Previously, I looked at ep.io, apphosted.com, gondor.io, dotcloud.com and now I'm looking at DjangoZoom.com. DjangoZoom.com is the brain child of Nate Aune and Shimon Rura and is based in Boston, Massachusetts. It was founded in 2010 at StartupWeekend Boston and was a finalist in the MassChallenge. Their office is in the Dogpatch Labs space for startups in Cambridge, Massachusetts. They are currently still in a closed beta, but they were nice enough to send me an invite to check it out. Normally when I check out a service for the first time, I look over the documentation to see what it can do, and what it can't do, and what I need to do in order to get my app up and running. DjangoZoom has a nice collection of documents that help guide you through the process of getting your application up and running on their platform. You need to be logged in, in order to read the documents, so I won't be able to link to any documents here, but if you are lucky enough to get an invite to DjangoZoom, I would check out the documents first, …
