Bastion Project Coding Plan
Component Source Code Languages: • Mobile Application
o Source will be written in Objective-‐C.
o Cocoa Libraries will also be included for app interface creation. • Web-‐server Instance
o Source written in Python.
o Selenium SDK used for rendering and taking actions on pages. o Communications and handshakes will also be managed via Python. o Some JavaScript may be required.
• Web-‐server Hypervisor
o Language dependent on what hypervisor system I decide to use. o Possible hypervisors:
Integrity Docker Vagrant
File Naming Conventions:
File names will be descriptive of their contents and contain appropriate suffixes to make them compliant with all requirements of the different languages. Spaces will not be allowed and will be replaced with a ‘-‐‘ dash. Finally, no uppercase letters will be used in the file-‐naming scheme unless required by the programming language. For example “this-‐is-‐a-‐file.txt” is a representation of the expected convention.
Coding style guide:
Coding style will be compliant to the Google style guides. Python’s style guide can be found here: http://google-‐styleguide.googlecode.com/svn/trunk/pyguide.html; the Objective-‐C guide here: http://google-‐
styleguide.googlecode.com/svn/trunk/objcguide.xml; and the JavaScript style guide here: http://google-‐styleguide.googlecode.com/svn/trunk/javascriptguide.xml .
Commit/Check-in Plan:
Effort will be made to commit after each progress point. A progress point being any point in which we have made a positive change to the project and it compiles.
All commits to the main branch of the project should be compilable and tested to some degree. Commits to side branches do not have to compile, as it is sometimes useful to have a checkpoint to come back to before trying a new approach.
However, once the changes have been successfully made, the branch will be merged back into the main before tackling the next objective to keep project flow sane and manageable.
Logging:
Logging mechanisms will be added to all parts of the product. The mobile application component will utilize the built in app logging system and will log details on errors and exceptions as well as debugging information.
Logs for the web-‐server instances will be more complicated. While it will be necessary to have good logging during development for testing and quality assurance purposes, it will also be important that while in actual deployment no logs are kept in order to ensure privacy and security concerns of the customer. Logging will occur in two modes, debug mode and quiet mode.
Hypervisor logs will be maintained as well and will be used both to monitor traffic and usage as well as to facilitate troubleshooting.
Error-handling:
Errors and bugs will be compiled into a bug-‐list added to the git repository. As errors are discovered, they will be added to the list along with details about how to replicate the situation. Errors will be removed from the list only after the issue has
been resolved and test cases have been added to ensure we don’t break anything again later.
Testing:
Unit testing will be implemented on all components to ensure that each piece runs appropriately. Additionally, automated user interactions will be run and compared against a standard to ensure actual live results. Ideally, tests will be built into the build process so that testing can occur with each recompilation.
Testing Frameworks: • Mobile application o OCUnit • Python o PyUnit (unittest) • JavaScript o BusterJS Task List:
Task Description Time Est.
Mobile
Connect to web-‐server instance
On startup, app needs to connect to the hypervisor and request a new web-‐server instance then establish secure
communications
5
Poll for new content App continuously checks for updated content on the website.
5 Display content App displays content in a relevant format
that is optimized for mobile viewing
25 Poll for new framework App continuously checks for updated
interaction frameworks
5 Overlay framework on top Once a framework is loaded, the 20
of content framework has to be integrated with the content.
Handle form elements Form elements have to be retroactively added on top of the content to receive user input. (expect this to be very difficult)
30
Listen for user actions Receive user actions and pass them off the appropriate handlers.
10 Handle user actions For each touch, swipe, navigation action,
and text input appropriate actions have to be made on the website.
20
Close connection When app shuts down, the hypervisor needs to be notified and destroy the web-‐ server instance
10
Web-‐server Instance
Receive web request Web-‐server has have a socket open and listening for a request from the app
5 Request website from the
internet
Take request and actually download page to start processing
1 Render page Render page and take a screenshot to be
used as base content
1 Parse page for interactive
elements
Find and hash by location on page all elements that can be interacted with.
40 Send framework back to
app
Send hash over a secure connection. 5 Receive user actions User actions must be translated onto the
actual webpage and so that content displayed is relevant and timely.
5
Apply actions to rendered webpage
Use Selenium or other animation framework to make actions happen on page
Hypervisor Receive connection for
new web-‐server instance
Have a socket open waiting for requests for new instances
3 Create instance Generate a new instance on the fly to be
used for a browsing session.
10 Connect instance to client Connection details have to be passed back
to client so that client knows where to connect to for actual browsing.
5
Monitor instance bandwidth and state
Log general details about instance performance and usage. Detect dropped instances and remove based on these logs.
20
Destroy instances Once session is terminated, power down and delete instance data
10
Coding Schedule:
Monday Tuesday Wednesday Thursday Friday Saturday Sunday 0 hrs 5-‐10 hrs 2 hrs 5-‐10 hrs 0 hrs 0-‐4 hrs 3+ hrs
Classes:
Not yet at a point of development where these classes are fully known.
