Workers Auto Approve
Lesson: Intro To Solidity
Build an Intro To Solidity Tutorial using the ChainShot [Builder](https://github.com/ChainShot/Builder) open-source IDE.
For more background information, I'd suggest running through a ChainShot tutorial on [the main ChainShot site](https//www.chainshot.com). This will help get a feel for how our tutorials currently run.
Also there's plenty of documentation on the [Builder](https://github.com/ChainShot/Builder), which is our open-source IDE that can create these tutorials.
All of ChainShot's content is stored [here](https://github.com/ChainShot/Content)
## Similar Tutorials
We've built an [Escrow Tutorial](https://www.chainshot.com/blocks/5c36bf15143eed0017f579755adab204929d249e5faefb4c/) for Solidity. We're looking for a tutorial that takes someone from scratch and walks them through concepts in Solidity.
We also have this [Solidity Buidlathon](https://github.com/ChainShot/Content/tree/master/projects/Solidity%20Buidlathon/Solidity%20v0.5.0) which has been used in Solidity workshops. It gives a pretty good example of how to start.
There are some ChainShot-specific terms we use. Should define these quick before jumping into the spec 😄
**Stage** - A set of Code Files and documentation that is combined to create a goal for the user. They should be given one or more code files that they need to change, and one or more test code files that have assertions and cannot be changed.
**Stage Container** (Building Block, Lesson, Challenge) - Every stage belongs to some stage container, which defines the tutorial/challenge. A **Challenge** is exactly how it sounds, less hand-holdy and more "demonstrate your knowledge" through a difficult problem. A **Building Block** is a tutorial that is built with the intention of creating a project; at the end the user can download the application they wrote. A **Lesson** is generally more esoteric. It is not necessarily a project that the user would continue, although it teaches concepts that will be useful to know.
More information can be found in the [ChainShot Builder Docs](https://chainshotbuilder.readthedocs.io/en/latest/).
**Expected Number of Stages** - Somewhere between 8-20. We aren't particular on this, however each stage should be have a very specific purpose. For instance, teaching how to write an array, or how to write a constructor or how to use the `require` function.
**Purpose/Theme** - Not necessary to have a common theme throughout, although it can definitely make the Tutorial more enjoyable!
**Target User** - Assume that the user begins with relatively little programming knowledge. They have never worked with Solidity before.
**Solidity Version** - v0.5.0
### Concepts to Cover
There are number of concepts we'd like to cover in this tutorial. They do not need to be covered in any particular order and it's not a *strict* list of concepts. It can certainly be used as a checklist, but feel free to use your own judgment.
1. **Basic Programming Concepts** - General programming concepts that carry over from other programming languages. Things like comments, operators and simple arithmetic.
2. **Contract Structure** - Explaining basic contract syntax. How to define the version, a contract and a constructor. Teaching functions and modifying state variables.
3. **Function Visibility** - Especially `public` and `private`. Explaining the differences between the two and how `public` creates a getter function. Mentioning that no data stored on the ethereum blockchain is currently truly private. `internal` and `external` for bonus points 👍
4. **Events** - Cover when events should be used and how to pass data through an event.
5. **Global Properties** - Not all global properties need to be covered, although the common ones should be. Among these `msg.value` and `msg.sender` should be utilized.
6. **Control Flow** - Loops, `if`/`else` and `return`. Potentially `break`/`continue`, not necessary.
7. **View Functions** - And how to return many values from a view function. Should mention the differences between a view function and one that modifies state.
8. **Value Types** - Not necessary to cover all value types. At least one type of integer should be covered, as well as `boolean`, `enum`, and `address` (perhaps when explaining how an address works?)
9. **Reference Types** - Should cover `array`, `mapping` and `struct`.
10. **Error Handling** - At least one exception function like `require`. May be good to introduce along with `msg.sender`/`msg.value` for security purposes.
11. **Payable Functions** - Should cover `msg.value`, balance transferring, and the `payable` modifier.
12. **Function Modifiers** - Creating their own custom modifier.
Setup your profile
Tell us a little about you:
No results found for
Type to search skills..
Required [[totalcharacter]] / 240
Are you currently looking for work?
[[ option.string ]]
Setup your profile
Our tools are based on the principles of earn (💰), learn (📖), and meet (💬).
Select the ones you are interested in. You can change it later in your settings.
I'm also an organization manager looking for a great community.
Enable your organization profile
Gitcoin products can help grow community around your brand. Create your tribe, events, and incentivize your community with bounties. Announce new and upcoming events using townsquare. Find top-quality hackers and fund them to work with you on a grant.
These are the organizations you own. If you don't see your organization here please be sure that information is public on your GitHub profile. Gitcoin will sync this information for you.
Select the products you are interested in:
Out of the box you will receive Tribes Lite for your organization. Please provide us with a contact email: