# \[Report\] Tutorial Repository for developing Near Contracts in Rust (april 08-\> april 15 2022)

**URL:** <https://gov.near.org/t/report-tutorial-repository-for-developing-near-contracts-in-rust-april-08-april-15-2022/19006>\
**Category:** Fellowships\
**Tags:** weekly-reports\
**Created:** [April 16, 2022, 12:18pm UTC](https://gov.near.org/t/report-tutorial-repository-for-developing-near-contracts-in-rust-april-08-april-15-2022/19006 "2022-04-16T12:18:13Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![On0n0k1](https://dub1.discourse-cdn.com/flex005/user_avatar/gov.near.org/on0n0k1/32/14062_2.png) [@On0n0k1](https://gov.near.org/u/On0n0k1)\
**Post date:** [April 16, 2022, 12:18pm UTC](https://gov.near.org/t/report-tutorial-repository-for-developing-near-contracts-in-rust-april-08-april-15-2022/19006/1 "2022-04-16T12:18:13Z")

</div>

**Project Title:** New Full Tutorial for Near in Rust.

**One-liner:** Tutorial Repository for developing Near Contracts in Rust

**Project Summary:** : There are many great tutorials about creating NEAR contracts in Rust. This project isn’t intended to be a replacement to any of those. Instead, it will be detailed examples about the features of Rust using NEAR contracts. Several times when the compiler gives an error, a new developer may feel compelled to just try making changes until the error go away.

This tutorial will show all possible implementations for all kinds of features in rust. Including ownership, modules, traits, generics, enums and so on. That way it can work as reference for aspiring rustaceans.

**Project Members:** Lucas Lemos, Matias Wald

**Period:** April 08 → April 15

**Extra** : Project has the main branch in Brazilian Portuguese. Translations to English and Spanish are also being made by Matias Wald.

The following list are the results obtained by me:

# Week 10

- Finished writing the code for lesson 6-2 thermometer. Need to write unit tests and the lesson Readme next. But this lesson is looking really good. Here are the topics it show:
  - Using enum to manage input/output for functions;
  - Using serde to manage how data is stored/displayed;
  - Storing data in trie using LookupMap, Vector and UnorderedSet;
  - Managing user access and permissions in the contract. “Who can access what”;
  - Adding functionality to custom types by implementing standard library traits. E.g. `From`, `std::fmt::Display`, `Default`, `PartialEq`, `Eq`.

- After finished with this lesson’s unit tests, documentation and lesson Readme, I’m considering sending it as an example for NEAR University Learn NEAR repository group;
- I created this contract with the intent of it being practical and usable in production environment. Just compile my project and use it for your embedded devices as you please. Making whatever changes you need (It’s MIT License).

Here’s a summary of how the contract works:

- Deploy your contract to one of your accounts;
- Create one NEAR account for each of your embedded devices;
- Only the owner is allowed to make function calls on the contract. But you can allow other accounts by calling the function `allow_user '{"account_id": "your-contract-name.testnet"}'`.
- Each allowed user has it’s own Vector of entries. The owner can read all the entries. But each user can only add and list their own entries. Only the owner can delete entries.
- Owner can call the function `set_format '{"temp_format": "Celsius"}'` to change the default temperature format to “Celsius”, “Fahrenheit” or “Kelvin”. Default format is “Kelvin”.
- Each entry is added to the Vector associated with the **predecessor’s account ID**. It must have a value of **Temperature**. **Temperature Format** is optional. **Time** is optional. **Date** is optional. If **Temperature Format** is omitted, use current system format. If **Date** or **Time** are omitted, use current date or time.
- Add entries with function calls like:
  - `new_entry '{"value": 10}'`;
  - `new_entry '{"value": 10, "format": "f"}'`;
  - `new_entry '{"value": 10, "format": "Kelvin", "date": (2022, "feb", 20), "time": (18, 30, 44, 0.543412314) }'`;

- If the system has a different temperature format to the message. Convert it before storing. If the system’s temperature format changes. It will only convert stored values when retrieving.
- See all entries for an account with `list_entries '{"account_id": "my-account.testnet"}'`. If `account_id` is omitted check own entries. Only owner is allowed to check entries for other contracts;
- Clear entries for an account with `clear_entries '{"account_id": "account_name.testnet"}'`. Only owner may call this function.
- Remove a user with `remove_user '{"account_id": "account_name.testnet" }'`. Only owner may call this function. I just realized that I didn’t forbid the contract from deleting the owner’s account. Will have to change that.
- Time stored is treated as UTC. Maybe I should add functionality for changing time formats the same way we change temperature.