Mixing environments – Creating working environment for blockchain developers

Mixing environments – Creating working environment for blockchain developers

This article is part of a series of articles depicting my experience with creating and conducting an 8 week long blockchain app development course in Brazil.

 

What tools should be used when teaching blockchain

 

The term blockchain is often misused. Very rarely do people use the term blockchain to describe anything beyond a chain of blocks. A lot of the time when people talk about the blockchain and its application, they basically refer to a somewhat wide variety of technologies, architectures, tools and protocols that, once properly combined and implemented, creates that “blockchain” they are referring to.

When I created the course, it was obvious to me that in order to properly teach the students how to work with “the blockchain”, I’ll first need to spend a lot time dealing with many different technologies and tools. There isn’t just one blockchain IDE or concept to examine; rather there are quite a number of them. Take key pair for example; private and public keys are some of the most crucial (and known) features in many crypto-currencies and blockchains, but they are by no means specific to blockchains. Many people use key pairs off chain. The same holds for many concepts that are highly integrated into the common view about blockchains – Hashing functions, signatures (and keys), scripts and stack architecture, byzantine general problem, bytes codes, merkle trees, DAGs and more.

Each feature in the list above represent another tool/approach/use case/concept that stands by itself but is also crucial to creating what is commonly known as “the blockchain”. This fact posed a great challenge for me when I tried to create the course. It was obvious to me that the course is aimed at people who want to learn how to develop their own blockchain applications and solutions, which meant that it will require the students to get their hands somewhat dirty in codes, command line prompt, and different computational tools.

The challenge here lay in choosing the right tools to work with while remembering that each item on the list should be taught in a manner that is  adequate on the one hand, but without going to a level too deep and insignificant for the course on the other hand. It was also important that there should be a clear difference in the relations between the different and individual items.  I knew I wasn’t hired to teach the students how to program or how to work with different environments. However, making the assumption that they had adequate programming knowledge, enough not to require any introduction to that programing language/ environment/ tools seemed quite optimistic at best, and downright stupid at worst. This is even more so when dealing with a variety of different tools and languages.

I decided to do my best to choose the most user friendly working environments – even at the cost of efficiency and future usability.

Numerous developers have their own working environment. However, I was convinced that every code, example and CLI command/tool should be properly tested and documented in a single uniform environment. The last thing I wanted to do was stand in front of the class while in the background, my code failed to compile. The result of this is that I tried  a lot of different environments while always keeping in mind that the environment to be used should fulfill the following requirements;

  1. It needs to support all the tools I require that my students use.
  2. It shouldn’t affect in anyway the students’ computers, working environments, file systems, paths and/or jeopardizes their computer security in any way.
  3. It should be uniform for all the students.
  4. It should be easy and fast to set and reset whenever needed.
  5. It should be as user friendly as possible.

 

After a few experimentations, I decided to work with the following configurations:

 

  1. Cloud9 level 1 IDE environment with the following installations:
    1. Python-pip.
    2. Python-virtualenv.
    3. Virtual environments for Python 2.7 and 3.5
    4. Ethereum SOLC
    5. Tcpdump (for some reasons, not all c9 workspaces had it installed)
    6. The following pip packages (base58, ecdsa)
Cloud 9 was used for running python files and as a uniform terminal.
  1. Digital ocean Ubuntu 16.041 X64 droplet with the following installations:
    1. Nodejs 6
    2. Meteor Javascript framework version 1.3.4 with web3 and bitcore-lib packages.
    3. The following changes were optional for a few students:
      1. Installing ipfs and running ipfs daemon and adding ipfs-api package to their meteor app. (For those who wished to work with IPFS).
      2. Adding swap file of 4 gb. (For those with memory issues).
  • Use openssh. (More IDE flexibility for advanced users).

 

  1. Solidity browser compiler was mostly used for writing and deploying smart contracts. SOLC (installed on c9) was used by a few students who required some more advanced contracts (mostly when containing libraries).

 

  1. The only 2 components the students were required to install on their own machines were:
    1. Chrome/Chromium with metamask addon.
    2. Wireshark.

 

Cloud9 provided a well-tested and easy to configure working environment that was consistent for all students. It was used mainly to run the Python codes the students created, to compile some Solidity codes (using SOLC), to catch some packets using tcpdump (The tcpdump files were later downloaded and examined using wireshark) and to access digital ocean droplet using ssh.

I was very pleased with this working environment as it was quite robust, highly configurable, not local and easy to reset – Basically it was a great playground to get dirty with, without having to worry about damaging the students’ native environment.

 

Digital ocean droplets were used to provide the students with a uniform platform on which they can create their apps. Meteor is a well-documented JavaScript framework. It was obvious to me that if the students were expected to create applications, they should also have access to some JavaScript tools as both Bitcoin and Ethereum have some very powerful tools for app developers – mainly web3 for Ethereum and Bitcore for Bitcoin.

There’s also another npm package for compiling Solidity (similar to SOLC), but unfortunately, I’ve experienced a lot of compatibility issues with that package and decided to ban the students from using it. IPFS-api is another useful tool for more advanced students who are interested in working with IPFS.

It is important to note that although I did discuss IPFS with some students, I didn’t consider it an important part of the course. First, the system is still in a very early stage. Secondly, the main goal of the course was to teach the students how to develop blockchain applications, and not necessarily decentralized applications (although the two might have a lot in common, they’re not mutually the same) and IPFS just didn’t really fit the slot. Besides, I already had an ample amount of topics to focus on and teach my students (And I must admit; I’m not that much of an expert in this platform myself).

Another point to consider is that in a future course, in the case where there’s no promise to create apps, digital ocean might still be used. In this case, JavaScript libraries can be taught by using clean nodeJS interface.

 

Metamask and solidity browser were wonderful and very easy to use tools. In a manner of minutes, the student had yet another playground to play with Solidity and the Ethereum blockchain.

(It’s important to note that I took some time to make sure ALL of the students were using clean metamask installation WITHOUT any of their real wallets imported to it and only on the Ropsten testnet).

 

One last note about truffle

I also feel compelled to justify a little further my decision to exclude the use of truffle and/or embark (with testrpc) during the course and instead choosing to work with solidity browser compiler. The thing is,  at the time, both truffle and embark had some memory issues that forced me to use another swap file (both when tested on Cloud9 and when tested on digital ocean droplet). In addition to that,  most smart contracts required were easy to deploy from the Solidity web compiler. For specific ad hoc contracts that required the use of a more robust compiler, Ethereum SOLC was used on cloud 9 (SOLC didn’t had any memory issues). I do however recognize that truffle and embark are major tools in the industry and I’m defiantly planning to integrate them into future courses.

Leave a Reply

Your email address will not be published. Required fields are marked *