photo by Grant Bishop
At Starbase we are creating blockchain applications that will impact the way that individuals and organizations raise funds and hire personnel for their projects. We have high hopes that some projects funded via the Starbase platform will add a positive mark in the universe.
Before this grand vision occurs though, we are working diligently on the technology that will make it happen: smart contracts. We are a startup building on the Ethereum virtual machine that means that we are blockchain driven. This blog post is a brief overview of the tools of trade and guidelines we are using to develop the technology at Starbase which will ultimately serve you.
Blockchain software is similar to hardware in the sense that once it is produced it cannot be changed. Imagine getting hold of a defective iPhone. The experience is not pleasant. The same is for smart contracts as once it is deployed it immutable. Deploying smart contracts generally means that you are dealing with the company’s or other people’s money so in order to create a smart contract, you got to make sure it works. At Starbase we have various contracts that we create and improve on daily. And for that we use smart contract tools such as Truffle.
We have on average a 1:20 ratio of smart contract code to unit testing lines. It is paramount that the smart contract code is well tested. As mentioned earlier, contracts on the blockchain world cannot be changed. Granted that there are upgradeable techniques for contracts but a best practice around it has not been established yet and even if it was here already, you would still want to spend time testing obsessively any contract code of yours. The basic guideline for testing that Starbase have is to not write untested code, ask at least a different engineer to review recently produced code, and not to reinvent the wheel for solutions that are proven and thoroughly tested.
Speaking Things Into Being
This guideline is based around “speaking things into being”, that is to say, not creating things and then describing them later.
This approach has a variety of benefits.If we can’t clearly describe something, we probably don’t actually understand what we’re trying to do. This will be reflected in the contract. Exploration and experimentation are encouraged — just not in commits.By putting documentation and testing first, we ensure that we always have an up-to-date specification for the system. This helps us stay focused on what we’re doing rather than how we’re doing it. How will always change quickly. What will change as well, but less often.By creating a common language together, our mental map of the system will remain more accurate. When changes need to be made, it is easier to see and discuss how concepts relate rather than how cogs of a complex machine relate. Our understanding should drive our structure, not vice versa.
This is the high level vision of the tools and guidelines we use and abide by here at Starbase. We believe we are building something truly special and invite all to take part of it and claim their piece of the universe by launching their project in the soon-to-be-made Starbase platform.
Our crowdsale is estimated to occur at the end of July 2017 and more info will be released soon on our site. Join us also on our Slack channel and for those that enjoy long and good read, here is our whitepaper :-).
A curious mind, joie de vivre practitioner