The two-step approach to big code modifications
We all have to make significant code changes from time to time. Most of these code changes are large. Consider the scenario that you merged one such significant change, and then other team members made a few more changes on top. Then a major bug is detected. You desperately make the fix. It makes it in. You declare a victory, and a few hours later, your colleague notices another bug/crash/performance regression. Your commit cannot be reverted. It isn’t just about you. Many others have built on top of the change you made—the code sloths along in this broken state for a few days before you eventually fix it. Everyone has faced this issue at some point or the other.
If the code change is small, this is a non-issue, you can revert it and fix it at your own pace. Therefore, when making significant code changes, always try to do it in two different commits (pull requests). In the commit, you add the new code, add a switch (command-line flag or a constant) to turn it on, and keep that switch off by default. In the second commit, turn the switch on. Now, if there is a problem, you immediately turn the switch off and start working on a fix. No one else will deal with the broken code. It would be even better if the switch is a command-line flag since you can turn on the flag for 10% of the machines (or users) and see the behavior for a few days before rolling it out to 100%. It big teams, it is usually good to add a comment to switch mentioning when it should expire or else you will end with Uber scale problem.
There are a few cases where this cannot be done, for example, during big code refactoring. I think big code refactoring touching code written by multiple teams is almost rarely justified in a single commit.
Examples of some cases where this is useful
- Switching over from consuming data via v1 of some API to v2
- Switching over from returning computed results to stored results (for faster response time but possibly inaccurate outcome)
- Switching over from JSON to Protocol Buffer/Thrift
- Switching over from VMs to Kubernetes (don’t delete the old code yet, you might regret it)
In a remote village in Thailand…
After renting a moped in Thailand, I stopped at a small shop to ask for a petrol pump/gas station. Instead, the shop owner handed me a bottle of gasoline for purchase.
“Must be a peaceful country where they can sell gasoline in bottles.”, I said to myself, “In most parts of the world, people would use this as a petrol bomb during violent protests and riots.”
Petrol/Gasoline sold in bottles in Thailand
Dealing with phone numbers in contact book
If you are building an app that uses the user’s contact book then their certain gotchas to avoid.
Telephone country codes are prefix-free
If a country has a country code “+91”, then no other country will get a country code like “+912” or “+913”. This scheme ensures that numbers are inherently unambiguous.
Telephone numbers can have multiple representations
Since most people don’t dial internationally, telecom systems implicitly assume a domestic call. So, someone dialing 612-555-1234 in the US is dialing “+1-612-555-1234”, while the same person in India is dialing “+91-612-555-1234”. Since international dialing would be more infrequent, telecoms require unique prefix numbers like “00” to distinguish whether someone is 612-555-1234 in their country or 0061-255-51234 in Austria. In some states, even the domestic area code is not explicitly required. So, a user might have stored “555-1234” as the phone number to which telecoms will implicitly prefix the user’s area code. And if the user wants to dial beyond their area, the telecom operator would require an additional “0” prefix to mark that it is an STD call. This localization has a massive implication regarding processing cleaning and normalizing phone numbers retrieved from the user’s contact book. Both country code and area code don’t contain “0”, and usually, that’s superfluous. So, while telecoms might be OK with calling or sending SMS to “0-612-555-1234”, they will treat a number like “91-0-612-555-1234” as incorrect.
Multiple countries can share telephone codes
USA, Canada, and many countries in the Caribbean share the “+1” telephony code. The carriers would treat calls or SMS as international, though. Italy and Vatican city share “+39”.
Continuous area codes or country codes are not always adjacent
As the population grows in certain areas more than others, the codes reserved for other regions can get allotted to them. An example of that is the San Francisco Bay area, where the first 408 and then 669 was allocated on top of the existing 650 area codes to deal with the growing population.
Confirming phone number ownership
You can never trust an incoming call or incoming SMS’s phone number. Therefore, the only way to verify that the user owns a phone number is by sending them a text message or making them a phone call.
Things to do in Cusco (Peru)
Cusco or Cuszo, an Andean city in South America, was the seat of the Inca empire and is home to world-famous Machu Picchu. I would recommend staying near the city center of Plaza De Armas (“Parade Square”). Most tourist activities are in and around the area.
Incremental testing: save time and money on CI for monorepo
To use monorepo or not is an eternal debate. Each has its pros and cons. Let’s say you decide to go with monorepo, one major issue you will face over time is slow testing. Imagine a monorepo, consisting of an Android app, an iOS app, some backend code, some web frontend code. In only very few occasions will someone modify more than one of those simultaneously.
Further, add to the fact that most of these projects confined to their directories would be using different build systems as well, for example, gradle for Android, yarn/npm for Javascript, go/rust/java/npm for the backend. The total build time, as well as test time, will only grow over time. It annoys developers making small modifications to their part of the codebase. And it slows down the development velocity drastically.
How to deploy side projects as web services for free
In 2020, the web is still the most accessible permission-less platform. For the past few months, I have been playing and building side-projects to simplify my life. I started with a Calendar Bot for scheduling events, DeckSaver for downloading decks from Docsend, AutoSnoozer for email management, and StayInTouch for maintaining follow-ups.
When I started on this journey, I had the following in my mind.
- Cost of domain ~ 12$ a year or 1$ a month
- Cost of a VM ~ 10$ a month
Docker 101: A basic web-server displaying hello world
A basic webserver
Docker containers are small OS images in themselves which one can deploy and run without worrying about dependencies or interoperability. All the dependencies are packed in the same container file. And the docker runtime takes care of the interoperability. You are not tied to using a single language or framework. You can write code in Python, Go, Java, Node.js, or any of your favorite languages and pack it in a container.
Consider a simple example of a Go-based webserver
