Lessons Learned while Participating in a Developer Contest (Part 1)
Recently I took part in the Switcheo Developer Contest to get a better understanding of how blockchain development works as well as get a better understanding of what full stack development actually looks like. My previous development experience has focused on back-end tasks such as data engineering/analytics/wrangling/science/pick your flavor. Since the contest is over and I have a tendency to forget what I learned after time passes I wanted to use this forum as pseudo documentation so I can look back at this as a reference for the next project.
A driving force behind adoption of blockchain projects is community involvement and contributing to this process is an open enterprise that allows everyone to collaborate toward building a more robust ecosystem for the project. This approach helps build community but also provides an incentive for those that can contribute via bounties and development competitions. One project that caught my attention was a burgeoning decentralized exchange (DEX) which offered a competition to develop integration with their newly released API. I was drawn to the project because I had used the platform and found it intuitive to use and the team around the project was very forthcoming about expectations.
Another aspect of this was to challenge myself to learn more about blockchain development because outside of some smart contract development I have minimal hands on experience in software development and also had less skills in the full stack development. This gave me the opportunity to explore many different areas of interest to help accomplish my objective and during that process more ideas bubbled up as potentially being useful (covered in part 2). However, the first step of this process was to decide what I would work on.
In the developer ecosystem JavaScript is the most popular language followed by Python. I also had previous experience writing my own personal trading automation with Python so having this experience gave me some familiarity on how these API’s are structured and utilized. Based on these factors I decided to build the Python API wrapper for Switcheo, which takes the endpoints documented from the Switcheo API and allows the end user to interact with the endpoints via Python objects/functions. During this process I was able to learn about many different coding philosophies as well as tertiary tools required to help automate the deployment process.
Blockchain Functionality and Helpers
Switcheo currently functions on two separate blockchains, both of which have separate ways to interact with the global networks. For the purpose of this project it was best to build on top of projects already built for this purpose.
I started with NEO development which helped me understand how to use a private key, the different ways a private key can be used to generate new public addresses, and most importantly how to sign messages and submit them to the NEO network. The NEO helper functions required further functionality so I ended up having to build this by trial and error with hexadecimal string (and comparing to JS functionality), the transaction helpers can be found here: https://github.com/KeithSSmith/switcheo-python/blob/master/switcheo/neo/transactions.py and the extra utilities can be found here: https://github.com/KeithSSmith/switcheo-python/blob/master/switcheo/neo/utils.py
Another important step in this process was learning the difference between big and little endian hexadecimal handling since the Switcheo smart contract and NEO blockchain expect parameters in specific order.
Ethereum had a much more robust API and was easier to integrate since it was the second supported chain to be introduced and it was easy to apply lessons learned from NEO integration into Ethereum development.
Continuous Integration and Continuous Development
The open source community is amazing in depth and seeing the integrations that have popped up around the GitHub community allows for contributors and end users to trust that the end product is of high quality. I am impressed at the amount of tools available to ensure that a project has what it needs to succeed and a lot of time went into each of these to ensure the next build process went smoothly.
Travis
This tool has a hook into GitHub upon commit, merge, or pull request and will return a pass/fail check once the build process is complete. Once the tool has been given access to your GitHub profile you can choose which project to hook into as well as add the build instructions with a YAML file committed to your GitHub project and an example can be found here.
https://github.com/KeithSSmith/switcheo-python/blob/master/.travis.yml
Coveralls
The next logical step after Travis is to take the testing suite the build process runs through and have Coveralls score the output. It provides history and statistics of code coverage for each commit and is included as part of the YAML file from the Travis CI process. This works well and promotes keeping up with unit testing as code is changed or added so that coverage stays high.
Another nice feature about Travis and Coveralls is the fact that when builds fail or succeed you are notified by email and can address concerns as they arise.
Unit Testing
As alluded to in the previous section this project has unit tests to ensure commits don’t break previous functionality. Its also important to have test functions in case the underlying functionality changes and in the case of the Switcheo API this has occurred on a couple of occasions to help provide uniform functionality and address it quickly.
Read the Docs
Having a location to host documentation is a great place to allow for further adoption and Read the Docs has become a leader in this space. In order to make this process easier I integrated sphinx into my code so that the code became self documenting as functions got built. It was also easy to do because PyCharm has sphinx integration that adds this automatically to each new function so that you only have to provide color around the use.
To get this working on commit it required a YAML function in the GitHub repository since it does not yet support Python 3.5 or higher.
https://github.com/KeithSSmith/switcheo-python/blob/master/readthedocs.yml
PyPi
- Create and maintain project
- Push deployments to PyPi once committed
- This allows for pip installs to succeed
Code Maintenance
These tools are known by pretty much everyone and I have personally had a great deal of experience with both. It is always great to hone ones skills and using these tools with other developers is where the power comes from. I will briefly touch on these and leave links.
Git
The necessary distributed coding tool to share work with others. The biggest lesson from a project like this is keeping commits small and frequent instead of large. At the start of this project I could get away with large commits but as things got more complicated it was important to keep deltas small.
GitHub
How the world shares information and maintains versioning. During this project I had fun learning about the flags to keep status of each process documented above. I also learned to integrate with PyCharm (Idea) and GitKraken to make for easier git workflow.
Consistent Environment
Since you never know what OS the end user will use it is important to have an environment where the code will run in a consistent manner. Python helps abstract this with virtual environments but I used this as an excuse/opportunity to run everything in a Docker environment and will eventually orchestrate all of this with Kubernetes.
Docker
One huge benefit of Docker is build and execution consistency. It is also great when developing on tablets or smaller devices (especially when travelling) to push to a machine that has more resources and integrates with PyCharm in a streamline fashion. There was a lot of learning here and it may require its own blog post to get into all the details but for this project the finished (in progress) result is here.
https://github.com/KeithSSmith/switcheo-python/blob/master/docker/Dockerfile
