This page, updated regularly, aggregates Community blog posts
from the Django community.

The Stanford Social Innovation Review recently featured Caktus in “Text the Vote” in Suzie Boss’ “What’s Next: New Approaches to Social Change” column. It describes how our team of developers built the world’s first SMS voter registration system in Libya using RapidSMS. Article excerpt In a classic leapfrogging initiative, Libya has enabled its citizens to complete voter registration via digital messaging technology. In late 2013, soon after Vinod Kurup joined Caktus Group, an open source software firm based in Durham, N.C., he became the lead developer for a new app. The client was the government of Libya, and the purpose of the app would be to support voter registration for the 2014 national elections in that country. Bomb threats and protests in Libya made in-person registration risky. “I realized right away that this wasn’t your standard tech project,” says Kurup. As a result of that project, Libya became the first country in the world where citizens can register to vote via SMS text messaging. By the end of 2014, 1.5 million people—nearly half of all eligible voters in Libya— had taken advantage of the Caktus-designed app during two national elections. “This never would have happened in a country like the ...

Part six of six in our PyCon 2015 Must-See Series, a weekly highlight of talks our staff enjoyed at PyCon. I've had an interest in robotics since high school, but always thought it would be expensive and time consuming to actually do. Over the past few years, though, I've observed the rise of open hardware such as the Arduino and the Raspberry Pi, and modules and kits built on top of them, that make this type of project more affordable and accessible to the casual hobbyist. I was excited by Katherine's talk because Robot Operating System (ROS) seems to do for the software side what Arduino and such do for the hardware side. ROS is a framework that can be used to control a wide range of robots and hardware. It abstracts away the hard work, allowing for a publish-subscribe method of communicating with your robot's subsystems. A plus side is that you can use higher-level programming languages such as Python or Lisp, not just C and C++, and there is an active and vibrant open source community built up around it already. Katherine did multiple demonstrations with a robot arm that she'd brought to the talk, that did much ...

Unlike every other programming language I've used before, Python does not have a switch or case statement. To get around this fact, we use dictionary mapping: def numbers_to_strings(argument): switcher = { 0: &quot;zero&quot;, 1: &quot;one&quot;, 2: &quot;two&quot;, } return switcher.get(argument, &quot;nothing&quot;) This code is analogous to: function(argument){ switch(argument) { case 0: return &quot;zero&quot;; case 1: return &quot;one&quot;; case 2: return &quot;two&quot;; default: return &quot;nothing&quot;; }; }; While the Python code is often more terse than the standard method of handling cases, I could argue it is more arcane. When I first started Python it felt weird and distracting. Over time it grew on me, the use of a dictionary key being the identifier in a switch becoming more and more habitual. Dictionary Mapping for Functions In Python we can also include functions or lambdas in our dictionary mapping: def zero(): return &quot;zero&quot; def one(): return &quot;one&quot; def numbers_to_functions_to_strings(argument): switcher = { 0: zero, 1: one, 2: lambda: &quot;two&quot;, } # Get the function from switcher dictionary func = switcher.get(argument, lambda: &quot;nothing&quot;) # Execute the function return func() While the code inside zero() and one are simple, many Python programs use dictionary mappings like this to dispatch complex procedures. Dispatch Methods ...

I had the opportunity to give a webcast for O’Reilly Media during which I encountered a presenter’s nightmare: a broken demo. Worse than that it was a test failure in a presentation about testing. Is there any way to salvage such an epic failure? What Happened It was my second webcast and I chose to use the same format for both. I started with some brief introductory slides but most of the time was spent as a screen share, going through the code as well as running some commands in the terminal. Since this webcast was about testing this was mostly writing more tests and then running them. I had git branches setup for each phase of the process and for the first forty minutes this was going along great. Then it came to the grand finale. Integrate the server and client tests all together and run one last time. And it failed. I quickly abandoned the idea of attempting to live debug this error and since I was at the end away I just went into my wrap up. Completely humbled and embarrassed I tried to answer the questions from the audience as gracefully as I could while inside ...

DjangoCon Europe is special. Most conferences I attend each year are basically just that: Conferences, meet-ups of like-minded people discussing interesting stuff. But what happened this past week in Cardiff is more like a huge family gatherings but where you can talk tech with anyone 😀 The City Hall as seen from Cardiff Castle And this year the organisers tried to make this family much bigger by explicitly inviting new speakers to the event and helping them to get started. But not only speakers: There was also a whole day prior to the actual conference with workshops and talks that were free to attend hosted by Cardiff University in the same rooms as last year&rsquo;s DjangoWeekend. No registration required, to strings attached. And from what I could see, quite a few people gave Django a shot there 😊 Markus had a workshop scheduled on that day for people already familiar with Python to learn the basics of Django. According to the sign-up page he could expect around 20 attendees so he asked around if someone was willing to help out. In the end we were about half a dozen trainers helping &hellip; half a dozen students. Slight overkill there on ...

This past Saturday, Caktus developer Rebecca Conley taught a 4-hour introductory level workshop in Django hosted by PyLadies RDU. PyLadies RDU is the local chapter of an international mentorship group for women who love coding in Python. Their main focus is to empower women to become more active participants and leaders in the Python open-source community. The workshop was held in our Astro Code School space and sponsored by Windsor Circle, Astro Code School, and Caktus Group. Leslie Ray, the local organizer of PyLadies, is always looking for new opportunities “to create a supportive atmosphere for women to learn and teach Python.” With a strong interest in building projects in Django herself, Leslie thought an introductory workshop was the perfect offering for those looking to expand their knowledge in Python as well as a great platform from which Rebecca could solidify her own skills in the language. “Django is practical,” explains Rebecca, “and it’s the logical next step for those with experience in Python looking to expand their toolkit.” The event was extremely successful, with a total of thirty students in attendance. Rebecca was impressed with the students, who were “ enthusiastic and willing to work cooperatively,” which is always ...

Good news! zest.releaser supports python 3.3+ now! Now... what is zest.releaser? zest.releaser takes care of the boring release tasks for you. So: make easy, quick and neat releases of your Python packages. The boring bit? Change the version number (1.2.dev0 -&gt; 1.2 before releasing and 1.2 -&gt; 1.3.dev0 after releasing). Add a new heading in your changelog. Preferrably record the release date in the changelog, too. svn/git/bzr/hg tag your project. Perhaps upload it to pypi. Zest.releaser takes care of this for you! Look at the docs on readthedocs.org for details. The short page on our assumptions about a releasable python project might be a good starting point. Now on to the python 3.3 support. It was on our wish list for quite some time and now Richard Mitchell added it, kindly sponsored by isotoma! We got a big pull request last week and I thought it would be a good idea to try and merge it at the djangocon sprint. Reason? There are people there who can help me with python 3. Pull request 101 was the important one. So if you want to get an idea of what needs to be done on a python package that was first ...

I see three conflicting styles of log formatting in most of the code I come across. Basically: import logging logging = logging.getLogger(__name__) logger.info(&quot;%s went %s wrong&quot;, 42, 'very') logger.info(&quot;{} went {} wrong&quot;.format(42, 'very')) logger.info(&quot;%s went %s wrong&quot; % (42, 'very')) I looked at the official PEP 282 and at the official docs. With the help of someone's stackoverflow question I think I understand it now. Use the first version of the three examples. So: The actual log message with the old, well-known %s (and %d, %f, etc) string formatting indicators. As many extra arguments as you have %s-thingies in your string. Don't use the second and third example, as both of them format the string before it gets passed to the logger. So even if the log message doesn't need to be actually logged somewhere, the full string gets created. The first example only gets passed a string and some extra arguments and only turns it into a real full string for in your logfile if it actually gets logged. So if you only display WARN level and higher, your DEBUG messages don't need to be calculated. There is no easy way to use the first example with {} instead ...

He compares react.js to angular. Angular basically want to take over your whole page. Multiple apps on one page, mixed with some jquery, isn't really possible. You also have to learn a lot of terminology. It is a full stack framework. And angular 2.0 won't have a migration path from angular 1.x... React.js only does one thing and does it well: the view. It doesn't do data fetching, url routing and so. React.js is quite pythonic. You can start adding little bits at a time to your code. You cannot really do anything wrong with it. A core idea is that the html is in one corner. That's the output. And the state is in the other corner. They're strictly seperated, which makes it easier to reason about. It is build by facebook. They take page load time seriously. You can even run react.js partially on the server side (&quot;react native&quot;, inside node.js), taking down rendering time, especially on mobile. Facebook is pretty deeply invested in it, so the chances of it disappearing are low. (As opposed to angular: google is barely using it itself). When you start using react.js on a page, you'll have to start thinking about components. ...

The following is the second installment of our Loop Letters series, an interview with Tracy Osborn. Tracy is the author of Hello Web App, a book to help designers and non-programmers get up and running with Python and Django. Tracy comes from a designer background herself and offers a unique and refreshing take on programming in her writing. We asked Tracy all about getting involved with Django, recent talks she&#39;s given, any advice she has, and what she enjoys doing away from a screen. Let&#39;s get started! Your startup, Wedding Lovely, has turned into your full time job. What inspired you to get this going? What’s your favorite part about what you do each day? I have an Art degree and I&#39;ve always loved wedding invitations — they&#39;re such beautiful pieces of art. When I first decided to do a startup, I wanted to build a website to help people do the typography for their own invitations. Unfortunately, that turned into a harder problem to solve than I thought; outputting a PDF with perfect typography is no easy task! Instead, I decided to teach myself programming and start with an easier idea: building a simple directory of freelance and small ...

(One of the summaries of a talk at the 2015 Djangocon EU conference). James Bennett worked already with Django for 9 years. And especially: he's been involved with Django's security releases for 8 years now. So this talk is about a history of django and security and how django tries to protect you. And where django screwed up and what you can learn from it. Bottom line: security is hard. There are always things that can be improved, always things that could be more secure. Some history He showed the first ever django security bug. And the last one (number 49). The last one had a proper full release, the first one told you to overwrite one specific file. The first issue played down the problem a bit, the last one didn't. See the full list of all security issues. In 2007, there was still an informal security process. In 2008, django 1.0, django started autoescaping in the templates. Quite controversial with a long discussion, but it was decided it was so important that it was enabled by default. In 2010, django 1.2, modern csrf protection got added. Security by default. Better to be safe out of the box. Next ...

(One of the summaries of a talk at the 2015 Djangocon EU conference). Owen Campbell himself is the ageing coder he talks about. He picked the title because he qualified for early bird tickets because of his age :-) His experience started at age 11 with a 1kB synclair ZX81 that you could only program in z80 assembly language. Storage? Cassette tapes. In university he did assembly programming on the 8086 and 86000. And for an extra course he did Fortran, a &quot;high level language&quot; which meant submitting code to the mainframe and getting a print back that you missed a comma. Please re-submit. He showed an impressive list of programming languages he used in all those years. For his own company he needed an accounting system. He re-used an older Lotus project and re-did it in microsoft access. Later he moved it to MSSQL server and a dotnet frontend. All in all it ran well for 15 years. But he got enough of the server license costs and the microsoft development environment. That accounting system is the &quot;old code&quot; from the title. He wanted to convert it to a web app. He started out with Ruby &amp; Rails. He ...

(One of the summaries of a talk at the 2015 Djangocon EU conference). David Winterbottom says that on the one hand, views are simple: a request comes in and a response goes out. On the other hand, you have lots of freedom in views, which might lead to problems. A central principle in software architecture is separation of concerns. For instance by encapsulation: providing a clean interface and hiding information from other parts of the system. A well-known design pattern is MVC, model-view-controller. Originally used for desktop application, but also used in most web frameworks. Note that every web framework interpretes it differently. Model: business logic. Domain logic. The data, the rules. View: what the user sees. Controller: steers the whole process. The user interacts with the controller. Django talks about MTV: model, template, view. He'd say that what's the view in MVC is mostly the templates and static files. The Controller in django is then views, middleware, urls.py. What David often notices in django projects is that the views.py is too big. There's data validation in there. Some of the model layer creeps into the view. And so on. You're not encapsulating everything like you could be. Django is ...

(One of the summaries of a talk at the 2015 Djangocon EU conference). Pycon Namibia - Daniele Procida In february 2015, the python conference in Africa actually took place! In Namibia! Daniele Procida talked about the plans at many conference (like at djangocon.eu 2014). It was really good. They formed valuable relationships and learned a lot. Several of the attendees are here at the conference. They're going to organize another conference later this year. So if you want to escape a dreadful European winter... I'm new to django but why should I use it? - Ben Sharif Why should you use it? You're new, so why Django? He's in that situation. He's a medical student. He's not a doctor yet. It also means he isn't a professional programmer. He wants to quickly prototype ideas for medical web apps. He wants something that lets him develop things fast: Django fits the bill. He started learning python in may 2014. He tried the django tutorial, but that didn't really work. He got pointed at web2py. Easy to get started. Almost no configuration. Through the web development. His demo is at http://medboard.co.uk/ So... what is he missing? The django community is absolutely massive. ...

(One of the summaries of a talk at the 2015 Djangocon EU conference). Adrienne Lowe wants to share some lessons she learned while learning to code. And how to use knowledge learned in one area in another one. Another area? Cooking! She cooked a lot. Working in restaurants, private cook, training, everything. She started a blog called coding with knives. Three lessons she has for new coders: If one tutorial doesn't work for you, choose another one. Don't let it reflect on your own opinion of yourself. If you're a cook and a cookbook doesn't work for you, you simply pick another! So simply look around for a different tutorial. Reach out. Don't be afraid to ask basic questions. The person answering also learns something: being a better teacher. So you both learn! In the cooking community, you exchange recipes. You help each other with tips. The same here in the django community. It is so friendly! And most of it is open source. Great! Let your goal guide you. You'll inevitable run into problems as a beginner. Don't let that discourage you. Make sure you have a specific goal you're working to and celebrate when you reach it. Simply ...

(One of the summaries of a talk at the 2015 Djangocon EU conference). Rae Knowler talks about hypothesis. It is a property based testing library inspired by Haskell's Quickcheck. So: it took out a a bunch of good ideas and you don't need to know a lot of scary Haskell :-) The core idea is that it uses randomized data. You tell it to test your login page, for instance, with a name, an age and an email address. It then creates 1000 random names/ages/emails and feeds them to your form. It simplifies examples of failures. What that means: if it finds an error, it tries iterating on it, finding out in the end that perhaps your form doesn't handle a name with a $ in it. It remembers interesting inputs. It works with pytest, unittests, everything. It is just a library. There's django integration: https://pypi.python.org/pypi/hypothesis-django/ . Custom field types are allowed. It can generate child models. And since last sunday it supports fixtures. Rae showed a demo. With random numbers, hypothesis reliably found a DivideByZero bug. Nice! Hypothesis makes discovering this kind of bugs easy. It makes it simple to write tests without having to rigorously figure out the ...

(One of the summaries of a talk at the 2015 Djangocon EU conference). Greg Chapple works half his time on Django projects, half on Rust projects. Some things you'll probably never hear: &quot;Can't wait to fix some pep8 violations today&quot;. Style conventions probably aren't the sort of thing you take into account when picking a language or a framework. Every line of code follows some sort of style convention. Intentional or not. The style of our code can identify us. Same as with this talk: Greg speaks with a slight Dublin accent, by default. Something to ask yourself: if you look at a piece of code inside your company, could you identify the person that wrote it? Let's get back to Greg's accent and the way he speaks. How did he come by this? Where he grew up, of course. The people he's around regularly. You can change it, though. He spend two weeks in the USA and when he came back he got funny looks for some of the US pronouncement that krept into his vocabulary. The same with your code style! You're influenced by the code you're surrounded by. If you want to make changes, it takes quite ...

(One of the summaries of a talk at the 2015 Djangocon EU conference). The panel consisted of Iacopo Spalletti of Django CMS and Tom Dyson of Wagtail. For many people, a CMS is the way they get acquainted with django, so it is pretty important. Often they come from Wordpress originally. What is the main philosophy of your CMS? Django CMS tries to be just another django app. After a while, django cms grew to support multiple roles. The content manager, the front-end designer, the main editors and the other editors. The main editors set up the content structure of the site and the other editors fill it. Wagtail doesn't try to give editors as much power as django CMS (and Drupal and so) do. Often the super-powers aren't even used. It is more aimed at django programmers. It has its own UI (instead of the standard django admin). Performance is a key priority. In practice, how does the philosophy work out for you? Django CMS is build upon the flexibility of the django admin. They use it everywhere and it gives them a lot of power. The only pain point is the URLconf. They love django. They wouldn't be ...

(One of the summaries of a talk at the 2015 Djangocon EU conference). Emmanuelle Delescolle says the django community is quite welcoming and friendly. The increased effort that is being poured into diversity is great. She showed a sample django project filesystem structure. It looked like a bit of a mess. Not too standard. Then she showed the structure that has her preference, including the settings that belong to it. Well, once you're happy with such a structure, how can you use it all the time? Django now allows you to pass a template parameter to &quot;startproject&quot;. Then your template gets used instead of the standard django one: $ django-admin startproject --template your-preferred_template/ You could make one for your reusable apps you want to release as open source. Automatically include a license file, for instance. See the django docs . How does such a template look? Basically the same as a regular django project, only certain parameters get replaced. A folder project_name gets renamed in your project's name, for instance. Same for python files: you can use {{ project_name }}-like strings in there and they'll get replaced. But it is not enough. Only python files can be templated. Not other ...

(One of the summaries of a talk at the 2015 Djangocon EU conference). Paul Hallett considers himself an &quot;API fanatic&quot;. He works for lyst, a website for buying clothes. They had an existing API, json-rpc, and wanted to have a better API that fitted better with http. RPC (remote procedure call) means you only have one endpoint (=url) and everything is a POST request, even if you only request information. &quot;RPC for http is bad&quot; is what he said. He wanted to do it with django rest framework. Django is a batteries-included webframework, django rest framework is a batteries-included API framework. If you need to re-build some existing API as a rest API, think of it as a chance to rebuild. If it is an existing API, the program probably changed a bit from how it looked originally. Shouldn't you clean it up a bit? Change a couple of models? The alternatively is to shoe-horn non-fitting models into an otherwise nice API... REST focuses on Resources. In django terms, you often think &quot;a model&quot;. This isn't necessarily true, it might be either more or less. A model might actually have two separate sets of attributes that you'd rather treat as ...

(One of the summaries of a talk at the 2015 Djangocon EU conference). (Anssi Kääriäinen gave a great talk last year at &quot;django under the hood&quot; about the django ORM. Look at that one, too.) Lookups, transforms and expressions are new features in the ORM (part in 1.7, part in 1.8). They are ways to inject custom SQL in a well-structured way. Custom lookups are things like __glob that you can write yourself in addition to the build-in ones like __gte. Custom transforms? __lower, as an example. How you could do this previously was by using .extra(), you could tweak the sql this way. The new approach is more reusable. It can also be chained (somefield__lower__glob)! Another drawback of .extra() is that it quite a hacky part of the django code. The new functionality Lookups. Those are basically &quot;a condition in the query's WHERE clause&quot;. Examples in django are lt, gt, gte, contains and so. To create a custom lookup, you subclass models.Lookup. You set the lookup_name and you implement the .as_sql() method. Afterwards you register it for the various Field types for which it is valid. An example (very quickly and incompletely copied over from the presentation): &#64;models.CharField.register_lookup class ...

(One of the summaries of a talk at the 2015 Djangocon EU conference). Ludvig Wadenstein is a developer, but he also does a lot of UX (user experience) work and user testing. What is user testing? You make someone use your application and see what comes out of it. Then you fix things. Why user testing? You see if your user &quot;gets&quot; your UI. And you get a fresh look. And perhaps you discover small changes that can make a big difference. Test while you build it and test it when it is finished. Keep in mind that the earlier you test, the cheaper it is to change something. A rule of thumb is to test it once a month. Who should be your test participant? Don't focus too much on finding the perfect participant, almost everybody is OK as long as they don't have much experience with building the system. Aim for a mix of beginners and experts. There are many ways to test. Their method takes about 50 minutes. They have two rooms, one is the test chamber, the other is the observation room. In the test chamber you have the participant and a facilitator. The facilitator should ...

(One of the summaries of a talk at the 2015 Djangocon EU conference). Ana Balica talks about mixins. Mixins are ways to add extra behaviour into classes. Mixins aren't anything special in python. They are just classes. Mixins are nice for providing modularity. They should have one specific goal and they should not themselves be extended or instantiated. You could use them for instance to work around copy-pasting code around between classes. Just make a class with the otherwise copy-pasted code. How do you use it? Python's multi-inheritance. A class can have multiple parents: class Foo(SomeMixin, BaseFoo): pass In django, mixins are especially useful for class based views. As an example, let's build a mixin that checks if our users are logged in: class LoginRequiredMixin(object): def dispatch(self, request, *args, **kwargs): if not request.user.is_authenticated(): raise PermissionDenied return super(LoginRequiredMixin, self).dispatch( request, *args, **kwargs) class AboutView(LoginRequiredMixin, TemplateView): template_name = 'about.html' dispatch() is handy to keep in mind. Likewise .get_context_data(). (Note by Reinout: doing something with get_context_data is probably not needed). How do you discover what's in django's class based views? You could look at the source code of django. But looking at http://ccbv.co.uk/ is handier. There are a lot of mixins already written ...

(One of the summaries of a talk at the 2015 Djangocon EU conference). Kat Stevens is the sole web manager at her wine company. So she needs to be an octopus with many arms to do all the tasks. Django, bug fixing, sysadmin, installing, planning, etc. When she started working there she found a 7 year old .net legacy site. She had the freedom to choose whatever she wanted and she picked Django. She had not programmed python before, so she started with small prototype projects to test everything out. Python/Django Django is the favourite part of the stack for her. She loves that it is open source so that she could inspect the code to see exactly what it was doing. Custom template tags are great, for instance for doing currency conversion. The site is quite big now, so she can lose track of things somewhere. If you're the only one working on a big codebase... Another drawback of working on your own is that you don't hear a lot about nice tools. Django debug toolbar was one of the tools that she discovered pretty late, but can't work without now. Nice: she only has to merge code with ...