At the beginning of October, I spoke at TruffleCon 2018 on “Smart Contract Testing Strategies”. You can view the code and presentation from that talk on Github. While preparing for that talk, I looked at a lot of smart contract tutorials that showed smart contract tests using
MyContract.deployed() in their mocha tests. While this benefits your tests by making use of the Truffle Clean Room Environment and speeds up your tests by only deploying a new set of contracts once per test file, I do not believe this leads to clean, easy to understand unit tests for your smart contracts. As I describe in that talk, I believe it is better to use
beforeEach blocks in your tests to deploy new contracts for each test, creating a clean state in which each individual test can run. For instance:
const MyContractAbstraction = artifacts.require(‘MyContract’);
When our Turing cohort explored ExpressJS this module, there was a quick comment at the bottom of one of our lessons about the
next() function in ExpressJS. While I was in the middle of a project figuring out API endpoints and using Knex with NodeJS, I could not fully absorb the possibilities of
next(). Having now gone through that project, I wanted to circle back and gain a better understanding of how
next() worked and how to look for patterns where it might be useful. In short,
next() sends the request to the next function (those clever developers with their fancy names) that handles the request. Still unclear? I know it certainly was when I first looked at
In the first post of this series, I talked about getting AWS setup and running your genesis node for a TestNet. Its great to have your own node, but really, you don’t want to have to SSH into the server every time you want to do something. Ideally you would be able to connect your computer to an always live test chain and get to work.
Setting Up AWS
We are going to focus on getting this set up on AWS since that is the most flexible for a team to work on contracts in the future.
Rails makes outputting a form pretty easy. Unfortunately, like with many things at this point in my Rails journey, the magic seems pretty opaque. One of the things that was confusing in our latest project was adding checkboxes to our forms.
Recursion - Favorite Technical Concept from Mod 1
One of the hardest and most fun concepts I learned during mod 1 was ‘recursion’. This at times can feel like something out of the movie Inception, but it was one of the most powerful tools I learned. It allows you to loop over a part of your program until a condition is met. Each new layer puts a temporary pause on the layer that spawned it and then ruby cycles back up through the layers completing the remaining program at each level before returning to the level that spawned it.
A pattern I see recurring in my programming is that I need to take an argument, then based on what it is do something, for instance:
Hashes are a very powerful and useful tool in Ruby, so I wanted to dig a little more into them.