How I started my way as a NEAR developer

Introduction:

Hi all, my name is Bogdan and 3 months ago I started my way as a NEAR developer in the RUST language. This is my first text where I want to share my experience as a NEAR Certified Developer from scratch. I have no experience in development or learning programming languages, the only thing I was working with before was making SQL queries to unload data from tables when I was a tech support person.

Choice of language and blockchain:

The choice every aspiring developer probably faces is “What language should I even learn?” and I was no exception. I started to watch various YouTube videos about popular programming languages and the tops were Python, Java, JavaScript which I had heard about before and Rust which I knew nothing about.

Since I was a bit interested in cryptocurrencies and blockchain before that, I started looking into what languages this code is written in in general. The first thing I came across was Solidity which can be used to write contracts for Ethereum. After that I found out that all of the front-end is written in JavaScript, but it felt like I didn’t want to work with the front-end. The last thing I found was Rust, where I could write contracts for Solana and NEAR.

I decided to learn more about Solidity and Rust and started digging. At first I went to YouTube to find some basic information and listen to the pros and cons of each language. As often happens with videos like that, they mostly talked about the pros and cons, the only thing I can remember is that on one hand Rust will be hard to learn if it’s the first programming language, but on the other hand it’s good to learn as the first language because it has principles that make it different from other languages. It was also important for me to get the basic information translated into my native language, Russian, because I had no experience with that kind of book, and it was harder to understand all the information in English. So, after reading about what a great language Rust is and that all the developers are very fond of it, I decided to choose it.

Searching for the necessary information:

Looking for the very first information on Rust, I went to YouTube. There I watched several introductory videos for 2-3 hours each, but of course I didn’t understand any of them. After that I found several articles about how to start learning Rust and it came down to what to start with The Rust Programming Language, so I did that. After reading the book the first time, I started to understand a little bit about the concepts of Ownership and Borrowing, and realized that there are different types of data, structures and so on. So, that was it, and I had no idea how to write anything more complicated than Hello, World! What I found next was an article on how to “properly” read The Rust Programming Language in order to understand at least something about how Rust worked. It went something like this:

First read chapter 1, 3, 5, 6, then 4, then 8, then 4 again, then 10, then 8 and 4 again

and so on through all the chapters, constantly going back to the previous ones. After this reading I got a little better understanding of how Rust works and why it works this way, and I was able to understand and repeat chapter 2 of Programming a Guessing Game. That was the end of my basic Rust experience and I started to choose a blockchain for my code (I didn’t know that it’s called smart contracts yet). The choice was not difficult, between Solana and NEAR, and since there was much more information about NEAR, I chose it.

Choosing the NEAR Certified Developer course:

First of all I went to https://near.org/ and started researching what training opportunities there are in general, went to https://docs.near.org/ and started reading everything in order to form an understanding of how everything works here. After I read what I thought were all the basic articles and got a little familiar with blockchain itself, I started looking for something more applied. Something where I could not only read and watch ready-made examples, but also to start working with the first smart-contracts, deploy them and somehow interact with them in testnet. And I found Learn NEAR Club and NEAR Certified Developer course, I liked the tasks of this course and the fact that after finishing it I could get up to $500 in NEAR tokens.

I didn’t fit the audience it was meant for, but I was ready to spend more than 6 hours a day and was not limited in time to complete it, so I decided to take it.

First Step:

The first step, as I understood it, describes the general concepts of both cryptocurrencies in general and Bitcoin and NEAR. Since I really wanted to get to the practical part and I already read a lot of articles and watched the MIT course on cryptocurrencies before, I decided that I could skip this step and go straight to the second one.

Second step. Reading:

The first steps of this course are to read three contract reviews and in addition you can watch Live Contract Review videos, Illia’s contract repo and all Rainbow Hackathon contract submissions. As it says in the description of these activities

It took me about two days to understand the three contracts that are described in the CORE Activities section. And I spent a few weeks reading and understanding the contracts of BONUS Activities, so that the lines of writing would mean something to me, and not just letters on a screen. After that, I moved on to step three, the title of which reflected what I had wanted for so long.

Step Three. Writing:

Here it is, the long-awaited stage, when the interaction with the contract begins, albeit minimal, but you can already feel like a developer who makes changes in the code and something changes from it, even if it’s just the names of variables or changing gas values. So, VS Code is set up and the repository is copied (which also took me a few days). Finally I change the first value in the code, the name of the function new to initialization (it was the first thing that came to my mind)

try to build the contract and get a bunch of errors. After a few hours of figuring out why, I realized that there was no way to build a contract using PowerShell and I had to install the Windows Linux subsystem. I was able to solve this fairly quickly and the contract was built and tested and no problems appeared later on when making small changes. The next step was the workshop on Rust contracts (based on berryclub) from the BONUS Activities section, it took me a few more days, but no special problems I remembered. After that, I moved on to the next step.

Steps 4, 5, 6:

Since the next steps didn’t require me to confirm exactly what I was doing going through them I decided to flip through them and see what was next in the course. I saw exactly what was required to sign up for demo day and turn in a project and focused specifically on coming up with a project and doing it, skipping steps 4 and 5.

Choosing the topic of the project:

I went straight to https://docs.near.org/ and started looking at Examples there. Tutorials and Zero to Hero guides. The most interesting thing was to study Zero to Hero guides, I was determined to understand every line of code, so after reading each section I tried to write code that I figured out on my own. This greatly improved my understanding of how FT, NFT and marketplaces work and my understanding of smart contracts in general.

Initially I wanted to implement a marketplace project, but to come up with something new or at least something that I have not seen in other marketplace contracts I could not and so I continued to look further and one evening I found a contract with a lottery I was wondering how it works and what I could do with it.

While I was working on that contract and simultaneously studying Master NFTs on NEAR, I had an idea to combine those two contracts and make a site similar to Patreon, where users could support content makers and get something in return.

I saw it this way, using an example: a drummer who puts out videos on YouTube creates an NFT collection, people who want to support him mint NFTs from that collection and every 5 new NFTs for example are raffled off, the winner gets to interact with the content maker somehow, like offer a topic for the next video or get a lesson with that drummer.

Implementation:

Since I was already familiar with the NFT contract, making the necessary changes to it in the form of collections, series, and lazy minting wasn’t difficult, but it still took me a long time and even simple changes like that took me days at a time.

Things were much more complicated with the lottery contract, initially it was a huge contract with several kinds of lottery itself, a participant whitelist, and different kinds of tokens that were accepted to participate.

In my case, most of that functionality wasn’t needed, so I started to clean it up, but it was quite a challenge to remove everything that wasn’t needed so that nothing would break. At first I removed all kinds of lotteries and left only the one that suited me, it was easy, and when I removed the last error that was highlighted by VS Code, rebuilt the contract, checked that all the tests pass, I redesigned the contract, but nothing changed. And then, with the seemingly simple problem I was stuck for a few days, because I didn’t know what it could be and where to look.

I checked the whole code several times from beginning to end, everything was fine and should work correctly. Deploy the contract to different accounts, rebuild contract a few times, deleted the target folder, built the contract again, googled a lot and noticed that the file Cargo.toml my old version rand = “0.7.3” and need to change it to “0.8.5”

which I did, after that contract is no longer built, but I thought that the problem was this and started looking to fix it. I spent half a day in Google and found a random function to replace the one that was in the contract, but still nothing worked and the contract was not created. I tried to solve this problem for three days and was almost in despair, but I found a man who could advise me and he explained that the random function in the blockchain is a very complicated thing and I should revert the contract and the old version rand = “0.7.3” was correct.

After I put everything back, I deleted the target folder again for some reason and this time for some reason decided to delete .wasm file from the res folder, rebuilt the contract and it was a miracle, all the changes applied. I understand that the problem was in .wasm file, but why it was not updated, I have not understood and never had such a problem.

Since I understood the lottery contract very well during those two weeks, making the other changes was no problem and did not take much time.

The next step was to write cross-contract calls between NFT contract and Lottery contract, I had two weeks for that before the Demo Live session in January, when I wanted to hand in the finished project.

I spent two days finding and view as many examples of cross-contract calls as I could, I’ve looked everywhere – at the NEAR YouTube channel, examples on https://docs.near.org, and many examples of cross-contract calls in different contracts on GitHub. The basic examples were easy to understand, because there were plenty of examples and they were explained in great detail, but writing the cross-contract calls I needed for my project was much harder. After that I tried to write cross-contract calls similar to the basic example described in the tutorial and got nothing, but this time the same thing didn’t work either. The next step was to write to the NEAR developer chat room, they suggested me several code examples where I could see the similar solution and use ChatGPT to make the “skeleton” of the function

the bot produced the same solution, as I wrote, when I took the cross-contract call from the NFT contract. But using this skeleton I got a compilation error, which I couldn’t fix.

After 12 days of trying to write this cross-contract call I failed and decided to show only the lottery contract at the Demo Live session.

Demo Live session:

This was my first experience with this type of call and I didn’t know what to expect. I was very unsure if the lottery contract I had written was enough and if I was ready to show the results of my work. The day before Demo Live session I found a playlist on YouTube with recordings of previous demo sessions and the projects shown there seemed to me much bigger and more complicated than mine, with good presentations and ready front-end, as you understand I didn’t have it. And knowing myself, knowing that I usually want to do everything perfectly, which most often leads to the fact that in an attempt to achieve perfection I can stop doing something and decide that my project is not good enough to show it to someone, I decided that by all means conquer my fear and show everything as it is, hear some criticism and keep moving forward. With these thoughts in mind, I sat over the presentation text until four in the morning and was ready to turn it in at eleven in the morning.

I slept very badly all night, was very nervous and tried to recover somehow before the presentation. I woke up at 10:30 and was ready to hand in the project, but then I noticed that the Demo Live session started at 11 a.m. Canadian time and I had it at 8 p.m. At first I was upset because I would have to spend another 9 hours in excitement and anxiety and I decided to go over the presentation again and when I started to do that I was very happy that the presentation wouldn’t be until 8pm. I saw a lot of errors in the commands I had to call as I went through the presentation. The constants were written with a “__” which caused an error when calling the functions and the subaccounts I was supposed to call the payable functions from had run out of balance in the previous tests and in the time left until the presentation I was able to fix them.

The presentation went great, I was the first one to give my project, so I didn’t feel the pressure that I would have felt if I had seen the projects that were halfway through. After I showed and talked about my project Sasha asked me some questions and gave me his feedback:

“This project doesn’t have a bright future in the mainnet, but for three months of study, it’s a good result, don’t you want to write an article about it?” Which I did.

Conclusion:

In conclusion, I would like to say that during these three months there were many problems that seemed unsolvable. There was a lot of joy when these problems were solved. I have a much better understanding of what code is and how to write it. How NEAR blockchain works and what its benefits are, got development experience and a big boost of motivation to keep it all going. And if you’re in doubt about whether to start the NEAR Certified Developer course, even if you have no experience at all, definitely yes, you should. You have to be prepared that it can take a lot of time and effort, but it seems to me at the beginning of the path it is one of the best ways to learn something. And I’ve got plans to continue studying, to figure out these problems and