Spring 2017 Schedule of Topics
Jump to week[n] ==> 1, 2, 3, 4, 5, 6, 7, 8, 9, 11, 12, 13, 14, 15, 16
Method Resolution Order (MRO) def. the order in which methods are overridden. See: Python C3
MRO for CreateView
: Follow along at the CreateView class inspector
… from urls
as_view()
dispatch()
get()
orpost()
get_context_data()
get_form()
get_form_class()
get_form_kwargs()
get_initial()
get_prefix()
render_to_response()
polymorphism
, generics
, inheritance
, composition
, override
, overload
-\w+ (matches one or more alphanumerics including the dash)
\d+ (matches one or more digits)
querysets
, template variables
, urls
, forms
TemplateView
, ListView
, DetailView
, CreateView
, UpdateView
Determine functionality needed - think - “page”
Create the view using one of the class based views noted above.
Create html (template) for page then assign file name to view.
Devise url pattern then point it to view.
Test your url.
Rinse and repeat.
A small mobile application that helps users create, read, update, and delete shopping lists. The application keeps track of a collection of items and their respective cost. A user assembles a shopping list by selecting items from the item collection. The application should display the items in a shopping list as well as the total cost of all its items. Users should be able to save shopping lists for reuse with the ability to slighty modify its items. Items can be created, read, updated and deleted from the item collection.
FUNCTIONAL REQUIREMENTS (what the program should do?)
USABILITY REQUIREMENTS (what the program should look like?)
RELIABILITY REQUIREMENTS (how reliable the system should be?)
PERFORMANCE REQUIREMENTS (how efficient should the system be?)
SUPPORTABILITY REQUIREMENTS (how easy should the system be to support?)
DESIGN REQUIREMENTS (design constraints?)
IMPLEMENTATION REQUIREMENTS (constraints on the way the software is built)
INTERFACE REQUIREMENTS (interfaces with other systems?)
PHYSICAL REQUIREMENTS (hardware requirements?)
INTERFACES: External: Cloud storage services; User: iOS
ARCHITECTURE: Monolithic (w/classes), Component-Based, Event-Driven UI, SOA (cloud storage sync)
DATABASE: barebones : SQLite
CLASSES
item
shopping_list
user
USE CASES SKETCH
ACTIVITY DIAGRAM SKETCH EXAMPLE creating a shopping list
Midterm Exam Thursday 11 - 12:15
For this case study, each person listed under their respective assigned projects below will gather together and devise a list of requirements for the project. The project manager/grad student will lead these discussions. Once requirements are agreed upon, the PM will post these requirements to the requirements document on their respective GitHub repository site (the “wiki”). We will review these requirements as a class.
Project Manager: LG
Project Team: MA, TH, NN, AM
Project Manager: RV
Project Team: FS, HC, JI
Project Manager: SG
Project Team: JM, MR, SE, NH
TITLE:
OVERVIEW/DESCRIPTION
BUSINESS REQUIREMENTS
USER REQUIREMENTS
FUNCTIONAL REQUIREMENTS
NONFUNCTIONAL REQUIREMENTS
IMPLEMENTATION REQUIREMENTS
USE CASES:
TITLE:
OVERVIEW/DESCRIPTION
FUNCTIONAL REQUIREMENTS (what the program should do?)
USABILITY REQUIREMENTS (what the program should look like?)
RELIABILITY REQUIREMENTS (how reliable the system should be?)
PERFORMANCE REQUIREMENTS (how efficient should the system be?)
SUPPORTABILITY REQUIREMENTS (how easy should the system be to support?)
DESIGN REQUIREMENTS (design constraints?)
IMPLEMENTATION REQUIREMENTS (contraints on the way the software is built)
INTERFACE REQUIREMENTS (interfaces with other systems?)
PHYSICAL REQUIREMENTS (hardware requirements?)
USE CASES:
issues
with GitHubpyramid
basic intropyramid
== NOT starting from scratch == Pyramid Cookiecutter Tutorialtemplates/mytemplate.jinja2
). Test in a browser.NOTE: you may encounter not found errors during the testing phase below. Study these and run the appropriate
pip install
commands to get them fixed.
test.py
to test the value of your nickname variable. See function: test_my_view(request).
Run pytest py.test
from the project root folder.import random
def get_random_nickname():
adjvs = ['golden', 'ruby', 'fuzzy', 'liquid', 'sour', 'snowy', 'blazing']
nouns = ['shores', 'keys', 'peaks', 'smiles', 'jungles', 'skies', 'forests']
return random.choice(adjvs) + ' ' + random.choice(nouns)
fork
and git branch
unit testing : unittest, pytest, doctest
unittest
module
test_mystuff.py
python test_mystuff.py
pytest
module
pip install pytest
sample.py
test_sample.py
(prepending with test allows pytest to find your test cases!)py.test
# sample.py
# Using unit tests included in docstrings
# See test_sample.py for unit tests that utilize pytest
def pow_of_two(x):
"""Return x to the power of 2.
>>> pow_of_two(2)
4
>>> pow_of_two(-2)
4
"""
return x**2
def float_div_by_two(x):
"""Return x divided by 2 in floating point precision.
>>> float_div_by_two(49)
24.5
>>> float_div_by_two(48)
24.0
"""
return x / 2.0
if __name__ == '__main__':
import doctest
doctest.testmod()
# test_sample.py
# Demonstrates unit testing using the pytest module.
# pytest must be installed through pip.
from sample import pow_of_two, float_div_by_two
def test_pow_of_two():
assert pow_of_two(3) == 9
def test_float_div_by_two():
assert float_div_by_two(5) == 2.5
documentation (developer/user): pydoc
software dev skill: pydoc
module
sample.py
pydoc -w ./sample.py
to generate a documentation page in html. Should be sample.html
developed by Philip Johnson, University of Hawaii
While Open Source licensing creates a legal mechanism for developers to collaboratively develop software source code and distribute it, there are many software projects that fail to function as an open source project—in other words, they fail to attract users, and they fail to attract developers.
The three Prime Directives for Open Source Software Engineering provide a simple means to assess whether or not a software project has the potential to successfully function in the open source community. Satisfying the three prime directives does not guarantee that an open source community will grow up around the project, but failure to satisfy them will make it significantly more difficult for such a community to emerge.
1. THE SYSTEM SUCCESSFULLY ACCOMPLISHES A USEFUL TASK.
The system does not have to include every bell and whistle to accomplish a useful task. Indeed, the art of incremental development is to determine the smallest useful increment of functionality and implement that first. In most cases, careful thought, ample user interaction, and efficient design and implementation can lead to a first public release with some useful functionality within weeks after project inception. A system developer cannot verify that the system achieves PD #1. Only an external user can.
2. AN EXTERNAL USER CAN SUCCESSFULLY INSTALL AND USE THE SYSTEM.
The system must include sufficient user-level documentation to support download, installation, and use of the system without significant interaction with a system developer. Typically, but not always, the system must also be distributed in an executable form so that external users do not have to compile the system themselves. A system developer cannot verify that the system achieves PD #2. Only an external user can.
3. AN EXTERNAL DEVELOPER CAN SUCCESSFULLY UNDERSTAND AND ENHANCE THE SYSTEM.
The system must include developer-level documentation providing insights into the design and development of the system that enable an external developer to understand and enhance it.
In pairs, choose a team leader and a team member.
Team leader creates a gitub project containing a single file with the code listed below.
Team leader pushes the file from [2] as first commit to github. Team leader adds team member as collaborator and shares the github link to the project in [2] with team member.
Team member clones the project in [2] and begins work on the indicated function.
Team leader begins work on the indicated function.
Leader and member write, test, and debug their respective code. When their portion is complete, they commit and push their changes to github.
Each member should then pull changes to THEIR working copy to see the “merge” of each respective code segment.
# git-exercise-01.py
# TEAM LEADER:
# implement this function so that it returns copy of string_arg reversed
def reverseWord(string_arg):
pass
# TEAM MEMBER:
# implement this function so that it returns the frequency of query in string_arg
def countFreq(string_arg, query):
pass
def main():
data = 'guidorossumwashere'
print 'REVERSED ==>', reverseWord(data)
print 'FREQUENCY OF s IN', data, '==>', countFreq(data, 's')
if __name__ == "__main__":
main()