Challenge Overview
Project Overview
VTARC currently has a requisition team that receives requests for supplies from various internal departments. They must then research available products and vendors that meet the criteria of each request. Currently this research is done primarily via Google. VTARC recently developed their own back end search engine to make this research more automated and efficient.
TopCoder is now building a front end to capture the necessary data for each request, crawl a list of urls for pages to be searched, route those pages to the back end search engine, and store and display the results.
Through TopCoder competitions we have already built the wireframes, storyboards, and html prototype as well as the architecture for the web crawling piece (with that assembly contest currently running). VTARC has already built the back end search engine and will be responsible for building the peices that filter, process, and display the results.
The purpose of this architecture competition, then, is to design a simple Python application to tie everything together.
Competition Task Overview
As noted above, the core pieces of this overall application are already being handled by VTARC resources and other TopCoder competitions. In this competition you will design a base application that captures the necessary data for each Task being researched, passes that data to the web crawler (which in turn passes its results to the back end search engine, called JKL), and then store the results where the reporting piece can filter, process, and display them.
Detailed Requirements
Login
- The system requires a basic login mechanism with a username/password
- If the user forgets their password the system can email it to them
- Users can change their password
- User can also logout
- There are two security levels, regular and admin. There are just two differences between the two:
- Admin users can access the user account administration pages
- Admin users see all Tasks, whereas regular users only see their own Tasks
Account Management
- Only accessible to Admin users
- Able to create new accounts
- Able to edit and delete existing accounts
Task Creation
- Users will initiate their product research by creating a Task
- A Task is made up of:
- Task Name - text field, required
- Task Description - text field, required
- Due Date - date field, optional
- Task Specifications (search terms) - multi-select
- Each Task Specification is labelled as required, optional, or do not include
- Min 1, no max
- Task Sources/Domains (URLs to crawl) - multi-select
- User can either type a URL or select from a list of previously used URLs
- System must store prevously used URLs
- Min 1, no max
- Broad Based Search - checkbox
- If checked, the system must run a Google search on the Task Description and then add the top 10 resulting URLs to the Task Sources/Domain list (behind the scenes, these are never displayed to the user)
- Once the Task data has been input, the user can either Save as Draft or Start Task
- Either operation persists the Task data to the database in Draft status
- Start Task also performs the following:
- If Broad Based Search is checked, perform the Google search and add those URLs to the list
- Pass all the Task data to the Web Crawler (note that the Web Crawler doesn't use all these data fields, but we want to pass it along anyways because the pieces of the system VTARC will be adding will use it)
- Sets the Task status to Work in Progress
- If a Task has not yet been started (that is, still in Draft status) it can be edited. Editing works the same as creating.
Task Management
- The application landing page will list all of the existing Tasks (if not the Admin user, then only that user's Tasks)
- The display is split up by tabs according to Task status. Those tabs are All Tasks, Work in Progress, Completed, and Draft.
- Each Task is displayed as a line item including the Task Name, Task Description, Status (as provided by the Web Crawler piece of the system), Due Date, and Report (which is just a link to the report for any task that is Complete)
- Note that the Wireframe has a detail popup when you click on the status of a Task. This is no longer in scope.
- Tasks can also be searched by Task Name, Task Description, Due Date, and/or Status.
- All columns on the main Task page or search results page are sortable
- Because the list of tasks may get very long, the display must implement paging (10 per page is fine)
Reports
- The generation and display of the reports will be implemented by VTARC. All we need here is a placeholder page (already in the prototype) and the implementation of the following features:
- There are two editable fields, Task Report For and Company Name, both optional text fields.
- Each report can be exported to csv, xls, pdf, doc, or text. VTARC will handle the formatting and output for each of these. We only need base export funcationality with the proper mime types.
- The user can select the report they wish to view in three ways:
- From the main Task page or Task search results page, click the direct report link
- Click the Reports tab, and then select from the list of existing reports (which is effectively the same thing as the Completed tab on the main Tasks page)
- When viewing a report, selecting from a dropdown of other avaiable reports (which is just a list of all Completed Tasks)
Help
- Just a static text page
Analysis
- This is out of scope. The tab in the Wireframe is just a placeholder.
Note here that the timeline and prize money is rather high for this contest because a) it's in Python, b) we don't have a formal requirements document (other than what I've described above), and c) we have a tight project timeline. The architecture here is expected to be quite simple. The one tricky part may be in figuring out how to get the statuses from the Web Crawler, as everything there is asynchronous.
If you find that anything here is not as simple as we think, please bring it up in the forums, and we will consider alternatives. Do NOT try to architect an overly complicated system here. Keep it simple.
This is a Direct-to-Assembly Architecture. We expect this can be implemented in one Assembly contest. If you feel that more than one is necessary, please bring this up in the forums.
Open Source Library
Open source Python libraries are allowed, as long as they are free to use.
TC Components
N/A, as this is Python
Technology Overview
- Python 2.7.3
- SQLite (if you find that another RDBMS would be better suited here, ask in the forum)
References
none
Documentation Provided
- Wireframes
- Web Crawler Architecture
Final Submission Guidelines
Submission Deliverables
All standard module architecture deliverables
Submission Guidelines
For each member, the final submission should be uploaded to the Online Review Tool.