Use of django at jolt online v3

Editor's Notes

• #2: This presentation will explain some techniques and highlights on the use of Django (and related stuff) on our day-to-day operations on Jolt Online.
• #3: Jolt is making browser games like Legends of Zork, Utopia Kingdoms or Playboy Manager. Our actual main programming languages are Python and Ruby. We make extensive use of Django and Ruby on Rails.
• #4: Currently there is a campaign ongoing in the US for stores. There distributing promotional codes that will give advantages for the users registering them. Each code is unique, and it's related to the store. To keep track of the distribution of codes, and to encourage the stores to distribute them, we have develop a system to show the actual performance of the stores and make some rankings. The presentation explains some techniques using in this project. The project is made in Django, of course.
• #5: Basic configuration of the production environment.
• #6: Some ways of using Django that are not the usual ones.
• #7: Django not always has to server templates or text files. It can generate CSV files using the Python standard library. StringIO is a ”fake file”. You can use it like a file and then get the information with .get_value()
• #8: Django can also return binary data, in this case, a chart generated by reportlabs
• #9: Using XML-RPC, you can allow remote function calls to Python code. The functions are accessible to any language with a XML-RPC library. On Jolt we use it to access the application mostly from Ruby code (Legends of Zork is made with Ruby on Rails).
• #10: Some useful techniques to work with the database using Django tools. Photo: http://everystockphoto.com/photo.php?imageId=1310754
• #11: You can define a fixture with the defined data to include on the database. Management command loaddata will load fixtures in the app/fixtures directory (no need for complete path) The data can also be dumped from the database: python manage.py dumpdata --format=json myapp > /path/to/myapp/fixtures/initial_data.json If the fixture is called initial_data.sjon, it will be loaed after create the database with syncdb. Initial data can be created with Django shell command and then dumped. Very useful in development!
• #12: That will allow to run the script using Django settings Also django-extensions allows the use of jobs and scheduled jobs.
• #13: You can use those stand-alone scripts to perform operations on the database not directly linked to the web application, like calculate periodically statistics or other data.
• #16: The Django ORM is really good, but it's slow for some big scale operations.
• #17: Example. Retail campaign. Generate millions promotional codes and insert on the database. Generation was really fast (just 9 random characters) Generation and insertion into database using Django ORM takes about 3 hours As we generate using a web interface, that will lead to create some actualization, progress bar, syncronization, etc to show the user the progress. That is not trivial to achieve.
• #18: Solution: Generate an SQL insert script (text file) Time to insert the codes < 3 minutes (1.5 writing file and 1.5 inserting into database) The user can wait that amount of time just with a ”This operation can take a few minutes” message. That simplifies the application. From time to time the best options it to keep using SQL
• #19: Other tools used on the deployment and use of the applications on production.
• #20: The staging server has the same environment, but is not serving to the public. Virtual Environment allow to create a controlled environment, without having to depend on the machine for the python setup. Fabric help in the deployment in an automated way git gets the proper version of the code to be deployed
• #21: Isolated environment Generate script with all the Python packages you need for your application installed through easy_install Django 1.1 or other specific version Django-debug-toolbar Django-extensions … Use source virtualenv/bin/activate to change shell or user virtualenv/bin/python interpreter
• #22: Executes remote commands using ssh Simplify a lot of maintenance operations and repetitive work. Avoids errors. The code should behave differently on a production deployment than on a development deployment (e.g, using a file only on production)
• #23: Example of the output of the execution of fabric command (simplified) We use also Capistrano (similar concept in Ruby)
• #24: It's great even for using it on a personal project, as it encourages frequents commits and branching, something that in other SCMs is difficult. The use of git is difficult and takes time to undestand its philosophy, but it's worth it
• #25: Git helps in making a lot of commits, each one with a particular step. You can search the commits and get back to any point The merging is easy (merging in SVN is risky). It is also much easier to generate new (small) branches with features and merge them into master (or trunk). Avoids the ”don't send your changes yet!” scenario. It's much complex, SVN is easier to use. Most of the difficulties (and advantages) comes from being distributed (e.g. There is no such thing as a central repository)
• #26: The current schema on Jolt to production follows roughly the one on http://nvie.com/git-model
• #27: This presentation will be available on my personal blog, www.wrongsideofmemphis.wordpress.com
• #28: Thanks for the attention! Photos from MorgueFile