Django community: Community blog posts RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
DjangoCon Europe 2011 is now over
DjangoCon Europe 2011 is now over We all had a great time learning new things from or co-Djangonauts and we managed to get a lot of work done on Django itself, in our castle. Now it is time to relax and get some sleep. We’ll be putting the conference videos and presentations online soon. -
Django-simpleadmindoc updated
I just published major rework of Simpleadmindoc to github with a lot of changes to make writing documentation easier. Django-simpleadmindoc is a tool that helps creating documentation for editors and administrators of django based website. Simpleadmindoc is based on and produces documents for Sphinx. Main features: autodocumenting models, referencing models and fields inside documentation fast creating of skeleton documentation If there is something you would like to see, get in touch, code is on GitHub: https://github.com/bmihelac/django-simpleadmindoc -
DjangoCon Europe 2011 Slides
I gave a talk at the wonderful DjangoCon EU again this year, and the slides are now up.You can download them from http://www.aeracode.org/static/slides/dceu-2011.pdf. Hopefully, the video will be up soon. -
Documentation-driven development is the future of Django
Or is it? Don't start this conversation when you're with the wrong crowd of animals. You could get yourself into a lot of trouble. Permalink | Leave a comment » -
Teach your team some Git! Experiences of a team lead who cares.
Teaching yourself using Git is a long process, full of obstacles - just as teaching yourself anything else more complex than cooking pancakes. But it’s not enough to use Git at home, hacking some console applications for a couple of GitHub stalkers - you should use some great version-control system at your workplace. Our dev team moved to Git not so long time ago, and it was quite a difficult move. -
Sprint introduction and closing (djangocon.eu)
-
Whither Django? - Russell Keith-Magee (djangocon.eu)
-
Scalability panel (djangocon.eu)
-
Internet connectivity at the sprints
Internet connectivity at the sprints At the sprints, wifi connectivity will be available, but only using 802.11a and 802.11n in 5 GHz-only mode. MacBooks have supported this for ages, and it’s a common feature on recent laptops of other brands as well. All model iPads support it too. Some devices, like the iPhone, only support 802.11n in 2.4 GHz mode, so they will not be able to connect. If you have a laptop that does not support 802.11a or 802.11n 5 GHz, a wired network will be available. However, depending on the amount of attendees who need/want a wired network, we may end up short on patch cables. So, if you happen to have a patch cable, please bring it to the sprints. Thanks for helping out! -
Taming runtime dynamic models in django - Will Hardy (djangocon.eu)
-
Please fill out our survey
We worked hard to make the conference as enjoyable and educational as possible, however we are humans, even Remco is, and we make mistakes. This is where you come in; to make sure we learn from our mistakes and also to make sure any future DjangoCons don’t make the same please fill out this survey. -
Deploying at an unusual scale - Andrew Godwin (djangocon.eu)
-
Django on rails: getting resourceful - Zachary Voase (djangocon.eu)
-
The best and worst of django core - Alex Gaynor (djangocon.eu)
-
An iPhone-Python love affair: Building APIs for mobile - Nate Aune, Anna Callahan (djangocon.eu)
-
The impact of django - Armin Ronacher (djangocon.eu)
-
Lightning talks tuesday (djangocon.eu)
What I learned from tomatoes - Erik Romijn Everyone knows tomatoes. And everone procrastinates. There are kitchen timers shaped like tomatoes and one of them inspired a time management technique: the pomodoro technique. Make not just django more efficient, but also make yourself more efficient. For instance, set a timer for 25 minutes and work on a task, then stop. Take a short break. Every 4 pomodoro periods, take a longer break. He tried it and it was way easier not to procrastinate. After 25 minutes you've forgotten what to procrastinate on. And it is easier to keep on working despite colleagues: "gimme another 10 minutes" is easier to get them to agree to than "come back in 4 hours". It is simple! You can learn it in a five-minute lightning talk. Try it! django-qmixin - Zachary Voase https://github.com/zacharyvoase/django-qmixin, an app for extending managers. You can more easily add methods that are available on the querysets. He showed some code, so just look at github for that :-) Javascript the right way - Angelo Dini Use semicolons at the end of your javascript lines. No comma at the end of }. Use braces, so no one-line IFs without braces even … -
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)