Django community: Community blog posts RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
API First
Recently, we were faced with the task of writing an API-first web application in order to support future mobile platform development. Here’s a summary of the project from the point of view of one of the developers. Agile API For the first couple of iterations, we had problems demonstrating the project progress to the customer at the end of iteration meetings. The customer on this project was extremely understanding and reasonably tech-savvy but despite that, he remained uninterested in the progress of the API and became quite concerned by the lack of UI progress. Although we were busy writing and testing the API code sitting just beneath the surface, letting the customer watch our test suite run would have achieved nothing. It was frustrating to find that, when there was nothing for the customer to click around on, we couldn’t get the level of engagement and collaboration we would typically achieve. In the end, we had to rely on the wireframes from the design process which the customer had signed off on to inform our technical decisions and, to allay the customer’s fears, we ended up throwing together some user interfaces which lacked any functionality purely to give the illusion ... -
Create a blog in minutes on App Engine with Django and Cloud Sql
Intro Django was actively supported at an early stage of the Python runtime in App Engine SDK through the notable django-nonrel framework, a fork of the original project that adds support for NoSql databases. But starting from the App Engine SDK 1.6.2, released more than two years ago, you can instead deploy Django’s official releases and take advantages from the whole stack using Google Cloud Sql. Case study We’re going to setup a minimal project using Zinnia, a blog engine built on top of Django and a fairly complex web application that leverages several components of the framework, a good benchmark for showing how easy can be deploying on App Engine. Prerequisites Setting up the Google Cloud services goes beyond the scope of this article and is well documented, as well as having a working Python environment, so the following it’s assumed: you already started a Google Cloud project a Google Cloud Sql instance is up and running and you created a database for this project you created a bucket on Google Cloud Storage to store media files you have a working installation of Python 2.7 and pip on your local machine you installed and configured the Python App Engine ... -
使用Django Extensions开源库扩展你的Django APP
Django Extensions 开源库是Django框架的扩展功能集合，包括management命令扩展, […] -
Moving from Google Code to GitHub
A few weeks back, the Evennia project made the leap from Google Code to GitHub (here). Things have been calming down so it's time to give a summary of how the process went.Firstly I want to say that I liked Google Code. It did everything expected of it with little hassle. It had a very good Issue system (better than GitHub in my opinion) and it allowed us to use Mercurial instead of Git for version control (I just happen to like Mercurial better than Git, so sue me). Now, GitHub is getting to be something of a standard these days. But whereas our users have occationaly inquired about us making the move, I've been reluctant to do so. The problem I did have with Google Code was that I got the increasing feeling that Google didn't care all that much about it. It worked decently, but it was not really going anywhere either. What finally made me change my mind though was an event just after summer last year. There was a bug in Google Code that made the links to online clones disappear. It was worse than that - creating new online clones of the main repo didn't ... -
Announcing Two Scoops of Django 1.6
It's our pleasure to announce that after months of research, writing, and review, Two Scoops of Django: Best Practices for Django 1.6 is in available. The result isn't just an update to the previous edition, it's a complete revision: Here is a short list of the changes: Updated for Django 1.6 and designed for both Python 2.7 and 3.3. Over 130 pages of new material, bringing the book to 446 pages. Expanded sections on database transactions, binary fields, security, custom admin skins, creating and maintaining third-party packages, utilities, serialization, built-in exceptions, deployment, and more. 5 new chapters with material on function-based views, consuming REST APIs in templates, deployment, identical environments, and continuous integration. 3 new appendixes on internationalization, settings alternatives, and working with Python 3. More tables! Improved explanations! Corrected spellings! Code examples available for download. Want to know the rest? Read the change list. We're offering the book in printed softcover format on it's product page. Any questions? Read the FAQ. -
Caktus Completes RapidSMS Community Coordinator Development for UNICEF
Colin Copeland, Managing Member at Caktus, has wrapped up work, supported by UNICEF, as the Community Coordinator for the open source RapidSMS project. RapidSMS is a text messaging application development library built on top of the Django web framework. It creates a SMS provider agnostic way of sending and receiving text messages. RapidSMS has been used widely in the mobile health field, in particular in areas where internet access cannot be taken for granted and cell phones are the best communication tool available. This has included projects initiated by UNICEF country offices in Ethiopia, Madagascar, Malawi, Rwanda, Uganda, Zambia, and Zimbabwe. Modeling RapidSMS on the Django Community The overall goals set forth by UNICEF for this project included improving community involvement by making RapidSMS easier to use and contribute to. Colin accomplished this by using Django's large and active community as a model. The community employs common standards to maintain consistency across developers. Using this best practice for the RapidSMS developers meant easier communication, collaboration, and work transfer. Colin shepherded six releases of the RapidSMS framework over his year long stint including 948 code commits to the repository. Colin broadened engagement in the RapidSMS community by tapping five others at ... -
Announcing Two Scoops of Django 1.6!
We (Audrey Roy and I) just released the revised, expanded, and slightly renamed second edition of our book on Django. It's called Two Scoops of Django: Best Practices for Django 1.6, and you can buy it right now in print format on our online store or Amazon.com. Two Scoops of Django: Best Practices for Django 1.6 is chock-full of even more material that will help you with your Django projects. We'll introduce you to various tips, tricks, patterns, code snippets, and techniques that we've picked up over the years. We have put thousands of hours into writing and revising its hundreds of pages of concise, example-packed text. Why Should You Purchase the Second Edition? "I read the first edition cover to cover. The second one raises the bar again. It's pedagogical, entertaining, and thoughtful." —Aymeric Augustin, Django Core Developer, Two Scoops of Django 1.6 Reviewer Why should you buy this updated version of our previous book? Well, it's more than a slight rename, it's been revised and expanded! It's Revised Significant portions of the previous material have been revised, incorporating huge amounts of feedback submitted by our readers over the past year. We listened to suggestions, clarified existing content, and ... -
Announcing Two Scoops of Django 1.6!
We (Audrey Roy and I) just released the revised, expanded, and slightly renamed second edition of our book on Django. It's called Two Scoops of Django: Best Practices for Django 1.6, and you can buy it right now in print format on our online store or Amazon.com. Two Scoops of Django: Best Practices for Django 1.6 is chock-full of even more material that will help you with your Django projects. We'll introduce you to various tips, tricks, patterns, code snippets, and techniques that we've picked up over the years. We have put thousands of hours into writing and revising its hundreds of pages of concise, example-packed text. Why Should You Purchase the Second Edition? "I read the first edition cover to cover. The second one raises the bar again. It's pedagogical, entertaining, and thoughtful." —Aymeric Augustin, Django Core Developer, Two Scoops of Django 1.6 Reviewer Why should you buy this updated version of our previous book? Well, it's more than a slight rename, it's been revised and expanded! It's Revised Significant portions of the previous material have been revised, incorporating huge amounts of feedback submitted by our readers over the past year. We listened to suggestions, clarified existing content, and ... -
Announcing Two Scoops of Django 1.6!
We (Audrey Roy and I) just released the revised, expanded, and slightly renamed second edition of our book on Django. It's called Two Scoops of Django: Best Practices for Django 1.6, and you can buy it right now in print format on our online store or Amazon.com. Two Scoops of Django: Best Practices for Django 1.6 is chock-full of even more material that will help you with your Django projects. We'll introduce you to various tips, tricks, patterns, code snippets, and techniques that we've picked up over the years. We have put thousands of hours into writing and revising its hundreds of pages of concise, example-packed text. Why Should You Purchase the Second Edition? "I read the first edition cover to cover. The second one raises the bar again. It's pedagogical, entertaining, and thoughtful." —Aymeric Augustin, Django Core Developer, Two Scoops of Django 1.6 Reviewer Why should you buy this updated version of our previous book? Well, it's more than a slight rename, it's been revised and expanded! It's Revised Significant portions of the previous material have been revised, incorporating huge amounts of feedback submitted by our readers over the past year. We listened to suggestions, clarified existing content, and ... -
WSGI, Twisted and Server Sent Events
Old-school web applications were easy to create. Big powerful frameworks like Django give you a lot of tools you can leverage. One weak point of all those WSGI framework is that they didn't integrate well with anything that broke outside the usual request-response cycle. The usual approach nowadays is to use WebSockets for real-time communication between browser clients and web servers. The usual way to do that would be to use a server capable of handling many concurrent connections, and use a message bus from the WSGI app to communicate to that service. That is a lot of moving parts. In my use case where I build a lot of intranet applications, deploying and maintaining all this infrastructure is a very big burden, so the result is usually to not even explore this kind of functionality. However, given that I deploy on Twisted, I wanted to explore what kind of cool things I could build on it. Enter SSE Server-Sent Events aren't that new - they have just been shadowed by WebSockets. They are a simple data format that is send from the server to the client via a plain HTTP connection. The Javascript API is quite simple, and it ... -
django-storages and AmazonS3
Saving files in the cloud, be it Amazon S3, Azure, or Rackspace, is very common now and almost a requirement. django-storages makes this seemless. This video shows you just how easy it is to get started.Watch Now... -
Simplifying your Django Frontend Tasks with Grunt
Grunt is a powerful task runner with an amazing assortment of plugins. It's not limited to the frontend, but there are many frontend-oriented plugins that you can take advantage of to combine and minify your static media, compile sass and less files, watch for changes during development and reload your browser automatically, and much more. In the last several years, the amount of tooling around frontend development has expanded dramatically. Frameworks, libraries, preprocessors and postprocessors, transpilers, template languages, module systems, and more! Wiring everything together has become a significant challenge, and a variety of build tools have emerged to help ease this burden. Grunt is the current leader because of its fantastic plugin community, and it contains a wide array of plugins that can be very valuable to a Django developer. Today I'm going to talk about an easy way to integrate Grunt with Django's runserver, and highlight a few plugins to handle common frontend tasks that Django developers often deal with. Installing Grunt Grunt uses Node.js, so you'll need to have that installed and configured on your system. This process will vary depending on your platform, but once it's done you'll need to install Grunt. From the documentation: $ ... -
Simplifying your Django Frontend Tasks with Grunt
Grunt is a powerful task runner with an amazing assortment of plugins. It's not limited to the frontend, but there are many frontend-oriented plugins that you can take advantage of to combine and minify your static media, compile sass and less files, watch for changes during development and reload your browser automatically, and much more. In the last several years, the amount of tooling around frontend development has expanded dramatically. Frameworks, libraries, preprocessors and postprocessors, transpilers, template languages, module systems, and more! Wiring everything together has become a significant challenge, and a variety of build tools have emerged to help ease this burden. Grunt is the current leader because of its fantastic plugin community, and it contains a wide array of plugins that can be very valuable to a Django developer. Today I'm going to talk about an easy way to integrate Grunt with Django's runserver, and highlight a few plugins to handle common frontend tasks that Django developers often deal with. Installing Grunt Grunt uses Node.js, so you'll need to have that installed and configured on your system. This process will vary depending on your platform, but once it's done you'll need to install Grunt. From the documentation: $ ... -
Looking forwards and backwards
We are almost a month into the new year, time to look forward.But first a look backwards. The year of 2013 was a year of big development projects and lots of quiet in the main repository in between. Two major updates were released during the year.The first update, the "many sessions per player" update, originated in a feature request that I thought would be easy to implement but which led to far-ranging changes (and honestly, improvements) to how Players and Sessions interconnect. It was a lot more more work than I anticipated.The second update was about moving Evennia's web server from the Portal level into the Server-level. The actual moving of the server was actually considerably easier than I thought it would be. But it turned out that a truckload of other things came along with it. Not only did the cache system have to change in order to accommodate the new webs erver, I had to also finalize the Out-of-band structure, since this made use of the cache system. And while I were at it, other fixes were done and ... the update grew and grew. When it finally merged late last year it closed plenty of issues, but it ... -
Populate Your Test Database With Mixins
While Django has support for loading fixtures in its unit testing tools, I have found that maintaining fixtures over time is nothing less than a giant pain in the butt. As your model definitions change over time, remembering to re-run manage.py dumpdata myapp >fixtures.json any time your fixtures are affected is something I guarantee you will forget to do. Not to mention the fact that your database may or may not contain records suitable for testing at any given time. Then all of your unit tests have blown up, it takes you a little bit of time to figure out why, and before you know it you are cursing and out of your flow. For a time I tried using Alex Gaynor's django-fixture-generator but that only solved the problem of creating the records you want to test, not the problem of fixtures sitting on disk that are out of sync with your model schema. After being introduced to Django class-based views' mixin-heavy style, I cooked up a technique for unit test TestCase classes to create the records they need at runtime, thus bypassing the need for fixtures. In an apps tests/__init__.py I create a PopulateDbMixin: class PopulateDbMixin(object): def populate_db(self): """Assume ... -
Populate Your Test Database With Mixins
While Django has support for loading fixtures in its unit testing tools, I have found that maintaining fixtures over time is nothing less than a giant pain in the butt. As your model definitions change over time, remembering to re-run manage.py dumpdata myapp >fixtures.json any time your fixtures are affected is something I guarantee you will forget to do. Not to mention the fact that your database may or may not contain records suitable for testing at any given time. Then all of your unit tests have blown up, it takes you a little bit of time to figure out why, and before you know it you are cursing and out of your flow. For a time I tried using Alex Gaynor's django-fixture-generator but that only solved the problem of creating the records you want to test, not the problem of fixtures sitting on disk that are out of sync with your model schema. After being introduced to Django class-based views' mixin-heavy style, I cooked up a technique for unit test TestCase classes to create the records they need at runtime, thus bypassing the need for fixtures. In an apps tests/__init__.py I create a PopulateDbMixin: class PopulateDbMixin(object): def populate_db(self): """Assume ... -
Email Validation
Email validation has always been a bit of a nightmare. On the one hand there are all of the local domain names (sometimes even a single word can be a valid email) meanwhile there is an explosion of top level domain names confusing the entire internet for no reason I've been able to work out.Anyway my problem today is that my payment processor SagePay validates emails and will decline the transaction if the email validation fails. I am using Django's EmailField to validate the addresses but unfortunately SagePay and Django have different views on what is a valid email with SagePay being more strict.In a fit of optimism I emailed SagePay support to try to find out the algorithm, after a brief exchange of mails I got to it as "RFC532n" which completely mystified me (and Google!) However on reading their documentation I got referred to RFC3696 which made more sense although it is one of the RFC's which leaves things quite open with a lot of advice rather than firm rules. So I did a bit of testing to try to reverse engineer the SagePay algorithm and it looks like it is the Django algorithm with the addition of ... -
Mercurial Mirror For Django 1.7 Branch
Today the Django project released the first alpha for Django 1.7. As such, the branch for 1.7 has been created in the git repository, and we can start mirroring it. Of course, this is still an alpha and the clone shouldn’t be used yet for prodution. The purpose is to test 1.7 early and to […] -
awesome-slugify: Human-readable URL slugs from any string (part 2)
In my previous blog post I covered using awesome-slugify to capture slugs in both ASCII and unicode. Today I'm covering the definition custom language slugify translation functions. Defining Custom Language slugify Translation Functions For those times we need ASCII representation of unicode characters, we can't always use the default unicode-to-ASCII mappings. A powerful feature of awesome-slugify is we can quickly and easily create our own translation functions. Just follow these two steps: Define a translation dictionary. Keys are the names of things you want translated, and the associated values are what the keys are translated into. Generate a translation function using slugify.main.get_slugify(). Explaining this in depth will take paragraphs of text, so I'll just demonstrate it using emoji: # -*- coding: utf-8 -*- # test_slugify_emoji.py # The way the awesome-slugify API works, you can't directly import from # the 'slugify' package. You have to import from the 'slugify.main' # module. See https://github.com/dimka665/awesome-slugify/issues/2 from slugify.main import get_slugify import pytest # Step 1: Define the translation dictionary ALT_EMOJI = { u'ʘ‿ʘ': u'smiling', u'ಠ_ಠ': u'disapproval', u'♥‿♥': u'enamored', u'♥': u'love', } # Step 2: Generate a translation function slugify_emoji = get_slugify(pretranslate=ALT_EMOJI) def test_basic_emoji(): # awesome-slugify capitalizes strings. # see https://github.com/dimka665/awesome-slugify/issues/3 assert slugify_emoji(u"ʘ‿ʘ") == u"Smiling" ... -
awesome-slugify: Human-readable URL slugs from any string (part 2)
In my previous blog post I covered using awesome-slugify to capture slugs in both ASCII and unicode. Today I'm covering the definition custom language slugify translation functions. Defining Custom Language slugify Translation Functions For those times we need ASCII representation of unicode characters, we can't always use the default unicode-to-ASCII mappings. A powerful feature of awesome-slugify is we can quickly and easily create our own translation functions. Just follow these two steps: Define a translation dictionary. Keys are the names of things you want translated, and the associated values are what the keys are translated into. Generate a translation function using slugify.main.get_slugify(). Explaining this in depth will take paragraphs of text, so I'll just demonstrate it using emoji: # -*- coding: utf-8 -*- # test_slugify_emoji.py from slugify import get_slugify import pytest # Step 1: Define the translation dictionary ALT_EMOJI = { u'ʘ‿ʘ': u'smiling', u'ಠ_ಠ': u'disapproval', u'♥‿♥': u'enamored', u'♥': u'love', } # Step 2: Generate a translation function slugify_emoji = get_slugify(pretranslate=ALT_EMOJI) def test_basic_emoji(): assert slugify_emoji(u"ʘ‿ʘ") == u"smiling" assert slugify_emoji(u"ಠ_ಠ") == u"disapproval" def test_sentence(): txt = u"I ♥ Audrey Roy Greenfeld" assert slugify_emoji(txt) == u"I-love-Audrey-Roy-Greenfeld" if __name__ == "__main__": pytest.main() More Practical Applications While writing an emoji-based translation function is fun, most ... -
awesome-slugify: Human-readable URL slugs from any string
note: The introduction mentions Django and Plone. However, this is not an article about Django or Plone. Introduction Years ago, when I was working with Plone at NASA, one thing I dreaded was when content editors would copy-and-paste from Microsoft Word into the title bar. All kinds of funny characters would appear in the title bar and URL. I would have to go into the database (ZODB) and fix things. Things didn't get better until Reed O'Brien turned on a title validator (probably in Plone.i18n). When we started using Django, one thing that made it nice was the presence of it's slugify() function and template filter. Inspired by the newspaper industry, this function it easier on both content editors and software engineers. In any case, using slugify() we completed a number of projects, with NASA Science being the only public one I worked on. As much as the slugify() function was useful, there were problems. As I discovered time and time again over the years, it didn't handle unicode. Or rather, it handled them by simply vanishing non-ASCII unicode characters. For example: >>> from django.utils.text import slugify >>> slugify(u"straße") # German for road u"strae" If you read German, you'll know ... -
awesome-slugify: Human-readable URL slugs from any string
note: The introduction mentions Django and Plone. However, this is not an article about Django or Plone. Introduction Years ago, when I was working with Plone at NASA, one thing I dreaded was when content editors would copy-and-paste from Microsoft Word into the title bar. All kinds of funny characters would appear in the title bar and URL. I would have to go into the database (ZODB) and fix things. Things didn't get better until Reed O'Brien turned on a title validator (probably in Plone.i18n). When we started using Django, one thing that made it nice was the presence of it's slugify() function and template filter. Inspired by the newspaper industry, this function it easier on both content editors and software engineers. In any case, using slugify() we completed a number of projects, with NASA Science being the only public one I worked on. As much as the slugify() function was useful, there were problems. As I discovered time and time again over the years, it didn't handle unicode. Or rather, it handled them by simply vanishing non-ASCII unicode characters. For example: >>> from django.utils.text import slugify >>> slugify(u"straße") # German for road u"strae" If you read German, you'll know ... -
Django Extensions 1.3.3
We are proud to release: Django-Extensions Version 1.3.3 This brings the usual tons of fixes and improvements Get it now: https://pypi.python.org/pypi/django-extensions/1.3.3 Changelog: Docs: Made it clearer that Django Extensions requires Django 1.4 or higher Translations: FR Updated Python3: Fix for shell_plus -
awesome-slugify: Human-readable URL slugs from any string
Years ago, when I was working with Plone at NASA, one thing I dreaded was when content editors would copy-and-paste from Microsoft Word into the title bar. All kinds of funny characters would appear in the title bar and URL. I would have to go into the database (ZODB) and fix things. Things didn't get better until Reed O'Brien turned on a title validator (probably in Plone.i18n). When we started using Django, one thing that made it nice was the presence of it's slugify() function and template filter. Inspired by the newspaper industry, this function it easier on both content editors and software engineers. In any case, using slugify() we completed a number of projects, with NASA Science being the only public one I worked on. As much as the slugify() function was useful, there were problems. As I discovered time and time again over the years, it didn't handle unicode. Or rather, it handled them by simply vanishing non-ASCII unicode characters. For example: >>> from django.utils.text import slugify >>> slugify(u"straße") # German for road u"strae" If you read German, you'll know that the default Django slugify() function is converting the word 'road' to nonsense. For sites dealing with internationalization, ... -
ViewSets and Routers - django-rest-framework part 3
ViewSets and Routers are very useful for slimming up your code and providing a lot of default functionality out of the box. They are powerful features in django-rest-framework allowing a lot of flexibility in your code while keeping things clean.Watch Now...
