reva VS ndn-sync

Before I deep dive into the architecture of what I rebuilt the app during the hackathon, I would like to tell about my experiences in my words. When I first came across #GO Hack Challenge on devpost, I was overwhelming to find related tracks which I could be fit for and tutorials to enrich my knowledge here and there to get into it. It was really a learning opportunity to someone who is newbie and contribute or build any stuff under the hood. I stepped into the open source projects under CERN Foundation, where I didn’t even know what the ecosystem around the project is. I was much curious then. Next, I delved into one of the projects for a few days and looked into a few issues and made a small contribution to it by fixing one of the bugs. I moved to another track where we needed to build any app based on golang. I came to know about use of generic function which is currently released and used in Go >= 18 Version. I managed to rebuild an app using Gin-Gonic framework and use the generic function usage in my app.

The advantage of that above just a simple "these tests are allowed to fail" is that, after adding a feature or fixing a bug, the developer is forced to look into the tests. If tests start to pass, the only job the developer has to do, is to remove them from the expected-to-fail list, and what a joy is that 🎉. From that point on the test has to pass in all future runs, and we are sure not to introduce any regressions. If we would only have an allowed-to-fail list, there would be no pressure to remove tests from that list, humans are humans, so they would forget or miss some. Potentially a bug could get fixed, then see some regression again and none of that would be noticed by the test-suite. So let the computers do what they are good at - automate!

Project