This project aims to create a two sided marketplace where people can rent unused snow gear from the many people that own gear and do not use it for the majority of the year. This will allow snow gear owners to earn extra money by putting their unused assets to good use. Most rental gear that is available in normal shops are of bad quality from the lack of care and high use of each item. They also use cheaper components than someone would buy for themselves.
- Multiple users supported with personal profiles that can be edited.
- User profile page shows all the listings of that user and average rating of all the user's listings.
- Ability to upload profile image that is used throughout the site.
- Can create new listings to be able to rent out ski or snowboards. These can be later edited or deleted.
- Ability to upload multiple images for each listing. Shown using a carousel on the listing page.
- Can book a rental using stripe payments that allows refunding / cancelling of future dates.
- Allows for rating of each listing after the rental period has finished. Author of review has option to edit or delete.
- A lister can also choose to refund any booking if needed.
- Shows all reviews of each listing and user including average rating to help with selection.
- Can track all your bookings that include both as a renter and a lister.
- Can filter listings based on city, available dates, category, type, size and brand.
- Uses pagination to limit how many listings are shown per page. Can change the limit amount.
- Responsive website design to allow for all screen sizes.
- HTML5
- CSS3
- Javascript / JQuery
- Ruby on Rails
- Bootstrap 4
- Heroku
- AWS - S3 Bucket
- Clone this git repository
git clone https://github.com/dav-armour/sloper
- Navigate into directory
cd sloper
- Install required gems
bundle install
- Create database, run migrations and seed database with sample data.
rails db:setup
Optional: If you do not want seed data
rails db:create
rails db:migrate
- Start the rails server
rails s
- Open web browser and goto http://localhost:3000
Initially, we did some research into existing rental product p2p apps to draw UI inspiration. Due to budget and time constraints, we did very little (read: none) external research into user pain points. Looking at competitor offerings,we determined that it was essential to allow the user to search for items on the landing page, for that is the main reason why users would visit the site.
We then designed the wireframes for the site look on Balsamiq, before working on our ERD.
We then looked through colour inspo. Our colour inspo board can be found here: colours moodboard.
We reiterated over the ERD, wireframes and site colours multiple times over the course of the assessment.
- Day 1
- Brainstorm ideas
- Do wireframes
- Come up with colour scheme
- Work on short answer questions
- Set up trello board
- Decide on MVP features
- Day 2
- Create ERDs
- Start coding
- Implement basic devise
- Add bootstrap
- Day 3
- Implement carrierwave and AWS set up
- Set up models
- Create database seeds
- Day 4
- Work on creating and showing listings
- Create booking system
- Implement stripe
- Day 5
- Improve seeds
- Finish booking system
- Day 6
- Implement filters on search
- Add reviews
- Day 7
- Add images to seeds
- Finish implementing features
- Day 8
- Add email for forgot password
- Start styling
- Finish testing
- Styling
- Day 9
- Finish styling
- Prepare documentation
- Code comments
- Day 10
- Presentation
- Submit assignment
- As a user I want to be able to sign up so I can rent and list gear.
- As a user I want to be able to login with my existing account.
- As a user I want to be able to retrieve my password if i've forgotten it.
- As a user I want to be to change my password.
- As a user I want to be able to find gear to rent based on location and specific dates so that I can find the gear I need.
- As a user I want to be able to list my gear with photos, pricing, specifications and information about my gear.
- As a user I want to be able to make and recieve payments after renting gear.
- As a user I want to be able to leave a review about my experience renting gear from another user.
- As a user I want to be able to edit my profile to change my photo and details.
- As a user I want to be able to view another user's profile to view their user rating, available listings and their reviews.
- As a user I want to be able to find the answer to frequently asked questions.
- As a user I want to be able to learn more about how the rental and listing process works.
- As a user I want to be able to contact Sloper through email or social media.
- As a user I want to be able to filter my results based on specific item details.
- As a user I want to be able to view a lister's last login to filter out inactive listings.
Link to User journey workflow diagram
Link to ERD (Open with Draw.io)
People need a place to rent cheap snow gear. Snow gear owners need a place to make extra money from unused items.
2. Identify the problem you’re trying to solve by building this particular marketplace App? Why is it a problem that needs solving?
The average vacationer only uses their snow gear for a few days per snow season, yet it is an essential part of their experience. There is also a large supply of snow gear owned by individuals which is unused for the majority of the year. Additionally, rental gear found near ski resorts tend to be of varying quality. We are aiming to connect owners of unused gear with vacation-goers who prefer to rent higher quality privately owned equipment.
The project will be a two-sided marketplace that will allow users to rent other user's snow gear, and also list their own snow gear for other users to rent. Renters will be able to search for all available gear based on the location of the renter, the desired pick-up and drop-off times. Listers will be able to make a listing for their available gear with photos, gear specifications and additional information.
Amazon AWS will be used to store images in an S3 Bucket. Heroku is where the app will be deployed and the postgresql database stored. Heroku is a cloud platform used to host web applications. It provides our website with a domain name and DNS to allow people to access our site.
The App uses Ruby on Rails with a postgresql database. Carrierwave gem used to allow uploading images to AWS S3 Bucket. MiniMagick gem also used for processing images. Devise gem used for user management.
PostgreSQL will be used for the database as it provides a lot of functionality. In comparison with SQLite, the default database management system bundled with Rails, PostgreSQL provides the critical ability to perform multiple writes into the server at the same time. Also, since PostgreSQL is widely adopted, open-source and completely SQL standards-compliant, searching for solutions for our app would be much easier. In particular there were a few functions of PostgreSQL that we used extensively throughout our site:
- Nested querying
- Eager loading
- Fuzzy searching
Postresql database will be used in production as it is hosted by Heroku. This will be a seperate database to development / testing.
Our app is structured as a layered, multi-tiered architecture in the form of the MVC framework. This can be separated into the presentation layer (view), logic layer (controller) and the data layer (model). At the core is our data layer (model), which stores and retrieves information using a database. This information is both provided and requested for by our logic layer (controller), which handles basically all of the calculations and decision-making for our app. The controller is also responsible for moving data to and from our model and view. Our presentation layer (view) is responsible solely for interacting with the user by transforming data from the controller into a user-friendly interface. Additionally, our app utilises rail's web framework. Users interface with our app via a web browser, with CRUD requests being sent through to our web server. We are currently using Puma as our web server. Puma interprets the requests and routes them through to our app's controller, Action Controller. Ultimately, when data is returned from our view it is sent through to the web server before being passed on to the user's browser.
Rails employs a Model View Controller (MVC) architectural pattern. In accordance with the design principle of 'separation of concerns', each component (model, view and controller) handles a specific set of actions for our app.
As such, Action Controller handles the requests after determining which action to take from our controllers. Our controllers communicates with both our view and model components.
Rails uses Active Record in the model layer. It is responsible for creating and maintaining persistent data required for our app by interacting with our database. We used a PostgreSQL database as it allows for multiple writes simultaneously.
Minimal logic is present in our view layer, which takes data instantiated by our controllers, transforms it and applies a layout before sending it to our web server, Puma, which ultimately passes the end result to the user's browser.
- AWS - S3 Bucket used to store uploaded images.
- Stripe - Used for taking payments from users.
- Mailgun - Transactional email API for generating forgotten password emails
11. Describe (in general terms) the data structure of marketplace apps that are similar to your own (e.g. eBay, Airbnb).
In essence, we are a peer-to-peer product rental app, and thus our data structure resembles other product rental apps such as ToolMates for tool renting, Spinlister for bike lending and Turo for car renting. Users can sign up with the personal information and have the ability to both add new products as well as search through and access products listed by other users. Once a booking is confirmed, the booking details are stored in the database and the product is unavailable during that timeframe.
We will be using two database relation types in our app.
- One to One
- This is used when 1 record in 1 table relates to only one record in another table. To set this up in rails one model needs to be given a belongs_to relationship and the related model needs to be set to has_one. Example: One booking can only have one review
- One to Many
- This relationship is used when a single record in one table has many related records in another table. This is achieved by using belongs_to and has_many in the rails models. Example: One user can have many listings.
- Many to Many
- This relationship was not needed for our application. It allows for records in table A to have many related records in table B and vice versa. Example: A student can have many classes and classes can have many students.
13. Describe your project’s models in terms of the relationships (active record associations) they have with each other.
- User Model - Stores user information
- Has many Listings
- Has many Bookings
- Listing Model - Stores details of each listing
- Has many Bookings
- Has many Renters through Bookings
- Has many Listing Images
- Has many Unavailable Days
- Has one Location
- Booking Model - Stores transactions when user rents a listing
- Belongs to User
- Belongs to Listing
- Has one Review
- Location Model - Stores geo data of listing location
- Belongs to Listing
- ListingImage Model - Stores all uploaded images of the listing
- Belongs to Listing
- UnavailableDay Model - Keeps track of what days each listing has been rented
- Belongs to Listing
- Review Model - Users can leave a review after renting an item.
- Belongs to Booking
- Has one User through Booking
Link to ERD (Open with Draw.io)
- As a user I want to be able to sign up so I can rent and list gear.
- As a user I want to be able to login with my existing account.
- As a user I want to be able to retrieve my password if i've forgotten it.
- As a user I want to be to change my password.
- As a user I want to be able to find gear to rent based on location and specific dates so that I can find the gear I need.
- As a user I want to be able to list my gear with photos, pricing, specifications and information about my gear.
- As a user I want to be able to make and recieve payments after renting gear.
- As a user I want to be able to leave a review about my experience renting gear from another user.
- As a user I want to be able to edit my profile to change my photo and details.
- As a user I want to be able to view another user's profile to view their user rating, available listings and their reviews.
- As a user I want to be able to find the answer to frequently asked questions.
- As a user I want to be able to learn more about how the rental and listing process works.
- As a user I want to be able to contact Sloper through email or social media.
- As a user I want to be able to filter my results based on specific item details.
- As a user I want to be able to view a lister's last login to filter out inactive listings.
- As a renter I want to be able to receive lister's confirmation before payment
- As a user I want to be able to reply to a review about me left by another user.
- As a user I want to be able to slide into another user's DMs.
- As a user I want to see where the item is located on a map.
Trello will be used for project management. As all of our tasks are listed in our Trello backlog, we assigned progress-critical work between ourselves and prioritised that while pulling whatever else we wanted to do next down from the backlog to our current sprint. Tracking is done via Trello as well, as tasks go through the phases Work-in-progress, In Review and Done throughout the task's lifecycle.
As per agile methodology, we broke down the entire assessment into small user stories, which were then sorted by importance on Trello. We assigned tasks based on what needed to be completed next and added them to our current sprint, which would then be gradually completed throughout the day. Completed tasks would be put into review, and if everything was fine it would be marked as done. If the task remained incomplete, we would discuss it during our standup the next morning regarding difficulties and whether it needed to be broken down due to unforseen work, before being reassigned and worked on again.
Each team member will be working collaboratively on the same git repo hosted by GitHub. Seperate branches will be used by each person and pull requests used to merge them together. One team member will be in charge of all pull requests and merging. SourceTree and GitKraken is used to make this process easier by provide a GUI for git related commands and keeping track of repo visually.
After pulling from our development branch to our local branch before pushing to github, we would test the newest changes added by other team members between our pulls. We also maintained a google spreadsheet with test cases, expected results and actual results for each user action on the site. This was tested before and after deploying to Heroku. All forms were tested with valid and invalid data to ensure that errors were handled correctly and no unauthorised actions could be taken. Link to spreadsheet
- Webpage form inputs must be sanitised or validated before being passed through to the database as malicious code in the form of an SQL injection can both harm the database and retrieve database information.
- Passwords cannot be stored as plain text for a website as it is not secure. Any user with access to the database can also access all passwords stored on the site. The most common form of security for a password is hashing the password.
- Any transmission or storage of payment data must be subject to the most stringent security available as it is extremely sensitive data. There are multiple technologies that have become the standard to ensure secure payment processing. these include TLS (transport layer security), PCI (Payment Card Industry) compliance, and tokenisation of ID authentication.
- To protect against SQL injection attacks, we validate our form fields, as well as sanitizing our parameters before they are passed to the model.
- The use of Rails ORM when querying the database also stops any potential SQL injection.
- Rails forms also use a CSRF token that stops any attempts at cross-site forgery requests.
- Using Devise's default settings, all user passwords are hashed using BCrypt.
- Our app neither handles nor stores payment data. All payments go through Stripe, which forces TLS encryption, PCI DSS and tokenisation. Our app only store the payment ID in our database as a payment reference.
As per Australia's privacy laws, and in accordance with Google's requirements, our website needs to include a privacy policy. For each piece of personal information, we would need to include:
- the type of data
- our purpose for the data
- how we collect and store the data securely
- a promise to not disclose emails
- how a user can access, change and remove data
- whether data is disclosed to other parties
- our contact details
- privacy complaint handling