Collecting a bag of what I think are good ideas in the history of programming, which lead to better thinking about system design, implementation and evolution.
Note: This post will continously be edited to include ideas as they come to my mind as worthy of being included here. Also, the ideas are in no particular order and this is just a brain dump.
(Cross posted from Imaginea Labs).
The distributed ledger protocol used by blockchains has resulted in systems where we do not have to place trust in particular parties involved in maintaining these ledgers. Moreover the ledgers are programmable with “smart contracts” - transactors whose state changes are recorded and validated on the blockchain. A collection of smart contracts describes a system that is expected to ensure certain invariants relevant to the domain are upheld. For example, an election system is expected to maintain voter confidentiality. While the code that describes these “smart contracts” is open for anyone to read, those who’re participating in the systems run by these smart contracts are not in general competent to evaluate them, with the OSS community being the sole eyes on the contracts being deployed. In this post, I examine how these smart contracts can provide “warranties” that are easier to ratify and describe clear and automatic consequences of violating the warranted properties.
Blockchain tech, especially smart contracts, are the hot new “internet”. Post the creation of Bitcoin, we’ve seen the rise of the public smart contract system Ethereum and several private systems like Linux Foundation’s Hyperledger. These distributed ledgers have become the brand new foundation to build apps on. This is as app developers hope to leverage the additional trust that these ledgers are supposed to provide by virtue of their distributed nature.
(Cross posted here from blog.imaginea.com - Blockchain apps must be closed systems)
Can we have a signin/signup flow that is email-based and passwordless similar to a “forgot password” flow but where the URL will work only for the initiator, and only once per signin? This is the scheme I’ve implemented on Patantara and I describe its innards here.
Recently, many techies have spilt words against doing the Google interview process. Broadly they feel their real and demonstrated abilities are not being valued. The most famous of these cases is Max Howell - the developer of homebrew - being rejected in the interview. Following Google, Amazon and the like, much smaller companies have also begun to subject interview candidates to such “problem solving exercises” - either on a whiteboard or within test environments such as HackerRank where you can be rewarded for coming up with the wrong answer quickly instead of the right answer slowly. These same candidates would speak up against these companies as well, had they interviewed there. Is there a real problem with this interviewing technique or are these candidates crying sour grapes?