MySunBuddy is a peer-to-peer platform to facilitate the purchase and selling of solar net metering credits.

In previous challenges we built the backend code and HTML  prototype.

The scope of this challenge is to hook up the provided AngularJS HTML prototype with the provided python backend code.

Challenge Requirements

Gitlab Repo

• - https://gitlab.com/tc-sunshot-r2/ss2-my-sun-buddy Please check challenge forums to get access.

• - REST Api application with sample demo pages that demonstrate the functionality we implemented https://gitlab.com/tc-sunshot-r2/ss2-my-sun-buddy/tree/master/mysunbuddy-backend-app

• - Prototype https://gitlab.com/tc-sunshot-r2/ss2-my-sun-buddy/tree/master/prototype

• - As part of this challenge, if there is any backend issue or bug or missing requirement, you will be required to address it.

Models Update

There are new data to collect in the provided UI prototype that we did not currently catch in the provided backend application, you need to address this in this challenge.

User Model

• - Name: This store the user full name.

Mapping Model

• - price_per_kWh : represents a float value (i.e can be between 0.1 and 0.9)

• - ghg_factor : represents the greenhouse gas impact on co2 factor used to calculate the GHG impact.

Deal Model

• - saving : this calculate saving in the deal.

• - ghg_impact : this is the calculated GHG impact on co2

• - document_id : represents the signed docuSign id associated with the deal.

• - start_date : represents the deal approval date.

• - end_date : represents the deal end date.

Partners Matching Job Scheduler Update

• - match_script.py is used to match partners.

• - Update signup method to execute this script after each each new registration.

• - When we found matching we want to assume the seller agreed on the sell, so store the status PENDINGBUYER to show the deals in buyer dashboard right away.

• - Also for some matchings we want to make them as completed deal. so the job will generate PENDINGBUYER deals and completed deals for the new buyer.

• - You need to do the following update to this job scheduler to calculate the new Deal fields:

  • - saving field :

    • - Formula : deal#quantity * mapping#price_per_kWh * DISCOUNT

    • - DISCOUNT is configurable value, use 0.15 in this challenge.

  • - ghg_impact field :

    • - Formula : deal#quantity * mapping#ghg_factor

Pages and Functionality Requirement

• - Landing Page

  • - Page : #/Landing

  • - This page will contain static content and mainly used to navigate to signup and signin.

• - Sign In Popup

  • - Clicking on Sign In on header will open up the Signin popup.

  • - Use /api/login endpoint to process login.

• - Signup : Seller Steps Wizard

  • - Page : #/Sign_Up_Seller

  • - The registration wizard will collect all information then store it in backend when clicking on “Next” in “Finish” step.

  • - Use /api/register endpoint to register the user, refer to the backend to see what fields we are passing. Role to be passed in this flow is SELLER.

  • - Clicking on “Calculate solar production” button logic :

    • - The three fields top of the button must be provided otherwise show error.

    • - Call GET api/credit/calculate to calculate solar production for the seller by passing the three fields values.

    • - When popup opens up, the 100% will present the total calculated value return from json, display the calculated value below the range field, user can change the range, value will be updated accordingly, when user close it the “Net Credit to Sell” % value will be updated to match the value selected.

• - Signup : Buyer Steps Wizard

  • - Page : #/Sign_Up_Buyer

  • - The wizard is same as Seller Steps wizard, we collect few different fields/information, it will create user in “Finish” tab and will use same endpoint, except we will pass different fields as shown in backend, and role = BUYER.

• - Buyer Dashboard

  • - Page : #/Buyer

  • - Retrieve current user information from “GET /api/account” endpoint response when page loads.

  • - Usage Section

    • - Usage : Use Dummy Data, assume it is 2.5KW.

    • - Initial State : Use Dummy Data, assume it is 10KW
      

  • - Summary Tab

    • - Summary section :
      

      • - We need to update the GET /api/account to include these three values in response.

        • - Savings : should be aggregated deal#saving field from all completed deals of current logged in user.

        • - GHG impact : should be aggregated deal#ghg_impact field from all completed deals of current user

        • - Purchased : should be aggregated deal#quantity from all completed deals of current user.

    • - “We found X matches in your area” section and table

      • - Endpoint to use will be /api/deals?&pending=1

      • - Use “count” field from response to render “X” in “We found X matches in your area”.

      • - The table will render the deals returned

        • - Buy button : this one will call /api/deals/{id}/approve endpoint where id is the deal “id” json attribute. On successful approve ajax call display a popup saying “Match complete!”

    • - “ Google Map”

      • - Display sellers addresses will be retrieved from endpoint GET /api/deals/sellers

      • - Display buyer house address.

    • - “Current Percentage of your bill to buy.” section :

      • - The large circle chart is set using “credit_to_buy_percent” json field from  GET /api/account endpoint

      • - kWh : Represents the monthly usage (dummy) * credit_to_buy_percent value.

      • - Price : Represents kWh * the mapping#price_per_kWh of user load-zone/zipcode area.

      • - GHG Impact : Represents the kWh* mapping#ghg_factor of user load-zone/zipcode area.

  • - MySunBuddy Buyer Tab

    • - The table is loaded using GET /deals endpoint, it loads completed deals.

    • - Table will render returned deals.

• - Seller Dashboard

  • - Page : #/Seller

  • - Retrieve current user information from “GET /api/account” endpoint response when page loads.

  • - Usage section :
    

    • - “Left %” = credit_to_sell_percent - sold credits of all deals current month.

    • - “Contracted”  the sold credit this month from all deals.

    • - Update “GET /api/account” endpoint to calculate the above two values and set them in response.

  • - Summary Tab

    • - Earning Section
      

      • The values map as follow :

        • - “Pending value of monetary credits” : represents the total (deal#price) active transactions of current month.

        • - Earning to date : this should aggregate the total deal#price of completed deals.

        • - Capacity Sold : this should aggregate total solar power ‘deal#quantity’ sold in all completed deals.

      • - Update “GET /api/account” endpoint to aggregate the above three values and set them in response.

• - “We found X matches in your area” section and table

  • - Endpoint to use will be /api/deals?&pending=1

  • - Use “count” field from response to render “X” in “We found X matches in your area”.

• • - “ Google Map” Section will be same as Buyer google map.

  • - “Current Percentage of solar production to sell” section :

    • - The large circle chart is set using “credit_to_sell_percent” json field from  /api/account endpoint

• - MySunBuddy Seller Tab

  • - The table is loaded using deals?limit=10&offset=0 endpoint, pagination should be passed, so it is progressive loading ajax.

Test Data

Provide test data for the solution.

Test Scenario 1

• - Buyer register

• - Buyer login

• - Buyer navigate to dashboard and see list of matches

• - Buyer click “Buy” and get “Match Complete!”

Test Scenario 2

• - Seller Register

• - Seller login

• - Seller navigate to dashboard and see list of matches

• - Seller click on “Sell” and get “Thanks! Notification sent to buyer!”

Technology

• - Python version 3.x running on Ubuntu

• - Postgres 9.4

• - Django 1.8.x

• - AngularJS

• - Bootstrap

Abstracting and Design Patterns

Please make sure to create helper/interface to include the common code/functionality.

Also please make sure your design is flexible, use facade design pattern and adapter design pattern (and any other proper design pattern) to enable future extensibility of the solution.

Coding Standard

Follow python coding best practices : PEP 8 for the main text, and PEP 257 for docstring conventions

Documentation

Your solution must be well documented.

Readme

Provide a detailed readme file using Markdown language with following information :

• - Overview

• - Setup Prerequisites

• - Configurations

• - Deployment

• - Any details about any limitations of your solution.

Please note, we're judging this competition not just on the code, but also on the quality of the documentation, and ease of use.

Final Submission Guidelines

Deliverable

• - Git patch file of changes.

• - Deployment document with verification steps