Django Bootstrapping with Ease

  • 1,864 views
Uploaded on

Presented at OSCON 2012 by Concentric Sky. Has details on virtualenv, projects templates and Djenesis (pip-installable).

Presented at OSCON 2012 by Concentric Sky. Has details on virtualenv, projects templates and Djenesis (pip-installable).

More in: Technology , Design
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,864
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
16
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Bootstrapping Django with ease OSCON 2012 www.concentricsky.com @concentricsky // biglan / wiggins / bothunThursday, July 19, 12
  • 2. Introductions Mike Biglan Wiggins Josh Bothun CTO Architect Senior Developer @coffindraggerThursday, July 19, 12
  • 3. Areas of Concentric Sky Web/Django Mobile EnterpriseThursday, July 19, 12
  • 4. (Some) Technologies We Use • Chef • Backbone.js • Jenkins • Jinja2 • AWS • Celery • Sphinx • DebugToolbar • Memcached • jQuery / jQueryUI • South • Compass / Sass • git • Mongo & MySQLThursday, July 19, 12
  • 5. Released CSky Creations • djenesis – Easy Django Bootstrapping • breakdown - Lightweight jinja2 template prototyping server • django-cachemodel – Automatic caching for django modelsThursday, July 19, 12
  • 6. CSky Creations in the Works • skycloud – Tool for AWS auto-scaling • django-skycms – CMS as a library • django-sky-visitor – Invitations, email confirmation, etc • django-client-admin – Flexible admin for clientThursday, July 19, 12
  • 7. CSky Teams 10 Django Team STAFF 50+ 5 Design Team 9 PM Team 3 System AdminsThursday, July 19, 12
  • 8. Team Interfacing • Each project is a mix from each team • Members might switch amongst projects • Interfaces between teams • Clean separation of handoffs and responsibilities • Best-practices shared within teamsThursday, July 19, 12
  • 9. “Bootstrapping” • Pulling one up by one’s bootstraps • Computers do this much better than humans • Django – starting a project, new or existingThursday, July 19, 12
  • 10. Bootstrapping with Ease Making booting (and rebooting) a django project as easy as possible • Ease is a continually moving target • Shouldn’t sacrifice other goals for ease (e.g. security, modularity, be PHP)Thursday, July 19, 12
  • 11. Moving Targets Moving targets create new problems. And new solutions. • CGI – Solving static HTML • JavaScript – Solving non-interactivity • CSS – Solving 100+ HTML pages • Puppet/Chef – Solving 100+ serversThursday, July 19, 12
  • 12. Problem/Solution Lifecycle 1. Problem grows 2. Many create their own solution; some polish; some release 3. Community flocks to one (or a few) solutions 4. Solution(s) gets anointed and others die offThursday, July 19, 12
  • 13. Goals of Easy Bootstrapping 1. More people using Django 2. More people using Django betterThursday, July 19, 12
  • 14. More People Using Django • As few commands as possible to try Django out • And to try someone else’s project out. • Must be highly likely to just work • All especially critical for beginners • Django’s runserver & sqlite...great! • It just works...Thursday, July 19, 12
  • 15. Making Mistakes should be Hard • Checklists are great • The best checklists are invisible • To automate lists of commands, must have consistencyThursday, July 19, 12
  • 16. Consistency Makes things Easier • Ease of replication across servers • Ease of sharing • Both templates and existing projects • Easier to build uponThursday, July 19, 12
  • 17. Consistently Standardized • Standardization: a tool to get to consistency • This can be in an organization. Or the full community • Oh yeah, and...Thursday, July 19, 12
  • 18. Standard had Better be RightThursday, July 19, 12
  • 19. Fragmentation • Poor standards lead to fragmentation • Hard to build things on top of fragmented environments • Imagine building for single browser. Not Mosaic.Thursday, July 19, 12
  • 20. Android Fragmentation http://www.businessinsider.com/android-fragmentation-chart-from-opensignalmaps-2012-5Thursday, July 19, 12
  • 21. Flexibility vs Standardization • Standardization can be rigid; can kill flexibility • Especially as the target moves • E.g. contrib.auth • Flexibility allows preference, innovation • Best of both worlds is standardization with structured options of flexibility • Django does this wellThursday, July 19, 12
  • 22. Django • Django is a set of higher-order building blocks • If blocks are too large, sacrifices what can be made (i.e. not flexibile) • If blocks are too small, becomes inefficient and unmanageable • If block types are wrong, not loosely coupled (i.e. non-orthogonal)Thursday, July 19, 12
  • 23. 3 Stages of Project Structure Grief • Denial • Bargaining • AcceptanceThursday, July 19, 12
  • 24. Denial I’ll just take the easy way out... • Stuff required libraries in a ‘lib’ directory • Stick django there too • Name everything MyProjectSomethingThursday, July 19, 12
  • 25. Denial I’ll just take the easy way out... Why this doesn’t work • project starts to get bloated • version management becomes a headache • upgrade paths become tangledThursday, July 19, 12
  • 26. Bargaining We’ll just adopt some standard practices... 1. Have the team argue about which way to do things 2. Assign someone to write a document about it 3. ??? 4. Ignore it when you start a new projectThursday, July 19, 12
  • 27. Bargaining We’ll just adopt some standard practices... Why this doesn’t work • Projects become inconsistent • It is not in source control • No way to manage changes across projects • There is no history of changes or discussionThursday, July 19, 12
  • 28. Acceptance Embrace the community • requirements.txt, version management • also solves the ‘git submodule’ problem • virtualenv is great, always use itThursday, July 19, 12
  • 29. Acceptance No, really, use virtualenv • dependency management • concurrent project management • sand-boxing • solves the “chicken-n-egg” problem • replicationThursday, July 19, 12
  • 30. What’s in a template? • For a django project, there are two styles: 1. toplevel directory is python code 2. toplevel directory is a website projectThursday, July 19, 12
  • 31. Toplevel is python code ./manage.py ./my_project/__init__.py • Pros ./my_project/settings.py ./my_project/urls.py • More pythonic; Everything ./my_project/wsgi.py is python code Django’s default template • It just works • Cons • Everything is python code • Where do non public files go?Thursday, July 19, 12
  • 32. Default Django Project ./manage.py ./my_project/__init__.py ./my_project/settings.py • Where do apps go? ./my_project/urls.py ./my_project/wsgi.py • How about ./my_project/ ./my_project/my_app/__init__.py my_app/? ./my_project/my_app/models.py • Name then becomes ‘my_project.my_app’ • What about reusability? • What if I want to rename my_project?Thursday, July 19, 12
  • 33. Default Django Project ./manage.py ./my_project/__init__.py ./my_project/settings.py • Where do apps go? ./my_project/urls.py ./my_project/wsgi.py • How about ./my_app/? • Better for reusability, but... ./my_app/__init__.py ./my_app/models.py • Now I have to add ./ to the PYTHON_PATHThursday, July 19, 12
  • 34. Default Django Project ./manage.py ./myapp1/models.py ./myapp1/urls.py • What was the name ./myapp2/models.py again? • Was it ‘myapp1’ or ‘myapp2’ ./myapp2/urls.py ./myapp3/models.py ./myapp3/urls.py that contains the main urls and settings...Thursday, July 19, 12
  • 35. Toplevel is website project • Pros ./manage.py ./wsgi.py ./requirements.txt • Closer to real world ./apps/mainsite/__init__.py ./apps/mainsite/settings.py ./apps/mainsite/settings_local.py ./apps/mainsite/urls.py environments ./apps/my_app/models.py • Consistency across ./apps/my_app/urls.py projects • Cons • ??? None I guess! http://github.com/concentricsky/djenesis-template.gitThursday, July 19, 12
  • 36. Toplevel is website project ./manage.py ./wsgi.py ./requirements.txt ./apps/mainsite/__init__.py ./apps/mainsite/settings.py ./apps/mainsite/settings_local.py.example ./apps/mainsite/urls.py ./apps/my_app/models.py ./apps/my_app/urls.py Python code is sandboxed • only have to add ./apps to PYTHON_PATH • everything else is ignored by WSGI serverThursday, July 19, 12
  • 37. Toplevel is website project ./manage.py ./wsgi.py ./requirements.txt ./apps/mainsite/__init__.py ./apps/mainsite/settings.py ./apps/mainsite/settings_local.py.example ./apps/mainsite/urls.py ./apps/my_app/models.py ./apps/my_app/urls.py Consistent Entry Point Name • I always know where to look first: ./apps/ mainsite/urls.py • More important than it may seem at first blushThursday, July 19, 12
  • 38. Toplevel is website project ./manage.py ./wsgi.py ./requirements.txt ./apps/mainsite/__init__.py ./apps/mainsite/settings.py ./apps/mainsite/settings_local.py.example ./apps/mainsite/urls.py ./apps/my_app/models.py ./apps/my_app/urls.py settings_local • Loaded after settings.py as overrides. • Easily set up a local development environment. • Production credentials are at no risk. • Easily deploy devel, staging, production stacks.Thursday, July 19, 12
  • 39. Toplevel is website project ./manage.py ./wsgi.py ./requirements.txt ./apps/mainsite/__init__.py ./apps/mainsite/settings.py ./apps/mainsite/settings_local.py.example ./apps/mainsite/urls.py ./apps/my_app/models.py ./apps/my_app/urls.py I have requirements.txt • Library dependencies and versioning is simple. • New developers can start working quicker. • Simple virtualenv integrationThursday, July 19, 12
  • 40. Okay, but now what? 1. Install and use virtualenv 2. Design and use a templateThursday, July 19, 12
  • 41. How hard can it be?Thursday, July 19, 12
  • 42. Taking a closer look $ mkvirtualenv myproject && workon myproject OR $ virtualenv ~/myproject/env && source ~/myproject/env/ bin/activate THEN $ git clone http://github.com/my/template.git /tmp/ mytemplate $ pip install django>=1.4 $ django-admin.py startproject --template=/tmp/ mytemplate ~/myproject/code $ rm -rf /tmp/mytemplateThursday, July 19, 12
  • 43. Our approach Djenesis: our solution to the bootstrapping problemThursday, July 19, 12
  • 44. djenesis • What is it? • A tool that facilitates the process of creating new and setting up existing Django projects. • Available on github & PyPi (apache license) • github.com/concentricsky/djenesisThursday, July 19, 12
  • 45. djenesis - Benefits • Simplifies routine workflows for: • Starting a new project • Getting an existing project up and running with ease • Encourages developers to use a standard project structure and best python practices (virtualenv) • Allows external project templates • Supports git, svn, hg URLs • Supports Django 1.4 project templatesThursday, July 19, 12
  • 46. djenesis - History 1. Single zip file of a stub project 2. Script that wrapped stub 3. Decouples templates from script 4. Can use external templates, git URL 5. Now: supports Django 1.4 templatesThursday, July 19, 12
  • 47. djenesis - External Templates • Inflating a project from a git/svn/hg source means you can (and should) version control your project templates • Collaborate with your internal teams on an ideal project structureThursday, July 19, 12
  • 48. djenesis StackThursday, July 19, 12
  • 49. djenesis - Setup • Requires virtualenv • Install virtualenv through pip or easy_install • Install djenesis through pip or easy_installThursday, July 19, 12
  • 50. djenesis – New Project Before $ virtualenv ~/myproject/env $ source ~/myproject/env/bin/activate $ pip install django $ git clone github.com/my/template.git /tmp/tmpl $ django-admin.py startproject --template=/tmp/tmpl ~/ myproject/code $ rm -rf /tmp/tmpl With djenesis $ djenesis myproject git+https://github.com/my/template.git $ source ~/myproject/env/bin/activateThursday, July 19, 12
  • 51. djenesis – Existing Project Before $ virtualenv ~/myproject/env $ source ~/myproject/env/bin/activate $ git clone github.com/my/project.git ~/myproject/code $ pip install -r ~/myproject/code/requirements.txt With djenesis $ djenesis myproject -i git+https://github.com/my/project.git $ source ~/myproject/env/bin/activateThursday, July 19, 12
  • 52. djenesis - Configuration • Use a default template DJENESIS_DEFAULT_TEMPLATE=/path/to/template • Always use virtualenvwrapper (if installed) DJENESIS_VIRTUALENVWRAPPER=1 • Set these in your .bashrcThursday, July 19, 12
  • 53. djenesis – Next? 1. startapp template in project template 2. setup.py Support 3. djenesis post-create hooks for common tasks (copy local settings, syncdb, import fixtures) 4. Activate virtualenv when djenesis is calledThursday, July 19, 12
  • 54. Bootstrapping Django with ease OSCON 2012 www.concentricsky.com @concentricsky // biglan / wiggins / bothunThursday, July 19, 12