DJANGO TOOLSETS: WHAT ARE THEY BUYING YOU, WHAT ARE THEY COSTING YOU?
Thursday 12:15 p.m.--1 p.m.
Audience level: Experienced
DESCRIPTION Django makes some things extremely easy. That doesn't make them right for you, your application or your business. In this talk we'll explore some things HireVue does with Django, what fits our business, what doesn't, and how you can learn from our mistakes.
ABSTRACT HireVue's business is about digital interviewing. That means large organizations with sensitive data and high availability demands. In this presentation we'll discuss our experience using Django, TastyPie, and South to convert our legacy PHP application into the brave new world of Python. We'll discuss why we chose these tools and what we expected to get out of them, how things when awry for us and how we recovered from it. We'll also cover what decisions have allowed us to continue to meet our obligations while using Django. Some topics include:
- Class methods on models and template tags to simplify queries - how that led to thousands of queries per page
- Django granular permissions - how we twisted Django signals into an extensive mandatory permissions system that strangled our development
- TastyPie - how we wrote an API really quickly that led us to shave a small herd of yaks and didn't really meet our business needs
- South - how south made us not think about migrations any more. Until we started taking down our production website with them.
- Django admin - how it allowed us to avoid any work to create real internal tools and instead do work trying to train support personnel as engineers. Badly.
- Django test runner - how we started writing unit tests. Lots of them. Enough that we had to ditch it to be able to effectively debug test failures
While our experience with these tools does not indicate that they are bad or unworkable it does provide insight in to how you can choose to use these, or other tools, depending on your business needs. We have learned to constantly improve our toolset by evaluating what helps us, what hinders us, what our tools buy us and what they cost us. From our painful beginnings we've switched to
- Separating our platform from our view logic to control query count and separate concerns
- Simplify our permissions system to consolidate business logic and reduce database queries
- Separate out our API logic to use common code and provide services that make sense for our business and are entirely separate from our persistence layer
- Use south coupled with careful process to avoid downtime when running migrations and allow developers to coordinate schema modifications
- Stop using django admin and build real internal tools
- Switch to py.test for our test runner