Logs
First day
Meeting with the client
We went over the requirements with our client, Edwin Rodriguez. Discussed the specifics, and features for the future application.
in particular:
1. User Profiles
2. User Feedback
3. Service Statistics
4. Payment Options
5. Dropdown List
6. Promotion
7. Daily Deals
8. Security
9. Appearance
Requirements given for the next meeting:
● Complete the set up for the Cloud Service
● Determine and finalize the tools, languages, and frameworks that will be used throughout the project.
● Have a Github repository ready
Meeting 1
02/11/2020 - Discord
Discussed the first step for the project, the creation of the static website
Opened an account in AWS Educate, where our App will be hosted.
Went over the steps involved in creating a storage space in AWS, using AWS S3 Buckets.
Planned on creating a single bucket that will be shared between all of our team members.
Assigned roles to each member in the first step:
Thomas – will organize daily meetings with the team both face-to-face and online. Will assign roles for the future tasks and make sure every team member is on board with the progress of the project.
Sarkis – Will create the AWS S3 Storage for the static website and set up the environment.
Hunter – Will create the Github repository for the project, and invite all team members.
Anthony – Will start designing the data model of the project and make design choices.
Narek – Will write the log for the first meeting with the customer, Edwin Rodrigues
Work on the static website.
Shared our available hours in order to set up meetings that work for everyone
Meeting 2
02/11/2020 - In person
Worked on the static website
Created a bucket on AWS S3
Uploaded HTML files composing our website
Added background image
Added a Logs page inside the website, to allow the user to read the outcomes of our meetings
Set up the navigation in the website, with the following pages:
Home, Logs, About Us, Contacts
Discussed the pros and cons of hosting a mobile web application on AWS
Finalized our discussion on the framework, concluding that AWS Services will be the best option for our project.
Talked about our experience in programming and the proficiency in relevant languages.
Meeting 3
02/12/2020 - In person
Discussed the programming languages to be used in the project
Thomas went over the libraries offered by Python, and how they fit in our project.
Sarkis shared his experience with privious projects and the advantages of some of the features offered by AWS EC2.
Sarkis briefly summarized the Database Servers available in AWS that we can use. Those include:
Amazon Linux 2 AMI
Amazon Linux AMI 2018.03.0
Red Hat Enterprise Linux 8
Ubuntu Server
We decided to use Linux AMI 2018.03.0.
Set up an online meeting time for 02/13, when we will work on the project as a group, using a screen sharing and video chat capability of Discord, our primary communication medium.
Meeting 4
02/13/2020 - Discord
Sarkis explained the workings of AWS products and services in detail.
He showed the team how to Launch a server using the EC2
Explained the differences between the different servers available
We opened a Database with AWS RDS
CEO Thomas opened a GitHub repository for the project
We planned to create individual branches for the project and do code reviews before merging any new code
The members most familiar with Git commands helped the others get familiar with it.
Thomas opened a screen-share on Discord and started typing Git commands and showing us what to do to create our own local repositories in our own local machines.
Then he showed us how to connect our local project repository to the remote repository
Went over some basic commands used to commit and push changes or pull from the remote repository.
At first, we were having issues in creating the Git project. The queries were not doing what they were supposed to. However, after several tries, we figured out how to launch the repo.
Then, each member went ahead and became a member of the repo.
We decided to use push commands very sparingly in order to avoid confusion and overwhelming number of changes to the project.
Having too many pull requests would give the master branch’s user a hard time deciding which commit to merge into the repo.
Also, too many requests would mean the member with the master permissions had to go through a lot of changes and decide which ones of them are good enough for merging.
Meeting 5
02/17/2020 - In Person
We Discussed the data model of the project.
There was a dispute between us about which model to choose:
A database with few tables but a lot of fields
A database with a lot of tables and a lot of references (relationships) between them, but each having a set of unique attributes
The CEO supported the first model because of its:
Scalability:
It means, if a restaurant gets an order per 5 minutes, and we have 100 restaurants in the system, then the individual tables will explode within an hour, with a lot of complicated relationships and the overhead of keeping track of them.
Safety:
Keeping several tables implies encrypting data every time we make a reference to another table, or insert a new record to a table that has several references to other tables. With a single table, encryptions are done once, increasing the protection of the database.
Speed:
Not having to worry about complex relationships between tables means getting data quickly. For example, let’s say we insert the reviews of orders inside a table called Restaurants, instead of creating a table named Review and having a reference to the Restaurant table. Then, every statement regarding the Review of a restaurant is satisfied from a single table, Restaurants, instead of having to link to another table and get the same data from there.
Simple Queries:
Not keeping several tables and interconnections means not dealing with complex join queries and error-prone SQL statements.
The argument behind multiple tables with complex relationships was to have unique data being separated, in their appropriate tables, instead of mixing up unrelated information.
We decided to stick with the first model, but the issue still remains open for discussion.
Meeting 6
02/18/2020 - Discord
Initially, we wanted to create a single table, with everything stored in it.
In one of our lectures, however, we learned that we should never do that.
Instead, we have to separate our data as much as we can, and use keys to connect our tables.
Created an initial draft for the data model using Draw.io. It gave us a taste of how the Relational Model would look like.
We also created the ER Model, which described the relationship between the tables and the data.
Discussed the pros and cons of having different tables, and agreed on using only a subset of the tables we came up with at the beginning.
Initially, we had tables for storing information about the drivers. However, for the time being, be agreed to get rid of it, and worry about drivers later, if need be.
Some of our members were already taking a Database course, and the concepts learned in that course helped us create a good data model.
We analyzed our current model and found some weaknesses.
Our Items table contained the menu to which it belonged. However, we also had a table called menu_items. It was because we thought one item could belong to multiple menus. In that way we could reuse our items.
However, in practice, we would have a redundant data. Thus, we decided to get rid of the Menu_items table, and only leave our Items table.
Meeting 7
02/19/2020 - In person + Discord
During the morning meeting, we realized the weakness of our current data model, and planned to develop it within the upcoming 48 hours.
Hunter worked on the fundamentals of our data model, providing our team a strong base to start the design of our data model.
He created a Google Doc and developed over 15 tables and their basic attributes to help the team get started.
In the Google Doc, before starting our voice chat, we started commenting on the attributes that we had question on. All of the team members were active and very responsive.
We managed to end up with a very neat, and meanwhile complex, database structure, with tables and attribute names written in the format below:
Table_name_1
>attribute_1
>attribute_2
…Table_name_i
>attribute_1
>attribute_2
…
Some of the tables and their purpose were not clear to some of the members, however. We cleared off any ambiguity and agreed upon all the tables and their relationships.
For example, we had a table called Order_Item. However, we also had a table named Orders. Some of the members argued that the tables Orders could store the items that were ordered, one by one. The weakness to that approach, however, was that in a given order, there can be several, and even dozens of items ordered, as a user should have the option of ordering as many items as he/she wants.
Thus, given the “list” nature of the items inside an order, and the advice by Mr. Rodriguez in keeping all the attributes atomic in all the tables, we agreed to use Order_Item table to keep track of every single item ordered in every order.
Another ambiguity was the necessity of having Order_Restaurant table, to take care of the multiple restaurants that are involved in a single order. As was the case with the Order_Item table, it made sense to create another table called Order_Restaurant to connect the restaurant_id’s with the order_id’s.
However, the team realized that the Order_Item table can actually contain one more attribute, called Restaurant_id, that will contain the restaurant from which the item comes from.
Thus, the Order_Restaurant table was considered to be unnecessary.
In the voice chat, we planned to start working on the actual ER and Relational models based on the information available in the shared document.
Meeting 8
02/20/2020 - Discord
Eliminated the tables Driver and Driver_Payment for now, but left it in our shared doc to get back to it when need be.
Reviewed the tables and their Relational Model created by Sarkis and made adjustments and improvements to it.
Sarkis created our ER Model using Microsoft Access and presented it to the team.
It had all the details and components specified in our first draft of the database.
All the tables had Primary Keys and Foreign Keys indicated with “key” symbols on their right side.
We went over the tables and suggested some minor changes to it.
For example, the Users table had the attribute “Location_ID” in it. However, after a few minutes of discussion, Hunter suggested that it is not necessary for a user to have a fixed location associated with him/her. His argument was that the only location that matters for our app is the CURRENT location of the user, which can change every second, and thus is impossible to store in the database.
Hunter also suggested to have the location of the user handled in the application itself, where we could keep track of the user’s location dynamically with the help of API calls.
The group unanimously agreed to follow that methodology.
Narek prepared all the queries necessary to instantiate the tables in the actual Azure SQL Database based on the data model prepared by the team and the Relational Model. Using SQL Server Management Studio (SSMS) and MySQL, the tables were created with their appropriate relationships.
We had to rename our table from User to Users, because the MySQL was throwing an error.
Referential Integrity rules were specified to deal with record deletions in parent and child tables.
Some of them, however, threw an error, and had to be removed from the queries. For example, a cascade override rule threw the error below:
ERROR:
Failed to execute query. Error: Introducing FOREIGN KEY constraint 'ORDERS_FK_LOCATION' on table 'Orders' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints.
Could not create constraint or index. See previous errors.
The ER Model was later created, based on the Referential model.
Meeting 9
02/21/2020 - In person
Discussed the upcoming plan for the next week.
Scheduled meeting times for the next week that works for everyone in the group.
Considered the possibility of Azure not being able to work with Django, and thought about alternatives we might use in case that happens.
Shared a template for SRS and a link to a detailed explanation of the contents that a well written SRS must have.
Planned to get familiar with Django, and some of the great tutorials available on Linked In
Share the database with each other.
Went over the Azure Database, and how to connect the SQL Server Management Studio (SSMS) to the shared database.
We created a new Firewall Rule and added the IP address of the member who was going to have access to it. After setting up the rule and saving it, the member could access the database via SSMS.
The login process in SSMS did not work at the beginning, but later we figured out that the name of the server asked in the login dialog referred to the URL of the Server given by Azure.
During the class, we found out that the instantiated SQL database could not be accessed via the IP address of the classroom that was not added to the Firewall Rules. We added a new rule, including the IP address of the classroom, and the permission was set successfully.
Tried to insert new records in our database. However, the SSMS did not recognize some basic MySQL clauses, such as
Insert into Orders values(….)
It kept referring to the contents inside the parenthesis as “unrecognized column names” for the table. When we tried the same queries in our local databases and tables using the MySQL command line, the commands worked just fine.
Meeting 10
02/24/2020 - In person + Discord
In Person:
We made bullet points organizing our thoughts for the SRS document.
Made some clarifications on what would go in the SRS and what not.
The details of the implementation were to be excluded from the document, as we will have another chance to include them in another document, specifically for Project Design.
Discussed the functional and non-functional requirements of our project, and suggested some candidate ideas that could go in there. For example, the Search Bar, the Map View, Deals, and Promoted Restaurant features were in the list of those ideas.
Briefly went over the requirements for Friday besides the completed SRS document.
Decided to start adding some sample records to the database the next day.
Discussed some issues concerning the “insert” statement inside SQL Server Management Studio (SSMS), and its possible fixes. Later, we figured out the problem, as the SSMS expected the character ‘ (single quotation mark) to be surrounding strings, and not “ (double quotation marks).
Online:
We started working on the SRS document on a shared google doc.
Our strategy was to assign each member a section to work on, using his chosen color.
That way, we were able to identify the author of each section and ask our questions in the Voice Chat to the right person.
Also, when we came up with an edition to a particular paragraph written by another team member, we were able to use our own color to make additions, making it easier for the original author to see the suggested changes.
We constantly discussed what each of us was writing. We kept asking questions to each other during the process, so another member could scroll up or down and give his opinion on the paragraph.
We almost completed the SRS document, and planned to meet the next day to finish it off and start working on the other requirements for the coming Friday.
Meeting 11
02/25/2020 - Discord
Went through the SRS document together, and made comments on each sentence
A member volunteered to read the content out loud, and the rest of the members listened carefully, following along and trying to find mistakes or inconsistencies.
We interchangeably read the content, and attacked on each sentence together to make sure everyone agrees on what is written
When a sentence was encountered that contained something a member(s) disagreed on, we stopped and made clarifications and editions to that sentence.
We also came up with questions to ask to our client during class.
The first question was whether we needed to provide the users with the options of delivery and pickup, rather than just delivery
The second question was to enable to system to keep track of the number of items ordered from a single restaurant
The argument was that if the number of items is too much, the restaurant may not be able to handle it.
Thus, we need to give the restaurant a chance to get ready for the order, or at least set a limit to the number of items allowed to be ordered with a single order.
We were planning to discuss a little bit about the server and how we would tackle it, but we left it for the coming day.
Meeting 12
02/26/2020 - In person + Discord
In Person:
Since our original Virtual Machine (VM), Server, and SQL Database was created on non-student account, we had to create a new account, registering as a student.
With the new student-account, we recreated all of the components.
We had some issued when trying to remotely connect to the VM.
We initially tried to use putty to accomplish the task.
However, after a few unsuccessful tries, we used Windows command line, with the command “SSH server_name@ip_address”
After unsuccessful attempts to connect to the Azure SQL server, our research revealed that it would be better to create a MySQL Database.
The latter proved to be the right choice, as it did not throw errors when our python code tried to access the database.
There were no drivers necessary to connect to the tables. By importing mysql.connector in our python code, and then using our database credentials, we were able to get access to the database through our Azure VM
Online:
Worked on the steps needed to take to get ready for Friday.
Using SSH protocols, all the team members were able to connect to the virtual machine created in one of the instances.
Each member had access to the VM
The CEO shared his screen with us so we could follow his actions, instead of trying to modify the VM individually
All the members created an Azure Student account, in order to be able to access the remote database instantiated in Azure.
Successfully used Django to create a project, then created a dumpApp inside of it.
After creating a working Django app that was running in the localhost, we eventually managed to deploy it in our Azure Server.
Meeting 13
02/27/2020 - In person
Planned to follow the suggestions of our client not to use the term applet in our SRS.
Since the scope of the project is not large, we also agreed to avoid providing security details and workarounds.
We will not be able to implement security related functionality during the semester as it would be practically impossible.
Discussed our plans for the weekend and the upcoming week.
Agreed on using Bootstrap for our application’s front end.
Decided to watch online courses on Django in order to have everyone up and running with Django.
Discussed the APIs that we would use in our application.
The mobile application will need to display some contents from the tables in the database (non-private contents), and that will require an extensive use of APIs.
We also need to utilize bootstrap in an extent to allow the mobile application to render contents in a user-friendly way.
Our goal for the next presentation (March 9) was formalized:
Create basic Authentication functionality.
Allow users to create new profiles.
Allow users to login to their already-existing accounts.
Allow users to view their account information using their mobile devices.
Meeting 14
03/02/2020 - In person
Divided the whole task into parts
One member was assigned to concentrate primarily on the Bootstrap and its usage for our website’s front-end development.
Another member agreed on starting out with Bootstrap once done with Django.
The middleware, however, remained the task for everybody in the group.
Discussed the features offered by Django and its power when dealing with Databases
Agreed on using github over File Management System, such as winSCR, in order to keep track of all the changes more effectively
However, for some minor changes and/or viewing the contents of the documents, we use winSCR to get the current versions of any files.
We use a remote Virtual Machine for our application. That means we get access to it with our local machines using putty or cmd. Thus, the advantage of winSCR is that we won’t have to keep using the linux command line to view our files. Instead, the interface of winSCR makes things much easier.
Made some clarifications of the purpose of having a website app
Differentiated the website (the desktop version) and the Android app itself
The desktop will act as a middleware, making sure the application and the database have a working connection.
The Mobile App will eventually be derived from the website, and inherit its functionalities and features.
The only difference will be its user interface and features unique to Mobile Applications.
Meeting 15
03/03/2020 - In person
There were changes made in the files of the master branch. However, those changes made the entire website non-functional.
There was a bug in the changes, that threw a number of error messages when we tried to access the website.
However, the bug was not self explanatory, considering the fact that we did not have a lot of experience with Django Python.
The only solution to fix the problem and get the website in the original working condition was recovering the old application.
Fortunately, we had the files of our working project in the CEO’s local machine
Transferring those files into the Virtual Machine got rid of the errors we were getting with the changed files.
This brought with it a port related error, which was fixed successfully.
We pushed the working project into our GitHub repository.
We made a strict rule to follow when working on the virtual machine:
Anyone who wants to change any code or file in the project, must first clone the project from the Github repository into his local computer. Only then he can modify the project.
After modifying and testing in the local machine, it must be presented during the meeting in person or via a screenshare on discord. That is to have everyone in the team approve the changes and suggest new ones.
Once the new version is approved by everyone, then the member responsible for the changes can go ahead and push it into the repository.
Finally, the new version of the project will be cloned into the Virtual Machine, where it will have its effects on the website.
All the aforementioned steps must be done using the member’s personal branch, and not the Master.
Meeting 16
03/04/2020 - Discord
Viewed one of the versions of the instance by a screenshare
After every member gave his approval, the version was pushed into the github repository for the project.
Then, the CEO cloned the newly updated version into the Virtual Machine, and the changes made in the personal instance appeared in the website.
Planned to start working on the Search Bar feature of the website first.
Decided to have the Search Bar available and functional by Thursday night, in terms of getting data from the database tables based on searched words/phrases.
After having the Search Bar ready, decided to start working on the API integration and endpoint calls
Found the documentation for the Yelp APIs online, which will most likely be used to carry out the API requests.
Also discussed the availability of Google APIs and its price. Most likely, it has fees and we must figure out a workaround.
Aside from working on the Search Bar and the APIs, we also decided to start working on the appearance of the website.
This task will most likely be completed using Django Bootstrap and CSS.
Fortunately, Django integrates well with bootstrap, and we can make decent user interface using Bootstrap.
Meeting 17
03/05/2020 - Discord
Decided to switch to another tutorial set for Django Python, as it contained material the previous videos did not.
So we tried to follow the new developer from the later published tutorials. However, his videos, like the previous one, built on top of one another.
This meant we had to restart some of the components of our project, going over the first several videos of the new tutorial set.
Backward compatibility was an issue, as we had to switch to another foundation, but keep the old project intact and runnable.
However, since the project is based on Scrumb methodology, we had to adapt quickly and follow the new version of Django.
The search bar functionality was introduced on video 28.
After unsuccessful tries to follow the video and make our search bar work, we were forced to go back and follow his previous tutorials
There were some changes we had to make in our files
We added new applications, using the command
python manage.py startapp
After some modifications to our views.py and urls.py files, we were able to get to the point where we could continue with the new tutorial set from where we left the old one.
Meeting 18
03/06/2020 - Discord
Implemented the interface of the search bar.
The search bar was implemented as an html form.
However, to figure out how to call a python file from html, we planned to do some research over the weekend.
We found some decent tutorial videos explaining how to achieve that goal, using Django’s built-in functionality.
The video was in Hindi. However, we were ready to learn even Hindi in order to finish our project. Whatever it took, as long as it would get the search bar up and running.
Started thinking about the Yelp API call and the way to accomplish it.
On discord, we posted the documentation page of Yelp, which would help us implement the call.
Planned to implement the call as a python function, and somehow use Django to call that function from the search bar.
For the interface, we realized that the base.html page was already using a bootstrap library.
That meant the interface requirement of our next meeting was pretty much complete.
The tutorials and the basic documentation that we were using for our project started to stray away from our custom needs.
In other words, starting at this point, the new features and functionalities had to be customized specifically for our project.
Instead of using the Django documentation or following tutorials, it is the time to start making our own editions and writing our own code, based on what we already have in the project.
This is a key point because the tutorials or documentations assume the reader (developer) to have certain files and apps already in place to implement some functionality. Since we have our own apps which do not match what is assumed by the documentation and tutorial makers, we must do a lot of adjustments to integrate any kind of functionality into our project.
Meeting 19
03/09/2020 - In person
Implemented the Yelp API call using python code.
The call was implemented as a python function. That accepted multiple optional arguments.
It was a good decision to work with python. It is very flexible when it comes to creating custom functions.
We used the API documentation found in Yelp’s website to work with the endpoint and get the results back.
The function returned the API response as a raw dictionar.
It was a big step towards completing the requirements for Friday as the API call was one of the expected outcomes of the iteration.
We planned to finish the implementation of the Search bar so that we could communicate the API call to the users. The way we pictured it was as follows:
Allow the user to enter keywords in the search bar and click on submit button provided under the search bar.
After the request got processed in the background, return the search results.
At first, displaying the raw dictionary as a response would suffice, proving that it actually works.
The final goal was to format each response object. Separate each response, having its own name, price, phone number, location, and preferably a photo associated with it.
Meeting 20
03/10/2020 - Discord
Talked about passing vars from html to python
Created a storage inside azure to store our website
Moving from aws
Discussed ways to have the user’s table inside of our MySQL database to be connected to the Django app, so instead of using Django’s models (tables), use the tables in our actual database
To create a profile page where the user can edit their personal information
Inside of settings.py, there is AUTH_USER_MODEL = ‘account.User’. So we thought by changing this line of code, we might be able to connect our db to the app.
Since the account was created under the name of one of the members, an “Owner” access was given to other members, too. So anyone in the team can make changes in the application, if need be.
This way, we don’t have to rely on one member, to login and change the app from his end
The code for api was not returning the result of the call, but storing it in a variable in a json format. So we had to look for ways to send back the data in a nice format so that our page could render the search results in a nice way.
Meeting 21
03/11/2020 - In person
We got the Search bar working. The search accepted the term (or the item) and the location of that item.
The search bar was created in an html file, using Django built-in functionality.
Django allowed us to change the action attribute of the form field, setting it to an existing view defined in views.py.
That meant the search form of the html page would post the keywords submitted to the view defined in views.py.
After hitting the submit button, the searched keywords would be passed to a python function for sending/processing API requests/responses.
A python method was created to make an API call to an endpoint provided by Yelp. The method accepted multiple variables, 2 of which was the term (the item the user wants to search for) and the location of the item. Then, the method returned the API response as a dictionary.
Using Django, we manipulated the dictionary, only displaying the most important fields
We created a navigation inside of our html document, and then used the content {% %} provided by Django to display only desirable elements.
The dictionary was in JSON format, so we were able to easily get the desired elements of the dictionary.
We also used Django’s for loop to iterate through all the objects in the response.
We also changed the category attribute, to shrink down the response body to only “restaurants”. With the category set to restaurants
With the category set to restaurants, the response contained information only about restaurants, as our project does not need any other categories.
We finally pushed the changes to the git, and the final product of the day became available.
Meeting 22
03/12/2020 - In person
Having implemented the search bar, and integrated the API calls with it, our next steps consisted of the following:
Allow the users to create accounts.
Provide an interface, i.e. a register/sign-up page to allow users to create new accounts. Also let them enter some other information such as first name, email address, preferences, etc.
Allow the users to sign in to their account.
After creating their accounts, users should be able to sign in using their credentials.
Use the Azure Database already in place to implement those functionalities.
There easier ways to do user authentication via the classes provided by Django. That is, it is possible to create user tables inside of Django’s models.py file and use the built in user authentication libraries and templates.
However, creating a user class from scratch required more work. The integration of our remote database with Django Libraries was a serious task.
User authentication usually requires third-party support, and is highly complex
Thus, we decided to create a custom user authentication interface.
Meeting 23
03/13/2020 - In person
Django has built in functionality that allows it to be integrated with authentication provided by third party companies.
However, we do not have an authentication system in place. We just have a remote database with tables in it.
Therefore, instead of trying to master Django’s built in authentication features, we decided to write a Python method to retrieve the user’s information from our Database.
It would be all custom, getting the credentials of the user and comparing it against the data entered by the user on the HTML form.
Our webpage already had bootstrap libraries called in our base.html file. However, those were taken from the tutorials.
Now it was time to switch gears, and instead of following tutorials, try to create our own product, with unique features.
One of our members had an internship in which he was asked to work with bootstrap. So the CEO assigned him to work on the bootstrap, as he would learn about it in his internship anyways.
The other members would concentrate on the middleware and html.
Although we had already created tables in the models.py file, it was inside Django.
So we got rid of those tables and started building our custom remote authentication
Meeting the Client
03/18/2020
The client said that the encryption can get too complicated. We don’t have the resources to worry about it. Thus, do not have to worry about it for this project.
The client did not like the colors of the website, and thought that it was too simplistic.
For the next sprint, he assigned us to work on the appearance of the webpage, using css, html, and bootstrap.
He wanted light colors, the style GrubHub and Uber Eats use.
The password input field was visible, so when we entered a password, the entered value could be seen.
The client showed us an html technique to have dots in place of characters.
Instead of using<intput type=”text”...>, we were told to use <input type=”password”...>
Meeting 24
03/23/2020 - Discord
Discussed the plan for the week, emphasizing on the appearance of the webpage and the sessions.
Also, one of the members researched the available encryption techniques.
However, as the client had mentioned during the meeting, if the techniques get too complex to implement, we can just ignore them and stick to simple custom authentication.
Our session feature did not work properly. We found a few logic errors in our views.py file.
To fix them, we had to tweak some snippets and add if statements.
After doing so, the sessions started behaving as expected, and the user stayed logged in even if we browsed from page to page.
For the bootstrap and html, the CEO assigned two people to work on.
We started changing the colors and adding some background pictures.
After doing so, the page looked more like a professional website.
We also shared some bootstrap documentation, explaining the different features available to us.
We used light colors, as the client had ordered.
It was easy to use as we called bootstrap methods inside our html elements.
We also decided to get the deals and promotions from our remote database, and render the data to the user in a nice fashion.
Meeting 26
03/25/2020 - Discord
Used HTML to cover the password entry, so that instead of the plain password, only dots were visible when signing in or signing up.
Our remote database, for the time being, stored plain text for the user passwords.
One of our goals for the week was to write code for encryption.
The code would convert (encrypt) the password entered by the user and convert it to an encrypted character set.
Our register page should then be integrated with the encryption code, so that the login page could take advantage of it.
Our next goals was to implement sessions.
We actually had it working partially.
However, it acted weird when we clicked on different tabs (pages) in a particular order.
So that also had to be fixed for the coming sprint.
We discussed the color options we had for our home page.
We used a light blue for our page bar on the top.
For the page names, we chose light silver.
We fixed our login page, using pure HTML.
We added spaces and some indentation to make the page look professional and more user friendly.
We looked into some HTML and bootstrap techniques to implement horizontal-scrolling divisions (<div>) inside of our home page.
The design bootstrap offered did not satisfy our needs, so we decided to implement it using pure HTML.
Meeting 26
03/25/2020 - Discord
Finished up the encryption code using python.
The encryption code would be used to both create users in our remote Azure MySQL database, and give them encrypted passwords.
In other words, instead of storing the plain password for users, the python code would convert it into an encrypted characters and then store it into the password.
We used a custom encryption technique, instead of relying on a third party middleware.
When we ran the code inside of the python terminal, it successfully created new users and then encrypted the password, storing the encrypted version of the password in the database.
Later, we updated the login page and implemented sessions.
Now, we had user sessions that propagated through all the pages in the website.
Also, even after closing the browser and reopening it, the session remained there. So we sort of implemented cookies for our website.
Using pure HTML code, we were able to create a scrolling photos.
The end goal was to add some text onto the photos and make each of them (the photos and the text) clickable.
The photos, upon a click, would redirect the user to another page, presumably called restaurants.html, which would show more details about the restaurant and the menus it has.
The restaurant.html would be a template, which would be reused for each clickable photo.
The data would come from our remote database, so one of our goals became to populate our Restaurant table with legitimate data.
Meeting 27
03/26/2020 - Discord
We populated our database with data that would eventually be used in our website.
We added several restaurants to our Restaurant table
Then, for each restaurant, we added 3-4 menus in the Menus table.
Finally, for each menu, we added several items in our Items table. The Items table had a column names “image_url”. So we also added one image per item, so we could show it on our restaurant.html table.
Our search bar worked, rendering simple output for the yelp API call, whenever the user searched anything.
However, our search bar worked only with 2 inputs.
The first had to be the name of the food (without spaces)
The second had to be the location of the food (again, without spaces). That is, we could not enter “Los Angeles” as the location because it consists of two words with a space between them.
We decided to fix that logic error, and allow the user to enter any type of food and city with any number of spaces.
The goal for the coming deliverable was to make the search results clickable.
That is, as was the case with the horizontal-scrolling photos, the search results would need to be clickable.
The links would send the user to the restaurants.html table, where more information about the restaurant would be provided.
We also made our register page functional with the encryption code created earlier that week.
Meeting 28
03/27/2020 - Zoom
Our interface lacked some minor features and the client said that we were 80% - 90% done.
The client mentioned that we have to work on the profile page for the user.
We just had the name of the user displaying after the user logged in. However, we have many more attributes in our database that need to be utilized in our pages.
We did not talk about user’s profile picture, but that might also be something we will consider for the next sprint.
After the user logged in, he/she is taken to the profile page.
The client said that we must have what’s called “Initial User Page”, with his/her personal favorites, recommendations, and items filtered by history.
This is where the user will spend the most time while in the website, so special attention must be given to this feature. This is the face of our webpage, and will determine whether the user likes the application or not.
The client also asked for full user registration
That means not only the email and password are asked from the user for registration, but also the full name, phone number, preferences, etc.
The client also wants to see Restaurant Menus showing up inside of the Restaurant page
We actually tried to display it on the page, but the Yelp API did not return any information about the Menu of the restaurant.
We do not know yet how we will receive the menus for each restaurant, but that is something the client wants to see on the next sprint.
So for the next sprint, we will need to write extensively in Python, HTML, CSS, and probably JavaScript. Although some of us are not familiar with those languages, it is essential to start learning those languages to complete the tasks for the next sprint.
Meeting 29
04/06/2020 - Discord
We found out that the menus and menu items could not be retrieved from the yelp API.
Actually, Yelp itself used third party APIs (e.g. TripAdvisor) to get the menus for each restaurant.
However, in order to use TripAdvisor’s product, we had to pay.
Because of the fee, we emailed our client to know if we could use our own database to store our own restaurants and menu items (taken from real restaurants and their menus).
The client replied back, allowing us to do it.
So we planned to populate our database with several restaurants, each of them with 3-4 menus
Each of the menus would have its own set of items.
Thus, we had to create yet another python script that would grab those data and pass it to our HTML pages.
We already had a python script for Yelp API call.
We did not remove it, but kept it and decided that it would still be functional.
Therefore, when the user searched restaurants on our website, he/she will get results both from Yelp and from our database.
We also planned to remove the search bar on top of our base.html. That is, the search bar would not appear in every page of our website
Meeting 30
04/07/2020 - Discord
We started to manually populate the database with restaurants and menus for each.
We created new columns in our Restaurant table called restaurant_image, that would store the url of the restaurant’s image.
We also added similar columns in the Items table, so that each item would have its own picture.
The process of inserting those rows was time consuming. We added 5 restarants to begin with
Each of the restaurant had 3 menus.
Each menu had 3 items.
Thus, we had to manually add 5*3*3 = 45 rows.
The most tedious part of the task was to gather the images from google. Images that were square and would not cause us problems when displaying them in our tables.
Meanwhile, as planned, some of our members worked on the python script that would retrieve those data.
Those data would then be retrieved by the HTML pages and rendered in a nice manner.
After creating the SQL queries and running the methods, the SQL threw some weird errors that were hard to solve.
Particularly one of them failed because the table ‘Users’ was types with a lower ‘u’. It was weird because MySQL is case insensitive. At least when we run commands like that on the terminal, it does not matter whether we type ‘USERS’ or ‘users’. The query will successfully run regardless of the cases.
Meeting 31
04/08/2020 - Discord
While working on our database, we found out that the Azure was to close our free account for some reason, and required us to make payments and create an account to save all the data.
We decided to abandon the Azure service and go back to AWS.
One of our members recreated all the components that we already had in Azure.
Those components included the Virtual Machine, SQL Database, the Subscriptions, etc.
Luckily, we had used good programming practices, and separated the Database connection code in its own file. We then called that code in several places in our Django project.
That is, we just had to change a few lines inside a single file to make our python scripts connect our new database.
If we didn’t follow this abstraction rule, we would have to change the Database credentials in several places.
Once the new SQL Database was created, we restarted the insertion of the data into our tables.
We also decided to run the Virtual Machine every Friday, before the meeting, in order to avoid unnecessary payments.
We had to make sure that the service was up and running until May 15, the last day of school.
Meeting 32
04/09/2020 - Discord
Our backend was complete and ready to be tested on the frontend.
The new services were up and running on the AWS.
Our restaurant page had new features and user friendly components added, using HTML and JavaScript.
Our profile page, however, used a template that had a logo of another website.
We had to eliminate it because the icon on the tab displayed something we could not remove.
The code was using external sources that could not be modified.
Therefore, we decided to go simple and have basic profile page, instead of using complex code from other templates.
There were also changes made in the python code that retrieved users.
Since our new profile page had several attributes displayed, the returned those attributes as well.
Also, we added a new column in the users page, called user_image, that stored the url of the image of the user. Since it was just a string, the code returned it as a string. That url would then be displayed on the screen using the <img> tag in html.
We also had some problems with git. It was problematic when we tried to resolve conflicts.
When one of us pushed his changes, and another one was still working in his own local repository, it meant the latter person would have to pull the changes from the remote database and resolve the conflicts that emerged from his own version of the project and the newly-pushed project.
However, working with git for about 2 months now, we have become more experienced in handling those kinds of issues.
Meeting 33
04/10/2020 - Zoom
The client admitted that the functionality was there.
The registration page was user friendly and fully functional.
The profile page showed not only the name of the user, but also his/her preferences, email address, username, and phone number.
The client also liked our dashboard, which had the restaurants stored in our database.
The client also liked our scrolling list of restaurant items and deals.
However, for the time being, the images were not clickable.
Our next task was to make those images links and take the user to a page where they could order the item.
The client emphasized that our top priority is to add functionality and make things work in our website.
Since we already had those, he said that we could now pay more attention to the aesthetics of our website.
The user experience is very important, and we had to improve the interface of our website. In that way, we can theoretically attract more users and therefore have more clients.
Our plan for the upcoming week was to beautify our website.
Also, we planned to work on the orders, and allow the users to create orders.
We also planned to start working on the Reviews, and allow the users who have ordered something to leave reviews/feedback about their experience with the service.
Meeting 34
04/13/2020 - Discord
Our main goal for the week was to improve the visuals of our website.
We started to research html and css, figuring out ways to add some components to our page that would look good and attractive to the users.
We had the template for the scrolling bars.
Although they were functional, they did not appear good and looked to be broken.
So our goal was to add more components to the bar.
We extended it on the page so it would stretch from one side to the other.
We used the static keyword in Django inside of our base.html and added code in the settings.py.
Then, we used the <link> inside of the <head> to link the CSS files to our page.
The first component we tested to make sure the linking processes was successful was the footer.
The working footer confirmed that the linkage worked.
From then on, we decided to create files whenever a new front-end feature was to be added to the website.
Still, we had a lot of mixed code in our base.html that needed to be modularized.
We also started to implement the ordering feature.
We created new classes in Python, called order_list and order, which would store the shopping cart of the logged in user.
Meeting 35
04/14/2020 - Discord
We added a footer to the website, with a color identical to the navigation bar’s color.
At first, the footer was added using a CSS class defined inside the <style> element of the base.html file.
However, we worked on creating a folder where all of our style sheets would be stored.
That way, we would not have to put every single CSS class inside of base.html. If we did, it would make our front end code untraceable..
After doing research and watching Django tutorials, we found a way to connect our HTML pages to CSS files that resided in different folders.
We also changed the font of the headers, which had a significant impact on the appearance of the pages.
More specifically, we used a font created by google.
We imported google API’s in our CSS code, accessing their fonts.
The font we chose was called Lobster.
We worked on a button that would change its colors when the user hovered the mouse over it.
We created a new CSS file called button_hover.css, which would be linked to our base.html.
Then the classes inside of the CSS file would be used in our <div> and <button> tags.
Meeting 36
04/15/2020 - Discord
We also decided to have a search input field with two sections one beside the other.
The left field would receive the name of the restaurant or food the user wants to order.
The right field would expect the location of the user.
While testing our search bar, we encountered a problem.
When the user searched for a restaurant name that had the symbol ‘ (apostrophe) in it, the search failed and the code crashed.
That was because in the remote database, the SQL received the ‘ symbol and interpreted it as the end of the string.
Thus, we had to use the escape character in Python in order not to pass the ‘ character as it were. In SQL, we can precede it with a backslash (\), in which case the query gets successfully submitted, reading the ‘ character as a symbol and not as the end of the string.
After doing a research on Python’s string manipulation functions, we found the method called replace(), and used it to pass \’ instead of ‘ to the SQL server.
Each of the \ and ‘ had to be escaped in our python code, yielding to the code below:
replace(“‘“, “\\\’”);
We also worked on different features in HTML that could enhance the user experience.
First, we tested the html pages in our local computer.
Only after it worked as expected on our computer we started merging the code into our project.
Meeting 37
04/16/2020 - Discord
Most of our work was to make our code more modular.
Our base.html file, that was basically the container for all the other pages (a Django functionality).
Over the weeks, the file had gotten packed with many unrelated CSS classes that were used throughout the project.
While trying to add new features, those classes conflicted the newly added ones and overwrote the latter.
It was becoming impossible to track down the conflicts and fix them manually.
We decided to add separate related css styling classes into their own files before it was too late.
The process was tedious as we had to test each class and figure out its effects on the website.
After figuring out what its purpose was, we combined classes that affected the same module in our website, and moved them into their own file.
Then, we used the <link> element in HTML to link the newly created CSS file to our base.html.
Besides the CSS classes, we also worked on creating HTML modules, which we could use in our code using Django.
Meanwhile, we continued working on the Python code for order submission.
There were some issues to resolve in the design of the order submission code.
The Order_ID that identified each order was generated by the SQL database after the order was submitted.
Therefore, we must have the order created and its Order_ID ready at hand before we could create an Order_Item.
The latter is a table to store multiple items per order.
Meeting 38
04/17/2020 - Zoom
The client was very pleased with our user interface.
Compared to the UI we had last week, it was a “from black to white” transition for the website.
The components that made the website attractive were the following:
The gradient background that was added to all the pages made a good impression.
The dashboard of the website had a light-colored header.
On top of the header was a transparent search input field.
The search input field itself was composed of 2 sections, which allowed the user to search both a restaurant and a location. That feature was important as our client saw it first. It was the first impression of the website.
The search button was transparent and gradually became light blue as the user hoverred the mouse over it.
The client also liked the “Deals” and “Recommendations” section of our home page. They were scrolling divisions, inside of which were images and image-descriptions underneath.
The client also liked the restaurants page, which was fixed during the week.
We also had an icon for the website, visible on the tab of the browser.
Since we had about 70% of our orders functionality implemented, our goal for the next sprint was to fully implement the ordering system.
Meeting 39
04/20/2020 - Discord
We already had most of the back end implemented last week.
The ordering system was almost ready to be tested on the front end.
The shopping cart was implemented with all of its attributes and methods.
We also had a page dedicated to the shopping cart.
The page had a list of items in it, including the name of the item, the image, the quantity, and the image of the item.
Below the list, there was a footer containing the total price of all the items in the shopping cart. The total was calculated by simple math calculation to get the total price of the order.
The shopping cart belonged to a single order.
That is, the items in the shopping card could only be ordered as a single order, not as individual orders.
That is how most of the online ordering systems work, and we decided not to have individual orders within a shopping card.
With this design, the only way the user can order something new is by ordering the existing items in the shopping cart or removing them from the shopping cart, and start adding new items in it.
We created an item page, that would be where the user would be redirected after clicking on an item.
The page had the image of the item, its name and its price.
Also, there was a quantity field that could be incremented/decremented by the user, to specify the number of items the user wished to order.
Finally, we created a button called “Add to shopping cart” that would submit the item, with its quantity, to the shopping cart.
The backend of the button was not implemented, though.
Meeting 40
04/21/2020 - Discord
The shopping cart was implemented as a class, and stored inside a session.
That is, the user, once logged in, could navigate through the pages of the website, and still maintain his/her items.
However, at the start of the meeting, the login and restaurant pages were not working for 2 of our members.
The login failed no matter what credentials (existing or non-existing) we provided.
Also, after searching a restaurant stored in our database, the search results page showed a bytearray(b’restaurant_name’) instead of just the restaurant name.
That, of course, broke everything that followed.
When looking at our terminal, we discovered that the login was failing because of the byte array mystery.
Instead of manipulating the hashed version of the password we entered in the user interface, Django was dealing with the byte array version of the credentials.
The byte array then got sent over to the database, which, of course, was unable to match that to any existing credential.
The problem was hard to solve because the error was found in only 2 of the member’s computers.
However, the backend Python code was written by another member, and the code was working perfectly on his and the other 2 members’ computers.
We decided to solve the issue on the next day.
Meeting 41
04/22/2020 - Discord
After careful research, we found out that the problem was the tuple API we were using in Python to implement the data transfers from and to our project.
The API was inconsistent, which explained the reason that it worked on some computers, and did not on the others.
Of course, keeping those inconsistencies and moving forward would not work, because we would lose the contributions from 2 of our members.
We decided to fix the problem and then continue working on the ordering.
That would mean less time for order implementation. But we had no choice.
The login functionality was so important as the ordering and shopping cart pages would show only if the user was logged in.
That is, we must be able to log in to be able to implement the ordering system.
All the meeting was dedicated to solving the tuple inconsistency.
After changing some code and testing it, we discovered that the problem could be solved by using dictionaries instead of tuples.
After changing one of the functions to send and receive a dictionary of values, we opened our terminal and observed the output.
The byte array was gone, and the data was in the format it was supposed to be in.
This meant that we had to find all the appearances of tuples in all of our methods, and manually change them to dictionaries. The worst part was that we could not make any progress once that was done.
Figuring out the cause of the problem took us so long that we decided to finish the manual modifications the next day.
Meeting 42
04/23/2020 - Discord
The modifications were done, and the login and restaurant pages were now working for all of our members.
We basically lost 3 days of our sprint just to fix an inconsistency found in Python’s API.
One more thing had to be fixed before we could go back to our implementation of the ordering system.
Since the backend was modified from tuples to dictionaries, it meant that the keywords used for the table attributes were also affected.
With tuples, we had table column names that were chosen by us, regardless of the actual column names in our remote database.
With dictionaries, we had no option but to use the column names found in our database.
This meant that whenever we had a reference of a database variable inside the double curly braces {{}}, we had to manually change them as well.
This was also a time consuming task, because we first had to find all the files and locations where the keyword was used.
Next, we had to match that name with the actual name in the database.
Finally, we had to change those names to reflect what we had in our database.
Only after completing all these manual changes we were ready to finish the ordering system of our project.
First, we pushed our front-end changes to github.
However, given the time restrictions, we were unable to fully implement it.
Meeting 43
04/24/2020 - Discord and Zoom
Meeting with the team:
We had a quick meeting before the start of the class as we were not done with the front-end implementation of the ordering system.
There was a non-functional implementation, which did not use the functions of the class properly.
The request.session, where the shopping cart was to be stored, did not accept the object we were passing to it.
The issue was that the session object cannot store a dictionary, which was the data type of the shopping cart.
For that reason, there was a method called convert_to_dict_list, which converted the shopping cart from a dictionary into a dictionary list, which could be readily stored in sessions and passed to the shopping cart page.
Due to the type limitations, we were unable to finish the implementation until the end. We were still getting JSON serialization errors, even after using the convert_to_dict_list() method.
Meeting with the client
We explained to the client the circumstances we were in during the week, all the trouble we had with the tuples.
Since we spent about 3 days of our 4 day sprint (Tuesday, Wednesday, and half of Thursday) trying to figure out the python’s api inconsistency, we lost a good amount of time that we could have been spending on implementing the ordering system.
The client said that things like that happen often in Software Engineering.
He said that we need more time to implement it, and fortunately, we will be given the time to do so, as we had 1 more week to go.
For the next (final) sprint, our goal was to fully implement the front-end of the ordering system.
Meeting 44
04/27/2020 - Discord
Started to test the methods in our project
Data generated while testing could get on the way of our data
For that purpose, we created the exact copy of our database, and concatenated the word “Test” at the end of the database name.
All the testing would be done with that newly copied database.
Otherwise, we had to keep manually deleting our test data from the database, which could cause issues
We also discussed backing up the database at a given point, and then, after doing the testing, revert it back to the backed up state.
That method wouldn’t work if two of our members did the testing at the same time. It would be hard to keep track of who made which changes.
Also, if one person reverted back to the state he started at, the changes made by the other tester, who had started earlier, would still be present.
That would lead to inconsistencies in the database.
We worked on the shopping cart, passing it down with the session in Django.
We were encountering a problem when incrementing the quantity of the item.
Instead of just incrementing the quantity of the item already existing in our shopping cart, a brand new item with quantity = 1 was being added to the cart every time we incremented the quantity.
We fixed the problem by changing the python code that was adding the item to our list. Instead of appending the new item to our cart, we actually created a new one and then appended the item to it.
Meeting 45
04/28/2020 - Discord
We started working on testing.
Since we had important data stored in the database, we did not want to do our testing on our original database.
It would be hard to clean up the database after the testing was over.
Since 2 of our members were working on it, reverting back to a point in time would not be ideal.
The problem was the choice of the back-up time, to which everything would be reverted.
That might have been fixed with rigorous collaboration, but we chose not to go that way.
Instead, we cloned our database (a functionality provided by phpMyAdmin), and named our new database with the name of our original database, concatenated with the word test.
Now, testing would be done by just changing the DBSetup file, by modifying the name of the database from BarbosasCrew to BarbosasCrewTest.
We also continued working on the ordering system.
After fixing the incrementing functionality of items, we started to work on the checkout page of the order.
The checkout page contained a from that asked the user to enter the location and credit card information.
The page also had information about the order and the items in it.
Meeting 46
04/29/2020 - Discord
The checkout page contained a from that asked the user to enter the location and credit card information.
However, the location and payment options were only in the front-end. We decided to leave location unimplemented as we did not have
The checkout page had the subtotal calculated for the order.
We found out that doing math in Django could be more complicated than adding a function in our python code that would calculate the total for us.
Thus, we wrote a function and called the function in views.py to get the subtotal of the order.
Then, we created another function that calculated the total price of the order, using the subtotal.
We used a constant tax value of 10%, and calculated the total with that.
We were also working on the testing. There were some tests that were failing, so we had to fix the subtle problems in our functions.
There were cases that we had to change the SQL queries a little bit, to make sure the tests passed.
Meeting 47
04/30/2020 - Discord
While testing, we were having issues comparing the query result returned by our remote database with the value stored in our python object.
When we printed out the two operands for the comparison, they were not identical as far as strings go.
The problem was the date-time returned, which was not parsed properly by python.
To fix it, we had to import a library for date in our python code.
After including it, the date-time portion was interpreted properly, and successfully matched with the data returned data from the database
We also continued working on the ordering system.
We created a page called Checkout Success, where the user would be redirected to upon the successful submission of his/order.
Meeting 48
05/04/2020 - Discord
We mainly focused on putting together our project report.
We created the outline for the document, with 7 sections, including 1) Introduction, 2) Problem Description, 3) Solution Approach, 4) Design, 5) Implementation, 6) Conclusion, 7) Appendix (Data Model, any testing data)
At first, we tried to find a template for our work. But not being able to find a good one for our purposes, we decided to custom template on our own.
As we started working on the sections, we realized how much we had to say about our project, our work, and our accomplishments.
We started with the introduction, and dived into the other sections.
We jotted down all the key terms we have been using throughout the semester, which acted as the skeleton for the report.
Then, we filled in each key term with examples and the justification for its use in our project.
We also talked about the approach we took for the solution, starting from the cloud based web application, up to the programming languages used.
One of our members worked on the testing.
He tested the userCustom.py function.
Most of the functions were utilized in our application. But there was a function that we never tested in Django. That is, there were functions that we did not use in our interface.
That function did not pass the test. It was the userPreferences() that saved the preferences of the user.
Meeting 49
We spent most of our time writing the report.
We expanded on our database structure and the primary reasons for our choice.
We justified our choice of the data model.
We also added the methodology on which our application development was based on.
The methodology was Agile, and its category was SCRUM.
We also justified our software choices, such as the backend and front-end programming languages we chose,
05/05/2020 - Discord
Meeting 50
05/06/2020 - Discord
We were informed by our client that the testing for views.py would be unnecessary, having the testing for urls.py
The reasoning behind it was that all of the functions in veiws.py are called via the path names found in urls.py.
That meant, testing a path name in urls.py would take care of the functions in the views.py.
Also, the only http request method we used in the views.py was the POST. We did not deal with the GET and DELETE methods, as they were unnecessary for our application. That meant that we did not need to create tests for those individual methods. The path names called the functions without making any further decisions whether or not to use GET or DELETE methods.
However, we still had the if statement that checked whether we were coming to the page from a POST request or not.
Meeting 51
We finished the testing for the urls.py file.
The good fact about that was that urls.py called every single module in views.py.
That meant that we did not have to implement another testing specifically for views.py
05/07/2020 - Discord
Meeting 52
05/08/2020 - Discord
We mainly worked on the report, going over what we had so far and reviewing our paragraphs.
We corrected several sentences, removing redundant ideas and adding complementary ones.
We also added diagrams to the appendix section.
The diagrams came from our ER Model and MySQL database.
We also provided a few screenshots of our tables to be able to explain application-related problems and solutions using references from the Appendix Section.
Other than the report, there was no application related discussion, nor implementation-relation conversation between the members.
As far as Software Engineering goes, we did not do any real coding or implementation.
Meanwhile, one of our members was working on finishing the testing of one of the modules, called submitOrder.