Web Application Development Process

This readme is to describe the project and framework development for Web Application Development

Process

1. Feature Definitions
   • Simplify the problem
   • Define in isolated, manageable, releasable chunks
   • Features that can be completed within 1-2 week time frame, no longer
2. Specifications
   • Do what is 'reasonable', not overboard
     • enough so it can not be mis-interpreted what we are building
   • models, attributes, schema
   • views, actions
   • controllers, libraries
   • Might require wireframes, maybe UML, but less, not more
   • Interfaces, front-end <-> backend, javascript, ajax, inputs/outputs
   • Dependencies, scheduling (developers, designers, testing, releases)
3. Branches
   • Developer branches
     • develop a project, branching for each developer
     • process, technology support
   • Release Branches
   • build/teardowm scripts
4. Testing
   • develop a project, appropriate depth and breadth unit testing (up to project lead discretion) for library and view functions
   • Functional: Unit
     • Attempt to use Django Test, might not be able depending on SQL Alchemy integration
5. Releases
   • Tags (Git)
   • define weekly deliverables and releases
   • code releases: Alpha, Beta1, Beta2, rc1, 1.0

Technology

Git

• demonstrate how we can and do use Git
• Concepts
  • Distributed VCS
  • Branches: client and server branches
  • Tags
• Documentation and Cheatsheets
  • http://delicious.com/chad.lindstrom/git

Python

• demonstrate a project written in Python
• Why Python?
  • Faster
  • good library support
  • better testing support
  • less forgiving, more structure
  • compiled

• How Python
  • Books
    • Python Cookbook
    • Dive into Python
  • Online Tutorials
  • Team Collaboration
    • Jesse, Ryan and Chad will develop into resident Python experts
    • http://delicious.com/chad.lindstrom/python

Django

• demonstrate a Django project
  • using SQL Alchemy
• What is Django
• Documentation
  • http://delicious.com/chad.lindstrom/django

• Build something in Django
  • Tutorials
    • http://nettuts.com/tutorials/other/intro-to-django-building-a-to-do-list/

Memcache

• what is memcache used for
• requirements for memcache
• benefits of memcache
• how many instances of memcache
• dedicated memcache hardware, shared on servers

Concepts

Sharding

• Demonstrate how sharding works
• organized by Master Database(s) and Shard Databases
• Setup of Sharding, policies for sharding
• How to reshard

Distributed File System

• multiple clients (Ryan and Chad's systems)
• may not be appropriate for alpha releases

Caching

• what to cache, how long, cache priority

Sessions

• using memcache
• using shared sessions

Policies

Sharding

• Shard data that grows and becomes expensive to serve
• finite data that is cached more often does not need to be sharded as much
• Shards should be defined in the database, not coupled with the code. Creating a new shard is entirely managed in the database
• Business Logic should not know anything about sharding, it should be the data/model layer that manages this

Sorting

• common operations that require sorting, should be sorted least amount of times
  • ie. sort on insert, rather than sort on output (if output happens often and input not as often)
  • sort offline, store in replicated database or memory

Caching

• finite data is cached as much as possible (system defined types)
  • expensive operations are caches as much as possible

Naming

• Names should use underscores to delimit concepts and actions/descriptors
  • ie. zookeeper_id, firstname, favourite_animal_id is good
  • ie. zoo_keeper_id, first_name, favouriteanimal_id is not good
• Objects, functions and variables that contain or return multiples, should be named plural
• Objects, functions and variables that contain single values, should be named singular
• Objects, functions and variables that return boolean results should be named appropriately, so as to ask/answer
  • ie. user.is_active == true|false ... instead of user.active
• Functions
  • should be developed such that they perform a single action, which can be tested with a unit test
  • ie: user.activate() is good
  • ie: user.save_and_activate() is not as good

Conclusion

We've noticed some benefits to this process:

• clear objectives
  • identified and defined up front, what functional and data requirements we have
    • policy, models, views, libraries
  • defined early on what our goals are
    • demonstrate concepts and policy
• motivation
  • process can have a positive effect, feeling and believing in a controlled and defined plan