Join our Peer Programming Call-In
We have a bi-weekly Peer Programming Zoom call for developers on Mondays at 9 AM US Pacific time (UTC-07:00 America/Los Angeles.)
We're currently implementing the Utility Emissions Channel use case together.
If you're interested, please check the calendar for the next call.
- Access data from several permissioned channels.
- Use standard model-factors to calculate emissions from the data.
- Record the emissions results on a permissioned channel for the next entity to consume.
- Minimalist apps which
- run as serverless micro services, for example on Amazon Lambda or Cloud Functions from Google or IBM;
- pass through customer authentication keys to the permissioned channels
In each process, it will simulate the roles of:
- Data source, which provides product use data
- CO2 emissions auditor, which calculates CO2 emissions from the product use data
- Data consumer, which uses the CO2 emissions data to calculate their own emissions, purchase offsets, etc.
The MVP will allow self-contained carbon emissions calculators for different purposes, as well as simulate how carbon emissions data could be shared across a supply chain with multiple parties.
Potential data sources include:
- Utility bills
- Shipping data
- Travel data
- Vehicle trip data
- Renewable Energy Certificates
- Carbon offsets
Think of each of these data source as a "programming primitive." On their own, they're just data. But combined together, we could build a variety of interesting applications, such as:
- Virtual Community Renewable Energy Network
- Virtual Zero Emission Travel Network
- Personal Carbon Offsets
- Data Center Carbon Calculator
Each of these applications could empower a group of people to work together and take positive climate action, without waiting for a central authority to step up and regulate things.
What we need is more ideas, both of where to obtain emissions data and what kind of applications could be built with them, so please write if you have any suggestions.
Even though, or perhaps because we're building open source software, code quality is very important. We're writing code that others would see long after we're finished, so we'd better leave them something they could actually understand and work with. We'd also like to avoid being featured in an "Anti Pattern" book or blog post.
The most important coding standard is to keep things very modular, so separate each function as much as possible. The UI and application logic must be completely separated, to the point of being separate projects, and talk to each other only through clearly defined (REST) API's. This means that we could have several different UI's, like Linux. It also means we don't start putting our business logic in the UI, like some PHP or JSP code did. Similarly, different application domains such as user management, application logic, and standards data management must be kept apart as well.