Your final project is to build an online Textbook Exchange site, customized for ICS students.
TextBookMania performs “disintermediation” by removing the bookstore as a middleman between ICS students wishing to sell textbooks and other ICS students wishing to buy textbooks.
Specifically, students can go to the site and create a profile for themselves. Then, they can create BuyOffers or SellOffers for any required or optional textbook in an ICS class for the current or upcoming semester. The system will generate and display “matches” (i.e. if you make a BuyOffer, the system will show all “SellOffers” that match. If you make a SellOffer, the system will show all BuyOffers that match.)
There is also an “admin” role. Admins are responsible for defining the required and optional textbooks in the system, and also enforcing standards of behavior. They can “ban” a user from the site for inappropriate behavior.
You will work in teams on this project. See the first experience for the teams. There will be Milestone Reviews on November 19, December 3, and December 10. At each milestone, you will present a deployed version of your system and report on your software engineering process.
TextBookMania will be worth (at least) 1000 points.
Users must authenticate using UH CAS authentication. See the meteor-example-uh-cas system for example code. You will only need to authenticate against the UH test CAS server for this project.
A student consists of an ICS student’s first and last name and an email address where they can be contacted. Email addresses must be unique, but there can be more than one student with the same name.
Each student indicates how they want to be contacted in the case of new matches. There are two required options:
Each student can also provide a URL to a picture of themselves, which must be square. This will be used to create thumbnail images (100px by 100px), using the Bootstrap “rounded image” CSS class.
The system will use UH CAS authentication. Any user with a UH account can login to this system, and will be regarded as a “student” for the purposes of the TextBookExchange.
Through a private settings file, certain UH accounts can be designated to be “admin”. Admins have access to special pages within the system where they can do specialized tasks, including:
You will implement roles using the alanning:meteor-roles package.
A textbook represents a text used in an ICS course. A textbook has a title (which must be unique), author, and an ISBN number (which is also unique).
The system must be able to generate a URL to an image of the textbook given its ISBN. See Abusing Amazon Images for an article on how to do that. Here is a working URL for retrieving a sample book’s front cover from Amazon.
A textbook also has a “condition”. The condition must be one of: excellent, good, fair, poor.
The system must allow creation, updating, and deleting of textbooks by admins. You must have a page containing a table of textbooks showing all the data associated with them, along with links providing the ability to edit or delete them. The table should show a thumbnail image of the book cover based upon the URL. You must ensure that the system does not allow creation of new Textbooks with the same name or ISBN as a currently existing Textbook.
If Amazon does not have an image for the textbook, the system must allow the user to enter a URL to an image manually.
You must initialize the system with the 20 ICS textbooks listed here. Note that you may need to alter certain ISBN numbers to get the image retrieved, but the listed ISBN number should be enough for you to find the textbook by googling.
A BuyOffer represents an offer by a Student to buy a Textbook at a given price (an integer representing whole dollars). For example, “5” represents $5.00. The system does not allow BuyOffers in partial dollar amounts, such as $5.50.
BuyOffers also have an expiration date and time. For example, “October 30, 2013, 1:30pm”. Once that date and time have passed, the BuyOffer will no longer show up in the list of Matches. (The BuyOffer will still show up in the user’s table of BuyOffers so that it can be supplied with a new expiration date if desired.)
The system must allow creation, updating, and deleting of BuyOffers. You must have a page containing a table of BuyOffers, along with links providing the ability to edit or delete them.
A user cannot have both a BuyOffer and a SellOffer for the same book.
SellOffers are exactly like BuyOffers, but instead of representing the desire by a student to buy a book at a specified price, they represent the desire by a student to sell a book they own at a specified price.
The system must provide a representation of “Matches”, which enable buyers and sellers of the same Textbook to find each other.
For each BuyOffer defined by the student, the system will display all matching SellOffers. Conversely, for each SellOffer defined by the student, the system will display all matching BuyOffers.
A student who wants to sell a book can click an “Accept Offer” button. This results in the system indicating to the chosen Buyer that the Seller wants to make a deal.
The system should provide online Help that documents how to use the system.
The system should be initialized with at least three BuyOffers and three SellOffers from the developers of the system (who can also be granted Admin access). This simplifies demonstrations of the system.
The following capabilities are not required as part of the core functionality of the system.
Enhance the notification system to support SMS texting. In this case, the user can specify in their profile section that they want to be notified of new matches via text message. You can implement text messaging by signing up for the free tier at Twilio and using the meteor-twilio package.
Enhance admin mode to allow banning users who have behaved inappropriately. Banning a user means: (a) all of their Buy and Sell offers are deleted, and (b) they can no longer log in to the system.
Enhance the user profile page to allow users to upload an image to be used as their profile image. You will need to use a package like FilePicker because the uploaded file cannot be stored at meteor.com. See this example for an approach.
Enhance the system with a logging service so you keep track of all the interactions on the system. You should log the creation and modification of all BuyOffers and SellOffers and all acceptances. Here’s an example of using Loggly with Meteor.
Enhance the system to support online chat when a match occurs. After a seller has accepted a match, the system will provide a chat window area for that match. Any text either student types into that window will be visible by the other student when they login.
Integrate your application with Slack. This means creating a Slack integration so that teams can receive notifications of events occuring within your app. See the Slack API getting started page for ideas on how to proceed.
All your code must be hosted in GitHub. You should follow our coding standards.
You should follow the philosophy of “commit early and often”. I will be evaluating your team in part by the representation of development shown in the commit history.
Your commit messages must be informative and useful. I will be reading them to better understand how you developed the system.
Consider the following hypothetical situation where two teams both implement everything but the “expiration date” functionality. Team A starts work on the system Friday evening and makes several commits, then makes significant progress on Saturday with more commits throughout the day, and finally finishes on Sunday early afternoon. By looking at the commit history, it is clear that both members of Team A have made significant contributions to the code. In contrast, Team B has no commits until early Sunday but works frantically right up until 5:00pm. Furthermore, 90% of the commits are made by only one person on Team B.
In this situation, Team A would get more credit for the system because they have employed a higher quality software engineering process (i.e. they did not wait until the last minute to begin). In addition, different amounts of credit would be given to the two team B members due to the fact that the commit history indicates that one member did the lion’s share of the work.
Your system should include a well-written README.md file (published using GitHub pages) that provides an explanation of how to install and use the system. It should not duplicate the information provided in the Help page of the running app.
You might find it useful to meet with your team immediately and start defining tasks according to our Issue Driven Project Management technique.
You should plan for three milestones. Each milestone should result in a “releasable” version of the system.
You will need to create a Slack team to support communication among your team members. Please invite me to your team.
GitHub issues must provide a complete representation of how the work was divided up, when various components of the system were implemented, and who was primarily responsible. You must use HuBoard to manage the workflow of issues.
A team could implement a complete functioning version of the system, but if the process by which the system was created is not documented at all (or poorly documented) through GitHub issues, then the team will receive only 50% credit.
