Matt Makai
{'name': 'Matt Makai',
'occupation': 'Full stack developer',
'specialties': ['Python',
{'Django': 'since 0.96'},
'data visualization',
'prototypes',
'oh crap! moments'],
'normal_location': 'Washington, DC',
}
Coding Across America?
- Road tripping 30 cities in 5 months
- Talk with devs from all city types
- Write about problems being solved with
software
- Connect people in different locations
March 9 - August 9
Meeting startups
Coding
Getting out of the building
Miles driven
Taking Over Existing Django Codebases
Where's this talk coming from?
- Several recent client engagements
- Fixes and enhancements estimation are hard
- Trial and error
- Where do you start?
Why should you care?
- Evaluate potential client engagement
- Jump into established project
- Improve your existing codebase
Approach
- Codebase
- Deployment
- Services
- Resources
Approach
- Codebase
- Deployment
- Services
- Resources
Determine
- Obtain code
- README
- Project structure
- Dependencies
- Settings.py configuration
- Data
- Tests
Example project
Obtaining the code
It is in version control, right?
Clone repo
git clone git@github.com:makaimc/pd.git
README
- Purpose, goals
- Important links - wiki, prod, staging sites
- Getting started (Vagrant, virtualenv)
- Special instructions (Solr, db replication)
- Deployment
Project structure
cd pd; ls -ltra
Project structure: 1.3-
project_root
|- settings.py
|- urls.py
|- wsgi.py
|- manage.py
|- requirements.txt
|- app1/
|- app2/
|- app3/
Project structure: 1.4+
project_root
|- project_name/
|- settings.py
|- urls.py
|- wsgi.py
|- manage.py
|- requirements.txt
|- app1/
|- app2/
|- app3/
Project structure: custom
project_root
|- settings.py
|- urls.py
|- wsgi.py
|- manage.py (modified)
|- env/
|- requirements.txt
|- apps/
|- app1/
|- app2/
|- app3/
Dependencies
That's what we want to see
Settings configuration
- settings.py
- manage.py mangling?
- local_settings.py.template
- environment variables
Environment variables
Local env variable setting
Let's get up and running
- manage.py
- syncdb / migrate
- test
- runserver
Data
- data generation scripts (.py?)
- fixtures (.json)
- database dump (.sql)
- production database replication scripts
grep -r fixtures.json *.py
find . -name '*.json'
Tests
- No tests
- Simple tests
- Multiple test suites
- Custom test runners
- Coverage reports and test checks
One tests file
project_root
|- app1/
|- tests.py
|- fixtures/fixture.json
more tests.py
No wonder the tests passed...
Multiple tests files in subdirectory
project_root
|- app1/
|- tests/
|- frontend-tests.py
|- backend-tests.py
|- smoke-tests.py
|- mocked-tests.py
|- fixtures/fixture.json
Test runner
- Standard Django test runner
- django-nose
- django-jenkins
- Custom test runner
Testing philosophy
- Get tests running
- Add coverage.py, if necessary
- Figure out code coverage
- Add tests while exploring code
- Review increased coverage w/client or team
Review
- Obtain code
- README
- Project structure
- Dependencies
- Settings.py configuration
- Data
- Tests
Scripts
- shell scripts
- Fabric
- Capistrano
- Ansible
Documentation
- Sphinx documentation
- IP addresses
- Usernames, passwords
- Purposes of various users
- Authentication schemes
Testing access
- SSH
- virtualenv
- manage.py shell
Services questions to ask
- What services are used?
- How are the services tested locally?
- Who controls the user names and passwords?
- Do the services cover full range of purposes? (debugging, user engagement, payments, etc)
