...
Currently, the site is hosted on scripts.mit.edu, which uses Apache to serve the HTML pages generated by the backend. We originally chose to use Rails as a backend because one member in our group was very efficient in it and another had previously worked with it, but . We wanted to choose a backend that we were comfortable with so that the majority of our efforts could be focused on the frontend, which 6.813. A critical implementation error we encountered was that Scripts only supports Rails 2, which neither member in our group had worked with before. The changes in the API in Rails from Rails 2 to Rails 3 caused some development errors problems that we did not expect as we realized that Rails did not necessarily have the functionality that we had thought. Some of the resulted problems included Rails 2's lack of support for for accessing multiple tables and a different routing schema. This also prevented us from using some of the gems (add on's or external classes) that we were acquainted with from being used, causing us to write this functionality and using more time.
Another resulting problem of Scripts was that without sudo access to the server we had a difficulties trying to create a development set of code from a production set of code. Because we were never able to solve this problem, we had to wait while our GR4 was being graded to begin coding GR5, which resulted in us losing a valuable week of development time.
We went with a MySQL database structure because using a relational database was perfect for this kind of project, and MySQL was easy to configure with the Ruby on Rails backend.
The database holds information about the Users, Households, and Bills.
The Users table is used to hold holds all of the information pertaining to individual users, and their accounts. This table contains the following columns: username, password, household, and id. The idea here is that each user has a unique account, and users are grouped together into households. The Households table only contains an id column and a column titled 'household' that is a string of the household's name. Each bill in the Bills table has an id, name, due_date, creator_id, household, total_amount, category, and paid_all. The creator_id field holds the id of the user that created the bill. The last column, paid_all, is used to tell if all of the users on a particular bill have paid their share. There is also a table called User_Bills that connects Bills to Users. This last table is necessary because the relationship between Users and Bills is many-to-many.
We decided to use HTML5 with CSS for the frontend because it made our implementation easier to construct. Ruby on Rails allows for the creation of dynamic HTML pages, which means that we can put content from our database directly into our HTML, depending on the users' requests. We used CSS to make the site visually appealing to the user. Using CSS also allowed us to have a different color scheme for alerts that we presented to the user for, for instance, incorrect data entry.
We used jQuery wherever we wanted to change the contents of a page without having the user reload the page in their browser. For instance when a user inputs the total amount for a bill, we automatically split the bill up amongst the members of the household and show the user these amounts as they are typing.
...