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.
- 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.
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.
- 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!
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:
- Accounts (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).
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 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.
- 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.
- 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.
Good luck deploying your first dApp! If you have any questions please ask in the comment section, or tweet at me @davekajpust.