Technology related blog posts

For 6-months, this website was compromised. I am not sure what exactly happened, but it was most likely password-reuse, which lend itself to this problem. The problem became apparent when I first noticed an unusual link to a ride-sharing service. Later, I saw more of those links. That’s when I realized that I couldn’t merely sit and scan every blog post manually and decided to write a small interactive link checker tool. This tool whitelists the starting domain and allows you to whitelist URLs on a per-domain basis. The whitelist is persisted at the end of execution and will be used next time you use the tool. ...

Earlier, the Software world was rigidly divided between closed and open-source software. Microsoft Windows is closed-source, GNU/Linux is open-source. Microsoft Office and Lotus Notes are closed-source, LibreOffice is open-source. Turbo C++ is closed-source, and GCC is open-source. But now, a new class of software products has emerged whose core is open-source, but still, the open-source software is of limited use. One model is to offer some critical and useful functionality in a closed-source layer via a managed service in AWS/GCP/Azure, for example, Redis is open-source, but useful modules on top of it are not. Another model is to use licensing gimmickry, for example, MongoDB is licensed under SSPL which requires that if anyone offers MongoDB as a service, then the source code of the full service must be published under this license. The third approach is to make the core software open-source but make it dependent on closed-source cloud services. For example, the node package manager (npm) is open-source, but a closed source company owns the default npm registry. Android is open-source, but most day-to-day application ranging from Google Maps to Google Music are closed-source. Now onwards, rather than calling such software open-source, we should call them closeum.

When the code runs on your servers, you have much more control over the “context” in which it runs. On the mobile devices, the device OS and the user control the context. This difference leads to some subtle implications. One significant set of differences comes from the lack of control of the platform. For server-side code, one can choose from a wide array of languages. For the mobile code, however, the best choice would almost always be the one dictated by the platform - Java/Kotlin on Android and Objective-C/Swift on iOS. Further, for the server-side where one can stick to a particular version of the language. In the case of mobile, the platform controls the language version. Same goes regarding the hardware choices - one can choose to use different types of server machines specialized in handling those jobs, eg. GPUs for math-intensive computes. While for the mobile-code, one had to write a good enough fallback to support a wide-enough set the devices. Similarly, the server-side has to rarely worry about the server killing a running process while it is normal for mobile OSes to kill backgrounded processes eventually. ...

iPhone iPhone iPhone 3G -> iPhone 3GS iPhone 4 -> iPhone 4S iPhone 5 -> iPhone 5S iPhone 6 -> iPhone 6S (and plus sizes) iPhone 7 (and plus sizes) Android Nexus One Nexus S Galaxy Nexus Nexus 4 Nexus 5 Nexus 6 Nexus 5X & Nexus 6P Pixel & Pixel XL While iPhone is recognized as a global name while erstwhile Nexus and now, Pixel has almost no branding outside of the Android fanboys. ...

Our brain loves distractions, and multitasking gets bored quickly. When we read text or watch a photo, it engages us visually, a video (with audio) engages us even more. The bandwidth of eyes is much larger than the bandwidth of our ears. When we are watching something, it utilizes more bandwidth and hence occupies more of our attention span. Also, given the way our eyes work, we can focus more on the exciting aspect of the visual feed. Compared to that, audio underutilizes our brain’s bandwidth. Further, the unidimensional flow of audio data at a linear speed does not mimic our ability to process it. Contrast forced direct listening with how non-linearly humans read. ...

Consider two systems: the first is 90% reliable and the second is 99%. The wrong to compare them is to compare the reliability and conclude that the second one is 9% (or 10% if you take 90% as the base) better. The right way to compare them is to compare the unreliability and conclude that the first system fails in 10% of the cases while the second fails only in 1%, making it 10X more error-prone than the second. The reliability comparison is a vanity matrix while the unreliability comparison not only demonstrates the user perception (“The user saw ten crashes in past one hour” vs “The user saw one crash in past one hour”) drastically but also shows the effort that goes into making the system more reliable. ...

All consumer internet products are either about consumption, production or both. A blog site is primarily about consumption. A photo transforming app is primarily about production. Social networks are consumption heavy. Good Messaging apps are symmetric. And a grievance collection product like BBB is production heavy. Building aggregation on top of similar products is a well-known strategy. The hard realization to note is that it can succeed only in very specific scenarios. Look at all the successful aggregation products, travel booking sites, news aggregators, RSS readers, discount coupon aggregators. As opposed to that, attempts to write an email aggregator, a social media aggregator etc. have not been as successful. And that’s the underlying theme, aggregator works well for consumption only interfaces where the product is sourced from many sources (more the better) and is standardized in the eyes of the consumer. They have limited success almost everywhere else. And this just doesn’t apply to software products. Microsoft tried and failed to have their own hardware stores since their offerings were similar and a subset of BestBuy whereas Apple succeeded in the same strategy despite the naysayers.

The book is Ben Horowitz’s memoir with a particular focus on his company Opsware and the lessons he learned there.

The book consists of the learnings which the author had while working on his startup IMVU. The book focuses on the concept of validated learning and the build-measure-learn feedback loop. It tries to bring in a systematic approach to measuring the progress of a startup. A startup has a true north, its vision. It employs a strategy that includes a business model, a product roadmap, and a view of partners, competitors, and customers. The product is the result of the strategy. Products constantly change ( engine tuning). Strategy changes occasionally ( pivot). Vision rarely changes. In general management, failure to deliver results is caused by failure to plan or failure to execute. Both are frowned upon. But in the modern economy, both are useful tools for testing new ideas. ...

Articles with the following titles would be considered a joke “BMW is planning to merge its series i5 cars and Motorrad bikes” “P&G is planning to merge tissue paper and toilet paper” “Arm and Hammer is working on merging face wash, body soap, shampoo, laundry detergent, and dish cleaner” Not that these combinations can’t be made or have never been made but consumers would just not buy them. They are usually inferior or more convoluted, or even worse, both. ...