Catching up

If you read my first post, you may recall that I began the process of creating BridgeBurner back January, when I started laying out the DApp’s initial structure following a Twitter brainstorm session. From then until I began this series in April, I had been coding BridgeBurner behind the scenes. But like with many side projects, I had to put the project on the backburner when things got busy. Which leads to my next point: you as the reader have some catching up to do. Or rather, I need to work hard to get you caught up to my current progress on the BridgeBurner smart contract.

As I’ve previously mentioned, this series is about sharing our experiences as a community. I intend for this blog to follow BridgeBurner’s development. I’d like for us to be able to work through problems as a community, but that can’t be done until everyone is on the same page. So in order to keep things moving at a good pace, I’ll have to be brief at times. I’m still trying to strike the right balance for this series, so just let me know if things aren’t working for you.

Community-sourced resources

Instead of writing the end-all-be-all of learning Solidity step-by-step, I’ll try to include existing guides and tutorials that the community suggests to me. Today I’d like to thank @abcoathup for suggesting Zeppelin’s smart contract tutorial game, The Ethernaut. I’ll have to check that one out for myself and report back to you! Zeppelin’s blog also has a Guides section that’s a great resource for understanding Solidity. You might also want to check out EGS Garage with Chaz #2 for tips on how to learn Solidity.

Getting started with BridgeBurner

With my initial idea fleshed out a bit thanks to Twitter, I was eager to begin production. The amazing part about working with open source software is that a lot of times you don’t have to reinvent the wheel to get things done. When I first sat down to take the first crack at BridgeBurner, I decided to model it after Paul Berg’s ERC-1620 standard.

ERC-1620 is a standard for streaming money; it allows you to pay someone else continuously over a given time period. When you open a money stream using the ERC-1620 standard, you set the rate (amount and frequency) you’re willing to pay and the duration of your payments. For example, you could set it to pay a contractor 50 Dai every 300 blocks in order to simulate an hourly rate. I figured that I could use the ERC-1620 standard as the “burn mechanism” for BridgeBurner by streaming money to a burn address.

After figuring out how I would execute the core function of the smart contract, the next step was to adapt the standard to my needs.

Don’t fall for the copypasta trap

At that point, I fell into the pitfall many newbies fall into. After finding the solution to my problem, I simply copied the solution instead of implementing it. You might be asking: what’s the difference? The key difference is your level of understanding. While it is true we all learn by imitating, you can take it too far.

In my case, I wrongly assumed that dates put into BridgeBurner would be their own struct alongside ERC-1620’s streams. Only after I spent time duplicating and translating each variable and function of streams into my dates struct did I realize that this approach wouldn’t work. My eagerness to get the project off the ground prevented me from seeing the forest for the trees, and now I had to backtrack. I could have saved time by pausing to think about how inheritance works in smart contracts and how ERC-1620 streams would fit into BridgeBurner’s contract.

If you’re not familiar with the concept of inheritance and migration in smart contracts, don’t worry. I’ll come back and cover that in a future post. For now, the important lesson is to stay focused on the big picture. And if you think you’ve found a shortcut, it pays off in the long run to take the time to think things through before charging forward.

Writing the first line of code

The first tool you’ll need to get started is an IDE, which is an editor where you can write, test, and compile your Solidity code. You can find some options by searching for “IDEs/Editors” in this list of resources created by ConsenSys. You might want to bookmark that page, because we’ll keep referring back to it throughout this series. I personally started off with Remix, an IDE that works in the browser and stores your files locally. I also created a GitHub repo for BridgeBurner.

Using Remix and GitHub let me work on BridgeBurner from anywhere. I would plug the code into Remix, work while bored in class, and then submit the changes to the GitHub repo. This worked great for me until I had to set the project aside for a bit.

Take the time to get set up, and comment liberally

When I came back to the code after a few weeks, I couldn’t remember which laptop had the local files in its Remix. My code also had a severe lack of comments, which made it hard to reorient myself. To avoid wasting time searching computers and your memory, I’d recommend you make a specific folder for your project and write lots of comments outlining your plan as you go along.

You could even start working on your smart contract by creating a comment outline including pseudo-code. Determine what variables and functions you’ll need and tag each with a “TO-DO” comment. Being verbose can save you a lot of effort and help you keep track of your progress. Feel free to even jot down notes and save a text file in the project folder if that’s what it takes. Don’t rely on your memory!

I suggest all these things because it wasn’t easy for me to pick up where I left off. Maybe if I had installed Truffle (another development framework) and saved the project in a specific place, it would have been much easier for me to jump back into my project. I did eventually switch to using Truffle which helped, but we’ll cover that later.

You may lose progress but nothing can take away what you learn

Paul’s code eventually was a big help in getting BridgeBurner where it is today. However, my initial approach only took me so far. I eventually realized that jumping around and building things without a clear understanding of all the moving parts wasn’t going to work. Also after some tinkering, I found that some initial design ideas wouldn’t work in practice. I’ll go into more detail about how the design changed in the next post.

Sometimes, I find it easier to ball up the piece of paper and toss it in the bin. It might feel like a step backwards, but you stand to benefit from starting fresh with a clean slate, this time with more experience. Plus, you don’t want to fall into the bad habit of commenting out lines and adding bloat to your project’s code.

That’s all I have for you today; until next time my friends.

And thank you all for the feedback so far! As always, if you have any questions or comments, reach out to me @ChazSchmidt on Twitter or in the Concourse Discord.