HW5: Breaking ground
CS 359B Spring 2018
Deadline: Monday - April 30, 2018, 11am
Your goal is to have the first working version of your project ready for the Midterm presentation. Is this possible? Here is how we are going to do it:
By Monday, April 30, 11am, you will:
By Monday, May 7, 11am, you will:
By Monday, May 14, 11am, you will:
To get full credit:
After surveying the class, the vast majority of students responded they prefer us to help host the projects directly on the class’ website. So, to do that we need to know exactly what technologies you need installed on the server my midterm. The fewer moving pieces the better for everyone. (e.g. mysql and postgres are too similar to make sense to install both)
Based on the survey data, we intend to support the following. But let us know if you strongly need something else.
We will create a private slack channel for your team. The members will be the class staff, your mentors, external team members, and you. Send a report to your team’s slack channel with the following: (you can copy+paste them from your github repo)
We will be using github classroom for submitting code in this class. Use the link below to create your class project github repository:
The process is different this time. It will ask you for a team name. We will be using your project name as the team name. Look through the list for your team created by your teammates. If your teammates have not created your team yet, type the name of your project as a team name. Coordinate with your teammates to get connected on the same team.
Update the README.md file with the technologies you will be using between now and the midterm.
The above link will create a new public git repository for your project in the class’ github account, and invite you to use it. The license of the code is set to be MIT License. Work directly on this repo, commit frequently. We will be assigning you credit for your work every week.
See CryptoTrees as an example submission. It had 1 pull request associated with 1 Milestone. (Clear the filters is:issue is:open to see it).
Most decentralized apps are open source. In a sense, the whole point of blockchain apps is that any user can audit them. Dapps users trust the source code more than the word of corporations or governments. So, in that respect, open source makes sense for this class. We are also open-sourcing cryptotrees and all class example dapps. If you have reasons you do not want to open source your code, let us know, and we can discuss it case by case.
Yes, with attribution. We highly encourage cross-team student collaboration and incorporation of external open source code into your projects, as long you provide the appropriate attribution. You are also welcome to reuse or draw inspiration by you fellow students projects and technical solutions (as long as you provide attribution). You are also welcome to reuse any part of class’ code, including the code of cryptorees.
No need to reinvent the wheel. If someone comes up with a good solution on a technical problem, there is no need for others to repeat the exercise. Reuse what you can and build on top of that. Feel proud if your code is used by others, you get their attribution and good karma.
No, you can use your own. However, the main benefits from using the class’ server are: simplicity, free of cost, cross-promotion from the class to obtain more users and visibility for your dapp, being a part of the group. Using the class server does not restrict you to only use the default dapps.stanford.edu/project_name URL, as you should also be able to link an external web domain to it if you like. In any case, class staff should be able to run your code locally on the server, for grading purposes.
We still ask you to create a class github account, which we can use for grading. You are welcome to reference your external github, and cross-link the two. Let us know if you plan to do that. Also, let us know of any concerns; we are happy to hear you out.
A: Yes. Chose the functionality wisely so that you can get it done. Work in a full stack mode and implement features all the way through, one at a time. Start with the simplest feature you can imagine and get it functional all the way. Then move to the next feature. For example in class we built features of the CardinalToken wallet in an hour. We first got it to display the balance of a Metamask user. We then got it to be able to send tokens to other accounts. Afterwards you were able to make it mint new tokens as part of your HW3. So, instead of implementing all sorts of frontend features (for example), and then moving to the backend, we finished each feature all the way, one at a time. In the end we had a dapp usable by end users within an hour, even though its functionality was very limited.