Bootstrapping Django with ease OSCON 2012 www.concentricsky.com - PowerPoint PPT Presentation

Bootstrapping Django with ease OSCON 2012 www.concentricsky.com @concentricsky // biglan / wiggins / bothun Wednesday, July 18, 12

Introductions Mike Biglan Wiggins Josh Bothun CTO Architect Senior Developer @co ffi ndragger Wednesday, July 18, 12

Areas of Concentric Sky Web/Django Mobile Enterprise Wednesday, July 18, 12

(Some) Technologies We Use • Chef • Backbone.js • Jenkins • Jinja2 • AWS • Celery • Sphinx • DebugToolbar • Memcached • jQuery / jQueryUI • South • Compass / Sass • git • Mongo & MySQL Wednesday, July 18, 12

Released CSky Creations • djenesis – Easy Django Bootstrapping • breakdown - Lightweight jinja2 template prototyping server • django-cachemodel – Automatic caching for django models Wednesday, July 18, 12

CSky Creations in the Works • skycloud – Tool for AWS auto-scaling • django-skycms – CMS as a library • django-sky-visitor – Invitations, email con fi rmation, etc • django-client-admin – Flexible admin for client Wednesday, July 18, 12

CSky Teams 10 Django Team 5 Design Team STAFF 50+ 9 PM Team 3 System Admins Wednesday, July 18, 12

Team Interfacing • Each project is a mix from each team • Members might switch amongst projects • Interfaces between teams • Clean separation of hando ff s and responsibilities • Best-practices shared within teams Wednesday, July 18, 12

“Bootstrapping” • Pulling one up by one’s bootstraps • Computers do this much better than humans • Django – starting a project, new or existing Wednesday, July 18, 12

Bootstrapping with Ease Making booting (and rebooting) a django project as easy as possible • Ease is a continually moving target • Shouldn’t sacri fi ce other goals for ease (e.g. security, modularity, be PHP) Wednesday, July 18, 12

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+ servers Wednesday, July 18, 12

Problem/Solution Lifecycle 1. Problem grows 2. Many create their own solution ; some polish; some release 3. Community fl ocks to one (or a few) solutions 4. Solution(s) gets anointed and others die o ff Wednesday, July 18, 12

Goals of Easy Bootstrapping 1. More people using Django 2. More people using Django better Wednesday, July 18, 12

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... Wednesday, July 18, 12

Making Mistakes should be Hard • Checklists are great • The best checklists are invisible • To automate lists of commands, must have consistency Wednesday, July 18, 12

Consistency Makes things Easier • Ease of replication across servers • Ease of sharing • Both templates and existing projects • Easier to build upon Wednesday, July 18, 12

Consistently Standardized • Standardization: a tool to get to consistency • This can be in an organization. Or the full community • Oh yeah, and... Wednesday, July 18, 12

Standard had Better be Right Wednesday, July 18, 12

Fragmentation • Poor standards lead to fragmentation • Hard to build things on top of fragmented environments • Imagine building for single browser. Not Mosaic. Wednesday, July 18, 12

Android Fragmentation http://www.businessinsider.com/android-fragmentation-chart-from-opensignalmaps-2012-5 Wednesday, July 18, 12

Flexibility vs Standardization • Standardization can be rigid; can kill fl exibility • Especially as the target moves • E.g. contrib.auth • Flexibility allows preference, innovation • Best of both worlds is standardization with structured options of fl exibility • Django does this well Wednesday, July 18, 12

Django • Django is a set of higher-order building blocks • If blocks are too large , sacri fi ces what can be made (i.e. not fl exibile) • If blocks are too small , becomes ine ffi cient and unmanageable • If block types are wrong , not loosely coupled (i.e. non-orthogonal) Wednesday, July 18, 12

And Django has many faces... Wednesday, July 18, 12

From Hot Jazz Wednesday, July 18, 12

And Spaghetti Westerns Wednesday, July 18, 12

to ¡pink ¡ponies Wednesday, July 18, 12

Django More Popular Than Ever Wednesday, July 18, 12

Thanks Jamie!?! Wednesday, July 18, 12

SEO And don’t name your App “Unchained” Wednesday, July 18, 12

3 Stages of Project Structure Grief • Denial • Bargaining • Acceptance Wednesday, July 18, 12

Denial I’ll just take the easy way out... • Stu ff required libraries in a ‘lib’ directory • Stick django there too • Name everything MyProjectSomething Wednesday, July 18, 12

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 tangled Wednesday, July 18, 12

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 project Wednesday, July 18, 12

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 discussion Wednesday, July 18, 12

Acceptance Embrace the community • requirements.txt, version management • also solves the ‘git submodule’ problem • virtualenv is great, always use it Wednesday, July 18, 12

Acceptance No, really, use virtualenv • dependency management • concurrent project management • sand-boxing • solves the “chicken-n-egg” problem • replication Wednesday, July 18, 12

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 project Wednesday, July 18, 12

Toplevel is python code • Pros ./manage.py ./my_project/__init__.py • More pythonic; Everything ./my_project/settings.py ./my_project/urls.py is python code ./my_project/wsgi.py • It just works Django’s default template • Cons • Everything is python code • Where do non public fi les go? Wednesday, July 18, 12

Default Django Project • Where do apps go? ./manage.py ./my_project/__init__.py ./my_project/settings.py • How about ./my_project/ ./my_project/urls.py ./my_project/wsgi.py my_app/? ./my_project/my_app/__init__.py ./my_project/my_app/models.py • Name then becomes ‘my_project.my_app’ • What about reusability? • What if I want to rename my_project? Wednesday, July 18, 12

Default Django Project • Where do apps go? ./manage.py ./my_project/__init__.py ./my_project/settings.py • How about ./my_app/? ./my_project/urls.py ./my_project/wsgi.py • Better for reusability, but... ./my_app/__init__.py ./my_app/models.py • Now I have to add ./ to the PYTHON_PATH Wednesday, July 18, 12

Default Django Project • What was the name ./manage.py ./myapp1/models.py ./myapp1/urls.py again? ./myapp2/models.py • Was it ‘myapp1’ or ‘myapp2’ ./myapp2/urls.py ./myapp3/models.py that contains the main urls ./myapp3/urls.py and settings... Wednesday, July 18, 12

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 environments ./apps/mainsite/urls.py ./apps/my_app/models.py • Consistency across ./apps/my_app/urls.py projects • Cons • ??? None I guess! http://github.com/concentricsky/djenesis-template.git Wednesday, July 18, 12

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 server Wednesday, July 18, 12

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 fi rst: ./apps/ mainsite/urls.py • More important than it may seem at fi rst blush Wednesday, July 18, 12

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. Wednesday, July 18, 12