Django

Last week everyone at Caktus stepped away from client work for a day and a half to focus on learning and experimenting. This was our fourth ShipIt day at Caktus, our first being almost exactly a year ago. Each time we all learn a ton, not only by diving head first into something new, but also by hearing the experiences of everyone else on the team.

We are always looking for ways to make our tests run faster. That means writing tests which don't preform I/O (DB reads/writes, disk reads/writes) when possible. Django has a collection of TestCase subclasses for different use cases. The common TestCase handles the fixture loading and the creation the of TestClient. It uses the database transactions to ensure that the database state is reset for every test. That is it wraps each test in a transaction and rolls it back once the test is over. Any transaction management inside the test becomes a no-op. Since [TestCase]{.title-ref}[ overrides the transaction facilities, if you need to test the transactional behavior of a piece of code you can instead use ]{.title-ref}[TransactionTestCase]{.title-ref}[. ]{.title-ref}[TransactionTestCase]{.title-ref}` resets the database after the test runs by truncating all tables which is much slower than rolling back the transaction particularly if you have a large number of tables.

Django's logging configuration facilities, which arrived in version 1.3, have greatly eased (and standardized) the process of configuring logging for Django projects. When building complex and interactive web applications at Caktus, we've found that detailed (and properly configured!) logs are key to successful and efficient debugging. Another step in that process — which can be particularly useful in environments where you have multiple web servers — is setting up a centralized logging server to receive all your logs and make them available through an easily accessible web interface. There are a number useful tools to do this, but one we've found that works quite well is Graylog2. Installing and configuring Graylog2 is outside the scope of this post, but there are plenty of tutorials on how to do so accessible through your search engine of choice.

Caktus is happy to be involved in this year’s DjangoCon hosted in Chicago.  We are pumped about the great lineup of speakers and can’t wait to see some of our old friends as well as meet some new folks. Beyond going to see the wonderful talks, Caktus is participating as a sponsor and Tobias McNulty will be speaking on scaling Django web apps. Come stop by our booth or see Tobias’ talk to connect with us.

Back in March, at PyCon 2013, the PSF provided each attendee with a Raspberry Pi, a tiny credit-card sized computer meant to be paired with the Python programming language. The power and portability of the Raspberry Pi has stimulated an explosion of interest among hobbyists and educators. Their uses seem to be limited only by our collective imagination.

UPDATE: Read a newer blog post on this topic.

The new custom user model configuration that arrived in Django makes it relatively straightforward to swap in your own model for the Django user model. In most cases, Django's built-in User model works just fine, but there are times when certain limitations (such as the length of the email field) require a custom user model to be installed. If you're starting out with a custom user model, setup and configuration are relatively straightforward, but if you need to migrate an existing legacy project (e.g., one that started out in Django 1.4 or earlier), there are a few gotchas that you might run into. We did this recently for one of our larger, long-term client projects at Caktus, and here's an outline of how we'd recommend tackling this issue:

When testing a Django application you often need to populate the test database with some sample data. The standard Django TestCase has support for fixture loading but there are a number of problems with using fixtures:

Do your mornings usually consist of reading design blogs and drinking coffee? Are you obsessive about fonts? Are you constantly seeking out new inspiration to make your designs better? As a Front-End Developer + Designer at Caktus, you’ll be able to put your passion for design and development to work by creating beautiful designs for complex websites. You will work closely with clients to bring their visions to life and help lead the branding and design process. Our designers take ownership of the user experience and design process from the beginning and collaborate with our development team to implement the vision. You should be passionate about the open source community and the philosophy behind it. If you’re interested in becoming part of and contributing to a creative, dynamic team, here’s an idea of what you’ll do:

[Caktus is proud to be a part of the launch of the]{style=“color:#000000; background-color:transparent; font-style:normal;”} PyCon 2014 in Montreal[ website. We were delighted to be selected as this year’s partner for software development and brand updates. In the past, we've enjoyed working with the ]{style=“color:#000000; background-color:transparent; font-style:normal;”}Python Software Foundation[ as a collaborator for the ]{style=“color:#000000; background-color:transparent; font-style:normal;”}Raspberry.io[ branding and development and are excited to help out with the PyCon website.]{style=“color:#000000; background-color:transparent; font-style:normal;”}

If you’ve ever written a test for a view or model with associated uploaded files you might have noticed a small problem with those files hanging around after the tests are complete. Since version 1.3, Django won’t delete the files associated with your model instances when they are deleted. Some work-arounds for this issue involve writing a custom delete for your model or using a post_delete signal handler. But even with those in place the files would not be deleted during tests because the model instances are not explicitly deleted at the end of the test case. Instead, Django simply rolls back the transaction and the delete method is never called nor are the signals fired. This can be quite an annoyance when running the tests repeatedly and watching your MEDIA_ROOT (or worse your S3 bucket) fill up with garbage data. More than annoyance, this introduces something you always want to avoid in unittests: global state.