Django community: Community blog posts RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Automation, Fabric and Django – presentation
As a follow up post of Automated deployment with Ubuntu, Fabric and Django here are the slides from my presentation on topic “Automation, Fabric and Django”. Unfortunately there is no audio podcast but if there is interest I can add some comments about each slide as part of this post. Automation – fabric, django and more from Ilian Iliev If there is anything that need explanation feel free to ask. -
The future of moderator
The future of moderator -
The future of moderator
-
The future of moderator
-
Open graph and timeline sharing using Django Facebook
As many apps will find out today, Facebook is removing it’s offline_access permission on October 3rd. For most apps this will mean that many of your open graph shares start failing. Fashiolista has built up quite some experience with tweaking this and today we’ll be sharing some tips. The actual code we’re using has been included in the latest version of Django Facebook. 1.) Store and retry your shares There are several advantages of storing your open graph shares in the database. You get: Stats Error tracking Ability to retry individual shares Ability to retry a user’s shares if you get an updated token Ability to delete shares (since you store the Facebook object id) Especially the ability to retry shares was important to us. Django Facebook provides a convenient OpenGraphShare model to store all your shares in. Have a look at the example below: class DjangoModel: def share_to_facebook(self, graph=None): from django_facebook.models import OpenGraphShare #this is where the magic happens share = OpenGraphShare.objects.create( user_id=self.user_id, action_domain='fashiolista:love', content_type=content_type, object_id=self.id, ) share.set_share_dict(kwargs) share.save() result = share.send() Note that we store all info required for sharing to Facebook in the OpenGraphShare model. The actual Facebook API request is sent when you call share.send(). Using ... -
Nested resources in Tastypie
More elegant approach to do nested resources in Django Tastypie and make authentication work while at it. -
Planning Our First ShipIt Day at Caktus
I'm delighted to write that last Friday, we announced we'll be trying our first "ShipIt Day" at Caktus in October. ShipIt Days, also known as FedEx Days, provide a time for the team to set aside what occupies us most days—building fantastic web applications using Python and Django for our wonderful clients—and pick up something new or scratch an itch that's been bugging us for awhile. We got the idea from the book Drive by Daniel Pink, and it was also suggested independently by a number of team members. Much of the reasoning and purpose behind our decision to try out a ShipIt day can be found in the guidelines we put together describing the event. So, without further ado, here's a copy of our ShipIt Day Guidelines as of September 28, 2012. Parts of the Guidelines have been shamelessly adapted from Atlassian's ShipIt Day FAQ and Six Feet Up's post on the outcome of one of their FedEx days. We'll be posting further updates again after our first day's completion and will almost certainly evolve this policy as we go. Thanks, and let us know your thoughts! Purpose Caktus needs to innovate. We need to devote resources to research, ... -
Django transactional
When hacking django transactional projects i usually en up write a lot of views that are basically the same: present a ModelForm -> accept form data as POST -> create new entry and then another one that does basically the same with the only difference that it'll edit an old entry rather than creating a new one, if you've found your self doing this over and over again you might find this post useful.Today i published a first usable beta of a solution to this issue under BSD license: Django-transactional. It'll take all that off the table for you and create all needed stuff, i even published it on pypi for installing convenience. It still needs some love on the documentation front, but it's fairly easy to use, you only need a couple of things:Install Django-transactional:$ pip install Django-transactionalAdd urls:Add dtrans.urls to your projects urls.py file:url(r'^', include('dtrans.urls')),This will match /APP/MODEL/add/ and /APP/MODEL/add/OBJ_IDCreate your templates:Templates must be named AppName_ModelName.html, so if you want to use Foo model of Bar app create a template named bar_foo.html that uses obj_form form on it:{% csrf_token %}{{ obj_form.as_p }}With this you are ready to go. Django-transactional will create a basic ModelForm for your form and you will ... -
Virtualenv med Python2.7 på FS-Data
(This blogpost is just available in swedish, since it involves a swedish webhost) Jag har tidigare skrivit hur man får igång Django på FS-Data. För ett par månader sen så uppdaterade de sin Pythontolk till 2.7, vilket gjorde livet bra mycket roligare. Något som gör livet än mer roligare är virtualenv. Virtualenv är en virtuell miljö som du installerar dina pythonpaket i så slipper du paket som kolliderar eller, vara beroende av att paket installeras system wide. Portabiliteten blir superb genom att man bara specar ens pythonpaket i en fil (requirements.txt) som man sedan använder när man deployar ut sin kod. Virtualenv är de facto-standard i Pythonvärlden och något varje Pythonutvecklare borde lära sig. Här följer en kort guide för hur du får igång virtualenv på FS-Data. SSH:a in på ditt FS-Datakonto, du kan göra livet lättare genom att logga in utan lösenord, vilket gör automatiska deployments bra mycket smidigare. ssh konto@konto.fsdata.se Skapa en mapp där de pythonpaket du behöver installera på ditt konto ska bo. mkdir site-packages Börja med att skapa .bash_profile och ändra i lite sökvägar: echo 'export PYTHONPATH=“$HOME/site-packages/" export PATH="$PATH:$HOME/site-packages/"' > .bash_profile Installera pip och virtualenv genom easy_install easy_install --install-dir=$HOME/site-packages pip; easy_install --install-dir=$HOME/site-packages virtualenv Nu har du ... -
Running two services at once on Dotcloud
If you’re a regular of my old personal blog you know that I have tested most of the more well known Django hosting services. The reason I chose Dotcloud for this project was that it involved both Django and NodeJS, and to make it more of a mess it it as web that both is an online and an offline web (yep, HTML5 appcache). For the offline part we are actually using some CommonJS modules straight in the browser. And to protect these files and not get the application server to serve those files we needed to be able to customize the Nginx configuration. So to make all these pieces fit nicely on just one host the choice was pretty easy, Dotcloud. So how do we deploy a two (or more) service thingie in Dotcloud? It’s actually very easy. You just add one more service in your dotcloud.yml, like: www: type: python approot: cleverfoldername node: type: nodejs approot: cleverfoldername/node config: node_version: v0.6.x This will fire up two instances, one for the django service and one for the nodejs service. As you can see the root for the nodejs service is actually inside of the django service, this is because we ... -
Drafts, reviews and in-future posts with Django-dress-blog
Allow authors/reviewers see content in draft mode, review mode, or waiting to hit the publication date. The draft mode and in-future posts are must-have features in any blog application. And when the blog is the result of a team the review mode comes very handy too. Since recent changes Django-dress-blog supports the **review mode** too, so that an author can set a story in **review** to get feedback from other authors before releasing the content to the public. Along with the review mode authors can also preview unpublished content in the blog, a new menu item allows switching on and off the visualization of unpublished content. This features are already available in the live demo. Here I introduce them in short and refer to the demo to see them in action. #### Writing drafts A draft preview The simplest writing flow that works for single authored blogs consist of: 1. Writing the draft and previewing it until it looks wonderful. 2. Then set the publication time, make the status "Public", and submit. To start writing the draft you don't do anything special, just click on "Add" or "Add story", in the administrative interface of your blog. Posts are created with ... -
Drafts, reviews and in-future posts with Django-dress-blog
Allow authors/reviewers see content in draft mode, review mode, or waiting to hit the publication date. The draft mode and in-future posts are must-have features in any blog application. And when the blog is the result of a team the review mode comes very handy too. Since recent changes Django-dress-blog supports the **review mode** too, so that an author can set a story in **review** to get feedback from other authors before releasing the content to the public. Along with the review mode authors can also preview unpublished content in the blog, a new menu item allows switching on and off the visualization of unpublished content. This features are already available in the live demo. Here I introduce them in short and refer to the demo to see them in action. ##### Writing drafts A draft preview The simplest writing flow that works for single authored blogs consist of: 1. Writing the draft and previewing it until it looks wonderful. 2. Then set the publication time, make the status "Public", and submit. To start writing the draft you don't do anything special, just click on "Add" or "Add story", in the administrative interface of your blog. Posts are created with ... -
Notes on Serving Django Apps with uWSGI
Notes on serving Django apps with Nginx/uWSGI -
We need more PyCon US 2013 submissions!
The PyCon US 2013 call for papers (CFP) ends tomorrow, September 28th, 2012. We need more talk and tutorial submissions. Talks are 30 or 45 minute efforts in front of the PyCon audience and are recorded for posterity. Tutorials are three hours long and are given to attendees who have paid an additional fee in order to slurp in knowledge from the masters. On the 3 hour tutorial side of things, we especially need more Intro to Python level submission. That means getting beginners up to speed on basic Python techniques, so they can then exploit the other tutorials, conference, and sprints to their full advantage. Now onto some questions... 1. I would like to give a tutorial but it's so much work to put together 3 hours of quality content. The organizers of PyCon recognize that putting together a quality tutorial is an amazing amount of work. Which is why tutorial presenters are compensated for their effort. 2. What is the most likely length talk to be accepted? 30 minutes or 45 minutes? The vast majority of PyCon sessions are 30 minutes long, so 45 minute slots are rare and valuable commodities. So if your talk needs to be ... -
We need more PyCon US 2013 submissions!
The PyCon US 2013 call for papers (CFP) ends tomorrow, September 28th, 2012. We need more talk and tutorial submissions. Talks are 30 or 45 minute efforts in front of the PyCon audience and are recorded for posterity. Tutorials are three hours long and are given to attendees who have paid an additional fee in order to slurp in knowledge from the masters. On the 3 hour tutorial side of things, we especially need more Intro to Python level submission. That means getting beginners up to speed on basic Python techniques, so they can then exploit the other tutorials, conference, and sprints to their full advantage. Now onto some questions... 1. I would like to give a tutorial but it's so much work to put together 3 hours of quality content. The organizers of PyCon recognize that putting together a quality tutorial is an amazing amount of work. Which is why tutorial presenters are compensated for their effort. 2. What is the most likely length talk to be accepted? 30 minutes or 45 minutes? The vast majority of PyCon sessions are 30 minutes long, so 45 minute slots are rare and valuable commodities. So if your talk needs to be ... -
Contributing to Django Documentation, Part 1: Generating and Editing Documentation Locally
Contributing to Django Documentation, Part 1: Generating and Editing Documentation Locally -
DjangoCon 2012 Recap
DjangoCon 2012 Recap -
Contributing to Django Documentation, Part 2: Submitting A Patch
Contributing to Django Documentation, Part 2: Submitting A Patch -
Going Mobile with Django and jQuery
Going Mobile with Django and jQuery -
QuerySets, Q Objects, datetime, and Far Too Much Context
QuerySets, Q Objects, datetime, and Far Too Much Context -
Initial Data Using South Migrations
Usually when starting a new project with commonly used apps, you will need some default data for the database, for example, default categories. Django provides fixtures for that. A fixture is a collection of data that Django knows how to import into a database. They say: If you create a fixture named initial_data.[xml/yaml/json], that fixture will be loaded every time you run syncdb. There is one problem with this approach. It is very likely that you will need to run syncdb in the future when adding new apps (without south migrations). In such cases the modified data will be overwritten with the initial data from fixtures. But there is a solution for that problem. You need to name your fixtures differently and then import them by south migrations. If you don't use south, you should start doing that, because it is a very handy way to modify database schema and data automatically. :) So this is how you can prepare south migration with the default fixture: 1. Create a fixture from existing models. python manage.py dumpdata --format=json --indent=4 myapp.Category > /path/to/myapp/fixtures/myapp_categories.json 2. Create data migration python manage.py datamigration myapp load_default_data 3. Edit data migration class Migration(DataMigration): def forwards(self, orm): from ... -
We need more PyCon US 2013 submissions!
The PyCon US 2013 call for papers (CFP) ends tomorrow, September 28th, 2012. We need more talk and tutorial submissions. Talks are 30 or 45 minute efforts in front of the PyCon audience and are recorded for posterity. Tutorials are three hours long and are given to attendees who have paid an additional fee in order to slurp in knowledge from the masters. On the 3 hour tutorial side of things, we especially need more Intro to Python level efforts. That means getting beginners up to speed on basic Python techniques, so they can then exploit the other tutorials, conference, and sprints to their full advantage. Now onto some questions... 1. I would like to give a tutorial but it's so much work to put together 3 hours of quality content. The organizers of PyCon recognize that putting together a quality tutorial is an amazing amount of work. Which is why tutorial presenters are compensated for their effort. 2. What is the most likely length talk to be accepted? 30 minutes or 45 minutes? The vast majority of PyCon sessions are 30 minutes long, so 45 minute slots are rare and valuable commodities. So if your talk needs to be ... -
Project Mwana featured in the BBC
Caktus has had the opportunity to work on the infrastructure of RapidSMS, an application framework that allows data collection and logistics coordination using mobile phone text messages for communication. The BBC World News recently posted an article, "RapidSMS: Saving a life in 160 characters" detailing the effects of RapidSMS technology is having on HIV/AIDS treatment in the developing world. The article focuses on work being done to combat the HIV/AIDS epidemic in Malawi where there is one of the highest rates of infection in the world. The statistics are sobering. More than 11% of Malawi's adults are living with HIV and around 120,000 children are thought to have the disease. [. . .] Annually, the United Nations estimates that 25% of new infections in the country are caused by mother-to-child transmission of the virus. That means it's absolutely critical that infants in Malawi get tested for HIV as soon as possible in the weeks following birth, and if they test positive, that treatment begins immediately. One of the main programs that has dramatically transformed the landscape of reporting test results is Project Mwana. Mwana, which means “baby” or “child” in Swahili, focuses on reducing the mother-to-child infection rate by using ... -
Getting an IP Address in Django behind an Nginx Proxy
How to get the client IP address in Django when running Django behind an Nginx reverse proxy server. -
Django project file structure
As I promised in Automated deployment with Ubuntu, Fabric and Django I will use this post to explain the file structure that I use for my Django projects and what I benefit from it. So here is my project directory tree. The structure ~/workspace/<project_name>/ |-- bin |-- include |-- lib |-- local |-- src |-- .git |-- .gitignore |-- required_packages.txt |-- media |-- static |-- <project_name> | |-- <project_name> | | |-- __init__.py | | |-- settings | | | |-- __init__.py | | | |-- <environment_type>.py | | | |-- local.py | | |-- templates | | |-- urls.py | | |-- views.py | |-- manage.py | |-- wsgi.py |-- <project_name>.development.nginx.local.conf |-- <project_name>.< environment_type>.nginx.uwsgi.conf |-- <project_name>.< environment_type>.uwsgi.conf Explanation At the top I have a directory named as the project and virtual environment inside of it. The benefit from it is complete isolation of the project from the surrounding projects and python packages installed at OS level and ability to install packages without administrator permissions. It also provides an easy way to transfer the project from one system to another using a requirements file. The src folder is where I keep everything that is going to enter the version control ...
