here: styleguide.googlecode.com/svn/trunk/javascriptguide.xml.

Transcription

1 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: styleguide.googlecode.com/svn/trunk/pyguide.html; the Objective- C guide here: styleguide.googlecode.com/svn/trunk/objcguide.xml; and the JavaScript style guide here: styleguide.googlecode.com/svn/trunk/javascriptguide.xml.

2 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

3 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 On startup, app needs to connect to the instance hypervisor and request a new web- server instance then establish secure communications Poll for new content App continuously checks for updated content on the website. Display content App displays content in a relevant format 2 that is optimized for mobile viewing Poll for new framework App continuously checks for updated interaction frameworks Overlay framework on top Once a framework is loaded, the 20

4 of content Handle form elements Listen for user actions Handle user actions Close connection Web- server Instance Receive web request Request website from the internet Render page Parse page for interactive elements Send framework back to app Receive user actions Apply actions to rendered webpage framework has to be integrated with the content. Form elements have to be retroactively added on top of the content to receive user input. (expect this to be very difficult) Receive user actions and pass them off the appropriate handlers. For each touch, swipe, navigation action, and text input appropriate actions have to be made on the website. When app shuts down, the hypervisor needs to be notified and destroy the web- server instance Web- server has have a socket open and listening for a request from the app Take request and actually download page to start processing Render page and take a screenshot to be used as base content Find and hash by location on page all elements that can be interacted with. Send hash over a secure connection. User actions must be translated onto the actual webpage and so that content displayed is relevant and timely. Use Selenium or other animation framework to make actions happen on page

5 Hypervisor Receive connection for new web- server instance Create instance Connect instance to client Monitor instance bandwidth and state Destroy instances Have a socket open waiting for requests for new instances Generate a new instance on the fly to be used for a browsing session. Connection details have to be passed back to client so that client knows where to connect to for actual browsing. Log general details about instance performance and usage. Detect dropped instances and remove based on these logs. Once session is terminated, power down and delete instance data 3 20 Coding Schedule: Monday Tuesday Wednesday Thursday Friday Saturday Sunday 0 hrs - hrs 2 hrs - hrs 0 hrs 0-4 hrs 3+ hrs Classes: Not yet at a point of development where these classes are fully known.