The Best Way to Start Coding in Solidity

This post is a list of Solidity tips and tricks I learned the hard way, by going through Solidity on my own and brute forcing my way through learning. This is really the only way to do it right now if you are learning on your own. It will help to identify the easiest tools and tips in order to get your first dApp deployed on the testnet using Heroku.

To start coding a new language, you want the easiest development environment that will help you through bugs so you can learn from your mistakes quickly as you go. Start by using the Remix Solidity IDE https://remix.ethereum.org.

• It is great for debugging, and gives you an option to step through the contract which is extremely helpful. I found it very useful to use the debugger throughout the whole development of my dApp, but at the start it was 100% necessary to help me write code that would actually compile.
• You should use remix until you get your dApp to compile with no bugs.
• There are three options with remix for injecting a blockchain instance into the browser, you can use the Javascript Virtual Machine (JVM), an injected web3 instance (like the chrome extension Metamask), or connecting to a web3 provider (like Infura). The JVM is the way to go when you are a beginner. It is much more forgiving, it ignores gas limits, it gives you an unlimited amount of ether to play with between 5 accounts, and it is much faster to debug with.

Make sure the environment is JavaScript VM when starting with your first dApp.

Start using Event Logs as much as possible to debug your code. They are the closest thing to console.log() from Javascript, as they can notify you of any changes to the state variables of your contract. In Remix they automatically show up in the user interface on the right side. When you want to see them from the front end of your dApp you will have to watch for the event with web3.js (explained later on in this post).

Events are shown in the right side user interface of remix.

• Note that Remix is glitchy sometimes. If it isn’t doing what you think it should be doing, open and close a new chrome window and it often helps. This is new software that is in active development, so bugs are expected.
• Note that sometimes the numbers in local or state storage while debugging will be extremely large. This might be due to accidental overflow for an integer calculation. However I have noticed that there is a bug in Remix . Sometimes while debugging it will show overflow, but in reality the contract still works and you get the correct results when executing functions in your dApp. So really pay attention when debugging to local and state storage, and if it is showing overflow and your contract still works perfectly, you are probably okay.

Using the Solidity Locals and Solidity State variable viewer in the debugger of remix is extremely helpful to see if your functions are working properly.

Keep in mind the first dApp you build will be slow when you are calling functions because you have to wait for blocks to be mined to get a response. This won’t rear its ugly head while using the JVM, as everything happens instantaneously. As you move away from the JVM it will be more frustrating to debug, so do as much debugging as you can here.

Moving onto a Better Development Environment with Truffle and testRPC

It is tempting to keep using Remix, but you should move on once you get to a point where your dApp compiles properly. Next you should use tools such as Truffle and testRPC that help simulate a real blockchain, so you can test your dApp in a more realistic situation.

• Truffle is a framework for developing and deploying Ethereum dApps. It is the best framework out there right now, and they are constantly upgrading and improving their product.
• testRPC is a simulated Ethereum blockchain you can run on your local machine that has been tweaked specifically for fast testing. You don’t have to wait anytime between blocks to see how your dApp is responding, which is super helpful for testing and debugging. However it still gives you a real blockchain environment for testing that will fail for things like an out of gas limitation.
• Truffle lets you write tests for your dApp with Javascript (based on mocha’s framework) and Solidity. Overall I have found that Javascript is better for integration tests, while Solidity is better for unit testing. However, I was unable to find good examples of Solidity testing online, and the documentation on it is not very in depth. Because of this I ended up doing the majority of my testing with Javascript because there is excellent documentation for mocha.
• It is sometimes tricky to test smart contracts, because there are situations where you want your contract to fail, like if only the owner is supposed to call a function, and if someone else tries to it should fail. The basic framework of truffle isn’t fully adapted to easily test for this at the moment, but there is a good blog post on a workaround that helps with testing for failures.
• Sometimes testRPC can act weird in the terminal. If you don’t end testRPC properly and you close your terminal window, it could still be running. Then the next time you try to run testRPC it won’t allow you to start a new instance. This happened most frequently to me when I used MetaMask. For some reason you can’t crtl+C out of testRPC when it is connect to MetaMask, so I started doing crtl+Z, and then I ran into these problems. I found resetting my computer cleans this up, and any other issues I came across with testRPC.

Turning it into a Real Front End dApp with Truffle Boxes

Truffle Boxes is a combination of the Truffle Framework and the React Framework. In order to use truffle boxes, you’ll need a basic understanding of react to go forward.

• Build out the most basic version of your front end dApp to interact with your contract. It will end up being almost exactly like a normal React app, but you use web3 js (which comes included in Truffle) to interact with the blockchain. You will then have to inject a blockchain instance into your chrome browser so that you can interact with your testRPC on the testnet.
• MetaMask is the easiest way to interact with a blockchain in the browser. It is a chrome extension that allows you to inject the mainnet, the testnet, or a local instance (like testRPC) of a blockchain. It also allows you to use multiple accounts and send ether or testnet ether between them. Then the web3 code in your front end will interact with the blockchain injected from MetaMask, and you have connected your dApp to a real blockchain!

Metamask Chrome Extension interface — unfortunately that is testnet ether, which is worthless :(.

Note that in a developement environemnt with metamask, you should never store real ether alongside your testnet ether, just in case you make a mistake, and send real ether while testing.

• You can get test net ether for the rinkeby test net here: https://faucet.rinkeby.io/.
• Always send transactions with a high gas cost in GWEI on the testnet. You might be inclined to keep it low because you are used to doing so for mainnet transactions. I’ve have long waiting times and bugs that have cost me an hour or two of time because I simply set way too small of a gas price on a large contract deployment, and then it failed on the test net, but MetaMask thought it succeeded. Then I couldn’t do anything because MetaMasks nonce count was incorrect. Testnet ether is worthless so you might as well send a lot to beat everyone else in the line!
• Use the mnemonic flag in testRPC to repeatedly get the same accounts generated whenever you start a new testRPC instance. I use the following command in my terminal:

The mnemonic flag generates ethereum accounts based on a string you pass it upon starting testRPC. If I always provide “hello”, I will always get the same accounts. This makes it easier to hardcode in accounts while running tests. The accounts flag is used to generate 50 addresses, also good for testing.

• Accounts[0] (from truffle and web3) will be the account that MetaMask had opened up when the dApp is loaded in the browser. Sometimes MetaMask is finicky, and if you switch back and forth between accounts the dApp’s web3 and Metamasks accounts won’t be talking to each other correctly. Just refresh the page.
• MetaMask will sometimes let you know a call from your front end dApp to the blockchain is going to fail by maxing out the gas you are sending with the transaction, and sending 0 ether instead of the amount the dApp is asking for. It doesn’t explicitly say why it will fail, but it will, and it will use up all the testnet gas. This happens most often when an account tries to call a function that it does not have access to, and it will just revert and burn the gas.

Deployment with Heroku

Heroku is perfect for deploying your dApp because it is super easy to do, and your dApp doesn’t have a backend which makes Heroku’s simple setup very attractive. This article will help with deploying a dApp on Heroku (you will have to let chrome translate the page to English) https://medium.com/taipei-ethereum-meetup/ethereum-dapp-tutorial-push-button-cae3810086a4.

My first version of my first dApp deployed to Heroku was very basic, but it doesn’t have to be pretty as long as the smart contract does what it is supposed to do! You can see it here: https://heroku-patreon.herokuapp.com/ (code is located here).

The first version of the first dApp I deployed with heroku.

When you deploy the front end to Heroku, you will have to deploy your contract to the testnet as well. Deploy the contract first, then once it is deployed you can get the address of the contract from etherscan, and hardcode it into your front end so that your dApp is interacting with the correct contract on the testnet. There are a few ways to deploy a contract to the testnet:

• You can deploy the contract using remix by injecting a web3 instance with MetaMask (make sure you change the environment from JavaScript VM to web3 instance, and that you pick the correct testnet to deploy to).
• You can deploy with myetherwallet here: https://www.myetherwallet.com/#contracts
• You can deploy with truffle as well, and there are good instructions to do so in their documentation.

I found using remix to be the easiest way to deploy a simple dApp.

General Tips

• Keep your first few contracts simple.
• Always update your dev tools (Truffle, testRPC, MetaMask) as much as possible. This is a new field and new versions of the software come out weekly.
• Be weary of looking at old Solidity code and copying it directly into yours. Solidity is updated often and some of their functions have been deprecated.
• Read the Solidity documentation.
• Learn to deal with ether in wei from the beginning, because all numbers should be passed around in wei on the EVM and the front end. Otherwise you will have to retroactively go back and fix your code, which is frustrating.
• The first time you come across a Big Number while coding go read the documentation here. It will help immensely when you start passing numbers between your front end and the blockchain.
• Consistenly check back with the web3 documentation and the truffle documenation. They both have a lot of helpful functions that make building dApps easier. There were multiple times when I tried to do something on my own, only to realize that truffle or web3 already has a function that does what I needed.

Things to look into for your second dApp

• Once you get the hang of actually creating a dApp that works, start to look more into the security of writing good smart contract code. Learn about common pitfalls and bugs and how to prevent them. A great place to start is ConSensys’s smart contract best practices.
• You can watch for Event Logs from the blockchain with the front end by using using web3 (https://github.com/ethereum/wiki/wiki/JavaScript-API#contract-events). Watching for Event Logs from the front end allows you to automatically update the front end when something is changed on the blockchain.
• Once you get the hang of smart contracts you can start to look at ways to reduce the gas cost of the deployment of your contract, and lowering gas cost for storage of state variables. When you are working on your first dApp there is no need to worry about this as it will just confuse you more.

Conclusion

Good luck deploying your first dApp! If you have any questions please ask in the comment section, or tweet at me @davekajpust.