Why one wrote "Constraints Innovate"

Earlier, one wrote an article "Constraints Innovate", it's for a short project that one is working on. One would like to talk a bit about this project: Spring is NEAR Challenge 5. Spring is NEAR is a competition (maybe more like hackathon?) that gives 8 challenges across 4 weeks, hosted by NEAR Protocol, to complete. Participants chose to invest time to finish the project, and this week (as of writing, it's Sunday my time, and Monday is "next week"), it's Challenge 5 and 6.

Earlier this week, usually one would utilize ones' afternoon (still "looking for work" passively, duh) to work on the challenge; but one got a little burnt out, so one took 1.5 days off and started only on Wednesday afternoon. Shorten a day plus this week's is much much more challenging than the first 2 weeks, it seems impossible to complete the project. In fact, one started out with challenge 6, because challenge 5 is open-ended (that is, little constraints), and one isn't sure what to do without sufficient constraints. Challenge 6 is more straightforward with sufficient constraints to start working on. One estimated it takes 2-3 days to complete (actually, 2 days, otherwise one wouldn't have much time for the other challenge). It was a bad estimation.

One finishes Challenge 6 partially on Friday and submit a partial MVP. By throwing away lots of unnecessary optional functions and focusing only on the core functions, one manages to share a demonstration of the project. You can check the deployed app here on Heroku (as long as one haven't deleted the app in the future due to limited apps one can have without a credit card; otherwise check github here). The backend is a hassle, taking 2 days; and one as a backend developer trying to make the frontend in one day, hahahah! You'll know when you see it. One shall appreciate that Bootstrap makes my life easier without writing all the CSS myself; and Rails for building a website MUCH MUCH more faster than React (as complication increases; for simple ones, React can actually build faster than Rails sometimes).

Then, 2 days left: Saturday and Sunday. Submission is my local time, Monday 15h; but one do not like to do things last minute, so let it stay till Sunday, and Monday morning the submission, perhaps writeup the README file (if you don't know what's a README, it's like a documentation for readers to know where to start), additional stuff like recording a video (that gains +50 points on the hackathon), and some basic testing on the website. For Challenge 6, one even have to give up (the holy) unit and simulation testing (and make my life more difficult in the future if one were to clone it as the first thing will be writing tests). For frontend, one is still extremely uncertain how to write tests.

That's it for Challenge 6. Let's talk about Challenge 5. One only have 2 days for an open-ended project, so one needs to dive in real quick: 15 minutes to knock the hammer on what project to work on. On Saturday morning, after writing README and record down ones' learning (before one forget about it) on my personal blog, we start with knowing "do something for a good cause". Ok, one ever learns about Effective Altruism, so let's just stop thinking about anything better than that. Then one ever donates to GiveWell (related to EA), so donation is a good topic. Then, why not just port Web2 to Web3 and make something similar to GiveWell while also advertise GiveWell? Sounds good. 15 minutes, done! We landed on a topic.

Now, NFT is very popular, so we'll make "NFT receipts" for every donations. Ok, we add a field for "donate amount" to NFT to record how much you donate. Then, to not fill up your wallet with receipts (ahem, NFTs) like you got a shoe-box-full of receipts (if you kept your receipts from supermarket, etc, in a shoebox like oneself, for a whole year, you'll know what one means), we'll only handle one receipt per donation field. By donation field, one means to "which sector" we're donating. GiveWell classify donations to sector, like Against Malaria for Children, Deworming for Children, GiveDirectly to poor people, and they handle the "backend" by redirecting your money to whom donate the most effective to these people in need (that is, you saves or improves the most life per dollar donated). We shall ignore the backend here, it's not important to end-users anyways, and one did not write the logic for it too! In fact, we don't have the time to do so.

Then, each NFT requires "donate and mint" or "donate and update NFT" (since we're reusing NFTs). Now, we need to add ourselves as approved to make changes to the NFT without permission from owner. In fact, we couldn't let them transfer the NFT around, or deny our approvals; otherwise, the syncing will fail. In real life, a receipt isn't worth anything to others, only yourself, like a badge of honor. Unfortunately, one did not delete the code to revoke approvals nor transfer, just to not disturb the "semi-fragile" state of the smart contract. However, that's something to work on in the future.

We do deny users from minting an NFT directly though. The only way to mint? Donate and mint. Otherwise, think of someone can assign receipt to themselves in a supermarket without buying something and said they bought something. Whether or not they steal the object or just make a fake receipt, it's having some inconsistencies with the product plus and minus from their database. In the same sense, we can't allow users to mint an NFT as they like; they pay and mint. The "donate and update" just uses the approval we grant ourselves to the receipt, and make changes to the "donate amount", simple.

Overall, the thought process when we start thinking is simple, but it's actually not. One think one kills quite a number of brain cells and reached "brain dead" state (when one thinking starts to slow and can't work effectively on something requiring problem solving) trying to solve the issues that are non-predictable as we work on the program. The end result, check this website or this github (as mentioned, one'll pull down the deployment in the future). One finishes this Sunday morning, quick!

Actually, one might have some time to write some tests, but one got pulled into working on something else during Sunday afternoon just now, so we'll also skip that for now and work on it when we require it in the future. The frontend is much easier than first time development. In fact, each project is a feedback to the template that one builds for faster development. Believe me, setting up everything, even with step by step instruction from scratch, will run into quite a number of problem; what says one didn't record down the step by step and forget about it some time later. A template is easier to work with.

It's a hassle this week, and one appreciate your time for reading this article with oneself. There may be unclear stuffs when one write this article, since this IS the first draft (no rewrite), immediately published. If there is, you're welcome to ask in the comments below and one'll answer when one found the time to do so. Thanks again.

Remember to Like and Subscribe!