Django community: Community blog posts RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Creating a Custom Panel for the Django Debug Toolbar
Sometimes you work on stuff you don’t really control, eg. when interacting with some mysterious SOAP server accross the Internets, and you’d appreciate a little help from the Django ecosystem to ease debugging. That’s — you guessed it — my case currently, and I really appreciated being able to create my own custom panel for adding specific debugging capabilities to the awesome Django Debug Toolbar. Here’s how I did, learning mainly from the code of the panels shipping with the DJT. I’m supposing you have installed and configured the DJT in your project already. First of all, create a panels.py module within one of your app (or wherever you want as it’s in your python path) and create a DebugPanel derivated class, like this: from debug_toolbar.panels import DebugPanel from django.template.loader import render_to_string from django.utils.translation import ugettext_lazy as _ class MyUsefulDebugPanel(DebugPanel): name = 'MyUseful' has_content = True def nav_title(self): return _('Useful Infos') def title(self): return _('My Useful Debug Panel') def url(self): return '' def content(self): context = self.context.copy() context.update({ 'infos': [ {'plop': 'plip'}, {'plop': 'plup'}, ], }) return render_to_string('panels/my_useful_panel.html', context) The debug panel class methods and code should be self-explanatory enough. Just note you have to create a template, here panels/my_useful_panel.html … -
Disqus experience - cache of model's related fields
Very interesting tricks from Disqus: Scaling The World’s Largest Django ApplicationThe main idea to retrieve related fields by two requests instead of 1 + 25 sql requests using post.userSuch situation caused in several projects simultaneously so I working on optimization things right now.# cacheposts = Post.objects.all()[0:25]users = dict( (u.pk, u) for u in \ User.objects.filter(pk__in=set(p.user_id for p in posts)))for p in posts: p.__user_cache = users.get(p.user_id)And don't forget about SQL indexes - in all cases when field used in ORDER or WHERE sql statements it will increase performance a lot -
django-meio-easytags 0.4 released!
I just released the version 0.4 of the django-meio-easytags. I added a subclass of django’s default template tags Library. And now it’s easier to create a template tag. Take a look. Projects page Read the Docs Download from Github -
Basic Python Logging in Django 1.2: Debugging Made Simple
When I was deploying my new social shopping site Wantbox a couple of month ago, I discovered that I couldn’t use the Django print command in my live Dreamhost (Passenger WSGI) environment like this: print "Hello world!" As a new site, I was still debugging a few persistent nits and really needed to print out messages when certain areas of the code were accessed. A few sites recommended that I try the Django debug toolbar, but I was having trouble getting that to work reliably in my Dreamhost setup. I searched around a bit more and after consuming many web pages, finally discovered a dead simple solution using the built-in Python logging module. Python Logging in Django, Step-by-Step: Open your “settings.py” file and add this code to the bottom: # setup logger import logging PROJECT_DIR = os.path.dirname(__file__) PARENT_DIR = os.path.dirname(PROJECT_DIR) logging.basicConfig(level=logging.DEBUG, format='%(asctime)s %(levelname)s %(message)s', filename=os.path.join(PARENT_DIR, 'django.log'), filemode='a+')</pre> Create a file called “django.log” at the same level as your project, my setup looks like: . .. .htaccess django.log passenger_wsgi.py passenger_wsgi.pyc public tmp wantbox (my django project) In the view where you need to “print” add the following: import logging logging.debug("hello world!") logging.info("this is some interesting info!") logging.error("this is an error!") Now … -
django-meio-easytags 0.4 released!
I just released the version 0.4 of the django-meio-easytags. I added a subclass of django’s default template tags Library. And now it’s easier to create a template tag. Take a look. Projects page Read the Docs Download from Github -
JSHint Edition Update: 2011-03-01
-
Django CMS 2.2 features that I want to see
… this is the “Post on request” for February 2011 Preface: I have to admit that I was expecting a bigger interest in the “Post on request” topic but probably my blog is too young for this but I think I will try again(soon or not). The more important thing is that Jonas Obrist is [...] -
Django-mockups, l’application mi moquette, mi ketchup
Malgré le fait que le mois de février ne fasse que 28 jours, malgré le fait que j'ai maintenant une petiote qui gazouille gentiment en me regardant avec ses grands yeux bleus, malgré le fait que les journées au boulot ne se finissent jamais, même le week-end, je réussi donc la prouesses de sortir ... -
Karma
Aquests dies estic bastant engrescat i enfeinat amb projectes molt relacionats amb Python i Django. Per una banda estam definit i creant el que serà la segona fase del projecte Clickote, una aproximació simpàtica a les reserves d'hotel en la qual estam passant molt de gust fent-hi feina. Per una altra banda estam migrant un aplicació web feta inicialment amb ezPublish, un CMS dels de tota la vida, cap a Django. Clickote és un projecte en el qual m'està agradant molt fer-hi feina perquè a més del projecte i la tecnologia en sí, ve a demostrar que client i proveïdor de serveis no són antagonistes, sinó que són col·laboradors. Amb l'equip de Clickote ens hi sentim molt bé fent-hi feina. Hem topat amb gent que no tan sols coneix el negoci, sinó que a més és conscient de la part tecnològica i de les implicacions en temps i esforç del que demanen, i sempre hem arribat a solucions beneficioses per al projecte. La migració d'un lloc web des del CMS ezPublish cap a un CMS fet a mida amb Django és també tot un repte i representa també tot una aposta de futur per part del client. A les primeres … -
0.2 release plans
Right, back to it then. Plans for 0.2 are underway, and there’s a bunch of stuff up now on the issue tracker. Looking to address permissions & authentication in this next release. The main planned features are: Throttling. Implemented as … Continue reading → -
Team of experienced Django devs looking for remote contract work
Three month ago I decided to become a freelancer. As of 31 January 2011 I stopped working for Open-E company where I spent last 3 years as Python/Django developer. Now I join forces together with my friend Bartosz Burclaf under name of eFabryka.com. We are a small, agile and goal oriented, distributed developers team operating out of Poland. In our daily work we strongly believe in KISS and DRY principles. While designing and writing our code we follow TDD/BDD approach. We are looking for interesting projects to dive into - find out more on: www.efabryka.com -
django-meio-easytags 0.3 released!
I released today the version 0.3 of django-meio-easytags. Now it supports template tags that accepts positional arguments (*args) and keyword arguments (**kwargs). If you don’t know how to use this, take a look at Python FAQ. In this release I included some documentation and created a page for the project. Any doubts, suggestions, feature requests, feel [...] -
django-meio-easytags 0.3 released!
I released today the version 0.3 of django-meio-easytags. Now it supports template tags that accepts positional arguments (*args) and keyword arguments (**kwargs). If you don’t know how to use this, take a look at Python FAQ. In this release I included some documentation and created a page for the project. Any doubts, suggestions, feature requests, [...] -
Release early \\ (Release often?)
Righty, this feels all sorta official. So, the 0.1 release of Django REST framework went up to PyPI yesterday and I made the announce on the django-users mailing list today. So that’s, that then. I’d really appreciate any constructive criticism of … Continue reading → -
Release early \\ (Release often?)
Righty, this feels all sorta official. So, the 0.1 release of Django REST framework went up to PyPI yesterday and I made the announce on the django-users mailing list today. So that’s, that then. I’d really appreciate any constructive criticism of … Continue reading → -
Optimization of getting random rows out of a PostgreSQL in Django
There was a really interesting discussion on the django-users mailing list about how to best select random elements out of a SQL database the most efficient way. I knew using a regular RANDOM() in SQL can be very slow on big tables but I didn't know by how much. Had to run a quick test! Cal Leeming discussed a snippet of his to do with pagination huge tables which uses the MAX(id) aggregate function. So, I did a little experiment on a table with 84,000 rows in it. Realistic enough to matter even though it's less than millions. So, how long would it take to select 10 random items, 10 times? Benchmark code looks like this: TIMES = 10 def using_normal_random(model): for i in range(TIMES): yield model.objects.all().order_by('?')[0].pk t0 = time() for i in range(TIMES): list(using_normal_random(SomeLargishModel)) t1 = time() print t1-t0, "seconds" Result: 41.8955321312 seconds Nasty!! Also running this you'll notice postgres spiking your CPU like crazy. A much better approach is to use Python's random.randint(1, <max ID>). Looks like this: from django.db.models import Max from random import randint def using_max(model): max_ = model.objects.aggregate(Max('id'))['id__max'] i = 0 while i < TIMES: try: yield model.objects.get(pk=randint(1, max_)).pk i += 1 except model.DoesNotExist: pass t0 = time() for i in range(TIMES): list(using_max(SomeLargishModel)) t1 = time() print t1-t0, "seconds" Result: 0.63835811615 seconds Much more pleasant! UPDATE Commentator, Ken Swift, asked what if your requirement is to select 100 random items instead of just 10. Won't those 101 database queries be more costly than … -
Optimization of getting random rows out of a PostgreSQL in Django
There was a really interesting discussion on the django-users mailing list about how to best select random elements out of a SQL database the most efficient way. I knew using a regular RANDOM() in SQL can be very slow on big tables but I didn't know by how much. Had to run a quick test! Cal Leeming discussed a snippet of his to do with pagination huge tables which uses the MAX(id) aggregate function. So, I did a little experiment on a table with 84,000 rows in it. Realistic enough to matter even though it's less than millions. So, how long would it take to select 10 random items, 10 times? Benchmark code looks like this: TIMES = 10 def using_normal_random(model): for i in range(TIMES): yield model.objects.all().order_by('?')[0].pk t0 = time() for i in range(TIMES): list(using_normal_random(SomeLargishModel)) t1 = time() print t1-t0, "seconds" Result: 41.8955321312 seconds Nasty!! Also running this you'll notice postgres spiking your CPU like crazy. A much better approach is to use Python's random.randint(1, <max ID>). Looks like this: from django.db.models import Max from random import randint def using_max(model): max_ = model.objects.aggregate(Max('id'))['id__max'] i = 0 while i < TIMES: try: yield model.objects.get(pk=randint(1, max_)).pk i += 1 except model.DoesNotExist: pass t0 = time() for i in range(TIMES): list(using_max(SomeLargishModel)) t1 = time() print t1-t0, "seconds" Result: 0.63835811615 seconds Much more pleasant! UPDATE Commentator, Ken Swift, asked what if your requirement is to select 100 random items instead of just 10. Won't those 101 database queries be more costly than … -
Optimization of getting random rows out of a PostgreSQL in Django
There was a really interesting discussion on the django-users mailing list about how to best select random elements out of a SQL database the most efficient way. I knew using a regular RANDOM() in SQL can be very slow on big tables but I didn't know by how much. Had to run a quick test! Cal Leeming discussed a snippet of his to do with pagination huge tables which uses the MAX(id) aggregate function. So, I did a little experiment on a table with 84,000 rows in it. Realistic enough to matter even though it's less than millions. So, how long would it take to select 10 random items, 10 times? Benchmark code looks like this: TIMES = 10 def using_normal_random(model): for i in range(TIMES): yield model.objects.all().order_by('?')[0].pk t0 = time() for i in range(TIMES): list(using_normal_random(SomeLargishModel)) t1 = time() print t1-t0, "seconds" Result: 41.8955321312 seconds Nasty!! Also running this you'll notice postgres spiking your CPU like crazy. A much better approach is to use Python's random.randint(1, <max ID>). Looks like this: from django.db.models import Max from random import randint def using_max(model): max_ = model.objects.aggregate(Max('id'))['id__max'] i = 0 while i < TIMES: try: yield model.objects.get(pk=randint(1, max_)).pk i += 1 except model.DoesNotExist: pass t0 = time() for i in range(TIMES): list(using_max(SomeLargishModel)) t1 = time() print t1-t0, "seconds" Result: 0.63835811615 seconds Much more pleasant! UPDATE Commentator, Ken Swift, asked what if your requirement is to select 100 random items instead of just 10. Won't those 101 database queries be more costly than … -
Optimization of getting random rows out of a PostgreSQL in Django
There was a really interesting discussion on the django-users mailing list about how to best select random elements out of a SQL database the most efficient way. I knew using a regular RANDOM() in SQL can be very slow on big tables but I didn't know by how much. Had to run a quick test! Cal Leeming discussed a snippet of his to do with pagination huge tables which uses the MAX(id) aggregate function. So, I did a little experiment on a table with 84,000 rows in it. Realistic enough to matter even though it's less than millions. So, how long would it take to select 10 random items, 10 times? Benchmark code looks like this: TIMES = 10 def using_normal_random(model): for i in range(TIMES): yield model.objects.all().order_by('?')[0].pk t0 = time() for i in range(TIMES): list(using_normal_random(SomeLargishModel)) t1 = time() print t1-t0, "seconds" Result: 41.8955321312 seconds Nasty!! Also running this you'll notice postgres spiking your CPU like crazy. A much better approach is to use Python's random.randint(1, <max ID>). Looks like this: from django.db.models import Max from random import randint def using_max(model): max_ = model.objects.aggregate(Max('id'))['id__max'] i = 0 while i < TIMES: try: yield model.objects.get(pk=randint(1, max_)).pk i += 1 except model.DoesNotExist: pass t0 = time() for i in range(TIMES): list(using_max(SomeLargishModel)) t1 = time() print t1-t0, "seconds" Result: 0.63835811615 seconds Much more pleasant! UPDATE Commentator, Ken Swift, asked what if your requirement is to select 100 random items instead of just 10. Won't those 101 database queries be more costly than … -
Entrevista a Daniel Rus de Witmeet
Comenzamos una nueva categoría de artículos en los que iremos descubriendo proyectos creados con Django por la comunidad hispanohablante. Para estrenarla tenemos la suerte de entrevistar a Daniel Rus, creador de Witmeet. Witmeet es un sitio web que permite buscar personas con las que practicar idiomas cara a cara en cualquier parte del mundo. Una vez te das de alta puedes configurar tu perfil con los idiomas que hablas y los que quieres practicar. Puedes crear tus propios witmeets eligiendo tu disponibilidad y los sitios (cafeterías u otros lugares) donde te apetezca quedar para practicar idiomas, o buscar witmeets cercanos creados por otros usuarios. -
Antonkovalyov Jshint Edition Update 2011 03 01
Today we released 2011-03-01 edition of JSHint, a community-driven code quality tool. This is the first release since the announcement and so far the community feedback has been nothing but helpful. I would like to personally thank the following contributors for providing patches that were includ... -
Redis at Disqus
-
django-meio-easytags released!
django-meio-easytags An easy way to create and parse custom template tags for Django's templating system. -
django-meio-easytags released!
django-meio-easytags An easy way to create and parse custom template tags for Django's templating system. -
Nice testimonial about django-static
My friend Chris is a Django newbie who has managed to build a whole e-shop site in Django. It will launch on a couple of days and when it launches I will blog about it here too. He sent me this today which gave me a smile: "I spent today setting up django_static for the site, and optimising it for performance. If there's one thing I've learned from you, it's optimisation. So, my homepage is now under 100KB (was 330KB), and it loads in @5-6 seconds from hard refresh (was 13-14 seconds at its worst). And I just got a 92 score on Yslow. I do believe I have the fastest tea website around now, and I still haven't installed caching. Wicked huh?" He's talking about using django-static. Then I get another email shortly after with this: "correction - I get 97 on YSlow if I use a VPN. I just found that the Great Firewall tags extra HTTP requests onto every request I make from my browser, pinging a server in Shanghai with a PHP script which probably checks the page for its content or if its on some kind of blocked list. Cheeky buggers!" It's that interesting! (Note: …