- Django admin static media moved locations from `django/contrib/admin/media/` to `django/contrib/admin/static/admin/`. If you rely on this location at all, you’ll need to change it.
- Serialization changes to datetime and time. Django serializers have changed the output they return for datetimes and times to potentially include timezones, milliseconds, or a different format. If you have any sort of API that relies on the built-in JSON or XML serializers(note that Django REST framework does), you will need to take action to prevent your API users from experiencing potential issues.
- The MySQL GIS backend used to have a bug that returned 1/0 for booleans instead of True/False (our @zmsmith ) reported it!). The bug got fixed so it could mean another potential change to any APIs you expose.
- django.contrib.sitemaps bug fix with potential performance implications. Requests to sitemaps used to return cached responses by default. They no longer do. All of our sitemaps already utilized caching, but you it’s always good to double-check.
- The content type for email encodings changed from quoted-printable to 8bit encodings with this commit ). This caused some issues in our emails that we thankfully caught during testing.
- Various modules and methods moved (django.conf.urls.defaults, django.contrib.auth.models.check_password, etc). The large majority of code that was moved around can still be imported from the old location, but it’s in your interest to upgrade the import paths now so that you don’t need to worry about it when the old import path becomes deprecated in version 1.5
Pitfalls When Upgrading to Django 1.4
This post is republished from the Yipit Django Blog
The Players
The Yipit Django team just finished the process of upgrading to the 6 week old Django 1.4 and figured that we would share the process we went through and some gotchas we found.
The Set-Up
Our goal in this process was not to start utilizing new Django 1.4 features, although there are quite a few. Our goal was to get our system running and stable on Django 1.4. Over the next few weeks we’ll start utilizing some of the new features QuerySet.prefetch_related, ModelAdmin.save_related, and queryset bulk_create). This post focuses on what is needed to get running on 1.4 – even though we’re dying to use some of the new features.
The Hook
Upgrading a critical piece of your stack is something that should never be done with haste.
About a month ago, half of our developers upgraded their local setups to run 1.4 and we read through the release notes to find which areas of our codebase needed changing. (As an aside, the Django community does an excellent job with the release note and we highly recommend you looking through them).
A few weeks later, we upgraded our continuous integration and staging servers. Naturally, we wanted to run 1.4 on hardware that mimics our production environment and found a few more issues.
The Tale
Here were the issues we ran into that may apply to others:
The Wire and The Shut-Out
After doing a full walk-through on our staging systems, we made the jump on production. Naturally, a few small bugs revealed themselves once our users stressed some edge cases. With our alert and monitoring systems, we were able to fix the few bugs we found within a few minutes of our rollout song stopping.
The Sting
This was our experience upgrading to 1.4. I hope you can now avoid running into some of these issues. If you have run into your own issues, please share them in the comments below.
Steve Pulec is a Developer at Yipit.
What Software Developers Can Learn From Fish and Chips
I love a good plate of fish and chips. I also love a good chance to compare the software development field to a completely separate industry. It’s a great way to find solutions to problems that have been solved decades ago in other fields (genealogy for example) and it helps to keep me grounded in the good ’ol practical reality.
I came across a great example of this today while watching Diners, Drive-Ins and Dives with Guy Fieri. It involves the owner of a fish and chips shop (Grant) talking to Guy about how they make their Toad in the Hole. There is a clip of the sequence here. Fast forward to about 5:10. For those unable to watch, the clip goes like this:
Guy: And the gravy? Mirepoix, drippings from the sausage?
Grant: Yeah, no none of that.
Guy: None of that?
Grant: We're not looking to make that kind of gravy. What we're
looking for is a fish 'n chips shop gravy, and the best way we've
been able to replicate that, with no shame, is a powdered gravy.
Guy: Seriously?
Grant: Seriously.This dialogue jumped out at me. Guy was expecting this renowned shop to be using an industry-standard technique, but the chef had decided to do otherwise. He was using something which would certainly be considered inferior (powdered gravy) and even shameful by some, but he was doing it because he thought it gave him the best result. He ignored the fact that it was not industry-standard, that it was not the pretty solution, that it was even considered shameful. He ignored all of that because he knew it would result in a better experience for his users.
I imagined him posting his recipe to his equivalent of Hacker News and being ridiculed by all of the other chefs for using a powdered gravy.
Sometimes, we software developers get caught up trying to make perfect software and forget that what matters most is what we deliver to our users. Looking to other industries helps remind us of that.
You can follow me here on Twitter
Why You Need a Git Pre-Commit Hook and Why Most Are Wrong
This post is republished from the Yipit Django Blog
A pre-commit hook is a piece of code that runs before every commit and determines whether or not the commit should be accepted. Think of it as the gatekeeper to your codebase.
Want to ensure you didn’t accidentally leave any PDBs in your code? Pre-commit hook. Want to make sure your javascript is JSHint approved? Pre-commit hook. Want to guarantee clean, readable PEP8 -compliant code? Pre-commit hook. Want to pipe all of the comments in your codebase through Strunk & White? Please don’t.
The pre-commit hook is just an executable file that runs before every commit. If it exits with zero status, the commit is accepted. If it exits with a non-zero status, the commit is rejected. (Note: A pre-commit hook can be bypassed by passing the `—no-verify` argument.)
Along with the pre-commit hook there are numerous other git hooks that are available: post-commit, post-merge, pre-receive, and others that can be found here.
Why Most Pre-Commit Hooks are Wrong
Be wary of the above’s example as the majority of pre-commit hooks you’ll see on the web are wrong. Most test against whatever files are currently on disk, not what is in the staging
area (the files actually being committed).
We avoid this in our hook by stashing all changes that are not part of the staging area before running our checks and then popping the changes afterwards. This is very important because a file could be fine on disk while the changes that are being committed are wrong.
The code below is the pre-commit hook we use at Yipit. Our hook is simply a set of checks to be run against any files that have been modified in this commit. Each check can be configured to include/exclude particular types of files. It is designed for a Django environment, but should be adaptable to other environments with minor changes. Note that you need git 1.7.7+
To use this hook or a hook that you create yourself, simply copy the file to .git/hooks/pre-commit inside of your project and make sure that it is executable or add in to your git repo and setup a symlink.
Steve Pulec is a Developer at Yipit.
